Três meses atrás, Michael Ballé nos visitou na Theodo e, mais uma vez, nos perguntou onde ele poderia ver o prazo de entrega de nossos produtos digitais. Envergonhados, respondemos: “Bem… hum… você sabe, na verdade é muito difícil ver quanto tempo leva, porque…”. Realmente não tínhamos um bom motivo para não medir isso.
Na Theodo, criamos e implementamos aplicativos baseados na web para nossos clientes. As empresas vêm até nós quando precisam de uma equipe técnica para construir rapidamente seu aplicativo. Para iniciar um projeto, temos que convencer nossos clientes de que entregamos valor mais rápido que os outros. Isso não é um bom motivo para medirmos o quão rápido fazemos nossa entrega?
DEFINA O QUE E QUANDO MEDIR
Primeiro de tudo, deixe-me dar um contexto sobre como trabalhamos. Dia após dia, nossos desenvolvedores constroem o que está escrito em um cartão da Trello - o que chamamos de histórias do usuário. Eles representam a menor parte de um recurso que pode ser enviado, e não pode demorar mais de um dia para ser criado. Um grupo de histórias do usuário constitui um épico, que representa um recurso completo. Por sua vez, um projeto é composto de vários épicos.
Por exemplo, um épico poderia ser: “Como vendedor, posso enviar uma fatura ao cliente para seu pedido”. E uma das histórias para conseguir isso pode ser: "Como vendedor, na lista de pedidos do cliente, quando clico no botão 'Enviar fatura', visualizo a fatura antes do envio".
O lead time é o tempo entre o momento em que você recebe um pedido de um cliente e o momento em que ele é entregue a ele. Em nosso ambiente, os clientes solicitam aplicativos sem saber exatamente quais serão seus componentes; depois, semana após semana, eles adicionam épicos. Finalmente, eles decidem quando começar a construir esses recursos, e a equipe cria histórias para esse épico.
Portanto, nosso problema inicial era entender qual era o lead time a ser seguido. Devemos nos concentrar no lead time do projeto? No lead time do épico? Ou no lead time das histórias do usuário? Não conseguimos escolher, então decidimos rastrear todos eles, definindo cada um como segue:
- O lead time de um projeto começa no primeiro contato com o cliente e termina quando o primeiro recurso é lançado publicamente.
- O lead time de um épico começa quando o épico é criado pelo responsável pelo produto e termina quando a última história do usuário do épico é lançada na produção.
- O lead time de uma história do usuário começa quando ela é criada e termina quando é liberada na produção.
Comecei a trabalhar com meus colegas Frédéric e Grégoire (ambos são desenvolvedores líderes em diferentes projetos) nos dois últimos lead times. Frédéric se concentrou no lead time das histórias do usuário de sua equipe, enquanto Gregoire partiu para entender o tempo de espera dos épicos de sua equipe. Nossos primeiros resultados mostraram que levamos entre 27 e 86 dias para entregar épicos e entre 1 e 43 dias para entregar histórias do usuário.
EXISTE UM PROBLEMA A SER RESOLVIDO?
Nesse ponto, imaginamos se tínhamos ou não um problema em nossas mãos. Sem um padrão claro, não poderíamos dizer se esses números eram ruins ou não. Então tanto Frédéric quanto Grégoire começaram a definir o lead time que eles achavam que deveríamos buscar e confirmaram com o cliente que eles eram aceitáveis.
Frédéric aprendeu que o prazo de entrega ideal para histórias do usuário é de menos de 10 dias:
- 7 dias na fase de análise: entre a criação e a primeira linha de código.
- 1 dia na fase de desenvolvimento: entre a primeira e a última linha de código na história do usuário.
- 1 dia na fase de validação: entre a última linha de código e o momento em que o responsável pelo produto valida a história do usuário.
- 1 hora na fase de implantação: após a validação até que a história do usuário seja implantada on-line.
Descobrimos que 7 histórias do usuário entre 19 totais estavam atrasadas:
- 5 levaram mais de 7 dias na fase de análise.
- 3 levaram mais de 1 dia na fase de desenvolvimento.
- 3 levaram mais de 1 dia na fase de validação.
- 18 levaram mais de 1h na fase de implantação.
Por sua vez, Grégoire aprendeu que os épicos devem ser feitos em menos de 28 dias:
- 14 dias na fase de análise: entre a criação do épico e a criação das histórias do usuário.
- 7 dias na fase pronto para ser desenvolvido: entre a criação das histórias do usuário e a primeira linha de código.
- 7 dias na fase de desenvolvimento: entre a primeira linha de código e o lançamento da última história do usuário do épico.
Com base nisso, descobrimos que 8 épicos de 10 totais estavam atrasados:
- 8 levaram mais de 14 dias na fase de análise.
- 3 levaram mais de 7 dias na fase de pronto para ser desenvolvido.
- 1 levou mais de 7 dias na fase de desenvolvimento.
O custo do estoque
Com uma compreensão clara dos primeiros passos necessários para se aproximar do prazo de entrega padrão, podemos agora abordar a fase de análise: o estoque de histórias que a equipe terá que desenvolver. Aprofundamo-nos no projeto de Frédéric para ver a “idade” das histórias. Oitenta e oito por cento delas tinham mais de 7 dias de idade.
Essa fase pode ser dividida em três etapas. Primeiro, quando criada, a história do usuário é armazenada no backlog. Em algum momento, o responsável pelo produto prioriza o backlog. Ele move o que ele quer que a equipe desenvolva em outra coluna chamada "a ser especificada". Uma vez por semana, a equipe especifica como codificar todos os tickets dessa coluna. No final, eles movem a história para a coluna “especificada” antes de desenvolvê-la. Aqui está a distribuição:
- No backlog: 65 das 65 histórias tinham mais de 7 dias.
- “A ser especificada”: 14 das 17 histórias tinham mais de 7 dias.
- “Especificada”: 6 de um total de 14 tinham mais de 7 dias.
No projeto de Gregoire, esse exercício foi ainda mais importante, pois 11 épicos dos 11 totais tinham sido criados há mais de 14 dias.
Sabemos que o estoque tem muitas consequências, mesmo que ainda não tenhamos estimado seu custo. No entanto, estávamos cientes de que a equipe repassava cada item, semana após semana, perguntando a si mesmos se deveriam fazer isso imediatamente ou mais tarde. Por sua parte, o responsável pelo produto passou muito tempo gerenciando seu backlog, tendo que encontrar a melhor maneira de priorizar histórias e épicos. Além disso, nossos clientes estavam perdendo oportunidades de negócios. Os usuários que esperam recursos para ajudar a melhorar sua produtividade ficam desapontados por não vê-los liberados, e os clientes ainda sofrem com recursos para os quais há melhorias no backlog e, assim, vêem suas vendas caírem pouco a pouco.
Para reduzir o lead time, percebemos que precisávamos reduzir o estoque de épicos e histórias. O primeiro passo foi identificar as fontes das histórias e quantas histórias elas geravam.
- 18,7% das histórias são criadas a partir do feedback dos usuários finais e problemas no aplicativo que eles enfrentam.
- 28% das histórias são criadas pela equipe quando encontram algo para melhorar.
- 53,3% é estoque em processo: o que não conseguimos concluir nas semanas anteriores, as investigações que iniciamos e não conseguimos concluir e as histórias que o responsável pelo produto não priorizou.
Isso revelou todo o desperdício que temos em nosso processo. A fase de análise é nosso estoque de histórias e épicos. Durante toda a semana, a equipe move para cima e para baixo as histórias e os épicos no backlog para priorizá-los. Eles leem cada história mais de uma vez para ter certeza de que é a hora certa de trabalhar nela ou não - uma espécie de processamento excessivo. E também produzimos em excesso, adicionando novas histórias ao backlog, identificando estratégias técnicas para elas enquanto elas estão com defeito.
SEM PUXADA E FLUXO QUEBRADO
Focamos na superprodução e nos defeitos. Anos atrás, definimos um estoque mínimo de histórias que o responsável pelo produto precisa criar para garantir que a equipe sempre tenha algo para fazer, mas não um máximo. Mas descobrimos, entre outras coisas, que o responsável por um produto continuava a criar histórias, embora o backlog já estivesse cheio. Aqui, o sistema puxado parecia estar quebrado, com o responsável pelo produto empurrando histórias sem considerar a capacidade da equipe. Ironicamente, o responsável pelo produto reclamava que ele não tinha tempo suficiente para trabalhar em coisas importantes, como receber feedback do usuário, fazer experiências com o usuário e assim por diante. Parece que encontramos uma solução para sua falta de tempo!
Há outra coisa interessante. Não distinguimos entre projetar o recurso e dividir os épicos em histórias do usuário. Isso acontece ao mesmo tempo, o que resulta em muitas informações ausentes ou incompletas. Isso também resulta em outros departamentos (designers, tradutores, marketing, equipe de infraestrutura) descobrindo no último momento que precisam fazer algo crítico para a entrega do recurso. Em tais casos, o fluxo é interrompido.
É onde estamos hoje. A janela está um pouco mais limpa, e embora eu acredite que o futuro continuará sendo desafiador, agora estamos cientes do que estamos perdendo. Mais importante, estamos agora enfrentando nossos problemas, o que significa que nosso amanhã só pode ser mais brilhante e cheio de novos aprendizados e inovações. Vou manter vocês informados sobre nosso progresso daqui a alguns meses ...