Metodología ágil para cuando las cosas van mal: la pieza que falta en tu plan de respuesta ante incidencias

Al adaptar los valores encontrados en el manifiesto ágil, puedes acabar con la respuesta ante incidentes y mejorar la confianza del usuario. 

 

Shannon Winter Shannon Winter
Browse topics

Las metodologías ágiles se utilizan cada vez más fuera del ámbito tradicional del desarrollo de software en todas las áreas empresariales, incluido el marketing. Así que pensamos, ¿qué aspecto tiene la metodología ágil en el mundo de la gestión de incidentes? En Atlassian, definimos la metodología ágil como un enfoque estructurado e iterativo de la gestión de proyectos y del desarrollo de productos. Da a tu equipo la capacidad de responder a los cambios sin desbordarse.

Dado que los errores de producción, los incidentes y las interrupciones del servicio pueden, sin lugar a dudas, clasificarse como momentos de "desbordamiento", pensamos que un plan como la metodología ágil (creada para ayudar a los equipos a no desbordarse) tendría un lugar natural en la gestión de incidentes; concretamente, en la comunicación de incidentes.

Aplicación de valores ágiles a la respuesta ante incidencias

Aunque no faltan herramientas que ayuden a tu equipo a detectar, alertar, tratar y resolver incidentes, las herramientas por sí solas no pueden reemplazar a una comunicación clara con las partes interesadas. Y, seamos realistas: los riesgos pueden ser altos. La reputación, el desgaste del cliente o el tiempo empleado en el control de daños, solo por nombrar algunos. Las metodologías ágiles pueden ayudar a minimizar esos riesgos. 

Muchos de vosotros estaréis ya familiarizados con los cuatro valores principales del manifiesto ágil: 1) prevalecen los individuos y las interacciones sobre los procesos y las herramientas; 2) prevalece el software funcional sobre la documentación global; 3) prevalece la colaboración del cliente sobre la negociación del contrato; y 4) prevalece dar respuesta a un cambio sobre el seguimiento de un plan. Indaguemos algo más en cada una de ellas y veamos cómo pueden aprovecharse para lograr una comunicación de incidentes más ágil.

Principio de la comunicación de incidencias: comunicación de incidencias centrada en los individuos

Este principio se basa en el valor de la metodología ágil, individuos e interacciones sobre procesos y herramientas. Los procesos y las herramientas son importantes para cualquier proceso de gestión de incidentes, pero no significan nada si se ven separados de las personas que intentan utilizarlos y de la cultura que se ha formado a su alrededor. ¿Cuál es el pegamento que consigue unir a las personas, los procesos y las herramientas? La comunicación, ¡por supuesto! 

La comunicación es fundamental cuando surge una incidencia, ya sea un error pequeño de producción o un fallo general del sistema. Incluso el plan de incidentes más completo requiere que exista una comunicación frecuente con el fin de alcanzar una solución y de mantener la confianza. 

Durante una incidente, es más probable que los usuarios afectados experimenten errores frustrantes —e incluso francamente debilitantes— y que necesiten saber qué es lo que ocurre lo antes posible. Muchos ya estarán enviando correos electrónicos, escribiendo tuits o rellenando tickets sobre la incidencia, así que, por el bien de todos, es mejor que te enfrentes a la situación rápidamente con un mensaje que demuestre que eres consciente de que algo anda mal y que estás buscando una solución. En Atlassian, utilizamos Statuspage para informar a las partes interesadas tanto internas como externas acerca de una interrupción del servicio. Además, creemos que también podrías identificar rápidamente el valor al tratar de transmitir información sobre un incidente a tus usuarios de una forma rápida y escalable. De hecho, Statuspage ha ayudado a los usuarios a aumentar la velocidad con la que comunican sus incidentes en nada menos que un enorme 50 %.

¿Quieres darle una oportunidad?

Regístrate o inicia sesión en Statuspage >>  

 

Una vez dentro, obtén más información sobre las prácticas recomendadas para suscribir a tus usuarios finales y comunicar de manera eficaz durante un incidente:

 

Sin embargo, da igual qué herramienta estés utilizando para informar a tus clientes, la comunicación centrada en el individuo llega muy lejos. Hay gente de carne y hueso al otro lado del problema que confía en ti y en tu servicio de soporte para mantenerles al tanto cuando algo no vaya bien. Aunque las plantillas son estupendas en un mundo perfecto, necesitarás a gente que pueda crear mensajes claros, concisos, empáticos y pertinentes para fomentar la confianza de los clientes incluso en los peores momentos. Tomemos como ejemplo Dyn. Sufrieron una tremenda interrupción del servicio durante uno de los mayores ataques DDoS de la historia, pero aun así los usuarios les agradecieron la sinceridad que mostraron durante esas horas de corte:

