Le replatform sono progetti politici · La guida riluttante alle migrazioni Shopify

Priya Shah, Director of Operations di Greycott & Co., ha un raccoglitore. Il raccoglitore vive nel secondo cassetto della sua scrivania a Charleston, e contiene diciassette fogli di calcolo settimanali. Sono nove anni che li compila ogni lunedì.

Il primo foglio—ormai lo apre a memoria, non guarda nemmeno il raccoglitore—è la riconciliazione della fatturazione wholesale. Il secondo è la previsione del retail. Il terzo è quello che lei chiama “la cosa di QuickBooks”, cioè ciò che succede quando il feed di inventario del magazzino non concorda con quello della finanza. Dal quarto al diciassettesimo sono più piccoli, ma sono tutti suoi.

La nuova piattaforma renderà la maggior parte di questi obsoleti.

Nessuno gliel’ha detto. Non ce n’è bisogno. Lo sa già.

Priya non è l’antagonista di questo capitolo. La paura lo è.

La maggior parte delle agenzie arriva su una replatform aspettandosi un organigramma pulito. C’è un product owner dal lato del brand—una singola persona che raccoglie i requisiti, prende le decisioni, fa da punto di contatto centrale. L’agenzia parla con quella persona, quella persona parla con tutti gli altri, e il diagramma funziona.

Il diagramma non funziona mai.

A scala enterprise, il product owner è un generalista in un’organizzazione piena di specialisti. Sa dirti cosa vuole il team e-commerce. Non sa dirti come il magazzino gestisce i resi, perché non ha mai gestito un reso. Non sa dirti perché la finanza ha bisogno di un certo campo al checkout, perché non ha mai riconciliato un chargeback. Sa dirti che il team dei contenuti ha un workflow. Non sa dirti quale sia il workflow, perché non è mai stato lui la persona che ci clicca dentro alle 23 di una domenica prima di un product drop. Far passare ogni conversazione attraverso quella persona crea un collo di bottiglia che rallenta il progetto, ma soprattutto il collo di bottiglia filtra via i dettagli, e i dettagli sono il punto in cui un progetto di questo tipo funziona o non funziona.

Il problema più profondo è che il diagramma tratta il brand come un monolite—una sola organizzazione, un solo insieme di requisiti. Le organizzazioni enterprise non sono monoliti. Sono insiemi di team che hanno, tra loro, le agende che finiscono stampate sul project charter:

Un lungo tavolo da riunione visto dall'alto, circondato da sedie spaiate angolate ognuna in modo diverso, con pagine di calendario sovrapposte poggiate a faccia in giù sulla superficie del tavolo. — Ogni sedia nella stanza ha un motivo diverso per essere lì.

Il CFO vuole i risparmi che hanno giustificato il progetto.
Il marketing vuole autonomia sulle campagne senza dover aprire ticket allo sviluppo.
Il team dei contenuti vuole un CMS che non gli faccia venire voglia di fare il carrellista al posto suo.

Queste agende in alcuni punti si sovrappongono e in altri confliggono apertamente. Il project charter stampa la versione senza conflitti. Il progetto non ottiene la versione senza conflitti. (Chiedici come lo sappiamo.)

L’agenda che riesci a leggere nel project charter è la metà facile.

Una guida sul campo alla paura.

La paura, su una replatform, è un campo. La paura è tassonomica. La paura ha sottospecie. Abbiamo passato abbastanza anni sulle migrazioni enterprise da poter compilare un catalogo parziale, che offriamo qui con la sicurezza pseudo-accademica di chi è stato morso da ogni esemplare.

Genere: Operativa. Specie: La paura del divario di processo. La paura che la nuova piattaforma esponga un’inefficienza che il team ha assorbito in silenzio per anni. Il workflow dei diciassette fogli di calcolo non è, a guardarlo bene, il modo più pulito di fare la fatturazione wholesale—c’è un modo per farlo nel sistema, in maniera nativa, in due schermate. Priya lo sa. Priya sa anche che è l’esistenza di quei diciassette fogli di calcolo ad averla resa, in nove anni, load-bearing. La nuova piattaforma non minaccia il suo posto di lavoro. La nuova piattaforma minaccia la sua unicità, che è una minaccia più personale e più difficile da nominare.

