archivo

Archivo de la etiqueta: agenda

Aunque resulte paradójico, la agenda es una de las principales causantes de la pérdida de control del proyecto porque en el momento en que se rompen sus premisas: estabilidad de las especificaciones, del contexto y acierto en las predicciones de coste y plazos y no se trata esta situación de manera natural ajustando la misma a la nueva realidad, estaremos trabajando en una condiciones fundamentadas en unas hipótesis erróneas y de esa situación no se puede esperar nada bueno.

La crisis del software se asoció al no cumplimiento de las agendas porque efectivamente los proyectos no cumplían objetivos de costes, plazos, alcance y calidad y a partir de ahí se constituyó la gestión predictiva de proyectos generando con las experiencias pasadas y con el paso del tiempo todo un cuerpo de conocimiento.

Precisamente este problema es el que sufren los desarrollos que siguen el enfoque clásico pero perfectamente son extrapolables a enfoques pretendidamente ágiles si los mismos están condicionados por agendas rígidas (digo pretendidamente porque agenda rígida y agilidad son conceptos contrapuestos).

Como es lógico, se mejoraron los resultados del pasado porque hay que tener en cuenta que se pasó del caos a un cierto orden, pero seguían sin ser satisfactorios a lo que había que sumar el desgaste que tiene este tipo de gestión entre todas las partes implicadas en el proyecto.

El culto a la agenda no es la solución porque pretende estabilidad y predicción en un contexto de incertidumbre que es inherente al desarrollo de software. Por eso, el centro no debe ser el triángulo de hierro sino el valor del producto de manera que costes, plazos y alcances supongan referencias y no límites.

El tamaño y la incertidumbre importan. Para un proyecto donde se prevé el desarrollo de un nuevo sistema de información de medio o gran tamaño o un mantenimiento evolutivo importante del mismo resulta muy complicado acertar, es más, soy de la opinión de que si se acierta es por casualidad.

Un gran desarrollo tiene incertidumbre inherente porque es sabido que en la mayoría (aplastante) de los casos, los usuarios no saben realmente lo que quieren hasta que se va avanzando en la construcción del producto y esto sucede independientemente del enfoque de desarrollo que se le quiera dar. Si a eso le sumas otros factores como la inestabilidad de los procesos de la organización cliente, de la propia organización, el mercado, etc…, todo se hace mucho más complicado.

Por ese motivo es importante que todas las partes sean conscientes de lo complicado que resulta acertar en un contexto como ese. Desgraciadamente en muchos casos, los usuarios y los clientes no atienden a razones y dan lugar a una gestión orientada a la agenda (a intentar mantener un equilibrio en el triángulo de hierro) en la que se sufrirá mucho si la desviación entre lo estimado y la realidad es sensible y que fracasará seguro si se superan los umbrales del Death March Project.

¿Por qué es importante tener en cuenta que estimar en esas condiciones es una batalla perdida? Pues precisamente para considerar la estimación como una referencia pero no como una losa que llevar a la espalda durante todo el proyecto, es decir, no se debe malgastar el presupuesto pero se debería ser flexible en su gestión y tener la mente abierta a la necesidad de contar con más presupuesto en el caso de que sea necesario.

Las estimaciones irán mejorando conforme se vaya avanzando en el conocimiento del producto y el equipo de trabajo se vaya familiarizando con el entorno tecnológico y el negocio. También se reducirá el margen de error si las historias de usuario o funcionalidades a desarrollar no son de gran tamaño.

Aún así se seguirá fallando y será necesario gestionar esas desviaciones, sobre todo en lo que al cumplimiento de los compromisos de la iteración se refiere, ya que en este caso, al estar más acotada la estimación y ser mayor el conocimiento que existe, las desviaciones a nivel de esfuerzo serán poco significativas (lo suficiente para fastidiarte o ponerte muy difícil cumplir con los objetivos del sprint) pero con escaso impacto a nivel presupuestario,.

Lo importante realmente en la predisposición a modificar la agenda, ahí es donde está la clave de todo esto. Esa predisposición supone haber entendido la incertidumbre del desarrollo de software y la necesidad de adaptarse al cambio y a los nuevos contextos que surjan durante su ejecución.

Sin embargo, son muchos años aplicando la filosofía de la llave en mano, de la gestión de agendas, de ciclo de vida clásico, de pensar que un proyecto de desarrollo de software es solo proceso y que no tiene por qué verse afectado por su contexto. Respeto ese cuerpo de conocimiento ya que supuso el primer intento de crear un orden dentro del caos y tuvieron un cierto éxito en comparación con el estado del arte anterior en el que sencillamente los proyectos, por regla general, no se gestionaban.

