A parte mais difícil de toda iniciativa quase nunca é o software. Geralmente, a complexidade está em toda a estrutura envolvida, na lógica e nos processos que precisam ser criados para que o software seja útil.
Imagine você e seus pares decisores em um cenário em que precisam tomar decisões baseadas em dados, como em qual setor investir ou retirar dinheiro, por exemplo, atualmente seria possível?
Por que pensar em coleta de dados?
Se você possui um time de tecnologia para gerir, já deve ter se perguntado pelo menos uma dessas perguntas:
- Quantas features estou entregando por sprint?
- Qual o tempo médio de desenvolvimento do meu time por issue?
- Quantos bugs são abertos por feature desenvolvida?
- Qual a % de retrabalho no meu setor?
Caso você tenha conseguido responder essas perguntas, parabéns! Você já possui uma base sólida para tomar decisões.
Porém, caso não consiga, não se desespere. No momento que escrevo essa série, eu também não consigo, mas o meu time segue entregando.
Então se o time está entregando, por que pensar em mais uma camada de complexidade na esteira?
Entenda que muitas minuciosidades em desenvolvimento de software podem gerar grandes impactos no resultado final e no longo prazo.
Se eu não sei o tempo médio por tarefa, como sei quantas features vou entregar para o meu cliente em 15 dias? Se eu não sei a taxa de bugs por feature, como sei que a qualidade das entregas está dentro do esperado?
São perguntas que a gente pode tentar responder com empirismo, certo? O feeling do dia a dia. Mas muitas vezes o nosso feeling pode não estar 100% alinhado com a realidade. Nisso, podemos sobrecarregar o time com tarefas demais, subutilizar com tarefas de menos, entregar algo ruim por conta da alta taxa de bugs e sucessivamente.
E é aí que a decisão baseada em dados e inteligência faz a diferença.
Quais dados coletar?
Para decidir isso, eu fui pelo caminho de: que perguntas eu quero responder hoje e não consigo?
Sendo honesto, as perguntas que listei anteriormente já cobrem boa parte das perguntas que eu não consigo responder hoje.
E mesmo que você não tenha nem as perguntas para responder no momento, existem várias métricas de senso comum nas metodologias ágeis que podem te guiar nesse processo (e também me guiaram). Nesse texto, estou trazendo um pouco da minha linha de raciocínio para que você possa se inspirar e criar a sua própria. Algumas delas são:
- Lead Time: informa qual o tempo médio que o time leva para entregar uma demanda, desde a criação da issue até a entrega em produção. É o tempo total que o cliente aguarda pela feature.
- Cycle Time: informa qual o tempo médio que o time leva para entregar uma demanda, desde o início do desenvolvimento até a entrega em produção. É diferente do Lead Time, pois aqui, medimos o tempo em uma etapa específica (design, desenvolvimento e etc).
- Throughput: informa quantas demandas o time consegue entregar em um determinado período de tempo.
- WIP (Work in Progress): informa quantas demandas estão em andamento no momento.
- Bug Rate: informa qual a taxa de bugs encontrados em produção por demanda entregue.
- Rework Rate: informa qual a taxa de retrabalho necessário para corrigir bugs encontrados em produção.
- Defect Density: informa qual a densidade de defeitos encontrados em produção por demanda entregue.
- Customer Satisfaction: informa qual o nível de satisfação do cliente com as demandas entregues.
- Team Satisfaction: informa qual o nível de satisfação do time com as demandas entregues de maneira intersetorial (saber como o time de dev se sente em relação ao QA e ao design, por exemplo).
Note que muitos dos itens são relacionados às perguntas que citei anteriormente. Essas métricas realmente são generalistas e premissas de desenvolvimento de software.
Como coletar?
Essa é a pergunta que ainda estou respondendo e construindo, pois o processo não está 100% finalizado. Porém, para te adiantar, essas métricas podem ser coletadas de diversas formas, como:
- Ferramentas de gestão de projetos (Linear, Jira, Trello, Asana, ClickUp e outros)
- Ferramentas de monitoramento de bugs (Sentry, Bugsnag, etc)
- Ferramentas de monitoramento de performance (New Relic, Datadog, etc)
- Pesquisas de satisfação com clientes e time
O importante é que você consiga coletar os dados de forma consistente e confiável para que possa tomar decisões baseadas em dados e não em feeling.
Conclusão
Nesse momento, as métricas que decidi coletar estão estabelecidas, e o processo de coleta está sendo construído.
Nos próximos posts, vou detalhar esse processo de construção e os resultados preliminares na UEEK.
Se você chegou até aqui, espero que esse texto tenha te inspirado a pensar em como coletar dados na sua esteira de engenharia e como isso pode impactar positivamente o seu time e o seu negócio.