¿Cómo priorizo un bug? ¿Lo cuelo en este sprint? ¿Le damos patada y lo dejamos en el backlog a ver si se soluciona sólo? A mi no me mires, pregúntale al bug ;)
Como siempre, empezamos por el principio, ¿qué es un bug? Es un bicho, una incidencia, un error que provoca que nuestro producto funcione de forma defectuosa, inesperada o deficiente.
El término bug viene del siglo pasado, cuando los bichos se colaban en los servidores o en las máquinas y acababan provocando cortocircuitos, incendios, apagones, etc.
Antes de adentrarnos en el maravilloso mundo de la entomología digital debemos aceptar que nuestros productos tienen o van a tener bugs. Cuanto antes lo aceptemos mejor será nuestra vida liderando productos.
Recordemos que aceptar no significa resignación, aceptar es comprender y accionar en consecuencia, es movimiento. La resignación es parálisis, es rumiación, son chupitos de cianuro que nos tomamos por no llegar a comprender y avanzar hacia la aceptación.
También debemos aceptar que dichos bugs van a convivir en nuestros backlogs con el resto de iniciativas y trabajos, de forma que será necesario hacerles un hueco e invitarlos a unirse a la fiesta.
Podemos diferenciar tres tipos de bugs: pre-producción, funcionales y producción.
Fórmate con profesionales top en el Curso de Product Manager de Thiga Academy
Bugs de pre-producción
Los que nos encontramos en los entornos de pre-producción son los más sencillos de solucionar. Surgen en demos con el equipo de desarrollo durante el sprint, haciendo pruebas en local o de integración en "pre". La sangre no ha llegado al río y nuestros procesos de revisión y pruebas dan sus frutos. Detectarlos en este punto del ciclo de desarrollo es esencial para evitar situaciones desagradables con nuestros usuarios y clientes.
Una vez detectado en entornos previos a producción, si tenemos tiempo antes de finalizar el sprint, si esa iniciativa o trabajo no está comprometido y solucionarlo no genera un sobreesfuerzo para el equipo podemos atacar y dejarlo solucionado.
En caso contrario, es decir, estamos al final del sprint, tenemos compromisos que pueden acabar generando cambios de alcance y frustración en nuestros stakeholders, o la solución propuesta se estima como un sobreesfuerzo para el equipo, entonces podemos llevarlo al siguiente sprint. Este movimiento nos dará un cierto margen para incluir esta solución en nuestros procesos de refinamiento.
Bugs funcionales
Cuando nos encontramos con bugs funcionales lo mejor es no llamarlos bugs. No son exactamente incidencias sino que más bien se trata de indefiniciones, casos de uso no contemplados, refinamientos superficiales, una aproximación ineficiente al problema o a la solución que nos lleva a una recogida de necesidades de baja calidad, en definitiva, un error en el proceso de generación de la solución.
En esta ocasión, la solución es sacar esta iniciativa o trabajo de nuestro sprint, llevar este trabajo a nuestro laboratorio, profundizar en el problema y refinar con más detalle la solución.
Bugs en producción
En el caso de los bugs en producción... Aquí está la magia, es donde esto se pone interesante. Veamos el proceso:
- 1. Detección: lo más importante en esta parte del proceso es documentar el escenario donde se ha detectado el bug para poder replicarlo, debuggear e investigar donde está el problema. Esta documentación debe recoger todos los datos posibles sobre el escenario que ha detonado el bug: datos de usuario, pantallas, flujos, acciones o eventos que se estaban produciendo, transacciones de BBDD, etc.
- 2. Priorización: en base a toda la información recopilada se llega a una conclusión sobre cuándo es el mejor momento para abordarlo. Después veremos una propuesta de herramienta que a mí me ha servido en vidas pasadas.
- 3. Resolución: el equipo de desarrollo recoge el testigo, discute/propone una solución, y la implementa, a ser posible, sin parches ni trampas cortoplacistas para evitar futuras refactorizaciones. Recuerda: un refactor es una deuda técnica mal gestionada. Al igual que un rediseño es una deuda de diseño mal gestionada.
- 4. Pruebas: realizamos la batería de pruebas habitual (otro día hablamos sobre planes de pruebas, estrategia de pruebas y cuáles de esas pruebas son responsabilidad de líderes de producto). Si no se soluciona el problema volvemos al punto anterior.
Dicho esto, y saldando la promesa hecha en el punto dos, la herramienta que yo he usado para tomar decisiones y priorizar los bugs en producción es algo tan sencillo y a la vez tan complejo como una Calculadora de Incidencias, es decir, un excel donde recogemos toda la información de la incidencia y en base a unos valores previamente asignados nos devuelve un resultado. Básicamente, le preguntamos a la incidencia.
Creamos este excel con una serie de preguntas del tipo:
- Número de usuarios afectados.
- ¿Tenemos solución detectada y estimada?
- ¿Afecta a funcionalidades Core del producto? ¿Qué funcionalidad está afectada?
- ¿Estamos en ventana favorable para solucionarlo? Es decir, estamos en un momento del sprint donde hay posibilidad de abordarlo
- ¿Cuál es el impacto de no solucionarlo?
- ¿Tenemos fechas comprometidas? ¿Provoca cambios de alcance de otros trabajos?
- Etc.
Las respuestas a estas preguntas tenían por detrás una valoración cuantitativa, de forma que al responder a todas salía un número. Ese número representaba una categorización, nosotros usamos desde DEFCON-1 a DEFCON-5, y cada categoría representaba una decisión de priorización. Para nosotros:
- DEFCON-1: Máxima urgencia y prioridad, un hotfix.
- DEFCON-2: En el sprint en curso pero no inmediatamente, cuando un dev quede libre, en lugar de empezar con la siguiente tarea se pone con el bug.
- DEFCON-3: Para el siguiente sprint.
- DEFCON-4: En los tres próximos sprints.
- DEFCON-5: Queda en el backlog para abordar en un plazo no estimado.
Obviamente esto no era algo incuestionable e inamovible. Probamos con incidencias de nuestro histórico para refinar la Calculadora y después, con cada incidencia que iba surgiendo fuimos mejorando las valoraciones y prioridades que nos devolvía. Si una incidencia era obvio que debía ser DEFCON-1 y la calculadora nos decía DEFCON-3 mirábamos donde podía estar el error y realizábamos ajustes.
Ahora, si todos pensábamos que debía ser DEFCON-1 y la calculadora decía DEFCON-2, ahí ya nos hacía dudar, generaba una reflexión y al menos nos retaba a tomar la mejor decisión.
Con esta calculadora acabamos con una batería de cerca de veinte preguntas que después añadimos como pantallazo a la documentación/evidencia de la prioridad elegida.
¿Te está gustando este tema? Profundiza en Product Management descargado nuestro libro de cabecera Las Claves del Product Management
El Mito de Heimdall para gestionar incidencias
Otra forma de gestionar las incidencias es abrir la mente a nuevas ideas.
Una técnica que nos recomendó nuestro Delivery Manager en uno de los equipos de producto con los que trabajé fue la figura de Heimdall. Sí, has leído bien, Heimdall, el dios guardián de la mitología nórdica que todo lo veía, protector del reino de Asgard y segurata a tiempo completo del Bifrost o puente del arco iris, recibiendo y despidiendo a Thor y sus colegas cada vez que se iban de juerga.
En nuestro caso nos quedamos sólo con la figura de guardián y protector del equipo, la primera línea de defensa para que el equipo pueda mantener su foco puesto en los desarrollos planificados.
Mediante acuerdos de equipo, definimos las responsabilidades de Heimdall orientadas a liberar al equipo de tareas operativas, como puede ser presentar el tablero en los diferentes eventos del sprint, moderar las dailys, secretario de las reuniones de equipo, gestionar el tren de releases, los merge, las tareas de QA de las funcionalidades que quedaban pendientes, los despliegues en los diferentes entornos, la gestión de las peticiones que nos grababan como solicitudes y también la gestión de las incidencias.
En esta última parte, no sólo las recibía, sino que además se hacía accountable de los bugs, conseguía más información, trasladaba la incidencia al Product Owner y desarrollaba la solución en caso de priorización. Al no tener muchas incidencias, la mayoría de ellas pequeñas o de rápida solución y disponer de esta figura dedicada, por lo general los bugs funcionaban en modo FIFO (first in, fist out).
La figura de Heimdall cumplía con la promesa, realmente era el guardián y protector del equipo, salvando las connotaciones épicas. Configuramos un orden de sucesión de manera que este rol fuera rotando cada Sprint y así cada miembro del equipo pudiera desarrollar esta responsabilidad.
Reservar un carril del sprint para bugs ya queda muy viejuno. Si estás pensando en poner un carril en tus sprints te recomiendo fervientemente adoptar la figura de Heimdall, acordar con el equipo sus responsabilidades, establecer un orden de sucesión y proteger a tu equipo. Pon un Heimdall en tu equipo.
Y lo más importante, estas técnicas son formas de gestionar incidencias que a mí me han funcionado, a mí y al equipo de producto con el que trabajaba, pero que no tiene por qué funcionarte a tí. Valida siempre con tu experiencia. Inspecciona y adapta a tu contexto.
Por último, pero no menos importante, cuando nos encontramos con bugs grandes o con una serie de bugs encadenados uno detrás de otro es conveniente realizar una retrospectiva para analizar qué puede estar pasando. Solucionar un bug, en mi opinión, es como tomarse un paracetamol cuando te duele la cabeza. Alivia el dolor pero no soluciona el problema. Es necesario investigar cuál es el gatillo original que detona el problema y tratar de buscar soluciones. ¿Se debe a un proceso obsoleto? ¿Demasiada deuda técnica? ¿Una arquitectura conflictiva? ¿Un error humano? ¿Falta formación? ¿Desmotivación o síndrome de burnout? ¿Alguna persona está generando relaciones tóxicas? Las posibilidades son muchas y muy diversas. Encontrarlas y generar los cambios en el proceso
¿De qué forma podemos encontrar el origen del problema? La técnica de los 5 Porqués, ojo spoiler, funciona. Aunque archiconocida, voy a describir brevemente el taller de los 5 Porqués para poder llevarla a cabo en los post-mortem de nuestros bugs.
- 1. Monta una reunión con todo el equipo. Si hay personas involucradas en el bug que no pertenecen al equipo inclúyelos en la reunión.
- 2. Realiza una breve introducción sobre la dinámica de este taller y haz una síntesis de los hechos objetivos (de la forma más neutra posible) que giran en torno al bug.
- 3. Hacemos una ronda de presentación e ideas iniciales que tiene cada persona sobre el bug que nos ha reunido a todos aquí.
- 4. El Porqué Nº1: ¿Por qué se ha producido este bug? Anota todas las respuestas y conclusiones en una pizarra, en posits por ejemplo, o notas adhesivas de cualquier otra marca.
- 5. Resto de Porqués: Cuando lleguemos a una conclusión, volvemos a preguntar, ¿Por qué se ha producido [conclusión_anterior]? Con cada ronda vamos anotando las respuestas y conclusiones, como en un árbol de decisión, o en formato Impact Map, o como guste el consumidor.
- 6. Una vez llegada a la conclusión nuclear, el posible origen más probable del problema creamos un plan de acción para solucionarlo, ya sea iterar un proceso, realizar formaciones, o migrar a una nueva arquitectura, por ejemplo.
Tips rápidos sobre el taller
- Comparte los resultados del taller con los asistentes, lo agradecerán y estarán más involucrados en hacer seguimiento del plan de acción.
- Genera comprensión y aceptación. Primero limpia la caca, luego haz los cambios para no hacer caca en ese sitio otra vez, por último seamos conscientes del aprendizaje que nos da la caca, de nada sirve restregar la caca en el hocico de nadie. Los errores se producen y podemos frustrarnos, rumiar infinito sobre universos alternativos donde eso se podría haber evitado y todos viviríamos felices, o podemos aprender de los errores y construir un conocimiento superior sobre las cenizas de nuestro fracasos.
- Genera confianza, no buscamos culpables, buscamos soluciones. Mandar a la hoguera a alguien no va a arreglar el problema, a no ser que se trate de un ciborg que viene del futuro para destruir nuestro producto, en ese caso sí, quema a ese maldito ciborg.
En este link de Eric Ries, el autor del libro Lean Startup, tienes más información sobre esta técnica
¿Tú cómo gestionas la prioridad de los bugs? Espero que si no lo haces al menos esto te sirva de inspiración ;)
Si buscas aprender de producto con los mejores, ¡echa un vistazo a nuestras formaciones!
