procesos · documentación
Cómo debería volver una corrección al documento
"Eso está mal, ahora lo hacemos de otra manera" es la frase más valiosa en operaciones y la que más a menudo se pierde. Un diseño para el bucle que va de la corrección al precedente, a la edición sugerida y a la nueva formación.
En algún lugar de tu empresa, hoy una persona con experiencia mirará una respuesta —de un compañero, de una wiki, de un chatbot— y dirá eso está mal, ahora lo hacemos de otra manera. Luego arreglará el ticket y seguirá con lo suyo. La corrección vivirá en su cabeza y, si el compañero tiene suerte, también en la suya. El documento sigue mal.
Esta es la mayor fuga en la forma en que las empresas mantienen sus procesos. No que la gente no conozca el proceso real; sino que el proceso real nunca vuelve a la página.
Qué es una corrección
Una corrección son tres hechos a la vez:
- El valor por defecto del documento era erróneo para este caso. Quizá siempre, quizá solo para este tipo de elemento.
- Esto es lo que hacemos en realidad. Normalmente lo dice alguien que estuvo en la reunión tras la cual no se actualizó el documento.
- El documento probablemente debería decirlo. Pero quien corrige está ocupado, no es el responsable, y editar una página de Confluence no es tarea de nadie a las 4 de la tarde de un martes.
La mayoría de los sistemas no conserva ninguno de los tres. Uno bueno conserva los tres y hace algo distinto con cada uno.
El ciclo
Regístrala donde ocurrió. La corrección pertenece al elemento (ticket 48230), al proceso (triaje de LP), a la etapa (escalar) y a la persona. Con eso basta para agruparla después: tres correcciones en la misma etapa por parte de tres personas son un defecto del documento, no tres opiniones.
Aplícala de inmediato como precedente. El documento no se actualizará hasta dentro de semanas. Mientras tanto, los elementos similares deberían recibir la respuesta corregida. "En un LP de contenido de conector, sincroniza primero y luego escala" debería aplicarse mañana, mostrando la fuente — corregido por Olivia en #48230 — para que la siguiente persona sepa por qué la respuesta difiere de la página.
Conviértela en una propuesta de edición para el responsable. No un cambio automático: uno concreto. Sustituye este párrafo por este otro, por estas tres señales. El responsable aprueba, rechaza o reescribe en un minuto, que es el tiempo del que realmente disponen los responsables. Si el documento está en tu propia herramienta, la edición se puede aplicar directamente; si es una página de Confluence, se publica como comentario que el responsable pueda recoger.
Registra la nueva versión y explica qué ha cambiado. Un diff es para el responsable. Para todos los demás —sobre todo para quienes se formaron con la versión anterior— basta un párrafo: la comprobación del conector ahora va antes de escalar; esto afecta a la etapa 2; lo verás en tu próximo repaso. Si solo ha cambiado la redacción, dilo también, y no obligues a nadie a repetir un curso por una coma.
Alimenta la formación. El escenario que cuatro personas fallaron el mes pasado trataba justo de esta laguna. Reconstrúyelo a partir del nuevo texto. La siguiente promoción aprende el proceso tal como es, no como era.
Por qué esto rara vez ocurre hoy
Porque cada paso pertenece a una herramienta distinta y a una persona distinta. La corrección está en Slack, el documento en Confluence, la formación en el LMS y el responsable en una reunión. Ninguna pieza es difícil por sí sola; el problema está en los traspasos, donde todo se pierde.
Reunir el ciclo en un solo lugar —seguir, corregir, proponer, versionar, reformar— es la idea de diseño detrás de Ovenbird. Pero merece la pena montar el ciclo incluso a mano: quince minutos a la semana en los que el responsable del proceso lea las correcciones de la semana, agrupadas por etapa, arreglarían más documentos de los que la mayoría de las empresas arreglan en un año.