🎳 👷🏻 👨🏻‍✈️ "O que fazer quando mudanças drásticas nos processos desmotivam uma equipe". A experiência do engenheiro de back-end que se tornou líder de equipe ☕️ 💺 ✋🏽

Durante 7 anos, trabalhei como engenheiro de back-end no Miro e depois me tornei líder de equipe. Nos últimos anos, nossa equipe de engenharia dobrou, tornou-se distribuída e internacional, o que implicou muitas mudanças.

Uma delas foi a introdução de equipes multifuncionais que poderiam resolver o problema completamente, desde o desenvolvimento da idéia até o lançamento dos recursos. Para isso, os engenheiros de back-end e front-end tiveram que aprender rapidamente muito do que nunca havíamos feito antes: testar, trabalhar com lançamentos, realizar rituais de scrum - sem perder velocidade e qualidade.

Os primeiros passos nessa direção levaram a um aumento no número de erros, uma diminuição na velocidade de desenvolvimento e desmotivação das equipes. Durante esse período difícil, eu acabei de me tornar um líder de equipe, então meu medo pessoal de fracassar e minha própria incompetência aumentaram o estresse geral.

Como resultado, lidamos com a tempestade, reduzimos o tempo de espera pela metade e avançamos significativamente na eficácia das equipes multifuncionais. Isso foi amplamente ajudado por uma mudança de atitude em relação às mudanças em andamento, a transição da mentalidade fixa para a mentalidade de crescimento.

Abaixo está um vídeo e uma transcrição do meu desempenho no Saint TeamLead Conf 2019, onde, usando minha equipe como exemplo, falo sobre os processos e ferramentas que tornaram possíveis essas alterações.

História nº 1. Alterando o processo de desenvolvimento para reduzir o lead time

Em 2016, nosso desenvolvimento consistiu em 20 pessoas e 5 equipes. As equipes interagiram efetivamente entre si, trocaram rapidamente informações e experiências. Com o crescimento de funcionários e equipes, a introdução de processos de CI / CD e revisões de código, o número de interdependências entre equipes aumentou.

Por exemplo, para lançar um grande recurso em um produto, a equipe precisava trabalhar com mais 6 equipes de engenharia:

Dê código à revisão do código.
Dê um recurso ao teste de controle de qualidade. Se necessário, o controle de qualidade incluirá o comando DevOps para criar um ambiente de teste especial.
Alivie o recurso usando o gerenciador de lançamento, responsável por todos os lançamentos na empresa.
Conecte comandos adicionais se algo der errado durante o lançamento.

E isso sem levar em consideração as dependências das equipes de marketing, design e suporte técnico, que também estão ativamente envolvidas no lançamento dos recursos.

Quanto mais dependências, mais Lead Time, ou seja, o tempo desde o início do desenvolvimento até o lançamento. Quanto maior o tempo de entrega, menos valor agregamos aos usuários.

Um grande número de comunicações e baixa velocidade de entrega desmotivam a equipe. O que fazer? Reduza dependências e reduza o tempo de entrega.

Estamos tentando construir um transportador em desenvolvimento

Para resolver esse problema, tentamos primeiro construir um transportador:

Descreva todas as etapas e processos;
introduzir SLA (Service Level Agreement, nível de qualidade exigido) para determinar o tempo pelo qual a tarefa deve passar por cada estágio;
endireite os fluxos para impedir que a tarefa recue para os estágios anteriores para melhorias.

Infelizmente, o pipeline não funcionou: um erro em qualquer estágio levou à suspensão de toda a cadeia, enquanto cada equipe foi forçada a resolver problemas a partir de sua própria lista de pendências. Por exemplo, o controle de qualidade precisava escolher: lidar com um bug no pipeline ou envolver-se em tarefas para melhorar o processo de teste. Esse problema de priorização levou ao fato de que lançamos recursos, mas não tivemos tempo para melhorar processos internos ou estávamos envolvidos na otimização de processos e não tivemos tempo para liberar recursos.

Decidimos reconstruir o transportador para movê-lo dentro de cada equipe.

