Kanban: o que uma melhoria de processo tem a ver com Growth Hacking

Publicado por Luciano Marcelino no dia agile, gestão

cactus comparação

Recentemente passei a entender o método Kanban mais como uma ferramenta de melhoria de processo do que como uma ferramenta de gestão de processo em si. Na verdade, nunca fui nenhum especialista em metodologias ágeis de desenvolvimento. Quando comecei a trabalhar como desenvolvedor eu caí de paraquedas no scrum e nunca dei muita atenção ao que diziam os princípios. Sempre tentei questionar o processo para que nós, como time, não repetíssemos erros passados. Eis que, hoje, tendo estudado um pouco mais da metodologia ágil, consigo entender porque me dei melhor quando comecei a trabalhar com kanban (ou algo parecido com kanban, mas sem nome nenhum).

Formalmente, Kanban é um método para gestão evolucionária de processos. Informalmente, digo que Kanban é um método para você errar, aprender e melhorar. Resumindo bastante, David J Anderson defende que se você vai começar com Kanban, deve usar ele sem mudar seu processo de trabalho. Adapte o Kanban ao seu processo, e não o contrário. A partir daí, você vai aplicando melhorias nesse processo com base nos dados que o método lhe traz.

Ok, agora chegamos na parte que eu queria: “você vai aplicando melhorias nesse processo”. Ouvi do Rodrigo Yoshima em um treinamento recente a frase:

“Trate toda e qualquer melhoria de processo como experimento”

Adorei. Creio que na hora de aplicar uma melhoria no processo do meu time, eu devo pensar nela como um experimento. Vou relacionar uma melhoria com um experimento baseado em algumas técnicas que uso quando trabalho com Growth Hacking. Seguem algumas técnicas de experimentação muito úteis na hora de melhorar seu processo de desenvolvimento:

  • Defina uma hipótese

  • Fique atento ao tamanho das melhorias

  • Não tire conclusões prematuras

  • Extraia conhecimento da mudança no processo

Defina uma hipótese

É importante que sua hipótese tenha 3 características:

  • Uma narrativa

  • Dados para embasá-la

  • Uma “aposta”

Para esclarecer, vamos supor que você identificou que existe um gargalo em uma etapa de homologação das tarefas, e que você conclui que a causa do gargalo é que só uma pessoa pode fazer esse trabalho enquanto outras 4 pessoas estão gerando demandas para essa etapa. Não é inteligente falar para o seu time: “Fulano, você vai ser treinado para homologar tarefas para diminuirmos nosso Lead Time”. Concorda?

Sua narrativa está ruim, vamos melhorá-la. Você pode falar para o time: “Observem que o tempo que as tarefas ficam paradas em homologação é muito grande. Se treinarmos alguém para que também possa fazer homologação das tarefas, poderemos diminuir esse tempo e, assim, entregar valor mais rápido para nossos clientes”. Melhorou, né?

Agora, para dar credibilidade à sua narrativa, você precisa de dados. Você pode apresentar seu Cumulative Flow Diagram e mostrar que o tempo de homologação está até maior que o tempo de desenvolvimento de uma demanda. Use o número de dias em que a tarefa fica parada esperando para complementar sua narrativa. A questão aqui não é só de mostrar para o grupo que a sua ideia faz sentido, mas também de você ter segurança de que sua hipótese vai atacar um problema real, e não seu achismo.

Sustentada a problemática que você apresentou, é hora de investir na solução. Defina em quantos dias ou em que proporção você acredita que o tempo de homologação vai diminuir depois que treinar alguém para executar essa tarefa também. Essa estimativa pode ser baseada em dados históricos, se possível. Senão, você pode fazer uma estimativa grosseira mesmo e depois comparar com o resultado. Isso é muito comum em Growth Hacking.

Fique atento ao tamanho das melhorias

