¿Cómo explicar devops a gerentes no técnicos?

Estoy totalmente entusiasmado con DevOps. Sé que DevOps es la metodología que nos llevará a construir una infraestructura de TI que racionalizará y hará avanzar a nuestra empresa.
Pero, ¿cómo vendo esto a mis jefes, especialmente a los jefes no técnicos?

Vamos a implementar un proyecto de automatización que incluirá, implementación automatizada, infraestructura en la nube, proceso de integración continua ... definitivamente necesitamos persuadir a nuestros jefes para que inviertan en niveles más altos en esto.

Nota : comenzamos a mejorar nuestro proceso mediante la automatización de pruebas, lanzamientos y supervisión, es un paso hacia la adopción de devOps, pero el proyecto de automatización en sí está en espera, ya que necesitamos más inversión.

Como consultor, estoy obligado contractualmente a responder, "depende". Con eso fuera del camino, puedo responder tu pregunta.

¿De qué depende? Bueno, eso podría resumirse en lo que piensa tu jefe sobre DevOps:

1. Si su jefe ha oído hablar del término, tal vez por su obsesión con CIO.com , pregúnteles qué creen que significa. A partir de ahí, determine cuál es la diferencia y si su punto de vista es compatible. Identifique un proyecto adecuado para probar DevOps y proponérselo. Recuerde que, en el centro, DevOps es cultura, así que considere cómo se podría aplicar a un proyecto.

2. Si su jefe nunca ha oído hablar del término, cree un caso de negocios para DevOps. Use el Estado de DevOps de Puppet Labs y material de libros como The Phoenix Project para escribir el caso de negocios. Encuentre un problema que tenga su jefe y DevOps pueda resolver y úselo como iniciador de conversación. Como dijo Kenchew que no tiene que mencionar DevOps, podría sugerir, por ejemplo, que las operaciones se involucren más en un proyecto o que se planifique más automatización de pruebas como parte de la entrega del proyecto.

3. Si su jefe piensa que DevOps es solo otra palabra de moda, entonces haga una de las anteriores pero no mencione DevOps, mire otros modelos similares como Ingeniería de confiabilidad del sitio, Ingeniería de plataforma o Implementación continua y descubra cómo podrían resolver el problema.

La clave es enfocarse en comprender por qué está motivado su jefe, luego dedicar un poco de tiempo, dinero y personas para tomar medidas tangibles para resolver ese problema.

Recomiendo encarecidamente el libro To Sell Is Human de Daniel H. Pink , fundamentalmente Daniel Pink habla sobre cómo vender algo es algo muy humano, todo lo que tenemos que hacer es aprovechar las necesidades y alinear nuestro "tono" proponiendo un solución que sirve esas necesidades.

Usted no

A pesar de su entusiasmo por DevOps, los jefes no tecnológicos realmente no comparten su fascinación con la jerga tecnológica.

Primero, muestre a sus jefes el beneficio de los pequeños proyectos piloto que ha realizado. Recopile algunos puntos de datos útiles para probar su caso. (Encontré esta pregunta que podría ayudar: ¿Cuáles son algunos métodos para medir el ROI de DevOps? )

Luego, dígale a sus jefes que tiene un proyecto que podría traer más beneficios pero que necesita una pequeña inversión. (Trata de descubrir un proyecto que no permita que tus jefes se caigan de la silla. Debes tener una idea de lo que es esta cifra si has estado trabajando con tus jefes durante un tiempo).

Una vez que obtenga la inversión, haga un excelente trabajo para lograr el objetivo. Mejor aún, ¡superévelo!

Ahora, cuando finalmente los jefes te preguntan "Entonces, ¿qué hiciste que nos trajo tantos beneficios?"

Este es el momento en que proclamas:

"DevOps"

Y solicite más inversión para su próximo proyecto devops.

Cualquier iniciativa de negocios obtendría tracción si muestra su relevancia para la línea superior o inferior de la organización.

Las iniciativas internas como los devops solo pueden afectar el resultado final. Debe identificar los costos del trabajo recurrente realizado por los individuos y cómo la automatización reduciría ese gasto.

A pesar de que los gerentes no técnicos pueden no entender la diferencia entre elegir chef en lugar de títeres, tienen cierta comprensión de las tendencias de la industria. Puede informarles sobre los costos de los retrasos debido a que las compilaciones no están disponibles, los costos de los problemas de regresión y cómo su enfoque puede reducir esos costos. Si puede mostrar un plan tangible de mejora en el resultado final, y si es mejor que los otros elementos de acción en su plato, obtendría un visto bueno.

Mi línea de razonamiento para personas que no están familiarizadas (o simplemente están equivocadas) sobre el término DevOps se reduce a "entregar valor comercial con mayor frecuencia". Esto, en mi experiencia, es algo a lo que muy pocos gerentes pueden oponerse. Ellos lo entienden.

Si dicen algo como "solo necesitamos a alguien para enderezar nuestros devops, probablemente solo unas pocas semanas de trabajo; así que hay un límite sobre cuánto invertiremos en devops en este momento" Solo trato de explicar eso es como decir "no queremos que nuestra empresa ofrezca demasiado valor comercial. Solo necesitamos un poco más, pero eso es todo".

Es solo retórica, por supuesto, pero creo que es efectiva, mucho más que decirles que lean un libro sobre Toyota.

Todo en las respuestas anteriores es cierto, pero creo que faltan algunas cosas para obtener la aprobación y el compromiso de sus jefes (por cierto: la mayoría de las personas solo tienen 1 jefe como máximo ...).

Tarde o temprano el Sr. Murphy vendrá (= Cualquier cosa que pueda salir mal, saldrá mal, y saldrá mal cuando no debería salir mal ). Y en ese momento, algunos jefes querrán obtener respuestas a preguntas como esta:

¿Qué sucedió cuándo y por qué, y qué usuario autorizado realmente lo aprobó ... por adelantado?

Y en ese punto obtendrá el ROI real de las prácticas de DevOps que tendrá implementadas ... Y / o de repente obtendrá todo tipo de aprobaciones presupuestarias enormes para implementar lo que parece estar buscando.

Incluso si le tomara mucho tiempo a Murphy, su empresa también podría encontrarse con requisitos como los que Richard describió en la pregunta " ¿Qué procesos o herramientas permiten la segregación de tareas cuando los ingenieros implementan y ejecutan código? " (Ese tipo de requisitos asustan CxOs ...).

Pero, si alguna vez tiene que presentar "DevOps" a alguien que es nuevo en él, puede ayudarlo a "advertirles" por adelantado como " OK, así que desea comenzar las prácticas de DevOps, ¡genial! Pero tenga en cuenta que es como cambiando a otra religión ... "