Ruptura de fronteras entre responsables técnicos, funcionales y proveedor

Es muy importante saber dónde se encuentra cada uno y cuál es su rol. Pero partiendo de esa base, los proyectos funcionan mejor cuanto menos muros existen entre los diferentes stakeholders en el proyecto (en el título del artículo he puesto unos cuantos, en la medida en que sean más los que decidan aplicar esta filosofía, las cosas funcionarán mucho mejor).

Venimos de una cultura formalista, en la que los mecanismos de comunicación se centraban en el intercambio de papel. Una cultura en la que todas las partes trataban de cubrirse las espaldas, para que cuando hubiera problemas, que los había, por mucho papel que hubiera por medio, todos tuvieran argumentos de defensa o de ataque.

El problema no era que quedasen cosas registradas en papel, en sí no es malo siempre y cuando no se abuse de él, sino la orientación que se le dio. En lugar de crear espacios comunes se creaban muros de defensa para lo que después podría venir.

Y es que al final nadie solía quedar satisfecho. La crisis del software (totalmente vigente hoy día) daba como resultado productos que no satisfacían las necesidades del cliente y encima el proveedor obtenía, en el mejor de los casos, beneficios muy escasos. Además, generalmente cuando más satisfecha quedaba una parte, menos quedaba la otra.

Eso necesariamente no lo arregla un simple cambio de mentalidad, porque en un proyecto siempre hay muchos intereses en juego e intervienen personas ajenas a los mismos pero que tienen influencia directa sobre los equipos (los responsables de los departamentos implicados o de las propias organizaciones).

Para que esto termine calando dentro de una determinada organización o departamento se requiere su tiempo, pero alguien tiene que dar el primer paso, y verás como te alegras de ser tú el que lo ha dado.

Jim Highsmith. Su visión de la gestión de proyectos ágil

Para Jim Highsmith (traducción libre): «La gestión de proyectos ágil abarca tanto «hacer» y «ser» ágiles, siendo lo segundo lo más difícil».

Gestionar proyectos siguiendo metodologías ágiles no hace necesariamente ágil ni a quien gestiona, ni al equipo de proyecto, ni al proyecto, porque la agilidad no se consigue solo con metodologías porque la agilidad está por encima de ellas.

¿Qué pasa si tu contexto de trabajo no te permite aplicar metodologías ágiles?, ¿desenchufas y ya no aplicas un enfoque ágil? Incluso en las circunstancias más adversas para ser ágil existirán resquicios que te permitirán serlo (con mayor o menor trascendencia).

La gestión ágil debe empezar desde el mismo proceso de definición del proyecto, realizando las tareas que sean necesarias para evitar que desde su inicio sea considerado un Death March Project (en este tipo de contextos los árboles siempre impedirán ver el bosque y la presión y el exceso de carga de trabajo dificultará la creación de un clima donde el equipo de proyecto sea colaborativo y esté motivado) y para asegurarse que los stakeholders, sobre todo el área usuaria, tienen la implicación que requiere el proyecto (ellos tienen que definir la línea de desarrollo del producto, especificar los requisitos, indicar sus expectativas).

Si no se logran esos objetivos (y es posible que así sea porque generalmente podremos intentar influir pero el poder de decisión estará lejos de nosotros) seguimos teniendo el proyecto bajo nuestra responsabilidad y aunque las restricciones establecidas hagan daño al modelo de funcionamiento que nos gustaría implantar, no hay que tirar la toalla para la aplicación de enfoques ágiles, es más, nunca hay que tirarla.

Después la gestión ágil debe contextualizar los métodos de trabajo a la naturaleza del proyecto y del equipo de personas que van a participar en él y estar dispuesto a hacer los cambios necesarios para mejorar si fuera preciso y/o para adaptarse al cambio (para esto es fundamental que la estrategia de desarrollo utilizada y la calidad del software creen la menor resistencia posible).

Y tras eso, mucho más, porque la gestión ágil es un día a día con tu equipo (o equipos) de trabajo y el resto de personas o grupos de personas que intervienen de alguna u otra forma en el proyecto, de manera que se consolide una relación de confianza entre todos ellos (y dentro del equipo de proyecto), que el nivel de implicación de todas las partes se mantenga acorde a las necesidades del proyecto, que la comunicación entre todos sea fluida y que todos se sientan importantes.

Desarrollo de software. Hay que comunicarse

La comunicación es básica en los proyectos de desarrollo de software y no solo entre los miembros de un equipo (algo que es esencial) sino también entre los stakeholders.

