10 min lectura • Guide 831 of 877
Modelos de Contratación Ágil
Los contratos tradicionales luchan contra ágil. GitScrum ayuda a los equipos a gestionar compromisos ágiles con visibilidad y métricas que soportan modelos de contratación flexible.
Desafíos de Contratación
Por Qué Falla lo Tradicional
CONTRATOS TRADICIONALES VS ÁGILES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PRECIO FIJO, ALCANCE FIJO: │
│ ────────────────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ CONTRATO: Construir sistema X con funciones A, B, C, D ││
│ │ por $500,000 para el 31 de diciembre ││
│ │ ││
│ │ PROBLEMA 1: Los requisitos cambian ││
│ │ Cliente: "Necesitamos E en lugar de D" ││
│ │ Proveedor: "Eso está fuera de alcance, orden de cambio"││
│ │ Resultado: Conflicto, retrasos, sobrecostos ││
│ │ ││
│ │ PROBLEMA 2: Descubrimiento durante desarrollo ││
│ │ Equipo: "La función B es más compleja de lo estimado" ││
│ │ Opciones: Cortar esquinas O exceder presupuesto ││
│ │ Resultado: Calidad sufre o sobrecostos ││
│ │ ││
│ │ PROBLEMA 3: Aprendizaje ││
│ │ Equipo: "Los usuarios no quieren A, quieren F" ││
│ │ Contrato: "Construye A de todos modos, está en alcance"││
│ │ Resultado: Construir lo incorrecto ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ TENSIÓN CENTRAL: │
│ │
│ PRECIO FIJO asume: ÁGIL asume: │
│ • Alcance conocido • Alcance evolucionará │
│ • Cambio es problema • Cambio es esperado │
│ • Planificar, luego ejecutar • Descubrir mientras se construye│
│ │
│ LOS CONTRATOS NO ENCAJAN CON EL PROCESO │
└─────────────────────────────────────────────────────────────┘
Tipos de Contrato Ágil
Modelos Alternativos
CONTRATOS AMIGABLES CON ÁGIL:
┌─────────────────────────────────────────────────────────────┐
│ │
│ MODELO 1: TIEMPO Y MATERIALES (T&M) │
│ ─────────────────────────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Se paga por: Tiempo trabajado a tarifas acordadas ││
│ │ Alcance: Flexible, se decide sobre la marcha ││
│ │ ││
│ │ ✅ Flexibilidad total ││
│ │ ✅ Puede adaptarse al aprendizaje ││
│ │ ⚠️ Sin predictibilidad de costos ││
│ │ ⚠️ Cliente asume todo el riesgo ││
│ │ ││
│ │ VARIACIÓN: T&M con tope ││
│ │ "T&M hasta $500K, renegociar si se acerca" ││
│ │ Agrega predictibilidad manteniendo flexibilidad ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ MODELO 2: PRECIO FIJO POR ITERACIÓN │
│ ──────────────────────────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Se paga por: Sprint/iteración a costo fijo ││
│ │ Alcance: Priorizado al inicio de cada sprint ││
│ │ ││
│ │ Ejemplo: ││
│ │ "$50K por sprint de 2 semanas, 10 sprints planeados" ││
│ │ Cliente prioriza backlog cada sprint ││
│ │ Puede parar después de cualquier sprint ││
│ │ ││
│ │ ✅ Costo predecible por sprint ││
│ │ ✅ Flexibilidad en alcance ││
│ │ ✅ Puntos de salida incorporados ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ MODELO 3: COSTO OBJETIVO │
│ ──────────────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Objetivo: $500K para alcance estimado ││
│ │ Rango: $450K - $550K aceptable ││
│ │ ││
│ │ Si bajo objetivo: Compartir ahorros 50/50 ││
│ │ Si sobre objetivo: Compartir exceso 50/50 (hasta tope) ││
│ │ ││
│ │ ✅ Incentivos alineados ││
│ │ ✅ Ambas partes comparten riesgo y recompensa ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Modelos Avanzados
CONTRATOS ÁGILES AVANZADOS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ MODELO 4: DINERO POR NADA, CAMBIO GRATIS │
│ ───────────────────────────────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ DINERO POR NADA: ││
│ │ Cliente puede terminar temprano ││
│ │ Paga 20% del valor restante del contrato ││
│ │ Proveedor obtiene ingreso predecible ││
│ │ Cliente puede parar cuando tiene "suficiente" ││
│ │ ││
│ │ Ejemplo: ││
│ │ 10 sprints a $50K = contrato de $500K ││
│ │ Después del sprint 6, cliente tiene suficiente valor ││
│ │ Restante: 4 sprints = $200K ││
│ │ Cliente paga: 20% × $200K = $40K para salir ││
│ │ Total pagado: $300K + $40K = $340K ││
│ │ Ahorrado: $160K ││
│ │ ││
│ │ CAMBIO GRATIS: ││
│ │ Cliente puede intercambiar ítems del backlog de igual tamaño││
│ │ Sin órdenes de cambio para trabajo equivalente ││
│ │ Alcance total permanece igual, contenido flexible ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ MODELO 5: BASADO EN RESULTADOS │
│ ────────────────────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Se paga por: Resultados logrados, no trabajo realizado ││
│ │ ││
│ │ Ejemplo: ││
│ │ "Pagar $100K si la tasa de conversión mejora 20%" ││
│ │ "Pagar $X por usuario adquirido a través de nueva función"││
│ │ ││
│ │ ✅ Alineados en valor, no esfuerzo ││
│ │ ⚠️ Difícil de definir para resultados complejos ││
│ │ ⚠️ Desafíos de atribución ││
│ │ ││
│ │ Mejor para: Resultados de negocio claros y medibles ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Construyendo Confianza
Mecanismos de Transparencia
CONFIANZA A TRAVÉS DE TRANSPARENCIA:
┌─────────────────────────────────────────────────────────────┐
│ │
│ VISIBILIDAD REGULAR: │
│ ──────────────────── │
│ │
│ DEMOS DE SPRINT: │
│ Cada 2 semanas, mostrar software funcionando │
│ Cliente ve progreso, no promesas │
│ Problemas salen a la luz temprano │
│ │
│ MÉTRICAS COMPARTIDAS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ DASHBOARD COMPARTIDO EN GITSCRUM: ││
│ │ ││
│ │ Velocidad: ████████░░ 30 pts/sprint ││
│ │ Backlog restante: ████████████░░░░░░░░ 120 pts ││
│ │ Presupuesto usado: ████████░░ 60% ││
│ │ Sprints completos: ████████░░ 6/10 ││
│ │ ││
│ │ El cliente puede ver exactamente dónde estamos ││
│ │ Sin sorpresas al final ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ PLANIFICACIÓN COLABORATIVA: │
│ ─────────────────────────── │
│ • Cliente participa en planificación de sprint │
│ • Priorización conjunta del backlog │
│ • Decisiones de alcance informadas │
│ │
│ CLÁUSULAS DE TERMINACIÓN TEMPRANA: │
│ ─────────────────────────────────── │
│ • Cualquier parte puede salir con aviso de X sprints │
│ • Reduce riesgo para ambos │
│ • Incentiva satisfacción continua │
└─────────────────────────────────────────────────────────────┘
Negociando Contratos Ágiles
Elementos Clave
ELEMENTOS DE UN CONTRATO ÁGIL:
┌─────────────────────────────────────────────────────────────┐
│ │
│ DEFINIR CLARAMENTE: │
│ ─────────────────── │
│ │
│ CAPACIDAD: │
│ • Tamaño del equipo │
│ • Roles incluidos (dev, QA, UX, etc.) │
│ • Disponibilidad (horas/semana) │
│ │
│ DURACIÓN: │
│ • Número de sprints │
│ • Duración del sprint │
│ • Cláusulas de extensión │
│ │
│ GOBERNANZA: │
│ • Responsabilidades del cliente │
│ • Responsabilidades del proveedor │
│ • Proceso de toma de decisiones │
│ • Escalación de problemas │
│ │
│ FLEXIBILIDAD: │
│ • Cómo manejar cambios de alcance │
│ • Puntos de revisión y ajuste │
│ • Condiciones de terminación │
│ │
│ MÉTRICAS: │
│ • Qué se medirá y reportará │
│ • Frecuencia de reportes │
│ • Definición de éxito │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ NO DEFINIR RÍGIDAMENTE: │
│ ─────────────────────── │
│ │
│ • Lista exacta de funcionalidades │
│ • Fechas de entrega por función │
│ • Especificaciones técnicas detalladas │
│ │
│ Estos deben evolucionar durante el proyecto │
└─────────────────────────────────────────────────────────────┘
Gestión de Cambios Contractuales
Proceso de Cambios
MANEJO DE CAMBIOS EN CONTRATOS ÁGILES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CAMBIOS DENTRO DEL ALCANCE: │
│ ─────────────────────────── │
│ • Intercambio de ítems de tamaño similar │
│ • Refinamiento de requisitos existentes │
│ • Re-priorización del backlog │
│ → No requiere cambio contractual │
│ │
│ CAMBIOS FUERA DEL ALCANCE: │
│ ────────────────────────── │
│ • Nuevos módulos o funcionalidades mayores │
│ • Cambio significativo en complejidad │
│ • Extensión de tiempo o capacidad │
│ → Requiere adenda al contrato │
│ │
│ PROCESO DE ADENDA: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 1. Cliente presenta solicitud ││
│ │ 2. Equipo evalúa impacto (tiempo, costo) ││
│ │ 3. Propuesta de opciones: ││
│ │ a) Agregar tiempo/presupuesto ││
│ │ b) Intercambiar por algo existente ││
│ │ c) Posponer para siguiente fase ││
│ │ 4. Negociación y acuerdo ││
│ │ 5. Documentar en adenda ││
│ │ 6. Agregar al backlog ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Riesgos y Mitigación
Riesgos Comunes
RIESGOS EN CONTRATOS ÁGILES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ RIESGO: ALCANCE INFINITO (T&M) │
│ ────────────────────────────── │
│ Sin límites, el proyecto nunca termina │
│ │
│ MITIGACIÓN: │
│ • Establecer topes de presupuesto │
│ • Revisiones periódicas de valor vs costo │
│ • Definir MVP y versiones posteriores │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ RIESGO: CLIENTE NO PARTICIPA │
│ ───────────────────────────── │
│ Cliente espera recibir producto terminado sin involucrarse│
│ │
│ MITIGACIÓN: │
│ • Definir responsabilidades del cliente en contrato │
│ • SLAs para respuesta y disponibilidad │
│ • Cláusulas si cliente no cumple │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ RIESGO: DESALINEACIÓN DE EXPECTATIVAS │
│ ────────────────────────────────────── │
│ Cada parte entiende algo diferente │
│ │
│ MITIGACIÓN: │
│ • Workshops de alineación antes de firmar │
│ • Backlog inicial con estimaciones │
│ • Demos frecuentes para validar │
│ • Métricas compartidas y visibles │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ RIESGO: DISPUTA SOBRE "TERMINADO" │
│ ───────────────────────────────── │
│ ¿Cuándo se considera el contrato cumplido? │
│ │
│ MITIGACIÓN: │
│ • Definición de Terminado acordada │
│ • Criterios de aceptación por sprint │
│ • Proceso de aceptación formal │
└─────────────────────────────────────────────────────────────┘
Transición de Contratos Tradicionales
Camino de Adopción
TRANSICIÓN A CONTRATOS ÁGILES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ FASE 1: CONTRATO HÍBRIDO │
│ ──────────────────────── │
│ • Mantener estructura tradicional │
│ • Agregar puntos de revisión trimestrales │
│ • Permitir re-priorización limitada │
│ │
│ FASE 2: PRECIO FIJO POR FASE │
│ ──────────────────────────── │
│ • Dividir proyecto en fases más cortas │
│ • Cada fase con alcance flexible │
│ • Decisión de continuar al final de cada fase │
│ │
│ FASE 3: PRECIO FIJO POR SPRINT │
│ ────────────────────────────── │
│ • Costo fijo por sprint │
│ • Alcance priorizado por sprint │
│ • Puntos de salida cada sprint │
│ │
│ FASE 4: CONTRATO COMPLETAMENTE ÁGIL │
│ ──────────────────────────────────── │
│ • Financiar equipos, no proyectos │
│ • Máxima flexibilidad │
│ • Métricas de valor como guía │
│ │
│ CLAVE: Construir confianza progresivamente │
│ Empezar con proyecto pequeño, expandir con éxito │
└─────────────────────────────────────────────────────────────┘