Gestão Lean vs Tradicional: 3 principais diferenças para você começar a usar Kanban

Publicado por Diego Pereira no dia agile, gestão

Eu amo Kanban!

Não amo Kanban por gestão visual de pacotes.
Não amo Kanban por controle de WIP (work in progress).
Não amo Kanban por ser parte do Sistema Toyota que tanto admiro.
Não amo Kanban por ser uma ferramenta de autogestão.
Não amo Kanban por facilitar a melhoria contínua de times e processos.

Amo Kanban pois ele me permitiu não ter gerentes de projeto.

Eu não gosto de gerentes de projeto! Eu já fui um, mas prefiro não falar sobre. Eles usam gravata; eu gosto de chinelo. Eles possuem Gantts; eu nunca entendi milestones. Eles falam de gestão de risco; eu sempre preferi sucesso do cliente. Eles possuem escopo e contra-escopo; eu sempre preferi times que entendem o problema.

Gerentes de projeto são complicados. Gestão Lean parece natural para uma criança de 10 anos. PMBoK precisa de certificado! Gestão Lean precisa de valores. Mas não quero escrever sobre PMBoK vs Lean. Óbvio que PMBoK funciona para muitos casos (inclusive de software). Jamais construiria uma represa com um Kanban.

Não temos gerentes de projeto no RD Station, temos Kanban!

Mas temos projetos no RD Station. Ele cresce principalmente orientado a grandes projetos. Mas aqui os chamamos de épicos, pra não lembrar gerente de projeto. Eu realmente não gosto de gerentes de projeto. Não gosto deles pois o foco de um gerente de projeto é o projeto. O foco do Kanban é o processo. E é nele que eu tento focar meus esforços para não precisar de gerente de projeto.

Projeto vs Processo

Existem diversas diferenças entre os modelos de Gestão Tradicional (PMBOK e outras escolas similares) e Gestão Lean. Em minha humilde opinião, o principal é o foco: o primeiro, no projeto; o segundo, no fluxo (ou processo). O grande diferencial da Gestão Lean, traduzida em ferramentas como o Kanban, é focar em construir um fluxo onde diversos pacotes (projetos, épicos) possam passar por ele e obter a “mesma qualidade”. O foco da melhoria está sempre no fluxo, ou seja, em aplicar todos os aprendizados no fluxo e não apenas no projeto que está passando por ele. Desta maneira o seu esforço na melhoria contínua obterá resultados em todo e qualquer pacote (projeto) que passar pelo seu processo.

Isso pode causar alguma estranheza no começo quando se fala de Gestão Lean. A tradução de Lean, do inglês para o português, é “enxuto”. Muitos confudem “enxuto” com falta de processo ou regras, quando na verdade ser enxuto significa ter processos e regras (com a devida melhoria contínua) para garantir ganhos em eficiência e qualidade nos pacotes (projetos) que passam pelo fluxo. Traduzindo para o mundo de produto, significa eliminar papéis e pessoas necessárias na Gestão Tradicional através de um fluxo claro de como seu produto deve ser feito. É o Kanban matando o gerente de projeto.

Na prática, a gestão de um produto com Kanban pode ser explicada com uma analogia ao chão de fábrica. Cada fase do Kanban pode ser interpretada como uma fase de um processo de fabricação. Nesta analogia, três fatores se destacam para garantir a morte do gerente de projeto.

1. Definition of Done

O definition of done (ou DoD) é o objetivo de cada fase. Ele representa o que o cliente interno (a próxima fase) deseja que a fase anterior lhe entregue. É um artifício para desenhar o papel de cada fase no seu fluxo e principalmente garantir a qualidade dos pacotes (épicos, projetos) que passam por ele.

Ele não significa engessar o trabalho das pessoas. É a essência para o sucesso de um projeto. O definition of done é um guia do que a equipe deve se atentar no avance do projeto pelo Kanban. Ele define o objetivo que o trabalho deve alcançar ao final de cada fase do Kanban sem tirar sua liberdade de como fazê-lo, muitas vezes típicos de cada épico.

Por exemplo, chamamos a primeira fase (pós-priorização) do nosso Kanban de Produto de Estudo e Benchmarking. Seu DoD é basicamente validação e quebra do problema, além de um benchmarking de como cada problema menor pode ser resolvido.

