archivo

Archivo de la etiqueta: costes

Es cierto que llegado el momento puedes abrir la mano y permitir cambios en las especificaciones, pudiendo negociar el intercambio de requisitos, pero la verdad es que no suele dar buenos resultados por diversas razones: el intercambio no es real (generalmente las tareas que entran suponen más esfuerzo que las que salen, si es que sale alguna), se cambian requisitos sobre visiones abstractas del producto por lo que se siguen realizando a ciegas independientemente de que la visión tenga menos niebla que al principio y además, cambiar de enfoque en determinadas funcionalidades, con el producto avanzado tiene un coste alto.

Esto último también se puede producir en un desarrollo iterativo incremental, lo que lo diferencia es que en muchos casos, la detección del problema se habrá realizado en etapas más tempranas (en el caso de que no sea un cambio de enfoque por cambios en el proceso) ya que los usuarios estarán interactuando con el producto mucho antes.

La gestión de proyectos basados en enfoques clásicos o predictivos es en realidad una gestión del desgaste porque el cumplimiento de la agenda implicará falta de flexibilidad una vez que el análisis inicial se ha completado.

En ese triángulo que forman: alcance, coste y plazos, la modificación de uno de los vértices impacta sobre el resto salvo que exista un margen suficiente que por otra parte casi nunca existe o casi nunca es suficiente. Si no existiendo ese margen se modifica el alcance (o el esfuerzo para conseguir los objetivos, ya que lo mismo el alcance es similar pero la modificación de requisitos sobre componentes construidos hace que sea necesario un esfuerzo mayor ya que el ya invertido hay que contarlo) y se quieren mantener costes y plazos, el primer afectado será la calidad final del producto.

El enfoque clásico o en cascada del desarrollo de software es un modelo de carácter predictivo. Se realiza un análisis del sistema a desarrollar o de los módulos a evolucionar (alcance), se estiman costes y plazos y se trata de gestionar esta agenda (lo que se denomina triángulo de hierro) durante el resto del proceso de desarrollo.

Resulta razonable que pueda funcionar, sin embargo, es un modelo basado en la estabilidad del contexto y en la rigidez de los requisitos y ahí es dónde empieza a tener problemas porque una vez sentadas las bases, lo que cobra prioridad es el cumplimiento de la agenda ya que se entiende que el producto está definido.

La realidad es que los requisitos van a cambiar, conforme vaya avanzando el desarrollo del producto el usuario se dará cuenta de que determinadas especificaciones no son buenas o son mejorables, que se le ha olvidado tal o cual gestión o que las prioridades indicadas tienen que modificarse.

No se trata de que el desarrollador (analista o el componente del equipo que haya hecho ese trabajo) o el usuario lo hayan hecho mejor o peor (por supuesto que un buen trabajo permite trabajar en unas condiciones mucho más favorables) sino de algo que es natural en un proyecto de desarrollo de software y es que haya una evolución ya sea del negocio y/o de la percepción que tienen los usuarios con respecto al sistema de información o algo tan simple y tan frecuente (y humano) como que nos hayamos equivocado.

Esto no es algo que yo me esté inventando, ¿en cuántos proyectos has trabajado en los que no se hayan tenido que cambiar algunos de los requisitos iniciales o se hayan tenido que añadir otros nuevos?.

Como la realidad es esta, tenemos que gestionarla: hay un catálogo de requisitos que permanece vivo a lo largo del proceso de desarrollo.

Como esa es la realidad, los enfoques iterativos incrementales son, a mi juicio, la mejor estrategia para afrontarla, teniendo en cuenta pueden existir proyectos, ¿por qué no?, donde el enfoque clásico sea el más apropiado.

El enfoque clásico y su gestión de proyectos asociada está orientada principalmente a controlar y gestionar las desviaciones en costes y plazos. Es decir, para que el proyecto tenga éxito no solo debe satisfacer las expectativas puestas en el mismo sino que también es necesario que las desviaciones sobre costes y plazos sean mínimas.

Por mucha habilidad que se tenga gestionando estos proyectos, por muy bueno que sea el equipo de proyecto y por muy implicados que estén el resto de stakeholders, si el cálculo inicial de costes y plazos es deficiente no se podrá evitar desviaciones en costes y plazos, además de comprometerse el producto final.

Y lo normal es que ese cálculo inicial sea deficiente porque se realiza valorando un producto que no deja de ser una idea abstracta. La calidad del cálculo de costes y plazos mejorará conforme se vayan conociendo más detalles del sistema a desarrollar por lo que si se quiere gestionar un proyecto siguiendo un enfoque y gestión de proyectos clásica se debería partir de unos requisitos de calidad.

Después se requerirá de un entorno de proyecto estable, sin cambios de contexto, para intentar gestionar adecuadamente la agenda, de lo contrario tocará hacer juegos malabares para intentar minimizar desviaciones en costes, plazos y calidad del producto y cuando esto pasa lo normal es que el proyecto no salga bien.

