processi · documentazione
Come dovrebbe rifluire una correzione nel documento
"È sbagliato, ora lo facciamo diversamente" è la frase più preziosa nelle operations e la più spesso persa. Un progetto per il ciclo che va dalla correzione al precedente, alla modifica suggerita, fino al riaddestramento.
Da qualche parte nella tua azienda, oggi, una persona esperta guarderà una risposta — di un collega, di una wiki, di un chatbot — e dirà è sbagliato, ora facciamo diversamente. Poi correggerà il ticket e andrà avanti. La correzione vivrà nella sua testa e, se il collega è fortunato, anche in quella del collega. Il documento resta sbagliato.
Questa è la singola perdita più grande nel modo in cui le aziende mantengono i propri processi. Non che le persone non conoscano il processo reale; è che il processo reale non torna mai sulla pagina.
Cos'è una correzione
Una correzione è tre fatti insieme:
- Il default del documento era sbagliato per questo caso. Forse sempre, forse solo per questo tipo di elemento.
- Ecco cosa facciamo davvero. Di solito da qualcuno che era alla riunione dopo la quale il documento non è stato aggiornato.
- Il documento dovrebbe probabilmente dirlo. Ma chi corregge è impegnato, non è il responsabile, e modificare una pagina di Confluence non è compito di nessuno alle 16 di martedì.
La maggior parte dei sistemi non ne conserva nessuno. Uno buono li conserva tutti e tre e fa qualcosa di diverso con ciascuno.
Il ciclo
Registrala dove è successo. La correzione appartiene all'elemento (ticket 48230), al processo (triage LP), alla fase (escalation) e alla persona. È abbastanza per raggrupparla in seguito: tre correzioni nella stessa fase da tre persone diverse sono un difetto del documento, non tre opinioni.
Applicala subito come precedente. Il documento non verrà aggiornato per settimane. Nel frattempo, gli elementi simili dovrebbero ricevere la risposta corretta. "Su una LP di contenuti del connettore, prima sincronizza, poi esegui l'escalation" dovrebbe valere già da domani, con la fonte in evidenza — corretto da Olivia su #48230 — così la persona successiva sa perché la risposta è diversa da quella della pagina.
Trasformala in una modifica proposta, per il responsabile. Non una modifica automatica: una modifica specifica. Sostituisci questo paragrafo con quest'altro, per questi tre segnali. Il responsabile approva, rifiuta o riscrive in un minuto, che è il tempo che i responsabili hanno davvero. Per i documenti conservati nel tuo strumento la modifica può essere applicata direttamente; per una pagina di Confluence, viene pubblicata come commento che il responsabile può riprendere.
Registra la nuova versione e spiega cosa è cambiato. Un diff serve al responsabile. Per tutti gli altri — soprattutto per chi è stato formato sulla versione precedente — basta un paragrafo: il controllo del connettore ora viene prima dell'escalation; riguarda la fase 2; lo vedrai nel tuo prossimo ripasso. Se è cambiata solo la formulazione, dillo, e non far rifare un corso a nessuno per una virgola.
Alimenta la formazione. Lo scenario che quattro persone hanno sbagliato il mese scorso riguardava proprio questa lacuna. Ricostruiscilo dal nuovo testo. Il prossimo gruppo impara il processo com'è, non com'era.
Perché oggi succede di rado
Perché ogni passaggio appartiene a uno strumento diverso e a una persona diversa. La correzione è su Slack, il documento su Confluence, la formazione nell'LMS e il responsabile in una riunione. Nessuna singola cosa è difficile; è nei passaggi di consegna che tutto si perde.
Mettere il ciclo in un unico posto — seguire, correggere, proporre, versionare, riaddestrare — è l'idea di progettazione alla base di Ovenbird. Ma vale la pena costruire il ciclo anche a mano: quindici minuti a settimana in cui il responsabile del processo legge le correzioni della settimana, raggruppate per fase, correggerebbero più documenti di quanti la maggior parte delle aziende ne corregga in un anno.