Métricas de Produtividade

Não se pode acompanhar o que não se pode medir. Uma pequena adaptação da frase de Morris A. Cohen, professor da Wharton e co-diretor do Centro Fishman-Davidson de Gestão de Serviços e Operações.

Imagine um avião saindo da cidade A e se dirigindo para a cidade B. Como saber se está dentro do horário se não for possível medir a distância percorrida, restante e velocidade? Como assegurar que não vai bater em uma cadeia de montanhas no caminho sem medir a altura?

Um projeto é similar. Sem métricas apropriadas o risco de fracasso é muito grande. Mesmo um caso de sucesso provavelmente teria resultados melhores se acompanhado com boas métricas.

Gerenciar um projeto sem métricas adequadas é gerenciar no escuro. Mas como escolher as métricas adequadas a cada projeto?

Não há resposta fácil, mas qualquer métrica que tenha sido bem pensada para o projeto é melhor do que nenhuma.

Visto que o assunto deste artigo é produtividade, vou falar um pouco sobre motivação e comunicação, duas das principais peças para obter produtividade. Como comunicar de forma clara e objetiva para a equipe a produtividade esperada? Eu digo que para isso é necessário ter métricas (e metas associadas) de produtividade pessoais e de equipe. Além de comunicar a necessidade para a equipe, elas vão ajudar na motivação. Elas os ajudam a ver possibilidade de ultrapassar as metas acordadas e possibilitam ao gerente premiar este esforço, trazendo um reconhecimento para o trabalho da equipe e, conseqüentemente, aumento ou manutenção da motivação.

Certa vez utilizei em um projeto três métricas para os desenvolvedores: pontos de função/mês, percentual de tarefas cumpridas no prazo e percentual de erros por ponto de função desenvolvido no período. Estas métricas deram muito certo para o projeto, que era também pago por ponto de função desenvolvido. Basicamente elas representavam os três principais assuntos que eu cobrava muito da equipe: produtividade, compromisso com o prazo e compromisso com a qualidade.

A cada mês tinhamos uma reunião, onde eram apresentados gráficos com o histórico das métricas de cada membro da equipe e o consolidado de toda equipe. O mais produtivo, se estivesse acima da meta, recebia um prêmio simbólico: uma caixa de bombom. Se um ou mais componentes estavam com as métricas muito baixas, o mesmo dava sua opinião (se desejasse) sobre o resultado, e todos discutiam como resolver a questão.

Será que a métrica não era adequada, e por isso uma ou mais pessoas ficaram abaixo? Sim, isto aconteceu principalmente nos primeiros meses, e fomos ajustando até chegar ao que concluímos ideal.

Será que o método de auferir a métrica não estava adequado? Também aconteceu, e corrigimos.

Será que algumas pessoas não estavam registrando da maneira correta? Sim, também corrigimos isso.

Será que ponto de função não representava sempre o tamanho adequado? Sim, e por isso criamos um fator de ajuste de complexidade a mais.

Veja bem, foi um pouco complicado nos primeiros dois meses, mas logo a equipe ficou muito unida e percebeu que não havia punição ou perseguição pelas métricas baixas, apenas discussão construtiva para tentar aumentar a produtividade de todos até chegar na meta. E muito cuidado, se não for assim a reunião vai desmotivar a equipe. Deixe assuntos delicados para reuniões em particular com a pessoa, este tipo de reunião deve ter somente comentários construtivos e que possam ser discutidos em grupo sem constranger os membros.

Claro que em determinado momento começamos a encontrar problemas de produtividade. Ótimo! Isto é parte do objetivo. A pessoa está doente e por isso baixou a produção? Bom saber que é um problema temporário. A pessoa está sempre doente? Melhor ainda saber, talvez esteja na hora de pensar em programas de prevenção de acidentes e/ou doenças na empresa. A pessoa não tem perfil adequado para o que está desempenhando? Muito bem, talvez seja melhor tentar alocar ela em algo que faz melhor e achar outro colaborador com o perfil adequado. Seja como for, é preciso saber a razão da baixa produtividade e discutir de forma construtiva, sempre em favor do projeto, mas respeitando as pessoas.

O que quero dizer com tudo isso é que pode ser difícil criar métricas apropriadas, mas é necessário criá-las e ajustar até conseguir. Monte sua base histórica. Saiba que a produtividade de uma pessoa está baixa e discuta em particular como resolver. Descubra uma pessoa muito produtiva, e dê os parabéns em público. Envolva sua equipe na criação das métricas, acompanhe com eles os indicadores e peça sugestões sobre como criar ou melhorar as métricas para de fato representarem o projeto.

