Se você gerencia um produto de software que já está em uso, é bem provável que já tenha se deparado com duas perguntas ao pensar em evoluções e melhorias da aplicação:

• Como priorizá-las?
• Quando elas serão entregues?

Neste artigo, teremos a oportunidade de discutir algumas abordagens que poderão ajudar você a responder tais questionamentos.

Tenho observado um movimento de gestão de produtos que vem concretizando os princípios por trás do Lean Startup que diziam: construa, meça e aprenda. A partir da ótica de medir e aprender, é perceptível que gestoras e gestores de produto começam a levantar hipóteses de negócio a partir de métricas como taxa de conversão, recorrência mensal, taxa de evasão, análise da interação dos usuários nos fluxos críticos da aplicação etc.

Voltando para a primeira pergunta que abriu o texto, nos deparamos com atributos quantitativos que nos permitem priorizar o que precisamos construir. Tal ferramenta sustenta a ideia de que estamos interessados em melhorar os resultados do produto a partir de números.

Antes que alguém me crucifique, nem só baseados em números devem ser os fatores para a priorização de novas features dos produtos que trabalhamos. Caso você tenha a possibilidade de se aproximar do seu usuário para perguntá-lo o que ele deseja, você também estará aumentando a probabilidade de construir algo que traga valor para ele. Dados qualitativos podem ser coletados através de questionários online, pesquisas de campo, análises de interação a partir de protótipos etc.

Ao priorizarmos uma funcionalidade, estamos em busca de gerarmos uma solução que traga valor para nossos usuários, clientes, acionistas e empresa. Em outras palavras, podemos dizer que estamos em busca de encontrarmos uma relação positiva na equação de valor que nada mais é do que a diferença entre o valor criado pela solução, menos o preço pago por ela #maisvalorporfavor.

Dado que priorizamos aquilo que é mais importante para a saúde do produto e para os usuários, um segundo questionamento que por vezes fica na cabeça é: quanto tempo levaremos para entregar essa nova feature?

Partindo do pressuposto que vivemos em um contexto incerto (sim, acredite, desenvolver software não é algo determinístico), trabalhar com cenários de entrega passa a ser uma abordagem mais confiável. Ao utilizar projeções, você passa a calcular ou predizer um evento futuro a partir da análise dos dados disponíveis (passado).

Para que isso seja possível, sugiro que você e a sua equipe passem a monitorar uma métrica de processo: lead time (número de dias entre o início e o fim do processo de entrega de uma história do usuário, um bug etc).

Em outras oportunidades, tivemos a chance de discutir formas de analisar o lead time (“Looking at Lead Time in a different way” e “Why we love metrics? Learning with Lead time”), porém, gostaria de compartilhar como o percentil pode ser uma referência útil para desenhar cenários futuros a partir de referências do passado.

Se você não conhece, percentil é uma medida que divide a amostra ordenada (por ordem crescente dos dados) em 100 partes, cada uma com uma percentagem de dados aproximadamente igual. Traduzindo e relacionando com uma distribuição de lead time, é como se analisássemos o lead time das demandas que foram entregues e discutíssemos qual o percentual de chances de um determinado valor ser atingido a partir do percentil.

Em um projeto recente, utilizamos a informação de percentil para projetar possíveis prazos de entrega de uma demanda de negócio que havia sido priorizada pelo Product Owner (PO) da célula em que trabalhamos.

A equipe utilizou o histograma acima e passou a seguinte análise do cenário ao PO:

• 50% das demandas levaram até 6 dias para serem concluídas (mediana);
• 75% das demandas levaram até 12 dias para serem concluídas ou seja apenas 25% levaram mais do que tal limite para serem concluídas (percentil 75);
• 95% das demandas levaram até 18 dias para serem concluídas, o que nos leva a afirmar que apenas 5% delas levaram mais tempo do que isso para serem finalizadas (percentil 95).

A partir dos dados acima, o time demonstrou confiança de entregar a demanda entre 6 e 12 dias. Com tal informação em mãos, o PO traçou o plano de comunicação e promoção do novo recurso do produto. Se você ficou curioso em saber, a demanda foi entregue em 8 dias.

Ao utilizar tal abordagem de projeção, o time e o PO se sentiram mais confortáveis e confiantes. Caso o PO tivesse imposto para o time que a nova demanda deveria ser entregue em 3 dias, com posse das informações de percentil, o time teria insumos para dizer que seria muito difícil entregá-la pelo simples fato de que apenas 25% das demandas entregues foram concluídas no prazo determinado (percentil 25).

Fecho esse texto com algumas sugestões:

1. Crie hipóteses através de fatos que podem ser originados por dados quanti ou qualitativos;
2. Projete cenários de entrega a partir de uma referência (histórico do time);
3. Desenvolva pequenas entregas de valor, pois elas permitirão que você mude de direção mais rápido;
4. Não acredite que métrica de produto ou processo é algo burocrático, pois eles servem como uma base para você construir um futuro melhor.

E você? Como tem priorizado e projetado suas entregas? Quais métricas e abordagens tem utilizado? Compartilhe sua opinião nos comentários abaixo. Estou curioso para aprender com o seu exemplo.

Se está interessado saber mais como lidar com prazos de projetos de software não deixe de conferir nosso e-book gratuito sobre o assunto.

***

Este artigo foi publicado originalmente em: http://blog.plataformatec.com.br/2017/04/dilemas-de-uma-equipe-de-produto-desenhando-uma-entrega/