Che faccia ha il successo? Perché è essenziale definirlo

Un momento fondamentale in fase di avvio di progetto è il cosiddetto “business planning“, quando si definisce il problema da risolvere o l’opportunità di mercato da cogliere. Si badi bene: parliamo di definire chiaramente il problema, non di prospettare già la soluzione da adottare (come troppo spesso viene invece fatto in questa fase iniziale).

Tutti coloro che sono interessati in qualche misura dal progetto (cliente, sponsor, team di lavoro, project leader, ecc.) lavorano per il suo successo. Molto spesso tuttavia questa idea di “successo” assume forme svariate nella testa delle persone coinvolte.
Senza condivisione di intenti non c’è dubbio che le incertezze e le conflittualità finiranno per essere all’ordine del giorno.

Ecco perché è fondamentale definire a priori i criteri di successo di un progetto, condividerli con tutti gli interessati e – auspicabilmente – tracciarli per iscritto.
Prima di partire con le attività vere e proprie tutte le persone coinvolte devono avere un’idea chiara di qual è l’obiettivo comune. Che cosa considereremo un successo? Quali caratteristiche ha? Quali risultati dovranno essere raggiunti perché il progetto possa essere definito “di successo”?

La risposta a queste domande non è sempre ovvia ed è opportuno sia il frutto di un’elaborazione comune.
Offrirà le più preziose linee guida alla progettazione e allo sviluppo per tutta la durata del progetto.
Quindi come definiamo i criteri di successo?
Formulando esplicitamente obiettivi che abbiano le seguenti caratteristiche:

  • specificità
  • chiarezza
  • misurabilità
  • un’orizzonte temporale di riferimento

Facciamo qualche esempio:

  • aumentare del 5% in 6 mesi le vendite online mediante revisione del processo d’acquisto
  • ridurre del 10% entro fine anno le chiamate al call center di assistenza

Troppo spesso ho partecipato a progetti in cui, a distanza di mesi dal rilascio, il team di lavoro non aveva minimamente il polso della situazione su “come stessero andando le cose”. E’ così difficile raggiungere questo livello di trasparenza? Io penso di no…
Semplicemente non in tutte le realtà professionali si usa rendere i target evidenti all’azienda intera o – peggio – si tende ad avviare i progetti senza averli formulati compiutamente.

Eppure dichiarare e condividere i criteri di successo offre numerosi vantaggi:

  • crea un obiettivo comune a tutti e lo rende concreto
  • crea un riferimento in base al quale i team di lavoro possono prendere autonomamente delle decisioni in fase di progettazione e sviluppo
  • assicura che i committenti alla fine del progetto giudichino i risultati in relazione agli obiettivi quantitativi condivisi e non sulla base di qualche percezione del momento (alzi la mano chi non ha mai ricevuto obiezioni di questo tipo)
  • offre a tutti – anche alle funzioni non coinvolte – una prospettiva sui benefici che ne potrà trarre l’azienda nel suo complesso

Vi sembra poco? A me no!
Se tutti i progetti sui quali lavoriamo partissero con una “meta” così chiara il “viaggio” sarebbe certamente più piacevole, veloce ed appagante. Peraltro dare un volto al successo e formulare degli obiettivi è buona pratica nel lavoro, così come nella vita. Non sono mai stata una campionessa in questo senso ma “ci sto lavorando” ;-)

Nota: considerazioni liberamente tratte dalla lettura di “Effective UI“, Anderson, McRee, Wilson & the Effective UI Team

Il design? Iterativo per natura

Recentemente mi sono trovata a rileggere un grande classico della bibliografia sul design – “La caffettiera del masochista – Psicopatologia degli oggetti quotidiani” di Donald A. Norman – e ho constatato quanto questo libro, la cui prima pubblicazione risale al 1988, sia ancora assolutamente attuale per molti aspetti.

In particolare mi ha colpito un paragrafo che parla dell’evoluzione naturale del design.
Scrive Norman:

“Il buon design ha una sua evoluzione: il progetto viene messo alla prova, si scoprono e si modificano problemi e difetti, e poi viene continuamente riesaminato e rimodificato fino all’esaurimento di tempo, energie e risorse.
Questo processo naturale è caratteristico dei prodotti artigianali, in particolare degli oggetti che fanno parte delle tradizioni popolari. Quando si tratta di oggetti fatti a mano […] ogni oggetto nuovo può essere modificato leggermente rispetto al precedente, eliminando difetti, apportando piccole migliorie o sperimentando nuove idee. Nel corso del tempo questo processo dà luogo ad oggetti funzionali ed esteticamente gradevoli”.

L’idea dell’iterazione e del miglioramento continuo è insita nel processo stesso del design. E questa idea si applica sia ad oggetti fisici sia a prodotti digitali.

Riportando le considerazioni di un progettista scrive:

“Di solito ci vogliono cinque o sei tentativi prima di indovinare un prodotto. La cosa può essere accettabile in un prodotto già lanciato, ma pensa un po’ che cosa vuol dire in uno nuovo. Supponi che un’azienda voglia creare un prodotto che forse farà una grossa differenza. Il problema è che, se il prodotto è davvero rivoluzionario, è improbabile che ci sia qualcuno capace di progettarlo giusto la prima volta; ci vorranno diversi tentativi”

La storia non cambia: una buona soluzione di prodotto nasce indubbiamente dall’analisi delle funzionalità, del target di riferimento e del contesto d’uso ma tutto ciò può non essere sufficiente.

design_iterativo

E’ necessario che il prodotto – o il suo prototipo o una versione beta del prodotto stesso – venga messo alla prova dei fatti per verificare che tutte le assunzioni fatte nel corso della progettazione fossero corrette.
Il prodotto deve andare nelle mani degli utenti finali.

Solo in questo modo verificheremo il reale interesse da parte del pubblico (ndr.: ho detto da parte del pubblico, non dei nostri committenti!), potremo acquisire conoscenza supplementare rispetto al prodotto stesso (chi lo utilizza realmente, come è usato, come potrebbe evolvere, ecc.) e capire se quanto abbiamo progettato ha un modello di business sostenibile o se anche questo deve essere riconsiderato alla luce dei fatti.
E’ dal rilascio in avanti che il prodotto può iniziare ad evolvere e migliorare di iterazione in iterazione.

Built, measure, learn: è questo il ciclo di iterazione che porta a buone soluzioni di design e ai prodotti migliori.

Product backlog: mi piace perché… [parte 2]

Riprendiamo il discorso sui principali vantaggi derivanti dall’utilizzo del Product Backlog rispetto alla classica documentazione di progetto (documento di requisiti, documento di specifiche funzionali, ecc.).
Ho già illustrato in un post precedente quali sono i benefici in termini di visione globale del prodotto, lettura a diversi livelli di profondità e dettaglio dei requisiti, ordinamento degli stessi in base alle priorità di business e gestione dello scope.
Oggi vorrei approfondire quelle caratteristiche che a mio parere rendono il Product Backlog un oggetto estremamente duttile ed adattabile ai cambiamenti di scenario, di business e di frame tecnologico di riferimento.

Elaborazione progressiva
Uno dei vantaggi tangibili consiste nel fatto che il Product Backlog è in continua evoluzione prima, durante e dopo il rilascio del prodotto sul mercato.
In particolare una delle considerazioni su cui desidero soffermarmi è che il Product Backlog all’inizio di un progetto non ha necessità di essere pienamente esaustivo e definito al 100%. E’ possibile partire con l’implementazione tecnologica dei primi macro-requisiti e mettere a fuoco progressivamente le funzionalità del prodotto.
Se qualcosa non è stato definito in prima battuta può essere accolto strada facendo secondo un processo autocorrettivo.

Aggiornamento continuo
Se da una parte non ha la necessità di essere “blindato” e “scritto col sangue” all’inizio di un progetto, dall’altra non smette mai di evolvere.
 Un Product Backlog non è mai completo: definisce chiaramente solo ciò che è oggetto di implementazione nei cicli di sviluppo immediatamente successivi.
Allo stesso tempo al termine di ogni iterazione e sulla base dei feedback raccolti nel corso dello Sprint Review può arricchirsi mano a mano di nuovi elementi.
Questa permeabilità agli stimoli esterni fa sì che la direzione dello sviluppo di un prodotto possa essere rivista più volte dal cliente ancora prima del primo rilascio in produzione.

Frutto di un lavoro collaborativo
Il Backlog nasce da un lavoro di gruppo che nelle fasi iniziali di concept del prodotto comprende il Product Owner, lo Scrum Master e gli stakeholder.
 Successivamente, dal momento in cui viene istituito un team ed il Backlog diventa il riferimento primo del lavoro da realizzare, diviene un oggetto di rielaborazione, grooming e brainstorming collettivo.
Tutte le persone del gruppo diventano mano a mano più consapevoli delle finalità del prodotto e hanno la possibilità di portare sul tavolo i propri spunti e suggerimenti, così come di accogliere contributi di valore provenienti dall’esterno.
Il prodotto finale è il risultato dell’applicazione di un’intelligenza collettiva.

Segue l’intero ciclo di vita del prodotto
“Finché esiste un prodotto esiste anche il suo Product Backlog”, così recita la Scrum Guide di Schwaber e Sutherland.
A differenza di un documento di specifiche che decade con il rilascio online di un progetto (e a volte “muore” molto prima per mancato aggiornamento), il Backlog viene manutenuto durante l’intero ciclo di vita del prodotto.
Le esigenze di adattamento, modifica ed evoluzione che emergono una volta che il prodotto è immesso sul mercato sono registrate mano a mano come nuovi requisiti nel Product Backlog.
Non vengono redatti nuovi documenti, il riferimento rimane sempre il medesimo per tutti  gli attori in causa sino alla dismissione definitiva del prodotto.