Acompanhando o desempenho individual do time

Dentro do time de Gestão de Engenharia que trabalho atualmente, nós temos a Operation Review, um ritual em que compartilhamos o acompanhamento do desempenho do time. Mesmo compartilhando essas métricas com o próprio time, não ter uma visão individual pode não dar o senso de urgência necessário para quem não está num bom ritmo.

Pensando nisso, comecei a compartilhar com cada integrante as suas métricas individuais antes de apresentar a Operation Review. A intenção é que cada pessoa consiga comparar as suas métricas com as métricas do time e entender em quais atividades precisa dar mais atenção.

Nesse post, vou compartilhar as métricas atuais compartilhadas com o time e o que entendo que cada liderado pode fazer para melhorar ou se manter num bom patamar.

Métricas do time

Dentro da Operation Review, as seguintes métricas são acompanhadas:

• Quantidade de deploys
• Cycle Time
• Refactory
• Rework
• Itens entregues
• Quantidade de tipos de itens entregues

Para entender um pouco mais sobre cada um delas, esse post que escrevi no Medium é bem útil.

Métricas individuais

Antes de apresentar a Operation Review para o time, eu passei a compartilhar as seguintes métricas individualmente:

• Quantidade de itens no Jira
• Reviews de PRs
• Quantidade de QAs validados
• Cycle Time

Cada uma delas representa uma dimensão importante do trabalho de desenvolvimento e fornece informações suficientes para a construção de um plano de ação.

Quantidade de itens no Jira

Uma das métricas mais importantes para se acompanhar na Squad é a quantidade de itens desenvolvidos. No nível do time, eu também acompanho quais tipos de itens estamos entregando para também saber o quanto estamos trabalhando em novas funcionalidades, em bugs e débitos técnicos.

Esse acompanhamento é importante para ter um fluxo de trabalho equilibrado, mas, mais importante ainda, é saber o quanto cada integrante colabora com esse número.

Dentro do Jira nós temos um campo chamado “Multiple users”, em que ficam registrados todos os usuários que se envolveram com o desenvolvimento. É através desse campo que eu faço a contagem das entregas para cada integrante.

Além de enviar a quantidade de itens entregues em que cada um esteve envolvido, também envio a porcentagem dessa quantidade em relação ao total do time. Por exemplo, se o time entregou 10 itens e o integrante se envolveu em 2 deles, então eu envio a informação de que ele entregou 2 itens que representam 20% do trabalho do time.

Essa informação da porcentagem é importante para que seja possível fazer uma autoavaliação mais direta do impacto do integrante do time. Se um integrante entregar 10 itens em um mês quando o time todo entregou 20 itens, ele tem um impacto totalmente diferente do integrante que entregou 10 itens quando o time inteiro entregou 12.

Também é importante considerar nessa métrica que os itens possuem tamanhos diferentes. Por isso, apenas o número de itens e a porcentagem em relação ao time não podem ser os únicos pontos a serem avaliados.

Como melhorar:

• Avaliar se está pegando apenas itens muito grandes e, se for o caso, também dar visibilidade sobre a quebra dos itens para o responsável pelo backlog
• Ajudar na quebra dos itens durante o Refinamento
• Atuar em bugs e em débitos técnicos
• Sinalizar os impedimentos assim que eles acontecem
• Revisar o quadro do Jira com frequência para mantê-lo atualizado
• Tirar dúvidas frequentemente com os colegas
• Se manter atualizado nas mudanças dos acordos do time

Reviews de PRs

Nós temos o acordo de que todos os PRs devem ter pelo menos duas aprovações antes de seguir adiante no fluxo. Pensando na disseminação de conhecimento e no apoio entre as Squads, é esperado que o time faça revisões de PRs de outros times. Assim como o time também pede que outras Squads façam o nosso review.

Por isso, uma métrica importante para acompanhar é o número de reviews de PRs feito por cada desenvolvedor. A ferramenta que usamos conta o número de comentários no PR, por isso uma aprovação sem ressalvas deve sempre ter pelo menos um comentário de aprovação para ser contabilizada.

É importante acompanhar o nível de revisão de PRs de cada integrante do time, porque todos dependem da revisão de outros. E o fluxo só vai andar em todos os times se todos contribuírem com as revisões.

Essa também é uma métrica que eu compartilho o número bruto junto da porcentagem.

Como melhorar:

• Dedicar um momento do dia para fazer a revisão de PRs de outros times
• Passar a enxergar a revisão de PR como um processo importante para aprendizado dos outros pontos do sistema
• Revisar PRs de outros times sempre que estiver esperando o retorno de algum impedimento que não depende da sua atuação para resolver ou quando estiver aguardando a validação do seu QA
• Lembrar que quem revisa muitos PRs sempre tem os seus PRs revisados, porque a revisão não deixa de ser uma troca de favores entre os times

Quantidade de QAs validados

Nós não temos um profissional dedicado para fazer os testes e essa tarefa é compartilhada entre os desenvolvedores, o PM e o Designer.

Por isso, nós temos uma etapa de validação de QA no quadro em que é esperado que todos colaborem para apoiar no avanço do card.

Assim como na revisão dos PRs, todos dependem da validação de QA e o mais justo é que todos apoiem na revisão dos QAs dos colegas. Assim, todos se ajudam e, ao mesmo tempo, ficam cientes do que está subindo em produção no detalhe.

Essa métrica não havia sido compartilhada inicialmente, mas o time sugeriu que também fosse incluída no relatório. Assim como nas anteriores, a porcentagem relativa ao time também é incluída.

Como melhorar:

• Avaliar a sua disponibilidade para validar um QA assim que ele for aberto e notificado
• Dedicar um momento do dia para conferir se tem um QA disponível para validar
• Passar a enxergar o processo de validação de QA como uma forma de evitar incidentes em produção e acionamentos urgentes pós deploy
• Assim como na revisão de PR, validar QAs sempre torna os colegas mais propensos a validar o seu QA também

Cycle Time

O Cycle Time é o tempo necessário para que o time de Engenharia entregue uma demanda. Ele começa a contar a partir do momento em que o card no Jira é passado para IN PROGRESS e vai até quando o código é mergeado em produção.

Esse número é compartilhado sem a porcentagem, apenas o número bruto. Como é uma métrica de tempo, fica bem fácil para cada um comparar a sua métrica com a métrica média do time.

Por exemplo, se o time está com uma média de 3 dias e a métrica individual é de 6 dias, fica muito claro que o integrante está contribuindo para aumentar a média do time.

Como melhorar:

• Avaliar quais são os gargalos do fluxo. Em quais etapas você costuma demorar mais? Em quais tipos de demanda você tem mais dificuldade de concluir o desenvolvimento?
• • Identificando esses gargalos, definir estratégias para superar esses desafios quando eles forem encontrados novamente
  • Caso os gargalos envolvam o time, levar os pontos para a Retrospectiva
• Garantir que entendeu o que está descrito na demanda e como deve ser desenvolvido. Participar ativamente e prestar atenção do Refinamento de negócios e do Refinamento técnico é uma forma de ter essa garantia
• Ler o card novamente quando for iniciar o desenvolvimento, para dedicar mais tempo entendendo o resultado esperado antes de começar a escrever o código
• Pensar em opções de soluções antes de iniciar o desenvolvimento
• Em casos de bugs, tentar reproduzir o comportamento para entender se ainda está ocorrendo antes de pensar em qualquer solução

Próximos passos

Depois de compartilhar as métricas com cada integrante, é feita a apresentação para todos das métricas do time no formato da Operation Review.

Assim, todos os integrantes do time estão sabendo as suas próprias métricas antes de ver as do time. Ficando mais fácil de comparar o seu desempenho com o geral.

Idealmente, quando alguém identifica que está com um desempenho descolado do time, a métrica pode ser o foco de discussão de um próximo 1:1.

Quem está focado em melhoria contínua geralmente se preocupa bastante com esse tipo de informação e eu, como gestora, posso ajudar dando a visibilidade dos números e ajudando a montar um PDI focado em melhorar essas métricas. Porém, é sempre importante lembrar que as mudanças dependem muito mais de cada liderado do que do líder.

Apenas para ficar bem claro, eu faço o compartilhamento das métricas individuais no chat privado de cada um. Se eles decidirem compartilhar com o time, tudo bem. Mas fica como decisão individual.

É importante sempre considerar o contexto das métricas. Por exemplo, se alguém estava de férias em certo período ou até mesmo apoiando outra Squad. Os números sozinhos sem análise podem nos enganar e nos fazer focar nos pontos errados para melhorias.

Espero que compartilhar esse ritual contigo tenha sido útil e fica a sugestão de que acompanhes as tuas métricas individuais também.

Até a próxima!

Copiar link