Projetista, Surpreenda seu Cliente!

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

Demonstrar simpatia, interesse, ser gentil; juntar a isso conhecimento tcnico e postura profissional. Estas so atitudes
bsicas 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 comunicao. Infelizmente, na maioria das vezes isso no
ocorre por uma srie de fatores.
Um dos principais motivos a falta de qualificao (ou treinamento) desse profissional no momento de lidar com as
pessoas, fato que pode, inclusive, levar a no concretizao do negcio.
Iniciando o Projeto...
De um modo geral, os bons projetos so muito semelhantes em termos de custos, benefcios e recursos. Para que seja
vivel, um projeto deve prover benefcios que excedam os seus custos e no deve vincular custos que excedam os
recursos disponveis. Assim, o diferencial passa a ser o profissional que oferta o servio ao cliente. Inovar nos servios e
no atendimento oferecer algo que o cliente no espera receber de um tcnico, um especialista. Encantar o cliente um
objetivo comum, mas surpreender um diferencial a ser alcanado.
Dentro de uma equipe de projeto podemos encontrar pessoas com habilidade natural para desempenhar atividades
comerciais, outras precisam ser treinadas e outras, definitivamente, que no levam jeito nenhum para esse tipo de
atividade. Neste contexto, treinar no significa adestrar, o que leva as pessoas a fazer suas atividades por repetio,
sem entender a essncia do que esto fazendo. O treinamento que eficaz nos leva a modificar nossas atitudes e nos
torna mais produtivos.
Tambm importante agregar valor ao que se faz. Apostar sempre na qualidade, pois participar de um projeto de alto
nvel valorizar-se profissionalmente e uma forma de atrair novos clientes. O cliente, por sinal, no anuncia quando vai
aparecer, mas a equipe deve estar preparada para receb-lo. Um cliente requer ateno e a equipe deve deixar bem
claro que tem disponibilidade para atend-lo. Este simples ato traduz para o cliente a satisfao 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 impresso a que fica.
No h uma frmula mgica para atender um cliente. Todas as tcnicas enfatizam que necessrio ter flexibilidade para
mudar a qualquer momento, conforme as diferentes faixas etrias, sociais, econmicas e culturais das pessoas que
chegam at o escritrio de projetos. Fazer questionamentos que agilizem o atendimento ajudam a apresentar mais
rapidamente uma soluo que atenda s necessidades desse cliente.
Ao atender seu cliente, esquea perguntas tradicionais como "em que posso ajudar?". Um cliente no entra no escritrio
de projetos para obter ajuda, ele entra para ter uma necessidade atendida ou mesmo apenas para se informar,
pesquisar novas tecnologias, novas tendncias. Ainda que o cliente no saiba exatamente o que quer, com certeza ele
sabe o que no quer. Nesse momento, um profissional bem preparado e treinado ser capaz de informar sobre o que
acontece no mundo das redes de comunicao, orientando-o quanto ao que mais adequado ao seu negcio. Isso o
que se chama assessoria, no ajuda.
Executando o Projeto...
Na fase inicial do projeto, tambm conhecida como fase conceitual, temos a identificao de necessidades do cliente, o
estabelecimento da viabilidade tcnica, a busca por alternativas tecnolgicas, preparao das propostas,
desenvolvimento de oramentos, os cronogramas iniciais e a nomeao da equipe, entre outras atividades. Nessa etapa,
uma questo importante interagir com o cliente para conhecer suas expectativas e combinar como sero tratadas as
trocas de informaes sobre o projeto. A comunicao 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 distribuio de informaes sobre o andamento do projeto e de seus resultados, como garantir que houve
comunicao efetiva entre os envolvidos.
Um projeto pode estar condenado ao fracasso mesmo antes de ser iniciado se no resultar em vantagens e melhorias
prticas para as aplicaes a que se destina. Afinal, o cliente espera solues, de preferncia econmicas, para seus
problemas e no apenas paliativos. Na vida real, a grande maioria dos projetos enfrenta a situao de ter mais
oportunidades de gastar os recursos disponveis do que recursos disponveis para gastar. Por esse motivo, a utilizao

