Se necesita un tiempo para responder y resolver incidentes. Pero los equipos implicados en la respuesta a incidentes a menudo trabajan en silos: los SRE y los desarrolladores tienen dificultades para solucionar el problema, el soporte está inundado de correos electrónicos / tickets, y el marketing / PR puede estar apagando incendios en X.
Incluso si hay alguna comunicación que ocurre en el chat o en los escritorios, generalmente hay margen de mejora para que estos equipos trabajen juntos cuando más les importa.
Cuando las cosas arden, lo último que se le ocurre es cómo mejorar la comunicación y la colaboración internas. E incluso después de la resolución, las tareas son bastante dispares.
Los equipos técnicos pueden sentarse para una revisión posterior al incidente, el soporte puede mirar hacia atrás en las respuestas al ticket, pero rara vez se unen para evaluar cómo lo hicieron como un equipo completo de respuesta a incidentes y cómo pueden mejorar la próxima vez. Es por eso que es muy importante reservar tiempo cuando las cosas marchan bien para abrir un diálogo entre los equipos y mejorar antes de que ocurra el siguiente incidente.
Hemos descubierto de primera mano lo útil que es reunir a los equipos técnicos y no técnicos antes, durante y después de una respuesta a un incidente. Permanecer en el silo significa cables cruzados, mensajes mezclados y sentimientos heridos.
De repente, tienes dos incidentes: el problema original y el caos interno que sigue. Eche un vistazo a lo que aprendimos reuniendo a los equipos de Atlassian, luego vea nuestros consejos principales y los talleres que creamos para ayudar a los equipos de su empresa a unirse para una mejor respuesta a los incidentes.
Ventajas de unir equipos técnicos y no técnicos durante la respuesta al incidente
Aprender de diversas experiencias y perspectivas
Reunir a los equipos para conversaciones que de otro modo no se producirían les permite aprender de los éxitos y los errores de los demás. No es necesario reinventar la rueda de respuesta al incidente si la gente ya ha establecido las mejores prácticas basadas en experiencias previas.
Descubra las lagunas en el proceso de respuesta al incidente antes de que afecten a los usuarios: Diferentes equipos a menudo se ocupan de diferentes partes de la respuesta al incidente. Al conectar los puntos antes de que ocurra un incidente, puede descubrir agujeros en el proceso antes de que afecten a los usuarios.
Por ejemplo, uno de nuestros equipos de soporte descubrió que un mensaje de error dentro del producto apuntaba a los usuarios a una página sin salida (en lugar de una página de estado con más información), solo después de chatear con el equipo de SRE que ayudó a resolver el error ocurriendo. Un simple intercambio de enlaces significó menos clientes frustrados y menos tickets de soporte durante el próximo incidente.
Comuníquese de forma más clara y genere confianza con los clientes
Cuando los equipos trabajan en silos, las actualizaciones de los clientes a menudo también se realizan en silos. Pero lo último que desea darles a los clientes frustrados son las actualizaciones mixtas / confusas. Los equipos que trabajan juntos para crear un plan de comunicación de incidentes pueden permanecer en el mensaje para proporcionar a los clientes actualizaciones consistentes. Mientras mejores sean las comunicaciones, mayor será la confianza y lealtad del cliente que construirá.
Desarrolle empatía con otros equipos
Es fácil pensar que su equipo lo tiene difícil cuando está en las trincheras día tras día. Al aprender sobre las luchas y los éxitos de otros equipos, generará empatía y respeto que se traducirá en una mayor transparencia de la confianza en toda la empresa.
Cree roles de incidentes bien definidos / documentados
Tener una clara identificación de propiedad antes de un incidente ayudará a garantizar que los equipos técnicos y no técnicos manejen de manera eficiente las cosas.
Invite a personas no técnicas a sus revisiones post-mortem / post-incidente
Cualquier persona que desempeñó un papel en la respuesta a incidentes (respondiendo tickets de soporte, twitteando a clientes, resolviendo el incidente, etc.) debe ser parte de su revisión. Tener la imagen completa es importante cuando se trata de aprender y mejorar. Si hubo muchas comunicaciones durante el incidente, considere realizar una revisión de las comunicaciones además de una revisión posterior al incidente.
Sea consciente de la jerga específica del equipo
Trate de evitar los acrónimos u otros lenguajes matizados que pueden ser confusos o desalentadores para los equipos nuevos en su dominio.
Alinearse con lo que más importa durante la respuesta al incidente: es clave tener un conjunto de valores mutuamente acordados para ayudar a guiar la toma de decisiones durante un incidente. Un conjunto de valores de incidentes compartidos ayuda a mantener la eficiencia y la coherencia en situaciones más subjetivas.
¿Trabajamos juntos? ¡Contáctanos ahora!
Fuente: Atlassian
