Práctica 01.03 · Calidad del producto
Prioriza los bugs por impacto en el usuario
No hace falta ser experto técnico para ordenar un backlog de bugs. Para cada bug responde cuatro preguntas: qué está roto, a quién afecta, con qué frecuencia ocurre y si existe una solución alternativa segura.
60 minutos para el primer análisis
En lenguaje sencillo
La prioridad es el daño al usuario, no el volumen de la discusión
Qué vas a necesitar
01
Cuándo aplicarla
El backlog no deja de crecer, el equipo discute sobre la urgencia y se atiende la última solicitud ruidosa en lugar del problema más peligroso.
En lenguaje sencillo
Dónde buscar evidencia
Una sola captura no muestra la escala. Combina la señal técnica, un reporte de usuario y el impacto en una acción clave.
Reportes de cierres inesperados y ANR
Mira la cantidad de usuarios afectados, la versión de la app, el dispositivo, el stack trace y la repetibilidad.
Si no hay reportes, pide a un desarrollador que reproduzca el problema y guarde el video, los logs y las condiciones.Soporte y reseñas
Agrupa las solicitudes por una única causa: inicio de sesión, estado, pago, pérdida de datos, pantalla en blanco o mensaje confuso.
Si no hay etiquetas configuradas, revisa a mano las 30 solicitudes más recientes y crea cinco categorías simples.Ruta clave
Compara la tasa de éxito de la acción antes y después de que apareciera el error: inicio de sesión, registro, guardado, verificación u operación.
Sin analítica, recorre la ruta diez veces en la versión afectada y anota la tasa de fallos.02
Ordena la lista de bugs en cinco pasos
Reúne todo en una tabla
Une los duplicados de los reportes de errores, QA, soporte y reseñas. Un problema del usuario debe ser una fila.
- Dónde hacerlo
- Jira, Linear o una tabla compartida con enlaces a las señales originales.
- Cómo se ve el resultado
- Tres tickets —«estado interminable», «operación bloqueada» y «no veo el resultado»— se unen en un solo problema.
Describe el daño con palabras simples
Anota qué no puede hacer el usuario y qué corre riesgo de perder. No dejes solo un código de error en el título.
- Dónde hacerlo
- En el campo «impacto en el usuario» de cada tarea.
- Cómo se ve el resultado
- No «API 504», sino «después de confirmar, el usuario no ve el estado final y repite la acción».
Confirma la escala
Indica la cantidad de personas afectadas, la plataforma, la versión, la frecuencia y el periodo. Si no hay número, anota con honestidad tu nivel de confianza.
- Dónde hacerlo
- Junto al rastro técnico y un enlace a las solicitudes de soporte.
- Cómo se ve el resultado
- 84 usuarios en 7 días; solo Android 12; confirmado por 12 solicitudes de soporte y un clúster de errores.
Asigna prioridad y solución alternativa
La seguridad, el dinero, los datos y una acción clave bloqueada van primero. Mientras el arreglo está en curso, soporte debe saber cómo ayudar al usuario de forma segura.
- Dónde hacerlo
- En las columnas P0–P3: responsable, plazo y solución alternativa.
- Cómo se ve el resultado
- P0; responsable: el equipo de backend; plazo: hoy 18:00; soporte revisa el estado por ID.
Cierra con datos, no con el release
Después del arreglo, repite el escenario y comprueba que desaparecieron tanto la señal técnica como las quejas de los usuarios.
- Dónde hacerlo
- En la tarea, entre 24 y 72 horas después de publicar el arreglo.
- Cómo se ve el resultado
- El clúster de errores desapareció, 20 ejecuciones de prueba pasan y no hay solicitudes nuevas sobre el tema durante dos días.
03
Ejemplos prácticos
P0: estado de la operación bloqueado
El problema afectó a 84 usuarios en una semana: el resultado no se ve, así que la gente repite la acción. Hay riesgo financiero y de confianza: hoy mismo hacen falta un responsable y una respuesta segura de soporte.
P1: historial vacío en Android 12
La escala es menor, pero hay datos clave no disponibles. La tarea registra la versión, un video de reproducción, la solución temporal de reiniciar y una revisión de las solicitudes de soporte 48 horas después del hotfix.
Una tabla de prioridades que todo el equipo entiende
Con cinco filas alcanza para la primera decisión. No esconda el impacto detrás del nombre técnico de un bug.
| Problema | Impacto y escala | Solución alternativa | Decisión |
|---|---|---|---|
| Estado de la operación bloqueado | Dinero/confianza · 84 usuarios | Soporte lo revisa a mano | P0 · arreglar hoy |
| El código de acceso no llega | Bloquea el acceso · Android 12 | Reenviar a los 60 segundos | P0 · desarrollador de Android |
| Historial vacío | Datos no visibles · versión 4.2 | Reiniciar la app | P1 · arreglo urgente |
| El push abre la pantalla de inicio | Paso extra · 11% de los toques | Abrir la sección a mano | P2 · próximo release |
| Icono desalineado | Solo apariencia | No hace falta | P3 · deuda de diseño |
Regla: un P0 bloquea o corrompe dinero, datos, seguridad o la ruta principal. Cada P0 tiene responsable, plazo, un mensaje para soporte y una forma de verificar el arreglo.
04
Lista de verificación de la priorización
Una tarea crítica debe leerse igual para producto, soporte y desarrollo.
05
Cómo saber si el arreglo funcionó
Señal técnica
El clúster concreto de cierres inesperados, el ANR o el código de error desapareció en la versión afectada.
Ruta del usuario
La tasa de éxito de los inicios de sesión, los guardados, las operaciones o la acción rota se recuperó.
Soporte y confianza
Dejaron de llegar solicitudes nuevas sobre el tema y los usuarios afectados recibieron una respuesta clara.
Un bug no se cierra cuando el código se publica, sino cuando los usuarios vuelven a completar la ruta y los datos lo confirman.