DESTAQUE - Após uma visita a um fornecedor da Toyota no Japão, os autores refletem sobre a natureza do kaizen e explicam por que talvez estejamos procurando no lugar errado.
Alguns meses atrás, estávamos no chão de fábrica de uma planta de estampagem, um fornecedor da Toyota no Japão. Tínhamos viajado por todo o mundo procurando por kaizen.
Um de nós (Benoît) comprometeu-se ao lean como um método de expansão para sua empresa de software em rápido crescimento, trabalhando com outro de nós (Régis, um coach ágil e especialista em TI lean) para começar a trabalhar em suas equipes de codificação. A ideia era usar o método de seis pontos de Isao Kato e Art Smalley: 1. descobrir o potencial de melhoria, 2. analisar o método atual, 3. gerar ideias originais, 4. desenvolver um plano de implementação, 5. implementar o plano, 6. avaliar o novo método.
O uso do lean pelo fornecedor da Toyota era impressionante: todas as máquinas estavam funcionando, e o desperdício era realmente difícil de encontrar; as pessoas estavam em suas estações agregando valor; a qualidade era rastreada individualmente; não havia um centímetro de espaço não utilizado na planta, e, no entanto, tudo parecia estar instalado e prontamente disponível para os operadores, para suportar seu trabalho padronizado. Os caminhões da Toyota pegavam pequenas quantidades de cada peça a cada meia hora. Nós até vimos o quadro de hoshin kanri detalhando os desafios, os objetivos da empresa e a forma como eles se encaixavam em departamentos funcionais. Mas não havia vestígios de kaizen estruturado.
À medida que continuamos a olhar ao redor, percebemos que todas as impressoras estavam não só trabalhando continuamente, mas também trabalhando em lotes muito pequenos para satisfazer a demanda da Toyota de pequenas quantidades de cada peça em cada caminhão. Vimos uma mudança de ferramenta: uma equipe de operadores mudou simultaneamente as matrizes de várias impressões em uma linha e as iniciou novamente em questão de minutos (menos de 10, enquanto em uma fábrica normal isso pode levar várias horas) - produzindo boas peças desde a primeira. Mais surpreendente ainda, a produção começou novamente após a mudança sem o controle usual e a verificação de peças: os operadores confiaram na qualidade da primeira peça.
Perguntamos novamente sobre kaizen e ficamos perplexos. "Kaizen está em toda parte, o tempo todo", disse o diretor da empresa.
Enquanto discutíamos o que vimos, concordamos que isso devia ser verdade. Simplesmente não havia como uma planta funcionar tão bem sem kaizen constante. Tendo visitado várias fábricas de estampagem ao longo dos anos, um de nós (Michael) confirmou que nunca tinha visto tal qualidade, flexibilidade ou intensidade de capital. Claramente, a força bruta da engenharia não pode chegar lá - você precisa de kaizen.
POR QUE ISSO IMPORTA PARA UM DESENVOLVEDOR DE APLICATIVOS?
De volta ao gemba, pensando muito sobre o que tinha visto no Japão, Benoît teve uma visão repentina: os usuários do aplicativo querem passar de uma página para a outra e obter o que querem (informações, serviço, compra de um produto etc.) o mais rápido possível. Com isso em mente, qualquer tempo de carregamento da página é puro desperdício aos olhos do usuário. Quão relevante seria fazer kaizen no tempo de carregamento da página, por abordar a forma mais importante de desperdício, aquele que afeta diretamente o usuário final? Muito, acreditamos.
Quando Régis e Benoît discutiram isso com Nicolas Goutay, um dos líderes da equipe da Theodo, ele concordou imediatamente. Ele mencionou que, de fato, os usuários se queixaram de páginas carregando muito devagar. Em um projeto em que ele estava trabalhando, certas páginas críticas levavam até seis segundos para serem carregadas. Uma pesquisa rápida mostrou o quanto isso era um problema - basta verificar este infográfico de Kit Eaton.
De acordo com esse artigo, uma em cada quatro pessoas irá abandonar uma página se ela demorar mais de quatro segundos para carregar. A Amazon estima que pode perder até US$ 1,6 bilhão em vendas a cada ano por uma desaceleração de carga de página de apenas um segundo. Esses são números impressionantes.
Régis e Nicolas decidiram abordar esse problema em um projeto específico e definir um alvo de três segundos no máximo para o tempo de carregamento - em condições reais, o que significa que a velocidade da Internet dos usuários faz parte da questão. Eles, então, começaram a procurar o que os gigantes tecnológicos como Twitter, Google, Facebook e New York Times fizeram e apresentaram ideias potenciais para melhorias. Então, trabalhando com Antoine Kahn, Alexandre Chaintreuil e o resto da equipe de desenvolvimento, eles atacaram o problema por etapas:
- 2 segundos foram salvos pela compressão de arquivos antes de enviá-los para o navegador do usuário.
- 6 segundos foram salvos eliminando pedidos desnecessários aos servidores.
- 4 segundos foram salvos ao priorizar o conteúdo, de modo que o que é mais importante para os usuários é carregado primeiro.
- 1 segundo foi salvo ao otimizar o código de back-end, traçando seu caminho e tempo de marcação, para entender melhor onde exatamente o tempo foi gasto executando o código.
O último exercício revelou-se particularmente interessante, pois permitiu à equipe estudar melhor seu código, formular hipóteses sobre sua eficiência e testá-los. Duas dessas hipóteses valeram a pena e tiraram um segundo extra do processo.
Ao longo desse esforço de melhoria, várias coisas se tornaram evidentes. Em primeiro lugar, o método kaizen de seis passos foi muito útil para começar, funcionando como um andaime para definir um alvo concreto. A abordagem também pode ajudar a estabelecer hipóteses e a criar um ambiente em que Benoît, como CEO, e Régis, como coach lean, possam desafiar ainda mais a equipe e mantê-los focados em explorar e entender em vez de resolver os problemas óbvios e seguir em frente.
Em segundo lugar, à medida que a equipe entendeu o problema, a estrutura formal do kaizen tornou-se menos relevante, enquanto o pensamento real de "estudar e eliminar desperdícios" aumentou em importância. Na verdade, a equipe tomou a decisão de considerar cada fração de segundo "desperdício" para o usuário e investigar de onde ela veio, formulando hipóteses, testando-as e inventando contramedidas - em outras palavras, kaizen.
Em terceiro lugar, isso tornou-se muito valioso para o CEO, que pôde, então, ver o potencial para espalhar esse tipo de pensamento para toda a empresa e transformá-lo em um verdadeiro diferencial para os aplicativos que desenvolve. Esse é um genuíno pensamento lean seguindo a tradição da Toyota de considerar "o cliente primeiro, o revendedor segundo, o fabricante terceiro". Na Theodo, Benoît estava olhando para o usuário primeiro, seguindo para o cliente e para os codificadores em terceiro lugar. O esforço feito pelas equipes de codificação para diminuir segundos dos tempos de carregamento beneficiaria primeiro os clientes e os tornaria felizes, além de desenvolver as habilidades de codificação individuais de cada desenvolvedor (bem como a capacidade geral da Theodo para criar melhores aplicativos).
Então, pode-se dizer que fomos ao Japão à procura de um "método" de kaizen, mas não encontramos o que estávamos procurando. O que encontramos foi o aprendizado. Percebemos agora que a estrutura formal do kaizen não é o próprio kaizen - o mapa não é o território.
O que aprendemos é que, para sustentar o kaizen real, precisamos melhorar em:
1. Esclarecer os ganhos pretendidos: o diretor-gerente do fornecedor japonês da Toyota era muito claro sobre o tipo de ganhos concretos de que ele precisava do kaizen e onde esses ganhos poderiam ser reinvestidos. Quando Benoît viu os ganhos potenciais no nível da empresa em tempo de carregamento de página mais rápido, isso fez sentido a todos os envolvidos e aos próprios codificadores, que entenderam o que lhes foi pedido para melhorar.
2. Estudar desperdícios, com indicadores para descobrir o que realmente acontece: além de limpar os problemas iniciais óbvios, a verdadeira descoberta da equipe foi seu método para marcar o tempo na execução do código e estudar como o código se comportou ao decorrer do tempo, o que levou a formular hipóteses e, de fato, a um maior aprendizado sobre código e codificação.
3. Kaizen exige trabalho em equipe: o interesse compartilhado do CEO, do treinador lean, do líder da equipe e dos membros da equipe é o que mantia o esforço quando as coisas ficavam difíceis (estudar o código linha a linha). Era também o que fazia tudo valer a pena no final. As diferentes perspectivas trazidas para abordar uma questão técnica permitiam que a equipe procurasse novas soluções.
Muitos esforços kaizen permanecem no nível organizacional formal: passa pelas etapas, preenche o modelo de resolução de problemas e talvez altera o "processo". Muitas vezes, eles não vão até o ponto do processo técnico real, onde o usuário usa o produto ou serviço, onde a ferramenta toca a peça, onde o design realmente executa a função. Aprendemos que o verdadeiro kaizen exige que a liderança entenda quais problemas típicos - aqueles "difíceis de fazer" - farão uma diferença competitiva e, em seguida, comunique isso às equipes, a fim de envolver seu talento e paixão na busca de maneiras criativas para fazer melhor as coisas. Kaizen não pode ser programático. Tem que começar com a alta administração realmente querendo melhorar as coisas para usuários e clientes e apoiando as equipes no estudo de suas próprias formas de trabalho e do tipo de desperdício que poderia ser retirado desses processos técnicos. É assim que a real melhoria ocorre. É assim que uma empresa inova.