El desafío contractual de las metodologías ágiles – 2 de 3

En nuestro artículo anterior expusimos brevemente qué son las metodologías ágiles para el desarrollo de software y por qué han resultado más convenientes y son preferidas por los desarrolladores actualmente. Todos estos aspectos los estudiamos en conjunto con nuestro cliente Inria Chile, fundación dedicada a la investigación, desarrollo y transferencia de tecnologías en el área de las ciencias y tecnologías de la información y comunicación, con el objetivo de esquematizar un contrato de desarrollo de software que abordara las particularidades de las metodologías ágiles.

En este artículo abordaremos las dificultades que enfrentamos al elaborar un contrato que recogiera estos principios de agilidad y expondremos algunos de nuestros hallazgos tras este ejercicio.

Como redactar un contrato para las metodologías ágiles

Como se puede prever, un contrato de desarrollo “tradicional” –entendiendo por tal uno que regula hitos, objetivos, tareas y plazos– probablemente no resulte útil ni conveniente para regular el desarrollo de software bajo metodologías ágiles, que exigen poder modificar el proyecto muchas veces durante su transcurso.

La primera deficiencia que reporta la estructura tradicional de un contrato de desarrollo es que los hitos, objetivos y plazos pactados inicialmente van quedando obsoletos al poco tiempo bajo las metodologías ágiles, pues de acuerdo con ellas, tanto el cliente como el desarrollador van descubriendo la necesidad de hacerle ajustes o derechamente reemplazarlos por otros.

La obsolescencia de los términos contractuales pone a las partes frente a un dilema: o se mantienen apegadas al contrato, y continúan desarrollando un proyecto que ya saben que está mal enfocado o que derechamente ya no sirve; o acuerdan una modificación al contrato, ya sea a través del procedimiento de control de cambios o de una modificación contractual propiamente tal; o derechamente deciden alejarse de las disposiciones contractuales, con el creciente riesgo de responsabilidad contractual que ello conlleva para cada una.

Nos podemos dar cuenta, entonces, de que hacer un contrato que sirva para las metodologías ágiles significa equilibrar agilidad y flexibilidad, por una parte, con certeza jurídica por la otra, pero ¿cómo equilibrar estos dos conceptos tan distintos?

Alternativa 1: Modificación del contrato

Una primera alternativa –quizás la más obvia– sea incluir una cláusula que permita a las partes modificar el proyecto completo si es necesario. Sin embargo, no es difícil darse cuenta de que esta alternativa en realidad no representa ninguna solución. Las partes siempre tienen la facultad de modificar el contrato, aunque éste no lo diga. Por lo tanto, incluir una cláusula de esta naturaleza no es realmente un aporte, ni representa innovación alguna.

Pero, además, toda modificación de contrato depende, lógicamente, de que ambas partes estén de acuerdo en modificarlo; y creemos que hay muy buenas razones para pensar que ese acuerdo no siempre se alcanzará.

Para entender este punto pensemos, por ejemplo, en un proyecto de desarrollo tradicional, regulado por un contrato de desarrollo tradicional, que dure 10 meses. Imaginemos que en el cuarto mes, el cliente descubre –gracias a los avances realizados– que el proyecto completo está muy mal enfocado, y se debate entre continuar con el proyecto, o pedir las modificaciones necesarias para reencauzarlo a sus necesidades. Las opciones que tendrá en un contrato tradicional son:

  • terminar inmediatamente el contrato, de común acuerdo con el desarrollador, alternativa que se ve poco viable, pues el desarrollador no tiene incentivos para aceptar la propuesta del cliente y renunciar a los seis meses de trabajo y pago restantes que le garantiza su contrato vigente; o
  • gatillar la cláusula de control de cambios del contrato –si la hay– lo que implica detener el proyecto para negociar si los cambios solicitados están o no dentro del ámbito inicial, y de no estarlo, negociar su objeto y precio, y cómo impacta este cambio en la planificación final; o
  • modificar un contrato sin cláusulas de control de cambios, lo que conlleva los mismos inconvenientes anteriores, pero sin un protocolo y tiempos preestablecidos para ello.

Alternativa 2: Flexibilidad total y radical del contrato

