archivo

Archivo de la etiqueta: comunicación

Abrir la mente es fundamental, no basta solo con poner los oídos sino que hay que estar dispuesto a escuchar y a poner en tela de juicio tus opiniones y tu punto de vista sobre los temas que se están tratando. Si de entrada crees que tienes la razón, la solución o la respuesta y que los demás, digan lo que digan, no la tienen, no hay forma de poder enriquecerse con las aportaciones que te hagan.

Si todo el equipo tuviera esa actitud solo quedaría como salida el “ordeno y mando” y eso limita mucho su capacidad porque se desaprovecha el talento individual y el colectivo y no se crea el contexto necesario para tener un equipo de proyecto dinámico y colaborativo en el que todos se sientan importantes, algo fundamental para un desarrollo ágil y generalizando, para cualquier enfoque que se vaya a utilizar.

Eso de considerar que mis ideas o mi código son los mejores son una resistencia al proyecto y no por el hecho de serlo, sino por la actitud que se toma con respecto a ellas ya que si se consideran como la verdad absoluta pueden provocar el descarte o minusvaloración del trabajo, apreciaciones, visiones u opiniones de otros componentes del equipo de trabajo y/o de otras personas que colaboran en el proyecto.

Cuando se elabora una documentación, como por ejemplo un catálogo de requisitos o una historia de usuario, se parte de una persona o grupo de personas que comunican en ese instante su visión del producto, de una funcionalidad o de una característica (se trata de una concepción abstracta por lo que ahí ya hay una diferencia entre lo que realmente necesitan y en lo que creen que necesitan), esa visión es transcrita por una persona o por un grupo de personas desde la interpretación que hacen de las mismas (por lo que también se pierde información), teniendo en cuenta que en el propio proceso de pasar esas ideas a lenguaje escrito también se pierden matices.

Esa documentación posteriormente es interpretada por las personas que la leen, por lo que, si nos ponemos a analizar, hay una diferencia (en unos casos más sensible que en otros) entre lo que se quiere y lo que se interpreta finalmente, y el documento, aunque deja constancia por escrito del trabajo que hay que realizar, es un elemento que introduce ruido sobre el objetivo final.

Por tanto, el documento no debe sustituir a la comunicación, sino que es en todo caso un instrumento en el que debe apoyarse la misma. Es un error pretender que los documentos sustituyan a la relación entre las personas porque de ser así, perdemos información, perdemos precisión y existirá desviaciones entre lo que se quiere y lo que se obtiene finalmente.

Todavía más duro resulta en contextos cambiantes o en productos que por sus características o complejidad requieran un feedback continuo del usuario, ya que resulta complicado dar una respuesta adecuada si tenemos que estar trabajando exclusivamente con pesados documentos que van de aquí para allá.

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

Sea cual sea el enfoque, estrategia o metodología que apliques en un proyecto, van a aparecer riesgos o problemas que pueden afectar en mayor o menor medida al proyecto y al cumplimiento de los compromisos y expectativas y que no deberíamos ignorar, en unos casos porque su materialización puede poner todo patas arriba y en otros porque una vez materializados suponen una resistencia importante en el propio proceso de desarrollo.

La gestión de riesgos en los enfoques ágiles está implícita en la propia dinámica de trabajo y en las prácticas que se vienen a aplicar. Esto no quiere decir que sea menos importante o que se le dedique menor atención, solo que ya se entiende, de base, que es necesario trabajar en ello.

Es importante tener en cuenta que se presta principal atención a los impedimentos o resistencias que son contingencias u obstáculos que bloquean o afectan a la velocidad real del equipo, lo cual no quiere decir que se ignoren riesgos a más alto nivel.

En un enfoque ágil de desarrollo se debe tratar que los problemas, resistencias y errores salgan a la luz lo antes posible porque se entiende que cuanto más cerca de su origen se aplique de manera efectiva cada solución, menos daño provocará al proyecto al ser menor su impacto en el producto y en las personas (si no se hace por eliminar o paliar determinadas resistencias, afectará al ánimo y moral de las mismas, agudizando el efecto que sobre la productividad provocan esos impedimentos) y, por tanto, menor el esfuerzo que se necesitaría para volver de nuevo a una situación de equilibrio.

Un ejemplo de ello lo tenemos en las reuniones diarias o Daily Scrum en las que cada participante, además de indicar lo que hizo la jornada anterior y lo que pretende realizar en esta, comenta qué impedimientos, obstáculos, resistencias o problemas se están encontrando en la realización de sus tareas. Se habla de ello para poner estas contingencias encima de la mesa con el objeto de que se le proporcione una solución que lo mismo puede ser inmediata o requiere de tareas (o incluso sprints específicos) para abordarlas.

