El coste oculto de las features urgentes
Toda feature urgente tiene un coste que no aparece en la estimación: el trabajo que no se hace, la deuda que se acumula, y la pérdida de foco del equipo. Ese coste es real aunque nadie lo contabilice.
La urgencia en los equipos de producto tiene una característica peculiar: siempre llega con justificación suficiente. El cliente más importante lo ha pedido. El competidor lo acaba de lanzar. La dirección lo necesita para la presentación del mes que viene. El equipo de ventas no puede cerrar sin esto.
Cada una de esas razones puede ser legítima. El problema es que si cada razón legítima genera una interrupción urgente, el equipo nunca trabaja en lo que se había decidido que era más valioso.
Lo que la urgencia no declara
Cuando alguien declara que algo es urgente, lo que normalmente se comunica es el valor de lo que se pide. Lo que raramente se comunica es el coste.
El coste de insertar una feature urgente en el plan de trabajo no es solo el tiempo de desarrollarla. Es el coste de lo que se pospone. El trabajo que tenía su lugar en el sprint y que ahora se mueve al siguiente. La iniciativa de discovery que se interrumpe. El bug de menor urgencia que lleva semanas en cola y que sigue sin abordarse.
Ese coste existe. Pero como no aparece en ningún ticket, como no tiene cara ni historia de usuario, no se siente con la misma concreción que la urgencia que sí tiene nombre y stakeholder detrás.
La deuda de contexto que nadie calcula
Hay un coste adicional que es todavía más invisible: el coste cognitivo de la interrupción.
Cuando un equipo de desarrollo está trabajando en algo complejo y tiene que parar para incorporar una feature urgente, no pierde solo el tiempo de la feature urgente. Pierde el tiempo de retomar el contexto de lo que estaba haciendo antes. Pierde la coherencia del ciclo de trabajo. Y pierde algo más difícil de medir: la confianza en que las prioridades que se comunican son las que realmente importan.
Con el tiempo, los equipos que trabajan con urgencias frecuentes aprenden a no comprometerse demasiado con ninguna planificación porque saben que va a cambiar. Ese cinismo tiene un coste en calidad de trabajo que tampoco aparece en ninguna métrica.
Cómo evaluar si la urgencia es real
No toda urgencia es igual. La distinción útil para mí es entre urgencia con coste real de no actuar y urgencia sin ese coste.
Una urgencia con coste real de no actuar: hay un bug crítico que está afectando a un porcentaje significativo de usuarios activos, o hay una fecha legal de cumplimiento que no puede moverse. Esas urgencias son reales y merecen interrumpir lo planificado.
Una urgencia sin coste real de no actuar: el cliente importante lo quiere para su presentación del viernes, pero si no está para el viernes también puede ser para la semana siguiente. El competidor lo lanzó, pero no hay evidencia de que los usuarios estén eligiendo al competidor precisamente por eso.
La pregunta que ayuda a distinguirlas: ¿qué pasa exactamente si esto no se hace en los próximos siete días? Si la respuesta es difusa o especulativa, probablemente no es urgente. Es importante para alguien, pero importante y urgente no son lo mismo.
El protocolo que me funciona
Lo que he encontrado útil cuando llega una urgencia es hacer explícito el trade-off antes de comprometerse.
“Podemos hacer esto. Si lo hacemos ahora, tenemos que sacar del sprint esto otro. ¿Eso es aceptable?”
Esa conversación cambia la dinámica completamente. Pone el coste sobre la mesa. Hace que quien pide la urgencia sea partícipe de la decisión del trade-off, no solo beneficiario de la urgencia. Y muchas veces, cuando se ve el coste concreto, la urgencia de repente ya no es tan urgente.
Las opiniones expresadas son personales y no representan la posición de ninguna organización.