En el otro extremo, una solución podría ser pactar contractualmente una flexibilidad total y radical en la determinación del objeto del contrato, los plazos y precio asociado; y facultar a los representantes técnicos de cada parte para que modifiquen el proyecto a su discreción, cuando lo estimen necesario. Un contrato bajo este esquema podría, incluso, no tener requerimientos técnicos de ningún tipo, de modo que sean los propios representantes técnicos de cada parte quienes los vayan descubriendo con el correr del proyecto.

Sin embargo, tampoco es difícil darse cuenta de que esta alternativa no es una buena solución. Un contrato de esta naturaleza genera incertidumbre, pues no define nada, lo que atenta contra uno de los propósitos esenciales de todo contrato: Generar algún nivel de certeza jurídica.

Tampoco soluciona el problema de los acuerdos que tenía la alternativa anterior, sino que solo lo traspasa a los representantes técnicos, quienes también podrían entramparse en discusiones sin salida respecto al rumbo del proyecto, por tener opiniones divergentes. Finalmente, nos daremos cuenta de que un contrato como éste se asemeja mucho a trabajar sin un contrato –al menos en lo que respecta a las características del proyecto y su metodología de avance– lo que nos demuestra que esta alternativa no cumple su propósito, y que el contrato sigue siendo inútil.

Alternativa 3: Intercalar períodos de trabajo con períodos de reevaluación del proyecto

Es entonces que empieza a emerger una tercera alternativa, intermedia entre la rigidez y la flexibilidad total. La alternativa consiste en ir intercalando períodos de trabajos con períodos de reevaluación del proyecto, es decir, alternar momentos de avance en torno a objetivos fijos, con momentos de análisis y planificación de los siguientes tramos de avance.

La idea sería fragmentar el proyecto, en varios tramos pequeños, e ir introduciendo entre tramo y tramo un período de reevaluación que permita a las partes rediseñar el proyecto de ser necesario, o ir especificando sus objetivos, en el evento de que estos no hubieran sido acordados desde el inicio.

Al dar con esta alternativa nos dimos cuenta de que, para ser útil, el contrato debía centrarse en regular la metodología de trabajo antes que los requerimientos técnicos, pues lo importante era lo primero y no lo segundo. Así fue que comenzamos a trabajar en regular contractualmente una metodología de ciclos de trabajo intercalados con etapas de revisión y planificación de los ciclos posteriores.

La mecánica de trabajo es bastante simple y parece lógica. Cada ciclo constituye un período de trabajo con objetivos bien definidos. Durante su transcurso, el desarrollador puede trabajar tranquilo en las tareas previamente acordadas y no tiene la obligación de irlas reevaluando. Tampoco es el minuto para que el cliente intervenga y corrija el avance, pues esto sólo ocurrirá una vez concluido el ciclo, en una etapa especialmente destinada para tal efecto. Las partes deben tomar registro de las conclusiones a las que lleguen durante esta etapa, pues ellas guiarán el trabajo del desarrollador durante el ciclo siguiente.

¿Y quiénes son las personas facultadas para adoptar estos acuerdos de modificación del proyecto? A nuestro juicio el contrato debería delegar esta potestad en los representantes técnicos de cada parte, pues la naturaleza de estos acuerdos exige que quienes los adopten sean personas con un buen entendimiento de los aspectos técnicos del proyecto. No obstante, también deben ser personas con habilidades de negociación y toma de decisiones; en la jerga de algunas metodologías ágiles (como la metodología Scrum, por ejemplo) al representante del cliente se le suele llamar “product owner” (dueño del producto), porque es quien, en último término, lleva las riendas del proyecto.

Como ya hemos anticipado, otro elemento fundamental es que los acuerdos de estas dos personas queden documentados en una bitácora o registro, que nosotros hemos denominado “Registro de Proyecto” en nuestra propuesta contractual, y que será el resguardo de ambas partes ante las decisiones adoptadas durante el avance del proyecto.

Hasta aquí la mecánica de trabajo parece bastante simple, intuitiva y lógica. Sin embargo, al poco andar nos dimos cuenta de que la metodología exigía aún más ajustes contractuales para poder funcionar, pues esta idea de los ciclos de trabajo, por sí sola, presenta algunos problemas importantes que el contrato debe atender.  En nuestro próximo artículo abordaremos los ajustes que introdujimos a la propuesta de contrato para que los principios de agilidad pudieran interactuar con la noción de certeza jurídica.