Vous êtes sur la page 1sur 9

Qualidade de software vai alm de testes1

Processos de melhoria de qualidade de software reduzem custos de projetos e garantem que o produto final
atender s necessidades existentes no momento de sua concepo.

Quem conhece aquele jogo de salo chamado telefone-sem-fio sabe o quanto ele se assemelha ao processo de
desenvolvimento de um software, do momento em que a solicitao feita at quando a soluo entregue. Da
mesma forma como, na brincadeira de criana, aquela frase ou palavra cochichada pelo primeiro participante se
distorce at chegar ao ltimo companheiro da fila, a demanda inicial de um software tambm interpretada de
diferentes formas em sua trajetria at o desenvolvedor.

Diferente do que muitas empresas ainda acreditam, testes por si s no so a soluo para o problema. Especialmente
se adotados simplesmente como uma das etapas no processo de criao do software, procedimento ainda muito
comum entre desenvolvedores, que, aos poucos, comeam a entender a importncia de colocar em prtica polticas de
qualidade e alinh-las aos processos de testes de solues.

Essas prticas vm ganhando um nvel de profissionalizao cada vez maior, impulsionadas por fatores como o
aumento na busca pelo offshore, a instalao de fbricas de software no Pas e o crescimento de exigncias regulatrias
como Basilia 2 e Sarbanes-Oxley. Como resultado, o que se v uma enxurrada de empresas, solues e servios que
prometem automatizar e aprimorar esses processos.

Muitas companhias, porm, tardam em compreender a diferena entre testes e processos de melhoria de qualidade e
as vantagens e implicaes para aqueles que os utilizam. Testes e qualidade esto interligados. Ambos so
necessrios, mas so coisas diferentes, decreta Adriano Alves, vice-presidente de tecnologia e servios da Compuware
para a Amrica Latina. Carlos Alberto Caram, diretor-executivo da consultoria ISD no Brasil e Amrica do Sul, concorda:
um erro achar que a qualidade comea pelo teste.

Especialista em maturidade de processos de software, especialmente aqueles estabelecidos pelo CMMI, do Software
Engineering Institute (SEI), Caram explica que teste apenas um dos aspectos de um programa de melhoria e
qualidade. O CMMI garantia da qualidade de processos e produtos, diz o profissional. Zero de erro ningum tem. O
que as empresas esto buscando reduzir esses ndices, afirma o diretor, lembrando que estas companhias precisam
comear a investir em regras bsicas de gesto do processo como um todo.

Tradicionalmente, o teste de software representa apenas uma das etapas a final, na maioria dos casos em seu
processo de desenvolvimento. Muitos desenvolvedores adotam os testes somente no fim do processo de
desenvolvimento para ganhar tempo, revela Alves, da Compuware. Ele explica que, em tese, implementar testes
desde o incio do desenvolvimento pode parecer mais caro, mas na prtica, adotar um ferramental de testes
automatizados pode significar mais agilidade e economia ao longo do processo.

Alm disso, ainda h muitas organizaes que tm nos testes o seu nico processo de garantia de qualidade. O que elas
no sabem que o teste no a soluo para os problemas, conforme afirma Luiz Wolf, um dos scios-diretores da
Tech4B, empresa nacional especializada em melhoria de qualidade, desempenho e custos de tecnologia da informao
(TI). Citando o especialista e desenvolvedor Michael Fagan, que h cerca de 30 anos, enquanto era funcionrio da IBM,
criou o processo de inspeo de cdigos que levou o seu nome, Wolf diz que os testes respondem pela soluo de
apenas 20% dos problemas em um software.

Di no bolso

Por mais exaustivos que tenham sido os testes, por si s, eles no garantem a qualidade do produto final, ainda que at
assegurem o seu bom funcionamento. A exemplo dos carros cerca de 40 anos atrs, muitas empresas ainda testam

