archivo

Archivo de la etiqueta: arrojar al otro lado del muro

Todas las medidas que supongan un obstáculo a la comunicación entre los componentes de un equipo de trabajo o entre equipos de trabajo diferentes suponen una resistencia importante al proyecto de desarrollo de software.

Se pueden establecer ciertas reglas orientadas a conseguir un mayor orden y una comunicación más eficiente pero es necesario evitar todas aquellas que creen entre personas y equipos que den lugar a que la comunicación sea mayoritariamente asíncrona (cuando no prácticamente inexistente) provocando un distanciamiento entre los equipos (no se trata de un hecho físico ya que pueden estar distanciados equipos que incluso trabajan en la misma sala), la aparición de antipatrones como: “Arrojar al otro lado del muro y que las funcionalidades se desarrollen o las decisiones se tomen sin contar con toda la información disponible lo que dará lugar a unos mayores costes debido al más que probable incremento del número de iteraciones necesarias para tener el producto.

A veces la comunicación se deteriora por conflictos entre personas o entre equipos que provocan que como medida de autodefensa se pongan como un escudo que dificulta o impide la comunicación. Por el bien del proyecto y de las personas que participan en él este tipo de situaciones hay que atajarlas cuanto antes y no dejarlas ir porque cuando se entra en enfrentamientos personales los mismos no terminan por arte de magia cuando acaba el proyecto.

También los gestores cuando no tienen una visión global tienen mucha que ver con el aislamiento de los equipos de trabajo.

Frederick Brooks en su libro “The Mythical Man Month” comenta lo siguiente: “Entonces, ¿cómo se comunicarán los equipos unos con otros? De tantas formas como sea posible”.

Cuando trabajamos desde una actitud ágil aplicando prácticas, estrategias o metodologías ágiles, tendemos a centrarnos en el incremento del valor del producto, sin olvidarnos de tener una deuda técnica sostenible, mientras solemos dejar de lado algunas tareas de gestión que llegado el momento nos pueden ahorrar algún problema.

Partamos de la base de que la agilidad funciona en un marco de trabajo en el que existe confianza entre las partes, cuanto mayor sea la separación entre las personas y los equipos más dominará la metodología y la burocracia y menos la agilidad (antipatrónarrojar al otro lado del muro“), sin embargo a veces en los proyectos intervienen factores externos que terminan por afectar a su desarrollo normal produciéndose problemas.

Por ejemplo, una de las partes cambia sensiblemente su posición en el proyecto exigiendo alcances o incrementos de presupuesto, siendo la situación del proyecto tal que no es posible alcanzar un acuerdo sin que alguna de las partes ceda de manera considerable.

En esos momentos, por muy buena voluntad que sigamos teniendo los que estamos en las trincheras tanto por parte del cliente y del proveedor, el partido se suele jugar en otras instancias, las cuales empiezan a solicitar a los equipos evidencias para tratar de utilizarlas en el proceso de negociación (o confrontación), evidencias que no irán más allá en muchos casos que el contenido de la pila de producto o de los sprints, lo que será insuficiente y luego se empezarán a pedir explicaciones por determinados tipos de acuerdos verbales que no se han registrado por escrito.

¿Cuál es la solución? Puedes optar por aplicar una táctica defensiva en todos los proyectos o realizar ajustes en función del mismo. La táctica defensiva consiste en tratar de registrar documentalmente todos los acuerdos parciales en el proyecto sin salirnos de la línea base del acuerdo inicial, esto puede servir como coraza (aunque quien quiera liarla, la liará con esto y sin esto).

Una táctica que considero más adecuada al desarrollo ágil consiste en analizar realmente qué tipo de proyecto estamos realizando, qué exigencias tiene nuestra organización y cuál es nuestra experiencia con el proveedor o con el cliente y a partir de ahí tomar tus propias decisiones sobre qué debe tener evidencia documental y que no (además de estas evidencias la propia metodología o procesos de las organizaciones pueden imponer otras, que tendrás que seguir quieras o no).

