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

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 tiques? 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 descarrilar.

Dado que los errores de producción, los incidentes y el tiempo de inactividad 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.

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 incidencias más ágil.

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 incidencia, 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. Puede que muchos ya estén notificando tiques por correo electrónico, mediante tuits o en formularios, 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 una incidencia 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 incidencias en nada menos que un 50 %.

Sin embargo, da igual qué herramienta estés utilizando para ofrecer a tus clientes el 4-1-1, la comunicación centrada en el individuo llega muy lejos. Hay gente de verdad al otro lado del problema que confía en ti y en tu servicio 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 queden quietecitos 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 y darles una estimación de cuándo volverá a estar en línea el servicio si dispones de esa información”.

Para este principio, tendremos en cuenta el valor de la metodología ágil "software funcionando sobre documentación extensiva".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 chuparse párrafos interminables de "paja" para saber qué es lo que ocurre y cuándo se espera que se solucione el problema. 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 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 (una media 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 intentando 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, consiguieron mandar el mensaje adecuado mientras se dedicaban principalmente a 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 incidencias con la página de estado como parte de tu proceso, podrás realizar pequeños ajustes para mejorarla.

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

No esperes hasta tu próxima incidencia 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:

• Aprende a personalizar tu página de estado
• Inspírate con estos excelentes ejemplos de diseño y personalización de páginas de estado

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 feedback propios, donde los clientes puedan expresar sus preocupaciones y alertarte ante cualquier problema que estén experimentando (con herramientas como Jira Service Management, Twitter, etc.). Las empresas de talla mundial entienden que los clientes esperan una respuesta a su feedback y quieren participar a la hora de realizar mejoras en tu producto y en tu proceso de respuesta ante incidencias. 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 sea 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, que está relacionado con la respuesta a los cambios...

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 una incidencia como después de que esta ocurra. La metodología ágil consiste en ser capaz de cambiar de rumbo sobre la marcha y en obtener feedback rápido y constante que mejore nuestro producto y nuestra cultura.

Wistia, una empresa de alojamiento de vídeos y analíticas 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 estado para facilitar sus vidas en situaciones como esta.Sin embargo, con la creación de su propia herramienta de comunicaciones de 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 asistencia en Wistia, ha descrito el movimiento: "Tras un par de meses de ligera frustración en torno a nuestra propia solución sin apenas funcionalidades pero útil, entendimos que necesitábamos algo más, algo que no requiriese demasiados cuidados. Entramos en 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 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 hechas en nuestra página de estado apuntan directamente a diversos lugares".

El equipo de Munson fue fiel al refrán: la vida les dio limones (la interrupción del servicio de 2013) y ellos hicieron 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 fue tan bien 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.

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.

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 empoderamiento. 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.