KPIs para medir a produtividade do desenvolvimento de software

Para além de acompanhar e dar encaminhamentos para os processos de desenvolvimento, fatores que definem a gestão de produtos, os gestores também precisam se atentar a outros fatores como a performance da sua equipe e do projeto. A partir de bons indicadores, eles terão a verdadeira consciência dos prazos, desempenho da equipe e andamento do projeto.

Continue na leitura para evoluir suas habilidades de gestão de projetos!

O que são KPIs? Como escolhê-las?

Os key performance indicators são fatores-chave que nos permitem identificar e interpretar a performance de algo ou de alguém. Todos os segmentos possuem os seus próprios indicadores, seja área da saúde, marketing, tecnologia ou qualquer outra. Diferente de métricas, os KPIs são indicadores que visam um objetivo de negócio e não apenas uma mensuração. Isto é, quando se trata de um valor meramente informativo, sem um propósito para interpretar uma situação, aí os valores passam a ser apenas métricas.

Esse comparativo importa uma vez que os gestores estão visando otimizar produtividades de desenvolvimento. Assim, não é qualquer indicador que deva ser levado em consideração para realmente indicar a performance. Podem existir inúmeras métricas, mas somente as que verdadeiramente exprimem um objetivo do negócio e da atividade que podem ser considerados indicadores-chave.

Dito isso, podemos avançar para exemplos de indicadores de produtividade do desenvolvimento de software.

Quais são os principais KPIs de desenvolvimento de software?

Cada projeto e empresa podem ter os seus principais indicadores de produtividade do desenvolvimento de software, mas existem aqueles que são comuns entre os gestores de produtos, tais como:

Tempo de entrega

A agenda do produto é um dos principais indicadores de produtividade, pois a partir dos prazos é possível separar as atividades do produto de forma que existam entregas contínuas até que ele seja entregue por completo.

A partir disso, a pessoa responsável pela gestão consegue compreender se o produto está em atraso ou adiantado, permitindo criar plano de ação e se antever em casos de imprevistos, por exemplo.

As metodologias ágeis são as principais ferramentas utilizadas para garantir que a agenda do produto seja cumprida (assim como o roadmap), bem como o uso de ferramentas que facilitam o acompanhamento das atividades, tal como o Gitlab.

Work in progress

O “work in progress” diz respeito à quantidade de atividades que já saíram do backlog. Ou seja, um balanço entre o quanto foi feito, o que está em andamento, o que ainda tem restante no backlog e também o total de atividades determinadas. Por isso, ele é diferente do KPI “tempo de ciclo”, que discutiremos no próximo tópico.

A interpretação do WIP pode ditar à gestão não só o desempenho do produto, mas também o da equipe no sentido de que, quando há um work in progress alto, isso quer dizer que existem muitas atividades sendo executadas simultaneamente. Este caso representa uma sobrecarga da equipe, o que também pode estar relacionado ao KPI sobre bugs.

Destaco este fator porque, quando tudo é prioridade, nada é prioridade. A partir disso, problemas podem surgir e a produtividade pode reduzir — bem como a qualidade. Com isso, o work in progress é um excelente indicador de produtividade de desenvolvimento.

Enquanto um alto WIP pode indicar sobrecarga, um WIP baixo também pode indicar ociosidade, ao passo que também indica maior foco e qualidade das entregas. Assim, tudo dependerá do cenário e contexto o qual o produto está inserido e a equipe.

Dessa forma, afirmo que o WIP por si só não basta para avaliar a produtividade da equipe, mas que outros indicadores devem ser levados em consideração para captar o real cenário do squad.

Tempo de ciclo

Diferente do que é o lead time, o tempo de ciclo — ou cycle time — é uma representação real que contempla desde o início de uma atividade até que ela esteja pronta para ser entregue de fato. Isto é, a etapa inicial começa no momento que o card no Git é movido do backlog para o doing e termina apenas quando está em produção ou quando é entregue para o cliente — este caso se tratando da terceirização de desenvolvimento.

Com esse entendimento do quanto a equipe ou pessoas do squad levam de tempo para determinadas tarefas, é possível medir e entender o padrão de comportamento. Esse é um fator interessante para futuras previsibilidade de projetos e também para encontrar gaps que convém otimizações, dentre outros insights.

Velocidade das sprints

O KPI velocidade das sprints é diferente do tempo de ciclo e também o lead time, uma vez que sua mensuração é o período da sprint apenas. 

Por padrão, as sprints têm durabilidade de 15 dias. No entanto, há atividades que podem ser resolvidas antes deste período. Assim, as sprints são ótimas indicadoras da agilidade e eficiência do processo de desenvolvimento e também da equipe.

Segundo nossa gestora de projetos aqui na Usemobile, Estefani Silva, ela recomenda o acompanhamento das sprints, pois elas permitem medir o tempo de ciclo. “Com ela podemos medir desde a concepção até a entrega para o cliente final”. 

Ela complementa dizendo que, “mesmo antes de entrar na esteira, já utilizamos a sprint para medir o desempenho e entregas. Isso é importante para sabermos se nossas estimativas estão sendo assertivas e se estamos conforme o esperado falando do ponto de vista do orçamento previsto”.

Retrabalho

