Menu
Contattaci
Esiste una tecnica giapponese detta “dei 5 perché”, utile a determinare la motivazione profonda che si nasconde dietro ad un’azione o un evento. Consiste nel chiedersi il perché di quell’azione, di esaminare la risposta e di chiedersi di nuovo perché, e così via per 5 iterazioni. Se entro l’ultima risposta non si ottiene una motivazione in linea con le massime priorità della vita, allora quell’azione è superflua e consuma inutilmente tempo ed energia, quindi non va fatta.
Supponiamo che “Tutti i martedì prendo una pizza con Giorgio”. Magari lo faccio “perché Giorgio mi propone argomentazioni interessanti”, importante “perché ciò mi permette di avere un rapporto sociale significativo” e magari dopo un altro paio di perché sono motivato a farlo “perché questo contribuisce ad un’appagante rete sociale che mi rende felice”: ho conferma che questa è un’ottima ricorrenza! Se dopo cinque perché, invece, ottengo solo “perché non ho di meglio da fare” o “perché è un’abitudine”, magari farei meglio a trovare altre attività, o altre persone per me più interessanti con cui prendere una pizza.
Ma arriviamo allo sviluppo software. Sakichi Toyoda, inventore della tecnica dei 5 perché e re degli inventori giapponesi, portò la tecnica alla Toyota negli anni 30 come approccio per gestire problematiche e relative soluzioni nel processo produttivo – da qua la tecnica entrò in automatico nel panorama Agile.
Un esempio più tecnico: Giorgio recentemente ha lasciato diversi bug nel software che hanno causato problemi nello sviluppo. Alcune tecniche manageriali consistono nell’insistere a dire a Giorgio che deve stare più attento e minacciare ripercussioni – può funzionare, ma alla lunga insistere sullo “stai più attento” non è tanto diverso che aspettarsi che una programmatore migliori ripetendogli “programma meglio”. Cosa può venire fuori dalla tecnica dei 5 perché? Magari scopriamo che “Giorgio è distratto continuamente da richieste del cliente”, oppure “Giorgio è demotivato perché non ha chiara l’utilità del suo lavoro”, o magari “Giorgio si sbronza tutti i martedì da quando non ha più compagnia per la serata pizza”.
Il problema potrebbe essere entrato nel nostro cerchio di controllo, e potremmo fare qualcosa per la cosiddetta root cause, come distribuire meglio le richieste del cliente, rendere Giorgio più partecipe degli obiettivi del progetto o organizzare un aperitivo leggero tra colleghi sul presto.
In questo articolo parlerò dell’Impact Mapping, ma come i palati più fini avranno già intuito, non descriverò in dettaglio i punti tecnici per portare avanti questa tecnica (per cui esistono già numerose ed ottime risorse online) ma discuterò come questa tecnica può avere conseguenze positive anche dal punto di vista della motivazione e della coesione di un team o di un’azienda. Ho iniziato discutendo la tecnica dei 5 perché in quanto la motivazione è un tema centrale sia nell’Impact Mapping sia per la crescita e lo sviluppo personale in un’azienda.
Una impact map è una rappresentazione grafica che collega in modo diretto ed intuitivo l’obiettivo che vogliamo raggiungere con il lavoro giornaliero che facciamo per realizzarlo. Si compone di 4 livelli – il perché, il chi, il come ed il cosa
Il perché deve essere un obiettivo chiaro la cui importanza sia lampante a chiunque veda la mappa. Anche quando l’obiettivo appare ovvio, analizzando i compiti fatti giorno per giorno in un processo di sviluppo può essere sorprendente quanti di essi non siano allineati con lo scopo del progetto. Mettendo il perché al centro della mappa, possiamo evidenziare quali siano le implementazioni meno utili, magari scelte per motivazioni politiche, per mire personali avulse dal bene del gruppo o per ragioni tecniche magari migliorative ma di dubbio impatto sul business.
Gli obiettivi devono essere precisi e ben definiti, o in altre parole SMART – Specifici, Misurabili, Orientati all’Azione, Realistici e Temporizzati. Questo permette di misurare, a posteriori, se un determinato obiettivo è stato raggiunto o meno. Una definizione precisa facilita inoltre decisioni su quanto si possa investire su un certo goal, o quale altro debba essere prioritizzato al suo posto.
Avere il perché al centro fa emergere automaticamente lo scopo di ogni compito, e rende difficile inserire qualcosa nel piano di lavoro senza un’opportuna giustificazione. Dal punto di vista dell’azienda, ci si assicura che ogni componente sia realizzato per tendere al goal. Per di chi sviluppa o produce, avere un obiettivo chiaro è molto più motivante di “faccio X perché lo vuole Y”. Dal punto di vista della comunicazione, ci si assicura che quello che stiamo creando sia allineato con quello che desideriamo.
Dai perché, possono emergere anche i valori di un’azienda o di un gruppo di lavoro. Se l’obiettivo è solo quello di ottenere più “vile denaro” (che comunque, in fondo piace a tutti) le cose possono anche funzionare bene, ma l’unico modo di tenere motivati i dipendenti sarà quello di pagarli sempre di più. Se abbiamo uno scopo che migliori anche un poco la vita e la qualità del lavoro a qualcuno, probabilmente potremo far leva anche su altre motivazioni più profonde. Per questo il secondo livello di un impact map coinvolge, per l’appunto, le persone.
Conoscere il perché è un’informazione sterile se non è chiaro chi con le proprie azioni ci potrebbe aiutare a raggiungere l’obiettivo. Per questo al secondo livello di una Impact Map è necessario definire, per ogni “perché”, chi sono gli attori coinvolti. Questi si dividono in tre categorie:
1. Attori primari, le persone che utilizzeranno direttamente il prodotto, tipicamente quelle che utilizzeranno il sistema
2. Attori secondari, che forniscono servizi di supporto al sistema (es. chi si occupa della sicurezza o della prevenzione delle frodi)
3. Attori che hanno in qualche modo interesse nel sistema, ma che non hanno collegamenti diretti come nei due casi precedenti
E’ importante specificare con precisione il chi, evitando il termine generico ‘utente’, in modo da qualificare meglio le persone coinvolte. Il passo successivo coinvolge come gli attori si dovrebbero comportare per andare in direzione del nostro obiettivo
Una volta che il nostro sistema è stato creato, in che modo le persone interagiranno con esso per fare ciò che prima non potevano fare? Oppure in che modo le parti in gioco potranno portare avanti delle operazioni nel modo migliore e più efficiente rispetto a come lo facevano prima?
Ci stiamo avvicinando alle funzionalità che dovremo realizzare, senza ancora parlare di aspetti tecnici, ma guidati dalle motivazioni di alto livello. Anche parlando del “Cosa”, ancora non dobbiamo trattare di funzionalità del programma, ma di requisiti di business. A questo livello, è rilevante anche considerare attività con un impatto negativo di ostacolo al nostro scopo – dovremo assicurarci che queste eventualità non si realizzano, e potrebbe essere necessario del lavoro anche per prevenire le possibili evenienze negative.
In questo quarto livello, per ogni “Come” dobbiamo elencare “Cosa” possiamo sviluppare per supportare l’impatto desiderato. A questo livello, abbiamo le funzionalità del software che potremmo realizzare, ma non solo: in alcuni casi, ci sono approcci alternativi che realizzano i nostri obiettivi senza la necessità di implementare nuovo software. Un esempio: in alcuni casi, investire in maggiore pubblicità può produrre un impatto maggiore di un miglioramento dei tempi di caricamento o la risoluzione di alcuni bug di scarsa rilevanza.
A questo livello, non è importante listare immediatamente tutti i dettagli, quanto piuttosto individuare le possibili alternative. Essendo legate ad un Come-Chi-Perché, tutto ha uno scopo ben preciso, e vengono tagliati fuori tutta una serie di compiti di scarsa utilità che finiscono spesso nel flusso di lavoro. Report che vengono letti due volte l’anno e funzionalità che nessuno userà per mesi molto probabilmente rimarranno fuori dal piano, per far spazio a feature utili per gli utenti, gratificanti da realizzare per gli sviluppatori e allineate agli obiettivi aziendali.
Vediamo un esempio di Impact Map, riportata da Gojko Adzic, autore del celeberrimo libro sull’argomento – abbiamo in mente un gioco per cui vorremmo avere un milione di giocatori
In figura, abbiamo anche dei livelli aggiuntivi ad espandere l’ultimo livello in componenti. Leggiamo un ramo della mappa: per raggiungere 1 milione di giocatori (perché), i giocatori (chi) potrebbero aiutarci invitando i loro amici (come) grazie a degli incentivi (cosa) come chips o riconoscimenti per chi ne invita molti (componenti del ‘cosa’).
Se abbiamo un processo di sviluppo Agile, da qua nascono le possibili storie; a seconda della grandezza del progetto, possono essere macrostorie (Epic) da poi risuddividere in storie di minore entità e/o in task tecnici. Dall’esempio:
“Come giocatore vorrei un sistema di incentivi in modo da essere motivato a invitare degli amici”
Molto meglio di “Come utente voglio un report per vedere cose”, vero? Non fa venir voglia di partecipare alla corsa per il milione di giocatori?
Per creare una Impact Map, il primo passo da fare è di ottenere le informazioni rilevanti dal nostro committente. Troppo spesso per richiedere un progetto software il cliente stila una lunga lista di funzionalità e si aspetta, alla consegna, di ritrovarsi un prodotto pronto con tutto quello che desidera. Purtroppo, senza avere chiari gli obiettivi, difficilmente le aspettative potranno essere rispettate. Chi sviluppa realizzerà funzionalità “perché sono state richieste”, che anche se tecnicamente perfette rischiano di essere inutili o sottoutilizzate, lasciando tutte le parti in gioco insoddisfatte.
Vogliamo una situazione diversa, dove partendo dagli obiettivi si possono discutere i possibili percorsi per arrivarci. Spesso chi realizza può avere proposte diverse per realizzare la stessa “Cosa” o per aiutare lo stesso “Chi”, magari ottenendo di più con meno sforzo. Con un piano così concordato, gli sviluppatori creeranno software utile, ed il cliente potrà esprimere le sue necessità in termini di business, con chiare corrispondenze con quanto verrà rilasciato. La mappa corrobora anche un linguaggio comune, ponte tra le parole del cliente ed il temibile linguaggio tecnico-informatico che risulta oscuro ai più.
Come parlare al meglio con il cliente? Ottenere il meglio è sempre una sfida non banale; come primo approccio, per ogni richiesta si può ricercare sempre il perché, magari con una tecnica simile a quella dei 5 perché discussa precedentemente. Quando possibile, potrebbe essere utile invogliarlo a usare queste tecniche proponendo del breve materiale introduttivo di terze parti.
Una volta steso un primo scheletro di una Impact Map, si può procedere con la scelta di quali funzionalità realizzare nella prima iterazione. Tenete presente che non tutto quello che compare nella mappa deve essere realizzato: non vogliamo fare tutto, ma trovare il percorso più breve da dove siamo ora al nostro obiettivo. Tramite una scelta accurata, è possibile che l’obiettivo venga raggiunto solo implementando una parte limitata di quanto riportato sulla mappa, e a quel punto quel che resta diventerà immediatamente obsoleto.
Come determinare su quali rami concentrarsi? Innanzitutto notiamo che gli archi che collegano le varie funzionalità con l’obiettivo rappresentano le nostre assunzioni. Nell’esempio, siamo sicuri che incentivare i giocatori a invitare gli amici implichi che otterremo più giocatori? Potrebbe funzionare, ma se il nostro gioco ha problemi di compatibilità con molti device l’impatto potrebbe essere molto limitato.
In generale, è molto difficile sapere a priori se un’assunzione è valida o meno; esperti del business possono essere di aiuto, ma avere certezze è comunque arduo. Un vantaggio dell’Impact Mapping è quello di fare emergere chiaramente le assunzioni, piuttosto che lasciarle come convinzioni personali date per scontato. Guardando la mappa, è facile metterle in discussione e capire perché un’idea ottima per una persona non è convincente per un’altra.
Nella scelta delle priorità, a questo punto vanno scelte le opzioni che si stima possano avere un grande impatto in relazione all’impegno richiesto per realizzarle. Può essere utile progettare degli esperimenti che mettano alla prova le nostre assunzioni e ne stimino l’efficacia nei confronti del raggiungimento dell’obiettivo. Per la scelta finale, si può procedere con un sistema di voti da parte dei partecipanti che permettano a tutti di esprimere diverse preferenze per le zone della mappa che ritengono più rilevanti.
Un altro problema tipico di molti progetti è quello di voler realizzare tutto, preferibilmente subito. Qualsiasi aspetto tecnico, grafico e commerciale deve essere al meglio, e tutti sono considerati obiettivi fondamentali. Il risultato di questo perfezionismo malsano è tipicamente un grande carico di lavoro, gran parte del quale ha poco o nessun impatto sul risultato finale. Anche stabilire priorità diventa difficile – da questo punto di vista, dire che è tutto importante non è tanto diverso dal dire che nulla lo è.
Per focalizzare gli sforzi, è utile definire come primo passo un unico obiettivo. Questo permette a tutto il team di essere allineato su uno scopo comune, e di fermarsi quando l’obiettivo è stato raggiunto – anche quando abbiamo tempo e risorse in avanzo, potrebbe non essere saggio proseguire al miglioramento del solito goal, perché con il passare del tempo è possibile che altri abbiano acquisito maggiore importanza.
A periodi regolari, è importante trovarsi per discutere l’obiettivo della successiva iterazione. Questo momento si combina bene con altre tecniche agili per la determinazione dei compiti da eseguire e per l’analisi in retrospettiva del lavoro fatto.
Sia durante la generazione di un’impact map, sia durante le revisioni periodiche, è importante saper proporre delle alternative alle soluzioni visibili sulla mappa. Può essere utile utilizzare una fase di brainstorming in modo da raccogliere un grande numero di idee anche di stampo molto diverso tra loro. Un ramo della mappa potrebbe essere realizzato tramite l’acquisto di un modulo software esistente. Migliorie grafiche potrebbero attrarre più persone al pari di nuove funzionalità.
Dovreste sempre essere pronti alla flessibilità per quanto riguarda i piani. Nell’informatica l’obsolescenza è sempre rapida ad arrivare, ed in un mondo dove il business cambia rapidamente è importante essere pronti ad adattarsi al cambiamento. Un’altra utile indicazione: se raggiungete l’obiettivo tramite un approccio totalmente diverso da quello previsto, sareste comunque soddisfatti? Se la risposta è no, c’è un problema con la definizione del perché, che probabilmente è lì solo per giustificare delle feature tecniche già pensate ma con uno scopo non ben chiaro.
Quanto presentato non è che un primo accenno sul mondo dell’Impact Mapping. Con questa breve panoramica, ho sottolineato alcuni aspetti interessanti per cui vale la pena approfondire questa tecnica. C’è molto altro da sapere, sia sull’Impact Mapping stesso sia su tutte le varie tecniche di cui fa uso e che sono state di ispirazione per il suo sviluppo.
Come molte altre tecniche che coinvolgono la comunicazione e l’interazione umana, per ottenere il meglio è molto importante sperimentare e fare esperienza. Molte metodologie agili sono strettamente correlate o perlomeno hanno un’ottima sinergia con questo approccio; anche team di sviluppo fuori dal mondo Agile possono tuttavia trarre beneficio da una Impact Map.
Credo che questa tecnica possa dare un contributo molto utile nel processo di sviluppo. Vedere un percorso chiaro dal lavoro giornaliero ad un obiettivo di riconosciuta importanza ha un chiaro impatto sulla qualità del lavoro, sia dal punto di vista dei risultati che da quello della soddisfazione personale. Discutere e definire insieme gli obiettivi fortifica il senso di squadra e di inclusione di tutti i suoi componenti. La visione chiara e condivisa di un obiettivo è fondamentale in molteplici contesti. Quindi, buon mapping a tutti.
L’impact mapping è stato reso celebre da Gojko Adzic, che in un piccolo libro facile da leggere e con tante figure è stato capace di promuovere una tecnica di grande impatto. L’autore afferma che la tecnica nasce dalla combinazione di molte altri approcci preesistenti, primo tra tutti il “InUse Effect Mapping”. Il punto di partenza che raccomando per approfondire i vari dettagli è proprio il sito ufficiale, al link