archivo

Archivo de la etiqueta: comunicación

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.

Por ejemplo, supongamos que un departamento de la organización necesita poner en producción en un plazo de una semana una determinada versión de un sistema. Supongamos también que ha sido validada funcionalmente y que se han realizado tareas de testing que no ha encontrado defectos que aconsejen su corrección antes de su puesta en marcha.

Y resulta que el departamento de sistemas tiene programada esa semana una serie de actuaciones de mantenimiento que provoca que buena parte del equipo esté ocupada de las mismas, y además, exigen que la entrega de la versión cumplan una serie de condiciones para ser aceptada, las cuales, pese a no ser importantes, provocan una serie de conversaciones entre las áreas de desarrollo y de sistemas, que pese a terminar en acuerdo tienen como consecuencia la pérdida de varios días.

Al final, suele suceder que los plazos fijados no se cumplen.

Bien es cierto que si fuera algo crítico o estratégico probablemente alguien con suficiente poder dentro de la organización hubiera dejado clara la prioridad y se hubieran volcado los esfuerzos en que todo hubiera salido hacia adelante. Pero también es cierto que cuando no es así, resulta complicado ser predecible con las fechas en que se prevé que una versión llegue a producción y esto a veces tiene poca importancia y en otros casos tiene un coste económico que podría ser poco significativo hasta que el número de veces en que se producen este tipo de circunstancias hace que el coste económico, gota a gota, sea sensible.

No se trata de echar la culpa a sistemas, en el ejemplo que he puesto la culpa perfectamente ha podido ser de desarrollo, ya que lo mismo sistemas avisó con suficiente tiempo de sus tareas y/o las condiciones de entrega y la falta de flexibilidad eran perfectamente conocidas y se podía haber comenzado el diálogo mucho antes.

Se considera parte del ADN de nuestro negocio que los departamentos de desarrollo, sistemas y explotación funcionen como reinos independientes con sus propias reglas y prioridades, que si bien tienen que colaborar entre sí, la fluidez con que se realizan esas colaboraciones dependen más de las relaciones personales existentes entre sus miembros que por unos objetivos a nivel organizativo o las necesidades propias de un proyecto.

Que personas puedan resolver problemas más allá de un contexto poco favorable para un trabajo cooperativo siempre es positivo, de hecho, como veremos más adelante, es fundamental.

Sin embargo en un mundo tan profesionalizado como el nuestro, las cosas tienen que salir adelante independientemente del grado de afinidad que tengan determinadas personas o de si un día alguien se ha levantado con más o menos humor que de costumbre.

La realidad es que cada departamento evoluciona de manera independiente, como si estuvieran desenchufados, como si no tuvieran nada que ver, lo que hace que definan sus propias interfaces, su propio modelo de relación y eso se termina convirtiendo en una fuente continua de conflicto porque cada uno de ellos enfoca sus prioridades a objetivos que siendo perfectamente legítimos, pueden no estar en consonancia con lo que la organización necesita en ese momento.

Es decir, ambas partes pueden llevar razón, incluso sus actuaciones podrían considerarse como válidas, sin embargo, en muchos casos esos resultados parciales positivos cuando no se realizan teniendo en cuenta al resto de la organización, sus tiempos y objetivos pueden tornarse en perjudiciales.

DevOps II
DevOps III
DevOps IV
DevOps V
DevOps VI
DevOps VII

Una versión simplificada del enunciado de la Ley de Conway (Melvin Conway) es la siguiente: “Cualquier pieza de software refleja la estructura organizacional que la produjo”.

Esta ley, se centra principalmente en las comunicaciones entre los equipos de personas y las personas dentro de esos equipos en un proyecto de desarrollo de software, reflejando algo que es una realidad: si no hay comunicación, si no es fluida o no es buena, el proyecto se resiente.

Y son muchas las líneas de comunicación que tienen que funcionar: product owner con el conjunto de usuarios, product owner con sus jefes, product owner y equipo de desarrollo, equipos de desarrollo entre sí (si existe más de uno), equipo de desarrollo con el departamento de sistemas, y así sucesivamente con todos los tipos de relaciones que pueden existir (que dependerán de las características del proyecto que se está desarrollando y la organización u organizaciones que intervienen).

