La cooperazione

Una conversazione può risolvere un incidente senza lasciare un modo di lavorare riutilizzabile. Lo mostra il caso composito di Igor.

È venerdì sera. Igor, SRE esperto, è reperibile e si ritrova in chiamata con il team che sviluppa il prodotto: alcuni utenti continuano a vedere dati vecchi, ma non tutti e non sempre. In questo incidente Igor esercita il ruolo del Senior: lui, gli sviluppatori e l’agente con cui Igor lavora si contestano a vicenda le ipotesi più comode, finché l’indagine si concentra su una corsa fra la scrittura e l’invalidazione asincrona della cache. Il servizio invalida la voce e scrive; se una lettura arriva nel mezzo, trova la voce assente e la ripopola con il valore ancora vecchio, che resta in cache fino alla scadenza. Arrivano il fix, i test e il rilascio in produzione. La cooperazione è stata reale: il risultato è nato dal confronto, il weekend è salvo.

Qualche settimana dopo, la stessa forma di errore compare in un altro servizio che usa la stessa cache. In turno c’è un’altra persona. Il codice corretto è rimasto, ma lo scambio del venerdì sopravvive soltanto nello scrollback: nessuno ha separato la decisione dal resto della conversazione, né ha conservato le ipotesi scartate e le ragioni per cui non reggevano.1 Chi riprende il problema non parte da zero, ma perde proprio la parte più costosa da ricostruire.

Che cosa manca a una conversazione per essere un metodo

Una conversazione efficace può contenere tutto ciò che serve a risolvere il caso presente e lasciare comunque implicito il modo in cui Senior e agente hanno lavorato.2

Una conversazione così non rende il lavoro ripetibile: la volta successiva dipende ancora da chi è presente e da ciò che ricorda. La conversazione può lasciare l’intero scambio, ma non una traccia utile che distingua ciò che avrà valore dopo. E confonde le decisioni con il flusso: diventa difficile ricostruire dove si è scelto, perché e in quali condizioni quella scelta andrebbe riaperta. Nel nastro continuo della chat, una decisione e un tentativo scartato occupano lo stesso piano.

Una buona conversazione è un evento. Un metodo rende riconoscibile e riutilizzabile il modo di lavorare anche quando cambiano le persone e il caso.

Il metodo non promette di riprodurre lo stesso esito: permette di recuperare i criteri, le responsabilità e le ragioni che hanno prodotto l’esito precedente.

Quando la cooperazione si impoverisce

Perfino una cooperazione riuscita come quella di Igor resta implicita. E la cooperazione può impoverirsi in molti altri modi: puoi fare tutto da solo, delegare senza direzione oppure restare coinvolto soltanto per correggere l’output a valle. Cambia la quantità di intervento, non il difetto, che è sempre lo stesso: il rapporto di lavoro resta implicito.

Il modo di lavorare rimane nella testa di una persona,3 oppure le decisioni si disperdono nell’esecuzione e nella review.

Progettare il rapporto

La cooperazione efficace dipende da come viene progettato il rapporto di lavoro, non soltanto dalla capacità del modello linguistico o dalla qualità dei singoli partecipanti.

Progettare il rapporto significa dare alla conversazione una forma che le sopravviva. Nel caso di Igor, la direzione può essere stata chiara durante l’incidente ed essere tornata implicita subito dopo. Un metodo rende esplicito chi dirige e ne risponde, anche quando Senior e agente contribuiscono entrambi alla scelta. Distingue le decisioni direzionali dalle molte decisioni operative e dai passi dell’esecuzione. Seleziona infine ciò che merita di essere conservato: non tutto il dialogo, ma il poco che avrà valore quando lo stesso problema tornerà con altre persone.

Non serve ancora trasformare queste parti in un ciclo o in una procedura. Quel venerdì sera non mancavano né intelligenza né collaborazione: il confronto aveva prodotto giudizio. Mancava una struttura capace di portare oltre l’incidente gli esiti di quel giudizio che meritavano di durare.

Il punto di contatto

Se la cooperazione va progettata, il primo punto da osservare è ciò che il Senior consegna all’agente nel momento in cui gli affida qualcosa. Nel fare tutto da solo quel momento non arriva mai; nella delega senza direzione si riduce a «pensaci tu». Sono i due estremi dei tre modi visti sopra, con la correzione a valle nel mezzo: tra quegli estremi serve una forma diversa da tutte e tre, che tenga insieme direzione e autonomia.

«Assegnare un compito» e «formulare un mandato» non sono la stessa cosa. La distanza tra i due è il primo luogo concreto in cui il rapporto smette di essere implicito.


  1. In ambito SRE ciò che sottrae allo scrollback le ipotesi scartate, la decisione e le sue ragioni è il postmortem, nella forma blameless diffusa da Google: un documento che trasforma un incidente in apprendimento riutilizzabile, invece di lasciarlo disperdere nella cronologia della conversazione. Il riferimento è il capitolo «Postmortem Culture» di Site Reliability Engineering, a cura di Beyer, Jones, Petoff e Murphy (O’Reilly, 2016).↩︎

  2. Il sapere che si esercita senza saperlo enunciare — qui il modo di lavorare che vive nella pratica e non nel testo — è la conoscenza tacita (Michael Polanyi, The Tacit Dimension, 1966). Renderla esplicita, e perciò condivisibile e riutilizzabile, è l’oggetto del knowledge management; il modello SECI di Nonaka («A Dynamic Theory of Organizational Knowledge Creation», Organization Science, 1994) descrive proprio la conversione continua fra i due stati.↩︎

  3. Quando il modo di lavorare vive solo nella memoria di chi era presente, il progetto dipende da quelle persone: in inglese si parla di bus factor (o truck factor), il numero di persone che, venendo a mancare, lascerebbero il lavoro senza continuità. Il sapere non scritto che circola a voce nel gruppo è la tribal knowledge.↩︎