Para o desenvolvimento de software, o retrabalho significa diversas coisas. Por si só, o retrabalho já é considerado um KPI interessante de se manter baixo, uma vez que entendemos a necessidade de refazer algo como um desperdício de tempo ou similares.

De fato, essa lógica está correta. No entanto, existe um fator que não necessariamente diz respeito sobre a equipe de desenvolvimento em si, pois o retrabalho também pode ser causado por clientes e pessoas à frente dos papéis decisores. 

Isto é, se um aplicativo começa a ser desenvolvido num escopo e passa a ter um novo escopo, seja para adicionar ou remover uma funcionalidade, isso acaba por gerar retrabalho na equipe. Essa é uma situação possível de acontecer.

Outro fator a se considerar sobre o retrabalho também é a senioridade da equipe e a necessidade de aprendizado, visto que existem projetos que desafiam as pessoas envolvidas, sendo necessário aprender novas tecnologias.

Com isso, o retrabalho pode acontecer também. Assim, com muitos retrabalhos acontecendo, é sinal que novos talentos possam agregar à equipe — ou consultorias e terceirização do desenvolvimento.

Ou então, este retrabalho também pode representar a qualidade do trabalho: quanto menor a necessidade de refazer, maior o sinal de produtividade e qualidade do desenvolvimento de software.

Bugs

Num caminho similar ao retrabalho, a frequência que bugs aparecem nos produtos também são indicadores de produtividade que é interessante de se manter baixa. Isso porque os bugs são negativos para a usabilidade e experiência dos usuários.

Dessa forma, quanto menor a necessidade de criar tarefas para a correção de bugs, maior o indicativo de que a produtividade de desenvolvimento de software está num caminho desejável e com qualidade.

Variação do orçamento

Uma variável bastante importante para o cotidiano dos gestores de produtos é o orçamento, o qual é alocado para determinar:

• o tempo e esforço das pessoas;
•  custo do desenvolvimento;
•  ferramentas utilizadas;
• infraestrutura de TI;
•  demais outros itens que forem condizentes com o projeto.

Dito isso, o orçamento realmente utilizado durante o desenvolvimento do projeto deve ser equivalente ao que foi disponibilizado. Isso implica numa alta capacidade de mensuração e entendimento dos valores, como uso de infraestrutura e o custo por hora das atividades das pessoas envolvidas nas atividades do produto.

Esses são fatores que esbarram no triângulo da gestão de projetos, que busca um equilíbrio entre os pilares escopo, recursos e tempo, no qual ele dita que:

• Projetos de escopo grande e recursos moderados requerem um maior tempo;
• Grandes escopos e tempo limitado tornam os recursos caros;
• Recursos moderados e tempo limitado.

Por isso, a gestão dos recursos deve ser equilibrada para que sejam evitados cenários negativos para o desenvolvimento. Com isso, um orçamento bem utilizado acaba se tornando um bom KPI para medir a produtividade do desenvolvimento dos softwares.

Satisfação do usuário

Partindo do ponto de que os produtos são feitos para pessoas, certamente que o feedback dos usuários entraria como um KPI para indicar a produtividade do desenvolvimento de software.

Ainda que o cliente não veja problemas ou falhas de usabilidade, os usuários finais são as fontes mais confiáveis para este tipo de feedback. Por isso, atentar-se ao que é falado sobre o produto é um KPI excelente. 

Se tratando especificamente do nosso cenário na Usemobile, nossa equipe fica atenta também aos comentários nas lojas de aplicativos para que sejamos rápidos nas correções e gerar o menor impacto possível quando convier.

Contudo, é importante ressaltar também que os usuários se sentem mais motivados a darem feedbacks quando se sentem insatisfeitos. Logo, não ter comentários de elogios nas lojas, por exemplo, acaba por ser um bom indicador também. Aqui é importante ter um olhar analítico no momento de avaliar o comportamento do usuário.

Como escolher seus KPIs?

A primeira premissa é assumirmos que os projetos possuem as suas particularidades. Se tratando de um projeto que é interno de uma empresa, a realidade é uma. Quando é o caso da terceirização de desenvolvimento, o cenário já vai pra outro campo; assim como quando falamos da gestão de um produto próprio de uma empresa (ou produtos).

Se tratando do último cenário, KPIs que envolvem faturamento da empresa, outras métricas podem ser tomadas como KPIs como o ROI (Retorno sob o Investimento). 

Já quando falamos de uma relação de terceirização de desenvolvimento, todos os indicadores apontados ao longo do artigo se fazem relevantes. Não necessariamente fazer o uso de todos, mas escolher os que melhor refletem a realidade da sua equipe.

Neste caso, o importante é fazer as entregas com qualidade e no tempo programado. Assim, o tempo de entrega, retrabalho e variação do orçamento soam interessantes.

No entanto, se houver uma alta taxa de retrabalho, o work in progress e velocidade das sprints podem se acolhar para entender a produtividade da equipe e realizar um plano de ação em cima, seja ele oferecer maior capacitação técnica para a equipe, contratar mais pessoas, dentre outras possibilidades.

Ser gestor de projetos implica ter as habilidades de análise bem trabalhadas para identificar os gargalos e melhor otimizar a equipe. Entendendo as dificuldades da equipe e do projeto, ficará mais fácil de detectar quais KPIs fazem sentido utilizar.

Concorda? Compartilhe a sua opinião nos comentários!