Output e outcome: qual è la differenza?

Il prodotto non è il risultato…

Nel mondo Agile è molto frequente il riferimento ai termini inglesi output e outcome, ma qual è esattamente il loro significato e quali le differenze tra i due?
Partiamo innanzi tutto dalla traduzione: l’output è ciò che viene creato alla fine di un’attività; potrebbe essere ad esempio una funzionalità, un prodotto o un servizio. L’outcome invece è il risultato finale, ovvero l’effetto che quella funzionalità, quel prodotto o quel servizio generano.

I risultati sono ciò che l’azienda vuole o deve ottenere (ricordate quando abbiamo parlato di vision e mission così come di obiettivi strategici?). Gli output sono le azioni o i deliverable che contribuiscono al raggiungimento di quel determinato risultato.

Crediti Crisp’s Blog

Soffermiamoci un attimo a considerare le differenze tra i due.
Gli output sono spesso tangibili e facili da misurare. Non sono le ragioni per cui viene avviato un progetto, bensì mezzi per un fine. Di norma possono essere controllati da chi gestisce il progetto o il prodotto e, una volta rilasciati in produzione, non ci forniscono una vera misura di efficacia.

L’outcome invece è per lo più qualcosa di intangibile e difficile da misurare. Il risultato finale che si vuole ottenere è esattamente il motivo per cui viene avviato un progetto o creato un prodotto.
Non è possibile controllare direttamente il risultato, quanto piuttosto influenzarlo con una serie di attività e misurarlo a posteriori con parametri di efficienza ed efficacia.
L’outcome dal mio punto di vista è esattamente ciò che viene definito un impatto nell’Impact Mapping.

Esempi di output e outcome

Facciamo qualche esempio pratico per essere sicuri di avere chiare le differenze.

Prendiamo il caso di una catena di fast food che produce hamburger.
L’hamburger è l’output, ciò che viene creato alla fine del processo. Il numero di hamburger prodotti o di persone servite ci fornisce un’indicazione sulle performance del ciclo di produzione ma non ci dice niente sulla risposta dei clienti e su come questi siano stati influenzati.
Due outcome possibili sono ad esempio la percezione di qualità da parte dei consumatori o la capacità del prodotto di eliminare la fame.

Altro scenario. Un bambino di 6 anni invita i suoi compagni di scuola per festeggiare il suo compleanno. Il culmine della festa è la torta a tema Spider Man ordinata con tanta cura dai genitori.
La torta è l’output in questo caso. Ma cosa succede se il dolce tanto atteso arriva con la scritta “Tanti Auguri Camilla”? O se ha il disegno di Peppa Pig al posto di Spider Man? Sono certa che qualunque genitore o chiunque abbia avuto a che fare con bambini di quell’età sappia perfettamente che il risultato finale (nonostante la consegna della torta) sarebbe disastroso.
Certo! Perché l’outcome atteso qui è una festa di compleanno ben riuscita e una masnada di bambini felici, non semplicemente mettere il dolce sul tavolo.

Infine consideriamo un ultimo esempio ripreso dal mondo no profit.
Parliamo di un’associazione di volontariato per la prevenzione e la lotta all’AIDS.
In questo caso un possibile output sono gli incontri di approfondimento, le lezioni e i workshop che l’ente tiene periodicamente per sensibilizzare i cittadini sul tema.
Il numero di questi eventi ci fornisce un’indicazione di performance rispetto all’output, ma l’outcome vero e proprio è la maggiore conoscenza e consapevolezza delle persone su questa tematica e l’acquisizione di comportamenti adeguati. Un risultato questo tutt’altro che semplice da monitorare.

E’ chiara la differenza adesso? Il cosa non è il perché: gli output sono le cose che produciamo – fisiche o virtuali che siano – per un certo tipo di cliente, gli outcome sono la differenza che queste cose fanno.
Se acquisto un seggiolino per auto quale risultato mi aspetto? Cosa è realmente importante per me? Che il bambino sia al sicuro durante gli spostamenti; questa è l’unica cosa che conta davvero!

Perché come Product Owner devi focalizzarti sull’outcome

Personalmente nel corso degli anni ho sperimentato entrambi i modelli di gestione dei progetti: per output e per outcome (i primi – ahimè – molto più frequenti dei secondi).
Prima di scoprire l’Agile seguivo progetti focalizzati sul rilascio di funzionalità piuttosto che sull’indicazione del risultato atteso.
Al team di lavoro veniva richiesto di creare una serie di feature seguendo requisiti di dettaglio.
Cosa veniva misurato al termine del progetto? Tempi, costi e – a volte – aderenza alle specifiche iniziali (l’ambito o scope per i project manager), tutti indicatori che dicevano poco o nulla del successo di un prodotto.

