As Funcionalidades e a Qualidade Percebida

Quando pensamos em qualidade, normalmente, imaginamos algum ambiente fabril ou, ao menos, um "produto tangível". Afinal, por exemplo, um shampoo precisa atender a uma série de especificações técnicas para poder ser comercializado sem prejudicar a população.

Todavia, qualidade não significa atender ou não os requisitos técnicos. Sendo assim, o seu software não é de qualidade porque segue um Design Pattern específico, porque tem segurança, porque desempenha bem e é veloz.

Poxa, como assim?

A realidade dura é que a qualidade de qualquer produto, serviço, projeto... não é definida pelo o que você acha, pelo que a empresa acha e, sim, pelo usuário. Ou seja, é o seu cliente que determina se você tem um software de qualidade ou não.

Como consumidores, nós tendemos a criar expectativas em relação a algum tipo de produto ou serviço. Por exemplo, eu espero que um banco digital seja um exemplo de segurança e transparência, caso surja um escândalo de vazamento de dados, a minha reação primitiva seria tirar o meu dinheiro dali.

Com esse fato advém duas grandes problemáticas: A subjetividade dos clientes e a qualidade percebida.

Basicamente, cada cliente terá um conjunto de expectativas em relação ao seu software, algumas dessas expectativas podem ser "compartilhadas" com os demais clientes da sua base e algumas podem ser "exclusivas" desse cliente devido a sua personalidade, renda, convívio social, escolaridade e etc.

Portanto, não dá para viver naquela máxima de "o cliente sempre tem razão", pois, ninguém agrada todo mundo. Por isso existem técnicas de marketing que surgem para auxiliar na construção de uma "persona" do seu cliente médio, que reunirá as expectativas compartilhadas sobre o seu software e etc.

A outra problemática que eu citei é o da qualidade percebida, funciona assim:

Dependendo do seu nicho, do seu mercado, do seu tipo de software, alguns atributos serão extremamente sensíveis para os seus clientes. Por exemplo, a questão da segurança e bancos digitais. Caso esses atributos não atendam a expectativas do seu cliente, todo o seu projeto será condenado, a percepção do seu software será vista como "sem qualidade".

O problema disso é que a qualidade percebida é apenas a parte "visível" da sua qualidade, mas essa parte "visível" depende de toda uma base sólida.

Por exemplo, o cliente de uma BMW pode avaliar a qualidade do carro pela estática, pelo ronco do motor, pelo consumo de gasolina, pela beleza e etc. Nem passa pela cabeça do cliente a qualidade necessária do parafuso que segura o volante para que o seu carro tenha "qualidade" técnica.

A dinâmica é parecida com o dinheiro, a simples presença do dinheiro não deixará ninguém extremamente feliz, pois, existem várias outras coisas na vida que são "atributos sensíveis" para nós, tipo, reconhecimento, família e etc. Entretanto, a falta do dinheiro causa estrago.

Pela trajetória técnica da área de Tecnologia da Informação, normalmente o trabalho a ser feito será em cima dos itens que "se faltar dará problema, mas se tiver não fará diferença". Não podemos deixar essa "miopia" necessária nos impedir de entender os atributos sensíveis dos nossos clientes, pois, são eles que ajudam a vender o projeto.