En mi opinión, lo realmente importante es el valor del producto. No digo que cumplir la agenda no lo sea, pero si las circunstancias golpean (y lo hacen casi siempre), la misma no debe condicionar el valor final del producto. Si no hay posibilidades de varias costes y plazos el producto se resentirá.

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

“¡He conseguido contratar este desarrollo con una tarifa de programador de 9 euros la hora!”.

Quién diga frases como esas presumiendo de ello, probablemente meses o años después se estará arrepintiendo de haber aceptado una propuesta con esos importes, en el caso, claro está, que a mediados del proyecto haya salido por patas dejándole el regalito a otra persona.

Para empezar a ninguna empresa le puede salir rentable un proyecto con esas tarifas y las pérdidas excederán, en la mayoría de los casos, a la cantidad límite a partir de la cual una empresa pueda considerar hacer una apuesta para quedarse con un potencial buen cliente.

Y como a la empresa no le saldrán las cuentas tenderá a tomar la medida (equivocada) de poner a personal con muy poca experiencia y cualificación en el proyecto, a intentar acortar sensiblemente y desde el primer momento el alcance del proyecto y a acelerar los desarrollos tirando la calidad por los suelos. Y todo ello en un contexto de desgaste que será más insoportable conforme avance el proyecto.

¿Qué eres capaz de hacer rentable un proyecto con esos precios?. Felicidades, te pediría que, por favor, escribieras un libro explicando cómo.

Al final esa ganga, se convertirá en pesadilla.

¿Motivo? Sacar un proyecto adelante no es solo echar horas sino intentar que las mismas sean productivas y el nivel de productividad y efectividad de un desarrollador no suele ser comparable linealmente con el de otro de menos conocimientos y experiencia sino que la diferencia probablemente será exponencial.

Para empezar habría que definir qué se entiende cómo documentación de calidad. Para mi una documentación de calidad es un instrumento que sirve como herramienta para un desarrollo debiendo estar ajustada a las posibilidades y contexto del proyecto.

Por tanto, la documentación debe ser la precisa, ni más ni menos y por ese motivo debe ser el proyecto el que determine la que resulta necesaria. ¿Formalismos? Puedo entender que una organización quiera una homogeneidad en la documentación de los proyectos pero las normas deben ser lo suficientemente flexibles para que cumpliendo ese objetivo no sobrecarguemos a los desarrollos con exceso de documentación (más documentos de los necesarios), con excesos en cada documento (que cada documento tenga más contenidos de los necesarios) y con exceso de formalismo.

Una documentación de alta calidad no es el resultado de los formalismos que se establezcan sobre la misma sino por la adecuación de sus contenidos a los propósitos del proyecto. Tener una documentación de un proyecto perfecta a nivel formal no asegura que el producto final satisfaga las expectativas que se tenían puestas en él, lo único que asegura es la inversión de un esfuerzo que se podría haber utilizado para entregar un producto más depurado y con menor deuda técnica.

Este antipatrón puede tener tres orígenes:

– El equipo de desarrollo opta por la opción más sencilla (en cuanto a asumir responsabilidades) de acatar la petición de desarrollo que se le ha descrito (con un cierto nivel de detalle que de alguna manera dirigiría la solución hacia un enfoque concreto de implementación), sin entrar en ningún análisis de alternativas de solución. “Me han dicho que haga X y yo hago X”. Típico en entornos en donde los gestores caen en el antipatrón “yes man“.

Es cierto que siempre se podrá utilizar la defensa de “yo he hecho lo que me han dicho”, pero eso puede provocar unos costes y un incremento en la complejidad de la aplicación que puede que no sean sostenibles (al cliente, es posible que no le haga mucha gracia saber que te has gastado una buena parte del presupuesto para implementar una funcionalidad, cuando todavía existen otras muchas por hacer).

Hay que tener en cuenta que el que realiza la solicitud probablemente no sepa las implicaciones que tiene lo que ha pedido y lo mismo considera válidas otras alternativas más simples.

No se trata de no hacer lo que nos piden, sino de buscar la solución más eficiente y productiva para todos.

– Se confía tanto en el criterio de alguien del equipo de proyecto, del área usuaria o el cliente que se decide aplicar la solución propuesta sin aplicar prácticamente ningún filtro sobre la misma.

– El director usuario o el cliente no atienden a razones, quieren lo que piden de una determinada manera y no quieren conocer otras alternativas (por más que se les insista).

En esta situación, lo mejor es dejarle muy claro al que lo ha pedido, los costes que tiene y el impacto en el producto (e incluso en el proyecto). Por tanto, todo por escrito, tanto la solicitud, como la previsión de costes e impacto (lo más probable es que en el futuro haya problemas y es necesario que quede delimitada la responsabilidad).