Encargar un MVP: por qué un prototipo suele ser mejor punto de partida que un pliego de requisitos

Una frase aparece pronto en muchas conversaciones de proyecto: “Primero lo ponemos todo por escrito y luego ya puede venir una oferta”. Suena razonable. Al fin y al cabo, quien construye una casa quiere ver los planos antes de que llegue la excavadora. Con el software la comparación solo sirve hasta cierto punto, porque una casa difícilmente admite añadir una planta una vez habitada, mientras que un formulario de entrada se cambia con mucha más facilidad.

Supongamos una empresa de veinte empleados que quiere sustituir su gestión de pedidos. La dirección y dos jefes de equipo escriben durante seis semanas un pliego de requisitos. Tiene ochenta páginas, modelos de roles, diagramas de estados y una lista de más de cien criterios obligatorios. Todos están orgullosos de él, y nadie ha hablado entretanto con los compañeros del mostrador y del teléfono que de verdad van a trabajar con el sistema.

Un documento puede describir lo que uno imagina, pero no mostrar si esa idea funciona en el día a día. Esta diferencia resulta cara más adelante, y tiene causas recurrentes.

Hay mecanismos que se repiten. El primero: las personas describen el estado ideal de su trabajo, no el real. La nota pegada en el monitor, la lista privada de Excel, la llamada a la compañera que “siempre lo sabe” no aparecen en el pliego porque se consideran rodeos. Sin embargo, son precisamente esos rodeos los que a menudo sostienen la actividad.

El segundo mecanismo es la presión por la exhaustividad. Un documento de este tamaño debe regularlo todo, así que se incluye cada caso especial que a alguien se le ocurre. Los casos raros reciben el mismo peso que el caso normal de cada día. Al final no está claro qué es realmente importante, y una oferta tiene que tratarlo todo por igual. El tercer mecanismo es más discreto: quien describe un campo no ve cómo se siente al rellenarlo veinte veces al día.

A esto se suma el lenguaje. Una frase como “El sistema debe gestionar los pedidos de forma flexible” puede implementarse de diez maneras, y las diez son formalmente correctas. La discusión surge en la aceptación, cuando cada parte considera correcta su propia interpretación. El documento tiene entonces efecto jurídico, pero ninguna capacidad de aclarar.

Los patrones de fallo típicos que resultan de ello son estos:

Antes de decidir el enfoque y el contrato, conviene hacer un inventario sobrio de qué es incierto en el proyecto. La viabilidad técnica rara vez lo es en la mayoría de las aplicaciones empresariales. Los formularios, listas, roles, notificaciones e interfaces con sistemas habituales son problemas resueltos. Lo incierto son casi siempre los supuestos sobre las personas y los procesos: ¿usará el equipo el software y es correcta la imagen que se tiene del proceso?

Esta pregunta puede formularse como hipótesis central, en una frase que puede resultar falsa. Por ejemplo: “Si los pedidos pueden registrarse en el smartphone en menos de un minuto, los compañeros del servicio externo dejarán de apuntar en papelitos”. Es comprobable y, además, dice qué no hace falta construir para realizar la prueba. La facturación, los informes y la gestión de permisos no forman parte de la prueba.

De la hipótesis se deduce el alcance mínimo útil. “Útil” es aquí la palabra decisiva. Un mínimo que nadie puede utilizar a diario no aporta ningún conocimiento, y los usuarios solo le prestan la atención que dedicarían a una cita de demostración. El núcleo debe poder soportar trabajo real, aunque sea solo en una parte: un equipo, un tipo de pedido, una sede.

Resulta útil ponderar los riesgos de forma expresa antes de fijar el alcance. El siguiente gráfico muestra una ponderación así para un proyecto hipotético de este tipo.

La alternativa al pliego de requisitos no es renunciar a planificar, sino cambiar el orden. Primero se despeja la mayor incertidumbre con el menor esfuerzo posible y después se decide qué se construye. Esto no ahorra dinero automáticamente. Desplaza el gasto de la suposición al conocimiento, y esa es la verdadera ganancia.

Un prototipo clicable es la fase más ligera. Consiste en pantallas diseñadas que pueden enlazarse entre sí, sin que detrás funcione lógica ni datos. Sirve para comprobar flujos, términos y secuencias, y puede crearse en días en lugar de semanas. No sirve para valorar la carga, la calidad de los datos ni la idoneidad para el uso diario, porque nadie trabaja con maquetas como lo haría con un sistema real.

Un MVP funcional va un paso más allá. Guarda datos reales, tiene inicio de sesión y funciona en el día a día, aunque con pocas funciones. Quien quiera encargar un MVP debería aclarar desde el principio si basta con un prototipo clicable o si la hipótesis solo puede comprobarse en uso real. Normalmente ayuda una combinación: primero el prototipo para el flujo, después el MVP para la prueba prolongada.

