Qualidade de software não importa; o que vale é entregar!
Essa visão de fazer os projetos de qualquer jeito, tem prejudicado toda a indústria de software, contribuindo justamente para o contrário.
Durante anos acompanhando o mercado de software no Brasil, venho me dedicando a conversar com os profissionais de tecnologia em todos os segmentos de empresas e o tema qualidade de software é sempre algo deixado em segundo plano na agenda dos gestores, sendo visto erroneamente como custo e mais trabalho para criar uma solução. Indo contra essa abordagem, o Forrester fez um excelente estudo, em 2009, no qual comprova que corrigir um bug em produção chega a custar trinta vezes mais, coisa que você já deve saber, porém poucos se dedicam a estudar mais a fundo a origem e como resolver.
Essa visão aplicada em fazer os projetos de qualquer jeito, criando sistemas de produção “pseudo” produtivos, tem prejudicado toda a indústria de software ao longo dos anos, contribuindo justamente para o contrário. Isso resulta em software mal projetado, inseguro e nada produtivo; permeado por falhas frequentes e um retrabalho absurdo, consumindo os desenvolvedores, usuários e demais participantes do ciclo do projeto.
É comum receber o contato de clientes relatando que desenvolvedores querem testes, mas sempre chegam com aquele tom de deboche e uma dúvida no ar: “para quê?”, como uma grande interrogação na cabeça do gestor, uma vez que para ele está indo tudo bem, maravilhoso e que fazer software é assim mesmo: árduo, complexo, repetitivo, falho e, principalmente, essas dificuldades só existem devido à características do negócio dele e por isso eles sofrem e estão condenados a viver assim, sempre planejando e vendendo sonhos que nunca são entregues conforme o previsto.
Eu imagino que você certamente se identificou com algo dito até este momento, afinal esses fatos refletem a mais pura essência de como se “conduz” e se pensa um projeto de software nas condições do vai fazendo e coloca em produção que eu assumo (“Go↳Go23 conteúdosEntendendo o Green Tea GC do Go 1.26Dev (Back & Front) · mai 2026Função recursiva em Go para acessar valores em mapas aninhadosDev (Back & Front) · set 2025Publicando projeto desenvolvido em Golang em um server grátisDev (Back & Front) · mar 2025Ver tudo em Dev (Back & Front) → Horse”), pode confiar. Estamos no momento importante para você se permitir uma pausa (“Eu sei que você já escutou isso”) para refletir se esse processo de trabalho na raça, força bruta e retrabalho é realmente a única forma de se construir software e repensar onde foi parar toda a modernização tecnológica que foi criada nos últimos quinze anos e continua sendo ignorada.
Em todas as minhas pesquisas no mercado de software tenho percebido que ninguém se preocupa em contabilizar o prejuízo, retrabalho, insatisfação de todos que participam, inclusive você e os usuários do sistema, mas, principalmente, o custo para manter um software na UMB (Unidade Multiplica Bug, equivalente à UTI para seres humanos) durante toda a vida do mesmo, temendo qualquer mudança, atualização que se torna cada vez mais nociva a estabilização do projeto.
Se você tem um software hoje hospedado na UMB (Unidade Multiplica Bug) sabe responder rapidamente o tamanho do backlog de mudanças que não consegue implementar por falta de tempo (“$”); sabe responder os seus sonhos não realizados que o impedem de atender o cliente de forma mais moderna com um software simples e fácil de atualizar, pois está preso em um ciclo vicioso de manutenção recorrente que consome todo o seu tempo de repensar, inovar e progredir no produto.
Não existe produtividade ou evolução com segurança em software feito de qualquer jeito sem sustentação. É o mesmo que ter um edifício sem a devida fundação que sustente a carga de pessoas. Eu sei que as palavras carga e escalar são proibidas de serem faladas em projetos de software, mas chega um momento que não aguentamos e temos que colocar o dedo na ferida e começar a dizer não. Quando eu digo não, é não mesmo. Chegou o momento de tomar uma atitude de mudança e parar de esperar resultados sem você fazer nada de diferente.
Para pensar em um ciclo moderno de software é importante entender e discutir os requisitos desde o início, tornando as pessoas parte do processo. É preciso pensar mais no problema a ser resolvido antes mesmo de iniciar a codificação. Com as tecnologias modernas é possível pensar e separar corretamente a inteligência da aplicação, criando código simples e de fácil manutenção, que quando integrado a testes unitários automatizados passam a compartilhar a qualidade para todos do projeto. Hoje podemos criar ciclos de qualidade indo desde funcionalidades até carga, usando serviços de nuvem, o que aumenta a sua produtividade com a redução do retrabalho eliminando problemas recorrentes que nunca se resolvem numa abordagem tradicional.
Adotar práticas de qualidade é mais atitude do que qualquer outra ação e precisa estar na mente de todos que participam do ciclo de desenvolvimento de software. Você precisa conquistar o coração do seu cliente com um produto orientado aos seus desejos e que funcione corretamente. Qualquer pessoa que contribuir no projeto precisa ter em mente o quanto é importante aquela qualidade que ele está somando ao projeto.
Hoje não existe mais desculpa para viver no mundo de “Alice do software”, achando que jogar a sujeira debaixo do tapete e deixar o cliente pagar a conta da falta de qualidade é a solução. Um cliente insatisfeito custa muito caro para o negócio. Ele vai reclamar do produto e esse ciclo repetitivo de ir e voltar desestimula todo a equipe que perde a percepção de entrega do projeto. Por isso, hoje, pensar em qualidade é fundamental para ter produtividade e satisfação entre todos. Reduza os custos do seu projeto eliminando defeitos recorrentes e repetitivos ainda no início.