Genere: Esecutiva. Specie: La paura della scelta originaria. Da qualche parte in questa organizzazione c’è il dirigente che, sei anni fa, ha sostenuto la piattaforma che ora state abbandonando. Non è nello steering committee per caso. È nello steering committee perché il suo giudizio di allora è, implicitamente, sotto processo. Non lo dirà. Farà, invece, un gran numero di domande taglienti sulla roadmap del nuovo vendor e sul track record del partner di integrazione. Non sta ostacolando. Si sta difendendo, una cosa che da sei metri di distanza sembra ostruzionismo.

Genere: Workaround. Specie: La paura della conoscenza istituzionale. Il senior engineer che ha, nell’arco di cinque anni, accumulato una specie di sapere popolare sul perché certe cose nella vecchia piattaforma si comportano come si comportano. Quel sapere popolare è reale. Quel sapere popolare è anche legato a un sistema che sta per sparire. Il senior engineer non sta, tecnicamente, sparendo—ma la versione di sé che contava (quella che sapeva dov’erano sepolti i cadaveri) sì. Ti dirà, nella seconda settimana di discovery, che una certa cosa non si può migrare. Quello che intende è che non è sicuro che la versione di sé che sapeva come funzionava esisterà ancora dopo.

Genere: Carriera. Specie: La paura del fallimento pubblico. L’Head of E-Commerce che ha caldeggiato questa migrazione all’offsite strategico dell’anno scorso, si è assicurato il budget e ha messo il proprio nome sul business case. Se funziona, è un eroe. Se non funziona, è la persona che ha bruciato diciotto mesi e tre milioni di dollari su un progetto che il board si era dovuto far convincere ad approvare. A ogni status meeting chiederà se le cose sono on track. Non sta chiedendo uno status update. Sta chiedendo se è ancora al sicuro.

Ce ne sono altre. La paura del vendor (prossima sottosezione). La paura del magazzino (un capitolo a sé, più avanti). La paura del designer, che è una specie di paura da impostore che riaffiora quando qualcuno nomina per la prima volta la parola metafield.

Il catalogo è parziale. Il catalogo è anche, a pensarci, tenero. Ognuna di queste paure è una persona a cui si chiede di entrare in una stanza di cui non vede il pavimento. Non scriviamo il catalogo per prenderle in giro. Lo scriviamo perché se non sai nominare una paura, non puoi lavorare con la persona che la porta dentro. Puoi solo etichettarla come resistente e andare avanti, che è la cosa che fanno quasi tutte le replatform, che è uno dei motivi per cui quasi tutte le replatform fanno male.

Anche i tuoi vendor hanno paura. Paure diverse, ma lo stesso campo.

Un vendor il cui contratto è in scadenza più o meno nello stesso periodo della tua migrazione è un vendor diverso da uno con un accordo pluriennale ancora in essere. Un vendor che viene sostituito nell’ambito della migrazione ha, matematicamente, un incentivo pari a zero ad aiutarti a migrare via dal suo prodotto. Un vendor che vede la migrazione come un’opportunità per farti un upsell di servizi aggiuntivi sarà ansioso di aiutarti, ma la sua disponibilità arriverà con la forma di un servizio aggiuntivo.

Niente di tutto questo rende i vendor degli avversari. Li rende degli stakeholder, con lo stesso tipo di agende dichiarate-contro-non-dichiarate che hanno i team dal lato del brand. Trattali così. Chiedi, presto, com’è fatto il ciclo di rinnovo di ogni vendor. Chiedi, presto, com’è fatto il loro supporto dedicato alla migrazione—il tuo provider logistico potrebbe aver già migrato quaranta clienti su Shopify e poter configurare la sua parte dell’integrazione con una sola breve call. Chiedi, presto, cosa serve loro da te ed entro quando; i lead time dei vendor sono la cosa che con più probabilità causa una corsa contro il tempo all’ultimo minuto, perché il calendario del vendor non è il tuo calendario e nessuno ti ha avvisato.

Il vendor in scadenza durante la tua finestra di lancio è lo stakeholder nascosto in piena vista. (Chiedici come lo sappiamo.)

Dunque: hai un’organizzazione piena di agende dichiarate, agende non dichiarate, e un catalogo parziale della paura. I conflitti stanno arrivando. La domanda è se hai un processo per gestirli o se ognuno diventa una trattativa politica improvvisata.