También es importante la otra cara. Un enfoque MVP no es la mejor opción en todas partes. En procesos muy regulados, con normas fijas o en la sustitución de un software existente con un alcance funcional exactamente definido, puede tener sentido un pliego de prescripciones detallado. Aun así, merece la pena un pequeño prototipo de las pantallas más arriesgadas.

El recorte comienza con la observación, no con una lista de requisitos. Pasaríamos media jornada en la empresa, acompañaríamos a dos o tres personas en su trabajo y anotaríamos el flujo tal como transcurre de verdad: con interrupciones, consultas, notas adhesivas. De ahí no sale un documento, sino una lista breve de momentos en los que la solución actual falla.

A partir de esos momentos se deduce el núcleo. Como regla práctica sirve preguntarse si una parte aporta valor por sí sola. Registrar un pedido y asignarlo a un empleado puede ser una parte así. Registrar un pedido pero todavía no facturarlo probablemente también lo es. Facturar sin registrar no lo es. Así surge un corte a través del proceso que contiene un trozo de trabajo de principio a fin, en lugar de un poco de cada capa.

La decisión sobre lo que no se construye forma parte por igual. Por eso llevamos una breve “lista de aún no”, con las funciones aplazadas deliberadamente y el motivo de cada una. Así queda claro que algo no se olvidó, sino que se aplazó, y la lista se convierte más tarde en la base de la planificación de la ampliación.

Varias fases de ampliación pueden representarse como capas que se apoyan unas en otras, cada una con su propio objetivo de aprendizaje.

Una objeción frecuente dice que un MVP es un producto desechable que después hay que reescribir por completo. Es cierto si se construye así. No lo es necesariamente. Lo decisivo es dónde se ahorra. Se ahorra en alcance, apariencia y casos especiales, no en el modelo de datos, la protección de accesos y la trazabilidad. Un modelo de datos limpio se puede ampliar; uno caótico solo se puede sustituir.

En la práctica apostamos por componentes probados y extendidos: una base de datos relacional, una interfaz web que funciona en el smartphone y en el ordenador, inicio de sesión mediante métodos consolidados, copias de seguridad periódicas. Se evitan desarrollos propios para problemas estándar como la gestión de contraseñas o el envío de correos electrónicos. Eso no solo reduce el esfuerzo, sino que facilita la transición a la ampliación posterior, porque otros desarrolladores conocen los componentes.

El trabajo se desarrolla en ciclos cortos. A una demostración le sigue el uso por usuarios reales, después una evaluación y la decisión sobre el siguiente recorte. Una versión pasa al uso diario a las pocas semanas, no solo cuando todas las funciones están terminadas. Para la trazabilidad, cada cambio queda documentado en un control de versiones y el equipo puede probar en un entorno de pruebas antes de que algo salga en producción.

Para garantizar la seguridad sirven pocas comprobaciones elegidas con criterio. Los flujos centrales cuentan con pruebas automatizadas para que los cambios posteriores no los dañen sin que nadie lo note. Para los datos vale lo mismo que para los sistemas mayores: las copias de seguridad no solo deben ejecutarse, sino haberse restaurado una vez a modo de prueba. Todo lo demás, como un concepto de permisos sofisticado, llega cuando el núcleo se sostiene.

Apenas hay otra cuestión que se discuta con tanta pasión. El precio cerrado promete seguridad, el tiempo y materiales promete flexibilidad, y ambas promesas son solo medio ciertas. Un precio cerrado es fiable si el servicio está descrito con exactitud. Cuanto más difusa es la necesidad, más margen incluye el proveedor o más disputa surge después sobre lo que estaba “incluido”. El precio cerrado traslada el riesgo, no lo elimina.

El tiempo y materiales es más honesto cuando el objetivo aún no está definido. Usted paga por el trabajo realmente realizado y conserva el control. El precio es disciplina por su parte: sin un límite máximo, sin avances periódicos y sin una priorización clara, un proyecto puede ampliarse silenciosamente. Quien lo utilice debería fijar un marco, por ejemplo un presupuesto por ciclo con la posterior decisión sobre el siguiente.

Como término medio resulta eficaz un modelo escalonado. La prueba, es decir, observación, prototipo y primer MVP, se acuerda como un paquete asumible con alcance y precio fijos, porque puede describirse de antemano. La ampliación posterior se desarrolla en ciclos, cada uno con un límite máximo y una aprobación clara. Así hay una salida en cada punto, y la decisión sobre el presupuesto grande se toma con conocimiento y no con esperanza.

La honestidad exige también reconocer que este modelo tiene inconvenientes. El coste total no está fijado al principio. Si internamente necesita una suma fija para aprobar el presupuesto, puede indicarse como un rango que se estrecha tras la prueba. Y un enfoque escalonado presupone que usted tenga tiempo para dar su opinión. Si falta, ni el mejor contrato ayuda.

En un proyecto iterativo los cambios son lo normal, no una perturbación. Eso no hace superflua la gestión de cambios, sino necesaria, porque sin reglas la flexibilidad se convierte en arbitrariedad. Ha dado buen resultado una lista breve en la que cada cambio consta con su motivo, el esfuerzo estimado y su efecto en el plazo o el presupuesto, y una persona de su parte que decida las prioridades. Varios responsables de decisión con deseos distintos son el riesgo más frecuente en este tipo de proyectos.

