El tema de las contrataciones en proyectos de software, siempre ha sido polémico. De forma tradicional, en un contrato se acuerdan un grupo de requisitos del cliente, que deben ser desarrollados en un tiempo X y por un valor Y. Estas condiciones generalmente conllevan a largas negociaciones posteriores por alcance, cuando el cliente quiere añadir alguna funcionalidad, o a que no se cumplan los plazos, anexos al contrato especificando valores adicionales a los pactados por la incorporación de nuevos requisitos, malos entendidos sobre los requerimientos iniciales podríamos decir que la contratación puede convertirse en una vulnerabilidad para empresas desarrolladoras de software.
Si hablamos de una empresa que desea o ha adoptado un marco de trabajo ágil, este siempre será uno de los primeros puntos dentro de sus preocupaciones. ¿Cuánto voy a tardar? ¿Cuántos requisitos pactamos? ¿Con cuánto presupuesto contamos? ¿Cómo voy a añadir cambios que están fuera de lo pactado? Definitivamente, una organización que adopte ágil, deberá revisar y modificar sus procesos, en especial, los de contratación.
Todos conocemos el siguiente grafico en el cual se tiene un triangulo con tiempo, alcance y recursos por lado a esto hay que añadir la calidad como area del mismo, pues en todo proyecto se tiene que tener claro que maximo se puede fijar 2 de los 3 lados y este es uno de los principales puntos a considerar en la contratación de software.
En este punto existen varias opciones, pero todos los clientes querrán saber cuánto les va a costar su producto y cuándo lo van a tener. Es por ello que para un contrato “ágil” se va a necesitar conocer en profundidad los principios y funcionamiento de Scrum y tratar de encontrar un punto medio, que beneficie a ambas partes y permita efectivamente que el contrato responda a los principios ágiles. El manifiesto agile valora la colaboración con el cliente por encima del contrato, pero siempre será necesario establecer las reglas con el cliente, de forma que se aumenten las probabilidades de éxito.
Dos de las opciones que sugiero valorar son:
1. Contrato de sprint
Estructura: en realidad, no es un contrato comercial, sino simplemente un acuerdo entre el Product Owner y el equipo para un sprint.
Alcance: el equipo acuerda esforzarse al máximo para entregar el conjunto de características acordadas (alcance) con un estándar de calidad definido al finalizar el sprint. El Product Owner acuerda no cambiar las instrucciones antes de finalizar el sprint.
Riesgo: un proyecto de Scrum puede ser visto como una serie de miniproyectos con parámetros fijos, tiempo (duración del sprint), alcance (backlog del sprint), calidad ( definition of done), y gastos (tamaño del equipo × duración del sprint).
2. Money for nothing. Changes for free
Estructura: este contrato funciona con los proyectos de software ágiles porque casi no hay trabajo en progreso. Al final de cada sprint, la funcionalidad está acabada o no se empezó. El trabajo es del tipo time & materials con un objetivo de coste, a menudo con la intención de que el proyecto no use todo el presupuesto. Una vez se entrega cierta cantidad de funcionalidad, el cliente puede darse cuenta de que ya se ha entregado una cantidad suficiente de valor de negocio y que no se necesita más desarrollo, por lo que puede cancelar el proyecto. Hay un gasto de cancelación que es igual a la ganancia restante que faltaba.
Alcance: puede cambiar. Las características planificadas sin implementar se pueden reemplazar por otras historias del mismo tamaño. Las características adicionales cuestan más.
Riesgo: compartido. Ambas partes están interesadas en completar antes el proyecto. El cliente obtiene costes inferiores y el proveedor, un margen más amplio.
Referencias.
Bermejo, M. (s.f.) Contratos ágiles. FUOC. Fundación para la Universitat Oberta de Catalunya. Recuperado de: https://www.exabyteinformatica.com/uoc/Audiovisual/Produccion_multimedia/Produccion_multimedia_(Modulo_5).pdf