Tentando construir equipes multifuncionais

As equipes multifuncionais são capazes de lidar com a tarefa do começo ao fim: desde a elaboração da idéia até a colocação do recurso final no produto. Para isso, a equipe precisa ter dentro de todas as competências, conhecimentos e processos necessários.

Decidimos realizar um experimento em várias equipes antes de lançar as alterações para toda a empresa. Minha equipe também entrou no experimento, que lida principalmente com tarefas de baixo nível ( escrevi sobre um de nossos exemplos de trabalho - implementação do ActiveMQ e Hazelcast). A equipe consistia em 3 desenvolvedores de back-end, um engenheiro de controle de qualidade em período parcial e eu como líder da equipe.

Determinamos as interdependências

Primeiro, determinamos as dependências atuais das quais queremos nos livrar:

Não há engenheiro de controle de qualidade em tempo integral, pelo que podemos esperar o teste de alguns dias a uma semana.
, -.
full-time -, , .

Havia outras dependências, mas decidimos nos concentrar principalmente nas três. Agora, precisávamos aprender muito com o que o engenheiro de QA, o Scrum master e o gerente de lançamento fizeram antes.

Aprendemos a testar de forma independente.Antes
, os engenheiros escreviam testes de unidade de forma independente e testavam a funcionalidade básica, o restante verificava o controle de qualidade. Agora, aprendemos como testar situações limítrofes de forma independente e escrever testes de ponta a ponta para testar a interação entre o cliente e o servidor.

Aprendendo a se libertar
Concordamos que queremos nos libertar pelo menos uma vez por semana. Para fazer isso, precisamos de um gerente de liberação dentro da equipe. Um dos desenvolvedores de back-end tornou-se por vontade própria.

Realizamos rituais de scrum por conta própria
O scrum master externo não teve tempo para lidar com todas as equipes; portanto, dentro da nossa equipe, escolhemos aquele que desejava esse papel. Ele precisava aprender a realizar de forma independente o planejamento, a aparência e o estilo retro.

Naturalmente, ninguém nos jogou nas barricadas. O controle de qualidade, o gerente de release e o scrum master transmitiram conhecimento e aconselharam em casos difíceis.

Primeiras falhas

Os resultados do primeiro sprint não tiveram êxito. Nós realmente começamos a trazer tarefas para o ramo principal muito mais rapidamente, mas não conseguimos fazer um único lançamento independentemente. Aconteceu que nossos processos e scripts não estavam prontos para isso. O script de lançamento conseguiu liberar apenas todos os serviços de cada vez, portanto, não foi possível liberar nossa parte do serviço separadamente.

Torcemos uma parte dos processos e, no final do segundo sprint, colocamos as tarefas do primeiro sprint no release. No entanto, algo deu errado novamente. Metade da funcionalidade lançada continha bugs críticos, por isso decidimos reverter o lançamento. E eles enfrentaram um novo problema: nosso desenvolvedor de back-end e gerente de liberação de meio período da equipe aprenderam a liberar, mas ainda não aprenderam a reverter as alterações. Portanto, precisávamos da ajuda de um gerente de versão externo.

Tudo isso levou à desmotivação da equipe: falhamos no segundo sprint consecutivo, liberamos funcionalidades com erros críticos - a sensação de que não podemos fazer nada sozinhos.

História nº 2. Um novo papel e medo do erro

No início do experimento com equipes multifuncionais, Max, um dos engenheiros de back-end, se ofereceu para se tornar um scrum master. No entanto, após o primeiro sprint, ele veio até mim e disse que não queria mais ser um mestre de scrum. Seguindo Max, veio Andrei, outro engenheiro, e disse que não iria testar: "Sou desenvolvedor, não testador". Como líder de equipe, era importante para mim entender as causas de ambas as falhas.

Como regra, um dos quatro motivos que podem funcionar com cada um deles é a pedra angular da decisão de abandonar a tarefa:

   → , , .
(, , ) → , .
  , → : , .
   → .

