Kanban antes do Kanban
Entre 2006 e 2007, trabalhava no Brasil em uma empresa considerada inovadora pelas suas ideias em como economizar dinheiro para outras empresas. Basicamente o objetivo era realizar compras em atacado para empresas e obter lucro baseado na quantidade economizada destas compras.
Eu era responsável pela parte tecnológica de compra e venda de um de seus clientes, uma grande siderúrgica. Neste momento eu era a equipe de um homem só. Trabalhava já na base do desespero, somente o que era prioridade máxima era executado e mesmo assim com muito pouca inteligência. As urgências eram respondidas e não pensadas. Estava ali para enxugar gelo. Até que me foi autorizada a contratação de alguém.
Fiz algumas entrevistas e contratei alguém baseado somente em suas características técnicas, achava que seria o suficiente para enxugar gelo também, pelo menos a pressão seria dividida.
Como primeira atividade, pedi ao novo colaborador que me ajudasse a resolver uma fila com centenas de registros os quais deveriam ser enviados ao cliente. A primeira pergunta que ele fez foi: temos que fazer manualmente? Lembro que minha resposta foi: precisamos enviar, faça o que achar melhor!
Então ele me pediu 2 dias para enviar tudo e … voilá, dois dias depois ele havia criado um robô que processava a informação dentro da base de dados e enviava automaticamente sempre que algo novo chegava.
Logicamente fiquei positivamente impressionado pois era um problema a menos para resolver dentre muitos. E assim começamos uma parceria que renderia muitos frutos.
Até então, o meu pensamento e o pensamento de toda a empresa era: livre-se dos problemas não importa como. Sempre trabalhamos de forma enxuta e no limite, as requisições eram muitas e diversas com vários tipos de dificuldade mas, o mais importante, era muito além da capacidade que tínhamos para resolver.
Nesta altura, usávamos uma ferramenta chamada Vantive que agrupava os problemas sérios, passíveis de multa por não cumprimento de SLA. Ali tínhamos problemas que vinham desde layout das ferramentas de compra e venda até problemas específicos não identificados por fornecedores de software. Era um número mágico de 168 problemas analisados e considerados graves ou seja, não seriam resolvidos sem análise e programação ou configuração de software.
Ferramenta diária de trabalho para visualização dos tickets.
Já estávamos faz algum tempo trabalhando juntos, resolvendo problemas e apagando incêndios. O mais importante é que resolvemos os problemas sempre na raiz, custe o que custasse. Se o problema estava ali, íamos até o cerne da questão e aquele ficava extinto.
Foi então que resolvemos atacar os 168 chamados, era chegado o momento! O ambiente estava estabilizado e os problemas vitais de funcionamento do dia a dia estavam controlados. Resolvemos seguir para aqueles que ofendiam nosso SLA e minavam o lucro da empresa enquanto prestadora de serviços.
Não tínhamos um quadro Kanban declarado, mas tínhamos um processo muito bem definido de atuação nos problemas: primeiro era separar os chamados por tipo de problema e atacá-los um por vez não deixando nada bloqueado ou em stand by. Hoje vejo que aplicamos o conceito de WIP muito bem naquele tempo onde o que estava para ser resolvido dentro do nosso fluxo contava, independentemente se era fácil, difícil, estava com alguém ou bloqueado por algum motivo. Avançávamos para o próximo item somente quando o anterior estivesse resolvido ou seja, contava no wip de 1 por recurso por vez.
Com isto ganhamos algo impensável há poucos meses atrás: previsibilidade. A medida que resolvíamos os chamados, e propositadamente escolhemos os mais difíceis primeiro, íamos para os próximos. Hoje fica bem claro como a teoria das restrições nos ajudou.
Ao fim de 3 meses fechamos nosso último chamado. Ele havia sido aberto 2 anos atrás e ligamos para o usuário naquela época para que verificasse se estava ok. Fomos informados que o mesmo já não trabalhava mais na companhia, porém o erro já não existia mais e o chamado poderia ser encerrado. Foi um dia inesquecível onde informamos a direção sobre o feito e apesar de termos economizado centenas de milhares de reais para a empresa, fomos agraciados com um almoço em uma churrascaria.
A maior recompensa veio mesmo por parte da Siderurgia que passou a confiar em nosso potencial a medida que apresentamos estes resultados, já haviam percebido a melhora nas reclamações e realmente ficaram impressionados com o desfecho.
A partir disso, ganhamos mais contratos de desenvolvimento de software com ele e o clima da equipe ( de 2 pessoas) era ótimo. Dominamos o ambiente e os problemas que ocorriam, sempre usávamos a Teoria das Restrições quando necessário. Tínhamos um fluxo muito bem definido e sabíamos que tipos de problemas ou filas poderiam acontecer no processo. Sempre nos preparavamos ao máximo antes de colocar qualquer coisa em nosso backlog, prevíamos os problemas e se teríamos pessoal disponível para testes o interações por parte do cliente.
Isto fez com que nosso faturamento crescesse exponencialmente, chegamos a responder por 40% do faturamento de toda a empresa. Cronogramas ainda eram feitos, porém muito assertivos visto que sabíamos o que poderia acontecer, dominamos o ambiente e a forma como fazer e mapeávamos muito bem os prováveis riscos durante o processo.
O trabalho era focado no objetivo e entregue com escopo e tempo determinado e acordado previamente. Isto fez com que também outros contratos de empresas pertencentes ao grupo dono da siderurgia aparecessem. Neste momento atingimos não só a siderurgia como também fábrica de cimentos, empresas portuárias e fabricantes de peças diversas de aço e alumínio.
Hoje vejo uma analogia muito forte com as principais práticas do Kanban:
Na visualização, atuávamos fortemente nos chamados e checagem da ferramenta várias vezes ao dia. Era um alerta! Como dito anteriormente não tínhamos um board mas vários sinais visuais eram agregados ao processo sempre que um chamado aparecia, cores para diferenciar ou ainda post-its nos monitores para sinalizar o que estava em voga.
O limite do trabalho em progresso (WIP) foi definido logo de início onde somente uma tarefa deveria ser tratada por recurso por vez. Só era permitido ir para a próxima quando a anterior estivesse finalizada. Isso nos permitiu criar previsibilidade de tarefas no fluxo e entender como (e razoavelmente quando) resolveriamos os bottlenecks na linha do tempo.
O Gerenciamento do fluxo era constante. Sabíamos as fases do processo tanto para correção de itens quando para novos desenvolvimentos. Sabíamos o que esperar e a quem recorrer em caso de dúvidas, alinhávamos as necessidades com nossos fornecedores e clientes para que ninguém ficasse esperando uma resposta indefinidamente.
Políticas explícitas eram grande parte do gerenciamento diário. Questões como: só se poderia solicitar o fechamento de um chamado se o item já tivesse sido testado internamente pelos 2 recursos ou um item novo só poderia entrar em desenvolvimento caso obtivéssemos aprovação e orçamento junto ao cliente eram respeitados, monitorados e revistos periodicamente.
Tínhamos alguns feedback loops explícitos também, reuniões semanais de Status Report bem com reuniões de equipe diárias com reports para a diretoria eram a regra. Também havia as reuniões de report ao cliente e definição de estratégia.
Por fim, a melhoria colaborativa e evolução experimental traçavam nosso destino. Desde a primeira interação onde várias informações foram processada através de melhorias inteligentes e não uma a uma, esta prática não parou mais. Foi o começo de uma parceria de sucesso que apesar de um hiato, dura até hoje!
.