archivo

Archivo de la etiqueta: alcance

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.

¿Quién expone más con esta estrategia?, ¿el cliente?, ¿el proveedor? De entrada podría pensarse que el cliente porque no cierra un alcance definido, solo lo esboza y puede darse el caso de que se acabe con el presupuesto y no se consigan los objetivos generales que se han marcado.

Es posible que esto suceda, como también es posible que suceda con una visión opuesta, la de la llave en mano, en donde se pretende mantener fijo el alcance, ya que en el momento en que las cuentas no cuadran para el proveedor y supera el umbral de las pérdidas admisibles, querrá empezar a querer recortar ese alcance y/o solicitar más dinero, todo eso en un contexto de desgaste en el que además, la productividad y calidad de los trabajos se verá afectada, impactando a su vez en los costes. Esto que cuento no es ciencia ficción, quiénes hayáis trabajado en este tipo de contratos sabéis de lo que estoy hablando.

La clave está en definir unas condiciones contractuales en las que ambas partes compartan el riesgo, pero para llegar a eso es importante que en el cliente se entienda que con la incertidumbre que es inherente a todo proyecto de desarrollo de software, cualquier estimación inicial terminará siendo papel mojado conforme vayan avanzando los trabajos y que lo realmente importante es ir trabajando de la mano del proveedor (y el proveedor de la mano del cliente) para ir incrementando el valor del producto en cada iteración, de manera coherente a la inversión que se está realizando.

El triángulo de hierro: alcance, coste y plazos, determina unas condiciones de partida para el proyecto basadas en la mayoría de los casos en hipótesis realizadas con un gran desconocimiento sobre el sistema que se va a realizar, estando además, condicionadas por el hecho de que el área usuaria va a tratar de que se abarque el mayor alcance, con el menor coste posible.

Después el proyecto evoluciona y nos iremos dando cuenta de cómo la estimación inicial ha fallado (y por mucho) y el alcance varía porque conforme el usuario vea materializada sus ideas, le surgirán otras nuevas, se dará cuenta de que determinadas funcionalidades ya implementadas son mejorables y que también se ha equivocado en otras, provocando que se tengan que modificar sensiblemente o reconstruirlas.

Y no solo eso, habrá riesgos que impacten y que supongan una resistencia al desarrollo, cambios de rumbo en el proyecto, etc… y todos ellos provocarán que sea necesario modificar alguno de los vertices del triángulo de hierro porque seguir creyendo en su foto inicial es engañarnos.

¿Cómo poder actuar contra esto? Trabajando sobre el alcance y gestionando las expectativas. Estas dos variables se tienen que modular a la realidad del proyecto y subordinarse al estado económico real en cada momento (costes) y a los plazos que se definan.

De esta forma podemos trabajar sobre unas condiciones de partida de tiempo y presupuesto y haciendo una estimación del alcance que se pretende.

El prototipado puede ir desde fórmulas muy simples como dibujos realizados a mano alzada a desarrollos que tienen una cierta lógica implementada. Son muy útiles ya que permiten trabajar sobre algo material y no sobre ideas de carácter abstracto. Nunca van a poder sustituir a la funcionalidad una vez implementada en toda su extensión pero sí que permiten desarrollar con más intención.

Este antipatrón surge cuando no se hace un uso adecuado del prototipo, no se interpreta o se comunica adecuadamente su función y utilidad, pudiendo abarcar diferentes áreas:

– El responsable funcional aprueba el prototipo pero no se ha llegado a un suficiente nivel de detalle en el comportamiento, esto puede provocar que una vez implementado no se alcancen (incluso nos hayamos quedado bastante lejos) las expectativas puestas en la funcionalidad. También puede pasar que se piense que el desarrollo es más simple o más complejo que lo que realmente es.

– En entornos de negociación cerrados, en los que solo existe el contrato como objeto de debate, si se cierran términos del mismo (alcance y coste) en base a un prototipo con muchos detalles por concretar, se corre el riesgo de que las estimaciones realizadas sean fallidas y el cliente se niegue a replantear el alcance del proyecto alegando que se conocía perfectamente el alcance ya que había un prototipo que respondía a todas las dudas.

– Los clientes también incurren en un riesgo importante si consideran un prototipo como la base fundamental para realizar una valoración del alcance, sin haber evaluado si el conocimiento que proporciona es suficiente como para hacerla reduciendo la probabilidad de que haya desviaciones sensibles.

En los dos casos anteriores, el problema lo tenemos por un lado en la falta de flexibilidad a la hora de abordar cambios en el alcance y/o de aportar más recursos económicos al proyecto (y esto ocurre trabajando con o sin prototipos) y por considerar los prototipos como una versión real pero de juguete del producto final, algo que no será así porque a lo largo del proceso de desarrollo los usuarios cambiarán de prioridades, descubrirán nuevas funcionalidades a implementar, etc…, es más, incluso en el caso de que el prototipo sea de una funcionalidad, la implementación real sacará a la luz problemas: de carácter tecnológico, de integración, funcional, etc…, muchos de los cuales son complicados de prever cuando se está trabajando con el prototipo.