Meu amigo e colega Luigi colocou muito bem em seu post sobre experimentação outro ponto que se aplica muito bem a melhorias de processos:

“Entendemos growth como um processo iterativo de melhoria, baseado em ciclos rápidos de experimentação”

Se você quer melhorar seu processo de desenvolvimento, é bom que seja em ciclos rápidos de melhorias. Dessa forma, você consegue testar mais rapidamente suas ideias. Dessa forma, se a mudança melhorar o processo, você teve os resultados rápidos. Se a mudança piorar o processo, você pode agir rápido para reverter a situação. Bem melhor do que demorar para saber se deu certo e, caso dê errado, demorar para reagir (ou ter desperdiçado mais tempo e dinheiro).

Utilizar ciclos rápidos não significa acelerar as coisas ou tirar conclusões prematuras sobre as mudanças efetuadas. Significa agir com pequenas melhorias, uma de cada vez. Se você utiliza pequenas melhorias separadas, você tem mais segurança de que aquela mudança que está fazendo é a responsável pela melhoria observada.

Se fizer muitas mudanças ao mesmo tempo, além de demorar para o time se adaptar, você não vai saber qual das mudanças foi responsável pela melhora ou degradação do processo.

Não tire conclusões prematuras

É importante tomar cuidado ao avaliar as mudanças efetuadas, pois você pode achar que o processo piorou, quando na verdade seu time ainda está se adaptando ao novo modelo de trabalho.

Diferente de um experimento que aplico em um produto, uma melhoria no processo não me diz se ela é estatisticamente relevante ou não. Quando eu coloco um experimento no nosso produto, eu consigo saber quando ele deu resultado pela quantidade de usuários que passaram por ele. Quando eu aplico uma mudança em um processo, dificilmente terei esse momento claro, até pela pequena amostra de tarefas, pessoas ou qualquer outra métrica.

É fato que existe uma Curva em J na performance do time ao aplicar mudanças no seu processo.

curva em j kanban

Isso acontece porque o time leva um tempo para se adaptar às alterações feitas. Portanto, não desista se as coisas piorarem num primeiro momento. Tenha paciência e analise com calma para encontrar a melhora que espera.

Vale ressaltar que se as mudanças forem desenhadas em pequenos “lotes”, esse processo se torna muito menos penoso, pois você terá várias pequenas curvas em J em vez de uma grande - e é numa curva em J grande que você tende a perder as esperanças de que o processo vai melhorar).

kaizen versus kaikaku

Extraia conhecimento da mudança no processo

Quando trabalho com Growth, meu objetivo com um experimento é aprender mais sobre o usuário, o produto ou o contexto que estou aplicando um experimento. Quando se trata de uma mudança no processo, o objetivo principal é melhorar alguma etapa do processo, mas isso não reduz a importância de aprender com o ocorrido.

É importante compilar os aprendizados. Converse com o time para bater o martelo se houve uma melhoria, como isso impactou o trabalho de cada um e porque deu certo ou errado. Esses aprendizados devem ser usados antes de definir as próximas hipóteses de melhorias para o processo.

Compilando

Em suma, creio que um experimento de Growth Hacking é muito semelhante a um experimento de melhoria de processo por todos os pontos que listei. Para evitar que fique muito abstrato tudo isso, vale listar algumas melhorias comuns num processo de kanban para você poder visualizar melhor do que eu estava falando, caso não esteja tão habituado com essa forma de trabalho.

Essas melhorias podem ser: limitar Work In Progress, utilizar classes de serviço, aplicar alguma técnica na hora de construir o que você constrói (no meu caso, de desenvolvimento de produto, poderia ser utilizar testes automatizados, revisão de código entre desenvolvedores, escrever cenários das funcionalidades antes de implementá-las, entre outras melhorias).

Você vê mais alguma semelhança entre os dois tipos de experimentação?

Leitura relacionadas:

Luciano Marcelino

Luciano Marcelino

Tech Leader

Comentários