L’illusione del controllo

State uccidendo inconsapevolmente il vostro prodotto. Cinque punti per convincervi a smettere.

Sviluppare un prodotto è un disastro. È una corsa ad ostacoli condotta nel fango contro ogni genere di avversità e imprevisti. Siamo tutti dei disperati in lotta contro le specifiche, i mockup del designer, i bug, i crash in produzione, il mercato, i concorrenti, idee che sembravano giuste ma sono sbagliate, idee che sembravano sbagliate ma erano giuste, e soprattutto contro il tempo.

Nonostante tutto questo, creare un prodotto è una delle attività più belle ed eccitanti. Si incontrano persone meravigliose e creative, sfide interessanti, si risolvono problemi veri che affliggono vite vere.

Vorremmo poterci concentrare solo sugli aspetti positivi, ma troppo spesso il processo di sviluppo va nella direzione sbagliata. Le feature tardano ad arrivare, il debito tecnico cresce, il progetto sembra vagare un po’ a vuoto e, la cosa peggiore, nessuno riesce a capire esattamente perché.
Certo, ognuno ha una proposta, un dito puntato in una direzione, ma è estremamente difficile mettere a fuoco esattamente cosa non sta funzionando ed elaborare conseguentemente una soluzione.
Se siete in questa situazione, probabilmente siete caduti nell’illusione del controllo e state uccidendo inconsapevolmente il vostro prodotto. Ma facciamo un passo indietro.

Fase uno: piegare lo spazio tempo

Per prima cosa chiariamo di cosa stiamo parlando. Lo sviluppo di un prodotto è un processo concreto e specifico. Non si sviluppano prodotti in astratto.
Abbiamo delle persone reali, in un’azienda reale, che lavorano con mezzi reali per costruire un prodotto reale, venduto ed usato da clienti reali. E il nostro obiettivo è far funzionare questo specifico processo. Il nostro processo. Nella nostra azienda, con i nostri mezzi di sviluppo, con i nostri clienti.

E il primo passo per avere successo in questo è riconoscere una banalità: indipendentemente dalle nostre buone intenzioni, dalle nostre teorie e congetture, se il processo che stiamo costruendo ha bisogno di violare le leggi dell’universo per funzionare, ebbene allora necessariamente fallirà.

Vi ho stupito? Probabilmente no. Probabilmente state ridacchiando, o sbuffando, con gli occhi rivolti al cielo.
È ovvio, ma allora come mai quasi ogni azienda fa affidamento sulla possibilità di poter fermare l’orologio, o moltiplicare le ore disponibili in un giorno, o tornare indietro nel tempo, o duplicare le persone, farle essere in più posti contemporaneamente, etc.?

Abbiamo tutti ben presente quella riunione che sembrava essere un pitch per un film di fantascienza.
Ma né le nostre priorità, né le nostre speranze, né l’esorbitante costo della posta in gioco possono cambiare le leggi della fisica. Se il successo del nostro processo di sviluppo e del nostro prodotto si affida a questo, allora entrambi sono destinati a fallire.

Ma in che universo viviamo dunque?

Fase due: fallimento e accettazione

Noi, come persone, come team, come aziende, siamo immersi in una rete inestricabile di eventi. Ognuno di essi è causa di qualcosa ed effetto di qualcos’altro, in un continuo flusso che ci travolge. Due elementi descrivono in modo fondamentale tutto questo: complessità ed imprevedibilità.

Tutto è infinitamente complesso e fondamentalmente imprevedibile. E sebbene la nostra società sia inflazionata da venditori di facili sicurezze usa e getta, in ogni ambito, questa rimane la dura verità.

So benissimo che passiamo la gran parte del tempo nello sforzo titanico di cercare di controllare la realtà intorno a noi ma non possiamo violare appunto la natura della realtà. Non si può controllare qualcosa che non si comprende appieno (perché infinitamente complesso) in un contesto dove non si può sapere in anticipo l’esito dei nostri tentativi (perché infinitamente imprevedibile). E quindi?

Dandoci un taglio con le chiacchiere, dobbiamo guardare le cose da un altro punto di vista. Invece di concentrare la nostra attenzione per inseguire l’illusione di controllare tutto, possiamo scegliere cosa sicuramente non vogliamo controllare, e fidarsi.

Fase tre: un cambio radicale di prospettiva

