Cómo redactar contratos compatibles con lo ágil: una lista de verificación para esta semana
Si tu equipo trabaja con Scrum pero tu contrato exige un alcance congelado, un precio fijo y una fecha de entrega definida antes de escribir una sola línea de código, ambos están en una guerra silenciosa. El contrato supone que puedes predecirlo todo de antemano; el Sprint supone que aprenderás sobre la marcha. Tras dos años en que los plazos de suministro, el personal e incluso las oficinas cambiaban cada mes, el costo de fingir que todo se puede fijar por adelantado pocas veces ha sido tan evidente.
No necesitas un título en derecho para hacer un contrato más amigable con lo ágil. Necesitas cambiar lo que el acuerdo protege: en lugar de garantizar una lista cerrada de funciones, garantiza una forma de trabajar, una cadencia de decisiones y una salida clara. Aquí tienes una lista que puedes llevar esta semana a tu próxima conversación de compras o con un proveedor.
Qué incluir en el acuerdo
Fija la cadencia, no el alcance. Acuerda la duración del Sprint, una Revisión de Sprint a la que asista el comprador y una Lista de Producto ordenada por el Product Owner del comprador. La lista puede cambiar; el ritmo de inspeccionar y volver a decidir, no.
Cobra por tiempo y materiales con tope, o por Sprint. Compra capacidad por un período fijo en vez de un conjunto cerrado de funciones. El tope tranquiliza a finanzas; el derecho a detenerse tras cualquier Sprint tranquiliza a todos.
Haz contractual el rol de Product Owner. Nombra a quién ordena la lista y a quién puede aceptar el trabajo en la Revisión. La demora en decidir, no la velocidad de los desarrolladores, es lo que suele hundir los proyectos remotos e híbridos.
Define «terminado» una sola vez, para todo. Remite a una Definición de Terminado escrita en el contrato para que «listo» no se discuta función por función a la hora de facturar.
Incluye una salida sin culpa. Permite que el comprador finalice el contrato al cierre de un Sprint con aviso, conservando todo el software funcional producido. Es la cláusula que hace honesta la entrega incremental.
Qué dejar fuera
Cronogramas detallados de funciones en un anexo: se convierten en una máquina de órdenes de cambio en cuanto aprendes algo.
Penalizaciones atadas a una fecha de lanzamiento fija que se adivinó antes del descubrimiento.
Puntos de aprobación que exigen una única gran aceptación al final, lo que anula el sentido de revisar cada Sprint.
Lenguaje vago de «mejores esfuerzos del sector» sin cadencia detrás: no protege a nadie.
Una prueba útil: lee el borrador y pregunta qué pasa si, en el Sprint 3, el equipo descubre que la función más valiosa no figuraba en ninguna lista al firmar. Un buen contrato ágil convierte eso en un simple reordenamiento de la lista. Uno malo lo convierte en una disputa. El contrato debe dejar que aprender cambie el producto sin cambiar la relación.
Nada de esto significa que los contratos se vuelvan laxos. Se vuelven específicos en lo correcto —cadencia, roles, aceptación y salida— y deliberadamente discretos en lo que nadie puede fijar con honestidad el primer día.
Rehacer un contrato para que financie valor en vez de pelear con tu modelo de entrega conviene hacerlo bien desde el principio: la asesoría en ejecución de programas y proyectos de XNM ayuda a equipos del sector público y de grandes proyectos a estructurar acuerdos sólidos.