Max entendeu o valor que o scrum master traz para a equipe, mas tinha medo de não lidar com as tarefas difíceis de facilitar as reuniões. Concordando com uma nova função, ele sabia pouco sobre o trabalho do scrum master e não se deu um relato completo das habilidades necessárias para isso. Max estava com medo de não conseguir lidar, perderia o tempo da equipe e pareceria incompetente aos olhos de seus colegas.

Na situação com Andrei, ele testou seu código por conta própria e teve certeza de que estava tudo bem. No entanto, por precaução, dei controle de qualidade para verificação e ele encontrou 5 erros no código. Isso foi repetido várias vezes, o que desmotivou Andrei, e ele decidiu não fazer mais testes.

Eu conhecia bem as situações de Max e Andrei. Recentemente, eu mesmo passei de um engenheiro de back-end experiente para um líder de equipe inexperiente. E, como tinha medo de não conseguir lidar com as tarefas, não cumpria as expectativas e, em geral, a liderança de equipe não era minha.

Instalação em crescimento e instalação em um determinado

Quando me tornei líder de equipe, fui aconselhado a ler o livro “ Consciência Flexível ” pela professora Carol Dweck, da Universidade de Stanford . Em resumo, descreve dois tipos de pensamento:

Mentalidade fixa - a crença de que inteligência e habilidades são fixadas de uma vez por todas, é impossível influenciá-las, e o fracasso indica falta de talento. Pessoas com esse pensamento tentam não realizar tarefas complexas para não perder a motivação e a fé em si mesmas.
A mentalidade de crescimento é a crença de que a inteligência e as habilidades podem ser aprimoradas ao longo da vida se forem feitos esforços para isso. O fracasso é uma razão para aprender alguma coisa, para que pessoas com esse tipo de pensamento estejam constantemente tentando sair da zona de conforto e assumir tarefas complexas.

Naturalmente, o mundo não é dividido em preto e branco; em diferentes situações, a mesma pessoa pode ser dominada por um tipo diferente de pensamento. Por exemplo, uma pessoa pode considerar que a programação é uma habilidade que qualquer pessoa pode aprender, mas, ao mesmo tempo, acredita que cozinhar deliciosamente é um talento inerente à natureza, e isso não pode ser aprendido.

Todo o esquema está no site da Carol Duque.

Essa abordagem descreve a atitude de uma pessoa em relação às mudanças que estão ocorrendo.

Pessoas com predominância de mentalidade fixa (configuração garantida)
: « , ».
, . , , .

Growth mindset ( )

, , .
, .
, .

Essa abordagem me ajudou a mudar minha atitude em relação aos erros. Portanto, decidi falar sobre a abordagem da equipe, pois ela poderia nos dar um sistema de coordenadas único, nos ensinar a tratar as mudanças de maneira diferente e reduzir o medo de erros. Como qualquer ferramenta, a orientação ao crescimento trabalha para resolver problemas específicos, por isso falei sobre isso nas reuniões 1: 1 para fornecer a todos as informações que seriam úteis para ele especificamente para resolver sua situação.

Além disso, contei a todos da equipe sobre o meu próprio exemplo de trabalho com configurações no momento de mudar de cargo de engenheiro para líder de equipe. Isso aumentou o resto da autoconfiança (“eu não fui o único a encontrar isso”, “é realmente possível mudar essa situação”).

Continuação da história número 2

Um experimento reduz as expectativas e o estresse. Após discutir a abordagem com a mentalidade Growth & Fixed, concordamos com Max em lançar um experimento no qual ele tentará um novo papel como mestre de scrum. A palavra "experimento" reduz bem o grau de estresse. No experimento, não é assustador cometer erros, mas é importante fazer o trabalho com os erros e fazer uma experiência útil. Na mesma linha, falamos sobre o novo papel de Max na equipe, o que diminuiu as expectativas da equipe.

