archivo

Archivo de la etiqueta: priorización

Llevo unos cuantos artículos haciendo reflexiones sobre el hecho de que el desarrollo de software tiene un precio y que cuando se oferta (y se acepta) hacerlo por menos del mismo sin que exista una justificación para esa reducción del importe o que cuando se pone un presupuesto de ejecución inferior al que debería ser, el proyecto entra en una situación de alto riesgo para que se desarrolle con unos niveles de calidad aceptables o para que simplemente se ejecute. Hay que huir, por tanto, de ofertas imposibles y presupuestos insuficientes.

Esa situación ha hecho y está haciendo mucho daño a nuestra profesión porque al final todos pagamos justo por pecadores cuando un proyecto y otro también no alcanza unos niveles mínimos de calidad.

Sin embargo, por encima del Departamento TIC de una organización se encuentra la dirección de la misma que es la que hace el reparto de presupuesto entre los diferentes departamentos de la misma. Si al Departamento TIC se le asigna X y en realidad necesita 2*X o 3*X para poder ejecutar sus competencias, es necesario hacer ajustes y ese ajuste llega también a los presupuestos de los proyectos porque lo que suele suceder es que el recorte económico no suele ir acompañado por una rebaja de competencias, es más, en algunos casos va de la mano incluso con más tareas.

Ante esto, ¿qué se puede hacer?

1) Pelear hasta donde se pueda porque el presupuesto que te asignen sea el máximo posible acorde a las tareas que tienes que realizar. El éxito de esto dependerá muy mucho de la consideración y posición que tenga el Departamento TIC en la organización. Si no está bien posicionado, será complicado conseguir algo, pero por lo menos, hasta donde se pueda hay que intentarlo.

En uno de los primeros artículos que escribí comenté lo necesario que resulta que el responsable TIC de una organización ocupe un puesto directivo en la misma, de lo contrario está vendido. También he comentado que el presupuesto TIC debe ser gestionado integramente por el Departamento TIC ya que así se conseguirá un mejor rendimiento de la inversión económica y una mejor planificación.

2) Gastar mejor.

Esto empieza por priorizar ya que no todo es igual de importante ni todo es igual de urgente. La priorización implica prescindir de tareas que no son necesarias. Si nos ponemos a analizar hay muchas modificaciones en sistemas de información (generalmente evoluciones funcionales), alcances de muchos desarrollos u otras tareas dentro del Departamento TIC que son prescindibles. En todos estos casos, menos es más.

Si hay una solución que funciona, ¿para qué sustituirla por otra? (salvo que su coste total de propiedad sea superior al que tendría si se desarrollase de nuevo).

3) Mejorar la productividad de los propios equipos. Siempre es posible afrontar esta mejora y en estas situaciones donde el presupuesto y el trabajo es el que es es cuando hay que intentar mejorar la eficiencia del trabajo desarrollado. No se trata de trabajar más, sino de trabajar mejor.

4) Adaptar los procesos a la realidad presupuestaria.

5) Elegir el proveedor más adecuado para cada trabajo. No hay un proveedor universal que sea el mejor en todo, hay especialistas que hacen mejor una serie de tareas que otros. La elección de un proveedor que sea especialista en un área probablemente te pueda proporcionar mejores condiciones económicas con un nivel de calidad aceptable que otros. Como puede haber diversos especialistas sobre una materia, lo mejor es ir hacia una concurrencia competitiva y que gane el que mejor solución proponga, sin que el precio sea el factor principal para realizar la elección.

6) Tender al producto sobre el desarrollo a medida, cuando las condiciones sean mejores, que lo serán en la mayoría de los casos. Si además, la solución es libre, mejor (siempre y cuando el servicio que se te ofrezca sea competitivo frente a la alternativa propietaria).

7) Aplicación de estrategias ágiles en el desarrollo y mantenimiento de software.

Estas son algunas posibilidades que se pueden aplicar y permitirán optimizar tu presupuesto, sin embargo, no son los ingredientes de una receta que te permitan conseguir imposibles, si el desequilibrio entre lo que se puede gastar y los servicios a ofrecer son importantes, la calidad de los mismos se verá mermada.

Un amigo me comentó hace poco que efectivamente los principios y metodologías ágiles establecen un marco de trabajo y un proceso de ingeniería del software que sientan unas bases para la entrega de un software de calidad, entendiéndose en este caso como la consecución de un producto que satisfaga las necesidades y expectativas del usuario, pero que tenía serias de que pudiese solucionar el ajuste al presupuesto (sobre todo) y plan de proyecto establecido.

