Modelos de Contratación, Presupuestos y Acuerdos de Nivel de Servicio (SLA)

El desarrollo de software profesional opera bajo marcos contractuales y financieros que determinan cómo se asume el riesgo económico entre el cliente (quien financia y encarga el software) y el proveedor (el equipo o consultora que lo construye).

Elegir un modelo de contratación inadecuado es una de las causas más frecuentes de pleitos legales, retrasos y degradación de la calidad del código.

1. Los Tres Grandes Modelos de Contratación de Software #

1┌───────────────────────────────┬───────────────────────────────┐
2       │ PRECIO FIJO (Fixed Price)     │ TIEMPO Y MATERIALES (T&M)     │
3       ├───────────────────────────────┼───────────────────────────────┤
4       │ • Alcance, plazo y coste fijos│ • Tarifa por hora/día de dev  │
5       │ • El riesgo lo asume el DEV   │ • El riesgo lo asume CLIENTE  │
6       │ • Inflexible ante cambios     │ • Máxima agilidad y evolución │
7       └───────────────┬───────────────┴───────────────┬───────────────┘
8                       │                               │
9                       ▼                               ▼
10       ┌───────────────────────────────────────────────────────────────┐
11       │     PRESUPUESTO ÁGIL CON ALCANCE VARIABLE (Capped T&M)        │
12       │     • Techo presupuestario cerrado + Sprints ágiles           │
13       │     • El cliente prioriza qué historias entran y cuáles no    │
14       └───────────────────────────────────────────────────────────────┘

A. Precio Fijo (Fixed Price / Proyecto Llave en Mano) #

• Cómo funciona: Se pacta un precio cerrado (ej. 30.000€) y una fecha límite para entregar una especificación técnica de requisitos cerrada.
• Ventajas: Certeza económica inicial para departamentos de compras y licitaciones públicas.
• El Problema del Precio Fijo en Software: Como el software siempre sufre cambios imprevistos, el proveedor suele inflar el presupuesto con un colchón de riesgo del 30% al 50%. Ante cualquier petición nueva del cliente, el proveedor detiene el trabajo exigiendo costosas ampliaciones contractuales (Change Requests).

B. Tiempo y Materiales (Time & Materials - T&M) #

• Cómo funciona: El cliente contrata un equipo de desarrolladores y paga periódicamente según las horas o jornadas dedicadas (ej. 45€/hora por desarrollador backend senior).
• Ventajas: Es el modelo natural para la agilidad. Permite cambiar prioridades de desarrollo en cada sprint sin fricciones legales ni renegociar contratos.
• Riesgo: Si el cliente no gestiona adecuadamente el backlog, el coste puede dispararse sin obtener un producto cerrado.

C. Presupuesto Ágil con Alcance Variable (Capped T&M / Target Cost) #

• Cómo funciona: Combina lo mejor de ambos mundos. Se fija un techo máximo presupuestario (ej. 60.000€ en 5 sprints de 2 semanas) y se acuerda que el alcance es variable.
• Mecanismo: En cada sprint, el cliente prioriza las historias de usuario más valiosas (Must/Should en MoSCoW). Si al llegar al sprint final se agota el presupuesto, el cliente dispone de un software completamente funcional y probado con las funciones esenciales, dejando las secundarias para una fase posterior.

2. Acuerdos de Nivel de Servicio (SLA - Service Level Agreement) #

Una vez que el software entra en producción, el contrato de desarrollo suele transicionar a un contrato de mantenimiento y soporte regulado por un SLA.

Un SLA es un acuerdo contractual vinculante que define los estándares mínimos de calidad, disponibilidad y tiempos de soporte que el proveedor garantiza al cliente.

Disponibilidad del Sistema (Uptime y los "Nueves"): #

$\text{Disponibilidad (\%)} = \frac{\text{Tiempo Total} - \text{Tiempo de Caída}}{\text{Tiempo Total}} \times 100$

Tiempos de Respuesta y Resolución por Severidad de Incidencia #

El SLA estipula plazos estrictos según la gravedad del incidente:

1┌──────────┬─────────────────────────────┬─────────────────────┬─────────────────────┐
2│ Nivel    │ Definición del Incidente    │ Tiempo de Respuesta │ Tiempo de Resolución│
3├──────────┼─────────────────────────────┼─────────────────────┼─────────────────────┤
4│ P1 - CRÍT│ Caída total del sistema     │ Menos de 15 minutos │ Menos de 2 horas    │
5│ P2 - ALTO│ Función clave dañada        │ Menos de 1 hora     │ Menos de 8 horas    │
6│ P3 - MED │ Error con solución temporal │ Menos de 4 horas    │ Menos de 48 horas   │
7│ P4 - BAJO│ Mejora menor o error visual │ Menos de 24 horas   │ Siguiente release   │
8└──────────┴─────────────────────────────┴─────────────────────┴─────────────────────┘

• Penalizaciones: Si el proveedor incumple los tiempos del SLA P1, el contrato suele contemplar reembolsos automáticos (Service Credits) deducibles de la factura mensual de mantenimiento.

3. Caso Práctico: Elección del Modelo Contractual #

Una startup médica tiene una idea innovadora para diagnosticar lesiones cutáneas con inteligencia artificial. No disponen de una especificación técnica cerrada y necesitan lanzar un prototipo rápido en 3 meses para captar inversión.

1. ¿Por qué un contrato de Precio Fijo fracasaría estrepitosamente? Porque el algoritmo y la UX requerirán constantes ajustes experimentales; un contrato cerrado bloquearía cada cambio con disputas legales.
2. ¿Qué modelo contractual es el idóneo? Un contrato de Presupuesto Ágil con Alcance Variable (Capped T&M), donde la startup fija un límite de gasto de 40.000€ y prioriza quincenalmente con el equipo técnico las funcionalidades más críticas para el demo con inversores.