dos recursos deve ser cuidadosamente planejada, junto com o cliente, a fim de que se possam avaliar as vantagens e os
benefcios obtidos sobre os custos.
Os procedimentos para a execuo do projeto so sistematizados e devem surgir de uma viso estratgica e objetiva da
realidade do cliente, assim como a organizao e coordenao das aes a serem desencadeadas. Neste ponto, as
informaes obtidas atravs do cliente facilitam o entendimento do escopo do projeto e a elaborao da topologia da
rede, dentro da diversidade de hardware e software disponvel. Observar que o projetista deve indicar as melhores
opes, sugerir solues, mas no insistir com o cliente ao ponto de tornar-se impertinente.
No julgar um cliente pelas aparncias (embora ele o faa). Um projetista no precisa gostar do cliente, mas deve evitar
atritos com ele. Se verificar que est difcil o entendimento, deve pedir ao colega da equipe para substitu-lo, passandolhe as informaes mais importantes sobre o que j foi conversado. Essas informaes devem incluir um conjunto de
requisitos e critrios baseados em especificaes tcnicas (funcionais, operacionais e construtivas) que devem ser
satisfeitas para que o projeto atenda as necessidades do cliente.
Muitas vezes o cliente no tem o conhecimento tcnico necessrio para interagir com a equipe, mas o projetista no
deve deixar transparecer que sabe disso. H tcnicas que ajudam a resolver os momentos de discordncia, como o uso
de expresses do tipo "eu entendo perfeitamente", ou "com certeza". O profissional deve mostrar-se solidrio com as
dificuldades e necessidades do cliente, inclusive quando ele emitir uma opinio contrria 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 servios disponveis no mercado e saber diferencilos em termos de aplicaes, possibilidades de combinao, assistncia tcnica, entre outros a fim de orientar o cliente e
esclarecer suas dvidas quanto a diferenas nos preos praticados entre fabricantes de equipamentos similares,
sistemas operacionais, etc. Sintonia de aes uma condio 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 inteno de
continuar o trabalho com aquela equipe. Por mais difcil que seja, deve-se ouvir a reclamao com ateno, 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. Contribuies espontneas nesse momento podem dar origem a mudanas produtivas para o
atendimento aos novos clientes e, consequentemente, aos novos projetos.
Tenha sempre em mente a disposio de superar as expectativas do cliente. Isto far a diferena, a seu favor, em
relao aos concorrentes. A eventual alterao do escopo do projeto porque foi detectado um erro de avaliao ou uma
falha de execuo, por exemplo, pode ser mais um fator de fidelizao do cliente. Com essa atitude, ele no ter dvidas
da seriedade dos profissionais que contratou.
Para surpreender o cliente existem vrias receitas. O que no muda so os ingredientes: bom humor, cortesia, ateno,
disponibilidade, responsabilidade, preparao da equipe, treinamento e outros que podem ser adicionados. A
preocupao com as melhorias nos processos deve ser constante e os investimentos redirecionados tantas vezes
quantas forem necessrias.
Referncias Bibliogrficas
FLORES, Maria de Ftima M. Surpreenda o cliente. Revista da ABLAC, n. 08, pg 22-26, jan. 2008.
PINHEIRO, Jos Maurcio S. Viabilidade de Projetos. Apostila de Projeto e Construo de Redes. UniFOA, 2008.
WILLE, Silvio Aurlio de C. Gerenciamento das Comunicaes no Projeto. Revista FAE BUSINESS, n.7, pg 28-31, nov.
2003.

SEO | FALANDO DE PROJETOS

Hlio Rodrigues Costa subdiretor de
projetos da Diretoria de Tecnologia da
Informao da Aeronutica e professor dos
MBA de Gerenciamento de Projetos da FGV.
email: falandodeprojetos@mundopm.com.br

Projetos falham! Isso um fato. Alguns at conseguem atingir, parcialmente,