Si un proyecto puede presentar problemas presupuestarios cuando se prevé un alcance y una complejidad mayor que cuando se hizo su estimación económica, la solución debería pasar, no por intentar meter todas las funcionalidades con calzador, sino por tratar de buscar una solución más racional que permita obtener un producto que satisfaga las prioridades que se han establecido con un alto nivel de calidad, aunque esto implique dejar fuera o para más adelante (en muchos casos es necesario gestionar con los responsables funcionales el síndrome de la última versión), otra serie de funcionalidades que pueden resultar interesantes.

El primer paso debería consistir en dividir el proyecto en diferentes entregas, siendo conscientes todas las partes de que el desarrollo será iterativo incremental porque del feedback de cada versión vendrán, muy probablemente, solicitudes de mejora por parte del área usuaria.

Si se trata hacer todo de golpe se correrá el riesgo de que se agote el presupuesto y que en medio del proceso de desarrollo se entre en un conflicto entre las partes sobre cuál será el alcance final.

La experiencia dice que por muy buen acuerdo que se alcance se verá afectada la calidad del software porque el proveedor tratará de minimizar pérdidas, porque los desarrolladores tendrán overtime y llegado a un punto el cansancio y las ganas de terminar darán lugar a precipitación que se traduce en deuda técnica y en un producto menos probado.

Por otro lado, el cliente tendrá una mayor desconfianza y la comunicación entre las partes, tan necesaria en un proyecto de desarrollo de software, perderá fluidez y en función del grado de desgaste en las relaciones podría dar lugar a situaciones del antipatrón “arrojar al otro lado del muro“.

También se puede agotar el presupuesto con el enfoque iterativo incremental, la diferencia está en que al reestructurar el proyecto de esta manera todas las partes conocen las reglas del juego: se trabaja así no solo porque sea el enfoque que mejor pueda convenir al proyecto sino porque permite gestionar de manera adecuada las prioridades, el seguimiento y consumo económico del proyecto.

El siguiente paso consiste en trabajar con pila de producto e historias de usuario. Los responsables funcionales priorizan estas historias que una vez tasadas y ajustadas a la capacidad del sprint, se convierten en lo que será el resultado final de la entrega.

Si no lo ves claro (y también si lo ves claro), no dudes en dividir el proyecto en partes y cada parte en componentes o trabajos más simples (historias de usuario). Será más manejable, te beneficiarás el feedback y la gestión económica será mucho más transparente y mejor entendida entre las partes.

Comenta Jeff Patton que: “No necesitamos una documentación precisa, sino un conocimiento compartido”.

Esa reflexión no descarta la documentación si bien no le da el monopolio sobre el conocimiento porque la documentación es eminentemente estática y el conocimiento es dinámico, porque la documentación presenta como límite la habilidad del redactor y la comprensión del lector y el conocimiento se basa más en la comunicación y en la interacción, si algo no lo he entendido lo consulto, si en algo no estoy de acuerdo trato de fundamentar otra posible solución (sin menospreciar la base teórica o informativa de los documentos escritos).

Los documentos se pueden utilizar como interfaz entre diferentes grupos de trabajo (siempre y cuando sus actividades no requieran una interacción continua o frecuente o la misma no sea posible, independientemente de que sea deseable), sin embargo, no se debe cometer el error de restringirlo como único canal de comunicación, precisamente por el hecho de que resulta prácticamente imposible que toda la información se haya plasmado adecuadamente y que el propio lector consiga interpretarlo con la misma intención que la persona que lo redactó (todos sabemos que existen tantas percepciones o visiones sobre un determinado asunto como observadores haya).

Por mucho tiempo que se dedique a la redacción del documento, siempre se va a perder información y se van a alimentar los malos entendidos. Cuando se requiere la colaboración continua entre personas o entre equipos, este modelo no funciona.

