archivo

Archivo de la etiqueta: objetivos

Es más, es posible que el que conozcas o que el que se defina en un análisis de un sistema de información no te lleve a ella. Es más, es posible que tengas que coger diferentes rutas para alcanzarla, que muchas de ellas se descubran por el camino, que incluso tengas que desandar parte de lo avanzado o que tal vez, tengas que conformarte con un objetivo más acorde al contexto en que se ha desarrollado el proyecto. Y en otras muchas ocasiones te termines quedando en el camino.

Eso es el desarrollo de software, saber a dónde se quiere ir, aceptar la incertidumbre y estar lo más preparado posible para adaptarse al cambio y que dicha adaptación requiera el menor esfuerzo posible.

En estos caminos habrá obstáculos, eso es seguro, unos serán sorteables (no sin esfuerzo), a veces nos encontraremos con otros que obligarán a abandonar parte del equipaje y no podremos llegar tan lejos como quisiéramos y en otros los obstáculos no nos permitirán llegar siquiera a un destino aceptable o nos dejarán tirados en medio del camino o de la nada.

Así es el desarrollo de software.

Otro enfoque que se puede aplicar es una variante del anterior y que podría suponer un modelo híbrido entre el modelo con presupuesto y plazos cerrados y el modelo con presupuestos y plazos abiertos (pago por iteración), para ello:

1) Se contrataría la realización del catálogo de objetivos y requisitos, pero centrándose en la obtención de aquellos que sean esenciales para obtener una versión mínima del sistema que sea operativa en producción, es decir, que sea utilizada por usuarios en circunstancias reales.

2) Se contrataría el desarrollo de esa versión y se aplicarían los criterios indicados en el artículo anterior sobre los aspectos que deben quedar fijados en el contrato.

Este desarrollo podría comprender más de una iteración.

3) Con la aplicación usándose en un contexto real el feedback cobra más relevancia. En este caso se podría abordar la contratación de incrementos del producto, ya sea mediante pago por iteración o con un enfoque más amplio, mediante un contrato de mantenimiento evolutivo que se podría articular de diferentes formas:

– Volver a aplicar la estrategia de contrato de catálogo de objetivos y requisitos + contrato de desarrollo.

– Directamente realizar la contratación del mantenimiento evolutivo y mediante órdenes de trabajo se encargarían las diferentes iteraciones a realizar sobre el producto.

La primera posibilidad que vamos a estudiar implica dejar muy claro a nivel contractual lo siguiente:

– Catálogo de objetivos y requisitos marco, debidamente priorizados por el cliente y con una valoración de esfuerzo realizada por el proveedor. Este catálogo de objetivos y requisitos, debe tener un nivel de detalle adecuado para poder ser evaluado de manera objetiva por el cliente y también para que pueda ser valorado por el proveedor.

Acertar con el nivel de detalle es importante, ya que no se pretende realizar un análisis en profundidad del sistema (de lo contrario estaríamos desarrollando en un híbrido entre la cascada y un enfoque iterativo incremental en la construcción), pero debe ser suficiente para que la valoración sea lo más acertada posible y para que no existan solapamientos entre requisitos o confusiones sobre su alcance real.

Es muy importante hacerle entender al cliente que resulta fundamental acertar con las prioridades, ya que permitirá obtener antes una versión del producto con sus aspectos más críticos ya implementados y tendrá margen de maniobra presupuestaria para poder hacer los ajustes que considere necesarios.

Lo anterior debe ser recordado al cliente durante todo el proceso de desarrollo.

Además se deberá presupuestar los costes de gestión por parte del proveedor al final de cada iteración: replanificación del proyecto en función de los cambios sobre el plan inicial o sobre el plan establecido hasta el momento, realización de un primer análisis y valoración de nuevos requisitos, revaloración de requisitos ya establecidos, etc…

Este catálogo de objetivos y requisitos, debe ser contratado aparte y antes de comenzar el proceso de desarrollo.

– Compromisos por parte del proveedor respecto a su participación en el proyecto: Esto podrá variar en función de la metodología utilizada, en algunos casos será suficiente su participación al principio de cada iteración (detallar los requisitos) y al final de la misma (evaluación de los resultados obtenidos y definición del alcance de la siguiente iteración), en otros casos requerirá que además de lo anterior, tengan participación dentro del propio equipo de desarrollo o tener un nivel de disponibilidad absoluto ante consultas o peticiones realizadas por los desarrolladores.

