Scotty: Il Maestro della Gestione delle Aspettative nel XXIII Secolo

Ultimamente ho passato una notevole quantità di tempo a bordo della USS Enterprise originale. Mentre è facile lasciarsi affascinare dal caotico carisma del Capitano Kirk o dalla fredda logica di Spock, la verità va detta. Il vero genio di quella nave non indossa oro o blu. Indossa il rosso e ha un discutibile accento scozzese.

Sto parlando di Montgomery “Scotty” Scott.

Molti guardano il Capo Ingegnere e vedono una spalla comica o un uomo che si diverte un po’ troppo a lamentarsi che “i motori non ce la fanno”. Si sbagliano. Scotty è l’unico adulto nella stanza. È il più grande praticante dell’arte perduta della Gestione delle Aspettative.

Il Miracoliere Calcolato

C’è una struttura classica in quasi ogni episodio. Ovunque vada l’Enterprise, succede qualcosa di terribile. Gli scudi cedono. Il motore a curvatura muore. I Klingon attaccano.

Kirk, con l’urgenza di qualcuno che ha una sceneggiatura da finire in 45 minuti, urla al comunicatore: “Scotty! Quanto tempo ci vuole per ripristinare la potenza di curvatura?”

Scotty, con la voce tremante di chi sta assistendo all’apocalisse, risponde: “Capitano! I cristalli sono fratturati. Mi servono almeno otto ore o diventeremo tutti polvere spaziale!”

Kirk, imperturbabile, ribatte: “Ne hai due.”

E cosa succede? Esattamente al minuto un’ora e cinquantanove, Scotty consegna il motore perfettamente funzionante. Kirk sorride e lo chiama un “miracoliere”.

Per un osservatore inesperto, Scotty sembra incompetente per aver sbagliato così tanto la stima o disonesto per aver gonfiato i numeri. Ma questa non è disonestà. Questa è Ingegneria Difensiva.

La Psicologia del Comando

Scotty comprende una verità fondamentale sul leadership e la gestione dei progetti che molti di noi ignorano. Il Comando (che sia il Capitano Kirk o il vostro Product Manager) non si cura della termodinamica. Non si cura della complessità del codice o del debito tecnico. Si cura del risultato.

Se Scotty dicesse l’onesta verità (“Capitano, questo richiede due ore se tutto va bene”), Kirk, essendo un manager aggressivo, pretenderebbe che fosse fatto in una. E quando qualcosa sarebbe inevitabilmente andato storto a metà del lavoro, la nave esploderebbe e la colpa ricadrebbe sull’ingegnere.

Dicendo “otto ore”, Scotty crea tre cose vitali:

1. Margine di Sicurezza: Se qualcosa si rompe (e succede sempre), ha sei ore di “grasso” per risolvere il problema senza che il Capitano vada in panico.
2. Controllo della Narrativa: Definisce la gravità della situazione. Ricorda al comando che le leggi della fisica non sono suggerimenti.
3. Valore Percepito: Quando consegna in due ore, non ha semplicemente fatto “il suo lavoro”. Ha compiuto un miracolo.

Questo è il concetto di “Prometti Poco e Supera le Aspettative” elevato al livello di arte. Scotty non protegge solo la sua reputazione. Protegge l’integrità del sistema dalle richieste assurde di persone che pensano che risolvere problemi complessi sia solo questione di “spingere di più”.

La Lezione per gli Sviluppatori Junior

Se state appena iniziando nel mondo dello sviluppo, ascoltate quello che dico.

C’è un impulso naturale a voler compiacere. Il vostro Tech Lead o il vostro PM verranno alla vostra scrivania e chiederanno: “Quanto tempo per implementare questa API di pagamento?” Guarderete, penserete allo scenario migliore possibile in cui il caffè è caldo e Stack Overflow (Ora l’AI) ha tutte le risposte, e direte: “Oh, posso farlo in due giorni.”

Avete appena firmato la vostra condanna a morte.

Nel momento in cui troverete un bug in una libreria di terze parti o il server di test andrà giù, sarete in ritardo. Farete notti in bianco. Spedirete codice sporco. E alla fine, nessuno vi ringrazierà per lo sforzo. Ricorderanno solo che siete stati in ritardo.

Fate quello che fa Scotty.

Se pensate che ci vogliano due giorni, dite quattro. Se il PM piange, negoziate a tre. Usate quel tempo extra per testare il vostro codice, per documentare, per gestire l’imprevisto.

Se finite in due giorni? Ottimo. Consegnate in anticipo. Sarete visti come efficienti e proattivi. Sarete il miracoliere che ha salvato lo Sprint.

Non si tratta di mentire. Si tratta di capire che lo sviluppo software, proprio come la manutenzione di un motore a curvatura con cristalli instabili, è un processo caotico. Il vostro lavoro non è solo scrivere codice. È gestire il caos in modo che il vostro Capitano non debba farlo.