Il problema nasce quando soddisfazione e risultato smettono di coincidere
In un progetto software il cliente valuta inevitabilmente anche la qualità della relazione con il fornitore. Vuole vedere progressi, ricevere risposte e sapere che le proprie richieste vengono prese sul serio. È normale, ed è uno dei motivi per cui una buona collaborazione conta così tanto.
Il rischio arriva quando la richiesta diventa la metrica principale. Una funzionalità può essere consegnata nei tempi, essere esattamente come era stata chiesta e produrre poco valore. Se il fornitore viene premiato soprattutto per la capacità di accontentare, il modo più semplice per mantenere alta la soddisfazione è dire sì più spesso di quanto il prodotto meriti.
È così che una squadra competente può trasformarsi in una feature factory senza che nessuno lo abbia deciso esplicitamente.
L'output è facile da vedere, l'outcome molto meno
Funzioni completate, ticket chiusi e schermate nuove sono visibili e facili da contare. Il risultato che il software dovrebbe produrre è più scomodo: richiede di osservare utenti, processi, dati e conseguenze reali.
Per questo una collaborazione può sembrare produttiva mentre sta accumulando cose che nessuno usa. L'antidoto è riportare continuamente la conversazione sul problema: quale comportamento deve cambiare, quale processo deve diventare più efficace, quale decisione dobbiamo poter prendere meglio, quale risultato stiamo cercando.
Le funzionalità tornano così a essere mezzi, non prove automatiche che il progetto stia andando bene.
La consulenza serve a rendere visibili i trade-off
Un cliente non deve diventare sviluppatore per governare un progetto software. Deve però avere abbastanza contesto per capire le alternative e le loro conseguenze.
Una consulenza utile rende espliciti i trade-off: cosa guadagniamo scegliendo questa strada, cosa stiamo rimandando, quale rischio stiamo assumendo, quali dati mancano e quali decisioni possono aspettare. Il fornitore porta esperienza tecnica e di prodotto, il cliente porta conoscenza del proprio business e dei processi. La decisione migliore nasce quando queste informazioni stanno nella stessa conversazione.
Il nostro obiettivo non è prendere il controllo al posto del cliente. È ridurre l'asimmetria informativa che rende alcune decisioni apparentemente tecniche e quindi facili da delegare senza comprenderne le conseguenze.
Cosa cambia nella pratica
Lavoriamo per arrivare presto a qualcosa di concreto quando il problema lo permette. Un prototipo, un flusso funzionante, una prima versione o un esperimento riducono la quantità di discussione basata su ipotesi.
Mettiamo in discussione richieste e priorità prima che diventino costose da cambiare. Quando una decisione è soprattutto di prodotto, guardiamo al comportamento degli utenti e al risultato. Quando è tecnica, rendiamo visibili costi, dipendenze e rischi. Quando serve una competenza che non abbiamo, il problema non si risolve fingendo di saperla.
L'AI ha aumentato la velocità con cui possiamo esplorare alternative e costruire prove. Questo rende ancora meno sensato difendere una specifica solo perché è già stata scritta.
Una buona consulenza dovrebbe rendersi meno necessaria
Se dopo mesi il cliente ha bisogno del fornitore per prendere esattamente le stesse decisioni che prendeva all'inizio, una parte del valore non è stata trasferita.
Una buona consulenza lascia criteri, contesto e capacità decisionale. In alcuni progetti questa autonomia può arrivare fino alla capacità di far evolvere direttamente parti semplici del software; in altri significa semplicemente sapere quali domande fare e riconoscere quando serve uno specialista.
La dipendenza dal fornitore dovrebbe rimanere dove conviene, non dove manca conoscenza per scegliere.
