Por qué un desarrollo a medida debe empezar por un MVP

El patrón se repite: una promotora decide que su operativa no cabe en el CRM genérico que tiene contratado, encarga un análisis funcional, recibe un documento de ochenta páginas con el detalle de todo lo que la plataforma debería hacer, y firma un proyecto a doce meses. Al mes nueve, el equipo comercial todavía no ha tocado nada. Cuando por fin lo tocan, resulta que el flujo de reserva que se definió en enero ya no es el que usan, que el módulo de postventa lo rellena una sola persona y que el panel de dirección que ocupó seis semanas de desarrollo lo abre nadie. El dinero ya está gastado.

El documento de requisitos es una hipótesis, no un plano

Un análisis funcional recoge lo que la organización cree que necesita en el momento de escribirlo. Eso incluye procesos que existen por inercia, excepciones que alguien recuerda mal y funcionalidades que se piden por si acaso. En una promoción, la diferencia entre lo que dice el procedimiento de reservas y lo que hace el comercial a las ocho de la tarde con un cliente dudando es considerable. El documento recoge lo primero.

En edificación, el proyecto de ejecución se puede desarrollar completo porque el comportamiento del hormigón es conocido. En software la variable es el comportamiento humano de quien lo usa, y eso no se puede calcular por anticipado. Por eso un desarrollo software a medida inmobiliario que se construye entero sobre el papel acumula un error que solo se manifiesta cuando ya no hay presupuesto para corregirlo.

Qué es un MVP en este contexto (y qué no)

Un MVP es la versión más pequeña del sistema que resuelve de verdad un problema real para un grupo concreto de usuarios, en producción, con datos reales. Dos condiciones importan más que el tamaño: que esté en manos de quien va a usarlo a diario y que cubra el flujo completo de principio a fin, aunque sea estrecho.

Estrecho y profundo, no ancho y superficial

Un MVP que gestiona la reserva de una vivienda desde que el comercial la bloquea hasta que entra el contrato de arras firmado, para una única promoción, sirve. Un MVP que tiene pantallas de todos los módulos —comercial, postventa, obra, dirección— y ninguna termina el proceso, no sirve para nada: nadie puede trabajar con él y, por tanto, no genera información.

La pregunta para decidir el alcance no es qué es importante, porque todo lo es. Es qué parte del proceso, si funcionara bien mañana, cambiaría el día a día de alguien.

Producción, no maqueta

Un prototipo clicable valida que la interfaz se entiende. No valida que el dato de disponibilidad cuadre con el ERP, que el comercial lo abra desde el móvil en la caseta de ventas o que el proceso aguante un fin de semana de puertas abiertas. Las sorpresas caras de un proyecto a medida casi siempre están en la integración y en el dato, no en el diseño de pantallas.

Lo que un MVP compra que un pliego cerrado no

Compra tres cosas concretas. La primera, evidencia sobre qué funcionalidades del documento original sobran. En la práctica, cuando un equipo lleva dos meses usando una herramienta propia, la lista de peticiones que presenta tiene poco que ver con la lista inicial: desaparecen informes que nadie mira y aparecen automatismos que nadie había pedido porque no sabían que eran posibles.

La segunda, capacidad de parar. Un proyecto de doce meses solo admite dos decisiones: seguir o cancelar con pérdida total. Un desarrollo por incrementos admite una tercera, que es la más útil: esto ya está bien, el siguiente euro se gasta en otra cosa.

La tercera, adopción. Un equipo que ha visto cómo sus comentarios cambiaban la herramienta en dos semanas la defiende. Un equipo al que se le entrega un sistema terminado y un manual lo recibe como una imposición de dirección, y el sistema compite con el Excel que ya funcionaba.

Cómo se elige el primer trozo

Tres criterios, por orden. Dolor medible: el proceso que hoy genera errores, duplicidades o llamadas. Frecuencia: algo que se haga todos los días, no el cierre trimestral. Y dependencia externa baja: si el primer incremento exige una integración bidireccional con un ERP cuyo proveedor tarda seis semanas en responder un correo, el MVP deja de ser un MVP.