Como dijo Werner Vogels, director de tecnología de AWS, al hablar del gran apagón de AWS S3 en febrero de 2017:

"A los clientes no les gusta que les digan que se sienten tranquilos y que no hagan nada. No, no es eso lo que quieren. Por eso, tienes que darles información muy buena, hacerles entender lo que está pasando, darles una estimación de cuándo volverá a estar en línea el servicio si dispones de esa información".

Principio de comunicación de incidencias: Creación de páginas sin obstáculos y actualizaciones de incidencias

Para este principio, tendremos en cuenta el valor de la metodología ágil, prevalece el software funcional sobre la documentación global. La documentación de tu producto debe ser clara e intuitiva, y creemos que las actualizaciones de incidentes también deben serlo. Los usuarios no deberían tener que leer entre líneas (ni ojear largos párrafos) para saber qué es lo que ocurre y cuándo se espera que se solucione. Si bien necesitas pensar en tus actualizaciones de incidentes y asegurarte de ser empático y humano en tus comunicaciones, no debes permitir que las entradas de aprobaciones o las múltiples revisiones se interpongan en el camino de tus actualizaciones frecuentes y honestas. 

Repasando el incidente de Dyn, puedes ver que el equipo no perdió el tiempo a la hora de informar de las actualizaciones a sus usuarios. En el transcurso de las más de 11 horas de incidente, actualizaron su página de estado 11 veces (un promedio de 61 minutos entre cada actualización). Su página de estado les permitió contar con un único lugar desde el que informar acerca del incidente, en lugar de perder el tiempo tratando de encontrar las listas de correo para enviar un mensaje o pensar cómo ajustar las actualizaciones a los 140 caracteres de Twitter. En otras palabras, enviaron el mensaje mientras aún trataban principalmente de reactivar el servicio. 

La belleza de una herramienta de comunicación de estado lista para usar es que no tienes que dedicar mucho tiempo a crear y poner en marcha una página sólida. En menos de 30 minutos, podrás crear una página de estado y, como en la metodología ágil, tu página de estado puede y debe ser iterativa. Piensa en cómo poner en marcha una página de trabajo para los clientes y, después, mejórala sobre la marcha. Después de que hayas sufrido un par de incidentes con la página de estado como parte de tu proceso, podrás realizar pequeños ajustes para mejorarla.

¿Estás listo para crear tu propia página de estado? Regístrate o inicia sesión en Statuspage >>

No esperes hasta tu próximo incidente para crear una página de estado. Échale unos minutos ahora para estar tranquilo cuando se produzca una interrupción del servicio. Recuerda que no tienes que dedicar demasiado tiempo a configurar una página para que haga el trabajo:

Principio de comunicación de incidencias: Comunicación transparente durante las incidencias y más allá

Este valor de la metodología ágil, según el cual prevalece la colaboración del cliente sobre la negociación del contrato, tiene que ver con el trabajo que realizas con los clientes para ofrecerles el mejor producto y la mejor experiencia posibles. Para nosotros, esto significa contar con canales de comentarios propios, donde los clientes puedan expresar sus preocupaciones y alertarte ante cualquier problema que estén experimentando (con herramientas como Jira Service Desk, Twitter, etc.). Las empresas de talla mundial entienden que los clientes esperan una respuesta a su comentario y quieren participar a la hora de realizar mejoras en tu producto y en tu proceso de respuesta ante incidentes. Con un poco de empatía y una buena explicación, llegas muy lejos (y los clientes no son tímidos a la hora de pedirlo). Así lo demuestran estos tuits:

Esto también significa mantener la transparencia en torno al tiempo de actividad para que los usuarios sepan exactamente lo que reciben al registrarse. Cuando te registras para un servicio en la nube, confías en que dicho servicio es fiable. No siempre existe un contrato físico, sino un contrato inherente negociado entre el cliente y el proveedor del servicio según el cual, si las cosas van mal, las dos partes se comprometen a colaborar para solucionar el problema rápidamente y a que se mantenga a todo el mundo informado desde la investigación hasta la resolución de dicho problema. Esto nos lleva a nuestro valor final relacionado con la prevalencia de dar una respuesta al cambio... 

Principio de comunicación de incidencias: Retrospectivas ágiles

Pero incluso el mejor de los planes... en fin, ya conoces el resto. En relación con el último de los principios del valor de la metodología ágil (prevalece dar respuesta a un cambio sobre el seguimiento de un plan), sabemos que incluso los planes mejor diseñados tendrán que, inevitablemente, someterse a cambios tanto durante un incidente como después de que este ocurra. La metodología ágil consiste en ser capaz de cambiar de rumbo sobre la marcha y en obtener comentarios rápidos y constantes que mejoren nuestro producto y nuestra cultura.