Es importante que no nos centremos solo en la comunicación entre los equipos de desarrollo, que si bien es fundamental, no es la única que existe, tal y como hemos visto en el párrafo anterior. No obstante, es interesante señalar que los problemas de comunicación entre los equipos los veremos reflejados principalmente en la integración entre sus trabajos.

No olvidemos tampoco las relaciones y la comunicación dentro de un mismo equipo de proyecto, donde a una escala más pequeña se pueden reproducir los mismos problemas de dos o más equipos que no se entienden. Si los desarrolladores pierden la visión de equipo y van cada uno a su aire, el resultado final verá reflejada esa circunstancia.

El nivel de afección de la estructura organizacional no solo se produce por los problemas de comunicación que pueden existir entre los diversos actores que intervienen en el proyecto, también hay que tener en cuenta que muchas veces se trata de que el software resuelva problemas organizativos, es decir, si hay un proceso que se quiere informatizar y el proceso en la vida real presenta deficiencias, no se puede esperar a que el desarrollo informático las resuelva (salvo que sean problemas de eficiencia en la comunicación entre personas que se encuentran en diferentes localizaciones geográficas), es más, es posible que incluso se empeore, al introducir una variable más dentro del problema.

Primero se tienen que resolver los problemas en el proceso, que puede dar lugar a una nueva formulación del mismo. Una vez hecho eso, el producto software puede ayudar a mejorar su eficacia.

La Ley de Conway podemos extender no solo a lo que es el desarrollo de software, sino también a la gestión del servicio TIC dentro de una organización, ya que la calidad y percepción que tienen los usuarios de ese servicio es el reflejo de la estructura de la organización que lo ofrece.

Por eso es tan importante que los Departamentos TIC funcionen en base a un conjunto de objetivos comunes, de manera coordinada, con comunicación constante y en búsqueda siempre de una mejora continua de su funcionamiento interno porque de esta forma se mejorará sin duda la calidad de los servicios que se ofrecen a la vez de conseguir un aprovechamiento más óptimo del presupuesto.

Quien piense que desarrollar con metodologías ágiles es más tranquilo o más sencillo, está totalmente equivocado, bien porque no sabe realmente qué es esto o porque los proyectos en los que ha participado o seguido y en los que teóricamente se aplican principios y prácticas ágiles no lo son en realidad.

Si hay algo que caracteriza a los desarrollos aǵiles es la intensidad. ¿Cómo si no se puede sacar cada poco tiempo una versión del producto potencialmente dispuesta para pasarse a producción?. Esto solo se consigue si todas las partes: desarrolladores, usuarios y restos de implicados participan con gran implicación en el proceso de desarrollo.

Si te duermes no cumples los compromisos.

A cambio de eso encuentras otras satisfacciones como el hecho de que se valore más el trabajo de las personas, la comunicación e interacción entre las mismas y el concepto de equipo (hay de todo, pero si las personas y el producto no son el centro de todo, estaremos hablando de metodologías ágiles pero no de agilidad real), la posibilidad de autogestionar tu trabajo y algo muy importante, ver como poco a poco vas construyendo un producto que sabes que va a resultar de utilidad y que no se va a quedar en una rama perdida en el sistema de gestión de versiones.

Los enfoques clásicos son mucho más irregulares en ritmo y si no hay premura en los plazos tienden a eternizarse, esto se hace más evidente en el desarrollo de grandes sistemas de información que parece que no terminan de ponerse en producción nunca y no es raro encontrarnos con sistemas que llevan más de dos o tres años de desarrollo (incluso con exigencia) y que no terminan de rematarse, algo que no es, en absoluto, una buena señal, porque se pondrá en marcha una aplicación mastodóntica sobre la que se tendrán que realizar ajustes, siendo el número de ellos proporcional a su tamaño y complejidad.

Se asocia ágil a desorganizado, a improvisación y no es así, si así fuera sería impensable tratar de cumplir unos compromisos cada poco tiempo. Muchas veces lo que parece organizado por el simple hecho de tener definidos ciertos entregables no es más que una fachada que esconde una gestión caótica.