Como convencer os desenvolvedores da minha equipe a adotar "Você constrói, executa"?

Como convencer os desenvolvedores da minha equipe a adotar "Você constrói, executa"? Por isso, tenho em mente esta citação de Werner Vogels :

A atribuição de responsabilidades operacionais aos desenvolvedores melhorou bastante a qualidade dos serviços, tanto do ponto de vista do cliente quanto da tecnologia. O modelo tradicional é que você leva seu software para a parede que separa o desenvolvimento e as operações, joga-o de lado e depois esquece. Não na Amazon. Você constrói, você executa. Isso coloca os desenvolvedores em contato com a operação diária de seus softwares. Também os coloca em contato diário com o cliente. Esse ciclo de feedback do cliente é essencial para melhorar a qualidade do serviço.

Estou pensando especificamente em um conjunto de desenvolvedores que:

• Foram contratados para uma função de desenvolvedor, com pouca / nenhuma menção de tarefas relacionadas a operações.
• Tradicionalmente, "jogamos código por cima do muro" para uma equipe de operações.
• Tradicionalmente, têm um horário de trabalho de 9 a 5 e são hostis à idéia de "dever de pager", participando da recuperação de desastres, escrevendo post mortem etc., especialmente fora do horário comercial. (Observação: só tenho interrupções muito raras em mente para isso; não estou propondo que adicionemos suporte ao cliente fora do horário comercial à carga de trabalho dessa equipe.)
• Atualmente, não somos responsáveis ​​por escrever / dar suporte ao monitoramento ou alertar sobre seus aplicativos.

Suponha que exista uma equipe que esteja desenvolvendo rapidamente novos microsserviços em nuvem com um perfil que será entregue de tal forma que entregar esses serviços a uma equipe de operações seja subótimo, porque eles não conseguem acompanhar o ganho de conhecimento profundo de os serviços necessários para gerenciá-los e monitorá-los efetivamente. "Você constrói, executa" funcionaria melhor para essa equipe, pois as tarefas poderiam ser delegadas a cada membro da equipe responsável. Portanto, essa equipe começou a participar do projeto de infraestrutura, ferramentas de monitoramento / alerta para os serviços e (com pouca frequência) a responder a eventos de interrupção.

Estou especificamente interessado em metodologias, apoiadas em exemplos do mundo real. Como isso foi implementado com sucesso em outros locais de trabalho e se existem etapas canônicas a serem seguidas durante a implementação? Quaisquer links para artigos que possam dar suporte a respostas seriam muito úteis.

Eu acho que a maneira mais fácil é alterar as metas de desempenho para que elas se baseiem na confiabilidade e no fornecimento de código. Vendê-lo, pois a empresa não pode ter sucesso sem os dois. Por que os desenvolvedores devem ser medidos apenas em um? A melhor maneira de eles atingirem suas metas de desempenho é se envolverem nas operações.

Em última análise, você precisa convencê-los de que essa é a melhor maneira de a empresa ter sucesso e, portanto, de ter sucesso. Isso é difícil e você não pode esperar que eles estejam a bordo desde o início. Eles precisam ser vendidos no valor também.

Quando se trata de afetar a cultura comercial, o melhor caminho é provavelmente através do conhecido método "ferva o sapo". Você precisa apresentar essas tarefas aos desenvolvedores lentamente, porque eu sei que eu (como desenvolvedor) ficaria frustrado por ter toda essa nova responsabilidade ao mesmo tempo.

Primeiro, comece introduzindo uma ou duas novas tarefas apenas para serem executadas durante o horário comercial normal. Eles precisam aprender como fazer devops, o que pode ser o processo de aprendizado de um desenvolvedor apenas de código (até o momento) e pode exigir alguma supervisão. Eles provavelmente também serão hostis à idéia de alterar o equilíbrio entre vida profissional e pessoal, já que você mencionou que eles estão acostumados com o 9-5. Nesse ponto, registre dados sobre os novos processos para uso posterior (peça para que escrevam esse código, os dados são sempre úteis).

Posteriormente, quando você estiver sem novas tarefas de devops-y a serem introduzidas (para que o primeiro, o segundo e o quarto pontos estejam quase completos), traga as primeiras tarefas que você apresentou como candidatas a serem executadas fora do horário normal de trabalho . Você pode ver uma reação negativa a isso e pode até perceber algum desgaste, dependendo de quão fortemente você pressiona isso e de quanto a cultura do trabalho às cinco está arraigada. Para se defender, esperamos que seus dados apóiem ​​a idéia de que o trabalho além do horário padrão será raro, ocorrerá apenas em situações extremas e beneficiará muito os negócios e o cliente. Se seus dados não suportam isso, é melhor você estar pronto para lidar com as consequências dessa escolha.