1ngelo, Fernanda. Qualidade de software vai alm de testes. Computer World: 04 de outubro de 2006.
http://computerworld.com.br/gestao/2006/10/04/idgnoticia.2006-10-04.5523272156/

1
apenas o produto final, compara Helio Katanosaka, outro scio-diretor da Tech4B. Nesse caso, quando um problema
detectado, o caminho at a sua fonte longo e custoso.

Paulo Srgio Biscardi, diretor de marketing da Dynamic, empresa especializada em avaliao de processos de
desenvolvimento, acrescenta que ao deixar os testes para o final do processo, pode acontecer de o desenvolvedor nem
lembrar com exatido o que fez e quando. Quando isso acontece, refazer tudo a nica sada, ainda que seja dez vezes
mais caro. Esse um problema causado tambm pela falta de boas prticas, que invariavelmente sugerem a
documentao de todas as etapas do desenvolvimento.

Caso no tenham sejam seguidos padres de qualidade e boas prticas, localizar um erro ou um cdigo que deva ser
modificado pode tomar muito mais tempo do que se imagina. Exatamente por isso que os especialistas so unnimes
ao afirmar que quanto mais tarde um problema for identificado, mais caro ele custar empresa.

Osmar Higashi, scio da empresa de testes de software RSI, estima que um erro detectado na fase de concepo do
software custa 1 dlar para ser consertado. Nesta fase, estamos falando sobre uma alterao em um documento
Word, por exemplo, justifica o executivo. Quando passa fase de desenvolvimento de cdigo, esse valor sobe para 10
dlares e cresce exponencialmente conforme o processo evolui, superando facilmente o patamar de cinco dgitos uma
vez que ele seja encontrado j com o software em produo. Incluir processos de inspeo ao longo da cadeia de
desenvolvimento uma das formas de evitar que o erro alcance fases avanadas da produo, sugere Caram, da ISD.

Para garantir que a soluo atenda integralmente s reais demandas do negcio e saber, entre outras coisas, at que
ponto ela funcionar sem ter seu desempenho comprometido, preciso mais do que testes. fundamental a
implementao de processos de qualidade ao longo do processo produtivo. Isso porque se a ferramenta no cumprir o
prometido, a companhia ter de fazer novos e altos investimentos para alter-la e adequ-la. A qualidade precisa
ser foco desde o comeo e a rea de TI que tem de ir at cada um dos diretores para evitar receber a informao
errada, sugere Gary Jerep, consultor da Quest Software, fornecedora de solues de gerenciamento de aplicaes.

Ao contrrio dos testes, os processos de qualidade ajudam no apenas a reduzir os erros presentes no produto final,
mas a calcular a necessidade de processamento que um sistema pode demandar do hardware e o quanto uma empresa
pode perder pela falta de disponibilidade ou baixo desempenho da soluo, acrescenta Wolf, da Tech4B. Ele conta
que, em geral, a maioria das empresas s pra para calcular o prejuzo quando precisa contabilizar o retrabalho. Hoje
os clientes no nos vem mais como custo, mas como forma de aumentar o seu faturamento. Inclusive porque os
testes funcionais no trazem capacidades preventivas.

Tambm a Borland, empresa de solues para a criao de softwares, sente a mudana de viso dos clientes
desenvolvedores. At pouco tempo, 100% dos clientes nos chamavam para apagar incndios, confidencia Jos
Rubens Tocci, presidente da Borland Brasil. Agora, muitos comeam a se conscientizar sobre os ganhos que os
processos de qualidade de software podem trazer ao negcio, completa.

Enrique Nunez-Ruiz, gerente de vendas da Quest Software para a Amrica Latina, explica que seus clientes comeam a
medir melhorias de desempenho e demonstrar pr-atividade na forma como contabilizam os resultados. Nossas
ferramentas ajudam a saber quando a soluo comear a ter seu desempenho afetado, destaca.

Quando parar?

