Controle estatístico de processo é o conjunto de técnicas que mede como um processo se comporta ao longo do tempo, separa a oscilação normal do funcionamento daquilo que é anomalia, e permite prever o que ele vai entregar antes de ele entregar. Nasceu na indústria nos anos 1920 e é o que sustenta a alta maturidade no CMMI, os níveis 4 e 5 do modelo. Aplicado a uma empresa de TI, ele responde a uma pergunta de negócio: a operação consegue cumprir o que está sendo prometido no contrato?
Previsibilidade em projetos de software costuma ser tratada como qualidade de gestor experiente, alguma coisa que se ganha com tempo de estrada e sensibilidade para reconhecer encrenca antes que ela apareça. Não é. Previsibilidade é uma propriedade mensurável do processo, e existe método para saber quanto ela vale hoje e para melhorá-la quando não é suficiente. Sem essa leitura, compromisso de prazo, de custo e de qualidade é estimativa apoiada em experiência pessoal. Com ela, compromisso passa a ser consequência do que o processo comprovadamente entrega.
Este artigo percorre esse caminho por dentro de dois cenários de decisão, um de software e um de serviços, do tipo que aparece na mesa da diretoria e precisa de resposta antes de assinar.
Um pregão público é a oportunidade que chega a uma fábrica de software de porte médio. O escopo é conhecido, o prazo é apertado, e a disputa se decide no preço: para ter chance de vencer, a empresa precisa baixar o valor que cobra por ponto de função em relação ao que pratica nos contratos privados.
O desconto no preço do ponto de função não muda o trabalho que vai ser feito. Muda quanto sobra depois dele. Refeita a conta com o preço reduzido, o contrato só se sustenta se a operação entregar com pelo menos 20% de margem. Abaixo disso, a empresa passa a trabalhar para pagar o próprio retrabalho.
A pergunta que a diretoria faz é direta: conseguimos entregar dentro dessa margem?
Na maioria das empresas, a resposta sai da média dos projetos anteriores. Alguém abre a planilha, calcula a margem média dos últimos doze meses, encontra 23% e responde que sim, dá para ir. É uma resposta rápida, é uma resposta com números, e ainda assim é uma resposta que não responde à pergunta.
O desfecho conhecido desse caminho é a empresa vencer o pregão e descobrir, já com o contrato assinado, que o preço que ela mesma ofereceu não cabe dentro do que a operação consegue entregar. A essa altura não há mais decisão a tomar, só prejuízo a administrar.
A média informa onde o processo costuma cair. Ela não informa o quanto ele oscila em torno disso, e é a oscilação que decide se o contrato fecha no azul ou no vermelho. Uma operação com margem média de 23% pode ter entregado projetos entre 21% e 25%, o que torna o pregão seguro, ou pode ter entregado entre 4% e 40%, o que transforma a assinatura em aposta. As duas situações produzem exatamente a mesma média.
Todo processo varia, e a variação tem duas origens que exigem tratamentos opostos.
Existe a variação comum, que é o ruído inerente ao modo como a empresa trabalha. Ela nasce da combinação normal entre pessoas, ferramentas, ambiente e método, aparece o tempo todo e é previsível dentro de uma faixa. Reduzi-la exige mudar o processo, e isso é decisão de quem responde pelo processo, não de quem executa a tarefa.
E existe a variação especial, que é a anomalia. Ela não pertence ao funcionamento normal, aparece por um evento específico, e é o que faz um projeto sair completamente da faixa esperada. Essa se resolve identificando e removendo a causa raiz.
Confundir as duas custa dinheiro nas duas direções. Tratar ruído como anomalia leva a mexer no processo sem necessidade, e mexer em processo estável costuma piorar o resultado em vez de melhorar. Tratar anomalia como ruído leva a conviver com um problema que tinha solução.
Vale registrar um efeito que quase ninguém considera: quanto mais sensível o critério de alarme, mais alarme falso ele produz. Mesmo com o critério mais conservador em uso, espera-se um alarme falso a cada algumas centenas de medições.
Uma empresa que reage a todo sinal acaba ajustando o processo por causa de ruído estatístico, e paga por isso em produtividade: cada ajuste desnecessário consome esforço de gente qualificada e desorganiza o trabalho de quem estava executando.
Há uma diferença que separa software de manufatura e que costuma ser ignorada quando essas técnicas chegam ao desenvolvimento. Máquina se desgasta com o tempo, e por isso o processo industrial tende a piorar se ninguém intervier. Pessoa faz o contrário: acumula conhecimento, domina melhor o produto, e melhora. Uma equipe classificada como júnior em um projeto pode se comportar como sênior no seguinte.
A consequência prática é que os agrupamentos de dados históricos não são fixos e precisam ser reavaliados periodicamente, sob pena de a empresa decidir hoje com uma fotografia que já não descreve a equipe que ela tem.
Aqui está a distinção que decide o pregão, e ela é a mais mal compreendida da área.
Um processo está sob controle estatístico, ou seja, é estável, quando só existe variação comum atuando sobre ele. Ele é previsível: dá para dizer, com base no histórico, dentro de que faixa o próximo projeto vai cair. Um processo é capaz quando essa faixa cabe dentro do que o cliente ou o contrato exige.
São duas perguntas diferentes, e a segunda não decorre da primeira. Um processo pode ser perfeitamente estável e completamente incapaz. É o caso de uma operação que entrega com regularidade admirável uma margem que oscila entre 12% e 18%: ela é previsível, ela é confiável, e ela não fecha o pregão de 20%.
Duas técnicas respondem a essas duas perguntas, e é importante não confundir o que cada uma faz. O gráfico de controle acompanha o desempenho ao longo do tempo e mostra se o processo está estável, marcando os limites dentro dos quais ele naturalmente opera. A análise de capacidade compara esses limites com o que o contrato exige e responde se ele é capaz. Aplicar a segunda sem ter passado pela primeira não faz sentido, porque não há como avaliar a capacidade de um processo que ainda está sob efeito de anomalias.
A forma mais clara de enxergar isso é reconhecer que existem duas vozes falando sobre o mesmo processo, e que elas não se conversam sozinhas.
A voz do processo sai do histórico da própria empresa. São os limites dentro dos quais ela realmente opera, calculados a partir do que ela já fez, e nenhuma reunião muda esses limites.
A voz do cliente sai do contrato, da especificação, do edital. É o que precisa ser cumprido, e foi definido sem consultar a capacidade de ninguém.
Quando as duas coincidem, o processo é capaz. Quando a voz do cliente é mais exigente do que a voz do processo comporta, existe risco, e o risco passa a ser conhecido antes de assinar em vez de descoberto na entrega.
Nada disso é exclusivo de projeto de desenvolvimento. Em uma operação de sustentação, a voz do cliente tem nome e está escrita no contrato: é o SLA.
Considere um contrato de suporte que exige resolução de chamados críticos em até quatro horas, com apuração mensal e multa em caso de descumprimento. A pergunta de negócio muda de forma mas não de natureza: a operação consegue sustentar esse acordo, ou vai pagar multa em alguns meses e lucrar em outros?
A resposta segue o mesmo percurso. Primeiro, o tempo de resolução dos chamados é acompanhado ao longo do tempo para verificar se a operação é estável, ou se existem anomalias, como um pico em determinado turno ou depois de determinada entrada em produção. Depois, a faixa real de tempo de resolução é comparada com as quatro horas do contrato. E aqui aparece o mesmo desencontro do pregão: uma operação pode ser exemplarmente regular e ainda assim regular acima do que foi prometido.
As medidas mudam, o método não.
| O que se quer controlar | Em projetos de software | Em serviços de TI |
|---|---|---|
| Compromisso do contrato | Prazo, escopo e margem do projeto | SLA de atendimento e resolução |
| Qualidade da entrega | Percentual de aprovação nos testes | Chamados resolvidos dentro do prazo |
| Retrabalho | Defeito que escapa e volta do cliente | Taxa de reabertura de chamado |
| Produtividade | Esforço por ponto de função | Esforço por chamado atendido |
| Sinal de anomalia | Projeto fora da faixa histórica | Pico de tempo de resolução em um turno |
A taxa de reabertura merece destaque, porque é o retrabalho de serviços com outro nome: chamado que volta é trabalho pago duas vezes e SLA consumido em dobro.
Saber que o processo não é capaz não resolve nada sozinho. A questão seguinte é o que fazer, e ela começa por uma tradução que a maioria das empresas nunca faz: transformar o objetivo de negócio em algo que dê para medir durante a execução, e não apenas no fechamento.
Margem é resultado final. Quando a margem aparece, o projeto acabou e não há mais decisão a tomar. Ela precisa ser conectada a algo que se manifeste cedo.
Em desenvolvimento de software, a maior parte do que corrói margem tem um nome conhecido: retrabalho. Refazer o que já estava pronto consome esforço que ninguém orçou, e consome duas vezes, porque atrasa o que viria depois.
É por isso que retrabalho, produtividade e prazo não são três problemas separados. São o mesmo problema medido em três lugares: o esforço que se gasta refazendo é esforço que não produz entrega nova, e a fila que se forma atrás dele é o atraso que o cliente enxerga.
E retrabalho, em larga medida, é consequência de defeito que escapou das fases anteriores e voltou do cliente. Existe um indicador que se manifesta antes do prejuízo e que mede exatamente isso: o percentual de aprovação nos testes. Ele aparece durante o projeto, muito antes do fechamento financeiro, e serve como aviso antecipado.
A cadeia fica assim: a margem depende do retrabalho, o retrabalho consome produtividade e prazo, e ambos dependem do defeito que escapa, que por sua vez aparece no percentual de aprovação nos testes. É esse encadeamento que permite acompanhar em agosto uma meta que só seria conhecida em dezembro.
As organizações de alta maturidade do CMMI fazem essa tradução de forma sistemática, e é uma das diferenças práticas mais visíveis entre elas e as demais. Não se trata de medir mais coisas. Trata-se de medir as poucas coisas que comprovadamente antecipam o resultado que interessa.
Com a medida definida, vem a pergunta que dá para responder com dados: o que dentro do processo determina esse resultado?
A técnica que responde a esse tipo de pergunta é a análise de regressão, que verifica se uma variável permite prever outra e com que força. Em um conjunto de onze projetos com histórico consistente, testou-se a relação entre a profundidade dos testes de produto, medida pela quantidade de critérios de teste por ponto de função, e o percentual de aprovação nos testes de aceitação do cliente.
A relação se confirmou. O modelo explica 75,1% da variação observada no percentual de aprovação, e a significância estatística ficou em 0,001, muito abaixo do limite de 0,05 usado como referência. Em linguagem de decisão: se não houvesse relação, a chance de observar um resultado desses seria de 0,1%, e a profundidade do teste prevê a qualidade percebida pelo cliente.
Isso muda o tipo de conversa que a empresa consegue ter. Deixa de ser uma discussão sobre se vale a pena testar mais, que é sempre uma disputa de opinião entre quem defende prazo e quem defende qualidade, e passa a ser uma estimativa: aumentar a profundidade do teste nesta medida move a aprovação nesta outra.
Chega então a decisão que caracteriza uma operação madura, e que é diferente de adaptar um processo padrão ao projeto.
Adaptar é ajustar o que já existe às circunstâncias. Compor é escolher, entre alternativas conhecidas de execução, a combinação que faz o processo alcançar o objetivo, sabendo antecipadamente o que cada alternativa entrega. As escolhas em jogo são concretas: a composição da equipe, o tipo e a intensidade das revisões, o grau de automação dos testes, a experiência exigida para determinadas tarefas.
É aqui que a empresa descobre que a mesma organização tem vários processos possíveis, com capacidades diferentes. Uma equipe com mais da metade de profissionais seniores trabalhando sobre um framework consolidado produz um processo capaz de sustentar a margem do pregão. A mesma empresa, alocando uma equipe majoritariamente júnior e sem automação de teste, produz um processo que não sustenta. Não são duas empresas, são duas composições, e a diferença entre elas é mensurável antes da escolha.
Quando as alternativas são muitas e interagem entre si, comparar uma a uma deixa de ser viável. Nesse ponto entra a simulação de Monte Carlo, que testa milhares de combinações possíveis a partir das faixas de desempenho conhecidas de cada alternativa e devolve a probabilidade de alcançar o objetivo em cada arranjo. É o que permite responder não apenas se dá para bater a margem, mas com que chance, e quais fatores mais contribuem para a variação do resultado. Esses fatores costumam ser os melhores candidatos a receber investimento de melhoria.
Quem não faz essa análise decide por intuição e chama isso de experiência. Quem faz decide por evidência e consegue justificar a decisão para o cliente, para o sócio e para o próprio time.
Suponha que a empresa decida introduzir inspeção de código como parte da composição escolhida. A pergunta que vem em seguida é a que quase nunca recebe resposta honesta: funcionou?
O caminho habitual é comparar a média antes com a média depois e comemorar a diferença. Isso é frágil por um motivo específico. Antes de comparar dois conjuntos de dados, é preciso verificar se eles se comportam de maneira compatível, e é isso que faz o teste de normalidade. Se essa condição não se confirma e a comparação de médias é feita assim mesmo, comparam-se coisas de naturezas diferentes, e a conclusão não se sustenta. É a diferença entre uma análise e uma impressão bem apresentada.
No conjunto analisado, os dados não passaram no teste de normalidade, e por isso se aplicou o teste de Mann-Whitney, apropriado justamente para comparar dois grupos quando essa condição não se verifica. O resultado: entre os projetos sem inspeção de código, o percentual de aprovação nos testes de produto ficou em 69% na mediana. Entre os projetos com inspeção, chegou a 100%. A significância ficou em 0,0012.
A conclusão que a empresa pode levar à diretoria não é que a inspeção de código parece ter ajudado. É que houve aumento comprovado do percentual de aprovação, e que a diferença observada não se explica por acaso.
Quando o resultado fica abaixo do esperado, o percurso é outro e também tem técnica própria. O gráfico de Pareto ordena os problemas por frequência e impacto e mostra em quais deles vale concentrar esforço, evitando que a empresa gaste energia com o que aparece muito e custa pouco. O diagrama de causa e efeito organiza as hipóteses de origem do problema antes de sair corrigindo. São ferramentas simples e o valor delas está em impedir que a ação corretiva seja escolhida pela urgência de quem reclamou mais alto.
Vale um complemento que costuma passar batido: quando o processo surpreende para melhor, isso também é sinal de que algo fora do previsto aconteceu, e também merece investigação. A diferença é o objetivo. No caso do problema, investiga-se para impedir que se repita. No caso do resultado excepcional, investiga-se para descobrir o que foi feito de diferente e transformar aquilo em prática padrão.
De volta ao pregão. A empresa agora sabe três coisas que antes não sabia.
Sabe qual é a faixa real de margem que o processo atual entrega, e não apenas a média. Sabe que existe uma composição específica de equipe e de práticas que torna o processo capaz de sustentar os 20% exigidos. E sabe, com evidência, quanto a inspeção de código contribui para esse resultado.
Com isso, a decisão deixa de ser uma aposta e passa a ter três saídas legítimas. A empresa entra no pregão com a composição que comprovadamente atende, e assume o compromisso sabendo o que está assumindo. A empresa entra com ressalva, negociando prazo ou escopo com um argumento que se sustenta em dado. Ou a empresa não entra, porque nenhuma composição disponível alcança a margem, e recusar é a decisão correta.
Essa terceira saída é a mais subestimada. Uma organização que ainda não chegou a esse nível de análise costuma abandonar a oportunidade por precaução, sem saber dizer se perderia dinheiro de fato, ou pior, aceitar e descobrir o prejuízo com o contrato em andamento. Saber recusar com fundamento, e saber aceitar com fundamento, é o retorno concreto de todo esse trabalho.
O mesmo vale para o contrato de suporte. Assumir um SLA de quatro horas sabendo que a operação atual sustenta seis é escolher pagar multa. Assumir sabendo que sustenta três é vender previsibilidade, e cobrar por ela.
Antes de qualquer análise, um passo que costuma ser tratado como detalhe e que decide a validade de tudo: verificar se o dado é confiável.
O número que chega até a planilha não contém apenas a variação do processo. Ele contém também a variação de quem mediu. Em uma fábrica, isso se refere ao instrumento. Em software e em serviços, a medição é feita por pessoas: alguém classifica a severidade de um defeito, alguém aponta o esforço gasto, alguém registra o horário de abertura e de fechamento de um chamado.
Se dois profissionais classificam o mesmo defeito de formas diferentes, ou se o mesmo profissional classifica de um jeito hoje e de outro na semana seguinte, a base histórica está medindo o avaliador junto com o processo.
Existe técnica específica para isso, chamada análise do sistema de medição, que separa duas coisas: o quanto uma mesma pessoa varia ao medir a mesma coisa repetidas vezes, e o quanto pessoas diferentes variam ao medir a mesma coisa. Conforme o resultado, a correção pode ser alinhamento e treinamento de quem mede, ou mudança na forma de medir.
A consequência de pular essa etapa é séria e acontece com frequência: a empresa condena um processo que estava saudável, ou aprova um que não estava, porque o problema estava na medição e não no processo. Por isso essa verificação é a primeira coisa a fazer, mesmo sendo quase sempre a última a ser lembrada.
O trabalho estruturado de melhoria de processo começa, com o dado confiável, por quatro pré-requisitos verificáveis. A organização precisa coletar e usar dados sobre o próprio trabalho. Precisa ter processos definidos que especifiquem como e quando esses dados são coletados. Precisa executar esses processos de forma consistente, com as adaptações acontecendo de maneira controlada. E precisa analisar o histórico que acumulou, em vez de apenas armazená-lo.
A metodologia Six Sigma mostra que as práticas de alta maturidade não substituem o que a empresa já pratica: o ciclo DMAIC organiza a melhoria na mesma lógica de medir, analisar e controlar.
A ISO 13053, que padroniza esse ciclo, é a referência para reconhecer as equivalências.
O Kanban Maturity Model faz o mesmo para quem opera com Kanban, com um mapeamento direto para os níveis do CMMI.
A Kanban University mantém o modelo e publica esse mapeamento.
Uma observação final sobre ordem de investimento. A tentação natural é começar pela ferramenta, porque ferramenta é o que se compra com decisão rápida. É a ordem errada. Ferramenta acelera o processo que já existe, seja ele bom ou ruim. Sem medição confiável e sem processo consistente, o resultado é chegar mais rápido à conclusão errada.
Implementar processos de alto nível de maturidade não é um projeto com data de encerramento. É uma revisão contínua do modo como a organização trabalha, sustentada por análise, em busca de um desempenho que se conhece e se controla. A diferença entre uma empresa que faz isso e uma que não faz aparece exatamente no momento em que alguém pergunta se dá para entregar dentro da margem, ou dentro do SLA, e alguém precisa responder.
As empresas brasileiras certificadas em CMMI que percorreram esse caminho relatam ganhos concretos em previsibilidade, produtividade e qualidade de entrega, e vale conhecer o que elas alcançaram.
Fale com a Promove para avaliar por onde começar, se a sua empresa precisa responder a esse tipo de pergunta e hoje só tem a média histórica como argumento.
Controle estatístico de processo é o conjunto de técnicas que mede como um processo se comporta ao longo do tempo, separa a oscilação ...
CMMI AIM (Artificial Intelligence Maturity) é o framework do...
Seja o primeiro a comentar!