Cinque definizioni di 'funziona'

"Funziona" è la frase più sovraccarica del software.

Dilla in una riunione di stato e cinque persone annuiranno, saranno d'accordo, e se ne andranno con cinque modelli mentali diversi di cosa sia appena successo. Nessuno sta mentendo. Stanno tutti rispondendo onestamente. Solo che stanno rispondendo a una domanda diversa da quella che pensi di aver fatto.

Gli executive misurano la prevedibilità

Quando un executive dice che funziona, intende che ora può impegnarsi sulla prossima milestone senza preoccuparsi in silenzio di un rewrite. La roadmap regge. Gli investitori sentono una storia coerente invece di una lista di avvertenze.

Non è una preoccupazione superficiale. La prevedibilità è la valuta che gli executive spendono per fare ogni altro impegno — piani di assunzione, narrative per il funding, promesse ai clienti. Un sistema che "funziona" ma di cui nessuno si fida della tempistica non gli dà davvero quello di cui hanno bisogno.

Il product misura l'adozione

Il product dice che funziona perché la metrica giusta si è mossa, i ticket di supporto su quel flusso si sono azzerati, e gli utenti completano il task senza chiedere come si fa. La loro definizione riguarda interamente ciò che succede fuori dal codebase.

Una feature può essere architettonicamente elegante e fallire completamente questo test — nessuno la usa, o la usa in un modo che genera ticket di supporto confusi. Dalla prospettiva del product, quello non è "funziona con qualche spigolo." È non funziona, punto.

L'engineering misura la modificabilità

L'engineering dice che funziona perché le astrazioni sono pulite, i failure mode sono isolati, e il prossimo developer non avrà bisogno di 45 minuti di onboarding solo per toccarlo.

Questa è la definizione di default per la maggior parte degli ingegneri, ed è la più invisibile a tutti gli altri. Nessuno fuori dal team nota se i failure mode sono isolati — finché, diciotto mesi dopo, una piccola modifica richiede tre settimane perché in realtà niente era isolato. Il "funziona" dell'engineering è una scommessa piazzata sul futuro, pagabile molto più tardi.

Il risk management misura la difendibilità

Il risk dice che funziona perché se un auditor chiedesse, ci sarebbe una risposta difendibile. La superficie di attacco è capita. Le decisioni — incluse quelle che scambiano sicurezza per velocità — sono scritte da qualche parte, con un motivo allegato.

Questa definizione raramente compare in una demo. Compare in una revisione post-incidente, o in un audit di compliance, o in un questionario di sicurezza di un cliente, momento in cui o c'è o decisamente non c'è.

Le operations misurano i sistemi silenziosi

Le ops dicono che funziona perché non ha squillato niente alle 3 del mattino. C'è un runbook. Quando qualcosa si rompe — e prima o poi qualcosa si rompe sempre — si rompe in modo prevedibile, con una risposta nota.

Le ops sono la definizione più correlata alle altre quattro e quella con meno probabilità di ricevere credito per questo. Un sistema che non squilla mai sembra, dall'esterno, esattamente come un sistema che non ha mai rischiato di squillare. Non sono la stessa cosa.

Nessuna di queste è sbagliata

La tensione non è che una di queste definizioni sia corretta e le altre siano rumore. Sono tutte corrette, misurate contro ciò di cui ogni funzione ha davvero bisogno dal sistema. La tensione è che ottimizzare a fondo per una qualsiasi di esse tende a creare debito in almeno un'altra.

Spedisci abbastanza in fretta da rispettare la soglia di prevedibilità dell'executive, e la definizione di modificabilità dell'engineering si erode in silenzio — le astrazioni vengono saltate perché non c'era tempo. Blocca la superficie di attacco abbastanza da soddisfare il risk, e i numeri di adozione del product possono soffrire se la frizione ricade sugli utenti. Costruisci la versione isolata, ben testata, modificabile che vuole l'engineering, e potrebbe uscire un trimestre dopo rispetto a quanto promesso dalla roadmap.

Nessuno di questi trade-off è un errore. Sono il vero contenuto del lavoro.

---

Spedire in fretta è facile. Spedire qualcosa con cui tutti e cinque possano convivere — quello è il lavoro che non si vede nella demo, ed è l'unica versione di "funziona" che regge davvero.