HPE entre los líderes de almacenamiento de Gartner
Los CIO deben estar alerta a esas micro expresiones de alarma o burla en el rostro de su equipo: significa que el autoengaño ataca.
CIO AMÉRICA LATINA | Por Elibeth Eduardo | @ely_e
Nada se olvida con más frecuencia que el hecho incontestable de que nadie se equivoca a propósito.
De hecho, la condición sine qua non del error es que el mismo debe ser involuntario e indeseado para que sea considerado como tal.
Por eso una de las mejores cualidades de un buen supervisor es detectar cuando un fallo se debió al sujeto que ejecutaba o al plan que se ejecutó.
El problema con el autoengaño es que los “puntos ciegos” (NUESTROS puntos ciegos) nos resultan indetectables… hasta que tratamos de interpretar. las reacciones de los otros frente a nuestras acciones.
Por eso es bueno ver comportamiento de auto-engaño en otros… para tratar de no ser la próxima víctima.
Las siguientes TRES (03) mentiras son frecuentes. Asegúrese que no es el único que lo cree y trate.
Auto-engaño de CIO # 1: Estamos haciendo ITIL
Puede que parezca fácil de detectar pero, en realidad, no lo es.
De hecho, comencemos por lo que “pareciera” ser un problema semántico: no hay tal cosa como “hacer” ITIL.
ITIL es un marco, como sus defensores pacientemente explican a quien está dispuesto a escuchar: un público generalmente pequeño y apático que, por supuesto, no incluye nuestro CIO auto-engañado.
ITIL enumera las cosas en las que TI tiene que ser bueno.
No prescribe:
- Cómo seguir siendo bueno en ellas.
- Tampoco qué es igual de bueno… ya que no hay una manera de hacer nada en la lista de ITIL que funciona en todas las situaciones.
Piense en cómo lo manejaría si trabajaba en una pequeña agencia de publicidad y piense en cómo lo manejaría si usted es un gran contratista especializado en ciberseguridad.
Además de esto, hay muchos CIO que equiparan “hacer ITIL” con tener un servicio decentemente funcionado (o al menos cambiar el nombre de su escritorio de ayuda para que se lea “service desk”) y, tal vez, con la creación de un consejo de cambio (CAB) para sentarse entre el desarrollador de aplicaciones y el encargado de operaciones de TI para que ambos se autoglorifiquen en el CAB.
Auto-engaño de CIO # 2: Estamos haciendo Agile
Hay departamentos de TI que han pasado de las técnicas de desarrollo de aplicaciones en cascada a una o más variantes Agile o están en el proceso de hacerlo.
Pero, por cada uno que REALMENTE adoptó Agile hay probablemente una docena o más que siguen alguna forma de “agilefall” en su lugar.
Es decir, se adhieren estrictamente a cada uno de los formalismos de Scrum, ignorando completamente el espíritu de la transformación Agile.
Como es el caso con tantas otras prácticas de negocios y TI, hay una diferencia entre la comprobación de las cajas y la ejecución adecuada del trabajo: las casillas de verificación están ahí para realizar un seguimiento.
Y me imagino que la mitad de los departamentos de TI que han evitado la trampa agilefall han ido alrededor de la curva en la otra dirección: No están practicando Agile.
Han instituido Haphazard en su lugar, a menudo a instancias de un waterfaller que estaba seguro antes de que todo el esfuerzo comenzado en Agile estaba condenado al fracaso e hizo todo lo posible para asegurarse de que esta. profecía fuera auto-cumplida.
CIO auto-engaño # 3: Estamos haciendo Devops
No, no lo está. Ni siquiera es Agile. ¿No sabe leer?
Bien bien. Si usted debe saber, a pesar de todo el zumbido sobre devops, sus proponentes no inventaron la colaboración.
Agile – lo real, no agilefall – abogó por la colaboración mucho antes de que llegaran los devops aunque, para ser justos, operaciones de TI no eran, generalmente, con quienes los desarrolladores colaboraban.
Esto es lo que devops agrega a la mezcla Agile:
- En primer lugar, los equipos de desarrollo incluyen operaciones de TI, por razones puramente egoístas: no quieren esperar a que sus entornos se construyan y no quieren esperar al CAB para implementar cambios de software.
- En segundo lugar, aporta la automatización en todas partes, una idea realmente buena. Tener que hacer mmanualmente los cambios de software (a ese ritmo) es simplemente tonto.
- La tercera es que, con devops pero no con las variantes más Agile, y ciertamente no con la cascada, el software siempre está en un estado desplegable.
No no no no no. No deplorable. Desplegable.
Entre las muchas realizaciones incómodas para las departamento más Agile esto significa que devops y Scrum no son totalmente compatibles.
Kanban funciona mejor.
Si, lo sé. Siento ser el portador de las noticias tristes.
Pero, si no sabía esto, es tiempo de que despierte: ningún auto-engaño puede durar para siempre.