En promoción residencial, los candidatos habituales son la gestión de disponibilidad y bloqueos comerciales, el seguimiento de incidencias de postventa con el cliente dentro del circuito, y la trazabilidad de la documentación de una operación hasta firma. En comercialización, el enrutado y cualificación de leads entre portales, web y oficina. Son procesos diarios, con dolor visible y con un perímetro que se puede cerrar.

Cuándo el enfoque MVP sale mal o directamente no compensa

No es gratis ni es universal. Hay cuatro situaciones donde conviene no hacerlo así.

Cuando no hay nadie que decida. El MVP funciona si existe una persona con autoridad para priorizar cada dos o tres semanas. Si las decisiones las toma un comité que se reúne una vez al mes, el proyecto va a ir más lento y más caro que con un pliego cerrado, porque el coste de coordinación se multiplica por el número de entregas.

Cuando el dominio no admite versiones parciales. Si lo que se construye tiene un requisito regulatorio o contable que debe cumplirse completo desde el día uno —cierres contables, protección de datos en un flujo con terceros, requisitos de un fondo inversor—, el alcance mínimo viable es mucho mayor de lo que suena la palabra mínimo, y conviene decirlo antes de empezar.

Cuando se usa el MVP como excusa para no pensar la arquitectura. Esto es lo que más daño hace. Empezar pequeño no autoriza a tomar decisiones de modelo de datos que luego impidan crecer. El primer incremento debe ser corto en funcionalidad y serio en estructura. Un MVP construido como un apaño se convierte en un sistema que hay que tirar al segundo año, y entonces la organización concluye, con razón aparente, que el software a medida no funciona.

Y cuando la necesidad está cubierta por producto estándar. Si el proceso es el mismo que el de cualquier otra empresa del sector, construir a medida es pagar por reinventar algo que se alquila por una cuota. El desarrollo propio se justifica donde hay una forma de trabajar que diferencia, no donde hay una funcionalidad de catálogo.

El coste real de empezar pequeño

Hay facturas que se pagan por este camino y conviene tenerlas en el presupuesto. Habrá código que se reescriba: parte de lo construido en el primer incremento se tira cuando el segundo demuestra que el modelo era otro. Eso es aprendizaje, pero sale en la hoja de horas igual que lo demás.

Habrá fricción con compras y con control de gestión, acostumbrados a precio cerrado y alcance cerrado. Un contrato por incrementos exige otro tipo de gobierno: presupuesto por trimestre, criterios de salida definidos y una conversación periódica que alguien tiene que sostener.

Y habrá un periodo incómodo en el que la herramienta nueva convive con la vieja. Ese solape consume tiempo del equipo y es la causa más común de que un MVP se abandone: no porque fuera malo, sino porque nadie reservó horas para usarlo mientras seguía el trabajo normal.

La pregunta útil antes de firmar no es cuánto cuesta la plataforma completa, sino cuánto cuesta averiguar si la plataforma completa es la que hace falta.

Cómo encaja esto en una decisión de inversión

Para un comité que valora una inversión tecnológica, el argumento no es de ahorro, es de riesgo. Un proyecto grande concentra todo el riesgo en una fecha de entrega lejana. Un desarrollo por incrementos reparte ese riesgo en decisiones pequeñas y reversibles, y permite que el gasto siga a la evidencia.

Eso cambia la pregunta de la reunión de seguimiento. Deja de ser cuánto se ha avanzado sobre el plan y pasa a ser qué sabemos ahora que no sabíamos hace dos meses, y qué hacemos con eso. Una plataforma a medida construida así suele acabar siendo más pequeña de lo que se proyectó al principio, y se usa entera. La alternativa es la contraria: grande, completa y usada a medias.

En GU Studio trabajamos esto en desarrollo software a medida inmobiliario. Si quieres ver cómo encajaría en tu caso, cuéntanoslo.