– Marco para el cambio del catálogo de objetivos y requisitos inicial y para la gestión de conflictos. Para reducir o evitar los conflictos es importante que quede claro y por escrito, cómo tratar las situaciones más comunes que se pueden producir en el proceso de desarrollo:

Cambio de prioridades. No tendría coste imputable al cliente.

Corrección de defectos. No tendría coste imputable al cliente.

Cambio de un requisito por otro nuevo, ampliación del alcance de un requisito ya existente y reajuste de un requisito ya implementado. Se tendría que evaluar el coste del cambio e intercambiarlo por requisitos todavía no implementados que tengan en suma un coste equivalente (sin pasarnos nunca del presupuesto restante para el proyecto).

Reducción del alcance de un requisito y eliminación de un requisito. Se generaría un “crédito” a favor del cliente que podría ser utilizado para los cambios indicados anteriormente.

Costes de gestión. Si los costes de gestión no superan el presupuesto establecido en cada iteración, pasarían a formar parte de ese “crédito” a favor del cliente. Si los superan y existe circunstancias motivadas para ello (cambios de enfoque en el proyecto, etc…) tendrá que compensarse el coste por créditos existentes o por requisitos.

Cumplimiento de plazos y de la calidad del producto. Siempre y cuando no existan circunstancias externas al proveedor, se debe garantizar por parte de éste un acuerdo de nivel de servicio que podría tener clausulas de penalización y también clausulas de excelencia.

En el artículo “¿Qué es un proyecto?” daba una posible definición de los mismos (una de entre otras tantas que se podía aplicar):

“Conjunto de actividades planificadas en el tiempo (su realización, por tanto, es gradual) que tienen como objetivo producir unos resultados (entregables) en base a los objetivos para los cuales se constituyó… Un proyecto, por tanto y por definición, debe ser finito”.

Vamos a ver si existe algún conflicto con un desarrollo iterativo incremental.

– Actividades planificadas en el tiempo.

Cada iteración está planificada en el tiempo, incluso podría establecerse una planificación inicial basada en una visión optimista de que nada va a cambiar durante el desarrollo, que no se va a producir ninguna contingencia o que siempre se va a acertar. Ahora bien, dicha planificación general debería adaptarse al feedback que se obtenga del usuario en cada ciclo, no hacerlo es atentar contra el cumplimiento de las expectativas del usuario que no es otra cosa que el fin último del proyecto.

– Producir unos resultados (entregables) en base a los objetivos para los cuales se constituyó.

Esto es lo que puede crear algo más de controversia, si bien la misma controversia que puedes aplicar a un desarrollo iterativo incremental la puedes aplicar a un desarrollo en cascada que muchos consideran el paradigma de lo debe ser un proyecto.

La controversia la podemos tener en el hecho de si realmente los entregables obtenidos entre el inicio y el fin del proyecto cumplen con los objetivos que dieron origen al mismo.

Si entendemos como objetivo la obtención de una aplicación que satisfaga las expectativas del usuario (o del cliente) en base a las especificaciones que se hayan podido implementar entre un inicio y fin pactado de un proyecto (en el siguiente punto, vemos esto de manera más concreta), el conflicto lo podemos encontrar no tanto en el nivel de acabado del producto sino en el cumplimiento de las expectativas, las cuales pueden ser satisfechas o no independientemente de la metodología o ciclo de vida aplicado.

Si no se ajustan dichas expectativas (que evolucionan desde los objetivos iniciales) a un final pactado del proyecto en función de su presupuesto, plazos y contingencias que se produzcan en su desarrollo, es cuando los proyectos parecen eternizarse o no tener fin.

Por tanto al final, la consideración de si los entregables del proyecto satisfacen los objetivos iniciales, es más cuestión de sentido común aplicado al contexto del proyecto que otra cosa (por eso, porque es cuestión de sentido común y de ética, existen tantos problemas a la hora de determinar un cierre de proyecto y esto es aplicable tanto a clientes como proveedores).

– Finito. Lo son. ¿Qué delimita el inicio y el fin? Posibilidades tenemos muchas, unas más objetivas que otras:

Si tomamos como base un presupuesto de partida, el inicio es el momento en que empezamos a consumir el mismo y el final cuando lo hemos agotado. Si hay un incremento sobre el presupuesto de origen, una segunda fase del proyecto (que en realidad es un nuevo proyecto) vendría delimitado de la misma forma por el inicio y fin de ese presupuesto adicional y así sucesivamente.

Otra posibilidad es tomar como referencia la entrega de un producto final que satisfaga las especificaciones del usuario, independientemente de que algunas hubieran cambiado desde la definición del alcance del proyecto (pudiendo haber diversas entregas intermedias que pasen a producción que satisfagan determinadas funcionalidades).

