Idea principal

Leída al pie de la letra, la fórmula anuncia un software sin defectos —algo que ningún equipo entrega—, y la objeción cae de inmediato. El objetivo está en otra parte: cero defectos conocidos sin decidir.

Lo desconocido queda fuera de alcance. Lo que se persigue es evitar la aceptación permanente y organizada de defectos que se conocen. Cuando llega una señal —un aviso del soporte, una regresión detectada en una aplicación como My Porsche—, el equipo decide: ¿es un defecto? Si lo es, se corrige. Si no, se saca de la gestión de defectos: mejora, petición de capacidad, malentendido, tema interesante pero fuera de prioridad.

Lo que la regla prohíbe es el tercer estado: "sabemos que es un defecto, lo guardamos en una lista para más adelante". Un defecto conocido que se conserva sin decidir ha dejado de ser un defecto de software; es un defecto de decisión.

Por qué es importante

Esto le da la vuelta a la objeción más corriente. No se promete la perfección, se prohíbe un estado intermedio, y el estado intermedio sí es perfectamente alcanzable.

También desplaza la medida. Ya no se cuentan los defectos del producto, se cuentan los defectos conocidos sin decisión. La primera cifra depende del sistema de producción; la segunda solo depende de la organización.

Matices y límites

La regla no dice nada sobre la calidad de las decisiones tomadas. Un equipo que recalifica masivamente como no-defecto cumple la letra y vacía el sentido.

Y solo afecta a lo conocido: un producto poco instrumentado, sin soporte estructurado, muestra pocos defectos conocidos sin tener menos.

Preguntas abiertas

• ¿Cómo detectar una recalificación de conveniencia, que cierra la decisión sin tratar el dolor?