Propuesta de contrato para el desarrollo de software bajo metodologías ágiles – 3 de 3

En nuestro artículo anterior abordamos algunas de las primeras dificultades que enfrentamos junto a Inria Chile al intentar diseñar un contrato de desarrollo de software que recogiera principios agilidad, y cómo fue que finalmente llegamos a la idea de ir intercalando períodos de trabajos con períodos de reevaluación del proyecto como primer acercamiento para la elaboración del contrato.

Sin embargo, como anticipamos en aquel artículo, esta mecánica de trabajo por sí sola nos pareció insuficiente para lograr el objetivo de que los principios de agilidad pudieran interactuar con la noción de certeza jurídica, y vimos la necesidad de ir introduciendo algunos ajustes contractuales para que la regulación de la metodología pudiera funcionar adecuadamente.

En este artículo analizaremos los siete ajustes contractuales que, por el momento, hemos podido identificar:

  • Las etapas de análisis y planificación deben tener duración indefinida. Fijarles una duración determinada resulta finalmente contraproducente para las dos partes. Eso les haría adoptar acuerdos bajo la presión de que, si no se apuran, el proyecto continuará de acuerdo con las directrices previamente adoptadas, que bien podrían haber quedado obsoletas a la luz de los últimos avances. Esto no le conviene a nadie, pero en particular no le conviene al cliente, que debe tener la libertad y tranquilidad de corregir y reestructurar su proyecto con calma.
  • Los ciclos deben tener duraciones genéricas y no estar asociadas a fechas específicas. Este segundo ajuste es una consecuencia del primero, y consiste en que la duración de los ciclos se debe establecer usando plazos genéricos (por ejemplo “dos semanas”) y no usando fechas específicas (“hasta el 25 de agosto”). ¿Por qué? Pues porque si ya hemos resuelto que la etapa de revisión y planificación que hay entre ciclo y ciclo tenga una duración indefinida, pues entonces su prolongación iría acortando todos los plazos futuros que se hubieran fijado con fechas específicas. Si el propósito de esta etapa, como ya hemos dicho, es analizar y planificar con total libertad y tranquilidad, los plazos de los ciclos futuros deben suspenderse mientras dure esta etapa. Creemos que esto se logra con un ajuste muy sencillo, que es el uso plazos genéricos, que se inicien o “activen” sólo una vez que las partes hayan resuelto iniciarlo, por haber concluido la revisión del ciclo anterior y la planificación del ciclo siguiente. Mientras eso no ocurra, ningún plazo comienza a correr.
  • El proyecto entero debe ser modificable en cualquier etapa de análisis y planificación. El tercer ajuste consiste en resguardar que las etapas de análisis y planificación no se vean influenciadas por los acuerdos que anteriormente se hubieran adoptado respecto de ciclos futuro (sus objetivos o duración, por ejemplo). Como ya hemos señalado, la idea fundamental de las etapas de revisión y planificación es que las partes puedan rediseñar libremente el proyecto si es necesario y ello puede requerir disminuir o aumentar la cantidad de ciclos futuros, su duración y objetivos. Por ello, todas las planificaciones de ciclos futuros deben ser inherentemente provisionales; deben ser modificables hasta el último momento antes de su inicio.
  • Las partes deben poder terminar unilateralmente el contrato, sin expresión de causa. Este cuarto ajuste es una consecuencia de todos los ajustes anteriores. Si durante cada etapa de revisión y planificación las partes tienen total libertad para modificar el proyecto, sin que corra en su contra ningún plazo para ponerse de acuerdo, pues entonces resulta posible que nunca se pongan de acuerdo. Al menos es una posibilidad no menor.

    Las partes podrían discutir y discutir sin alcanzar un punto de encuentro, pues la metodología no contempla un mecanismo para suplir su falta de acuerdo, y tampoco es bueno que lo contemple, como ya hemos explicado. A nadie se le puede obligar a llegar a un acuerdo, si no, no es un verdadero acuerdo. Aquí, las partes han llegado a un punto muerto.

    Pero ¿tiene sentido mantener vivo un contrato que ha llegado a un punto muerto? Creemos que no y eso es lo que justifica nuestro cuarto ajuste. Las partes deben poder terminar unilateralmente el contrato, sin expresión de causa, durante cada etapa de revisión y planificación.

    Permitirle esto a las partes cumple dos funciones. Una es equiparar el poder negociador de cada una durante la etapa de revisión y planificación. Si ambas pueden “salir de la mesa de negociación”, es esperable que su discusión sea más libre y sincera. La segunda función es otorgarle a las partes una garantía, que les permita liberarse del contrato si la otra parte no está debidamente comprometida con la metodología.
  • Los precios deben pactarse por ciclo trabajado y no por el proyecto completo. Este ajuste es una consecuencia del cuarto, y es que el precio por los servicios debe pactarse por ciclo trabajado y no por todo el proyecto.

    Si el proyecto puede terminar en cualquier momento, debe idearse un mecanismo para que el precio no dependa de que el proyecto llegue a término. Creemos que eso se logra estableciendo que los pagos se hagan en función de cada ciclo terminado.

    Además, el precio de cada ciclo debe ser negociable y ajustable durante la etapa de revisión y planificación anterior a su inicio. Si lo son sus objetivos y duración, pues también lo debe ser su precio, para mantener la equidad de las negociaciones.
  • Regular qué ocurre con la terminación anticipada. El sexto ajuste consiste en regular qué ocurre si alguna de las partes ejerce su derecho a la terminación anticipada. Esto resulta conveniente para que las partes puedan terminar el contrato en buenos términos, pero también es una exigencia del propio espíritu de la metodología ágil, que siempre busca que el cliente pueda marcharse con algo que le resulte útil y que el esfuerzo invertido no se pierda.

    En nuestra propuesta contractual establecimos que la terminación anticipada dé lugar a un ciclo de cierre de proyecto –sin costo para el cliente– donde las partes negocien un último entregable. Eso sí, delimitamos en el contrato lo que el cliente puede exigir de ese entregable final. El desarrollador sólo está obligado a incorporar en ese entregable tareas y objetivos que hubieran formado parte de los ciclos efectivamente concluidos. No se le puede exigir incorporar tareas y objetivos nuevos. Ahora bien, si el desarrollador voluntariamente quiere incorporarlos, bien puede hacerlo, pero no se lo puede obligar a ello.
  • La planificación de un nuevo ciclo implica la aceptación del trabajo realizado en el ciclo anterior. Este último ajuste es esencial para que toda la metodología sea viable y consiste en establecer contractualmente que la planificación de un nuevo ciclo implique la aceptación del trabajo realizado en el ciclo anterior, con independencia de las observaciones que le haya formulado el cliente.

    Como ya hemos explicado, el principal propósito de las metodologías ágiles es darle al cliente la oportunidad de revisar y corregir periódicamente el trabajo del desarrollador, quien está constantemente abriéndole las puertas, una y otra vez, para que observe y corrija lo que hace el equipo de desarrollo. En este entendido, lo natural y esperable es que cada revisión deje observaciones e instrucciones de mejora al desarrollo logrado. Ese es el principal objetivo de la metodología.

    Por tanto, lo natural e inherente a la metodología será encontrarnos con un registro de proyecto lleno de observaciones, comentarios e instrucciones de mejora. Si las hay, es porque justamente la metodología está funcionando.

    Pero imaginemos qué pasaría si una vez terminado el contrato, el cliente tomara el registro de proyecto, con todas sus observaciones, comentarios e instrucciones de mejora y lo llevara a un tribunal, y lo usara como prueba de un incumplimiento contractual para exigir la restitución de todo lo que ha pagado durante el proyecto. Ese escenario sería, sin duda, un abuso de la metodología y un uso –de muy mala fe– de las herramientas que esta concede.

    Para resguardar que eso no ocurra, el contrato debe incorporar un mecanismo que haga que el avance signifique la validación de los ciclos terminados. Creemos que esto se logra estableciendo que toda planificación de un nuevo ciclo implique la aceptación del trabajo realizado en el ciclo anterior, con independencia de las observaciones que le haya formulado el cliente. Esto, bajo la lógica de que, si las partes han podido ponerse de acuerdo sobre un nuevo ciclo, es porque quieren seguir trabajando juntas. Más todavía si tenían la facultad de terminar unilateralmente el contrato. Por lo tanto, lo razonable es concluir que valoran lo avanzado, aún a pesar de las observaciones y correcciones que pudieran haber surgido durante cada etapa de revisión y planificación.

    Si el cliente llegara a rechazar completamente lo realizado en un ciclo y no quiere que opere la validación y aceptación, pues sencillamente no debe seguir embarcado en el proyecto y debe hacer uso de su facultad de terminación unilateral, que como ya hemos explicado, no lo deja a la deriva, sino que le da derecho a un último ciclo de cierre de proyecto, sin costo para él.

