Un roadmap lleno de fechas no es un roadmap: señales de que trabajas en una feature factory

Hace un tiempo, en una gran empresa con plan financiero anual, revisamos con sus equipos de producto lo que se había comprometido a principios de año. Un trimestre concreto no llegaba al 50% de lo prometido. La conversación en la sala fue la esperable: por qué llegamos tarde, qué equipo se retrasó, cómo recuperamos en el siguiente trimestre.

Nadie hizo la otra pregunta: qué tenía que haber cambiado en el negocio con lo que sí se había entregado. Esa ausencia, más que el retraso, es la señal de una feature factory: una organización que mide el éxito por lo que entrega, y no por el cambio que esas entregas producen. Y a esa organización no la habían llevado ahí ni el talento de sus equipos ni unos stakeholders caprichosos, sino unas pocas decisiones sobre cómo preparaba, compartía y medía su roadmap.

Un roadmap lleno de soluciones y fechas es un plan de entrega

Abrid el roadmap de vuestra organización y contad. ¿Cuántos items son soluciones con fecha —un módulo, una integración, un rediseño, para el tercer trimestre— y cuántos son problemas a resolver o resultados a mover? En la mayoría de los roadmaps que hemos revisado, la primera lista se lleva casi todo el documento.

Un documento así no es un roadmap. Es un plan de entrega. Sirve para coordinar equipos y responder a “¿cuándo estará?”. No sirve para decidir, porque le falta lo más importante: el racional de por qué cada item importa para los usuarios y para el negocio.

Sin ese racional, dos cosas se vuelven imposibles. La primera, discutir el orden: si nadie ha escrito qué mueve cada item, la priorización se decide por quién lo pidió y con cuánta insistencia. La segunda, quitar algo: no puedes descartar por falta de impacto un item cuyo impacto nunca se enunció.

Marty Cagan describe el cambio de modelo con una frase sencilla: “La organización mueve su foco de features concretas lanzadas en fechas concretas a resultados de negocio”.

Las fechas no desaparecen; en una empresa con regulación y contratos, algunas son innegociables. Lo que cambia es que dejan de ser la única medida de éxito. Y este es solo uno de los caminos por los que un equipo termina convertido en una fábrica de funcionalidades.

Qué es una feature factory y quién popularizó el término

John Cutler popularizó el término feature factory en 2016, a partir de un artículo titulado 12 Signs You’re Working in a Feature Factory. La imagen es la de una fábrica: entran peticiones, salen features, y el indicador de rendimiento es cuántas salen y cuándo.

De sus doce señales, tres describen casi todas las organizaciones con las que hemos trabajado antes de empezar.

• Los roadmaps muestran una lista de features, no áreas de foco ni outcomes.
  
• Teatro del éxito alrededor de la entrega, con poca discusión sobre el impacto.
  
• No se retiran features; la medida principal de éxito son las features entregadas, no los outcomes conseguidos.

A esas tres añadimos las que vemos con más frecuencia en la empresa española: un Discovery que existe pero no tiene consecuencias —se entrevista, se aprende y el roadmap no se mueve—, stakeholders que llegan con la solución ya decidida y métricas de equipo que solo cuentan entregas: story points, features cerradas, porcentaje del plan cumplido.

Cuando el éxito se mide por la fecha

Volvamos a la sala del principio. Aquel trimestre por debajo del 50% dolió, y con razón: había compromisos con negocio y con clientes. Pero la reacción de la organización fue reveladora. Se pidió más previsibilidad, más detalle en las estimaciones, más control del plan.

Entregar menos del 50% no era el problema. El problema era que nadie sabía qué tenía que haber cambiado con el 50% que sí se entregó. Cuando el éxito se mide por la fecha, cumplir el plan y generar resultados se confunden, y la organización invierte toda su energía en lo primero.

Aquí conviene ser justos con los stakeholders. En una empresa con plan financiero anual, el presupuesto se aprueba por iniciativa y con fecha. Un director de área que quiere resolver un problema de su negocio solo tiene una manera de conseguir capacidad: pedir una feature concreta y meterla en el plan.

El sistema le invita a hablar de soluciones, y él responde al sistema. Culparle de pedir features es como culpar al agua de bajar por la pendiente. Y al equipo le pasa lo mismo: si lo que se reporta a comité es el porcentaje de plan cumplido, lo racional es proteger la fecha, no cuestionar el item.

Lo que cuesta trabajar así

Hay datos de fuentes distintas que apuntan en la misma dirección.

Pendo, en su informe de adopción de features de 2019, analizó datos agregados de uso de 615 suscripciones de clientes y estimó que “el 80% de las features del producto de software medio se usan rara vez o nunca”.

A partir de esos datos, estimó además que las empresas cloud cotizadas podían haber invertido “hasta 29.500 millones de dólares— en desarrollar features infrautilizadas”.

Ronny Kohavi publicó en 2013, con datos de Microsoft, que “solo un tercio de las ideas probadas en Microsoft mejoró las métricas para las que se diseñaron”.

Y eso en una organización que las medía. En una feature factory, los dos tercios restantes corren el riesgo de darse por buenos simplemente porque llegaron a producción o cumplieron la fecha.

La consecuencia para quien dirige producto o tecnología es directa. Si el roadmap se llenó con soluciones sin racional, existe el riesgo de que una parte importante de la capacidad del año se esté dedicando a cosas cuyo impacto desconocemos, y el sistema no tenga forma de enterarse.

