Sin Cultura, no hay DevOps (menos agilidad organizacional)

Sin Cultura, no hay DevOps (menos agilidad organizacional)

Podemos contar con las mejores plataformas para la integración, manejo de versiones, realización de pruebas unitarias, pruebas exploratorias, e incluso con la capacidad de hacer deployment automatizado, pero… si no desarrollamos la cultura adecuada, no lograremos llegar a establecer una práctica de DevOps efectiva, real y eficiente. Lo que es peor, vamos a estar desperdiciando mucho dinero, recursos y tiempo.

CAMS es el acrónimo acuñado por Damon Edwards y John Willis en el DevOps Days de Mountainview en el año 2010, el cual describe los valores o elementos necesarios para lograr implementar una práctica de DevOps real. CAMS significa:

·       Cultura

·       Automatización

·       Medición

·       Compartir (Sharing en inglés)

No es casualidad que en dicho acrónimo la “C” de Cultura aparezca primero y antes que los otros elementos. Y es que revisando “casos de la vida real” nos damos cuenta de que, efectivamente, hay organizaciones y equipos que cuentan con las mejores herramientas para la gestión del ciclo de vida de las aplicaciones de software, pero sin una cultura bien cimentada, esto es equivalente a tener un cohete, con capacidad de llevarnos a la luna, y utilizarlo como amenidad en un parque de juegos infantiles.

¿A qué se refiere el elemento Cultura en el acrónimo CAMS?

Bueno, realmente este es el elemento que hace de DevOps una práctica absolutamente necesaria para lograr eficiencia, efectividad, retorno de inversión y agilidad en la entrega de soluciones tecnológicas. La cultura en DevOps tiene injerencia desde muy temprano en el ciclo de vida de una aplicación. Supongamos, a modo de ejemplo, que nuestra organización es un banco (el banco “A”), el cual tiene una fuerte competencia en el mercado actualmente, pues hay otros dos bancos, el banco “B” y “C”, quienes están enfocando su estrategia al mismo segmento de mercado al que se enfoca el banco “A”. La competencia es marcadamente agresiva, en el sentido que cuando alguno de los tres jugadores lanza al mercado un nuevo producto, una promoción o un nuevo servicio, los otros dos competidores deben reaccionar rápido, para mantener su proporción de mercado, buscando incrementarla y no perder clientes. Actualmente, el mercado bancario compite brindando diferenciadores enfocados en servicios y obviamente, productos a sus clientes. En la gran mayoría de casos, tanto productos, como servicios se están apoyando en soluciones digitales o tecnología de alguna índole. DevOps presenta muchas ventajas competitivas y puede ser un elemento clave en la carrera por el mercado en un entorno altamente peleado y volátil. Tomando en cuenta experiencia relacionada con DevOps acumuladas por organizaciones a nivel mundial, les comparto los siguientes datos:

·       Los equipos de desarrollo de aplicaciones de software con una práctica de DevOps efectivamente implementada logran realizar liberaciones de versiones de sus aplicaciones hasta 30 veces más frecuentemente que otros equipos que manejan sus ciclos de desarrollo de software de forma “tradicional” y, sobre todo, “desconectada” de la organización.

·       Los equipos de tecnología (Desarrollo de Software y Operaciones) que logran implementar efectivamente DevOps, presentan una velocidad de ejecución de proyectos hasta 168 veces más rápida que otros equipos funcionando de otras formas.

 

¿Cómo es esto posible? ¿Cómo se logran esas diferencias tan abismales? La respuesta es simple y compleja a la vez: Cultura.

Sin una cultura enfocada en la generación de valor centrado en el cliente, con equipos funcionando como silos y en la “comodidad” de su propio entorno, nada o casi nada se podrá esperar en cuanto a generación de innovación disruptiva, ventajas competitivas reales y capacidad de reacción. 

Pero, elaboremos un poco más respecto de la cultura, desde la perspectiva de la administración del ciclo de vida de las aplicaciones, (las cuales, por cierto, está generando nuestro banco “A”, mencionado a modo de ejemplo), con el afán de generar competitividad y mejora en sus productos y servicios.  Nuestros amigos en el banco “A” no la están pasando nada bien, pues se han identificado como una organización reactiva, con poca capacidad de proposición, que está prácticamente siguiéndole los pasos siempre al banco “B” y “C”, quienes han estado marcando el paso en cuanto a innovación en los últimos años, principalmente el banco “B”, el cual ha incrementado incluso su participación de mercado en el último año de forma muy marcada, ofreciendo procedimientos de consulta de información de cuentas de forma sumamente segura, ágil y rápida a sus clientes. Ha modificado totalmente la experiencia de la banca móvil y de la banca electrónica, haciéndola sumamente atractiva, dinámica y agradable.

¿Qué está haciendo el banco “B”, que no hace el banco “A”, ni el banco “C”?

