Como falar Kata de Aperfeiçoamento

Temos vindo a praticar o Kata de Aperfeiçoamento há já algum tempo, mas ainda nos debatemos com o significado dos diferentes termos e como aplicá-los. Depois de ler este artigo, você deve ter uma visão clara das partes do Kata de Melhoria, o que elas significam e como aplicá-las.

Vamos começar!

Processo vs. Resultado

Antes de mergulharmos nos detalhes da linguagem do Kata de Melhoria, devemos começar por fazer uma distinção entre o processo e o resultado. Esta é talvez a parte mais difícil do Kata de Melhoria. Estamos habituados a pensar em objectivos e resultados e no que queremos alcançar. Queremos chegar aos nossos números de produção. Estamos focados no resultado. Com o Kata de Melhoria, concentramo-nos no processo que leva a um resultado. Devemos colocar o processo no centro das atenções, e o resultado é a consequência do processo. Eu tento sempre explicar desta forma:

• Não se pode realizar um objetivo ou um resultado.

• Mas pode-se realizar um processo.

Porque é que isto é difícil?

Esta mudança de mentalidade é a parte mais difícil do Kata de Melhoria. Desde cedo que nos ensinam a pensar em resultados. Temos de definir objectivos ambiciosos e alcançar as estrelas. Não está enraizado na nossa cultura pensar no processo. Por isso, temos de fazer esta mudança de mentalidade para aprender a fazer esta distinção e concentrarmo-nos no processo.

A melhoria do trabalho quotidiano é mais importante do que o trabalho quotidiano. Mas não vem em vez do trabalho quotidiano.

Antes de começarmos, uma visão geral

Esta é uma visão geral esquemática do processo Kata de Melhoria. Irei discutir as diferentes partes neste artigo, pode usar esta imagem como referência.

O verdadeiro norte - a nossa visão para a empresa

Queremos ser uma empresa calma. E acreditamos que o facto de nos esforçarmos por atingir estes quatro objectivos nos nossos processos nos permitirá alcançar esse objetivo:

• Fluxo de um único item, em sequência e sob demanda.

• Zero defeitos.

• 100% de valor agregado.

• Segurança para as pessoas.

Examinemo-las mais detalhadamente.

Fluxo de artigos individuais, em sequência e a pedido

Este é um dos princípios abrangentes do Kata de Melhoria. Antes de fazermos qualquer outra coisa, devemos mover um processo, qualquer processo, para mais perto de ser um fluxo de um único item, em sequência, e sob demanda. Mas porquê?

Queremos um processo estável e previsível. Queremos ter um processo escalável e um processo sem muito desperdício. Para lá chegar, precisamos de ver os estrangulamentos nesse processo. A mudança para um fluxo de um único item mostra esses estrangulamentos o mais rapidamente possível. E de forma mais clara. É necessário resolvê-los, caso contrário, nada pode fluir através do processo.

Se tivermos um processo de fluxo de um único item, em sequência, não podemos cortar nos cantos e acelerar as coisas para as fazer. Temos de eliminar um estrangulamento no processo antes de podermos avançar. Enquanto não estivermos lá, podemos fazer batota. Se conseguirmos ver claramente o estrangulamento num processo, podemos começar a resolvê-lo e a melhorar o processo, o que conduz a melhores resultados.

Zero defeitos

Sempre que um processo não funciona como definido, temos um defeito. Por isso, um defeito está centrado no processo e não no resultado. Cada defeito deve ser investigado para se aprender com ele.

Muitos problemas equivalem a um patrão feliz.

100% de valor acrescentado

Tudo o que fazemos num processo deve acrescentar valor ao resultado final do processo. Se fizermos coisas no nosso processo que não acrescentam valor, não o devemos fazer. Isto também é conhecido como a remoção de desperdícios de um processo.

Muitas das discussões sobre o 'lean' centram-se na eliminação de desperdícios. O pressuposto é que livrar-se do desperdício é um objetivo do lean, enquanto que livrar-se do desperdício é, na verdade, um resultado do Kata de Melhoria. Não é um objetivo por si só.

Segurança para as pessoas

Tudo o que fazemos deve respeitar este princípio. Quando estabelecemos um desafio, uma condição de objetivo ou uma descrição de processo, temos sempre de verificar se está dentro deste limite.

