Parte III. El Sprint con IA
Planificar cuando el esfuerzo ya no manda
Roadmap, mapa de historias y plan de releases con IA
Un roadmap impecable
Para planificar el trimestre, Héctor probó algo nuevo. Le dio a la IA el contexto de GymApp, las reseñas, los objetivos de la empresa y la lista de ideas, y le pidió un roadmap. En veinte minutos tenía uno: tres temas, doce funcionalidades, fechas por mes y una justificación para cada una. Estaba mejor escrito que cualquier roadmap que hubiera hecho él.
En la reunión nadie le puso pegas, y precisamente eso le inquietó. Germán le dijo después, en el pasillo, que había leído la justificación de la integración con relojes deportivos y no sabía de dónde salía. Héctor tampoco.
Cuando todo parece una victoria rápida
Casi todas las formas de priorizar que usamos (RICE, WSJF, la matriz de valor y esfuerzo) ponen el esfuerzo en el denominador: valor partido por esfuerzo. Con IA, el esfuerzo de construir se desploma y de repente todo parece una victoria rápida. Si nada cuesta, nada se descarta, y el roadmap se convierte en una lista de cosas que se pueden hacer.
El esfuerzo no ha desaparecido del todo. Integrar con sistemas antiguos, revisar la seguridad o tocar datos de producción siguen costando. Pero ha dejado de ser lo que separa lo que se hace de lo que no.
Además, incluso si construir es barato, se genera un coste cognitivo tanto para los equipos como para los usuarios. Los primeros tienen más producto que entender y mantener y los segundos tienen productos más complejos, más complicados y costosos de usar.
Cuatro preguntas para priorizar
Cuando el esfuerzo deja de ordenar, hacen falta otras preguntas. Jeff Gothelf propone ordenar el roadmap por dos de ellas: lo que se aprende y lo fácil que es deshacerlo. Yo añado otras dos que en una empresa no se pueden dejar fuera:
- ¿Qué valor tiene para el usuario? Qué cambia en lo que hace, y para cuántos.
- ¿Qué aprendemos construyéndolo? Si resuelve una duda importante o si solo confirma lo que ya creemos.
- ¿Cuánto cuesta deshacerlo? Un cambio que se apaga con un interruptor no es lo mismo que uno que cambia el modelo de datos o promete algo a los clientes. Jeff Bezos lo explicaba en su carta a los accionistas de 2015: hay puertas de ida y vuelta, que se pueden cruzar rápido, y puertas de un solo sentido, que hay que pensar.
- ¿Qué riesgo legal o de datos trae? Con IA, esta pregunta va en la priorización, no al final.
Lo que enseña mucho y se deshace fácil, se construye ya. Lo que enseña mucho y es difícil de deshacer, se prototipa primero. Lo que enseña poco y se deshace fácil, se hace pequeño y sin reunión. Lo que enseña poco y es difícil de deshacer, se queda fuera.
Hay algo que la IA no cambia: el coste del retraso, es decir, lo que se pierde por cada semana que algo valioso tarda en llegar a los usuarios. Una campaña para captar socios vale mucho en enero, cuando la gente se apunta al gimnasio, y mucho menos en abril, por rápido que se construya. Por eso, con lo demás igual, va primero lo que pierde valor con el tiempo.
Lo explica Don Reinertsen en The Principles of Product Development Flow (Celeritas, 2009).
Roadmap de resultados
Un roadmap útil no es una lista de funcionalidades con fecha. Es una lista de hitos o resultados: qué cambio de comportamiento buscamos, en quién y en qué orden. "Que los socios nuevos reserven clase en su primera semana" es un resultado.
"Integración con relojes deportivos en marzo" es una funcionalidad, y solo tiene sentido si sirve a un resultado. Product Roadmaps Relaunched (C. Todd Lombardo y otros, O'Reilly, 2017) explica cómo construir un roadmap así.
Con IA esto importa más, porque generar funcionalidades es gratis. Un roadmap de funcionalidades se llena solo.
Mapa de historias y plan de releases
El mapa de historias, que popularizó Jeff Patton con su libro User Story Mapping (O'Reilly, 2014), sigue siendo la mejor forma de ver un producto entero: el recorrido del usuario arriba y las historias debajo. La IA puede generar un primer mapa en una hora a partir de la evidencia. La sesión del equipo deja de dedicarse a escribir tarjetas y se dedica a lo que importa: decidir dónde se corta la primera entrega.
El plan de releases de un equipo se hace con previsiones, no con fechas prometidas. Con los datos reales del flujo (cuántos elementos termina el equipo por semana y con qué variación) se puede decir "entre la semana 6 y la 9, con un 85 % de probabilidad". Es la previsión probabilística que explica Daniel Vacanti en When Will It Be Done? (2020).
La IA ayuda a hacer ese cálculo; la conversación sobre qué hacer si sale la semana 9 la tiene el equipo. El plan de varios equipos tiene su propio capítulo, el 15.
Interrogar al roadmap generado
Un roadmap escrito por una IA se interroga igual que cualquier otro, con dos preguntas:
- ¿Qué evidencia hay detrás de cada elemento? Si la respuesta es "lo dice el documento", no hay evidencia.
- ¿Qué tendría que ser cierto para que funcione? Es la pregunta que proponen A. G. Lafley y Roger Martin en Playing to Win (Harvard Business Review Press, 2013) para poner a prueba una estrategia, y saca a la luz las suposiciones que la IA ha tomado de lo que se suele hacer en general, no de tu empresa.
Héctor repasó el roadmap con esas preguntas. De las doce funcionalidades, cuatro tenían evidencia. La de los relojes deportivos salía de un artículo sobre tendencias. El roadmap del trimestre acabó con dos resultados y seis elementos, y dos de ellos eran experimentos.
En resumen
Cuando el esfuerzo deja de ordenar, prioriza por valor, aprendizaje, reversibilidad y riesgo. Planifica resultados, no funcionalidades, y usa previsiones en lugar de fechas prometidas. Un roadmap generado se interroga como cualquier otro.
Pruébalo esta semana
Coge el orden del próximo Sprint y pásalo por las cuatro preguntas. Cuenta cuántas victorias rápidas caen. Ese número dice cuánto de tu plan estaba ordenado por facilidad y no por valor.
Si vas a rehacer el mapa de historias, la plantilla de historias de usuario trae la guía y el Excel para el backlog.