Indice
Hai mai la sensazione che gestire lo sviluppo e la manutenzione del tuo prodotto digitale svolte dal tuo team (interno o esterno) sia come cercare di spegnere un palazzo in fiamme?
Mi riferisco al fatto che definire le priorità degli sviluppi, delle attività di supporto, degli incidenti e di tutte le altre operazioni digitali è un vero e proprio inferno dove si risolve una cosa e se ne rompe un’altra, si litiga continuamente nel definire delle scadenze che molto frequentemente non vengono rispettate e lo spazio per migliorare la situazione si fa sempre più ristretto.
E questo avviene in modo paradossale: più si cerca di pianificare le attività in modo esatto, tentando di mettere a punto anche il più piccolo dei dettagli, facendosi dare stime più precise possibili dagli sviluppatori e dagli altri specialisti, allineandosi il più frequentemente possibile con il team, più la situazione si aggrava invece di migliorare.
Anche includendo tutte le micro attività in un bel grafico GANTT come farebbe un project manager tradizionale e mettendole tutte in fila, ti accorgi che il risultato è sempre lo stesso: il caos.
Ed ecco che ti ritrovi con attività che rimangono ferme e diventano sempre più urgenti, sviluppi affrontati a pezzi sparsi e mai terminati, criticità che crescono fino a diventare incidenti, software malfunzionante, ecc. In una situazione simile è ovvio pensare che il team di sviluppo con cui hai a che fare è in realtà una banda di incompetenti disorganizzati che produce codice male e in ritardo, con il quale si litiga per ogni singola attività e anche per le virgole di una e-mail.
Inoltre, dal punto di vista di un imprenditore digitale il risultato di quanto sopra è che stare in questo palazzo in fiamme significa bruciare denaro in opportunità mancate, oltre a portare uno stress che chiamo “incubo della tecnologia” e che toglie risorse allo sviluppo del business.
Se questa è la tua sensazione, o peggio è anche la situazione in cui ti trovi, sei in buona compagnia: è quello che avviene in quasi tutte le aziende digitali italiane che lavorano con un team tecnologico (interno e/o esterno fa poca differenza).
Praticamente tutte le aziende che ho visto negli ultimi 20 anni dove c’è un’importante parte di tecnologia digitale con sistemisti, programmatori e altri specialisti si sono ritrovate in questa situazione spiacevole.
Alcune sono fallite per questi motivi, molte altre non sono mai decollate come avrebbero potuto perché l’attenzione agli affari è stata deviata nel risolvere questi problemi e in generale come minimo i danni subiti sono sempre stati impattanti sul business.
O almeno questo è ciò che accade fino a quando non non si inizia ad adottare un metodo di gestione studiato e testato appositamente per risolvere questo specifico problema; la soluzione c’è.
Negli anni ho personalmente condotto numerose verifiche e revisioni degli aspetti tecnologici e organizzativi dell’IT presso aziende digitali di vari generi, in occasione di “audit” esterni in cui sono stato chiamato come esperto per effettuare valutazioni indipendenti. In molte di quelle occasioni imprenditori e manager (es. responsabili marketing) mi hanno raccontato la loro situazione, facendomi vedere lunghi elenchi di bug, attività che non venivano consegnate nei tempi, richieste che si accumulavano, ecc. in molti casi dandomi anche accesso a codice e infrastruttura per farmi toccare con mano la situazione. Il tutto, puntando il dito contro il team tecnologico in modo più o meno esplicito.
Ma non è (solo) colpa del team
La verità è che, dopo aver visto molte di queste situazioni e aver identificato le vere cause alla loro origine, con gli anni ho iniziato a prendere tutti questi indicatori come forti segnali che il problema in realtà non è (solo) nel team dei “tecnici” ma (soprattutto) nel modo di organizzare le attività, di prendere decisioni e nella cultura manageriale dell’azienda.
In occasione degli audit tendo dunque a storcere il naso quando mi si pongono osservazioni di questo genere dando la colpa in un solo verso.
Certo, approfondendo poi ho visto molte volte un modo di lavorare inadeguato da parte del team e l’assenza di molte buone pratiche di lavoro, in alcuni casi metodi e tecniche obsoleti (quante volte ho visto team fermi a SVN e tabelle MyISAM) ma queste non spiegavano mai l’intero problema.
Mentre leggi questo devi sapere che la mia indipendenza di cui ho accennato poco sopra deriva anche dal fatto che ho un punto di vista particolare: praticamente da sempre sono sia un imprenditore che uno specialista di aspetti tecnologici anche di basso livello, riesco quindi a capire sia gli imprenditori che i “tecnici” essendomi “sporcato le mani” in entrambi i ruoli, e a fare da ponte tra di loro. Non è quindi mio costume prendere le difese di uno o dell’altro per partito preso e questa indipendenza la mantengo anche nei confronti della mia stessa azienda.
Lavorare con le modalità convenzionali dei progetti nel digitale non funziona
E’ per questo, cioè vedendo le cose da entrambi i lati, che a conti fatti posso dichiarare che bisogna abbandonare definitivamente la nozione per la quale il modo convenzionale di gestire progetti deve essere l’approccio standard nel gestire e controllare lo sviluppo software e in generale ciò che fanno i gruppi di lavoro tecnologici.
Non funziona bene, e spesso non funziona per niente. Allo stesso modo posso affermare che un team che basa parte o tutto il lavoro su pratiche ingegneristiche quali quelle che ricadono nel cosiddetto “Extreme Programming” (XP) difficilmente è la causa dei problemi elencati sopra.
Non si può pianificare il 100% del tempo sulle attività a scadenza fissa
Un’altro mito da sfatare è quello che bisogna pianificare il 100% del tempo disponibile per aumentare la produttività, controllando regolarmente che il team non perda tempo e consegni le attività in tempo una dietro l’altra.
E’ l’esatto contrario: pianificare tutto il tempo disponibile sulla carta porta a una riduzione dei risultati e a problemi di pianificazione di elevato impatto.
Non si può pensare di avere una pianificazione in cui tutto il personale è occupato per il 100% del tempo su lavoro basato su scadenze fisse e magari ravvicinate una dopo l’altra, consentendo al contempo di interrompere le persone per gestire nuove attività urgenti, e aspettarsi lo stesso di avere il rispetto delle scadenze e la prevedibilità di come andranno le cose.
Anche se non ci fossero le interruzioni, in ogni caso l’impiego della totalità del tempo su attività che devono essere consegnate con scadenze stringenti non è una soluzione per ottenere efficienza, ma per ottenere estrema imprevedibilità e ritardi, per non parlare poi dell’insostenibilità a livello umano.
Un sistema organizzato richiede necessariamente delle pause, del tempo dedicato ad attività non pianificate, al fine di assorbire urgenze e variazioni di priorità, così come le persone stesse ne hanno bisogno se non vuoi bruciarle e alla fine renderle improduttive.
Questo tempo, tecnicamente, viene chiamato “slack”. In un contesto in continuo, forte cambiamento come quello delle tecnologie digitali è poi assolutamente necessario lasciare del tempo per la formazione, l’aggiornamento e la partecipazione a conferenze di settore.
Anche qui pensare di far lavorare senza sosta gli specialisti può portare un piccolo vantaggio nel breve termine ma garantisce l’obsolescenza nel medio/lungo termine e di conseguenza gravi problemi di competitività.
Alcuni dei team di cui accennavo sopra che usavano ancora tecnologie antiquate (senza inoltre guadagnare la maggior produttività derivata dall’utilizzo di strumenti più moderni) erano rimasti indietro proprio perché non gli era stato dato il tempo per aggiornarsi.
Diversi tipi di attività richiedono diverse modalità di gestione
Inoltre non è possibile trattare nello stesso modo tutto il lavoro da effettuare nel contesto di un prodotto digitale già operativo (quindi uscito dalla fase di costruzione iniziale), vi sono diversi tipi di attività che richiedono trattamenti specifici e flussi di lavoro differenti.
Ad esempio, alcuni tipi di attività sono da pianificare e prendere in carico in cicli di lavoro con una cadenza fissa, rispettando alcune fasi di lavoro.
E’ importante poi avere una roadmap anche di massima di queste attività pianificate che magari durano settimane o mesi, in modo da spezzarle in cicli di lavoro più piccoli anche settimanali. La tecnica è quella per cui un elefante si mangia un boccone alla volta.
Altri vanno gestiti a flusso, definendo dinamicamente le priorità in base non alla sola urgenza ma anche ad altri criteri molto articolati.
Altri ancora invece arrivano improvvisamente e hanno la precedenza su tutto il resto, come ad esempio gli incidenti in produzione.
E’ necessario analizzare la quantità di richieste e quante risorse abbiamo a disposizione per svolgerle
Capire tutti questi concetti è fondamentale per sapere come gestire meglio le richieste a fronte delle risorse che abbiamo a disposizione, così come per identificare le differenti variazioni nei flussi di lavoro che devono essere gestiti e come renderli compatibili tra di loro.
Comprendere quali sono le differenti sorgenti d’ingresso delle richieste aiuta a preparare e a gestire i carichi di lavoro mentre arrivano.
Sapere per quali ragioni è necessario sviluppare determinate attività aiuta a comprenderne i rischi in modo da poterli gestire nel modo opportuno, senza perdere delle opportunità.
È quindi importante condividere con il team le motivazioni che stanno dietro alle richieste, in modo da trasmetterne il valore ed evitare poi di doversi lamentare perché le rispettive attività sono state consegnate in ritardo per gestirne altre.
Capire la quantità di lavoro necessaria per svolgere quelle attività serve per scegliere la giusta granularità nel renderla visibile e controllarla.
Un problema tipico del mondo del software è infatti rendere paragonabile almeno in termini relativi la dimensione di ciò che il cliente (interno o esterno) sta chiedendo al team di sviluppo, che viene poi trasformato in modo troppo semplicistico nel mitico concetto delle “stime”, altra fonte di incomprensione e litigio perenne.
Meno dati si hanno e più il range della stima si amplia (si chiama “cono dell’incertezza”), rendendo difficile dare valori esatti o quantomeno vicini a quelli che saranno i tempi a consuntivo.
È invece un po’ più facile dare stime in termini relativi.
Per farmi capire: guardando un grafico con il sistema solare, è difficile dire con esattezza quanto è grande il pianeta Giove, però è più facile dire quante volte Giove è più grande della Terra vedendoli.
La chiave delle attività è renderle visibili con opportuni metodi.
Un altro concetto “strano” ma importante da capire è la cosiddetta “capacità di processo”, che in termini banali altro non è che l’output prodotto da una certa quantità di lavoro che un determinato team riesce a svolgere.
Attenzione: quantità di lavoro, non risultati.
Questi ultimi dipendono da altri fattori (riconducibili, sostanzialmente, in aspettative e una gestione sbagliate) e a parità di quantità di lavoro possono cambiare enormemente.
Questo spiega perché molti team composti anche da persone con capacità eccellenti che lavorano a pieno ritmo non producono tanti risultati rispetto ad altri team (magari anche più scarsi), a parità di tempo lavorato; non sono gestiti correttamente, tipicamente per le pressioni imposte da chi richiede l’esecuzione delle attività.
La capacità di processo può essere misurata in più dimensioni: lead time (tempo tra la richiesta iniziale e la consegna finale), prevedibilità, tasso di consegne, ecc.
È importante capire qual è il divario tra questa capacità di processo e le aspettative del cliente, per rendere evidenti quali tipi di miglioramento sono richiesti, da una parte e dall’altra.
Da questo punto di vista è utile controllare quanto lavoro è stato consegnato recentemente, quanto è attualmente in progresso e quanto è in attesa di essere processato.
Come gestire la pianificazione e la prioritizzazione delle attività digitali?
C’è quindi un modo migliore di gestire le operazioni digitali, tenendo conto di quanto appena indicato sulle reali cause dei problemi ed entrando nel dettaglio di ciascuno di essi? Certamente e lo approfondirò in uno specifico articolo in cui spiegherò alcune parti del metodo che ho creato negli anni e che devi seguire se non vuoi finire nella situazione che ti ho illustrato sopra. Più nel dettaglio ti spiegherò:
- Come definire le priorità e metterle in ordine.
- Come pianificare le attività.
- Quali sono i differenti tipi di attività da considerare, allineandoli ai risultati di business che vuoi ottenere.
- Gestire il lavoro per classi di servizio in modo da rendere compatibili tra di loro i differenti tipi di attività evitando l’effetto “palazzo in fiamme”.
Per ora sappi che se applicherai anche solo una parte delle indicazioni che ho elencato in questo articolo avrai compiuto il primo passo per spegnere alcuni grossi focolai nel tuo palazzo in fiamme.
Anche la tua azienda si ritrova in questa situazione?
Allora ciò di cui hai bisogno è un controllo diagnostico di tutti i tuoi processi, del tuo team e dello stato dei tuoi prodotti digitali, per ottenere le raccomandazioni e il piano di azione per arrivare al punto desiderato: un vero e proprio Check Up basato sul GamePlan, la nostra metodologia.
