Quello che un brief non dice

Dopo più di vent’anni passati a lavorare su progetti digitali, quando mi arriva un brief ben fatto la prima cosa che cerco non è quello che c’è scritto.

Cerco quello che manca.

Può sembrare paradossale, perché un brief nasce esattamente per spiegare cosa bisogna fare. Ci sono le pagine del sito, le funzionalità, le integrazioni, i mercati, le lingue, magari anche tecnologia, tempi e budget. Nei capitolati più strutturati ci sono decine di pagine e tabelle che arrivano quasi al livello della specifica tecnica.

Eppure, terminata la lettura, molto spesso manca ancora l’informazione che mi interessa di più:

perché stiamo facendo questo progetto?

Non intendo la frase istituzionale che normalmente compare nelle prime righe, qualcosa tipo “rinnovare la presenza digitale dell’azienda” o “migliorare l’esperienza utente”.

Intendo cosa deve succedere, nella realtà, perché tra un anno qualcuno possa dire: questa cosa è servita.

Sono due domande parecchio diverse.

Il brief arriva quasi sempre dopo che qualcuno ha già scelto la soluzione

“Dobbiamo rifare il sito.”

È probabilmente una delle frasi che ho sentito più spesso nel mio lavoro.

Benissimo.

Perché?

Il sito è vecchio e non rappresenta più l’azienda. I commerciali fanno fatica a usarlo durante le presentazioni. Non genera contatti. È ingestibile internamente. È lento. Non viene indicizzato bene. È stato costruito da un fornitore con cui non si riesce più a lavorare. L’azienda si sta internazionalizzando. È cambiato il posizionamento. Il CEO lo guarda e lo odia.

Oppure, molto più banalmente, il concorrente ha appena rifatto il suo.

Sono tutti motivi plausibili per arrivare alla frase “dobbiamo rifare il sito”, ma producono progetti profondamente diversi.

La cosa curiosa è che il brief tende a partire dalla fine di questo ragionamento.

Qualcuno, all’interno dell’azienda, ha osservato un problema, ne ha discusso con altre persone, ha immaginato una soluzione e alla fine ha scritto: “nuovo sito web”.

A noi arriva l’ultima riga.

Il resto è rimasto nelle riunioni precedenti.

È comprensibile. Chi scrive il documento vive dentro quell’azienda tutti i giorni. Conosce prodotti, persone, equilibri, problemi storici, discussioni interne. Alcune cose gli sembrano talmente evidenti che non avrebbe nemmeno senso scriverle.

Per chi arriva da fuori, invece, sono esattamente le informazioni che permettono di capire il progetto.

Un sito progettato principalmente per generare lead sarà diverso da quello di un’azienda che deve convincere grandi clienti internazionali di avere struttura e competenze adeguate. Un e-commerce che deve aumentare la conversione pone problemi diversi da uno che deve ridurre le telefonate al customer care.

Magari alla fine useremo WordPress in entrambi.

Ma WordPress, in questa fase, è probabilmente la cosa meno interessante di cui discutere.

Clayton Christensen ha costruito buona parte del concetto dei Jobs to Be Done proprio attorno a questa distinzione: capire quale “lavoro” una persona sta realmente cercando di far svolgere a un prodotto permette di guardare oltre la soluzione dichiarata.¹

Nel nostro mestiere succede qualcosa di molto simile.

Il brief descrive ciò che il cliente pensa di voler costruire. Io devo capire quale problema sta cercando di risolvere.

Poi ci sono le cose che nel brief non possono proprio esserci

Questa è la parte che gli anni di esperienza insegnano forse più di qualsiasi metodologia.

Ogni progetto ha una seconda specifica, invisibile.

Dentro ci sono il gestionale del 2007 che “però quello non possiamo assolutamente toccarlo”, l’IT che dovrà approvare l’architettura ma che nessuno ha ancora coinvolto, il reparto legale che arriverà inevitabilmente verso la fine, la campagna media già acquistata che improvvisamente trasforma una data indicativa in una scadenza inderogabile.

E poi ci sono le persone.

Quella è una variabile che nei diagrammi di Gantt compare raramente.

Chi decide davvero?

Chi deve approvare?

Chi può bloccare tutto?

Chi ha voluto il progetto?

Chi invece lo considera una perdita di tempo?

Sono domande molto meno tecniche dell’elenco delle API da integrare, e spesso hanno un impatto molto maggiore sul risultato finale.

Mi è capitato parecchie volte di iniziare un progetto apparentemente semplice e scoprire qualche settimana dopo che esisteva un vincolo che nessuno aveva pensato di mettere sul tavolo.

Non necessariamente perché qualcuno lo avesse nascosto.

Per lui era semplicemente ovvio.

“Ah sì, naturalmente questa parte deve rimanere così.”

Naturalmente.

Solo che noi non lo sapevamo.

Ed è esattamente per questo che, quando qualcosa non torna, preferisco fare una domanda in più all’inizio piuttosto che trovare una risposta molto costosa tre mesi dopo.

La parola più pericolosa è probabilmente “bello”

Poi ci sono le aspettative, che sono ancora più difficili da mettere nero su bianco.

“Vogliamo un sito moderno.”

