Como medir a produtividade do desenvolvedor? Um guia para não derrubar a moral da sua equipe

Eu me encolho quando as equipes de desenvolvimento me dizem que suas organizações fazem com que elas capturem horas no Jira Software, Azure DevOps ou qualquer ferramenta de gerenciamento ágil que estejam usando. A captura de horas é compreensível e frequentemente necessária para organizações de serviços profissionais, que geralmente cobram dos clientes por tempo e materiais contratados. Mas para a maioria das organizações, selecionar métricas contábeis para quantificar a produtividade do desenvolvimento é um antipadrão herdado das práticas de gerenciamento de comando e controle.

Há uma longa lista de outras métricas de produção que também são problemáticas. Calcular a produtividade por linhas de código concluídas? Essa é uma boa maneira de incentivar as equipes de desenvolvimento a enterrar a organização com dívidas técnicas de bases de código inchadas. Medir o número de histórias de usuário ou pontos de história entregues? Isso é apenas pedir aos desenvolvedores para dividir os recursos em mais histórias ou aumentar suas estimativas de pontos de história.

Determinar o número de lançamentos concluídos é um passo para uma direção melhor, mas essa métrica também requer esclarecimento. As versões de produção que introduzem defeitos, causam incidentes graves ou proporcionam experiências ruins ao usuário final devem ser marcadas de forma diferente das implantações bem-sucedidas.

Claramente, medir a produtividade do desenvolvimento de software é repleto de desafios. Um dos especialistas com quem conversei sobre eles, Sagar Bhujbal, Vice-Presidente de Tecnologia da Macmillan Learning, alertou que escolher as métricas erradas pode afetar o moral da equipe:

“A produtividade do desenvolvedor não deve ser medida pelo número de erros, atraso na entrega ou incidentes. Isso causa angústia desnecessária nas equipes de desenvolvimento que estão sempre sob pressão para fornecer mais recursos de maneira mais rápida e melhor. Em vez disso, forneça segurança psicológica e alinhe continuamente a estrutura operacional e melhore as práticas de engenharia”.

Neste artigo, examinaremos como as medidas de produtividade podem ser aplicadas a desenvolvedores de software e equipes de desenvolvimento não apenas para melhorar (e não prejudicar) sua produtividade e ânimo, mas também para melhorar os resultados de negócios.

Não use métricas de produtividade de desenvolvimento para avaliar o desempenho

Eu sou um forte defensor da captura de KPIs e métricas de desenvolvimento para impulsionar melhorias no processo, qualidade e, sim, produtividade. A principal preocupação é quando as organizações equiparam as medidas de produtividade aos objetivos de desempenho individual ou da equipe. O problema é que igualar produtividade com desempenho sem contexto adequado muitas vezes leva a comportamentos indesejáveis, como:

• Desenvolver mais recursos que geram pouco impacto nos negócios.
• Lançar mais software sem considerar riscos, segurança, qualidade e impactos operacionais.
• Inovar sem um caminho realizado para a produção de experimentos de sucesso.

Portanto, sempre que estou falando com recursos humanos ou discutindo o desempenho geral de um grupo de desenvolvimento de software, me esforço para cobrir um conjunto mais amplo de medidas além da produtividade.

Use métricas de produtividade de desenvolvimento para ajudar o negócio

Então, onde as métricas de produtividade podem ser aplicadas às equipes de desenvolvimento de software para melhorar os resultados de negócios? Especificamente, as melhorias de produtividade devem ajudar as empresas a aumentar a receita, melhorar a experiência do usuário final, aumentar a qualidade, reduzir custos, permitir a inovação, fornecer recursos estratégicos, melhorar a colaboração, impulsionar a eficiência, simplificar o acesso a informações ou reduzir riscos.

O desenvolvimento de software (e TI em geral) costuma contribuir para esses resultados de negócios, e os KPIs baseados em resultados devem definir o contexto para qualquer métrica de desenvolvimento de software (e TI). O lado operacional desses KPIs deve ser uma métrica sobre a eficácia da equipe em relação aos valores e padrões declarados.

Há um crescente corpo de conhecimento sobre essas métricas. Aqui estão alguns exemplos:

• As métricas de desenvolvimento de software que importam hoje incluem métricas ágeis, como tempo de ciclo e velocidade da equipe, e métricas de produção, como tempo médio de reparo.
• Algumas métricas de produtividade inteligentes se concentram em comportamentos como revisões de código concluídas, documentação escrita e conversas mantidas com outras pessoas que capturam produtividade, qualidade e colaboração.
• Comparar atividades de valor agregado, como design de software, teste e integrações, com atividades sem valor agregado, como configuração de ambientes, disputas sobre problemas de implementação ou a escrita de um novo código para descobrir como o código existente funciona.

Ao considerar algumas dessas métricas de produtividade, vale a pena avaliar os deltas em comparação com as métricas atuais. Quando as equipes melhoram a velocidade e os tempos de ciclo, ou reduzem a taxa de escape de defeitos e o tempo médio de reparo, a produtividade da equipe provavelmente está melhorando.

Use métricas de produtividade de desenvolvimento para melhorar a produtividade

Um dos objetivos de medir a produtividade deve ser otimizar os investimentos que proporcionam melhorias de produtividade. Os investimentos que ajudam as equipes de desenvolvimento de software a enfocar mais tempo e energia na solução de problemas de negócios priorizados se enquadram nesta categoria. Alguns exemplos:

• Automatizar implantações com CI/CD em vez de executá-las manualmente.
• Padronizar ambientes com infraestrutura como código (IaC) e contêineres para minimizar configurações manuais e reduzir defeitos vinculados a diferenças de sistema.
• Automatizar testes de regressão para que os desenvolvedores corrijam bugs durante o processo de desenvolvimento e gastem menos tempo investigando e corrigindo defeitos encontrados na produção.

Bhujbal, da Macmillan Learning, observa a importância dos comportamentos da equipe e ferramentas que afetam a produtividade. “Medidas intangíveis, como menos atrito e colaboração contínua com departamentos de negócios e ferramentas de otimização, ajudarão a atingir os resultados desejados e oportunos”.

As métricas de produtividade devem se concentrar nos resultados de negócios

Martin Davis, um CIO experiente da Southern Company Services, também enfatiza o foco no valor e nos resultados do negócio:

“Quanto mais a TI pode usar métricas de negócios para medir sua produtividade, mais facilmente a alta administração pode entender o valor. Eu sempre tentaria medir nossa produtividade de desenvolvimento em termos de funções agregadas ou problemas de negócios resolvidos e, de preferência, tentaria obter valores em dólares para o valor agregado. Ao fazer isso, você pode transformar a conversa de TI como um custo, em TI como um provedor de valor”.

Ramki Ramaswamy, Vice-Presidente de TI, Tecnologia e Integrações da JetBlue, concorda com Davis que a produtividade do desenvolvimento deve ser um fator de valor agregado e ele adiciona a remoção de riscos como um segundo fator. “A produtividade do desenvolvimento é geralmente relatada em horas ou defeitos ou dólares”, disse ele, “mas deve ser medida em valor (retorno, oportunidade, economia operacional) por dólar gasto versus risco (segurança, oportunidade) de não fazer nada”.

O conselho de Ramaswamy e Davis é consistente com o que considero mais importante num KPI ágil. Em última análise, as equipes devem primeiro medir os resultados de negócios e, em seguida, qualificá-los com métricas que ilustram os comportamentos direcionados. Apresentar KPIs que combinam resultados e qualificações de entrega ajudam a responder a quem, o quê, por que e como entregar software de alta qualidade. Esses KPIs são muito mais significativos do que focar em um monte de métricas de baixo nível.

Depois que esses KPIs são definidos, as melhorias de tecnologia e processo ganham muito mais contexto e significado para os desenvolvedores de software e para a empresa. Por exemplo:

• Uma equipe de desenvolvimento solicitada a melhorar as métricas de satisfação do cliente como um resultado de negócios pode optar por se concentrar em melhorar o tempo médio para reparar problemas e as taxas de fuga de defeitos.
• À medida que as equipes de desenvolvimento demonstram melhorias nessas métricas, elas devem expressar onde investem em melhorias de produtividade, como automação, desenvolvimento de documentação ou redução do débito técnico.
• À medida que as equipes de desenvolvimento entregam melhorias, elas devem medir a satisfação do cliente e relatar suas métricas selecionadas.

KPIs que combinam resultados de negócios e métricas de produtividade do desenvolvedor ajudam a responder a pergunta: “A equipe está entregando os resultados de negócios priorizados enquanto melhora sua produtividade?”. Dado que as equipes não podem melhorar tudo de uma vez, as organizações devem buscar equipes campeãs que tomem decisões prudentes, que entreguem resultados enquanto aumentam a produtividade.