Por que seu time de desenvolvimento não é produtivo?

Este artigo é destinado as pessoas que são responsáveis por times de desenvolvimento, que podem ser compostos por uma ou mais pessoas. Seja você líder de si mesmo (eu-quipe), ou de um grupo.

Nele, vou apresentar minhas perspectivas e referências. As quais busco perseguir sempre como fundamentos.
Boa leitura!

Introdução

O que é produtividade? Segundo o dicionário, se define como: “eficiência na produção de algo”.

No contexto de engenharia de software, estamos falando (quase sempre) sobre a criação e manutenção de um produto ou serviço.
Podemos pensar no processo de desenvolvimento de software como uma esteira de produção para estes resultados.

Estamos acostumados a considerar apenas trabalhos físicos como linha de produção, geralmente associamos apenas fábricas ou grandes montadoras a este processo. Mas a verdade é que podemos (e devemos) entender o ciclo de desenvolvimento de software da mesma forma.

Nos outros processos mencionados, a eficiência é um valor enraizado. Agora, será que no desenvolvimento de software, analisamos a eficiência da nossa esteira de produção da melhor forma?

Com isso em mente, trago alguns pontos que, de forma comprovada, aumentam a eficiência de um time de desenvolvimento.

Implementar um padrão de tecnologias a nível organizacional

Isto é, igualar o máximo possível nos diferentes produtos e serviços as linguagens utilizadas, os ambientes de clouds (deploys, pipelines, bancos de dados), arquiteturas e design patterns.
De acordo com a unidade de negócio, podemos (e vamos!) precisar de tecnologias específicas, e não teremos como fugir de processos únicos, mas estes devem ser tratados como exceções.

Vantagens de utilizar os mesmos padrões de tecnologia:

Reuso de códigos

Uma boa prática comumente utilizada em C#, é a criação de pacotes NuGet. São “pacotes” úteis que podem ser utilizados publicamente ou privados. De forma análoga, temos os pacotes NPM em NodeJS, que também podem ser distribuídos de forma privada para uma organização.

Indo além, podemos pensar em módulos que podem ser compartilhados entre aplicações, por exemplo:

• API Gateway de pagamentos
• Módulo de cadastros
• Configuração de embed de dashboards PowerBI

Manobras de alocação de pessoas

De acordo com o objetivo estratégico da empresa, é comum termos que alocar as pessoas em diferentes squads por períodos limitados. A tecnologia, caso destoe demais entre squads, pode ser um limitador para este processo.
Este limite pode ser total ou parcial - no caso parcial, seria a dificuldade de onboarding da pessoa no squad. Desde a configuração inicial do ambiente, do próprio processo de desenvolvimento até o entendimento das regras de negócio. No limite total, impossibilitaria a alocação temporária.

Implementar boas práticas de desenvolvimento

Guia de boas práticas de desenvolvimento organizacional

Além dos padrões de tecnologia, podemos pensar em padrões de boas práticas de construção de código a nível organizacional. Algumas delas:

Proibir mais que 3 níveis de código aninhados

Veja este vídeo BRILHANTE do canal CodeAesthetics no youtube (em inglês): https://www.youtube.com/watch?v=CFRhGnuXG-4
O vídeo entrega exemplos de códigos mal escritos e o processo de refactoring deles. Melhorando sua leitura e manutenibilidade.

Nomes claros em variáveis e funções

Pode parecer irrelevante, mas dar nomes compridos e óbvios as variáveis pode facilitar o processo de entendimento do código.
Este comportamento vem desde quando a programação servia apenas para fórmulas matemáticas, que buscavam reduzir o máximo possível as variáveis até que chegassem em apenas uma letra ou símbolo.
Afinal, x e y não significam nada além de eixos rs.

Incentivo de pair programming

A prática de pair programming, além de contribuir para que os desenvolvedores discutam e cheguem a conclusões juntos, aumentando a estima do time, comprovadamente² também aumenta a eficiência em até 15% do processo de desenvolvimento. Na prática, não temos um volume maior de entregas relevante, mas temos uma diminuição de bugs. Visto que os desenvolvedores vão passar menos tempo construindo código e mais tempo discutindo previamente sobre a determinada tarefa.

