MVP en 30 días: qué entra y qué queda afuera

"Entregamos en 30 días" suena a promesa de vendedor. Y muchas veces lo es: hay equipos que prometen un mes, entregan una demo que no aguanta el primer día de uso real y llaman a eso un MVP.

Pero la promesa también puede ser genuina, y la diferencia no está en la velocidad del equipo. Está en qué se decidió dejar afuera. Un mes es un plazo perfectamente alcanzable para poner un sistema en producción, siempre que las dos partes acepten una regla incómoda: en treinta días no entra todo lo que querés, y la conversación difícil hay que tenerla al principio.

Esta nota es sobre esa conversación.

Qué es y qué no es un MVP

El término se degradó hasta significar "versión barata". No es eso.

Un MVP es la versión más chica del sistema que ya sirve para trabajar. La palabra que importa no es "mínimo": es "viable". Si tu equipo no puede operar con eso y tiene que seguir usando el Excel en paralelo, no entregaste un MVP. Entregaste una demo.

De ahí sale el criterio de corte que ordena todo lo demás:

Una funcionalidad entra en el MVP si sin ella el sistema no se puede usar para trabajar. No si es importante, no si es urgente, no si el cliente la pidió con énfasis.

Es un criterio duro y por eso funciona. "Importante" incluye casi todo; "sin esto no se puede operar" incluye mucho menos.

Qué entra siempre

En un sistema de gestión, esto es el piso. Sacar cualquiera de estas cosas produce algo que no se puede usar:

El flujo principal completo, de punta a punta. Si el sistema es para gestionar pedidos, tiene que poder crear un pedido, seguirlo y cerrarlo. Un flujo cortado a la mitad no sirve para nada.
Login y permisos básicos. Aunque sean dos roles. Un sistema donde todos pueden hacer todo no entra en producción en una empresa real.
La carga de los datos que ya tenés. Un sistema vacío no se usa. La migración inicial no es opcional.
Los datos que exige la ley o el cliente. Si tenés que emitir un comprobante fiscal, eso no es negociable ni postergable.
Que no se pierdan datos. Respaldos, manejo de errores, validaciones. Es lo primero que se recorta y lo que hace que el sistema pierda credibilidad para siempre a la primera pérdida.

Qué queda afuera casi siempre

Esta es la lista que genera resistencia y es donde está el mes de diferencia.

Reportes y tableros. Casi todo el mundo los pide en la primera reunión y casi nadie los mira los primeros dos meses. Además, los reportes que realmente vas a usar sólo se descubren cuando el sistema tiene datos adentro. Construirlos antes es adivinar.
La app móvil. Salvo que el trabajo sea en la calle o en un depósito sin señal. Una web bien hecha para celular cubre la etapa uno.
Las integraciones que no bloquean la operación. Si podés cargar algo a mano durante un mes, la integración va a la etapa dos. Las integraciones son lo más impredecible del cronograma porque dependen de sistemas que no controlás.
Los casos borde. El proveedor que factura distinto, el cliente con el descuento histórico, la excepción que pasa dos veces al año. En el MVP se resuelven a mano, y en la etapa dos se automatizan los que realmente hayan aparecido.
Configuración de todo. La tentación de que "cada parámetro sea configurable desde el panel" duplica el trabajo. En el MVP, lo que cambia una vez al año va escrito en el sistema y se ajusta con un pedido.
Notificaciones y automatismos. Mails automáticos, recordatorios, alertas. Suman mucho valor y ninguno es imprescindible el primer mes.

Por qué la mayoría fracasa

Tres razones, y ninguna es técnica.

1. El alcance no se cerró, se pospuso

Es el fracaso más común. Las dos partes evitan la conversación incómoda al principio —queda mal decir que no— y arrancan con un alcance ambiguo. La discusión ocurre igual, pero en la semana tres, con medio sistema construido y la fecha encima. Ahí ya no se puede cortar nada sin tirar trabajo hecho.

