Spreco 2: Funzionalità Extra
Costruire cose di cui nessuno ha bisogno—lo spreco più costoso di tutti.
1La Trappola della Sovrapproduzione
Nella produzione manifatturiera, la sovrapproduzione significa produrre più di quanto ordinato dai clienti. Nel software, significa costruire funzionalità che nessuno usa.
Gli studi mostrano costantemente che il 60-80% delle funzionalità viene usato raramente o mai. Pensateci. La maggior parte di ciò che i team software costruiscono non crea valore.
Questo è lo spreco più costoso perché ha costi composti:
- Costo di sviluppo: Tempo per costruire la funzionalità
- Costo di manutenzione: Ogni funzionalità aggiunge complessità per sempre
- Costo opportunità: Cos'altro avreste potuto costruire?
- Costo per l'utente: Più funzionalità significano prodotti più difficili da usare
Una funzionalità mai usata non è gratuita—vi costa ogni giorno in carico cognitivo, onere di test, documentazione e potenziali bug.
Il Costo di Mantenimento
Ogni funzionalità ha un costo di mantenimento. Richiede test. Potrebbe rompersi. Complica il codice. Confonde gli utenti. Le funzionalità inutilizzate hanno valore negativo—costano più di niente.
2Perché si Costruiscono Funzionalità Extra
I team costruiscono funzionalità non necessarie per molte ragioni:
"Già che ci siamo": Aggiungere ambito perché sembra efficiente raggruppare. Non lo è—ritarda il lavoro di valore e aggiunge spreco.
Requisiti immaginari: Costruire per utenti con cui non avete parlato. Le supposizioni si accumulano in spreco.
Doratura: Ingegneri che aggiungono sofisticazione tecnica che non serve agli utenti. Astrazioni che nessuno riutilizzerà. Ottimizzazione delle prestazioni per funzionalità che nessuno usa.
Funzionalità FOMO: "Il concorrente X ha questa funzionalità!" Forse nemmeno i loro utenti la usano.
Funzionalità politiche: Funzionalità costruite perché qualcuno di importante le ha richieste, non perché gli utenti ne abbiano bisogno.
Over-engineering: Costruire per una scala che non raggiungerete mai. Progettare per una flessibilità che non userete mai. "Ma se dovessimo supportare un milione di utenti?" Probabilmente non lo farete.
L'opposto delle funzionalità extra non è la povertà di funzionalità. È la concentrazione. Costruite esattamente ciò che serve, niente di più, e costruitelo bene.
Un team ha speso due mesi a costruire l'esportazione CSV/Excel/PDF per una funzionalità di reportistica. Le analitiche hanno mostrato che 3 utenti hanno mai usato l'esportazione. La funzionalità rimane nel codice, aggiungendo onere di test e costo di manutenzione per sempre.
Un team doveva supportare un fornitore di pagamenti. Hanno costruito esattamente quello—nessuna astrazione per più fornitori. Più tardi, quando hanno effettivamente avuto bisogno di un secondo fornitore, hanno fatto refactoring. Il costo totale è stato inferiore a quello che sarebbe stata un'astrazione anticipata.
3Prevenire le Funzionalità Extra
Validate prima di costruire: Parlate con gli utenti. Eseguite esperimenti. Usate prototipi. La funzionalità più economica è quella che non costruite.
YAGNI (You Ain't Gonna Need It): Non costruite per requisiti futuri immaginari. Costruite ciò di cui avete bisogno ora. Fate refactoring più tardi se i requisiti cambiano—e spesso non cambiano.
Minimum Viable Everything: Qual è la cosa più piccola che testerebbe questa ipotesi? Costruite quella. Imparate. Iterate.
Deprecazione basata sui dati: Misurate l'uso delle funzionalità. Eliminate le funzionalità che non vengono usate. Il coraggio di rimuovere è importante quanto la disciplina di non aggiungere.
Dite no più che sì: Il default per le nuove funzionalità dovrebbe essere "no". Le funzionalità devono giustificarsi. Dire no a una buona idea è spesso giusto perché dovreste lavorare invece su un'idea eccellente.
Budget di funzionalità: Per ogni nuova funzionalità, rimuovetene una vecchia. Questo forza la prioritizzazione e previene il gonfiamento.
I migliori team non sono orgogliosi di ciò che hanno costruito—sono orgogliosi di ciò che hanno scelto di non costruire.
Ogni funzionalità che non costruite è un risparmio infinito: nessuno sviluppo, nessun test, nessuna manutenzione, nessuna documentazione, nessun bug, nessuna confusione—per sempre.
- Il 60-80% delle funzionalità software viene usato raramente o mai
- Le funzionalità extra hanno costi composti che non si fermano mai
- Costruite per bisogni validati, non requisiti immaginari
- YAGNI: Non costruite per bisogni futuri che potrebbero non arrivare mai
- I migliori team sono orgogliosi di ciò che non hanno costruito
- •Raggruppare ambito extra perché siete "già nel codice"
- •Costruire astrazioni prima di avere più casi d'uso
- •Presumere che gli utenti vogliano funzionalità perché i concorrenti le hanno
- •Over-engineering per una scala che non raggiungerete mai