Prototype-Driven Development: de la conversación a la evidencia
Un prototipo no sirve para demostrar que una idea era buena. Sirve para descubrir qué parte de la idea todavía no entendemos. Prototype-Driven Development reduce la distancia entre una conversación, una evidencia compartida y la siguiente decisión.
Dos personas pueden salir de una reunión convencidas de que han acordado lo mismo y estar imaginando productos completamente distintos. El problema no suele aparecer en el acta. Aparece semanas más tarde, cuando algo construido obliga a concretar qué significaban palabras como «sencillo», «rápido» o «automatizado».
Durante años intentamos reducir ese riesgo escribiendo más: requisitos, especificaciones, historias de usuario, diagramas. Todo puede ayudar, pero ningún documento elimina la interpretación. Cuanto más nueva es la solución, menos lenguaje común existe para describirla.
Prototype-Driven Development parte de una idea diferente: cuando la incertidumbre es alta, el primer resultado del trabajo no debería ser una solución terminada. Debería ser una evidencia que podamos observar juntos.
El prototipo no es una versión barata del producto
Un buen prototipo responde una pregunta. Puede ser una interfaz navegable, una automatización con datos controlados, una simulación, un flujo manual cuidadosamente representado o una pequeña pieza de software real. Su fidelidad depende de la decisión que necesitamos tomar.
Si queremos saber si una persona entiende un proceso, necesitamos una interacción observable. Si queremos comprobar si una integración es posible, necesitamos código ejecutándose contra el sistema adecuado. Si la pregunta es comercial, quizá baste una propuesta concreta que alguien pueda aceptar o rechazar.
La calidad de un prototipo no se mide por cuánto se parece al producto final. Se mide por la calidad de la conversación que provoca y por la decisión que permite tomar.
Un ciclo de cinco movimientos
El método puede leerse como un bucle:
- Observar. Entender el contexto, las restricciones y el comportamiento actual antes de proponer una respuesta.
- Replantear. Convertir una petición amplia en una pregunta que pueda resolverse con evidencia.
- Crear. Construir la pieza más pequeña que haga visible la hipótesis importante.
- Aprender. Ponerla delante de quienes conocen el problema, observar su reacción y registrar qué cambia.
- Evolucionar. Decidir si avanzar, corregir, integrar, descartar o iniciar otra vuelta.
El orden ayuda a explicarlo, pero el trabajo no es una cadena de relevos. Mientras creamos podemos descubrir una restricción que obliga a replantear la pregunta. Mientras aprendemos puede aparecer un riesgo que exige volver a observar. El valor está en mantener corto el recorrido entre cada hallazgo y la siguiente acción.
Los agentes hacen el método más necesario, no menos
La IA reduce drásticamente el coste de producir una primera versión. Eso es una ventaja, pero también facilita construir con mucha eficacia algo que nadie necesitaba. Cuando la ejecución se abarata, la capacidad de formular la pregunta correcta y reconocer evidencia útil se vuelve más importante.
Los agentes pueden explorar alternativas, escribir código, preparar datos, comprobar escenarios y documentar resultados. La dirección humana sigue decidiendo qué merece ser probado, qué riesgo es aceptable y qué evidencia basta para avanzar.
Por eso el objetivo no es «hacer prototipos más rápido». Es comprimir el ciclo completo entre intención, realidad y aprendizaje.
Lo que queda después
Una vuelta debería dejar algo más valioso que una demo: una decisión mejor, una hipótesis descartada, un criterio compartido, un riesgo descubierto o una capacidad que el equipo pueda reutilizar. A veces el prototipo continúa hasta convertirse en producto. Otras veces cumplir su función significa poder tirarlo sin arrepentimiento.
Fuentes y referencias
- Principios del Manifiesto Agile.
- Fuente primaria: experiencia y método desarrollado por Victor H. Sáez.