2. No hay una sola persona que decida del lado del cliente

Un proyecto de treinta días necesita decisiones en horas, no en semanas. Si cada definición tiene que pasar por tres áreas y una reunión de directorio, el cronograma se muere en la primera semana. No es un problema de burocracia: es que la velocidad del proyecto no puede superar la velocidad de las decisiones.

Un MVP en un mes exige una persona del lado del cliente con autoridad para decidir y disponibilidad de al menos unas horas por semana. Si eso no existe, el plazo correcto no es treinta días.

3. Se confundió "mínimo" con "mal hecho"

Un MVP es chico en alcance, no en calidad. Si para llegar a la fecha se recortaron las validaciones, el manejo de errores y las pruebas, lo que entregás es una deuda con intereses: el mes dos se va entero en arreglar lo del mes uno, y el sistema arranca con mala reputación adentro de la empresa. Recuperar la confianza de un equipo que probó un sistema que fallaba es más caro que haberlo hecho bien.

Cómo se ve un mes que funciona

Un cronograma realista de cuatro semanas se parece bastante a esto:

Semana 1 — Definición y estructura. Se cierra el alcance por escrito, se acuerdan las pantallas y las reglas de negocio, se define el modelo de datos y se arma la base técnica del proyecto. Al final de la semana ya hay algo que se puede abrir, aunque esté casi vacío.

Semana 2 — El flujo principal. Se construye el camino completo de punta a punta. Feo, sin pulir, pero entero. Al final de la semana el cliente lo prueba.

Semana 3 — Lo que rodea al flujo. Permisos, validaciones, los casos que aparecieron cuando el cliente probó la semana anterior, la carga de datos existentes.

Semana 4 — Producción. Ajustes, pruebas, migración final, despliegue y capacitación. La última semana no es para construir: es para que el sistema entre en la operación real.

Los dos detalles que hacen que esto funcione: el cliente prueba algo al final de cada semana, y la cuarta semana no tiene funcionalidades nuevas asignadas. Un cronograma que llena la última semana de desarrollo no tiene margen para lo único seguro que va a pasar, que es que algo salga distinto a lo previsto.

La etapa dos, que es la que hace que esto tenga sentido

Nada de esto funciona si el MVP se piensa como el final. Se piensa como la primera de varias entregas, y hay una razón económica: la etapa dos se define con información que hoy no tenés.

Después de un mes de uso real sabés qué pantallas se usan todo el día y cuáles nadie abrió, qué reporte piden de verdad, qué caso borde apareció seis veces y cuál ninguna. Esa información no se puede obtener en una reunión de relevamiento. Sólo se obtiene usando el sistema.

En la práctica, la lista de prioridades de la etapa dos casi nunca coincide con lo que se había postergado en la etapa uno. Eso no es un fracaso de la planificación: es exactamente el beneficio de haber salido a producción rápido. Construir en el mes uno todo lo que se pedía en el mes cero habría significado pagar por funcionalidades que la realidad después despriorizó.

Cómo saber si tu proyecto entra en un mes

Cuatro preguntas:

¿Podés nombrar el flujo principal en una frase? "Cargar un pedido, asignarlo a un repartidor y cerrarlo con la firma del cliente". Si no entra en una frase, probablemente sean dos proyectos.
¿Hay una persona que pueda decidir sin consultar? Con disponibilidad real.
¿Las integraciones son imprescindibles el primer día? Si sí, el plazo depende de terceros y no lo controlás.
¿Estás dispuesto a que la primera versión no tenga reportes? Si la respuesta es no, es una respuesta válida, pero el plazo no es un mes.

Si las cuatro dan que sí, un mes es realista.

Si alguna da que no, sigue siendo un proyecto perfectamente sano: sólo que dura dos o tres meses, y es mejor saberlo en la semana cero que en la semana cinco.