La gestión de defectos es lo que le ocurre a un error entre que alguien lo detecta y alguien confirma que ha desaparecido. Es un proceso, no una herramienta: los estados por los que pasa un defecto, quién lo mueve y cómo decide el equipo cuáles se arreglan primero.
La mayoría de los equipos tienen uno, lo hayan escrito o no. La versión no documentada suele ser “ponlo en el tracker y confía”, que funciona hasta que hay más defectos de los que nadie puede retener en la cabeza - normalmente unos treinta.
El ciclo de vida
Los estados se llaman de forma distinta en cada tracker, y la forma que hay debajo es la misma.
- Nuevo. Reportado, nadie lo ha mirado todavía.
- Triado. Alguien lo ha leído, ha confirmado que es real y ha decidido cómo de urgente es.
- Asignado. Tiene un responsable.
- Arreglado. El responsable cree que está hecho. Nadie más cree nada aún.
- Verificado. Alguien que no es el responsable lo ha confirmado contra el informe original.
- Cerrado. Terminado.
Hay otros dos finales legítimos que a menudo se manejan mal. Rechazado significa que no es un defecto: el comportamiento es intencionado, o el informe describía un malentendido. Aplazado significa que es real y que no se va a arreglar ahora. Ambos necesitan un motivo escrito en el ticket, porque la alternativa es que el mismo defecto se vuelva a reportar dentro de seis semanas por alguien que no tiene manera de saber que ya se había considerado.
El paso que los equipos se saltan sin decirlo es la verificación. Un defecto cerrado por la persona que lo arregló es un defecto cerrado sobre la opinión de una sola persona, y el arreglo que en realidad no cubría el caso reportado es una experiencia lo bastante común como para tener su propio problema de reproducción.
Severidad y prioridad no son lo mismo
Esta es la confusión que merece la pena aclarar, porque provoca discusiones que parecen desacuerdos sobre el defecto pero en realidad son dos personas usando una palabra para dos ideas.
La severidad es lo malo que es el comportamiento. Perder datos es grave. Un icono desalineado no. Es una propiedad del defecto en sí y no cambia porque haya cambiado el calendario.
La prioridad es lo pronto que se arregla. Eso es una decisión de negocio, y depende de a quién afecta, a cuántos, de si hay una solución temporal y de qué más compite por la misma semana.
Las dos se separan en ambas direcciones, y eso es lo que hace que valga la pena distinguirlas:
- Severidad alta, prioridad baja
- Un fallo en una pantalla de administración que usa dos veces al año una persona que conoce la solución temporal
- Severidad baja, prioridad alta
- El nombre de la empresa mal escrito en la página de precios, visible para todos, corregido esta misma mañana
Los trackers que solo ofrecen un campo obligan a promediar las dos en un número que no significa ninguna. Si el tuyo lo hace, di cuál de las dos representa y déjalo escrito, porque si no media parte del equipo ordena por daño y la otra media por urgencia.
Quién tría, y con qué frecuencia
El triaje es una decisión, así que necesita a alguien con permiso para tomarla. En un equipo pequeño es una persona que repasa la cola de nuevos cada mañana. En uno más grande es una reunión corta y periódica con un desarrollador, un tester y alguien que hable por el producto.
Lo que importa más que el formato es que sea regular. Una cola que se tría cuando alguien se acuerda acumula una cola de defectos que nadie ha leído, y el coste de eso no es la cola sin tocar: es que ya nadie se fía de la cola, así que los defectos reales se reportan por chat.
El triaje necesita tres respuestas por defecto, y ninguna más: si es real, cómo de malo es y de quién es. Todo lo que dure más es trabajo de diseño ocurriendo en la reunión equivocada.
Los informes deciden a qué velocidad va el proceso
Cada estado posterior a “nuevo” depende de lo bueno que fuera el informe.
El triaje no puede juzgar la severidad sin saber qué pasó en realidad. El responsable no puede arreglar lo que no puede reproducir. La verificación no puede confirmar nada si los pasos originales ya no están escritos. Un informe vago no cuesta simplemente los cinco minutos de quien lo reporta: cuesta una ida y vuelta en cada etapa, y cada ida y vuelta es un día.
Ahí es donde se va la mayor parte del tiempo. No en arreglar, en volver a preguntar.
Session Replay
Extensión gratuita de Chrome. Un clic en la página que se está portando mal captura la captura de pantalla, la consola y el registro de red, y te devuelve un enlace para pegar en el ticket.
Nuestra guía de informes de error tiene la forma que sobrevive al triaje: qué pasó, qué se esperaba, los pasos y el entorno. Pide esas cuatro cosas y la mayoría de las idas y vueltas dejan de ocurrir.
Métricas que engañan
Se cuentan tres números porque son fáciles de contar, y cada uno merece leerse con cuidado.
- Número de defectos abiertos. Sube cuando el testing mejora, que es lo contrario de lo que parece. Que caiga a cero suele significar que la gente ha dejado de reportar, no que el software haya mejorado.
- Defectos por desarrollador. Premia a quien toca menos código. No lo hagas.
- Tiempo hasta el cierre. Útil, pero mide el proceso tanto como el trabajo: una semana esperando a que quien reportó conteste una pregunta cuenta igual que una semana depurando.
La que sí merece vigilarse es la tasa de reapertura: defectos marcados como arreglados que volvieron. Es una medida directa de si “arreglado” significa algo en tu equipo y, a diferencia de las otras, es difícil de manipular.
La versión corta
Seis estados, un motivo escrito para todo lo rechazado o aplazado, y una verificación hecha por alguien distinto de quien lo arregló. La severidad es cómo de malo, la prioridad es cómo de pronto, y son campos distintos. Triaje con un horario en vez de cuando alguien se acuerda. Y la mayor parte del tiempo que se ahorra se ahorra al principio, en el informe: un defecto que llega completo recorre todo el proceso sin que nadie tenga que hacer una pregunta.