Possiamo vedere il controllo come una risorsa finibile che necessita di parsimonia. Va spesa in modo oculato. Non vogliamo sperperare il controllo per cose che non ne hanno bisogno.
Questa è la parte dolorosa da capire e assimilare.
Tanto più cerco di controllare un aspetto del nostro processo di sviluppo, tanto più inevitabilmente mi sfuggirà il controllo di altri aspetti. E se cerco di controllare tutto, tutto mi sfugge di mano.
Se cerco di controllare le scelte tecniche del mio team, e le scadenze, e la qualità del codice, e il numero di feature, etc. in realtà non sto controllando niente. Devo necessariamente fare dei compromessi.
Abbiamo solo due possibilità: o siamo noi consapevolmente a fare dei compromessi, o il caos sceglierà per noi.
In modo inaspettato e casuale perderemo il controllo di sezioni del nostro processo di sviluppo e non sapremo capire che sta succedendo.
Questo mese abbiamo affrontato problemi tecnici particolarmente complicati, a ridosso di una scadenza, e abbiamo perso il controllo della qualità. Il prossimo mese invece incontreremo delle imprecisioni nelle specifiche, casualmente emergeranno un paio di bug in produzione importanti, e avremo perso il controllo delle tempistiche. Il mese ancora dopo lo sviluppatore senior che conosceva bene alcune parti della tecnologia che avevamo scelto di usare magari si ammalerà, e avremo perso il controllo dello sviluppo.
Fatalità? Andrà meglio il prossimo mese? Forse. Il punto è che non lo sa nessuno, perché il controllo è solo apparente. È un’illusione.
Stiamo cercando di controllare tutto, e quindi non stiamo controllando niente. La variabilità degli eventi sta decidendo per noi quale parte del sistema viene a mancare.
Spesso non è un dramma se si sfora una scadenza; spesso non è un dramma se emerge un bug in produzione; spesso la vita continua. A volte invece era vitale, e un progetto muore.

Fase quattro: la soluzione agile

Un processo di sviluppo agile comincia con la perdita volontaria del controllo, tramite scelte consapevoli. Bene, facciamolo.

Lasciamo che il team di sviluppo si organizzi internamente da solo. Lasciamo che compia le sue scelte tecniche, in autonomia. Non vogliamo avere il controllo di questo. Abbiamo esercitato controllo nell’assumere quelle persone e nel creare quel team, non possiamo anche controllare cosa devono fare nel dettaglio tecnico. Ci dobbiamo fidare.

Scopriremo che se il team avrà l’autonomia e la responsabilità di scegliere i propri tool, i framework, i dettagli operativi, si orienterà su tecnologie che conosce bene, su cui sa di essere più produttivo. Sarà più motivato, più capace, più veloce. Sono loro gli esperti. Ci dobbiamo fidare.

Su cosa vogliamo tenere il controllo? Sulla direzione. Vogliamo che il prodotto si evolva acquisendo valore per il cliente finale. Questo è un punto fisso che non possiamo lasciare.

Ma cosa ha valore? Nuovamente, questo non può essere sotto il nostro controllo.
Lasciamo che il cliente finale, l’utente, ci dica cosa ha valore e cosa no. Lui è l’esperto di cosa vuole, e noi non possiamo controllarlo. Dobbiamo ascoltarlo. Ci dobbiamo fidare.

E vogliamo allentare il controllo sul tempo, quantità e qualità. Vogliamo invece negoziare con il team compromessi realistici di volta in volta. Se abbiamo la necessità di controllare la data di una scadenza, inevitabilmente perdiamo il controllo sulle altre variabili, come il contenuto di un rilascio, o la qualità del codice. Se invece è la qualità l’elemento essenziale, inevitabilmente perderemo il controllo sulle altre due. Il team ci dirà cosa è fattibile, quali compromessi sono possibili, e ci dobbiamo fidare.

Vogliamo tenere il controllo su quale compromesso scegliere, caso per caso, sprint per sprint, a seconda delle esigenze di business che emergono, e quindi vogliamo lasciare il controllo su quali compromessi sono realizzabili davvero. 

Come vedete, in ogni esempio, ogni volta che mettiamo un vincolo al processo (la composizione del team, le scadenze, le feature…) ci dobbiamo immediatamente interrogare su dove stiamo perdendo il controllo e assicurarci che questa perdita ci sia realmente.
Per usare un’analogia, se in un meccanismo in funzione mi trovo a dover inserire un blocco in un punto, le altre parti devono avere la libertà di movimento per continuare a funzionare. Se inserisco blocchi senza preoccuparmi che rimanga spazio di manovra, il meccanismo semplicemente si ferma.

Ed è vero esattamente il contrario. Se il meccanismo è fermo, la domanda più intelligente da porsi (e spesso la più utile) è: cosa stiamo controllando che non dovremmo controllare?

La fenomenologia di questo blocco, in un processo produttivo, si manifesta solitamente proprio con l’aumento dell’entropia generale, dai mille volti diversi che conosciamo bene: il rallentamento del lavoro, la fragilità del codice, le scadenze non rispettate, clienti che se ne vanno, etc.

Fase cinque: consapevolezza

Il punto più alto che possiamo raggiungere non è dunque il controllo assoluto e perfetto del nostro processo, ma è invece la consapevolezza.

La consapevolezza che non è possibile decidere tutto. La consapevolezza dei compromessi che devono essere fatti. La consapevolezza di come una richiesta in un punto del processo ha conseguenze che condizionano il movimento di ogni altra componente in gioco.

La consapevolezza di quali sono gli elementi che non sono controllabili a prescindere, indipendentemente dai nostri sforzi; quelli che invece sono parzialmente controllabili e i costi di questo controllo parziale; e le corrispettive libertà e autonomie che devo prevedere per mantenere il processo in movimento.

La consapevolezza che quando le cose non vanno è probabilmente perché le stiamo controllando troppo, e in modo sbagliato, e non perché non le stiamo controllando abbastanza.