Como alterar as políticas existentes em uma organização?

Suponho que uma organização que deseja fazer uma transformação do DevOps tenha alguns problemas e políticas que está interessado em mudar. Esse interesse pode vir dos principais gerentes, gerentes intermediários ou mesmo de baixo para cima. Um dos maiores fatores que impedem essa mudança é levar outras pessoas a comprá-la.

Por exemplo, em muitos casos, o envio de "novas" idéias, como o Agile, geralmente falha. As pessoas resistem à mudança, e parece um muro que impede que coisas boas aconteçam. No entanto, há um mandato para que boas coisas aconteçam.

Quais métodos podem ser usados ​​para afetar os funcionários de uma organização que inicia sua transformação de DevOps? Técnicas e maneiras especialmente específicas que funcionam. Específico como em mais engenharia, menos movimento da mão.

Você precisa entender que os processos mudam as pessoas que os seguem. À medida que as pessoas aprendem, internalizam e melhoram em um processo, isso muda a maneira como aprendem a resolver um problema específico. Um conjunto de processos semelhantes se reforça em uma mentalidade que a pessoa usa para resolver uma categoria de problemas e, eventualmente, formar um conjunto de valores que orienta decisões e novas soluções para novos problemas.

Mesmo se você mudar o processo, sem a mudança de mentalidade e ainda mais crucial para os valores, a pessoa simplesmente adaptará o novo processo para se adequar aos mesmos valores, mesma mentalidade ou mesmo solução que no processo original. Em um determinado momento, não é possível separar essa pessoa nessa posição da mentalidade adquirida ou alterar os valores subjacentes.

Para instituir uma alteração, você tem as duas opções a seguir:

1. Convide uma pessoa que já tenha os valores e a mentalidade certos e, na melhor das hipóteses, entenda o processo que precisa ser seguido sem a sua ajuda.
2. Contrate e capacite o novo funcionário, contratado recentemente, um novo contratado ou a transferência de uma equipe diferente da organização e treine-o no novo processo, na esperança de instilar a nova mentalidade, na esperança de que o novo conjunto de valores apareça.

Se a alteração for local, você pode preferir uma transferência interna, pois essa pessoa já compartilharia os valores globais da empresa que deseja manter. No caso de uma mudança maior, é necessário trazer alguém de fora para ter uma nova perspectiva e não compartilhar os valores amplos da empresa que você pode estar tentando mudar.

A parte importante é capacitar a pessoa, equipe ou unidade de negócios a seguir os processos e isolá-los da equipe antiga, de outras equipes ou do restante da empresa, respectivamente, que ainda podem seguir o antigo conjunto de processos. Como é muito difícil isolar esse agente de mudança da gerência acima, para que a mudança seja maior, muitas vezes é necessário seguir todo o caminho da cadeia de gerenciamento ou percorrer todo o caminho.

Nota : É difícil trazer mudanças para mais do que apenas sua equipe, sem o apoio da gerência. Mesmo dentro da sua equipe, é difícil se outras pessoas já estão no seu caminho. Para uma nova equipe em uma nova empresa, um evangelista bem-sucedido geralmente pode afetar as políticas de formação, mesmo sem o apoio da gerência, simplesmente por ser um líder ou criar o caminho de menor resistência para os outros seguirem. Mas em empresa estabelecida, veja acima.

Hackear sua equipe

Trazer mudanças na sua organização é difícil. As pessoas têm hábitos, resistem à mudança e geralmente se sentem à vontade com o status quo. Para trazer mudanças, em nenhuma ordem específica, aqui estão algumas ferramentas que você pode usar.

1. Faça com que outras pessoas experimentem o problema que o DevOps resolve. Muitas vezes, os benefícios do DevOps são entendidos apenas em nível teórico por sua equipe. A maioria dos problemas que ocorrem durante a implantação é esperada e raramente experimentada pelo restante da equipe ou gerenciamento de desenvolvimento. Para corrigir isso, verifique se você está falando sobre problemas quando eles surgirem e mencione como esse problema não teria acontecido se a equipe estivesse usando uma solução de integração contínua. Outra possibilidade é ter certeza de pedir aos desenvolvedores que corrijam os problemas causados ​​pelo código durante a implantação, em vez de corrigi-lo.

2. Encontre os líderes . É comum que as pessoas sigam os líderes, sejam eles de gerência ou apenas a pessoa mais popular / comandante do grupo. Junte esses líderes a seu desejo de mudar para uma cultura DevOps e crie maneiras públicas pelas quais eles possam ser vistos usando ou defendendo as melhores práticas.

3. Crie confiança . É mais provável que concordemos com as coisas das pessoas depois que já concordamos com elas uma ou duas vezes antes. Idealmente, você pode encontrar pequenas melhorias que podem ser feitas sem uma mudança na cultura e aproveitar esse sucesso. No entanto, se isso não for uma opção, faça perguntas simples e ofereça sugestões simples, para que elas adquiram o hábito de dizer sim ou concordar com você.

4. Não tenha vergonha de se repetir. A repetição funciona e, eventualmente, entra em cena. Sempre que possível, mencione como grandes coisas seriam se a equipe estivesse usando o DevOps. No entanto, isso só funciona se você tiver criado confiança em sua equipe.

5. Torne-o agradável . Se você puder criar uma prova de conceito para a sua situação de DevOps, use emoticons fofos e cores alegres nos relatórios e notificações. Poste gifs engraçados quando uma compilação falhar. Verifique se você não é irritante com suas atualizações.