Questo è un punto che ho sottolineato in tanti post: non basta arrivare a rilasciare un prodotto in produzione per avere successo se ciò che abbiamo realizzato non interessa a nessuno.
L’outcome è proprio il vantaggio che i clienti ricevono dalle soluzioni che offriamo perché ci siamo presi il tempo di comprenderne a pieno le esigenze.
L’outcome è il vero valore per il cliente finale, ecco perché dev’essere il focus primario di un Product Owner!

L’output invece – più facile da misurare – è spesso oggetto degli indicatori aziendali.
Ma se monitoriamo solo il raggiungimento di quest’ultimo senza misurare i risultati da un punto di vista più strategico, si produce il cosiddetto “effetto anguria”.
Tutti i report e le dashboard a prima vista si presentano con KPI positivi, ma quando si approfondiscono gli indicatori dei risultati attesi (quelli che misurano il raggiungimento dell’obiettivo) i numeri sono in rosso.
Ed è chiaro il motivo: hai creato un COSA senza un PERCHE’ (un punto-chiave sul quale Simon Sinek ha detto tutto ciò che c’era da dire in “Start with Why“).

Quindi perché dovresti preferire progetti outcome-driven piuttosto che output-driven?
Per evitare di produrre waste (spreco). Per deliziare i clienti, non fare più cose. Per fare la differenza e non creare solo “roba”.

Quando ho avuto l’occasione di lavorare su progetti gestiti per risultati (outcome-driven) la musica è cambiata e di molto! In quel caso gli stakeholder in azienda ci hanno lasciato “carta bianca”.
Sono stati più sfidanti e più difficili, hanno richiesto un lavoro di discovery molto più approfondito e tanta sperimentazione con il cliente finale ma alla fine raggiungere l’obiettivo ha avuto tutt’altro sapore.
E aggiungo anche un’altra cosa: sono questi i progetti dove i team di lavoro fanno davvero un salto in termini di crescita e di consapevolezza nella gestione del prodotto.
Talvolta è un’esperienza per stomaci forti, ma ne vale davvero la pena.

Crediti businessillustrator.com

Perché la gestione per risultati è merce rara

Sempre in tema di outcome qualche tempo fa ho visto in rete un intervento di Teresa Torres al Business of Software (BoS) che mi ha colpito. Trovo che faccia delle riflessioni interessanti e particolarmente acute sul perché sia così difficile applicare la gestione per risultati e, dato il tema trattato nel post, ho deciso di condividervi qui una sintesi.

Questo è lo scenario che incontra più di frequente nella sua attività di Product Coach: “nonostante si parli di gestione in base ai risultati da anni, i manager hanno spesso ancora difficoltà a concedere ai team la flessibilità e la libertà per esplorare il percorso migliore al raggiungimento degli stessi. Si continuano a dettare le azioni che i team devono intraprendere per raggiungere tali obiettivi e si ricade quindi negli output.”

Perché succede questo? Secondo la Torres c’è un sostanziale problema di fiducia.
Da una parte i manager non credono del tutto che i team possano raggiungere i risultati da soli, cadono spesso nel micro-management e concentrano i feedback sui dettagli piuttosto che nel comunicare la visione strategica; dall’altra non tutti i team hanno la seniority necessaria per avere successo con questo tipo di gestione e anche i più maturi dimostrano scarsa capacità di comunicare i progressi verso i risultati. Sono abituati a concentrarsi sulle conclusioni dei loro ragionamenti – le funzionalità che implementeranno, i progetti che eseguiranno e le iniziative che forniranno – senza condividere i motivi che li hanno portato a quelle scelte.
Focus sui dettagli e micro-management sono due facce della medesima medaglia.

Affinché questo circolo vizioso si spezzi sono necessarie due cose secondo l’opinione della Torres: insegnare ai team come comunicare i loro progressi verso un risultato ed insegnare ai manager come fornire feedback migliori.

Concordo con la sua visione. Ma mi piace l’idea di condividere qualche suggerimento pratico che possa fare la differenza da subito nella vita di tutti i giorni.
La raccomandazione è questa: quando vi viene richiesto di produrre qualcosa chiedete perché e cercate di capire la necessità che sta dietro la richiesta.
In questo modo state portando la conversazione ad un livello più alto e state educando anche il vostro interlocutore a ragionare sull’outcome.
Sembra una cosa da nulla ma è in realtà una rivoluzione più grande di quanto possiate immaginare!

