Se activa una alerta a las 2:10. Un ingeniero implementa un cambio de configuración, el servicio de pago comienza a mostrar errores y el responsable de guardia lo revierte 40 minutos después. En la reunión de revisión, la primera pregunta es: "¿Quién implementó el cambio?". En cuestión de minutos, la conversación gira en torno al criterio de una sola persona a las 02 de la madrugada, y nadie pregunta por qué el cambio llegó a producción sin una alerta inicial, por qué la alerta tardó tanto en activarse o por qué el manual de procedimientos estaba desactualizado.
Este es un ejemplo ilustrativo, no un caso real de un cliente. Es reconocible porque sucede: una revisión de incidentes que se centra en la última persona que actuó produce una historia bien estructurada, pero con muy poco aprendizaje.
Esta guía está dirigida a gerentes de ingeniería y líderes de capacitación que buscan que el personal mejore su capacidad para analizar la evidencia de incidentes y acordar mejoras que puedan ser probadas. Cubre cómo diferenciar las brechas de habilidades de las condiciones que las rodean, cómo diseñar prácticas, cómo realizar sesiones informativas posteriores y cómo medir la efectividad de las revisiones.
Qué significa y qué no significa "inocente".
El libro de Google sobre Ingeniería de Confiabilidad de Sitios lo deja claro: para que un análisis post mortem sea verdaderamente imparcial, debe centrarse en identificar las causas que contribuyeron al incidente sin acusar a ningún individuo o equipo de mala o mala conducta. También describe la premisa subyacente: todos los involucrados actuaron con buenas intenciones e hicieron lo correcto con la información que tenían.Libro de Google sobre SRE: "Cultura post mortem: Aprendiendo del fracaso"..)
Que no haya culpabilidad no significa que no haya consecuencias. El mismo capítulo exige que los análisis posteriores a un incidente concluyan con acciones prioritarias y responsables. Si bien la investigación sin culpabilidad requiere rendición de cuentas, esta se traslada de "¿quién causó esto?" a "¿quién mejorará la seguridad del sistema y para cuándo?". Si sus revisiones omiten la segunda parte, tendrá una conversación agradable, no un proceso de aprendizaje.
1. Identificar el comportamiento y su contexto.
Empiece por el comportamiento específico que desea cambiar. "Nuestras revisiones de incidentes se centran en la última persona que actuó" es observable. "Nuestra cultura se basa en culpar a los demás" no lo es.
Luego, pregúntese si se trata realmente de un problema de habilidad. El entrenamiento solo puede solucionar algunas de las causas del bajo rendimiento. Antes de construir nada, distinga tres posibilidades:
- Una habilidad que falta. Los revisores no saben cómo elaborar una cronología, distinguir un desencadenante de un factor contribuyente, ni preguntarse "¿qué hizo que esta acción pareciera razonable en ese momento?".
- Incentivos. Las reseñas influyen en las conversaciones sobre el rendimiento, por lo que la gente adapta sus cuentas para protegerse.
- Gradientes de autoridad y respuestas anteriores. Un ingeniero junior que expresó su preocupación el trimestre pasado y al que se le dijo que dejara de ser negativo no volverá a expresarla en esta reunión, por muy bien formado que esté.
Solo el primero es un problema de capacitación. Los otros dos son condiciones. Si se entrena la habilidad pero no se modifican las condiciones, las personas repetirán algo que el entorno laboral penaliza. Considere su visión actual de la causa como una hipótesis y compruébela con algunas conversaciones con ingenieros y revisando documentos recientes antes de comprometerse con un programa.
2. Establecer las condiciones operativas para la práctica.
Practica las transferencias solo si el entorno laboral lo permite. Antes de que nadie ensaye, acuerda estos puntos con las personas que realizan las evaluaciones:
- Responsabilidades aprobadas. ¿Quién facilita el proceso, quién elabora el cronograma, quién se encarga del seguimiento? Es importante definir claramente las funciones para que el facilitador no improvise autoridad.
- Cómo los líderes reciben las inquietudes. Si un ingeniero dice "la herramienta de despliegue me permitió omitir la fase de prueba", ¿qué debe hacer el director a continuación? Decidir la respuesta con antelación, por ejemplo: agradecerle, registrarlo como un factor que contribuyó al problema y asignarle una acción.
- La respuesta del supervisor. El ensayo del personal requiere una respuesta correspondiente por parte del supervisor. Si se capacita a los ingenieros para que expresen sus opiniones en las evaluaciones, pero sus gerentes siguen preguntando "¿de quién fue la culpa?", la capacitación no servirá de nada.
Una breve sesión informativa para los gerentes sobre el proceso de evaluación es tan importante como la capacitación para los participantes. Incluya una explicación clara de cómo se utilizan (y cómo no se utilizan) los documentos de evaluación en la gestión del desempeño.
3. Diseñar un itinerario de aprendizaje basado en el comportamiento.
La guía del Centro Eberly de Carnegie Mellon sobre objetivos de aprendizaje destaca el útil punto de que los objetivos, las evaluaciones y las estrategias de instrucción deben estar alineados entre sí (Centro Eberly, Objetivos de aprendizaje). Se trata de una guía de diseño, no de evidencia sobre ninguna herramienta o resultado en particular, pero es una buena prueba para este programa: si el objetivo es analizar la evidencia y acordar mejoras comprobables, entonces las preguntas de recuerdo por sí solas no pueden ser la evaluación.
La taxonomía de Bloom resulta útil para describir la exigencia cognitiva de la tarea: analizar, evaluar y crear. Describe lo que la tarea requiere de una persona, pero no explica por qué la realiza o no, por lo que no debe utilizarse para diagnosticar la motivación.
Un proceso viable consta de tres etapas.
| Fase | Acción del alumno | Entrega |
|---|---|---|
| Preparación | Lea su política de revisión de incidentes y un breve glosario (desencadenante, factor contribuyente, mitigación, elemento de acción). Un breve diagnóstico verifica los requisitos previos. | Estudio a su propio ritmo. La comprobación de conocimientos solo confirma los requisitos previos, no evalúa las habilidades. |
| Práctica | Analice un caso práctico de incidente y acuerde mejoras comprobables. Se requiere una respuesta razonada, no una simple selección de opciones. | Práctica de casos interactiva o facilitada, con retroalimentación sobre la calidad del análisis de los factores contribuyentes y el seguimiento posterior. |
| Revisión y transferencia | Analice una opción ambigua y, a continuación, complete un caso nuevo o una revisión real supervisada. | Entrenamiento en vivo o revisión asíncrona. Verificar la transferencia después de que las personas hayan tenido tiempo de usar la habilidad en el trabajo. |
Mantén el caso realista y solicita la validación de un ingeniero experimentado. Un caso técnicamente incorrecto genera desconfianza en los revisores.
4. Analice el escenario y realice una sesión informativa.
Así podría desarrollarse una sesión práctica con el escenario de las 02:10. El paquete de evidencias contiene el registro de despliegue, la cronología de alertas, la política de paginación, la solicitud de extracción y el manual de procedimientos, todos ficticios.
Indicación al participante. Explique por qué el ingeniero impulsó el cambio en ese momento. Cite las pruebas que utilizó. Indíquenos qué información o apoyo adicional necesitaría antes de poder estar seguro.
Una respuesta débil suena así: "El ingeniero debería haber revisado la puesta en escena". Menciona a una persona, no cita nada y no propone ningún cambio.
Una respuesta más contundente sería la siguiente: "El registro de despliegue muestra que el cambio se implementó directamente porque el paso de prueba canary es opcional en la herramienta. La solicitud de extracción tuvo un revisor que la aprobó tras un intervalo de 20 minutos. La página se activó 18 minutos después de que comenzaran los errores, ya que el umbral de alerta se configuró con un promedio de cinco minutos. Me gustaría saber cuántos otros cambios de este mes omitieron el paso canary y si a los ingenieros de guardia se les ha informado alguna vez que este paso se puede omitir. Acciones propuestas: hacer que el paso canary sea obligatorio para este nivel de servicio, responsable: equipo de plataforma, verificación: intentar un despliegue sin el paso canary en el entorno de pruebas y confirmar que está bloqueado; reducir el intervalo de alerta, responsable: responsable de guardia, verificación: reproducir los errores de la semana pasada con el nuevo umbral."
Fíjate en lo que lo hace mejor. Utiliza evidencia, nombra las limitaciones y la incertidumbre, y culmina en acciones que pueden ser comprobadas.
Ahora, el análisis posterior. No se limiten a calificarlo. Pregunten:
- ¿Qué evidencias respaldaban y qué suponías?
- ¿Cuáles de tus acciones tendría realmente autoridad para realizar el equipo?
- ¿Qué facilitaría que repitieras este comportamiento en tu próxima reseña real? ¿Qué lo dificultaría?
La tercera pregunta es la más importante. Revela las condiciones de la sección 2. Si tres participantes dicen "mi jefe preguntará quién lo hizo", habrás encontrado una limitación que la capacitación no puede eliminar.
5. Medir el comportamiento y el seguimiento.
La pregunta clave es qué evidencia demostraría que los estudiantes pueden analizar la evidencia de incidentes y acordar mejoras comprobables. Aquí hay una rúbrica para comenzar. Se trata de una propuesta para adaptar con un ingeniero experimentado, no de un estándar de preparación validado.
| Criterio | Evidencia observable | 0 | 1 | 2 |
|---|---|---|---|---|
| Ejecución de tareas | Analiza la evidencia y acuerda mejoras; registra la acción y la evidencia que la respalda. | Ausente o sin respaldo | Parcial, con las omisiones pertinentes. | Completo y justificado según los criterios acordados. |
| Razonamiento | Explica las limitaciones, las alternativas y la incertidumbre; los factores contribuyentes van más allá de la última acción. | Ausente o sin respaldo | Parcial, con las omisiones pertinentes. | Completo y justificado |
| Límites | Utiliza los procedimientos aprobados; pide ayuda cuando falta información o autoridad. | Ausente o sin respaldo | Parcial, con las omisiones pertinentes. | Completo y justificado |
Defina los errores críticos por separado; por ejemplo, al señalar a una persona como la causa o al proponer una acción sin un responsable. Una puntuación total alta nunca debe ocultar un fallo crítico.
En cuanto a la medición en sí:
- Calidad del análisis de factores contribuyentes. Compara las reseñas escritas antes del programa con las escritas después, evaluadas según la misma rúbrica por alguien que desconozca cuál es cuál. Utiliza tanto casos reales como casos de seguimiento no vistos.
- Seguir adelante. Calcula el porcentaje de elementos de acción que tienen un responsable, una prueba y que se han completado, con respecto al total de elementos de acción planteados. Indica el denominador y el intervalo de tiempo.
- Relacione la observación con los cambios en el proceso. Participa en una revisión real. Comprueba qué sucedió después con los puntos de acción.
Tenga cuidado con el volumen de informes. Si se registran más preocupaciones e incidentes leves después del programa, esto podría significar que la seguridad ha mejorado, la confianza ha aumentado o que una nueva herramienta facilitó el registro. Una caída podría significar menos problemas o una menor disposición a hablar. Analice qué cambió en el mismo período antes de atribuir cualquier cambio a la capacitación y evite afirmar un tamaño del efecto que no haya medido.
Las directrices de Eberly mencionadas anteriormente establecen un marco de alineación; no constituyen una prueba de que este enfoque reduzca los incidentes. Mantenga sus propios datos de referencia y de seguimiento, y considérelos como evidencia local.
¿Qué limitaciones pueden persistir incluso después de que mejoren las habilidades?
Sé sincero con tus patrocinadores sobre estos aspectos:
- Los documentos de revisión aún pueden influir en las decisiones de desempeño.
- Los equipos que trabajan bajo presión para cumplir con los plazos de entrega pueden omitir acciones que, si bien son costosas, son sensatas.
- Las acciones entre equipos pueden estancarse porque nadie controla el límite.
- Es posible que los ingenieros sénior sigan dominando la discusión.
Un mejor análisis no elimina estos problemas. Planifique cambios de proceso específicos para cada uno de ellos.
Poniéndolo en práctica con AhaSlides
AhaSlides admite el aprendizaje adaptativo, el aprendizaje interactivo y la alternancia entre presentaciones en vivo y a ritmo propio. En este proceso, esto podría implicar una etapa de preparación a ritmo propio, una sesión de caso en vivo o facilitada con preguntas abiertas para que todos se comprometan con un análisis antes de la discusión grupal, y una tarea de seguimiento después de la sesión. Las funciones específicas de creación, puntuación e informes deben probarse en una demostración con su propio caso antes de utilizarlas, y cualquier elemento que involucre IA, simuladores o integraciones con sus herramientas de gestión de incidentes debe tratarse como externo hasta que se muestre.
Próximo paso: Toma la rúbrica anterior y adáptala con uno de tus ingenieros senior, luego construye el caso que usarás. Si deseas ver cómo podría funcionar una versión en vivo y a tu propio ritmo de este recorrido, Reserva una demostración del flujo de trabajo de AhaSlides. una vez que tenga el caso y la rúbrica redactados.
