Como Medir Performance em P&D 1 – Introdução

Atividades que dependem de inspiração e criatividade… Como medir performance deste tipo de profissional?

Introdução

Este artigo é a introdução de uma série longa de artigos sobre medida de performance em P&D. O tema é amplo, complexo e difícil. Justamente por isso, é um dos mais requisitados tanto para a Repo (empresa em que atualmente trabalho) como nas palestras que dou. Inclusive foi tema de uma discussão no editorial do Embarcados.

A grande pergunta que todo mundo se faz: como medir performance de atividades que dependem de criatividade e de inspiração?

Bom… Há como. E as dicas a seguir podem ser aplicadas não só a software, mas também a qualquer atividade intelectual: seja um advogado a redigir petições, seja um químico a documentar processos, enfim.

O Problema

Todos sabem que há dias em que o desenvolvedor rende mais para por coisas para funcionar. Há dias em que o desenvolvedor rende menos, mas está mais criativo, consegue ter muitas ideias para resolver um problema, mas não consegue dar andamento em nenhuma delas de maneira consistente.

Isso é porque as pessoas conseguem, com certa facilidade, treinar para realizar tarefas repetitivas. Um jogador de futebol irá treinar pênaltis até que as cobranças sejam automáticas. O mesmo fará o goleiro. O treinamento é tal até que o corpo já tome ações por reflexo.

Quando uma pessoa dirige um automóvel, muitas vezes não prestou atenção ao caminho. Dirigiu sem usar o cérebro!!! Porém, seria este tipo de situação possível para atividades criativas? Curiosamente, a resposta é “depende”.

A Subjetividade

Este “depende” é que é o problema. É possível um profissional aumentar sua proficiência inclusive na capacidade de soluções de problema. Mas como quantificar isso, para gerar algo mensurável como medida de performance?

É uma resposta extremamente complexa. Para montar o processo que usamos na Repo, eu busquei métodos de avaliação do pessoal que gera conteúdo: Jornalistas, agências de publicidade. Esse pessoal desenvolveu ferramentas para avaliar o subjetivo e como colocar ele em indicadores utilizáveis até mesmo em processos de qualidade.

E tive mais outras fontes além dessa (se quiser saber, mande um mail ou comente este post).

O problema a ser resolvido é partir de avaliações subjetivas, avaliações de valor percebido e gerar um conjunto de indicadores que apontem para a performance do desenvolvedor. Porém, neste post, anteciparei o que não serve como um indicativo forte de performance:

• Quantidade de commits (envio de informação ao repositório de conteúdo)
• Linhas de código escritas
• Quantidade de Projetos resolvidos
• Número de tickets fechados

Por que? porque todas essas medidas na verdade são pacotes fechados que não trazem a informação sobre a complexidade das tarefas necessárias ou por trás destes números. E a performance está ligada justamente a esta complexidade.

É isto que busco trazer para esta série de artigos. Fiquem ligados! 🙂