Algumas organizaes pecam ao enxergar processos de melhoria de qualidade como projetos pontuais, muitas vezes
como mais uma modalidade de negcios que reduz o budget de TI. Ao contrrio disso, a adoo desses processos pode
e deve resultar em uma significativa economia de dinheiro e tempo. E o que sugerem as companhias que j
adotaram esse modelo de desenvolvimento.

No entanto, muitos diretores de TI questionam o momento certo de parar de investir no aprimoramento desse
processo. Testes custam dinheiro. Ento a dvida quando parar de testar, reconhece Jerep, da Quest Software.
Segundo ele, as empresas no conseguem encontrar o meio termo para esses investimentos. sempre oito ou 80.

Para todos os especialistas, sem exceo, no h hora de parar os investimentos em qualidade tm de ser contnuos.
Qualidade no projeto. um processo, opina Caram, da ISD Brasil. Enquanto for preciso, necessrio investir, diz
o executivo, comparando esse aprimoramento ao de um atleta. Na busca pelo aprimoramento contnuo, ele [o atleta]
no pra de treinar.

2
Caram lembra ainda que quanto maior o controle que uma empresa tiver sobre o seu processo de desenvolvimento,
melhores sero os resultados que poder obter dele. Os atrasos em projetos custam muito caro, tanto para o
fornecedor quanto para o cliente, afirma. Se o desenvolvedor souber, por exemplo, que no tem condies de
entregar determinada demanda em um dado espao de tempo, pode ser mais vantajoso recusar o projeto. Mas ele s
vai saber disso se adotar boas prticas e processos de qualidade, garante.

Alves, da Compuware, diz que melhoria de qualidade implica em investimentos sem fim. Para perpetuar as melhorias
os investimentos devem ser contnuos, diz. Qualidade no pode ser pontual. Tem de ser um processo, faz coro Wolf.
Segundo o executivo da Quest, desde que seja bem-feito, o investimento sempre render ganhos. Se optar pela
qualidade, o custo total sobre o investimento (TCO) tem de diminuir. Se no diminuir porque o investimento no est
bem-aplicado, pontua.

Tocci, da Borland, diz ainda que investimentos em qualidade e no prprio CMMI devem ser feitos para o bem da
empresa e no para o seu marketing. Os investimentos no devem parar nunca. A habilidade vem da experincia, dos
erros e acertos, conclui.

No fim das contas, toda a discusso a respeito das vantagens de adotar polticas de testes e melhoria da qualidade de
softwares levam a crer que o mercado est mais maduro no que tange o desenvolvimento de solues. Especialmente
entre aqueles que buscam economia de dinheiro e tempo e, para quem pretende, principalmente, competir
internacionalmente.

Contra nmeros no h argumentos

Desenvolvedores gastam 50% do seu tempo encontrando e corrigindo erros IDC


80% do custo de desenvolvimento so destinados identificao e correo de erros National Institute of
Standards and Technology (NIST)
1 erro gerado a cada 10 linhas de cdigo escritas Writing Solid Code, Microsoft
Em mdia 12 horas so gastas para corrigir cada erro em um cdigo Writing Solid Code, Microsoft
54% dos projetos tm seus oramentos estourados The Standish Group
A cada mil linhas de cdigo so encontrados entre 20 e 30 bugs Sustainable Computer Consortium
Inspeo de software reduz entre 60% e 90% dos defeitos em software e 25% de seus custos de
desenvolvimento Michael Fagan Associates
56% dos erros encontrados depois da soluo final ter sido entregue tm origem na fase de requisitos Chaos
Report

3
Cinco parmetros para medir corretamente a qualidade do software 2

A qualidade de um aplicativo mais do que simplesmente a soma da qualidade de seus componentes. O maior erro
esquecer esse fato

Avaliar a qualidade de um software um mistrio. Muitos profissionais de TI ficam frustrados sobre como definir e
medir a qualidade das aplicaes.