También la aceptación necesita otra forma. En lugar de una única cita al final, hay criterios de aceptación por ciclo, formulados de modo que puedan observarse. “El software es fácil de usar” no es uno. “Un empleado nuevo registra un pedido sin ayuda tras diez minutos de instrucciones” sí lo es. Estos criterios pueden comprobarse en el día a día y evitan la discusión sobre interpretaciones.

Otro caso especial son los datos existentes. Si se van a migrar datos antiguos, a menudo solo en la prueba se ve lo heterogéneos que son: clientes duplicados, texto libre en lugar de selección, datos obligatorios ausentes. Recomendamos importar los datos pronto con un pequeño extracto, porque de lo contrario se subestima la depuración. Lo mismo vale para las interfaces con sistemas de terceros, cuyo comportamiento solo se conoce de verdad en la práctica.

Por último, está el caso de que la hipótesis resulte falsa. Es un buen resultado, aunque no lo parezca. Con un esfuerzo limitado se ha averiguado que el camino previsto no se sostiene, y se puede cambiar de rumbo o decidir no seguir adelante con el proyecto. Para ello debería establecer de antemano cómo se reconocerá, o de lo contrario cada comentario se interpretará como una confirmación.

Un enfoque MVP mejora la base para decidir, no automáticamente el resultado. Lo que puede esperar es que los mayores supuestos erróneos se detecten antes que en un proyecto planificado por completo de antemano. Que al final eso ahorre dinero o tiempo depende del proyecto, del equipo y de la calidad de la colaboración. No podemos indicar con seriedad porcentajes de ahorro.

El beneficio puede medirse con indicadores cercanos al día a día. Entre ellos están el tiempo del proceso central frente al método anterior, el número de consultas y correcciones por operación, la proporción de operaciones que realmente se generan en el sistema en lugar de en papeles o tablas, y el uso voluntario tras la fase de introducción. Antes de empezar debería recabarse a grandes rasgos la situación actual, pues de lo contrario falta la comparación.

Cuente con varias semanas de observación antes de que aparezcan patrones. Los primeros días están marcados por la curiosidad y los problemas de arranque; el uso solo resulta significativo cuando pasa el atractivo de la novedad. Es otra razón para no fijar la prueba demasiado corta. Resulta útil además hablar, tras la fase de observación, con los usuarios que evitan el sistema: sus motivos suelen mostrar con más exactitud que cualquier estadística qué supuesto no se sostuvo y si puede corregirse con un ajuste o solo renunciando a él.

No puede garantizarse que el MVP crezca después hasta convertirse en la solución completa sin reformas, que todos los implicados acepten el software ni que el precio total se mantenga por debajo de un límite determinado. Lo que sí puede prometerse es un procedimiento transparente, avances honestos y la posibilidad de salir en puntos definidos.

La idea más importante es que la claridad nace del uso, no de la descripción. Eso no significa que las descripciones carezcan de valor. Un documento conciso con la imagen del objetivo, la hipótesis central, la lista de aún no y los criterios de aceptación ha demostrado a menudo ser mejor base de trabajo que un pliego de requisitos exhaustivo, porque deja constancia de las decisiones sin presentar los supuestos como hechos.

La segunda conclusión se refiere a la participación. Implicar pronto a los usuarios no significa sentarlos en talleres, sino darles algo tangible y observar su reacción. Incluso un prototipo clicable que una compañera maneja durante cinco minutos aporta a menudo más que un día de conversaciones sobre requisitos. Igual de importante es no preguntar solo a los entusiastas, sino también a los escépticos, porque sus objeciones suelen ser más concretas y afectan justo a los puntos en los que el día a día pondrá más tarde a prueba el sistema.

En tercer lugar, toda decisión sobre el alcance debería incluir un rechazo razonado. Un MVP que sirve un poco para todo no es un MVP. Quien solo añade funciones y nunca las elimina está construyendo un pliego de requisitos en código. Ayuda una regla fija: para cada función nueva se indica qué supuesto comprueba y cómo se reconocerá.

Un pliego de requisitos no es un error, pero a menudo es el primer paso equivocado. Si no está seguro de que el equipo vaya a aceptar un software nuevo y de que la imagen del proceso sea correcta, un núcleo pequeño y utilizable es la forma más económica de averiguarlo. Quien quiere encargar un MVP compra sobre todo una respuesta fiable a la pregunta de qué debería construirse realmente.

El siguiente paso es asumible. Formule en una frase qué debe cambiar en el día a día y anote cómo lo reconocería. Añada tres cosas que expresamente aún no necesita. Con esta media página se puede mantener una conversación que logra más que un documento largo. Con gusto lo revisamos con usted y le diremos con claridad si un enfoque MVP encaja con su proyecto o si un pliego de prescripciones clásico es la mejor opción.