Cuándo el desarrollo a la medida tiene sentido
(y cuándo es una trampa)

Por qué el 70% de los proyectos de desarrollo superan presupuesto o tiempo

El Chaos Report del Standish Group, publicado con datos de miles de proyectos de software durante décadas, muestra consistentemente que entre el 60% y el 70% de los proyectos de desarrollo a la medida se entregan tarde, fuera de presupuesto, o con menos funcionalidades de las prometidas. Lo notable de esta estadística no es el porcentaje, sino su consistencia a través del tiempo: no mejora significativamente con los años ni con la adopción de nuevas metodologías.

La razón es que el problema no es técnico. Los proyectos no fracasan porque los desarrolladores sean malos o la tecnología sea inadecuada. Fracasan porque el proceso de definición del alcance es inadecuado desde el inicio. Una empresa que describe sus requerimientos en términos vagos como "quiero un sistema que gestione mis ventas" está comprando un proyecto de duración indefinida. Una empresa que puede especificar exactamente qué flujo de trabajo, qué reglas de negocio, qué integraciones, y qué criterios de aceptación necesita, puede tener un proyecto exitoso.

La causa raíz: el alcance ambiguo

El alcance ambiguo es el origen de casi todos los proyectos que se extienden. Cuando el alcance no está bien definido, cada semana alguien en la empresa cliente descubre que el sistema necesita hacer algo que no estaba en el contrato original. El desarrollador tiene que decidir si lo hace sin cargo —perdiendo dinero— o cobra extra —generando conflicto con el cliente. Ninguna de las dos opciones produce buenos resultados.

La trampa del alcance ambiguo se instala en la fase de ventas: el cliente describe un problema, el proveedor propone una solución a alto nivel, y ambas partes asumen que entienden lo mismo. La cotización se firma con base en ese entendimiento compartido pero nunca documentado. Las sorpresas empiezan cuando el desarrollador empieza a hacer preguntas específicas que el cliente no había considerado: ¿Cuántos niveles tiene la jerarquía de aprobación? ¿Qué pasa cuando un cliente tiene múltiples contactos autorizados? ¿Las reglas de descuento aplican igual para todos los canales?

Cada una de esas preguntas que no tiene respuesta en el documento de alcance es potencialmente una semana de retraso y un costo adicional. Un proyecto de 50 preguntas sin responder puede fácilmente triplicar la duración estimada.

Las 4 fases obligatorias de un proyecto de desarrollo a la medida exitoso

Los proyectos de desarrollo a la medida que se entregan dentro de tiempo y presupuesto comparten una característica: el cliente y el proveedor invierten tiempo suficiente en definir exactamente qué se va a construir antes de escribir una sola línea de código. Las cuatro fases que hacen la diferencia son:

1. Fase 1 — Levantamiento de procesos y especificación funcional (2-4 semanas). Esta fase no es opcional y no puede acelerarse. El proveedor debe mapear el proceso actual de la empresa, identificar los casos de uso, definir los usuarios y sus roles, y documentar las reglas de negocio. El resultado es un documento de especificación funcional que describe exactamente qué hace cada pantalla, qué datos maneja, y qué flujos de trabajo soporta. Este documento es el contrato técnico del proyecto.
2. Fase 2 — Diseño de arquitectura e integración (1-2 semanas). Antes de desarrollar, hay que decidir cómo se conecta el sistema nuevo con el ERP y los demás sistemas existentes. Las decisiones de arquitectura que se toman en esta fase determinan la mantenibilidad del sistema durante años. Una mala decisión de arquitectura en esta fase puede duplicar el costo de mantenimiento en los próximos tres años.
3. Fase 3 — Desarrollo por sprints con demos de avance (6-16 semanas dependiendo de complejidad). El desarrollo debe hacerse en iteraciones cortas de dos semanas con demos al cliente al final de cada sprint. El cliente puede validar que lo que se está construyendo corresponde a lo que especificó, y puede hacer ajustes menores antes de que el costo de cambio sea alto. Los cambios grandes que se descubren en la última semana del proyecto siempre cuestan más que los que se identifican en el sprint 2.
4. Fase 4 — Pruebas de aceptación y go-live (2-3 semanas). Las pruebas de aceptación las hace el usuario final, no el desarrollador. El desarrollador hace pruebas unitarias y de integración durante el desarrollo. Las pruebas de aceptación validan que el sistema hace lo que el negocio necesita en condiciones reales. Esta distinción es importante: un sistema puede pasar todas las pruebas técnicas y fallar en las pruebas de aceptación porque los usuarios descubren flujos que no estaban en la especificación.