seus objetivos, mas benchmarkings nacionais e mundiais apontam para nmeros
assustadores. Causas para essas falhas so
incontveis e esto listadas nas pesquisas
e nos livros de gerenciamento de projetos.
Em minhas aulas e consultorias, tenho
ouvido muitas pessoas falarem que atualmente as chances de se alcanar os objetivos definidos em um projeto so menores
que h algum tempo, pois o contexto, a
complexidade e a presso por bons resultados com cronogramas e oramentos cada
vez mais apertados, provocam uma srie
falhas que, na maioria das vezes, levam os
projetos a resultados pouco satisfatrios.

Falhas em
projetos

melhana com os projetos que realizamos

atualmente mera coincidncia.
Em 16 de janeiro de 1625 o rei sueco
Gustav II designou o almirante Fleming
para desenhar e construir junto com Henrik e Arend Hybertsson quatro navios.
Henrik era um construtor de navios e
Arend algo como um gerente de negcios.
O Projeto foi subcontratado para Johan Isbrandsson, que se comprometeu a entregar os navios em quatro anos. Dois navios
teriam 108 ps e os outros dois, 135 ps
(bela estimativa de prazo).

No concordo muito com essa desculpa e, sempre que posso, conto a histria do
navio sueco Vasa (pronuncia-se como Vassa), que em sua viagem de estreia partiu
do porto de Estocolmo em 10 de agosto de
1628 e, aps navegar por 1.300 metros e
ser atingido por uma leve brisa (cerca de
oito ns), naufragou ceifando a vida de 53
pessoas e levando para o fundo do mar o
maior e mais caro navio de guerra at ento construdo no mundo. A situao foi
agravada pelo fato de a Sucia estar em
guerra com a Polnia e precisar do referido
navio para seu esforo de combate.

Aps uma srie de mudanas no justificadas de requisitos por parte do rei, os

construtores solicitaram autorizao para o
corte de madeira da floresta real para que
os navios fossem construdos. Em setembro, a marinha sueca sofreu uma perda
de dez navios durante uma tempestade e
o rei ordenou que os navios menores fossem construdos primeiro e em um ritmo
mais acelerado para tentar repor as perdas.
Dessa forma, em janeiro de 1626 (um ano
depois) a construo do Vasa teve incio, j
que era um dos navios menores. No entanto, o rei solicitou que o tamanho dos navios
fosse alterado para 120 ps e que fossem
capazes de carregar 32 canhes com peso
aproximado de 3.000 libras cada um (mudana de requisitos... s se for na Sucia,
pois aqui no acontece).

Os fatos que se seguem foram retirados de sites, folders e documentos que

contam a histria do Vasa e qualquer se-

Henrik (o construtor) resolveu fazer

um inventrio para saber quanto material
possua e descobriu que s tinha recursos

Mundo Project Management

Junho/Julho 2011

mundopm.com.br

para construir um navio de 111 ps e outro

de 135 ps (111 ps? De onde veio essa especificao?). No entanto, nem os construtores nem o almirante queriam dar a notcia
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 canhes e no gostaria de ficar para trs. Rapidamente deu
a ordem para que o projeto do Vasa fosse
alterado para 135 ps e que o navio possusse dois decks de canhes. (Clientes... so
todos iguais). O detalhe que ningum na
Sucia jamais havia construdo navios assim. (Novas tecnologias).
Aps uma rpida anlise, os construtores decidiram que aumentar o navio inicialmente previsto para 111 ps seria mais
rpido que comear a construir um novo
navio, pois estavam atrasados no cronograma e sendo pressionados pelo rei (cronograma apertado e presso do sponsor
interferindo nos requisitos tcnicos). Vale
ressaltar que nunca se encontrou um desenho ou planta do navio e, segundo historiadores, muito pouco provvel que algum tenha gasto um nico dia levantando
requisitos ou preparando documentaes,
pois a presso exercida pelo rei era muito
grande em relao ao prazo (mais uma vez
repito. Isso s acontece na Sucia).

Em funo da rpida adaptao necessria, descobriu-se, mais tarde, que a

