# Prioriza los bugs por impacto en el usuario

- **URL canónica:** https://playbook.affpartners.io/es/apps/practices/quality-bugs/
- **Versión Markdown:** https://playbook.affpartners.io/es/apps/practices/quality-bugs/index.md
- **Módulo:** Calidad del producto
- **Tiempo:** 60 minutos para el primer análisis

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.

## Resultado

Una tabla con los cinco bugs de mayor impacto, con evidencia, solución alternativa, responsable y fecha de revisión.

## La prioridad es el daño al usuario, no el volumen de la discusión

Un defecto visual llamativo puede atraer mucha atención, pero un estado de operación bloqueado, una pérdida de datos o un fallo de inicio de sesión suelen importar más. Protege primero la seguridad, el dinero, los datos y la ruta clave; la comodidad y la apariencia van después.

## Qué vas a necesitar

- **Accesos:** Crashlytics, AppMetrica u otro reporte de errores, además de la lista actual de tareas en Jira, Linear o una hoja de cálculo.
- **Colegas:** Un ingeniero de QA o un desarrollador y alguien de soporte durante 20 minutos, para confirmar el rastro técnico y la frecuencia de las quejas.
- **Periodo:** Errores, solicitudes de soporte y reseñas de los últimos 14 días; anota por separado las versiones de la app y las plataformas.

## Términos en lenguaje sencillo

- **Crash-free rate — La proporción de usuarios sin cierres inesperados de la app:** Definición: Cuanto más cerca del 100%, menos usuarios sufrieron un cierre inesperado de la app durante el periodo elegido. Ejemplo: Un 99,5% de usuarios crash-free significa que el 0,5% sufrió al menos un cierre inesperado.
- **ANR — Un bloqueo de una app de Android:** Definición: Android registra un ANR cuando la interfaz deja de responder al usuario durante demasiado tiempo. Ejemplo: El usuario toca un botón, la pantalla se congela y Android ofrece cerrar la app.
- **Analytics event — El registro de una acción concreta del usuario:** Definición: La app envía un evento cuando un usuario abre una pantalla, toca un botón o completa una acción. Ejemplo: registration_started y registration_completed muestran cuántas personas abandonan el registro.
- **Conversion — La proporción de personas que pasan al siguiente paso:** Definición: Muestra cuántas de las personas que empezaron un paso lo completaron o llegaron al siguiente. Ejemplo: 80 registros completados de 100 iniciados: 80 ÷ 100 × 100% = 80% de conversión.

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

## 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**
  - **Fuente:** Mira la cantidad de usuarios afectados, la versión de la app, el dispositivo, el stack trace y la repetibilidad.
  - **Si no hay acceso:** 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**
  - **Fuente:** 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 acceso:** Si no hay etiquetas configuradas, revisa a mano las 30 solicitudes más recientes y crea cinco categorías simples.
- **Ruta clave**
  - **Fuente:** 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.
  - **Si no hay acceso:** Sin analítica, recorre la ruta diez veces en la versión afectada y anota la tasa de fallos.

## Ordena la lista de bugs en cinco pasos

1. **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.
   - **Ejemplo:** Tres tickets —«estado interminable», «operación bloqueada» y «no veo el resultado»— se unen en un solo problema.
2. **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.
   - **Ejemplo:** No «API 504», sino «después de confirmar, el usuario no ve el estado final y repite la acción».
3. **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.
   - **Ejemplo:** 84 usuarios en 7 días; solo Android 12; confirmado por 12 solicitudes de soporte y un clúster de errores.
4. **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.
   - **Ejemplo:** P0; responsable: el equipo de backend; plazo: hoy 18:00; soporte revisa el estado por ID.
5. **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.
   - **Ejemplo:** El clúster de errores desapareció, 20 ejecuciones de prueba pasan y no hay solicitudes nuevas sobre el tema durante dos días.

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

## Artefacto final: 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.

## Lista de verificación de la priorización

Una tarea crítica debe leerse igual para producto, soporte y desarrollo.

- [ ] El problema está nombrado a través de la acción y el daño al usuario.
- [ ] Están la plataforma, la versión, el periodo y una escala confirmada (o un nivel de confianza).
- [ ] Los errores que afectan dinero, datos, seguridad y confianza están marcados por separado.
- [ ] Los P0 y P1 tienen responsable, plazo y una solución alternativa segura.
- [ ] Está anotado por adelantado qué datos confirmarán el arreglo.

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

## Regla principal

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.

## Crece con GameChange Partners

[Explorar el programa de afiliados ↗](https://gamechange.partners/es?utm_source=academy&utm_medium=referral&utm_campaign=gcpacademy)

---

- [Versión HTML](https://playbook.affpartners.io/es/apps/practices/quality-bugs/)
- [Todas las prácticas](https://playbook.affpartners.io/es/apps/)