Desarrollo de software. El enfoque iterativo incremental y la conciencia del coste en el usuario

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.

Desarrollo de software. Antipatrón. Llave en mano

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

Desarrollo de software. No se puede ser ágil sin pensar en el producto y en el usuario

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.

Desarrollo de software. Agilidad y la evolución en la incertidumbre en el proyecto

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.

Desarrollo de software. Agilidad, orientación al producto y orientación al proyecto

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.

Desarrollo de software. Contratación ágil V

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%.

Desarrollo de software. Contratación ágil IV

¿Es suficiente realizar estos planteamientos al cliente para que acepte el desarrollo de sistema de información aplicando una metodología ágil, teniendo en cuenta que lo mismo está acostumbrado a contratar según un modelo clásico y monolítico y existen otros proveedores que pueden aceptar esas condiciones?.

Si el cliente no conoce los beneficios de la aplicación de los principios ágiles y su instrumentación mediante metodologías podrá ver el enfoque que se plantea alejado de la ortodoxia y ya sabemos todos lo complicado que resulta salir de la zona de seguridad aunque te vaya mal en ella.

Por tanto, si existe la oportunidad de hacer pedagogía con los clientes y mostrarles las ventajas de un enfoque ágil en el desarrollo de software, no solo te estarás ayudando a ti, sino también a toda la profesión y a todo el sector.

No obstante, el desarrollo iterativo incremental ofrece diversas cartas bajo la manga que pueden resultar muy atractivas para el cliente (y también para el proveedor):

- ¿Por qué no incluir en el contrato la posibilidad de que el cliente pueda dar por finalizado el proyecto antes de ejecutar todo el presupuesto?.

Esto se puede plantear de muy diversas formas: Darle la oportunidad a que lo pueda hacer en cualquier momento, a que lo pueda hacer con un mínimo de un % del presupuesto ejecutado, etc… En cualquier caso, el proveedor debería tener como compensación, además de lo ya ejecutado, un % del presupuesto restante (salvo que se haya pactado que un incumplimiento del acuerdo de nivel de servicio pueda suponer que esa compensación se elimine).

En este planteamiento todos ganan:

Si el cliente no está contento puede anular el proyecto, si el proveedor tiene una versión del producto que le parece suficiente no tiene por qué seguir invirtiendo en funcionalidades que lo mismo van a ser innecesarias.

El proveedor en el primer caso, no conseguirá los ingresos inicialmente estimados, pero a cambio se evita el camino a ninguna parte y lleno de desgaste al que iba el proyecto. En el segundo caso, el proveedor obtiene como premio además del beneficio por el trabajo ejecutado, el % extra de la compensación (sería como una prima por hacer las cosas bien).

- ¿Por qué no abordar un modelo relacionado con el esfuerzo necesario para realizar la tarea en el que todos ganen?.

En este caso al esfuerzo planificado se le aplica un buffer de esfuerzo, de manera que si el esfuerzo es t, nos quedemos con un rango válido de [t-buffer,t+buffer]. Si se consigue terminar la tarea con un tiempo entre [t-buffer,t] el beneficio se reparte entre cliente y proveedor y si la tarea termina con un tiempo entre [t,t+buffer], se reparten los gastos.

En el caso de que se superen los límites, habría que estudiar, antes de aplicar cualquier medida el motivo de tal desviación.

Desarrollo de software. Contratación ágil III

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.

Desarrollo de software. Contratación ágil II

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.

Desarrollo de software. Contratación ágil I

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.