Pero tampoco supusieron la solución definitiva, solo un primer avance, sin embargo muchas organizaciones, muchos profesionales de reconocido prestigio creyeron ver ahí la solución a la ejecución de los proyectos software. El tiempo vino a demostrar que no, como tal vez el tiempo venga a demostrar que los enfoques ágiles tampoco lo son, sino una siguiente aproximación a otro modelo que permita obtener mejores resultados.

En cualquier caso y sea cual sea el enfoque a aplicar, lo realmente importante es el valor del producto y considerar la agenda como algo inamovible es atentar precisamente contra ese principio.

Recomiendo la lectura, si no lo habéis hecho ya a esta serie de artículos que si bien están orientados a los enfoques iterativos incrementales tratan, en esencia, de este mismo problema:

La (difícil) convivencia entre el enfoque iterativo incremental y el cumplimiento de agendas: Parte I, Parte II y Parte III.

La gestión de una agenda con falta de flexibilidad en sus parámetros supone no la gestión del proyecto en sí, sino la gestión del desgaste en las relaciones entre los diversos participantes, las cuales se irán deteriorando conforme vaya avanzando el proyecto porque no se terminarán de llegar a acuerdos que sean satisfactorios para ambas partes. La gestión del desgaste tratará de buscar puntos de equilibrio en ese caos en el que se habrá convertido la situación, con el objetivo de intentar exprimir al máximo un fruto al que prácticamente no le queda jugo.

El segundo escenario suele ser el más habitual y es la base para el fracaso de muchos proyectos de desarrollo de software, independientemente del enfoque a utilizar, si bien los enfoques evolutivos ofrecen la posibilidad de desarrollar el software por incrementos y si el área usuaria se muestra flexible (y la agenda da alguna oportunidad) es posible conseguir una solución razonable con el presupuesto y plazos definidos.

¿Qué agenda se puede gestionar si las condiciones iniciales son imaginarias? Solo es posible hacer algo en el caso de que el cliente entienda esta situación y no se cierre en banda al llave en mano. Si lo hace perderá el proveedor, pero también el cliente, porque pocos proyectos alcanzan un éxito real en esas condiciones.

También podría ser, porque también pasa, que las condiciones iniciales estén muy por encima de lo que requiera el proyecto, este escenario es más favorable que el anterior (por no decir que un chollo para el proveedor si te toca trabajar en estas condiciones), pero no arregla el problema de fondo, tal vez el proyecto sea muy rentable y el cliente quede satisfecho, pero el desarrollo de software es algo lo suficientemente serio como para esperar a ver si la moneda cae cara o cruz.

Recuerdo de artículos míos recomendando que el presupuesto fuera holgado, teniendo en cuenta esta situación de incertidumbre inicial, sin embargo, la solución no pasa por ahí, sino que pasa por la definición de presupuestos objetivos y por la predisposición a modificarlos si las circunstancias del proyecto lo aconsejan.

Cuando hablo de presupuesto objetivo lo hago desde la perspectiva de que se base al menos en una visión sólida del producto, para lo cual no es necesario hacer un análisis completo y en detalle del sistema de información, teniendo en cuenta que ese presupuesto objetivo obedece a una visión inicial (aunque sólida) del producto y que después habrá cambios que afectarán a las condiciones de la agenda.

Cuando el usuario quiera cambiar cosas deberá negociar y en esa negociación suelen quedar tocados tanto desarrolladores como usuarios, los primeros porque el esfuerzo a realizar tras el cambio será mayor, ya que el cumplimiento de la agenda recaerá sobre sus espaldas y los segundos porque no podrán llevar al producto todos los cambios que entienden que son necesarios (el valor del producto está fuertemente limitado por el valor teórico del producto en su especificación) y tendrán, probablemente, un producto de mayor deuda técnica (se descuidará la calidad del desarrollo como consecuencia de incrementar el ritmo de trabajo y del más que probable overtime que tengan dedicar) y con una peor ejecución funcional porque se habrá dedicado menos tiempo (si es que se ha dedicado alguno) a la detección y corrección de incidencias y deficiencias funcionales.

Pero, ¿dónde comienza la gestión de agenda?, ¿antes o después de tener el catálogo de requisitos?. La respuesta natural a la pregunta es que poca agenda puedes gestionar si no sabes lo que vas a hacer y en base a ellos se ha definido un presupuesto y unos plazos equilibrados.

Sin embargo, nos encontramos con dos escenarios:

1) Definición de agenda, una vez definido el alcance inicial del proyecto.

2) Definición de agenda, sin tener una versión inicial del catálogo de requisitos y por tanto, con una estimación del presupuesto y plazos un tanto irreal.