No hace mucho un amigo me hizo referencia a un proyecto de hace ya algunos años en el que la comunicación entre usuarios y desarrolladores se basaba principalmente en documentos (también existía diálogo, pero la pieza fundamental, eran encuestas, formularios, etc…), ¿podéis imaginaros cuál fue el resultado del proyecto?.

Por otro lado si la interfaz se basa en documentos, se alimenta la distancia entre los equipos, propiciando la aparición del antipatrón “arrojar al otro lado del muro“, en el que el proyecto queda en segundo plano, ante la actitud defensiva que toman los diversos implicados.

Puedes trabajar con factorías de software siguiendo el modelo que más pueda convenir: Offshore, Nearshore, Onshore y conforme exista más distancia entre los equipos que tratan las especificaciones y el equipo que las desarrolla más mecánico se convierte el trabajo del equipo de programadores: “toma las especificaciones, te las modelo y desarrolla según la arquitectura y framework pactado”.

Es posible que esa distancia la puedan reducir los equipos de trabajo aplicando distintos tipos de técnicas y herramientas porque como he dicho en otras ocasiones el impacto de la distancia depende mucho de la actitud de todas las partes. Sin embargo cuando por encima de los técnicos, hay jefes de proyecto o gerentes “contables” la actitud (si existe) queda difuminada y se entra en un peligroso modelo de trabajo basado en el antipatrón “arrojar al otro lado del muro”.

Como bien dice un amigo, no hacen falta factorías de software para caer en ese antipatrón, te puede pasar perfectamente con el proveedor incluso compartiendo oficina.

En el momento en que se entra en ese juego la programación desgraciadamente se convierte en una actividad mecánica: el programador se limita a ejecutar tareas, conociendo solo el sistema que se desarrolla a bajo nivel. Con esto perdemos el feedback del programador tanto a nivel técnico: tal vez sean recomendables ciertos cambios en la arquitectura o el framework para adaptarlos mejor a la naturaleza del software que se desarrolla, como funcional: Esto no termina de ser coherente con otros módulos del sistema y es necesario que las especificiones sean más claras o que se estudie esa falta de consistencia con el usuario.

En un proyecto todos suman, los programadores por supuesto también (y mucho). Todas las personas que están en el proyecto están capacitadas para aportar ideas y soluciones, tengan el rol que tengan, a veces estarán acertadas y otras se equivocarán pero lo que no podemos hacer es dejar de escuchar sus opiniones porque estaremos despreciando toda la capacidad y talento de los componentes de nuestro equipo.

Una condición necesaria para conseguir el éxito en un proyecto es crear un equipo. No te centres solo en el equipo de desarrollo sino en el conjunto de equipos que participan activamente en el proyecto.

Si ya es difícil a un grupo de personas hacerlas funcionar como equipo, hacer que diversos grupos con distintos intereses, con diferentes objetivos y que pueden ser incluso de varias organizaciones funcionen como un equipo, es un auténtico reto. Reto que, por supuesto, merece la pena porque de lo contrario el proyecto estará en peligro.

La situación de partida suele ser que cada equipo es como una ciudad estado, con sus muros gigantescos y con sus propias leyes. En algunos casos estarán organizados y en otros reinará el caos (con toda la escala de grises entre un extremo y otro). Este ecosistema es un caldo de cultivo óptimo para el antipatrón “arrojar al otro lado del muro“, ya que cada cual se centrará en su parte concreta del proyecto, olvidándose de que todos dependen del trabajo de los demás. En este contexto la comunicación entre los equipos es poco fluida y generalmente muy procedimentada, lo que pondrá una resistencia importante a la interacción entre las personas y no solo eso, la actitud de los equipos será defensiva, algo que suele tener como efecto que los muros sean cada vez más grandes.

He descrito un panorama extremo, es cierto, porque todos los equipos no tienen por qué tener de partida un comportamiento de ese tipo, pero también resulta algo poco real pensar que de partida todos los equipos van a estar funcionando como uno.

