archivo

Archivos Mensuales: septiembre 2013

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.

Anuncios

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.

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