Al negociar el precio de un proyecto de software a medida, la unidad que más suelen alinear ambas partes, A y B, es «hombre‑día» : cuántos ingenieros, durante cuántos días y a qué precio unitario. Este modelo funciona bien cuando los requisitos son estables y los límites de entrega están claros; pero en cuanto las reglas del terreno cambian con frecuencia, las herramientas de IA elevan la eficiencia de codificación y la parte A sigue aceptando según el criterio de «acumular cabezas», surgen conflictos: la parte B considera que los requisitos se han extendido, mientras que la parte A piensa que «no se ha añadido personal, pero no hay más resultados».
Señal política: pasar de vender cabezas a vender resultados
En septiembre de 2026, el Ministerio de Industria y Tecnología de la Información publicó el «Plan de Implementación de la Acción Especial “IA + Software”», en el que se menciona en varias ocasiones impulsar la transformación del modelo de producción de software, desarrollar modelos como servicio y agentes como servicio, y establecer claramente que para 2028 se crearán aplicaciones ejemplares de software basadas en agentes en sectores clave. El documento no descarta el desarrollo a medida, pero transmite una dirección clara: para evaluar el valor del software, cada vez se valora más la efectividad real, en lugar de limitarse a contar cuántos hombre‑días se han invertido .
Para las empresas que están implementando ERP, MES, CRM o sistemas de gestión sectorial, esto significa que si en los contratos aún solo se indica «XX personas × XX días», tras la puesta en marcha será fácil caer en discusiones del tipo «el código está terminado, pero el negocio no lo utiliza». Una forma más sostenible de redactar es dividir la entrega en resultados empresariales verificables .
Lógica empresarial: los hitos deben ser más concretos que los hombre‑días
Se debe actualizar el sistema de pago del proyecto de «pagos por etapas» a «pagos por hitos»; cada hito debe cumplir simultáneamente cuatro condiciones:
- Escenario empresarial : quién lo utiliza y qué operación resuelve (por ejemplo, «el encargado del almacén escanea para ingresar mercancías» en lugar de «completar el módulo de ingreso de mercancías»).
- Criterios de datos : qué datos maestros, campos de estado y rangos de permisos están involucrados, y cuáles son las reglas de muestreo.
- Guía de aceptación : con datos de prueba dados, qué procesos se deben ejecutar y qué documentos o informes se deben generar.
- Manejo de excepciones : cómo responde el sistema ante fallos, quién tiene autoridad para realizar cambios y si se deja registro.
Los hitos no deberían superar las 2–4 semanas por uno; si son demasiado largos, volveremos al «desarrollo en caja negra». Un ejemplo típico de desglose: datos maestros y permisos → ciclo cerrado de documentos clave → informes y conciliación → interfaces y cambio de entorno de producción.
Lógica de diseño: incluir el alcance, los cambios y la «asistencia inteligente» en el contrato
La codificación asistida por IA, la generación automática de casos de prueba y la completitud inteligente de documentos cambiarán el consumo de hombre‑días para la misma funcionalidad, pero no modificarán automáticamente la complejidad del negocio . En el contrato y en las especificaciones de requisitos, se recomienda incluir apartados específicos:
- Línea base del alcance (Baseline) : lista de funciones + lista de lo que queda fuera del alcance (Out of Scope); cualquier cambio debe tramitarse mediante una solicitud de cambio.
- Reglas de tarificación de cambios : los nuevos hitos se valorarán según «escenario + guía de aceptación», en lugar de añadir hombre‑días de forma improvisada.
- Límites de la asistencia inteligente : en qué etapas puede utilizarse la IA para mejorar la eficiencia (generación de código, borradores de documentos), y en cuáles es indispensable la firma manual (seguridad, cumplimiento, compromisos externos).
- Propiedad del conocimiento acumulado : quién posee los documentos del proceso, la configuración y los scripts, para evitar brechas en la operación posterior a la entrega.
Implementación técnica: automatización y observabilidad en la aceptación
Para hacer que la orientación a resultados sea realmente viable, el equipo técnico debe colaborar en tres aspectos:
- Ingreso de casos de aceptación en el sistema : cada hito corresponde a un conjunto de casos de prueba automáticos o semiautomáticos, que pueden repetirse en las pruebas de regresión.
- Aislamiento del entorno y de los datos : los datos del entorno UAT pueden reiniciarse, evitando que «solo pase en el entorno de demostración».
- Registro de eventos observable : las operaciones clave cuentan con registros de auditoría, permitiendo rastrear quién modificó qué en caso de controversia.
Si el proyecto incluye agentes o motores de reglas, la aceptación debería incorporar un mecanismo de inspección aleatoria : introducir casos límite al azar, verificar si las respuestas negativas, los ascensos a personal humano o los bloqueos de permisos cumplen con el diseño, en lugar de limitarse a comprobar si «puede conversar».
Tres tipos comunes de controversias y sus prevenciones
Controversia número uno: «Se han realizado todas las funciones, ¿por qué el negocio no las usa?» — Prevención: vincular los hitos con las operaciones específicas de los puestos y con el registro de asistencia a la formación; durante la aceptación, realizar recorridos in situ, no limitarse a presentar PPT.
Controversia número dos: «¿Por qué hay que cobrar extra por añadir una pequeña demanda?» — Prevención: especificar en la solicitud de cambio los hitos, scripts y plazos afectados, y proceder con el desarrollo solo después de que ambas partes firmen.
Controversia número tres: «La IA ha mejorado la eficiencia, ¿se pueden reducir los hombre‑días?» — Prevención: diferenciar en el contrato entre «costo de implementación» y «complejidad del negocio»; los beneficios de la mejora pueden reflejarse en el precio total o en el plazo, pero los estándares de aceptación no deben rebajarse.
Recomendación piloto: comenzar con un módulo de ciclo cerrado
No es necesario esperar a que todo el sistema reescriba el contrato. Elegir un módulo que pueda cerrar su ciclo en 2–3 semanas (como el control de entradas y salidas, la elaboración de órdenes de trabajo o la aprobación de gastos), y firmar un acuerdo complementario con un nuevo formato: enumerar escenarios, scripts, excepciones y puntos de pago. Una vez probado, extenderlo a todo el proyecto. Para medir el éxito, observar si las solicitudes de cambio reducen el tiempo de disputas y si la tasa de aprobación en la fase UAT aumenta , en lugar de centrarse en cuántos hombre‑días reportó menos la parte B. Si el módulo piloto se elige bien, el cambio del contrato en todo el proyecto ganará credibilidad. Los hombre‑días no desaparecerán de la noche a la mañana, pero están pasando de ser la «unidad única de fijación de precios» a convertirse en una «referencia para estimar costos». Incluir los hitos y las guías de aceptación en el contrato es la habilidad básica para que el software a medida siga entregando resultados confiables en el contexto de «IA + software».
Los hombre‑días no desaparecerán de la noche a la mañana, pero están pasando de ser la «unidad única de fijación de precios» a convertirse en una «referencia para estimar costos». Incluir los hitos y las guías de aceptación en el contrato es la habilidad básica para que el software a medida siga entregando resultados confiables en el contexto de «IA + software».
Complementar con precios fijos y ciclos ágiles
La aceptación por hitos no excluye la agilidad: cada Sprint aún puede entregar incrementos demostrables, pero el pago y la aceptación formal dependen de un hito mayor. En los contratos de precio fijo, especialmente, conviene especificar claramente el «punto de congelación del alcance»: después de qué revisión se tramitan los nuevos requisitos mediante una solicitud de cambio, evitando añadir funciones de forma verbal. Para los módulos que incluyen agentes, se recomienda realizar la aceptación por hitos separados, evaluando la «versión de las reglas + tasa de aprobación de las inspecciones», sin vincularlo a la puesta en marcha global de toda la plataforma.
Los datos del sector muestran que aproximadamente un tercio de los fracasos en proyectos de software se deben a la falta de claridad en los requisitos y los criterios de aceptación, más que a la propia implementación técnica. Antes de debatir si la IA sustituyó a algunos programadores, conviene primero definir en el contrato «qué significa estar terminado», lo cual resulta mucho más valioso. En la próxima revisión de la propuesta, podría plantearse esta pregunta: si mañana todo el equipo de la parte B se tomara vacaciones, ¿podríamos determinar mediante la guía de aceptación si el hito actual cumple con los estándares? Si no se puede responder, significa que la aceptación aún no está claramente definida. Incluir los hitos en el contrato no es para dificultar la labor de la parte B, sino para que ambas partes discutan sobre «si ya está hecho» desde la misma página. Esto es especialmente importante en proyectos donde la mejora gracias a la IA es más evidente, y conviene aclararlo desde el principio.