Contratos Ágiles – Tercera parte

 En esta última entrega de la serie veremos contratos derivados del Time and Materials y cláusulas especiales para una ejecución ágil de proyectos, y las conclusiones finales del trabajo. 

Ganancia fija

Se establece un alcance fijo, y los cambios no son posibles. Se convienen también los costes del proveedor y una suma fija de ganancia. No importa la fecha de entrega, el cliente pagará al proveedor todos los costes incurridos más la ganancia fija.

La situación más conveniente para el proveedor es acabar antes, con lo que obtendrá su ganancia en menos tiempo. Esto beneficia igualmente al cliente, que al finalizar antes abonará menos costes. De esta manera, los riesgos son también compartidos.

Este contrato no es adecuado para Scrum por no permitir cambios.

Bonos y penalidades

En esta modalidad se establece un bono si el proveedor finaliza antes, y una penalización si hay retraso. Cualquier cambio puede afectar negativamente a la fecha de entrega, por lo que el alcance será fijo. 

Desarrollo por fases

Este tipo de contrato se suele pactar por trimestres, y se prorrogan de acuerdo al resultado obtenido. El alcance de cada fase es cerrado, pero resulta fácil posponer una funcionalidad para la fase siguiente si resulta conveniente. Tanto el proveedor como el cliente tienen interés en que las entregas se cumplan exitosamente para continuar con la fase siguiente. Es una buena combinación de Time and Materials  con Alcance Variable y Techo de Costes. En el contrato se especifica el objetivo de la entrega, los costes por hora o por día y el techo de coste. Todo el resto del acuerdo se determina en los Contratos de Sprint.

Time and materials con alcance fijo y techo de coste

Es un contrato de tiempo y materiales, en el cual el riesgo del cliente está limitado por una cláusula de techo costo. El alcance es fijo y predeterminado. El coste diario u horario está determinado. Si el proyecto finaliza antes de lo estimado, el cliente solo paga los costes hasta ese momento. Si el objetivo no se alcanza en fecha, o al llegar al techo presupuestario, el cliente no paga más del techo hasta finalizar. El proveedor buscará el punto de máximo beneficio en el techo de coste, y no tiene ningún incentivo para entregar antes.

Time and materials con alcance variable y techo de coste

Es en términos generales similar al anterior, con la salvedad que el alcance no está estipulado de antemano. La combinación de un presupuesto limitado y alcance variable enfoca al cliente y al proveedor en lograr el valor de negocio requerido dentro del presupuesto disponible. Este tipo de contrato es el que mejor funciona con Scrum. El cliente mantiene el control en cada Sprint y puede introducir cambios al finalizar cada iteración. El contrato finaliza al alcanzar el techo de coste o cuando el cliente considera que ha obtenido suficiente valor de negocio y no es redituable continuar invirtiendo en funcionalidades adicionales. El proveedor colabora con el cliente para generar cada Sprint un incremento valioso para el negocio y continuar el desarrollo hasta alcanzar el techo de coste. Una relación constructiva implica que, incluso si surgiesen problemas, las emociones y el enfoque serían correctas para poder alcanzar una solución de mutuo beneficio.

En esta modalidad, el cliente establece un costo y un plazo, y el proveedor entregará el resultado del esfuerzo

Conclusiones finales

La situación actual

En plena era de la transformación digital, muchas organizaciones aún presentan algunas de las siguientes características:

• Presupuesto por proyecto con alcance cerrado
• Equipos de desarrollo externos, de un mismo proveedor o multi vendor
• Contratos fixed price o time & materials 
• Sistema de selección de proveedores basados en la oferta económica por encima de la capacidad técnica
• Departamentos o silos conviviendo con equipos ágiles (scrum o kanban)
• Poca experiencia con marcos de trabajo ágiles
• Adaptación de Scrum o Kanban para conservar las estructuras jerárquicas de control (Scrum But)

Pensando en productos y no en proyectos

Las consideraciones anteriores están referidas siempre a proyectos. Si buscamos evolucionar estos conceptos a líneas de productos con sus correspondientes ciclos de vida, podemos intuir que estos contratos sólo están pensados a corto plazo. Una vez establecido el modelo de cooperación, es necesario establecer contratos marco para evitar la permanente redefinición de los acuerdos.

Un camino posible

Algunas consideraciones que podemos tener en cuenta a la hora de instrumentar un marco de contratos ágil podrían ser:

• Indagar en el mercado qué proveedores ofrecen células ágiles
• Formar a los Product Owner. Esto no implica solamente obtener la certificación, sino coaching y mentoring que generen una mentalidad o mindset ágil.
• Aprovechar pequeños evolutivos o micro desarrollos de menos de un mes para implantar un Sprint único (utilizarlo como una Prueba de Concepto para generar unas lecciones aprendidas y siguientes pasos).
• Aprovechar pequeños proyectos (2 o 3 meses de estimación) en modo time & materials para implantar un equipo Scrum y conocer su velocidad (3 a 5 Sprints)
• Una vez que tenemos un equipo Scrum conformado y con velocidad conocida, podemos asignarlo a un proyecto de mayor envergadura, en la modalidad Sprints o Time & materials con techo de coste y alcance variable.
• Cuando se ha madurado el nivel de agilismo, y con abundante información histórica, podemos establecer acuerdos marco con un precio por punto de historia y unas DoD y DoR probadas y consensuadas

Un contrato para cada necesidad

La matriz de Stacey nos propone diferentes formas de desarrollo según el grado de certeza en los requerimientos y el dominio de la tecnología implicada. No hay nada malo en un contrato de alcance fijo, sólo que no es lo adecuado cuando la dimensión y complejidad de un proyecto es determinante. Asimismo, sería absurdo utilizar Dinero por nada y cambios gratis en un microdesarrollo de 200 horas. No es la misma situación en un área de soporte de incidencias operando en Kanban que en un programa de 20 proyectos distribuidos alrededor del mundo. No podemos esperar que un contrato ágil nos solucione todos los problemas, cuando la implantación de Scrum es disfuncional o hemos comenzado a aplicarlo desde hace una semana.

La matriz de Stacey

Algunos factores a considerar a la hora de tomar la decisión son:

• Grado de certeza de los requerimientos
• Dominio de las tecnologías involucradas
• Tamaño del proyecto
• Grado de madurez y experiencia Agile/Scrum
• Soporte de un Agile Coach
• Confianza entre las partes
• Autosuficiencia del equipo de desarrollo (grado de dependencias fuera de su control)
• Criticidad del proyecto
• Flexibilidad de la fecha de lanzamiento
• Capacidad económica

Y no olvidéis el factor más importante: el sentido común.

Pincha en este enlace para ver la segunda parte

Este obra está bajo una licencia de Creative Commons Reconocimiento-NoComercial-SinObraDerivada 4.0 Internacional.