No surpreendentemente, essas dificuldades resultam de um foco incorreto sobre o processo pelo qual o software
construdo. Achamos que podemos definir essas atividades e medi-los com preciso para que as pessoas possam ver e
focar nas atividades necessrias para criar, melhorar e gerenciar o software.

Mas de nada adianta ter um processo impecvel se o produto no estiver em linha. Infelizmente, esse o tipo de falha
que corremos o risco quando no somos capazes de medir a qualidade do software.

Essa falta de visibilidade sobre a qualidade est na raiz de muitos problemas de gesto de software. Os executivos de
negcios no conseguem entender por qual motivo um software custa tanto, demora tanto tempo para ser
desenvolvido e ainda tem custos associados para mud-lo. CFOs e CEOs, por sua vez, no conseguem entender por que
o investimento em TI to alto.

Voc deve estar pensando: "Ser que no cuidamos da qualidade de testes de software?" Mas o teste na melhor das
hipteses uma soluo parcial. O teste no realmente concebido para medir a qualidade estrutural do software - a
qualidade do design de um aplicativo e da fidelidade de sua implementao para o projeto.

Um software bem concebido, bem arquitetado e bem executado possui alta qualidade. fcil trabalhar com ele,
mant-lo e melhor-lo para suprir as demandas dos negcios. Ns sabemos que medir a qualidade do software bom,
mas podemos, de fato, medi-lo? Sim, graas a produtos que realizam essa tarefa.

Em uma aplicao, a qualidade de qualquer componente depende de outros componentes que ele est integrado. A
qualidade de um aplicativo como um todo , portanto, mais do que simplesmente a soma da qualidade de seus
componentes. O erro mais frequente em engenharia de software esquecer esse fato.

Por isso, qualquer sistema que possa ajud-lo nessa tarefa dever medir cinco pontos:

1. Alcance: deve ser capaz de lidar com vrias tecnologias. A maioria dos aplicativos modernos contm vrios idiomas e
sistemas que so ligados entre si de forma complexa.

2. Profundidade: deve ser capaz de gerar mapas completos e detalhados da arquitetura do aplicativo do Graphical User
Interface (GUI), ferramenta de captura, processamento e anlise de imagem, para o banco de dados. Sem essa
detalhada arquitetura, seria impossvel obter contextualizao da aplicao.

3. Tornar o conhecimento explcito de engenharia de software: deve ser capaz de verificar a aplicao inteira contra
centenas de padres de implementao que codificam as melhores prticas de engenharia.

4. Mtricas acionveis: as mtricas de qualidade no devem apenas informar, mas tambm orientar sobre como
realizar a melhoria da qualidade do software, mostrando o que fazer primeiro, como faz-lo, prximos passos etc.

5. Automatizao: finalmente, deve ser capaz de realizar todos os pontos descritos acima de forma automatizada.
Nenhum profissional ou equipe pode fazer essa tarefa, muito menos faz-la em um curto espao de tempo.

importante medir a qualidade do software, mas igualmente importante executar a atividade de forma correta. Essa
ao muito til no desenvolvimento de software, mas, muitas vezes, melhor no ter medio alguma do que contar
com uma errada.

2Subramanyam, Jitendra. Cinco parmetros para medir corretamente a qualidade do software. CIO Magazine Brasil Tecnologia: 09
de maio de 2014. http://cio.com.br/tecnologia/2014/05/09/cinco-parametros-para-medir-corretamente-a-qualidade-do-software/

4
Como controlar a qualidade no mundo gil?3

Em outras palavras, como fazer software rpido, mas fazer bem-feito?

Uma vez que as prticas geis de desenvolvimento de software estejam em pleno uso na sua empresa por seus times,
bem provvel que voc encontre alguns problemas em relao ao processo de desenvolvimento:

Novos releases quase sempre acompanhados de novos bugs;


