No vale la pena arreglar cada bug

En los primeras días de Savy, dónde aún estábamos construyendo lo que sería el equipo de tecnología y yo aún escribía la mayoría del código, tomé una posición un tanto agresiva en contra de arreglar bugs. Cada vez que uno de mis socios se acercaba a mencionarme sobre algún nuevo error y si podría darle una mirada rápido y arreglarlo, mi respuesta por defecto era no.

Acto seguido, la conversación tomaría el siguiente curso:

¿Cómo así que no lo vas a arreglar? un usuario acaba de enviarme esta captura de pantalla del error ¡debemos arreglarlo antes que le suceda a alguien más!
¿Por qué? respondía yo, sólo le ha ocurrido a esta persona por ahora. Esperemos a verificar que le ocurra a alguien más, o incluso a varias personas. De ahí podemos decidir si vale la pena el esfuerzo de arreglarlo.

Podría afirmar que el 90% de las veces no era urgente. No es que el bug se hubiera desaparecido, por su puesto, simplemente no era tan grave para que tuviera que atenderlo en ese preciso momento.

Como co-fundador estaba en una posición privilegiada para decir no y desafiar la expectativa de arreglar bugs tan pronto como fuera posible. Pero a medida que el equipo fue creciendo, quise extenderles a ellos el mismo poder. Por defecto, los bugs no serían considerados una emergencia. En mi opinión, esa política nos permitió mantenernos enfocados en proyectos grandes y ambiciosos, así eso significara que los bugs iban a tener que esperar un poco en ser arreglados, si es que lograban convertirse en bugs dignos de arreglarse.

En mi experiencia previa en la industria de software, los bugs siempre eran tratados como emergencias. La realidad es que son pocos los que merecen algún tipo acción inmediata. En mi opinión, hay dos argumentos para soportar esta afirmación. El primero es el costo de arreglar bugs es alto, mucho más alto de lo que parece a primera vista. El segundo, es que la mayoría de las veces los bugs no son tan graves.

Bug: una palabra incomprendida #

Cuándo desarrollamos un producto digital van a existir bugs. Esto es algo natural de todo software. No obstante, hemos creado expectativas irreales en cuanto a la calidad del mismo. Como consumidores, actuamos con soberbia cada vez que encontramos un error en una aplicación. Y como miembros de la industria, como si cada error fuera un escándalo que debe ser arreglado tan pronto como sea posible, sino antes.

¿Cómo definir un bug? El problema de esta definición es que no creo que exista una única respuesta y, lo que es peor, el significado seguramente cambia según el rol que desempeñas, por lo que la misma definición no aplica para desarrolladores, analistas de calidad o gerentes de proyecto. En mi opinión, este malentendido viene de la tendencia actual de la industria de crear silos especializados de habilidades técnicas en lugar de tener grupos multidisciplinarios responsables por producto o funcionalidad de este. Es difícil a nivel organizacional ponerse de acuerdo en la severidad de un bug y discutir las ven tajas y desventajas de arreglarlo si cada equipo tiene una definición diferente en mente y, peor aún, métricas de éxito diferentes que no se alineen con el alcance del proyecto.

Si estás en proceso de construir un nuevo producto seguramente estás desarrollando nuevos features para completar la visión del producto, probando algunas nuevas ideas para validar la viabilidad del mercado. Esto significa que estás escribiendo más código y, por lo tanto, creando nuevos bugs. ¡Y eso no tiene ningún problema! todo lo contrario, es parte del proceso. No tiene ningún sentido pulir una aplicación a la perfección si aún no has validado que existe un mercado para esta. Lo que importa es que estés progresando en el desarrollo del producto y resolviendo las necesidades de tus usuarios. Pero nadie en el equipo debería estar pasando noches en vela intentando mantener limpio un creciente backlog de errores.

Sí, seguramente llegará una situación en la que un bug terrible aparece y un flujo importante de la aplicación se ve afectado, lo que será una verdadera emergencia de código rojo y todo el mundo tendrá que poner las manos a la obra en solucionarlo. Pero estas situaciones son la excepción no la regla. No puedes permitir que cada vez que un usuario se encuentra con un error en la aplicación el equipo entre en modo de pánico.

En resumen, no todos los bugs son iguales. Algunos aparecen en circunstancias muy específicas o a una pequeña cantidad de usuarios. Otros viven en algunos flujos de aplicación poco frecuentados o en funcionalidades de poco impacto. Así que en vez de correr a arreglarlos, es mejor esperar. Revisar los dashboards y los datos de usabilidad. Lo más posible es que la mayoría de los usuarios estén cumpliendo con su objetivo sin ningún problema.

