Táticas de Liderança em Engenharia: Encontrando Foco
Esse post foi traduzido automaticamente do inglês. Se você encontrar algum erro, por favor entre em contato.
Ao falar sobre Liderança Sistêmica para times de software, uma pergunta que surge frequentemente é como aplicá-la na prática. Sim, pensamento sistêmico faz sentido, mas como um engineering manager (EM) o utiliza no trabalho do dia a dia?
Embora os times sejam diferentes, algumas situações acontecem com frequência suficiente para serem consideradas padrões onde o pensamento sistêmico pode ajudar, e uma delas é o desafio do foco. Em outras palavras, como os times podem aumentar sua performance aumentando seu foco.
Por que Foco?
Antes de discutir o problema e possíveis soluções, devemos esclarecer por que isso importa. Primeiro, por que o foco é tão importante?
A ideia de foco como ferramenta para aumentar produtividade tem sido usada em muitas indústrias ao longo dos anos. Por exemplo, a essa altura, é bem sabido que multitarefa diminui a produtividade individualmente. Em sistemas de produção Lean, empresas usam “trabalho em progresso” como uma métrica crítica para seus processos, já que leva a custos mais altos (mais material inacabado), menor receita (menos produtos prontos para venda) e maior risco geral.
A situação acima se traduz bem para software. Quanto mais tempo o time leva para completar um projeto ou partes dele, mais tempo levará para validá-lo no mercado, incorrendo em mais risco, e maiores serão os custos, já que o tempo de engenharia geralmente é o principal gasto de um time de software.
Além das semelhanças, no desenvolvimento de software, algumas características tornam o foco ainda mais crítico do que para trabalho individual ou outros sistemas de produção:
- Times de software geralmente são pequenos e multifuncionais, com as mesmas pessoas executando diferentes partes do processo (ou seja, design, escrita de código, code review e garantia de qualidade).
- Engenharia de software tem um nível baixo de documentação comparado a outras disciplinas. Uma parte significativa do conhecimento relacionado aos sistemas só está disponível como conhecimento tribal na cabeça dos engenheiros.
Por causa disso, quando times de software têm baixo foco, com engenheiros espalhados por muitas iniciativas, isso leva a bloqueios e gargalos em todo o sistema. Por exemplo, pull requests ficam esperando code review por um tempo significativo, atrasando quando o trabalho é entregue. Ou o trabalho é executado com menor qualidade já que o engenheiro mais conhecedor estava ocupado com outra atividade, levando a retrabalho no futuro.
Para piorar, dado como as empresas avaliam engenheiros pela sua performance individual, times com baixo foco levam a ainda mais trabalho em progresso. Quando um engenheiro está bloqueado porque o time não está focado, ele pega novo trabalho para ser “produtivo”, criando mais trabalho em progresso e foco ainda menor. Esse padrão cria um ciclo vicioso que pode afetar significativamente a capacidade de entrega de um time.
Um anti-padrão comum em times com baixo foco
É aqui que o pensamento sistêmico pode ajudar.
Para melhorar um time enfrentando esses desafios, precisamos pensar no todo (qual é o objetivo que o time está tentando alcançar?) em vez das partes (o que cada engenheiro está fazendo agora?).
A conclusão nada surpreendente é que quanto menos iniciativas o time trabalha, mais produtivo será. O que tenho encontrado na prática é que, embora a maioria dos gestores concorde com essa afirmação na teoria, há desafios com os aspectos práticos disso, então vamos falar sobre isso.
Falta de Foco na Prática
Um time de software na maioria das empresas tem uma série de distrações para ocupar seu tempo. Múltiplos projetos estão sendo entregues e mantidos. Existem problemas e bugs descobertos tanto internamente quanto por clientes. Alguns incidentes requerem atenção. Pessoas em outras partes da empresa fazem perguntas.
Nesse sentido, devido a como as empresas de software são organizadas, já existe naturalmente uma quantidade de trabalho paralelo que sempre estará lá. Por causa disso, uma abordagem passiva em relação ao foco provavelmente levará a um time com muitas iniciativas e baixa produtividade. E isso só vai piorar se o time permitir que complexidade adicional entre no sistema.
O que é complexidade adicional nesse caso? É qualquer atividade que permita que o número de trabalhos paralelos aumente. Embora seja impossível compilar uma lista exaustiva, alguns exemplos são:
- Falta de disciplina para iniciar e concluir iniciativas permite que elas se multipliquem.
- Uma estrutura de trabalho que incentiva engenheiros a trabalhar independentemente, criando backlogs de facto independentes para cada pessoa.
- Trabalho de baixa qualidade leva a problemas excessivos e retrabalho, criando interrupções que o time não consegue controlar.
- Longas esperas por colaboração, como ciclos longos de code review ou garantia de qualidade, levam engenheiros a pegar novo trabalho.
- Repriorização constante e mudanças de foco levam a trocas frequentes de contexto pelos engenheiros.
Em resumo, qualquer coisa que permita que mais trabalho seja iniciado e menos trabalho seja concluído.
O que um EM pode fazer?
Como gestor do time, o EM está na melhor posição para influenciar o foco do time agindo no sistema e em como as pessoas trabalham juntas. Claro, cada situação é diferente, mas existem algumas práticas e princípios que vi serem usados de forma eficaz com frequência.
Foque na eficiência do time, não na eficiência individual
Se eu tivesse apenas uma dica para dar a gestores, seria tornar extremamente claro para os engenheiros que a eficiência do time é mais importante que a eficiência individual. Cada membro do time deve entender que a métrica principal não é o quão ocupado e produtivo cada um é individualmente, mas quão rápido o time consegue entregar funcionalidades para os clientes em conjunto.
Essa atitude não vem naturalmente na maioria dos ambientes, dado que engenheiros são avaliados individualmente. No entanto, é inevitável que, se o time colabora bem, cada membro também aumentará sua produtividade individual.
Tenha as prioridades do time claras
Gestores devem deixar claro quais são as prioridades do time a qualquer momento. Embora existam diferentes formas de gerenciar objetivos (OKRs, metas trimestrais, objetivos de sprint), deve ser fácil entender os marcos e objetivos para os quais o time está trabalhando.
Engenheiros tomam centenas de decisões todos os dias. Desde qual ticket trabalhar até qual abordagem usar para a implementação de uma funcionalidade. Quanto mais eles entenderem os objetivos de negócio do seu trabalho, melhor poderão decidir como abordar cada decisão.
Visualize o trabalho
Engenharia de software é uma disciplina abstrata por definição. Portanto, quanto mais simples for entender no que o time está trabalhando e se precisam de ajuda, mais eficazes serão.
A forma mais fácil de fazer isso é visualizar o trabalho regularmente como time, idealmente no stand-up, para que todos estejam claros sobre isso. E o gestor pode desempenhar um papel crítico removendo bloqueios, incentivando colaboração e compartilhamento de conhecimento, e em última instância definindo a melhor formação para o time naquele dia.
Trabalhe em grupos
Em um mundo perfeito, cada time teria um único objetivo e projeto e estaria 100% focado nele. Isso é irreal em qualquer ambiente corporativo, no entanto. Times geralmente têm múltiplas iniciativas em andamento a qualquer momento.
Mesmo nesse contexto, ainda há uma diferença significativa entre um engenheiro individual trabalhando em uma ou múltiplas iniciativas simultaneamente. E também há uma diferença substancial entre trabalhar sozinho ou como parte de um grupo. Trabalho individual muito provavelmente levará a silos de conhecimento e bloqueios. E se um engenheiro está dividindo sua atenção entre múltiplos projetos, estará constantemente trocando de contexto.
Uma alternativa prática é dividir temporariamente o time quando múltiplas iniciativas estão em andamento. Por exemplo, isso pode ser feito dedicando um par de engenheiros a bugs enquanto o resto do time trabalha em um projeto, ou definindo sub-times que trabalharão juntos em um projeto ou sprint. Dessa forma, o time ainda pode ser flexível e executar diferentes tipos de trabalho mantendo um alto nível de foco e colaboração.
Reduza desperdício e minimize distrações
Além de agir no presente, o gestor pode trabalhar para reduzir distrações futuras para o time, aumentando sua produtividade no longo prazo.
Ele pode analisar o tipo de trabalho que o time tem feito e entender o que leva a trabalho em progresso. Por exemplo, o principal problema pode ser bugs em uma parte específica do sistema que pode ser melhorada, ou uma estratégia de produto que é flexível demais e poderia ser simplificada.
Mantenha o time no alvo
Embora seja uma jornada sem fim, focar ativamente o time em seus objetivos principais é uma das atividades de maior alavancagem que um gestor pode fazer. Mantenha o time no alvo. Eles vão trabalhar menos e alcançar mais.
Esse post faz parte de uma série sobre Liderando Times de Software com Pensamento Sistêmico.