Case: Como aceleramos o tempo de entrega das demandas no App Hurb

Reduzimos de 20 para 5 dias o tempo de entrega melhorando a qualidade e robustez do desenvolvimento.

Este é o Control Chart, o gráfico que usamos para acompanhar a velocidade de entrega das demandas no App Hurb (disponível na ferramenta Jira da Atlassian). Puxamos o período de 6 meses para visualizar o antes e o depois da aceleração que tivemos.

Cada bolinha no gráfico representa uma demanda. Quando elas estão preenchidas e maiores significam um conjunto de demandas que foram entregues ao mesmo tempo. A linha azul mostra a média móvel, em uma janela de 7 dias, do tempo de entrega e é nela que notamos uma redução significativa a partir do final de julho, saindo de mais de 20 dias para 5 dias em média no final de setembro. Também é possível observar que o desvio padrão, representado pela cor azul claro também reduz, mostrando que estamos sendo mais consistentes nesse tempo.

Antes de avançar para o “como fizemos”, é bom esclarecer o “porquê fizemos”. Por que acelerar ou entregar melhor e mais rápido é importante? Porque é uma grande vantagem competitiva garantir ser o primeiro a entregar uma solução no mercado. Nos permite ter o feedback e dados sobre aquela entrega mais rápido para que possamos aprimorar ou pivotar, se necessário.

Entretanto, não é só uma questão de velocidade, mas também de agilidade. “Agilidade dos Métodos ágeis está mais para adaptação a mudanças do que para velocidade de entregas” diz Sony Maia em seu artigo Velocidade ≠ Agilidade. Como descrito nesse documento, o time melhorou seus testes e ficou mais resiliente à mudanças de roadmap sem que isso prejudicasse a qualidade do desenvolvimento.

Contexto do time

O faturamento do app é muito representativo para a empresa que, cada vez mais, investe no produto e desafia o time. Time esse que é responsável por toda a jornada do usuário no aplicativo, e também pela sustentação técnica do produto. Isso significa que nossas demandas são das mais variadas possíveis e a expectativa é alta.

O time de app do Hurb contava com 13 pessoas nesse período: 1 Product manager, 1 trainee de produto, 2 designers, 1 desenvolvedor backend, 4 desenvolvedores iOS e 4 desenvolvedores Android. Um time grande para dar vazão a muitos stakeholders, já que tudo o que era pensado para o site, o app poderia aproveitar. Haviam 8 times para partes do site, ou seja, nasciam demandas desses times, mas também do atendimento, da área de negócio e outros. Precisávamos e ainda precisamos priorizar bem o que vamos desenvolver para tentar trazer o máximo de resultado com o produto.

Usamos kanban como metodologia ágil desde 2021, pois nos dá maior flexibilidade durante a sprint. Priorizamos e despriorizamos tarefas todos os dias.

O app tem uma particularidade para lançar novas funcionalidades. Ao contrário de sites que podem colocar no ar melhorias a qualquer momento, o app precisa sempre gerar uma versão com o que quer lançar e enviar para avaliação pelas lojas App Store e Google Play, onde eles irão aprovar e aí sim iniciar um lançamento gradual da versão (+-5 dias). Depois disso, os usuários ainda precisam atualizar seus aplicativos para ter acesso a essas novidades. Ou seja, um processo bem mais burocrático e lento que dificulta o mantra da agilidade que é testar rápido.

Optamos por lançar versões a cada 3 semanas, um tempo confortável para desenvolver um número considerável de novidades e também o suficiente para uma boa adesão de usuários à nova versão. Caso haja demandas que foram previstas para serem entregues, mas não foram finalizadas a tempo, adiamos ela para a próxima versão. Apenas em casos excepcionais atrasamos um lançamento.

Mas agora você deve estar se perguntando:

“Se vocês lançam versões a cada 3 semanas, por que o gráfico lá do início diz que entregam em uma média de 5 dias? Não deveria sempre mostrar 21 dias (3 semanas)?”

O gráfico contabiliza o tempo de desenvolvimento desde o refinamento técnico, quando os envolvidos estruturam quem e como desenvolver, até a versão final antes de ser enviada para a loja, ou seja antes de estar no app do usuário. As demandas só passam para essa versão final após o funcionamento, o layout e o código serem bem testados. Existem as que levam os 5 dias em média, outras apenas algumas horas e as que podem ultrapassar 21 dias dependendo da complexidade. Nós precisamos enxergar isso, saber exatamente o tempo em que as demandas levam para ser desenvolvidas.

Estratégia para aceleração

A mudança pela qual passamos não é resultado de uma ação apenas, foram várias melhorias e ajustes durante o período. Entretanto, o gatilho que despertou essa possibilidade e nos apontou um caminho foi o conhecimento que adquirimos com a certificação de Kanban System Design (KMP I) pela Kanban University.

Listamos abaixo com detalhes o que nos levou a acelerar.

1. Quebrar em entregas menores

