O sonho, o fluxo e o pássaro

Em alguns Agile Tour, apresentei em quase todas as cidades o meu workshop, buscando o estado de fluxo. O que se segue aqui é uma descrição do mesmo, para que você também o possa aplicar em sua equipe, talvez levando um pouco mais de entendimento sobre Lean-Kanban ou ao menos, fazendo-os pensar sobre o assunto.

No começo é necessário lembrar de uma lenda japonesa que diz que se você tiver um sonho, algo que você deseje muito, basta produzir 1000 (mil) tsurus (pássaros ou garças de origami) e pendurá-los em uma cerejeira que esse desejo é atendido. Bom, eu desejo uma Harley-Davidson, qualquer modelo (preferencia pela FatBoy), portanto peço aos que atenderam para esse workshop que me ajudem.

O processo para fabricar o tsuru é bem simples e não exige nenhum conhecimento prévio de dobradura. Ele pode ser apresentado nas sete etapas que podem ser observadas nas fotos abaixo:

tsuru_step1 tsuru_step2 tsuru_step3 tsuru_step4 tsuru_step5 tsuru_step6 tsuru_step7 tsuru

Assim, dividido em 7 etapas distintas, necessita-se de uma equipe de 7 pessoas no mínimo para executar essa atividade. Organize-os em uma sequência de mesas, mais ou menos como uma linha de produção.

IMG_2932

DSCN1674

Além dos papés de quem vai efetivamente executar o trabalho, precisamos de pessoas que monitorem o processo, observem-o e foquem em aperfeiçoa-lo. Claro que os inputs podem vir de qualquer membro da equipe, mas se não houver com o foco nisso, equipes inexperientes podem ter dificuldade para gerir as mudanças no princípio. Assim, precisamos de uma pessoa para anotar os dados em duas planilhas, a primeira é bem simples, com um número para cada etapa em cada um dos ciclos. Nela devem ser anotados quantos itens ficaram em cada etapa ao final do tempo dado.

tsuru_tracking

Um último detalhe que as imagens não descrevem, o primeiro membro da equipe, aquele que corta o papel para ser um quadrado, deve anotar em qual ciclo/lote aquele papel foi cortado. Isso será usado na outra planilha onde vamos montar um gráfico de dispersão. Essa planilha é opcional (portanto a anotação também), somente para o caso de você querer ensinar sobre Lead time e quanto tempo as tarefas podem estar paradas dentro do seu processo. Eu costumo faze-lo direto no Excel, ferramenta excelente e necessária para esse workshop.

Muito bem, equipe treinada no processo, observadores a postos, trackers alinhados sobre o que deve ser medido, iniciemos o trabalho, que se realizará em ciclos de 4 minutos. Correndo o primeiro ciclo (ou sprint, iteração, o que você achar melhor) algumas disfunções já são visíveis. A primeira é que o processo está desbalanceado, com etapas muito simples e outras muito complexas. Isso visivelmente vai gerar gargalos, mas não podemos chegar no processo final ainda, então muita disciplina é necessária nesse momento. Outra observação que se pode fazer é que existem pessoas que tem mais afinidade com algumas atividades, outras com outras e ainda temos aquelas que não se adaptam a trabalhos manuais. Normal, não somos todos iguais e as diferenças, quando assumidas, devem ser respeitadas.

O ideal é executar o ciclo de desenvolvimento umas 7 vezes aproximadamente, dando sempre um tempo entre os ciclos para que as pessoas parem, reflitam e implementem modificações. Ao final, muitas equipes foram capazes de compreender aonde estão os seus gargalos e agir para tratá-lo. Já outras colocaram mais e mais recursos da platéia na equipe até perceberem que essa era uma das piores soluções. A seguir alguns dos gráficos gerados por essas equipes. Neles os gargalos ficam muito claros a partir de um tempo. Algumas equipes souberam lidar com seus problemas em tempo, outras precisaram de ajuda, ainda houveram outras em que nem com ajuda o tempo foi suficiente para resolver.

Uma coisa que pode se fazer para lembrar o quanto trabalho em progresso é ruim é, no meio do processo, lá pelo 4º ou 5º ciclo, avisar que o mercado mudou e não se interessa mais por pássaros, mas sim por aviões de papel. Isso fica especialmente evidente caso a equipe não tenha se preocupado em limitar o WIP (Work in progress) pois todo os itens começados e não acabados agora terão de ser ou jogados fora ou vendidos à preço de banana. De qualquer forma, sua produção teve um prejuízo.

Seguem alguns gráficos de equipes que realizaram esse workshop.

cfd01

cfd02

cfd03

dispersao03

dispersao05

dispersao01

Essa obviamente é uma descrição bem superficial, ao final ainda conversamos sobre teoria das restrições, como promover mudanças e outras observações que o público apontar.

O importante é que no final, todos perceberam a importância de observar o sistema como um todo, de tratar os gargalos de seu processo produtivo, como medir de maneira justa e ainda como a limitação de trabalho em progresso pode ser uma ótima opção para tudo isso.

Posted on: 12 de Janeiro de 2015, by :

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *