archivo

Archivo de la etiqueta: contratación ágil

Los presupuestos fijos en los proyectos sobre una base de funcionalidades que hay que desarrollar (y que son o pueden ser innegociables) dan lugar a fuertes desviaciones en las previsiones iniciales que se pueden ver reducidas o acentuadas en función del conocimiento del negocio, tecnología y de las personas (componentes de los stakeholders) que van a participar en el proyecto y de la materialización o no de los riesgos previstos e imprevistos.

Cuanto mayor sea la incertidumbre más probabilidad hay de que las estimaciones sean erróneas. Por tanto, cuanto más cerca estemos del inicio del proyecto, más probabilidad de error habrá.

Mike Cohn lo cuantifica de la siguiente manera (traducción libre): “Durante la fase de estimación de la viabilidad de un proyecto la estimación realizada se sitúa entre el 60% y el 160%”.

Sobre esa afirmación se podría pensar que todos los proyectos están abocados al desastre. Tal vez quien piense eso no anda muy mal descaminado, sobre todo si el proyecto se realiza en un contexto de inflexibilidad en el que las distintas partes no se centran en el problema: que es desarrollar un producto software de la mayor calidad posible teniendo en cuenta los recursos disponibles.

¿Qué es ese contexto de inflexibilidad? Este es el presupuesto y esto es lo que hay que hacer, no hay posibilidad de negociación ni voluntad de analizar las causas que han dado lugar a esa situación.

Es importante que tengamos en cuenta lo que nos dice el Manifiesto Ágil al respecto: “Se valora la colaboración con el cliente, por encima de la negociación contractual”, a lo que habría que añadir también que “Se valora la colaboración con el proveedor, por encima de la negociación contractual”.

Y es que las causas hay que analizarlas con el objeto de determinar cuál o cuáles han sido los orígenes de esta situación porque en base a eso hay que dialogar y negociar. Generalmente los problemas de ese diálogo o de esa negociación lo tenemos también como consecuencia de una situación de inflexibilidad y la negativa a reconocer errores por parte del cliente y del proveedor.

Dado que el desarrollo de software es evolutivo soy de la opinión de que el presupuesto en un proyecto debe evolucionar de la misma manera que lo hace el software teniendo siempre presente el cliente y el proveedor el coste de cada actuación. Sobre esta materia recomiendo leer la serie de artículos sobre Contratación ágil que escribí hace un tiempo.

Tenemos los extremos:

- En los contratos llave en mano el riesgo lo asume el proveedor: “Estas son los objetivos, las condiciones y el dinero… ¡suerte!”.

- En los contratos por horas el riesgo lo asume el cliente: La baja productividad y esas horas que se pierden en el limbo de las horas de los proyectos de desarrollo de software (que debe de ser, por cierto, muy grande, para dar cabida a tantas).

Ambos extremos, en frío, sin matices, deben ser evitados y sin embargo con muy pocos matices son los que se utilizan de manera mayoritaria y ambas partes: clientes y proveedores tratan de arrimar el ascua a su sardina, muchas veces sin tener en cuenta que lo que a priori parecen ventajas se puede convertir después en inconvenientes.

La llave en mano es demoledora cuando se falla en las estimaciones y ten seguro que será así, estadísticamente se suele ser demasiado optimista con las mismas y más optimista será si el cliente es el que se ha encargado de hacerlas. Y no es cuestión solo de pesimismo o de optimismo, la clave está en que no se dispone de información suficiente para poder hacer una estimación medianamente realista y el problema lo tenemos en que ese conocimiento se obtiene conforme vamos avanzando en el proyecto.

Cuando el error es sensible nos encontramos en una situación de Death March Project, en la que será necesario replantear el triángulo de hierro o el proyecto fracasará sin remedio y con gran desgaste entre las partes.

Y el problema no es solo fallar más o menos con las estimaciones sino también en la definición de los objetivos por un lado porque a lo largo del contrato pueden cambiar, pero sobre todo por la interpretación de cuál es el nivel de acabado que tienen que tener los mismos para darse por satisfechos: para el cliente pocas veces será suficiente para el proveedor será justo lo contrario.

Las bolsas de horas ofrecen una flexibilidad extrema pero soy de la opinión de que para optar por esta opción el cliente debe confiar muchísimo en el proveedor y más que en el proveedor en las personas que van a intervenir en el proyecto.

Incluso en las condiciones más favorables para aplicar esa estrategia es beneficioso para ambas partes la definición de objetivos como podría ser por ejemplo facturar por iteración.

Como veis es difícil encontrar una fórmula en la que se consiga el equilibrio pero tal vez sea más sencillo encontrar soluciones en las que el riesgo se comparta.

En la serie de artículos sobre Contratación Ágil podéis ver algunas posibles soluciones a aplicar, teniendo siempre en cuenta que independientemente de la fórmula utilizada, si las personas se quieren entender se entienden (y al contrario), pero dado que nadie puede garantizar a priori que quiénes toman las decisiones van a estar durante todo el proyecto (las personas vienen y van), es conveniente que exista un marco de referencia:

Contratación ágil I.
Contratación ágil II.
Contratación ágil III.
Contratación ágil IV.
Contratación ágil V.

Si el usuario no tiene en cuenta lo que cuesta cambiar de opinión, equivocarse y en general la adaptación de la solución disponible en cada iteración a una que se aproxime cada vez más a sus expectativas estamos entrando en el juego peligroso de la barra libre ficticia, ya que llegará un punto donde por parte del proveedor no se pueda asumir más gasto y generalmente se avisará al cliente demasiado tarde (siempre será demasiado tarde).

Cuando se llega a esa situación el resultado en la mayoría de los casos será desgaste por ambas partes y un producto final que no dejará contento a nadie.

¿Una posible estrategia? Que el cliente (tanto el responsable técnico como los responsables usuarios) tengan conocimiento y estén de acuerdo con el coste que tiene llevar a cabo las especificaciones realizadas en cada iteración (una por una) y que como se partirá de un presupuesto de partida fijo a cambio de qué se llevan a cabo esos ajustes (ver artículos relacionados con la contratación ágil).

No se trata de poner al cliente o al usuario bajo la presión de tener que acertar siempre, eso no sería ni realista ni ágil, sino de que entiendan que se tienen que tomar muy en serio su rol en el proyecto y que la evolución del producto no se lleva a cabo mediante prueba y error, sino con intención.

Los proyectos de desarrollo de software tipo “llave en mano” son una fuente continua de fracasos, salvo excepciones (que las hay), se salvarán aquellos proyectos en los que se haya acertado en su valoración, hayan tenido una cierta estabilidad en el desarrollo (sin cambios significativos en procesos, interlocutores, etc…) y en los que tanto cliente como proveedor hayan estado acertados y hayan colaborado en la consecución de un objetivo común que no es otro que desarrollar un sistema que satisfaga las expectativas de los usuarios.

Sin embargo, lo normal es que estos proyectos no vayan bien y terminen por dejar descontentos sobre todo al cliente, pero también dejarán descontentos a muchos proveedores, de los cuales algunos se sentirán así por no haber cumplido con las expectativas del cliente y otros porque el proyecto han tenido pérdidas (como he dicho en numerosas ocasiones, desgraciadamente un número significativo de proveedores les da igual el cliente y solo miran los números).

En este artículo no analizo quién es el principal culpable del fracaso (entre otras cosas porque eso es algo que habría que analizar caso a caso) sino en señalar como una de las principales causas el enfoque de proyecto llave en mano en el que se espera que a partir de una previsión inicial de coste, se haya acertado en la misma y que todo en el proyecto haya discurrido con normalidad para alcanzar los objetivos marcados.

Cuanto más grande sea el proyecto, más probabilidad existirá de que el coste estimado sea erróneo y que existan contingencias en el desarrollo que provoquen desviaciones.

Hay que tener en cuenta que un proyecto llave en mano el proveedor está vendido si el cliente así lo quiere, pero también lo está el responsable técnico del cliente ante sus usuarios. ¿Por qué está vendido? Porque si no se gestiona adecuadamente los costes de los cambios de especificaciones en el desarrollo, al final todo quedará en un montón de actas de reuniones, correos y conversaciones que no son más que papel mojado y palabras que no valen para nada.

¿Solución? Enfoque iterativo incremental con valoración y priorización de los diversos requisitos bajo un marco de actitud ágil.

El feedback y tener capacidad para dar respuesta rápida al mismo es esencial, como también lo es dividir el desarrollo del sistema en incrementos donde la capacidad de error en las previsiones se minimice. Por otro lado, se debe establecer un mecanismo en el que los usuarios sean conscientes del coste del cambio y hacerse responsables de ellos y en el que los proveedores se responsabilicen de su trabajo y se centren más en el producto y en el cliente que en salvar los números del proyecto.

Existen diferentes formas de implementar este tipo de solución, podéis tener más información en la serie de artículos que dediqué a la contratación ágil:

Contratación ágil I
Contratación ágil II
Contratación ágil III
Contratación ágil IV
Contratación ágil V

En el momento en que nuestra atención en el proyecto es mayor que la atención al producto y en el usuario, dejamos como secundario el objetivo para el que estamos trabajando que no es otro que conseguir satisfacer las expectativas del usuario a través de un producto de calidad.

La causa de la desviación de la atención o de las prioridades a veces será provocada por el cliente (no atender a los acuerdos por los que se rige el proyecto y romper por tanto la dinámica de trabajo: ver contratación ágil), por el proveedor (incumplimiento de compromisos, falta de productividad, incremento de las expectativas de beneficios, etc…) o por ambos.

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.

Seguir

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

Únete a otros 3.211 seguidores