Projetista, Surpreenda seu Cliente!

Prof. Especialista José Mauricio Santos Pinheiro em 10/07/2008

Demonstrar simpatia, interesse, ser gentil; juntar a isso conhecimento técnico e postura profissional. Estas são atitudes básicas que um projetista de redes deve demonstrar naturalmente quando entrevista um cliente com o objetivo de elaborar um novo projeto ou a melhoria de uma rede de comunicação. Infelizmente, na maioria das vezes isso não ocorre por uma série de fatores.

Um dos principais motivos é a falta de qualificação (ou treinamento) desse profissional no momento de lidar com as pessoas, fato que pode, inclusive, levar a não concretização do negócio.

Iniciando o Projeto...

De um modo geral, os bons projetos são muito semelhantes em termos de custos, benefícios e recursos. Para que seja viável, um projeto deve prover benefícios que excedam os seus custos e não deve vincular custos que excedam os recursos disponíveis. Assim, o diferencial passa a ser o profissional que oferta o serviço ao cliente. Inovar nos serviços e no atendimento é oferecer algo que o cliente não espera receber de um técnico, um especialista. Encantar o cliente é um objetivo comum, mas surpreender é um diferencial a ser alcançado.

Dentro de uma equipe de projeto podemos encontrar pessoas com habilidade natural para desempenhar atividades comerciais, outras precisam ser treinadas e outras, definitivamente, que não levam jeito nenhum para esse tipo de atividade. Neste contexto, treinar não significa adestrar, o que leva as pessoas a fazer suas atividades por repetição, sem entender a essência do que estão fazendo. O treinamento que é eficaz nos leva a modificar nossas atitudes e nos torna mais produtivos.

Também é importante agregar valor ao que se faz. Apostar sempre na qualidade, pois participar de um projeto de alto nível é valorizar-se profissionalmente e uma forma de atrair novos clientes. O cliente, por sinal, não anuncia quando vai aparecer, mas a equipe deve estar preparada para recebê-lo. Um cliente requer atenção e a equipe deve deixar bem claro que tem disponibilidade para atendê-lo. Este simples ato traduz para o cliente a satisfação em tê-lo ali, naquele momento e que a equipe está empenhada em fazer tudo o que estiver ao seu alcance para satisfazê-lo em suas necessidades. É importante ser receptivo, demonstrar cortesia e bom humor naturalmente. Lembre-se sempre: a primeira impressão é a que fica.

Não há uma fórmula mágica para atender um cliente. Todas as técnicas enfatizam que é necessário ter flexibilidade para mudar a qualquer momento, conforme as diferentes faixas etárias, sociais, econômicas e culturais das pessoas que chegam até o escritório de projetos. Fazer questionamentos que agilizem o atendimento ajudam a apresentar mais rapidamente uma solução que atenda às necessidades desse cliente.

Ao atender seu cliente, esqueça perguntas tradicionais como "em que posso ajudar?". Um cliente não entra no escritório de projetos para obter ajuda, ele entra para ter uma necessidade atendida ou mesmo apenas para se informar, pesquisar novas tecnologias, novas tendências. Ainda que o cliente não saiba exatamente o que quer, com certeza ele sabe o que não quer. Nesse momento, um profissional bem preparado e treinado será capaz de informar sobre o que acontece no mundo das redes de comunicação, orientando-o quanto ao que mais é adequado ao seu negócio. Isso é o que se chama assessoria, não ajuda.

Executando o Projeto...

Na fase inicial do projeto, também conhecida como fase conceitual, temos a identificação de necessidades do cliente, o estabelecimento da viabilidade técnica, a busca por alternativas tecnológicas, preparação das propostas, desenvolvimento de orçamentos, os cronogramas iniciais e a nomeação da equipe, entre outras atividades. Nessa etapa, uma questão importante é interagir com o cliente para conhecer suas expectativas e combinar como serão tratadas as trocas de informações sobre o projeto. A comunicação adequada entre as partes envolvidas no projeto é fator fundamental para seu sucesso e exige o uso de instrumentos adequados. Neste momento, é fundamental cuidar tanto da distribuição de informações sobre o andamento do projeto e de seus resultados, como garantir que houve comunicação efetiva entre os envolvidos.

Um projeto pode estar condenado ao fracasso mesmo antes de ser iniciado se não resultar em vantagens e melhorias práticas para as aplicações a que se destina. Afinal, o cliente espera soluções, de preferência econômicas, para seus problemas e não apenas paliativos. Na vida real, a grande maioria dos projetos enfrenta a situação de ter mais oportunidades de gastar os recursos disponíveis do que recursos disponíveis para gastar. Por esse motivo, a utilização