Los principios y metodologías ágiles como bien indicaba mi amigo son instrumentos y los mismos por sí solo no garantizan nada. Es lógico pensar que con las mejores herramientas se trabaja mejor y se pueden obtener mejores resultados de una manera más eficiente. Sin embargo, lo que se obtiene al final es el resultado de la aplicación de las mismas por personas (ya pertenezcan al equipo de desarrollo, al área usuaria o a los responsables técnicos del cliente) en un proyecto concreto. Si las personas fallan, los instrumentos no pueden solucionar por sí solo nada, tal vez pueden hacer que el estropicio sea menor, pero poco más.

Por ese motivo en el desarrollo de software lo más importante son las personas, todo lo demás puede ser más o menos importante, pero viene después.

Partiendo de esa base, la aplicación de estrategias ágiles ni garantiza nada, ni produce milagros.

Si un proyecto tiene un presupuesto y/o plazos que no se ajustan a la realidad del objeto del trabajo y/o de las expectativas del usuario da igual que el equipo de proyecto sea el mejor, que estén motivados y que la metodología sea la más apropiada al proyecto, ya que lo más probable es que no se consigan los resultados que se esperan a nivel de calidad, presupuesto o plazos.

Los que nos dedicamos al desarrollo de software no estamos para hacer milagros sino que estamos para intentar hacer nuestra labor de la mejor manera posible y para ello se requiere un equilibrio entre lo que se pide, se espera, se tarda y lo que cuesta.

Lo anterior es complejo, sobre todo porque la estimación de esfuerzo a alto nivel de un proyecto (no de tareas concretas) puede fallar y a partir de ahí, lo más probable es que fallen también los plazos.

Para estimar un proyecto que se va a desarrollar siguiendo estrategias ágiles soy de la opinión que hay valorar el proyecto en primer lugar sin tener en cuenta el feedback del usuario en cada iteración y sobre esa estimación inicial aplicar un factor de ajuste, teniendo en cuenta la complejidad funcional y técnica del proyecto, así como las características de los usuarios que van a intervenir.

Por tanto, aplicando ese método el coste que debe salir será superior que el de si se realizase el cálculo teniendo en cuenta una metodología en clásica o en cascada, ya que mientras en esta segunda los costes de mantenimiento se aplican después, en las metodologías ágiles se pueden realizar mantenimientos desde la primera entrega, por lo que hay que tenerlos en cuenta en el propio coste del proyecto.

Con respecto a los plazos es importante conocer las expectativas del usuario en ese sentido y desde el primer momento darle a conocer lo factible o no que resultan sus deseos y que la estrategia a seguir será establecer una priorización de sus requisitos, para que cuando la fecha límite llegue, se tenga construido lo más importante.

Como decía al principio, todo esto son ideas, consideraciones, herramientas y estrategias, que como fundamento teórico para la realización de un proyecto pueden estar bien (o no estar de acuerdo con ellas), sin embargo, al final, lo realmente decisivo son las personas.

En la gestión de un sistema de información llegan incidencias de funcionamiento, peticiones de mejora y también se detecta desde el departamento de sistemas comportamientos anómalos de las aplicaciones. Todo eso supone un conjunto de tareas que tenemos que ordenar de alguna manera. Todo eso se complica si además, el mantenimiento del sistema es compartido a través de un mismo contrato con otros, es decir, el presupuesto y por tanto, la capacidad de trabajo asumible se tiene que repartir entre todas las aplicaciones que son sustentadas por el mismo. Si además el presupuesto es escaso, las rampas serán todavía más duras.

Como no es posible tratar todo a la vez es necesario priorizar. Cuanto menos nos equivoquemos al seleccionar qué tareas se realizan antes que otras conseguiremos una mayor satisfacción de los usuarios y unos sistemas más estables en la menor tiempo posible. Pese a que ese sea un objetivo es necesario ser realistas y tener presente que nos equivocaremos y muchas veces, a veces por un problema de criterio, otras porque la información necesaria para tomar la decisión no haya venido completa o sea incorrecta y otras porque la propia presión ejercida por los usuarios nos haga tomar unos caminos en lugar de otros.

Para reducir el número de errores es necesario que conozcamos muy bien los sistemas de información sobre los que tenemos que tomar decisiones y su contexto (características de los usuarios, grado de utilización de la herramienta, estado actual de la aplicación, posible evolución en cuanto a modificaciones funcionales, etc…), así como las características del contrato de mantenimiento (capacidad de trabajo asumible, duración, etc…) y conocer, en la medida en que sea posible, las disponibilidades presupuestarias futuras, ya que no es lo mismo realizar priorizaciones en un mantenimiento sabiendo que puede tener continuidad en un futuro con un presupuesto acorde a las necesidades existentes que teniendo constancia de que el presupuesto se va a reducir considerablemente o incluso desaparecer.