Escrito originalmente en francés. Traducido por IA — se ha preservado el sentido, no la prosa.
Una política de cero bugs permite dejar de gestionar stocks de defectos.
Pero no es suficiente.
Si el equipo corrige bugs más rápido sin cambiar cómo produce, sigue en un bucle de reparación. El backlog baja, luego vuelve a subir. Las urgencias desaparecen, luego vuelven. El soporte respira, luego se satura de nuevo.
El verdadero problema está antes.
¿Cómo evitar producir tantos bugs?
No se reducen los bugs solo con una mejor organización del triaje. Se reducen responsabilizando a quienes entregan, rechazando especificaciones demasiado vagas, probando antes, y dando a QA un rol de política de calidad en lugar de red de seguridad.
La calidad no es algo que se delega a posteriori.
La calidad pertenece a quienes entregan.
Corregir los bugs de otros diluye la responsabilidad
En muchos equipos, la organización se parece a esto.
Un desarrollador trabaja en una feature. La entrega. Pasa a otro tema. Aparecen bugs. Como ya está ocupado, alguien más los toma. Un desarrollador disponible. Una persona de rotación. Un equipo de soporte técnico. A veces un equipo dedicado a los bugs.
Sobre el papel, parece eficiente. Se optimiza la disponibilidad.
En realidad, se diluye la responsabilidad.
Quien introdujo el defecto no siempre ve el coste de lo que entregó. Quien corrige debe entender un contexto que no creó. El tiempo perdido se vuelve colectivo, por tanto menos visible. Y cada uno puede protegerse detrás de una frase clásica: "Ya pasé a otra cosa."
Este sistema crea una mala señal.
Dice implícitamente: puedes entregar, y si algo se rompe, alguien más lo absorberá.
Aunque nadie lo formule así, el efecto existe.
Quien crea el bug lo corrige
La regla más sana es simple: quien crea el bug lo corrige.
No para castigar.
No para humillar.
Sino porque la responsabilidad de corrección debe permanecer ligada a la responsabilidad de producción.
Si un desarrollador sabe que sus bugs le volverán directamente, entregará de forma diferente. Probará más. Revisará mejor. Evitará empujar un cambio frágil solo para cumplir un plazo. Aceptará menos fácilmente producir sobre una ambigüedad fuerte.
No es una garantía. Pero es un incentivo sano.
Por supuesto, hay excepciones.
El desarrollador puede estar ausente. El bug puede venir de varias contribuciones. El problema puede estar en código legacy. La responsabilidad puede ser compartida. Otra persona puede estar mejor posicionada para corregir.
Estos casos existen.
Pero no deben convertirse en una excusa para abandonar la regla general.
En la mayoría de los casos, si un desarrollador creó el defecto, debe corregirlo. Aunque haya pasado a un tema importante. Aunque eso perturbe el planning. Aunque ralentice la siguiente feature.
La calidad consume capacidad. Ocultarlo no la hace gratuita.
Responsabilidad no es culpa
Hay que distinguir aquí entre responsabilidad y cultura del blâme.
Responsabilizar no significa buscar un culpable. No significa señalar públicamente a quien rompió algo. No significa crear miedo a entregar.
Una cultura del blâme destruye la calidad. La gente esconde los problemas, minimiza los defectos, evita tomar riesgos, documenta para protegerse, y el equipo aprende más lento.
La responsabilidad útil es diferente.
Dice: eres dueño de lo que entregas, por tanto participas en su corrección, en su aprendizaje y en su mejora.
No se busca castigar. Se busca cerrar el bucle.
El desarrollador que corrige su propio bug entiende mejor qué se rompió. Ve dónde su comprensión era insuficiente. Ve si faltaba el test. Ve si la spec era vaga. Ve si la arquitectura hacía probable el error.
Es ese bucle el que crea calidad.
Los desarrolladores no son ejecutores
Esta responsabilidad supone otra idea: los desarrolladores no son ejecutores.
No están ahí para "escupir código".
Son creadores de valor.
El Product Manager es responsable de las decisiones de producto: por qué este tema, para qué público, con qué impacto, en qué prioridad. Pero los desarrolladores son responsables de la calidad técnica, del código base y de lo que entregan.
Cada uno tiene su zona de responsabilidad.
Si el Product Manager toma una mala decisión de producto, debe asumirla.
Si los desarrolladores entregan código frágil, poco probado, mal comprendido o difícil de mantener, también deben asumirlo.
Esto no significa que las responsabilidades estén aisladas. Se hablan. Un buen producto se construye en el diálogo entre decisiones de producto, viabilidad, uso, calidad y restricciones técnicas.
Pero el diálogo no debe servir para disolver la responsabilidad.
Una especificación demasiado vaga debe rechazarse
Un defecto no siempre viene de código malo.
Puede venir de una especificación incompleta, de una decisión de producto ambigua, de un caso no pensado, de un flujo mal comprendido.
Pero eso no significa que nadie sea responsable.
Si una spec es demasiado vaga, los desarrolladores deben poder rechazar producir.
Rechazar no significa bloquear. Significa: el marco no está suficientemente claro para entregar correctamente.
Es mejor pedir una aclaración antes de codificar que crear una funcionalidad inestable que luego generará bugs, soporte, rework y discusiones interminables.
Un desarrollador responsable no se limita a ejecutar una petición ambigua. Busca entender el comportamiento esperado, los casos límite, los criterios de aceptación, los riesgos, los datos, las dependencias.
Si no puede entender qué debe entregar, no puede garantizar la calidad de lo que entrega.
La responsabilidad de producto y la responsabilidad técnica convergen aquí: el Product Manager debe clarificar la decisión de producto; los desarrolladores deben rechazar transformar una ambigüedad fuerte en código frágil.
El TDD: el qué antes del cómo
El TDD, Test Driven Development, es una respuesta concreta a esta lógica.
En lugar de escribir primero el código y verificar después si funciona, se escribe primero el test.
El test describe el qué.
El código implementa el cómo.
Es una distinción importante. El test formaliza una parte de la especificación: este es el comportamiento esperado, esto es lo que debe seguir siendo cierto, esto es lo que no debe romperse.
Luego, el código puede evolucionar. Puede refactorizarse. Puede interactuar con nuevos datos. Otras funcionalidades pueden llegar alrededor. Pero si el comportamiento esperado se rompe, el test falla.
Idealmente, el problema se detecta en el entorno del desarrollador o en calificación, no en producción.
El TDD no elimina todos los bugs. No reemplaza la reflexión de producto. No transforma una spec mala en buen producto.
Pero cambia algo esencial: obliga a hacer verificable una parte de la calidad antes de la implementación.
En una organización que quiere menos bugs, esta disciplina importa.
QA no es una red de seguridad
QA no debe ser el lugar donde los desarrolladores depositan su responsabilidad de calidad.
Si QA es solo una red de seguridad al final de la cadena, llega demasiado tarde. Prueba lo que debería haberse pensado, clarificado, automatizado o evitado antes. Se convierte en el último dique antes de producción, es decir, el lugar donde la organización externaliza sus defectos.
No es suficiente.
QA puede jugar un rol mucho más estratégico.
Puede definir los criterios de calidad. Las políticas de test. Los estándares de entrega. Los umbrales de regresión aceptables. Los riesgos a cubrir. Las zonas del producto a asegurar. Los tests a automatizar. Las señales que muestran si un equipo entrega mejor o peor.
Con la inteligencia artificial y la automatización, este rol se vuelve aún más importante.
Como en muchos oficios, la IA permite reducir parte del trabajo operativo repetitivo para concentrarse más en la estrategia. Para QA, eso significa menos tests manuales repetitivos, menos regresiones rejugadas pantalla a pantalla, y más reflexión sobre el sistema de calidad.
El valor de QA se desplaza.
Menos: repetir mecánicamente las mismas verificaciones.
Más: definir qué verificar, por qué, con qué nivel de automatización, sobre qué riesgos, con qué criterios.
QA no reemplaza la responsabilidad de los desarrolladores. Construye el marco en el que esa responsabilidad se vuelve practicable, medible y duradera.
Las métricas deben servir a la calidad
Medir puede ser útil.
El rework, por ejemplo, puede mostrar que un equipo vuelve demasiado seguido sobre los mismos temas. El cycle time puede revelar que las revisiones ralentizan mucho la entrega. Las regresiones pueden mostrar que ciertas zonas del producto se rompen con demasiada frecuencia.
Estas señales son útiles si sirven para mejorar el sistema.
Se vuelven tóxicas si recrean una obsesión administrativa.
No sirve de nada pasar tiempo infinito averiguando si un defecto es un bug, una feature, una mejora, una revisión, una anomalía QA u otra cosa, si esa calificación no cambia la decisión.
La medición debe iluminar.
No debe reemplazar el juicio.
El objetivo sigue siendo simple: sacar rápido lo que importa, con un nivel de calidad aceptable, y reducir el dolor real.
El legacy del futuro
El legacy existe.
Todos los equipos deben, en algún momento, trabajar con código antiguo, decisiones pasadas, arquitecturas frágiles, dependencias mal documentadas, decisiones que quizás tenían sentido ayer y que complican todo hoy.
No siempre se puede evitar el legacy existente.
Pero sí se puede evitar fabricar el legacy de mañana.
Un bug transferido a otra persona, una spec vaga aceptada sin discusión, un test nunca escrito, una regresión manual repetida sin automatización, una QA usada como red final, código entregado rápido pero mal comprendido: todo eso se convierte en legacy futuro.
Responsabilizar a los desarrolladores no lo soluciona todo. Pero cambia la trayectoria.
Cuando quien entrega posee la calidad de lo que entrega, produce de forma diferente. Cuando puede rechazar una spec demasiado ambigua, evita transformar lo vago en complejidad. Cuando el TDD formaliza parte de la especificación, el producto se vuelve más robusto. Cuando QA define una política de calidad, el sistema entero se vuelve más claro.
El legacy futuro no es una fatalidad.
Es a menudo el resultado de responsabilidades mal asignadas hoy.
Conclusión
Un equipo que quiere menos bugs no debe solo clasificarlos mejor.
Debe hacer la calidad imposible de delegar.
La política de cero bugs trata el stock de defectos conocidos. Pero la calidad de entrega impide recrear ese stock. Para eso, cada uno debe asumir su responsabilidad.
El Product Manager posee la decisión de producto.
Los desarrolladores poseen la calidad técnica de lo que entregan.
QA construye el marco de calidad: criterios, estándares, riesgos, tests, automatización.
Y el equipo, colectivamente, debe rechazar las organizaciones donde los bugs siempre se convierten en el problema de otro.
Responsabilidad no significa culpa. Significa ownership.
La calidad pertenece a quienes entregan, porque son ellos quienes pueden construirla en el momento en que cuesta menos: antes de que el bug exista.
Para saber más
Cero bugs: dejemos de gestionar inventarios de defectos Code centric