Cualquiera que haya contratado servicios de programación sabe que muchas veces los plazos de entrega no se cumplen.

La causa casi siempre es compartida. Puede que las partes no hayan definido bien los requerimientos y funcionalidades, o bien surgen necesidades no previstas, el Cliente puede cambiar de opinión en lo que quiere, el desarrollador no haber ajustado sus previsiones…

El modelo tradicional de Desarrollo de software es lineal, en el que las distintas fases se suceden de forma concatenada, marcándose una serie de hitos en un diagrama de Gantt.

El cliente suele preferir este sistema porque hay un mayor control de los costes y puede medir mejor las posibles desviaciones en los plazos y los entregables.

A fin de minimizar los riesgos de cara al cliente, lo habitual es sujetar los pagos al cumplimiento de dichos hitos (dejando el grueso para la entrega), incluir controles intermedios que le proporcionen información suficiente sobre lo que se está haciendo en todo momento, y fijar penalizaciones económicas en caso de retraso.

Trasladar lo anterior al Contrato es, en principio, más sencillo, y permite ver más fácilmente que la realización del programa es una obligación de resultado (contrato de obra). No crean que esto está tan claro, pues la mayoría de los contratos de desarrollo informático se suelen identificar como de prestación de servicios (otra cosa es que lo sean). Pero sobre esto, que es interesante y tiene mucha trascendencia, hablaré otro día.

El sistema es perfecto si los requerimientos y el análisis funcional se han hecho correctamente y no se plantean nuevas necesidades, ideas u otras circunstancias que aconsejen una modificación o ampliación del desarrollo. Si esto ocurre, las partes deben sentarse a negociar nuevos plazos y, en función de la causa, una revisión en el precio inicial, y si ocurre tarde, es posible que haya que rehacer parte del trabajo.

Lo anterior es el mayor problema que tiene el modelo tradicional, ya que supone alterar el objeto del contrato. En la práctica es una situación incómoda para ambas partes y surgen fricciones. El cliente tiende a minimizar la importancia de esos cambios y el impacto que puede tener en el cumplimiento de los plazos y en el precio; y el desarrollador suele entender que el problema es que el cliente no tenía claro lo que quería, o bien simplemente que pretende hacerle trabajar más manteniendo el coste. En general, es un problema de falta de comunicación y de planificación previa que, como decía, no siempre es imputable sólo a una de las partes.

Para evitar la rigidez del modelo lineal surgieron los modelos evolutivos e interativos (el más conocido quizá sea Scrum) de desarrollo ágil de software por medio de ciclos cortos. La característica principal de estos sistemas es que se asume que las necesidades y los objetivos del proyecto pueden ir cambiando. En vez de trabajar por fases estancas y definidas que, tras una planificación cerrada, llevarán a un producto terminado y que entonces se entregará al cliente, el desarrollo aquí está orientado a la consecución de resultados puntuales según una lista de prioridades, que se testean, revisan y mejoran continuamente junto con el cliente.

En los modelos iterativos el cliente define objetivos generales que quiere en el producto (funcionalidades) y establece prioridades, que se abordan por orden de importancia y en distintos ciclos de programación que suelen durar de 15 a 60 días. Finalizado el ciclo que corresponda, se revisa con el cliente y si se da por cumplida se ejecuta el siguiente. Por tanto, el cliente puede ir cambiando e introduciendo nuevas funcionalidades durante el desarrollo del proyecto, cosa que siguiendo un método lineal es un problema.

Esa metodología de trabajo implica también riesgos y posibles problemas, que desde un punto de vista legal debemos prever en el contrato, en el que además de lo habitual se contemplará:

1. La descripción de la metodología de trabajo. El cliente debe ser consciente de cómo se va a trabajar y aceptarlo. La lista de funcionalidades priorizada (“product backlog” en Scrum) es un documento vivo, pero forma parte inseparable del contrato, que deberá indicar su contenido mínimo, cómo se concretan las tareas y controlan las desviaciones.
2. Mayor información e implicación por parte del cliente. Debe señalarse un interlocutor por cada una de las partes y establecerse que se realizarán reuniones conjuntas previas y posteriores a cada iteración, de cuyo resultado se dejará constancia por escrito. El cliente ya no sólo debe estar informado, sino que vive de cerca el desarrollo, por lo que se le debe garantizar acceso al software de gestión del proyecto o, al menos, poder solicitar y obtener datos concretos sobre el estado del mismo de forma inmediata.
3. Control sobre el equipo de desarrollo. Trabajar con modelos ágiles requiere experiencia y conocimientos específicos, pues se aparta de lo habitual. Debe indicarse en el contrato la composición del equipo de trabajo, garantizarse el mantenimiento de los perfiles acordados, impedirse la cesión de la posición del desarrollador y solicitar autorización del cliente para subcontrataciones. En realidad esto debería hacerse siempre, independientemente de la metodología, pero aquí entiendo el riesgo es mayor.
4. Ajustar el precio en función de las funcionalidades y los pagos a las iteraciones. El precio total del proyecto será variable en la medida en que las funcionalidades también lo sean. En estos casos, o bien el precio se fija en función del tiempo de trabajo en pagos periódicos, a ser posible al final de cada iteración, o bien se pacta un coste por unidad de iteración. Probablemente este punto es el que genera más recelos al cliente, pues el coste total del proyecto se puede disparar. Si no se quiere asumir esto y se quiere evitar la incertidumbre en cuanto al precio, lo mejor es usar un modelo de desarrollo en cascada.
5. Validación e integración. La ejecución correcta de una iteración implica su aceptación, sin que se requiera una validación explícita. Tampoco habrá una entrega final sino que los cambios se van implementando conforme se finalizan, de modo que el cliente siempre tiene una versión del programa usable, a la que se le añadirán mejoras a lo largo del tiempo. En este punto, el riesgo del cliente se reduce enormemente frente al modelo tradicional, en el que debe hacer pagos anticipados y hasta el final no sabe si el programa funciona o no.
6. Resolución anticipada flexible. Las desviaciones en la consecución de los objetivos y plazos que tradicionalmente generan penalizaciones (aunque hay que prever su posible recuperación) no tienen mucho sentido en este modelo, siendo preferible facultar al cliente a resolver el contrato en todo momento (tras una iteración), de forma unilateral sin penalización si no está conforme con el resultado. Si se utilizan bien estas técnicas, la finalización anticipada del contrato no tiene un impacto muy negativo, pues se dispondrá de una versión del programa útil y su posible continuación por un tercero debería ser más sencilla.
7. Cesión de derechos a partir de la primera iteración. No se puede sujetar la cesión de derechos de propiedad intelectual en favor del cliente (con los límites que sea, también hablaré otro día de esto) a una entrega final porque no existe. Por tanto, la cesión se aplica sobre los sucesivos cambios sobre el programa y debe preverse sea efectiva desde el primer día.

The post Contratos de desarrollo de software conforme a metodologías ágiles appeared first on Javier Prenafeta - Abogado - Tecnologías de la Información.