La reducción de lead time más dramática de Long Suciu no vino de un marco de procesos, un cambio de herramientas ni un rediseño organizacional. Vino de una conversación. En este segmento de su charla con Patrycja Radwanska en la serie Let’s Talk Operations, cuenta cómo un equipo de APIs de la industria de viajes pasó de ciclos de entrega de 52 semanas a entregar en un solo trimestre, y cómo el catalizador fue un director de producto que miró un backlog de funcionalidades por primera vez y dijo cinco palabras que lo cambiaron todo.
El contexto: uno o dos años era simplemente normal
El equipo para el que Suciu trabajaba como consultor construía APIs para la industria de viajes. Las aerolíneas conectaban con su producto para acceder a servicios de base de datos y clientes. El modelo de entrega era tradicional en el sentido más literal: un director de producto montaba un business case, aseguraba financiación para un proyecto de dos a tres años, dotaba de recursos a un equipo, y entonces el equipo construía todo el conjunto de funcionalidades antes de que nada fuera a producción.
Un ciclo de uno a dos años desde el inicio hasta el despliegue no se consideraba un problema. Se consideraba normal. Nadie lo había cuestionado porque nadie había tenido razón para hacerlo. La organización operaba con un modelo orientado a proyectos donde todo – financiación, recursos, planificación – se estructuraba en torno a entregar un paquete completo. La idea de entregar una pieza de ese paquete de forma independiente no había entrado en la conversación.
La intervención: mapear el recorrido, no los requisitos
El enfoque de Suciu no fue introducir terminología ágil ni imponer un marco. Fue hacer una pregunta diferente. En vez de “¿cuáles son los requisitos?” preguntó “¿cuál es el recorrido del cliente cuando usa vuestras APIs?” La distinción suena sutil. Sus efectos no lo fueron.
Cuando el equipo empezó a mapear el customer journey – cómo los usuarios interactuaban realmente con el producto, paso a paso – el conjunto monolítico de requisitos empezó a descomponerse naturalmente en funcionalidades discretas. No porque alguien decretara elementos de trabajo más pequeños, sino porque el propio recorrido tenía límites naturales. Cada paso en el recorrido correspondía a una capacidad distinta, y cada capacidad podía, en principio, existir de forma independiente.
El equipo, el product manager y finalmente el director de producto trabajaron juntos en este mapeo. Y entonces llegó el momento.
“En vez de tener que obtener todas las funcionalidades antes de lanzar al público, el director de producto vio una funcionalidad que podía usarse inmediatamente.”
El director de producto miró el backlog de funcionalidades que había emergido del mapeo del recorrido y reconoció algo que había sido invisible cuando el trabajo se enmarcaba como un paquete de requisitos: una de esas funcionalidades era útil por sí sola. Ahora mismo. Sin esperar a todo lo demás. No necesitaban el paquete completo. Necesitaban esa API, y la necesitaban este trimestre.
El cambio: del monolito a la entrega incremental
El equipo construyó y entregó esa única funcionalidad dentro del trimestre. Lo que había sido un mínimo de 52 semanas se convirtió en 13 semanas para la primera entrega. El cambio psicológico fue más significativo que la mejora de plazos. El director de producto había experimentado, de primera mano, la posibilidad de obtener valor antes, y una vez que esa experiencia aterriza, el viejo modelo de empaquetar todo en un proyecto plurianual deja de ser la opción por defecto. Empieza a parecer una elección, y no una particularmente buena.
La entrega incremental se convirtió en el nuevo modo. En vez de preguntar “¿cuándo estará todo listo?” la conversación pasó a “¿qué podemos entregar a continuación?” Cada funcionalidad posterior se dimensionó, construyó y entregó en su propia línea temporal. El producto global seguía tomando forma, pero a través de una serie de entregas utilizables en vez de un único despliegue monolítico.
El modelo de financiación era la causa raíz de la disfunción original. Cuando dotas de recursos a un equipo para un proyecto de dos a tres años y evalúas el éxito por si el paquete completo se entrega, no hay incentivo para entregar nada antes. La estructura premia la finalización del todo, no la entrega de las partes. Suciu no intentó cambiar el modelo de financiación directamente. Cambió la conversación sobre qué contaba como entregable, y el control del modelo de financiación se aflojó como consecuencia.
Por qué el customer journey fue el punto de entrada correcto
La razón por la que el mapeo del recorrido funcionó donde los mandatos de proceso no habrían funcionado es que cambió el objeto de discusión. En vez de debatir prácticas, metodologías o modelos de entrega – conversaciones que activan los anticuerpos organizacionales en cualquier empresa que lleva haciendo las cosas de cierta manera durante años – el equipo estaba hablando de sus clientes. Esa es una conversación que todo el mundo quiere tener. No se siente como una amenaza para la autoridad o la experiencia de nadie. Se siente como hacer mejor el trabajo.
Y la descomposición que emergió del recorrido no fue artificial. No fue alguien viniendo a decir “necesitáis descomponer vuestros epics a dos semanas de trabajo.” Las funcionalidades cayeron del recorrido de forma natural, y el orden de prioridad fue determinado por la persona con la autoridad para determinarlo – el director de producto – que tomó la decisión basándose en lo que podía usar inmediatamente.
La lección que Suciu extrae es que la técnica de transformación ágil más poderosa que ha encontrado no es un marco, ni una métrica, ni una herramienta. Es poner a las personas adecuadas en una sala, pedirles que describan cómo sus clientes experimentan realmente el producto, y dejar que las implicaciones de esa descripción hagan el trabajo. La reducción de 52 a 13 semanas no fue ingeniada. Fue descubierta.
Para el desglose completo de la entrevista, consulta nuestra entrevista completa con Long Suciu.
Herramientas mencionadas en la entrevista
Las siguientes herramientas y plataformas fueron mencionadas durante esta conversación.
Contenido relacionado
Operaciones de producto a escala sin romper equipos: entrevista con Long Suciu
Long Suciu lleva 25 años rediseñando cómo los equipos de producto e ingeniería planifican, priorizan y entregan. Explica por qué los story points suelen ser lo primero en eliminarse, cómo una cadencia de planificación trimestral de seis semanas alineó a más de 30 equipos en Gartner, y por qué las herramientas deben reforzar comportamientos en lugar de reemplazarlos.
Por qué eliminar los story points es el primer paso en cualquier transformación ágil
Long Suciu explica por qué eliminar los story points -- una práctica que usa el 90% de los equipos de software -- suele ser el shock más productivo para el sistema cuando se transforma la forma en que los equipos planifican y entregan.
Cómo la alineación entre Productboard y Jira eliminó el problema de las presentaciones
Long Suciu traza el viaje desde objetivos en presentaciones hasta un sistema Productboard-Jira totalmente integrado en Gartner: una transformación que consiguió que 70 product managers trabajaran a la altitud correcta y mantuvo Jira limpio para los equipos que realmente ejecutaban.