Un processo strutturato fa due cose insieme. Primo, costringe nella stanza gli operatori rilevanti—non solo il dirigente che possiede il budget, ma il responsabile di magazzino che userà il tool di logistica cinquanta volte al giorno. La decisione che il dirigente prende nel vuoto è la decisione che, sei mesi dopo, genera lo sfogo collettivo contro il nuovo sistema. Secondo, il processo strutturato depersonalizza la conversazione. Documenti ogni opzione con i suoi pro, i suoi contro e il suo impatto concreto sul business. La conversazione smette di essere l’opinione di Priya contro l’opinione di Owen e diventa l’opzione A riduce l’overhead operativo di circa quattro ore a settimana ma aggiunge tre settimane alla timeline; l’opzione B rilascia nella timeline originale ma richiede uno step di riconciliazione manuale che dovremo rivedere nel Q3. Le persone possono comunque non essere d’accordo. Saranno in disaccordo sugli stessi fatti, che è l’unico tipo di disaccordo che produce una decisione invece che un rancore.

Una volta presa la decisione—con gli operatori nella stanza, con le opzioni sulla carta—applichi il disagree and commit. Tutti vanno avanti. Inclusi, soprattutto, quelli la cui opzione preferita ha perso. La persona che ha sostenuto con più forza l’opzione A non può tornare a discutere l’opzione A alla settimana undici. Può portare informazioni nuove se ne emergono. Non può riportare a galla l’argomentazione originale solo perché ha avuto il tempo di pensare a nuovi modi di formularla. Riaprire le decisioni è uno dei modi più rapidi per dissanguare una migrazione; il resto di questo libro è in larga parte un catalogo degli altri.

Più ti addentri in una replatform, più è facile perdere il filo. Gli sprint si riempiono. I problemi di integrazione si moltiplicano. La meccanica del quotidiano comincia a soffocare gli obiettivi originari, e a un certo punto il tuo team sta consegnando—ticket chiusi, feature rilasciate, milestone raggiunte—senza che nessuno verifichi se le cose che vengono consegnate sono ancora le cose di cui il business aveva bisogno quando è stato approvato il budget. È così che un progetto arriva al lancio avendo fatto tutto ciò che era nel piano e sentendosi comunque come una delusione. In questo scenario hai eseguito con successo un piano che intorno al quarto mese ha smesso di descrivere il progetto giusto.

L’antidoto è una cadenza con gli stakeholder senior che opera a un’altitudine diversa rispetto alle tue sprint review. Non un resoconto di cosa è stato fatto la settimana scorsa. Non una lista di rischi colorata di verde-giallo-rosso. Una conversazione onesta, a livello di singola frase, che chiede: questo progetto è ancora puntato nella direzione giusta. I trade-off a terra si stanno accumulando in modi che nessuno ha esplicitamente riconosciuto? Il business case è scivolato in silenzio fuori sincrono con il lavoro?

Questa conversazione è difficile da mettere in agenda e facile da saltare. Mettila in agenda lo stesso. Lo stakeholder senior è la persona meglio posizionata per tenere la visione originaria e abbastanza in alto da poter sbloccare le cose quando il progetto va alla deriva. Può svolgere quel ruolo solo se gli dici la verità, e l’istinto, in un momento difficile, è di ammorbidire la verità mentre sale, come la ammorbidiresti per un parente che è stato male. Resisti. La verità ammorbidita è la cosa più costosa che puoi consegnare a uno steering committee. È la voce di costo che non compare nel project plan e compare, per intero, nel documento di change order più avanti.

E adesso: Priya.

Hai un’organizzazione piena di paura, un inventario di agende dichiarate e non dichiarate, un modo strutturato per risolvere i conflitti, e una cadenza con gli stakeholder senior che tiene la visione. C’è un’altra cosa.

Metti la piattaforma nelle loro mani.

Non in una slide. Non in un workshop. Non in uno screenshare con il project manager che narra. Nelle loro mani vere. Dagli un login. Dagli l’ambiente di staging. Digli quali task possono provare e lasciaglieli provare. Digli quali angoli sono ancora in costruzione e che quelli saranno pronti più avanti.

Quello che succede, quasi ogni volta, è questo. Il membro del team che era indifferente alla migrazione—o di nascosto ostile—esegue, sulla nuova piattaforma, un task che prima richiedeva quindici minuti. Il task gli richiede due clic. Resta lì, per un attimo, con i due clic. Li riclicca per essere sicuro. Lo fa una terza volta, perché le prime due sembravano uno scherzo.

Due mani sospese appena sopra la tastiera di un laptop in una posa immobile e incredula, lo schermo del laptop girato lontano da chi guarda. — L'ha cliccato una terza volta. Le prime due sembravano uno scherzo.

