Idea principal

El esquema está extendido: un desarrollador entrega una funcionalidad, pasa al tema siguiente, y los defectos que aparecen los coge otra persona — un desarrollador libre, alguien de rotación, un equipo de soporte técnico, a veces un equipo dedicado a los bugs. El criterio de asignación es la disponibilidad.

Optimizar la disponibilidad parece una ganancia de planificación. El efecto real está en otra parte. Quien introdujo el defecto no ve nunca lo que costó su entrega. Quien corrige tiene que reconstruir un contexto que no ha creado, así que paga dos veces: la corrección y la comprensión. Y el tiempo perdido, ya colectivo, deja de ser imputable a una entrega concreta.

El sistema emite entonces una señal que nadie formula: se puede entregar rápido, y si eso rompe algo, otro lo absorberá. "Ya he pasado a otra cosa" se convierte en una respuesta admisible.

Por qué es importante

Esto desplaza el diagnóstico de un equipo que produce demasiados defectos: antes de mirar sus competencias o sus herramientas, se mira su regla de asignación de las correcciones. Una regla que optimiza el rendimiento a corto plazo puede ser lo que alimenta el flujo que hay que corregir.

Da también una lectura de los equipos "dedicados a los bugs": no son solo un modo de organización, son un dispositivo que corta el vínculo entre una entrega y su coste.

Matices y límites

La asignación por disponibilidad no siempre es evitable: un desarrollador que se ha ido, un defecto surgido de varias contribuciones, una zona de legacy sin autor identificable, una persona objetivamente mejor situada. Estos casos existen y no se discuten.

Lo que sí se discute es su uso: sirven a menudo para justificar la regla general inversa, en la que la disponibilidad decide por defecto en lugar de por excepción.

Preguntas abiertas

• ¿Cómo atribuir un defecto surgido de varias contribuciones sucesivas sin convertir la atribución en una investigación más costosa que la corrección?