No olvidemos que la comunicación entre las personas ni empieza ni termina con el Daily Scrum, por lo que aplicando los principios de transparencia que deben regir en un proyecto ágil, en cualquier momento se puede y se debe levantar la mano para comunicar un riesgo o un problema que puede afectar al desarrollo.

En cualquier caso, tenemos otro punto de sincronización en las retrospectivas, en las que se analiza en qué aspectos se puede mejorar y cómo y qué resultado están dando las medidas aplicadas hasta ahora para tratar otros puntos de mejora detectados en sprints anteriores. Este es otro punto donde se puede y se deben discutir sobre todo aquello que afecte a lo que sería un normal desarrollo del proyecto.

Estas resistencias, se pueden inventariar en una pila de impedimentos o Impediment Backlog con el objetivo de hacerlas visibles y poder hacer un seguimiento de las mismas.

Esas medidas más concretas, que mencionaba en el artículo de ayer, irán orientadas principalmente:

– A reducir la incertidumbre: Definición de políticas por parte del Departamento de Sistemas, consensuadas con el Departamento de Desarrollo que pueden ir orientadas a definir un “catálogo de sistemas base”, es decir: estos son los servidores de aplicaciones con tal versiones, estos los de bases de datos, este el gestor documental, etc…, una serie de condiciones con respecto a la entrega de las versiones (instalación en entornos previos lo más parecidos posibles al de producción y verificación de su correcto funcionamiento), etc…, y la participación de personal de Sistemas en el proyecto, con más intensidad en la fase en la que se defina el entorno tecnológico, etc…

– A mejorar la coordinación: Que ambos departamentos tengan información actualizada sobre las operaciones, eventos y entregas que puedan afectar al otro, consensuar soluciones o prioridades en el caso de que se prevean períodos de importante carga de trabajo, establecer estrategias para gestionar el WIP (Work in Progress) como puede ser la aplicación de Kanban que pueden resultar de utilidad para detectar cuellos de botella o para realizar ajustes en los equipos de trabajo, etc…

– A reducir las actividades mecánicas en el proceso de entrega e instalación de manera que tanto desarrollo como sistemas puedan dedicarse a las actividades realmente importantes: ¿para qué realizar instalaciones o ejecutar scripts a mano si se puede automatizar?. Esto al principio choca, porque para muchos supone un cambio de paradigma, sin embargo, si se establecen una serie de medidas para reducir la incertidumbre y se demuestra que el modelo funciona y es el adecuado para un conjunto de sistemas (aunque se empiecen con determinados sistemas piloto), terminará por asentarse porque es productivo, disminuye errores humanos y lo que decía antes, se puede invertir más tiempo en otro tipo de actividades donde se requiere un mayor esfuerzo intelectual.

Todo ello sin olvidar que los más importante, al final, son las personas.

Es cierto que un modelo organizativo más ordenado y racional ayuda y que las personas pueden crear puentes y dar soluciones ante situaciones de bloqueo, pero sigue siendo necesario dar un paso más que permita agilizar todo ese proceso de entrega y paso a producción reduciendo o eliminando esos cuellos de botella que sin duda aparecerán y que además, permitan resolver problemáticas concretas de determinadas aplicaciones que requieran de manera puntual o continua que sus cambios lleguen a producción cuando se necesita (que no es ni pronto, ni tarde).

Ese paso más supone nuevos cambios, algunos de los cuales suponen una transformación de los métodos o procedimientos utilizados hasta ahora. Es normal que cuando se propongan, sean tomados con cautela y que incluso provoquen rechazo porque es muy posible que no se terminen de entender los motivos y/o que no se alineen con las políticas del departamento (o con la visión de cómo deben hacerse las cosas que tenga el responsable correspondiente).

Por eso comentaba la importancia de sentar primero unas bases: primero la intención de un cambio, unas personas dispuestas a modificar el modelo actual, unos objetivos a nivel de la organización (y del departamento TIC a menor escala) y la necesidad de un mejora continua, y a partir de ahí definir medidas más concretas aplicadas paulatinamente en proyectos reales para medir sobre los mismos su efectividad. Es ahí donde se empezarán a despejar dudas y a eliminar resistencias porque si la solución adoptada es buena probablemente dejará satisfechos a todos.