[ClickBus] A organização do processo de produto não tem fim, mas tem um começo - ClickBus na Mídia
[ClickBus] A organização do processo de produto não tem fim, mas tem um começo
Afogadas nos problemas diários, muitas empresas não olham para os seus processos internos. No mundo de produtos digitais há muito enfoque no que as empresas estão fazendo, mas muito pouco no como. Na ClickBus fazemos diferente.
Recentemente embarcamos em uma jornada para melhorar a forma com que desenvolvemos os nossos produtos, e por consequência, atender melhor o viajante. Para começar essa empreitada, reunimos algumas das principais oportunidades para servirem de norte ao nosso projeto. Eram elas:
Clareza sobre onde estamos alocando os recursos. A lei de Parkinson diz que o trabalho se expande de acordo com o tempo disponível para executá-lo. É provável que na sua empresa, o mesmo aconteça se você não utilizar elementos de gestão à vista para visualizar o que está sendo feito. Quando falamos de desenvolvimento de produtos digitais, isso tende a se tornar ainda mais relevante, dado que o trabalho é intangível e invisível.
Na ClickBus, apesar de utilizarmos o Jira para visualizar as demandas de desenvolvimento, faltava clareza em como a nossa energia estava sendo distribuída nos diferentes produtos e/ou novas funcionalidades versus correção de defeitos.
Otimização de gargalos percebidos. Em uma investigação inicial, percebemos que havia pouca clareza em onde estava o maior gargalo no processo atual. Algumas pessoas acreditavam que estava na etapa de testes e qualidade. Outros achavam que o que faltava eram mais desenvolvedores. E uma outra minoria achava que design também poderia ser um problema. Não havia consenso, porque também não haviam dados que nos permitissem uma melhor análise dos gargalos. E claro, sem ter certeza onde o gargalo estava, era mais difícil ainda propor uma otimização.
Uma vez que identificamos as oportunidades, estabelecemos um objetivo para o nosso projeto. Melhor do que tapar os buracos existentes, seria tornar os buracos atuais e os futuros visíveis. Por isso, concordamos que o caminho ideal seria estabelecer um processo de melhoria contínua. Escolhemos o método Kanban proposto por David J. Anderson e contamos com o apoio da Target Teal.
Iniciamos a implementação do método Kanban realizando uma mapeamento das etapas atuais do processo, assim como os diferentes "serviços" existentes. No final, o nosso quadro Kanban ficou mais ou menos assim:
As colunas representam as diferentes etapas em que uma demanda de desenvolvimento (seja ela uma nova funcionalidade, defeito ou melhoria na experiência do usuário) percorre até ser entregue para o cliente final. Estabelecemos limites para a quantidade de itens em cada etapa do fluxo, como mostram os números no topo do quadro. Isso impede com que o trabalho no gargalo se expanda infinitamente e nos permite uma melhor gestão do que estamos fazendo.
Dividimos o nosso quadro em linhas, cada uma representando um "serviço" ou tipo de atendimento. Alocamos espaço para itens com alta prioridade, permitindo atendimento diferenciado para demandas críticas (urgentes) e com prazos externos (data fixa). Também garantimos um equilíbrio entre os diferentes produtos da ClickBus, numerados de 1 a 3 no quadro.
Perceba que a distribuição dos números nos serviços não é aleatória. Atualmente, estamos colocando cerca de 30% da nossa energia no produto 1, 30% no 2, 20% no 3 e mais 20% em itens intangíveis (abaixo falaremos mais sobre eles). Esses números representam uma alocação estratégica para o nosso negócio. O quadro no Kanban nos dá a flexibilidade de mudar isso futuramente, caso seja mais adequado colocar mais energia no produto 3, por exemplo.
Nos demos também a liberdade de alocar cerca de 20% da nossa capacidade no que chamamos de "intangíveis" no Kanban. Esses itens correspondem a refatorações no código-fonte, melhorias nos processos de desenvolvimento, automações de testes legados, entre outros. Tais itens são comumente referidos como "débito técnico" na comunidade de software, e podem ser responsáveis pela morte do seu produto. Na ClickBus, garantimos a sustentabilidade no longo prazo sempre reservando um espaço para isso.
Depois de colocar para rodar o quadro Kanban, iniciamos a coleta das principais métricas do sistema, como Lead Time, Throughput e o Diagrama Cumulativo de Fluxo. Logo começamos a realizar reuniões regulares com o time sobre o processo, para discutir as métricas e propor evoluções.
Apesar do processo ser vivo e estar longe de ter um fim, conseguimos perceber algumas mudanças de imediato.
Maior colaboração e trocas diárias. Certamente o principal benefício de curto prazo foi o aumento da troca de experiências entre os desenvolvedores na frente do quadro físico. O senso de urgência obtido pelo aumento da transparência trouxe mais conversas e debates em frente ao cartão de cada demanda.
Mensuração dos tempos de aprendizado. Logo depois de algumas semanas, conseguimos capturar o nosso Lead Time médio, que corresponde ao tempo que decorre entre o início e o fim de cada demanda. Cada nova feature lançada no produto, começa como uma hipótese e termina com algum aprendizado que nos gera a partir do que observamos no uso dela. Ver o Lead Time nos permitiu dar atenção a quão rápido estamos aprendendo e atendendo os viajantes.
Envolvimento dos diversos stakeholders no processo. Com a transferência das atividades de gestão de projetos e cobrança para o sistema Kanban, a equipe de Produtos ganhou mais tempo para se dedicar à organização do Backlog dos produtos. Com os backlogs mais bem preparados, começamos a realizar encontros com todos os stakeholders interessados para a escolha dos próximos itens de trabalho de cada produto. Esse envolvimento aumentou a percepção do custo de desenvolvimento entre os stakeholders e a necessidade de fazer concessões, transmitiu transparência e deu dinamismo ao desenvolvimento do roadmap de produto, antes estático.
Clareza sobre onde otimizar. Antes de medir o fluxo, poderíamos ter caído na tentação de aumentar o time de testadores, porque esse era um gargalo aparente. No entanto, depois de coletar os dados nós identificamos que esse não era o maior ponto de alavancagem. Se tivéssemos feito essa otimização precipitada, teríamos um time de testadores ociosos.
Flexibilidade de alocação por produto. Estamos experimentando uma política que permite aos desenvolvedores escolherem em qual produto se dedicar. Não existe um time de produto fixo, mas um conjunto de pessoas que atuam nos diferentes "serviços", de acordo com a capacidade disponível no sistema. Se precisarmos mudar o foco da ClickBus de um produto para o outro, basta alterar os parâmetros e a mágica está feita. Como um bônus, os desenvolvedores também conseguem ter a autonomia de escolher onde trabalhar.
A melhoria contínua na organização não tem fim, logo não poderia ser diferente no nosso sistema Kanban. Estamos sempre realizando testes, mudando um parâmetro ou outro no quadro, alterando as colunas ou mexendo nos processos internos, ou seja, buscando aquele pequeno ajuste que pouco a pouco vai nos levando a um ritmo de trabalho cada vez mais sustentável e inovador.
Começamos a dar tanta atenção ao como criamos novas funcionalidades quanto a quais coisas escolhemos para focar a nossa energia. Ao limitar a quantidade de coisas em andamento, também conseguimos liberar mais espaço – no dia a dia e nas nossas cabeças – para inovar mais nos produtos da ClickBus e melhor atender o viajante.