A volte cerchiamo una soluzione nel codice, nell’architettura o nel processo. Ma il blocco vero è altrove: una decisione che nessuno prende, un’informazione che non circola, una responsabilità che resta nel mezzo.
Ci sono problemi che sembrano tecnici.
Un rilascio che non parte.
Un’attività ferma.
Un requisito che continua a cambiare.
Un’anomalia che torna.
Una dipendenza che nessuno riesce a chiudere.
E allora facciamo quello che sappiamo fare meglio.
Analizziamo.
Apriamo ticket.
Coinvolgiamo persone.
Cerchiamo log.
Rivediamo flussi.
Facciamo call.
Poi, a un certo punto, qualcuno si accorge che il problema non era lì.
Non mancava una soluzione tecnica.
Mancava una decisione.
I problemi tecnici sono rassicuranti
In un certo senso i problemi tecnici sono comodi.
Hanno una forma.
Un comportamento atteso.
Un comportamento reale.
Possiamo osservare, testare, misurare.
Possiamo dire:
qui qualcosa non funziona come dovrebbe.
I problemi organizzativi sono più sfuggenti.
Non generano necessariamente un errore.
Non sempre hanno un owner.
Spesso non hanno nemmeno un nome.
Un progetto può rimanere fermo per giorni non perché manchi una soluzione, ma perché nessuno vuole prendersi la responsabilità di scegliere tra due alternative.
Da fuori sembra un problema tecnico ancora aperto.
In realtà il lavoro tecnico è già finito.
“Stiamo aspettando”
Una frase che nei progetti dovrebbe sempre far drizzare un po’ le antenne è:
“Stiamo aspettando.”
Aspettando cosa?
Una risposta?
Una decisione?
Un’approvazione?
Un dato?
Una persona?
Perché dietro “stiamo aspettando” possono nascondersi cose molto diverse.
A volte manca davvero un’informazione.
Altre volte l’informazione c’è, ma nessuno vuole trasformarla in una decisione.
E questo cambia completamente il modo in cui va affrontato il problema.
Se manca un dato, bisogna recuperarlo.
Se manca una decisione, continuare ad analizzare non serve.
Una riunione in più non risolve automaticamente niente
Quando qualcosa si blocca, la risposta organizzativa più comune è aggiungere una riunione.
Poi magari un’altra.
E infine una riunione per preparare la riunione.
Il problema è che una call può mettere persone nella stessa stanza virtuale.
Non può costringerle a decidere.
Puoi uscire da sessanta minuti di discussione con più informazioni di prima e con esattamente lo stesso blocco.
Perché il punto non era comprendere meglio il problema.
Era assumersi la responsabilità di scegliere.
In questi casi la domanda utile non è:
Cosa ne pensiamo?
Ma:
Chi decide?
E subito dopo:
Di cosa ha bisogno per decidere?
A volte il requisito non è ambiguo. È conteso.
Ci sono requisiti che sembrano poco chiari perché continuano a cambiare.
Ogni volta che ne parli emerge una versione leggermente diversa.
Il primo istinto è pensare che serva un’analisi migliore.
Non sempre.
A volte il requisito è perfettamente chiaro.
Il problema è che due persone vogliono due cose diverse.
Finché questa divergenza non viene resa esplicita, il team tecnico riceverà continue correzioni.
E ogni correzione sembrerà un nuovo dettaglio emerso durante l’analisi.
In realtà stiamo assistendo a una negoziazione che nessuno ha ancora chiamato con il suo nome.
Il tecnico, in quel momento, rischia di diventare il luogo nel quale un conflitto organizzativo viene scaricato sotto forma di modifiche.
Anche le responsabilità possono finire “tra due sedie”
Ci sono attività che non sono realmente assegnate a nessuno.
Formalmente magari sì.
Praticamente no.
Un team pensa che debba farlo l’altro.
L’altro è convinto che sia responsabilità del primo.
Nel frattempo l’attività rimane ferma.
Qui non serve una soluzione più intelligente.
Serve rendere esplicito chi fa cosa.
Sembra banale.
Ma molti problemi complessi sopravvivono a lungo proprio perché nessuno vuole porre una domanda apparentemente semplice:
“Chi se ne occupa?”
La tecnologia diventa facilmente un alibi
C’è anche un fenomeno più sottile.
Dire che un problema è tecnico può essere rassicurante.
Perché sposta la discussione su qualcosa di impersonale.
“Il sistema non lo permette.”
“L’architettura è complessa.”
“Serve un’analisi.”
Può essere tutto vero.
Ma qualche volta dietro quelle frasi c’è anche altro.
Una priorità che non vogliamo dichiarare.
Una decisione scomoda.
Un compromesso che nessuno vuole assumersi.
Un vincolo organizzativo trasformato in vincolo tecnico.
Non significa che qualcuno stia mentendo.
Molto spesso succede senza che ce ne accorgiamo.
La tecnologia finisce semplicemente per assorbire problemi nati altrove.
Capire la natura del problema cambia il lavoro
Se un problema è tecnico, servono competenze tecniche.
Se è organizzativo, servono decisioni.
Se è informativo, serve contesto.
Se è relazionale, serve una conversazione.
Se è di responsabilità, serve un owner.
Sembra una classificazione ovvia.
Eppure passiamo moltissimo tempo applicando lo strumento giusto al problema sbagliato.
Un’altra analisi.
Un altro documento.
Un’altra call.
Un’altra escalation.
Quando magari sarebbe bastata una domanda.
Non tutto deve diventare un’escalation
Riconoscere che il problema non è tecnico non significa immediatamente “portarlo sopra”.
L’escalation è uno strumento.
Non una strategia universale.
Molte situazioni possono essere risolte semplicemente facendo emergere ciò che fino a quel momento era implicito.
Abbiamo due alternative tecnicamente valide. Chi sceglie?
Oppure:
Il team può procedere, ma serve conferma su questa priorità.
O ancora:
Non manca un’analisi: manca l’accordo tra queste due esigenze.
A volte formulare il problema correttamente è già metà della soluzione.
Il lavoro più utile può essere fermarsi
C’è una tentazione molto forte nei progetti:
fare qualcosa.
Produrre.
Analizzare.
Scrivere.
Correggere.
Muovere il problema.
Ma non sempre muoversi significa avanzare.
A volte la cosa più utile che possiamo fare è fermarci e chiederci:
stiamo davvero risolvendo il problema giusto?
Perché possiamo essere efficientissimi nel produrre una soluzione tecnica.
E scoprire alla fine che il blocco vero non aveva mai avuto nulla a che fare con la tecnologia.
Una domanda prima della soluzione
Più lavoro su progetti complessi, più trovo utile una domanda molto semplice:
Che tipo di problema è questo?
Non:
“Come lo risolviamo?”
Prima:
“Che cosa stiamo davvero cercando di risolvere?”
Perché una soluzione tecnica può essere eccellente.
Ma non può prendere una decisione al posto di qualcuno.
Non può chiarire automaticamente una responsabilità.
Non può riconciliare due priorità incompatibili.
Non può sostituire una conversazione che nessuno vuole avere.
E forse una parte importante dell’esperienza consiste proprio nell’accorgersi quando è il momento di smettere di cercare la risposta dentro il sistema.
E iniziare a cercarla fuori.