Dvidas se o esforo de desenvolvimento est indo para valor adicionado ao produto ou para manutenes
corretivas;
No-conformidades e divergncias em relao ao padro corporativo (mesmo entre analistas de uma mesma
equipe);
Diferentes padres de desenvolvimento e metodologia entre os times;
Falta de sinergia entre as equipes e dificuldades para fazer um rodzio entre os analistas de times diferentes
(afinal, cada equipe faz do seu jeito).

Uma soluo tradicional seria montar um time de controle de qualidade para inspecionar os artefatos e testar as
releases, apontar as no-conformidades, bugs e rejeit-los. Simples, porm um paradoxo conceitual. Afinal, todo o
ganho de agilidade nas entregas pode ser colocado em risco se deixarmos para descobrir, l no finalzinho, que parte do
software precisa ser refeita. Facilmente, para cada correo, podemos adicionar algumas semanas no prazo final. Ou,
ento, aquela correria de entrega final, com custos de horas-extras e a penalizao motivacional do time, alm de
prejudicar a qualidade do produto (testa a, rapidinho).

possvel fazer diferente, com bons resultados. Podemos contar o caso, ocorrido numa grande organizao, onde
atuamos na causa-raz do problema (a falta da cultura de testes e a baixa aderncia metodologia de desenvolvimento
pelos desenvolvedores), e no apenas nos sintomas (artefatos com no-conformidades e bugs), focando na importncia
de se construir software com qualidade desde o incio.

Em conjunto com a equipe de qualidade, criamos indicadores para acompanhamento das entregas e do trabalho dos
desenvolvedores, tangibilizando os pontos fortes e os pontos de melhoria. Livres do rigor acadmico, alguns
indicadores eram simplesmente valores booleanos que indicavam se uma prtica era seguida. Eles foram divididos em
quatro grandes temas:

Processo de Desenvolvimento de Software


Produto
Eficincia e Melhoria Contnua
Cliente/Negcio

Fizemos uma apresentao dos indicadores para todos os desenvolvedores na reunio geral da Gerncia de
Desenvolvimento de Produtos, mas a receptividade deixou a desejar: alguns desenvolvedores sentiram-se "auditados".
Sempre acreditando no trabalho colaborativo, fizemos encontros com cada equipe para esclarecer dvidas e reforar o
foco na melhoria do processo, e no no controle individual de desempenho.

Tambm para melhorar a comunicao com os times, criamos um rito ao final de cada sprint, a Retrospectiva Tcnica,
em que o time de qualidade apresentava para cada clula de desenvolvimento a sua planilha de indicadores, e eram
levantados pontos de melhoria e respectivos planos de ao.

Aps dois anos de trabalho, tivemos slidos resultados.

3Fujikawa, Fabrcio. Como controlar a qualidade no mundo gil? CIO Magazine Brasil Tecnologia: 28 de maio de 2014.
http://cio.com.br/tecnologia/2014/05/28/como-controlar-a-qualidade-no-mundo-agil/

5
Melhoria da Qualidade do Software Produzido

Reduo direta do custo do desenvolvimento. A relao de causa e efeito foi visvel: os times mais aderentes
metodologia de desenvolvimento tinham menos defeitos no software produzido. Alm disso, identificamos que estava
ocorrendo muito trabalho em correes de funcionalidades que j tinham sido dadas como concludas. E, pior, sem
reflexo em nenhuma mtrica de acompanhamento, j que o indicador de defeitos, inicialmente, s monitorava
sistemas em Produo. Mudamos o conceito do indicador para abranger as manutenes corretivas em todas as
funcionalidades concludas pelos times, mesmo que ainda no estivessem em Produo. Assim, cobrimos este aspecto
da qualidade j na fase de desenvolvimento. Descobrir defeitos mais cedo sai mais barato.

Criao de Comunidade de Prticas: Frum de QA

