Da Progetto a Prodotto

Versione PDF “Pretty”

https://agileitalia.agileforitaly.com/index.html#1_2019

di Dimitri Favre

Ciao Dimitri raccontaci chi sei?

Sono un programmatore e morirò programmatore, come diceva Robin Williams nella leggenda del Re pescatore.
Il programmatore è come il fumatore che anche se ha smesso di fumare continua ad esserlo fino alla fine dei suoi giorni.

Abbiamo letto il tuo libro in anteprima, Complimenti! Innanzitutto spiegaci perché prodotti e non progetti?

Quello che noi tutti facciamo sono i prodotti ed i progetti sono solo uno strumento che storicamente abbiamo utilizzato per realizzare i prodotti che utilizziamo tutti i giorni.
Nel software i prodotti hanno una caratteristica che li differenzia molto dai progetti ed è tutto legato al loro ciclo di vita, ad esempio un software fin che non lo si dismette è un qualcosa di vivo e che viene continuamente modificato. Il progetto invece finisce molto prima ovvero quando metti il software in produzione, poi chi si è visto si è visto.

Quali sono le più grosse deviazioni che hai visto nella pratica?

Nella pratica ce ne sono diverse, la più grossa deviazione è che i progetti vengono affidati a dei team creati ad hoc per fare i progetti. Questo crea una serie di problemi perché quando metti insieme delle persone che non hanno mai lavorato insieme, inevitabilmente ci si butta a capofitto nella valle della curva di Tuckman passando da un gruppo di persone ad uno pseudo team che è terribilmente inefficiente perché deve imparare a lavorare insieme e quando ha fnelmente imparato a lavorare insieme si butta via tutto perché si è consegnato il progetto.

Se siamo un’azienda di prodotto, come facciamo a conciliare quello che ci hai appena spiegato con dei fornitori esterni?

Questo è un tema molto interessante e non ancora risolto, non solo da parte mia ma anche a livello di ricerca. Ad esempio grazie al lavoro di “Bjarte Bogsnes” in Beyond Budgeting si studia come viene deciso di spendere i soldi dell’azienda, quando si fa un budget lo si finalizza non al prodotto ma al progetto che costruirà quel prodotto con tutte le conseguenze del caso.
Deve essere finanziato un progetto, aspettare che venga approvato e tipicamente quel determinato progetto viene approvato sulla base di uno “scope” definito.
Io mi chiedo, non si ragiona sul beneficio che introdurrà? SI in parte ma poi si stimano le cose in base a quello che verrà fatto, le “features” previste e ci si dimentica dei “needs” che vogliamo risolvere in realtà.
Quindi in questo modo si è molto poco Agile perché si è già definito tutto quello che ci deve essere, si è stimato quanto si spenderà e si farà di tutto per spendere quei soldi.
Le persone vengono valutate in base a come spendono bene il loro budget, questo significa che lo devono spendere tutto e non che ne devono spendere di meno.
Tutto questo non è molto Agile, tipicamente il lavoro che si fa oggi è stato pensato almeno 12 mesi fa.
 
Nella tua esperienza e cercando di salire nell’organigramma in generale il budget è una cosa che riguarda il CFO, hai visto delle implementazioni strutturate? SAFE è una soluzione?

SAFE qualcosa dice come anche “Scott Ambler” in Disciplined Agile ma secondo me fanno un po’ di casino perché trasferendo tutto dall’alto al basso e ragionando sempre in termini di sistemi estremamente grandi, molto più grandi di quelli che normalmente si incontrano, tendono a complicare più del necessario le cose.
Dal punto di vista pratico molte aziende di prodotto lavorano con un principio molto semplice ovvero anziché finanziare lo “scope” finanziano la “capacity”. Nella pratica è quando io non so esattamente cosa farò, ho fatto una roadmap in termini agili (come detta il buon senso e le regole) so che voglio migliorare i miei prodotti e per farlo stimo di aver bisogno di una certa capacità lavorativa interna o esterna.
Su questo argomento però si innesca il tema dei contratti che non è semplice perché un modello di questo tipo basato sull’esternalizzazione finisce per privilegiare i contratti “Time Material” che non sono necessariamente l’ideale perché non permettono lo “Skill in the Game” del fornitore. Al contrario altri tipi di contratto come quelli “Fixed Price” lo “Skill in the Game” è tutto indirizzato al fornitore e mai a beneficio cliente.
Nella realtà il problema è capire quali sono veramente gli obbiettivi di evoluzione del prodotto o dei prodotti che abbiamo, capire le necessità del mercato che dobbiamo soddisfare o quello che il mercato ancora non conosce e cercare di strutturarsi per avere una “Capacità di Delivery” più che finanziare lo “Scope di Delivery”.
Cosa vorresti dire ad un CFO per convincerlo di questo?

Questo è uno dei pochi temi a cui non abbiamo ancora sufficientemente “presto abbastanza attenzione” come movimento Agile.
I CFO dovrebbero essere sensibilizzati sul fatto di avere una gestione più Agile del budget, ad esempio una revisione del portafoglio delle iniziative strategiche con una frequenza molto maggiore rispetto all’ approvazione annua del budget che, tra l’altro, si presta molto ad essere un po’ taroccata. Nella pratica vengono chiesti soldi, ma più di quello di cui si ha bisogno, perché non si è comunque mai certi e si cercherà di spenderli tutti indipendentemente da come vanno le cose… perché altrimenti l’anno successivo vengono tolti.
La soluzione potrebbe essere rivedere continuamente su base trimestrale o addirittura mensile le iniziative a livello Agile o Lean.
Ad esempio in Safe di molto interessante c’è il “Lean portafoglio Management” che grazie ad una kamban board permette di gestire le iniziative ad alto livello.
Anziché finanziare la capacity e lo scope da oggi ad un anno con qualcosa che è partito 6 mesi prima ( quindi 18 mesi di “look ahead”) si dovrebbe cominciare a ragionare in maniera molto più tattica e sul breve periodo.

Dimitri Favre

Dimitri Favre

Website

Business Agility Transformation and Agile Coach at Accenture | Trainer | Speaker | Book Writer | Thought Osteopath

This author does not have any more posts.