Al momento stai visualizzando Kanban vs. diagramma Gantt
Diagramma di Gantt vs Kanban

Kanban vs. diagramma Gantt

  • Categoria dell'articolo:Agile / Kanban

La transizione dalla gestione tradizionale dei progetti alla gestione snella con Kanban può essere impegnativa. Si sente spesso dire che la pianificazione Kanban è difficile e che molti team si rifiutano di seguire la via Kanban perché “non sanno pianificare”, o meglio… c’è una certa pianificazione a cui molti project manager aspirano anche sulla via di un’azienda agile: la buona vecchia pianificazione con il diagramma di Gantt.

Una cosa in anticipo: il diagramma di Gantt è meraviglioso per visualizzare le dipendenze o le sequenze. Tuttavia, non appena si allegano date di inizio e fine ai singoli elementi di lavoro, si apre il vaso di Pandora. Perché?

Perché abbiamo una leva: “Il progetto è indietro, lavorerai nel fine settimana”.

Perché possiamo giustificare le cattive decisioni: “Tu vuoi che lo facciamo entro venerdì, quindi non lo facciamo, facciamo quello che possiamo”.

Sappiamo di essere in orario: “I grafici sono verdi, ma nessuno sa cosa sta realmente accadendo”

Abbiamo ancora tempo e non dobbiamo avere fretta: “Il compito è programmato per 5 giorni, quindi facciamo in modo che ci voglia almeno quel tempo”

I diagrammi di Gantt sono accettabili per circostanze di bassa variabilità, ma per il lavoro di conoscenza possono diventare un vero incubo.

Quando pianifichiamo una campagna di marketing  o sviluppiamo un software, semplicemente non sappiamo quanto tempo ci vorrà.

Come facciamo allora a creare un grafico di Gantt accurato? Abbiamo sicuramente bisogno di una migliore pianificazione, ed è qui che entra in gioco Kanban.

Pianificazione, stima e programmazione per te sono la stessa cosa? Per me no.

E allora tuffiamoci in queste tre definizioni:

The good one

La pianificazione è il nostro tentativo di organizzare il lavoro in modo che possa essere fatto in modo appropriato. Questo avviene all’inizio di un particolare periodo o fase del progetto/programma.

Per esempio, quando costruiamo una casa, durante la pianificazione consideriamo se abbiamo bisogno prima delle fondamenta, ordiniamo prima le finestre o scegliamo prima il sistema di riscaldamento.

Parliamo dei tempi approssimativi che prevediamo per il completamento del progetto. Abbiamo anche un’idea approssimativa dei costi totali.

Quando abbiamo abbastanza informazioni, pianifichiamo anche le dipendenze e cerchiamo di trovare misure adeguate per affrontarle.

Tutto questo è noto, naturalmente, e non importa se si usa Kanban, Lean, Scrum, Waterfall o qualcos’altro per questo passo.

The bad one

Mentre le stime approssimative vanno benissimo e lo facciamo comunque quando facciamo un piano generale, stimare a livello di singoli elementi di lavoro è una cosa abbastanza insensata da fare. Ci sono molte ragioni per cui non dovrebbe essere fatto:

Non sappiamo mai quanto tempo richiederanno i singoli compiti.

Quando stimiamo lo sforzo lavorativo, di solito creiamo aspettative irrealistiche

Quando dobbiamo fare una stima, di solito aggiungiamo un enorme buffer, “non si sa mai”.

Per una varietà di ragioni, alla maggior parte dei team viene chiesto di stimare lo sforzo del loro lavoro. Anche i team che affermano con orgoglio di lavorare in modo agile continuano a stimare la quantità di lavoro. In Kanbanize, stimiamo solo se un compito richiederà più di due settimane – questo è più o meno tutto ciò di cui abbiamo bisogno.

Just in time!

Programmare significa che impostiamo la data di inizio e di fine di ogni compito. La programmazione del lavoro di conoscenza è uno spreco. Sicuramente.

Se qualcuno sostiene di poter programmare efficacemente il lavoro di un team di lavoratori della conoscenza con più di una settimana di anticipo (anche questo è improbabile), dategli uno schiaffo in faccia e non parlategli più.

Non è un segreto che abbiamo bisogno di pianificare il nostro lavoro prima di farlo effettivamente. Tuttavia, dobbiamo accettare il fatto che non abbiamo alcun controllo sul futuro e semplicemente non possiamo sapere quanto tempo ci vorrà, no, neanche se è nel nostro diagramma di Gantt.

Se accettiamo questo, possiamo cambiare il nostro approccio di pianificazione da deterministico a probabilistico.

La sfida finale è accettare che sappiamo solo ciò che è importante ora – in questo momento.

È così che è nata la produzione just-in-time e le aziende producevano solo ciò che il cliente aveva già ordinato. È così che è nato Kanban – avevamo bisogno di un metodo per supportarci nel nostro lavoro quotidiano e per affrontare il futuro imprevedibile.

Come facciamo a sapere se la pianificazione Kanban è accurata?

Per organizzare i nostri flussi di lavoro, dovremmo evitare di fare la nostra programmazione e la stima del lavoro senza i dati pratici come base e  dovremmo invece concentrarci sulla pianificazione utilizzando dati storici reali sulla produttività e regolando ogni fase individualmente.

Quindi mettiamo da parte il diagramma di Gantt e sostituiamolo con l’unico successore sensato: la tavola di pianificazione visiva Kanban. Cosa ne dici? Se non sei ancora convint* della modalità, contattami per una consulenza gratuita.