Wistia, una empresa de alojamiento de analítica y vídeo en Internet, descubrió la importancia de seguir siendo ágiles durante un incidente inesperado en el año 2013 que dejó su infraestructura de estadísticas totalmente paralizada. No estaban preparados, lo que les dejó desbordados con los tickets de soporte de clientes insatisfechos. Su primer giro fue crear su propia página de estados para facilitar sus vidas en situaciones como esta. Sin embargo, con la creación de su propia herramienta de comunicaciones del estado, soportaban entonces un nuevo producto además de su producto principal. Quedó claro que este era un coste que su equipo de 20 personas no podía asumir en ese momento. El segundo giro fue renunciar a su propia solución y pasarse a Statuspage. 

Jordan Munson, ingeniero de soporte en Wistia describió el cambio: "Tras un par de meses de ligera frustración en torno a nuestra propia solución sin apenas funciones pero útil, entendimos que necesitábamos algo más, algo que no requiriese demasiados cuidados. Descubrimos Statuspage. Desde que nos pasamos a Statuspage, hemos podido hacer lo que pretendíamos, manteniendo a los clientes al día del estado de nuestra aplicación de una forma rápida y sencilla. Solo necesitamos un apagón generalizado y la creación de un nuevo producto para conseguirlo. Hemos avanzado un par de años hacia los tiempos modernos y nuestro proceso parece mucho más fluido. Cuando se produce una interrupción del servicio, las personas afectadas reciben directamente de nosotros información actualizada. Además, saben dónde buscar las actualizaciones, y las actualizaciones de nuestra página de estado se envían directamente a diversos lugares".

El equipo de Munson recogió limones (la interrupción del servicio de 2013) e hizo limonada (un proceso de comunicación de incidentes nuevo, mejorado y escalable). Esta es una respuesta ágil al cambio en su máxima expresión. 

Las retrospectivas son también una parte fundamental de este valor de la metodología ágil. Una retrospectiva concede a tu equipo la posibilidad de distanciarse y debatir lo que funcionó bien durante la comunicación de incidentes, lo que no lo hizo tanto y, lo que es más importante, lo que hay que hacer para evitar que se repitan los mismos errores. No, no cedas a la tentación de saltarte una retrospectiva después de que se haya marcado un incidente como "resuelto" o si crees que tu equipo actuó bien. Siempre hay margen de mejora en lo que respecta a la comunicación de incidentes y siempre hay una oportunidad para desarrollar una mejor relación y una mayor confianza con los usuarios. 

Consejo de experto:

Pon en práctica este juego de retrospectivas del Manual de estrategias para equipos de Atlassian para ofrecer a tu equipo un espacio seguro en el que puedan reflexionar y debatir sobre lo que funciona (y lo que no) para poder mejorar.

Al volver a consultar nuestro manifiesto ágil, las retrospectivas, sin duda, requieren una comunicación centrada en los individuos para tener éxito y producir resultados duraderos. Echa un vistazo abajo a algún vocabulario que puedes tener en cuenta al debatir cómo fue la resolución de un incidente en una reunión retrospectiva. Parte de este vocabulario también debería llevarse a la revisión retrospectiva o a la revisión tras incidentes (PIR) que envías a los usuarios una vez restaurado el servicio. Adoptar una metodología ágil significa mejorar de forma continua, no solo en cómo se ejecutan las tareas relacionadas con incidentes, sino también en cómo te relacionas con tus compañero de equipo y llevas a cabo tu función durante una situación de estrés. 

Lenguaje de las personas

Lenguaje del producto

Suposiciones, expectativas y miedos

Tareas, incidencias y acciones

Motivaciones, equivocaciones y comportamientos

Sprints, epics, historias y publicaciones

Preferencias, relaciones y respeto

Hitos, dependencias y fechas

Roles y responsabilidades

Reuniones, calendarios, correos electrónicos y archivos

No te olvides de la confianza

En la metodología ágil, hablamos mucho de la confianza y no va a ser de otra forma para este caso de uso. Una comunicación de incidentes eficaz requiere confianza y capacitación. Los equipos de la organización deberían sentir que tienen la aprobación y los conocimientos necesarios exigidos para informar a los usuarios acerca de los incidentes. Los individuos también deberían ser capaces de confiar en que todo el mundo cumplirá con la labor que les ha sido asignada durante una respuesta ante incidentes y no dudarán en intervenir e interrumpir el proceso cuando ocurran imprevistos. Confiar en los equipos para informar de forma eficaz acerca de los incidentes permitirá a los clientes estar al corriente de la situación más rápidamente y, a su vez, aumentará la confianza del usuario y la fidelidad de este a tu servicio (el 67 % de los clientes de Statuspage afirma que esta plataforma les ha ayudado a aumentar la confianza de sus usuarios). Una auténtica ventaja para todos. 

A continuación
Continuous integration