Mecanismos para medir a performance de equipes podem se tornar uma grande armadilha se mal utilizados.
Em engenharia de software os Métodos Ágeis habilitaram práticas como Story Points e Velocity. O Método Kanban trouxe para esse mundo a visão da gestão de fluxo e com ela muitas métricas como Lead Time, Throughput, Flow Eficiency, entre outras. São excelentes ferramentas, mas o uso requer bom senso.
O exemplo fictício abaixo ilustra uma situação comum que requer nossa atenção:
Imagine uma estrutura com squads (times multifuncionais) utilizando gestão de fluxo no dia a dia. Ambas pertencem a uma big tech que tem em seu portfólio muitos produtos já lançados em escala e gerando receita. Cada squad da estrutura é responsável pelo desenvolvimento de um produto. Abaixo um histórico do Throughput (vazão de entrega) de 3 meses de duas Squads:
É importante dizer que comparar métricas entre fluxos não é uma boa idéia pois são contextos e muitas vezes produtos e tecnologias diferentes. Porém apenas para fins didáticos, qual squad você acredita que performa melhor?
Na perspectiva da eficiência, não tenho dúvidas que escolherá a primeira. Porém abaixo trago dados referentes aos resultados dos produtos de cada squad:
Produto Squad 1:
– Jan: Incremento de 5% na receita em comparação ao mês anterior, taxa de churn (abandono) estável
– Fev: Redução de 2% na receita em comparação ao mês anterior, aumento de 8% na taxa de churn.
– Mar: Redução de 12% na receita em comparação ao mês anterior, aumento de 8% na taxa de churn.
A squad 1 trabalhou em uma lista de features priorizadas desde o ano anterior, fizeram horas extras para reduzir o backlog (principalmente o de bugs). Conseguiram.
Produto Squad 2:
– Jan: Incremento de 5% na receita em comparação ao mês anterior, taxa de churn estável.
– Fev: Incremento de 5% na receita em comparação ao mês anterior redução de 5% na taxa de churn.
– Mar: Incremento de 10% na receita em comparação ao mês anterior, redução de 7% na taxa de churn.
A squad 2 investiu uma parte considerável do tempo de trabalho em um Discovery. Este habilitou o desenvolvimento de 2 features matadoras, muitos clientes migraram de concorrentes com a novidade que foi bem simples e rápida de desenvolver. Com o restante do tempo fizeram algumas refatorações e aumentaram a cobertura de testes automatizados (que já era bem alta).
Espero que esse exemplo gere uma reflexão sobre o que consideramos como alta performance e resultados.
A realidade é que novas funcionalidades ou mudanças em funcionalidades existentes não necessariamente incrementam valor real. Ao contrário, podem complicar demais o uso, gerando churn e migração para concorrentes. Novas funcionalidades também aumentam a complexidade do código, testes, processamento, débitos técnicos, etc.
Outra verdade indigesta: Ociosidade ainda é visto como algo pior do que a falta de eficácia. Preferimos ocupar o tempo das pessoas com coisas erradas do que vê-las “paradas” enquanto não descobrimos a coisa certa. Isso é potencializado pelo tamanho/custo da estrutura ou da equipe. Quanto maior, mais se faz necessário justificar o investimento (erroneamente com mais trabalho).
Conclusão:
Manter equipes enxutas, focar em eficácia (sem esquecer a eficiência), promover colaboração e troca de conhecimento, entregar as funcionalidades certas (utilizando método científico, UX e principalmente dados), na hora certa, com alta qualidade (Testes) e principalmente medir e recompensar por resultados reais são essenciais para a sobreviver e prosperar em um mundo cada vez mais complexo e competitivo.
*Se você gostou desse conteúdo, deixe 50 claps (palmas), compartilhe em suas redes e siga o perfil da DBServices pra não perder os próximos artigos.