Entender quais são seus agressores de produtividade

Entender o cenário que estamos introduzidos pode ser um desafio, principalmente em organizações onde as responsabilidades não estão muito bem definidas. É nosso papel blindar o time de desenvolvimento deste tipo de desalinhamento, e atuar com visão estratégica analisando o contexto.

Existe um princípio que diz que 80% dos problemas vem de 20% das causas, o princípio de Pareto.

Nos outros contextos de processos de produção, a análise através deste princípio é muito comum. Basicamente, devemos focar o esforço nos 20% de causas, e ignorar os 80% restantes.

Parte do nosso papel como gestores, é o entendimento dos nossos agressores de produtividade.

Quais são os processos mais onerosos ao seu processo?

A partir dessa análise de onde o time perde mais tempo, podemos utilizar o princípio para mitigar riscos.

Alguns agressores muito comuns, podem ser:

• Processo de Debug
• Configuração de ambiente de testes
• Conflitos de Merges
• Má especificação de requisitos

Para cada agressor, podemos ter diferentes abordagens pensando na sua mitigação.

Por exemplo, para o processo de merge, você sabia que existem abordagens de desenvolvimento que buscam diminuir o máximo possível a quantidade de merges? O trunk based development ou TBD.

Empatia como ferramenta

É importante ressaltar que faz parte do seu papel como líder construir um ambiente de contribuição entre o time.

A empatia é uma ferramenta muito importante, e deve ser ativamente estimulada no time.
Entrevistas, feedbacks 360° e exercitar a escuta ativa, são práticas que podem auxiliar no entendimento das pessoas que compõem o time, e consequentemente, os principais agressores de produtividade que eles sentem.

O problema é eficiência ou visibilidade?

Você está acompanhando o time diariamente, todos entregando. Mesmo assim, seus gestores e diretores continuam com a impressão que seu time é ineficiente e não traz resultados. Os esforços nunca são o suficiente e a conta no fim do mês não fecha. E agora?

Existe um ditado, que infelizmente não consegui encontrar o autor, mas que nos dá uma luz para este cenário:

“- Mais importante que fazer certo o projeto, é fazer o projeto certo”

Entender quais são as entregas estratégicas para a organização é seu papel. A identificação de stakeholders e a gestão das prioridades precisa ser um esforço ativo. Portanto, não basta o time entregar, o time precisa entregar valor. Se o time fizer 10 entregas não prioritárias com qualidade, mas errar na entrega mais importante, qual você acha que será o resultado disso? A percepção de ineficácia, mesmo que pela média o time seja eficiente.

Conclusão

Caro colega gestor, não existe bala de prata. Ferramentas de produtividade ou IAs podem ajudar, mas nos lembremos do princípio de Pareto. O que funciona mesmo é: entender as pessoas e suas necessidades.
Nosso papel é ser o filtro e a direção do time. Nosso resultado não depende apenas de nós, e este é o nosso desafio. Não podemos nos colocar em papel de herói, não vamos conseguir entregar tudo sozinhos. É importante ressaltar que caso você precise ser um, isto não é - e não será - sustentável por muito tempo.

Referências:

1. Robert C. Martin. 2008. Clean Code: A Handbook of Agile Software Craftsmanship (1st. ed.). Prentice Hall PTR, USA.
2. Cockburn, A., & Williams, L. (2000). The costs and benefits of pair programming. Extreme programming examined, 8, 223-247.
3. CodeAesthetics - Why You Shouldn't Nest Your Code
4. Sommerville, Ian. Engenharia de Software, ED. Pearson, 9a. ed, São Paulo, 2011
5. https://caetreinamentos.com.br/blog/ferramentas/diagrama-de-pareto-acao-com-maior-beneficio/
6. https://trunkbaseddevelopment.com/