archivo

Archivo de la etiqueta: presupuesto

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.

Este antipatrón surge cuando se asigna un presupuesto para el desarrollo de un producto y no se tiene en cuenta que tras la construcción del mismo va a ser necesario continuar con su evolución ya sea ampliando funcionalidades o realizando modificaciones sobre las ya existentes.

Esto lo podemos encontrar tanto en enfoques clásicos como en los iterativos incrementales. Es muy frecuente sobre todo en los primeros, ya que suelen tener un enfoque de contrato cerrado: “esto es lo que hay que hacer y este es el dinero que te voy a pagar”, no obstante los segundos también se ven afectados en el momento en que se agota el presupuesto y se detecta que es necesario seguir trabajando sobre el sistema.

Pensar que se va a desarrollar el producto a la primera es una quimera tan grande como pensar que incluso consiguiéndolo no se van a dar circunstancias que hagan necesario realizar una mantenimiento.

Lo mismo piensas: “Bueno, si hace falta más dinero, se pone y ya está”. Eso no es tan fácil, ya que dependerá de la holgura que permita el presupuesto de la organización. En el caso de proyectos con la Administración resulta todavía más complejo porque los procesos de contratación requieren su tiempo y porque existe menos flexibilidad presupuestaria.

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.

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

En este artículo vamos a analizar el impacto que tiene la reducción de los plazos o la ampliación del alcance en el caso de que se quieran conservar los objetivos de calidad:

– Si se reducen los plazos solo se podrán salvar costes y alcance disminuyendo la calidad.

Aquí también podría entrar en juego la productividad pero con unos efectos similares a los indicados anteriormente.

No obstante, algunos podréis preguntarse, ¿necesariamente tiene que verse afectada la calidad?, ¿no basta solo con meter más personas en el proyecto?.

Meter personas puede funcionar si entran ya rodadas, es decir, conocen perfectamente la tecnología de desarrollo y la dinámica de trabajo del equipo, y aún así, requerirán un tiempo de adaptación hasta poder producir al 100%, además de tiempo de personas del equipo de desarrollo para situarles en el contexto funcional, de arquitectura e incluso técnico de los trabajos. Este tiempo de adaptación tanto por los nuevos como por los que ya formaban parte del equipo tiene que salir de algún lado y se traducirá en overtime y/o en una menor dedicación a determinadas actividades que resultan fundamentales en el desarrollo como es el testing.

Sin embargo no siempre se podrán incorporar al proyecto personas con el perfil indicado o no llegarán a tiempo o simplemente no merecerá la pena, esto dará lugar a que tenga que ser el equipo el que tenga que asumir ese nuevo contexto y aquí inevitablemente tendremos overtime que, además, será sostenido en el tiempo y eso terminará por agotar al equipo e influirá sobre la calidad de los resultados. No debemos olvidar que no somos máquinas, somos personas, y nos cansamos física y psicológicamente, cansancio que será más acusado porque al mayor número de horas habrá que sumar el desgaste que supone la presión.

Y el overtime no será suficiente, al final, con el objeto de ejecutar trabajo se será más descuidado en el proceso de pruebas del software, que además, de base tendrá un mayor número de deficiencias, a lo que habrá que sumar una más que probable deuda técnica adicional porque lo que importará será sacar trabajo por encima de la calidad final del código.

– Si se amplía el alcance solo se podrán salvar costes y alcance disminuyendo la calidad.

El análisis de esta situación es un compendio del indicado en las dos anteriores.

Se conoce como triángulo de hierro al espacio que generan tres variables fundamentales a tener en cuenta en el proceso de desarrollo de software: coste (presupuesto), plazos y alcance.

Ese espacio es el que ocupa la calidad del software que se desarrolla.

Esto es teoría, hay equipos que con menos espacio son capaces de desarrollar software de mayor calidad que otros que cuentan con un mayor margen.

Y no solo depende de los equipos, la colaboración o no del resto de implicados en el proyecto también condiciona mucho.

No obstante, pese a ser un aspecto teórico sí que sirve para analizar la implicación directa que tienen esas tres variables sobre el resultado final:

– Si se reduce el presupuesto solo se podrán salvar plazos y alcance disminuyendo la calidad.

Algunos podréis pensar, ¿y si se gana en productividad? Es cierto, puede ser una solución general o, al menos, un instrumento que permita que su impacto en la calidad no sea tan significativo. Pero, ¿se puede mejorar la productividad de manera sensible de la noche a la mañana?.

La mejora de la productividad como parte de un proceso de mejora continua siempre debe estar presente a nivel organizativo y a nivel de proyecto, si llevamos esta idea al triángulo de hierro va a permitir mejorar la situación del vértice de los costes, pero una reducción del presupuesto significativa no podrá contrarrestarse con una mejora de la productividad a corto plazo porque estas mejoras llevan su tiempo ya que no solo se trata de cambiar la forma de hacer determinadas cosas sino que también se trata de un asunto de mentalidad de las personas (y eso requiere tiempo de maduración).

En el próximo artículo veremos las implicaciones en el caso de que se reduzcan los plazos o se amplíe el alcance.

En el artículo de ayer exponía que los presupuestos abiertos ofrecen una mayor flexibilidad para abordar el desarrollo de un proyecto de desarrollo de software desde el punto de vista del valor del producto.

El cliente podría pensar, ¿y si considero que el valor del producto es suficiente y todavía queda presupuesto por consumir?.

Cuando hablo de presupuestos abiertos, lo hablo en los dos sentidos, en la posibilidad de ampliarse, si fuera necesario y con la posibilidad de reducirse, ya sea por el motivo indicado en el párrafo anterior o por el hecho de que al cliente le surjan otras prioridades económicas o no esté satisfecho por el trabajo que se está realizando.

Esto es muy potente y es una de las circunstancias que puede empujar a los clientes a adoptar estos esquemas de trabajo.

Pero, ¿puede interrumpir el cliente sin más el contrato? Hay que tener en cuenta que en estas circunstancias quien tiene las de perder será el proveedor porque tiene un equipo de proyecto dedicado al trabajo y que tendrá que reorientar hacia otros proyectos o redistribuir sus componentes en otros equipos. Esto requiere un tiempo y lo normal es que se pacte un compensación entre las partes si se termina el contrato antes de tiempo y no se ha avisado con la suficiente antelación.

Por tanto, el presupuesto abierto siempre es una ventaja entre las partes, ofrece una mayor flexibilidad y se adapta de manera más natural al funcionamiento y dinámica de los proyectos de desarrollo de software.