Atto III: A media distanza
Architetti e cartografi
Sulla carta il piano di migrazione sembrava pulito. Cicli, story point, tre mesi di buffer, demo settimanali. Alla sesta settimana il team era in attesa di un vendor doganale in un altro fuso orario, i designer avevano disegnato filtri che avrebbero richiesto ciascuno il proprio metaobject, e l’import storico dei prodotti—in teoria un compito da seconda metà—stava già rimodellando il data model.
Gli strumenti non erano sbagliati. Lo era la disciplina.
È quello che succede quando un project manager competente applica il manuale di un custom build a una migrazione Shopify. Gli standup continuano a esserci. I ticket continuano a muoversi. Il burndown chart continua a scendere nella direzione giusta, più o meno, se non guardi quali ticket si stanno muovendo. Gli stakeholder sono, nominalmente, contenti. Ma da qualche parte là sotto il progetto ha smesso di essere un build e ha iniziato a essere una negoziazione con una piattaforma che non legge il calendario.
Naomi Brennan è stata assunta per gestire la migrazione di Greycott, ed è stata assunta perché era brava. Prima di Greycott aveva guidato il rollout di un ERP sanitario in quattro ospedali regionali—diciotto mesi, approvazioni regolatorie, un data model con dentro le cartelle cliniche dei pazienti, il tipo di progetto in cui un errore non è un refactor ma una deposizione in tribunale. Ha accettato il lavoro su Shopify in parte perché, dopo l’ERP, sembrava una vacanza. (È a chi lo dice ad alta voce che la piattaforma viene a bussare per prima. Chi lo dice solo a se stesso si guadagna qualche settimana in più.)
Non è la cattiva di questo capitolo. È la sua protagonista, ed è bravissima nel suo lavoro, ed è precisamente questo il problema—perché la cosa in cui è brava è la cosa che qui fa male.
Il passaggio dallo sviluppo custom a Shopify non è una questione di velocità. È una questione di agency.
Su un custom build, il sistema si piega alle tue decisioni. Sei tu a possedere il data model, la pipeline di deploy, il livello di integrazione, l’admin. Quando qualcosa si rompe alla decima settimana, lo rifai alla undicesima. Il costo di sbagliare è quasi tutto interno—il tuo team, il tuo tempo, i tuoi compromessi—ed è un costo che puoi pagare più tardi, il che è un modo per dire che quasi non lo senti come un costo. L’intera disciplina di gestire un build è organizzata attorno a questo fatto. Tieni il lavoro in movimento. Aggiusta man mano che la realtà si rivela. Hai mancato una spec di integrazione? Aggiungi uno sprint. Trovato un problema di performance? Lo rifai. Il sistema risponde a te.
Su Shopify è la piattaforma a tracciare il perimetro. I primitivi dei dati sono quelli che sono. La superficie dei customer account è quella che è. Markets è quello che è. Il project manager lavora dentro il perimetro, non sopra di esso, e la differenza non è filosofica, per quanto possa suonare tale. Gli architetti danno forma al mondo. I cartografi lo leggono. Il lavoro che un tempo era dare forma è ora, per lo più, leggere—leggere il terreno con abbastanza accuratezza, e abbastanza presto, da non far marciare il team dentro un canyon che la mappa mostrava già.
Abbiamo visto project manager smaliziati trattare Shopify come un ambiente di sviluppo che si aspettano si pieghi a misura, e poi scoprire al quarto mese che una decisione sui customer account che vorrebbero rimettere in discussione era stata bloccata da primitivi scelti al primo mese. Il percorso da dovremmo cambiare questa cosa al cambiarla davvero passa per l’idea che ha la piattaforma di come funzionano i customer account, non per l’idea che ne ha il team. La decisione non era reversibile. Sembrava soltanto reversibile. (Scopri che la parte che non puoi rifare è la parte che non hai scritto tu.)
Quindi ecco la cosa scomoda, detta chiaramente al senior project manager che sta leggendo e sente il primo prurito di stizza difensiva: il muscolo che hai allenato più a lungo è quello che ti ingannerà di più. La correzione rapida della rotta dentro un feedback loop stretto è l’istinto più prezioso su un custom build e un peso morto su questa. Non è che la tua esperienza non si trasferisca. È che la parte più trasferibile di essa—posso aggiustarlo in corsa—è la parte che qui è silenziosamente falsa, e falsa in un modo che non si annuncerà finché il costo dell’aggiustamento non si è già stratificato. Le persone più esperte a volte fanno più fatica di tutte, esattamente per questo motivo. Hanno più muscolo da disimparare.
Se non puoi aggiustare le cose in corsa, il lavoro deve spostarsi dal triage all’anticipazione—e l’anticipazione è più difficile, non perché il ragionamento sia più difficile ma perché lo è l’attesa. Su un custom build il collo di bottiglia è di solito dentro il tuo team, dove hai leva. Su Shopify i colli di bottiglia sono per lo più fuori, dove non ne hai nessuna. Un integratore ERP su un calendario di release diverso. Un partner di pagamenti con una coda di onboarding di varie settimane. Un’app Shopify la cui roadmap non si piega alla tua timeline. Una feature della piattaforma che è quasi-ma-non-del-tutto quello che ti serve, con il divario riempito dal trimestre di qualcun altro. Il lavoro in sé non è più difficile. Solo, non puoi sbloccarlo da dentro la stanza, e un project manager il cui intero riflesso è sbloccare le cose da dentro la stanza spenderà una gran quantità di energia a spingere contro un muro.
I team che si adattano gestiscono un risk register di tipo diverso. Non cosa potrebbe andare storto dentro il lavoro del team ma cosa potrebbe andare storto fuori da esso, e con quanto anticipo dobbiamo saperlo. Più lontano riesci a vedere, più puoi comprimere il progetto. Più una sorpresa atterra vicino alla scadenza, più costa—e su una piattaforma dove la leva che normalmente tireresti non esiste, costosa può voler dire la finestra di lancio stessa.
Naomi, va detto a suo merito, l’ha capito più in fretta della maggior parte, e il modo in cui l’ha capito vale la pena descriverlo perché sembra una stranezza caratteriale ed è in realtà tutto il lavoro. Teneva due timeline—una per lo steering committee, fatta delle date su cui tutti si erano accordati, e una per sé, fatta delle date in cui credeva davvero. La timeline del committee era una promessa. La sua era una previsione. E poiché manteneva la previsione onestamente, tendeva a conoscere lo slittamento due settimane prima di chiunque altro, il che le dava due settimane per fare l’unica cosa che aiuta: dirlo a qualcuno fuori dal team, presto, finché due settimane erano ancora abbastanza. Sul progetto ERP quell’abitudine era stata una copertura. Sulla migrazione si è rivelata lo strumento—la cosa che un cartografo porta con sé al posto di un volante. Ci aveva passato anni a costruirla per le ragioni sbagliate. Era stata lo strumento giusto per tutto il tempo.
L’anticipazione funziona solo se le decisioni che vanno prese presto vengono effettivamente prese presto—e la trappola è che diverse tra le più gravide di conseguenze sembrano lavoro da seconda metà. Sembrano rinviabili. Non lo sono.
Le migrazioni Shopify hanno una forma più a cascata di quanto la maggior parte dei team si aspetti, non perché la cascata sia virtuosa ma perché l’ordine in cui atterrano le decisioni determina il data model, il design system e la superficie di lancio, e sbagliare l’ordine si stratifica per tutto il resto del progetto. Una manciata di cose va all’inizio anche quando sembrano cose che faresti dopo:
L’import dei dati storici è quello che sorprende di più i team. Sembra un compito di migrazione—spostare le vecchie righe nel nuovo sistema, tardi, una volta che il nuovo sistema esiste. Ma la forma del catalogo legacy, le lacune nei suoi attributi, le convenzioni che il team merchandising ha costruito in silenzio attorno alla vecchia piattaforma nel giro di sei anni—tutto questo cola dentro il data model che stai mettendo in piedi adesso. Rinvia l’import e dovrai adattarci sopra il modello più tardi, malamente, mentre ogni altro workstream tira contro il cambiamento. È qui che vive la verità più scommessa del capitolo, quella che vale la pena portarsi dietro in ogni atto che segue: migra le assunzioni, non solo il codice. Le righe sono la parte facile. Il decennio di convenzioni non dette che vi è cotto dentro è la parte che rimodella tutto a valle, e fa il suo rimodellamento che tu l’abbia messo a calendario o no.
Le grandi integrazioni esterne—ERP, OMS, CRM—hanno i propri calendari di release e le proprie code di onboarding, e prima hai una specifica reale, prima scopri cosa è negoziabile e cosa no. Le scelte architetturali—Markets, customer account, headless o restare nel tema—danno forma a ogni decisione a valle e non sono dettagli da rivedere ma vincoli a cui impegnarsi. E le grandi feature custom, quelle con un proprio livello dati o una propria superficie admin, vanno sequenziate in base a cosa dipende da loro, non in base a quando sembrano scadere.
Lo store locator di Greycott è stato l’esempio che ha insegnato la cosa al team in piccolo. Greycott ha tre negozi retail e un’attività wholesale, e il locator non era un ripensamento nel footer—affiorava in homepage, sulle pagine prodotto, nella logica che diceva a un cliente wholesale quale dei tre negozi gestiva il suo account. Ognuna di quelle superfici doveva prenderne una dipendenza. Costruito per ultimo, avrebbe significato ricostruire tutto ciò che ne dipendeva una volta che fosse finalmente atterrato. Costruito per primo—sequenziato in base ai suoi dipendenti, non alla sua scadenza—era semplicemente infrastruttura su cui il resto del build poteva poggiare. Nessuno voleva spedire lo store locator alla terza settimana. Leggendo la mappa, si vedeva che non c’era nessun’altra settimana in cui spedirlo.
C’è un limite onesto a tutto questo, e nominarlo fa parte del lavoro. In un mondo ideale il data model non si piegherebbe mai allo schema di un’integrazione di terze parti. Nel mondo di Shopify, a volte lo fa—perché il costo di combattere l’integrazione è più alto del costo di compromettere il modello, e un cartografo che finge il contrario sta disegnando una linea di costa dove vorrebbe che ci fosse l’acqua. Nomina il compromesso ad alta voce, con gli stakeholder, prima che morda. La piega che scegli deliberatamente al primo mese è una decisione. La piega in cui ti infili al quarto mese è una ferita.
Il project manager non può essere l’unica persona nella stanza capace di leggere il terreno. Gli errori più costosi su una migrazione Shopify non li fa l’interprete della piattaforma che conosce i vincoli; li fanno a monte di lei, persone che non li conoscono, in stanze in cui lei non c’è.
Un designer che non sa cosa Shopify permetterà disegna esperienze che l’engineering poi ritrocede ad alto costo. Una serie di filtri di categoria su quella migrazione iniziale—quelli del cold open, disegnati liberamente, ricchi e variegati, il tipo di filtraggio che sa di moderno—avrebbe richiesto un metaobject dedicato per ogni valore di filtro per essere spedita come immaginata. Il che voleva dire che il team di engineering di Daniel Okafor si caricava il peso di costruire lo scaffolding dei contenuti strutturati, e il team merchandising ereditava una superficie sterminata da mantenere a mano ogni volta che aggiungeva un attributo, per sempre. Il design era bellissimo. È invecchiato più in fretta di quanto avrebbe dovuto, nel modo in cui invecchiano le cose la cui manutenzione è lavoro di qualcun altro e nessuno ha deciso di chi. L’intera cosa avrebbe potuto essere un design diverso, ugualmente bellissimo, se un briefing di trenta minuti fosse avvenuto prima che lo schermo venisse disegnato. Non è avvenuto. (Se il tuo designer non sa cos’è un metafield entro la terza settimana, è un problema di processo, non un problema di designer.)
La soluzione è poco glamour e di rado avviene per default: un breve briefing prima che ogni sezione di design inizi, che passi in rassegna cosa la piattaforma supporta nativamente e cosa no. Suona troppo ovvio per metterlo per iscritto. Viene saltato su all’incirca ogni migrazione che poi vorrebbe non lo fosse stato. Il principio più ampio è quello da tenere: su Shopify non c’è tela bianca. Ogni schermo è una negoziazione con la piattaforma. I team che vincono presto quelle negoziazioni spediscono meno codice custom, meno workaround fragili, e uno store che il brand può davvero far funzionare per anni. I team che le vincono tardi spediscono un lancio e un backlog di rimpianti.
Quindi ecco la nuova descrizione del ruolo, se qualcuno fosse abbastanza onesto da scriverla: il project manager di una migrazione Shopify non è una versione più lenta del project manager da custom build. È metà product manager, metà interprete della piattaforma. Traduce l’intento di business in ciò che la piattaforma ti lascerà davvero spedire, e traduce i vincoli della piattaforma in decisioni di prodotto su cui gli stakeholder possono agire. Anche il quotidiano ha un altro aspetto. Meno inseguire ticket, più leggere il sistema. Anticipare cosa sta per rompersi. Sequenziare la decisione successiva prima che il team ne abbia bisogno. Tenere la linea, con garbo, contro la parte di ciascuno—se stessi inclusi—che continua a credere che tutto questo si possa aggiustare in corsa.
C’è una ragione per cui questo si posa così spesso sulla migrazione dell’operating model di cui abbiamo passato la fine dell’atto scorso a parlare. Il lavoro dell’interprete e il lavoro della seconda migrazione hanno la stessa forma: entrambi riguardano il divario tra ciò che la piattaforma fa e ciò che l’organizzazione aveva assunto che facesse, ed entrambi peggiorano quanto più a lungo nessuno nomina il divario ad alta voce. L’infrastruttura cambia. I colli di bottiglia no—non a meno che qualcuno il cui intero lavoro è leggere il sistema non legga anche quello.
Naomi ci è arrivata. Non alla prima migrazione; sarebbe la prima a dirti che ha gestito le settimane iniziali di quella di Greycott nel modo in cui avrebbe gestito il build ospedaliero, spingendo contro i muri, e che i muri non si sono spostati. Ci è arrivata attorno alla settimana in cui ha smesso di aprire lo standup chiedendo cosa fosse bloccato e ha iniziato ad aprirlo chiedendo cosa avremmo saputo tra due settimane che oggi non sappiamo. È un piccolo cambiamento nell’ordine del giorno di una riunione. È l’intera differenza tra i due lavori. I project manager che azzeccano questa cosa sono di solito quelli che l’hanno sbagliata alla loro prima migrazione. La disciplina si può imparare. Solo, non è quella con cui la maggior parte dei progetti di replatforming parte.
Ha corretto la rotta per sei mesi. La rotta era un cerchio. Il settimo mese ha smesso di sterzare e ha iniziato a leggere, e il progetto—che era stato un build che fingeva di poter battere la piattaforma in velocità—è finalmente diventato ciò che era stato da sempre: una negoziazione con una mappa.
Gli architetti spediscono piani. I cartografi spediscono a dispetto dei piani.