Atto IV: L'incastro
Portare la scatola nera nella stanza
L’operatore era bravo nel suo lavoro, ed è proprio questo che peggiorava le cose. Una cliente aveva scritto a proposito della sua scatola—il caffè surgelato era arrivato, il numero giusto di capsule, niente di rotto, nessuna lamentela sul prodotto. Voleva solo sapere perché proprio queste. Beveva il caffè nero, l’aveva indicato nelle sue preferenze, e la scatola conteneva tre miscele che l’ultima volta che qualcuno gliel’aveva chiesto aveva segnalato come troppo acide. Così aveva scritto, gentilmente, come scrive chi dà per scontato che dall’altra parte ci sia una persona che ha deciso: Mi sapete dire perché ho ricevuto queste?
Lui non lo sapeva. Ha guardato. Ha aperto il suo account, lo storico ordini, le preferenze dichiarate, le note di magazzino, e niente di tutto questo gli diceva perché il sistema avesse scelto i caffè che aveva scelto, perché la scelta avveniva da qualche parte che lui non poteva vedere—dentro un modello che pesava il suo storico e le sue preferenze e cosa c’era nel freezer quella settimana e un certo numero di altre cose, e ne emetteva una scatola. Le ragioni erano reali. Le ragioni erano anche sepolte in un codice che nessuno dalla sua parte dell’edificio sapeva leggere, e le persone che sapevano leggerlo erano a tre fusi orari e una coda di ticket di distanza. Così ha fatto l’unica cosa umana che aveva a disposizione. Si è scusato, le ha detto che si sarebbe assicurato che la scatola successiva fosse più scura, e le ha mandato una sostituzione scelta a mano, perché sceglierla a mano era l’unica parte della transazione che riusciva davvero a spiegare.
Sei mesi dopo, una qualche versione di quella conversazione si ripeteva decine di volte a settimana. Non una crisi. Niente in fiamme. Solo una tassa costante e a bassa intensità sulla fiducia di tutti—clienti che volevano una ragione, operatori che non ne avevano una, ingegneri che avevano costruito qualcosa di genuinamente brillante e l’avevano vista diventare la cosa che il supporto temeva in silenzio. L’algoritmo funzionava. Per ogni metrica che il team dati guardava, funzionava bene. E rendeva l’azienda un po’ meno capace di parlare con i propri clienti ogni singolo giorno, perché l’unica domanda a cui non sapeva rispondere era l’unica domanda che contava per la persona che la poneva.
Ecco cosa era diventato l’algoritmo, e la parola è esatta, quindi lascia che la usi: una scatola nera. Qualcosa entra, qualcosa esce, e la parte nel mezzo è sigillata. Non per malizia. Nemmeno per sbadataggine—il sistema di Cometeer era l’opposto della sbadataggine, era il frutto di un pensiero vero su come deliziare un abbonato. Ma era sigillato lo stesso, e un sistema sigillato ha una proprietà che non compare in nessuna dashboard: nessuno di quelli che ne devono rispondere può vederci dentro.
Quella proprietà è più costosa di quanto sembri, e diventa più costosa in una forma che vale la pena tracciare, perché la forma è tutto l’argomento. Comincia con un sistema in cui le persone non riescono a vedere dentro. Siccome non riescono a vederci dentro, non si fidano del tutto—e la scarsa fiducia in un sistema automatizzato non è un sentimento, è un comportamento, è l’operatore che sceglie a mano una sostituzione perché la scelta della macchina non si può difendere. Siccome chi manda avanti l’azienda non si fida del sistema, lo aggira, e quella collaborazione tra team che lo migliorerebbe davvero non avviene mai—il team di supporto ha il segnale del cliente e nessun modo di restituirlo, il team dati ha il modello e nessuna idea di cosa stia dando fastidio a qualcuno. Siccome nessuno sa spiegare una decisione, ogni ticket di supporto che tocca la scatola nera ci mette più tempo a risolversi, perché risolverlo significa scusarsi per una ragione che non hai. E siccome nessuno fuori dal gruppo che l’ha costruito può vedere cosa fa il sistema, migliorarlo resta il privilegio esclusivo, e ingolfato, della manciata di ingegneri che l’hanno scritto—il che significa che migliora lentamente, ammesso che migliori, e la lentezza fa da moltiplicatore a tutto quello che sta sopra.
Poca visibilità, poca fiducia. Poca fiducia, nessuna collaborazione. Nessuna collaborazione, risoluzione lenta e miglioramento ancora più lento. È una cascata, scorre verso il basso, e la cosa in cima alla collina è semplicemente se le persone che devono convivere col sistema riescono a vederlo.
Se non riesci a vederlo, non puoi fidartene. Tienitelo stretto, perché è tutta la cura oltre che tutta la malattia, e gran parte di questo capitolo è solo quella frase puntata contro una superficie dopo l’altra. Se non riesci a vederlo, non puoi fidartene—e il corollario, quello che trasforma una lamentela in un piano, è che la visibilità è qualcosa che costruisci, di proposito, con qualunque livello di sforzo il problema meriti. Non devi scegliere tra una scatola sigillata e una cattedrale. Tra le due c’è una scala.
La scala ha cinque pioli, e la disciplina sta nel partire dal più basso che risolve il tuo problema reale e salire solo quando l’utilizzo te lo dice. I team lo fanno al contrario di continuo. Vedono un processo invisibile, decidono che serve una vera interfaccia, e cominciano a dimensionare un’applicazione custom—che è il piolo in cima, il piolo più costoso, il piolo a cui arrivi per ultimo—quando il più delle volte sarebbe bastato il piolo in fondo. Quindi prenderemo i pioli dal basso, perché il basso è quasi sempre il punto in cui dovresti stare.
Il piolo più basso sono i tag. Shopify ti dà la possibilità di taggare quasi tutto—prodotti, ordini, clienti—e un tag è il control plane più leggero che puoi mettere su un processo automatizzato. È un flag che una persona può leggere e una persona può impostare, senza deploy, senza ingegnere, senza ticket. Sembra troppo umile per contare qualcosa, finché non lo vedi funzionare. Il retailer di vino—lo stesso brand italiano che spunta altrove in questo libro indossando qualche cappello diverso—controlla con i tag quali prodotti sincronizzare verso il suo ERP. Una persona delle operations che non ha mai scritto una riga di codice, e mai la scriverà, aggiunge un tag e il prodotto fluisce; lo toglie e si ferma. Il control plane di un pezzo di logica di integrazione che prima richiedeva un ingegnere ora è un campo che una persona che capisce davvero il business può azionare dall’admin, mentre beve un caffè, tra una cosa e l’altra. È il piolo in fondo che fa tutto il lavoro, e costruirlo non è costato niente perché la piattaforma ce l’aveva già.
Il secondo piolo sono i metafield, per quando un flag non basta—quando la cosa che devi rendere visibile ha una struttura, parametri, valori, non solo acceso e spento. Lo stesso retailer di vino che guida la sincronizzazione del suo ERP con i tag guida il suo motore di pricing di terze parti con i metafield: i parametri che il motore usa vivono in campi strutturati sul prodotto, dove un merchandiser può leggerli, modificarli e osservarne l’effetto, tutto dentro Shopify, senza aprire una scatola nera né aprire una richiesta contro di essa. I tag sono un interruttore della luce. I metafield sono le manopole sotto di esso. Entrambi condividono la proprietà che conta—una persona non tecnica può vedere lo stato del sistema e cambiarlo—ed entrambi stanno in fondo alla scala proprio perché non richiedono niente da costruire. Stai facendo emergere la logica conservandola dove le persone possono già guardare.
Il terzo piolo è dove cominci a costruire, e sono le Admin UI Extension—interfacce native che vivono dentro l’Admin di Shopify, dove il team passa già la sua giornata. È il piolo che avrebbe salvato l’operatore di Cometeer. La soluzione per la scatola nera non era rendere l’algoritmo più semplice né consegnare al supporto un PDF che nessuno avrebbe letto. Era costruire, dentro l’Admin, una vista che visualizzasse la decisione—che mostrasse, per una data scatola, i fattori che il modello aveva pesato: le preferenze dichiarate di questa cliente, il suo storico ordini, cosa c’era nel freezer quella settimana, il peso relativo di ciascuno. All’improvviso la scatola non era più sigillata. L’operatore poteva aprire l’ordine, vedere perché proprio quei caffè, e dire alla cliente la verità invece di una scusa. E poi è successa la parte che il team non aveva previsto e su cui non riusciva a smettere di sorridere: una volta che le persone potevano vedere la decisione, i membri non tecnici del team hanno cominciato a suggerire come migliorarla. Il responsabile del supporto ha notato uno schema che il team dati si era perso. Qualcuno delle operations ha proposto un cambio nei pesi. Il modello è migliorato più in fretta di quanto avesse mai fatto, non nonostante fosse uscito dalle mani degli ingegneri ma perché ne era uscito—la visibilità aveva trasformato un sistema sigillato che tutta l’azienda aggirava in un oggetto condiviso su cui tutta l’azienda lavorava.
Il quarto piolo accetta una verità sulle persone che il terzo piolo non accetta: a volte il team che devi raggiungere non vive affatto dentro l’Admin di Shopify. La tua organizzazione di supporto vive in Zendesk, o in Kustomer, o in qualunque help desk si sia standardizzata tre anni fa, e chiedergli di cambiare strumento per vedere ciò che gli serve significa chiedergli di cambiare strumento decine di volte al giorno, il che significa che non lo faranno, il che significa che la visibilità che hai costruito sta in una finestra che nessuno apre. Quindi porti la logica da loro. È la integrazione con piattaforme di terze parti—far emergere il tuo comportamento custom dentro lo strumento che il team ha già aperto. MeUndies ha fatto esattamente questo con la sua logica di subscription: invece di far uscire un agente di supporto da Zendesk per capire o modificare la subscription di un cliente, la subscription emergeva dentro Zendesk. L’agente poteva vedere le spedizioni in arrivo, saltare una consegna, aggiornare le preferenze—tutto senza uscire dal ticket in cui si trovava già. Il sistema non è diventato più semplice. È diventato più vicino. Si è spostato dove stavano le persone che ne avevano bisogno.
Il quinto e più alto piolo è il frontend custom—un’applicazione completa, incorporata nell’Admin o autonoma, costruita quando l’operatività è abbastanza specializzata che niente al di sotto andrà bene. Questa è la cattedrale, e l’avvertenza che la accompagna è la stessa che accompagna qualunque cosa costosa: il più delle volte non ti serve, e la tragedia della scala è quanto spesso i team partono da qui. Quando ti serve davvero, costruirlo non è più l’impresa lunga svariati trimestri che era qualche anno fa—piattaforme di accelerazione come Retool, e altre della stessa famiglia, possono dare un morso consistente al tempo, a volte la maggior parte. Ma il costo che scende non è una ragione per salire. È una ragione per salire con grazia quando i pioli più bassi si sono onestamente esauriti, e non un piolo prima.
Quindi hai una scala, e la domanda diventa quale piolo, e la risposta non è una questione di gusto—si mappa quasi meccanicamente sulla forma del problema, che è la grazia di tutto il framework. Se ti serve uno stato semplice che una persona imposta e il sistema legge, ti serve un tag. Se ti servono parametri strutturati che una persona regola e il sistema consuma, ti servono i metafield. Se ti serve una vista ricca di qualcosa di complicato, e le persone che ne hanno bisogno vivono nell’Admin, ti serve una Admin UI Extension. Se le persone che ne hanno bisogno vivono da qualche altra parte, devi farla emergere in quel da-qualche-altra-parte. E se l’operatività è abbastanza specializzata che nessuna di queste va bene, solo allora costruisci il frontend. Abbina il piolo al problema e spenderai il meno possibile per risolverlo. Allunga la mano verso il piolo in cima per riflesso e passerai un trimestre a costruire una cattedrale per ospitare un interruttore della luce.
C’è un altro pezzo di disciplina, e riguarda la sequenza più che la selezione. Non cominciare passando in rassegna ogni processo invisibile della tua azienda e costruendo visibilità per tutti. Comincia trovando quello che fa più male—la scatola nera che ti sta costando più fiducia, più tempo di risoluzione, più attrito quotidiano e silenzioso—e mettila sul piolo più basso che la apre. Poi guarda come viene usata. L’utilizzo ti dirà se il piolo in fondo bastava o se il dolore si è guadagnato una salita. La scatola nera di Cometeer si è guadagnata una Admin UI Extension perché il costo della sua invisibilità si misurava in decine di conversazioni di supporto a settimana; un processo che ti costa una mail confusa al mese si è guadagnato un tag, se va bene. Lascia che sia il dolore a scegliere il piolo, e lascia che sia l’utilizzo a dirti quando salire.
Questo non è, alla fine, un saggio sulle interfacce. È un saggio su se le persone nel tuo edificio riescono a guardare il sistema negli occhi. Quando migri su Shopify, costruirai automazioni—logica di pricing, logica di sincronizzazione, logica di subscription, logica di raccomandazione, tutto il comportamento brillante che fa sì che uno store enterprise sembri meno un catalogo e più un’azienda. Ognuna di queste è una candidata scatola nera. Ognuna può essere la cosa che l’operatore di supporto teme, o la cosa che l’operatore di supporto apre e spiega. La differenza non è se la logica è buona. La logica di Cometeer era buona. La differenza è se hai speso lo sforzo piccolo e deliberato di portare la scatola nella stanza—di metterla dove la persona delle operations, l’agente di supporto, il merchandiser possono vederla, toccarla e dirti quando sbaglia.
I segni che ci sei riuscito sono silenziosi e si accumulano. I ticket di supporto che prima venivano escalati ora si chiudono al primo contatto, perché l’agente vede la risposta. La fiducia interna nei sistemi automatizzati sale, il che suona vago finché non ti accorgi che il team ha smesso di aggirare la macchina e ha cominciato a fidarsene. La collaborazione tra team sale, perché ora c’è un oggetto condiviso su cui collaborare invece di una scatola sigillata contro cui aprire ticket. Il tempo di manutenzione scende e così il tasso di errore, perché le persone più vicine al problema riescono a vedere il problema. Nessuno di questi comparirà come l’annuncio di un lancio. Compaiono come la lenta sparizione di un certo tipo di brutta giornata.
E vale la pena chiudere dove la piattaforma rende il fondo della scala quasi gratuito, perché il team che migra su Shopify ha un’occasione che il team sullo stack vecchio raramente aveva. Prendi il brand di specialty food che seguiamo lungo tutto questo libro—quello che sta spostando il suo olio d’oliva e gli aceti e i set regalo via da Magento. Sulla vecchia piattaforma, la regola su quali prodotti si sincronizzassero verso il back office viveva in uno script di sincronizzazione e in una serie di convenzioni nella testa di qualcuno, e il modo in cui la direttrice delle operations la teneva onesta era un foglio di calcolo che riconciliava a mano, perché il foglio di calcolo era l’unica superficie che riuscisse davvero a vedere. Su Shopify, quello stesso controllo diventa un tag che imposta lei stessa, modellato esattamente su ciò che il retailer di vino ha costruito—e uno dei suoi fogli di calcolo, quello che esisteva solo per tracciare cosa stesse facendo la sincronizzazione, in silenzio non ha più ragione di esistere. Nessuno lo annuncia. Lei semplicemente lo apre una settimana, si accorge di non averlo toccato da un mese, e chiude il tab. La scatola nera che prima viveva in uno script che non sapeva leggere ora è un campo che le appartiene. È tutto il progetto, in una piccola ora recuperata: la scatola è entrata nella stanza, e la stanza si è rivelata essere stata sua dall’inizio.
Qui giace l’algoritmo che nessuno sapeva spiegare. Sceglieva bene. Sceglieva da solo. L’abbiamo portato nella stanza, e si è scoperto che voleva compagnia.