Ya no me pregunto si un MVP generado con IA "se ve bien". Esa pregunta casi siempre da una respuesta demasiado optimista.
Lo que reviso ahora es si el prototipo da una sensacion falsa de que ya esta listo para ingenieria. Cuando pruebo un flujo en NxCode, hago estas tres comprobaciones antes de abrir backlog.
1. Pantalla bonita, pero sin pantalla de prueba
Si la portada esta bien resuelta pero no puedo senalar la pantalla que demuestra el trabajo real, el MVP todavia no esta listo.
En un flujo de intake, la pantalla que importa es la que deja ver:
- responsable
- siguiente accion
- fecha limite
- estado
Si esa pantalla no convence, lo demas es presentacion.
2. Camino feliz sin camino de recuperacion
Siempre busco un fallo normal, no un caso exotico:
- falta responsable
- falta fecha
- hay un lead duplicado
- un item queda bloqueado
Si el flujo solo funciona cuando todo sale bien, no tengo un MVP revisable. Tengo una demo.
3. Demasiados campos antes de ganar confianza
La primera version no necesita un modelo entero. Necesita un pequeno nucleo que el equipo pueda confiar desde el dia uno.
Mi lista suele ser:
- origen
- responsable
- prioridad
- fecha limite
- nota corta
Cuando el prototipo trae analytics, permisos, reportes y configuraciones antes de que ese nucleo se vea solido, parece mas avanzado de lo que realmente esta.
La frase de decision
Antes de seguir, escribo una frase:
Dejar tablero de intake, cambio manual de estado y siguiente accion; sacar reportes, permisos y reglas de notificacion del sprint uno.
Eso me obliga a decidir si el MVP merece tiempo real del equipo.
Estoy probando este criterio con NxCode porque me permite revisar un flujo concreto en vez de discutir sobre una especificacion vacia:
Top comments (0)