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.

Este marco de trabajo, basado en la colaboración efectiva entre equipos distintos, en los que sobre unos procesos que establecen unas reglas generales del juego, se encuentran una serie de personas que se comunican, interactúan y llegan a acuerdos para llegar a cumplir una serie de objetivos comunes, hace que se asocie DevOps a la aplicación de agile más allá del proceso de desarrollo.

Pero no es solo eso, sería muy simple dejarlo en eso, va más allá, porque agile ya preveía desde el manifiesto ágil la colaboración entre equipos. En este caso se trata de aplicar sus fundamentos para acercar esos departamentos que tienden a funcionar por separado, a romper esas barreras culturales y conseguir que trabajen de manera conjunta para servir a unos objetivos generales.

Desde el punto de vista operativo, la solución no es simple porque se parte una situación muy heterogénea: múltiples proyectos que se encuentran en diferentes momentos de su desarrollo y/o de su ciclo de vida, desarrollados además con diferentes enfoques, con diferentes tecnologías, cada uno con sus propias prioridades que varían a lo largo del tiempo, unos con muchos problemas, otros con menos, unos con unas fechas de entrega rígidas, otros más flexibles, etc… y todos ellos llegan a una misma puerta de entrada: departamento de sistemas, el cual además, realiza operaciones relacionadas con el mantenimiento de la infraestructura, de la seguridad y de las comunicaciones, tanto a nivel físico como lógico y que cuenta con unos medios limitados tanto personales como materiales.

Es complicado enfocar las culpas hacia una de las partes, por lo menos en términos generales, ya que cuando se producen problemas en los puntos de integración entre diferentes departamentos es síntoma de que lo que está fallando es el sistema. Esto no quita que existan problemas adicionales, como el hecho de que además de lo anterior, existan personas que se muestren intransigentes y no vean más allá del límite, no ya de su propio departamento, sino de su propio yo.

La solución al problema no es simple pero para empezar es fundamental tener perfectamente definidos y que sean bien conocidos por todos, los objetivos del Departamento TIC, establecer un modelo de mejora continua que tenga como finalidad que la evolución, prioridades y actuaciones de los diferentes departamentos atiendan a esos objetivos, que su interacción sea efectiva, que la información fluya en el momento adecuado a todos los que deberían ser conocedores de la misma y que se fomente la colaboración y cooperación entre todos los implicados.

A lo anterior hay que sumar mecanismos que permitan prever y si no es posible, arbitrar, situaciones de conflicto minimizando el impacto de las mismas en las actuaciones implicadas.

Pero por encima de todo lo anterior, es fundamental que las personas entiendan que hay que mirar hacia la organización y no exclusivamente hacia dentro de su departamento (o a más bajo nivel hacia sus proyectos o hacia los sistemas que administran), porque lo segundo sin lo primero ni existiría ni tendría razón de ser.

De esta forma, no podemos dejar la solución en mano de los procesos y procedimientos porque al final son las personas las que los hacen buenos o malos, sobre todo teniendo en cuenta que lo que se pretende es romper barreras culturales entre los integrantes de ambos departamentos, barreras que se repiten organización tras organización.

Realmente, no se trata exclusivamente de un problema de predecibilidad o de que ambas partes no se hayan tenido en cuenta a la hora de programar sus tareas (que lo es), sino que hay, además, un aspecto importante que hay que tener en cuenta y es que cada paso a producción genera incertidumbre.

Una nueva versión con problemas puede afectar no solo a su conjunto de usuarios, sino que puede comprometer la disponibilidad o el rendimiento de otros sistemas con los que comparte infraestructura o incluso afectar a la seguridad.

No ayuda el hecho de que los desarrolladores tengamos malas prácticas, no probemos los productos lo suficientemente o no nos preocupemos por el impacto que tienen nuestros desarrollos sobre la infraestructura de sistemas (“¿optimizar?, ¿para qué si la “chapa” es barata?”).

Podemos luchar contra esa incertidumbre, pero no podemos luchar contra la aparición de nuevas versiones ni con la ventaja competitiva (o de ahorro de costes) que tiene liberar y poner en producción una nueva versión a tiempo, porque lo que es seguro es que nos movemos en un contexto donde el cambio es inevitable y necesario.

Por esta razón, los Departamentos de Sistemas no pueden convertir el proceso de aceptación de las aplicaciones en algo lento, farragoso y con continua devolución de versiones a desarrollo por el incumplimiento de ciertas normas que no aportan valor a nadie.