La fábrica funciona a pleno rendimiento. Lo que fabrica es la incógnita.

Las pocas decisiones que te convierten en una fábrica de funcionalidades

Nadie decide ser una feature factory. Se llega por acumulación de decisiones pequeñas que parecen operativas y no lo son. En nuestra experiencia, hay dos que pesan más que el resto.

La primera es cómo preparas y compartes el roadmap. Si el documento que circula por la organización lista soluciones con fecha, eso es lo que la organización discutirá, pedirá y medirá.

Una prueba sencilla: ¿cuándo fue la última vez que en una conversación de priorización un item se movió o se cayó del roadmap porque alguien dudó de su impacto? Si la respuesta es “no recuerdo”, la priorización se está haciendo sobre esfuerzo y urgencia, no sobre valor.

Cutler señala exactamente este desajuste: “entre el rigor al priorizar y el rigor al validar si era lo correcto”.

La segunda es si has tenido, o no, una conversación de capacidad con tus stakeholders. El plan anual suele asumir que el 100% del equipo está disponible para el plan. No lo está. Una parte del tiempo se va a corregir bugs, otra a operar lo que ya existe —BAU—, otra a deuda técnica.

Stripe estimó en 2018 que el desarrollador medio dedica más de 17 horas semanales a mantenimiento, como depurar y refactorizar, y unas cuatro horas semanales a “bad code”, un coste que el informe estima en cerca de 85.000 millones de dólares de coste de oportunidad anual.

Si vuestros stakeholders no saben cuánto tiempo del equipo se va a cada tipo de trabajo, el compromiso del trimestre nace roto.

El equipo lo sabe, el plan no. Y el trimestre por debajo del 50% llega solo.

Hay una tercera decisión, más silenciosa: qué se celebra en la demo del trimestre, lo que se entregó o lo que cambió.

Cómo salir del modelo feature factory: por dónde empezamos

Con el cliente del principio no empezamos por cambiar la herramienta de roadmap ni por dar formación en OKR. Empezamos trabajando con sus equipos para que definieran y refinaran sus compromisos trimestrales a partir de los objetivos que tenían que cumplir, no del plan de acción que alguien había escrito meses antes.

El plan pasó a ser una hipótesis de cómo llegar al objetivo, y por tanto algo que podía cambiar cuando aparecía evidencia. El trabajo sigue en marcha, así que el relato termina ahí: en el cambio de práctica, no en un resultado que aún no hemos medido.

Los pasos que aplicamos, en este orden:

1. Un racional por item. Cada elemento del roadmap del próximo trimestre lleva dos líneas: qué cambia para el usuario y qué cambia para el negocio, con la métrica que lo demostraría. Lo que no puede escribirse en dos líneas vuelve a Discovery.
   
2. Compromisos como resultados, plan como hipótesis. El equipo se compromete con el objetivo —por ejemplo, reducir el tiempo de alta de nuevos clientes— y propone las features como su mejor apuesta actual para llegar. Ante el comité se defiende el objetivo; las features pueden cambiar.
   
3. Una conversación de capacidad con números. Antes de comprometer nada, el equipo enseña a sus stakeholders cuánto tiempo del trimestre anterior se fue a bugs, BAU y deuda técnica, y cuánto queda para el plan. Cifra real, no estimación optimista.
   
4. Una revisión de lo entregado. Un mes después de cada entrega relevante, se mira la métrica que se escribió en el paso 1. Lo que no la movió se discute abiertamente, y se retira al menos una cosa por trimestre. Es la señal más visible de que se ha dejado de fabricar por fabricar.

Ninguno de estos pasos exige reorganizar la empresa ni esperar al próximo ciclo presupuestario. Exigen que alguien con autoridad acepte que el plan es una hipótesis y que el porcentaje cumplido deje de ser la métrica principal en el comité.

El filtro para tu próximo lunes

Coged el roadmap del trimestre en curso e, item por item, intentad completar una frase:

“Esto está aquí porque cambiará [métrica] para [usuario o negocio], y lo quitaríamos si [condición]”.

Contad cuántos items la completan. Si la completan casi todos, tenéis un roadmap, y las fechas son un detalle de ejecución.

Si la completan menos de la mitad, tenéis un plan de entrega, y el porcentaje que consigáis cumplir dirá poco sobre si el año ha ido bien.

Ese recuento es el primer número que llevaríamos a la siguiente conversación con stakeholders.

Preguntas frecuentes

¿Qué es una feature factory?

Una organización de producto que mide su éxito por las features que entrega y las fechas que cumple, no por el cambio que esas features producen en los usuarios o en el negocio. El término lo acuñó John Cutler en 2016.

¿Cuál es la diferencia entre un roadmap y un plan de entrega?

Un plan de entrega lista soluciones con fecha y responde a «cuándo estará». Un roadmap añade el racional: qué problema resuelve cada item, qué métrica debería mover y qué haría que se retirase. Sin ese racional no se puede priorizar por impacto ni quitar nada.

¿Cómo salir de una feature factory sin reorganizar la empresa?

Empezando por el roadmap del próximo trimestre: un racional por item, compromisos expresados como resultados con el plan como hipótesis, una conversación de capacidad con cifras reales y una revisión de lo entregado un mes después. Son cambios de práctica, no de organigrama.