Todo produteiro já sabe, mas é importante reforçar: quebre as funcionalidades e ideias em entregas pequenas e incrementais para que se tornem mais fáceis e rápidas de se fazer. No app Hurb, os designers projetam seus conceitos de forma mais completa tentando contemplar até possibilidades futuras, mas quando chega nas mãos das pessoas de produto, esse projeto é quebrado em várias histórias e tarefas que serão implementadas e testadas separadamente.

A grande vantagem é que “dividir as tarefas em partes menores nos ajuda a enxergar as tarefas maiores como mais viáveis e reduz nossa propensão a procrastinar ou adiar tarefas por simplesmente não saber por onde começar” diz Melissa Gratias, Ph.D., coach e palestrante sobre organização e produtividade no trabalho. Mas além disso, também facilita na validação daquele pedacinho, pois podemos medir isoladamente o impacto dele, sem influência de um conjunto de melhorias.

No gráfico fica nítido quando começamos a melhorar nisso. Quanto mais tarefas (bolinhas verdes), o nosso tempo de entrega reduz. Isso porque agora elas são menores e mais fáceis de desenvolver.

Acreditamos que a habilidade de particionar projetos se conquista com muita prática. Por mais que a gente ache que “esse é o mínimo que se pode fazer para entregar esse valor” sempre podemos aperfeiçoar. É um trabalho constante e depende muito de cada projeto.

2. Beneficiar-se da flexibilidade e agilidade do kanban

Mesmo trabalhando com sprints optamos pela metodologia Kanban, pois nos deu mais flexibilidade para atualizar as tarefas, substituindo a que não tem tanta urgência por outra que se torna prioritária. Enquanto o scrum você se compromete com um conjunto de entregas no início da sprint e nada mais muda durante esse período, no nosso kanban tudo pode ser alterado, na condição de o desenvolvimento não ter sido iniciado ainda.

Kanban é ótimo para equipes que recebem muitas solicitações que variam em prioridade e tamanho. Enquanto os processos Scrum exigem alto controle sobre o que está no escopo, Kanban permite que você siga o fluxo. MAX REHKOPF, em Kanban vs. Scrum: que tipo de ágil é você?

O time se compromete com o que está no quadro, seguindo a ordem das tarefas priorizadas semanalmente, sem a necessidade de uma reunião de planejamento (planning). O dinamismo desse processo resulta em mais agilidade e resiliência da equipe.

3. Garantir um sistema puxado e não empurrado

Uma questão muito importante da estratégia foi perceber que estávamos incentivando os desenvolvedores a iniciar cada vez mais tarefas e não finalizá-las.

Quando uma tarefa passava para a fase de validação (coluna 4), a nossa lista de prioridade era atualizada retirando essa tarefa e adicionando uma nova no lugar. Resultado: as demandas iniciadas eram empurradas até a fase de validação. Ao chegarem lá, eram temporariamente esquecidas e só voltavam ao foco nas vésperas de um lançamento, quando já havíamos acumulado um grande montante de tarefas que precisavam ser testadas e possivelmente ajustadas. Criávamos um grande gargalo no nosso fluxo que atrasava o lançamento.

Isso é o chamado fluxo empurrado, onde nós praticamente atropelávamos as tarefas não validadas com novas.

Hoje somos adeptos da filosofia “pare de começar e comece a terminar” do próprio Kanban. O foco sempre deve ser no que está mais próximo de ser concluído. Agora, nossa lista semanal confere maior prioridade para as demandas em fase de validação, então o time é guiado a puxar as tarefas para o final do fluxo (coluna “Aprovada”). Novos itens só são iniciados à medida que outros estão totalmente prontos para compor a versão final.

4. Priorização rápida e eficiente

Com o foco no final do fluxo, a prioridade sempre será atuar naquilo que está mais avançado no quadro Kanban. Entretanto, para decidir quais são os próximos itens que entrarão na esteira de desenvolvimento, levamos em conta primeiro as demandas que já possuem uma data de entrega mais próxima e inflexível.

Depois, seguimos a ordem definida por um modelo de priorização semi-automático, ensinado no artigo Um modelo de priorização eficiente — sem “achismos”. Criamos uma calculadora que pontua valor e esforço para cada demanda, levando em consideração critérios definidos pelo time. A prioridade é dada a partir da razão entre esse valor e esforço. Quanto maior for o número do resultado, maior a prioridade do item.

Nesse processo as pessoas de produto ficam responsáveis por montar a lista de prioridades, não havendo necessidade de reuniões de planejamento para definir as próximas entregas, economizando o tempo de todos do time que mantém o foco nas soluções.

5. Limitar o wip (work in progress)

Limitar o trabalho em progresso (wip) foi a parte mais desafiadora do conjunto de mudanças que aplicamos. É contra intuitivo pensar que impedir de começar novas tarefas resultará na agilidade das entregas.