Mesmo com os dados, ainda pode ser mais fácil fazer com que os desenvolvedores escrevam o código de monitoramento / alerta (para que se tornem dev ops, mas ainda principalmente dev) e mantenham a equipe de ops alternativa como suporte de linha de frente (como alguns outros sugeriram). Como eu disse, pequenas mudanças são importantes para evitar reações adversas. A integração do trabalho para desenvolvedores além do horário padrão será desafiadora, pois eles podem saber que podem procurar emprego em outros lugares se não gostarem, pois o mercado para desenvolvedores está forte agora, especialmente se eles já tinham habilidades em desenvolvedores. Advertência emptor!

Olhando para fora do DevOps especificamente, se você estiver falando de ambientes corporativos grandes (ish), a metodologia SAFe tem uma maneira bastante boa de incentivar esse tipo de comportamento.

Essencialmente, tudo se resume a alguns estágios-chave:

• os projetos começam como trens de liberação. A intenção (e a expectativa de quem a está financiando) é que isso seja demorado. Estou falando há muitos anos, nada disso "levante uma equipe por 3 meses e depois diminua" os negócios.

• durante o curso de um projeto, o trem de liberação inevitavelmente acumulará mais pessoas, uma vez que mais dos novos requisitos do projeto são baseados em oportunidades de negócios recém-realizadas, bem como nos impostos em andamento do trabalho no estilo de manutenção.

• Quase sempre vejo os trens executando seu primeiro incremento como equipes de projeto / mudança de 100%; no segundo incremento, eles alocam uma porcentagem de tempo para executar o trabalho. O gerenciamento do 3º incremento percebe que está prestes a ter um problema e começa a adicionar equipes para tentar lidar com o estouro de execução, dando aos desenvolvedores e engenheiros agora experientes tempo para continuar trabalhando nos novos requisitos.

• se o equilíbrio certo for alcançado, as equipes do projeto poderão continuar entregando os resultados do projeto sem se atrapalharem muito com o trabalho de manutenção, e não se espera que novas equipes que se juntem ao trem sejam apenas 100% de equipes de suporte, mas, em vez disso, assuma um parte justa do trabalho de mudança que seria gerenciado, você acaba com as equipes de entrega que possuem os produtos que estão construindo por padrão; não é necessário abordar todos de uma vez que agora eles são uma equipe de execução, em vez disso, ele se integra lentamente às atividades do dia a dia.

Onde esse modelo obviamente apresenta alguns pontos fracos está nos preços de uma empresa. Geralmente, eu esperaria pagar muito mais por um recurso de alteração do que por um recurso de execução, normalmente contratos com grandes fornecedores têm preço fixo e a intenção é que eles ganhem dinheiro com melhorias contínuas e, portanto, economia de custos.

Dito isto, não é tão difícil considerar que as equipes de mudança se levantaram como parte de um trem de liberação para simplesmente oferecer melhorias contínuas. Se houver algo que eles possam construir ou fazer que melhore sua capacidade de se concentrar nas entregas de novos projetos e se preocupem menos com o trabalho "comercial como de costume", isso deve ser acumulado e priorizado com base nos benefícios percebidos por quem detém o dinheiro para o projeto. solte o trem.

IMHO You build it, you run itnão deve ser tomado literalmente. Para começar - parece quase um castigo;)

Nenhuma pessoa, nem mesmo uma pequena equipe de desenvolvedores, pode oferecer suporte razoável a uma ferramenta ou conjunto de ferramentas usado no processo de desenvolvimento de software (ou seja, na produção!) Por longos períodos de tempo. Estive lá, fiz isso :)

As tarefas de suporte tendem a se expandir à medida que a base de clientes da ferramenta (definida) cresce. Se assumindo essas funções exclusivamente, a equipe de desenvolvimento pode acabar dando apoio principalmente, com pouco / nenhum tempo sobrando para o desenvolvimento no futuro. Efetivamente, um beco sem saída - quantos desenvolvedores gostariam de permanecer nesse ambiente?

Ter uma 1ª linha profissional de equipe de suporte é crucial para evitar frustração, estresse e outros efeitos da exposição a longo prazo para dar suporte aos deveres dos membros da equipe de desenvolvedores.

A equipe de suporte da 1ª linha, é claro, recuaria para a equipe de desenvolvedores (novamente, equipe, não uma pessoa!) Para problemas que não podem cobrir diretamente. Sim, pode ser difícil no começo, mas as coisas vão melhorar. Deve ser uma colaboração - é parte do objetivo do DevOps.

Em última análise, isso depende do tamanho e da estrutura da empresa. Existem realmente três estágios em que sua empresa pode estar:

1. O estágio de inicialização (menos de 150 engenheiros). Obviamente, os desenvolvedores precisam executar seu próprio software. Todo mundo faz isso em uma inicialização. Você pode até não ter uma equipe de operações, mas mesmo assim, é pequeno e a velocidade do progresso é tão rápida que não há como passar o conhecimento necessário para executá-lo com êxito em outra equipe com rapidez suficiente para que eles ser bem sucedido.

2. A empresa de médio porte (mais de 150 engenheiros, mas uma única equipe de operações). Nesse estágio, a rotatividade na empresa começa a ser muito alta, os engenheiros que constroem o software não ficam necessariamente por perto também para executá-lo. Você não conhece mais todo mundo e é difícil se comunicar efetivamente para que todos estejam em operações. Começaria a se transformar em caos. Nesta fase, você deseja recorrer ao modelo do Google, onde toda equipe precisa operacionalizar seu software, mas não necessariamente operá-lo. Eles irão operá-lo no início, mas uma grande parte da criação de software é reduzir o custo de operação até certo ponto, onde a carga é pequena o suficiente para que a equipe de operações possa assinar ao executá-lo. Só então é considerado feito.

3. Empresa de grande porte com várias unidades de negócios (onde cada uma possui sua própria equipe de operações): nesse estágio, você pode voltar ao modelo da Amazon, onde cada equipe essencial desenvolve e opera seus próprios serviços. Cada uma das unidades de negócios deve ser pequena o suficiente para que todos se conheçam, portanto, com cerca de 150 engenheiros e você opera cada um essencialmente como uma startup. A Amazon tem cada serviço da AWS operando mais ou menos separadamente e funciona para eles.

Você precisa descobrir em que estágio sua empresa está e / ou entrar e agir de acordo. Não existe uma solução "tamanho único".

Minha opinião sobre isso (se eu fosse confrontado com esse mandamento, ou como você o chama), seria algo como " What else would you expect?!?!". Porque, acidentalmente:

• Eu nem seria capaz de viver sem ele, e
• Eu amo comer minha própria comida (cachorro).

Deixe-me explicar um pouco mais ...

Meu negócio / hobby / paixão é scm , mais especificamente em ambientes de mainframe . E onde quer que eu vá (para ajustar as coisas para atender às necessidades dos clientes), o primeiro requisito que eu imponho (no meu contrato) é que qualquer ajuste feito no sistema que implementamos seja através do mesmo sistema. E, ao fazer isso (é verdade, isso leva algumas horas, digamos, meio dia no máximo), obtemos esses benefícios (lista incompleta):

• Quase não documento nada do que fiz para ativar o sistema. Se alguma pergunta for feita, basta consultar o sistema (e ensinar o cliente a consultar o sistema sem minha ajuda).
• Se eu for chamado em X meses / anos (para atualizar para uma nova versão?), Quero saber (lembrar) o que "eu" já fazia antes (e a única coisa em que confio é o que o sistema me diz, também conhecido como me lembra sobre).
• Eu só preciso perguntar ao cliente uma vez sobre como fazer coisas específicas em seu site (é difícil lembrar as convenções de nomenclatura) ou convencê-lo a conceder as permissões necessárias ao "sistema" (não para mim ...).
• Você está continuouslytestando o controle de qualidade do seu próprio sistema ... em produção. As chances são de que você encontrará bugs, erros lógicos ou recursos ausentes (e o que não). E esses são extremamente motivadores para abordá-los o mais rápido possível ... por exemplo, para se tornar mais produtivo.
• ... e se você quiser, posso adicionar outra dúzia de razões ...

No entanto, antes de tentar fazer isso em casa, lembre-se de algumas armadilhas a serem evitadas:

• você quer que todos participem da festa (use o sistema), porque apenas uma "exceção" (também conhecida como gerente / proprietário da empresa?) pode arruinar a festa (você acha que pode confiar no seu sistema, mas alguém fez algo sem perguntar / usar o sistema). Nesse caso, pode custar-lhe dias para descobrir ...
• novos usuários podem reclamar que, usando esse (novo) sistema, eles levam muito mais tempo para realizar seu trabalho (em comparação com o que eles usavam antes). E sempre que fizer sentido, eles usarão isso como desculpa para se atrasarem para concluir seu trabalho. Nesse ponto, é melhor você ter uma gerência superior cobrindo você, porque, caso contrário, seu projeto / sistema poderá ser responsabilizado.
• verifique se você conhece seu próprio sistema e como configurá-lo para atender às suas necessidades. Como uma amostra (no meu caso): você deseja configurar o sistema para usar o ambiente operacional para entregar ao seu ambiente experimental, e não o contrário ... Vi isso acontecendo no passado ... usando (abusando) do sistema de teste para entregar em ambientes altamente seguros.