Habilitar la agilidad en una organización sin duda requiere cambios en todos los niveles organizacionales. Algunos mas complejos que otros, pero al final es una espiral de cambios constante, para adaptarse al nuevo contexto y/o a las nuevas necesidades.
Desde hace varios años, los equipos de negocios y desarrollo han visto un cambio de los enfoques tradicionales de desarrollo de software, al tener que pasar del desarrollo en cascada al desarrollo iterativo, de ágil a nivel de equipos ha escalado ágil hasta llegar a Enterprise Business Agility.
Pero cambiar el enfoque de una organización desde la definición de temas estratégicos, pasando por la identificación de necesidades de los clientes, la gestión del portafolio y el desarrollo de iniciativas hasta llegar a la entrega está lejos de ser sencillo. Cada bloque del proceso presenta diferentes tipos de retos que deben ser abordados a lo largo de todo el ciclo de la mejor manera posible.
Es decir que, para tener una visión completa de la agilidad empresarial, es necesario equilibrar el Valor (construir lo correcto), la Calidad (construir correctamente y el Flujo (construir a la velocidad adecuada). Para este último, significa optimizar el flujo de entrega de valor balanceando el grado en que la organización optimiza el uso de recursos y optimiza el flujo de entrega de valor al cliente.
Es en este punto en donde entra DevOps. Para unos una cultura, para otros una metodología, para otros algo creado sin necesidad, dado que la agilidad como tal engloba el concepto de unir de manera colaborativa y con el único fin de generar valor, el trabajo de las diferentes áreas de la organización.
Implementar DevOps en una organización se convierte en un desafío cultural y tecnológico, lo cual significa que es obligatorio para cualquier organización tomarse en serio el proceso, tener líderes a la cabeza del proceso, que lo entiendan y puedan trabajar con diferentes tipos de roles de manera interfuncional, será sin duda una de las claves principales del éxito de la implementación. Por lo tanto, si hay una visión clara y los objetivos están bien definidos desde el principio, entonces el resto de la organización se alineará. Por el contrario, si esto no existe, es casi seguro que la implementación va a fallar.
A continuación, veamos los 11 principales errores que se deben evitar entonces al querer implementar DevOps:
- Partir con la idea que DevOps es una cultura. No, DevOps no es en sí una cultura, pero sí requiere de una fuerte evolución cultural y organizativa para su implementación. Un evolución cultural hacia la colaboración, la comunicación, y en último término la completa integración entre las áreas de desarrollo y sistemas. Lo cual requiere una buena gestión del cambio.
Pero según lo anterior, entonces que podemos decir que es DevOps: DevOps es una metodología de desarrollo software, y una evolución cultural no es en sí misma una forma de desarrollar software. Esta evolución cultural es tan complicada de conseguir en algunas organizaciones, que muchas personas la identifican directamente con implementar DevOps.
- Creer que DevOps es un Rol o cargo nuevo. Este es otro error común, ya que se tiende a confundir DevOps con modelos que algunas startups se ven abocadas a adoptar en sus inicios, en los que todos los miembros del equipo técnico saben de desarrollo, de operaciones, de bases de datos… etc. DevOps no consiste en aumentar la responsabilidad de los desarrolladores haciendo que lleven varios sombreros (en particular dos, el de desarrollo y el de operaciones), sino en sustituir esos dos sombreros por uno solo, un nuevo sombrero de DevOps.
Según Rob Steward, vicepresidente de desarrollo de producto de Progress Software, “una buena práctica de DevOps liberará a los desarrolladores de ciertas tareas, para que se centren en hacer lo que mejor saben hacer: escribir software. Dado que DevOps elimina el trabajo y las preocupaciones de la puesta en producción del software una vez que está escrito”.
Si esto es así, ¿qué es un ingeniero DevOps?, ¿Por qué se buscan en el mercado (y cada vez con mayor demanda) perfiles con habilidades específicas para montar equipos DevOps? La respuesta es sencilla. Para un desarrollador pasar a un modelo DevOps resulta inmediato, mientras que un ingeniero de sistemas necesita nuevas habilidades. Estas habilidades, según una investigación de Puppet Labs, son: scripting, reingeniería de procesos, experiencia con herramientas específicas y una serie de soft skills necesarios para lograr las interacciones que se requieren dentro del proceso. Por lo que un perfil de este tipo, no es fácil de encontrar.
Así que no, DevOps no es una profesión, y estrictamente no existen ni perfiles DevOps ni ingenieros DevOps, sino “ingenieros de sistemas con capacidades específicas para integrarse en equipos DevOps”.
- No considerar a las personas y a los recurso en el proceso de implementación. Si no se tiene suficiente conocimiento sobre las cargas de trabajo de los equipos y sus capacidades para realizar tareas, lo mejor es no obligarlos a adoptar DevOps. Lo más recomendable siempre será, cuantificar primero la carga de trabajo de cada una de las personas de los equipos y de los equipos en general. Los siguientes pasos serán entonces, diseñar indicadores clave de rendimiento (KPI) y garantizar que estén bien controlados. Acto seguido, analizar y comprender el rendimiento de todos, para así utilizar la información obtenida para organizar mejor las cargas de trabajo
- Ver a DevOps solo como un proceso de automatización. Si bien en DevOps, es importante automatizar la mayor parte del proceso (si la mayor parte, no todo), tanto como sea posible. DevOps va más allá, Matthew Skelton (cofundador de Skelton Thatcher) dijo: “si se crea un enfoque DevOps, que involucra a un único equipo encargado de la automatización, se perderá el sentido, ya que concentrarse solo en la automatización le proporcionara solo un poco de efectividad adicional en TI”. otro experto en DevOps, Stephen Thair (Cofundador de DevOps Guys) explica: “DevOps no es solo una cosa de TI. Ya que, si la organización está centrada solo en la automatización, DevOps le ofrecerá un software mejorado. Pero no solucionará los problemas de cuellos de botella que tenga el flujo de desarrollo de soluciones en la organización”.
Otro punto interesante para tener en cuenta es: Armar un equipo o célula en TI enfocado en DevOps, hará que se establezca un nuevo silo en el flujo.
- Querer implementar DevOps con personas sin experiencia. Actualmente muchas empresas están dando el paso hacia la implementación de DevOps. Sin embargo, en muchos casos con pocos o ningún ingeniero con experiencia real en la implementación de DevOps. Como resultado, terminan entregando trabajos de baja calidad. Aquí hay que tener algo presente, pasar de un proceso de desarrollo de soluciones sin DevOps a uno con DevOps es una idea brillante, pero solo si como organización se está bien preparado y se cuenta con ingenieros con experiencia. Ya que el nivel de habilidades y conocimientos que se requieren es extremadamente alto.
- Sobreponer la velocidad sobre la calidad. Muchas organizaciones se enfocan en fabricar un producto rápido, en lugar de enfocarse en la calidad. (aquí una opinión muy personal: agilidad sin calidad, no es agilidad y la agilidad si debe brindar velocidad a la hora de generar valor, pero con calidad). Las tareas de DevOps deben lograrse manteniendo altos estándares. Por otro lado, no puede comprometer la velocidad con la calidad. En el mundo de hoy, la competencia se ha vuelto tan dura y permanecer relevante es un desafío. Es por eso por lo que muchas organizaciones se apresuran a aceptar proyectos de DevOps y terminarlos en el menor tiempo posible. Como resultado, la calidad del trabajo es pobre. La velocidad y la calidad deben funcionar de la mano.
- Avanzar hacia nuevas tecnologías sin terminar de madurar las anteriores. El problema en muchas organizaciones es que comienzan a usar nuevas tecnologías antes de que terminen de investigar y/o madurar las anteriores. Además, en muchos casos vemos como usan tecnologías que aún están en modo beta, solo porque los competidores están haciendo lo mismo. (el mismo caso sucede con la agilidad, la cual en muchos casos llega a las organizaciones, más por el hecho que en la competencia se está “trabajando bajo agile”, que por el hecho de existir conciencia que se debe habilitar en la organización) . Antes de comenzar a usar estas tecnologías, las organizaciones deben tomarse el tiempo necesario para realizar una investigación seria y exhaustiva de dichas tecnologías, con el objetivo de determinar si estas son las que realmente requiere o se adaptan a la organización o si, por el contrario, es la organización quien debe adaptarse a ellas. Esto con el fin de gestionar dicho cambio responsablemente. Hay que tener en cuenta también que la tecnología cambia día a día y se están introduciendo complementos para actualizar las tecnologías antiguas. Sin embargo, lo recomendable siempre será, no tengas prisa por actualizar cuando se trata de tecnología. Lo mejor siempre será, tomarse el tiempo para aprender todo en cada etapa, y luego avanzar al siguiente paso cuando se esté listo.
- Tener un ¿por qué? muy pobre para querer implementar DevOps. Al igual que al hablar de agilidad en una organización, es muy importante tener un ¿por qué?, muy solido a la hora de hablar de DevOps. Dado que DevOps es una excelente manera de acelerar la formar en que TI puede asegurarse que cumple con las demandas de la empresa. Sin embargo, al querer implementar DevOps, este debe enfocarse en respaldar las necesidades de la organización. Tener claro el ¿por qué?, siempre ayuda a determinar la estrategia adecuada. Y una estrategia adecuada, ayudara a alentar a las partes interesadas a determinar el presupuesto, los recursos y los cambios que se necesitan.
- No incluir a las personas de auditoria o de PMO. Muchas organizaciones consideran que DevOps es un tema exclusivo de TI, quizás porque en su acrónimo habla de Desarrollo y operaciones. Sin embargo, DevOps es una combinación de muchas partes interesadas. Ya que este es un proceso continuo de automatización y desarrollo de software que puede dar lugar a muchas áreas grises en temas de auditoria, cumplimiento de estándares de seguridad y/o normativos. Por lo cual es de suma importancia contar con personal de auditoria o de la PMO que entienda los procesos, evalué los controles e identifique los riesgos (esto no es un trabajo solo de este grupo de personas, debe ser de todas las personas que participan. Sin embargo, por su neutralidad, están llamados a brindar una mirada externa que aporta mucho valor). Es decir, la organización debe crear un sistema de pensamiento inclusivo, que haga que la implementación de DevOps no sea algo solo de TI, sino por el contrario que sea de contexto organizacional.
- Determinar un plan de implementación prescriptivo y ser rígido con dicho plan. Al igual que en la agilidad, es más importante “responder al cambio sobre seguir el plan” sin que el plan no sea importante. Y he aquí en donde muchas organizaciones fallan en su implementación de DevOps. La rigidez con que se busca abordar DevOps en la organización termina creando puntos ciegos (como los que se presentan en una habilitación agile) que no permiten ver la situación real. Por eso es importante localizar el liderazgo adecuado dentro de la organización para dicho fin, es decir lideres que estén al servicio de la implementación de DevOps, no al contrario. Por otro lado, se debe gestionar el cambio de paradigma en la organización sobre como abordar las fallas o errores. Es decir, si en la compañía se castiga el error, las personas serán reacias a mostrarse abiertas a los cambios que requiere la implementación de DevOps. Fomentar la experimentación será clave en el proceso.
- Sobre vender DevOps en la organización. DevOps no es una bala de plata que va a solucionar todos los problemas de cuello de botella que existen en la organización y/o las ineficiencias que existan en TI y/o en el proceso de desarrollo de soluciones. Aquí es crucial entender por parte de la organización, que entre mejor estén hechas las cosas antes del despliegue, mejores resultados se obtendrán. Otro punto importante es adoptar un enfoque que vaya proyecto por proyecto y no uno completo o Big Bang. Siempre es recomendable comenzar por proyectos valiosos, pero no de misión crítica. De esa manera la organización puede ver los beneficios claros de las practicas de DevOps, así de los posibles errores que se estén cometiendo, sin que sus procesos críticos se vean afectados. Así con el paso del tiempo y cuando el tema vaya madurando en la organización, se va llevando a procesos más críticos.
Como puedes ver mi querido amigo lector, son muchos los errores que se pueden cometer al querer implementar DevOps en una organización. Aquí solo mencioné los más comunes, sin llegar mencionar los técnicos, que representan otros desafíos.
Mi querido amigo lector una vez más, gracias por tu tiempo.
Ah y porque no todo es lectura, quiero compartir contigo también, mi canal de YouTube, el cual podrás visitar y suscribirte al canal aquí. Canal en el que también estoy publicando constantemente contenido.
Saludos,
Contenido Relacionado
– SUSCRÍBETE A MI BLOG –
Y cada vez que realice una nueva publicación, recíbela al instante.