As pessoas cometem erros. Os sistemas que temos em vigor devem ajudar a evitar que isso aconteça ou, se acontecer, devem reduzir as consequências de um erro. Deveria ser seguro cometer erros. Não devem resultar em acontecimentos catastróficos. E se acontecer um acontecimento catastrófico ou menos catastrófico, temos de melhorar os sistemas.

A segurança das pessoas significa também que todos podem ser eles próprios no trabalho. Devemos ser capazes de falar, dar feedback e partilhar conhecimentos. É assim que aprendemos como pessoas e como organização.

Estado atual

Quando falamos da situação atual, falamos do processo que queremos melhorar. Num mundo perfeito, este processo deveria ter uma descrição clara. Esta descrição deve dizer como gostaríamos que o processo funcionasse. A descrição deve conter:

• Todas as etapas do processo.

• O tempo que cada etapa pode demorar.

• Quantas pessoas trabalham numa etapa.

• Quaisquer métricas de qualidade desta etapa.

• Quanto inventário é permitido por etapa.

• O tempo de ciclo total do processo.

Pode também conter uma descrição das caraterísticas deste processo. Devem ser mencionadas quaisquer preocupações relativas à segurança das pessoas e, por último, mas não menos importante, deve incluir uma métrica de resultados.

Para um novo processo, esta descrição pode ser feita ao longo do percurso. Enquanto trabalhamos para melhorar o processo, descobrimos como é que o processo deve funcionar. Isto pode e deve ser escrito para que possa ser usado como documentação sobre o processo. E, enquanto estamos a mudar e a melhorar o processo, esta documentação deve ser actualizada. Verá que quanto mais tempo trabalhar num processo, mais aperfeiçoado ele se torna.

Porque é que isto é difícil?

Para podermos passar para o fluxo de um único item e não acabarmos com optimizações locais, temos de nos esforçar por obter um único processo. É necessário ter em atenção a descrição de um processo como um processo autónomo que, na realidade, faz parte de um processo maior e, por conseguinte, é um subprocesso autónomo.

Quando começámos a aplicar o Kata de Melhoria, tínhamos um processo de desenvolvimento, um processo de teste e um processo de documentação, tradução e comunicação. Tive dificuldade em convencer os responsáveis pelo desenvolvimento de que tínhamos de incluir o processo de teste como parte do processo de desenvolvimento total. Porque ao melhorar o ciclo de desenvolvimento, mas sem poder testar e implementar histórias, tínhamos criado desperdício.

Temos de otimizar o conjunto.

Exemplo

Vamos utilizar um exemplo para ilustrar este facto. O nosso processo de entrega de valor aos clientes é composto pelos seguintes subprocessos para colocar uma funcionalidade online:

• Decidir o que construir - 3 semanas

  • Recolher informação sobre pedidos de funcionalidades (a pedido).

  • Classificar os pedidos de funcionalidades para obter uma prioridade (em sequência).

  • Descrever essa funcionalidade e planear o seu desenvolvimento.

• Desenvolver uma história - 3 dias

  • Discutir com o product owner.

  • Definir critérios de aceitação.

  • Desenhar, construir, revisão de código.

  • Refactorar o código.

  • Testar com a equipa.

• Testar e implantar uma história - 3 horas

  • Criar a história para staging.

  • Executar testes de aceitação.

  • Testar uma história.

  • Mergulhar história.

  • Implantar em produção.

• Traduzir - 1 dia

  • Criar pacote de item único para esta história para os tradutores.

  • Enviar o pacote para os tradutores.

  • Os tradutores traduzem as etiquetas desta história.

• Documentar e comunicar - 3 dias

  • Escrever notas de lançamento.

  • Escrever, atualizar e publicar artigos de ajuda.

  • Comunicar com clientes relevantes.

Temos muita documentação para cada etapa, descrevendo a qualidade a que se deve aderir, quantas histórias podem estar numa determinada etapa, quantas iterações são permitidas e quantos defeitos são permitidos numa história. Isso seria um artigo por si só.

A conclusão importante é que, para otimizar o todo, é necessário ter todas as etapas de um processo e medi-las. Se não o fizer desta forma, a otimização de uma etapa trará desperdício noutra etapa.

Métrica de resultados

A métrica de resultados descreve o que um processo produz. Este é o resultado do processo. Medimos a métrica de resultados de vez em quando para verificar se o processo ainda está a caminho de produzir o resultado desejado para a empresa. É isto que as outras empresas utilizam como objectivos ou metas.

Porque é que isto é difícil?

