julio de 2026 · 4 min de lectura
Cómo planificar un MVP sin construir de más
Un marco práctico para decidir qué se publica ahora, qué espera y qué probablemente no debería existir.
Ingeniería de ZitDevs
La mayoría de los MVP fallan por el alcance, no por el código
Un MVP que toma nueve meses no es un MVP. Es una primera versión con un nombre optimista, y cuando se publica las suposiciones sobre las que se construyó ya tienen un año.
Construir de más casi nunca viene de una decisión grande. Viene de treinta decisiones pequeñas que parecían baratas: una pantalla de configuración, un segundo rol de usuario, una exportación, un panel para administrar esa exportación. Ninguna vale una discusión por separado. Juntas son la diferencia entre seis semanas y seis meses.
El marco de abajo existe para tomar esas treinta decisiones una sola vez, por escrito, antes de que alguien las estime.
Empiece por la decisión, no por la lista de funciones
Un MVP es un instrumento para responder una pregunta. Escriba la pregunta primero, en una oración, y hágala refutable: no "les gustará esto", sino "el personal de operaciones registrará los envíos aquí en lugar de la hoja de cálculo".
Cuando la pregunta es explícita, cada función propuesta se puede evaluar contra ella. Si una función no puede cambiar la respuesta, no forma parte del MVP, por barata que parezca.
- ¿Qué decisión nos permite tomar esta versión?
- ¿Quién tiene que comportarse distinto para que la respuesta sea real?
- ¿Qué número indica la respuesta y dónde se mide?
- ¿Cuánto tiempo estamos dispuestos a esperar por ella?
La prueba
Si dos personas del equipo escriben la pregunta del MVP por separado y producen oraciones distintas, el alcance todavía no está acordado. Resuelva eso antes de estimar.
Clasifique todo en ahora, después o nunca
Dos categorías no alcanzan. Los equipos que solo tienen "dentro" y "fuera" pasan el proyecto discutiendo de nuevo lo que quedó fuera, porque nadie escribió por qué se excluyó.
Una tercera categoría, nunca, es la que mantiene la lista estable. No es un rechazo de la idea; es el registro de que la idea se consideró y se declinó conscientemente para esta versión, con el motivo adjunto.
Ahora
- Responde directamente la pregunta del MVP
- Bloquea el flujo principal si falta
- No se puede simular con una persona o una hoja de cálculo
Después
- Necesario para el segundo grupo de usuarios
- Valor real, pero no evidencia
- Diferido con un disparador escrito, no con una fecha
Nunca
- Configuración sin una segunda configuración
- Roles que nadie ha pedido todavía
- Informes que una exportación CSV ya cubre
Haga a mano lo que de otro modo construiría
Casi toda herramienta interna de un MVP se puede reemplazar por un tiempo con una persona haciendo la tarea a mano. Altas de usuarios, facturación, reembolsos, aprobaciones, moderación: todo eso puede funcionar con un buzón compartido y una lista de verificación mucho antes de funcionar en una pantalla.
La regla que usamos: si la tarea ocurre menos de cinco veces por semana y toma menos de diez minutos, no lleva interfaz en la primera versión. Anote el volumen que está suponiendo, para saber cuándo se rompe la suposición.
Es el recorte de mayor efecto disponible y el que más resistencia genera, porque el trabajo manual se siente poco profesional. No lo es. Construir un flujo que nunca se ha ejecutado a mano es lo que produce el flujo equivocado.
Una advertencia
Los procesos manuales deben ser visibles y tener un responsable. Un paso manual sin documentar no es una decisión, es un pasivo que heredará en el cuarto mes.
Defina el terminado antes de definir el sprint
Escriba los criterios de lanzamiento al mismo tiempo que el alcance: qué flujo funciona de principio a fin, en qué dispositivos, con qué datos y qué se permite explícitamente que se vea feo. Lo que no está en esa lista no bloquea el lanzamiento, y decirlo por adelantado es lo que evita que las últimas dos semanas se conviertan en seis.
Después acuerde qué pasa a continuación. Un MVP que se publica sin una reunión de revisión agendada no produce ninguna decisión, y todo el ejercicio fue un proyecto de software normal con presión adicional.
- Un flujo principal funciona de principio a fin sin intervención del personal
- Datos reales, ingresados por usuarios reales, no datos de prueba
- Los errores quedan registrados donde una persona los lee
- Una fecha de revisión en el calendario, con la métrica nombrada