Táticas de Liderança em Engenharia: Resiliência Através da Colaboração
Esse post foi traduzido automaticamente do inglês. Se você encontrar algum erro, por favor entre em contato.
Colaboração em equipe por MidJourney
Colaboração é uma coisa boa. Ninguém na indústria de tecnologia vai dizer o contrário. Como regra geral, a maioria das empresas e organizações de engenharia de software é organizada em times multifuncionais, permitindo que pessoas de diferentes disciplinas trabalhem juntas em direção ao mesmo resultado.
No entanto, ainda é comum ver times onde o trabalho individual é o foco principal quando se trata de engenharia de software. Por exemplo, enquanto no passado os times jogavam trabalho por cima do muro para outros times, agora os engenheiros jogam pull requests (PRs) para outros pelo GitHub. Eles também entregam projetos isoladamente para serem mais eficientes e pensam sobre arquitetura em comentários de documentos. Em resumo, embora todos os engenheiros em times de software trabalhem juntos, nem todos colaboram de forma eficaz.
Engineering Managers (EMs) liderando times focados em trabalho individual podem estar obtendo mais eficiência em alguns casos. Afinal, o engenheiro experiente com conhecimento de uma parte específica do código vai entregar mais rápido naquela área se puder avançar sozinho. No entanto, os EMs às vezes não percebem que estão efetivamente comprando risco com essa abordagem. E no longo prazo, isso não compensa.
Um Conto de Dois Projetos
Para entender melhor os desafios nessa área, vale a pena analisar dois projetos de software que observei. Ambos aconteceram em times multifuncionais, onde produto, design e engenharia colaboram diariamente.
No primeiro, um grupo de engenheiros dentro de um time trabalhou na construção de uma nova funcionalidade de produto. O projeto era liderado por um deles, que era responsável por executar a maior parte do trabalho, além de trabalhar individualmente em uma das frentes do projeto. Outros engenheiros no projeto tinham diferentes partes do trabalho delegadas a eles (trabalho de frontend, por exemplo).
O líder do time teve dificuldades com sua atribuição. Ele não estava entregando seu trabalho tão rápido quanto esperado e não estava guiando bem os outros engenheiros. Como cada frente de trabalho estava separada das outras, o restante do time ficou bloqueado, adicionando pressão sobre o líder. O desempenho do líder só piorou com o estresse adicional, atrasando o projeto ainda mais.
No segundo exemplo, um time de tamanho similar trabalhou em outra funcionalidade de produto. Embora esse time também tivesse um líder, eles não dividiram o trabalho em frentes separadas. Na prática, todos os engenheiros trabalhavam em diferentes tickets que construíam iterativamente a funcionalidade e a experiência do usuário.
Não separar o trabalho significava que todos no time precisavam entender o plano arquitetural, levando a mais discussões. Embora o time tivesse especialistas em frontend (FE) e backend (BE), todos os tickets tinham componentes de FE e BE, então qualquer um podia pegar qualquer ticket e pedir ajuda dos colegas quando necessário.
Nesse projeto, o líder do time teve problemas pessoais enquanto o projeto estava em andamento e não trabalhou em tempo integral por algumas semanas. Embora isso tenha impactado a velocidade de entrega, a ausência dele foi apenas um breve contratempo no desempenho do time. Todos os outros continuaram executando da mesma forma, levando o projeto a ser entregue com sucesso.
Se quiser ir rápido, vá sozinho. Se quiser ir longe, vá junto
O primeiro exemplo acima destaca um tipo de colaboração ineficiente, embora esse não seja o único. Existem múltiplas razões pelas quais times decidem focar em processos mais individuais.
Algumas das que já ouvi são:
- Eficiência Individual: Engenheiros acreditam (e às vezes estão certos) que se trabalharem sozinhos, podem entregar uma tarefa em menos tempo.
- Ownership individual: Com empresas recompensando ownership individual ao extremo, engenheiros acreditam que precisam fazer alguma parte do trabalho sozinhos para serem reconhecidos.
- Trabalho remoto: Embora a colaboração possa ser alcançada em um ambiente remoto, ela também é mais desafiadora em alguns casos, levando os times a se moverem para um ambiente de pouca comunicação.
- Eficiência do Time: Times acreditam que separar o trabalho leva a mais eficiência, já que ninguém vai duplicar esforço na mesma tarefa, ou vão minimizar a necessidade de comunicação durante a entrega do projeto.
No entanto, os exemplos acima também mostram que a colaboração eficaz, onde engenheiros trabalham próximos nas mesmas áreas, oferece um benefício significativo para times e EMs: resiliência.
Resiliência na produção não é um conceito novo. Em Sistemas de Produção Lean, o conceito de Heijunka foca em nivelar o trabalho de produção. O objetivo é evitar picos, já que um processo mais nivelado levará a um fluxo mais consistente, permitindo que o sistema se adapte melhor a mudanças.
Em engenharia de software, funciona da mesma forma. Focar indivíduos exclusivamente em suas áreas de especialidade (ou em uma parte específica do trabalho ou uma disciplina particular) levará a desigualdade, e isso significa que o processo é mais frágil a condições inesperadas que inevitavelmente vão ocorrer.
E isso não é um “se”. Em qualquer projeto de tamanho considerável, coisas inesperadas vão acontecer, levando times mais resilientes a entregar melhor no longo prazo. Alguns exemplos de áreas comuns de variação em times de software são:
- Detalhes Esquecidos — software é uma disciplina complexa, com engenheiros tentando manter um contexto significativo durante seu trabalho diário. Normalmente, detalhes serão esquecidos se apenas uma pessoa focar em uma parte específica de um problema. Ter sobreposição e múltiplas perspectivas sobre a mesma atividade minimizará o risco de perder aspectos essenciais.
- Complexidade Oculta — o desafio mais óbvio que times enfrentam é que projetos têm complexidade oculta que aparece enquanto o trabalho está em andamento. Ser capaz de aumentar a capacidade e focar em uma área específica permitirá ao time minimizar o impacto desses problemas.
- Pessoas Sendo Humanas — enquanto robôs não tomaram conta, pessoas entregam software. E pessoas vão cometer erros, ficar doentes e ter problemas pessoais. Ter um time resiliente também significa ter um time mais humano e inclusivo, permitindo que as pessoas passem pelos altos e baixos da vida sem impactar significativamente seu trabalho (e o trabalho dos outros).
Em outras palavras, EMs devem resistir à tentação da eficiência individual e criar um processo onde engenheiros trabalhem em colaboração próxima, criando um ambiente mais estável e previsível. Como em muitas coisas, desenvolvimento de software é uma maratona, não um sprint.
Esse post faz parte de uma série sobre Liderando Times de Software com Pensamento Sistêmico.