El primer escenario es en el que realmente tendría sentido la gestión de la agenda ya que se da por conocido el sistema que hay que desarrollar y para ello se ha dedicado un presupuesto y previsto unos plazos. Sin embargo, al final, el problema sigue siendo el mismo, porque cuándo surjan modificaciones en los requisitos tocará negociar para mantener la agenda y en caso de desacuerdo el perjudicado en primera instancia será el producto final, en segunda instancia todo el resto de implicados.

En el artículo de mañana analizaremos el segundo escenario que, por desgracia, suele ser el más habitual.

Es posible que esté transmitiendo en mis artículos que las agendas resultan negativas para los proyectos de desarrollo de software. Si lo hago es porque entiendo que es más importante incrementar el valor del producto.

No es incompatible aumentar ese valor con las restricciones de la agenda pero llegará un punto donde habrá que decantarse por un camino o por otro o lo que es lo mismo, cuando se pongan en conflicto los límites de la agenda con tareas que permitirían evolucionar el producto tocará elegir. Generalmente se intentará que todo quepa dentro de esos límites pero eso dará lugar a falsas expectativas y también, de forma más que probable, el incremento de valor no sea el esperado, al no poder dedicarse el esfuerzo necesario, se verá mermada la calidad del producto y se incumplirá la agenda.

En cualquier caso valoro la importancia que pueden tener las agendas en determinados proyectos y es que hay situaciones en las que no es posible disponer de más presupuesto del que se parte y tampoco es posible jugar con otros plazos.

Siendo objetivo, incluso partiendo de la base de que lo importante es el valor del producto, no podemos ser tan ilusos como para pensar que el presupuesto y los plazos son infinitos. Esto nos lleva a que el desarrollo se haga con intención, es decir, con la idea de que cada incremento proporcione un valor real al producto acorde al esfuerzo invertido, priorizando las funcionalidades principales del sistema, determinando el mínimo de las mismas que se requerirían para tener la aplicación funcionando en producción y enfocando el desarrollo a una estrategia iterativa incremental.

Conocer los límites puede resultar interesante, el problema está cuando los mismos son irreales con la naturaleza del trabajo a realizar y con las múltiples contingencias que se producen en el proceso de desarrollo y eso, desgraciadamente, lo que suele suceder.

El enfoque clásico, predictivo o en cascada del desarrollo de software tiene como objetivo final el cumplimiento de a la agenda: “Estas son las condiciones contratadas y esto es lo que hay: alcance, coste y plazos”.

La premisa es que las condiciones de partida no van a cambiar y que la información existente para realizar las estimaciones era suficiente para que la desviación en lo vértices el triángulo de hierro no afecte a la calidad final de los trabajos.

Puedo no estar de acuerdo con esta estrategia de desarrollo de software, teniendo en cuenta que mi apuesta es por los enfoques iterativos incrementales siguiendo prácticas ágiles, pero no por ello es una estrategia descartable ya que puede ser válida o la solución más óptima en determinados tipos de contextos.

Además, a priori, suena bien eso de cumplir la agenda, porque de ello se desprende tranquilidad y predecibilidad (sé lo que me gasto, sé lo que voy a obtener y cuándo) y es cierto, en teoría parece que no presente grietas.

Pero solo en teoría, el castillo de naipes se desmorona en el momento en que las condiciones de partida cambian (es posible que incluso se desmorone antes, si la estimación ha sido deficiente) y eso es algo que se producirá con una probabilidad muy alta, causas puede haber muchas, como por ejemplo que cambie el proceso que se quiere informatizar, que la implicación de una de las partes sea menor que la esperada, que la complejidad sea superior a la prevista, etc… pero lo más frecuente es que el propio usuario se de cuenta en el proceso de desarrollo de ciertas mejoras o cambios que permitan dar al producto un mayor valor.

¿Dónde comienza el antipatrón? Cuando se pasa de velar por el cumplimiento de la agenda a una situación de culto por la agenda, de manera que no se trata de buscar una solución mediante la flexibilización de alguna de las variables: coste, plazos, alcance y calidad, sino que se pretende conseguir la cuadratura del círculo de manera que se asuman los cambios sin variar las condiciones de partida.

Y esto no suele traer buenos resultados, para empezar se producirá un desgaste en las relaciones entre los diferentes equipos implicados que hará todavía más complicada la consecución de los objetivos, dará lugar a un sobreesfuerzo por parte de muchas personas con el objeto de compensar esa desviación lo que terminará pasando factura en la calidad y en la productividad y por último el producto final será el reflejo de todos estos problemas y situaciones.