El verdadero costo de arreglar un bug #

En general, existe una tendencia de subestimar el costo de las interrupciones y el cambio de contexto. Esto aplica para reuniones, llamadas, mensajes directos y, por su puesto, reportes de bugs. Hagamos el ejercicio de reflexionar cuánto tiempo tardas en reunir el contexto y la concentración cuando estás trabajando en una tarea que requiera de mucho enfoque. Por ejemplo, escribir un email sensible, codificar o diseñar una interfaz de usuario. Para muchas personas apostaría que toma al menos 30 minutos reunir el contexto necesario de la tarea y retomar donde habías quedado la última vez más otros 30 minutos para entrar en estado de flujo y empezar a progresar. Si a la hora que empiezas a ser productivo, alguien te toca el hombro (sea físicamente o por slack) y te pide que le pongas atención a otra cosa, esa torre de naipes en la mente y el tiempo que tomó construirla no generó ningún avance al final del día. La próxima vez que te sientes que en problema, tendrás que empezar de nuevo. Imagínate que esto suceda dos veces o más a la semana y de repente no te sorprenderías tanto que tu o tu equipo sientan que están constantemente atrasados en sus proyectos.

¿Por qué deberían los bugs saltarse al frente de la cola? Si invertimos una cantidad considerable de tiempo en planear nuestros proyectos, en priorizar las tareas y establecer objetivos ambiciosos, ¿por qué tirarlo todo por la ventana cuando se trata de un bug? ¿Qué los hace más importantes que las otras tareas que están en la lista de prioridades? Al final del día, también son trabajo que va a consumir horas de la persona que los realice. Como tal, deberían ponerse en la balanza con las demás tareas y decidir si, efectivamente, tienen la importancia necesaria en lugar de saltar inmediatamente al frente.

Los bugs pueden conducir a agujeros de conejo. Muchas veces la causa de un bug no es fácil ni obvia de encontrar, mucho menos la mejor forma de arreglarlo en caliente. Incluso una vez identificado el problema, puede que no exista una solución fácil para el mismo. Es importante tener esto en cuenta para la próxima vez que sientas el impulso de perseguir un bug. Como mínimo, recomendaría tener una cota de tiempo estricta para hacer el diagnóstico.

El problema es cultural, no técnico #

Cuando se trata de tener buenas dinámicas de equipo y cultura organizacional no existe una receta maestra. En mi opinión, cada equipo debería evaluar distintas metodologías y ajustarlas según lo que mejor funcione. En consecuencia, muchos de los aprendizajes de este artículo están derivados de mis propias experiencias y experimentos en compañías tipo start up y seguramente es en donde tendría más sentido aplicarlas. Sin embargo, me at revería a decir que estas lecciones aplican a equipos de ingeniería en cualquier contexto. Si el objetivo es lograr que los equipos sean productivos y logren los resultados esperados a tiempo, deben ser capaces de ejecutar sus tareas sin tener distracciones constantes. Un equipo que está trabajando en problemas retadores y progresando en su misión, seguramente se mantendrá motivado.

Tener una cultura donde cada bug tiene un temporizador encima para ser resuelto en el menor tiempo posible, impacta negativamente la productividad de un equipo y con el tiempo erosiona la cultura organizacional. Exploremos algunas razones del porqué:

Crea expectativas irreales para los equipos de tecnología. En un principio parecerá que no hay mayor problema en lidiar con los errores a medida que van apareciendo. Cuándo una aplicación es relativamente pequeña y aún cabe en la cabeza de una sola persona seguramente será una tarea sencilla y directa. El problema es que no siempre va a ser así y ahora hay un precedente de inmediatez bastante peligroso. A medida que el código aumenta en complejidad e interdependencias, esas pequeñas tareas que tomaban unos pocos minutos se convertirán en tareas de unas cuantas horas. Sin embargo las expectativas de inmediatez y velocidad para el equipo seguirán igual. La mejor forma de prevenir esta situación, es con un no comprensivo, pero firme ante cualquier trabajo con la etiqueta de ahora mismo. Después de un tiempo, te darás cuenta que la mayoría de las veces no era tan urgente en primer lugar.