dos recursos deve ser cuidadosamente planejada, junto com o cliente, a fim de que se possam avaliar as vantagens e os benefícios obtidos sobre os custos.

Os procedimentos para a execução do projeto são sistematizados e devem surgir de uma visão estratégica e objetiva da realidade do cliente, assim como a organização e coordenação das ações a serem desencadeadas. Neste ponto, as informações obtidas através do cliente facilitam o entendimento do escopo do projeto e a elaboração da topologia da rede, dentro da diversidade de hardware e software disponível. Observar que o projetista deve indicar as melhores opções, sugerir soluções, mas não insistir com o cliente ao ponto de tornar-se impertinente.

Não julgar um cliente pelas aparências (embora ele o faça). Um projetista não precisa gostar do cliente, mas deve evitar atritos com ele. Se verificar que está difícil o entendimento, deve pedir ao colega da equipe para substituí-lo, passando-lhe as informações mais importantes sobre o que já foi conversado. Essas informações devem incluir um conjunto de requisitos e critérios baseados em especificações técnicas (funcionais, operacionais e construtivas) que devem ser satisfeitas para que o projeto atenda as necessidades do cliente.

Muitas vezes o cliente não tem o conhecimento técnico necessário para interagir com a equipe, mas o projetista não deve deixar transparecer que sabe disso. Há técnicas que ajudam a resolver os momentos de discordância, como o uso de expressões do tipo "eu entendo perfeitamente", ou "com certeza". O profissional deve mostrar-se solidário com as dificuldades e necessidades do cliente, inclusive quando ele emitir uma opinião contrária a algo que afete o bom andamento do projeto. Esta postura ajuda a minimizar os problemas do dia-a-dia e a evitar outros que possam ocorrer.

Um projetista deve conhecer o mix de equipamentos, aplicativos e serviços disponíveis no mercado e saber diferenciá-los em termos de aplicações, possibilidades de combinação, assistência técnica, entre outros a fim de orientar o cliente e esclarecer suas dúvidas quanto a diferenças nos preços praticados entre fabricantes de equipamentos similares, sistemas operacionais, etc. Sintonia de ações é uma condição determinante nesse momento para o sucesso da abordagem com o cliente.

Concluindo o Projeto...

Interessante notar que, quando uma pessoa reclama de alguma falha no atendimento, é porque tem intenção de continuar o trabalho com aquela equipe. Por mais difícil que seja, deve-se ouvir a reclamação com atenção, pois nesse momento há a oportunidade de corrigir uma falha, um erro cometido e jamais deve-se deixar o cliente sem retorno, mesmo que seja negativo. Contribuições espontâneas nesse momento podem dar origem a mudanças produtivas para o atendimento aos novos clientes e, consequentemente, aos novos projetos.

Tenha sempre em mente a disposição de superar as expectativas do cliente. Isto fará a diferença, a seu favor, em relação aos concorrentes. A eventual alteração do escopo do projeto porque foi detectado um erro de avaliação ou uma falha de execução, por exemplo, pode ser mais um fator de fidelização do cliente. Com essa atitude, ele não terá dúvidas da seriedade dos profissionais que contratou.

Para surpreender o cliente existem várias receitas. O que não muda são os ingredientes: bom humor, cortesia, atenção, disponibilidade, responsabilidade, preparação da equipe, treinamento e outros que podem ser adicionados. A preocupação com as melhorias nos processos deve ser constante e os investimentos redirecionados tantas vezes quantas forem necessárias.

Referências Bibliográficas

FLORES, Maria de Fátima M. Surpreenda o cliente. Revista da ABLAC, n. 08, pg 22-26, jan. 2008. PINHEIRO, José Maurício S. Viabilidade de Projetos. Apostila de Projeto e Construção de Redes. UniFOA, 2008. WILLE, Silvio Aurélio de C. Gerenciamento das Comunicações no Projeto. Revista FAE BUSINESS, n.7, pg 28-31, nov. 2003.

SEÇÃO | FALANDO DE PROJETOS

Mundo Project Management Junho/Julho 2011 mundopm.com.br

Falhas em projetos

Hélio Rodrigues Costa é subdiretor de projetos da Diretoria de Tecnologia da Informação da Aeronáutica e professor dos MBA de Gerenciamento de Projetos da FGV.email: falandodeprojetos@mundopm.com.br