Para tratar de tirar o reducir el tamaño de esos muros es muy importante la tarea de alinear los equipos al objetivo del proyecto, enfocarlos, hacerles entender que su esfuerzo es esencial para sacarlo adelante y que solo se conseguirá el éxito si todos los equipos tienen éxito en la parte del proyecto en la que le toca trabajar.

Esto no se consigue con una charla, se consigue conversando mucho, escuchando más y promoviendo que los trabajos de los equipos sean abiertos, de manera que todos tengan la oportunidad de conocer qué se está haciendo. De esta forma se reducirá la complejidad de la integración resultados ya que se detectarán problemas más temprano y por otro, que se tenga una visión global de los trabajos lo que facilitará el entendimiento de que o todos colaboran o esto no tendrá éxito.

No es sencillo que los equipos se abran a otros, sobre todo si son de organizaciones distintas, para facilitar esto es necesario que la apertura sea bidireccional y en las mismas condiciones, por otro lado hay que estar muy atento para atajar cuanto antes los conflictos que puedan acontecer.

Hay que evitar tener favoritos y tener un trato justo con los equipos. Es posible que un equipo esté desarrollando la parte más crítica del sistema y es posible que eso haga que le dediques mayor atención. Eso es algo lógico y no expresa favoritismo, sino sentido común. El trato justo se mide cuanto ante circunstancias similares tu comportamiento es el mismo con un equipo que con otro y cuando respetas de la misma manera el trabajo, siempre y cuando el mismo merezca ese respeto.

Mantener el equilibrio es complicado porque en el proyecto pasan muchas cosas. Habrá pasos adelante y pasos atrás, siendo estos últimos más largos generalmente que los primeros porque esto de trabajar en equipo funciona si hay confianza y la confianza cuesta mucho conseguirla y es muy sencilla de perder.

Al final, uno puede intentar todo lo posible porque todos los equipos trabajen como uno, para reducir distancias, para ayudar en la resolución de problemas pero sin la voluntad por parte de los mismos y/o sus organizaciones no será posible. Se puede estar un tiempo con el viento en contra, con un equipo o varios equipos que no quieren adaptarse a este esquema de funcionamiento, pero no todo el proyecto, porque habrá quien, con razón, termine por no aguantar esta situación.

Tenemos que estar centrado en nuestro trabajo, proyectos y tareas. No se trata de no colaborar, sino de hacerlo cuando se solicita, existe un acuerdo o nos hemos enterado de una información que sabemos que puede ser de utilidad para otros compañeros y proyectos.

Otra situación en la que podemos ayudar es aquella en la que escuchamos una conversación (no estamos encerrados en un búnker) y nos percatamos de una decisión o una información que es errónea o de un enfoque que podría ser mejorable. En estos casos hay que elegir de manera adecuada la persona y el momento en el que se va a realizar la matización o corrección, interrumpir puede ser molesto o no deseable por las personas que están hablando.

Este antipatrón surge cuando por alguna circunstancia nos enteramos de una decisión o de una información incorrecta que no nos atañe directamente y no informamos, de la manera adecuada, al tercero o terceros implicados. Esta situación se puede producir entre personas que trabajan en proyectos distintos e incluso dentro de un mismo proyecto, con la famosa excusa del “ese no es mi problema” o “ese no es mi trabajo”.

Este problema suele ser colateral en entornos en los que se ha consolidado el antipatrón: “arrojar al otro lado del muro“, si bien puede producirse, perfectamente, sin él.

De producirse este antipatrón, da lugar a la materialización de una decisión errónea que, en función de su naturaleza, podría tener un impacto económico importante a nivel de proyecto y/o de organización. Además, viene a demostrar, en el caso de que no sean hechos aislados, de que hay un problema importante entre personas o equipos de trabajo que debe ser atajado cuanto antes.