Acontece que não limitar dá abertura para as pessoas de produto jogarem muitas demandas para dentro do quadro, inflando ele. Isso gera ansiedade no time que acha que sempre está atrasado e estimula a questão de empurrar tarefas.

Mesmo não tão confiantes, resolvemos definir um número limite para cada uma das colunas do nosso quadro de gestão de tarefas, com cada etapa do fluxo tendo seu próprio limite. A partir daí os benefícios foram rapidamente percebidos.

Primeiro, nossos gargalos foram evidenciados. No jira, quando colocamos um limite, a coluna fica em vermelho assim que ultrapassamos o número máximo de tarefas. E a coluna que mais ficava vermelha era a de validação — hoje isso é óbvio para nós, mas antes não era. Agora, assim que enxergamos uma coluna vermelha, direcionamos o time para focar em resolver aquela fase do processo. No nosso caso, todos paravam o que estavam fazendo para testar, colaborando para manutenção de um sistema puxado.

Por fim, se um desenvolvedor terminou suas tarefas e o quadro Kanban estiver lotado, ele deve ajudar outra pessoa do time, atribuindo velocidade ao progresso, ou até mesmo ficar livre para estudar conteúdos novos.

6. Trabalho colaborativo de verdade

No time todos tem um par: a dupla de produto, os designers e também a galera que desenvolve. Nos organizamos de forma que toda pessoa júnior possa ser guiada por alguém mais experiente. Os pares atuam juntos na demanda que é finalizada mais rápido e ainda serve de ensinamento para os novatos até que tenham mais confiança para trabalhar sozinhos no projeto. Essa formação diminuiu bastante o risco da pessoa ficar empacada em um problema, também divide a responsabilidade e alivia a carga de trabalho.

A grande maioria das demandas tem o requisito de ser entregue tanto para a plataforma iOS quanto para a Android. Nesse caso é necessário um desenvolvedor de cada para trabalhar nela e estes também acabam conversando bastante. É fundamental que eles estejam alinhados desde o refinamento técnico até a entrega final da tarefa, pois assim conseguimos garantir que os usuários de ambas plataformas terão a mesma experiência com uma determinada funcionalidade e que ela foi desenvolvida da forma mais otimizada possível.

7. Testar cada demanda separadamente

Esse é o fator que garantiu maior qualidade nas entregas. No processo anterior, deixávamos para testar uma versão completa, com todas as novidades, alguns dias antes de enviar para as lojas. Naturalmente, achávamos erros impeditivos e isso gerava uma lista extensa de ajustes que precisavam ser corrigidos em pouco tempo.

Além de criar uma atmosfera estressante pela pressão de um prazo apertado para o ciclo desenvolver-testar-aprovar, ter um alto volume de demandas a serem testadas de uma vez faz com que os detalhes se tornem mais imperceptíveis para quem testa. Como consequência, tínhamos um grande retrabalho para todas as partes. E mesmo com todo esforço do time, muitos erros passavam e acabavam nas mãos dos usuários finais.

No novo formato as demandas são testadas separadamente, além disso o teste deve ser feito por pelo menos dois desenvolvedores que não executaram a tarefa para validar o código e ainda outras duas pessoas do time para avaliar a experiência. Caso a funcionalidade envolva mudança de UX e/ou UI, um designer também deve testar.

Testar as demandas separadamente permite um momento de foco completo e exclusivo para cada item, onde aqueles que testam conseguem validar o que foi feito com maior acurácia e os desenvolvedores tem um tempo saudável para atuar nas correções, que não são feitas todas de uma vez.

Nos dias que antecedem um lançamento, uma versão completa ainda é gerada, mas tendo todos os itens previamente aprovados, é necessário garantir apenas que os fluxos principais do produto estejam funcionando conforme o esperado.

Consequências e resultados

Além da vantagem principal de conseguir colocar no mercado uma solução com mais rapidez, esse conjunto de melhorias trouxe uma série de outros benefícios que foram percebidos pelo time e stakeholders:

• Antes: Média de 20 dias para entrega / Depois: Média de 5 dias para entrega;
• Antes: Tarefas pesadas e grandes / Depois: Tarefas menores e mais rápidas de se desenvolver;
• Antes: Começamos mais que terminamos / Depois: Terminamos mais que começamos
• Antes: Lista enorme de ajustes a poucos dias antes do lançamento / Depois: Poucos ajustes antes do lançamento;
• Antes: Não tínhamos previsibilidade de entrega / Depois: Conseguimos prever duas versões a frente;
• Antes: Ansiedade perto do lançamento de versão / Depois: Lançamentos mais organizados, mas ainda com ansiedade (nada é perfeito).

E é com muito orgulho que hoje nosso Control Chart está assim:

Essa conquista é fruto do trabalho de muitas pessoas. Todos abriram espaço para essas mudanças e permitiram que isso acontecesse. Nos ajudou muito e esperamos que ajude outros times também.

Essa documentação foi inteiramente escrita em colaboração com a incrível Maria Luíza Servilhano, Product Manager no App Hurb.