Ambas posibilidades, que son dos ejemplos posibles de delimitar un principio y un fin del proyecto son perfectamente compatibles con un enfoque iterativo incremental.

Lo fácil es asociar un incremento de la jornada laboral a un intento por incrementar la productividad en lugar de aplicar otras estrategias que probablemente tendrían mejores resultados.

La productividad es la capacidad de generar más resultados efectivos (que sirvan) por unidad de tiempo. Con esta definición se podrá pensar: “Bien, si es capaz de hacer X en t, si le incremento un 10% t, x también se incrementará en un 10%”.

Error.

Tal vez en máquinas eso funcione, pero en personas no. Nadie es capaz de mantener un ritmo de manera sostenida (sí de tener una media o una regularidad), un incremento de horas tal vez permita generar a corto plazo más trabajo efectivo, pero ¿y a la larga? lo más normal es que la productividad se diluya entre el número de horas de la jornada laboral.

¿Quieres hacer a la gente más productiva?, ¿quieres que superen la media de la organización? Para empezar no los desmotives (es importante este detalle, comento que lo primero que hay que hacer antes de motivarles es no desmotivarles porque desgraciadamente se tiene la tendencia a que las decisiones que se toman, más allá de motivar producen el efecto contrario) y a continuación premia de manera objetiva el cumplimiento de resultados.

Y conseguir los resultados no es lo mismo que ejecutar trabajos. Para ejecutar trabajos ya te pagan, la bonificación debe llegar cuando se superan unos objetivos que van más allá de lo normal, así como las penalizaciones deberán llegar cuando el rendimiento sea inferior a lo esperado.

Más tiempo, ¿más productividad? No, más tiempo, mayor temperatura en la silla.

Los planteamientos ágiles en el desarrollo de software, siendo extensible a prácticamente cualquier ámbito de nuestra vida, no son contrarios ni incompatibles con la definición de objetivos a medio o largo plazo porque una cosa es saber a dónde queremos llegar y otra superar las diferentes metas parciales con sus correspondientes obstáculos que nos encontraremos hasta llegar allí.

Y es en ese camino de incertidumbre donde los planteamientos ágiles permiten sortear los inconvenientes que nos vayamos encontrando, realizando adaptaciones rápidas y aproximada a cada nuevo entorno.

Definir un objetivo, determinar con detalle los pasos a dar para conseguirlo y no querer salir del guión pase lo que pase es como tener un mapa que sabemos que está equivocado y empeñarnos en seguir utilizándolo.

Los proyectos de desarrollo de software se caracterizan por su incertidumbre. Tenemos una idea de a dónde queremos llegar pero no podemos saber qué es lo que va a pasar por el camino. Una buena gestión de riesgos permite adelantarnos a esas contingencias o tener previstas una respuesta pero es su combinación con un planteamiento ágil la que permitirá sortear con menos dificultad los obstáculos.

La agilidad es una actitud que se instrumenta en metodologías pero no es la solución a todos los problemas ya que es una forma de afrontar y reaccionar ante ellos, una forma de evolucionar hacia la consecución de un objetivo.

Son muchos más los factores y variables que nos pueden llevar al éxito o al fracaso. Por eso el desarrollo de software es algo tan complejo y no basta con seguir una metodología o unos principios, si bien, cuanto mejores sean nuestras herramientas, hábitos, experiencia y conocimientos más posibilidades habrá de superar las adversidades, teniendo presente que, nadie, absolutamente nadie, es infalible.

Es curioso descubrir la diferencia en los resultados cuando cada uno hace la guerra por su cuenta y cuando todos están enfocados a la consecución de un objetivo común.

Puede parecer sencillo alinear objetivos pero la realidad es que lo más normal es que cada uno interprete los objetivos a su manera, ¿por qué? pues porque la percepción de cada uno sobre un mismo hecho es diferente y porque somos tremendamente egoistas (y quien esté libre de pecado que tire la primera piedra).

Un gestor de equipos de trabajo tiene que tratar de conseguir ese enfoque común en los objetivos, que se entienda la importancia de la colaboración entre todos para alcanzarlos. Un gestor de proyectos tiene que tratar de conseguir lo mismo entre los diferentes stakeholders que intervienen.

Personas, personas, personas, al final todo lleva a lo mismo, cierto es que el contexto en los proyectos influye mucho en los resultados, pero somos nosotros finalmente lo que lo empujamos al éxito o al precipicio.