Atto VI: L'altra riva
Le prime quattro settimane
Settimana uno. Il team si riunisce ogni mattina alle nove, e le riunioni sono brevi, e quasi nulla viene deciso lì dentro. Questo confonde il nuovo VP, arrivato due settimane prima del lancio, convinto che uno standup quotidiano fosse il posto da cui si gestisce un lancio. Non lo è. Le dashboard sono già verdi alle nove; qualcuno le guarda dalle sei. Lo standup esiste per un motivo diverso, e il motivo è questo: se qualcosa va deciso oggi, viene deciso oggi, in questa stanza, da queste persone, prima che si disperdano di nuovo nella giornata. La riunione non è uno status update. È un’offerta permanente. È il team che tiene la porta aperta per l’unico problema che non è ancora emerso, così che quando emergerà, ci sia già una stanza in cui può entrare.
Le dashboard dicono che va tutto bene. Le dashboard in passato hanno sbagliato—hai passato un intero capitolo, prima in questo atto, sulla specifica disonestà di uno schermo verde—e così il team tratta il tutto bene come qualcosa da verificare ogni giorno, non come qualcosa da credere. Nessuno in questo team scambia una mattina tranquilla per una mattina al sicuro. Gli hanno detto, persone di cui si fida, la frase verso cui tutta questa parte del libro è andata camminando, e stanno per scoprire quanto sia vera.
Il lancio è l’inizio.
È questa la frase. Non la addobberemo, perché te ne sei guadagnata una semplice, e perché il lavoro delle prossime settimane è soprattutto il lavoro di crederci, dopo che l’adrenalina è svanita.
Ecco cosa la rende difficile da credere. Per mesi—per un anno, in una migrazione grande—il giorno del lancio è stato il giorno. Il piano puntava lì. Il freeze ci conduceva. Il runbook esisteva per quello. Ogni persona sul progetto ha, da qualche parte in fondo alla testa, trattato il lancio come il traguardo, non importa quante volte abbia annuito quando qualcuno diceva che non lo era. E poi il lancio avviene, e per lo più funziona, e la forma naturale del sistema nervoso umano è espirare e iniziare a cercare l’uscita. Il backlog rinviato può aspettare. Il monitoraggio può andare in automatico. L’agenzia può smobilitare. Ce l’abbiamo fatta.
Ce l’hai fatta davvero. Hai fatto la cosa difficile, provata e riprovata, spaventosa, e ha tenuto. E la mossa che ora sei tentato di fare—dichiararla finita—è il singolo errore più costoso a tua disposizione in tutto il periodo post-lancio, perché i problemi che hai rinviato non sono spariti. Li hai rinviati. Sono seduti in una coda con un timestamp, e il timestamp è adesso.
Quindi la prima disciplina è una cadenza, e la cadenza è la cosa più noiosa di questo capitolo e anche quella che più vale la pena azzeccare.
Quotidiana per le prime due settimane. Tutto il team, brevemente, ogni mattina, nel modo del non-decidere-ma-pronti-a-decidere descritto sopra. Poi, quando il sistema avrà passato qualche giorno senza sorprendere nessuno, settimanale. Poi, quando il settimanale inizia a sembrare teatro, ogni due settimane, e poi si ripiega in qualsiasi sarà il tuo normale ritmo operativo, e non stai più gestendo un lancio—stai gestendo un negozio.
L’errore non sta nella cadenza. L’errore sta nel ridurla troppo in fretta. Due giorni puliti non sono la prova che il pericolo sia passato; sono la prova che qualunque cosa dovesse rompersi oggi non si è ancora rotta oggi. La spinta a scendere da quotidiano a settimanale nella prima settimana è enorme, perché le riunioni quotidiane sono costose e sono tutti stanchi e le dashboard sono verdi e sicuramente possiamo restituire alle persone le loro mattine. Resistici comunque per tutte e due le settimane. Il costo di uno standup quotidiano che si rivela inutile è quarantacinque minuti e un po’ di lieve risentimento. Il costo di aver smobilitato il giorno prima che il numero della conversion crollasse in silenzio è una settimana di ricostruzione e una riunione con qualcuno più in alto di chiunque altro nella stanza. Riduci la cadenza man mano che il sistema se la guadagna, non man mano che la tua stanchezza la pretende.
Ora, la cosa per cui serve la cadenza. Stai osservando, e la domanda è cosa.
L’istinto è osservare l’uptime, perché l’uptime è il numero che urla. Osservalo, certo—ma capisci che l’uptime è il guasto facile, quello che si annuncia da solo, quello che fa squillare il cercapersone di qualcuno alle tre del mattino e viene risolto entro colazione. I guasti che fanno davvero male a un negozio migrato nel suo primo mese sono quelli silenziosi, quelli che tengono il sito su e funzionante e semplicemente sbagliato, e li troverai solo se vai a cercarli con una lista specifica e non con un generico senso di vigilanza.
Il delta di conversion, spacchettato—per template, per market, per dispositivo. Un numero di conversion complessivo che sembra sano può nascondere un checkout che si è rotto su esattamente una classe di dispositivi, o un singolo market il cui metodo di pagamento ha smesso silenziosamente di renderizzare, sommerso da tutti gli altri market che si comportano bene. Il numero aggregato è il numero che mente. Spaccalo nel modo in cui il materiale di poco prima ti ha insegnato a spaccare il traffico, per lo stesso motivo.
La rilevanza della search. La search della tua vecchia piattaforma era stata messa a punto negli anni, da persone, contro query reali, e quella nuova sta facendo onestamente del suo meglio contro un catalogo che ha conosciuto la settimana scorsa. Un cliente che cerca la cosa che era venuto a comprare e non la trova non apre un bug. Se ne va. Osserva le ricerche che non restituiscono nulla, e osserva le ricerche che restituiscono per prima la cosa sbagliata, perché la seconda categoria è invisibile in ogni metrica tranne il fatturato.
L’attribuzione del tracking. Da qualche parte uno strato del tuo stack di tracking—e un capitolo precedente ti ha già avvertito che ce ne sono tre—potrebbe aver attraversato la migrazione in modo sottilmente sbagliato, così che le conversioni scattano ma finiscono nel bucket sbagliato, e il team marketing sta per prendere una decisione di budget basandosi su un report di canale che è diventato in silenzio una finzione.
Gli errori di crawl SEO, e qui il materiale della precedente zona di pericolo non è un richiamo, è un’istruzione viva: le prime quattro-sei settimane sono quando il motore di ricerca ri-effettua il crawl e ri-decide cosa sei, e il danno fatto il giorno del lancio arriva nei numeri ora, tre e quattro settimane dopo, con un ritardo lungo precisamente quanto basta a lasciarti rilassare prima. E quando leggi quei numeri—osserva prima il non-brand. Il traffico brand è fedele e lento e continuerà ad arrivare molto dopo che il pavimento è crollato sotto tutto il resto, il che significa che maschera la ferita. La metà del tuo traffico che può davvero farti male è la metà fatta di persone che non conoscevano già il tuo nome. Guarda lì per primo, ogni volta.
E i ticket di supporto—non solo il conteggio, ma la forma. Un picco di ticket è informazione, ma il tipo di picco è il messaggio vero. Un’ondata di “non trovo il mio ordine” è un problema di dati o di collegamento degli account ed è urgente ed è risolvibile e probabilmente non è in fiamme. Un’ondata di “il checkout è rotto” è un animale completamente diverso e significa che qualcuno nella war room dovrebbe già essersi alzato in piedi. Il volume ti dice che sta succedendo qualcosa. La tassonomia ti dice cosa.
C’è una cosa che succede alla lista dei bug nelle prime due settimane di cui nessuno avverte l’engineering lead, e vale la pena dirla chiaramente così che non sembri un fallimento quando arriva.
La lista dei bug cresce prima di restringersi.
Non è un segno che il lancio sia andato male. È un segno che il lancio viene operato—che persone vere ora stanno usando la cosa nelle decine di migliaia di piccoli modi non provabili che nessun ambiente di staging e nessuna prova generale avrebbero potuto produrre, e ognuna di quelle persone è un fuzzer che non hai dovuto pagare. La lista che sale nella settimana uno è il sistema che ti dice che è finalmente sotto carico reale. I team che vanno nel panico davanti a una lista di bug che cresce prendono decisioni sbagliate—iniziano a fare hotfix in produzione a mezzanotte, reintroducendo esattamente l’instabilità che il freeze era progettato per prevenire, sulla teoria che una lista lunga sia un’emergenza. Di solito non lo è. La disciplina è accumulare e dare priorità: cattura tutto, scrivi tutto, e poi fai triage a mente fredda in risolvi adesso, risolvi questa settimana e questo è reale ma può aspettare. Una lista di bug non è una misura di quanto le cose vanno male. È una misura di quanto stai vedendo, e vedere di più è un bene, anche quando non lo sembra.
Il che ci porta, finalmente, alla coda che con tanta disciplina ti sei trattenuto dal toccare.
Per tutto questo libro ti abbiamo detto no. No alla wishlist che voleva diventare un programma fedeltà. No a sistemare la tassonomia il giorno del lancio. No al già che ci siamo che trasforma ogni migrazione in due migrazioni. Il freeze, il cambia-meno-cose-possibile, il parcheggialo-nel-backlog—l’intera spina dorsale della disciplina del progetto è stata una lunga, paziente serie di rinvii, ognuno accompagnato dalla promessa che la cosa rinviata avrebbe avuto il suo turno. Le prime settimane dopo il lancio sono quando quella promessa scade, e mantenerla è insieme una ricompensa e un pericolo.
La ricompensa è ovvia: finalmente puoi costruire le cose che volevi costruire, su una piattaforma ora abbastanza stabile da leggere cosa fa davvero ogni cambiamento. Il pericolo è più sottile. Ciò che rendeva sicuro il rinvio era che cambiavi meno cose possibile mentre il terreno si muoveva. Il terreno ora è quasi fermo—ma “quasi” è la parola operativa nella settimana uno, e la tentazione, dopo aver tenuto la linea così a lungo, è rilasciare l’intero backlog tutto insieme nel momento in cui il lancio è passato, che è solo il vecchio errore con un cappellino di carta in testa. Ti sei guadagnato il diritto di fare cambiamenti. Non ti sei guadagnato il diritto di smettere di osservare cosa fanno. Quindi lasci uscire il backlog lentamente, un cambiamento deliberato alla volta, ognuno spedito in un sistema abbastanza stabile da poter capire davvero se ha aiutato—che è l’intero motivo per cui hai aspettato. Ciò che rinvii conta quanto ciò che risolvi. Ciò che de-rinvii, e quanto in fretta, conta di nuovo altrettanto.
C’è un’altra transizione in queste settimane, ed è quella che più probabilmente verrà gestita male, perché è organizzativa più che tecnica e gli ingegneri che hanno fatto il lancio non sono le persone che lo possiedono.
A un certo punto le persone che hanno costruito la cosa devono consegnarla alle persone che la faranno funzionare. Se l’agenzia o il build team semplicemente evapora la settimana dopo il lancio—chiude il contratto, restituisce i laptop, manda una bella email—hai consegnato un sistema vivo, vecchio di un mese, ancora in assestamento, a un team che non lo ha mai operato, esattamente nella finestra in cui è più probabile che lo sorprenda, e l’hai fatto per il peggior motivo possibile, ossia che il calendario diceva che il progetto era finito. E se l’agenzia resta per sempre, hai costruito una dipendenza che garantisce in silenzio che il team interno non imparerà mai davvero il sistema, perché c’è sempre qualcun altro a cui chiedere.
Nessuno dei due estremi è la risposta, e la risposta è quella a cui questo libro continua ad arrivare da ogni direzione: il team che farà funzionare la cosa va portato dentro la cosa mentre è ancora calda. Pianifica un handoff graduale—non la settimana uno, quando sono tutti troppo occupati a tenere accese le luci per insegnare qualcosa a qualcuno, e non il mese sei, quando la conoscenza si è calcificata nelle teste delle persone che stanno per andarsene, ma attraverso le settimane di mezzo, deliberatamente, con il team interno che prende il volante su pezzi progressivamente più grandi mentre le persone che l’hanno costruita sono ancora nella stanza a raddrizzare lo sbandamento. È la stessa lezione di quella sul migrare le assunzioni e non solo il codice, puntata sulle persone invece che sui dati. Un sistema consegnato senza la comprensione di come funziona è un sistema che entro il trimestre verrà operato per superstizione. L’handoff non è una data. È un programma di studi.
E così, alla fine, ecco la parte per una persona specifica.
Sei l’engineering lead. È la seconda settimana. Stai guardando la lista dei bug, e la lista dei bug è più lunga di quanto fosse il giorno del lancio, e una piccola voce fredda in fondo al cranio si chiede se l’intera faccenda non sia stata un errore—se ti sia sfuggito qualcosa di fondamentale, se le dashboard verdi mentano nel modo in cui mentiva lo store di staging, se stai per diventare la storia che qualcuno racconta in un capitolo successivo del libro di qualcun altro. Sei stanco in quel modo specifico che arriva solo dopo mesi passati a puntarti contro un’unica data immobile. E stai leggendo questo paragrafo a un’ora a cui non dovresti essere sveglio.
Ecco l’unica cosa che vale la pena dirti, ed è vera: questo è normale, e ne uscirai. La lista cresce prima di restringersi. I guasti silenziosi affiorano in ritardo perché è quello che fanno i guasti silenziosi, non perché tu non sia riuscito a coglierli. Gli standup sembrano eccessivi fino alla mattina esatta in cui uno di loro ti salva. La spossatezza è reale ed è anche temporanea, e il sistema che hai costruito sta, proprio ora, mentre ne dubiti, lavorando in silenzio—prendendo ordini, servendo pagine, facendo la cosa insignificante che farà ogni giorno d’ora in avanti finché non sarà semplicemente il negozio e nessuno ricorderà che ce ne fosse mai stato un altro.
Non hai raggiunto il traguardo. Non ce n’era uno. Hai raggiunto l’inizio, che è più difficile e migliore e l’unico posto a cui valga la pena arrivare. Il lancio è l’inizio. Ora va’ a dormire, e torna domattina, perché lo standup è alle nove e potrebbe esserci qualcosa da decidere.