Nessun piano sopravvive al primo sprint (e va bene così)
Perché alla fine la roadmap serve a dare un punto da cui partire, sapendo già che da lì devierai
[Video Youtube] I rischi del vibe coding per chi sviluppa
In questo video ti racconto quali sono i rischi del vibe coding per chi sviluppa prodotti digitali oggi.
👋 Ciao, sono Chri. Fractional CTO e questa è Senza Filtri: la newsletter dove condivido il dietro le quinte del mio viaggio da imprenditore (esperienze, cosa ho imparato e tanti errori) alternando a qualche deep dive sui business che mi incuriosiscono.
Ogni progetto inizia con un piano, con una bella roadmap, con le sue belle colonne e con le scadenze, messe lì come se qualcuno sapesse davvero ciò che dovrà accadere (o magari come se avesse la sfera di cristallo).
E noi tecnici quella roadmap la trattiamo come un’entità superiore, una cosa decisa da qualcuno che non è lì con noi, ma sta in un’altra stanza, e che arriva giù, tra noi, per chiederci cieca obbedienza.
”Questo va consegnato entro il 30”, dice, e tu sei lì a fare i salti mortali per far tornare i conti.
Peccato che 9 volte su 10 i conti non tornano. Trovi la scadenza che non sta in piedi, un effort stimato alla bene e meglio da chi non scriverà una riga e una dipendenza che nessuno aveva visto. E quando salta, salta sempre dalla stessa parte: la nostra.
Per anni l’ho vissuta come un mio problema, pensando “sarò io che stimo di merda” (autostima alle stelle, come vedi), ma ho capito che il problema non era la stima, ma il momento in cui la roadmap veniva decisa e, soprattutto, chi c’era in quella stanza.
La roadmap calata dall’alto
Lo schema lo conosci: la roadmap la decide il business e successivamente viene calata sul team di prodotto, che a quel punto deve fare le magie per rispettarla. E chi sviluppa davvero, ovvero gli individual contributor, vengono coinvolti solo nella fase di discussione. Mai nella decisione.
Nella discussione ti chiedono “ce la fai per il 30?”. Hai già la data davanti, hai già la feature definita, hai già tutto definito. Puoi dire soltanto “sì”, oppure essere quello che frena il progetto. Nella decisione, invece, sei nella stanza di prima. Quando si decide cosa fare, perché, e in che ordine. Quando le scadenze sono ancora ipotesi e non promesse già fatte a un cliente.
Quasi sempre l’IC entra a giochi fatti. E gli si chiede pure di essere motivato.
Perché non funziona
Il motivo per cui questo schema fa acqua non è uno solo, sono tanti e sono tutti collegati.
Il primo è il più ovvio e il più ignorato: chi esegue ha informazioni che chi decide non ha. Il business stima a vista, il tecnico sa dove sono i campi minati (o i merdoni). Sa che quella cosa che “sembra mezza giornata” tocca un pezzo di codice che nessuno osa guardare da due anni. Sa quali sono le dipendenze vere. Decidere senza quelle informazioni vuol dire decidere alla cieca, e poi stupirsi che il muro arrivi.
Poi c’è una cosa che ho imparato a mie spese: i problemi è meglio scoprirli sempre prima. In fase di decisione un nodo costa una conversazione di mezz’ora. In fase di esecuzione costa uno sprint bruciato e una telefonata al cliente per dirgli che no, per il 30 non si fa. Più aspetti a tirare fuori il problema, più ti costa.
C’è il discorso dei trade-off, che secondo me è quello che pesa di più. Il trade-off vero lo può fare solo chi conosce il costo. “Questa feature intera sono tre settimane, ma una versione all’80% sono tre giorni.” Questa frase il business da solo non la può dire, perché non sa quanto costano le cose. E quasi sempre, indovina un po’, l’80% bastava. Solo che se nessuno te lo dice, parti per fare il 100% e ci sbatti la testa.
E poi c’è la parte umana, che è quella che cambia tutto a lungo termine. Un piano deciso con te lo difendi, mentre uno imposto dall’alto lo subisci. È la differenza tra un team che si fa in quattro per far funzionare le cose e un team che aspetta in silenzio il momento di poter dire “io l’avevo detto”. L’ho visto succedere, ed è una delle cose più tristi da vedere in un’azienda.
L’ultima la dico veloce perché è quella che esplode più tardi di tutte: le promesse irrealistiche non fanno male nel momento in cui le fai. Fanno male dopo, quando il cliente o il mercato presentano il conto. Coinvolgere chi esegue è il modo più economico che esista per non promettere cose impossibili. Costa una riunione adesso invece di un rapporto incrinato fra tre mesi.
Severo ma giusto, direbbe qualcuno.
Come provo a sistemarla
Allora, cosa faccio io quando entro in un’azienda da fractional e mi trovo davanti questa dinamica?
Innanzitutto, prima ancora di toccare processi e tool, cambio come vengono visti gli IC. Non più esecutori, ma pensatori, persone coinvolte nel prodotto e non solo braccia a cui dare il task. Sembra una banalità detta così, ma cambia tutto: se uno è un esecutore lo chiami quando il piano è pronto, se è un pensatore lo chiami mentre il piano si fa.
Questo vuol dire portarli nella stanza quando si pianifica. E qui arriva la parte difficile, perché un IC ragiona in modo diverso da un uomo di business. Parla un’altra lingua, ha altre priorità, guarda altri rischi. Il lavoro vero è trovare il modo di far parlare questi due mondi, e portare oggettività dove si può. (Su questa cosa del tradurre tra tech e business ci ho scritto una newsletter intera, come comunico ai non techy guys del management, perché è metà del mestiere.)
E ti dico una cosa controintuitiva: questa fatica non aiuta solo il team, aiuta anche il business. Perché un business che ha coinvolto il team ha argomenti veri per motivare le scelte, non solo agli stakeholder, ma alle persone che quelle scelte le devono fare. L’appartenenza al prodotto non te la regala nessuno, te la costruisci coinvolgendo.
Dove voglio arrivare quindi? Semplice, la mentalità di prodotto.
Ogni team funzionale che è owner end-to-end di un pezzo. Non “tu scrivi il codice di questa cosa”, ma “questa cosa è tua, dall’idea a quando gira in produzione”. Su team piccoli funziona benissimo, e io lavoro quasi sempre con startup dove il team di prodotto è massimo una decina di persone. Su strutture grandi è un altro discorso, lì entrano in gioco un botto di dinamiche che qui non sto a raccontare.
Lo so cosa stai pensando: “ma tutta questa roba porta via tempo allo sviluppo vero” ed hai ragione. E va detto chiaro, non ha senso nasconderlo. Solo che è un investimento, non un costo. Se ho chiaro tutto, ci metto meno. Se parto confuso, ci metto il triplo e rifaccio le cose due volte. Il tempo che “perdi” a pianificare insieme lo riguadagni in esecuzione con gli interessi. Non esiste nessuna formula universale, ogni team ha i suoi processi, metodi ed equilibri. Non sto vendendo un framework, ma voglio farti capire che si può fare e che dove l’ho fatto ha funzionato.
E adesso c’è pure l’AI
C’è un pezzo nuovo in tutta questa storia, ed è quello che mi ha fatto venire voglia di scriverne adesso e non un anno fa.
L’AI sta diventando sempre di più l’esecutore della visione.
Prima il contesto passava da persona a persona. La memoria del prodotto era umana, implicita, viveva nelle teste e nelle chiacchiere davanti alla macchinetta del caffè. Funzionava male, ma funzionava: alla peggio andavi a chiedere al collega “perché questa cosa è fatta così?”.
All’AI non puoi chiederlo davanti alla macchinetta. Per farla lavorare bene devi darle il contesto, e l’unico modo per darle il contesto è scriverlo. Tutto. Nero su bianco.
Il che significa che pianificare non è più mettere date su una roadmap. È costruire e mantenere una libreria di contesto prodotto scritta. Una cosa che serve agli umani per capire dove stanno andando, e che ora serve anche alla macchina per eseguire senza combinare disastri.
E sai qual è il bello? Che la roadmap calata dall’alto, quella decisa in una stanza senza chi esegue, salta proprio qui. Perché non ha contesto scritto, non ha visione condivisa, ha solo date. E se metti un’AI a eseguire una visione che il team non ha costruito e che non è scritta da nessuna parte, non ottieni velocità. Ottieni caos e più velocemente.
Improvvisamente saper scrivere il contesto, mantenerlo, tenerlo vivo, è diventata una competenza di prodotto. Non un di più.
Quindi
Eisenhower aveva ragione. Il piano in sé vale poco, salterà comunque al primo contatto con la realtà. Quello che vale è l’atto di pianificare insieme, con le persone giuste nella stanza al momento giusto, prima che le date diventino promesse.
Perché alla fine la roadmap serve a darti un punto da cui partire, sapendo già che da lì devierai. Per deviare nel modo giusto, devi aver già capito dall’inizio dove stai andando, ed ecco perché chi lo fa deve stare nella stanza delle decisioni, e non solo in quella delle esecuzioni.
Senza filtri,
Chri
P.S. Costruiamo insieme Senza Filtri
Ho creato un breve sondaggio anonimo per capire come migliorare la newsletter ed esserti più utile. Se ti va di rispondere a qualche domanda clicca qui (meno del tempo di prendere un caffè). Grazie mille.