archivo

Archivo de la etiqueta: equilibrio

Una reacción frecuente por parte de los gestores, ya sea de la parte usuaria o del equipo de desarrollo, cuando aparecen problemas es tratar de ejercer un mayor control sobre el proyecto.

Esto puede tener efectos beneficiosos o perjudiciales en función de cómo realmente se enfoque ese control y si se toman o no decisiones para resolver los problemas reales que tiene el proyecto.

Creo en la autogestión pero por mucho que creamos en ella depende al final de al actitud de las personas que forman parte del equipo y del grado en que terceras personas que pueden ser otros gestores o no influyan en el día a día del equipo.

Si el equipo no es capaz de autogestionarse es necesario tratar de conseguir un orden con el objeto de que el equipo funcione de nuevo de manera adecuada e incluso sea capaz de autogestionarse. Las actuaciones deberán ir dirigidas a dar un orden y criterio a los trabajos y también a tratar de resolver los problemas que han provocado que el equipo no funcione como tal y/o hayan provocado que se llegue a esta situación.

Se trata por tanto de un mayor control orientado a buscar un equilibrio que permita volver a una situación de normalidad en la cual ya no sea necesario esa intensidad en el control.

El tiempo que se tarda en recuperar el equilibrio dependerá del caos que exista en el proyecto y los problemas en las relaciones entre cliente y proveeedor por lo que en muchas ocasiones no se consigue volver a una situación de normalidad y se requiere una alta implicación del gestor.

Evidentemente llegada a esa situación el gestor deberá hacer autocrítica porque si se llega a ese nivel de caos y contaminación en el proyecto es porque no ha sabido leer el estado en el que se encontraba y/o porque no ha tomado las decisiones adecuadas en el momento o momentos en que era preciso.

Pero una cosa es ejercer un mayor control y otra su exceso porque tal vez se consiga dar un cierto orden a los trabajos pero puede provocar que los desarrolladores se bloqueen y teman equivocarse lo que afectará a su productividad y a la búsqueda de soluciones que vayan más allá de su zona de seguridad.

Los proyectos de desarrollo de software suelen tener una duración media o alta. En estos casos es fundamental mantener una constancia en los niveles de productividad y calidad. Alcanzar ese equilibrio es complicado de ahí que muchos proyectos entren en un constante sube y baja que si no se gestionan bien terminan impactando en su resultado final.

Es muy importante empezar bien un proyecto. ¿Qué se entiende por eso? Disponer de los medios adecuados para alcanzar los objetivos planteados, empezar a utilizarlos de manera adecuada y contar con la colaboración efectiva de los diferentes stakeholders, sobre todo los responsables funcionales o product owners.

Sin embargo empezar bien no es sinónimo de nada (decía Sócrates que: “Comenzar bien no es poco, pero tampoco es mucho”) pero supone por lo menos una base con la que empezar a trabajar sin tener que estar apagando fuegos desde el primer día y gestionando conflictos y desgastes con el cliente desde el primer momento.

Un inconveniente importante lo encontramos cuando los proyectos entran en una fase de letargo, algo muy frecuente en ciclos de entrega largos (generalmente superiores a tres o cuatro meses) en los que se pierde la constancia, implicando al final, un sobreesfuerzo de todos para tratar de cumplir con la entrega, provocando generalmente la entrega de una versión de peor calidad y un desgaste por parte del equipo que se podría haber evitado.

Este es uno de los motivos que debe empujar a la aplicación de ciclos de entrega más cortos. No se trata con ellos de exprimir al desarrollador (de hecho si se llega a eso es que no lo estamos haciendo bien) sino de conseguir una constancia, un ritmo y una velocidad que trate de mantener una buena relación entre la productividad y la calidad de los trabajos.

No se puede entender el desarrollo de software sin cooperación y sin el elemento imprescindible para que sea efectiva: la comunicación.

Cuantos más distancia (no me estoy refiriendo a distancia física) haya entre las personas y los equipos y más muros (o fosos) se pongan en medio más complicado será que el proyecto vaya a algún sitio.

La creatividad también es importante si no se pierde el control sobre la misma ya que no poseemos un recetario que ofrezca soluciones a todos los problemas.

Comenta Alistair Cockburn que: “El desarrollo de software es un juego cooperativo de invención y comunicación” y estoy totalmente de acuerdo con esa apreciación: si no sabes o no quieres jugar el trabajo se resiente.

Reducir distancias, eliminar fronteras y agilizar las relaciones requiere de mucho esfuerzo y habilidad pero sobre todo depende de que creamos que realmente es así como hay que trabajar. No basta con que lo leamos o que nos lo digan, hay que creer en ello porque mantener el equilibrio no es nada sencillo debido a que las propias contingencias de un proyecto desestabilizan y porque detrás de todo estamos las personas y no hay nada menos estable que nuestro comportamiento.

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

Un modelo de relaciones cliente/proveedor en el que se rompe de manera sensible el equilibrio del todos ganan, afecta al producto de manera directa.

