Atto I: Il problema con i libri sui replatform
Due progetti travestiti da uno solo
Standup del martedì. Rettangolo di Zoom. Il lead engineer sta parlando di idempotenza dei webhook. Parla di idempotenza dei webhook da quattro minuti e, secondo lui, ha appena cominciato. La marketing lead ha gli occhi puntati in basso a destra dello schermo, dove ha la casella di posta aperta in un’altra finestra, dove l’agenzia che cura le campagne le ha appena mandato un brief con le immagini prodotto sbagliate, di nuovo. Il CFO è in muto con la telecamera spenta, su tutta un’altra chiamata. Lo capisci perché c’è un piccolo pallino verde, due finestre più in là, che dice che è in riunione con qualcun altro.
Il product owner è l’unica persona che ascolta il lead engineer, e il product owner ascolta perché il product owner è l’unica persona pagata, in qualunque senso significativo del termine, per ascoltare il lead engineer parlare di idempotenza dei webhook un martedì mattina.
In un solo rettangolo di Zoom stanno avvenendo tre conversazioni. Non è una cosa insolita. È cos’è uno standup di replatform.
Ogni replatform è in realtà due progetti travestiti da uno solo.
Il primo è il progetto tecnico. Ha degli artefatti. Ha una board su Jira. Ha un diagramma di Gantt a cui nessuno crede ma a cui tutti fanno riferimento. Ha commit, branch, pull request, un URL di staging con una password lievemente umiliante. Ha un architetto, forse due. Ha un nome per ogni sistema che tocca e un diagramma per ogni sistema che non tocca. Il progetto tecnico è il progetto che l’agenzia è stata assunta per fare. Il progetto tecnico è il progetto sulla SOW.
Il secondo è il progetto organizzativo, e il progetto organizzativo non ha nessuna di queste cose.
Il progetto organizzativo ha le riunioni. Il progetto organizzativo ha il responsabile di magazzino che sei finalmente riuscito a portare in chiamata alla settimana undici, che ha spiegato—con un tono che lasciava intendere fosse ovvio—che i resi vengono lavorati usando un formato di etichetta di cui nessuno, ai piani alti, ha mai sentito nemmeno il nome. Il progetto organizzativo ha il CFO che vuole vedere i risparmi che hanno giustificato il progetto e che, a suo giudizio, non li ha ancora visti. Il progetto organizzativo ha il content team a cui piaceva il vecchio CMS, il content team che odiava il vecchio CMS, e il content team a cui il nuovo CMS piacerà una volta che avrà capito cos’è, cosa che non ha ancora capito. Il progetto organizzativo ha il responsabile di dipartimento la cui scelta di piattaforma originaria, in virtù di questa migrazione, viene seppellita in silenzio, e che se ne ricorderà nella stagione delle performance review.
Il progetto organizzativo ha le persone. Persone con un lavoro a tempo pieno a cui la migrazione, nella loro onesta valutazione, intralcia il passo. Persone con lealtà di reparto e nemici politici e KPI che nessuno, dal lato dell’agenzia, ha letto. Persone che, quando chiedi loro di cosa hanno bisogno, ti diranno qualcosa di vero ma parziale—la parte che è sicuro dire in un rettangolo di Zoom con dentro undici persone. L’altra parte salta fuori dopo, in un corridoio, o in un DM su Slack alle 21:47, o nella domanda dopo la domanda dopo la domanda, tre meeting dentro a una relazione che hai dovuto costruire per caso perché nessuno ti aveva detto che era compito tuo.
Il progetto organizzativo non ha un diagramma di Gantt. Non può avere un diagramma di Gantt. Un diagramma di Gantt per il progetto organizzativo avrebbe una sola barra che corre per tutta la larghezza del progetto e una sola milestone, intorno alla settimana trentasei, intitolata iniziano tutti a fidarsi gli uni degli altri. La barra sarebbe del colore sbagliato. La milestone slitterebbe.
È questo il libro che stavi cercando sul secondo progetto.
Sul primo progetto di libri ce ne sono tanti. Il primo progetto ha la documentazione ufficiale. Il primo progetto ha, per quanto ne sappiamo, quattordici diversi PDF prodotti dai vendor in circolazione mentre andiamo in stampa, parecchi dei quali piuttosto buoni, tutti quanti sul primo progetto, nessuno su cosa fare quando il direttore operations smette di rispondere ai tuoi messaggi su Slack un giovedì.
Il primo progetto è il progetto su cui tutti vogliono scrivere, perché il primo progetto ha gli esagoni dentro, e la gente adora un esagono.
Il secondo progetto non ha esagoni. Il secondo progetto ha il responsabile di magazzino che devi richiamare perché ti sei dimenticato di chiedergli del formato dell’etichetta. Il secondo progetto ha l’head of digital che ha messo in CC il CFO in una mail del venerdì pomeriggio in cui non avrebbe dovuto mettere in CC il CFO. Il secondo progetto ha il momento, al mese cinque, in cui il team operations smette di rispondere ai tuoi messaggi, e devi capire perché, e il perché non sta in nessun documento. Il perché sta in una conversazione avvenuta in una cucina a un offsite nel 2023, due riorganizzazioni fa, su uno strumento interno che la migrazione sta silenziosamente rendendo obsoleto. Il perché non sta sulla SOW. Il perché non è mai stato su una SOW.
Passeremo una bella fetta di questo libro nel secondo progetto, perché il secondo progetto è dove le migrazioni effettivamente deragliano, e perché il secondo progetto è il progetto di cui nessun altro sta scrivendo. Non è perché il primo progetto ci sembri privo di interesse. Il primo progetto, al contrario, ci affascina. Andremo in profondità su middleware e search e checkout e i diciotto modi in cui una configurazione di Shopify Markets può tradirti in silenzio. Disegneremo diagrammi di architettura. Avremo delle opinioni sui diagrammi di architettura.
Ma il diagramma di architettura non è ciò che uccide la migrazione. Il diagramma di architettura è ciò che uccide l’engineer, magari, e il weekend dell’engineer, e la relazione dell’engineer con il suo partner, che intorno al mese quattro ha cominciato a chiedersi se non sia stata rimpiazzata da un campo intero su un record cliente di Shopify. Il diagramma di architettura non uccide, da solo, la migrazione.
Ciò che uccide la migrazione è il secondo progetto.
Senior Engineer che legge a notte fonda: sei bravo nel primo progetto. Lo sappiamo. Non staresti leggendo a notte fonda se non lo fossi. Il motivo per cui stai leggendo a notte fonda non è il primo progetto. Il motivo per cui stai leggendo a notte fonda è che il direttore operations ha smesso di rispondere ai tuoi messaggi su Slack giovedì e non sai cosa hai fatto. Il primo progetto non ha smesso di rispondere ai tuoi messaggi su Slack giovedì. Il primo progetto non ha uno Slack.
E-Commerce Director che ha saltato il pranzo: non ti eri candidato a fare il project manager tecnico. Ti eri candidato a fare l’e-commerce director. Il board, quando ha approvato la migrazione, non ti ha consegnato una copia del PMBOK. Ti ha consegnato un budget e la promessa implicita che tu, in un certo senso, l’avresti gestita. Adesso stai scoprendo che gestirla significa, in pratica, occuparti del secondo progetto, e sospetti di non essere qualificato per occuparti del secondo progetto, e hai ragione, nel senso che nessuno è qualificato per occuparsi del secondo progetto, nel senso che il secondo progetto è il genere di cosa per cui ci si qualifica solo retroattivamente. Ti stai qualificando adesso. La qualifica è scomoda. È normale.
Project Manager con il diagramma di Gantt dell’inferno: ci dispiace. Non esiste una versione di questa migrazione in cui tu non sia, almeno in parte, un politico. La buona notizia è che i politici che la spuntano in queste cose non sono quelli che sono arrivati volendo fare i politici. Sono quelli che sono arrivati volendo disegnare un piano di progetto pulito e che lentamente, con riluttanza, nel mezzo di un lungo martedì, hanno capito chi aveva bisogno di cosa. Questo sei anche tu. Solo che ancora non lo sai.
Le migrazioni che vanno in porto bene non si distinguono per un approccio tecnico più intelligente o per un documento dei requisiti più dettagliato. Si distinguono per il lavoro costante e ingrato di tenere le persone allineate attraverso mesi di priorità in competizione, contesto che cambia e tensione accumulata. È una cosa che abbiamo già detto, in un post sul blog che nessuno tra quelli che avrebbero dovuto leggerlo ha letto, e la stiamo ridicendo qui, in un libro che forse leggeranno davvero, perché non riusciamo a dirla abbastanza spesso.
I replatform si vincono o si perdono nel messy middle. Il messy middle è il secondo progetto. Tutto il resto di questo libro parla del secondo progetto.
Non faremo finta del contrario. Non faremo finta che questo lavoro prenda una forma più ordinata se adotti il framework giusto o compri il software giusto. I framework sono utili dentro il secondo progetto nello stesso modo in cui le mappe sono utili dentro un paese: una mappa ti dice dove sono le città, non come fare in modo che il sindaco di una parli col sindaco di un’altra. Quella parte la fai a piedi.
Il primo progetto, per fortuna, è sui binari.
La maggior parte di questo libro parla di cosa fare quando ne scendi.
Qui giace la migrazione che era, tecnicamente, in tempo.
Quel tecnicamente stava facendo un sacco di lavoro.