Incentiva malas prácticas de comunicación. Así como los bugs tienen una tendencia a saltarse la cola de prioridades también tienden a saltarse los protocolos de comunicación. Como líder de equipo, más de una vez me encontré con personas trabajando en bugs porque un líder de otra área se los pidió. Los fundadores tienden a ser particularmente culpables de esta práctica. O tal vez alguien en servicio al cliente les pidió el favor de revisar un problema rápidamente. Personalmente, no me considero alguien que abogue por implementar procesos sobre buena comunicación y sentido común, pero he visto como este tipo de prácticas se salen de control hasta convertirse en un problema. Recuerdo un ejemplo de alguien que se estaba sobrecargando de trabajo porque era demasiado cortés para decir que no ante estas solicitudes. No estoy diciendo que no se deban reportar bugs, al contrario, incentivaría a todas las áreas de una compañía a tomarse el tiempo de hacerlo apropiadamente. Pero dejemos atrás la expectativa que un reporte significa asignarle esa tarea a alguien y ponerle una fecha límite encima. Los reportes serán atendidos a su debido momento el cual, reitero, no es ahora mismo.

Es desmoralizante para el equipo. Consideremos por un minuto la ansiedad que produce tener notificaciones y recordatorios cada vez que aparece un nuevo bug en producción. De por sí en el mundo laboral actual ya estamos sufriendo los efectos psicológicos negativos de tener un flujo constante de notificaciones vía correo o aplicaciones de mensajería instantánea. Agregar bugs a esto puede inducir a sentimientos de culpa e incluso de depresión. Estas notificaciones pueden llegar a ser tan abrumadoras en volumen que algunos equipos terminan ignorándolas del todo. El ratio de señal a ruido es demasiado bajo. Incluso si el equipo aún está logrando controlar este flujo de notificaciones, a menos que existan personas dedicadas exclusivamente a esa tarea, seguramente los está atrasando considerablemente en su día a día. Y en ese caso, la pregunta es ¿por cuánto tiempo podrán sostener ese ritmo? Al final del día, no es una estrategia sostenible al mediano plazo y empezarán a quedarse cortos en sus entregas. Existe una correlación fuerte entre la moral de un equipo y su capacidad de cumplir con sus entregas. Si el balance se rompe en algún momento, empieza un espiral negativo que termina en un equipo descontento y poco motivado.

¿Como garantizar calidad entonces? #

En este punto espero haberte convencido que manejar bugs como una emergencia que debe ser atendida tan pronto como sea posible es una mala idea. Decir que no a los bugs le devolverá a tu equipo la libertad de enfocarse en resolver los retos que aparezcan durante el ciclo de desarrollo y entregar valor a los usuarios, sin embargo debemos lidiar con ellos en algún momento. Los puntos que resalté anteriormente no son una excusa para ignorarlos para siempre, sin embargo creo que existe una forma más sostenible e inteligente de lidiar con ellos.

Guardias técnicas #

Las guardias técnicas son herramientas de tecnología que nos permiten prevenir errores, ayudarnos a tomar decisiones y detectar emergencias oportunamente. Tener la seguridad que los flujos más importantes de una aplicación están funcionando para la mayoría de los usuarios evitará una respuesta de pánico y nos dará argumentos para priorizar efectivamente.

Implementa pruebas de integración para los flujos más importantes. Si tuviera que escoger sólo una estrategia para implementar de las que voy a describir a continuación, sería esta. Es una inversión que tendrá un retorno de diez veces fácilmente. Las pruebas de integración (o end to end) no son fáciles ni de implementar ni de mantener. Pero tener la confianza de desplegar aplicaciones a producción sin miedo vale la pena y se convertirá en la última línea de defensa para prevenir que un error llegue a las manos de un usuario. Puede que esto suene obvio, pero la prevención es la forma más rápida y efectiva de lidiar con bugs.
Instala herramientas de monitoreo en el ambiente de producción. Hay múltiples herramientas que permiten ver el estado de una aplicación en producción desde la infraestructura, errores, tiempos de respuesta, entre otros. Cada uno de estos tiene su propia utilidad por lo que depende de cada equipo decidir cuáles adoptar. Lo importante, sin embargo, es no obsesionarse con cada métrica o reporte de error, sino mantener la mirada en el panorama general de las cosas y conocer el comportamiento de la aplicación en condiciones normales para poder identificar cuando algo extraordinario suceda. Adicionalmente, ahora contarás con datos históricos para tomar decisiones. Las herramientas de monitoreo de excepciones, por ejemplo, cuentan el número de usuarios e instancias que un error se ha presentado. Esta información es muy valiosa cuando se trata de decidir si se debe actuar inmediatamente o se puede esperar unos cuantos días.
Programa alertas automáticas para emergencias previsibles. Generalmente son fáciles de configurar y tienen un propósito doble. Por un lado, una simple notificación puede ayudar a prevenir una futura emergencia, como un servidor llegando al límite de su capacidad. Por otro, aseguran que haya una reacción oportuna por parte del equipo cuando se presente una emergencia y sean los primeros en enterarse. Esto fomentará una sensación de confianza entre las distintas áreas de negocio de la compañía y le dará espacio al equipo para resolver la situación sin presiones innecesarias.

