La storia potrebbe cominciare così: una nuova organizzazione ci chiama, ci racconta come percepisce sé stessa, dicendoci dove vorrebbe migliorarsi, e ci chiede di supportarla.
Qui parte la “sfida previsionale”, dell’organizzazione e di noi stessi, sfida che deve accettare di buon grado il fatto di non potersi sottrarre alle regole implicite del Cono di Incertezza (Cone of Uncertainty), tanto decantate ed utilizzate quando si parla di Stime e Pianificazioni Agili.
Cone of Uncertainty
Il Cono di Incertezza è uno strumento fondamentale, “portato” nel mondo del software da Barry Boehm come “Funnel Curve” e basato su una serie di lavori che hanno origine nell’ambito di uno studio sul Risk management nell’ingegneria chimica promosso dall’American Association of Cost Engineers alla fine degli anni ’50 del secolo scorso.
Il nome Cone of Uncertainity viene coniato da Steve McConnel, dopo che il lavoro di Boehm è stato raffinato, tra gli altri, dalla US Air Force e dalla NASA.
La potenza di questo strumento si trova nell’essenza stessa dello sviluppo dei sistemi appartenenti alla sfera del “Complesso” e dall’accettazione che le conoscenze relative aumentano in relazione al grado di avanzamento stesso del progetto: è praticamente impossibile, dati gli strumenti e gli approcci attuali, conoscere in anticipo con certezza quanto impiegheremo per la realizzazione di un progetto software.
Ogni progetto è unico, nella sua realizzazione, e si fonda sul lavoro di Persone, che sono uniche a loro volta ed evolvono costantemente.
Quindi, tornando ad un’azione di trasformazione: come possiamo dare un tempo certo per raggiungere il risultato, se l’ecosistema a cui ci riferiamo è costellato da una serie così ampia di incognite? La risposta è semplice: non possiamo!
Quello che è possibile fare è sfruttare anche per le azioni di trasformazione i principi fondanti del Cono di Incertezza e considerare le stesse come un progetto (o meglio un programma) in cui si identificano degli obiettivi progressivi che consentono di attuare due aspetti primari:
- Innestare nel contesto elementi di trasformazione e crescita progressiva, in modo da sviluppare il percorso di cambiamento;
- Aumentare costantemente il nostro know-how di contesto, valutando i feedback ed i segnali che arrivano direttamente e indirettamente da quanto approcciato e dalle persone coinvolte.
In tal modo è evidente come un’azione di trasformazione debba realizzarsi a step progressivi, individuando finestre temporali (chiamatele Sprint o Iteration se preferite J) sufficientemente ampie da poter rendere significativa l’azione specifica, ma al contempo sufficientemente strette da poter intervenire rapidamente per correggere il tiro.
Al termine di ogni finestra temporale, è fondamentale validare quanto raggiunto, riflettere sugli step successivi e, di conseguenza, capire come allocare sufficienti risorse per raggiungere i nuovi obiettivi: approccio Lean Startup docet!
E qui si lega anche la classica domanda: ma come contrattualizzare il tutto?
La tematica è molto ampia, ma, in generale, valgono le stesse considerazioni e la maggior parte degli approcci che vanno sotto il cappello di “Contratti Agili”, dai più tradizionali Fixed-Price Contracts ai Cost-Plus Contracts.
Un approccio progressivo e legato alle evidenze, è un approccio che, nella mia esperienza, piace molto alle aziende, sentendosi “coccolate” e contando su un’azione “ricamata” sulle loro necessità e progressivamente rivista in funzione dei risultati ottenuti, piuttosto che essere vincolati ad un Piano realizzato up-front e poi preso a riferimento di tutte le scadenze a discapito del Valore prodotto…. waterfall memento!
Stay tuned J