O que nos parece difícil é fazer uma distinção clara entre resultados (métrica de resultados) e processo. E quando se define uma métrica de resultados, de repente parece que se trata de um objetivo. Que temos de atingir e ficamos desapontados por não o fazer. O único objetivo da métrica de resultados é poder medir se nos aproximamos do ponto onde queremos estar.

Exemplo

A métrica de resultados do nosso processo de desenvolvimento é que queremos lançar uma funcionalidade de 100 dólares de três em três meses por equipa. Pensamos que o facto de lançarmos todos os meses uma funcionalidade que proporcione valor aos nossos clientes nos proporcionará o crescimento de que a empresa necessita para ser uma empresa tranquila.

Desafio

O desafio descreve o estado futuro do seu processo que pretende alcançar. A parte difícil disto é ter em mente que estamos a falar do processo, não do resultado. Deve descrever como gostaria que o processo funcionasse, e não um objetivo ou resultado. Um desafio pode ser lançado a grande distância e com um prazo longo, entre seis semanas e um ano. Se já sabe como lá chegar, está demasiado perto. O desafio dá uma direção e será dividido em condições-alvo mais pequenas.

A melhor forma de começar a definir o desafio é chegar ao fluxo de um único artigo. Em seguida, deve esforçar-se por atingir a sequência e a última parte deve dizer respeito à procura. Chegar ao fluxo de artigo único e em sequência levou-nos dois anos.

Porque é que isto é difícil?

Mais uma vez, isto resume-se a pensar em processos e não em resultados. Para muitas pessoas, é difícil lidar com a incerteza de não saberem como lá chegar.

Exemplos

Quando começámos com o Kata de Melhoria, tínhamos o desafio de passar para o fluxo de um único item para lançar uma história. Assim, quando uma história estivesse pronta, ela deveria ficar online.

Outro exemplo é o subprocesso para as traduções. Definimos o desafio da seguinte forma:
Dentro de três meses, chegar ao fluxo de um único item para traduções, com um tempo de ciclo de um dia, sem gastar tempo a responder a perguntas.

Condição de objetivo

Uma condição-alvo é o primeiro passo que o aproxima do seu desafio e que pode ser alcançado num prazo de três a seis semanas. Este é o estado futuro do processo que pretendemos atingir. A condição-alvo dar-nos-á um sentido de orientação para as nossas melhorias. Como? Medimos o nosso processo de trabalho enquanto trabalhamos. Sempre que temos um desvio do processo, tal como descrito na condição de objetivo, temos de o analisar. Chamamos a isso uma "análise da causa raiz" (RCA). A realização das ACRs fornecer-nos-á informações sobre o nosso estrangulamento.

Exemplo

Para o desafio sobre as traduções, definimos esta primeira condição de objetivo:
Definir e medir o tempo que leva para traduzir um único item para todas as línguas. Queremos medir por língua.

Gargalo

Por vezes, referimo-nos a este facto como um obstáculo. Mas a palavra estrangulamento é muito mais adequada para descrever o que é. Um processo só pode ter um estrangulamento (mas muitos obstáculos). O estrangulamento é o que nos impede de atingir o nosso objetivo.

Se olharmos para uma ampulheta, a parte mais pequena é o ponto de estrangulamento. Aumentar o tamanho da ampulheta antes ou depois do estrangulamento não aumenta o fluxo. Melhorar tudo o que não seja o estrangulamento é um desperdício. O estrangulamento impede que o item flua através do processo sem interrupções, ou é a parte do processo com o menor rendimento.

Só a melhoria do estrangulamento o aproximará da sua condição-alvo. Resolvemos o estrangulamento através de um ciclo PDCA (mais sobre isso adiante).

Porque é que isto é difícil?

A parte mais difícil é definir o ponto de estrangulamento. Quando se começa a melhorar e se apanha o jeito, vê-se uma série de coisas que podem ser melhoradas mas que não são o estrangulamento. É difícil resistir ao impulso de resolver essas coisas, especialmente quando são pequenas coisas que se podem fazer. Manter-se fiel à resolução do estrangulamento é difícil e requer alguma disciplina. Por outro lado, embora a teoria diga que só existe um estrangulamento, resolver alguma coisa é sempre melhor do que procurar o estrangulamento e não resolver nada. Fazer uma melhoria leva-o a praticar os ciclos RCA e PDCA.

Melhorar o que deve ser melhorado e não o que pode ser melhorado.

Exemplo

