Idea principal

La roadmap recoge las funcionalidades previstas. Ahí los plazos son visibles, ahí se hacen los arbitrajes, ahí se adquieren los compromisos. Los defectos se quedan al margen, como una carga implícita que se tratará "cuando haya tiempo".

Sin embargo consumen la misma capacidad: tiempo de desarrollo en el momento de la corrección, tiempo de soporte cada vez que hay que explicar un apaño, atención de producto cada vez que se relee un ticket. Y consumen lo que no se planifica: la confianza del cliente que se topa dos veces con el mismo comportamiento, la credibilidad interna de un equipo del que se sabe que los puntos molestos no se mueven.

No anotarlos no los hace gratis. Los hace invisibles justo en el único sitio donde se arbitra.

Capa aportada por "La calidad pertenece a quienes entregan" (2026-06-03). La misma constatación se vuelve contra la objeción de planificación que se opone a toda regla de calidad: traer de vuelta a un desarrollador sobre su propio defecto altera el sprint, retrasa la funcionalidad siguiente, cuesta de forma visible. La calidad consume capacidad, y excluirla del plan no la hace gratis: solo saca el gasto del único sitio donde se compara con los demás.

Por qué es importante

Esto deshace la oposición entre roadmap y calidad, que hace pasar las funcionalidades por el trabajo de verdad y los defectos por un ruido a gestionar alrededor. Ambos tiran del mismo presupuesto; solo uno se cuenta.

La cuestión no es, por tanto, encontrar tiempo para los defectos, sino hacerlos entrar en el plan donde el tiempo se reparte.

Matices y límites

Anotar no basta. Una cola de defectos es una anotación, y puede quedarse ahí indefinidamente sin arbitraje real.

Y la carga no es uniforme: un defecto que nunca se encuentra no consume nada mientras nadie se lo cruce.

Preguntas abiertas

• ¿Cómo cifrar la carga de soporte de un defecto antes de haberlo corregido?