4 livelli per requisiti agili

Recentemente ho avuto occasione di seguire un workshop di Sally Elatta dal titolo “4 levels of Agile Requirements”.
L’idea centrale della relatrice – fondatrice di Agile Transformation e Agile coach – è che sia fondamentale approcciare i requisiti agili secondo diversi gradi di astrazione.

Questo modus operandi non è una novità.
Abbiamo già parlato di come l’introduzione di una gerarchia nel Product Backlog possa essere d’aiuto sia per il team sia nei rapporti con gli stakeholder di progetto.

Sally Elatta ripropone questa idea sottolineando l’importanza di avere punti di vista sul progetto che vanno dal generale al particolare, ovvero:
epiche
funzionalità
user stories
– singole attività (task)

Considerare i requisiti secondo questi 4 livelli di astrazione consente di legare le singole attività implementative con la “big picture” del progetto e dare così valore alle scelte che dovremo effettuare nel corso dello sviluppo.

Livelli di progetto

La continuità tra i vari livelli è ben rappresentata nell’immagine.
In relazione al Backlog ci interessa concentrare l’attenzione sui 3 livelli centrali.

USER STORIES

Le user story rappresentano il secondo livello dal basso, quello in cui propriamente avviene l’azione o interazione.
Descrivono brevemente ciò che il sistema può fare per risolvere un problema specifico di un utente ben definito.
La caratteristica principale delle storie è essere focalizzate sul valore che producono per il soggetto, a differenza dei singoli task che sono invece una segmentazione delle attività ai fini della lavorazione da parte del team.

 

FUNZIONALITA’

Ad un livello superiore di astrazione rispetto alle user stories troviamo le funzionalità (features), che costituiscono una descrizione più tradizionale del comportamento del sistema.
Sono il livello intermedio tra i bisogni dell’utente e la soluzione progettuale complessiva.
Il concetto di funzionalità ha dal mio punto di vista un enorme pregio: collega le singole attività portate avanti dal Team Scrum con una terminologia utilizzata abitualmente da figure professionali quali Program Manager, Product Manager e manager in generale.
Mediante un elenco di funzionalità siamo in grado di descrivere il nostro progetto con un discreto grado di approfondimento e di spiegarlo anche ad interlocutori non avvezzi alle metodologie agili.

In alcune realtà aziendali di dimensioni medio-grandi anche i team di sviluppatori potrebbero essere organizzati intorno a queste feature.

 

EPICHE

Infine le epiche rappresentano il livello più alto di espressione del bisogno di un utente.
Sono i pilastri della big picture, le caratteristiche costituenti.

Le epiche sono i primi elementi che emergono dal concept di progetto. Si tratta di storie di grandi o grandissime dimensioni che
permettono di comunicare il perimetro di progetto in poche battute ma non consentono di effettuare una stima iniziale dato l’elevato livello di astrazione.

Il collegamento tra questi 3 livelli – storie, funzionalità ed epiche – ci consente di avere maggiore controllo sullo stato di avanzamento del progetto ed offre una chiave di lettura di immediata comprensione agli interlocutori.

Per questo motivo può essere molto utile verificare la consistenza del backlog salendo e scendendo attraverso questi 3 livelli.

Facciamo qualche esempio di “prova del 9“:

  • Possiamo ricondurre tutte le user stories ad un’epica corrispondente?
    Se non è così probabilmente potremmo avere “lavoro sommerso” e sprint goal poco definiti.
  • Ci sono epiche a cui sono collegate pochissime user stories?Verifichiamo di aver compreso bene le aspettative degli stakeholder. Potremmo aver perso qualcosa per strada o non aver spacchettato correttamente il lavoro.
  • Siamo in grado di tradurre il backlog della release in una lista di funzionalità? Possiamo sintetizzare con una percentuale di avanzamento a che punto sono queste feature ?

Potreste accorgervi – come nel mio caso – che non state utilizzando coerentemente o con continuità tutti e 3 i livelli.
Non resta che ispezionare e adattare il backlog, in perfetto spirito agile…

 

User stories efficaci: 5 regole per non sbagliare

Una guida per scrivere user stories

Quest’estate, mentre ero alla ricerca di titoli relativi al product management e alla raccolta dei requisiti, mi sono imbattuta in un piccolo manualetto dal titolo “Writing effective user stories” di Thomas e Angela Hathaway.

