processi · operazioni
Perché i processi documentati vengono saltati (e non è pigrizia)
I team scrivono il processo e il passaggio viene comunque saltato. Le ragioni sono strutturali: distanza, tempismo, documenti obsoleti e aderenza invisibile. Come si presenta ciascuna su un ticket reale, e cosa la risolve.
Ogni responsabile delle operations ha avuto questa conversazione. A un cliente è stata detta la cosa sbagliata, un'escalation è tornata indietro dall'engineering, una release è uscita senza l'approvazione. Qualcuno apre la pagina di Confluence e dice: ma è scritto qui.
È scritto proprio lì. Eppure è stato saltato. Dopo qualche centinaio di queste conversazioni, lo schema è abbastanza chiaro da poterlo nominare. Le persone non saltano i passaggi documentati perché sono sbadate. Li saltano per quattro ragioni strutturali, e ognuna ha una soluzione diversa.
1. Il documento è lontano dal lavoro
Il runbook sta in Confluence. Il ticket sta in Freshdesk. L'issue di engineering sta in Jira. La decisione che cambia tutto è stata presa martedì in un thread di Slack. Chi lavora sul ticket avrebbe bisogno di cinque schede e dieci minuti per ricostruire cosa dice il processo per questo elemento.
Nessuno ha dieci minuti per ticket. Quindi fanno ciò che fanno le persone: agiscono su ciò che hanno davanti, cioè il ticket, e si affidano alla memoria per il resto. La memoria va bene per il percorso comune ed è pessima per l'eccezione, ed è proprio sull'eccezione che il documento si guadagna il suo posto.
Cosa lo risolve: portare il processo al lavoro. Non un link — il passo. "Prossimo passo: di' al cliente che è un comportamento previsto ed esegui Recalculate." Il documento resta la fonte di verità; semplicemente viene letto al posto della persona, per questo ticket, con il contesto collegato.
2. Il passo dipende da un fatto che nessuno ha verificato
La maggior parte dei processi si dirama. "Se la LP è critica per la compliance, apri una P2." "Se il cliente è sulla 4.12 o successiva, il fix è già live." "Se è un solo utente, è un problema di dati; se sono molti, è di configurazione." La condizione del ramo è un fatto sull'elemento, e spesso il fatto non è nel ticket.
Ecco il fallimento silenzioso: la persona non conosce il fatto, non sa che il processo ne dipende e prende il ramo predefinito. Il documento è stato seguito. È stato preso il ramo sbagliato. Nessuno se ne accorge finché non se ne accorge il cliente.
Cosa lo risolve: chiedere. La domanda a cui il documento ha bisogno di una risposta, posta nel momento in cui conta, con le opzioni del documento stesso: un solo utente o molti? In quale ambiente è stato testato? Un processo che chiede prima di presumere viene seguito molto più spesso di uno che presume.
3. Il documento era giusto il trimestre scorso
I processi vanno alla deriva. L'engineering cambia il percorso di escalation, una nuova squad prende in carico un'area, uno strumento viene sostituito. Il documento viene aggiornato sei settimane dopo, se qualcuno se ne ricorda. In quelle sei settimane le persone esperte seguono il processo reale (erano alla riunione) e i nuovi seguono quello scritto. Entrambi pensano di avere ragione.
La versione costosa di questo è la formazione: una coorte formata a marzo su un documento cambiato ad aprile, che a maggio lo fa con sicurezza alla vecchia maniera.
Cosa lo risolve: far rifluire le correzioni. Quando qualcuno dice "è sbagliato, ora facciamo escalation alla squad Learn", quella correzione dovrebbe (a) applicarsi subito a elementi simili e (b) diventare una modifica proposta al documento, con il responsabile che decide. E quando il documento cambia, le persone formate sulla versione precedente dovrebbero sapere cosa è cambiato — in un paragrafo, non in un diff.
4. Nessuno vede l'aderenza finché non diventa un post-mortem
Chiedi a un team lead quale percentuale di ticket ha seguito il processo di triage il mese scorso. Nessuno lo sa. L'aderenza è invisibile finché qualcosa non si rompe abbastanza da giustificare una revisione, e a quel punto la domanda è "chi", non "dove".
Senza visibilità non c'è feedback: un passo saltato il 40% delle volte appare identico a uno che non viene mai saltato. Il documento non può migliorare perché nessuno sa dove fallisce.
Cosa lo risolve: i segnali. Ogni correzione, ogni domanda a cui il documento non ha saputo rispondere, ogni scenario di formazione che le persone sbagliano, raggruppati per fase. Una fase che molti sbagliano è un problema del documento, non delle persone — e ora puoi vederlo.
Il filo conduttore
Nessuno di questi problemi si risolve scrivendo un documento migliore, organizzando una sessione di formazione o mandando un promemoria. Si risolvono riducendo la distanza tra il documento e il momento dell'azione, e lasciando che il momento dell'azione corregga il documento. Quel ciclo — seguire, correggere, riaddestrare — è ciò attorno a cui abbiamo costruito Ovenbird. Ma anche senza uno strumento, vale la pena porsi queste quattro domande su qualsiasi processo che il tuo team continua a sbagliare: quanto è lontano il documento dal lavoro? Da quale fatto dipende il passo? Quando è stato vero l'ultima volta? Come faremmo a sapere che è stato saltato?