quilha construda era muito estreita e pequena em relao 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 reforar o fundo. Essa
e outras adaptaes alteraram profundamente o centro de gravidade do navio
(at minha av sabe que a estabilidade
de um navio muito dependente do centro de gravidade). Alm disso, descobriuse, na preparao para a partida do navio,
que os pores no possuam tamanho suficiente para receber o lastro necessrio
para estabilizar o barco (j viu aonde isso
vai parar?).
A histria dos canhes s no hilria
porque triste. Dos 32 canhes iniciais. O
rei alterou o requisito trs vezes at que a
especificao final foi que se instalasse 32
canhes em cada deck e mais uma srie
de pequenos canhes. A instalao de 32
canhes no deck superior levou o centro
de gravidade mais para cima, provocando
mais instabilidade. Ao final s foram instalados 24 canhes em cada deck, pois no
havia espao suficiente para se carregar
munio para tantos canhes (que bela
integrao). S para complementar, relatos
da poca comentam que os canhes foram
construdos to rapidamente que eram de
pssima qualidade e, provavelmente, explodiriam na primeira batalha (mais presso do cronograma).
O rei queria que o navio impressionasse a marinha dinamarquesa e pediu
a artesos que construssem ornamentos
com motivos bblicos e mitolgicos feitos de carvalho em torno de todo o navio.
Nenhum clculo estrutural foi feito para
a instalao desses ornamentos, mas com

certeza alteraram o centro de gravidade,

pois estavam na parte de cima do navio
(ningum merece!).
Em 1627 o construtor Henrik faleceu, levando para o tmulo tudo o que
sabia sobre o navio, pois no havia nada
escrito ou planos documentados. Isso levou a srias dvidas sobre o que era para
ser feito e como deveria ser implementado. 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 Jacobsson, ex-assistente de Henrik, que foi
designado pelo almirante Fleming como
novo gerente do projeto (que furada!
Tudo errado, nenhuma documentao,
atrasado e pressionado pelo rei).
Aps muito trabalho envolvendo 400
homens e uma incomensurvel 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 barco (controle de qualidade fantstico).
Aps trs corridas, o teste foi interrompido, pois logo se percebeu que se no
fosse interrompido o barco iria capotar.
Descobriu-se mais tarde que o Vasa foi
construdo para carregar 120 toneladas de lastro e que o correto seria levar
200 toneladas para ter estabilidade. No
entanto, existiam dois problemas: no
havia espao para tanto lastro e se todo
esse lastro fosse instalado, o deck mais
baixo de canhes ficaria abaixo do nvel
da gua (planejamento fantstico).
Nenhum dos responsveis pela construo do navio estava presente, com exceo do almirante Fleming, que resolveu
no revelar o resultado dos testes para ningum, especialmente ao rei, que no momento estava em uma batalha na Polnia.

Afinal, ningum tinha uma boa ideia para

aumentar a estabilidade do navio e j no
havia tempo para modificaes (muito tico esse almirante).
O ano j era 1628 e Gustav II determinou que o lanamento fosse no dia 25 de
julho e os responsveis por atrasos ficariam sujeitos desgraa do rei (isso que
presso). Finalmente, com duas semanas
de atraso, no dia 10 de agosto, e com todos
os problemas de instabilidade, o Vasa estava pronto e foi lanado ao mar com toda a
pompa e circunstncia. O final da histria,
o leitor j sabe.
Alguns erros clssicos podem ser extrados dessa histria e so eles:
1) Excessiva presso do cronograma,
levando a erros inaceitveis;
2) Mudanas de requisitos constantes;
3) Falta de especificao tcnica;
4) Falta de documentao do projeto;
5) Inovaes tecnolgicas sem capacidade
tcnica de serem implementadas;
6) Ausncia de mtodos cientficos para
testes;
7) Ignorar o bvio diante de situaes
crticas; e
8) Falta de tica.
Como falei no incio do texto, qualquer
semelhana com os dias atuais pura coincidncia, mas parece que nossos problemas em projetos ainda vo continuar por
muito tempo.
Em 1961, 333 anos aps ter afundado, o Vasa foi iado, praticamente
intacto, do fundo da baa de Estocolmo O navio foi totalmente reformado
e encontra-se exposto no Museu Vasa
(www.vasamuseet.se), construdo prximo do local onde naufragou. Vale a
pena a visita. Eu garanto.

Mundo Project Management

Junho/Julho 2011

mundopm.com.br