Estos son los ajustes que hemos podido identificar por el momento y quizás haya más que por ahora no podemos ver. Pero con los que ya tenemos, podemos sintetizar la metodología contractual de la siguiente manera. El proyecto se divide en ciclos de trabajo en los que el desarrollador debe trabajar para objetivos y tareas previamente acordados. Entre un ciclo y otro hay una etapa de duración indefinida en la que las partes revisan el trabajo del ciclo anterior y planifican el del ciclo siguiente, pudiendo modificar sus objetivos, tareas, duración, precio y entregables esperados; e incluso pudiendo eliminar ciclos futuros y terminar unilateralmente el contrato. Si aun teniendo esta última facultad las partes logran acuerdo sobre cómo seguir y planifican un nuevo ciclo, pues ella ha de implicar la validación y aceptación del trabajo realizado en el ciclo anterior, para resguardar la viabilidad de la metodología. Todos los acuerdos alcanzados deben ser documentados en una bitácora o registro de proyecto firmado por los representantes técnicos de ambas partes.

Cuando ya habíamos redactado el contrato, nos dimos cuenta con agrado y sorpresa de dos cosas: que podía funcionar perfectamente sin requerimientos técnicos iniciales –es decir como un proyecto en blanco– y no sólo eso, sino que también se puede emplear para otros proyectos distintos del desarrollo de software, pues el trabajo por ciclos y la mecánica de negociación periódica son universales.

Los contratos reflejan las esperanzas de las partes, pero en mucho mayor medida, también los miedos. Los proyectos exitosos finalmente no surgen de un contrato bien dibujado, sino de relaciones basadas en la colaboración, transparencia y confianza. El contrato ágil debe, por lo tanto, entregar la flexibilidad necesaria para que esos niveles de confianza puedan prosperar.

 

“Los contenidos y materiales de esta página web no constituyen asesoría legal. Esta página web sólo tiene fines informativos, es de carácter general y no pretende ser exacta ni completa. Está sujeta a actualizaciones y correcciones. Carey y Cía. Ltda. no es responsable del contenido de páginas web con enlaces o links hacia o desde nuestra página”

Modelo de contrato ágil Cláusula de agilidad