Una vez que se consigue que la comunicación sea fluida (no es tan fácil ya que no solo depende de uno mismo) o por lo menos que exista cuando sea necesario es importante que de vez en cuando haya encuentros cara a cara (cuanto mayor sea la relación que se tenga que tener más frecuentes deberían ser esos encuentros).

Es cierto que el contexto en el que se desarrolla el proyecto condiciona mucho y si tu cliente está a 500 kilómetros o en otro país no es tan sencillo conseguir esa cercanía, lo cual no quita que se busque el mecanismo de comunicación que permita una mayor proximidad dentro de esas condiciones y en el que ambas partes se sientan cómodos.

Y es que la comunicación previene de muchos problemas y también permite resolver otros tantos. Cuando hay un malentendido, un conflicto o un desencuentro lo mejor es hablarlo y hacerlo cuanto antes. A veces, en función del carácter que tenga cada uno es interesante esperar un poco ya que a veces es mejor dar tiempo a reflexionar y ver las cosas desde otras perspectiva. Esperar un poco no es aguardar a que el problema desaparezca porque en este tipo de circunstancias suele quedar un poso que tarde o temprano termina saliendo afuera, sino hablar unas horas o unos días después.

Pero no es solo útil en este tipo de circunstancias, ya que permite armonizar las visión del conjunto sobre el proyecto, resolver dudas y lo más importante desarrollar y consolidar paulatinamente la relación de confianza.

Generalmente muchos problemas en los proyectos no vienen por un exceso en la comunicación sino por su defecto.

Brad Appleton. Confianza como factor clave en los proyectos

En la confianza se cimentan las relaciones personales, laborales y mercantiles.

Cuando un equipo de proyecto y los stakeholders construyen un ambiente de confianza disminuye la resistencia para conseguir el éxito, es la diferencia entre ir todos a una o encontrar personas o equipos que empujan en direcciones direcciones o sentidos.

Si dos principios del Manifiesto Ágil indican que se valora:

– A los individuos y su interacción, por encima de los procesos y las herramientas.
– La colaboración con el cliente, por encima de la negociación contractual.

La confianza resulta un ingrediente esencial para poder satisfacerlos.

No es condición suficiente la confianza para el éxito del proyecto pero es importante, tampoco es condición necesaria pero resulta poco probable que en este contexto el proyecto tenga un fin acorde a las expectativas.

La confianza no se gana de un día para otro, se requiere tiempo y mucho más que palabras. La confianza se basa en los hechos.

Sin embargo, la confianza se puede perder en un momento. Cuesta mucho ganarla, casi nada perderla.

Brad Appleton, director de ingeniería del software de Motorola, realiza una reflexión con la que estoy de acuerdo: «Lo primero que hay que construir es la confianza». O por lo menos empezar a construirla ya que, como decía, requerirá tiempo.

Desarrollo de software. El mantenimiento de sistemas de información con problemas

Un sistema con problemas tiene consigo a toda una multitud de personas (usuarios, directores usuarios, etc…) quejándose de manera sistemática y en muchos casos creando un ruido y una presión difíciles de soportar.

Trabajar de esta forma es complicado y todavía puede ser peor si las relaciones entre diferentes stakeholders se han deteriorado ya que alcanzar soluciones de consenso requerirán de mucho diálogo, debiéndose aceptar que no siempre se podrá conseguir ese consenso y que si la decisión o la solución que se ha ejecutado resulta poco acertada tocará soportar de nuevo una fuerte marejada aunque la decisión no la hayas tomado tú

En estas circunstancias siempre estarás en medio y ahí se vive y se trabaja mucho peor.

Si hay problemas incluso cuando has estado detrás del sistema desde el principio, los mismos se multiplican cuando el sistema que gestionas lo has heredado así.

¿Por qué? Pues porque tendrás que asumir un contexto que han creado otros y eso resulta complicado de digerir, es decir, nos sentimos motivados para arreglar problemas en los que hemos estado involucrados (independientemente de nuestro grado de responsabilidad en la deriva final del sistema) pero mucho menos cuando estos directamente se nos han puesto encima de la mesa.

El principal motivo es que tendremos que trabajar con restricciones técnicas en las que probablemente no creemos y generalmente nuestros recursos presupuestarios serán muy inferiores a los invertidos en el proceso de desarrollo.

Es cierto que no es plato de buen gusto trabajar en estas circunstancias pero os puedo asegurar que como contraprestación a lo mal que se pasa y a la cantidad de horas que hay que echarle, está lo que se aprende en este tipo de proyectos.

La experiencia no es lineal en relación al tiempo que llevas trabajado, este tipo de proyectos es un claro ejemplo de ello.

