Os Tempos Estão Mudando na Engenharia de Software

20 de fevereiro de 2023

Esse post foi traduzido automaticamente do inglês. Se você encontrar algum erro, por favor entre em contato.

Bifurcação na estrada, por MidJourney

Uma coisa é certa na indústria de engenharia de software atualmente: ela está mudando. Após um crescimento intenso por vários anos, vemos retração e demissões na maioria das empresas de tecnologia, mudando rapidamente o cenário para engenheiros e gestores.

Sem a capacidade de adicionar mais pessoas para sustentar o crescimento, também vemos a consequência natural desse movimento. As empresas precisam focar na eficiência e desempenho do seu departamento de engenharia.

Embora isso seja esperado e, de certa forma, positivo, também é uma transformação delicada. Podemos fazê-la de maneira que mova nossa indústria para ser mais performante e previsível, mantendo a inovação, a satisfação dos engenheiros e o respeito pelo ofício de software. Ou pode ser simplista, focando em conceitos antiquados, levando a uma perda de eficácia.

Ainda estamos no início dessa transformação. Infelizmente, os primeiros sinais poderiam ser melhores. Mas antes de discutir como abordar esse desafio, devemos discutir engenharia de software como disciplina.

Engenharia de Software Como a Conhecemos

Temos desenvolvido sistemas de software há um bom tempo. Embora cada contexto seja diferente e ainda haja avanços significativos para acontecer na indústria (olá, IA!), a maior parte do software desenvolvido por empresas de tecnologia hoje em dia segue princípios similares. E nós basicamente sabemos como construí-lo: foque no resultado, construa de forma iterativa, integre continuamente, escreva testes, construa com alta qualidade e colabore.

Esses princípios existem há décadas e deveriam levar a uma indústria muito eficaz. Ainda assim, às vezes vemos engenharia de software sendo tratada como pura arte em vez de ciência. Se você perguntar a um Engineering Manager onde seu time gasta tempo, ele provavelmente não saberia. Muitos times e empresas têm dificuldades com qualidade e estão sobrecarregados com problemas decorrentes disso. O executivo de engenharia médio não consegue especificar onde o investimento multimilionário em engenharia está sendo aplicado. Se você observar alguns times, é difícil para qualquer pessoa de fora entender que trabalho está sendo feito. Às vezes é difícil até para pessoas dentro do time entender. Resumindo, podemos fazer melhor do que isso.

Por outro lado, engenharia de software continua sendo uma atividade altamente complexa. Embora uma boa parte de qualquer projeto de software seja previsível, algumas partes são complexas e caóticas. Uma nova funcionalidade pode ser simples, mas adicioná-la a um sistema de produção em alta escala sem introduzir nenhum problema não é. Engenheiros trabalham com conceitos abstratos enquanto mantêm contexto sobre um grande conjunto de restrições. Mesmo decidir o que precisa ser construído e alinhar isso entre produto, design e engenharia é um esforço complicado que requer múltiplas iterações.

Construir software é uma atividade de alta variação; tratá-la como se não fosse só levará a um ciclo vicioso de baixa qualidade e pressão.

O que acontece quando assumimos que engenharia de software é simples.

Fazer Mais com Menos

Com o contexto acima em mente, a frase da moda em tecnologia é como “fazer mais com menos”. Se uma empresa não pode aumentar seu headcount, como vai continuar entregando seu produto e crescendo? Líderes de engenharia agora estão na berlinda, tendo que guiar a transição e equilibrar as necessidades esperadas do seu produto e as complexidades da engenharia.

Como em qualquer decisão, existe uma posição simplista. E infelizmente, é a que mais está sendo discutida. Como resultado, agora vemos pedidos para “ser mais produtivo” (que soa muito similar a “trabalhe mais”), retorno ao escritório como solução para qualquer problema, e um movimento de achatamento de hierarquia, que está fadado a piorar as coisas se mal aplicado.

O Desafio do Achatamento

Reduzir hierarquia para tornar empresas mais eficazes pode ser positivo em alguns contextos. Também não é uma ideia nova, e empresas já a aplicaram em diferentes indústrias no passado.

No entanto, o desafio que mais vi com times de engenharia de software não é que Engineering Managers (EMs) têm tempo sobrando e poderiam ter mais subordinados diretos. É que os EMs estão colocando seu foco principal longe da eficácia do seu time. Adicionar mais subordinados diretos sob eles, nesse caso, só vai piorar a situação.

Reduzir Engineering Management a gerenciar indivíduos em uma empresa é o anti-pattern que nossa indústria precisa combater para alcançar mais eficácia. Em vez disso, EMs deveriam ser líderes que conduzem seus times em direção a resultados através de múltiplas facetas, incluindo liderança técnica, alinhamento organizacional, melhoria de processos, crescimento individual, gestão de desempenho e delegação. Adicionar mais subordinados diretos a um gestor sem mudar essa perspectiva só vai amplificar o padrão negativo.

Existem muitos gestores que não são executivos. Muitas pessoas, em outras palavras, são superiores de outras pessoas e ainda assim não afetam seriamente a capacidade da organização de performar. […] Eles são “supervisores” no sentido literal da palavra. São gestores na medida em que gerenciam o trabalho dos outros. Mas não têm nem a responsabilidade por, nem a autoridade sobre, a direção, o conteúdo e a qualidade do trabalho ou os métodos de sua execução.

Peter Drucker — The Effective Executive

Na prática, achatar a hierarquia sem mudar a perspectiva dos EMs vai levar a times menos eficazes ou engenheiros se tornando gestores de fato, tendo que contribuir tecnicamente e conduzir alinhamento no seu trabalho. Embora o segundo seja possível, já sabemos há muito tempo sobre os calendários de gestores e makers. Engenheiros podem ser líderes eficazes, mas farão isso em detrimento da sua capacidade de focar e contribuir tecnicamente.

Uma Perspectiva Melhor

Existe um caminho melhor. Uma versão mais produtiva dessa transição é focar nos sistemas ao redor do time de software, garantindo que sejam o mais eficazes possível. E para fazer isso, EMs precisam ter o tempo e o suporte para fazê-lo.

Na prática, existem ações que empresas podem tomar para alcançar mais com menos sem reduzir a qualidade do seu output ou a satisfação dos seus funcionários (dica: essas não são ideias novas):

• Mover o foco para eficácia do time em vez de eficácia individual. Incentivar padrões de colaboração, avaliar desempenho baseado no impacto do time e reduzir a dependência de “rockstars” individuais.

• Empoderar gestores para liderar em direção à eficácia. Treinar EMs em liderança de times em vez de apenas gestão de pessoas. Fornecer autoridade e responsabilidade pelo trabalho e resultados do time.

• Criar um ambiente onde engenheiros possam ser mais produtivos. Reduzir a dependência dos engenheiros para criar e gerenciar seus próprios projetos, resultando em mais tempo de foco para trabalho técnico e colaboração.

• Impulsionar satisfação e crescimento individual através da eficácia do time. Criar sistemas que incentivem crescimento e progressão em engenharia alinhados com os resultados do time, não apenas baseados em caminhos individuais.

No fim das contas, entenda o sistema de desenvolvimento de software e aja para melhorá-lo. Na minha experiência, o time de engenharia de software médio pode ser muito mais eficaz. Só precisa trabalhar de forma mais inteligente, e não mais.