Evitando Burocracia em Times de Software
Esse post foi traduzido automaticamente do inglês. Se você encontrar algum erro, por favor entre em contato.
Labirinto. Imagem gerada por MidJourney
Melhoria de processos é uma das principais ferramentas de Engineering Managers (EM) para gerir seus times. Entregar software comercial envolve a sobreposição de múltiplos sistemas, e agir neles de forma eficaz melhora o ambiente e os resultados do time.
No entanto, processos também podem facilmente prejudicar a eficácia. Foco excessivo neles pode restringir o time e seus membros, e técnicas mal aplicadas também podem ter resultados negativos. Não há melhor maneira de entender isso do que olhar para a percepção atual da indústria sobre o movimento Ágil. O que era uma mudança para focar em iteração e flexibilidade se tornou sinônimo de estruturas rígidas e ineficazes.
Isso traz um dilema para gestores. Se melhoria de processos e padronização são ferramentas que podem beneficiar times, como elas podem ser aplicadas sem criar ambientes restritivos? Para discutir isso, vamos primeiro olhar para os dois lados dessa moeda.
Melhoria de Processos como Ferramenta
Nada é mais desafiador (e ineficaz) do que melhorar um sistema instável. Se não existe um processo repetido para melhorar, tentar responder a problemas se torna um jogo de acertar a toupeira. Isso porque a única maneira de agir em um time sem mudar o sistema é influenciando os membros do time.
Por exemplo, um time pode passar por um incidente grave em produção. Eles fazem um postmortem e identificam que a mudança de código que levou ao incidente não teve revisões suficientes. Em um ambiente centrado no indivíduo, o gestor conversaria com a pessoa que fez aquela mudança para combinar um plano de melhoria. Depois, o gestor observaria para garantir que o funcionário seguisse a orientação. Se isso parece microgerenciamento, é porque é. Todo esse esforço só melhorará as entregas de uma pessoa.
Se a mesma situação ocorre em um ambiente mais estável, o EM tem um ponto de alavancagem melhor porque o time tem uma estrutura que define como revisam mudanças. Ele poderia atualizar as diretrizes de revisão para incluir procedimentos melhores, ou, se isso já estiver feito, poderia discutir como o time está seguindo as diretrizes novamente. Se fizer isso com sucesso, todos os engenheiros passarão a revisar mudanças melhor. Ao agir no sistema, é possível melhorar o time inteiro, não apenas um indivíduo específico.
No segundo caso, o problema está resolvido e todos estão felizes. Mas será que estão?
Padrões de Processo como Imposto
Avance um ano, e as diretrizes de teste ainda estão em vigor e sendo rigorosamente seguidas. O time tem alguns membros novos que as veem como normais. Ao mesmo tempo, eles simplificaram significativamente seu código, tornando os procedimentos extras de revisão menos necessários ou relevantes. No entanto, continuam executando-os já que está “funcionando.”
Nesse caso, as mudanças de processo introduzidas passaram de necessárias para um fardo. Embora não estejam prejudicando a qualidade do time, há um custo para executá-las. Isso porque qualquer processo também será um imposto. Custa para implementar e só vale a pena se houver retorno sobre o investimento.
Mas remover processos é muito mais difícil do que introduzi-los. Com o passar do tempo, as pessoas começam a ver todos os processos como sua forma habitual de trabalhar e não os questionam tanto. E como a mudança aconteceu há tanto tempo, ninguém lembra por que foi introduzida. Como você pode garantir que o problema não voltará se nem sabe qual era o problema em primeiro lugar?
E esse é o dilema que os times enfrentam. Como introduzimos padrões sem correr o risco de acumulá-los e criar um ambiente rígido?
Centrando no Problema
Se eu tivesse um martelo para bater em cada prego de melhoria de processo, seria sempre centrar no problema, não na solução.
Embora as pessoas comecem sua reflexão sobre melhoria a partir de um problema que percebem, geralmente enquadram suas propostas em torno de uma solução. Em um exemplo básico, um gestor pode perceber um desafio com code reviews e introduzir um novo template de code review sem especificar o problema que está tentando resolver. Embora possa estar claro para ele, não estará para o resto do time. Ao fazer isso, ele está subindo a escada de inferência e compartilhando apenas o último degrau que deu, em vez de toda a jornada, privando os outros do contexto completo.
Por causa disso, qualquer proposta de melhoria deveria centrar no problema que está tentando resolver. Em vez de “Introduzindo um novo template de code review,” deveria focar em “Reduzindo a complexidade de código dos PRs.”
Focar no problema possibilita uma série de benefícios que serão valiosos no longo prazo, como:
- Todos entendem o porquê: ao tornar o raciocínio claro para todos os envolvidos, eles podem tomar melhores decisões quando inevitavelmente precisarem adaptar o processo a novas circunstâncias.
- Há menos resistência: com as pessoas entendendo e concordando sobre um problema existente, é muito mais fácil discutir soluções e seus trade-offs.
- Abre espaço para alternativas: discutir um problema permite que outros proponham soluções, criando espaço para mais empoderamento e conversa.
- Permite autonomia: centrar mudanças de processo em um problema permitirá que indivíduos específicos se desviem dele quando necessário, mantendo os benefícios da mudança.
Além do acima, o principal benefício de centrar iniciativas de mudança em problemas é que permite acionar caminhos de saída e melhorias quando apropriado. No exemplo acima, um processo centrado e medido em não ter incidentes permitiria ao time disparar outra discussão quando pararem de ter incidentes ou pensarem em novas soluções se a primeira não teve o resultado esperado.
O Jeito Lean
Se isso soa familiar, é porque padronização de trabalho é a base para melhoria contínua em Sistemas de Produção Lean. Você só pode melhorar um sistema se tiver um padrão para ele. Só pode continuar evoluindo se acreditar que seus padrões estão constantemente mudando. E só pode iterar continuamente se focar no problema — os gargalos do sistema.
“Foque em um problema por vez e tente alcançar melhoria contínua, não importa quão pequena seja. É assim que você pode coletar pistas úteis sobre como o trabalho padronizado deveria ser.” Taiichi Ohno — The Toyota Mindset
Focar no Problema Compensa
Mudança de processo é a principal ferramenta de um gestor para influenciar um time de software. Mantenha-as focadas nos objetivos e gargalos do time; as melhorias virão naturalmente.
Esse post faz parte de uma série sobre Liderando Times de Software com Pensamento Sistêmico.