Desarrollo de software. La agilidad y la resistencia

No se pueden entender desarrollos ágiles si no se disminuye la resistencia hasta unos umbrales mínimos aceptables.

¿Qué es la resistencia? Toda aquella actividad que dificulta el progreso del proyecto y esto se extiende desde el propio proceso de desarrollo (incluida la implantación del sistema en sus diversas iteraciones) hasta el conjunto de stakeholders que intervienen en el mismo, pudiendo incluso trascender a lo que es el propio proyecto: tanto en aspectos de políticas y normas como en aspectos de infraestructura (estabilidad de la aplicación, del CPD en el que se encuentra, etc…).

No entiendo como resistencia actividades propias del proceso de desarrollo independientemente de que no tengan influencia directa sobre el producto. Habrá quienes piensen que lo que no tenga influencia directa en el desarrollo se considere resistencia en todos los casos y lo respeto y hasta puedo llegar a estar de acuerdo, no obstante hay que entender que habrá tareas que son necesarias de realizar con el objeto, por ejemplo, de cumplir con los procesos establecidos en la organización, pero, ¿dónde está la frontera entre lo que es resistencia y no lo es? cuando se pierde la visión de los principios ágiles.

Es muy difícil encontrar un contexto de trabajo sin resistencia, por lo que será algo con lo que tendremos que convivir. Ahora bien, No se puede hacer un desarrollo ágil si se superan unos ciertos límites. Claro que podrás aplicar metodologías, tácticas o actitudes ágiles pero otra es que las puedas aplicar en condiciones y sean realmente efectivas.

Desarrollo de software. Antipatrón. Interbloqueo

Nos encontramos ante un antipatrón que también se suele producir con frecuencia y que provoca retrasos y otro tipo de problemas en los proyectos.

El interbloqueo ya sea directo o indirecto es consecuencia principalmente de una mala comunicación en el proyecto, también lo puede ser de una mala planificación (pero no necesariamente una planificación inadecuada tiene por qué provocar interbloqueos, pudiéndose producir también este tipo de situaciones sin que existan este tipo de problemas).

Eso de que yo no puedo continuar porque estoy esperando a que tú hagas algo, mientras que tú no puedes hacerlo porque estás esperando a que yo haga otra cosa, desgraciadamente está a la orden del día y lo peor de todo es que la solución en la mayoría de los casos, es sencilla: comunicación.

Cuántos problemas se ahorrarían muchísimos proyectos si la comunicación dentro del equipo de proyecto o entre stakeholders fuera fluida.

No es casualidad que el primer principio del manifiesto ágil indique que se valore «a los individuos y su interacción, por encima de los procesos y las herramientas.»

Lo que suele pasar es que cuando en un proyecto empieza a existir desgaste uno de los primeros elementos en resentirse es la comunicación, lo cual generará más problemas y más desgaste, haciendo la bola de nieve cada vez más grande.

Desarrollo de software. Antipatrón. Abracadabra

Nos encontraríamos ante una situación concreta del antipatrón «responsable ausente«. En este caso, el gestor a modo de sortilegio establece una líneas generales para el desarrollo del proyecto y desaparece, apareciendo solo cuando existen problemas en el proyecto y generalmente como reacción ante las quejas de uno o más stakeholders (antipatrón «gestión dirigida por disparos«).

Nadie es imprescindible, pero si cada uno desempeña su rol en el proyecto de manera adecuada existirán más posibilidades de que todo salga bien.

Desarrollo de software. Antipatrón. Con la mitad es suficiente

Nos encontramos con este antipatrón cuando ante un sistema de información de complejidad y tamaño medio/alto, con una deuda técnica alta, se solicita la realización de tareas de mantenimiento, generalmente evolutivo, de cierta envergadura, las cuáles deberían ejecutarse en un plazo de tiempo muy ajustado y se centran los esfuerzos en intentar conseguir ese objetivo, independientemente de que el producto vea incrementada su deuda técnica y complejidad.

El primer problema que nos encontramos es la existencia de una restricción temporal que condiciona los trabajos, lo que hace que se enfoquen los esfuerzos en «apagar el incendio», dejando de lado la aplicación de determinadas buenas prácticas y controles de calidad del software si estos pudieran frenar el avance de la ejecución de las tareas.

Esto hace que el plan de proyecto se centre en dar una respuesta a la situación, dejando para el final la realización de tareas que mitiguen la deuda técnica y la simplificación de funcionalidades eliminando funcionalidades o código que no ya no tienen utilidad (ver antipatrones lava seca y ancla de barco). ¿Qué es lo que suele pasar? Pues que al final no haya tiempo para realizar esos ajustes, ya sea porque nos hemos quedado sin presupuesto y/o aparecen nuevos fuegos que ir mitigando.

