Atto I: Il problema con i libri sui replatform
La migrazione che ti sei dimenticato di pianificare
Il marketing era alla scrivania, un martedì mattina, quando ha trovato il nuovo pulsante.
Era piccolo. Diceva qualcosa come Genera con l’AI. Lei ci ha cliccato. Aveva un brief di campagna sul desktop—tre righe su un nuovo cofanetto regalo di olio d’oliva, la data di lancio, l’immagine hero. Ha dato in pasto quelle tre righe alla casella. Quaranta secondi dopo aveva una sezione di pagina completa: titolo, sottotitolo, posizionamento dell’immagine, un layout che faceva grossomodo quello per cui stava per aprire un ticket.
Ci è rimasta sopra un attimo. Ha modificato due parole. L’ha pubblicata.
Dall’altra parte dell’ufficio, il team dei contenuti aveva trovato lo stesso pulsante circa un’ora prima. Ne erano stati entusiasti, in silenzio. Avevano passato la mattinata a prototipare landing page per una gift guide natalizia che non sarebbe servita prima di un altro mese, nel modo in cui a volte passi una mattinata in un lavoro che è frustrante da tanto tempo, quando qualcuno ti mette in mano uno strumento che fa sparire la parte frustrante. Entro martedì pomeriggio, tre nuove sezioni erano online. Entro mercoledì, altre due. Entro venerdì, la homepage aveva sopra cinque sezioni generate dall’AI di cui nessuno in agenzia era stato avvisato.
Ogni sezione era giusta all’incirca all’80%.
È la percentuale peggiore possibile per una sezione di contenuto. Sbagliato al venti per cento è abbastanza sbagliato da farti accorgere—la brand voice è quasi giusta, la tipografia è vicina al sistema, il crop dell’immagine è quasi sulla griglia. Ma non è abbastanza sbagliato da spingere qualcuno a segnalarlo prima di uscire dalla porta, perché le persone che cliccavano pubblica erano le stesse a cui, sei mesi prima, non era permesso avvicinarsi nemmeno alla homepage. Erano al settimo cielo. Si erano guadagnati il diritto di esserlo. Nessuno aveva detto loro che guadagnarsi il diritto di pubblicare non è la stessa cosa che avere il sistema per pubblicare.
La dashboard delle performance se n’è accorta per prima.
La bonifica ha portato via la maggior parte di tre settimane. Un processo di handoff è stato messo insieme, sotto pressione, dopo che il danno era fatto—genera liberamente, finalizza in revisione, pubblica attraverso un gate che non esisteva quando il pulsante è stato cliccato la prima volta. Il processo funzionava. Il processo sarebbe dovuto esistere già dalla prima settimana. È esistito dalla sesta perché quella era la settimana in cui serviva.
Raccontiamo questa storia con affetto. Non erano persone stupide. Il team marketing non si era, in nessun senso significativo, comportato male. Gli era stato dato uno strumento. Avevano usato lo strumento. Il sistema attorno allo strumento—la regola che stabilisce cosa conta come sezione finita e chi decide e quando—non era ancora stato costruito, perché la costruzione di quel sistema non faceva parte del progetto di migrazione. Il progetto di migrazione riguardava l’andare su Shopify. Il sistema che decideva cosa pubblicare era il problema di qualcun altro, sulla timeline di qualcun altro, nel trimestre di qualcun altro.
Questo è il capitolo in cui ti diciamo che sono lo stesso problema.
Ogni brand enterprise che migra su Shopify gira, in silenzio, su anni di memoria muscolare operativa. Sa come gestire una piattaforma. Sa come pubblicare. Ha processi, catene di approvazione e workflow di engineering che sono stati affinati attraverso quel tipo di apprendimento istituzionale lungo e doloroso che produce—alla lunga—competenza. Niente di tutto questo è stato un errore. Magento e Salesforce Commerce Cloud premiavano esattamente questo tipo di disciplina organizzativa. La customizzazione era il modo in cui restavi competitivo. Il controllo centralizzato era il modo in cui restavi stabile. Il modello operativo cresciuto attorno a quelle piattaforme non era un fraintendimento; era una risposta razionale all’ambiente.
Shopify è un ambiente diverso, e tira quasi esattamente nella direzione opposta. Premia la configurazione sulla customizzazione, l’autonomia sul controllo, la proprietà distribuita sul gatekeeping centralizzato. Per un brand che ha passato sei anni a ottimizzare nell’altra direzione, non è una spintarella gentile. È una vera e propria collisione tra due logiche coerenti ma incompatibili—e la migrazione è il momento in cui la collisione diventa impossibile da ignorare.
Ci sono due migrazioni dentro ogni migrazione su Shopify. C’è la migrazione tecnologica: i dati, le integrazioni, il tema, il cutover. È la migrazione che il piano di progetto descrive. E c’è la migrazione del modello operativo: i workflow, i confini di proprietà, i momenti in cui l’organizzazione deve decidere che una cosa che prima richiedeva tre settimane adesso può richiedere tre ore. È la migrazione che il piano di progetto non descrive.
Se ne fai una senza l’altra, arrivi al lancio sulla nuova piattaforma con la stessa organizzazione.
Ci sono due istinti organizzativi che ti hanno servito bene su Magento e ti remeranno contro su Shopify. Entrambi sono, localmente, razionali. Entrambi arriveranno alla migrazione intatti, non annunciati e portanti. Nessuno dei due si identificherà nel piano di progetto.
L’istinto della customizzazione. Su una piattaforma legacy, lo sviluppo custom era la risposta di default a quasi ogni problema. Quando la piattaforma non sapeva fare qualcosa nativamente, lo costruivi. Col tempo, l’organizzazione si è cablata attorno a quell’assunto: i team di engineering sono cresciuti per sostenerlo, il procurement ha imparato a parlare la lingua dei build a scope definito, e l’idea che tu possedessi e controllassi ogni layer dello stack è diventata parte di come la leadership pensava al vantaggio competitivo. Niente di tutto questo era irragionevole. SFCC e Magento erano flessibili proprio perché si aspettavano che ci costruissi sopra. Il build custom era lo strumento giusto perché la piattaforma aveva la forma giusta per il build custom.
Shopify ribalta quella logica. La piattaforma ha opinioni forti su come le cose dovrebbero funzionare, e combattere quelle opinioni è sempre costoso—in tempo di sviluppo, in onere di manutenzione e nel debito tecnico che si accumula ogni volta che pieghi la piattaforma lontano dalla sua forma prevista. Lo sviluppo custom non sparisce; avrai requisiti che giustificano davvero un build su misura, e dedicheremo diversi capitoli più avanti a dirti esattamente quali. Ma la domanda di default deve cambiare. Non più come lo costruiamo? La nuova domanda è: Shopify ci porta al 90% del traguardo?
Sembra semplice. In pratica, richiede una sponsorship attiva da parte della leadership, perché gli ingegneri che hanno passato anni su Magento, in assenza di quella sponsorship, deriveranno di nuovo verso le soluzioni custom. Non stanno facendo ostruzionismo. Stanno facendo se stessi, una cosa che da lontano sembra ostruzionismo e che, a guardarla bene, è solo il muscolo allenato che fa quello per cui è stato allenato.
L’istinto del controllo. Sulla vecchia piattaforma, le modifiche ai contenuti richiedevano codice. I deploy richiedevano coordinamento. I team non tecnici hanno imparato a girarci attorno così:
- Aprendo un ticket.
- Aspettando la prioritizzazione.
- Aspettando sviluppo e QA.
- Pianificando la campagna successiva attorno a quanto tempo tutto questo richiedeva.
Il sistema era lento. Il sistema era frustrante. Il sistema era anche stabile, nel senso che una modifica ai contenuti mal ponderata non poteva, da sola, mandare giù la homepage. Per piattaforme dove rompere la homepage era una possibilità concreta un martedì pomeriggio, quel livello di controllo non era irragionevole.
Shopify rimuove la maggior parte delle barriere tecniche che rendevano necessario l’istinto del controllo. Ma rimuovere la barriera non rimuove, da sé, il comportamento. I team che hanno passato anni ad aprire ticket non passano spontaneamente al self-service quando lo strumento compare nelle loro mani. Il riflesso è più profondo dello strumento. Ed è rinforzato—questa è la parte che la maggior parte dei piani di migrazione non mette a budget—da una paura ragionevole.
L’effetto cumulativo dell’istinto della customizzazione e dell’istinto del controllo, moltiplicato per un’organizzazione enterprise, è una migrazione su Shopify che atterra sulla nuova piattaforma e poi la fa girare come la vecchia. L’engineering possiede ancora i contenuti. I build custom vivono ancora dove sarebbe bastata la configurazione. Le automazioni Flow sono scritte in script lunghi e fragili perché a nessuno, dal lato operations, sono state date le chiavi per comporre le proprie. Il theme editor sta lì—usato per lo più, usato in parte—nel modo in cui un tapis roulant sta nella stanza degli ospiti di una persona che si è, tecnicamente, iscritta in palestra.
I brand in questa posizione ottengono tra un mezzo e due terzi del valore pratico della piattaforma. Hanno pagato l’intera piattaforma. Girano su una fetta di essa. La fetta su cui girano è, secondo qualunque misura onesta, migliore di quello che avevano prima—Shopify è una piattaforma più veloce, più moderna, più affidabile di quella da cui hanno migrato, anche quando usata male. Quindi la migrazione riesce. Riesce nel senso che le dashboard diventano verdi, il lancio esce, il comunicato stampa si legge pulito. Lascia anche, sul pavimento della stanza, una frazione sostanziale del motivo per cui la migrazione era stata approvata.
La cosa lasciata sul pavimento è ciò con cui si sarebbero dovuti pagare i prossimi diciotto mesi della tua roadmap.
Owen Caldwell, Head of E-Commerce di Greycott, ha mandato alla sua agenzia, nella terza settimana di discovery, una nota che recitava, per intero: Dovremo pensare alla formazione, vero? Cioè, cosa fa davvero il team dei contenuti con il nuovo editor la mattina in cui glielo consegniamo.
È il tipo di email che un’agenzia di solito non riceve nella terza settimana di discovery. (Di solito la riceviamo nella terza settimana dopo il lancio, scritta in un registro molto meno collegiale.) Owen aveva letto. Owen aveva letto in particolare di quel failure mode in cui al team dei contenuti viene dato accesso al nuovo sistema e poi, tre settimane dopo, si scopre che non ha cambiato niente. Owen voleva prevenirlo. L’istinto di Owen era giusto.
Dall’altra parte del corridoio—in senso figurato; l’ufficio di Greycott è, di fatto, un magazzino convertito piuttosto piccolo vicino al waterfront di Charleston, e la scrivania di Priya è a diciotto metri da quella di Owen—Priya Shah stava facendo la sua versione dello stesso calcolo, nella privacy della sua testa, sulla sua timeline. Diciassette fogli di calcolo, osservò Priya, a nessuno in particolare, non si migreranno da soli. E poi, avendolo detto solo a se stessa: E nessuno mi ha chiesto quali di loro dovrebbero.
Priya aveva ragione. Nessuno glielo aveva chiesto. Il piano di migrazione elencava operations sotto la colonna intitolata onboarding post-lancio, con una data fissata al secondo mese dopo il cutover. Entro quella data, la migrazione avrebbe deciso—nel codice, nella configurazione, nelle automazioni Flow scritte dal team di integrazione—quali dei diciassette workflow di Priya la nuova piattaforma avrebbe assorbito nativamente e quali no. Priya sarebbe arrivata al suo onboarding post-lancio e avrebbe scoperto che quattordici delle decisioni erano già state prese al posto suo, da persone che non avevano mai aperto il faldone.
Sono due versioni diverse della stessa presa di coscienza. Owen è arrivato alla sua presto. Priya è arrivata alla sua senza che nessuno si accorgesse che era arrivata. Entrambi stanno dicendo all’agenzia, nei loro registri separati, la stessa cosa: la migrazione che avete pianificato non è l’unica migrazione che deve avvenire, e la seconda è la mia.
Se hai un piano di progetto solo per la prima migrazione, la seconda ti accade. Se hai un piano per entrambe, la seconda accade con te. La differenza è la differenza tra un’organizzazione che opera la piattaforma e un’organizzazione che la guarda operare.
L’errore più comune è trattare la migrazione del modello operativo come qualcosa da capire dopo che la migrazione tecnologica è andata in produzione. Sembra logico. Mettiamo la piattaforma online, poi sistemiamo i workflow. In pratica, significa arrivare al go-live con una piattaforma capace e un’organizzazione che non sa come usarla, e poi provare a innestare a posteriori la governance su un sistema che è già in produzione, mentre ogni team a cui era stata promessa l’autonomia finalmente ti guarda costruire la nuova coda dei ticket con i propri occhi.
Ci sono tre pezzi di lavoro che devono avvenire durante la migrazione stessa, non dopo. Li nomineremo una volta e poi ne parleremo lungo tutto il resto del libro.
Il primo è l’audit dei workflow. Prima che il build sia avviato, ti siedi con i team che oggi instradano tutto attraverso l’engineering—contenuti, marketing, operations, customer service—e chiedi loro, workflow per workflow, quali di questi Shopify vi restituisce e quali invece lascia all’engineering? È un piccolo progetto. Richiede una settimana e mezza. È la settimana e mezza con la leva più alta dell’intera migrazione, ed è quella più spesso saltata perché non produce un diagramma che qualcuno voglia mettere in uno status update.
Il secondo è la partecipazione al build. I team che opereranno la piattaforma dovrebbero metterci le mani durante la costruzione. Non come osservatori. Non come le persone che danno l’ok il venerdì. Come operatori, mani sull’ambiente di staging, a costruire pagine vere, a rompere cose in una sandbox a cui è permesso rompersi. La partecipazione fa due cose insieme: produce operatori che arrivano al lancio con una fiducia genuina invece che con una formazione teorica, e ti permette di costruire i guardrail nell’architettura man mano che scopri dove servono. Il brand su Magento che ha fatto questo—il caso opposto alla storia della generazione delle sezioni con l’AI, lo stesso tipo di organizzazione un anno prima—ha ricostruito l’intera homepage con il team dei contenuti nella stanza. Al lancio, il team dei contenuti non era capace di operare in autonomia. Stava operando in autonomia. Lo faceva da due mesi. Il giorno del lancio era, per loro, un martedì qualunque.
Il terzo è la sponsorship attiva della leadership sul cambiamento culturale, in particolare attorno all’istinto della customizzazione. Se la leadership non è nelle riunioni a dire, ad alta voce, useremo Shopify nel modo in cui Shopify vuole essere usato, e l’onere della prova è sul build custom, non sulla configurazione, il team di engineering riempirà il vuoto con le abitudini che ha già. Il team di engineering non sta facendo i capricci. Non gli è stato detto di fare niente di diverso. Le abitudini sono il default. La sponsorship è ciò che cambia il default.
Niente di tutto questo è lavoro complicato. È, però, lavoro vero, e va messo a scope, a budget e staffato accanto alla migrazione tecnologica. I brand che lo trattano come un ripensamento tendono a completare le loro migrazioni in tempo e poi a passare l’anno successivo a scoprire lentamente quanto valore si sono lasciati alle spalle.
Questo primo atto ti ha detto, in vari modi, che questo libro non è un libro di checklist. Le ragioni si sono andate accumulando. La matematica del mid-market non sopravvive al salto. Il progetto è due progetti dentro un solo trench. La proposta dell’agenzia è un documento che parla per lo più di se stesso. La politica della migrazione è la migrazione. E ora questo: il sistema che stai migrando non è l’unico sistema che deve migrare.
La migrazione tecnologica ti porta su Shopify. La migrazione del modello operativo è ciò che determina quanto di Shopify usi davvero. I brand che confondono le due arrivano su una piattaforma più veloce, più moderna, più affidabile—e girano sugli stessi assunti organizzativi che rendevano frustrante la vecchia. L’infrastruttura cambia. I colli di bottiglia no.
Il resto del libro è, in un modo o nell’altro, la seconda migrazione. Il prossimo atto è cosa fai prima che qualcuno muova qualcosa—discovery, sequencing, il retailer di vino che ha fissato la lezione, phased contro big bang, le decisioni di data modeling che bloccano la tua forma per il prossimo decennio. Quello dopo è come far girare il progetto—cicli dentro una waterfall, lo steering committee e la task force, il project management come cartografia. Poi viene il nucleo tecnico, le superfici—le app come governance, i build custom, il middleware, Markets, search, checkout. Il nome di Daniel Okafor è sulla maggior parte di esso. Poi le cose che da fuori sembrano fatte e non lo sono—compliance, accessibilità, tracking, SEO, testing, staging. E infine il cutover, le prime quattro settimane e il gap del modello operativo che affiora solo dopo il lancio. Ogni atto è, a guardarlo bene, anche la seconda migrazione. Continueremo a dirlo. Quando avremo finito, ne sarai un po’ stanco. Sarà la giusta quantità di stanchezza.
Il brand early-adopter del nostro inizio sta bene, comunque. La bonifica ha funzionato. Il processo di handoff ha tenuto. La campagna successiva è uscita senza incidenti, e il team marketing ha continuato a usare lo strumento AI—con il guardrail al suo posto—e ci ha costruito pagine davvero buone. Il danno era reale, ma era riparabile. Niente di questa storia è una tragedia. L’unico spreco dentro di essa è che il processo di handoff esisteva, nella testa di tutti, nella terza settimana del progetto. Solo che non era stato messo per iscritto, perché nessuno aveva deciso di chi fosse il compito.
La migrazione che ti sei dimenticato di pianificare è quella che decide a cosa serve la piattaforma.
Pianificala.