Procesos organizacionales #

Las siguientes prácticas no son particulares a tecnología sino a los procesos internos de una empresa de cómo organizamos el trabajo y qué expectativas se imponen a los equipos. Se trata de establecer las líneas de comunicación apropiadas y definir las expectativas correctas en las distintas áreas de la compañía.

These points deal with working effectively as an organization, and setting up clear boundaries and expectations between the different stake holders.

Define qué es una emergencia y cómo será manejada. Como dije anteriormente, 95% de las veces un bug no debería desviar tu atención de tu tarea actual. Pero igual, está el otro 5% restante. ¿Cuáles errores conforman exactamente ese 5% en tu producto? Si hacemos una definición proactiva y preliminar de qué aspectos de la aplicación son críticos y serán tratados como una emergencia en caso de que fallen habremos reducido la incertidumbre de todas las personas en la compañía. Los equipos de tecnología no se verán afectados en su día a día cuando no se trate de una emergencia y las áreas directivas tendrán la seguridad de que, cuando algo salga mal, hay un plan de acción.
Tomar un respiro después de los despliegues. En el fondo, culpo los ciclos de dos semanas popularizados por Scrum de tener que mencionar este punto. Son tan pequeños que a duras penas se logra hacer algo significativo, sin embargo existe la promesa de desplegar al final. Y de inmediato, en la semana tres hay que estar empezando el nuevo sprint sin nada de tiempo entre medio. Personalmente, considero que es mucho más saludable tener ciclos más largos de 4 o 6 semanas y dejar una o dos de respiro sin tareas programadas. Este es un buen tiempo para coordinar un despliegue, revisar feedback inmediato y posibles bugs que se escaparon en la etapa de calidad, o otros pendientes que el equipo quiera solucionar.
Tener ciclos exclusivos para trabajar deuda técnica. Me alegra ver que esta práctica ha ido aumentando en popularidad dada su efectividad. Después de unos cuantos ciclos de desarrollo de nuevos features, que suelen ser intensos, los equipos generalmente agradecen un ciclo para trabajar en bugs o deuda técnica que hayan identificado en ciclos anteriores. Además sirven para romper un poco la monotonía, cambiar el paso y tienen el beneficio de recortar considerablemente los backlogs de vez en cuando.
Asciende bugs a proyectos. Esta es una continuación de la idea que los bugs no son intrínsecamente distintos a otras tareas que hay en la lista des espera. Algunos bugs son síntomas de problemas mucho más grandes en una aplicación, como alguna mala decisión arquitectural del pasado o un servicio externo que no está funcionando correctamente. Este tipo de tareas no deberían realizarse como parte de un ticket, sino convertirse en sus propios proyectos y ponerse en la mesa de toma de decisiones junto con los demás proyectos para considerar su prioridad y las ventajas o desventajas de invertir tiempo en arreglarlo.

Comentarios finales #

La intención de este post es reflexionar sobre la forma en la que vemos los bugs y las distintas estrategias que usamos para lidiar con ellos. Al final el objetivo de un equipo es construir grandes productos que nuestros usuarios amen y les resuelvan problemas reales. Si tu equipo está logrando esa misión con éxito usando otras técnicas, ¡felicitaciones! continúa haciendo lo que te está funcionando. Pero si sientes que no estás progresando, que semana tras semana lo único que haces es arreglar bugs y que el producto no progresa, entonces considera algunos de los puntos y estrategias descritos acá. De pronto la forma en la que estás manejando los bugs está frenando a tu equipo. En ese caso, la próxima vez que recibas un reporte de un error en lugar de decir dame 15 minutos y lo miro, podrías responder esperemos un rato, Asegurémonos que vale la pena arreglar este bug.

Agradecimientos #

Gracias a mi incondicional amigo Felipe por ser siempre mi primer lector y crítico y a mi hermano David por su disposición y feedback oportuno. Sin la ayuda de ellos, mis pensamientos incoherentes difícilmente llegarían a convertirse en un artículo completo.