Cómo ganar con DevOps y perder el miedo al cambio

Antonio Díaz, director de cuentas Mainframe & Continuous Delivery de CA Technologies Iberia.

Imagine que se encuentra en un casino de Las Vegas. ¿Cómo se sentiría si ganase o perdiese cien euros con un giro de la ruleta? Curiosamente, los estudios psicológicos indican que cuando se pierde, el impacto emocional es el doble que cuando se gana. Nos duele perder más de lo que nos gusta ganar.

Es este conocimiento sobre el comportamiento y el sesgo cognitivo es lo que ayuda a los casinos a obtener beneficios. También es algo que puede influir en cualquier iniciativa de cambio sobre la tecnología aplicada al negocio, incluyendo DevOps.

Ahora imagine que trabaja en el desarrollo de software. Está bajo presión para lanzar una actualización de una nueva aplicación. En su fuero interno sabe que podría haber algún problema de rendimiento o de calidad, pero pensar en retrasar el lanzamiento es inimaginable. Así que, igual que un jugador de casino, asume el riesgo y echa el dado de “lanzar y que haya suerte” para evitar una pérdida segura. Con suerte, su sensación incómoda no llega a ser un error serio que comprometa el negocio. Pero ¿cuál es la probabilidad de que, al igual que en Las Vegas, el destino se vuelva contra usted?

Odiamos perder aquello que hemos construido, incluso lo que no merece la pena.

Los problemas asociados con la aversión a la pérdida no se limitan únicamente al desarrollo de software, también afectan a las operaciones de TI y a la gestión de servicios.

El miedo a la pérdida puede verse influido también por otros matices técnicos del comportamiento, como el denominado «efecto IKEA». Este efecto, que debe su nombre a la conocida marca de mobiliario que debe montar el comprador, viene a destacar que las personas valoramos más aquello que hemos construido nosotros mismos. Esto es positivo porque en el caso de desarrollo nos permite sentirnos orgullosos de nuestro software, pero puede ser perjudicial si sobreprotegemos nuestras creaciones y rechazamos mejorarlas cuando es necesario. Es como mantener un viejo armario de Ikea con una pata que baila. Lo deberíamos haber cambiado hace años, pero estamos demasiado involucrados emocionalmente para hacerlo.

Una vez más el “mobiliario problemático” apreciado en exceso no es solo dominio del desarrollo. En operaciones se protegen fielmente herramientas y métodos para soportar la especialización en áreas concretas, haciendo gala del ensamblado de complejos procesos de ingeniería en detrimento de los muchos cambios necesarios.

Por tanto, ¿cómo pueden protegerse las organizaciones que se embarcan en DevOps ante los efectos adversos de la aversión a la pérdida? ¿Cómo asegurar que su personal no toma riesgos innecesarios por miedo a las consecuencias?

Varias recomendaciones:

1 – Acabe con las apuestas en el área de desarrollo. Tradicionalmente los equipos de desarrollo confían en los de calidad y pruebas para encontrar errores y defectos. Ahora, sin embargo, la adopción de técnicas como el desarrollo orientado a  pruebas (tdd) significa que si los test no se completan, el código no se libera y los desarrolladores obtienen un conocimiento inmediato sobre la calidad del software. Si a esto se añaden nuevas herramientas que eliminan las limitaciones para hacer pruebas, todo ello lleva a que la calidad se implanta mucho antes y no hay razón por la que el área de desarrollo deba tomar más riesgos y adquirir una deuda técnica innecesaria.

2 – Redescubra la artesanía. En la era del desarrollo ágil muchos de los antiguos procesos diseñados y construidos para asegurar el cumplimiento y la resiliencia ahora pueden ser un obstáculo en el circuito de innovación. Para resolver esto, muchos equipos de desarrollo asumen la función de operaciones “en la sombra”, adoptando nuevas herramientas para eludir al equipo de operaciones TI. En lugar de resistirse, debería animarse a los equipos a aplicar su experiencia en áreas más allá de los confines de la estructura organizativa. Esto permite que elementos críticos y a menudo descuidados como el soporte de aplicaciones o la experiencia de usuario final de alta calidad se “construyan” durante el diseño y el desarrollo.

3 – Incentive en función de los resultados del negocio. Para el personal de soporte va a ser duro renunciar a la recompensa económica, por lo que es preciso tener especial cuidado. En lugar de compensar al personal en función de los resultados técnicos (líneas de código, número de problemas solucionados) considere establecer métricas por las que el personal pueda ser medido e incentivado en función de cómo sus actividades mejoran los resultados del negocio. Idealmente, esto debería ser aplicable a todos los grupos para fomentar el hecho de compartir conocimiento, información y estrategias de mejora transversales.

Resulta demasiado fácil plantear problemas en una cultura resistente al cambio, pero no debemos olvidar que la cultura viene moldeada por los comportamientos. En cualquier tipo de cambio es normal que las personas teman perder muchas cosas, incluyendo su importancia, habilidades, carrera o dinero; por ello se resisten cuando esas cosas se ven amenazadas. Si bien DevOps y sus herramientas se orientan a construir software de elevado rendimiento y resiliencia, también se trata de establecer dichas cualidades en las personas que las construyen y nutren.

Así y sólo así las organizaciones podrán comenzar a canalizar estas condiciones tan humanas y enfocarlas hacia aquello que verdaderamente debería preocupar perder a todos los colectivos DevOps: negocio, clientes y oportunidades.