Software sem qualidade não quebra só sistemas — quebra empresas
A importância de limitar atributos de qualidade, alinhá-los à estratégia e revisá-los continuamente.
Um caso que chocou Wall Street
Poucas horas no mercado podem arruinar anos de trabalho. Em 1º de agosto de 2012, a Knight Capital — uma das maiores corretoras de alta frequência — colocou em produção um novo módulo de roteamento de ordens (SMARS).
O código substituía um algoritmo de teste antigo chamado Power Peg que havia sido desativado desde 2003. Entretanto, parte desse algoritmo de testes permaneceu no sistema e um engenheiro reutilizou a mesma flag que ativava o Power Peg para acionar o novo módulo. O programador implantou manualmente o código em oito servidores; por engano, um deles ficou com a versão antiga, sem testes e com o Power Peg oculto. Como não havia processo de validação ou automação para a implantação, ninguém percebeu o erro. Às 9h30, o servidor defeituoso começou a enviar milhares de ordens de compra e venda a cada segundo, sem considerar o número de ações já executadas.
Em 45 minutos a Knight executou mais de 4 milhões de operações e perdeu cerca de US$ 440 milhões. Investigadores notaram que o código morto não foi removido, a reutilização de flags confundiu a equipe e faltou automação de testes e implantação. A empresa também trabalhou com um prazo de apenas 30 dias para desenvolver, testar e implantar mudanças complexas em um sistema que movimentava bilhões de dólares por dia — um cronograma “impulsivo, ingênuo e imprudente”.
O problema: falta de alinhamento com objetivos estratégicos
Os fatos acima ilustram um problema recorrente: a qualidade do software não foi tratada como parte da estratégia do negócio. A Knight priorizou velocidade de entrega e custo, mas ignorou atributos de qualidade vitais para uma corretora — confiabilidade, segurança operacional e gerenciamento de risco. Não havia processos formais de validação, automação de implantação nem gestão de riscos. O resultado foi uma falha catastrófica que levou à perda de reputação e à venda da empresa dois anos depois.
A mesma falta de alinhamento aparece em outras tragédias da engenharia. A Boeing projetou o 737 Max para competir com o Airbus A320neo sem exigir treinamento adicional dos pilotos. Para economizar custos e acelerar a certificação, os engenheiros escolheram um único sensor de ângulo de ataque para alimentar o sistema de correção MCAS — omitindo redundância e criando um ponto único de falha. Pressões de cronograma e cultura corporativa focada em margens fizeram a empresa ocultar o sistema dos manuais de pilotagem e minimizarem riscos. Dois acidentes (Lion Air JT610 e Ethiopian Airlines ET302) e 346 mortes forçaram a paralisação global da frota. Na missão da Mars Climate Orbiter, a NASA perdeu uma sonda de US$ 125 milhões porque o software de navegação em solo usava unidades inglesas, enquanto os demais sistemas trabalhavam em unidades métricas; a discrepância passou despercebida porque as verificações e validações não confirmaram que o software atendia aos requisitos e porque as equipes não comunicaram suas preocupações.
Outro caso clássico presente como case nas universidades. A sequência de erros do Therac‑25 — acelerador de radioterapia que matou pelo menos cinco pessoas — mostra como a eliminação de intertravamentos de hardware e a falta de revisão de código e testes permitiram que software não testado controlasse doses letais.
Esses casos mostram que qualidade de software não é um atributo isolado; ela deve estar alinhada com os riscos, valores e estratégias do negócio.
Quando empresas se concentram apenas em prazos ou custos e desconsideram atributos como segurança, confiabilidade ou usabilidade, criam riscos sistêmicos que podem se materializar em acidentes, perdas financeiras ou até mortes.
Um relato pessoal: relatórios financeiros e o cabo de guerra entre usabilidade e segurança
Apesar de as tragédias acima terem impacto midiático, muitos conflitos relacionados à qualidade permanecem invisíveis dentro das organizações. Recentemente, vivenciei um caso que ilustra como a ausência de critérios explícitos para ordenar atributos de qualidade pode gerar tensões internas. Trabalhávamos em um módulo para disponibilizar relatórios financeiros a clientes via e‑mail. A solução inicial envolvia enviar um link público para acessar o relatório. Do lado de produto, a prioridade era usabilidade: o processo deveria ser simples, com poucos cliques e sem cadastros. Do lado de engenharia, havia preocupação com confidencialidade e proteção dos dados. Como não havia uma diretriz prévia sobre quais atributos de qualidade deveriam prevalecer, a discussão se transformou em um cabo de guerra com reuniões intermináveis e atrasos.
Essa disputa expôs riscos invisíveis que muitas vezes passam despercebidos. Relatórios financeiros contêm dados sensíveis que, se compartilhados por um link público e sem controle de acesso, podem ser interceptados por terceiros ou cair nas mãos erradas. Um simples erro de envio de e‑mail pode constituir um vazamento de dados.
No nosso caso, o bom senso acabou prevalecendo: optou‑se por exigir autenticação e links expirados, implementando controles de acesso para priorizar a segurança — uma decisão que deveria ter sido óbvia se houvesse um alinhamento prévio com os objetivos estratégicos da empresa (proteger dados sensíveis e preservar a confiança dos clientes). O conflito poderia ter sido evitado se a organização tivesse definido explicitamente que, em produtos financeiros, segurança e confidencialidade têm prioridade sobre conveniência, servindo como critério de desempate em decisões de design.
Esse episódio também revelou outras fragilidades comuns: funções críticas sem um simples perfil de acesso, ausência de mascaramento de valores e campos vulneráveis a XSS. Esses riscos não geraram manchetes, mas representam um risco invisível que pode levar a perdas financeiras, multas regulatórias e danos à reputação se não forem tratados.
Alinhar atributos de qualidade aos objetivos do negócio — e comunicar essa ordem a todo o time — evita disputas desgastantes e reduz a exposição a esses riscos.
Por que alinhar atributos de qualidade com a estratégia?
Um software existe para atender a necessidades de diversos stakeholders. O modelo ISO/IEC 25010 define:
Qualidade de software é o grau em que o sistema satisfaz as necessidades explícitas e implícitas dos stakeholders.
E propõe um modelo de nove atributos de qualidade (funcionalidade, desempenho, compatibilidade, usabilidade, confiabilidade, segurança, portabilidade, manutenibilidade e escalabilidade) subdivididas em subatributos. Esses atributos representam valores que podem apoiar objetivos estratégicos como satisfação do cliente, conformidade regulatória ou eficiência operacional.
Alinhar atributos de qualidade com a estratégia significa responder a questões como: quais atributos são críticos para gerar valor? Se a empresa opera serviços financeiros, confiabilidade e integridade de dados são fundamentais; se o negócio prioriza crescimento rápido de usuários, usabilidade e escalabilidade importam mais. Técnicas modernas de trade‑off, como as propostas por Neal Ford no livro Software Architecture: The Hard Parts, seguem essa premissa. Em vez de um processo extenso como o ATAM, os autores recomendam um processo simples de três etapas:
Identificar o que está entrelaçado, ou seja, quais requisitos e componentes entram em conflito;
Analisar como esses elementos estão acoplados e como cada decisão de arquitetura impacta múltiplos atributos;
Avaliar o impacto de mudanças discutindo explicitamente os trade‑offs com base nos objetivos de negócio.
Para orientar essa conversa, a Architecture Characteristics Worksheet sugere listar no máximo sete atributos arquiteturais. Atributos implícitos como segurança ou viabilidade podem tornar‑se prioritárias quando são críticas para o negócio.
Escolhendo os atributos certos (e por que limitar-se a três)
É tentador querer otimizar todos os atributos — ter software rápido, seguro, confiável, fácil de usar, portátil e barato. No entanto, isso é impossível na prática. Como observa um artigo do Stack Overflow, não existe “o melhor de todos os mundos”: há inevitáveis trade‑offs entre atributos de qualidade; aumentar a segurança pode reduzir a usabilidade, melhorar a performance pode dificultar manutenção. Por isso, uma parte essencial da análise de requisitos é entender quais atributos de qualidade são mais importantes para o negócio. Muitas listas incluem dezenas de atributos, mas poucos projetos precisam se preocupar com todos.
Se a sua empresa é uma start/scale-up, concentre‑se nos dois ou três atributos que melhor suportam a visão e as metas estratégicas da empresa — isso facilita a tomada de decisões e evita conflitos de design. Neal Ford e Mark Richards defendem de 5 a 7 atributos, acho que isso se aplica a grandes corporações ou grandes projetos, se esse for o seu caso, considere-os.
Na prática, o time identifica quais atributos arquiteturais são importantes para o sistema, p.ex.: desempenho, segurança, disponibilidade. Cada atributo recebe uma classificação de importância de acordo com o contexto do negócio. Para cada atributo, descreve-se o porquê ele é importante, em que cenários será testado/avaliado e qual o critério de sucesso. Por fim, registrar trade-offs, e utilizar a planilha como uma “bússola”: quando há dúvida sobre design, a escolha é guiada pelos atributos prioritários documentados.
Em novo post, falarei mais sobre Architecture Characteristics Worksheet.
Faz sentido escolher atributos diferentes por épico ou produto?
Em produtos amplos ou em portfólios de soluções, diferentes epics podem ter metas específicas: um módulo de pagamentos precisa priorizar segurança e conformidade, enquanto outro módulo voltado para marketing pode valorizar usabilidade e desempenho. Portanto, definir atributos de qualidade por épico ou produto pode fazer sentido, contanto que haja coerência com a estratégia global. A arquitetura deve assegurar que atributos críticos (por exemplo, segurança e confiabilidade) não sejam negligenciados em nenhum componente que possa impactar a empresa como um todo. Além disso, decisões sobre atributos locais devem ser comunicadas a toda a equipe para evitar incompatibilidades (como aconteceu no Mars Climate Orbiter, onde equipes isoladas não comunicaram suas preocupações e o erro de unidades passou despercebido).
Quando mudar os atributos prioritários?
Os atributos de qualidade são vivos e devem evoluir com a estratégia. Mudanças no mercado (como regulamentações de proteção de dados), novas metas de negócio (por exemplo, priorizar expansão internacional ou reduzir custos), estágio do produto (MVP vs. produto consolidado) ou indicadores de desempenho (alta taxa de churn por dificuldade de uso) podem exigir revisar as prioridades. Técnicas modernas de trade‑off recomendam ciclos de reavaliação: após identificar e priorizar os atributos de qualidade, a equipe deve revisá‑las periodicamente para revalidar os trade‑offs e ajustar as escolhas. Uma revisão semestral ou a cada grande release pode detectar a necessidade de incluir um novo atributo (como escalabilidade) ou rebaixar outro. A mudança deve ser tratada como decisão estratégica: avalie como ela impacta a arquitetura e se há recursos para atender às novas metas.
Contraste: o perigo de escolhas isoladas
Tomar decisões de qualidade isoladamente — seja por equipe, funcionalidade ou gestor — é perigoso. No 737 Max, a escolha de usar um único sensor e esconder o MCAS foi tomada sob pressão comercial sem considerar a segurança global; a falta de comunicação com reguladores e pilotos agravou o risco. Na NASA, a equipe de navegação não utilizou a documentação de interface para validar unidades e não comunicou suas preocupações a outras equipes; erros “escorregaram pelas rachaduras” e levaram à perda da sonda. O Therac‑25 concentrou responsabilidades de segurança no software sem intertravamentos de hardware e sem revisão independente; a crença de que o sistema não podia causar sobredosagem e a falta de canais de reporte impediam que os incidentes fossem investigados. Esses exemplos reforçam que qualidade precisa ser discutida transversalmente, com participação de todas as áreas, revisões independentes e validação de requisitos.
Conclusão
A qualidade de software não é um atributo técnico isolado, mas sim uma extensão da estratégia da empresa. A história da Knight Capital mostra que ignorar atributos essenciais à confiabilidade e à segurança operacional pode levar a perdas bilionárias e à ruína; os casos do 737 Max, da Mars Climate Orbiter e do Therac‑25 mostram que decisões de engenharia desconectadas dos objetivos de segurança e comunicação acabam em tragédia.
Para evitar esses erros, as organizações devem:
Identificar drivers de negócio e derivar atributos de qualidade que realmente suportem esses objetivos;
Priorizar um pequeno conjunto de atributos (tipicamente 2 ou 3) para orientar decisões e evitar trade‑offs conflitantes;
Definir cenários mensuráveis e revisá-los iterativamente com base em técnicas modernas de trade‑off (como as de Neal Ford), envolvendo todas as partes interessadas;
Comunicar e coordenar decisões de qualidade através de todas as equipes para evitar discrepâncias e erros como os que levaram à perda da Mars Climate Orbiter.
Revisar e ajustar prioridades quando a estratégia, o mercado ou os resultados exigirem;
Ao alinhar a qualidade do software aos objetivos estratégicos e tratar essa escolha como uma decisão de negócios, as empresas reduzem riscos, melhoram a satisfação do cliente e aumentam suas chances de sucesso sustentável.
Você já parou para pensar qual atributo de qualidade o seu time defende quando tudo entra em conflito? Velocidade, usabilidade, segurança… e quando ninguém define a ordem, o que acontece?
Abaixo deixo um cheat sheet, um atalho para escolher e comunicar o Top 3 de atributos de qualidade alinhados à estratégia. Siga o fluxo Identificar → Definir → Comunicar → Revisar para tomar decisões com menos atrito e mais direção.
