Idea principale

Di solito la complessità di un prodotto si legge nel suo codice — dimensione dei file, numero di strati, dipendenze. È la parte meno costosa. Una funzionalità rilasciata si paga poi presso l'utente che deve capire a che cosa serve, nei ticket di supporto che apre, nella documentazione da scrivere e mantenere, nella coerenza di un'esperienza che si confonde a ogni aggiunta, e nella capacità dell'organizzazione di spiegare quello che fabbrica.

Queste voci non accelerano. Quando il codice diventa l'anello veloce, i colli di bottiglia si spostano verso la revisione, la sicurezza, l'inquadramento delle esigenze funzionali, l'integrazione e l'assorbimento da parte delle persone — che diventano addirittura più critici di prima, perché ricevono di più.

Un prodotto diventa quindi illeggibile, per chi lo usa come per chi lo costruisce, appena si aggiungono funzionalità più in fretta di quanto si capisca come vengono usate. Produrre più codice non significa produrre più valore; significa spostare il conto verso reparti che non l'hanno messo in preventivo.

Perché è importante

Cambia quello che si conta quando si decide un'aggiunta. Il costo di sviluppo, ormai basso, smette di essere un indicatore del costo totale, e una stima che si ferma al codice sottovaluta sistematicamente ciò che una funzionalità comporta.

Dà anche al supporto e alla documentazione il ruolo di allarme anticipato: sono i primi posti in cui una complessità decisa altrove diventa misurabile.

Sfumature e limiti

Non tutta la complessità ricade sull'utente. Una funzionalità invisibile, attiva per impostazione predefinita e senza alcuna superficie d'uso, può appesantire parecchio il codice senza costare nulla in adozione o in supporto — il conto resta intero, ma dentro il team.

E il ragionamento ha un limite: un'organizzazione che rilasciasse solo ciò che il supporto assorbe senza sforzo rilascerebbe poco, e lascerebbe il campo libero a un concorrente. La questione è mettere in preventivo, non astenersi.

Domande aperte

• Come stimare, prima del rilascio, il carico di adozione e di supporto di una funzionalità, se non constatando a posteriori i ticket che genera?