Si tratta di un libro in formato digitale di dimensioni molto contenute (si legge in un soffio) che offre alcuni consigli di taglio molto pratico sulla formulazione delle user stories.

La formula delle user stories a cui fa riferimento il testo è quella classica, costituita da 3 elementi cardine: il punto di vista dell’utente (meglio sarebbe dire dello stakeholder), il risultato atteso e la motivazione per la quale viene realizzata l’attività in questione.

Ovvero: “In qualità di <utente> desidero che <risultato> così da <motivo>”.

La formula sembra facile, addirittura banale rispetto ai classici documenti di requisiti. Eppure nella sua essenzialità si rivela veramente efficace per descrivere ciò che dev’essere realizzato… a patto che… a patto che si rispettino queste 5 semplici regole!

Perseguire la semplicità

La user story deve indicare un solo risultato atteso, non di più!
Gli autori suggeriscono di evitare l’utilizzo di frasi composte e perifrasi, di star ben attenti alle espressioni che contengono congiunzioni quali “se”, “e” o “ma” ma anche “a meno che” ed “eccetto”, perché è molto probabile che – data la formulazione – nascondano più obiettivi o risultati.
In questo caso è sempre meglio separare più concetti in diverse storie, così da garantire maggiore facilità di elaborazione.

Esprimere il cosa, non il come

E’ fondamentale distinguere tra il cosa (il risultato atteso) ed il come (la soluzione adottata per raggiungere quel determinato risultato).
Il “come” è oggetto di elaborazione del team di sviluppo, non degli stakeholder.
Focalizzarsi sul risultato di business evitando di concentrarsi su come raggiungerlo ci consente di non arrivare a prospettare una soluzione troppo presto.
Pensiamo alla meta finale, non al viaggio.
Evitiamo premature decisioni tecnologiche e lasciamo al team l’onere e l’onore di individuare il modo più adeguato di soddisfare il bisogno.
Una user story che si focalizza sul “cosa” esprime maggior valore.
Per esperienza non è così semplice astrarsi dal “come”… meglio rileggere più volte ciò che è stato formulato.

Mantenere la rilevanza nei confronti del progetto

La user story è coerente con la finalità generale del progetto? E’ in linea con il project charter (se presente)? E’ sempre bene porsi questa domanda, perché troppo spesso nel backlog sopravvivono requisiti poco rilevanti o di nessuna utilità.
Una user story rilevante descrive funzionalità rilevanti per il progetto in termini di business, che non eccedono o sono al di fuori del suo scopo e che non creano effetti “a cascata”.
Mantenere solo le storie rilevanti fa risparmiare all’azienda tempo e denaro, oltre a sostenere la motivazione del team.

Evitare l’ambiguità

Dato che è difficile individuare formulazioni ambigue quando si è gli autori delle user story in prima persona gli autori ci suggeriscono di provare a cambiare prospettiva.
Tentiamo di metterci nei panni del lettore.
Proviamo a rileggere quanto abbiamo scritto in un contesto diverso, ad un’ora diversa del giorno.
Meglio ancora – se ne abbiamo la possibilità – chiediamo a qualcuno di riscrivere o riformulare la nostra user story mantenendone il significato ma utilizzando tutte parole diverse.
Questo trucco costringe l’interlocutore a pensare fuori dagli schemi.
Una volta che la “traduzione” è fatta verificheremo se le due storie coincidono nel significato. Se c’è aderenza la user story iniziale non presenta ambiguità; in caso contrario si disporrà di indicazioni preziose per riformulare la storia.
Il semplice atto di analizzare il modo in cui qualcun altro interpreta le nostre storie originarie offre preziosissime indicazioni.

Rendere misurabili i requisiti non funzionali

Non è sufficiente formulare il risultato che si vuole ottenere, dobbiamo poterlo esprimere in termini misurabili in modo da renderlo chiaro a qualsiasi tipo di pubblico.
Per sviluppare una soluzione che soddisfi i bisogni del richiedente gli sviluppatori hanno la necessità di avere requisiti funzionali e non funzionali espressi in termini misurabili (ricadono tra questi ultimi quelli relativi ad esempio a frequenza, urgenza, volumi, accuratezza, usabilità, flessibilità, scalabilità, affidabilità, ecc.).
Ricordiamoci che ciò che è oggettivamente misurabile può essere validata anche da terze parti.
Solo fornendo un requisito realmente misurabile saremo in grado – a lavoro terminato – di verificare il raggiungimento del nostro obiettivo.