¿Cómo cambiar las políticas existentes en una organización?

Supongo que una organización que desea hacer una transformación DevOps tiene algunos problemas y políticas que le interesa cambiar. Este interés puede provenir de los gerentes superiores, gerentes intermedios o incluso de abajo hacia arriba. Uno de los factores más importantes que impiden este cambio es hacer que otras personas compren para hacer el cambio.

Por ejemplo, en muchos casos, impulsar ideas "nuevas" como Agile, a menudo falla. La gente se resiste al cambio, y parece un muro que impide que sucedan cosas buenas. Sin embargo, hay un mandato para que sucedan cosas buenas.

¿Qué métodos se pueden usar para afectar a los empleados de una organización que comienza su transformación DevOps? Especialmente técnicas y formas específicas que funcionan. As-in específico más ingeniería, menos agitación de la mano.

Tienes que entender que los procesos cambian a las personas que los siguen. A medida que las personas aprenden, se internalizan y mejoran en un proceso, cambia la forma en que aprenden a resolver un problema en particular. Un conjunto de procesos similares se refuerzan mutuamente en una mentalidad que la persona usa para resolver una categoría de problemas y eventualmente forma un conjunto de valores que guía las decisiones y las nuevas soluciones a los nuevos problemas.

Incluso si cambia el proceso, sin el cambio en la mentalidad y aún más crucial para los valores, la persona simplemente adaptará el nuevo proceso para ajustarse a los mismos valores, la misma mentalidad o incluso la misma solución que en el proceso original. En cierto punto, no es posible divorciar a esta persona en esta posición de la mentalidad adquirida o cambiar los valores subyacentes.

Para instituir un cambio, tiene las siguientes dos opciones:

1. Traiga a una persona que ya tenga los valores y la mentalidad correctos y, en el mejor de los casos, comprenda el proceso que debe seguirse sin su ayuda.
2. Traiga y capacite a un nuevo empleado, ya sea recientemente contratado, un nuevo empleado o una transferencia de un equipo diferente en la organización y capacítelo en el nuevo proceso, con la esperanza de inculcar la nueva mentalidad, esperando que surja el nuevo conjunto de valores.

Si el cambio es local, es posible que prefiera una transferencia interna ya que esa persona ya compartiría los valores globales de la compañía que desea retener. En caso de un cambio mayor, debe traer a alguien de afuera para tener una perspectiva fresca y no compartir los valores generales de la compañía que podría estar tratando de cambiar.

La parte importante es capacitar a la persona, el equipo o la unidad de negocios para que sigan los procesos y los aíslen del equipo anterior, de otros equipos o del resto de la empresa, respectivamente, que aún podrían seguir el conjunto de procesos anterior. Como es muy difícil aislar a dicho agente de cambio de la administración anterior, para que el cambio sea más grande, a menudo necesita seguir toda la cadena de administración o llegar desde la parte superior.

Nota : Es difícil llevar el cambio a algo más que a su equipo sin el apoyo de la administración. Incluso dentro de su equipo es difícil si otros ya están establecidos en su camino. Para un nuevo equipo en una nueva empresa, un evangelista exitoso a menudo puede afectar las políticas de formación, incluso sin el apoyo de la gerencia, simplemente por ser un líder o crear el camino de menor resistencia para que otros lo sigan. Pero en una empresa establecida, ver arriba.

Hackea tu equipo

Lograr cambios en su organización es difícil. Las personas tienen hábitos, se resisten al cambio y a menudo se sienten cómodas con el statu quo. Para lograr un cambio, sin ningún orden en particular, aquí hay algunas herramientas que puede usar.

1. Hacer que otros experimenten el problema que resuelve DevOps. Muchas veces los beneficios de DevOps solo son comprendidos a nivel teórico por su equipo. La mayoría de los problemas que ocurren durante el despliegue se esperan y rara vez se experimentan por el resto del equipo de desarrollo o la administración. Para solucionar esto, asegúrese de expresarse sobre los problemas cuando surjan y mencione cómo este problema no habría sucedido si el equipo estuviera utilizando una solución de integración continua. Otra posibilidad es asegurarse de solicitar a los desarrolladores que solucionen los problemas que su código causó durante la implementación en lugar de solucionarlo usted mismo.

2. Encuentra los líderes . Es común que las personas sigan a los líderes, ya sean gerentes o simplemente la persona más popular / dominante en el grupo. Haga que esos líderes se sumen a su deseo de pasar a una cultura DevOps e idee formas públicas en las que se los pueda ver utilizando o abogando por las mejores prácticas.

3. Construir confianza . Es más probable que estemos de acuerdo con las cosas de las personas después de haberlas acordado una o dos veces antes. Idealmente, puede encontrar pequeñas mejoras que se pueden hacer sin un cambio en la cultura y construir sobre ese éxito. Sin embargo, si esa no es una opción, hágales preguntas simples y ofrezca sugerencias simples para que se habitúen a decir que sí o estar de acuerdo con usted.

4. No te avergüences de repetirlo. La repetición funciona y eventualmente se hunde. Siempre que sea posible, mencione cuán grandiosas serían las cosas si el equipo estuviera usando DevOps. Sin embargo, esto solo funciona si primero ha creado confianza en su equipo.

5. Hazlo placentero . Si puede crear una prueba de concepto para su situación de DevOps, use emoticones lindos y colores alegres en los informes y notificaciones. Publica gifs divertidos cuando falla una compilación. Asegúrate de no molestar con tus actualizaciones.