how-it-works · agentic-qa · defect-management
Defect Management — Gestionar la Calidad por sus Incidencias
Bug, Defect, Improvement: el mismo síntoma, distinta estrategia de gestión. Cómo se reportan bajo un estándar de calidad reusable, cómo viven en su workflow, y cómo se convierten en métricas que responden preguntas de calidad.
Del reporte a la métricaparte 1: las 3 incidencias · parte 2: workflow + campos del estándar · parte 3: medir (ejemplo ShopFlow)
Encuadre: esto NO es sobre casos de prueba ni test plans — es sobre la gestión de incidencias de error (Bug/Defect/Improvement): cómo se reportan, cómo transitan y cómo se miden. La meta final es que el equipo de producto vea la salud de la app con sus propios ojos.
el dato que responde
40 / 40
En ShopFlow, las 40 incidencias tienen Components — y cada campo del estándar — relleno. La data no solo existe: responde cada pregunta de calidad. Lo que rellenas con disciplina hoy es lo que el dashboard sabe medir mañana.
Arranca con la tesis: gestionar defectos no es abrir tickets, es generar datos que respondan preguntas. ShopFlow rellena el 100% de sus campos → el dashboard ve todo. Volveremos a este equipo modelo en la parte 3.
qué cubriremos
Tres Partes: Distinguir, Gestionar, Medir
01Las tres incidencias — Bug vs Defect vs Improvement: mismo término, distinta estrategia de gestióndistinguir
02El estándar de calidad — un solo workflow, los mismos campos, y el rol clave de Componentsgestionar
03Medir la calidad — de campos rellenos a métricas y dashboards que responden preguntas (ejemplo ShopFlow)medir
3 quizzes interactivos a lo largo del recorrido — haz clic en las respuestas.
La parte 3 es la más importante: las métricas. Las partes 1 y 2 construyen el vocabulario y la disciplina que hacen posible medir.
PARTE 01
Las Tres Incidencias
Bug · Defect · Improvement
El término no las distingue — léxicamente un bug ES un defecto. Lo que las distingue es cuándo nacen y qué le dicen al equipo sobre el estado del producto.
Insistir: la diferencia no es semántica, es estratégica. Es una decisión de gestión de incidencias, no de diccionario.
la idea central
Mismo Término, Distinta Gestión
"Bug" y "defecto" son sinónimos en el lenguaje. La diferencia vive en la línea de tiempo del producto: ¿la funcionalidad sigue en desarrollo, o ya fue liberada?
El eje que decide todo
Una falla detectada durante el sprint, sobre una funcionalidad que aún se está construyendo → Defect. La misma clase de falla, descubierta después del release sobre algo que ya funcionaba → Bug. El Improvement es el tercer camino: ni una ni otra, sino una mejora.
El usuario lo resume así: defecto = bajo sprint, en desarrollo; bug = regresión post-release; improvement = mejora, muchas veces trivial o reclasificada tras análisis de causa raíz.
incidencia #1
Defect — la falla que cazamos en el sprint
Qué indica
Que una User Story bajo sprint está saliendo defectuosa y hay que arreglarla antes de que suba a ambientes superiores.
Cuándo nace
Durante el desarrollo / la fase de QA del sprint. Es lo normal y deseable: el sprint existe para destapar defectos y cerrarlos.
- Nace de una User Story. Se enlaza a la US que se está construyendo (edge causation: la US causes el Defect).
- Es contención, no escape. Encontrarlo aquí es éxito de QA — el defecto nunca llegó al usuario.
- Si el sprint hace bien su trabajo, la US entra al release libre de defectos.
Recalcar: destapar defectos en el sprint es la meta. Un sprint con muchos defectos detectados y cerrados es un sprint sano, no uno enfermo.
incidencia #2
Bug — la regresión que escapó
Qué indica
Que una funcionalidad ya liberada y desplegada está fallando. Algo que se suponía debía funcionar dejó de hacerlo.
Cuándo nace
Pasado el sprint — semanas o meses después — típicamente como un edge case o una regresión sobre código ya validado.
- El Bug es el tipo de incidencia de las regresiones: cada vez que algo que debería funcionar, falla.
- Es un escape. Cruzó la red del sprint y llegó a producción — eso es justo lo que las métricas deben vigilar.
- Mismo síntoma que un Defect, distinto momento → distinta lectura de gestión.
El bug no es "peor" que un defecto por naturaleza — es peor por ubicación: ya está en manos del usuario. La distinción Defect/Bug es precisamente lo que hace medible el "escape".
el mismo fallo, dos vidas
Caso: el Carrito de Compra
1
Sprint — nueva US del carrito
Se agrega una historia de usuario sobre el carrito. QA detecta que el cálculo del total falla. DEFECT Está en desarrollo, se enlaza a la US, se arregla dentro del sprint.
2
Release — la US sale limpia
El defecto se reparó. La funcionalidad del carrito entra al release libre de defectos. El usuario la recibe funcionando.
3
Meses después — un edge case
Aparece un caso límite alrededor del mismo carrito (cupón + moneda extranjera + stock 0). Falla en producción. BUG Es una regresión descubierta post-sprint.
Este es el ejemplo canónico del usuario. El mismo componente (carrito) genera primero un Defect (en sprint) y luego un Bug (post-release). La taxonomía captura la diferencia de momento — y de ahí salen las métricas de escape.
incidencia #3
Improvement — ni falla, sino mejora
Un work type de tipo mejora. A veces trivial; a veces el destino de un Bug o Defect que, tras análisis de causa raíz, resulta no ser una falla sino un asunto de requerimientos.
Origen directo
Una mejora pequeña detectada al usar el producto: copy, UX, un atajo. No rompe nada — eleva la calidad.
Origen por reclasificación
Un Bug/Defect pasa por RCA y se descubre que el "error" era en realidad el comportamiento especificado. Se transforma: a Improvement, o a una nueva User Story.
En el workflow esto es literal
La transición is not a Bug lleva un Bug/Defect desde Open al estado terminal Enhancement — la reclasificación está cableada en el flujo del estándar, no es informal.
Conectar con la parte 2: el estado terminal "Enhancement" y la transición "is not a Bug" son exactamente este camino. RCA puede convertir un reporte de error en un requerimiento.
las tres, lado a lado
Defect vs Bug vs Improvement
| Dimensión | Defect | Bug | Improvement |
|---|
| Momento | Durante el sprint | Post-release | Cualquiera |
| Estado del producto | En desarrollo | Ya liberado | Funcional |
| Qué señala | US saliendo defectuosa | Regresión / escape | Mejora o reclasificación |
| Lectura de gestión | Contención (éxito de QA) | Fuga (riesgo a usuario) | Valor incremental / RCA |
| Nace de | Una User Story | Un edge case en prod | Uso real o un RCA |
Léelo como instrumentación, no como burocracia
Elegir bien el work type no es papeleo: es lo que más adelante hace que la pregunta "¿estamos deteniendo los defectos antes de que escapen?" sea medible.
Esta tabla es el ancla conceptual de la parte 1. Cada fila es una decisión de gestión, no una etiqueta arbitraria.
quiz · parte 1
¿Bug, Defect o Improvement?
Q1Durante el sprint, QA encuentra que el nuevo formulario de registro no valida el email. La US aún está en desarrollo.
ADefect — falla detectada en sprint, sobre una US en desarrollo
BBug — es una falla funcional
CImprovement — el formulario podría mejorar
Defect. El criterio no es la gravedad sino el momento: la funcionalidad sigue en construcción dentro del sprint. Cazarlo aquí es contención, no fuga.
Q2Tres meses tras el release, un usuario reporta que el login falla solo si la contraseña tiene emojis. Antes funcionaba.
ADefect — hay que arreglarlo
BBug — regresión / edge case sobre algo ya liberado
CImprovement — soportar emojis es una mejora
Bug. Funcionalidad ya desplegada que deja de funcionar = regresión. Es un escape: cruzó la red del sprint y llegó al usuario.
Deja que el público haga clic — las explicaciones aparecen al responder. La lección: el criterio que distingue es momento + estado del producto, nunca la gravedad ni el síntoma. Tercer caso (Improvement): si tras RCA el comportamiento es el especificado pero el cliente lo quiere distinto, se reclasifica vía "is not a Bug" → Enhancement (ver slide 9).
PARTE 02
El Estándar de Calidad
Un Workflow, los Mismos Campos
Las tres incidencias comparten exactamente el mismo esquema de workflow y los mismos campos. Reportar disciplinadamente hoy es lo que habilita medir mañana.
Aclarar que esto es un estándar de gestión reusable — una recomendación, no una ley universal. Pero es un estándar probado y consistente que cualquier equipo puede adoptar en Jira.
hallazgo del esquema real
Bug, Defect e Improvement → Mismo Esquema
Bug #10021
11 estados · 15 transiciones
Defect #10023
11 estados · 15 transiciones
Improvement #10022
11 estados · 15 transiciones
Idénticos byte por byte
Mismos estados (Open, In Progress, In Review, Ready For QA, Closed…), mismas transiciones, mismos campos para rellenar. Cambias el work type, no la mecánica. Esto es deliberado: un solo modelo mental para gestionar las tres.
Verificado en .agents/jira-workflows.json: los tres comparten el mismo workflow_scheme. Para el equipo significa cero curva de aprendizaje extra al pasar de uno a otro.
el flujo feliz
El Ciclo de Vida de una Incidencia
Open→
In Progress→
In Review→
Ready For QA→
Closed ✓
start fixing
Open → In Progress. El dev toma la incidencia.
Pull Request / Fixed & Deployed
In Progress → In Review → Ready For QA. El fix llega a QA para retest.
ReTest Passed
Ready For QA → Closed. QA verifica el fix (terminal de éxito).
Atajos y regresos cableados
Hard pushed salta el review (In Progress → Ready For QA). back reabre un Closed a Ready For QA cuando una regresión se cuela tras el sign-off.
Este es el camino principal. Los colores: gris=new, ámbar=indeterminate (trabajo en curso), verde=done. La categoría del estado importa para las métricas (parte 3).
la decisión más importante
Triage desde Open — 6 Caminos
Open es el hub de triage. No todo reporte se arregla — la mitad del valor de gestión está en clasificar bien lo que no es un fix.
start fixing → In Progress
Es real. El dev lo toma y arranca el fix.
is duplicated → Duplicated
Repetido. Ya existe otro ticket. Terminal.
is WAD → REJECTED
Working As Designed. No es falla. Terminal.
is CNR → Cannot Reproduce
No reproducible. Sin repro, no hay fix. Terminal.
is not a Bug → Enhancement
Reclasificación. Era requerimiento → mejora. Terminal.
defer → Deferred
Pospuesto. Aceptado pero no ahora. Reanudable.
El triage es donde un Bug puede volverse Improvement (is not a Bug → Enhancement). Las cuatro salidas terminales (Duplicated, REJECTED, CNR, Enhancement) son "ruido" que las métricas de calidad-de-reporte deben vigilar.
cómo termina una incidencia
Estados Terminales y sus Categorías
| Estado | Categoría | Significa | Lectura de métrica |
|---|
| Closed | done | Fix verificado por QA | Trabajo resuelto — el numerador del progreso |
| Duplicated | done | Repetido de otro ticket | Ruido de reporte |
| REJECTED | done | Working As Designed | Falso positivo |
| Cannot Reproduce | done | Sin repro confirmable | Reporte incompleto |
| Enhancement | done | Reclasificado a mejora | Asunto de requerimiento |
| Deferred | indeterminate | Pospuesto, reanudable | Deuda viva (aging) |
| ABORTED | done | Abandonado sin fix | Descartado |
La categoría (new / indeterminate / done) es lo que Jira usa para colorear y para los gadgets. Duplicated+REJECTED+CNR juntos = la tasa de "ruido" — una métrica de calidad del proceso de reporte.
qué se rellena al reportar
Los Campos del Estándar de Calidad
Siempre (alta señal)
- Summary — Épica: Componente: Síntoma
- Steps to Reproduce — pasos numerados
- Actual vs Expected Result
- Severity · Priority
- Error Type · Test Environment
- Evidence — captura / trace / log
Después / contexto
- Root Cause — se fija tras el RCA
- Fix — bugfix vs hotfix
- Workaround — mitigación temporal
- Components — agrupación (¡clave! →)
- Labels — bug, dominio
- Links — US causes Bug
Regla de oro
Cada campo que dejas vacío es una pregunta que el dashboard no podrá responder. La disciplina al reportar ES la materia prima de la métrica.
Estos campos salen de .agents/jira-required.yaml (sección bug/defect). El summary sigue el patrón Épica:Componente:Síntoma — que ya es agrupable. Conecta con Components en la siguiente.
clasificar el impacto
Severity → Priority
| Severity | Criterio | Priority | Ejemplo |
|---|
| Crítica | Core bloqueado, sin workaround, pérdida de datos | Highest | Login caído, checkout falla |
| Mayor | Feature principal rota, workaround difícil | High | Búsqueda devuelve resultados erróneos |
| Moderada | Issue con workaround fácil | Medium | Orden roto pero el filtro sirve |
| Menor | Bajo impacto, baja prioridad | Low | Validación de edge case faltante |
| Trivial | Solo cosmético | Lowest | Typo, leve desalineación |
Severity ≠ Priority
Severity es impacto técnico (lo fija QA); Priority es urgencia de negocio (la fija el equipo). Un typo en el logo (Trivial) puede ser High priority antes de una demo. Sepáralos siempre.
El mapeo Severity→Priority es el default; el negocio puede sobreescribir Priority. Mantener ambos campos da dos ejes de medición distintos.
dos taxonomías que alimentan métricas
Error Type (qué) vs Root Cause (por qué)
Error Type — el síntoma
Se infiere al reportar, desde el comportamiento observado.
functionalvisualcontentperformancecrashdataintegrationsecurity
Root Cause — la causa
Se fija después del fix, en el post-mortem.
code_errorconfig_env_errordata_errorenvironment_errorintegration_errorrequirement_errorthird_party_errorworking_as_designed
Por qué importan las dos
Error Type responde "¿qué clase de fallas dominan?" (¿somos débiles en seguridad? ¿en performance?). Root Cause responde "¿de dónde vienen?" (¿código? ¿requerimientos? ¿integraciones?). Dos preguntas, dos campos, dos gráficos.
Error Type es de cara al usuario (síntoma); Root Cause es de cara al proceso (causa, post-RCA). Juntos permiten preguntas de mejora de proceso, no solo de conteo.
el campo subestimado
Components — Agrupar para Medir
Un campo nativo de Jira, configurable para que aparezca en cada incidencia. Su superpoder: agrupar Bugs, Defects e Improvements por la parte del producto que afectan.
Flexible según la estrategia del proyecto
Los componentes se definen como convenga: por features, por épicas, por módulos. ¿20 épicas? → 20 components. Cada incidencia marca el/los componente(s) afectado(s).
Para qué sirve realmente
"¿Qué parte de la app falla más?" se vuelve una sola query. Habilita ownership (qué equipo dueño de qué componente) y routing automático de incidencias.
Y ShopFlow lo rellena siempre
Las 40 incidencias de ShopFlow marcan su Component → el dashboard de ownership existe y dice qué módulo concentra los defectos. Regla en una línea: lo que no rellenas no lo puedes medir — por eso es la recomendación #1 de higiene, y ShopFlow no deja ninguno vacío. Lo vemos en la parte 3.
Énfasis: Components es flexible (épicas/features) y poderoso para agrupar. ShopFlow lo rellena en las 40 incidencias — por eso su dashboard de ownership se puede dibujar entero. Es el campo que más equipos olvidan y el que más preguntas habilita.
quiz · parte 2
Workflow & Campos
Q1Triage de un Bug recién abierto: el equipo confirma que el comportamiento es exactamente el especificado. ¿Transición y estado?
Astart fixing → In Progress
Bis WAD → REJECTED
Cdefer → Deferred
is WAD → REJECTED. Working As Designed: no es una falla, es comportamiento especificado. Estado terminal (categoría done). Si además el cliente quisiera cambiarlo, sería is not a Bug → Enhancement.
Q2El equipo de producto quiere un dashboard de "¿qué parte de la app concentra más defectos?". ¿Qué campo lo habilita?
ASeverity
BPriority
CComponents
Components. Es el campo de agrupación por parte del producto (features/épicas). En ShopFlow está relleno en las 40 incidencias, así que ese dashboard se construye entero y muestra que Checkout y Auth lideran.
Refuerza: triage terminal (is WAD → REJECTED) y el rol de Components. Recuerda también el otro eje: un typo cosmético antes de una demo = Severity Trivial (impacto bajo) pero Priority High (urgencia alta) — ejes independientes, dos campos (ver slide 18).
PARTE 03
Medir la Calidad
De Campos a Preguntas Respondidas
Un dashboard no es una lista de datos — es un set de respuestas. La meta: que producto vea, con sus propios ojos, cómo va la app. Lo ilustramos con el proyecto de ejemplo ShopFlow.
La parte más importante. El principio rector: nadie quiere ver métricas, quiere resolver dudas. Las métricas son el medio. Los números de ShopFlow son ilustrativos, no de un proyecto real.
el principio rector
Los Datos Solo Importan si Responden Preguntas
❌ Dashboard como vertedero
- Lista de 200 tickets sin agrupar
- Conteos sin contexto ("hay 40 incidencias")
- Métricas que nadie sabe leer
- El equipo de producto no entiende nada
→
✓ Dashboard como respuesta
- "¿Estamos deteniendo defectos antes del escape?"
- "¿Qué componente falla más?"
- "¿La calidad del fix mejora o empeora?"
- Producto abre Jira y entiende la salud
Primero la pregunta de calidad, luego la métrica, luego el campo, luego la query. Nunca al revés. Este orden es el corazón de la enseñanza.
snapshot · proyecto de ejemplo ShopFlow (casa en orden)
Un Snapshot Típico: ShopFlow
40
familia de incidencias
26 Defect · 10 Bug · 4 Improvement — todas tipadas
26
Closed (verificadas)
6 In Progress · 5 Ready For QA · 3 Open
4
Críticas
11 Mayor · 17 Moderada · 8 Menor — 40/40 con Severity
Defect26
Bug10
Improvement4
ShopFlow es un proyecto de ejemplo (fictional), pero modela un equipo que SÍ hizo la ingeniería de calidad: 40 incidencias, todos los campos rellenos. 26 Defects vs 10 Bugs — la mayoría se cazó en sprint; guardar esta proporción para la slide de escape rate (28% sano).
lo que rellenas, lo puedes medir
La Casa en Orden: Campos al 100%
Priority100%
Severity100%
Components100%
Root Cause100%
Error Type100%
Resolution98%
El diagnóstico
ShopFlow rellena cada campo del estándar en las 40 incidencias → las 8 preguntas de la parte 3 tienen respuesta, sin ningún slice "sin asignar". El principio se cumple, pero al revés: lo que no rellenas no lo puedes medir — y aquí no quedó nada vacío. La disciplina al reportar HOY es la métrica fiable de MAÑANA.
Aquí el equipo modelo: cobertura completa. Severity, Components y Error Type al 100% → toda gráfica se dibuja entera, sin porción muted. El único campo que no llega al 100% es Resolution (98%), porque hay incidencias aún abiertas — eso es esperado, no una brecha de higiene.
el mapa que importa
Pregunta de Calidad → Métrica → Campo
| La pregunta que el equipo se hace | Métrica que la responde | Campo(s) |
|---|
| ¿Detenemos los defectos antes de que escapen a prod? | Defect Escape Rate = Bugs / (Bugs+Defects) | issuetype |
| ¿Qué tan grave es lo que encontramos? | Distribución por Severity + Severity Index | Severity |
| ¿Qué parte de la app falla más? | Defectos por Component | Components |
| ¿Por qué fallamos? (mejora de proceso) | Distribución por Root Cause | Root Cause |
| ¿Qué clase de fallas dominan? | Distribución por Error Type | Error Type |
| ¿Qué tan bueno es el fix? (¿reabrimos?) | Reopen Rate | historial de status (back/re-open) |
| ¿Cuánto tardamos en cerrar? | Defect Age / MTTR | created → resolved |
| ¿Cuánto ruido genera el reporte? | Rejection Ratio = (Dup+REJ+CNR)/total | resolution / status |
ESTA es la slide núcleo. El orden siempre: pregunta primero, métrica después, campo al final. Cada fila es directamente construible (o casi) con los campos del estándar. Escape Rate es la estrella — la siguiente slide la desarrolla.
de la pregunta a la query
JQL — el Lenguaje de los Dashboards
JQL · proyecto SHOP (ejemplo)
# Todos los defectos críticos aún abiertos
project = SHOP AND issuetype in (Bug, Defect) AND "Severity[Select List]" = Crítica AND statusCategory != Done
# Escape: bugs post-release vs defects in-sprint
project = SHOP AND issuetype = Bug → 10 (escaparon)
project = SHOP AND issuetype = Defect → 26 (contenidos)
# Agrupar por componente (Components relleno en las 40)
project = SHOP AND issuetype in (Bug, Defect) ORDER BY component
# Ruido de reporte: descartados
project = SHOP AND status in (Duplicated, REJECTED, "Cannot Reproduce") → 3
JQL es el motor detrás de cada gadget de dashboard. Una pregunta de calidad bien planteada se traduce casi 1:1 a una cláusula JQL + un group-by. Mostrar que los campos son literalmente los filtros.
vocabulario de métricas de defectos
Las Métricas que Debes Nombrar
| Métrica | Qué mide | Fórmula (en términos del estándar) |
|---|
| Defect Escape Rate | Fugas a producción | Bugs / (Bugs + Defects) |
| DDP / DRE | Eficiencia de detección | Defects / (Defects + Bugs) — el inverso del escape |
| Defect Density | Concentración | Defectos por Story / por Component / por módulo |
| Reopen Rate | Calidad del fix | reabiertos (back) / cerrados |
| Defect Age / MTTR | Velocidad de cierre | tiempo medio created → Closed |
| Rejection Ratio | Calidad del reporte | (Duplicated + REJECTED + CNR) / total |
| Severity Index | Gravedad ponderada | Σ(peso × conteo) / total |
Definir cada término en clave de gestión de incidencias, no de ejecución de tests. DDP/DRE y Escape Rate son inversos: cuánto contienes vs cuánto se fuga. Estas son las palabras que un Senior QA debe poder usar con propiedad.
la métrica estrella del shift-left
Defect vs Bug = tu Medidor de Escape
Aquí la taxonomía paga. Como Defect = en sprint y Bug = post-release, su proporción es, literalmente, la salud del shift-left: ¿cuánto contenemos vs cuánto se fuga?
26
Defects (contenidos)
cazados dentro del sprint
10
Bugs (escapados)
descubiertos post-release
28%
Escape Rate
10 / (10+26)
Un 28% es shift-left sano
Como ShopFlow usa el work type Defect con disciplina, la lectura es fiable: 72% de los defectos se contienen en sprint y solo el 28% escapa a producción. La taxonomía Defect/Bug bien aplicada es justo lo que hace creíble esta métrica.
Con 26 Defects contenidos y 10 Bugs escapados, el 28% refleja un shift-left que funciona: la mayoría de las fallas se cazan antes del release. La distinción Bug/Defect usada con disciplina es lo que hace que esta métrica sea fiable en vez de un artefacto de sub-tipado.
el home de producto en jira
El Dashboard que Producto Quiere Ver
Salud general
Gadgets: por type, por status (lifecycle slice), Escape Rate. listo en ShopFlow
Gravedad & causa
Pie por Severity, por Root Cause, por Error Type. listo en ShopFlow
Ownership
Por Component + Reopen trend + Aging. listo: Components al 100%
El objetivo final
Una página donde el PO/PM abre Jira y, sin preguntar a nadie, ve: cuántas incidencias vivas, qué tan graves, qué parte de la app sufre, si el fix mejora. La gestión de incidencias se vuelve transparente.
Cerrar el arco: el dashboard NO es de pruebas (eso es otra presentación) — es de gestión de incidencias. En ShopFlow los tres bloques se construyen enteros porque cada campo está relleno: salud, gravedad/causa, ownership.
leyenda · antes del dashboard
Cómo Leer Estos Gráficos
Donut / Pie
Proporción de un total; las partes suman 100%. "¿Cómo se reparte el total?"
Barras
Comparar la magnitud entre categorías. "¿Cuál es mayor?"
Barra apilada
La composición de UN total dentro de una sola barra. "¿De qué se compone esto?"
Gauge (medidor)
Un valor único contra su máximo/meta (un %). "¿Qué tan cerca del tope?"
| Término | Qué es | Ejemplo en este dashboard |
|---|
| Rate / Tasa | Proporción expresada de 0 a 100% | Escape Rate = fugados / total |
| Ratio | Relación entre dos cantidades | Rejection Ratio = ruido / total |
| Distribución | Cómo se reparte el conteo entre categorías | por Severity, por Root Cause… |
| Índice ponderado | Σ(peso × conteo) / total — no todo pesa igual | Severity Index: una crítica pesa más que una menor |
| Slice "Sin asignar" | La porción de datos faltantes; mostrarla = honestidad | si un campo quedara vacío iría aquí (muted) — en ShopFlow no aplica: todo relleno |
Slide-glosario: que nadie se pierda con donut/gauge/barra apilada antes de ver el dashboard. Idea clave a verbalizar: cada forma responde una pregunta distinta — proporción (donut), comparación (barras), composición (apilada), valor-contra-meta (gauge). El slice "Sin asignar" (muted) es el recurso honesto para cuando un campo queda vacío — pero en ShopFlow no aparece, porque todo está relleno. Los íconos son los mismos componentes CSS que verán a tamaño completo en los 3 dashboards siguientes.
dashboard en vivo · bloque 1/3 · ejemplo ShopFlow
Dashboard · Salud General
¿Detenemos los defectos antes de que escapen a prod?
métrica · Defect Escape Rate
Shift-left funciona: 72% se contiene en sprint — Escape Rate 28%, sano.
¿De qué se compone la familia de incidencias?
métrica · Type split (40 total)
Defect26
Bug10
Improvement4
Defects (26) > Bugs (10): se caza antes de release.
¿En qué punto del ciclo están?
métrica · Status lifecycle (40 total)
Closed26
In Progress6
Ready For QA5
Open3
26 cerradas; 14 vivas avanzando por un flujo sano.
Bloque 1 del dashboard blueprint materializado, con la data completa de ShopFlow. Escape Rate (donut): 72% contenido en sprint, 28% escapa — shift-left sano. Type split: Defect domina (26 de 40) → se caza antes del release. Lifecycle (barra apilada): 26 Closed + 14 vivas (6 In Progress, 5 Ready For QA, 3 Open), todas en flujo normal. Los tres gadgets se dibujan enteros porque type y status están al 100%.
dashboard en vivo · bloque 2/3 · ejemplo ShopFlow
Dashboard · Gravedad & Causa
¿Qué tan grave es lo que encontramos?
métrica · Severity dist. (40 total)
Crítica4
Mayor11
Moderada17
Menor8
Mayoría Moderada/Mayor; 4 críticas bajo control.
¿Por qué fallamos?
métrica · Root Cause (40 total)
Lógica código15
Req. ambiguo9
Datos/config7
Integración6
Validación3
Lógica de código domina → foco de mejora de proceso.
¿Qué clase de fallas dominan?
métrica · Error Type (40 total)
Funcional17
UI9
Validación7
Performance5
Seguridad2
Funcional domina; UI y validación siguen.
Bloque 2 del dashboard, con la data completa de ShopFlow — Severity, Root Cause y Error Type están al 100%, así que ninguna gráfica necesita slice "Sin asignar". Severity: mayoría Moderada (17) / Mayor (11), solo 4 críticas bajo control. Root Cause: lógica de código domina (15) → foco de mejora de proceso. Error Type: funcional domina (17), seguido de UI y validación.
dashboard en vivo · bloque 3/3 · ejemplo ShopFlow
Dashboard · Ownership & Proceso
¿Qué parte de la app falla más?
métrica · Defectos por Component (40 total)
Checkout11
Auth8
Search7
Cart6
Profile5
Notifications3
Checkout y Auth concentran los defectos → dónde reforzar.
¿Qué tan bueno es el fix? (¿reabrimos?)
métrica · Reopen Rate
8%
2 reabiertos / 26 cerrados
Solo 8% se reabre: fixes sólidos.
¿Cuánto ruido genera el reporte?
métrica · Rejection Ratio (40 total)
7% de ruido: reportes limpios (2 duplicados + 1 rechazado).
Bloque 3 del dashboard, con la data completa de ShopFlow. Components (gráfico 1) se dibuja entero: Checkout (11) y Auth (8) concentran los defectos → ahí reforzar testing y ownership. Reopen Rate (gauge): 2/26 = 8%, fixes sólidos. Rejection Ratio (donut): 3 descartados (2 Duplicated + 1 REJECTED) = 7% de ruido → reportes limpios. Cierra el arco: los tres gadgets viven porque el equipo rellenó todos sus campos.
quiz · parte 3
Métricas & Dashboards
Q1El PM pregunta: "¿estamos atrapando los problemas antes de que lleguen al usuario?". ¿Qué métrica responde?
ADefect Escape Rate = Bugs / (Bugs+Defects)
BSeverity Index
CDefect Age
Defect Escape Rate. La proporción Bug/Defect mide exactamente la fuga, porque Defect=en sprint y Bug=post-release. Es la métrica núcleo del shift-left.
Q2El equipo de producto abre el dashboard de ShopFlow y pregunta "¿qué parte de la app concentra más defectos?". ¿Qué módulo lidera?
ACheckout (11 defectos)
BNotifications (3 defectos)
CNo se puede saber: falta rellenar Components
Checkout (11). Como ShopFlow rellena Components en las 40 incidencias, el gráfico de ownership se dibuja entero: Checkout y Auth (8) lideran → ahí reforzar. Si el campo estuviera vacío, la respuesta sería C — pero esa es exactamente la disciplina que este equipo no descuidó.
Conecta las ideas clave de la parte 3: escape rate como métrica estrella (28% sano) y el pago de la higiene de campos (Components al 100% → dashboard de ownership legible, Checkout lidera). Una métrica más para nombrar: si muchos tickets se reabren vía "back" tras cerrarse, eso es Reopen Rate alto = fixes que no resolvieron de verdad — en ShopFlow es solo 8% (ver slide 28).
checklist de higiene
Disciplina de Defect Management
- Usa el work type correcto — Defect en sprint, Bug post-release. Es lo que hace medible el escape.
- Rellena Components siempre — sin él, no hay dashboard de ownership.
- Severity ≠ Priority — dos ejes, dos campos, dos preguntas.
- Evidencia siempre — captura, trace o log embebidos.
- Fija Root Cause tras el RCA — alimenta la mejora de proceso.
- Triagea con honestidad — Duplicated/WAD/CNR mantienen limpia la señal.
- Enlaza US ↔ incidencia — causes / is blocked by para trazabilidad.
- Primero la pregunta, luego la métrica — nunca el dashboard por el dashboard.
El checklist operativo. Cada punto es una palanca directa sobre la calidad de las métricas posteriores. La disciplina al reportar HOY es la métrica fiable de MAÑANA.
para llevar
Tres Ideas que se Quedan
1
El momento define el tipo
Bug = defecto = síntoma idéntico. Lo que cambia es cuándo nace y qué le dice al equipo. Defect contiene; Bug se fuga; Improvement mejora.
2
Un workflow, los mismos campos
El estándar de calidad: las tres incidencias comparten esquema. La disciplina al rellenar — sobre todo Components — es la materia prima de toda métrica.
3
Mide preguntas, no datos
Un dashboard es un set de respuestas. Pregunta primero, métrica después, campo al final. Escape Rate es la estrella del shift-left.
El cierre de los tres conceptos. Si el público recuerda solo tres cosas, que sean estas.
Reporta con Disciplina. Mide con Preguntas.
Distinguir (Bug/Defect/Improvement) → Gestionar (un workflow, los mismos campos) → Medir (de campos rellenos a dashboards que el equipo de producto entiende de un vistazo).
← → navegar · S notas del orador · O resumen · T tema
Cierra atando las tres partes. La gestión de incidencias bien hecha es lo que convierte tickets sueltos en una imagen viva y honesta de la salud del producto.