Projetos falham! Isso é um fato. Al-guns até conseguem atingir, parcialmente, seus objetivos, mas benchmarkings nacio-nais e mundiais apontam para números assustadores. Causas para essas falhas são incontáveis e estão listadas nas pesquisas e nos livros de gerenciamento de projetos.

Em minhas aulas e consultorias, tenho ouvido muitas pessoas falarem que atual-mente as chances de se alcançar os objeti-vos definidos em um projeto são menores que há algum tempo, pois o contexto, a complexidade e a pressão por bons resul-tados com cronogramas e orçamentos cada vez mais apertados, provocam uma série falhas que, na maioria das vezes, levam os projetos a resultados pouco satisfatórios.

Não concordo muito com essa descul-pa e, sempre que posso, conto a história do navio sueco Vasa (pronuncia-se como Vas-sa), que em sua viagem de estreia partiu do porto de Estocolmo em 10 de agosto de 1628 e, após navegar por 1.300 metros e ser atingido por uma leve brisa (cerca de oito nós), naufragou ceifando a vida de 53 pessoas e levando para o fundo do mar o maior e mais caro navio de guerra até en-tão construído no mundo. A situação foi agravada pelo fato de a Suécia estar em guerra com a Polônia e precisar do referido navio para seu esforço de combate.

Os fatos que se seguem foram reti-rados de sites, folders e documentos que contam a história do Vasa e qualquer se-

melhança com os projetos que realizamos atualmente é mera coincidência.

Em 16 de janeiro de 1625 o rei sueco Gustav II designou o almirante Fleming para desenhar e construir junto com Hen-rik e Arend Hybertsson quatro navios. Henrik era um construtor de navios e Arend algo como um gerente de negócios. O Projeto foi subcontratado para Johan Is-brandsson, que se comprometeu a entre-gar os navios em quatro anos. Dois navios teriam 108 pés e os outros dois, 135 pés (bela estimativa de prazo).

Após uma série de mudanças não jus-tificadas de requisitos por parte do rei, os construtores solicitaram autorização para o corte de madeira da floresta real para que os navios fossem construídos. Em setem-bro, a marinha sueca sofreu uma perda de dez navios durante uma tempestade e o rei ordenou que os navios menores fos-sem construídos primeiro e em um ritmo mais acelerado para tentar repor as perdas. Dessa forma, em janeiro de 1626 (um ano depois) a construção do Vasa teve início, já que era um dos navios menores. No entan-to, o rei solicitou que o tamanho dos navios fosse alterado para 120 pés e que fossem capazes de carregar 32 canhões com peso aproximado de 3.000 libras cada um (mu-dança de requisitos... só se for na Suécia, pois aqui não acontece).

Henrik (o construtor) resolveu fazer um inventário para saber quanto material possuía e descobriu que só tinha recursos

para construir um navio de 111 pés e outro de 135 pés (111 pés? De onde veio essa espe-cificação?). No entanto, nem os construto-res nem o almirante queriam dar a notícia ao rei (quem gostaria de fazer isso? Ele era o rei e tinha seu requisitos “claramente” definidos).

Nesse momento, o rei descobriu que a Dinamarca estava construindo um grande navio com dois decks de canhões e não gos-taria de ficar para trás. Rapidamente deu a ordem para que o projeto do Vasa fosse alterado para 135 pés e que o navio possu-ísse dois decks de canhões. (Clientes... são todos iguais). O detalhe é que ninguém na Suécia jamais havia construído navios as-sim. (Novas tecnologias).

Após uma rápida análise, os constru-tores decidiram que aumentar o navio ini-cialmente previsto para 111 pés seria mais rápido que começar a construir um novo navio, pois estavam atrasados no crono-grama e sendo pressionados pelo rei (cro-nograma apertado e pressão do sponsor interferindo nos requisitos técnicos). Vale ressaltar que nunca se encontrou um de-senho ou planta do navio e, segundo his-toriadores, é muito pouco provável que al-guém tenha gasto um único dia levantando requisitos ou preparando documentações, pois a pressão exercida pelo rei era muito grande em relação ao prazo (mais uma vez repito. Isso só acontece na Suécia).

Mundo Project Management Junho/Julho 2011 mundopm.com.br

Em função da rápida adaptação ne-cessária, descobriu-se, mais tarde, que a quilha construída era muito estreita e pe-quena em relação ao tamanho do navio, pois foi aproveitada do navio de menor tamanho. A quilha é a parte inferior de um barco e se estende, de forma geral, de sua proa à sua popa e é usada para permitir curvas e reforçar o fundo. Essa e outras adaptações alteraram profun-damente o centro de gravidade do navio (até minha avó sabe que a estabilidade de um navio é muito dependente do cen-tro de gravidade). Além disso, descobriu-se, na preparação para a partida do navio, que os porões não possuíam tamanho su-ficiente para receber o lastro necessário para estabilizar o barco (já viu aonde isso vai parar?).

