Aunque el Manifiesto Ágil valora más a la colaboración con el cliente que al contrato, los contratos son necesarios cuando se trabaja con proveedores externos. Un contrato en realidad es un conjunto de reglas que delimitan el área de juego. Usar las reglas correctas aumenta las probabilidades del éxito para ambas partes. Usar las reglas incorrectas van a dificultar y entorpecer el progreso. Entonces, ¿cuáles son las reglas de juego disponibles, y cuál es el mejor contrato para un proyecto ágil?
En esta primera parte del artículo de Agile Manifesto, vamos a analizar el propósito y contenido de los contratos, y algunos criterios para evaluar a los contratos ágiles. En el siguiente artículo vamos a ver distintas alternativas para contratos ágiles, examinando sus fortalezas y debilidades.
¿Cuál es el propósito de un contrato?
Los contratos son un conjunto de reglas de juego para el proyecto. En teoría, estas reglas se acuerdan libremente por ambas partes para crear condiciones óptimas que permitan completar con éxito el proyecto. En la práctica, a los contratos se los suele ver como juegos competitivos, en el cual el objetivo es dejar en desventaja a la otra parte, especialmente cuando las cosas van mal. Muchas organizaciones grandes y gobiernos tienen condiciones comunes que tienen que aceptarse en conjunto como pre-requisito para hacer negocios con ellos. Estas condiciones casi nunca son justas, por lo cual un resultado razonable para un proyecto depende en gran medida de la buena relación con el cliente, evitando discutir el contrato o recurrir a la ley (el Manifiesto Ágil hace un punto importante acá: la relación con el cliente es más importante que el contrato escrito!).
Incluso los contratos negociados no siempre intentan llegar a una situación ganar-ganar, por lo que podríamos necesitar la ayuda de expertos. Sin embargo desde la perspectiva del cliente, los contratos no producen ningún valor. Son un desperdicio para el producto, por lo que debe minimizarse el esfuerzo en negociarlos y producirlos.
Un contrato distribuye el riesgo y refleja la confianza entre las partes. ¿Qué ocurre cuando algo sale mal? ¿Quién paga cuánto si el proyecto es más difícil de lo esperado? ¿Quién se beneficia si el proyecto se termina antes de lo planificado?
Usar las reglas incorrectas puede ser perjudicial para el éxito del proyecto. Las reglas malas llevan a precios irrealistas, tiempos imposibles o expectativas funcionales que no se cumplen. Los juegos ganar-perder son perjudiciales para el éxito del proyecto. La calidad casi siempre sufre. Hay que pensar muy cuidadosamente cuánta presión se pone en el proveedor.
Cómo evaluar los contratos
Los contratos comerciales pueden tener muchas formas. ¿Cuáles son las alternativas que aplican a los proyectos de desarrollo ágil? En cualquier contrato hay que mirar:
- ¿Cómo está estructurado el contrato? ¿Cuáles son las reglas básicas para el alcance de las entregas y la factura por ingresos?
- ¿Cómo se reparte los Riegos y las Recompensas entre el cliente y el proveedor?
- ¿Cómo se gestionan los cambios a los requerimientos?
- ¿Qué modelo de relación con el cliente fomenta: competitividad (ganar-perder), cooperación (ganar-ganar), indiferencia (no me importa si perdés) o dependencia (si sale bien yo gano, sino vos perdés)?
Si no fuimos nosotros quienes redactamos el contrato debemos buscar trampas - la negociación puede ser un juego competitivo. La pregunta es, ¿qué hacer si encontramos una trampa? ¿Intentamos exponerla y quitarla, o la aceptamos y seguimos adelante? Esto es una "decisión de negocios".
¿Qué información debe incluirse en un contrato?
Mientras exista más confianza entre el cliente y el proveedor, menos se necesita escribir en el contrato. En mi experiencia, hay un par de puntos que siempre deberían aparecer en todo contrato:
- Objetivos del proyecto y de la cooperación entre las organizaciones.
- Un resumen de la estructura del proyecto - procesos de Scrum, roles clave y cualquier diferencia con Scrum que aplique.
- Personal clave - quién es responsable a nivel operacional y jerárquico, y que se necesita de estas personas.
- Pagos y facturación, incluyendo las cláusulas de bonus y penalidades.
- Terminación normal y temprana del contrato.
- "Detalles legales". Dependiendo de las leyes locales y costumbres legales, es posible que tenga que limitarse la responsabilidad civil, especificar la ganancia, o incluir otros textos que se necesiten legalmente. Aquí es necesario conocer las prácticas legales del país donde se firma el contrato. Un contrato de ejemplo siempre ayuda.
¿Es necesario incluir el alcance del proyecto en un contrato? Aunque a menudo está presente (al menos en los contratos con el gobierno suele ser un requisito legal), fijar el alcance en el contrato también lo hace inflexible. Si fuera posible, es mejor especificar cómo se va a gestionar el alcance (por ejemplo, con un backlog de producto, contratos por sprint), y dejar los detalles operacionales fuera, para que los gestione el equipo del proyecto.
Los puntos 2, 3, 4 y 5 determinan las reglas de juego para el proyecto. Si son las correctas, vamos a tener una base sólida para un buen proyecto. Pero, ¿cuáles son las mejores reglas? Hay por lo menos media docena de estilos de contrato diferentes, desde Tiempo y Materiales hasta Precio Fijo, Alcance Fijo.
En el próximo artículo vamos a ver las diferentes formas de contratos y qué tan compatibles son con Scrum y los proyectos ágiles.