La respuesta corta
Un MVP de software, sigla en inglés de producto mínimo viable, es la versión más pequeña de un sistema que resuelve un problema real, se usa en el trabajo de verdad y muestra si la idea funciona. No es un prototipo ni una versión a medias: es poca cosa, pero hecha para uso real.
El objetivo del MVP es aprender con el menor esfuerzo posible antes de invertir en el sistema completo. Usted elige el dolor principal, construye solo lo necesario para resolverlo, lo pone en uso y mide. Si el resultado aparece, el sistema crece a partir de ahí. Si no aparece, lo descubrió temprano, cuando todavía es barato cambiar el rumbo.
Lo que no es un MVP: prototipo, demostración y versión a medias
La palabra se volvió sinónimo de cualquier cosa pequeña, y eso confunde la decisión. Un prototipo navegable sirve para probar el flujo y la interfaz antes de escribir código, pero nadie trabaja en él: los datos son ficticios y nada queda guardado. Una demostración sirve para convencer. Y una versión a medias, con todo incompleto, no enseña nada, porque nadie logra usarla lo suficiente como para decir si resolvió el problema.
El MVP está entre el prototipo y el producto completo. Hace pocas cosas, pero las hace bien, con seguridad, datos verdaderos y el cuidado de quien va a seguir construyendo sobre él. La tabla resume la diferencia.
| Aspecto | Prototipo | MVP | Producto completo |
|---|---|---|---|
| Para qué sirve | probar flujo e interfaz antes del código | demostrar que el sistema resuelve el dolor principal | atender toda la operación |
| Quién lo usa | usuarios invitados a una prueba guiada | una parte real de los usuarios, en el trabajo diario | todos los perfiles previstos |
| Datos | ficticios, nada queda guardado | de producción, con seguridad y cumplimiento de la ley brasileña de protección de datos (LGPD) | de producción, con todas las integraciones |
| Qué se aprende | si las personas entienden las pantallas | si el uso real genera el resultado esperado | dónde evolucionar y qué ajustar |
| ¿El código se conserva? | en general no, es descartable | sí, es la base de lo que viene después | sí, y sigue evolucionando |
Cómo elegir lo que entra en el MVP
La tentación es incluir todo lo que parece importante. El criterio correcto es otro: qué tiene que existir para que el dolor principal se resuelva por completo, de principio a fin, para al menos un grupo de usuarios. Algunas preguntas ayudan a recortar:
- ¿Cuál es el dolor que justifica el sistema? Escríbalo en una frase. Todo lo que no ayude a resolverlo es candidato a quedar para después.
- ¿Quién es el primer grupo de usuarios? Un sector, una unidad o un tipo de atención. Empezar con un grupo bien definido facilita medir el resultado.
- ¿Cuál es el recorrido completo de la tarea? El MVP tiene que llevar la tarea de principio a fin. Medio flujo funcionando y el resto en la planilla no demuestra nada.
- ¿Qué puede seguir siendo manual por ahora? Un informe armado a mano o un registro hecho por el equipo pueden esperar a la segunda versión sin perjudicar la prueba.
- ¿Qué integración es indispensable? Integre solo lo que la tarea no puede dejar de lado. Las demás entran en los sprints siguientes, con más información.
Ese recorte se hace en el estudio inicial, junto con quienes operan la rutina, y se convierte en un backlog priorizado. La guía sobre cómo definir el alcance de un software detalla ese trabajo, y la de discovery de producto muestra cómo validar hipótesis antes de construir.
Cómo medir si el MVP validó
Un MVP solo enseña si la pregunta se hizo antes. Por eso el criterio de éxito se acuerda junto con el alcance, y no después de que el sistema está en línea. Sin eso, cualquier resultado se vuelve motivo para seguir.
Las señales más útiles suelen ser fáciles de observar en el propio sistema y en la rutina del equipo:
- Uso espontáneo. ¿Las personas usan el sistema sin que haya que recordárselo, o vuelven a la planilla antigua ante la primera dificultad?
- Tiempo de la tarea. ¿La tarea que motivó el sistema se volvió más rápida, con menos pasos o menos idas y vueltas?
- Error y retrabajo. ¿Disminuyeron las divergencias, las cargas repetidas de datos y las correcciones posteriores?
- Datos para decidir. ¿La gestión empezó a ver en el sistema el número que antes dependía de que alguien armara una planilla?
- Pedidos de los usuarios. ¿Los pedidos que llegan son de ampliación, señal de que lo básico sirve, o de corrección de lo básico?
Con estas señales en la mano, la decisión tiene tres salidas honestas: seguir y ampliar, ajustar lo que no funcionó o detenerse antes de invertir más. Las tres son resultados válidos de un MVP. La única salida mala es no decidir.
¿Un MVP tiene sentido en un sistema interno y en un organismo público?
Sí, y a veces más que en un producto vendido en el mercado. En un sistema interno el usuario está dentro de la casa, lo que facilita observar el uso y escuchar a quienes operan. Empezar por un sector o una rutina reduce el riesgo de cambiar todo de una vez y le da al equipo tiempo para adaptarse mientras se construye el resto.
En el sector público la lógica es la misma, con cuidados propios. La contratación sigue reglas de licitación y el objeto debe estar descrito, así que el MVP aparece como la primera etapa de un alcance planificado por fases, y no como improvisación. Los requisitos de accesibilidad, la LGPD y el registro de cada movimiento entran desde la primera versión, porque un sistema que atiende al ciudadano no puede tratarlos como una mejora futura. La guía sobre contratar software para un organismo público profundiza en ese camino.
En salud, por ejemplo, nuestro sistema de gestión de pacientes para atención de urgencias se construye en sprints con demostración, y cada parte del flujo se valida antes de la siguiente.
Errores comunes al hacer un MVP
- Llamar MVP al sistema completo con un plazo ajustado. Si no se recortó nada, no es un MVP. Es el proyecto completo con menos tiempo, y el resultado suele ser peor en las dos cosas.
- Recortar calidad en lugar de recortar alcance. El MVP es pequeño en lo que hace, no en el cuidado. Seguridad, pruebas y código revisado siguen valiendo, porque el sistema va a crecer sobre esa base.
- No definir antes qué es el éxito. Sin un criterio acordado, el MVP se vuelve una primera versión eterna de la que nadie sabe si funcionó.
- Probar solo con la gestión. Quien decide no es quien opera. Si las personas de la rutina no usan el MVP, la prueba no midió lo que importa.
- Olvidar lo que viene después. El MVP tiene que caber en un plan. Sin backlog para las próximas etapas, el aprendizaje se pierde.
Cómo trabajamos un MVP en la práctica
Nuestro desarrollo de software a medida empieza con un estudio corto que define el alcance, las prioridades y lo que entra en la primera versión. A partir de ahí seguimos el ciclo descrito en cómo trabajamos: sprints cortos, cada uno terminando con software funcionando para que usted lo pruebe, comente y apruebe.
El MVP es la primera entrega que pasa al uso real, y lo que muestra decide el orden de los sprints siguientes. Si quiere entender cuánto tiempo suele pedir cada etapa, la guía sobre cuánto tiempo se tarda en desarrollar un sistema a medida explica qué pesa en el plazo.