Escrito originalmente en francés. Traducido por IA — se ha preservado el sentido, no la prosa.
Porsche publicó un caso práctico interesante sobre la zero bug policy, aplicada a My Porsche. La idea puede parecer poco realista a primera vista. Todo el mundo sabe que un software sin bugs no existe. Hasta los mejores productos tienen defectos, regresiones, comportamientos inesperados, casos límite.
Pero no es ese el tema.
Una política de cero bugs no promete código perfecto. Apunta a otra cosa: dejar de aceptar que los bugs conocidos se conviertan en un inventario permanente que se prioriza, reclasifica y pospone.
El verdadero problema de los bugs no es solo que existan. El verdadero problema es que la organización se acostumbra a conservarlos.
Se abre un ticket. Se le asigna una prioridad. Se clasifica. Se revisa dos semanas después. Se cambia su prioridad. Se habla de él en comité. Se pospone porque una feature del roadmap es más urgente. Luego un cliente se queja, el bug resurge y el equipo trata con urgencia lo que debería haber decidido con claridad desde hace tiempo.
En ese momento, el bug ya no es solo un defecto del software. Es un defecto de decisión.
Los bugs no cuentan hasta la urgencia
En muchas organizaciones, los bugs viven en un extraño limbo.
Existen. Todo el mundo los ve. Consumen energía. Irritan a los clientes. Saturan el soporte. Pero no cuentan de verdad en la planificación.
El roadmap avanza. Las features previstas llegan. Los plazos son visibles. Los arbitrajes se hacen sobre los temas nuevos. Y los bugs se quedan a un lado, como una carga implícita que se tratará cuando haya tiempo.
Salvo que nunca hay tiempo.
Así que los bugs solo se vuelven prioritarios cuando son demasiado visibles: un cliente importante se queja, una demo se rompe, el soporte se satura, una regresión afecta un flujo crítico, un directivo tropieza con el problema.
Esta lógica opone artificialmente roadmap y calidad. Como si las features fueran el trabajo real y los bugs un ruido a gestionar alrededor. Pero un bug consume capacidad. También consume confianza del cliente, credibilidad interna, tiempo de soporte y atención de producto.
No contarlo no lo hace gratuito.
Qué significa realmente "cero bugs"
Una política de cero bugs no significa que no habrá nunca un bug.
Significa: cero bugs conocidos sin decisión.
El matiz es esencial. El objetivo no es eliminar lo desconocido. El objetivo es no organizar la aceptación permanente de defectos conocidos.
Cuando llega una señal, el equipo debe decidir rápidamente: ¿es un defecto o no?
Si es un defecto, se corrige.
Si no es un defecto, no se trata como bug. Puede ser una mejora. Puede ser una petición de feature. Puede ser un malentendido. Puede ser un tema interesante, pero fuera de prioridad.
En cualquier caso, hay una decisión.
Lo que la política de cero bugs rechaza es el tercer estado: "Sabemos que es un bug, pero lo guardamos en una lista para más adelante."
Ese "más adelante" suele ser el verdadero problema.
La trampa del backlog de bugs
Un backlog de bugs da una sensación de control.
Todo está listado. Cada bug tiene una prioridad. Algunos son blocker, otros major, minor, trivial. Se puede filtrar. Se puede ordenar. Se puede hacer un comité. Se pueden producir informes. Se puede decir que el tema está bajo control.
Pero priorizar un bug cada mes no es tratarlo.
A menudo es solo aceptar que siga ahí.
El inventario de bugs crea su propio trabajo. Hay que verificar si el bug sigue existiendo. Hay que saber si sigue siendo prioritario. Hay que saber si el cliente afectado sigue siendo cliente. Hay que saber si aún es reproducible. Hay que saber si debe pasar delante de otra anomalía. Hay que releer, reclasificar, replanificar.
La organización gasta energía en administrar defectos en lugar de restaurar la calidad.
Y lo más absurdo es que muchos de esos bugs nunca se corregirán.
Se sabe. El equipo lo sabe. El soporte lo sabe. El Product Manager lo sabe. Pero el ticket sigue abierto, porque cerrarlo equivale a asumir una decisión que nadie quiere tomar.
Una política de cero bugs obliga a esa decisión.
Dos decisiones: defecto o no defecto
La fuerza del enfoque de Porsche reside en su simplicidad.
En lugar de multiplicar las categorías, el equipo reduce la decisión:
defect: es un defecto, así que se corrige;no defect: no es un defecto, así que no se trata como bug.
Esta simplificación no significa que todo se vuelva brutal o automático. Siempre hay que entender el impacto, el contexto, el cliente, la frecuencia, la gravedad. Pero la discusión debe llevar a una decisión, no a una nueva categoría.
Una mejora puede ser útil sin ser un defecto.
Una petición de cliente puede ser pertinente sin ser un bug.
Un comportamiento puede ser frustrante sin ser prioritario.
Lo que importa es no ocultar el arbitraje detrás de una tipología.
Si es un defecto real, se trata. Si no lo es, se asume. Pero no se mantiene indefinidamente un bug conocido en una cola que sirve sobre todo para evitar decidir.
Bug o feature: al cliente le da igual
Desde el punto de vista del cliente, la distinción entre bug y feature tiene poco interés.
El cliente no se pregunta si sufre por un bug, por una feature ausente, por una feature mal hecha o por una feature que no responde a su necesidad. Siente un dolor.
Un software puede no tener ningún bug técnico y aun así no responder a la necesidad del cliente. El dolor sigue siendo real.
A la inversa, algunos bugs son objetivamente defectos, pero su impacto es bajo. Si el usuario tiene que hacer doble clic en un botón, no es ideal. Pero si, al mismo tiempo, una feature ausente le impide hacer una declaración fiscal o legal obligatoria, la ausencia de feature es más crítica que el bug menor.
Por eso la categoría del ticket no debe reemplazar el análisis del dolor.
La pregunta real no es: "¿Es un bug o una feature?"
La pregunta real es:
- ¿qué dolor genera?
- ¿para quién?
- ¿con qué frecuencia?
- ¿con qué impacto?
- ¿es bloqueante?
- ¿es regulatorio?
- ¿genera soporte?
- ¿destruye la confianza?
La tipología puede ayudar a medir. No debe decidir en lugar del equipo.
Asumir una posición radical: sin tarjetas de bug separadas
Se puede ir más lejos.
En muchas organizaciones, yo suprimiría las tarjetas de bugs separadas en Jira o en las herramientas equivalentes. Solo mantendría tarjetas de trabajo.
¿Por qué?
Porque la separación bug / feature acaba creando a menudo dos sistemas de prioridad. Las features las pilota el roadmap. Los bugs los pilota la urgencia, el soporte, la presión del cliente o los comités de priorización. Y entre ambos, nadie mira realmente el conjunto desde el ángulo del dolor y el valor.
Una tarjeta de trabajo debería representar un problema que tratar.
A veces ese problema viene de un defecto del software. A veces de una capacidad ausente. A veces de un mal diseño. A veces de deuda técnica. Pero el arbitraje debe ser el mismo: ¿qué dolor, qué valor, qué impacto, qué decisión?
El daily de la mañana puede entonces servir para decidir qué cuenta realmente ahora. No para debatir veinte minutos sobre si algo es un bug, una feature, una mejora o un rework.
Claro que algunas organizaciones necesitan reporting de calidad. Se pueden mantener tags, métricas, categorías mínimas. Pero son información secundaria. No deben estructurar toda la decisión.
O se trata ahora, o se rechaza
El peor estado de un bug no es "no corregido".
El peor estado es "a priorizar más adelante".
"Más adelante" parece razonable. En realidad, a menudo es una manera educada de no decidir.
Algunos bugs deben tratarse de inmediato.
Otros deben rechazarse explícitamente. Se puede escribir una tarjeta mínima si se quiere conservar un rastro: "No lo haremos." Pero no hay que alimentar un backlog interminable de bugs para dar la impresión de que el tema sigue existiendo.
La disciplina es simple:
- si es un defecto real e importante, se corrige;
- si no es un defecto, se saca de la gestión de bugs;
- si es demasiado menor para tratarse, se asume;
- si vuelve a aparecer a menudo, se reevalúa con nuevas señales.
El objetivo no es volverse dogmático. El objetivo es obligar a la organización a producir una decisión.
La velocidad debe absorber la calidad
Corregir un defecto de inmediato puede afectar la velocidad.
Puede impedir terminar una feature. Puede perturbar el objetivo de un sprint. Puede posponer un tema del roadmap. Es incómodo, pero es normal.
La calidad consume capacidad.
Cuando un equipo ignora los bugs para preservar su velocidad, protege una métrica en detrimento del producto. Da la impresión de avanzar rápido, pero acumula fricción, soporte, deuda y desconfianza.
Una política de cero bugs hace visible ese coste.
Si los defectos ralentizan al equipo, no es la política de cero bugs la que crea el problema. Simplemente revela que el sistema produce demasiados defectos o los detecta demasiado tarde.
La respuesta correcta no es ocultar los bugs en un backlog. La respuesta correcta es mejorar el sistema de producción: tests, QA, TDD, automatización, clarificación de specs, responsabilidad de los desarrolladores.
Ese será el tema del próximo artículo.
Cómo empezar con un inventario existente
La dificultad llega cuando el equipo ya tiene un inventario de bugs.
Se puede tomar una opción radical: cerrar todos los bugs existentes y empezar de cero. Es limpio, pero políticamente difícil. Requiere una fuerte confianza interna y capacidad para asumir los rechazos.
También se puede tomar una opción progresiva.
El artículo de Porsche propone una lógica de reducción por etapas: priorizar una última vez, tratar un pequeño número de defectos por sprint y definir un nuevo cero temporal. Lo importante es que esta fase sea una transición, no una nueva forma normal de backlog.
Un método muy eficaz consiste en pasar por el soporte.
Cada semana, el soporte lista el top 3 de retornos de clientes relacionados con bugs.
Este top 3 se convierte en los 3 bugs prioritarios a tratar.
La semana siguiente, si uno, dos o tres bugs se han corregido, el soporte propone los siguientes.
Se avanza por Pareto. Se trata primero lo que aparece con más frecuencia, lo que duele más, lo que genera más carga de soporte. No se empieza repriorizar cien tickets. Se tratan los irritantes que realmente obstruyen la organización.
Este método tiene una doble ventaja.
Primero, reduce el dolor del cliente visible.
Después, descongestiona el soporte.
El soporte ve que sus retornos sirven para algo. El equipo de producto trata los problemas que realmente vuelven. Los desarrolladores no se dispersan en una lista abstracta. La dirección ve cómo desaparecen los irritantes.
Para salir de un inventario de bugs, no hay que empezar por repriorizarlo todo. Hay que tratar lo que vuelve con más frecuencia y duele más.
Las métricas útiles, sin obsesión administrativa
No se trata de suprimir toda medición.
Algunas métricas son útiles:
- el rework;
- el cycle time;
- las regresiones;
- los defectos encontrados antes de producción;
- los defectos encontrados en producción;
- la carga de soporte ligada a ciertos bugs.
Estas medidas pueden iluminar la calidad. Permiten ver si el equipo rehace demasiado a menudo su trabajo, si ciertos flujos se rompen regularmente, si una zona del producto genera demasiado soporte, si los defectos se detectan demasiado tarde.
Pero la métrica debe seguir siendo una herramienta.
Si el equipo pasa más tiempo calificando los defectos que mejorando el sistema, recrea el problema que quería resolver. Se reemplaza entonces el backlog de bugs por un backlog de categorías.
La finalidad no es medirlo todo. La finalidad es reducir el dolor y mejorar el flujo.
Conclusión
Una política de cero bugs no hace el software mágico.
Solo hace imposible ocultar los defectos conocidos detrás de un backlog.
Obliga a decidir. Hace visible la calidad. Impide que los bugs se conviertan en un inventario administrativo. Obliga a la organización a elegir: corregir, rechazar o reclasificar como otra cosa.
Es radical, pero es precisamente eso lo que hace útil el enfoque.
Mientras un bug puede dormir en un backlog durante seis meses, nadie es realmente responsable de la decisión. Una política de cero bugs devuelve esa responsabilidad al centro.
Pero no es suficiente por sí sola.
Si el equipo corrige rápido sin cambiar la manera en que entrega, seguirá en un bucle de reparación. El verdadero siguiente tema es la prevención: responsabilidad de los desarrolladores, especificaciones claras, TDD, QA, automatización, legacy futuro.
En otras palabras: una política de cero bugs trata el inventario. La calidad de entrega impide recrearlo.
Para saber más
La calidad pertenece a quienes entregan El backlog no es un vertedero: es una herramienta de acción