Custo de Qualidade é a língua que o CFO entende

De todas as métricas de Quality Assurance, o custo de Qualidade talvez seja a única que dispensa tradução para a alta gestão — e, ironicamente, é justamente a menos medida. Enquanto nós, engenheiros, discutimos densidade de defeitos, cobertura funcional e lead time, o CFO raciocina em termos de custo, risco e retorno; e o custo de Qualidade é precisamente o ponto em que essas duas linguagens se encontram, para começo de conversa.

O problema é que, como esse custo raramente é explicitado, ele acaba absorvido (em estimativas, propostas e planejamentos) como custo de desenvolvimento. Ou seja: o orçamento de tecnologia carrega um componente escondido que distorce a produtividade real dos times e transforma a engenharia em uma linha de custo opaca, daquelas que a alta gestão só sabe cortar porque não consegue ler. Philip Crosby, um dos pais da disciplina, resumiu a questão na provocação “quality is free”: o que custa caro não é a qualidade, mas, sim, a não-conformidade; e é esse preço da não-conformidade (aquilo que gastamos, ou deixamos de gastar, com prevenção, verificação e correção) que deveria orientar decisões de investimento em processos, ferramentas e perfis de equipe.

E aqui vale resgatar Fred Brooks. Já escrevi neste espaço sobre o seu icônico “No Silver Bullet” e sobre a distinção entre complexidades essenciais (inerentes ao domínio de negócio, irredutíveis) e acidentais (criadas por nós mesmos, engenheiros de software). Proponho estender essa distinção ao custo de Qualidade: existe um componente essencial desse custo, derivado da complexidade do domínio, pois não existe versão “barata” de garantir conformidade em um processo de aprovação de crédito, por exemplo, com seus requisitos regulatórios e de negócio, e esse componente não pode ser eliminado por arquitetura, ferramenta ou modelo, sob pena de cairmos na mesma ilusão da bala de prata. Mas existe também um componente acidental: ciclos de vida de defeitos burocráticos, retrabalho causado por requisitos mal traduzidos, automações construídas sem governança nem manutenção. É apenas esse segundo componente que podemos (e devemos) atacar; e é apenas a medição que nos permite separá-lo do primeiro.

Sem essa separação, aliás, nascem as compras de balas de prata: adquire-se uma ferramenta de ponta (hoje, tipicamente, alguma solução de IA) para atacar um custo que era, noves fora, burocracia processual. Em minha vivência, tive contato com um projeto que apresentava baixa densidade de defeitos de escape (no papel, um caso de sucesso) mas cujo custo por defeito era tão alto que os poucos bugs encontrados comprometiam prazos inteiros; o vilão, descoberto justamente pelo exercício de decompor o custo de defeitos, era um fluxo triplo de aprovações no ciclo de vida dos defeitos, que inflava o prazo de report. Não adianta uma baixa densidade de defeitos se cada bug custa uma pequena fortuna; e nenhuma ferramenta resolveria o que era, essencialmente (perdão pela ironia brooksiana), um problema acidental.

A escala disso não é trivial: o consórcio CISQ estimou que a má qualidade de software custou US$ 2,41 trilhões à economia americana apenas em 2022, um número com tamanho de PIB que, no entanto, segue invisível nos orçamentos corporativos porque está pulverizado, projeto a projeto, dentro do “custo de desenvolvimento”.

Explicitar o custo de Qualidade é, portanto, o que permite à alta gestão tratar decisões de Quality Assurance como decisões de investimento com ROI; é o que tira a tecnologia da condição de linha de custo a ser controlada e a coloca na condição de motor de resultado a ser escalado; o primeiro passo não exige ferramenta nenhuma: exige registrar quanto o time gasta prevenindo, verificando e corrigindo. O mero exercício, garanto, já revela gargalos.

Fonte: “The Cost of Poor Software Quality in the US: A 2022 Report”, CISQ (https://www.it-cisq.org/the-cost-of-poor-quality-software-in-the-us-a-2022-report/).