Cynthia Rojas Ureña | Política y sociedad / ENFOCÁNDONOS EN LO IMPORTANTE
El informe de resultados será publicado en dos tractos, en este primer informe se presentan los resultados relacionados sobre la estrategia de DevOps.
¿Quiénes tomaron la encuesta?
La muestra fue de 423 informantes (n=423), donde el 73.8 % de las respuestas pertenecen del sector tecnología, seguido por el sector financiero, industria/manufactura, retail y otros. La muestra estuvo compuesta por profesionales de diferentes área TI, gerentes/jefes y consultores, los porcentajes se muestran en el siguiente gráfico.
Estrategia de DevOps
El 45.24 % del total de los encuestados reportan tener una estrategia de DevOps, el 38.10 % no la tiene y un 16,67 % no sabe si tiene una estrategia clara. Sin embargo, los porcentajes cambian cuando de rol funcional se trata.
-
En el caso de roles técnicos (aquellos que no son jefes o gerentes) se encontró que el 48 % dice sí tener una estrategia, un 35 % no y un 16.22 % dice no sabe si la hay.
-
En el caso de gerentes/jefes el 60 % dice no tener una estrategia, un 20 % no sabe y un 20 % de los encuestados indican poseer una estrategia.
Según la investigación, se encontró que existe una importante diferencia (desde la perspectiva cuantitativa y cualitativa) entre jefes y colaboradores. Es decir, las estrategias no siempre se llevan a cabo con la alineación de las gerencias y la organización, por lo que arranca con frecuencia en los niveles técnicos, principalmente el desarrollo de software de manera aislada, quedando rezagadas otras áreas partícipes del ciclo de DevOps como SQA, infraestructura y sin ninguna participación seguridad u otras áreas como análisis de negocio (BA), arquitectura, diseño/ ideación entre otros.
Otro hallazgo importante fue que, pese a que la automatización de pruebas para los encuestados es importante a nivel práctico, esta unidad no está lo suficientemente articulada con la estrategia como es requerido. Según Gartner (2019), para el 2023, el 90 % de las iniciativas de DevOps no cumplirán plenamente las expectativas debido a las limitaciones de los enfoques de liderazgo, no a las razones técnicas. El valor de adoptar las prácticas de DevOps es enorme, pero para que las iniciativas tengan éxito, las organizaciones deben abordarlas de la manera correcta. Por tanto, es importante que la estrategia esté hilvanada con todos los roles necesarios con el fin de lograr la colaboración y comunicación interdisciplinaria.
Se halló también que el tamaño de la empresa no guarda correlación con la existencia de una estrategia para DevOps. Sin embargo, se observó que las empresas con 50 personas o menos no tienen una estrategia, a partir de los 51 colaboradores se empieza a visualizar la creación de estrategias. Por otro lado, se encontró que las empresas de entre 500 y 1 000 empleados presentan poca actividad con respecto a la definición de estrategias. No así en los casos de entre 100-500 y más de 1 000 personas. Este es un hallazgo que merece profundizarse en próximas investigaciones. Otro aspecto que llama la atención es la mezcla de percepciones expuestas por los informantes de las empresas grandes, donde quienes reportan tener una estrategia y quienes no es muy similar. El restante 7.14 % de ese sector señala encontrarse en estado de desconocimiento sobre la existencia de una estrategia.
Pese a que las start ups o microempresas, durante la investigación, no reportaron poseer estrategias de DevOps, las mismas tienen la gran oportunidad de arrancar con procesos de DevOps debido a la agilidad, gracias a su tamaño y estructura liviana. Aprovechando así entregas continuas, capitalizando la experimentación y generación de valor a sus clientes desde las etapas más tempranas de su concepción.
Tool chain o cadena de herramientas y gobierno de aplicaciones
La desvinculación de la cadena de herramientas o tool chain, así como la definición de roles dentro de la ecuación de la estrategia, desacelera el avance y atenta contra los mismos principios de trabajo colaborativo y gobierno de aplicaciones/tool chain. Se encontró que solo el 28 % de la muestra tiene una estrategia de integración y/o adquisición, así como un gobierno intrínseco a la estrategia de DevOps. El restante 72 % no sabe o no posee una estrategia para integración/adquisición y gobierno de herramientas. Para Bhat, Betts y Little (2019), el gobierno es sumamente importante y toma cada vez más relevancia debido al aumento de software de código abierto OSS. Para los autores, la automatización del gobierno del software de código abierto es indispensable si de busca un tool chain escalable para DevOps que permita flexibilidad, cumplimiento con respecto a políticas de licenciamiento y seguridad. De manera que las entregas al negocio no se vean afectadas por aspectos técnicos relacionados al tool chain. Para estos casos, herramientas para análisis de composición SCA pueden ser de gran ayuda.
Capacitación
Existe una correlación entre una definición de roles para DevOps y la estrategia de capacitación. Es decir, a mayor claridad en cuanto la definición de roles, mayor claridad en la estrategia de capacitación. Con excepción de empresas con más de 1 000 empleados, donde se encontró que un 19 % invierte en capacitación pese no tener claridad en los roles. Esta situación representa un riesgo en cuanto a inversión y adopción, sin roles claramente definidos, el esfuerzo en capacitación e implementación puede desaprovecharse, ralentizando el proceso de transformación. La carencia en cuanto a definición clara de roles también genera incongruencia en lo concerniente a la comunicación, expectativas tanto hacia los colaboradores, del negocio hacia TI, y de la organización con respecto a la gestión del cambio. Para Gartner (2019), diversas organizaciones centran los esfuerzos en las herramientas de DevOps e ignoran la gran importancia e impacto de incorporar a su personal en el proceso de cambio. Para ello, Garner recomienda, como proceso relevante de la estrategia, identificar y nutrir a los candidatos con la actitud correcta de DevOps. Donde aquellos que manifiestan trabajo en equipo, responsabilidad, autoridad y aprendizaje permanente muestran el mayor potencial. En el mercado se encuentran disponibles algunas herramientas que pueden ser exploradas para llevar a cabo el modelo de competencia de DevOps, entre ellas se pueden mencionar DASA, DOI, SAFE o cualquier otro que apoye en la definición de roles y competencias para una óptima adopción. Según el Reporte de habilidades de DevOps (DevOps Institute, 2019), en una investigación realizada en Estados Unidos, estos son los roles más contratados en DevOps.
-
Ingeniero/mánager de DevOps
-
Ingeniero de software
-
Consultor de DevOps
-
Ingeniero de pruebas
-
Arquitecto de automatización
-
Ingeniero de infraestructura
-
Ingeniero de CI/CD
-
Administrador de sistema
-
Ingeniero/manager de lanzamiento (release)
-
Ingenieros de confiabilidad del sitio (site reliability)
En dicho informe, se presenta la clasificación por orden de importancia de las habilidades para un miembro del equipo de DevOps, tal como lo muestran las siguiente figura. También las habilidades técnicas que las 711 empresas de dicho estudio consideran más importantes, entre las cuales se mencionan como más relevantes las siguientes: cloud platform, cloud environment, analitical knowledge, marcos específicos (frameworks), entre los que se mencionan .net, css, AJAX, SOA; ambientes web y mobile entre otros.
Así mismo, se indica en que el caso de puestos de liderazgo, competencias tales como influencia, comunicación, negociación, pensamiento estratégico, habilidades de liderazgo, así como destreza y experiencia en el negocio son precisos para una exitosa implementación, tanto como una generación de valor clara a los clientes. Esto requiere un perfeccionamiento en la comprensión para identificar, anticipar y evolucionar capacidades que permitan una gestión del cambio de manera constante. Schaeffer (2017) señala que, para lograrlo, los líderes deben cambiar sus paradigmas, es decir, deben ver el cambio no como un disruptor ocasional, sino como la esencia misma de su rol y desarrollar en sus equipos las capacidades necesarias para implementación, evolución y mejora continua.
Indicadores
Con respecto la existencia de indicadores claros para DevOps, se obtuvieron los siguientes resultados. El 40.48 % reporta tenerlos, un 38.10 % no los tiene y un 21.43 % no sabe si hay claridad en los indicadores o bien no sabe si existen.
No se encontró correlación entre el tamaño de la empresa y la definición de indicadores claros. Sin embargo, como se puede ver en el siguiente gráfico, cuando las empresas sobrepasan las 50 personas se reporta más claridad en los indicadores de DevOps. Por otro lado, en las empresas de entre 500 y 1 000 colaboradores se encontró un 150 % de aumento entre aquellas que tienen indicadores claros versus la suma de aquellos que reportan no saber si existen y aquellos que no los tienen. Este es un hallazgo importante, pues, como se vio anteriormente, las empresas más grandes son aquellas que invierten más en capacitación pero son más proclives a no tener roles claramente establecidos, si a esta situación se le aúna indicadores de DevOps no claros, o bien inexistencia de los mismos, el riesgo aumenta durante el proceso de implementación y adopción.
Para Watts (2017), las métricas para DevOps se pueden clasificar en las siguientes cuatro categorías:
-
Eficiencia y efectividad
-
Velocidad
-
Calidad
-
Cultura, colaboración
A continuación se presenta una lista de algunos indicadores que pueden ser utilizados en estas categorías. Es importante tomar en cuenta que lo más recomendable es iniciar con unos 4 o 5 indicadores, los mismos deben estar alineados a la estrategia de implementación y value stream mapping inicial. De esta forma, los mismos pueden ir evolucionando y expandiéndose de la mano de los mismos equipos de trabajo y retroalimentación obtenida por parte del negocio (generación de valor al cliente).
Conclusiones
Durante la investigación se encontró que la estrategia está gestándose mayormente en los roles técnicos y está desarticulada con los jefes/gerentes. Es importante que la estrategia de DevOps se base en la generación de valor al cliente, por lo que la definición de la estrategia de DevOps debe trabajarse de manera interdisciplinaria y con la participación de todos aquellos roles que tienen una participación activa, mismos que van más allá del área técnica. Por tanto, el papel de los líderes debe ser más activo, involucrarse consciente y sistemáticamente con las personas. Desarrollando metas claras y una dirección en común donde todos conciban que el trabajo que se realiza muestra progreso, valor al cliente, innovación y mejora continua de manera colaborativa.
Uno de los hallazgos durante la fase cualitativa fue el gran enfoque que los informantes dan a las pruebas, sin embargo, estas unidades o roles están poco representadas durante la definición de la estrategia capacitación e indicadores.
Es necesario desarrollar estrategias y mecanismos claros para la adquisición y gobierno de aplicaciones y cadena de herramientas (tool chain) para DevOps. Esto implica un trabajo conjunto de diversas áreas de TI, infraestructura, operaciones, desarrollo, seguridad, desarrollo y SQA, o todas aquellas relacionadas al proceso de construcción y gestión de la operación.
Es necesario definir cuidadosamente los roles, así como la escogencia de recursos que serán asignados dentro de la estrategia de DevOps, así como la comunicación de la visión y las expectativas para ellos dentro del plan de implementación, capacitación y adopción al resto de la organización. Un aspecto importante a destacar es que, cuando de roles se habla, estos van más allá de los técnicos, se hace mención a todos aquellos de mercadeo, ideación, negocio, gestión, arquitectura, entre otros, los cuales son indispensables dentro del engranaje de los equipos, programas y portafolios de empresa.
Bibliografía
Bhat, M., Betts, D., & Little, C. (2019). Four Steps to Adopt Open-Source Software as Part of the DevOps Toolchain. Garter, report ID: G00378544.
DevOps Institute. (2019). Enterprise DevOps Skills Report. USA: DevOps institute.
Gartner. (2019). 5 reasons your DevOps initiative could fail, and how to avoid them. Recuperado de Gartner.
Schaffer, R. H. (2017, octubre 26). All Management Is Change Management Change Management. Recuperado de HBR.
Imagen principal proporcionada por Cynthia Rojas Ureña.
Cynthia Rojas Ureña

Ingeniera en Sistemas con más de 20 años de experiencia en el sector, máster en Resolución de Conflictos y Mediación en España, máster en Administración de Negocios con énfasis en Gestión Tecnológica y doctora en Ciencias de la Administración de la UNED en Costa Rica. Apasionada lectora e investigadora de temas relacionados con tecnología, sociedad y ciencias empresariales. Fiel creyente que la tecnología sigue siendo un medio para la sociedad y no un fin en sí misma.
Correo: dra.cynthiarojasurena@gmail.com
Un Commentario
Muy buen artículo, complementario a la lectura de «State of Devops Report» de 2019.
Gracias.
Dejar un comentario