“Deve essere molto dinamico.”

“Cerchiamo qualcosa di innovativo.”

“Deve avere impatto.”

Ho imparato a diffidare abbastanza di questi aggettivi.

Non perché siano sbagliati, ma perché ognuno attribuisce loro un significato diverso.

“Dinamico” per una persona significa grandi animazioni e transizioni. Per un’altra significa contenuti aggiornati frequentemente. Per un’altra ancora semplicemente che il sito attuale sembra fermo al 2012 e qualunque cosa nuova apparirà dinamica.

E “bello” è ancora peggio.

Il problema arriva quando nessuno ha definito cosa significa aver fatto un buon lavoro.

Possiamo consegnare un progetto tecnicamente corretto, nei tempi, perfettamente aderente al brief e scoprire comunque che il cliente è insoddisfatto.

Non perché abbiamo costruito la cosa sbagliata.

Perché ciascuno stava misurando una cosa diversa.

Il Project Management Institute, in un rapporto dedicato alla gestione dei requisiti, rilevava già anni fa come una raccolta e una gestione inadeguata dei requisiti fossero tra le cause importanti del fallimento dei progetti.²

Ma anche la parola “requisito”, secondo me, rischia di portarci troppo velocemente sul piano tecnico.

Prima ancora dei requisiti serve capire le aspettative.

Se tra sei mesi il progetto avrà funzionato, cosa sarà cambiato?

Ci saranno più richieste commerciali?

I clienti troveranno autonomamente informazioni che prima chiedevano al customer care?

Il marketing riuscirà finalmente a pubblicare senza passare ogni volta dallo sviluppatore?

Un potenziale cliente internazionale, arrivando sul sito, percepirà l’azienda per le sue dimensioni reali anziché come una piccola realtà locale?

Sono risultati completamente diversi.

E possono convivere nello stesso brief che chiede semplicemente “il rifacimento del sito corporate”.

Per questo le prime riunioni mi interessano moltissimo

Negli anni mi sono accorto che alcune delle domande che fanno emergere più informazioni sono quasi imbarazzanti per quanto sono semplici.

Perché volete farlo?

Perché proprio adesso?

Cosa dovrebbe cambiare rispetto a oggi?

Come capiremo che ha funzionato?

Chi dovrà approvarlo?

Cosa avete già provato?

Perché non ha funzionato?

E una che trovo particolarmente utile: cosa succede se non facciamo nulla?

Quest’ultima ogni tanto produce qualche secondo di silenzio.

Ed è un silenzio interessante.

Perché può emergere che il progetto risponde a un problema urgente. Oppure che risponde a un’esigenza reale ma non urgente. O ancora che nessuno sa esattamente perché lo stia facendo, se non perché a un certo punto qualcuno ha stabilito che era arrivato il momento.

Sono informazioni molto diverse quando bisogna decidere dove mettere budget, tempo e complessità.

Naturalmente esiste anche un modo insopportabile di fare questo lavoro: trasformare la riunione in una specie di interrogatorio nel quale il consulente cerca di dimostrare al cliente che non ha capito il proprio problema.

Non serve.

Chi sta dall’altra parte conosce la propria azienda infinitamente meglio di noi.

Noi possiamo portare una cosa diversa: la possibilità di guardarla da fuori.

Ed essere esterni, ogni tanto, è un vantaggio enorme. Possiamo fare domande che internamente nessuno fa più perché certe premesse sono diventate parte dell’arredamento.

Mi piacciono molto i momenti in cui, durante una riunione, qualcuno si ferma e dice:

“Effettivamente questa cosa non ce la siamo mai chiesta.”

Lì normalmente abbiamo trovato qualcosa di utile.

Il brief, alla fine, è materiale di partenza

Questo è probabilmente il modo in cui è cambiato di più il mio rapporto con i brief negli anni.

All’inizio tendevo a considerarli una specifica da comprendere bene per formulare la risposta corretta.

Oggi li considero soprattutto la prima rappresentazione che il cliente è riuscito a dare del problema.

Può essere estremamente accurata.

Può essere incompleta.

Può anche contenere già una soluzione molto buona.

Ma rimane il punto da cui comincia il lavoro, non quello in cui termina il ragionamento.

E infatti alcuni dei progetti migliori ai quali ho lavorato sono cambiati parecchio tra il brief iniziale e ciò che abbiamo effettivamente realizzato. Non perché qualcuno avesse sbagliato il documento, ma perché discutendone avevamo capito meglio il problema.

A volte abbiamo tolto cose.

Altre ne abbiamo aggiunte.

Qualche volta abbiamo scoperto che una funzionalità apparentemente fondamentale interessava pochissimo agli utenti, mentre un dettaglio liquidato in due righe nel brief era in realtà centrale.

È anche il motivo per cui, quando ricevo una richiesta particolarmente dettagliata, cerco di non farmi ingannare dalla sensazione rassicurante che sia già tutto deciso.

Più un documento è preciso, più viene spontaneo iniziare immediatamente a stimare tempi, giornate uomo, tecnologie e costi.

Io preferisco aspettare un attimo.

Leggerlo.

E poi cercare ciò che qualcuno, comprensibilmente, non ha scritto.