Un pago falla para un grupo reducido de clientes, el estado de un pedido se queda desactualizado de forma intermitente y un banner se ve mal en un navegador. Los tres avisos pueden llegar etiquetados como «urgentes». Para un Product Owner, ordenar ese trabajo requiere información suficiente para explicar qué ocurre si cada defecto sigue abierto y qué otro trabajo se aplaza al corregirlo ahora.
Los ejemplos siguientes utilizan Mercato, una tienda en línea hipotética. Muestran cómo la decisión cambia cuando varían el público afectado, la alternativa disponible o el tiempo que queda antes de una campaña. Las prioridades propuestas pertenecen a estos casos; no constituyen una clasificación universal que deban adoptar todos los equipos.
La severidad describe el fallo; la prioridad ordena la respuesta
La severidad describe la gravedad del defecto para el sistema o para la persona que intenta utilizarlo. La prioridad expresa con qué urgencia debe abordarlo el equipo frente al resto del trabajo. Un cierre inesperado en una herramienta interna obsoleta puede ser grave para quienes todavía la utilizan y requerir una respuesta distinta a un fallo menor que afecta a la campaña del checkout de hoy. La distinción solo ayuda si se documenta a quién afecta y en qué condiciones.
Etiquetas como crítico, grave, P1 o P2 varían entre organizaciones. Microsoft Azure Boards, por ejemplo, mantiene campos separados de severidad y prioridad y explica por qué sus valores pueden no coincidir. Producto, Ingeniería, QA y Soporte deben acordar el significado de sus etiquetas, incluida la vía de actuación ante un incidente activo. Copiar una etiqueta de otra empresa no establece un tiempo de respuesta.
Concretar el impacto antes de discutir el orden
«Algunos clientes no pueden pagar» basta para empezar a investigar, pero todavía no describe el alcance. El equipo necesita conocer el método de pago afectado, las condiciones del fallo, cuándo empezó y si el cliente puede recuperarse sin pagar dos veces. Un número reducido de avisos puede reflejar poca exposición o un problema que los clientes abandonan sin comunicar. La incertidumbre sobre el alcance debe quedar visible.
Un aviso de bug útil ofrece al equipo una base común para esa conversación. La información siguiente puede completarse de forma progresiva; investigar un incidente grave no debería esperar a que alguien termine de rellenar un formulario perfecto.
- El comportamiento observado y el esperado, el recorrido afectado y las condiciones conocidas para reproducirlo.
- El público expuesto al fallo, con las evidencias disponibles y sus limitaciones.
- Las consecuencias para los clientes, las transacciones o los datos, incluida la posibilidad de revertirlas.
- La alternativa disponible, quién puede utilizarla y qué coste o limitaciones tiene.
- La condición temporal, las medidas de contención posibles y una primera valoración técnica de la corrección.
La guía de observabilidad de producto desarrolla cómo investigar las señales de producción. Para priorizar, el resultado útil es una descripción breve del impacto y de la confianza que merece la información. Una traza llena de errores no demuestra por sí misma cuántos clientes han dejado de completar una compra.
Tres bugs y las decisiones que explican su prioridad
La confirmación falla después del pago
Mercato recibe avisos de pagos cobrados que no generan un pedido visible. El alcance inicial se desconoce. Como el cliente puede reintentarlo y recibir otro cargo, el equipo aplica su procedimiento de incidentes y evalúa medidas de contención, como desactivar la vía de pago afectada, mientras Ingeniería investiga. Soporte necesita identificar a las personas afectadas y explicar qué ocurrirá con su dinero y su pedido.
Responder de inmediato no implica publicar la primera modificación de código propuesta. El equipo debe comparar las opciones de contención y recuperación, valorar la corrección y revisar las transacciones ya afectadas. Producto aporta las consecuencias para el cliente y el negocio; Ingeniería concreta las alternativas técnicas y sus riesgos. Esperar a la próxima reunión habitual del backlog dejaría sin atender un perjuicio activo.
El estado del envío deja de actualizarse
Una integración logística deja algunos pedidos en preparación aunque ya se hayan enviado. Los paquetes siguen su recorrido y el cliente puede consultar la página del transportista, pero el enlace solo aparece en un correo que algunas personas no encuentran. El bug puede quedar inicialmente detrás del incidente de pagos y, aun así, tener una persona responsable, una revisión prevista y una medida temporal de soporte.
La alternativa debe evaluarse tal como la experimenta el cliente. Si la mayoría de las personas afectadas no encuentra el correo, la existencia de una página de seguimiento alivia poco el problema. Un aumento de contactos con Soporte o evidencias de que se están ocultando entregas fallidas cambiarían la prioridad. Documentar esas condiciones permite al equipo saber cuándo revisar la decisión.
Un error visual antes de una campaña
Un banner recorta una línea de texto en un navegador. Si el texto es decorativo y la oferta sigue entendiéndose, el equipo puede programar la corrección después del trabajo de mayor impacto. Si la línea oculta contiene la compra mínima de la promoción de mañana, el mismo defecto visual cambia lo que el cliente entiende de la oferta. Corregir o sustituir el banner puede pasar a ser una condición previa al inicio de la campaña.
Por tanto, clasificarlo como «visual» no basta para asignarle una prioridad baja. La decisión depende de la información que se pierde, las personas afectadas y el tiempo disponible para actuar. Una imagen corregida o una campaña detenida temporalmente pueden ofrecer una respuesta más segura que un cambio apresurado de maquetación con consecuencias en otras pantallas.
Una tabla de decisión para trabajar con el equipo
La tabla recoge el razonamiento de los ejemplos. Sirve para discutir la decisión, no para calcular una puntuación automática. Cada fila necesita evidencias y, cuando el impacto se desconoce, puede ser necesario investigar o contener el problema antes de ordenar con confianza la corrección definitiva.
| Situación | Respuesta inicial | Motivo para revisar |
|---|---|---|
| Pago cobrado, pedido ausente | Activar la respuesta a incidentes, valorar la contención y conciliar las transacciones afectadas. | Nuevas evidencias de alcance, cargos duplicados o alternativas de recuperación. |
| Estado del envío desactualizado | Planificar la corrección y ofrecer una alternativa accesible de seguimiento. | La alternativa falla, aumenta la demanda de soporte o se ocultan entregas fallidas. |
| Condición de campaña recortada | Corregir o sustituir el banner antes de exponer a los clientes a la oferta. | Se aplaza la campaña, se sustituye el contenido o cambia la exposición. |
Hacer explícito el coste de cambiar el plan
Un bug no deja de consumir capacidad porque se etiquete como urgente. Corregirlo puede interrumpir otro trabajo, necesitar a una persona especializada e introducir riesgo de regresión: que deje de funcionar algo que antes funcionaba. La valoración de Ingeniería debe incluir la comprobación y el despliegue, además del cambio de código. Con esa información, el Product Owner puede explicar qué resultado previsto se aplaza y por qué se justifica esa decisión.
En Scrum, el Product Owner responde de la ordenación del Product Backlog y los Developers gestionan el Sprint Backlog. Cuando aparece trabajo nuevo durante un Sprint, el Product Owner y los Developers discuten el alcance sin poner en peligro el Objetivo del Sprint. Un incidente activo también sigue las responsabilidades operativas de la organización; el Product Owner no debería convertirse en la única persona que autoriza una medida de contención. El trabajo que incumple la Definition of Done no puede darse por terminado como parte del Incremento porque se haya asignado una prioridad baja al defecto pendiente.
Documentar por qué un bug puede esperar y cuándo revisarlo
Un bug aplazado necesita una decisión que se pueda revisar. Conviene registrar el impacto conocido, la medida temporal, quién lo revisará y la fecha o el evento que activa esa revisión. «Después del lanzamiento» requiere una persona responsable y un lugar en la planificación; de otro modo, puede convertirse en un aplazamiento indefinido. Los avisos de clientes, una activación más amplia o un cambio en la alternativa disponible pueden dejar obsoleta la valoración inicial.
Cerrar el aviso también requiere evidencias de que se ha resuelto el fallo original y se ha considerado a los usuarios o las transacciones afectados. Cuando el comportamiento esperado era ambiguo, el artículo sobre criterios de aceptación para Product Owners ayuda a convertir el acuerdo en casos que el equipo pueda comprobar. El libro Testing, bugs y calidad para Product Managers desarrolla los resultados de pruebas, la clasificación de bugs y las decisiones de lanzamiento para Product Managers y Product Owners.
Referencias
- Microsoft Learn: gestión de bugs y distinción entre severidad y prioridad.
- La Guía Scrum: Product Owner, Sprint Backlog, Objetivo del Sprint y Definition of Done.