Entender e validar o problema é um valor muito forte para a construção de grandes produtos. Pular esta etapa é uma das principais razões para a falha de alguns produtos. Fazer benchmarking está no nosso DNA enxuto. Entender como outros resolveram o mesmo problema nos dá ganho e eficiência.

Continuamente, com nosso aprendizado, vamos melhorando este DoD. Vemos que para muitos projetos existe grande valor em fazer primeiro uma validação quantitativa e conceitual para, posteriormente, qualificar qualitativamente. Também aprendemos que compartilhar este conhecimento com toda a empresa tem grande valor no futuro; quando as soluções tiverem que perpetuar em todos os times. Logo, no DoD, explicitamos a necessidade de realizar um seminário interno sobre o assunto.

Todos os aprendizados de cada novo pacote são aplicados para os seguintes. É outro fator muito importante para uma Gestão Lean de projetos.

2. Melhoria contínua no fluxo (processo) e não no pacote (projeto)

Fácil de entender no papel, difícil de aplicar na prática! Atacar o processo e não o pacote é contraintuitivo, porém essencial para o produto.

Digamos que no lançamento de uma nova funcionalidade você descobre que um alto número de tickets com dúvidas são gerados via suporte. Você provavelmente arruinou o engajamento de uma série de clientes por uma falha educacional. O suporte já está atuando para ajudar estes clientes e seu time de desenvolvimento já está subindo uma atualização para corrigir o problema (um “Recall”). Apesar deste custo extra, que você tem que aplicar, o grande valor ao olhar de Gestão Lean está em aprender em qual parte do seu processo esta falha foi originada e melhorá-la para que não volte a acontecer em outros projetos (funcionalidades, melhorias, etc). Aonde você deveria atuar neste problema? Na sua fase Alpha? Nos testes de usabilidade? No desenho da solução?

Entenda e aplique uma melhoria para que outros pacotes não falhem da mesma maneira. Foco constante no seu fluxo é o grande segredo para o sucesso de uma Gestão Lean.

3. O Fluxo (processo)

O Fluxo é a forma que você faz o seu produto ou projetos. Seu desenho tem grande responsabilidade sobre como você constrói seu produto. Ele deve refletir os valores que seu time/empresa pregam.

Nosso culture code, aqui na Resultados Digitais, tem influência, por exemplo, nos princípios do Lean Startup. Não a toa uma das fases de nosso Kanban se chama MVP.

Não existe uma regra sobre como deve ser um fluxo. Obviamente, boas práticas e experiências podem ser aplicadas de acordo com o seu produto ou empresa. E ele irá mudar, junto com o crescimento de seu negócio e maturidade da sua equipe. Nosso fluxo no começo da Resultados Digitais, para preparar o MVP, não reflete o de hoje, com uma equipe de mais de 200 pessoas e outros desafios.

Desenhe e melhore seu processo refletindo seus aprendizados. Mas principalmente os valores da sua empresa. Se data-driven é importante pra gente, obviamente a fase de Estudo e Benchmarking tem forte influência em validações quantitativas, tão importantes para entender alavancas em produtos.

Entenda seu negócio, as pessoas e valores de sua empresa. Use seu fluxo de modo a potencializar e reforçar os valores que você deseja ver em seu time e produto. Ele é uma ferramenta muito poderosa para espalhar cultura.

Kanban não é só isso

Kanban possui diversas outras características e boas práticas. Quis refletir apenas nas que se destacam em comparação com o modelo tradicional de gestão de projetos. Sua origem dentro do Sistema Toyota, fabricando carros, teve papel fundamental no controle de estoque. Traduzindo para software, é o controle do WIP (work in progress) para garantir entrega rápida de valor.

Sua gestão visual tem grande influência nas práticas de times ágeis que pregam a autogestão. Utilizar um Kanban e os princípios de Gestão Lean se torna muito valoroso para desenvolvimento de produtos e equipes com entrega contínua. Comece hoje com um (To Do, Doing, Done) e aprenda continuamente. E claro, me conte mais como você está aplicando Lean na sua empresa nos comentários abaixo.

Diego Pereira

Diego Pereira

Product Manager

Comentários