Una de las tendencias que más está cambiando la manera en qué se trabaja y desarrolla en las áreas TI es el , que si bien se ha hablado mucho al respecto aún es poco claro qué es lo que cambiará en la industria Javier Urrutia Tobar, CEO/Founder de coreDevX, Consultora y Centro de Investigación en las Dinámicas y Procesos de desarrollo de Software, nos ofrece una visión para atenderlo de manera clara y conocer sus alcances en las empresas.

Indica que es un nuevo movimiento, que nace producto de problemas inherentes al desarrollo de software y en su base está en la tradicional tensión entre las áreas de desarrollo de software y las áreas de operaciones tecnológicas, al interior de las Gerencias de Tecnologías.

El cambio cultural o movimiento se conoce como “DevOps”, una unión de las palabras Developer (Desarrollador de Software) y Operations (Operaciones tecnológicas). Es una forma de entender que ambos equipos trabajan para la misma empresa, y por lo tanto necesitan reconocerse como pares de un mismo equipo. El movimiento no tiene reglas explicitas, pero se conocen algunas convenciones al respecto.

Y aunque parezca que “DevOps” viene a resolver un problema de áreas de tecnologías de la información, la verdad es que más bien está orientado al negocio y no a la tecnología en sí. “DevOps” se basa en un fuerte acento en prácticas de comunicaciones y de cuestionamientos efectivos a fin de derribar silos y muros que se forman de manera natural en las organizaciones, digámoslo así por la “naturaleza humana”.

Además tiene un fuerte componente de automatización por sobre manualidades, así como gestión de distintos elementos, tales como configuraciones, rendimiento, capacidad, monitorización, etc. La verdad es que al movimiento “DevOps” no le faltan herramientas. Pero lo que realmente es relevante es que en general se tienden a usar en modalidad ecosistema.

Esto es que, cada una apoya a las demás y cuando esto pasa, el resultado es mayor que la suma de ellas (piense en Apple y su ecosistema de dispositivos). Al igual que en la dimensión humana, “DevOps” no es una certificación o un título. Es una forma de mirar las personas, las tecnologías y el negocio de cada empresa.

Muchos creen que “DevOps” es cultura para StartUps, empresas emergentes o disruptivamente innovadoras. Pero la verdad es que “DevOps” es para corporaciones, ya que son éstas donde mejor provecho se puede sacar al elemento clave de la cultura “DevOps”, que la destrucción de la barreras, murallas y silos de poder y comunicación dentro de las organizaciones.

Y entonces, ¿por qué el movimiento “DevOps” afectaría al negocio, más allá de las áreas de tecnologías de la información de cada empresa? La respuesta es que para que el movimiento “DevOps” funcione de forma correcta, el input para saber lo que hay que hacer es definida por el negocio. Entonces, el alineamiento para las acciones, prioridades y etapas, vienen definidas por el afán y valores de cada empresa, pero no de forma totalmente arbitraria ni unilateral, sino haciendo ecosistema con sus áreas de tecnologías.

“El Sistema como un todo” es la empresa (incluido TI). Ese es el todo. El feedback, viene de la constante evaluación del resultado comercial de las acciones en el negocio articuladas por requerimientos iniciales a TI, pero construidos con otras áreas más allá de TI, y compartidas por todos y a todos (conscientemente).

La experimentación y el aprendizaje continuo, va por salir al mercado lo antes posible (Time to Market), pero no necesariamente con grandes disrupciones tecnológicas de servicios o productos, sino con elementos experimentales que validen a bajo costo hipótesis del negocio (ROI justificado).

¿Y entonces por qué no todos están en esto? Simple, el punto débil es que la cultura “DevOps” no se puede imponer, y si bien es cierto se manifiesta en TI, requiere de una visión y sponsor mucho más alto en la organización, un trabajo de coaching de mediano plazo. Además requiere practicar la fontanería de silos (Desarrollo, Operaciones y Marketing, entre otras áreas de la empresa).

Tampoco vale montar un “Equipo de DevOps”, ya que no es un título ni una misión en sí misma. Se trata de compartir responsabilidades y generar mecanismos de incentivo cruzado sin cambiar su estructura. Practicar la transparencia de información, cuidar la comunicación, practicar la elasticidad corporativa, aumentar los canales de feedback, lidiar con la resistencia al cambio, automatizar por sobre gestionar y mucho más.