segunda-feira, 19 de dezembro de 2011

Satisfação dos clientes

Hoje, vamos falar um pouco sobre a satisfação do Cliente com a implementação dos requisitos, especialmente os não funcionais.

O que é um software de qualidade para você? Muita gente pensa que, se um produto faz o que tem que fazer, então é bom, se não faz, então é ruim, ou seja, uma concepção dicotòmica (binária), do "é tudo ou nada".

Mas, na vida real não é assim. Sempre variamos nosso grau de satisfação, pois nem todo produto atende exatamente o que nós queremos, certo? O que quero colocar é que a satisfação é uma medida variável e contínua (ao contrário de discreta).

De acordo com a norma ISO 9001 – 2000, citada em [SWEBOK, 2004], diz que a qualidade de um produto de software é:

“is the degree to which a set of inherent characteristics fulfills requirements.”

Traduzindo: é o grau em que um conjunto de características atendem aos requisitos. Logo, qualidade é uma medida contínua (em contraponto a discreta), ou seja, existe uma escala livre na qual as características de um produto podem variar.

Quando falamos em requisitos funcionais, é mais simples saber se ele atende ou não. Agora, quando falamos em requisitos não funcionais, o conceito se torna mais subjetivo. Para sumarizar, os requisitos funcionais representam O QUE o cliente quer, e os não funcionais, COMO o cliente gostaria que fosse feito.

A Implantação da Função de Qualidade (QFD - http://en.wikipedia.org/wiki/Quality_function_deployment), uma técnica desenvolvida pelo Dr. Yoji Akao, classifica os requisitos em:
  • Normais: são declarados explicitamente pelos clientes (ou usuários). Sua ausência pode gerar um grau variado de insatisfação;
  • Esperados: nem sempre são declarados explicitamente, porém são esperados de um produto. Sua ausência gera um alto grau de insatisfação;
  • Excitantes: elevam o grau de satisfação quando presentes, mas não geram insatisfação quando ausentes;
Muitas vezes os requisitos não funcionais são tratados como "esperados" ou "excitantes", não sendo declarados explicitamente pelos Clientes. É claro que ajuda muito se o analista de requisitos for um profissional de informática (conforme nosso post anterior - http://www.obomprogramador.com/2011/12/japones-em-braile.html), pois saberá capturar melhor o que o cliente espera do novo produto de software.

Nós já sabemos que, ao fazer menos que o cliente espera, causaremos insatisfação. O que quase ninguém entende é que fazer demais também pode gerar problemas, pois o Cliente fica com a sensação que pagou mais do que deveria.

Eu costumo entender e representar a questão da qualidade de software como um gráfico:


Dado um conjunto de requisitos (R1, R2 etc), é dito que sua implementação pode variar e que desta variação advém a satisfação do cliente. Há uma linha imaginária que separa a satisfação da insatisfação (Mais que o esperado / menos que o esperado). Se a implementação dos requisitos por um software ultrapassa esta linha, significa que atende mais do que o esperado. Porém, se ultrapassa muito, entra na área do supérfluo, gerando insatisfação porque o cliente está pagando por algo que não foi solicitado.

Se a implementação dos requisitos por um software está abaixo desta linha, entra na área da insatisfação e, novamente, se está abaixo de um mínimo, gera a rejeição. As áreas escuras dos gradientes representam os níveis onde a instatisfação começa. Há uma pequena faixa de tolerância que, normalmente, é difícil de determinar.

Porém, se algum requisito "esperado" está abaixo da linha, isto pode causar até mesmo a rejeição do sistema. Sempre existem funcionalidades "xodó" dos clientes, e eles, quase nunca, dizem isto de forma clara. Passei por experiência semelhante há pouco tempo, que demonstrou claramente esta situação. O Cliente insistia em determinada forma e implementação, não sossegando até que eu fiz exatamente o que ele esperava, embora não seja o mais adequado (em termos de usabilidade).

A responsabilidade da análise de requisitos

Muitos problemas de insatisfação podem ser evitados se a análise de requisitos for feita com bastante critério, e por profissionais. Uma técnica que costuma ajudar é a elaboração de protótipos de interface, o que também é pouco compreendido pelos desenvolvedores profissionais. Um protótipo de interface NÃO É UMA PEÇA DE SOFTWARE, logo, não pode ser aproveitado no sistema definitivo. Ele tem que ser rapidamente criado e descartado sem culpa.

Existem algumas ferramentas no mercado que podem ajudar a criação de protótipos rapidamente e sem programação. A Microsoft possui o produto "Expression", que tem a ferramenta "Sketch Flow", muito interessante (http://www.microsoft.com/expression/products/sketchflow_overview.aspx). Outra ferramenta rápida, fácil e barata é a ForeUI (http://www.foreui.com/), e ainda temos a MockUp Screens (http://www.mockupscreens.com/?gclid=CPq62Jr3ja0CFUOQ7QodI2TFoA).

O que eu não recomendo é utilizar artifícios como:

  • Criar páginas HTML para simular a interface;
  • Criar desenhos no PhotoShop ou em software semelhante;
  • Criar aplicações Swing ou .NET para demonstrar o funcionamento;
Um protótipo deve ser e parecer provisório! Se o cliente perceber que é HTML ou que tem um programa por trás das telas, ele vai assumir que parte do trabalho já está pronta e você terá muitos problemas para explicar isso. O que acontece? Você perde mais tempo no protótipo e fica com uma solução "meia bomba" na mão!

Capacidades

De todos os requisitos não funcionais, as capacidades ("ilities"), ou os RNFs mais ligados ao funcionamento interno, são os mais difíceis de capturar. Por exemplo, como capturar adequadamente o desempenho? Ou a escalabilidade? E a manutenibilidade? 

O desempenho é mais fácil de capturar mostrando sites alternativos e medindo a satisfação do usuário. Pesquise alguns sites com tempos de resposta variados (ruim, bom, mais ou menos) e mostre ao usuário. A escalabilidade é um fator complexo e, normalmente, demanda muito hardware para ser implementada. Uma boa medida e mostrar sites que tem bom desempenho fora do horário de pico, mas ficam ruins dentro dele (horário comercial). 

E a manutenibilidade? Bem, é melhor conversar com o cliente sobre a rapidez e a tenacidade da concorrência, e a agilidade que ele espera para poder implementar novas funcionalidades. Depois, você pode apresentar o custo e o benefício de desenvolver código fácil de manter e estender.

Olhe para si mesmo


Você é um cliente de aplicações! Não acha? Bem, se você tem um smartphone (ou tablet), certamente já comprou algumas porcarias, certo? Isto sem falar nos softwares que você tem instalados no seu computador pessoal. Qual é a paciência que você tem com aplicações ruins? A faixa de tolerância é muito pequena! Funciona como o gráfico que eu mostrei no início.

Então, o que fazer?
Para começar, tenha certeza que os requisitos, e o nível de tolerância para com eles, tenham sido adequadamente capturados. Se você não é um analista de requisitos, então junte-se a eles, mesmo que seja só em algumas reuniões. Proponha a criação de protótipos de interface, tente capturar a "paciência" do usuário através de sites-exemplo. E, principalmente: 

Entregue APENAS o que o usuário QUER!