Poi qualcosa cambia. La tolleranza passiva si trasforma in advocacy attiva. La persona che il mese scorso trascinava i piedi sullo UAT, questo mese chiede quando sarà pronto il prossimo modulo, perché ha delle idee su come andrebbe formato il suo team. La persona che temeva il nuovo sistema come un referendum sulla sua vecchia scelta, questo mese chiede se il nuovo sistema può fare una cosa che il vecchio non poteva. La paura non è sparita. Alla paura è stata data risposta—concretamente, dall’esperienza, con le proprie mani, sui propri tempi. Non puoi convincere una persona a uscire da una paura contro cui non può fare un test. Una volta che può fare il test, il ragionamento si sistema da solo.

È anche l’unico modo per evitare il crunch di UAT della settimana di lancio. Una fase di UAT massiccia alla fine di un progetto è il posto dove le timeline vanno a morire. Una validazione continua, con le mani sul sistema lungo tutto il progetto, fa emergere i problemi al secondo mese, che sono problemi risolvibili; gli stessi problemi che emergono nella settimana di lancio sono crisi. La differenza non è quali problemi esistono. La differenza è in quale settimana li trovi.

Head of Digital il cui board ha approvato questa cosa martedì scorso: Priya non è il tuo problema. Priya è la tua collega. Il sistema che ha prodotto i diciassette fogli di calcolo di Priya l’ha fatto perché, nove anni fa, Greycott non aveva la piattaforma per gestire la fatturazione wholesale in maniera nativa, e Priya si è fatta avanti. Ha fatto il lavoro che l’azienda aveva bisogno fosse fatto. Che lo abbia fatto abbastanza bene, e abbastanza a lungo, da diventare indispensabile non è colpa di Priya. È una storia di adattamento istituzionale, e la migrazione è il prossimo capitolo di quella storia, e Priya, in quel prossimo capitolo, farà un’altra versione della stessa cosa—capirà come la nuova piattaforma si incastra nei suoi workflow, poi in quelli del suo team, poi in quelli del magazzino, e poi diventerà di nuovo indispensabile, in un modo diverso. Il suo posto di lavoro non è a rischio. La sua unicità sta cambiando forma. Diglielo. Ad alta voce. Presto.

Operations Director che legge a fine giornata perché dormire è stato difficile ultimamente: ti vediamo. Siamo stati accanto a persone nel tuo ruolo attraverso sei versioni di questa storia. La paura è reale. La paura è anche temporanea. La cosa che sta dall’altra parte—la versione di te che conosce la nuova piattaforma abbastanza a fondo da essere la persona a cui gli altri chiedono—quella persona esiste già. Solo che non l’hai ancora incontrata.

E-Commerce Director il cui project charter contiene la frase “single product owner”: cancella quella frase. Non ti chiederemo perché è lì. Ti chiederemo di cancellarla. Sostituiscila con un working group integrato con gli operatori nella stanza. Non cambierà la struttura del progetto—descriverà la struttura che il progetto prenderà comunque, che è metà della battaglia. L’altra metà è convincere il procurement che il working group non è un problema di fatturazione.

Il raccoglitore di Priya è ancora nel cassetto. Del raccoglitore non abbiamo ancora fatto niente.

Al nono mese della migrazione, tre dei diciassette fogli di calcolo sono spariti—assorbiti in report nativi della piattaforma che lei può eseguire senza uscire dall’admin. Al dodicesimo mese, ne sono spariti undici. Quando il team scrive la retrospettiva post-lancio, Priya è la persona che tiene le sessioni di formazione per il team wholesale su come usare la nuova dashboard di reporting. Scrivendola, si è scritta una nuova job description. Nessuno in azienda gliel’aveva chiesto.

Il raccoglitore è ancora nel cassetto. Priya lo tiene lì. Non lo apre da quattordici mesi. Ormai è più un totem che uno strumento—la testimonianza di una versione precedente del lavoro, conservata dalla persona che l’ha portato avanti.

Lo tiriamo fuori perché se fai questa cosa per bene, qualcuno nella tua azienda avrà anche lui un raccoglitore. Lo avrà per la stessa ragione. E la domanda di cosa succede a quel raccoglitore—se viene buttato o tenuto su uno scaffale o assorbito in qualcosa di nuovo—è, in un senso reale, la domanda se hai davvero migrato, oppure soltanto spostato.

La maggior parte delle replatform sposta.

Questa, ci auguriamo, migra.