Esa restricción temporal puede estar justificada ante la necesidad de adaptar un sistema de información a una normativa o para adaptar el sistema a un cambio en procesos o a un nuevo proceso que resultan esenciales para el funcionamiento de la organización y que de no estar en los plazos fijados podría suponer un importante perjuicio económico que podría incluso afectar seriamente no solo a los balances, sino incluso a la propia viabilidad de la compañía.

Otras veces la restricción temporal, pese a que pueda estar sustentada por ciertos criterios objetivos, no deja de ser un capricho de cierto personal directivo a los que un día en un «alarde de creatividad» deciden que es necesario realizar ajustes en un sistema o incluirle nuevos módulos.

El siguiente problema es la realización de cambios de cierta magnitud en un sistema con una deuda técnica elevada, que implican que cualquier tarea de desarrollo sobre el mismo (sobre todo aquellas que supongan modificaciones en módulos ya implementados) cueste muchísimo más esfuerzo (como correr con un vendaval de viento en contra, con carga en una mochila y con pegamento en la suela de las zapatillas), además de incrementarse la probabilidad de errores, tanto por posibles efectos colaterales como por la presión de ejecutar trabajo rápidamente, dejando de lado la realización de determinadas prácticas de aseguramiento de la calidad del software.

Al final, en el caso de que cumplamos el hito temporal (algo que en aquellos casos donde los plazos sean muy ajustados solo será posible priorizando tareas, teniendo a todos los stakeholders muy implicados y acertando mucho), tendremos un producto más complejo, más costoso de mantener (si cabe) y bastante más inestable.

Desarrollo de software. Antipatrón. No es mi trabajo

No es mi trabajo, no es mi problema, no es asunto mío, ha sido otro, etc… es otro antipatrón muy frecuente, propio de organizaciones o equipos de trabajo donde no existe una visión del colectivo y donde cada cual vela única y exclusivamente por sus intereses.

De todas formas, es conveniente hacer algunas matizaciones:

– Cuando se hereda un trabajo que proviene de otro o de otros, dentro o fuera de la organización, recomiendo que se realice siempre un análisis objetivo del mismo y se exponga a todos los implicados en el proyecto, de manera que se alineen las expectativas de los stakeholders con la realidad del proyecto (esto no es sencillo porque lo mismo las expectativas que tenían eran muy superiores al estado real de los trabajos (antipatrón «Humo y espejos«) y y tal vez seas un recién llegado al que no conocen).

¿Qué no te creen? Tu ya has hecho lo que tenías que hacer, has establecido un punto de partida y a partir de ahí tienes que seguir trabajando, ¿qué siguen teniendo las expectativas que tenían antes? pues el problema en este caso lo tienen ellos. Por supuesto que te salpicará a ti, pero peor sería no haber avisado y seguir con el mismo discurso hasta al final (antipatrón «El traje nuevo del emperador«).

En conclusión, no estás diciendo que este no sea tu trabajo, sino que estás haciendo ver que este es el estado de lo que me encuentro y a partir de ahí empieza mi labor que pretenderá conseguir los objetivos marcados pero modulados y condicionados por la herencia recibida (estamos para intentar conseguir resultados pero no para hacer milagros).

– Tiene una cierta relación con la matización anterior. Salvo que entiendas que por alguna circunstancia debas hacerlo, no tienes por qué aceptar cargar con responsabilidades que no te corresponden, salvo aquellas que sean motivadas por personas a tu cargo, donde sí que es importante que, salvo actos de evidente negligencia o indisciplina, se de la cara por quienes trabajan contigo, con los que hay que estar para lo bueno y para lo malo y con los que hay que lavar los trapos sucios siempre en casa.

Fuera de estas dos matizaciones, en el ámbito de una organización o de un equipo de proyecto hay que esperar un ambiente colaborativo (en el ámbito organizativo donde se premia la depredación en lugar del win-win entre los empleados, resulta un tanto utópico), a veces podrás echar una mano, en otras ocasiones involucrarte realmente en otra tarea (sería conveniente comunicárselo a tu responsable) y otras veces no podrás, pero por lo menos hay que estar abierto a poder ayudar si es posible, aunque eso suponga hacer tareas que entiendas que no te corresponden, ya sea por encima (siendo programador participando en ciertas tareas de análisis o diseño) o por debajo (siendo programador, colaborando en la carga inicial de datos del sistema).