Los malos hábitos son difíciles, especialmente cuando han sido institucionalizados. Es por eso que el liderazgo es tan importante.
Todas las empresas buscan mejorar la entrega de nuevas capacidades digitales de manera más rápida, más eficiente y con menos riesgos. En definitiva, el objetivo es lograr la Entrega Continua, donde existe una fricción cercana a cero entre el reconocimiento de una oportunidad de mercado y el verdadero código en producción.
Pero si bien es útil aprender las mejores prácticas de quienes están más cerca de este ideal que nosotros, también podemos aprender mucho de organizaciones que todavía luchan por lograr sus objetivos de Entrega Continua.
Aquí, entonces, hay siete malos hábitos comunes que impiden la entrega digital en las empresas:
Mal hábito #1: no tomar en serio la cultura
Para nosotros, las personas de ingeniería, la noción de “cultura” puede parecer demasiado sutil y subjetiva como para tener una relevancia real en nuestros trabajos. Nos ocupamos de realidades concretas como modelos de objetos y memoria transaccional, no abstracciones como la cultura del lugar de trabajo.
Sin embargo, la cultura es en gran medida una “cosa” concreta. Y tiene un profundo impacto en la forma en que el personal técnico trabaja en conjunto para alcanzar las metas apropiadas. Entonces, si usted está enfocado en procesos y herramientas que excluyen la cultura, no lo haga. Infórmese sobre cómo impacta su liderazgo en la cultura y haga de ella una verdadera prioridad.
Mal hábito #2: administrar las métricas incorrectas
Los viejos hábitos son difíciles de romper. Es por eso que tendemos a seguir con las métricas de rendimiento que nos han funcionado en el pasado, como las tasas de error y los tiempos de respuesta.
Sin embargo, las métricas del pasado pueden inhibir los comportamientos que necesitamos para el futuro. Por ejemplo, es posible dejar que sucedan más errores a corto plazo para que pueda fomentar el aprendizaje que se necesita a largo plazo. También es posible dejar que algunos pasos anteriores en su cronograma de DevOps tarden un poco más de lo que lo hicieron en el pasado como parte de su esfuerzo más importante en mover el aseguramiento de la calidad hacia la izquierda.
Mal hábito #3: multiplicar silos, en lugar de eliminarlos
En Fantasia, hay una escena en la que Mickey Mouse corta la escoba fuera de control, pero en lugar de matarla, crea cientos de escobas fuera de control.
Lo mismo puede pasar con los silos. Por ejemplo, el hecho de que realice las pruebas con mayor frecuencia en su proceso de desarrollo de software, no implica que lo haya desactivado. Es posible que acabe por crear un montón de mini silos. Para que su control de calidad pueda descifrarse verdaderamente, usted debe asegurarse de que esté perfectamente integrado en el proceso de codificación a través de la automatización y los controles de proceso adecuados.
Mal hábito #4: denegación de seguridad
Los líderes de DevOps han tenido una lucha real en los últimos años, ya que han tratado de adoptar Agile, vincular mejor el desarrollo y las operaciones, eliminar el cuello de botella de control de calidad, etc. Dadas estas dificultades, es comprensible que muchos opten por dejar la seguridad a los profesionales de la seguridad de la información.
Esta es una elección contraproducente. Usted puede, de hecho, probar continuamente su código para la seguridad de la misma manera que lo prueba continuamente para detectar otros tipos de fallas funcionales. De lo contrario, las pruebas de seguridad se mantendrán como una restricción contra la Entrega Continua. También ejerce presiones innecesarias sobre los equipos de seguridad de la información que ya están sobrecargados y carecen de recursos suficientes.
Mal hábito #5: automatización insuficiente
Históricamente, los gerentes y ejecutivos de TIC han pensado en la automatización principalmente en términos de ROI de ahorro de mano de obra. Es decir, implementaron una automatización basada en el ahorro de costos en comparación con el trabajo manual.
Esa lógica ya no es válida. Cuando toda su empresa depende de convertir inmediatamente las ideas en código de trabajo, la automatización de extremo a extremo es un imperativo existencial. Por lo tanto, en alguna parte del ciclo de vida de desarrollo de su software – gestión de requisitos, codificación, prueba, promoción o lo que sea – hágalo lo antes posible.
Mal hábito #6: mezclar integración continua con entrega continua
La integración continua (IC) es una disciplina crítica para los negocios digitales. Es por eso que muchas organizaciones han adoptado a Jenkins y otras tecnologías que aseguran que el producto de trabajo codificador pueda combinarse bajo demanda para mantener el ciclo de vida de desarrollo de su software en funcionamiento.
Pero IC no es entrega continua (EC). La EC implica mucho más que solo construir su paquete de código. También requiere una promoción de código y una gestión de versiones rápidas y automatizadas. El retroceso con botón también es esencial, de modo que, si encuentra problemas en la producción, sea posible salir rápidamente de la situación con un impacto mínimo en la experiencia del cliente.
Mal hábito #7: reutilización inadecuada
La mejor forma de obtener un código bueno y seguro en la producción de forma rápida y rentable es tenerlo de antemano. Es por eso que la contenedorización y los micro servicios son tan útiles para las empresas digitales. Después de todo, volver a usar el código que ya tiene no le costará nada.
Desafortunadamente, muchas organizaciones todavía tienen la reutilización en segundo plano, en la mayoría de los casos porque están bajo demasiada presión para lograr ganancias a corto plazo. Pero si no comienza a sentar las bases para su reutilización ahora, estará en una importante desventaja competitiva en los próximos años.
Los malos hábitos son difíciles, especialmente cuando han sido institucionalizados. Es por eso que el liderazgo es tan importante. ¡Empiece a atacar los malos hábitos de su organización hoy y tenga una excelente Entrega Continua!
Dejar su comentario sobre esta nota
Su direccion de correo no se publica. Los datos obligatorios se encuentran identificados con un asterisco (*)