Quando o problema de qualidade estava antes do QA

O contexto

A missão inicial parecia clara.

Testar a plataforma antes das entregas, reduzir falhas e melhorar a qualidade percebida pelo cliente.

Posteriormente, a atuação também passou a incluir a gestão da equipe de suporte.

Se problemas estão chegando ao cliente, precisamos melhorar a avaliação final.

Mas, nas primeiras semanas, começou a aparecer outro cenário.

Tickets, e-mails e conversas mostravam que atividades de naturezas muito diferentes circulavam praticamente pelo mesmo fluxo.

• suporte;
• bug;
• manutenção;
• customização;
• nova funcionalidade;
• novo desenvolvimento.

Alguns dos trabalhos mais pesados nem sequer possuíam registro correspondente no sistema de gestão.

O desafio

Havia situações classificadas inicialmente como bugs que, depois da investigação, revelavam outra coisa: a funcionalidade simplesmente não existia naquela versão do cliente.

A plataforma havia crescido por meio de diferentes customizações. Clientes distintos possuíam combinações diferentes de funcionalidades.

Ao mesmo tempo, demandas comerciais podiam chegar ao desenvolvimento com contexto insuficiente.

O cliente imaginava A. A necessidade era traduzida. O desenvolvedor recebia algo próximo de A, interpretava B e entregava B.

A divergência aparecia no fim como “erro”. Mas o problema havia começado muito antes do QA.

A análise técnica posterior revelou ainda outra dimensão: a evolução do software havia ocorrido sem uma disciplina madura de produto, versionamento e deploy formal. As diferenças entre instalações de clientes não possuíam um registro técnico centralizado suficientemente robusto.

O que aconteceu

A recomendação foi separar as naturezas de trabalho.

Suporte passou a significar manter e corrigir aquilo que já deveria existir e funcionar.

Desenvolvimento/customização passou a exigir discovery, especificação e construção de algo novo ou modificado.

A proposta foi aprovada.

Um onboarding passou a orientar as reuniões de novos desenvolvimentos. A responsável participava da conversa com o cliente, investigava a necessidade e levava contexto estruturado para a equipe técnica.

O sistema de gestão passou a funcionar também como memória operacional. Mesmo quando uma conversa acontecia por e-mail, o trabalho precisava existir como trabalho.

A equipe também começou a ser organizada considerando o tipo de demanda e as características dos desenvolvedores.

A implementação foi rápida. A institucionalização, não.

Foi necessário cobrar registros, treinar pessoas, adaptar ferramentas e reforçar repetidamente a nova maneira de trabalhar.

QUANDO O PRODUTO TAMBÉM COMEÇOU A MUDAR

A reorganização operacional aconteceu ao mesmo tempo em que a plataforma amadurecia.

A análise técnica do produto mostra evoluções concretas em áreas como representação de etapas, prioridade, permissões e rastreabilidade — preservando várias capacidades que já existiam, em vez de reconstruir artificialmente todo o sistema.

Um ponto particularmente relevante foi o tratamento dos dados históricos.

Em software legado, não basta criar uma funcionalidade que funcione para registros novos.

Se anos de histórico permanecerem presos ao modelo anterior, a empresa passa a operar duas gerações do mesmo produto.

O trabalho técnico buscou evitar justamente essa ruptura, adaptando o acervo existente para participar das novas estruturas e funcionalidades.

Os resultados

Com o tempo, a distinção entre suporte e desenvolvimento passou a fazer parte da forma de trabalhar.

Bugs começaram a ser tratados de maneira mais sistêmica:

Se apareceu neste cliente, onde mais pode aparecer?

A quantidade de bugs caiu progressivamente e o trabalho da equipe tornou-se mais observável.

Essa visibilidade permitiu demonstrar carga, responsabilidades e necessidade adicional de recursos.

A operação também passou a sustentar melhor o crescimento comercial. Representantes do cliente relacionaram explicitamente a melhora do software e do serviço à capacidade de vender mais.

Com o amadurecimento, a operação passou a funcionar sem depender da atuação cotidiana da pessoa que havia liderado sua reorganização.

Aprendizados de gestão

O controle de qualidade não corrige uma entrada mal desenhada

Testar melhor pode detectar divergências. Não elimina necessariamente requisito insuficiente, natureza de trabalho mal classificada, versão errada sendo comparada ou contexto perdido entre negócio e desenvolvimento.

A qualidade começa antes do QA.

Aquilo que não é distinguido não pode ser bem gerenciado

Se bug, manutenção, suporte e desenvolvimento entram todos como “ticket”, a organização perde capacidade de medir, priorizar, estimar, precificar, contratar e prever capacidade.

Aquilo que a organização não consegue distinguir dificilmente consegue gerir.

Trabalho invisível também produz valor invisível

Quando trabalho importante vive em e-mails, conversas e conhecimento individual, a empresa não enxerga sua própria capacidade.

Process design → Observabilidade → Capacity evidence → Commercial argument.

Um bom processo deve sobreviver à sua criadora

Dependência permanente não é sinal de sucesso. O objetivo de uma transformação operacional é fazer com que a organização consiga continuar funcionando quando quem desenhou o sistema já não precisa sustentá-lo diariamente.

PARA LEVAR PARA SUA OPERAÇÃO

Se sua equipe está sempre ocupada e ainda assim tudo parece urgente, estamos chamando trabalhos diferentes pelo mesmo nome?