A história dos canhões só não é hilária porque é triste. Dos 32 canhões iniciais. O rei alterou o requisito três vezes até que a especificação final foi que se instalasse 32 canhões em cada deck e mais uma série de pequenos canhões. A instalação de 32 canhões no deck superior levou o centro de gravidade mais para cima, provocando mais instabilidade. Ao final só foram ins-talados 24 canhões em cada deck, pois não havia espaço suficiente para se carregar munição para tantos canhões (que bela integração). Só para complementar, relatos da época comentam que os canhões foram construídos tão rapidamente que eram de péssima qualidade e, provavelmente, ex-plodiriam na primeira batalha (mais pres-são do cronograma).

O rei queria que o navio impressio-nasse a marinha dinamarquesa e pediu a artesãos que construíssem ornamentos com motivos bíblicos e mitológicos fei-tos de carvalho em torno de todo o navio. Nenhum cálculo estrutural foi feito para a instalação desses ornamentos, mas com

certeza alteraram o centro de gravidade, pois estavam na parte de cima do navio (ninguém merece!).

Em 1627 o construtor Henrik fale-ceu, levando para o túmulo tudo o que sabia sobre o navio, pois não havia nada escrito ou planos documentados. Isso le-vou a sérias dúvidas sobre o que era para ser feito e como deveria ser implemen-tado. Cada um sabia apenas a sua parte (se é que sabiam). Isso obviamente fez com que o cronograma fosse atrasado. Nesse momento, entra em cena Hein Ja-cobsson, ex-assistente de Henrik, que foi designado pelo almirante Fleming como novo gerente do projeto (que furada! Tudo errado, nenhuma documentação, atrasado e pressionado pelo rei).

Após muito trabalho envolvendo 400 homens e uma incomensurável soma de dinheiro, o Vasa estava pronto para seu primeiro teste de estabilidade, que foi feito da seguinte forma: 30 homens corriam de um lado para outro do bar-co (controle de qualidade fantástico). Após três corridas, o teste foi interrom-pido, pois logo se percebeu que se não fosse interrompido o barco iria capotar. Descobriu-se mais tarde que o Vasa foi construído para carregar 120 tonela-das de lastro e que o correto seria levar 200 toneladas para ter estabilidade. No entanto, existiam dois problemas: não havia espaço para tanto lastro e se todo esse lastro fosse instalado, o deck mais baixo de canhões ficaria abaixo do nível da água (planejamento fantástico).

Nenhum dos responsáveis pela cons-trução do navio estava presente, com ex-ceção do almirante Fleming, que resolveu não revelar o resultado dos testes para nin-guém, especialmente ao rei, que no mo-mento estava em uma batalha na Polônia.

Afinal, ninguém tinha uma boa ideia para aumentar a estabilidade do navio e já não havia tempo para modificações (muito éti-co esse almirante).

O ano já era 1628 e Gustav II determi-nou que o lançamento fosse no dia 25 de julho e os responsáveis por atrasos fica-riam sujeitos à desgraça do rei (isso é que é pressão). Finalmente, com duas semanas de atraso, no dia 10 de agosto, e com todos os problemas de instabilidade, o Vasa esta-va “pronto” e foi lançado ao mar com toda a pompa e circunstância. O final da história, o leitor já sabe.

Alguns erros clássicos podem ser ex-traídos dessa história e são eles:

1) Excessiva pressão do cronograma, levando a erros inaceitáveis;2) Mudanças de requisitos constantes;3) Falta de especificação técnica;4) Falta de documentação do projeto;5) Inovações tecnológicas sem capacidade técnica de serem implementadas;6) Ausência de métodos científicos para testes;7) Ignorar o óbvio diante de situações críticas; e8) Falta de ética.

Como falei no início do texto, qualquer semelhança com os dias atuais é pura coin-cidência, mas parece que nossos proble-mas em projetos ainda vão continuar por muito tempo.

Em 1961, 333 anos após ter afun-dado, o Vasa foi içado, praticamente intacto, do fundo da baía de Estocol-mo O navio foi totalmente reformado e encontra-se exposto no Museu Vasa (www.vasamuseet.se), construído pró-ximo do local onde naufragou. Vale a pena a visita. Eu garanto.