Es decir, el prototipo es un facilitador para desarrollar con intención pero nadie (cliente y proveedor) debe tomarlo como la verdad absoluta y que en base a ellos se tomen decisiones inamovibles.

– Si se dedica mucho esfuerzo al prototipo es posible que se caiga en la tentación de convertirlo en el producto definitivo. Esto supone un riesgo importante porque lo más posible es que su desarrollo se haya realizado sin tener en cuenta aspectos relacionados con la calidad y mantenibilidad del software, lo que después puede dar lugar a importante costes de evolución del producto, falta de robustez, efectos colaterales en cada versión, etc…

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.

El triángulo de hierro delimita la calidad final del producto software siempre y cuando las variables que lo componen den la oportunidad de que por lo menos el proyecto tenga alguna oportunidad.

Los enfoques clásicos de desarrollo están orientados al cumplimiento de una agenda, lo que no quita que en los enfoques ágiles se tengan en cuenta también esos parámetros, la diferencia se encuentra principalmente en el grado de flexibilidad que se aplica a los mismos.

Una de las variables es el alcance. Conforme se va avanzando en el proceso de desarrollo, el usuario se empezará a dar cuenta de especificaciones que ha realizado y que son incorrectas o mejorables, así como de nuevas funcionalidades que entienden que serán necesarias. El usuario presionará para que se incorporen todas, incluso en aquellos casos en los que se tenga que “tirar” desarrollo ya realizado.

Si no se gestiona adecuadamente el alcance y en consecuencias, las expectativas, del usuario, el proyecto correrá un riesgo importante. Si se dice a todo que sí y no se ajusta la carga de trabajo a la capacidad que se puede asumir: tanto en tiempo como en presupuesto, el producto se resentirá (reducción de la calidad) y las relaciones entre las partes también (desgaste como consecuencia de condiciones impuestas sin negociación, como consecuencia de expectativas insatisfechas, como consecuencia de la presión, etc…).

De tanto tensar la cuerda termina por romperse lo que puede dar lugar a un proyecto que se quede a medias en el que funcionalidades importantes se han quedado fuera o sin rematar, motivado principalmente por el hecho de no haberse realizado una adecuada gestión de prioridades, ya que el cliente daba por hecho de que todo lo que estaba pidiendo iba a entrar.

Este es un antipatrón para clientes y proveedores. Ambos pierden, los primeros por no buscar un equilibrio entre lo que se quiere y lo que se puede y los segundos por no saber o querer gestionar estas situaciones.

¿Cuál es la conclusión final de todo esto?

1) Para mantener el nivel de calidad es necesario que cuando una variable cambie el resto se ajuste a esta circunstancia si se quiere mantener el nivel de calidad definido. Esto supondrá un ajuste de la agenda, algo que también trato en relación a la segunda consecuencia.

2) La necesidad de un equilibrio porque no se trata exclusivamente de que a lo largo del proceso de desarrollo estas variables varíen su valor sino de establecer de partida un equilibrio entre todas ellas para alcanzar los objetivos de calidad que se esperan.

Eso es muy complicado ya que se trata de hacer una predicción, la cual muy probablemente haremos con un desconocimiento importante del alcance final de los trabajos, ya sea porque el usuario o el cliente no tenga todavía claro lo que quiere (que será lo más probable) o porque todavía no terminamos de captar o entender con el suficiente detalle qué es lo que quieren.

¿Entonces?, ¿qué hacemos? Incluso en ese contexto tratar de hacer una estimación con la mayor calidad posible. Mi recomendación es que se haga un análisis preliminar para llegar a captar la visión del producto. Digo análisis preliminar, no análisis detallado. La duración y alcance del mismo dependerá de la naturaleza del sistema a desarrollar.

De esta manera podremos empezar con un triángulo de hierro que se ha intentado que sea equilibrado. Lo más probable es que nos hayamos equivocado, entre otras cosas porque es muy complicado acertar y porque entre nuestras herramientas de estimación no se encuentran las bolas de cristal. Sin embargo, lo más importante en todo caso es la intención, se ha definido esa agenda exprimiendo al máximo las posibilidades y conocimiento que tenemos en ese momento, de esa forma habremos tratado de minimizar esa desviación.

Después de esto podremos haber acertado más o menos (incluso haber errado sensiblemente) pero no lo hemos dejado a la improvisación, si eso sucede no habrá sido por dejadez, no habrá sido por intentar conseguir una situación de partida justa y apropiada para los trabajos que se tendrán que realizar.

Tras esto, la gestión de la agenda puede ser flexible o rígida.

Sobre esto no os voy a decir nada que no sepáis o hayáis experimentado vosotros: en el desarrollo de software pueden pasar muchas cosas que te revienten la agenda (o al fin y al cabo, ese triángulo de hierro), a lo que hay que sumar que los propios responsables funcionales van a aprendiendo sobre el producto que quieren a medida que se va desarrollando.

Si no es flexible, el principal afectado será el producto final y después tanto el cliente como el proveedor, tanto a nivel institucional (ambos perderán dinero ya sea directamente por el desarrollo o como consecuencia del mismo) como de las personas que han participado en el proyecto, que se habrán esforzado, en muchos casos muy por encima del salario que están percibiendo.