Un MVP no se atasca porque el equipo no sepa programar. Se atasca porque, en la primera semana, cada persona tiene una película distinta en la cabeza.
El Product Owner habla de “la app”. El developer pregunta “¿cuál pantalla primero?”. Alguien más ya está eligiendo framework. Y el alcance —quién entra, qué puede hacer, qué datos se guardan— sigue en un chat o en un documento que nadie vuelve a abrir.
Eso no es un problema de talento. Es un problema de requerimientos.
Lo que suele faltar no es una idea. Es una frontera.
Una idea alcanza para emocionar. No alcanza para construir. Para construir hacen falta cuatro cosas dichas en voz alta:
- Para quién es. No “usuarios”. Roles: dueño, operador, cliente, admin.
- Qué puede hacer cada quien. Una frase por necesidad, no un párrafo de visión.
- Qué información tiene que existir. Si el sistema no recuerda un dato, esa función no existe.
- Qué queda fuera de esta versión. Sin recorte, el MVP se convierte en el producto completo… a medias.
Si esas cuatro no están escritas, el equipo no está “iterando”. Está adivinando.
El costo de adivinar
Adivinar se siente rápido. Sale caro.
- El developer construye la pantalla que creyó que era el núcleo.
- El PO revisa y dice “esto no era”.
- Se reescribe. Se pierden días. A veces sprints.
- La confianza baja: “es que no me entendieron”.
Casi nunca es que no entendieron. Es que no había un mapa compartido contra el cual decir sí o no.
Los números de la industria apuntan a lo mismo: una parte grande de los proyectos se descarrila por requerimientos mal definidos, y una parte grande del presupuesto se va en retrabajo. No hace falta un estudio más para verlo en un equipo de cinco personas.
El orden que evita el atasco
Antes de un ticket, antes de un repo, conviene este orden:
- Objetivo en una frase (qué cambia para el usuario cuando esto exista).
- Roles y lo que cada uno necesita.
- Historias de usuario con criterio de “listo”.
- Datos que el sistema tiene que guardar.
- Pantallas y cómo se conectan.
- Recién ahí: tickets que un developer puede tomar sin preguntar por chat.
Ese orden no es burocracia. Es traducir la idea a algo ejecutable. El código llega después, más corto, porque ya no está resolviendo debates de producto.
Cómo saber si ya puedes construir
Hazte estas tres preguntas. Si alguna se responde con “depende” o “luego lo vemos”, todavía no es un MVP: es una conversación.
- ¿Un developer nuevo podría tomar el primer ticket y saber qué queda incluido y qué no?
- ¿Sabemos qué roles entran en esta versión y cuáles no?
- ¿Hay una lista de datos que el sistema debe recordar, o eso “se define con el back”?
Si la tercera pregunta se delega al backend “más adelante”, el modelo de datos se inventará en silencio — y el producto cambiará de forma cuando alguien intente conectar las pantallas.
De la idea al plan, sin volverte técnico
No hace falta hablar en tickets, sprints o esquemas para dejar esto claro. Hace falta escribirlo en el lenguaje de quien usa el sistema, y dejarlo en un solo lugar que el equipo vea.
Eso es lo que hace Traductor Dev: tomar la idea, los roles y las necesidades, y dejarlas como spec viva —historias, datos, pantallas, tickets— para que el equipo construya en vez de interpretar.