Criei essa postagem depois que li a publicação recente do Matheus Montenegro (inclusive obrigado por compartilhar), referenciando uma outra publicação sobre a produtividade de engenheiros de software me trouxe algumas reflexões sobre esta questão.
Assim como qualquer área em uma empresa, desenvolvimento de software precisa de gestão ativa e o gestor precisa saber o que acontece “debaixo dos panos”, caso não seja possível ter um gestor assim, é bem provável que a produtividade da equipe caia ao longo do tempo.
Embora muitas equipes de produto e tecnologia sejam bastante independentes e capazes de resolver boa parte dos desafios sozinhas, elas ainda precisam de suporte para remover os obstáculos que surgem no processo. Esses obstáculos geralmente aparecem devido a planejamentos incompletos, mudanças inesperadas de escopo, tecnologias inviáveis ou outros problemas identificados apenas durante o desenvolvimento, mas que poderiam ter sido evitados com um planejamento mais robusto.
Outro ponto crítico é a falta de supervisão por parte de gestores que não entendem o trabalho técnico. Em casos extremos, isso permite que alguns profissionais se aproveitem da situação, reduzindo seu desempenho ao mínimo necessário até o salário cair na conta.
Eu mesmo passei por essa experiência (da falta de supervisão) enquanto era programador. Em muitas empresas onde trabalhei, meus gestores tinham pouco ou nenhum entendimento técnico do que eu fazia. Se eu dissesse que uma tarefa levaria 3 ou 30 dias, eles simplesmente aceitavam. Os questionamentos sobre prazos existiam, mas eram baseados em palpites, geralmente motivados pela pressão do cliente por entregas rápidas, sem qualquer fundamento técnico.
Para manter a produtividade – especialmente em equipes remotas – uma abordagem comum é tentar controlar as horas trabalhadas. No entanto, essa prática é inútil se quem monitora não tem uma noção clara de quanto tempo as tarefas realmente levam para serem concluídas. Métricas como o número de commits também não são úteis para avaliar produtividade, conforme mencionado na publicação que inspirou essa reflexão.
Em minha experiência, algumas boas métricas para acompanhar a produtividade incluem:
- Quantidade de tasks entregues;
- Quantidade de pull requests devolvidas;
- Quantidade de bugs relacionados às tasks entregues;
- Quantidade de horas planejadas x horas cumpridas (quanto mais próximo das horas úteis de uma sprint, melhor);
Além disso, uma equipe alinhada com a cultura e os objetivos da empresa tende a assumir maior responsabilidade pelos resultados das entregas. Em equipes maiores, manter esse alinhamento é desafiador, mas adotar estruturas como squads e tribos pode ajudar a sustentar o alinhamento interno no médio e longo prazo.
Na byecar, utilizamos algumas ferramentas que têm nos ajudado bastante no dia a dia:
- Jira para gestão de projetos e tasks de cada desenvolvedor;
- tMetric integrada ao Jira para controle de horas;
- GitHub, integração com Jira, para automações relacionadas ao deploy e gestão do código fonte.
A integração entre essas ferramentas garantem relatórios precisos sobre a velocidade da equipe e sua capacidade de implementação, fornecendo uma visão clara para ajustes e melhorias contínuas.