Crie uma periodicidade pré-definida para discutir os indicadores com todos. Um dos problemas que vejo é que mesmo as pessoas mais motivadas perdem o rumo se não tiverem dados objetivos para acompanhar. Isso sem contar que é praticamente impossível estimar prazos sem uma idéia do quanto a equipe é capaz de produzir. Se alguém te perguntar como está sem desempenho, nunca responda apenas "bom". Seja específico e objetivo, tenha métricas em mãos, e mostre o desempenho da pessoa em relação às metas estabelecidas.

Enfim, crie suas métricas de produtividade junto com a equipe. Acompanhe. Discuta. Cobre. Use a métrica. Se precisar, jogue fora e comece de novo, mas ache as métricas adequadas para seu projeto. Ache os indicadores que fazem a equipe vibrar e se esforçar para ultrapassar as metas estabelecidas. Pode ser complicado conseguir achá-las, mas certamente você verá um impacto muito positivo na produtividade. Quer uma dica? Seja S.M.A.R.T. (Specific, Measurable, Attainable, Relevant, Time-Bound).

Maquetes de Software

É comum, no início dos projetos de software, serem criados protótipos para permitir uma visualização do entendimento da equipe para o cliente/usuário, facilitando assim alinhar a visão de quem vai criar a ferramenta (o software) com a visão de quem precisa dele.

Como é de praxe na área de TI, os prazos são curtos e os orçamentos, em geral, apertados. Desta forma, os protótipos costumam ser feitos em pouquíssimo tempo e, portanto, em geral os engenheiros de software os consideram inúteis para o desenvolvimento efetivo do sistema.

É aí que, em minha visão, muitos projetos já começam destinados a desastres.

Os clientes e usuários de projetos desta natureza, e até mesmo gerentes que não tem conhecimento técnico na área, muitas vezes enxergam o protótipo como uma peça que pode ser incrementada até chegar ao produto desejado, o que não costuma ser verdade. Para piorar, de suas perspectivas, ao verem um protótipo que reflete em certo nível suas necessidades, entendem que grande parte do trabalho de desenvolvimento já está pronto, e portanto exigem que o protótipo se torne funcional em pouco tempo, ordenando que o projeto continue a partir do protótipo.

Creio que muitos leitores vão concordar comigo que esta prática leva ao desastre, e um tempo precioso do projeto é gasto refatorando e corrigindo defeitos com origem em uma arquitetura que não foi feita para a produção, mas apenas para uma apresentação ao cliente. Já tive muitas experiências similares, e percebi que o tempo total do projeto utilizando esta prática fica muito maior do que se o protótipo tivesse sido jogado fora para, então, iniciar as tarefas de engenharia (requisitos, negócio, software, etc) antes da codificação. A qualidade final do produto é ainda mais afetada por esta prática, que costuma ficar péssima quando o software é desenvolvido desta forma.

Visto estes problemas, e outros que convenientemente omiti, vejo a necessidade de criar um entendimento comum sobre o significado de um protótipo de software. Trago uma proposta diferente, que ainda não encontrei similar ao navegar pela internet.

Em breve chegamos lá, mas antes pensemos no termo "protótipo". É comum em diversas áreas, e muito visto em filmes de ficção, um protótipo ser uma primeira versão de determinado produto, em geral funcional, porém com desempenho abaixo do que a versão de produção em escala. Vejamos uma das definições do Grande Dicionário Larousse Cultural da Língua Portuguesa: "Em design, a primeira realização concreta de um projeto, com todas as características do produto final, antes de ser industrializado."

Vejo que é isso que muita gente entende ser um protótipo de software, e este entendimento talvez venha destes casos, mas digo que esta definição não se aplica a software.

Assim sendo, finalmente chego à minha proposta: que paremos de chamar estas carcaças não funcionais de protótipos, e passemos a chamar de maquetes de software.
O objetivo é facilitar, por analogia, ao cliente/usuário entender a utilidade (ou inutilidade) do mesmo com uma analogia a maquetes utilizadas na construção civil.

Uma maquete serve muito bem, para prover ao cliente de um projeto de construção, uma visão de como ficará o produto final. Ao mesmo tempo, fica claro para ele que a casa não será construída a partir da maquete. Óbvio que paredes de isopor e componentes de papel não tem capacidade de sustentar uma casa, aguentar ao mal tempo, prover encanamento, eletricidade ou quaisquer características de uma casa real. Óbvio? Então porque não é visto sob este ponto de vista quando se trata de um software?

A idéia é que o mesmo princípio se aplica à maquete de software. Ela não é estruturada para suportar um uso real. Ela não tem uma arquitetura que facilite sua manutenção ou evolução. A maquete certamente não foi pensada para escalabilidade, segurança e outros assuntos necessários à produção de um software.

Assim sendo, proponho que lidemos com este tipo de produto, que hoje chamamos de protótipo não-funcional, pelo nome de Maquete de Software. Recomendo, também, que seja explicado muito bem a todos envolvidos o significado disto, de forma que novos projetos de software reduzam a chance de serem forçados a transformar um prédio de papel em um arranha céu.