Por Reynald Fléchaux
Impossível de quantificar? A produtividade dos programadores pode ser monitorizada com precisão e otimizada ao longo do tempo? E será que isso pode ser feito sem consequências indesejadas? Este assunto está longe de ser novo (a metodologia de Pontos de Função remonta a 1979), mas volta a estar no centro das atenções agora que a McKinsey se interessou pelo assunto. Num blogue, a consultora americana considera que o consenso atual, baseado na constatação de que não é possível medir o desempenho de ponta a ponta dos programadores, já não é sustentável, numa altura em que o desenvolvimento se está a tornar parte integrante do core business de muitas organizações.
“Outras funções podem ser avaliadas razoavelmente bem, algumas até com uma única medida, enquanto no desenvolvimento de software, a ligação entre os recursos utilizados e os resultados obtidos é muito menos clara”, lamentam os analistas da McKinsey, que reconhecem, no entanto, que o desenvolvimento de software é um trabalho altamente colaborativo, complexo e criativo que requer várias medidas a diferentes níveis (sistemas, equipas e indivíduos). Já para não falar do facto de as ferramentas de IA generativa, como o ChatGPT e o Copilot X, estarem a agitar as coisas, melhorando a produtividade em certas tarefas (a própria McKinsey publicou um estudo sobre o assunto, mostrando ganhos muito significativos na documentação e na escrita de código).
Criar uma visão global da produtividade
Obviamente, os consultores da McKinsey vem tocar neste velho assunto porque têm uma metodologia para propor. Uma “nova abordagem” que, segundo a empresa, já foi implementada em cerca de 20 empresas dos setores tecnológico, financeiro e farmacêutico. “Os primeiros resultados são prometedores”, diz a consultora, que aponta para uma redução de 20% a 30% dos defeitos registados pelos clientes destas organizações.
A metodologia desenvolvida pela McKinsey foi concebida para complementar duas outras abordagens, a da Google (Dora) e a do GitHub e da Microsoft Research (Space). Para os consultores, a primeira fornece uma imagem clara dos resultados alcançados pelas equipas de desenvolvimento, enquanto a segunda lança luz sobre a eficiência de uma organização. “Para além destas medidas já poderosas, a nossa abordagem procura identificar o que pode ser feito para melhorar a forma como os produtos são entregues e o valor destas melhorias, sem a necessidade de instrumentação pesada”, escrevem os consultores. “Ao complementar as métricas Dora e Space com métricas baseadas em oportunidades, é possível criar uma visão holística da produtividade do programador de software”.
Distribuição das competências “em diamantes”
A McKinsey propõe, nomeadamente, três medidas adicionais. Em primeiro lugar, a medição do tempo do “circuito interno” em comparação com o tempo do “circuito externo”, ou seja, o tempo gasto a criar o produto de software em comparação com o tempo gasto a pôr o código em produção (integração, testes de integração, gestão de versões, lançamento da produção). Os consultores indicam que as empresas tecnológicas têm como objetivo um rácio de partilha de tempo de 70/30. De seguida, a McKinsey recomenda que se analise o Developer Velocity Index, que compara a base tecnológica, as práticas de trabalho e a estrutura organizacional de uma empresa com parâmetros de referência que lhe permitem comparar-se com outras organizações. “Esta comparação destaca áreas específicas de oportunidade, quer em termos de gestão de atrasos, testes, segurança ou conformidade”, escreve a McKinsey. Por fim, propõem duas métricas mais ligadas aos indivíduos: a análise da contribuição – que mede a contribuição de cada indivíduo para o progresso do backlog – e a pontuação da capacidade de competências. “Idealmente, as organizações deveriam aspirar a uma distribuição de competências em “diamante”, com a maioria dos programadores a meio do intervalo”, diz a empresa.
Este conjunto de indicadores deveria ajudar a direção geral a afastar-se do efeito de caixa negra que frequentemente rodeia as equipas de desenvolvimento de software. Mesmo se os consultores se dizem conscientes de eventuais abusos, como a má utilização dos indicadores. Mas, para a McKinsey, este efeito perverso verifica-se sobretudo nas organizações que privilegiam os KPI demasiado simplistas, como o número de linhas de código produzidas ou o número de commits. Para a empresa americana, as medições de produtividade deparam-se também com dificuldades ligadas à mudança de atitudes. “Para beneficiar verdadeiramente das métricas de produtividade, os gestores e os programadores devem ultrapassar a noção de que os gestores não conseguem compreender as subtilezas da engenharia de software, ou que esta é demasiado complexa para ser medida”, escrevem os consultores. Por outras palavras, é mais do que tempo de as métricas financeiras serem implantadas neste mundo.
“Medir significa mudar o comportamento”.
Não é de surpreender que a incursão da empresa de consultoria no domínio da engenharia informática tenha sido recebida com relutância pelos especialistas do setor. Kent Beck, engenheiro de software e criador da metodologia ágil Extreme Programming, descreve a análise como “absurda e ingénua”, ignorando a dinâmica das equipas de engenharia de software bem-sucedidas. E cita a sua experiência no Facebook, onde trabalhou durante 7 anos e que implementou “o tipo de abordagem recomendada pela McKinsey”. Com resultados desastrosos, na sua opinião. Porque as pessoas estão agora a manipular o sistema”, observa. Começámos a medir e a encorajar – com dinheiro e estatuto – as mudanças de medidas! Mas essas medidas estão a levar a mudanças de comportamento.
Juntamente com Gegerly Orosz, um engenheiro com 15 anos de experiência em desenvolvimento e autor do boletim informativo The Pragmatic Engineer, Kent Beck escreveu dois artigos que apontam os limites da abordagem da McKinsey, bem como os objetivos da empresa. Para ambos os autores, o artigo deste último foi escrito por “uma razão: os CEO e os CFO estão cada vez mais frustrados por verem os CTO a levantarem as mãos e a dizerem que a engenharia de software é demasiado complexa para ser avaliada, enquanto as equipas de vendas são seguidas através de métricas individuais e quotas a cumprir, tal como as equipas de recrutamento. Atualmente, os gestores de engenharia não podem evitar a questão de como medir a produtividade dos programadores. Se o tentarem fazer, correm o risco de o CEO ou o CFO recorrerem à McKinsey, que trará a sua estrutura personalizada, a implementará – mesmo que o CTO proteste – e começará a apresentar relatórios sobre as métricas concebidas pela McKinsey”. Por outras palavras, a empresa está a falar com os seus clientes habituais, sem se preocupar muito com as consequências reais.
McKinsey centra-se no esforço e na entrega do produto
Para Gegerly Orosz e Kent Beck, o modelo proposto pela consultora “fará certamente mais mal do que bem” às organizações que o adotarem e à sua cultura de engenharia. Para demonstrar os limites da abordagem proposta, os dois engenheiros fazem uma distinção entre o esforço produzido pelas equipas de desenvolvimento (planeamento, codificação, etc.), o output destas últimas (essencialmente as funcionalidades), os resultados obtidos (a mudança de comportamento do utilizador ou do cliente após a implementação das novas funcionalidades) e, finalmente, o valor criado (a que chamam impacto).
No entanto, os indicadores propostos pela McKinsey centram-se no esforço produzido e na produção, criticam os dois engenheiros. Os únicos que se interessam por estes indicadores são aqueles que os recolhem”, ironizam Gegerly Orosz e Kent Beck. Os clientes não querem saber. Os gestores não querem saber. Nem os investidores. Em segundo lugar, e o mais importante, a recolha e a avaliação destes KPIs atrapalham as medidas que realmente interessam às pessoas a jusante, como a rentabilidade. Porque é que a McKinsey está a acrescentar indicadores para medir o esforço? Uma das razões é o facto de ser a coisa mais fácil de medir! Mas esta abordagem ignora uma verdade essencial: o próprio ato de medir altera a forma como os programadores trabalham, uma vez que tentam ‘jogar’ com o sistema.”
Demonstração pelo absurdo
A McKinsey recomenda que os CIOs e os líderes empresariais se concentrem em indicadores centrados nos resultados (a forma como as funcionalidades alteram o comportamento dos utilizadores) e no impacto (o valor criado). Esta é a abordagem proposta pelas metodologias Dora e Space, que a McKinsey pretende complementar. Mesmo que este tipo de KPI também possa ter efeitos perversos, como eles próprios referem, recomendando aos CTO que estejam atentos às mudanças de comportamento das equipas de desenvolvimento. Para os dois engenheiros, no entanto, recompensar o impacto incentiva os engenheiros de software a compreender o negócio da empresa e a ajudá-la a atingir os seus objetivos. “Será que a entrega de uma versão que reduz os custos em 2 milhões de dólares por ano através de uma simples alteração de configuração vale menos do que a entrega de uma versão que requer 5 meses de engenharia para os reduzir em 500.000 dólares”, ilustram Gegerly Orosz e Kent Beck numa forma de demonstração do absurdo. E num aceno à McKinsey.
