Este artigo é um desabafo pessoal sobre a falta de atenção para a qualidade na área de desenvolvimento de software.
Já estamos em 2025 e parece que os softwares só pioram.
Existem muitas pessoas compartilhando algo como:
- “Para que fazer código bem feito? Consegui vender um projeto mal escrito por $x dólares”
- “Não temos tempo para qualidade. Precisamos entregar valor para o cliente”
- “Não temos dinheiro ou tempo para investir em qualidade”
Gostaria de trazer alguns fatos para que nós possamos refletir sobre o que é qualidade e como ela contribui para área de desenvolvimento de software.
Este artigo é para as pessoas que gostariam de ter a oportunidade de refletir sobre o assunto.
Qualidade para quem?#
Primeira coisa importante antes do meu desabafo é sobre o conceito de qualidade.
Nós desenvolvemos e testamos para quem? Quem é a pessoa que define a qualidade do nosso trabalho?
Não é seu colega de trabalho.
Não é seu líder e nem o CEO da sua empresa.
Tão pouco as avaliações feitas dentro da empresa.
É o cliente e o usuário final.
A opinião do cliente é absoluto em relação à qualidade do seu produto.
Não adianta você saber fazer um café utilizando grãos de primeira linha para uma pessoa que não gosta de café.
Mas se você fizer um café qualquer para um bom apreciador de café, saiba que você receberá feedback negativo.
Desenvolvimento de Software#
Mas desenvolvimento de software é diferente de café.
Estamos fazendo algo que resolve o problema do cliente. Ele quer o software.
Ou seja, ele é um “apreciador de café”. Vai ter feedback negativo se o sistema estiver ruim.
Como desenvolvedor, testador, Q.A., gestor de produto ou qualquer outro profissional responsável, deveríamos nos preocupar com a satisfação do cliente.
Ou seja, deveríamos ter empatia do cliente.
Empatia é a capacidade de entender o outro sem julgamento prévio. Você não precisa gostar do cliente e nem precisa ser amigo.
Entregar um software sem bugs para o cliente não deveria ser algo impossível. Deveria ser algo normal e básico. Equipes que entregam sistemas sem bug não deveriam ser excepcionais.
Excepcional são aquelas equipes que, além de entregar algo sem problemas, excede a expectativa do cliente de forma positiva.
É o café diferenciado e único que faz com que o cliente queira pagar por mais.
Mas hoje em dia é normal entregar rápido com bugs em produção.
Clientes e usuários do seu sistema podem ir presos por causa de bugs.
Isso aconteceu com o sistema chamado Horizon.
O link da notícia está logo abaixo:
E não é nenhum bug complicado que causou este problema. Um teste simples e inteligente poderia ter evitado esta tragédia.
Existem muitos casos assim. Bugs e problemas no software que prejudicam a vida das pessoas.
Nós sofremos com bugs de sistemas e reclamamos. Mas quando somos os profissionais na área de desenvolvimento de software, parece que não é mais tão importante fazer algo bem feito.
E quem se responsabiliza? E se encontrarmos os responsáveis, o que devemos fazer?
Um pedido de desculpas é suficiente?
Se um produto prejudicasse sua vida, uma desculpa seria suficiente?
Responsabilidade é quando você quebra um prato de prata do cliente e devolve um pratos de ouro. É morar do lado do rio onde sua indústria despeja o lixo tóxico.
Quando você ignora ou trivializa a qualidade, você está pronto para aceitar a sua responsabilidade?
Para você que não tem tempo para qualidade#
Provavelmente falta um processo de qualidade.
Vou compartilhar um vídeo que mostra como um grupo de médicos melhorou o processo deles para atender pacientes com TDAH.
Antes da melhoria, o diagnóstico demorava 4 meses e com qualidade duvidável.
Após a melhoria, o diagnóstico é feito em 3 semanas, melhoria na qualidade do atendimento, stress reduzido dos médicos (pois não tinham mais agendas lotadas), melhor satisfação dos funcionários e melhoria na produtividade.
Como é possível melhorar a produtividade “trabalhando menos”?
Como é possível ter mais tempo livre produzindo mais?
É o “paradoxo” da eficiência.
Para quem ficou curioso o vídeo está aqui:
E quem quiser uma explicação teórica do assunto, pode me chamar para conversar!
Para você que conseguiu ou viu um projeto vendido com bom dinheiro com código mal feito#
Primeiro, parabéns!
Vender algo é uma habilidade ainda inata para mim e algo que quero aprender.
Mas não pense que uma pessoa lucrou “melhor” por ter vendido um produto com código mal feito.
Ou não pense que não valeu a pena fazer as coisas bem feitas por ter visto alguém ganhar com um código ruim.
Isso não é causa e consequência. O código não reflete o valor do seu produto. É o famoso: correlação não implica causalidade.
Mas um código mal feito vai refletir na sua vida profissional, as pessoas que te seguem como exemplo, sua empresa e os usuários do seu código.
Por não ser algo factual, você não deve compartilhar sua crença como fato.
Pois isto influência outras pessoas e principalmente você mesmo.
Você terá uma mente dogmática sobre o assunto, principalmente com o reforço das pessoas em sua volta.
Sua empresa vai sofrer. Você se tornará exemplo e muitos funcionários seguirão a sua lógica. E quando precisar que algo seja bem feito, não terá ninguém que saiba fazer isso, pois não existe ninguém experiente que entregue rápido com qualidade.
O usuário final vai sofrer. Todo software precisa de manutenção. Os únicos software que não precisam mais de manutenção são aqueles que deixaram de ser utilizados. Ou seja, se o usuário ou cliente precisar de algo novo, alteração nova, vai sofrer pela demora na entrega.
Vou compartilhar novamente um caso onde um projeto foi bem vendido com código mal feito, mas que no final das contas o cliente entrou na justiça:
Qualidade é sobre prevenção também.
Se você for responsável pelo código, você se responsabiliza?
Para você que diz que entregar valor é mais importante que qualidade#
Concordo parcialmente. Entregar valor para o cliente é crucial para o negócio.
E ainda concordo que deveria entregar o mais rápido possível para o cliente, pois somente descobrimos se agregou valor ou não quando vemos a reação do cliente.
Mas você deve entender uma coisa importante. Você e sua equipe estão demorando para entregar algo valioso para o cliente principalmente por ter ignorado a qualidade.
Qualidade não é uma coisa “bonitinha” a ser feita. É um divisor de águas para a eficiência da equipe e sua empresa.
No momento que você colocou na balança a Qualidade e Velocidade de Entrega, você entrou na falsa dicotomia.
Quem faz com qualidade, entrega mais rápido, melhor e sem bugs ou problemas.
Compartilho novamente uma história famosa de uma fábrica de carros: NUMMI.
Esta fábrica era da General Motors com a pior reputação. Os funcionários colocavam areia no tanque de gasolina, deixavam latas de coca cola e assim por diante.
General Motors e sua liderança demitiram os funcionários por mal comportamento.
Mas surgiu uma oportunidade da General Motors fazer uma parceria com Toyota na NUMMI.
Com a gestão do Toyota o inesperado aconteceu.
Toyota contratou de volta os ex-funcionários que foram demitidos por mal comportamento e demitiram 80% da liderança.
A lógica era simples. Os funcionários, sabiam já executar o trabalho. Era só resolver o problema de contexto, como vimos no artigo anterior sobre o viés da culpa.
O foco era simples, qualidade. Em tudo que era feito e entregue, qualidade era prioridade.
Em um ano, esta fábrica da NUMMI foi de pior fábrica de carros para um dos melhores fábricas da General Motors com os “piores funcionários”.
Aqui está o vídeo com mais detalhes com a pessoa que trabalhou na NUMMI:
Você acha que sua equipe é ineficiente? Ou será que o contexto criado para a equipe que causa a ineficiência?
Conclusão#
Este artigo foi realmente um desabafo da minha parte. Existem muitos problemas em vários softwares.
Já trabalhei com sistemas que podem prejudicar a vida de alguém.
Surge um sentimento de raiva e tristeza quando vejo bugs no sistema, pois eu cometi o mesmo erro de ignorar a qualidade e vi pessoas sofrendo com meus erros.
Mas existe o outro lado da moeda. Sabemos que estamos fazendo algo melhor e bem feito quando recebemos elogio dos clientes e usuários finais.
A minha melhor recompensa foi quando eu estava em uma equipe onde recebemos uma carta do usuário final agradecendo pelo sistema.
Gostaria que muito mais pessoas da área de desenvolvimento de software tivessem a oportunidade de receber uma carta de agradecimento.
Se tiver mais curiosidade sobre o assunto, pode falar comigo!
“Rant” foi escrito com sucesso!
🥒🥒 Espero que tenham curtido e até o próximo artigo! 🥒🥒