Prestar serviços, ou da mesma forma, gerenciar projetos com qualidade, ainda será uma tarefa árdua por um bom tempo no Brasil, especialmente pela questão cultural. Tradicionalmente valorizamos muito mais os bens físicos do que os chamados serviços agregados a eles. Reflexo da revolução industrial na criação de nossos antepassados, que valorizou muito mais “produtos” do que serviços, ainda hoje sentimos dificuldade para enxergar claramente as características desejáveis de uma boa prestação de serviços.
Por incrível que pareça, em relação a bens materiais, conseguimos avaliar quase “intuitivamente” várias características como design, qualidade e até preço. Cabe, contudo, destacar que não existe característica (produto e serviço de entrega) mais importante. Ambas merecem cuidados adicionais e equivalentes para a plena satisfação do cliente.
Se transportarmos isso para o mundo da Tecnologia da Informação vamos acrescentar um componente ainda mais complexo, a “intangibilidade tecnológica” dos mesmos (quem de nós consegue explicar com facilidade para um CEO ou diretor financeiro por que devemos investir em Storage ou Web Services?). Se temos dificuldade para entender aspectos objetivos da prestação de serviços, o que diremos de conhecimento tecnológico e científico.
Mas como resolver ou contornar esta questão?
De acordo com Christian Grönroos, no livro “Marketing: Gerenciamento de Serviços”, a qualidade de um serviço tem duas dimensões: uma dimensão ou resultado técnico e uma dimensão funcional ou relacionada ao processo. Em projetos de TI distinguimos isso pela especificação do que será entregue (técnico) e o como isso será colocado em funcionamento (serviço ou projeto de implantação). No dia-a-dia encontramos diversos exemplos de projetos que entregaram exatamente o que o Cliente esperava tecnicamente (ou pelo menos próximo a isso), mas que deixaram-no totalmente insatisfeito com o processo adotado (atrasos, desgastes de relacionamento, custos fora de controle etc.). Ou seja, nos preocupamos excessivamente com o que vai ser entregue e não nos preocupamos com o “como iremos proceder”.
As duas dimensões estão totalmente relacionadas e desconsiderar uma ou outra certamente ocasionará um impacto negativo, seja ele financeiro ou de credibilidade, para o cliente e para o prestador de serviço.
O cuidado com o chamado escopo é fartamente discutido em diversos âmbitos. Contudo, algo escapa do gestor do projeto (prestador de serviços) pela natureza da atividade gerencial (e não técnica): existem dois escopos distintos mas intimamente relacionados. “Escopo do produto” (1), isto é, as características ou funções que definem o produto ou serviço a ser entregue; e o “escopo do projeto” (2), isto é, o trabalho que deve ser realizado para gerar o produto ou serviço dentro das características e funções especificadas. Ou seja, mais uma vez destaca-se a importância de especificarmos claramente ambas as características, o que deve ser entregue e como será entregue, para obtermos a satisfação plena do cliente.
A média dos profissionais de mercado ainda não percebeu a distinção disso. A grande maioria ainda confunde o “serviço ou produto a ser implantado (entregue)”, com a forma como isso será colocado em funcionamento.
Um exemplo: em projetos de implantação de hardware discute-se sobre as características técnicas de um determinado harwdware (servidores, switches, storage) mas muito pouco sobre como colocá-lo em funcionamento e quais as habilidades exigidas para tal (gerando custos e prazos não planejados). Outro exemplo: inversamente, em projetos de implantação de ERP se discute muito sobre prazos e atividades envolvidos, mas relativamente pouco sobre adequação (aderência) dos processos a realidade do Cliente (gerando “gaps” no momento da entrada do sistema em funcionamento e conseqüentes desgastes com o cliente).
A questão exige cuidado, pois mesmo especialistas em entrega de “projetos” como o PMI (Project Management Institute) não têm tecnologia própria para intervir na natureza da especificação do escopo do produto e, isso, diversas vezes “escapa” do controle do gerente de projeto que com alguma freqüência não tem conhecimento técnico para discernir sobre a qualidade da especificação do mesmo. Cabe portanto, dentro do contexto do projeto, uma preocupação adicional por parte do gerente de projeto em aprovar da melhor forma possível o escopo do produto, já que executar perfeitamente, mas entregar de forma imperfeita, ou vice-versa.
Um dos aspectos mais críticos, tanto no escopo do projeto, quanto no escopo do produto, é a clareza na linguagem com a qual nos comunicamos com os nossos clientes. Há alguns anos recebi uma reclamação muito intrigante de um cliente, sobre o grau de detalhe de nossas propostas, “suas propostas são detalhadas demais. Não li completamente suas especificações e, portanto, não recebi exatamente o que queria. Vocês deveriam ter explicado isso melhor!”.
Veja bem, o cliente tem razão. Ele não pode ficar lendo detalhes sem importância, como também não pode ficar sem os detalhes importantes (principalmente se não houver um especialista ao seu lado). O fato é que o ponto exato do detalhamento dependente muito de dois aspectos: (a) o segmento de negócio ou produto que se comercializa e (b) o nível do cliente envolvido na negociação. Por isso mesmo, ainda teremos de adotar um procedimento de personalização (e segurança) em todos os contatos que fazemos com os clientes.
Ainda que o tema seja complexo e exija um estudo mais profundo para cada caso, algumas dicas práticas podem ajudar “muito”: (1) ouvir tudo que o Cliente tem a dizer sem interrompê-lo; (2) nos esforçarmos para entender o que querem, anotando tudo; e (3) nos esforçarmos para que ouçam atentamente nossa interpretação de suas necessidades, antes de assinarem o contrato. Sem isso, todo esforço feito para satisfazer o cliente fica no limite do obscuro. Além disso, o cuidado em registrar formalmente todas as alterações solicitadas pelo cliente nas especificações é essencial para que o mesmo, no final, tenha ciência dos reflexos dessas mudanças, não responsabilizando exclusivamente o fornecedor.
A satisfação do cliente não está ligada somente a aspectos inerentes ao produto, mas também ao processo com o qual será produzido e entregue. Acima disso, devemos nos esforçar ao máximo para entender e interpretar o nível de detalhe que cada cliente deseja trabalhar e oferecer exatamente (ou próximo a isso) especificações legíveis que descrevam o produto e o projeto (serviço), que será utilizado para entregar o que foi pedido. Obviamente, caso seja necessário um processo mais detalhado na execução, documentos e orientações adicionais podem ser utilizados. Contudo, usar técnicas sem envolver o cliente não é uma forma eficiente de atingir o sucesso.
O preço de uma falha nesses cuidados (especificação do escopo do produto e do projeto, assim como o envolvimento por parte do cliente) é o desperdício do esforço de todo um time ou empresa. O prêmio de se especificar com clareza (do ponto-de-vista do cliente) e controlar as alterações no produto e no processo de produção é a economia de recursos e a natural satisfação do cliente.
Cléber Augusto Piçarro é diretor de Serviços da RM Sistemas