Si la contratación de un proyecto se saca por mucho menos de su valor o un proveedor realiza una oferta muy por debajo de lo que va a costar el desarrollo, habrá problemas.

En los dos casos, el proveedor no va a querer perder dinero (salvo que sea una apuesta para abrir las puertas de un determinado cliente con el objetivo de conseguir nuevos contratos que permitan recuperar la pérdida y obtener beneficios) y por tanto vendrán recortes en la calidad del software y en el alcance del proyecto.

El cliente podrá actuar para minimizar esos recortes pero su control del producto no será suficiente para evitarlos en su totalidad. A lo anterior se le sumará un desgaste importante por parte de las personas implicadas.

En estas circunstancias, el proveedor a veces conseguirá ligeros beneficios, otras se quedará prácticamente a la par y en el resto perderá dinero; mientras que el cliente tendrá un producto probablemente con deuda técnica deficiente, con funcionalidades no implementadas y con incidencias de funcionamiento.

Sin embargo, esta ruptura del equilibrio, no tiene por qué proceder de presupuestos desequilibrados, también se puede producir con presupuestos objetivos a la naturaleza de los trabajos a realizar e incluso con presupuestos holgados.

En estos casos suele estar motivado porque el cliente empiece a realizar cambios sobre el alcance inicial del proyecto o sobre el producto sin consensuar con el proveedor a cambio de qué otras tareas se llevan a cabo (en la mayoría de los casos a cambio de nada) o porque el proveedor quiera paliar la falta de productividad de su equipo y/o maximizar beneficios y reduzca la calidad de los trabajos e intente escamotear todas las funcionalidades que le sean posible.

Por tanto, tanto si se trata de contratación ágil como de otros tipos de contratos entre cliente y proveedor, todo empieza a desviarse cuando se rompe el equilibrio.

Si todo es así de evidente, ¿por qué se rompe el equilibrio? pues porque somos personas y como tales tenemos nuestras debilidades, como por ejemplo nuestra falta de capacidad a la hora de asumir nuestros propios errores. Otro factor es la ambición desmedida.

Y otro factor muy importante es el entorno tanto en el cliente como en el proveedor, que aprietan a las personas implicadas en el proyecto para favorecer sus intereses, por ejemplo, hay que intentar que el proveedor nos haga este módulo aunque no esté contratado o hay que intentar incrementar el margen de beneficio del proyecto un 15%.

En un proyecto de desarrollo de software participan muchas personas, cada una de las cuales tiene un criterio propio, resultado del rol que desempeñan, su experiencia, conocimientos, percepción del problema. etc…

Y esta situación la tenemos tanto dentro del equipo de proyecto, como con las personas del resto de stakeholders con los que tenemos que trabajar.

Alcanzar un equilibrio entre tantas visiones resulta complicado, como difícil resulta también alinear sus objetivos individuales con un objetivo común y general que no es otro que realizar el proyecto con éxito.

Un proyecto es la suma de muchas decisiones, a veces se acertará, a veces se fallará. Eso es una constante, como también lo será que dentro de tal amalgama de personas, probablemente habrá casi siempre alguien que ante un problema apunte una solución más adecuada que la que se tomó.

A este antipatrón se llega, cuando de manera reiterada el equilibrio entre las personas que trabajan en el proyecto (ya sean del mismo equipo o de diferentes) se rompe, echando en cara que determinadas decisiones fueron erróneas por no escuchar la solución que se proponía.

El equilibrio se rompe porque no se es constructivo en el análisis del proceso de toma de decisiones, tal vez algo esté fallando en él y no se estén teniendo en cuenta, por el motivo que sea, opiniones válidas. En lugar de eso, se procede al ataque personal o a la creación de motines.

Los equipos de proyecto y, en general, los equipos de trabajo, hasta cierto punto deben funcionar de forma autónoma, utilizando como patrón de funcionamiento los procesos implantados en la organización, la metodología de desarrollo y cualquier acuerdo específico alcanzado para la realización del proyecto.

Ahora bien, existen determinadas decisiones que deben recaer sobre aquellas personas en las que se le ha delegado una determinada competencia y que no se deben diluir por inacción en el equipo de proyecto porque al final esto se volverá en contra de dicho equipo.

También existen determinadas circunstancias donde el responsable máximo del proyecto o el responsable de un equipo de trabajo tiene que intervenir, ya sea para poner un poco de orden, cuando éste se pierde, para reconducir situaciones no beneficiosas para el proyecto, etc…

El antipatrón lo tenemos cuando dichos responsables no aparecen en el proyecto o no aparecen en momentos clave, es decir, cuando se les necesita casi nunca están. Esta circunstancia hace mucho daño al proyecto, ya que su principal misión es mantener el frágil y complicado equilibrio entre todos los stakeholders y entre las personas que conforman un determinado equipo de trabajo.

Cuanto más grande sea la grieta creada por su ausencia, más complicado será reconducir el proyecto a una situación de equilibrio y si se consigue será a costa de un desgaste y/o un esfuerzo innecesario, si el responsable hubiera hecho lo que tenía que hacer.