El banco “B” se ha enfocado desde hace un par de años en convertir su operación en la versión más ágil posible, de esta cuenta, las iniciativas de proyecto, para implementar o generar un nuevo producto o servicio, se obtienen tanto de su maquinaria de prospectiva, la cual incluye un motor de analítica de información de sus clientes, que les permite realizar análisis predictivo de comportamientos y tendencias, así como de una unidad enfocada en innovación, la cual ha montado una práctica permanente de generación de iniciativas estratégicas, apoyada por personal de todas las áreas y niveles de la organización, quienes participan en laboratorios de generación de disrupción creativa de forma mensual. Paralelo a esto, cuando una iniciativa involucra el desarrollo de alguna aplicación o solución de software, su proceso de diseño aplica principios de Pensamiento de Diseño (Design Thinking) y Lean Startup, lo cual les permite contar con visibilidad y claridad de qué es lo que sus clientes realmente valoran y esperan de la solución. En otras palabras, la toma de requerimientos se hace desde la realidad del usuario interno, o cliente externo, teniendo en cuenta sus expectativas y experiencia en el día a día, y planteando una solución práctica y con el menor costo posible, enfocada en rentabilidad y competitividad. Así mismo, los equipos de desarrollo ahora están conformados por ingenieros desarrolladores, diseñadores web, arquitectos de software, DBA´s, administradores de infraestructura y testers. Los proyectos de desarrollo se enfocan no solo en entregar la “funcionalidad soñada completa”, sino se comprometen con generar el producto mínimo viable en el menor tiempo posible. Planteado de otro modo, no es importante sacar al mercado un producto altamente sofisticado, que haga y cumpla todas las expectativas funcionales que se han planteado para el proyecto, sino que se entrega en un período de no más de un mes, una primera versión funcional para ser utilizada y probada en el menor tiempo posible. Una vez lanzada la primera versión de la solución, los equipos cuentan con mecanismos y canales de comunicación directa y abierta con los patrocinadores del lado del negocio y/o del cliente final, quienes brindan retroalimentación temprana (no más allá de 4 semanas luego de la salida de la primera versión de la solución) respecto de la experiencia y beneficio evidenciado por la utilización de la aplicación. Esta retroalimentación permite a los equipos de desarrollo realizar los ajustes y modificaciones necesarias para ir puliendo la funcionalidad actual y generando nueva funcionalidad que esté alineada con lo que los usuarios requieren o esperan. Si una solución o modificación no genera el valor esperado, se descontinúa o re-ajusta en la siguiente iteración, generando una pérdida mínima en tiempo y recursos.

Como parte de la metodología definida dentro de los equipos de desarrollo en el banco “B”, se cuenta con una plataforma integrada, la cual permite registrar el nivel de ocupación de cada uno de los miembros del equipo, tener visibilidad de los elementos funcionales que se deben ir generando para agregar valor a la solución, nivel de avance de cada una de las actividades del proyecto, las cuales, por cierto, se han auto-asignado los miembros de cada equipo. En los equipos de desarrollo no hay supervisores, jefes o líderes impuestos. Los equipos se gestionan a partir del compromiso de entrega de la funcionalidad a la que se han comprometido. Hay metas y métricas de cumplimiento, las cuales son sumamente importantes para la Dirección de IT.  Los directivos de todas las áreas tienen visibilidad sobre el nivel de avance de cada proyecto e iniciativa desde un tablero integrado de control. Los sistemas y soluciones de software son diseñadas tomando en cuenta el potencial uso y requerimientos de infraestructura. La infraestructura necesaria es proactivamente preparada por los especialistas del área de operaciones, teniéndola a punto y lista para recibir las nuevas implementaciones, tanto en la etapa de pruebas, como en la salida a producción. 

Como hay un correcto manejo de versiones y ramificaciones del código de cada una de las aplicaciones de software, el equipo encargado del soporte de las aplicaciones en producción cuenta con la información necesaria para poder soportar de forma adecuada cada una de las soluciones. Antes de poner cada solución en producción, el equipo de operaciones que tendrá a cargo su soporte es capacitado por un miembro del equipo que generó la solución. La documentación relacionada con la arquitectura de la solución se entrega de forma completa y en formato digital, de tal cuenta que la misma se indexa dentro del portal de conocimiento de las aplicaciones de software en producción, lo cual facilita mucho encontrar la información necesaria al momento de atender un evento de soporte. Cuando el sistema ya está en producción, se le siguen sumando funcionalidades identificadas como generadoras de valor, actualizando su funcionalidad de forma proactiva. Así mismo, se van incluyendo en las diferentes iteraciones correcciones necesarias para resolver inconvenientes que los usuarios hayan reportado, los cuales, por cierto, cada vez son menos, pues la organización ha aprendido y afianzado una práctica que les permite entregar soluciones de software “sanas”, en el sentido de no contener errores, o presentar la menor cantidad de errores que atropellen su lanzamiento y aprovechamiento desde el primer momento de uso.

Sé que suena a “ciencia ficción”, pero la realidad es que ya hay varios equipos y organizaciones que se gestionan de esta forma, o al menos, van encaminados a funcionar de esta manera. En un entorno tan volátil, incierto, convulso y ambiguo como en el que nos manejamos actualmente a nivel mercado, la organización que logre afianzar e implementar una práctica de DevOps real, tendrá una ventaja competitiva casi imposible de igualar, lo que la pondrá a años de distancia de sus competidores. Por otro lado, la organización que logre una sana práctica de DevOps, se ahorrará una cantidad enorme en recursos financieros, horas de trabajo y potenciales pérdidas de mercado y clientes por falta de competitividad.

Estamos en la era de la digitalización y el futuro será aún más digital. La digitalización descansa en una práctica de IT efectiva, sana y eficiente.

 


Inicia sesión para ver o añadir un comentario.

Otros usuarios han visto

Ver temas