"El primer proyecto que hicimos con una empresa de desarrollo duró 18 meses y costó el triple. El segundo proyecto, con otro proveedor que insistió en hacer la especificación funcional completa primero, tardó 4 meses y quedó dentro del presupuesto. La diferencia no fue el código: fue el proceso." — Gerente de Proyectos TI, grupo industrial, Monterrey, 1,200 empleados

La especificación funcional: el documento que protege a ambas partes

La especificación funcional es el documento más importante en un proyecto de desarrollo a la medida y también el más frecuentemente omitido. Muchos proveedores lo evitan porque requiere tiempo y esfuerzo que no siempre se cobra por separado en la fase de ventas. Muchos clientes lo evitan porque les parece un paso burocrático que retrasa el inicio del desarrollo "real".

Ambas percepciones son incorrectas. La especificación funcional no retrasa el proyecto: lo acelera. Un proyecto que invierte dos semanas en especificación funcional y luego tarda diez semanas en desarrollo es más rápido que un proyecto que empieza a desarrollar de inmediato y descubre en la semana ocho que hay un requerimiento fundamental que nadie documentó y que requiere refactorizar tres módulos.

La especificación funcional también protege al cliente: si el proveedor entrega algo diferente a lo que está en el documento, el cliente tiene evidencia contractual de la discrepancia. Y protege al proveedor: si el cliente pide algo que no estaba en el documento, el proveedor puede cobrar el trabajo adicional sin conflicto.

Mantenimiento post go-live: el costo que nadie presupuesta

El presupuesto de un proyecto de desarrollo a la medida casi nunca incluye el costo de mantenimiento post go-live. Este es un error frecuente con consecuencias de largo plazo. El software que se pone en producción necesita mantenimiento: corrección de bugs que aparecen en uso real, adaptaciones cuando cambian las reglas de negocio, actualizaciones de seguridad, y compatibilidad con nuevas versiones del ERP o de las APIs de terceros.

Una regla práctica es presupuestar entre el 15% y el 20% del costo de desarrollo original como costo anual de mantenimiento. Un sistema con un costo de desarrollo significativo necesita ese porcentaje del mismo costo anualmente para mantenerse en condiciones operativas. Este costo debe incluirse en la evaluación de costo total de propiedad cuando se compara desarrollo a la medida contra módulos SaaS con cuota mensual.

Plataforma propia vs. construir desde cero: la tercera opción

Entre el módulo SaaS estándar y el desarrollo completamente desde cero existe una tercera opción que combina ventajas de ambas: las plataformas de desarrollo con arquitectura probada. Estas son plataformas que tienen componentes reutilizables —autenticación, gestión de usuarios, integraciones con ERPs comunes, arquitectura multi-tenant— que aceleran significativamente el desarrollo sin sacrificar la capacidad de customización.

Una plataforma de desarrollo probada puede reducir el tiempo de un proyecto de desarrollo a la medida entre un 40% y un 60%, porque los componentes transversales ya existen y solo hay que configurarlos. El cliente obtiene una solución más específica a su proceso que un módulo estándar, pero con menores tiempos y costos que un desarrollo completamente desde cero. Es el punto óptimo para muchos requerimientos de empresas medianas que tienen procesos genuinamente específicos pero no tienen presupuesto para proyectos de 12 meses.