Sempre que trabalhei com desenvolvimento de software, ele era realizado internamente nos modelos comuns de demanda de automação para serem utilizados pelo cliente-patrocinador ou como um produto da empresa. A qualidade sempre foi uma grande preocupação e, em alguns casos, os custos das atividades relacionadas com “qualidade” foram maiores que a implementação do software. Dentre essas atividades, temos: auditoria de documentos, revisões de projeto, revisões amostrais de código, testes manuais e automotizados, etc. Acredito que o mínimo esperado de um software de qualidade deve ser que os usuários finais realmente tenham condições de utilizar o software, ou seja, nenhum erro nas principais funcionalidades, bom desempenho e interface amigável.
Essa realidade ficou no passado, pois agora por motivos diversos estou diante da necessidade de contratação de fornecedores. Fornecedores que fazem mil promessas durante a venda do serviço e, ao serem questionados sobre a dificuldade de se construir o sistema que está sendo negociado, adoram "bater no peito" e dizer frases como: “isso é muito simples”, “fazemos isso o tempo todo”, “acabamos de entregar algo parecido para outro cliente”, “temos um desenvolvedor que entende tudo dessa tecnologia”, e muitos profissionais dessa área se sentem confortáveis ao ouvir esse tipo de coisa mas esquecem que depois da entrega, o suporte, muitas vezes, será feito pela sua equipe interna.
Após a entrega os problemas começam, em alguns sistemas já na fase de implantação. Ao precisar fazer alguma simples alteração ou correção de algum bug pequeno, olhamos para dentro do código e vemos que algumas partes foram feitas com ‘preguiça de pensar’ e em entregar algo bem construído. Agora o que vejo nessas outras empresas é algo que se parece com um pacto em que, por vezes, qualidade é atropelada pelo tempo, “nunca há tempo para fazer bem feito” ou para realizar todos os testes.
Entendo que “qualidade” é um conceito subjetivo, mas se as empresas em modo geral, não apenas da área de TI, ignoram isso é como se ignorassem o próprio cliente. Existem vários modelos, metodologias e processos a respeito, porém acho difícil serem usados com essa cultura de que os gastos com esse tipo de atividade são opcionais ou desnecessários.
Porque quando desenvolvemos softwares internos eles geralmente têm uma ótima qualidade? Logicamente porque as reclamações vêm dos colegas ao lado e de si mesmo, é o chamado dog food. A qualidade é cobrada na hora do almoço ou do cafézinho, talvez não seja o melhor meio, mas é uma forma de exigir qualidade.
É verdade que existem milhares de empresas atualmente com este tipo de serviço no Brasil, mas o que para alguns é visto como um mercado já saturado e concorrido, eu vejo como um mercado cheio de oportunidades e a busca do diferencial pode ser basear-se em um ponto elementar: a qualidade do que é entregue ao cliente. Parece muito simples mas. Infelizmente, não é uma realidade.
Então quem é responsável pela falta de qualidade em software em um país onde temos as várias competências necessárias? Muitos diriam que é um problema de gestão dentro dessas empresas fornecedoras mas eu não acredito nisso. Penso que é de responsabilidade do cliente em não mais aceitar esse nível de serviço, porque só assim pode ocorrer uma mudança fundamental no mercado, cortando a fonte de receita dessa empresas. Obviamente isso não é algo simples, ainda mais para clientes sem uma boa área de TI para realizar esse tipo de avaliação. Portanto, cabe a nós enquanto clientes exigir que tenha qualidade e, claro, pagar o preço justo por isso.