Conseguimos um compartilhamento contnuo de conhecimento tcito entre os participantes atravs de encontros


peridicos. As reunies de retrospectiva tcnica foram fundamentais, pois permitiram o compartilhamento de
experincias e debates, incluindo lavagem de roupa suja, com os desenvolvedores apresentando suas insatisfaes e
crticas com a metodologia. Isto permitiu uma melhoria contnua do processo. Tanto que elas evoluram para uma
comunidade de prticas, chamada de Frum de QA, formada por representantes de todas as equipes de
desenvolvimento, onde tambm tivemos troca de experincias, discusses sobre dificuldades, sugestes e dvidas
tcnicas que ocorriam no dia-a-dia dos times.

Ampliao do Uso dos Cenrios de Testes

Na metodologia de desenvolvimento da empresa, um documento muito relevante era o Cenrios de Testes, escrito
pelos prprios desenvolvedores, no formato Given-When-Then, de especificao comportamental (BDD). Com o
passar do tempo, vrios outros pontos de utilizao dos documentos dos cenrios de testes, no imaginados
inicialmente, foram identificados: na validao do PO tcnico;

na validao do cliente;
na review;
na ambientao de novos colaboradores;
no apoio equipe que cuidava da operao do software em Produo;
na definio dos cenrios para testes de performance.

O fato de os documentos serem criados na plataforma Google Docs, disponvel via internet para todos os usurios da
empresa, e no s os da Tecnologia, viabilizou e liberou todo o potencial de uso dos artefatos, que se tornaram a
principal forma de compartilhamento e reuso de conhecimento explcito na metodologia.

Automatizao dos Testes

medida que a cultura de desenvolvimento orientado a testes (a partir dos cenrios de testes) foi absorvida pelos
analistas, comeamos a buscar solues para automatizao. Ao final do trabalho, todos os times j executavam testes
automatizados: tanto os unitrios, como tambm os testes de interface. Testes de regresso que levavam algumas
horas para serem feitos manualmente, passaram ser executados em cerca de 20 minutos. Com os deploys constantes
de seus produtos, isto representou uma reduo significativa de custos para a empresa.

Simplificao da Planilha de Acompanhamento dos Indicadores

Ao longo do tempo, o acompanhamento dos indicadores foi simplificado, e reduzimos os indicadores para apenas
quatro: um para cada tema. O objetivo foi focar no essencial e tornar a metodologia de acompanhamento mais leve.

Pesquisa de Satisfao com a Metodologia de Desenvolvimento

Tivemos 73,9% de avaliaes positivas, respondidas pelos desenvolvedores e Scrum Masters.

Apoio e Patrocnio so Fundamentais

Mudar cultura complexo. A alta gerncia precisou atuar em alguns momentos como mediadora entre as equipes de
desenvolvimento e a Equipe de QA, mantendo saudvel a relao entre os analistas envolvidos. Sem este apoio, a
iniciativa teria fracassado, sem dvidas.

6
Nossa experincia mostrou que possvel fazer software rpido e bem-feito. Trabalhar na causa-raz do problema, na
cultura de desenvolvimento, uma jornada rdua, que exige pacincia e evangelizao, mas compensa com resultados
concretos, duradouros e, sim, mensurveis.

(*) Fabrcio Fujikawa Diretor de Desenvolvimento e Qualidade da TeamWare

7
A importncia da qualidade para os clientes e para a empresa4

Ter um canal aberto e vivo entre empresa e cliente o melhor caminho para melhorar a experincia de consumo

Qualidade! Uma palavra inserida no dia a dia de cada um de ns. Mas o que , exatamente?

Qualidade um termo subjetivo que pode ser atribudo a varias situaes ou condies. Podemos atribuir qualidade
natureza, ao talento, ao produto, preciso em inmeras situaes.