Para o nosso exemplo de tradução, definimos o primeiro estrangulamento da seguinte forma:
Não saber em que consiste um item. Não definimos um item e não sabemos que etiquetas e páginas que precisam de ser traduzidas fazem parte desse item.

RCA

Como já expliquei, RCA é a abreviatura de "análise da causa raiz". Sempre que temos um desvio do nosso objetivo, fazemos uma RCA para encontrar a causa principal. Encontrar a causa raiz mostrar-lhe-á o ponto de estrangulamento.

Porque é que isto é difícil?

Um desvio da condição-alvo nunca acontece numa altura conveniente, na maior parte das vezes é preciso incomodar as pessoas para se reunirem para fazer a ACR. Gostamos de fazer a RCA o mais próximo possível do momento em que o desvio está a acontecer, para que o rasto de informação não arrefeça. Assim, fazer a ACR é um compromisso entre não trabalhar no fluxo e melhorar diariamente.

No outro dia, tive uma conversa com o Maarten, Front-End Developer & UX Designer, sobre uma funcionalidade que demorou muito tempo a ficar online. A conversa desenrolou-se da seguinte forma:

Maarten: Finalmente temos a história que gera automaticamente as imagens para a documentação online. Foram necessários dois RCAs e muito trabalho para o conseguirmos fazer.
Me: Não se preocupe por ter demorado mais tempo do que o planeado, porque aprendemos muito durante o processo.
Maarten: Sim, os RCAs que fizemos mudaram a minha mentalidade de "este processo é instável" para "porque é que este processo é tão instável?".

Com esta mudança de mentalidade, pode começar a analisar a causa principal e a pensar em soluções. Com a mentalidade anterior, só se fica irritado e frustrado e isso não melhora nada.

Temos de abrandar para ir mais depressa.

PDCA

PDCA é a abreviatura de "Planear, Fazer, Verificar, Agir". O processo para melhorar um estrangulamento em pequenos passos. O desafio aqui é encontrar um pequeno passo para melhorar o processo. Algo que se possa fazer hoje. Para algumas coisas, é óbvio que precisamos de mais tempo. Por exemplo, se precisarmos de desenvolver ou automatizar algo. Mas devemos sempre tentar tornar as coisas mais pequenas. Podemos primeiro fazer uma melhoria à mão para vermos se nos aproxima da condição desejada? Se for esse o caso, podemos automatizar? Uma pequena melhoria mudará o nosso campo de visão e aumentará o nosso limiar de conhecimento. Após a melhoria, vemos e sabemos mais.

Uma melhoria demasiado grande pode levar ao desperdício porque não nos aproxima do desafio. É por isso que temos de manter as melhorias pequenas. Só podemos fazer uma melhoria por processo e por dia. Caso contrário, não saberemos se a melhoria efetivamente melhorou alguma coisa.

Porque é que isto é difícil?

Na maior parte das vezes, vemos muitas coisas que podem ser melhoradas. E queremos tirá-las do caminho, pensando que isso resolverá todos os problemas, para podermos continuar com o nosso trabalho. Mas não sabemos se todos esses problemas ainda existem quando fazemos algumas pequenas melhorias.

Outra coisa difícil é não pensar demasiado à frente e ver todos os obstáculos no caminho. Não se sabe se esses obstáculos se vão realmente materializar quando lá estivermos. E se esse obstáculo é, de facto, o ponto de estrangulamento. Por isso, não sabemos até lá chegarmos.

Dar pequenos passos é maximizar o trabalho não efectuado.

Campo de visão ou limiar de conhecimento

O campo de visão ou limiar de conhecimento é o que sabemos atualmente e o que podemos ver. Neste campo de visão existem muitas melhorias possíveis. O desafio dar-nos-á uma direção para as nossas melhorias. Se fizermos uma pequena melhoria, deslocaremos o nosso campo de visão (linha azul) e aumentaremos o nosso limiar de conhecimento na direção do desafio. Após esta mudança, sabemos mais e podemos ver outras melhorias e passos que podemos dar para alcançar o nosso desafio.

Porque é que isto é difícil?

Culpamo-nos por não termos visto melhorias mais cedo. Podemos apanhar alguém a dizer "porque é que não fizemos isto no ano passado?".

Tenho de citar aqui o famoso jogador de futebol neerlandês, Cruijff:

Je gaat het pas zien als je het doorhebt.

Traduzido grosso modo para:

Só o verás quando o compreenderes.