Un’immagine vale più di mille parole. E questa sicuramente la conoscete:
Notevole eh.
Per chi non la conoscesse, consiglio la spiegazione che ne fa l’autore stesso. Io ne sono stato subito colpito, lo ammetto. Ma dalla seconda volta in poi che l’ho guardata e, da lì, per tutte le innumerevoli volte che mi è tornata alla mente o che l’ho rivista, l’unica parte che cattura completamentamente la mia attenzione (e mette il dito nel mio senso di inadeguatezza) è questa:
L’MVP, la “Earliest Testable/Usable/Lovable Product” o come più prosaicamente la chiamo io: la prima release. Dopo la prima release cominci ad avere dei feedback reali, cominci a capire cosa serve davvero, cosa migliorare, quali funzionalità cassare dal backlog, quali far salire, quali far scendere. Cosa più importante, il Cliente e gli utenti (almeno alcuni) si stanno portando a casa del valore, stanno lavorando, stanno usando il tuo software.
Dopo la prima release aggiungere funzionalità è in genere semplice e, se ti sei strutturato bene, anche veloce. Sì certo, sei in produzione dove tutto è più difficile e richiede attenzione e tempestività, ma l’unico software che ha un senso è quello che gira in produzione.
Siamo d’accordo che arrivare a quella prima release è bene. Ma la strada che ti ci porta è ricca di insidie scivolose. Fondamentalmente, per via di questo:
Queste le “insidie” che io ho pestato negli ultimi anni.
Cliente: “Mi serve ‘la macchina’!!”
E’ l’essenza della grafica di Kniberg. Però continua ad essere un problema serio. Mi spiego: quante volte il Cliente mi ha detto che gli serve il sistema o la funzionalità X per far qualcosa? Quante volte mi ha saputo dire l’obiettivo di business che c’è dietro quel qualcosa? Ci siamo capiti.
Gli obiettivi sono necessari. Senza obiettivi non ci sono vere priorità, senza priorità non serve nemmeno ragionare sulla prima release.
Ultimamente mi piacerebbe proprio evitare di imbarcarmi in questi progetti, ma non sempre è possibile. Lavorare su un’applicazione, un sistema o peggio ancora su una piattaforma senza sapere quali sono i veri obiettivi di business che si vogliono raggiungere (magari espressi in termini di €/anno), comincia a diventare demotivante.
Nella mia agoghé, ricordo un sacco di insegnamenti. Uno dei più garbati era:
Non fai l’imbianchino!
[G.Verraz]
con tutto il rispetto per gli imbianchini, ma mi sento come quello a cui viene chiesto di pitturare la parete gialla ed io faccio la parete gialla. Qual è il valore?
Che è gialla…
Per capirci: non sono un fan dei business plan, per niente, preferisco l’intuito. Ma quando l’intuito mi dice che qualcosa non va, preferisco avere un business plan.
Cliente: “Se non c’è tutto, non serve a niente!”
Questa è la malattia più comune: tutte le funzionalità sono necessarie, nessuna esclusa. Non è mai vero, ma è spesso dura farlo capire al Cliente. Il concetto è che ovviamente, prima o poi avrà tutto (se serve), ma per quello che è la priorità numero uno, perchè aspettare mesi e mesi?
Sembra facile da far capire, no?
Non lo è mai…
Ci sono tante cose che si possono fare per risolvere la questione, ma tutte hanno in comune due ingredienti importanti:
- Capire veramente cos’è il valore e dove sta
- Realizzare che quanto capito al punto [1] è un assunto da verificare il prima possibile
Il Cliente porta il primo ingrediente, noi il secondo. Poi si mescola insieme il tutto.
Cliente: “Posso aspettare (ma se non c’è tutto, non serve a niente)”
Tana. Questo è più comune di quanto io abbia sempre creduto; ovvero che il Cliente sia, in realtà, disposto a mettere sul piatto una proroga delle scadenze. Il succo alla fine è semplice: “è una vita che vado avanti senza il tuo software, non è che muoio se non ce l’ho proprio alla data X…se ti serve più tempo per fare tutto quello che è necessario, parliamone (facendoti pagare il mio disturbo, s’intende)”. La tentazione è alta, ma bisonga resistere per non ricadere nella trappola del “voglio la macchina completa”. Parliamoci chiaro: ultimamente fissare delle scadenze a breve termine è più utile a me che al Cliente. Nel caso in cui ci troviamo a gestire in parallelo diversi filoni progettuali, con risorse limitate (lo sono sempre), il time-boxed è il nostro unico punto di riferimento. Si va in deroga ad una scadenza su un singolo progetto? Le reali conseguenze dell’effetto domino che ne conseguono sono spesso oscure. Quando capisco che un progetto è in ritardo, la domanda che mi sale istantanea come un brivido lungo la schiena (o mi scende…vedete voi) è: chi si incazzerà? o “Quanti?”. Oramai sono consapevole di questo e quindi, appena posso, informo il cliente delle date che mi sto dando. E cerco di fare in modo che la data sia la più vicina possibile, perchè è solo da quel momento che sarò pagato (in feedback o altro) e capirò se il lavoro fatto è nella direzione giusta. E mi sforzo per fare in modo che la data non sia prorogabile. E’ più un problema mio quindi…
Ma alla fine non stiamo rilasciando valore se posticipiamo.
Cliente: “Se questo è l’inizio, allora meglio fermarsi”
Bisogna preparare il Cliente al fatto che quello che vedrà non è il risultato finale e bisogna fare in modo che abbia comunque un qualche appeal per lui. Vogliamo che lo usi e quindi va sufficientemente curato per invogliare il Cliente ad utilizzarlo anche solo su una piccola porzione dei suoi prodotti/clienti/utenti/processi/ecc.
E’ interessante per me notare che, in alcune circostanze (nelle quali la relazione con il Cliente è stabile), l’ipotesi di fermare le attività è spesso più dolorosa per il Cliente che per me. Soprattutto se parto con il concetto che il fallimento su scadenze corte è generalmente positivo.
Cliente: “Non sono io che lavoro per te, ma tu per me”
Questo in realtà non l’ho mai sentito dire, ma l’ho visto e lo vedo fare spesso. Rilasciamo l’applicazione X in release 1.0 e vorremmo dei feedback dai primi utenti, ma nessuno la utilizza. Perchè? Se non c’è un reale beneficio per gli utenti/cliente rispetto a quello che già fanno, nessuno utilizzerà veramente il nostro software o potrebbero darci dei feedback sulla base del loro utilizzo post-demo e non da un reale e continuativo utilizzo su casi concreti. Possiamo monitorare, ma il punto è che non solo dobbiamo capire qual è il caso d’uso specifico che copriremo con il nostro rilascio, ma aver chiaro il beneficio che il Cliente ottiene rispetto allo status quo, già dal primo giorno.
Non è da prendere alla leggera, perchè se le cose vanno così, non si è arrivati realmente alla prima release. Si potrebbe annunciare che la release 1.0 è in produzione (che in alcuni contesti pesa molto), ma in realtà non è vero.
In più se la release 2+ è condizionata dal feedback sulla release 1 (condizione che ultimamente cerco di mettere sempre), la prospettiva di avere dei feedback solo dopo diverse settimane (o mesi) ed in più averceli parziali o falsati è…come dire…
sgradevole(?).
L’immagine di Kniberg racchiude veramente tante cose per me ed è dura approcciare il percorso corretto che porta alla prima release. Ogni volta c’è qualche ostacolo diverso da affrontare, però l’obiettivo rimane uno, ovvero rilasciare valore velocemente.
Rilasciare. Valore. Velocemente.
Chiudo con un pensiero positivo:
Comments