Backlog senza priorità reali
Tutto era importante, quindi niente lo era davvero. Il backlog conteneva quasi quattrocento voci, molte duplicate, alcune obsolete. Le priorità venivano negoziate caso per caso, in riunione, senza un criterio condiviso.
Case study
Recupero di un programma Salesforce in ritardo di sei mesi
Quando siamo arrivati, nessuno sapeva più quante release fossero in coda.
Un programma Salesforce Commerce Cloud avviato due anni prima si era progressivamente ingolfato. Il team lavorava molto, ma le release si accumulavano, gli stakeholder iniziavano a essere scettici e i rischi venivano segnalati senza essere mai chiusi. Non era un problema di tecnologia. Era un problema di flusso decisionale e di governance del backlog.
In sintesi
Programma Salesforce Commerce Cloud in un contesto retail, team distribuito tra interno e tre fornitori, ritardo cumulato di circa sei mesi sulle milestone di rilascio. Il lavoro di recupero è durato tre mesi e ha restituito visibilità, ritmo e sostenibilità senza riavviare il programma né sostituire il team.
I cinque nodi
Tre fornitori, nessuna regia
Ogni fornitore lavorava sul proprio pezzo. Le integrazioni venivano scoperte in produzione, non disegnate prima. Quando qualcosa si rompeva, il primo passaggio era capire chi avrebbe dovuto saperlo.
UAT scollegata dalle release
I test arrivavano in ritardo rispetto alle release. Ogni go-live conteneva difetti che sarebbero stati intercettabili settimane prima, se l’UAT fosse stata parte del flusso di delivery e non un’attività a valle.
Stakeholder che non parlavano tra loro
Business, IT e marketing avevano priorità diverse e si incontravano solo nei comitati di escalation. Il programma non aveva una stanza dove le decisioni potessero essere prese davvero, prima che diventassero problemi.
Decision log inesistente
Le decisioni venivano prese in mail, chat e riunioni. Nessuno sapeva più cosa era stato deciso e quando. Le stesse domande tornavano ogni due settimane, e ogni volta la risposta era leggermente diversa.
Come abbiamo lavorato
Audit del flusso reale
Prima settimana: interviste a diciotto persone tra business, fornitori e IT. Mappatura di come si muovevano davvero le decisioni, di dove si fermavano e di quali responsabilità erano ambigue.
Priorità su un foglio solo
Riduzione del backlog da quasi quattrocento a meno di cento voci, suddivise per sostenibilità, valore e rischio. Tutto in un’unica vista condivisa, accessibile a tutti gli stakeholder.
Una regia per i fornitori
Cadenza di sincronizzazione settimanale tra i tre fornitori. Architettura delle integrazioni disegnata prima dello sviluppo. Un punto unico di sintesi tecnica, separato dalla discussione sulle priorità di business.
UAT come parte del flusso
Ambiente di test sempre allineato alla release in lavorazione, test plan integrato nel piano di delivery. Nessuna release in produzione senza UAT chiusa. Nessuna eccezione.
Decision log vivo
Un documento condiviso, una persona responsabile dell’aggiornamento, un formato semplice: cosa è stato deciso, da chi, quando, con quali conseguenze. Le decisioni passavano da qui prima di diventare lavoro.
Risultati
Tre release consecutive consegnate nelle finestre concordate. Backlog rientrato sotto le cento voci e gestito con priorità trasparenti. Tempo medio di chiusura di un’escalation passato da settimane a giorni. Il programma è proseguito con il team interno, senza più bisogno di una funzione di delivery esterna. Il valore non è stato l’intervento in sé, ma il fatto che l’organizzazione abbia recuperato la capacità di portare avanti il lavoro in autonomia.
Cosa abbiamo imparato
I programmi Salesforce raramente si rompono per un singolo motivo. Si rompono perché governance, integrazioni, backlog e UAT crescono a velocità diverse, e nessuno si occupa di mantenere coerenti tra loro questi quattro piani. Il delivery management non sostituisce il team: rende leggibili le interdipendenze che il team, dall’interno, fa fatica a vedere.
Approfondimenti collegati
Delivery Manager Salesforce Guida al delivery in progetti Salesforce complessi Audit di progetto Segnali precoci di un progetto in difficoltà Servizi
FAQ
?
Quanto è durato il lavoro di recupero? Circa tre mesi, con un coinvolgimento intenso nelle prime quattro settimane e una presenza più leggera nelle successive. Il punto non era restare a lungo, ma rimettere il team in condizione di proseguire da solo.
?
Si può fare un recupero senza riavviare il progetto? Quasi sempre sì. Riavviare costa molto di più e raramente risolve. È molto più efficace fare ordine in ciò che già esiste, separando ciò che vale da ciò che si è accumulato per inerzia.
?
Quanto è replicabile questo approccio? Il metodo sì, i tempi e gli interventi specifici dipendono dal contesto. La logica resta: prima la lettura del flusso, poi gli interventi mirati.
Hai un programma Salesforce che ha perso ritmo?
Raccontami in breve il contesto: dove sta rallentando, chi è coinvolto e da quanto tempo. La prima conversazione serve a capire se ha senso continuare a parlarne.