Uma questão de percepção
Enviado em 15 de Novembro de 2007
Publicado por Felipe Rodrigues | Enviar por e-mail
| Hits para esta publicação: 587
Nesta semana, comecei a questionar a qualidade do serviço que presto a meus clientes.
A primeira coisa que me veio à cabeça foi questionar a cultura das empresas que me contratam, com o objetivo de justificar a não utilização de conceitos que julgo de extrema importância, por exemplo Scrum e XP (meus processos favoritos) ou mesmo DDD (Domain Driven Design). Cheguei a seguinte conclusão:
Gerentes de projeto muito apegados e acomodados em seus cargos tem dificuldade de inovar e permitir que seus projetos fluam por vertentes mais produtivas. A cultura tradicional embutida na forma de desenvolver software está presente na maioria das empresas. E na maioria dos casos está fora de nossas mãos resolver essa situação.
Falta na maioria das empresas a iniciativa de busca por constante atualização e incentivo ao aprimoramento de seus profissionais. O profissional de informática tem por natureza o desejo de trabalhar sempre com tecnologias novas e conceitos revolucionários. Isso gera certo desconforto para os desenvolvedores, que são “obrigados” a enfrentar dificuldades desnecessárias no dia-a-dia, fruto do uso de tecnologias defasadas ou mesmo arcaicas.
Se por um lado isso é ruim, por outro é completamente compreensível, pois imagine a si mesmo como o responsável por um sistema crítico que movimento informações vitais para o negócio em questão. A confiabilidade exigida da tecnologia a ser utilizada é de extrema importância. Outro fator a ser ponderado é o dead-line do projeto. Prazos curtos inviabilizam a adoção de novidades devido à curva de aprendizado exigida.
Vejo isso como constante causa de insatisfação no relacionamento cliente/fornecedor (contratado / contratante), pois a expectativa do cliente não foi compreendida pelo fornecedor.
Na opinião do Dr. PhD Daivd H. Maister, uma das maiores autoridades sobre administração de empresas de serviços no mundo e autor de livros como “Managing the Professional Service Firm” e “True Professionalism” diz que a satisfação de um cliente pode ser medida através do que ele chama de “A Primeira Lei do Serviço”, expressa através da seguinte fórmula: “SATISFAÇÃO = PERCEPÇÃO – EXPECTATIVA”.
Entendo dessa forma que a satisfação de nossos clientes e empregadores é resultado da percepção que conseguimos estimular menos a expectativa (pode-se entender também como objetivo) sob a qual fomos contratados.
Para desenvolver software com qualidade, é necessário entender a real necessidade e principalmente a expectativa do cliente. De nada nos adianta sermos bons no que fazemos ou mesmo empregar muito bem os novos conceitos e tecnologias se não tivermos sempre em mente o objetivo do sistema e a expectativa em torno dele. A velha premissa de que o cliente tem sempre razão continua valendo mesmo para caso onde o tradicionalismo é mais forte que a inovação.
Uma boa notícia é que dispomos das metodologias ágeis que nos oferecem uma forma mais próxima para entender o cliente e assim conseguir atingir a satisfação mais facilmente. Mas como fazer o cliente entender os benefícios de uma metodologia ágil? Aí é uma outra questão. Acredito que uma conversa focada em satisfação, com flexibilidade e mentes abertas como sugerido neste artigo possa ser de grande valia nesse sentido.
Outro ponto importantíssimo para estimular a percepção do cliente é uso de “Software Visualization”, que consiste em uma imagem geral do sistema. Como um mapa da complexidade do sistema e como ele se comporta em relação ao negócio (domain) do cliente. Podemos assim demonstrar mais facilmente como foi implementado o que o cliente pediu e também mostrar benefícios antes ocultos aos olhos do cliente, como detalhes de flexibilidade na arquitetura. Isso é estimular a percepção do cliente.
Mas e quando se trata de uma migração ou mesmo de uma pequena alteração no sistema? Bom nesse caso o conceito de Software Visualization também se aplica, mas na forma de arqueologia arquitetural, levantando toda a arquitetura do sistema antes de implementar as alterações, possibilitando a participação do cliente na tomada de decisão sobre como o serviço deverá ser realizado.
Em resumo, devemos partir sempre da premissa de que “Um bom trabalho executado, não significa um bom serviço prestado.” E nós, como fornecedores ou como clientes, como contratados ou mesmo contratantes devemos sempre lembrar dessa premissa, para que possamos executar serviços cada vez com maior qualidade, mas também poder avaliar de forma justa e eficaz os serviços que nos são prestados.
Olá Felipe,
Muito interessante o texto… acredito tb que qto maior a expectativa de nossos clientes, tanto maior será a decepção ao não receberem o esperado, numa relação inversamente proporcional…
Métodos Ágeis tentam diminuir o tempo entre solicitação e entrega, de forma a diminuir a expectativa do cliente e mantê-lo num estado mais contínuo de satisfação…
já escrevi um pouco sobre isso também em: http://malditacomedia.blogspot.com/2007/10/entre-expectativa-e-satisfao.html
Achei muito boa a analogia que você fez em relação à conquista de uma mulher. Repare que não basta ser um bom namorado, você tem que deixar bem claro e evidente que você é um bom namorado, através de romantismo e paixão. Como dizem, as pessoas só percebem o que perderam depois que perdem. Mas a idéia é sempre disponibilizar uma forma para que percebam o melhor do que a gente oferece.
=) é isso ai!
Não consegui ler o artigo do Victor, mas um problema que enfrento e que acredito ser da maioria é que em uma empresa relativamente grande é mais complicado você tentar inovar, se o cliente for grande e não sendo seu único fornecedore a dificuldade triplica.
O jeito é tentar ir adotando idéias/tecnologias aos poucos… Processo lento, muito lento.
[…] Esse é um exmplo simples, mas com esse tipo de notação pode-se expressar processos de negócio complexos, o que ajuda muito na visualização do domain. É importante observar que nesta notação bem simples, temos todos os conceitos explicitos. Isso nos dá o gancho para o próximo item que é a criação de uma linguagem comum para o time. […]