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).
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).

Oi Thiago. Sinto-me desconfortável com diversas questões sobre engenharia de software há muito tempo. Em particular, aquelas relacionadas com métricas. A seguinte frase tem me trazido muitos incômodos: "You can’t control what you can’t measure." Ela não circulava nas minhas veias com naturalidade. Foi, então, que me deparei com o seguinte: http://www.systemsguild.com/pdfs/TDMSoftwareSummer2009.pdf
ResponderExcluirWow, "Strict control in something that matters a lot in relatively useless projects and much less on usefull projects" - lembrando que usefull/useless referia-se a valor agregado (não aquele valor agregado do PMBOK).
ResponderExcluirOutro pedaço que me chamou atenção foi "sw dev is and will always be somewhat experimental.The actual sw construction isn't necessarly experimental, but it's conception is".
Thiago, qdo tiver tempo de uma olhada no video
ResponderExcluirhttp://www.infoq.com/presentations/agile-metrics
me diga o que vc acha do sobre "what is rewarded gets done"
A man went fishing one day. He looked over the side of his boat and saw a snake with a frog in its mouth. Feeling sorry for the frog, he reached down, gently took the frog from the snake, and set the frog free. But then he felt sorry for the snake. He looked around the boat, but he had no food. All he had was a bottle of bourbon. So he opened the bottle and gave the snake a few shots. The snake went off happy, the frog was happy, and the man was happy to have performed such good deeds. He thought everything was great until about ten minutes passed and he heard something knock against the side of the boat. With stunned disbelief, the fisherman looked down and saw the snake was back with two frogs! "What Gets Rewarded Gets Done," by Michael LeBoeuf
ResponderExcluirOlá Pessoal.
ResponderExcluirDesculpem a demora para responder, foi um mês bem conturbado.
Bom, primeiramente terei a ousadia de discordar do Tom DeMarco ao voltar atrás do que falou. Acho razoável não usar tantas métricas quanto possível o tempo todo, pois de fato elas tem um custo razoável, mas não vejo um projeto bem gerido sem nenhum tipo de métrica.
Na pior da hipóteses, as métricas de produtividade servirão somente para criar desafios para as pessoas aumentarem seu nível atual de produção. Claro que há diferentes tipos de produção, e alguns são difíceis de medir. Um exemplo é o arquiteto, que faz um trabalho difícil que leva muito tempo, e depois de pronto os demais da equipe podem reutilizar em minutos, mas isso também deve ser levado em conta.
Em relação ao comentário do "WTF Venezuela", eu concordo que a métrica não deve permitir que as pessoas sejam recompensadas pelos próprios erros ou permitir que as pessoas tomem ações para manipular as métricas como nos quadrinhos que linkou. Até por isso que no exemplo que citei, a criação de erros contava "negativamente" na pontuação do desenvolvedor, de forma que criar erros para depois corrigir não levava a nada.
Adicionalmente, minha opinião é que nada é absoluto. Ao criar uma métrica, temos de acompanhar e verificar se elas estão atendendo a seus objetivos, e se não estiverem, mudá-las. Concordo com premiações por bom desempenho sim, mas não comecei a fazer isso antes de ver que as coisas estavam "nos trilhos" conforme esperado, o que aliás não aconteceu antes de muitas correções.
O que vejo na maioria dos projetos sem métricas é que muitos integrantes das equipes tem dificuldade de enxergar o quanto eles contribuem para o todo, e nisso acho que a métrica ajuda muito.
Em relação as distorções, acho que elas podem ser corrigidas ao longo do tempo e discutidas com a equipe a todo momento, e por isso eu tinha as reuniões mensais para discutir as métricas.
Enfim, concordo que não adianta acompanhar tudo quanto é métrica existente, mas ainda discordo que um projeto sem métrica alguma vá ter o melhor desempenho possível, mesmo que eventualmente traga retornos enormes.