Atto II: L'anticamera
La discovery è una postura
Settimana 1 di discovery. Il finance lead scrive, in un pre-survey di otto minuti, che il nuovo sistema deve preservare esattamente i campi di compliance fiscale che ha aggiunto nel 2022. L’e-commerce director, che giovedì scorso in riunione aveva definito il successo come “un checkout più veloce e più semplice”, non ne sa nulla.
Settimana 6 del build. La customer service lead accenna, di sfuggita durante una call su tutt’altro argomento, che il blocco del venerdì pomeriggio segnato sul suo calendario come roba QB sono quattro ore passate a reinserire a mano i rimborsi dentro QuickBooks. A nessuno era venuto in mente di chiederglielo. A lei non era venuto in mente di dirlo.
Settimana 14. Qualcuno in magazzino chiede, un martedì mattina, cosa intende fare la migrazione riguardo al pick sheet del mattino che viene generato da un FTP a file piatto. L’FTP a file piatto sta su un server che è “in programma per la dismissione” da tre anni.
Questi non sono tre fallimenti della discovery. Sono tre successi. Sono lo stesso successo, che riaffiora in tre momenti diversi. Sono l’aspetto di una buona discovery—in modo continuo, lungo tutto l’arco del progetto, non in un unico colpo eroico all’inizio.
Questo è il capitolo in cui ti diciamo che la discovery è una postura, non una fase.
La tentazione, quando leggi una guida ai replatforming enterprise, è trattare la discovery come una fase di progetto—quella con un deliverable chiamato solution proposal, quella che finisce prima che cominci il build. Lo facciamo anche noi. La mettiamo a calendario. La fatturiamo. Consegniamo il documento. C’è un kickoff, e il kickoff ha una cena, e qualcuno, prima o poi, in una mail di status update scrive “la discovery è completa”.
La mail di status update sta mentendo.
Quello che è vero è che il workshop è completo. Quello che è vero è che il primo passaggio sulla soluzione è completo. Quello che è vero è che adesso il team ha, tra le mani, il quadro migliore del progetto che avrà per circa tre settimane, dopodiché il quadro andrà aggiornato, perché qualcosa sarà riaffiorato.
La discovery non è un deliverable. La discovery è una postura che il team adotta e continua ad adottare. Il workshop è dove inizi a praticarla. Le quaranta settimane successive sono dove la pratichi davvero.
Eisenhower aveva una battuta a questo proposito. I piani sono inutili; pianificare è tutto. Eisenhower parlava di un esercito. Noi parliamo di una migrazione Shopify. Entrambe coinvolgono grandi quantità di persone che coordinano i propri comportamenti verso un esito che non possono prevedere del tutto, e in entrambi i casi il valore del piano non è il piano. Il valore è l’atto di pianificare—e, ancora più importante, la disponibilità a continuare a pianificare. L’artefatto con cui esci dal workshop è, in un senso molto concreto, un souvenir. L’asset è la postura.
Ci sono tre ragioni per cui gli affioramenti continuano a succedere, e vale la pena nominarle, perché sono tutte strutturali. Non sono il risultato di un workshop fatto male. Non sono evitabili con una preparazione più accurata. Sono iscritte nella forma stessa di qualsiasi migrazione enterprise, e un team che non se le aspetta verrà sorpreso ripetutamente, e a caro prezzo.
La prima è che l’organizzazione stessa non sa tutto quello che sa. Il blocco QuickBooks del venerdì pomeriggio, il pick sheet del mattino dall’FTP orfano, il campo del checkout aggiunto nel 2022 a causa di un audit in Mississippi—non sono segreti che l’organizzazione sta nascondendo. Sono fatti attorno ai quali l’organizzazione si è adattata. Sono diventati invisibili per le persone che li fanno, come il ronzio di un neon che entro la terza settimana smette di essere udibile. Il workshop ne fa affiorare alcuni. Il build ne fa affiorare altri. Il cutover, com’è prevedibile, fa affiorare quello che resta. Il team di QA, tre giorni prima del go-live, ne fa affiorare uno che nessuno credeva possibile.
La seconda è che lo stato futuro è esso stesso un bersaglio in movimento. La piattaforma verso cui stai migrando non è stabile; rilascia nuove capability ogni trimestre, e alcune di quelle capability faranno sembrare, alla settimana 19 del tuo build, leggermente sciocca una decisione che avevi fissato alla settimana 4. Al workshop non sapevi che Shopify stava per rilasciare la nuova capability di Markets che ti serviva davvero. Non potevi saperlo. La postura è ciò che ti permette di rispondere alla nuova capability come a un’opportunità anziché come a un fallimento della pianificazione.
La terza è che l’organizzazione stessa è in movimento. Il director of operations alla settimana 11 si ritrova un nuovo capo. Alla settimana 17 il brand acquisisce una piccola azienda solo B2B e adesso la migrazione deve pensare al provisioning del wholesale. Il legal, alla settimana 22, ti consegna un nuovo requisito di compliance arrivato da un auditor esterno. Niente di tutto questo era nel workshop. Tutto questo è reale. Niente di tutto questo è una ragione per fare scope-creep sul progetto. Tutto questo è una ragione per mantenere una memoria di lavoro del contesto reale del progetto, che sta cambiando indipendentemente dal fatto che il piano di progetto lo riconosca o no.
Il requisito che erediti non è il requisito che hai. Era un catechismo precedente. Ecco il suo seguito: il requisito che hai oggi non è il requisito che avrai tra sei settimane. Il senso della postura è mettere il team a proprio agio nel dirlo, ad alta voce, quando se ne accorge.
Che aspetto ha la postura nella pratica? Ha l’aspetto di un piccolo numero di abitudini ricorrenti, ciascuna delle quali è insignificante presa da sola e portante presa nell’insieme.
Ha l’aspetto di qualcuno del progetto che, alla fine di ogni settimana, pone la domanda cosa abbiamo imparato questa settimana che non sapevamo al kickoff?—e poi aspetta, attraverso la pausa imbarazzata, finché qualcuno non risponde onestamente. Ha l’aspetto della risposta messa per iscritto da qualche parte dove una versione futura del team potrà ritrovarla. Ha l’aspetto delle assunzioni di lavoro del progetto che vengono aggiornate quando la risposta lo giustifica, per iscritto, con la versione precedente conservata, così che nessuno debba far finta di aver sempre pensata nel modo nuovo.
Ha l’aspetto della spec di integrazione che viene emendata alla settimana 9, quando qualcuno scopre che l’ERP alimenta anche un secondo sistema a valle che nessuno aveva citato. Ha l’aspetto del diagramma di architettura ridisegnato davvero, non solo annotato—ridisegnato in modo che il team che entra alla settimana 14 possa leggerlo senza bisogno di una guida turistica. Ha l’aspetto del data model rivisto alla settimana 11, quando atterra l’acquisizione del ramo wholesale. Ha l’aspetto dello steering committee a cui si dice, con la faccia seria, questa settimana abbiamo scoperto una cosa che ci fa venir voglia di rivedere una decisione presa alla settimana 3. Ha l’aspetto dello steering committee che accoglie quella notizia con curiosità anziché con allarme, perché il team l’ha addestrato, fin dall’inizio, ad aspettarsela.
Ha anche l’aspetto del pre-mortem che viene rifatto. Non una volta sola, alla fine del workshop, ma ogni paio di mesi. Mancano sei settimane al go-live. Il lancio è fallito. Cosa ci è sfuggito? Le risposte alla settimana 4 sono diverse dalle risposte alla settimana 22. Entrambe sono utili. Il team che fa il pre-mortem alla settimana 22 e non trova niente di nuovo o sta mentendo o sta dormendo.
Niente di tutto questo è esotico. Niente di tutto questo richiede una metodologia. Richiede, per lo più, la disponibilità a continuare a dire ad alta voce che il progetto è ancora in via di definizione—e la disciplina di continuare a fare il piccolo lavoro amministrativo che rende quella definizione leggibile a chi si unisce più tardi.
C’è un archetipo di agenzia che fa l’opposto. Vale la pena descriverlo, perché lo incontrerai.
Questa agenzia annuisce con aria saggia quando alla settimana 9 emerge un nuovo finding e dice sì, l’avevamo già messo in conto, in un tono calibrato per comunicare competenza e per scoraggiare ulteriori domande. Questa agenzia esiste, in questo momento, per far sentire al brand che l’agenzia sapeva. Sta, in questo momento, facendo al brand un piccolo, costoso disservizio. Il disservizio è che il finding non viene integrato nel piano di progetto. Il disservizio è che il team impara, per l’esempio, che far affiorare nuovi finding non è il genere di cosa che questo progetto fa—il che significa che il finding successivo, quello della settimana 13, non affiorerà affatto. Quello ancora dopo affiorerà alla settimana 22, quando per farlo affiorare bisognerà spaccare qualcosa che si sarebbe dovuto aggiustare con delicatezza sei mesi prima.
L’agenzia che invece dice non l’avevamo messo in conto; ecco come questo cambia il nostro ragionamento—quell’agenzia ti è più utile alla settimana 9 dell’agenzia che fa finta dalla settimana 9 alla 22 e scopre, alla settimana 23, che far finta non funziona più.
La differenza la noterai alla settimana 9. Te lo stiamo dicendo adesso, prima della settimana 9, così che tu sappia cosa hai davanti quando lo vedrai.
Owen Caldwell, Head of E-Commerce di Greycott, ha tenuto il suo discovery workshop un martedì di inizio novembre. Aveva mandato il pre-survey. Aveva fatto la sintesi. Era stato in piedi davanti alla parete con il warehouse lead e il finance lead e la customer service lead e aveva chiesto, ripetutamente, perché c’è questo. Il workshop, secondo Owen, era andato bene. E anche secondo l’agenzia era andato bene.
L’agenzia ha portato a casa la sintesi, ha scritto la solution proposal, l’ha illustrata a Greycott un mercoledì pomeriggio e ha mandato a tutti un PDF il lunedì successivo. Owen ha inoltrato il PDF al suo CFO con una nota che diceva Sembra tutto a posto. Siamo pronti a partire con il build.
Owen, scrivendo questa mail, credeva due cose. Credeva che la fase di discovery fosse completa. Credeva che la fase successiva fosse il build. Owen, nel corso di questo viaggio, scoprirà che entrambe le convinzioni erano sbagliate nello stesso modo.
Alla settimana 4 del build, la warehouse lead chiamerà Owen per chiedergli del pick sheet del mattino dall’FTP orfano. (Al workshop nessuno le aveva chiesto dell’FTP, perché l’FTP non era venuto in mente a nessuno come una cosa da chiedere. È il tipo di dettaglio attorno al quale l’organizzazione si è adattata.) Alla settimana 9, il finance lead metterà sul tavolo un memo su un nuovo requisito di compliance fiscale statale arrivato dopo il workshop. Alla settimana 14, Shopify annuncerà una capability di Markets che risolve, gratis, un build che l’agenzia aveva stimato in ventisei giorni-sviluppatore.
Niente di tutto questo è una catastrofe. Ciascuna di queste cose, se Owen è rimasto nella postura, è una conversazione moderatamente soddisfacente seguita da un piccolo aggiornamento a un documento. Ciascuna di queste cose, se Owen non è rimasto nella postura, diventa una piccola crisi seguita da un’imbarazzante mail allo steering committee che comincia con ci siamo imbattuti in una complicazione.
Torneremo a trovare Owen più avanti, in entrambi i registri. La cosa che il capitolo vuole farti notare di Owen adesso è che, per Owen, la fine del workshop non è la fine della discovery. È il momento in cui Owen ha la possibilità di chiudere la sua postura o di tenerla aperta. Non ha ancora deciso. La mail del lunedì potrebbe andare in entrambe le direzioni.
Adesso stiamo parlando con te. Proprio con te.
Se stai per mettere a calendario il tuo discovery workshop, segui il runbook. Manda prima il pre-survey. Il runbook non è opzionale, e non è nemmeno sufficiente.
Se sei alla settimana 6 del tuo build e qualcuno del tuo team ha appena fatto affiorare un processo manuale portante che nessuno aveva citato al workshop, non punirlo. Ringrazialo. La postura è fragile e sei tu la persona, in questo momento, responsabile di tenerla aperta. Il team guarda come reagisci. E lo guarda anche quel membro del team che non ha ancora fatto affiorare la cosa su cui sta seduto.
Se sei alla settimana 14 e la piattaforma ha appena rilasciato una capability che risolve ventisei giorni di lavoro che avevi messo a scope, prenditi la vittoria. Poi chiedi, allo standup successivo, se qualcuno si è trattenuto dal far affiorare un finding perché pensava che il progetto fosse troppo avanti per assorbirlo. Due di loro, statisticamente, l’hanno fatto.
Se sei alla settimana 22 e lo steering committee sta per essere informato che qualcosa è cambiato, scrivi la nota con cura. Apri con il finding, non con le scuse. Abbiamo imparato una cosa che ha effetti sul progetto. Ecco come abbiamo intenzione di gestirla. Lo steering committee assorbirà la notizia in base a come l’hai addestrato ad assorbire le notizie. Se hai passato il tempo a infilare di nascosto voci preoccupanti negli status report come rischi senza mai farne affiorare una come finding, stai per avere una settimana più dura di quanto serva.
Cominciare bene è la maggior parte del lavoro. Quasi tutto il resto del lavoro è cominciare bene di nuovo, ogni settimana, su scala più piccola, su qualunque cosa sia affiorata dall’ultima volta. I team che fanno questo sono i team le cui migrazioni atterrano. I team che chiudono la discovery il lunedì dopo il workshop sono i team le cui migrazioni atterrano con un piccolo surplus di questioni irrisolte, che poi vanno a formare la punch list dei primi sei mesi dopo il go-live.
Tu non sei, ci auguriamo, nel business di accumulare una punch list.
Tu sei nel business di costruire una postura.