Atto III: A media distanza
Cicli dentro una cascata
Giorno del lancio, le nove del mattino. Il team di QA interno di Greycott—tre persone delle operations, due dal lato content, tutte quante hanno passato cinque mesi a sentir parlare della migrazione e nessuna delle quali ha mai fatto login nel nuovo admin—ricevono nella stessa email l’URL di staging e una checklist. La checklist ha quarantun voci. L’admin ha, per quanto possano capire, diverse migliaia di cose dentro. Aprono un prodotto. Non sono sicure se il prezzo che stanno guardando sia quello che vedranno i clienti, o quello che un Market sta sovrascrivendo, o quello che un’app sta per cambiare. Non sono sicure dove guardare per scoprirlo. Hanno trentasei ore.
Il lancio va bene come può andare un lancio quando le persone che lo testano hanno incontrato la cosa che stanno testando quella mattina stessa. Cioè va bene, nello stesso modo in cui va bene un volo. Due settimane dopo il team operations trova sei cose—una fascia di prezzo wholesale che arrotonda male, un bundle di gift-set che scala l’inventario sbagliato, un tag di customer-group che non è stato riportato—che il QA avrebbe intercettato in un pomeriggio, se il QA fosse vissuto dentro l’admin per un mese invece di passarci un giorno in visita. Nessuna delle sei è un bug di sviluppo. Ognuna di esse è una cosa che vedi solo quando provi a fare il tuo lavoro vero nel nuovo sistema, e nessuno aveva provato a fare il proprio lavoro vero nel nuovo sistema.
È questo il fallimento di cui parla questo capitolo, e non è un fallimento di testing. È un fallimento di scheduling.
Il capitolo precedente sosteneva che l’ordine delle operazioni in una migrazione Shopify ha una forma più a cascata di quanto la maggior parte dei team vorrebbe—che i grandi impegni architetturali devono atterrare in apertura, in sequenza, perché sbagliare la sequenza si accumula. Tutto questo è vero, e niente di tutto questo va confuso con il permesso di gestire il progetto in sé come un’unica colata di cemento lunga cinque mesi.
L’ordine delle operazioni è a cascata. La quotidianità non può esserlo. Un progetto in sequenza che si esegue come un’unica lunga scatola nera, a testa bassa, silenziosa di demo, apre le porte alla fine su una fase di QA in preda al panico e su un lancio in cui nessuno nell’edificio crede davvero. La disciplina che tiene un team fuori da quella scatola sono i cicli—loop brevi e visibili dentro la sequenza più grande—e ciò a cui servono quei cicli non è la velocity. È il contatto. Il team resta in contatto con la cosa che sta costruendo, e le persone che dovranno gestirla restano in contatto con la cosa che dovranno gestire, settimane prima del giorno in cui diventa loro.
Il modo più limpido di capire perché conti è smettere di trattare sviluppo, assemblaggio e QA come un unico tratto indistinto di “costruzione”. Sono tre problemi diversi, e i piani di progetto che vanno a sbattere sono quelli che hanno messo a budget il primo e dato per scontato che gli altri due fossero la stessa cosa con un cappello diverso.
Lo sviluppo è costruire i pezzi. Una pagina prodotto. Una regola di pricing wholesale. Un flusso di subscription. Ogni pezzo può essere costruito, revisionato e dimostrato in demo per conto suo, e quando funziona per conto suo la ticket si chiude e il burndown chart è felice. Questa è la fase in cui ogni piano di progetto è bravo, perché è la fase che somiglia di più ai custom build da cui tutti provengono. I pezzi funzionano.
L’assemblaggio è ciò che succede quando i pezzi devono diventare uno store. Dati di prodotto veri, tutti gli undicimila SKU, non i sei campioni ordinati su cui la PDP è stata dimostrata in demo. Merchandising vero—i gift-set, le fasce wholesale, le collezioni stagionali, il modo in cui il catalogo di Greycott tiene insieme davvero invece del modo in cui il data model immaginava che avrebbe tenuto. Edge case veri, che è solo un nome educato per le convenzioni che un brand ha accumulato in sei anni sulla vecchia piattaforma e non ha mai messo per iscritto. Una pagina prodotto che fa il render è sviluppo. Una pagina prodotto che un operatore può gestire davvero, con la logica di merchandising che lei si aspetta e l’inventario che si comporta come si comporta il magazzino, è assemblaggio. La maggior parte del valore della migrazione vive in quella seconda frase. E così la maggior parte delle sorprese. I pezzi funzionano; il sistema no, non ancora—e lo spazio tra queste due proposizioni è dove i progetti che credevano di aver quasi finito scoprono che non è così.
Il QA è il terzo problema, ed è quello che i team archiviano regolarmente nella cartella sbagliata. Il QA non è un laptop nuovo e una checklist e una persona che non ha mai visto l’admin che clicca quarantun voci in un pomeriggio. Quella non è assicurazione di qualità; è uno smoke test con un’espressione seria. Il vero QA su una migrazione è il team interno che usa il nuovo sistema come strumento quotidiano—non testarlo, ma operarlo—e scoprire, attraverso l’attrito del provare a portare a termine il proprio lavoro vero, tutti i punti in cui l’idea che il sistema ha del lavoro e l’idea che loro hanno del lavoro non combaciano. Da una checklist non lo ottieni, perché una checklist può solo porre le domande che qualcuno già sapeva di dover porre. Tutto il senso di far entrare gli operatori presto è che pongono le domande che nessuno sapeva di dover porre, nell’unico modo in cui quelle domande affiorano, cioè sbattendoci contro mentre provano a fare qualcosa di reale.
Ed è per questo che il team interno non può essere paracadutato dentro il giorno del lancio, ed è per questo che la versione più comune di questo errore è così silenziosamente devastante: le persone che gestiranno lo store per i prossimi cinque anni vengono trattate come destinatarie della migrazione invece che come partecipanti. Vengono formate nelle ultime due settimane, ricevono le chiavi alla fine, e ci si aspetta che siano fluenti in uno strumento che hanno operato per trentasei ore.
Nella migrazione di Greycott la cosa che ha spezzato questo schema era poco appariscente e sul piano sembrava una piccola voce: il team interno ha ottenuto l’accesso allo staging alla settimana otto, non alla settimana venti. Le persone del content di Owen e un paio di addetti operations di Priya hanno ricevuto le credenziali e l’istruzione permanente di iniziare a fare il loro lavoro vero nel nuovo admin in parallelo a quello vecchio—costruendo la vera collezione autunnale in staging, facendo passare qualche vero ordine wholesale, riconciliando una settimana vera contro il sistema vero invece che una sandbox. Alla settimana otto erano pessimi, ed era proprio quello il punto. Alla settimana dieci avevano compilato il tipo di bug report che puoi scrivere solo quando hai sentito la cosa andare storta sotto le tue stesse mani: l’inventario del gift-set scala i componenti ma non il bundle, e a Natale questo ci farà oversellare. Al lancio non venivano formati sul sistema. Lo stavano operando, e lo facevano da mesi, e il giorno del lancio fu—per una volta—noioso per loro, che è la lode più alta che un giorno del lancio possa guadagnarsi.
Il contrasto è tutto l’argomento. Il team che incontra il sistema il giorno del lancio passa il suo primo mese a scoprire, dal vivo e davanti ai clienti, le cose che il team anticipato aveva scoperto in silenzio alla settimana dieci. I bug sono gli stessi bug. Cambia solo il pubblico.
Sarebbe comodo se i cicli volessero dire sprint e potessimo fermarci lì. Non è del tutto così. La demo di sprint è il ciclo facile, quello che ogni team già fa girare—ecco la cosa che abbiamo costruito, sembra giusta, chi ha appunti. È necessario ed è il loop meno prezioso del progetto, perché chiede se i pezzi funzionano, e i pezzi quasi sempre funzionano. Il ciclo difficile è quello tra uno sprint e l’altro, ed è quello che i team saltano quando sono in ritardo, che è esattamente quando ne hanno più bisogno.
Quel che intendiamo per ciclo difficile è la retrospettiva strutturata che non riguarda il lavoro appena finito ma le dipendenze che stanno per mordere. Non abbiamo rilasciato la PDP ma la spec dell’integratore ERP è attesa per giovedì e se slitta perdiamo la finestra di import, quindi cosa facciamo mercoledì. Non status—anticipazione, del tipo che il capitolo precedente ha argomentato per tutta la sua lunghezza, trasformata in una riunione ricorrente invece che in un tratto caratteriale. La ragione per cui è il ciclo difficile è che non produce nessun artefatto da mostrare in demo e nessuna ticket da chiudere. Produce, in una buona settimana, il preavviso che ti permette di agire mentre agire costa ancora poco. I project manager che lo conducono sono quelli che tengono due timeline—quella su cui tutti si sono accordati e quella in cui credono davvero—e usano lo scarto tra le due come unico vero punto all’ordine del giorno della riunione.
E sopra quel loop, più lento e a un’altitudine diversa, c’è una cadenza di cui gli stakeholder senior hanno bisogno e che non è la sprint review e non andrebbe mai lasciata collassare in una. La sprint review risponde i pezzi funzionano. La cadenza senior risponde a una domanda diversa e più grande: il progetto punta ancora nella direzione giusta. Stiamo ancora costruendo il business che dicevamo di costruire tre mesi fa, o il business è cambiato sotto il piano mentre tutti erano a testa bassa sui metafield. A quella domanda non risponde un burndown chart e non andrebbe posta in uno standup. Merita una sua stanza e un suo ritmo, e uno stakeholder che vede solo la sprint velocity risponderà male, perché la velocity ti dice quanto vai veloce e non dice nulla su se stai andando da qualche parte in cui vuoi ancora essere.
C’è un filo che corre sotto tutto questo, che la fine del primo atto ha nominato e che continua ad affiorare ogni volta che la conversazione si sposta sulle persone invece che sul codice. La parte più difficile di una migrazione non è mai stata spostare i dati. È stata spostare l’organizzazione che opera sui dati—e un’organizzazione non si sposta perché le hai consegnato un sistema finito. Si sposta perché ha passato settimane a vivere dentro il nuovo sistema mentre il vecchio era ancora lì per ripiegarci sopra, facendo i suoi errori in privato, costruendo la memoria muscolare che il giorno del lancio le chiederà. Non puoi aspettarti che un team operi, il primo giorno, un sistema che non ha mai usato. Migra le assunzioni, non solo il codice: le righe sono la parte facile, e le persone che devono gestire quelle righe sono la parte che il piano continua a dimenticare di mettere in calendario. Prima sono nella stanza—nell’admin vero, a fare lavoro vero—più piccolo è lo scarto tra il lancio che rilasci e il lancio che loro sanno gestire.
Quindi tutta l’istruzione del capitolo sta su una scheda, il che è appropriato per un capitolo che ti ha chiesto di non riempirlo. Esegui la sequenza come una cascata, perché la piattaforma ti ci costringe. Esegui le giornate come cicli, perché la scatola nera finisce sempre in un panico. E lascia che le persone che vivranno nello store ci vivano presto, finché essere pessimi è gratis.
La migrazione che ha aperto questo capitolo aveva un piano pulito e un team competente e una fase di QA esattamente dove il manuale dice di metterla. Qui giace il lancio che ha testato bene e ha fallito lo stesso per due settimane: i pezzi funzionavano tutti, e nessuno aveva mai chiesto al sistema di essere uno store.