Táticas de Liderança em Engenharia: Construindo Alinhamento
Esse post foi traduzido automaticamente do inglês. Se você encontrar algum erro, por favor entre em contato.
Mudança faz parte do dia a dia de um Engineering Manager (EM). Pode ser porque o EM está tentando melhorar os resultados de entrega ou a qualidade do time. Ou pode ser porque está tentando fazer melhorias que afetam a organização de forma mais ampla.
Já discuti a implementação de mudanças em alto nível anteriormente. Gostaria de aprofundar algumas táticas que usei no passado. Como conseguir alinhamento em diferentes níveis?
Alguns pensamentos iniciais
Embora existam muitas táticas para influenciar mudanças no seu time e na organização, há duas premissas que serão verdadeiras em qualquer situação.
Métricas são suas aliadas
Independentemente do que um EM esteja tentando resolver, se ele tiver métricas demonstrando a situação atual e puder usá-las para acompanhar o resultado das melhorias, isso ajudará significativamente o esforço. Quantificar o problema e o impacto do trabalho vai facilitar a obtenção de adesão e a compreensão de se a melhoria está alcançando os resultados esperados.
Obter métricas é mais fácil na teoria do que na prática. No entanto, embora seja difícil encontrar medições precisas para melhoria de processos, geralmente é possível encontrar estimativas boas o suficiente para usar como norte. Entre controle de versão, chats do time, sistema de tickets e pesquisas, a maior parte do trabalho de um time de software pode ser quantificada quando necessário.
Documentação de processos ajuda na estabilidade
Ao olhar para Sistemas de Produção Lean, um dos equívocos comuns é que a definição de processos leva à rigidez. A suposição é que, se um processo está documentado, ele será menos flexível e mais difícil de mudar. Curiosamente, o pensamento por trás de processos documentados no Lean é justamente permitir a melhoria contínua. A ideia é que um time não pode melhorar um processo a menos que ele seja estável. Caso contrário, como a melhoria poderia ser verificada?
Em geral, vejo times de software evitando documentar processos e confiando em conhecimento tribal para manter a operação do time. Sem entrar muito nos prós e contras dessa abordagem, será benéfico para um time ter a área-alvo documentada e estável ao tentar melhorar um sistema. Isso facilitará demonstrar a mudança que foi feita e manter o novo estado após a melhoria ser implementada.
As Táticas
Com os pensamentos acima em mente, existem algumas abordagens diferentes que usei no passado para situações distintas. Vamos analisá-las.
Conduzindo mudanças com o time: Improvement Kata
O Improvement Kata é uma ferramenta simples em um quadro visual para acompanhar melhorias e colaborar com outros nelas. Embora a ferramenta possa ser aplicada em diferentes situações, quero discutir seu uso para alinhar um time em torno de melhorias.
Um improvement kata é mais útil quando se trata de um esforço de melhoria contínua onde os problemas são visíveis e geralmente claros para todos os envolvidos. Por exemplo, se o time está alinhado que qualidade é um problema e está fazendo um esforço para melhorá-la.
Nesse caso, um processo simples é se reunir regularmente e alinhar experimentos a serem tentados, medir seus resultados e então iterar ou pivotar a partir daí. Esse processo ajuda todos a participarem do esforço e mantém o time focado em poucas mudanças por vez, levando a melhores resultados.
Ao usar um improvement kata:
- Crie um momento regular onde o time analisa o quadro. Pode ser parte das retrospectivas ou uma reunião regular com todos os envolvidos.
- Atribua responsáveis para as melhorias e remova itens do quadro se ficarem parados. É melhor admitir que algo não está avançando e ser consistente em trabalhar ativamente no que está no quadro.
Criando alinhamento com o time: Construindo consenso
E em situações onde o consenso ainda não existe? O EM (ou qualquer outra pessoa) pode perceber um problema não reconhecido ou ter uma ideia de solução na qual o time ainda não acredita.
Nessas situações, achei útil conduzir a conversa individualmente antes de expô-la a um grupo maior. Isso me permitiu entender diversas perspectivas e adaptar a solução a elas, garantindo que todos se sentissem ouvidos.
Existe uma palavra em japonês, Nemawashi, que é o processo de preparar o terreno para uma mudança proposta. O artigo da Wikipedia discute evitar constrangimentos como o objetivo de usá-la. Para mim, tem sido mais útil para evitar resistência em mudanças propostas.
Ao construir consenso dentro do time:
- Espere os problemas acontecerem, pois isso pode ajudar a catalisar a intenção de resolvê-los.
- Seja paciente. Às vezes não será possível encontrar alinhamento, e esperar é melhor do que tentar forçar uma mudança.
Propondo mudanças mais amplas: Usando Documentos
Embora conversar com pessoas individualmente possa ser muito útil, às vezes há gente demais para conversar. Esse é o caso quando alguém tenta sugerir mudanças mais amplas ou de longo prazo. Além do número de pessoas para discutir uma ideia, em esforços mais longos, é difícil manter a proposta consistente ao longo de múltiplas conversas informais durante muitos meses.
É aqui que documentos se tornam uma excelente ferramenta. Ter uma proposta escrita ajudará a obter feedback amplo e alinhamento sobre o problema percebido e a solução. Ter o raciocínio documentado também permite que a proposta evolua com o tempo, mantendo o registro das decisões ao longo do caminho.
Existem múltiplas opções em termos de formato. Meu padrão é criar documentos baseados no formato A3 Thinking, que é excelente para explicar todo o contexto de uma melhoria. Também é interessante acompanhar o estado das propostas ao longo do tempo, e um processo de RFC pode ser valioso para isso.
Ao usar documentos para propor mudanças:
- Foque em manter o ritmo. Isso significa solicitar feedback, iterar no documento e propor ações conforme o esforço progride. É fácil para todos esquecerem propostas quando estão em um documento que não está no topo das prioridades deles.
- Seja claro e verifique quando acreditar que há alinhamento suficiente para seguir em frente. É fácil para as pessoas estarem desalinhadas, levando à frustração entre quem não se sentiu ouvido.
A parte mais importante
As táticas acima podem fornecer um caminho para muitos tipos de melhoria. No entanto, é essencial lembrar de alguns princípios ao aplicar qualquer uma delas.
Propor mudanças e conseguir consenso não é o objetivo. O objetivo é melhorar o sistema. Embora essas táticas ajudem a iniciar a mudança, a parte difícil é concluí-la, medir seu resultado e manter o novo sistema funcionando ao longo do tempo. Nada vai limitar mais a sua capacidade de implementar mudanças do que um histórico de iniciar e não concluir muitas iniciativas.
É necessário haver um ambiente estável para permitir que as mudanças sejam implementadas e persistam. Em outras palavras, se um time tenta melhorar muitas coisas simultaneamente, mesmo que consiga concluí-las, será impossível entender o resultado. Esse é o cenário infelizmente muito familiar de times que têm ótimas retrospectivas, propõem múltiplas ideias de melhoria, mas não conseguem concluir nenhuma delas.
Como em qualquer trabalho, é essencial limitar o trabalho em progresso ao melhorar sistemas e focar em terminar antes de começar. Isso sem dúvida levará a melhores resultados.
Esse post faz parte de uma série sobre Liderando Times de Software com Pensamento Sistêmico.