Desperdicios, validaciones y lanzamientos
En la duodécima sesión del programa de dirección de producto del Instituto Tramontana cruzamos la puerta que se había quedado abierta en la sesión anterior. Después de haber recorrido los momentos de captura y moldeado, y haber diseñado los semáforos que regulan el flujo de descubrimiento, toca abordar lo que sucede cuando una conjetura llega al espacio de desarrollo. Y aquí es donde aparece uno de los problemas más persistentes de nuestra industria: el desperdicio.
La industria de los productos digitales es, con frecuencia, una industria de desperdicio. No solo porque no suele implementar procesos de descubrimiento ni semáforos para decidir cuándo merece la pena profundizar en una conjetura, sino porque cuando salta a la ejecución suele hacerlo sin establecer un perímetro. Cuando, además, los equipos trabajan en silos pasándose un testigo, los problemas derivados de esa falta de limitaciones se multiplican. Las metodologías ágiles no pueden mejorar por sí solas esta situación. Incluso pueden empeorarla al crear una falsa sensación de agilidad que no se traduce ni en velocidad ni en claridad.
Problemas abiertos, no secuencias de tareas
La tarea es la referencia más común cuando se trabaja en algo que se quiere desarrollar. La mentalidad de entrega es el resultado de partir de esa base y tratar la complejidad a partir de ella. Una solución grande frente a una solución pequeña se entiende simplemente como una secuencia más grande de tareas.
En la mayoría de las ocasiones, sin embargo, nos enfrentamos a problemas abiertos, problemas intrínsecamente complejos. En parte por la naturaleza específica del software, que vimos en las primeras sesiones. En parte por lo difícil que es obtener evidencia de lo que realmente sucede. Finalmente, porque la demanda —el cliente, el problema— es la incógnita que no sabemos despejar, y por lo tanto se nos abren muchas posibles soluciones a partir de una misma oportunidad.
La experiencia está llena de situaciones que confirman lo que la literatura sobre gestión de proyectos de software ha ido sintetizando: el aumento de recursos —en todas las dimensiones: personas, herramientas, materiales— cuando se trata de resolver problemas abiertos puede acabar haciendo el problema aún más grande.
Del output al outcome
La razón de un problema abierto empieza con su conjetura. El efecto de esa conjetura —es decir, el beneficio esperado— es lo que debe servir como guía durante todo el proceso. No se trata de entregar funcionalidades, sino de perseguir un resultado.
Cuando trabajamos con problemas abiertos, la pregunta no debería ser "¿qué lista de cosas tengo que entregar?", sino "¿qué beneficio estoy persiguiendo?". Eso cambia la conversación: en lugar de negociar qué debo sacrificar de una lista cerrada, me pregunto qué efecto quiero provocar y cómo puedo llegar a él. Es la diferencia entre que un equipo reciba tareas y que un equipo reciba un objetivo.
Este cambio de perspectiva tiene consecuencias directas en cómo se gestiona el alcance. Si el equipo entiende el beneficio esperado, puede tomar decisiones sobre qué construir, qué simplificar y qué descartar. Si solo tiene una lista de tareas, ejecuta sin criterio para decidir qué es esencial y qué no.
Moldear no es definir requisitos
Moldear una solución no es lo mismo que definir requisitos. La diferencia es fundamental para evitar el desperdicio. Moldear implica moverse entre la palabra y el píxel: dar suficiente forma a una idea para que un equipo la pueda entender y empezar a trabajar, pero sin cerrarla tanto que no quede espacio para las decisiones que solo se pueden tomar al construir.
Existe un equilibrio entre lo demasiado abierto y lo demasiado cerrado. Si la solución se plantea de forma demasiado abierta, el equipo no tiene un punto de partida claro y puede perderse explorando. Si se cierra demasiado, se convierte en una lista de requisitos que elimina la capacidad del equipo de adaptarse a lo que descubra.
Moldear bien implica cuatro cosas. En primer lugar, establecer un contorno delimitado, no una lista exhaustiva de puntos. Se trata de decir "esto es lo que entra y esto es lo que no entra", no de especificar cada detalle. Una lista de bullets no es un moldeo: es un documento de requisitos disfrazado. En segundo lugar, apuntarse los potenciales riesgos. Antes de que un equipo empiece a construir, debería estar claro qué cosas podrían salir mal o qué preguntas quedan abiertas. En tercer lugar, explicar el conjunto de la solución, no las piezas sueltas. Un buen moldeo transmite la experiencia completa que se quiere crear: cómo se relacionan las partes, cuál es el flujo, qué se espera que sienta o haga el usuario. Y por último, moverse entre la palabra y el píxel: combinar la descripción narrativa con bocetos suficientes para que se entienda la intención, sin llegar al nivel de un diseño cerrado.
El tiempo como cortafuegos
El tiempo es el recurso más eficaz para poner límites al desperdicio. En lugar de estimar cuánto tardará algo —lo cual es una forma de engañarse cuando se trata de problemas abiertos—, la pregunta debería ser: "¿cuánto tiempo le daríamos a esto?". Es el concepto de apetito: cuánto estás dispuesto a invertir en una conjetura, dado lo que sabes y lo que no sabes.
El apetito funciona como un cortafuegos. Si una solución se moldea para caber en un ciclo de tiempo fijo, el equipo tiene que tomar decisiones de alcance: qué es esencial y qué puede quedarse fuera. Sin esa restricción temporal, el alcance tiende a crecer indefinidamente.
Esto se diferencia de los sprints tal como se usan habitualmente. El problema de muchos equipos no es que no hagan sprints, sino que los sprints se encadenan sin un horizonte claro: "si no da en este, hacemos otro". Después de ocho sprints, nadie sabe realmente cuánto se ha invertido ni si el resultado justifica la inversión. El tiempo fijo con apetito definido evita esa cadena: se le da un ciclo concreto a una conjetura concreta, y al final de ese ciclo se evalúa.
Las limitaciones no son obstáculos. Son la forma de reducir la incertidumbre. Obligan a priorizar, a recortar lo accesorio y a centrarse en lo que realmente importa para validar la conjetura.
Colaborar en lugar de pasarse el testigo
Uno de los mayores generadores de desperdicio en producto digital es el modelo de pase de testigos: un rol define, otro diseña, otro construye, otro valida. Cada paso es una transferencia donde se pierde contexto, se acumula interpretación y se multiplican los desencajes.
La alternativa es entregar la responsabilidad completa a los equipos. No se trata de que alguien piense la solución y otros la ejecuten, sino de que el equipo que va a construir participe desde el principio y tenga capacidad de decisión sobre cómo resolver el problema dentro del contorno definido.
Esto implica construir y tocar desde el primer día. El equipo debería empezar a hacer cosas tangibles —aunque sean toscas— lo antes posible. Implica también mostrar progreso de forma continua, sin esperar a tener algo "presentable". Y cuando se recibe feedback, hay que tratarlo con el mismo rigor que se aplica al moldeo inicial: evaluarlo, contornearlo y decidir si entra o no, en lugar de añadirlo automáticamente como tarea adicional.
Desarrollar es desenvolver
Trabajar con problemas abiertos en producto digital significa aceptar que no somos buenos estimando. El alcance final de lo que estamos proyectando no es algo que podamos poner como punto de partida para, a partir de ahí, establecer su duración. El alcance es algo móvil. Desarrollar software es, por lo tanto, desenvolver el alcance de eso que estás proyectando.
Al tratarse de un proceso, no podemos entender la validación como algo que solo se produce al final. No podemos seguir un modelo de imprenta: se establece una entrada y luego se espera una salida, y es entonces cuando se valida si lo que sale se corresponde con lo que entra. Tenemos validaciones antes de empezar, mientras construimos, y también al lanzar.
Una de las claves para ejecutar correctamente es aceptar que terminado significa lanzado. Publicado. No "el código está listo" ni "la rama está mergeada", sino que los usuarios lo están utilizando. Los equipos deben ser quienes decidan cuándo algo está suficientemente terminado para salir.
Validaciones en tres tiempos
Antes de haber empezado a construir, es razonable intentar validar la información con la que trabajamos. Adelantar a los equipos de ingeniería tiene principalmente la función de empezar a validar si lo que se está proyectando tiene encaje con lo que existe, así como para empezar a tener una noción de riesgo e incertidumbre.
Durante la construcción, el primer arranque suele ser una etapa de descubrimiento de todas aquellas cosas que no se podían saber antes de empezar a construir. Los desconocidos desconocidos. Esa primera validación puede llevar a modificar sustancialmente el alcance. Es importante señalar que no conviene validar soluciones proyectadas —mockups en Figma, prototipos estáticos— como si fueran la solución real. Hay aspectos fundamentales —el email que no llega, la latencia de una API, el flujo real con datos reales— que solo se pueden validar con software funcionando.
Después del lanzamiento, la validación viene determinada por la clasificación de la solución. Si estamos ante un problema de cliente, podemos buscarla a través de una interacción inmediata. Si es una palanca, una observación cuantitativa del comportamiento de ciertas métricas debería valernos. Si persigue deleite, posiblemente necesitaremos algún tipo de encuesta, entrevista, o estar atentos a lo que comentan los clientes en diferentes canales.
Lanzar es una decisión de diseño
Los lanzamientos también se pueden dar de distintas formas. Lo digital ofrece una plasticidad que abre múltiples opciones. La diferenciación principal suele ir de lanzamientos totales —de una vez— frente a lanzamientos progresivos. Las plataformas de desarrollo móvil han establecido como estándar lanzar a partir de porcentajes, y los equipos de ingeniería funcionan con la idea de que eso les permite ir validando si aparecen problemas.
También se puede distinguir entre lanzamiento interno y lanzamiento externo. Si estás trabajando en un producto que se utiliza internamente, es habitual que las funcionalidades estén un tiempo dentro de la empresa, y que salgan fuera cuando ya se han validado e incluso refinado. El lanzamiento progresivo es, en sí mismo, otra forma de validación.
Práctica de la sesión
Caso de uso: Moldeo de una apuesta real. El ejercicio de esta sesión consistía en tomar una de las apuestas que salieron del panel de descubrimiento y darle forma siguiendo los principios de moldeo: combinación de palabra y prototipo de punto gordo, exposición del problema, la solución, el perímetro —lo que no entra— y los potenciales riesgos o zonas más desconocidas. El tiempo que le dedicaríamos se establece en función del objetivo y su impacto, sin caer en el cálculo de complejidad o viabilidad.
Para casa: Completar el moldeo y buscar un par de personas ajenas a la empresa, potenciales o actuales clientes, para que a partir del documento compartan sus sensaciones: si están de acuerdo con el problema, si le ven valor, si entienden la solución. En la misma línea, buscar la forma de acortar la distancia con lo que se está creando: darse de alta, hacer operaciones con el producto, probar los flujos reales. No dejarlo para después.