archivo

Archivo de la etiqueta: contrato ágil

Hablar de un proyecto de desarrollo de software es hablar de incertidumbre. Cuanto más grande y complejo sea el producto a desarrollar, más tiempo se requerirá para tener una versión que se pueda considerar definitiva del producto, independientemente de que si se sigue un enfoque iterativo incremental se puedan tener versiones operativas (aunque no completas) en producción y utilizándose en un contexto real.

La incertidumbre existe en todos los proyectos pero a priori no es la misma en todos ellos ya que además del factor tiempo, existen otros muy significativos: el momento en que se decide iniciar el proyecto (no es lo mismo empezar en un entorno de procesos estable que en un entorno donde se sabe que existe una gran posibilidad de el mismo cambie, no es lo mismo empezar cuando los usuarios expertos pueden dedicar tiempo al proyecto que cuando se sabe que tienen que dedicar gran parte de su tiempo, cuando no todo, a realizar otras tareas, etc…), las características del cliente y de las personas designadas por el mismo, la adecuación del presupuesto a la naturaleza del proyecto, la complejidad del mismo, etc…

Es cierto que conforme se va avanzando en el proyecto se va acotando la incertidumbre pero esto realmente es significativo en desarrollos iterativos incrementales donde realmente en cada iteración, en cada feedback nos vamos acercando más y más a la solución.

Con un desarrollo en cascada con su orientación a entrega única, la incertidumbre no se reduce de manera tan sensible, ya que aunque determinados riesgos tecnológicos, de arquitectura, de cambios en los procesos se hayan superado, siempre quedará la incertidumbre de saber si en esa bola de cristal cuya visión ha quedado plasmada en el análisis de este tipo de desarrollos se ha acertado o no en el pronóstico.

En cualquier caso, sea cual sea el proyecto y sea cual sea la metodología, siempre puede pasar algo, incluso en el último momento que dé al traste con el trabajo: cambio absoluto del proceso que se estaba informatizando, desencuentros entre diferentes departamentos del cliente, etc… Y sucede mucho más de lo que se piensa.

Independientemente de que la incertidumbre siempre estará presente, es un hecho, como comentaba antes, que la misma disminuye conforme se avanza en el proyecto y esto es una ventaja muy grande para los enfoques iterativos e incrementales, ya que las estimaciones de esfuerzo tendrán cada vez una mayor precisión (ya que además, técnica y funcionalmente se tendrá más controlado el sistema) y de esto pueden sacar un mayor provecho tanto clientes como proveedores, siempre y cuando exista un marco contractual (contratación ágil) que sea flexible y coherente con esto.

Como he indicado en el primer artículo de la serie dedicada a la contratación ágil, uno de los principales obstáculos que nos encontramos para aplicar metodologías ágiles es que los clientes difícilmente se van a aventurar a aceptar proyectos sin un presupuesto y sin unos plazos concretos, lo que obliga a hacer uso de determinadas estrategias para que estos proyectos queden encuadrados dentro de un marco presupuestario y de plazos, sin que eso tenga afectar la metodología o sin que tenga que significar que tras un primer contrato vengan otros que terminen de completar el producto.

En otro artículo justifiqué como la aplicación de enfoques iterativos e incrementales encajaban dentro del concepto clásico de proyecto.

Pese a que la compatibilidad metodología ágil/proyectos existe, es más que evidente que la aplicación de los principios ágiles y su instrumentación en diversas metodologías están fundamentalmente orientados al producto ya que por encima de todo se encuentra conseguir que el mismo satisfaga las expectativas del cliente/usuario y para ello antepone principios basados en el producto que principios basados en la propia gestión de los proyectos (no los anula, simplemente da un mayor peso a unos frente a otros).

El desarrollo de un producto la mayoría de las veces está por encima de los límites fijados por el proyecto, salvo que el presupuesto fijado sea muy holgado, algo que en raras ocasiones ocurre. Precisamente querer reducir los límites del desarrollo del producto al proyecto, hace daño sobre todo al producto, pero también al proyecto.

Al producto porque la propia naturaleza del desarrollo de software con presupuestos y alcance inicial, lo que hará que para cuadrar en los números iniciales sea necesario reducir el alcance además de la calidad del producto, pudiéndose quedar fuera funcionalidades consideradas esenciales.

Al proyecto porque si el producto no cumple con las expectativas, no se habrá conseguido alcanzar el fin último por el que se ha ejecutado.

Es necesario que el cliente comprenda que es posible que el producto obtenido como consecuencia del proyecto necesite seguir siendo trabajado hasta conseguir los resultados esperados y esto hará necesario nuevas contrataciones.

Soy consciente de que resulta muy complicado transmitir esto al cliente, sobre todo si deseas que sea tu cliente. Siempre habrá competencia que dirá que ellos lo pueden hacer de una sola vez y por supuesto, con menos dinero.

Hacer un proyecto siguiendo un enfoque iterativo incremental ante un cliente con mentalidad abierta (no todos son iguales) y que entienda las clausulas del contrato (para ello lo firmó) puede ser suficiente pedagogía para darse cuenta de que una vez que el proyecto llegue a su fin, puede ser necesario otro para conseguir que el producto alcance sus expectativas.

Un modelo de relaciones cliente/proveedor en el que se rompe de manera sensible el equilibrio del todos ganan, afecta al producto de manera directa.

Si la contratación de un proyecto se saca por mucho menos de su valor o un proveedor realiza una oferta muy por debajo de lo que va a costar el desarrollo, habrá problemas.

En los dos casos, el proveedor no va a querer perder dinero (salvo que sea una apuesta para abrir las puertas de un determinado cliente con el objetivo de conseguir nuevos contratos que permitan recuperar la pérdida y obtener beneficios) y por tanto vendrán recortes en la calidad del software y en el alcance del proyecto.

El cliente podrá actuar para minimizar esos recortes pero su control del producto no será suficiente para evitarlos en su totalidad. A lo anterior se le sumará un desgaste importante por parte de las personas implicadas.

En estas circunstancias, el proveedor a veces conseguirá ligeros beneficios, otras se quedará prácticamente a la par y en el resto perderá dinero; mientras que el cliente tendrá un producto probablemente con deuda técnica deficiente, con funcionalidades no implementadas y con incidencias de funcionamiento.

Sin embargo, esta ruptura del equilibrio, no tiene por qué proceder de presupuestos desequilibrados, también se puede producir con presupuestos objetivos a la naturaleza de los trabajos a realizar e incluso con presupuestos holgados.

En estos casos suele estar motivado porque el cliente empiece a realizar cambios sobre el alcance inicial del proyecto o sobre el producto sin consensuar con el proveedor a cambio de qué otras tareas se llevan a cabo (en la mayoría de los casos a cambio de nada) o porque el proveedor quiera paliar la falta de productividad de su equipo y/o maximizar beneficios y reduzca la calidad de los trabajos e intente escamotear todas las funcionalidades que le sean posible.

Por tanto, tanto si se trata de contratación ágil como de otros tipos de contratos entre cliente y proveedor, todo empieza a desviarse cuando se rompe el equilibrio.

Si todo es así de evidente, ¿por qué se rompe el equilibrio? pues porque somos personas y como tales tenemos nuestras debilidades, como por ejemplo nuestra falta de capacidad a la hora de asumir nuestros propios errores. Otro factor es la ambición desmedida.

Y otro factor muy importante es el entorno tanto en el cliente como en el proveedor, que aprietan a las personas implicadas en el proyecto para favorecer sus intereses, por ejemplo, hay que intentar que el proveedor nos haga este módulo aunque no esté contratado o hay que intentar incrementar el margen de beneficio del proyecto un 15%.

Otro enfoque que se puede aplicar es una variante del anterior y que podría suponer un modelo híbrido entre el modelo con presupuesto y plazos cerrados y el modelo con presupuestos y plazos abiertos (pago por iteración), para ello:

1) Se contrataría la realización del catálogo de objetivos y requisitos, pero centrándose en la obtención de aquellos que sean esenciales para obtener una versión mínima del sistema que sea operativa en producción, es decir, que sea utilizada por usuarios en circunstancias reales.

2) Se contrataría el desarrollo de esa versión y se aplicarían los criterios indicados en el artículo anterior sobre los aspectos que deben quedar fijados en el contrato.

Este desarrollo podría comprender más de una iteración.

3) Con la aplicación usándose en un contexto real el feedback cobra más relevancia. En este caso se podría abordar la contratación de incrementos del producto, ya sea mediante pago por iteración o con un enfoque más amplio, mediante un contrato de mantenimiento evolutivo que se podría articular de diferentes formas:

- Volver a aplicar la estrategia de contrato de catálogo de objetivos y requisitos + contrato de desarrollo.

- Directamente realizar la contratación del mantenimiento evolutivo y mediante órdenes de trabajo se encargarían las diferentes iteraciones a realizar sobre el producto.

La primera posibilidad que vamos a estudiar implica dejar muy claro a nivel contractual lo siguiente:

- Catálogo de objetivos y requisitos marco, debidamente priorizados por el cliente y con una valoración de esfuerzo realizada por el proveedor. Este catálogo de objetivos y requisitos, debe tener un nivel de detalle adecuado para poder ser evaluado de manera objetiva por el cliente y también para que pueda ser valorado por el proveedor.

Acertar con el nivel de detalle es importante, ya que no se pretende realizar un análisis en profundidad del sistema (de lo contrario estaríamos desarrollando en un híbrido entre la cascada y un enfoque iterativo incremental en la construcción), pero debe ser suficiente para que la valoración sea lo más acertada posible y para que no existan solapamientos entre requisitos o confusiones sobre su alcance real.

Es muy importante hacerle entender al cliente que resulta fundamental acertar con las prioridades, ya que permitirá obtener antes una versión del producto con sus aspectos más críticos ya implementados y tendrá margen de maniobra presupuestaria para poder hacer los ajustes que considere necesarios.

Lo anterior debe ser recordado al cliente durante todo el proceso de desarrollo.

Además se deberá presupuestar los costes de gestión por parte del proveedor al final de cada iteración: replanificación del proyecto en función de los cambios sobre el plan inicial o sobre el plan establecido hasta el momento, realización de un primer análisis y valoración de nuevos requisitos, revaloración de requisitos ya establecidos, etc…

Este catálogo de objetivos y requisitos, debe ser contratado aparte y antes de comenzar el proceso de desarrollo.

- Compromisos por parte del proveedor respecto a su participación en el proyecto: Esto podrá variar en función de la metodología utilizada, en algunos casos será suficiente su participación al principio de cada iteración (detallar los requisitos) y al final de la misma (evaluación de los resultados obtenidos y definición del alcance de la siguiente iteración), en otros casos requerirá que además de lo anterior, tengan participación dentro del propio equipo de desarrollo o tener un nivel de disponibilidad absoluto ante consultas o peticiones realizadas por los desarrolladores.

- Marco para el cambio del catálogo de objetivos y requisitos inicial y para la gestión de conflictos. Para reducir o evitar los conflictos es importante que quede claro y por escrito, cómo tratar las situaciones más comunes que se pueden producir en el proceso de desarrollo:

Cambio de prioridades. No tendría coste imputable al cliente.

Corrección de defectos. No tendría coste imputable al cliente.

Cambio de un requisito por otro nuevo, ampliación del alcance de un requisito ya existente y reajuste de un requisito ya implementado. Se tendría que evaluar el coste del cambio e intercambiarlo por requisitos todavía no implementados que tengan en suma un coste equivalente (sin pasarnos nunca del presupuesto restante para el proyecto).

Reducción del alcance de un requisito y eliminación de un requisito. Se generaría un “crédito” a favor del cliente que podría ser utilizado para los cambios indicados anteriormente.

Costes de gestión. Si los costes de gestión no superan el presupuesto establecido en cada iteración, pasarían a formar parte de ese “crédito” a favor del cliente. Si los superan y existe circunstancias motivadas para ello (cambios de enfoque en el proyecto, etc…) tendrá que compensarse el coste por créditos existentes o por requisitos.

Cumplimiento de plazos y de la calidad del producto. Siempre y cuando no existan circunstancias externas al proveedor, se debe garantizar por parte de éste un acuerdo de nivel de servicio que podría tener clausulas de penalización y también clausulas de excelencia.

En las relaciones cliente/proveedor, uno de los aspectos que más complicado resulta a la hora de enfocar un proyecto siguiendo un enfoque iterativo incremental lo tenemos en el marco contractual.

Teniendo en cuenta la incertidumbre que existe en el proceso de desarrollo de software y que el objetivo final debería ser cumplir las expectativas de los usuarios a los que va dirigida la aplicación, la situación ideal sería ir facturando por iteración hasta conseguir la versión final del producto.

Es decir, a priori, no tendríamos ni límite presupuestario ni límite de plazos. Muy pocos clientes aceptarían un marco de trabajo como ese, entre otras cosas porque ellos sí que se tienen que ceñir a un presupuesto y en la mayoría de las ocasiones (con mayor o menos flexibilidad) a unos plazos.

Por tanto, va a resultar necesario adaptar los trabajos a un marco limitado en presupuesto y también en plazos, pero resulta absolutamente necesario que el cliente sea consciente de qué es lo que se va ejecutar con ese presupuesto y que el proceso de desarrollo de software es adaptativo, evolutivo y bajo incertidumbre o lo que es lo mismo, que el planteamiento inicial que se haga puede variar (de hecho variará).

Se pueden aplicar diferentes fórmulas para realizar una contrato ágil, en próximos artículos veremos algunas posibilidades.

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 3.225 seguidores