Duas equipes, na mesma empresa, na mesma semana. A da expedição quer testar uma etiqueta nova de identificação de volume e decide começar por um dia, num turno, com um cliente. A de TI quer testar um novo fluxo de aprovação de pedidos e resolve ligar para a operação inteira na segunda-feira, porque “em pedaços não dá para avaliar direito”.
A primeira parece tímida. A segunda parece decidida. E as duas podem estar erradas, porque ninguém fez a pergunta que define a escala: quanto nós já sabemos sobre essa mudança, e quanto custa se ela falhar? Escala de teste não é questão de temperamento nem de pressa da diretoria. É uma decisão com dois critérios, e ela pode ser tomada em cinco minutos numa reunião.
O que é a escala do teste
Escala do teste é o tamanho do escopo em que uma mudança é experimentada antes de ser adotada, e é a decisão que antecede qualquer projeto piloto: quantas pessoas, por quanto tempo, em quantos lugares, com quantos casos. Ela vai de bem pequena, como um turno com um operador, até grande, como uma unidade inteira por um trimestre.
Há uma confusão que atrapalha desde o início: pequena escala não significa mudança pequena. A escala se refere ao escopo do teste, não à ambição da mudança. Uma reorganização profunda do fluxo de atendimento pode ser testada com três pacientes numa tarde. A mudança é grande; o teste é minúsculo, e é justamente por isso que ele pode ser feito na semana que vem em vez de no semestre que vem.
A escala também não é o mesmo que a duração, embora as duas costumem andar juntas. Um teste com uma equipe por seis semanas e um teste com seis equipes por uma semana, cada uma servindo de grupo de comparação das outras, têm escopos parecidos e ensinam coisas diferentes: o primeiro mostra se a mudança sobrevive ao tempo, o segundo mostra se ela sobrevive à variedade de condições.
Os dois critérios que decidem
O Modelo de Melhoria resolve isso com dois critérios cruzados, e não com bom senso.
O primeiro é o grau de convicção de que a mudança vai resultar em melhoria. O conceito vem de Shewhart e não é um número calculado: é um julgamento explícito, alto, médio ou baixo, que depende de duas coisas. Quanta evidência sustenta a predição, e quão parecidas são as condições em que essa evidência foi obtida das condições em que a mudança vai operar. Um resultado excelente obtido num hospital grande diz pouco sobre uma clínica pequena, mesmo sendo evidência de verdade.
O segundo é o custo da falha, que é onde a escolha da escala encosta na gestão de risco. Se o teste der errado, o que se perde? Há mudanças cuja falha custa duas horas de retrabalho e mudanças cuja falha custa um cliente, uma multa ou a segurança de alguém. O custo alto não impede o teste: ele diminui a escala.
Cruzando os dois, a regra fica curta. Convicção baixa e custo de falha alto pedem escala bem pequena, e isso vale mesmo quando a organização inteira está comprometida com a ideia, porque compromisso não é evidência. Convicção baixa com custo de falha baixo ainda pede escala pequena, já que o barato de errar não paga o caro de não aprender. Convicção alta com custo de falha alto permite crescer só onde há compromisso real para sustentar o teste. E convicção alta com custo de falha baixo, numa organização preparada, é o único caso em que se pode partir para a implementação sem um novo ciclo.
Repare no que esses critérios excluem. Não entram no cálculo a urgência da diretoria, o tamanho do investimento já feito, nem a confiança de quem propôs a ideia. Entram o que se sabe e o que se perde.
De volta às duas equipes (situação-tipo construída para este texto)
A equipe da expedição já tinha evidência: a etiqueta nova era usada em outra planta do grupo havia dois anos, com o mesmo tipo de volume e o mesmo sistema. Convicção alta. E o custo de falhar era baixo, porque uma etiqueta ilegível se resolve reimprimindo. Pelos dois critérios, o teste de um dia com um cliente era pequeno demais: ela poderia ter começado com um turno inteiro e chegado à decisão duas semanas antes.
A equipe de TI estava no extremo oposto. O fluxo de aprovação era novo, desenhado internamente, sem nenhum caso parecido para se apoiar. Convicção baixa. E o custo de falhar era alto, porque pedido travado no fluxo significa entrega atrasada para o cliente final. Pelos mesmos critérios, ligar para a operação inteira na segunda-feira era a pior escolha possível.
O que a equipe de TI fez depois de refazer a conta: testou com uma família de itens, de baixo giro, por três dias, com o fluxo antigo rodando em paralelo como rede de segurança. Em três dias descobriu que 4 de 19 pedidos travavam numa condição que ninguém tinha previsto, a de aprovador ausente sem substituto configurado. Custou três dias e nenhum cliente. Na versão original, teria custado uma semana de operação e um número desconhecido de entregas.
Sete formas de reduzir a escala sem perder o aprendizado
Quando o cruzamento aponta para escala bem pequena, a dúvida vira prática: como testar tão pequeno e ainda assim aprender alguma coisa? O Modelo de Melhoria lista caminhos, e todos servem para o mesmo fim, que é reduzir o risco da falha e preservar o que se aprende.
Simular a mudança, fisicamente ou no computador, com simulação quando a variabilidade é conhecida, antes de encostar no processo. Pedir a quem conhece o assunto que revise a proposta e comente a viabilidade. Testar primeiro nos próprios membros da equipe que desenhou a mudança, antes de apresentá-la aos outros. Rodar a mudança lado a lado com o processo atual, com redundância, como fez a equipe de TI. Limitar a um único lugar, uma linha, um escritório, um cliente. Limitar a um período curto, uma hora ou um turno. E testar com um pequeno grupo de voluntários, lembrando que voluntário é ótimo para aprender e enganoso para decidir sobre a adoção geral.
Nenhuma dessas opções é gambiarra: são desenhos legítimos de teste, e a escolha entre elas depende de qual incerteza incomoda mais. Se a dúvida é se a mudança funciona tecnicamente, a simulação resolve. Se a dúvida é se as pessoas conseguem executá-la no ritmo do dia, só o turno real responde.
Como a escala cresce entre um ciclo e o seguinte
A escala não é escolhida uma vez. Ela cresce à medida que o grau de convicção sobe, e é isso que transforma uma sequência de ciclos PDSA em construção de conhecimento em vez de tentativa e erro.
O padrão de excelência para testar uma mudança, na formulação do Modelo de Melhoria, é ter predições satisfatórias sobre uma ampla gama de condições. Isso significa que cada ciclo não deve apenas repetir o anterior com mais gente: deve incluir uma condição nova. Outro turno, outro tipo de produto, outro perfil de cliente, outra época do mês. Ampliar mantendo tudo igual aumenta o volume de dados e não aumenta a convicção sobre o futuro, porque o futuro tem condições que o teste não visitou.
Duas assimetrias merecem atenção nesse caminho. Raramente se deve implementar logo após um único teste bem-sucedido em pequena escala, por mais animador que tenha sido o resultado. E raramente se deve abandonar uma mudança depois de uma primeira falha: uma razão comum de testes iniciais darem errado é a mudança não ter sido executada como planejado, o que é problema de execução e não da ideia. A mudança só deve ser descartada quando a teoria revisada deixar de prever que ela produzirá melhoria.
Quando parar de testar
A pergunta “quantos ciclos bastam?” não tem resposta fórmula, e o próprio Modelo de Melhoria a trata como questão de julgamento. O que existe são três condições que, juntas, autorizam a passagem do teste para a implementação: convicção alta de que a mudança resultará em melhoria, custo baixo de uma falha, e organização preparada para adotá-la.
Faltando qualquer uma, o caminho é outro ciclo, e não uma reunião de convencimento. Quando falta convicção, o próximo ciclo testa uma condição ainda não visitada. Quando o custo da falha é alto, o próximo ciclo reduz a exposição, com redundância ou um plano de reversão. Quando a organização não está pronta, o problema não é de teste: é de preparação, treinamento e sistema, e testar mais não resolve.
Vale registrar a diferença de expectativa entre as duas fases. Durante os testes, algumas falhas são esperadas e são a fonte do aprendizado. Depois da implementação, falhas devem ser raras: se continuam frequentes, a mudança foi implementada antes da hora.
O custo de escolher errado, nos dois sentidos
Errar para o lado grande é o erro visível. Ligar a mudança em todo mundo antes de saber se funciona produz o retrabalho caro, a desconfiança da operação e, com frequência, o abandono de uma ideia que era boa e foi mal testada.
Errar para o lado pequeno é o erro invisível, e talvez mais comum em empresas que já se queimaram. Testes minúsculos repetidos indefinidamente, sem nunca incluir condição nova, consomem meses e não movem a convicção. Existe até um efeito perverso: quando a escala pequena não é considerada uma opção, as pessoas protelam a mudança e tentam desenhar a versão perfeita antes de encostar no processo, com medo das consequências de um teste malsucedido. O resultado é que nada é testado e nada é aprendido.
O antídoto para os dois lados é o mesmo: declarar, antes de cada ciclo, o grau de convicção e o custo da falha. São duas frases. Elas tornam a escolha da escala uma decisão discutível, com critério, em vez de uma preferência de quem fala mais alto na reunião. É o tipo de julgamento técnico que se aprende conduzindo projetos com método, e que uma formação como o Green Belt desenvolve na prática, ciclo a ciclo, junto com o critério para afirmar que houve melhoria.
Na próxima reunião em que alguém propuser um teste, experimente fazer só as duas perguntas antes de discutir tamanho, prazo e área. Em boa parte dos casos, a escala se decide sozinha depois delas.
Conteúdo revisado pelo Master Black Belt Marcelo Petenate, estatístico, formado pela Unicamp, mestre pela USP e especialista em Lean Six Sigma e melhoria contínua. Nesta revisão, o foco foi o conceito de grau de convicção, de Shewhart, e o cruzamento com o custo da falha como critério de escolha da escala.
Escolher a escala pelo risco é uma das primeiras decisões técnicas de quem conduz uma melhoria, e ela pressupõe saber formular a predição e ler o resultado no tempo. O White Belt gratuito da EDTI cobre essa base, com o ciclo PDSA e a leitura de dados em série, e é o ponto de partida natural para quem vai desenhar o próximo teste da própria área.
Perguntas frequentes
O que define a escala de um teste de mudança?
Dois critérios cruzados: o grau de convicção de que a mudança resultará em melhoria e o custo de uma falha. Convicção baixa ou custo alto empurram para escala bem pequena; convicção alta com custo baixo permite testes maiores ou até a implementação direta, se a organização estiver preparada.
O que é grau de convicção?
É o julgamento explícito, alto, médio ou baixo, sobre a chance de a predição estar correta. Não é probabilidade nem nível de confiança estatística: depende de quanta evidência sustenta a predição e de quão parecidas são as condições dessa evidência com as condições em que a mudança vai operar.
Testar em pequena escala significa fazer uma mudança pequena?
Não. Pequena escala se refere ao escopo do teste, não ao tamanho da mudança. Uma alteração profunda pode ser testada com poucas pessoas, por poucas horas, num único lugar. É exatamente isso que permite testar ideias ambiciosas sem colocar a operação em risco.
Quantos ciclos de teste são necessários antes de implementar?
Não há número fixo: é questão de julgamento. A passagem para a implementação exige três condições simultâneas, que são convicção alta, custo baixo de falha e organização preparada. Faltando uma delas, o caminho é mais um ciclo, preferencialmente em condição ainda não testada.
Como aumentar o grau de convicção sem aumentar o risco?
Incluindo condições variadas em vez de apenas mais volume. Testar em outro turno, com outro produto, em outra época do mês ou com outro perfil de equipe aumenta muito mais a convicção sobre o futuro do que repetir o mesmo teste com o dobro de casos.
O que fazer quando o primeiro teste falha?
Descobrir por quê antes de decidir. As causas mais comuns são a mudança não ter sido executada como planejado ou os processos de apoio não estarem prontos, e nenhuma das duas condena a ideia. A mudança só deve ser abandonada quando a teoria revisada deixar de prever melhoria.
Dá para pular a fase de teste quando a mudança é óbvia?
Só quando as três condições da implementação estão presentes, e “óbvia” não é uma delas. Convicção alta precisa vir de evidência em condições parecidas, não da sensação de que a ideia é boa. Quando o custo de errar é alto, mesmo a mudança óbvia merece um ciclo pequeno antes.