C’è un momento, in ogni progetto, in cui smetti di analizzare per capire e inizi ad analizzare per esistere.
All’inizio è tutto sano. C’è un obiettivo, c’è una deadline, c’è un problema concreto da risolvere. Si fanno domande intelligenti: chi lo usa? perché? cosa succede se fallisce? quali sono i vincoli? L’analisi è una torcia, illumina il sentiero e ti evita di finire in un burrone architetturale scavato con le tue stesse mani.
Poi, quasi impercettibilmente, succede qualcosa.
Qualcuno dice: “Sì, però in generale…”
E da lì si apre il portale.
Benvenuto nella metafisica della lana caprina.
Quando il dettaglio diventa religione
La lana caprina è quel punto oltre il quale il dettaglio smette di ridurre il rischio e inizia ad aumentarlo. Non stai più chiarendo, stai raffinando il marginale. Non stai più decidendo, stai sospendendo la decisione in attesa di una purezza concettuale che non arriverà mai.
La riunione parte con:
“Dobbiamo definire il flusso di registrazione.”
Dopo un’ora sei qui:
“Ma ontologicamente, cos’è un utente?”
Il PM vuole allineamento strategico.
Il developer vuole coerenza architetturale.
Il cliente, come al solito, non ha ancora capito bene cosa vuole ma gli serve per ieri.
Tutti, senza accorgersene, stanno scavando.
Si inizia con il naming (userId o user_id?), si passa alla tassonomia dei ruoli, poi alla modellazione perfetta del dominio, poi agli edge case improbabili (“E se un utente si registra mentre Mercurio è retrogrado?”). Nel frattempo il competitor ha già lanciato una feature imperfetta ma funzionante.
La differenza? Loro hanno scelto. Noi abbiamo capito tutto.
O quasi.
Il falso controllo
La metafisica della lana caprina prospera in ambienti intelligenti. Non nasce dall’incompetenza, ma dall’eccesso di zelo. Più le persone sono preparate, più sono capaci di generare complessità. Ogni domanda produce quattro sotto-domande. Ogni risposta apre una dipendenza logica. Ogni dipendenza richiede un documento.
Il PM dice: “Dobbiamo mappare tutti i casi.”
Il dev risponde: “Allora dobbiamo generalizzare il modello.”
Il PM rilancia: “Se generalizziamo, dobbiamo prevedere la scalabilità futura.”
Il dev piazza l’all-in: “Allora forse serve un layer di astrazione.”
Tre sprint dopo, non esiste ancora nulla che un utente possa toccare, ma la documentazione è pronta per essere tramandata ai posteri.
La cosa affascinante è che ci si sente produttivi. Le board sono piene, i diagrammi eleganti, i concetti coerenti. È un’illusione di controllo: se abbiamo discusso tutto, allora siamo al sicuro.
Spoiler: no.
Stiamo solo spostando il rischio dal codice alla decisione. E l’indecisione è il rischio più costoso di tutti.
Il punto di non ritorno
Ci sono segnali inequivocabili che indicano che sei entrato nel vortice:
Le frasi iniziano con “in generale”, “a regime”, “idealmente”, “in assoluto”.
Le decisioni diventano “apriamo un thread”.
I thread diventano “serve un documento”.
Il documento diventa “facciamo un workshop”.
La domanda non è più “cosa serve per andare live?” ma “qual è il modello corretto per qualsiasi possibile futuro dell’azienda nei prossimi dieci anni?”.
È qui che la lana caprina si manifesta in tutta la sua potenza metafisica: la realtà concreta (tempo, budget, utenti) viene sospesa in favore di una perfezione teorica che non sarà mai implementata esattamente così com’è stata immaginata.
Perché la verità è brutale: il software reale sporca sempre i modelli perfetti.
Perché lo facciamo
Perché decidere è violento.
Decidere significa tagliare possibilità. Significa accettare che una soluzione “abbastanza buona” oggi valga più di una soluzione “perfetta” domani. Significa assumersi la responsabilità di un trade-off.
È molto più rassicurante discutere ancora un po’. Analizzare un altro scenario. Modellare un’altra variante.
Il PM evita il rischio politico di una scelta.
Il developer evita il rischio tecnico di un compromesso.
Entrambi evitano l’unica cosa che fa davvero avanzare il progetto: chiudere.
Una modesta via d’uscita
Io, quando sento l’odore della lana caprina nell’aria, non apro un altro documento. Affilo il machete.
Quando la discussione inizia a piegarsi su sé stessa, quando il dettaglio diventa fine a sé stesso e le frasi iniziano con “sì ma non potremmo anche…”, taglio corto. Riporto tutti – cliente, PM, developer, eventuale filosofo del dominio – a una domanda brutalmente semplice:
Qual era il problema da risolvere?
Non quello ideale. Nemmeno la risposta alla domanda fondamentale sulla vita, l’universo e tutto quanto. Quello iniziale. Lo use-case concreto da cui siamo partiti, quello con una persona vera che deve fare una cosa reale entro un tempo finito.
La lana caprina prospera nell’astrazione. Il machete vive nella concretezza.
“Dobbiamo coprire tutti i casi.”
No. Intanto copriamo quello principale.
“E se poi in futuro…”
In futuro, se servirà, lo affronteremo con dati reali, non con scenari partoriti da una call di due ore.
Io prediligo un approccio semplice e quasi noioso nella sua brutalità: iterativo, incrementale, pragmatico.
Prima rendiamo solido lo scenario principale. Quello che genera valore vero. Poi sistemiamo i casi secondari, quelli frequenti ma non vitali.
E solo dopo, con calma, ci occupiamo dell’utente daltonico, mancino, che deve usare quella specifica feature dal BlackBerry mentre è in ritiro spirituale in una notte di luna piena.
Non perché non sia importante. Ma perché non è la prima cosa che impedisce al progetto di esistere.
L’agilità, quella vera, non è fare stand-up e usare Jira. È accettare che la perfezione sia un processo, non una precondizione.
Il machete serve a questo: separare ciò che è necessario per partire da ciò che è rassicurante discutere.
Chiudere è un atto tecnico
C’è un momento in cui qualcuno deve dire: basta, questa decisione è “sufficientemente buona”. Non perfetta. Non eterna. Buona.
Chi sviluppa lo sa: quasi tutto è refactorabile. Quasi tutto è versionabile. Quasi tutto è migliorabile. Ma niente è migliorabile se non esiste.
La metafisica della lana caprina ti convince che pensare ancora un po’ ridurrà il rischio. In realtà lo sta solo spostando in avanti, accumulando tempo morto e ansia organizzativa.
Il machete non è superficialità. È gerarchia.
È ricordarsi che un software imperfetto ma usato insegna più di un’architettura sublime ma teorica.
E forse la vera maturità, in un progetto, non è saper scendere sempre più in profondità.
È sapere quando smettere di scavare.