Talento é experiência adquirida.Andrei, ao discutir sua recusa em testar, abandonou a frase: "Sou talentoso em programação". Aconteceu que Andrei considerava a programação e o teste talentos inatos. Ele teve o primeiro, mas não o segundo. Começamos a discutir a experiência de Andrei e percebemos que ele passava pela programação por noites sem dormir em busca de erros, dias de imersão em projetos de outras pessoas, escrevia dezenas de milhares de linhas de código por conta própria. Acontece que sua experiência em programação não é um talento, mas uma experiência para a qual ele passou muito tempo e de propósito. Apenas aprendendo algo, muitas vezes esquecemos os primeiros passos dados nessa direção.

OKRs pessoais.Para tornar nosso progresso visível, mesmo com um ligeiro avanço, concordamos com a equipe que acompanharemos o progresso de cada treinamento. Isso ajudará não apenas a ver o caminho percorrido, mas também a entender quanto mais você precisa ir para o objetivo pretendido.

No nível da empresa, temos OKRs, por isso decidimos aplicá-lo ao nível de treinamento pessoal. As condições foram as seguintes:

Adicionamos aos OKRs pessoais apenas o que ajuda no trabalho atual;
Os principais resultados devem ser mensuráveis a qualquer momento e ajudar a responder à pergunta “Até onde progredi em comparação com a semana passada?;
Cada resultado principal possui uma lista de iniciativas que permitem que seja alcançado;
(, ), , ;
OKRs 1:1.

Implementando OKRs pessoais para o trimestre
Algumas semanas após o lançamento da iniciativa, percebemos que nada estava acontecendo. Descobrimos que ficamos por nossa conta - exageramos nossas próprias expectativas. A equipe estava preocupada com o fato de que era necessário fazer OKRs ideais por um longo tempo e isso era um estupor.

Então concordamos que consideraríamos isso uma das iterações. Os OKRs sempre podem ser revisados e refinados, isso não é algo esculpido em pedra, mas apenas a direção que você deseja desenvolver. Isso ajudou a perceber a iniciativa como um jogo interessante, e tudo correu.

Exemplo de OKRs de Andrey

Bonus, concordamos em compartilhar OKRs pessoais dentro da equipe. Ajuda a aprender um com o outro e funciona como uma confirmação pública.

Continuação da história número 1

Graças a uma mudança de atitude, em retrospetos, começamos a procurar as causas das dificuldades em nós mesmos, e não fora. Agora não havia desculpas que poderiam ter soado antes: "Então o processo é construído, o que posso fazer". Começamos a refinar processos que não nos convinham. A equipe teve uma sensação de propriedade dos processos em andamento.

Isso nos permitiu começar a implementar de maneira estável um pequeno número de tarefas. Embora fosse metade do que era antes, mas a vendemos de forma totalmente independente e sem bugs.

Tudo isso nos adicionou autoconfiança. Depois de algum tempo, Andrey automatizou independentemente casos de teste complexos. Roma, responsável pelos lançamentos, otimizou o processo para que cada membro da equipe agora possa ser lançado independentemente.

Como resultado, com base nos resultados do trimestre, conseguimos reduzir o lead time em 2 vezes devido à redução de dependências, aumento de competências dentro da equipe e mudança de atitude em relação a dificuldades e erros.

Nossa produtividade é afetada não apenas pelos conhecimentos e habilidades que possuímos agora, mas também pela maneira como nos relacionamos com as mudanças na empresa. Às vezes, novos processos podem desmotivar e tarefas muito complexas podem minar a autoconfiança. Mas com isso, você pode trabalhar tanto para você quanto para o nível de toda a equipe.

Minha equipe foi ajudada a lidar com as mudanças e atitudes em relação aos erros da mentalidade Crescimento e Fixo. Nós o tratamos como uma ferramenta de trabalho que resolve problemas específicos. Obviamente, a instalação não mudou em poucas semanas e meses. Mas, mudando a atitude para situações específicas, conseguimos avançar significativamente no trimestre em relação às tarefas e dificuldades diárias do trabalho.

"O que fazer quando mudanças drásticas nos processos desmotivam uma equipe". A experiência do engenheiro de back-end que se tornou líder de equipe