Objetivos comunes o prioridades discordantes

Es absolutamente necesario en todo Departamento de Informática de una organización el conocimiento y comunicación de sus objetivos adecuados al contexto y circunstancias en las que se encuentra, de lo contrario, los distintos departamentos que la componen definirán sus propios objetivos o prioridades ajenos a una visión global del servicio que se tiene que ofrecer y dando la espalda a cualquier posibilidad de sinergia.

Y como decía sin olvidar contexto y circunstancias. Lo mismo las posibilidades actuales pasan exclusivamente por dar una buena atención orientada al puesto de trabajo de los usuarios e intentar dar supervivencia a los sistemas de información más críticos o prioritarios de la organización. Si no tenemos en cuenta donde nos encontramos probablemente no consigamos llegar a ningún sitio y enfoquemos los esfuerzos en aspectos secundarios que hagan que nos quedemos con la bolsa vacía.

Y no, no son tan obvios los objetivos de un departamento si no se definen o discuten. Los objetivos deben ser explícitos y recitados casi a modo de mantra por los que se tienen que encargar de alcanzarlos. Darlos por conocidos, sin reflejarlos en ningún sitio, sin hacer un seguimiento medianamente objetivo, es lo mismo que dejar las puertas abiertas al caos, a la definición de prioridades y objetivos singulares y a los reinos de taifas.

Desarrollo de software. Metas, caminos, incertidumbres

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.

Desarrollo de software. Contratación ágil III

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.

Desarrollo de software. Contratación ágil II

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.

Desarrollo de software. Enfoques iterativos incrementales y el concepto de proyecto, ¿conflicto?

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.

Más tiempo, ¿más productividad?

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.

Desarrollo de software. Objetivos, incertidumbre, agilidad

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.

Desarrollo de software. Alinear objetivos

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.

¿Qué es el software?

No hace mucho un amigo me pidió que dedicase un artículo a lo que para mi era el software, más allá de definiciones formales. Es cierto, hablo mucho sobre aspectos relacionados con los procesos, la metodología, las personas, la calidad, sus problemas, algunas de sus características, pero no me había centrado en darle una definición desde mi propio punto de vista.

¿Qué es el software? Una solución.

Una solución porque tiene como objetivo satisfacer una expectativas de manera directa (cuando se trata de un desarrollo a medida) o de manera indirecta (cuando se trata de un desarrollo que se ofrece a la sociedad de manera gratuita, de pago, con acceso al fuente o no, con la posibilidad de modificar el fuente o no).

Tras las expectativas hay personas. Por lo que el software es una solución que trata de satisfacer una serie de expectativas que sobre él tienen puestas personas. Tras las expectativas hay objetivos. Por lo que podemos ampliar la definición a que el software es una solución que trata de satisfacer una serie de expectativas que sobre él tienen puestas personas para el cumplimiento de unos objetivos.

Esta solución, está formada por un conjunto de instrucciones que se ejecutan sobre un dispositivo físico (independientemente de que se pongan capas software entre ellos, como servidores de aplicaciones, servidores web, máquinas virtuales, sistemas operativos, etc…, ya que los mismos actúan básicamente como interfaces que ofrecen servicios y valor añadido).

Así de simple y así de complicado a la vez es el software porque para que un sistema o una aplicación funcione es necesario que el código simule un comportamiento inteligente que responda a acciones provocadas por estímulos externos, ya provengan de un usuario, de sensores, de eventos, de otro software, etc…

Desarrollo de software. Compartir objetivos

Considero fundamental, para la gestión de un departamento, de una organización y por supuesto de un proyecto de desarrollo de software que exista una visión global de los objetivos por parte de los stakeholders.

Dentro de las tareas que tienes encomendadas tienes tus propios objetivos pero siempre destinados a satisfacer un objetivo mayor. Cuando se pierde ese enfoque, se pierden las sinergias, la colaboración y cada pieza trata de funcionar, de mantenerse a flote, ande o no ande la máquina en la que se encuentran.

Para conseguir esto se requieren de políticas de comunicación, de coordinación y de dinamización efectivas, con personas decididas y convencidas de que la suma de las partes en conjunto vale más que por separado. Encontrar personas que tengan esa amplitud de miras es muy complicado, ya que además de esa cualidad se requieren habilidades de liderazgo.

En un departamento TIC, por ejemplo, los eternos conflictos entre los departamentos de desarrollo y sistemas vienen provocados precisamente por eso, por no compartir objetivos comunes.

En un proyecto de desarrollo de software, con su complejidad, su incertidumbre, donde las condiciones de partida lo mismo son muy negativas, si los distintos grupos de personas implicados no comparten el mismo objetivo con respecto al sistema, la batalla está perdida.