Kanban fora da TI – uma experiência
Nesse artigo iremos abordar como um método evolucionário, criado por David Anderson para otimizar a entrega de softwares, inspirado nas bases do sistema de produção da Toyota e princípios lean, criando um sistema puxado de trabalho e que nos permite enxergar os pontos problemáticos dentro de uma entrega, pode nos ajudar com projetos com escopo de excelência operacional.
Com um time formado por três consultores, André Mascarenhas, Clara Monteiro e Gilberto Strafacci dentro de um projeto de gestão de processos, que utiliza ferramentas para analisar, definir, otimizar, monitorar e controlar processos com objetivo de medir e melhorar o desempenho de processos de negócios interdependentes. Sabendo que historicamente esse tipo de projeto possui a fama de não cumprimento dos prazos iniciais e retrabalhos recorrentes, para nosso caso, o escopo do projeto de resumia em mapear processos administrativos com a ferramenta de fluxogramas funcionais e elaborar padrões operacionais das atividades chaves mapeadas.
O dia a dia dos consultores consistia em realizar entrevistas com os assistentes administrativos para a confecção do fluxograma funcional, após seria identificado as atividades críticas realizadas e elaborado um padrão operacional para estas atividades. Enxergamos assim um fluxo de trabalho, onde primeiro deveríamos fazer e validar os fluxogramas para depois elaborar os padrões. A principal entrega do projeto eram os padrões operacionais, sendo a demanda inicial de 30 padrões em 480 horas contratadas, vale ressaltar que na reunião inicial do projeto o cliente sinalizou que não esperava a entrega total e que estaria satisfeito caso conseguíssemos 80% da demanda.
Com intuito de otimizar o tempo e entregas, optamos por utilizar algumas das métricas Kanban para gerenciar nosso fluxo de trabalho, deixar claro possíveis barreias e possíveis pontos de preocupação ao longo do projeto.
Como as métricas Kanban podem ajudar:
Quem não mede não gerencia, baseado neste fato, as métricas do Kanban nos ajudam a identificar as ocorrências de muda, mura, muri, ou seja, práticas que geram desperdício e que podem ser eliminadas, por exemplo: atividades que consumam recursos sem criar valor para o cliente, falta de regularidade ou grande variação em uma operação e sobrecarga de pessoas ou equipamentos.
Utilizamos no projeto as seguintes métricas:
Touching time: tempo utilizado e/ou trabalhado em uma pendência do projeto, para o nosso caso – tempo utilizado na elaboração dos padrões.
Lead Time: tempo total entre o surgimento da demanda e a entrega dela, para no nosso caso – tempo entre a identificação de uma atividade crítica (momento em que incluíamos um cartão na coluna backlog do quadro Kanban) até sua entrega para o cliente (momento em que movíamos o cartão para a coluna de feito)
WIP: work in process, quantidade de trabalho que está dentro do fluxo, para o nosso caso – número de padrões que estão sendo trabalhados
WIP Cap: quantidade de trabalho máximo sendo realizado simultaneamente, para o nosso caso – definimos como um limite de dois padrões por consultor sendo realizados simultaneamente.
A utilização de WIP cap está ligada a lei de Little, que relaciona a taxa de saída de um processo com seu lead time e a quantidade de trabalho sendo realizado em um sistema em equilíbrio.
Taxa de saída = WIP
Lead Time
CFD: Acredito que o cumulative flow diagram é a principal ferramenta do dia a dia de um projeto que aplica o Kanban, nele é possível enxergar o WIP cap (se está sendo seguido ou não), lead time, touching time, entrega total, gargalos, trabalho bloqueado entre outros.
Desafios e restrições:
A principal dificuldade encontrada foi a inserção do cliente para uma mentalidade ágil, e mostrar a importância do gerenciamento do fluxo de trabalho, como a etapa de validação estava com ele, a diferença entre o touching time dos padrões e dos guias se tornou um problema no início, sendo essa diferença podendo alcançar 20 dias! Ou seja, os padrões ficavam esperando em uma fila para serem validados. Essa diferença começou a reduzir no final do projeto pois foi demonstrado para o cliente a importância da validação para o gerenciamento do fluxo e entrega final.
Resultados
Com o limite de 2 padrões sendo realizados simultaneamente por cada consultor, conseguimos sinalizar para o cliente possíveis barreiras, que logo foram retiradas, devido a alta produtividade que o gerenciamento do fluxo possibilitou, conseguimos entregar todos os padrões na demanda inicial com aproximadamente 2/3 do tempo de consultoria consumido, superando a expectativa do cliente em tempo e qualidade do trabalho.
Ainda com tempo contratado, o cliente decidiu que deveríamos realizar o mesmo trabalho em outra área da empresa, como a área não estava preparada para receber os consultores, para não haver um excesso de tempo parado, o limite de WIP foi dobrado, os impactos já esperados foram o aumento da média do touching time e um aumento da variação!
Impacto do estouro do WIP (testes estatísticos)
Como todos consultores envolvidos no projeto são black belts (lean six sigma), não poderíamos deixar de realizar testes estatísticos para validar o impacto da alteração do limite do WIP, com o objetivo de ter lições aprendidas para o projeto e no próximo conseguir uma produtividade ainda maior.
O objetivo era avaliar e validar o impacto da mudança do WIP cap após a demanda inicial ter sido entregue, realizamos um teste de hipóteses (apesar da pequena quantidade de dados) para validar a diferença entre médias e variação entre os dois períodos.
Apesar da diferença entre as médias ser de 1,349 dias, elas são consideradas estatisticamente iguais devido ao intervalo de confiança e o p-value obtido.
Mas se temos certeza do impacto, por que não conseguimos comprovar a diferença entre as médias estatisticamente? A resposta está na variação! Com um intervalo de confiança de 95% obtivemos um p-valor < 0,002!!! Demonstrando estatisticamente a diferença de variação para os dois grupos.
E qual o impacto da diferença da variação dos grupos?
Previsibilidade! Sempre importante em um projeto ter uma previsão da entrega e dos prazos acordados, com uma variação grande essa previsibilidade não existe, ou seja com um WIP cap de dois padrões por consultor tínhamos uma entrega previsível e constante, a partir do momento em que extrapolamos esse WIP cap passamos a variar muito na entrega, e perder nossa previsibilidade chegando a demorar até 10 dias de touching time em dois padrões, impactando na média de entrega.
Conclusão:
O aumento do limite de WIP no final do projeto levou à um aumento da variação de tempo de entrega de cada padrão para a validação, o que reduz a previsibilidade das entregas.
O Kanban se mostrou extremamente efetivo para a identificação e consequentemente a retirada de barreiras para um trabalho de mapeamento de processos, conseguindo uma produtividade elevada, e mesmo com desafios relacionados a uma não cultura de agilidade no local de desenvolvimento do projeto, se provou efetivo no gerenciamento do fluxo de projetos fora da TI!
