Melhoria contínua no time de Engenharia

Eu compartilhei no post “Acompanhando o desempenho individual do time” sobre a iniciativa de coletar e compartilhar as métricas individuais de Engenharia. O que me motivou a fazer esse tipo de trabalho, foi o fato de que as métricas do time estavam boas, mas nem todas as pessoas contribuíam para as métricas de forma balanceada. E basear a avaliação e desenvolvimento do time nas métricas é uma forma de reduzir vieses e ser mais justa na minha avaliação.

Nesse post, vou compartilhar como foi a primeira rodada de negociação e acompanhamento das métricas individuais.

Métricas avaliadas

Apenas relembrando, eu estou acompanhando as seguintes métricas individuais:

• Quantidade de itens concluídos no Jira
• Quantidade de reviews de PRs feitos
• Quantidade de QAs validados
• Média do Cycle Time

Eu tenho um arquivo no Excel, que possui uma aba para cada desenvolvedor com uma tabela e um gráfico mostrando a evolução das métricas. E é através dele que eu registro e acompanho os números do time.

Definição de metas

Inicialmente, eu estava apenas compartilhando as métricas com os integrantes do time para que eles também pudessem avaliar o seu desempenho. A partir de outubro, defini metas para cada um, baseadas na senioridade e no que eu entendia como ponto de melhoria.

Usei o 1:1 de cada um para apresentar as métricas que eu tinha definido. Ninguém foi obrigado a aceitar os números e todos puderam negociar métricas mais factíveis. Como é a primeira rodada, a minha intenção é que todos se preocupem com as métricas e com os impactos de não seguir o processo de Engenharia corretamente.

O meu combinado com o time é que vamos rever as métricas no final do primeiro trimestre do ano que vem. A ideia é ir aumentando a expectativa através das metas e ver o time evoluindo de forma constante.

Depois que as metas foram combinadas, eu adicionei em cada aba do arquivo no Excel mais uma tabela contendo as metas de cada um. A partir das métricas de novembro, comecei a colorir a tabela que já existia com um código de cores:

• Verde: atingiu ou superou a meta
• Amarelo: quase atingiu a meta
• Vermelho: não atingiu a meta

Pretendo manter essa visualização para ficar mais clara a interpretação do quanto cada um atingiu as metas ao longo do tempo.

Diferença no dia a dia

Todos os integrantes do time já sabem que precisam desenvolver os itens no Jira, reservar um momento para revisar PRs, reservar um momento para validar QAs e manter uma média baixa de Cycle Time enquanto respeita todas as etapas do processo de Engenharia. Porém, nem todas as pessoas seguiam essa recomendação.

No cenário anterior, eu tinha um desenvolvedor que se destacava por entregar muitos itens, outro que se destacava por validar muitos QAs e assim por diante. Mas todos os desenvolvedores precisam trabalhar em todas as tarefas que fazem parte do papel. Até mesmo para evitar que alguém seja sobrecarregado com uma das tarefas para compensar a falta de apoio de alguém.

Depois que defini metas individuais e estabeleci que o time todo seria cobrado pelas métricas do time e cada integrante seria cobrado pelas métricas individuais, a diferença no dia a dia foi percebida quase que imediatamente.

Antes, uma mensagem de validação de QA poderia passar mais de um dia aguardando alguém para testar. Agora, não se passam nem 10 minutos sem alguém puxar a validação. Antes, um card no Jira bloqueado era apenas mais um card esperando algum retorno. Agora, vejo as cobranças na Daily e a preocupação em fazer o card ser desbloqueado.

Definir metas individuais e deixar claras as expectativas sobre cada um moldou o time de uma forma que deu menos trabalho do que eu imaginava.

Observações

A última afirmação só é verdadeira porque eu decidi ser um pouco inflexível. Por exemplo, o time deve indicar que validou um QA ao marcar a mensagem de teste disponível com emojis no Slack. Por várias vezes, o time esquecia de sinalizar e o card andava no Jira sem esse acordo ser cumprido.

A partir do momento em que eu só contava nas métricas individuais os QAs em que as mensagens foram sinalizadas, caiu muito a taxa de esquecimento do time. Isso aconteceu após a primeira apuração, quando mais de uma pessoa não concordou com as métricas. Depois de mostrar como fiz a contabilização (que está documentada para o time), todos concordaram que não seguiram o processo. E deixei claro que só vou considerar o que for feito de acordo com o combinado.

Não mudei as métricas e elas se mantêm “incorretas” nas tabelas até hoje, como um lembrete para que todos sinalizem os testes.

Parece um pouco rígido, mas eu tenho certeza que se a excessão for aberta e eu ficar retificando as métricas após cada reclamação, ninguém vai lembrar de seguir o processo. As métricas vão moldar o comportamento e se eu manipular o que está registrado, eu vou desfazer o bom resultado que poderia estar tendo.

Até o momento, estou bem satisfeita com os resultados que estou obtendo. O time está mais atento, consegui compartilhar a responsabilidade de acompanhar as métricas e vejo a melhoria no dia a dia.

Para que as métricas de um desenvolvedor batam a meta, os outros desenvolvedores também precisam fazer o seu trabalho. Se ninguém desenvolver itens no Jira, não vai ter QA para validar nem PR para revisar. Então, o ciclo precisa ser completo para que todos batam as suas metas. O que significa que o time inteiro vai passar a se atentar ao trabalho do outro.

Também é importante salientar que nenhuma meta foi inventada sem nenhum critério. Eu me baseei na quantidade média de itens entregues por mês e considerei as médias dos meses anteriores para definir a meta de cada um. Quem estava muito abaixo em alguma métrica, teve números mais desafiadores. Também estou comprometida em manter o backlog sempre em dia junto da PM, porque se não tivermos demanda, não podemos cobrar entregas do time.

Espero que ter compartilhado esse processo contigo tenha sido útil.

Até a próxima!

Copiar link