Quando somos clientes ou consumidores mais fcil evidenciar a subjetividade da Qualidade, pois neste momento
unem-se necessidades, expectativas e percepes. Quando estamos do lado do fabricante, do produtor, do fornecedor
de servios, a Qualidade o resultado de um padro, de algo que tem de ser produzido de forma clara e objetiva.

Se compararmos estes dois lados, o de empresa ou fornecedor de servios e cliente, a Qualidade a traduo da razo
(seres racionais propem explicaes para causa e efeito) e emoo (experincia subjetiva associada a temperamento,
personalidade e motivao).

Idealmente, para fornecer o melhor custo-benefcio, a maior ou melhor qualidade, precisamos identificar qual a
expectativa do cliente para criarmos padres que vo resultar em nveis de servio que promovem uma boa
experincia ao cliente.

H empresas que geram experincias que entendem que sejam as melhores, as que promovero a melhor
qualidade, sem ouvir seu cliente ou consumidor. Mas tambm h empresas que ouvem seu cliente e consumidor,
estabelecem padres de servios para entregar nveis que se adequem a expectativa para produzir uma experincia
nica.

Traduzir estes caminhos e relaes em quatro eixos que resumem os pontos de vista de clientes e empresas nos
permite indicar o mtodo de pesquisa mais adequado para auxiliar as companhias a direcionarem e otimizarem suas
aes.

Para apoiar a traduo dos eixos que compem esses pontos de vista muito importante uma metodologia de
pesquisa que se adeque a cada um dos quadrantes.

- Estudos qualitativos, conduzidos atravs de grupos focais ou entrevistas em profundidade, so tcnicas que se
adaptam muito bem e permitem compreender a Qualidade esperada pelo cliente;

4Lindemeyer, Rafael Peres. A Importncia da qualidade para os clientes e para a empresa. CIO Magazine Brasil Opinio: 22 de
outubro de outubro de 2014. http://cio.com.br/opiniao/2014/10/22/a-importancia-da-qualidade-para-os-clientes-e-para-a-
empresa/

8
- Qual a experincia de compra ideal? Qual a Qualidade desejada? possvel responder a estas perguntas e
proporcionar a melhor jornada de compra para cliente, identificando pontos chave que podem ser o caminho para o
sucesso ou o fracasso dessa experincia. Para isto acontecer muito importante que a prpria empresa repense e
avalie qual a jornada que quer promover ao cliente. E o cliente? No pode esquecer-se dele, portanto muito
importante confrontar o que a empresa quer promover e o que o cliente deseja;

- Padres so estabelecidos para gerar nveis de servio e a Qualidade produzida neste caso algo que no pode ser
aferido de forma subjetiva. Para este quadrante o melhor caminho colocar o cliente comum como centro. Ele ser o
porta-voz e ir mensurar se os padres esto sendo cumpridos.

- Para fechar o ciclo de Qualidade percebida, ouvir o cliente a chance de compreender se todo desenvolvimento para
proporcionar a melhor experincia de compra, de fato est sendo entregue. Importante nessa etapa fazer a avaliao
sobre a experincia vivenciada o mais prximo possvel do tempo real, dando a chance para a empresa reverter
situaes desagradveis para o cliente sem permitir que tomem grandes propores, que reverberem entre outros
clientes ou futuros clientes e que permita que o consumidor perceba que a empresa, alm de preocupar-se com ele,
age para ajustar falhas possveis em todo processo e rpido.

Qualidade algo que ouvimos e vivenciamos a todo momento. Ter um canal aberto e vivo entre empresa e cliente o
melhor caminho para melhorar a experincia de compra e para que amanh, o que entregamos hoje e foi bom seja
uma experincia melhor ainda para o cliente. Ouvir o cliente , com certeza, um bom caminho para mensurar e
melhorar a Qualidade do servio das empresas.

(* ) Rafael Peres Lindemeyer Research Director da Ipsos Loyalty & Mystery Shopping

Vous aimerez peut-être aussi