Unisul Gestao de Projetos e Equipes

Universidade do Sul de Santa Catarina
Palhoa
UnisulVirtual
2006
Gesto de Projetos e de Equipes
Disciplina na modalidade a distncia
3 edio revista e atualizada
gestao_de_projetos_e_de_equipes.indb 1 28/5/2007 15:27:26
Apresentao
Este livro didtico corresponde disciplina de Gesto de Projetos
e de Equipes.
O material foi elaborado visando a uma aprendizagem autnoma,
abordando contedos especialmente selecionados e adotando uma
linguagem que facilite seu estudo a distncia.
Por falar em distncia, isso no signica que voc estar sozinho.
No esquea que sua caminhada nesta disciplina tambm
ser acompanhada constantemente pelo Sistema Tutorial da
UnisulVirtual. Entre em contato sempre que sentir necessidade,
seja por correio postal, fax, telefone, e-mail ou Ambiente Virtual
de Aprendizagem. Nossa equipe ter o maior prazer em atend-lo,
pois sua aprendizagem nosso principal objetivo.
Bom estudo e sucesso!
Equipe UnisulVirtual.
Mauro Faccioni Filho
Palhoa
UnisulVirtual
2006
Design instrucional
Daniela Erani Monteiro Will
Maria Isabel Orofno
3 edio revista e atualizada
Livro didtico
Copyright UnisulVirtual 2006
Nenhuma parte desta publicao pode ser reproduzida por qualquer meio sem a prvia autorizao desta instituio.
Ficha catalogrfca elaborada pela Biblioteca Universitria da Unisul
658.404
F12 Faccioni Filho, Mauro
Gesto de projetos e de equipes : livro didtico / Mauro Faccioni Filho ; design
instrucional Daniela Erani Monteiro Will, Maria Isabel Orono; [Flavia Lumi
Matuzawa, Karla Leonora Dahse Nunes, Leandro Kingeski Pacheco] 3. ed. rev. e
atual Palhoa : UnisulVirtual, 2006.
295 p. : il. ; 28 cm.
Inclui bibliograa.
1. Administrao de projetos. I. Will, Daniela Erani Monteiro. II. Matuzawa,
Flavia Lumi. III. Nunes, Karla Leonora Dahse. IV. Pacheco, Leandro Kingeski. V. Ttulo.
Crditos
Unisul - Universidade do Sul de Santa Catarina
UnisulVirtual - Educao Superior a Distncia
Campus UnisulVirtual
Rua Joo Pereira dos Santos, 303
Palhoa - SC - 88130-475
Fone/fax: (48) 3279-1541 e 3279-1542
E-mail: cursovirtual@unisul.br
Site: www.virtual.unisul.br
Reitor Unisul
Gerson Luiz Joner da Silveira
Vice-Reitor e Pr-Reitor Acadmico
Sebastio Salsio Heerdt
Chefe de gabinete da Reitoria
Fabian Martins de Castro
Pr-Reitor Administrativo
Marcus Vincius Antoles da Silva Ferreira
Campus Tubaro e Ararangu
Diretor: Valter Alves Schmitz Neto
Diretora adjunta: Alexandra Orseni
Campus Grande Florianpolis e
Norte da Ilha
Diretor: Ailton Nazareno Soares
Diretora adjunta: Cibele Schuelter
Campus UnisulVirtual
Diretor: Joo Vianney
Diretora adjunta: Jucimara Roesler

Equipe UnisulVirtual
Administrao
Renato Andr Luz
Valmir Vencio Incio
Bibliotecria
Soraya Arruda Waltrick
Coordenao dos Cursos
Adriano Srgio da Cunha
Ana Luisa Mlbert
Ana Paula Reusing Pacheco
Charles Cesconetto
Diva Marlia Flemming
Elisa Flemming Luz
Itamar Pedro Bevilaqua
Janete Elza Felisbino
Jucimara Roesler
Lauro Jos Ballock
Luiz Guilherme Buchmann Figueiredo
Luiz Otvio Botelho Lento
Marcelo Cavalcanti
Mauri Luiz Heerdt
Nlio Herzmann
Onei Tadeu Dutra
Patrcia Alberton
Patrcia Pozza
Rafael Pete da Silva
Raulino Jac Brning
Design Grco
Cristiano Neri Gonalves Ribeiro
(coordenador)
Adriana Ferreira dos Santos
Alex Sandro Xavier
Evandro Guedes Machado
Fernando Roberto Dias Zimmermann
Higor Ghisi Luciano
Pedro Paulo Alves Teixeira
Rafael Pessi
Vilson Martins Filho
Equipe Didtico-Pedaggica
Angelita Maral Flores
Carmen Maria Cipriani Pandini
Carolina Hoeller da Silva Boeing
Cristina Klipp de Oliveira
Dnia Falco de Bittencourt
Elisa Flemming Luz
Enzo de Oliveira Moreira
Flvia Lumi Matuzawa
Karla Leonora Dahse Nunes
Leandro Kingeski Pacheco
Ligia Maria Soufen Tumolo
Mrcia Loch
Patrcia Meneghel
Silvana Denise Guimares
Tade-Ane de Amorim
Vanessa de Andrade Manuel
Vanessa Francine Corra
Viviane Bastos
Viviani Poyer
Logstica de Encontros Presenciais
Caroline Batista (Coordenadora)
Aracelli Araldi
Graciele Marins Lindenmayr
Jos Carlos Teixeira
Letcia Cristina Pinheiro
Knia Alexandra Costa Hermann
Marcia Luz de Oliveira
Priscila Santos Alves
Logstica de Materiais
Jeferson Cassiano Almeida da Costa
(coordenador)
Eduardo Kraus
Monitoria e Suporte
Rafael da Cunha Lara (coordenador)
Adriana Silveira
Caroline Mendona
Edison Rodrigo Valim
Francielle Arruda
Gabriela Malinverni Barbieri
Gislane Frasson de Souza
Josiane Conceio Leal
Maria Eugnia Ferreira Celeghin
Simone Andra de Castilho
Vincius Maycot Seram
Produo Industrial e Suporte
Arthur Emmanuel F. Silveira (coordenador)
Francisco Asp
Projetos Corporativos
Diane Dal Mago
Vanderlei Brasil
Secretaria de Ensino a Distncia
Karine Augusta Zanoni
(secretria de ensino)
Djeime Sammer Bortolotti
Carla Cristina Sbardella
Grasiela Martins
James Marcel Silva Ribeiro
Lamuni Souza
Liana Pamplona
Maira Marina Martins Godinho
Marcelo Pereira
Marcos Alcides Medeiros Junior
Maria Isabel Aragon
Olavo Lajs
Priscilla Geovana Pagani
Silvana Henrique Silva
Secretria Executiva
Viviane Schalata Martins
Tecnologia
Osmar de Oliveira Braz Jnior
(coordenador)
Ricardo Alexandre Bianchini
Rodrigo de Barcelos Martins
Edio Livro Didtico
Professor Conteudista
Design Instrucional
Maria Isabel Orono
Flavia Lumi Matuzawa (2 ed. rev.)
Leandro Kingeski Pacheco (3 ed.
rev. e atual.)
Projeto Grco e Capa
Equipe UnisulVirtual
Diagramao
Rafael Pessi
Reviso Ortogrca
Revisare
Palavras do professor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Plano de estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
UNIDADE 1 Introduo gesto de projetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
SEO 1 Histria e evoluo da gesto de projetos . . . . . . . . . . . . . 18
SEO 2 O que Projeto? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
SEO 3 O que Gesto? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
SEO 4 Prazo, Recursos, Custos e Grupos de Trabalho . . . . . . . . . . 36
UNIDADE 2 Nascimento do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
SEO 1 Inovao tecnolgica: fonte de novos projetos . . . . . . . . 46
SEO 2 Identifcando oportunidades . . . . . . . . . . . . . . . . . . . . . . . . . . 59
SEO 3 Motivao para o projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
SEO 4 Quais so os tipos de projeto? . . . . . . . . . . . . . . . . . . . . . . . . . 67
UNIDADE 3 Viso geral do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
SEO 1 Identifcao e avaliao inicial . . . . . . . . . . . . . . . . . . . . . . . . 85
SEO 2 Requisitos do cliente e soluo de problemas . . . . . . . . . 96
SEO 3 Algoritmo do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
SEO 4 Prazo geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
SEO 5 Viabilidade do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
SEO 6 Antecipando e administrando riscos . . . . . . . . . . . . . . . . . . 125
UNIDADE 4 Planejamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
SEO 1 Modelagem do fuxo de atividades . . . . . . . . . . . . . . . . . . . 143
SEO 2 Metodologias de planejamento Grfco de Gantt . . . 153
SEO 3 Metodologias de planejamento PERT/CPM . . . . . . . . . . 168
SEO 4 Estimativa de recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
SEO 5 Estimativa de custos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
UNIDADE 5 Estruturando a equipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
SEO 1 Estruturando a equipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
SEO 2 Recursos humanos e perfs . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
SEO 3 Treinamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
SEO 4 Responsabilidade e diviso de tarefas . . . . . . . . . . . . . . . . 213
SEO 5 Terceirizao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Sumrio
UNIDADE 6 Executando o projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
SEO 1 Preparao e incio dos trabalhos . . . . . . . . . . . . . . . . . . . . . 230
SEO 2 Liderana versus gesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
SEO 3 Tomada de decises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
SEO 4 Motivao e comunicao . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
SEO 5 Reunies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
SEO 6 Gerenciando qualidade, tempo e recursos . . . . . . . . . . . . 247
SEO 7 Gesto de confitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
SEO 8 Simulao, testes e validao . . . . . . . . . . . . . . . . . . . . . . . . . 253
UNIDADE 7 Finalizando o projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
SEO 1 Fase de fnalizao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
SEO 2 Planos de contingncia em caso de problemas . . . . . . . 262
SEO 3 Atendendo as expectativas do cliente . . . . . . . . . . . . . . . . 264
SEO 4 Sobre o sucesso (ou fracasso) do projeto . . . . . . . . . . . . . 265
SEO 5 Desfazendo a equipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
SEO 6 Documentao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
SEO 7 Lies aprendidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
SEO 8 Idias para um novo projeto . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Para concluir o estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Referncias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Sobre o professor conteudista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
Respostas e comentrios das atividades de auto-avaliao . . . . . . . . . . . . . . . 287
Palavras do professor
Os livros dedicados gesto de projetos dividem-se
basicamente em dois tipos: aqueles que listam uma
srie de tcnicas prticas de planejamento, e aqueles que
discutem teoricamente a disciplina de gesto.
Os do primeiro tipo acreditam que simplesmente
aplicando alguma metodologia pr-concebida de gesto
ser possvel gerenciar um projeto com ecincia e
eccia. Baseiam-se em mtodos e tcnicas - uma srie
imensa de planilhas e relatrios - e mais recentemente
dedicam-se a explicar e implantar ferramentas
computacionais.
Os do segundo tipo analisam a gesto como uma
disciplina capaz de apoiar e beneciar aqueles que se
dedicam ao planejamento e ao desenvolvimento de
projetos, mas carecem de uma real experincia em
diferentes tipos de projetos, os quais envolvem sempre
um agente essencialmente subjetivo: o ser humano.
Este livro didtico explora esse assunto de uma outra
forma. Aqui o foco ser essencialmente na aprendizagem
e na discusso que gera um tipo de conhecimento que
pode e deve ser til aos que se interessam pelo tema.
Neste sentido este no um livro puramente acadmico,
com unidades e sees que apresentam teorias e exemplos
desvinculados da realidade e de uma viso aplicada aos
negcios e aos trabalhos prticos. Sem dvida muitas
questes aqui colocadas vieram de pesquisas e anlises
acadmicas, porm esto sempre focadas em aplicaes.
10
A idia central desta disciplina discorrer sobre as principais
teorias de gesto de projetos e de equipes, mas com o olhar
voltado s aplicaes e ao nvel estratgico. A palavra gesto
est intimamente relacionada funo de gerncia, como
veremos, e a gerncia se assemelha a uma funo operacional
voltada ao controle. Mas em projetos isso no funciona. O
melhor foco para a gesto de projetos deve estar colocado no
conceito de liderana, pois a liderana submete a gesto, e no o
inverso.
Com essas palavras iniciais gostaria ento de convid-lo a
essa aventura do conhecimento o estudo dos projetos, sua
organizao, planejamento e, acima de tudo, trabalho de redes
sociais participativas e cooperativas. Bom estudo!
Professor Mauro Faccioni Filho.
Plano de estudo
O plano de estudos visa a orient-lo/a no desenvolvimento da
Disciplina. Nele, voc encontrar elementos que esclarecero
o contexto da Disciplina e sugeriro formas de organizar o seu
tempo de estudos.
O processo de ensino e aprendizagem na UnisulVirtual leva
em conta instrumentos que se articulam e se complementam.
Assim, a construo de competncias se d sobre a articulao
de metodologias e por meio das diversas formas de ao/
mediao.
So elementos desse processo:
o livro didtico;
o Espao UnisulVirtual de Aprendizagem EVA;
as atividades de avaliao (complementares, a distncia
e presenciais);
o Sistema Tutorial.
Ementa
Anlise de requisitos do cliente. Anlise de custos, recursos
e prazos. Descrio do escopo do problema. Planejamento e
gesto de recursos materiais e humanos. Diviso de tarefas
e etapas, considerando riscos. Criao de plano com uxo
de trabalho e sincronismo de equipe e recursos. Controle da
qualidade em projetos para Web. Encerramento de projetos.
Vericao da satisfao do cliente. Feedback.

12
Objetivo geral
Apresentar os conceitos bsicos da rea de gesto de
projetos.
Fornecer subsdios para a avaliao de riscos de um
projeto, com nfase nos projetos de base tecnolgica.
Apresentar tcnicas de planejamento, execuo e
controle de projetos, formao de equipes e seu
gerenciamento de reunies.
Descrever um modelo para gesto de projetos.
Vericao dos softwares disponveis para auxlio no
gerenciamento de projetos.
Utilizao de software livre para gesto de projetos.
Contedo programtico
Unidade 1: Introduo gesto de projetos
Apresentao da histria e evoluo dos grandes projetos
desenvolvidos pelo homem, e como surgiu a disciplina de Gesto
de Projetos para gerenciar esse tipo especial de trabalho. Nesta
unidade so apresentados os conceitos fundamentais da disciplina
de gesto de projeto e equipes.
Unidade 2: Nascimento do projeto
O papel da inovao tecnolgica como geradora de projetos
discutido, e os diferentes tipos de inovao so apresentados.
Oportunidades de projetos podem surgir de descobertas
cientcas, invenes ou de inovaes tecnolgicas, mas preciso
motivao para o seu desenvolvimento. Nesta unidade so ainda
apresentadas as diversas classicaes de projetos, segundo
diferentes propsitos e diferentes vises.

13
Unidade 3: Viso geral do projeto
Os primeiros passos de um projeto so descritos, o que inclui
o levantamento de requisitos do cliente e os problemas a serem
solucionados. Descreve-se um modelo genrico de algoritmo para
o planejamento e realizao de projetos, e fatores como prazo,
viabilidade e riscos so apresentados e discutidos.
Unidade 4: Planejamento
As principais metodologias de planejamento de projeto so
apresentadas nesta unidade, bem como tcnicas para sua aplicao
em problemas prticos. Mtodos como Grco de Gantt, PERT/
CPM, estimativa de recursos e cronogramas fsico-nanceiros so
desenvolvidos e aplicados em projetos tpicos.
Unidade 5: Estruturando a equipe
A formao da equipe, descrio dos principais pers e
organizao dos recursos humanos para o trabalho em projetos
o tema desta unidade. Problemas como terceirizao, treinamento
e mtodos para dividir tarefas so estudados e as teorias sobre o
assunto so apresentadas.
Unidade 6: Executando o projeto
Unidade que rene os temas relacionados ao dia a dia dos
projetos, desde o comportamento da liderana, tomada de
decises, estruturao de reunies, gesto de conitos e aspectos
diversos como motivao da equipe e gesto da qualidade.
Como projetos so atividades com prazo denido, so descritos
passos intermedirios com simulao, testes e validao como
ferramentas de ajuste e melhoria contnua dos projetos e dos seus
resultados.
Unidade 7: Finalizando o projeto
Unidade que relata as atividades de encerramento do projeto, os
planos de contingncia em caso de problemas, e aspectos relativos
s demandas originais do cliente, vericando ento o sucesso (ou
fracasso) da empreitada. Mostra ainda que lies sero aprendidas
no decorrer do trabalho, e que sem dvida idias para novos
projetos devero surgir.
14
Agenda de atividades/ Cronograma
Verique com ateno o EVA, organize-se para acessar
periodicamente o espao da Disciplina. O sucesso nos
seus estudos depende da priorizao do tempo para a
leitura; da realizao de anlises e snteses do contedo; e
da interao com os seus colegas e tutor.
No perca os prazos das atividades. Registre no espao
a seguir as datas, com base no cronograma da disciplina
disponibilizado no EVA.
Use o quadro para agendar e programar as atividades
relativas ao desenvolvimento da Disciplina.

15
Atividades atividades

Demais atividades (registro pessoal)
UNIDADE 1
Introduo gesto de projetos
Objetivos de aprendizagem
Compreender diferenas entre projetos e atividades

rotineiras e contnuas.
Verifcar um breve histrico dos projetos e de sua gesto.
Analisar a evoluo da gesto de projetos e de equipes

como uma disciplina do conhecimento.
Conhecer os principais conceitos sobre projetos, equipes

e gesto.
Sees de estudo
Seo 1 Histria e evoluo da gesto de projetos.
Seo 2 O que Projeto?
Seo 3 O que Gesto?
Seo 4 Prazo, Recursos, Custos e Grupos de
Trabalho.
1
18
Para incio de conversa
Voc acabou de ler nas palavras iniciais deste livro que projetos
so atividades feitas geralmente por grupos de pessoas em
trabalho cooperativo. Para dar continuidade a esta reexo, voc
poder agora aprofundar seus conhecimentos sobre o que so
projetos e por que eles se destacam como atividade especial.
Esta unidade apresenta em sua primeira seo um breve
histrico sobre projetos e como eles assumiram importncia
como atividade diferente dos trabalhos de rotina. Voc vai ver
que os projetos nos acompanham h alguns milhares de anos, e
seus resultados perduram at hoje como obras magncas do ser
humano. Como disciplina de estudo, no entanto, tem no mais
do que cem anos.
Na segunda seo so enfocados os principais conceitos da
matria e diversos exemplos e contra-exemplos so apresentados
para que voc exercite o seu entendimento.
Pretendo que este trabalho sirva de estmulo ao desenvolvimento
de novos e bem planejados projetos, pois, como j ouvi certa vez,
o planejamento a me da sorte.
Bom estudo, bom planejamento e boa sorte!
SEO 1 Histria e evoluo da gesto de projetos
Todo mundo tem uma noo do que seja um projeto. Voc,
com certeza, deve ter uma.
A palavra projeto muito comum e est presente nos
dilogos de todos os dias. Porm, os conceitos que se
formaram sua volta so bastante distintos de uma
pessoa para a outra, e isso acontece porque o uso
convencional dessa palavra varia de situao a situao.
Mas antes de comear a discutir o conceito de projeto, e acima
disso o que a sua gesto, como se formam as equipes, que
mtodos e que ferramentas podemos usar, importante que voc
19
Unidade 1
conhea a origem desta forma de trabalho e como ela vem se
modicando ao longo da histria.
Mas qual a origem dos projetos como forma de
organizao do trabalho?
Na histria da humanidade o trabalho foi se organizando
lentamente. Tribos nmades andavam pelo planeta h
milhares de anos, buscando todos os dias o alimento dirio
e lutando contra as intempries, contra os animais, contra as
doenas e todas as diculdades. Justamente como os animais
fazem at hoje.
Com a inveno de alguns artefatos e com a domesticao dos
animais, o ser humano passou de nmade a sedentrio, comeou
a construir habitaes e aglomerados de casas, formando ento
aldeias, vilas e cidades. O arranjo do trabalho se modicou, e
no tendo mais que buscar o alimento por meio da caa, passou
a produzi-lo e estoc-lo. Alguns passaram a deter mais poder
do que outros, comearam a poupar objetos de valor, terras,
ampliando os domnios terrestres e at mesmo um patrimnio
sobre as questes espirituais.
Por essa poca surgem alguns empreendimentos que deviam
marcar a presena dessas pessoas poderosas, deixar para sempre
suas marcas sobre a Terra.
No preciso avanar muito e voc vai se lembrar das
pirmides do Egito, obras realizadas para sepultar
os faras, considerados deuses. Acompanhe a seguir
mais informaes.
Com esse propsito especco de sepultamento, a pirmide
era encomendada pelo prprio fara (que iria us-la aps a
morte!) e ento projetistas e construtores desenvolviam seu
desenho e passavam a executar a obra. O prazo da execuo
era aproximadamente o da durao da vida do fara, ou
preferivelmente menor, obviamente. Milhares de homens
formavam as equipes e literalmente eram usados na construo,
quebrando e carregando pedras at a exausto. Alm dos faras
muitos homens ricos encomendavam suas prprias pirmides,
20
cada um na medida das suas riquezas. Muitas no cavam
prontas a tempo, e vinham ento servir para o sepultamento de
alguma outra pessoa.
Figura 1.1 - As trs pirmides do Egito, dos Faras Quops, Qufren
e Miquerinos.
As pirmides eram tipicamente projetos. Em outras culturas,
como a dos Maias e dos Incas, assim como a dos Astecas, as
pirmides eram construdas para cultos religiosos e sacrifcios,
e da mesma forma eram encomendadas e construdas com mo-
de-obra escrava, tendo grupos de comando e um prazo denido
para entrega.
Uma das mais interessantes e importantes obras j
feita pelo ser humano, comeou a ser construda
685 anos antes da Era Crist (685 AC). As Grandes
Muralhas da China tiveram seu incio com a
pretenso de defesa de diferentes reinos, naquela
poca em luta pela expanso dos seus territrios
(COURAU, 2004).
21
Unidade 1
No havia a China como conhecemos hoje, mas sim um conjunto
de sete reinos em combate, todos buscando conquistar e anexar os
vizinhos. Um desses reinos se chamava Qin e foi comandado por
Zheng, que por volta de 240 a 220 AC conseguiu vencer e anexar
os outros reinos, unicando todos eles. E em 220 AC decidiu
realizar essa obra gigantesca, ligando os trechos de muralhas
existentes e criando de fato as Grandes Muralhas da China.
E qual era a inteno ao construir essa obra?
Com o objetivo de separar o pas dos brbaros, e internamente
denir a unidade da nao e a civilizao, a obra teve um prazo
de aproximadamente 10 anos de construo, uma extenso de
mais de 6.000 quilmetros de muros com altura de at 16 metros
e forticaes para soldados a cada 60 metros, recursos humanos
da ordem de centenas de milhares de operrios em regime de
trabalho forado e um plano de produo rgido (na verdade,
cruel), esse um tpico projeto, evidentemente impossvel de se
realizar hoje em dia.
Figura 1.2 - A Grande Muralha da China, projeto de mais de dois mil
anos atrs. (COURAU, 2004)
Origem do nome atual da
China.
22
Enquanto a China buscava unifcar seu territrio e criar
uma verdadeira civilizao, mais a oeste outro imprio
se desenvolvia e seria praticamente uma das bases da
nossa civilizao ocidental: o Imprio Romano.
Desde Jlio Csar, o Imprio Romano cresceu incessantemente,
chegando a fazer divisa com o Imprio Chins. Os romanos
so conhecidos por seus grandes projetos civilizatrios, e muitas
das obras que resultaram desses projetos resistem at hoje. Voc
certamente se lembra do Coliseu, aquela grande arena construda
em Roma para festejos, lutas entre gladiadores e espetculos.
Durante centenas de anos o Coliseu foi utilizado nessas
atividades, que entraram em sua rotina, porm houve, antes de
tudo, o projeto de sua construo.
Tambm outros projetos importantssimos foram desenvolvidos
pelos romanos, mas no para diverso e sim para melhoria das
cidades, como:
os aquedutos;
as estradas caladas em pedras, que cruzaram a Europa
em todas as direes e que at hoje tm alguns trechos
mantidas (quando as pedras no foram roubadas!).
Um outro caso de projeto muito interessante foi desenvolvido
na fronteira norte do Imprio Romano. A ilha onde hoje
est a Inglaterra foi dominada pelos romanos (que por sinal
fundaram Londres), porm a extremidade norte da Bretanha
no foi conquistada ( a regio onde hoje est a Esccia). Os
romanos buscavam marcar suas divisas com os territrios no
conquistados, e criavam forticaes, geralmente tendo rios como
elementos divisores. Os rios dicultavam a invaso dos brbaros.
Porm, ao norte da Bretanha no havia rios, e constantes lutas
aconteciam naquele pequeno trecho.
Em 120 AC o Imperador Adriano esteve no local e decidiu
contratar um projeto de seus correligionrios: construir uma
Muralha forticada, que isolasse toda a ponta norte da ilha, ou
seja, o objetivo do projeto era fazer um muro que ligasse o mar
ao leste da ilha at o Oceano Atlntico, a oeste. Esse muro era
de aproximadamente 117 quilmetros, construdo em pedra, com

23
Unidade 1
portes forticados e 16 fortes para soldados, distribudos ao
longo do Muro. Com o exguo prazo de 6 anos para construo,
o projeto foi sendo modicado durante as obras, e muitas vezes
a edicao em pedra foi substituda por barro misturado com
galhos. Tipicamente resultado de alteraes de prazo de projeto,
e tambm da diculdade de obter recursos materiais (as pedras
eram raras na regio), a substituio por barro criou pontos falhos
na obra, que posteriormente tiveram de ser corrigidos.
Como voc vai ver adiante, problemas no dia-a-dia da execuo
dos projetos so muito comuns. To comuns, que vai chegar um
momento na histria que algumas metodologias sero criadas
para tentar controlar esses problemas. Mas sobre isso, voc vai
aprofundar o estudo nas prximas unidades.
Figura 1.3 - Porto fortifcado nas Muralhas de Adriano (representao, em demonstrao
no Hadrians Wall Museum).
Os projetos da Antigidade citados at agora (as pirmides, as
muralhas) referem-se a grandes obras. Mas houve outros tipos de
projetos, alguns muito bem-sucedidos.
Os gregos fundaram a civilizao ocidental,
colocando as bases da nossa cultura, flosofa e
cincia.
Uma das mais importantes obras literrias de todos os tempos, o
poema Ilada, de Homero, descreve um projeto elaborado pelos
combatentes gregos para tentar invadir e dominar a lendria
cidade de Tria. Em guerra contra os troianos, os gregos sitiaram
por dez anos a cidade de Tria, sem conseguir invadi-la.
24
Agamenon, chefe dos gregos, arquitetou ento um projeto que
consistia em construir um cavalo de madeira gigante (a primeira
etapa) e coloc-lo em frente aos portes de Tria durante a noite
(a segunda etapa do projeto).
Ao amanhecer, os troianos viram o imenso objeto e pensaram ser
algum tipo de presente divino. Abriram os portes e trouxeram
para a praa central da cidade. A terceira etapa do projeto
de Agamenon estava concluda. Naquela noite, quando todos
dormiam, os soldados gregos que estavam dentro do cavalo,
escondidos, saram e abriram os portes da cidade, permitindo
que o exrcito grego entrasse e vencesse nalmente a batalha.
Quarta etapa concluda!
Figura 1.4 - O Cavalo de Tria sendo puxado para dentro da cidade, segundo o pintor
Giovanni Battista Tiepolo.
Muitos desses projetos tiveram um prazo bem denido (mesmo
que longo) com objetivos diretos e quase sempre ligados s guerras.
Voc sabia?
Passados muitos sculos, j no fnal da Idade Mdia e
quando os pases ocidentais comearam a se defnir
como naes, houve um pas que fcou com uma rea
territorial muito restrita, impedindo seu crescimento
e riqueza.
Deu-se incio ento a um enorme projeto, que na
verdade fcou dividido em inmeros subprojetos, que
consistiram em aumentar o territrio da Holanda,
conquistando espao do mar. Como?
25
Unidade 1
Imensas regies da atual Holanda eram, no passado, banhadas
pelo mar. Como os nossos mangues, na mar cheia a gua
invadia reas enormes, alagando e salinizando o solo, que ento
no era apropriado para a agricultura.
O projeto de conquista de terras consistiu em criar uma divisa
entre terra e mar (barreiras), criando regies alagadas. No interior
dessas regies, chamados polders, eram construdos diversos
canais para drenar a gua at um dique. Esse dique ento
bombeava a gua de volta ao mar. Inicialmente com o auxlio
de moinhos de vento (imagem que popularizou a Holanda),
atualmente o bombeamento feito com motores eltricos e no
mais com a fora do vento. Inmeros diques foram construdos,
fazendo parte de um grande projeto que hoje garante Holanda
40% do seu territrio (em reas muito frteis!).
Esses exemplos de grandes projetos da Antigidade mudaram
a histria da humanidade e a maneira dos seres humanos agirem
uns em relao aos outros e em relao natureza. Pessoas
envolvidas nesses projetos comearam a perceber algumas
caractersticas tpicas de um projeto, que eram diferentes, por
exemplo, de uma tarefa rotineira como a manuteno do dique,
o dia-a-dia das batalhas, ou das tarefas administrativas de
conduo da poltica imperial romana ou chinesa.
Projetos tm objetivos defnidos e prazo de concluso
e, para que isso acontea com sucesso, preciso
conduzir, coordenar e controlar um projeto e as
pessoas que o integram.
Com toda essa experincia prtica, acumulada em tantos projetos
ao longo da histria, no tardou para alguns pensadores se
voltassem para esse tipo de produo, e comeassem a criar uma
teoria a respeito. Neste sentido, talvez o primeiro livro sobre o
assunto tenha sido An Essay on Projects (Um ensaio sobre
projetos), escrito por Daniel Defoe em 1697 (CLELAND,
2004). A partir dessas primeiras teorias comeam a se
desenvolver projetos com uma outra mentalidade, especialmente
com o advento da revoluo industrial, no sculo 18.
26
Um pouco depois, durante o sculo 19, os governos dos pases
mais desenvolvidos comearam a contratar grandes projetos
de infra-estrutura, tais como ferrovias, pontes, embarcaes
etc, demandando enormes esforos das companhias para a seu
execuo, com valores nanceiros e prazos pr-denidos.
Decises importantes deviam ser tomadas nos projetos, para
que atendessem s solicitaes desses grandes clientes, e tais
decises eram gerenciais, administrativas. No era mais possvel
escravizar milhares de homens para construir uma estrada, como
tantas vezes na histria j tinha acontecido. E tambm no havia
fundos ilimitados. E a gesto desses projetos tinha que seguir
algum tipo de planejamento.
Um cientista da administrao surge nessa poca e comea
a estudar detalhadamente o trabalho, mostrando que a
produtividade pode ser aumentada se o trabalho for dividido em
tarefas pequenas e distintas. Seu nome Frederick Taylor (1856-
1915), e ele considerado o pai da cincia da administrao
(SISK, 2004).
Com a sua contribuio, a indstria pde modicar seu modo
produtivo e deslanchar para aquilo que conhecemos hoje: em
vez de um trabalhador executar todas as tarefas at concluir
determinado produto, ele se ocupa apenas de uma tarefa,
especializando-se nela. Com isso a produtividade aumenta e os
produtos so feitos em srie.
Fundamental para a revoluo
industrial em curso, a contribuio
de Taylor tambm teve seu
lado negativo, transformando
o trabalhador numa espcie de
mquina, de engrenagem dentro
do processo produtivo, que tem
sido sempre muito criticada e
satirizada, como no flme Tempos
Modernos de 1936 de Charlie Chaplin o Carlitos.
27
Unidade 1
Junto com Taylor trabalhava Henry Gantt (1861-1919), que
estudou em detalhes as operaes associadas a um trabalho,
decompondo-as em etapas. Para ver as diversas etapas em
seqncia, e como elas vo se sucedendo at o nal de um
determinado projeto, Gantt inventou um grco constitudo de
barras, sendo que cada barra representa uma etapa e seu tamanho
representa uma durao.
Os grcos de Gantt caram famosssimos e at hoje so
usados para gerenciar projetos. Voc vai estudar esses grcos
em detalhe, mais frente nesta disciplina, e vai ver como eles
podero lhe ajudar a gerenciar futuros projetos.
Veja na fgura a seguir um exemplo de grfco de
Gantt.
Figura 1.5 Exemplo de grfco de Gantt.
Durante a Segunda Guerra Mundial, muitos projetos
tecnolgicos foram desenvolvidos pelos militares dos
pases em luta.
Sabemos do desenvolvimento dos msseis; o que posteriormente
levou conquista do espao, de vrios tipos de avies, de bombas,
de tratamentos etc.
Com o m da guerra, cou evidente que havia um campo do
conhecimento especco da administrao de projetos, que cou
conhecido em ingls por project management; e em portugus
por gesto de projetos.
28
A maior associao mundial de engenheiros eletrnicos e
eletricistas, o Institute of Electrical and Electronic Engineers
(IEEE), criou em 1954 a revista Transactions on Engineering
Management especialmente para discutir temas relacionados
gesto de projetos e produo em engenharia, que tem
inuenciado consideravelmente a rea.
Tambm nos anos 50 surgem dois mtodos que se tornaram
muito importantes na gesto de projetos, disciplina que
passou a fazer parte de todos os currculos de Administrao e
Engenharia de Produo desde ento (PRADO, 1998). Veja a
seguir quais so:
O primeiro surgiu na empresa Du Pont em 1957, com
o ttulo de Mtodo do Caminho Crtico (CPM). A
empresa buscava melhorar suas tcnicas de planejamento
e controle de projetos de engenharia, e o mtodo fez
enorme sucesso desde o incio.
O segundo foi desenvolvido quase simultaneamente,
quando a marinha americana lanou um projeto
complexo para a construo de submarinos atmicos,
o projeto Polaris. Devido complexidade do projeto,
ao relacionamento de diversas empresas (eram mais
de 9.000 empreiteiros!), e complexidade tecnolgica
envolvida, um sistema de planejamento e controle
precisava ser desenvolvido. Esse sistema foi criado em
1958 e denominado Program Evaluation and Review
Technique (PERT), que signica tcnica de avaliao e
reviso de programas/projetos.
Na poca uma pesquisa foi realizada nos EUA para vericar
como se comportavam os projetos governamentais e privados,
com relao ao que era planejado e ao efetivamente realizado. O
quadro a seguir mostra os desvios encontrados (PRADO, 1998).
Iniciais do ttulo em ingls Critical

Path Method - CPM.
29
Unidade 1
Quadro 1.1 Desvios no planejamento.
Desvio entre o planejado e o realizado
Projeto Desvio de tempo Desvio de custo
Governamental / militar 40 a 50% 100 a 200%
Privado 40% 70%
Esses dados foram divulgados e foram alarmantes. Projetos
governamentais podiam superar em at 200% os custos
inicialmente estimados! No entanto, com o uso do PERT, o
projeto Polaris foi realizado com sucesso dentro do oramento
e em apenas trs anos. A partir da, os mtodos PERT e CPM
acabaram se fundindo e assumindo inclusive o formato de
Diagrama de Precedncias, tcnica desenvolvida na Frana em
1964 (PRADO, 1998).
- Voc vai estud-lo e exercit-lo no decorrer desta disciplina.
A evoluo dos sistemas computacionais na segunda metade do
sculo vinte que vai contribuir para a melhoria dos mtodos
de gesto de projetos, mesmo porque os prprios sistemas
computacionais so desenvolvidos na forma de projetos, e por
isso demandam tcnicas de planejamento e controle especcos.
Normas comearam a ser escritas para a gesto de projetos, e
nos EUA foi criado o Instituto de Gesto de Projetos Project
Management Institute (PMI), tem sido responsvel pelas mais
recentes e importantes contribuies neste campo, especialmente
o livro Guide to the Project Management Body of Knowledge,
conhecido como PMBOK (PMBOK, 2004).
30
Figura 1.6 Logo do instituto PMI e fac-smile da capa da 3 edio do PMBOK.
Uma alternativa aos mtodos normatizados pelo PMBOK
foi apresentada por Eliyahu Goldratt em 1997, com o nome
de Critical Chain Project Management (CCPM), que pode
ser traduzido como gesto de projetos pelo encadeamento
crtico (RAZ, 2004). Isso demonstra o quanto ainda est em
desenvolvimento a rea da gesto de projetos.
Mas se voc pensa que o uso de grcos de Gantt, Caminho
Crtico, PERT, CCPM e outros mtodos resolveram o problema,
infelizmente est enganado. No ano de 1998 o Te Standish Group
realizou uma pesquisa nos EUA e descobriu que muita coisa est
fora do lugar. Conforme reportado pela empresa Process Quality
Associates Inc., alguns resultados esto no quadro a seguir e nos
mostram o quanto ainda h por fazer.
Quadro 1.2 Estatsticas apresentando problemas tpicos de projetos.
Desaos e sintomas tpicos de projetos Mdia nacional EUA (1998)
Atraso
Apenas 44% dos projetos so concludos
no prazo. Na mdia os projetos costumam
atrasar em at 222% do prazo programado.
Acima do custo estimado. 189%.
No atingem satisfatoriamente os requisitos
tcnicos planejados.
70% dos projetos.
Cancelados antes do trmino. 30% dos projetos.
31
Unidade 1
A rpida evoluo da computao, especialmente da
dcada de 1990 em diante, e tambm das tecnologias
da comunicao e informao, onde a Internet o
maior smbolo, representa um novo desafo. Com
este desafo em mente que esta disciplina foi
construda.
Com este breve histrico sobre projetos e sobre a crescente
necessidade de seu gerenciamento, espero que voc tenha uma
primeira viso a respeito do que um projeto, como ele se
diferencia de outras atividades humanas, e tambm sobre a
importncia de um sistema de planejamento e controle para
conseguir obter sucesso.
Nas prximas sees, voc vai conhecer alguns conceitos que vo
estar presentes em toda a disciplina e que certamente vo ajud-lo
muito, seja em seus trabalhos educacionais ou prossionais.
Para discutir e estudar Gesto de Projetos e de Equipes
importante, antes de tudo, que voc compreenda alguns
conceitos, a m de evitar equvocos ou interpretaes errneas.
SEO 2 O que Projeto?
Quem nunca participou de uma conversa ou
um debate, onde se perdem horas em acalorada
discusso para, no fnal, se perceber que tudo
comeou porque uma simples palavra foi entendida
de forma diferente pelas pessoas?
Esse problema to grave que um dos maiores lsofos do sculo
passado, Ludwig Wittgenstein, considera que boa parte das
questes loscas no passa do desentendimento das palavras
por parte dos que a usam. Ao mesmo tempo ele percebe que h
palavras que no podem ser entendidas igualmente por todos.
32
Bem, voc no vai encontrar essa discusso nesta disciplina, mas
vamos trabalhar alguns conceitos importantes e se manter perto
deles. Comeemos pelo conceito de projeto.
A primeira palavra importante a considerar , obviamente,
projeto. No histrico das grandes obras e empreendimentos
humanos que voc estudou na seo anterior, pode perceber
algumas coisas em comum:
Prazos.
Objetivos.
Custos.
Recursos.
Mas a importncia desses componentes foi mudando com o
tempo. Acompanhe um exemplo a seguir.
O prazo de construo das pirmides deveria ser
menor que o tempo de vida do fara. Mas como
isso no podia ser determinado, muitas vezes o
servio ultrapassava do prazo. J para o caso das
Muralhas de Adriano, o prazo de poucos anos era
absolutamente importante, para evitar as constantes
invases, tanto que algumas vezes eles optaram
por mudar os recursos materiais (substituram as
pedras pela construo em barro) para ganhar tempo.
H casos mais dramticos, como as Muralhas da
China, onde ningum se importava com as equipes
de construtores. Morriam trabalhando e eram
substitudos depois de exaurirem, ou seja, ningum se
importava com os recursos humanos.
Com o passar das eras e chegando j nos tempos modernos,
o que se v que os objetivos caram mais claros e mais
especializados, os prazos cada vez mais curtos, os custos sempre
maiores e os recursos cada vez mais escassos.

33
Unidade 1
Conforme Antnio Houaiss em seu dicionrio de lngua
portuguesa (2004), projeto pode ser denido como: Idia,
desejo, inteno de fazer ou realizar (algo), no futuro; plano;
descrio escrita e detalhada de um empreendimento a ser
realizado; delineamento, esquema.
Para esta disciplina adotei uma viso voltada gesto de projetos,
a qual est denida pelo Project Management Institute como:
Um projeto um conjunto de tarefas, arranjado
numa seqncia ou relao defnida, que produz um
efeito ou sada pr-defnida. Um projeto sempre tem
um comeo, meio e um fnal.
(A project is a series of tasks, arranged in a defned
sequence or relationship, that produce a pre-defned
output or efect. A project always has a start, middle,
and an end.)
importante, ainda, que voc observe que a viso de projeto
nesta disciplina compreende os empreendimentos voltados s
reas de tecnologia, como software e engenharia, por exemplo, e
de certa forma isso os diferencia de outros tipos de projeto, como
o caso de uma campanha poltica, ou o projeto de salvao das
baleias, dar a volta ao mundo numa bicicleta etc.
Tambm importante ter em vista que o projeto tem um ciclo
de vida bem denido, pois um projeto sempre tem um comeo,
meio e um nal.
Diferena entre projeto e tarefas de rotina / atividades contnuas
Projetos no so empreendimentos de rotina, so
empreendimentos completos e independentes (KEELING,
2002), com recursos e administrao prprios.
Para exemplicar essa questo vamos analisar a tabela a seguir,
onde temos um determinado campo de trabalho ou rea de
atividades humanas, e ao lado um tipo de projeto bem como
alguma atividade rotineira (que no projeto).
34
Quadro 1.3 Exemplos comparativos entre atividades de rotina e projetos.
rea Exemplo de projeto
Exemplo de tarefa de rotina ou
atividade contnua
Culinria
Lanamento de um restaurante
temtico.
Administrao do restaurante
temtico.
Construo civil
Desenhar e construir um prdio
comercial.
Manter e operar o sistema eltrico e de
automao do prdio.
Eletrnica
Desenvolver novo tipo de
condensador eletrnico.
Construir telefones celulares.
Agricultura
Pesquisar planta resistente a
determinado tipo de praga.
Plantar e colher as safras.
Software
Pesquisar novo sistema de
reconhecimento de fala.
Suporte tcnico aos usurios de
determinada plataforma.
Pelo quadro, podemos perceber que, enquanto os projetos tm
um objetivo preciso, fcil de medir e um resultado previsvel,
as atividades contnuas so planejadas a longo prazo, o controle
pode mudar bastante durante o tempo, sempre procurando novas
oportunidades e mesmo outros resultados, diferentes daqueles
pensados no incio.
Lanar o restaurante, por exemplo, tem apenas um
resultado: a sua inaugurao. Porm sua operao
pode trazer resultados to diferentes quanto a
mudana dos pratos, variaes de cardpio conforme
o gosto dos clientes, diminuio ou aumento da
equipe conforme as vendas, mudana de gerentes, e
assim por diante.
A internet um projeto?
Assim, como voc j estudou na disciplina Introduo Internet,
no incio houve um projeto para constituir uma grande rede,
interligando computadores com nalidades bem denidas. A sua
expanso, a incluso das transaes comerciais, a interligao
de redes de pesquisa, de telecomunicaes, os negcios, os
empreendimentos pessoais, enm, todas as comunicaes
que hoje usam a Internet como meio, zeram dela uma
infra-estrutura de telecomunicaes mundial. Hoje pode ser
considerada uma atividade de uso rotineiro, base para outros
projetos, que se superpem a ela.
35
Unidade 1
SEO 3 - O que Gesto?
Conforme Antnio Houaiss (2004), em seu dicionrio de lngua
portuguesa, gesto pode ser denida como: ato ou efeito de
gerir; administrao, gerncia.
Uma caracterstica de muitas disciplinas dedicadas gesto de
projetos e de equipes, e da maioria dos livros sobre o assunto,
que eles se dedicam a fornecer ao estudioso um conjunto de
ferramentas e metodologias, modelos de planilhas, softwares e
outros dispositivos, dando a entender que isto o que basta para
uma boa gerncia. No entanto, disponibilizar e ensinar a usar
ferramentas e mtodos de gerncia um assunto estritamente
operacional, e no estratgico. Compreendo que a simples gesto
de um projeto pode ser feita com o uso de ferramentas de apoio,
mas o sucesso de um projeto depende de liderana e cooperao,
assuntos que extrapolam, e muito, o campo operacional.
Dessa forma, olharemos sempre a palavra gesto
nesta disciplina visando a ir alm da gerncia
operacional, tentando encontrar as brechas para um
trabalho de liderana e cooperao, sempre voltadas
para uma viso abrangente e estratgica do projeto.
A gerncia est associada idia de controle, de administrao.
Para Page-Jones (1990), a gerncia de projetos est associada a
cinco atividades:
planejar o projeto;
organizar todos os recursos;
integrar os diversos elementos durante a execuo do
projeto;
medir o andamento das atividades e
revisar o plano para corrigir eventuais discrepncias,
para alcanar o objetivo do projeto.
Na opinio de Valeriano (1998) h diferenas entre
administrao, gerncia e gesto. Para esse autor, a administrao
se d no nvel da organizao, como um todo. A gerncia est no

36
nvel do projeto, enquanto a gesto seria aplicada a parcelas, ou
tpicos especcos, de um determinado projeto.
Nesta disciplina adotei uma denio mais genrica, que engloba
essas atividades, pois assim est sendo compreendida atualmente
a funo de gesto em projetos. Veja s:
A gesto de projetos compreende as funes de
planejamento, organizao de recursos, distribuio
e comunicao das tarefas s pessoas da equipe, com
monitoramento constante das atividades e motivao
do grupo para a conquista do objetivo pr-defnido.
SEO 4 Prazo, Recursos, Custos e Grupos de Trabalho
Prazo
Prazo a palavra do momento. Como voc j leu, no passado
muitas vezes no havia uma preocupao com os prazos
dos projetos. Porm, hoje ela enorme pois os recursos so
sempre escassos, e colocar um produto no mercado antes que a
concorrncia pode ser o fator do sucesso ou do fracasso.
Mas justamente nos prazos onde acontecem os
maiores erros de previso, e no me lembro de muitos
projetos concludos no prazo cujos resultados tenham
sido satisfatrios. Por qu?
Vamos discutir isso mais adiante. Por enquanto importante que
voc compreenda a seguinte denio de prazo:
Considerando o objetivo do projeto, prazo o tempo
disponvel para chegar ao resultado.
Como por exemplo, gesto da
qualidade, gesto dos documentos
etc.
37
Unidade 1
Recursos
Muitas vezes se confunde recursos com dinheiro, ou recursos
com custos. Porm vamos usar uma denio mais abrangente,
pois as condies nanceiras possibilitam obter diversos recursos,
mas no todos.
Veja o caso onde se precisa de um determinado especialista, um
engenheiro de grandes estruturas, por exemplo. Mesmo com
dinheiro para pagar um, possvel que no exista algum com
disponibilidade.
Uma denio til :
Recursos so as condies econmicas, materiais,
equipamentos e pessoal necessrio para desenvolver
determinado projeto a contento.
Custos
Idias maravilhosas, projetos visionrios, nada disso
pode ir alm se no houver condies de pagar os
custos de desenvolvimento. Recursos so necessrios, os
equipamentos custam dinheiro, materiais de consumo
tambm, cada vez mais caras so as horas de trabalho
das pessoas e dos especialistas em particular.
Custos so os gastos fnanceiros necessrios para
que todos os outros recursos sejam adequadamente
distribudos no projeto, desde o incio at a sua
concluso.
Grupos de trabalho
O principal elemento de um projeto, no interessa sua dimenso
ou importncia, o conjunto de pessoas responsveis pela sua
consecuo. Isso no quer dizer que as pessoas tenham seu valor
considerado adequadamente, basta ver os exemplos histricos
que mencionamos. Impossvel seria construir as Muralhas da
China sem os milhares de operrios que l estiveram. No entanto
38
eles eram considerados descartveis, trabalhavam como
escravos. Com o avano da civilizao isso mudou, e
alm de imprescindvel num projeto, o ser humano
passou a ter valor.
Mas projetos (a no ser os muito pequenos) no so
para uma pessoa s. Precisamos constituir grupos, com
atividades e responsabilidades diversas, interagindo
todo o tempo e em busca de um objetivo comum. Com
isso chegamos ao trabalho cooperativo. Em projeto
imprescindvel a presena de grupos de pessoas trabalhando de
forma cooperada. Nesta disciplina usaremos o conceito de equipe
de projeto como:
Grupo de indivduos dedicados ao projeto, com
funes e responsabilidades bem defnidas,
trabalhando em regime de cooperao e focados no
sucesso da empreitada.
39
Unidade 1
Sntese
Voc viu, na primeira seo, que os projetos, como atividades
com incio, meio e m, bem datados e com resultados claramente
esperados, j existem h milhares de anos. Diversos desses
projetos resultaram em obras que perduram at hoje.
Com o tempo os projetos foram se desenvolvendo e cando
mais complexos, sendo que ultimamente o desenvolvimento
de softwares e produtos de alta tecnologia tm exigido enormes
esforos de organizao e cooperao. Estudos sobre como
planejar e realizar projetos passaram a tomar importncia e
resultaram no desenvolvimento de diversas metodologias e
tcnicas. Ultimamente tais tcnicas tm sido implementadas
em sistemas de software e em redes distribudas, favorecendo
imensamente os lderes e gestores de projetos.
A segunda seo apresentou os principais conceitos sobre essa
rea do conhecimento, de tal forma que tais conceitos sejam uma
base comum para nossas prximas discusses e estudos.
Na prxima unidade voc vai ver como se d a gnese de novos
projetos, e o que pode determinar as sementes do seu sucesso
ou fracasso. Voc ver, tambm, como as oportunidades so
identicadas, quais as motivaes e quais os diferentes tipos de
projetos.
No deixe de fazer as atividades de auto-avaliao para a melhor
compreenso e xao dos conceitos, bem como de participar
ativamente nos fruns de discusso, sejam desta disciplina, sejam
dos ambientes atuais de estudo e discusso que se movimentam
na internet.
40
Atividades de auto-avaliao
1) Considerando que projetos tm objetivos defnidos e prazo de
concluso, encontre um exemplo de projeto em sua prpria
experincia, ou na histria, e descreva o mesmo.
2) Com respeito administrao dos projetos ao longo da histria, voc
viu que houve um momento em que se passou do trabalho realizado
sem planejamento para um incio de teorizao e implantao de
prticas gerenciais. Em que poca isso acontece, e por que motivos?
41
Unidade 1
3 Veja os dois quadros a seguir. O primeiro de um levantamento
realizado em 1958 e o segundo tem dados de 1998. Compare os ndices
e analise se houve mudanas nesse perodo.
Quadro 1.1 Desvios no planejamento (1958).
Desvio entre o planejado e o realizado
Projeto Desvio de tempo Desvio de custo
Governamental / militar 40 a 50% 100 a 200%
Privado 40% 70%
Quadro 1.2 Estatsticas apresentando problemas tpicos de projetos (1998).
Desaos e sintomas
tpicos de projetos
Mdia nacional EUA (1998)
Atraso
Apenas 44% dos projetos so concludos no prazo.
Na mdia os projetos costumam atrasar em at
222% do prazo programado.
Acima do custo estimado. 189%.
No atingem satisfatoriamente os
requisitos tcnicos planejados.
70% dos projetos.
Cancelados antes do trmino. 30% dos projetos.
42
4) Vimos que os projetos atualmente tm, em comum, o seguinte:
Prazos defnidos.
Objetivos estabelecidos.
Custos planejados.
Recursos previamente alocados.
No entanto isso no era assim nos grandes projetos da antiguidade.
Cite um desses casos e comente quais dessas caractersticas no se
apresentam.
5) Considere o quadro a seguir, onde exemplos de projetos so
comparados com exemplo de tarefas de rotina. Inclua no quadro
alguns novos exemplos para as reas determinadas:
Quadro 1.3 Exemplos comparativos entre atividades de rotina e projetos.
Exemplo de tarefa de rotina ou
atividade contnua
Concessionria de energia
eltrica
Software
Indstria Automobilstica
Bancos
Governo
43
Unidade 1
Saiba mais
1 - importantssimo hoje estar atualizado sobre o que acontece
no Project Management Institute (PMI), que edita do PMBOK
, tem mais de 150 mil associados em todo o mundo. Voc deve
dar uma olhada em: www.pmi.org. Nesse site voc encontrar
artigos variados, conferncias, possibilidade de se associar,
comprar livros e saber o que acontece de novo no mundo da
gesto de projetos.
2 - Outro local importante no desenho de mtodos e teorias
sobre a gesto de projetos a Sociedade de Gesto de Engenharia
do IEEE (IEEE Engineering Management Society (EMS). Esta
sociedade est no endereo http://www.ewh.ieee.org/soc/ems/,
e o site do IEEE geral o www.ieee.org.
3 - Algumas revistas muito interessantes sobre a rea de gesto
de projetos de tecnologia esto hoje disponveis e abertas na
Internet. Um exemplo a revista http://www.worldscinet.com/
compsci.shtml, especca sobre Gesto de Tecnologia. Nesse
mesmo site podemos encontrar diversas outras publicaes (em
ingls) sobre temas de interesse da computao.
2
UNIDADE 2
Nascimento do projeto
Compreender como nascem os projetos e como
detectar oportunidades de nascimento de projetos,
sejam individuais ou em ambientes empresariais e
industriais.
Perceber que os projetos ocupam uma posio

especial na produo industrial moderna, e que as
novas tecnologias nascem de projetos cada vez mais
complexos.
Reconhecer os principais tipos de projeto e analisar as

diferenas entre tecnologia e cincia, bem como entre
os diferentes tipos de pesquisa.
Verifcar que a inovao tecnolgica um processo que

passa pela gerao do conhecimento e sua aplicao, e
que os projetos inovadores so os principais geradores
de tecnologia.
Sees de estudo
Seo 1 Inovao tecnolgica: fonte de novos
projetos.
Seo 2 Identifcando oportunidades.
Seo 3 Motivao para o projeto.
Seo 4 Quais so os tipos de projeto?

46
Nesta unidade voc vai conhecer como nascem os projetos, sejam
eles pequenos empreendimentos pessoais ou grandes projetos
transformadores de uma era tecnolgica.
Vamos reetir sobre a inuncia da cincia e da pesquisa como
geradores tecnolgicos, os quais passam pelo desenvolvimento
de projetos especcos. preciso considerar que os ambientes
de grande desenvolvimento tecnolgico e, por conseqncia
econmico, so justamente aqueles onde acontece a pesquisa
cientca e acadmica, voltadas para a gerao do conhecimento.
E mais: o papel das empresas neste processo, sejam grandes
ou pequenas, e como o empreendedorismo de inovao
importante para o crescimento e manuteno empresarial.
Isso tudo, no entanto, no possvel sem o suciente nvel de
motivao, que nasce muitas vezes de uma necessidade bsica,
mas que para existir precisa daqueles lderes que enxergam
viabilidade onde muitos outros s percebem riscos e diculdades.
Foi com essas idias que esta unidade foi escrita. Convido voc a
participar e contribuir!
SEO 1 Inovao tecnolgica: fonte de
novos projetos
Os projetos das reas tecnolgicas nascem de uma
sucesso de avanos no conhecimento humano. Tais
conhecimentos vo se acumulando e uns se servem dos
outros para avanar sempre mais, seja questionando-
os, seja aprimorando-os e transformando-os. Como
voc j estudou na unidade anterior; projetos podem
acontecer em reas muito diversas. Porm, agora o
nosso foco vai recair sobre como eles se do nas reas
de tecnologia.
Nesta seo voc vai conhecer as fontes cientcas e tecnolgicas
dos projetos, e de que forma os conhecimentos so gerados na
47
Unidade 2
busca de soluo de problemas. Como voc viu, projetos nascem
para solucionar problemas do mercado, das pessoas, das empresas.
Para se ter um projeto preciso haver um sonho. Algum tem
que imaginar algum tipo de soluo, algum tem que sugerir
uma idia. Mas as idias no surgem do nada, e em se tratando
de projetos tecnolgicos elas surgem de duas fontes:
necessidades;
conhecimentos e tecnologias disponveis.
Veja na gura a seguir, inspirada no trabalho de Jay Paap (2004),
um modelo de inovao tecnolgica. Necessidades que surgem
no negcio, ou na vida diria das pessoas, ou de renovao do
mercado, enm, problemas que surgem todos os dias, esto
constantemente nos desaando pela busca de solues. Quando
algum aceita esse desao, e simultaneamente h conhecimentos
cientcos e tecnolgicos disponveis, idias surgem. Uma
criteriosa seleo dessas idias pode levar ao desenvolvimento de
novos produtos ou novos processos que, se alcanarem sucesso,
sero amplamente utilizados e difundidos.
Necessidades
Conhecimento
e Tecnologia
Novas idias Seleo
Desenvolvimento
do projeto
Uso e
difuso
Figura 2.1 - Um modelo de inovao tecnolgica.
A transformao dessas idias em produtos ou
processos considerada uma Inovao Tecnolgica,
e pode ser algo to simples como uma nova maneira
de assentar tijolos numa construo, ou to complexa
quanto lanar uma nova linguagem de programao.
1.
2.
48
- Para entender melhor como o conhecimento cientco e as tecnologias
podem levar a projetos de inovao tecnolgica, leia um pouco mais
sobre esses conceitos.
Cada ciclo tecnolgico tem origem numa inovao. A inovao
tecnolgica pode ser caracterizada como a primeira vez que se
utiliza um determinado produto, processo, sistema ou servio,
sejam novos ou melhorados, introduzidos num determinado
mercado, ou numa produo. O centro de gravidade da inovao
tecnolgica a empresa.
Veja por exemplo o caso do CD Compact Disc. Todo
um novo ciclo tecnolgico de gravaes musicais,
flmes, arquivamento de dados, est marcado
pela inovao do uso do laser. Antes disso, se fazia
gravao de dados em ftas magnticas. Esse novo
ciclo tecnolgico teve origem num projeto de
desenvolvimento de um grupo de engenheiros da
Philips e da Sony. O desafo que eles se propuseram
resolver era o da gravao de imensa quantidade de
dados num pequeno espao, e que uma vez gravados
no pudessem se perder, como acontecia com as ftas
magnticas.
O processo de inovao tecnolgica compreende a identicao
de uma necessidade ou de uma oportunidade. Uma necessidade
de um determinado grupo de usurios como, por exemplo,
dentro de uma planta fabril onde um novo equipamento ou novo
processo se faz necessrio para dar agilidade a uma produo. Ou
uma oportunidade de negcios, como a telefonia sobre a Internet,
que exige projetos especiais de desenvolvimento.
A gerao ou adaptao tecnolgica para atender
essa necessidade ou oportunidade tambm um
processo de inovao.
No entanto, para que essa inovao acontea preciso ter a
capacidade de pesquisa, desenvolvimento e engenharia, para
fazer a devida gerao ou adaptao tecnolgica, bem como
a capacidade de conduzir essa tecnologia ao mercado ou
sociedade que a demandou. No s isso, pois levar depois ao
mercado exige tambm aes competitivas, ou seja, o projeto
49
Unidade 2
estar realizado quando cumpriu prazos e cumpriu demandas antes
do que a concorrncia. Fazer tudo certo e chegar depois fracasso.
Os processos inovativos so bastante complexos, pois esto
ligados ao desenvolvimento de projetos nas reas de engenharia e
tecnologia avanadas, e com isso podem apresentar as seguintes
incertezas:
So irregulares, quando h diferentes etapas de
trabalho, possibilidades de retrocessos, re-anlises
constantes etc.
So de alto risco, quando no h certeza de que
correspondero ao que originalmente foi imaginado.
So excessivamente lentos ou prolongados, com
resultados que demoram para chegar ao mercado, muitas
vezes comprometendo sua receptividade.
A inovao tecnolgica atualmente assunto da poltica nacional,
e grande ateno est sendo dada a ela neste incio de sculo,
tendo em vista que projetos originais na rea podem criar grande
diferencial e valor agregado, com grande ganhos econmicos e
distribuio de renda.
No entanto, o tipo da inovao divide projetos em trs linhas
principais:
1) Projetos de inovao bsica ou radical, que constituem
uma mudana histrica e geralmente so decorrentes de
descobertas cientcas, dando origem a novos produtos,
novos processos ou servios, qualitativamente diferentes
dos produtos, processos ou servios anteriormente usados.
Essa categoria de inovao considerada como sendo
empurrada pela cincia, pois novos conhecimentos
cientcos literalmente foram o desenvolvimento de
tecnologias.
Exemplo de projeto de inovao tecnolgica
bsica foi o que deu origem aos transistores (com
os conhecimentos cientfcos sobre materiais
semicondutores), tambm o caso das fbras ticas
(transmisso de ondas de luz), sistema just in time na
produo industrial, o uso do laser na medicina etc.

50
2) Projetos de melhoria ou de inovao Incremental;
o que produz melhoria em tecnologias existentes, mas
no altera suas caractersticas fundamentais, ou seja, no
parte de novos conhecimentos cientcos que foram sua
existncia, mas antes so puxados pela demanda, quer
dizer, a demanda tecnolgica que fora uma inovao,
e por isso ela chamada de incremental, pois coloca um
incremento sobre a tecnologia j existente.
Um exemplo tpico de melhoria incremental o que
vem sendo feito nos computadores pessoais, os PCs,
pois constantemente so feitas modifcaes no
gabinete visando a melhorar sua compatibilidade
eletromagntica ou dissipao de calor; outro
exemplo so as modifcaes feitas nas linhas de
produo dentro das fbricas, visando a maior
qualidade do produto fnal ou maior quantidade de
produo.
3) Projetos de inovao menor, ou seja, so aqueles que
no alteram qualitativamente os produtos, mas apenas
alteram suas relaes com o mercado. Basicamente
so melhorias superciais na tecnologia e tambm
so puxados pela demanda, pois o mercado dene
tendncias de consumo, que demandam desta forma
algumas modicaes e adaptaes no produto.
Um exemplo tpico de inovao menor, mas
certamente muito importante, so as mudanas
de design de um produto, ou de ergonomia

(como temos visto recentemente com os telefones
celulares), mas tambm as mudanas de resistncia da
embalagem (no caso de alimentos), e muitos outros.
Por essa diviso, voc percebe que os projetos de inovao
tecnolgica so gerados por foras que vm de dois lados: de
um est o avano cientco, e do outro esto as necessidades
das pessoas e do mercado. Se olharmos com mais ateno para
a Cincia, vamos perceber que ela tambm tem seu progresso
muitas vezes baseado em projetos, os chamados projetos de
pesquisa e desenvolvimento P&D.
A ergonomia estuda as relaes
entre os seres humanos e as
mquinas, buscando uma interao
de qualidade tima e de segurana.
51
Unidade 2
Em nossa sociedade a cincia assumiu um papel importantssimo,
e a gura do cientista praticamente surge como a de algum
desassociado da realidade cotidiana. Esta imagem falsa e
nasce de uma viso deturpada do que seja a cincia e de como as
pessoas atuam nesse campo.
Como a cincia deve ser considerada?
uma instituio social, bem comum de todas as pessoas;
um mtodo para adquirir conhecimentos;
uma tradio que acumula conhecimentos adquiridos;
um fator que apia o desenvolvimento e a manuteno da
produo de bens e de servios;
uma inuncia fundamental no comportamento do ser
humano.
A cincia combina teoria e prtica e tem suas prprias formas
de comunicar, sua metodologia e seus critrios de sucesso, que
so diferentes de outras atividades humanas. A cincia est
vinculada a uma sociedade e, portanto, vinculada aos valores
desse ambiente social e, certamente, isso determina uma ideologia
qual est vinculada. Vem desde muito antes dos gregos, e se
constituiu a partir de um conjunto de conhecimentos, passados
de gerao a gerao, que se transformou na raiz da atual cincia.
Para que a cincia se transformasse na atividade como a
conhecemos hoje, foi preciso separar a teoria da prtica, ou
seja, separar o trabalho do pensamento do trabalho manual.
Essa separao comeou a acontecer a partir do surgimento
das sociedades escravistas. Com o uso do trabalho escravo
comearam a surgir pessoas com tempo livre para teorizar
sobre as coisas da natureza. A cincia possvel apenas com o
pensamento terico, e esse tipo de pensamento distinto de
concepes religiosas, loscas ou artsticas.
Certamente h teorias no pensamento religioso, na losoa
especialmente, porm esses modelos de pensar no utilizam
mtodos cientcos, o que os distingue da cincia (e os projetos
que viro a partir da).

52
A introduo do mtodo cientco se deu na Grcia, quando os
conhecimentos comearam a sofrer uma:
Categorizao (diviso dos campos do conhecimento).
Sistematizao (colocou-se uma lgica para relacionar os
conhecimentos).
Teorizao (argumentos, concluses e conceitos tericos
foram sendo colocados para as diversas categorias de
conhecimento).
O retorno causalidade religiosa, durante o perodo da era
medieval, fez com que houvesse um retrocesso cientco. A
causalidade religiosa a que explica todos os acontecimentos
da natureza como de origem sobrenatural ou espiritual, sendo,
ento, desnecessrio buscar causas naturais para explicar os
fenmenos (como vinham fazendo os gregos e os romanos). Mas
depois das grandes navegaes, das descobertas, e da retomada
do estudo dos clssicos gregos, a cincia voltou a ocupar um
importante e fundamental lugar na histria da humanidade (e
por isso que voc est fazendo este curso!).
A cincia uma atividade e desta forma tem seus:
atores: todos aqueles envolvidos num determinado
projeto de estudo e produo de conhecimentos; so os
membros da equipe;
objetos de investigao e estudo: a natureza e seus
fenmenos, o homem, sistemas articiais, tcnicas, a
sociedade, o pensamento, os prprios mtodos cientcos etc.;
objetivos: obter informaes, novos conhecimentos e
aplicaes para os objetos de estudo;
meios materiais ou recursos: as informaes, os recursos
humanos, o lugar de trabalho;
resultados, que so os conhecimentos cientcos bsicos,
ou fundamentais, e tambm as tcnicas e tecnologias
desenvolvidas;
mtodos e processos de trabalho: que a articulao
coordenada e objetivada dos membros da equipe, dos
meios e dos objetos, visando obteno dos resultados
(SENZ, 2002).

53
Unidade 2
O mtodo cientco a ordem denida de atividades,
organizadas de maneira consciente e aplicadas com constncia
para chegar aos resultados almejados: conhecimentos,
demonstrao de verdades, novas tcnicas etc. Se olharmos com
ateno, vamos perceber que esse mtodo justamente o que
aplicaremos para a gesto de projetos. Quatro passos crticos
esto colocados no mtodo cientco para a soluo de um
problema. Veja quais so:
Denir o problema, ou seja, caracterizar adequadamente
os seus limites, saber o que se pretende resolver com a
maior exatido possvel.
Descrever o problema, determinando onde est inserido
e com que outros fatos o problema est relacionado. A
descrio do problema deve ser feita com o mximo de
detalhamento.
Formular hipteses de soluo, que possam ser estudadas
e testadas dentro do escopo do trabalho. Nesta etapa ser
criado um plano de trabalho.
Executar o projeto de pesquisa propriamente dito,
vericando as hipteses, testando as possibilidades,
conrmando e rejeitando solues intermedirias, a m
de obter os resultados esperados.
Voc Sabia?
Cincia muitas vezes confundida com tecnologia.
Apesar de muitos pontos em comum, cincia e
tecnologia no so a mesma coisa. Assim como a
cincia, a tecnologia uma instituio social, ou
seja, algo que nasce no seio da sociedade e por
sua necessidade. um conjunto de conhecimentos
(cientfcos, empricos), habilidades e procedimentos
capazes de produzir, distribuir, comercializar e utilizar
bens e servios. Porm, ao contrrio da cincia, a
tecnologia pode ser entendida como a aplicao dos
conhecimentos existentes.
1.
2.
3.
4.
54
O avano tecnolgico (que vem com as inovaes tecnolgicas)
pode ocorrer com ou sem a cincia, pois alm do conhecimento
cientco, o conhecimento prtico tambm uma fonte para seu
desenvolvimento.
Um exemplo de avano tecnolgico, independente
da cincia, ocorreu no incio da revoluo industrial,
quando houve o desenvolvimento da mquina a
vapor no sculo XVIII. Isso se deu sem o conhecimento
cientfco das Leis da Termodinmica, que viriam a ser
descritas apenas no sculo XIX a partir de 1850. Mas a
alta tecnologia de hoje dependente da cincia, no
possvel avanar sem a contribuio da pesquisa
cientfca.
Hoje, o descobrimento de novas leis da natureza e novas teorias
possibilitam o surgimento de novas tecnologias. Por sua vez
as novas tecnologias criam novos objetivos de estudo, alm de
permitir instrumentos mais poderosos para o trabalho cientco,
o que as torna interdependentes. A gura a seguir mostra essa
interdependncia e como isso tem permitido a revoluo tcnico-
cientca que vivemos.
A cincia como pr-requisito fundamental
Tecnologia fornece diretrizes
Atual revoluo tcnico- cientfica
Figura 2.2 - Revoluo tecnolgica como interao entre cincia e tecnologia.
Essa revoluo tcnico-cientca se d por meio de diversos
projetos de pesquisa e desenvolvimento, que podem ser
classicados da seguinte forma (SENZ, 2002):
55
Unidade 2
Pesquisa bsica: pesquisa original, terica ou
experimental, com o propsito de adquirir conhecimento
sobre determinado fenmeno, porm sem uma nalidade
prtica em vista ( o que se chama da pesquisa pura).
Pesquisa aplicada: tambm original, mas dever
resultar numa aplicao por meio da obteno de novos
produtos, processos ou mtodos; esse tipo de pesquisa se
d por meio de projetos multidisciplinares; um exemplo
desse tipo acontece atualmente com o desenvolvimento
de um padro de TV Digital no Brasil.
Desenvolvimento tecnolgico: parte de conhecimentos
existentes e visa desenvolver produtos, processos ou
mtodos; o desenvolvimento de um novo software
tipicamente um desenvolvimento tecnolgico.
Melhoria de processo/produto: trabalho que visa a
aprimorar algo existente e j desenvolvido, geralmente
devido a modicaes da tecnologia e do mercado;
um exemplo deste caso a constante melhoria de
softwares por meio de novas verses, adaptadas s novas
necessidades do mercado ou devido a modicaes do
hardware.
Assistncia tcnica e tecnolgica: atividade que se
destina a manter produtos e processos de acordo com as
normas e os padres de qualidade de uso.
Veja no quadro a seguir essa classicao em cinco etapas,
e tambm a origem de cada etapa na coluna Entrada. Na
coluna Sada esto os resultados obtidos em cada etapa, e na
coluna Retroalimentao voc pode ver que o resultado de
determinado projeto pode ser uma nova entrada de pesquisa e
desenvolvimento, dando origem a diferentes projetos.

56
ETAPA ENTRADA SADA RETROALIMENTAO
Pesquisa bsica
Idias de pesquisadores,
dos laboratrios, linhas de
pesquisa.
Hipteses, descobertas,
teorias, artigos cientcos,
livros, equaes.
Outras pesquisas bsicas,
solicitaes externas,
invenes, novos problemas.
Pesquisa aplicada
Sada da pesquisa aplicada,
idias de pesquisadores,
dos laboratrios, de
empresas, de engenheiros,
necessidades sociais.
Patentes, invenes,
maquetes, prottipos,
softwares de simulao.
Outras pesquisas bsicas
e aplicadas, solicitaes
externas, novos problemas
tcnicos e cientcos,
fracassos anteriores.
Desenvolvimento
tecnolgico
Idias de engenheiros e de
empresrios, invenes,
resultados de pesquisas e
outros trabalhos.
Projetos, planos, prottipos,
novos produtos e processos,
especicaes.
Novos problemas tcnicos e
cientcos, necessidades de
inveno, relatrios de xitos
e fracassos.
Melhoria de processo
/ produto
Produtos e processos
em uso, necessidades
de usurios, idias de
engenheiros e empresrios.
Produtos e processos
modicados, novo design,
modicaes de fabricao,
automao de processos.
Necessidades de alterao
em linhas de produo,
modicao comercial, novos
desejos de consumo.
Assistncia tcnica e
tecnolgica
Necessidades de norma e
de legislao, padres de
qualidade, manuteno,
bugs.
Calibraes, ensaios,
padronizaes.
Percepo de melhorias,
novos bugs.
O desenvolvimento tecnolgico uma atividade
multidisciplinar, e as tecnologias no podem ser
consideradas como atividades isoladas ou unidades
independentes geralmente elas so pacotes
tecnolgicos.
Esse conceito de pacotes tecnolgicos muito importante para
o desenvolvimento de um projeto, pois mostra claramente a
necessidade de vrios tipos de relacionamento e vrios tipos de
competncias na equipe. Essa uma noo de sistema, onde
diversas tecnologias sustentam-se de forma global e, para isso, o
desenvolvedor do projeto deve considerar sempre o conjunto de
relaes. Outra questo importantssima que voc deve conhecer
que as tecnologias tm um ciclo de vida, que pode ser longo
ou no. Mas toda tecnologia perece, ela nita. A cincia, ao
contrrio, busca verdades perenes, leis fundamentais e durveis,
independentes no espao e no tempo.
Quadro 2.1 Painel sobre diferentes modelos de pesquisa, suas entradas e sadas.
57
Unidade 2
A obsolescncia de uma determinada tecnologia
acontece, por exemplo, quando h o aparecimento de
uma nova tecnologia, que a substitui, ou h mudanas
de preos ou no fornecimento de insumos. Pode
tambm acontecer de os consumidores mudarem
seus hbitos, ou os competidores passaram frente,
fornecendo produtos com melhorias que voc no
dispe.
Veja com ateno o grco da gura a seguir. Ele mostra o ciclo
de vida de determinado produto. Se tomarmos as trs primeiras
fases como as etapas de projeto, veremos que envolve muitos gastos,
especialmente na fase de introduo no mercado. A partir da, h
o amadurecimento e o crescimento das vendas do produto gerado
no projeto, at uma fase de estabilizao seguida da crise e morte.
A fase de estabilidade pode durar se, por exemplo,
novos projetos de melhorias forem introduzidos,
retardando ao mximo a chegada da inevitvel crise.
. Pesquisa
. Desenvolvimento
. Engenharia
. Investimento e
Produo
. Introduo no
mercado
. Maturao . Saturao . Crise
+$
-$
Tempo
Figura 2.3 Ciclo de vida de produtos tecnolgicos.
58
A durao maior ou menor da vida do produto depende de vrios
fatores. Analise os trs exemplos apresentados na gura a seguir.
+$
Tempo
A
B
C
A - tecnologia de impacto econmico, mas de envelhecimento precoce (softwares, aplicativos);
B - lento crescimento, mas de grande durao, permitindo ganhos contnuos (indstria dos computadores);
C - pequeno impacto e vida curta (alguns softwares).
Figura 2.4 Diferentes ciclos de vida relacionados ao impacto econmico.
O produto da curva A chegou a um enorme faturamento, mas
teve um ciclo muito curto. O exemplo dado de certos softwares
ou aplicativos, que surgem para atender uma demanda especca
e rapidamente caem em desuso. A curva B mostra outro caso,
tambm com um bom impacto econmico porm com uma vida
bem mais longa.
o caso, por exemplo, da indstria de computadores,
e poderamos dizer, tambm, da indstria de
aparelhos de telefonia celular. Ano aps ano a
indstria se mantm, com melhorias constantes e
desenvolvimento tecnolgico baseado em pesquisas
cientfcas.
J a curva C mostra um caso diferente, onde o impacto
econmico foi pequeno e teve uma durao curta (mas maior que
a de A!).
59
Unidade 2
- Bem, at aqui voc tive uma viso geral das fontes de conhecimento
cientco e tecnolgico, e como eles se desenvolvem para gerar mais
conhecimento e mais tecnologia. Na seo 2 voc vai identicar onde
pode haver oportunidades de novos desenvolvimentos, pois essas
oportunidades podero ser as fontes de novos projetos.
SEO 2 Identicando oportunidades
Certamente no existe um manual de novidades a ser
explorado, onde pudssemos consultar e vericar onde esto os
projetos que daro origem s grandes inovaes.
A busca por oportunidades de novos projetos depende, em
primeiro lugar, de uma postura investigativa por parte de cada
um de ns.
Esse olhar atento deve estar voltado para todos os detalhes.
Muitos imaginam que os grandes projetos so aqueles que vo
revolucionar uma empresa ou um mercado inteiro, geralmente
imaginando inovaes de grande impacto. A realidade nos
mostra algo muito diferente: pequenas alteraes, ou mesmo
idias aparentemente sem valor, acabam provocando modicaes
profundas em um processo industrial ou nos hbitos do
consumidor.
Para identicar oportunidades e gerar novas idias preciso
ter uma mente sem pudor (no pense em bobagem!). As
crianas so um bom exemplo disso. Sempre por descobrir o
mundo, tentam o tempo todo entender o que acontece
na natureza e tm idias mirabolantes para resolver
quaisquer problemas. Mas aos poucos a ordem e a
disciplina da sociedade vo tolhendo essa caracterstica
despudorada de explicar o mundo, colocando em
seu lugar uma organizao esquemtica e que permite
poucas distores. Aqueles que conservam algo dessa postura
aberta geralmente se destacam por procedimentos criativos,
mesmo que s vezes chutem algumas bolas fora mas no se
importam com isso, logo esto de novo tentando.
60
Na verdade as oportunidades de novos projetos esto bem
nossa frente, basta sabermos ler. Porm, apenas identicar uma
oportunidade no tudo: para fazer algo com essa oportunidade
preciso dispor dos recursos, tempo, tecnologias etc.
- Sobre isso discutiremos mais tarde. Agora estude um pouco mais sobre
como as oportunidades surgem dentro do campo das tecnologias.
O diagrama da gura a seguir nos mostra trs aspectos inter-
relacionados do avano tecnolgico, que so:
A descoberta, que corresponde ao resultado de um
projeto de pesquisa cientca e geralmente no est
associada a uma necessidade comercial.
A inveno j est mais prxima da realidade do
mercado, porm ainda com uma viso de criar um
produto, sem a certeza de que ter aproveitamento
econmico.
A inovao, por sua vez, est intimamente atrelada
a uma racionalidade econmica, pois nasce das
necessidades vindas do mercado, seja diretamente do
consumidor, seja da empresa interessada em atuar sobre
esse consumidor.
Descoberta Inveno Inovao
Corresponde pesquisa
cientfica, busca a verdade
e a compreenso dos
fenmenos da natureza.
Corresponde pesquisa
aplicada, busca um novo
produto e uma
racionalidade tcnica.
Inteno de novas
tecnologias, mas com uma
racionalidade econmica.
Figura 2.5 Diferenas entre descoberta, inveno e inovao.
Boa parte das descobertas cientcas pode levar muito tempo
at ser aproveitada em algum projeto prtico e, por esse motivo,
so criticadas como sem serventia. Esse tipo de crtica (ou
sarcasmo) comum em nosso pas, infelizmente. Professores
e pesquisadores universitrios sofrem gozaes por gerarem
dissertaes e teses que apenas serviriam para encher as
estantes. Esse tipo de comentrio um enorme equvoco.

61
Unidade 2
H teoremas que levaram sculos at serem aproveitados em
aplicaes.
Um exemplo importante a lgebra Booleana, de
1847, base da atual informtica. Outro a Teoria da
Relatividade, de 1905, aproveitada muito tempo
depois no desenvolvimento da energia nuclear.
Como voc j sabe, os conhecimentos cientcos so perenes
e estaro sempre disponveis para permitir o avano do
conhecimento.
J a maioria das invenes acaba numa prateleira, sem utilidade
prtica e sem algum industrial interessado. Poucas obtm sucesso,
especialmente aquelas que nascem de idias aparentemente
brilhantes, mas que se esqueceram de perguntar: a quem
interessa? E a que preo?
Pude observar uma Feira de Inventores onde vrios objetos
eram bastante curiosos, os inventores eram talentosos, mas
cujo resultado prtico foi nulo. Motivo de frustrao para os
inventores, certamente o equvoco estava na organizao da
Feira, mais preocupada em promover uma festividade e algumas
personas do que propriamente em orientar os desenvolvedores
para a atividade industrial. (Apesar de tudo soube que a tal Feira
ter novas edies, ano aps ano.)
Por outro lado a inovao tecnolgica, objetivo
da imensa maioria dos projetos, orientada para
o mercado, seja a partir de novos conhecimentos
cientfcos que possibilitam tal inovao (ou seja,
empurram a inovao), seja a partir de novas
demandas que puxam tal desenvolvimento.
Quando se diz que a inovao do modo empurrado pela
cincia, isso acontece geralmente sem uma demanda especca
da sociedade. tambm chamada de modo ofertista, pois
oferta novidades e um modelo de produo linear, onde cada
etapa s comea quando a anterior j est nalizada. O centro de
gravidade da inovao passa a ser a universidade, o instituto ou o
centro de Pesquisa & Desenvolvimento, e no a empresa, que ca
em segundo plano. Isso acaba isolando tais centros de pesquisa,
62
que por no estarem prestando ateno no que acontece no
mercado, consideram terminada sua tarefa ao concluir o projeto.
A gura a seguir um esquema genrico de projeto de inovao
tecnolgica empurrada pela cincia, sendo que o princpio est
numa idia e num mdulo de Pesquisa & Desenvolvimento. Na
seqncia vm os novos conhecimentos tecnolgicos e uma oferta,
que s ento parte em busca de uma necessidade e uma demanda.
IDIA
Novos
conhecimentos
tecnolgicos
Oferta
tecnolgica
Necessidade
Social
Demanda
de Mercado
Pesquisa e
Desenvolvimento
Conhecimentos
existentes
Tcnicas de
engenharia
Figura 2.6 Modelo genrico de inovao empurrada pela cincia.
O caso oposto acontece quando uma oportunidade
de projeto tecnolgico nasce do mercado, ento
dito como puxado pela demanda. Este um
comportamento gerado pela demanda empresarial,
ou seja, deve haver esse desejo de inovao por
parte da indstria, a qual percebeu uma demanda e
pretende supri-la.
Em pases ou regies que tm a indstria pouco desenvolvida,
ou sem a cultura da inovao, no h esse tipo de solicitao de
projetos inovadores. Para que esse modo exista so necessrias
polticas de cincia e tecnologia que propiciem esse tipo
de demanda ou, o que mais difcil nos pases pobres ou
perifricos, uma cultura industrial empreendedora genuna.
O risco que esse modo corre o de acreditar que tudo pode ser
resolvido apenas pela inovao tecnolgica, esquecendo da cincia
e de dar condies de existncia pesquisa bsica, gerando o
truncamento da criatividade cientca.
63
Unidade 2
A gura a seguir representa um esquema tpico de gerao de
inovao tecnolgica a partir de demandas de mercado e de
necessidades sociais. A partir disso e havendo disponibilidade
de tecnologias, h o surgimento da idia de projetos, e s ento
acontece o desenvolvimento at chegar numa produo capaz de
atender aquela demanda original.
Necessidade
Social
Tecnologia
necessria
IDIA
Novos
conhecimentos
tecnolgicos
Produo
Demanda
de Mercado
Pesquisa e
Desenvolvimento
Conhecimentos
existentes
Tcnicas de
engenharia
Figura 2.7 Modelo genrico de inovao puxada pela demanda.
Atualmente o que se busca uma complementao desses dois
modos que so, ento, chamados de modos de integrao ou de
sistemas em rede, pois o desenvolvimento tecnolgico o tempo
todo retroalimentado com informaes do mercado e de novos
conhecimentos cientcos.
Para que um projeto de inovao tecnolgica tenha sucesso
preciso que:
a necessidade social esteja vinculada a uma demanda
atual ou potencial, ou seja, alm de querer ter, o usurio
precisa ter condies para isso;
exista uma estratgia empresarial e competitiva para
colocar o produto no mercado;
haja capacidade tcnica, cientca, produtiva e comercial
para desenvolver o produto;

64
sejam alocados recursos nanceiros convenientes;
as equipes de pesquisa, engenharia e comercial trabalhem
de forma interativa;
haja uma sistemtica comercial e de marketing adequada,
bem como ps-venda, manuteno e aperfeioamento
constantes;
seja compatvel com os critrios dos consumidores;
a complexidade relativa seja baixa e exista a possibilidade
de avanos contnuos;
o impacto ambiental e social seja positivo.
Com todas essas condies de contorno percebe-se que uma
boa oportunidade de projeto nasce quando est inserida num
sistema tecnolgico, que algo bem maior do que simplesmente
a inovao tecnolgica do produto. Tal sistema tecnolgico pode
ser modelado de acordo com a gura, onde um grande nmero de
relaes entre diferentes mdulos est presente. Projetos inovadores
podem surgir em qualquer um desses mdulos, num conjunto
deles, e nos casos mais complexos envolvendo todo o sistema.
IDIA
Pesquisa e
Desenvolvimento
Conhecimentos
existentes
Tcnicas de
engenharia
Produo e
Distribuio
Usurios
Tecnologia de Produo,
Distribuio e vendas
Tecnologia de
Consumo, social
Necessidade
Social
Demanda
de Mercado
Servios tcnicos
Fornecedores
Competidores
Figura 2.8 Modelo de Sistema Tecnolgico.

65
Unidade 2
Tendo ocorrido o surgimento de uma oportunidade de projeto
dentro de tal sistema, um modelo genrico de desenvolvimento
tecnolgico pode ser apresentado como na seguinte gura, onde
necessidades e oportunidades tcnicas se juntam para gerar idias
e denir, ento, um caminho, que pode ser trilhado ou no, para
o desenvolvimento de um novo projeto.
Necessidade
explcita
Oportunidade
tcnica
Necessidade
latente
Gerao de
idias
Escolha de
alternativas
Estudos de
Mercado
Estudos de
viabilidade
Elaborao
de projeto
Obteno de
recursos
Incio do projeto
Figura 2.9 Gerao tecnolgica uma representao.
- Na seo seguinte, voc vai conhecer o que pode motivar um projeto
para que seja, de fato, realizado.
66
SEO 3 Motivao para o projeto
Se um projeto tem origem numa idia, por causa de uma
necessidade social, comercial ou por um novo conhecimento
tecnolgico disponvel, para que ele possa crescer e chegar etapa
do desenvolvimento e ir at o nal, entregando um resultado
prximo do esperado, ele precisa ter uma motivao que o
alimente.
Diversas so as motivaes possveis, desde o empenho
unicamente pessoal at um contrato abrangente e inviolvel.
Voc agora vai conhecer algumas dessas motivaes, sabendo
antecipadamente que muitas vezes elas esto mescladas no dia-a-
dia dos projetos, umas com mais fora, outras menos.
Algum em uma pequena empresa teve a viso
de um novo produto, que ele acredita ser capaz de
alterar o futuro de sua empresa. Essa viso passa a
ser ento um guia e um objetivo, capaz de motivar
e ajustar cada momento de desenvolvimento do
projeto que ento gerado. Os lderes so muitas
vezes movidos por essas vises, que so perseguidas
constantemente at o fnal, sem descanso. Tal viso
pode surgir na busca de resolver um problema,
pessoal ou empresarial.
Para uma determinada empresa que vem perdendo posies no
mercado, o projeto de um novo produto pode nascer como a
reao ao produto concorrente e que vem se destacando. Essa
reao comercial motiva o nascimento e a execuo do projeto,
geralmente com forte presso por resultados e prazos. uma
motivao reativa.
Por outro lado, a empresa ativa busca sua ampliao no mercado
no apenas pela reao ao que j surgiu, mas pela criao de
novos produtos. Essa cultura criativa dene as empresas que
lideram o mercado, pois constantemente esto criando produtos
inovadores ou lanando novas formas de se relacionar com
seus clientes, o que acaba mudando o comportamento geral
do mercado e as favorece. Como no podia deixar de ser, as
empresas criativas so mais raras do que as reativas, e ambas so
motivadas pela competio.
67
Unidade 2
Nos dois casos anteriores, h uma motivao que o
denominador comum: sucesso da empresa. Esse motivador
movimenta o mundo do capital e est na base do crescimento
econmico. Tambm h o motivador que o sucesso pessoal,
perseguido no pelas empresas, mas pelos indivduos.
Na base do sucesso pessoal um dos grandes motivadores o
ganho nanceiro. O prmio em dinheiro d motivao para
perseguir o projeto at o nal, mesmo que a pessoa muitas
vezes no d valor algum ao projeto em si, mas simplesmente
remunerao.
Fora do campo puramente pessoal ou empresarial, o progresso
social pode ser um grande motivador no desenvolvimento
de projetos. Parece ser esse o caso dos projetos ecolgicos e
ambientalistas, onde um determinado grupo social, interessado
em melhorias locais ou regionais, empreende projetos de carter
especco. Sindicatos, associaes, organizaes civis de interesse
pblico e partes do governo tambm so geradores de projetos
especiais, voltados ao bem-estar social.
SEO 4 Tipos de projeto
Os projetos podem ser classicados em diversas
categorias, e essa classicao vai variar conforme
interesses comerciais, cientcos e industriais, ou
ento conforme graus de diculdade, ou mesmo
conforme o ambiente em que se desenvolvem.
Veja agora algumas dessas possveis divises e, ao
nal, voc vai conhecer uma sistematizao dessas classicaes,
de modo a facilitar uma viso estratgica sobre tipos de projetos.
De acordo com o que voc estudou nas sees 1 e 2 desta
unidade, os projetos podem ser classicados quanto natureza
cientca e tecnolgica e, neste sentido, podem ser, grosso
modo, divididos nos seguintes tipos:
68
Projetos de Pesquisa: so os projetos cientcos, que
geralmente acontecem em universidades e centros de
pesquisa, e nascem da idia de pesquisadores e linhas de
pesquisa j em andamento; podem ser de pesquisa bsica,
quando direcionados a resolver problemas genricos e
tericos, sem aplicao prtica em vista, ou de pesquisa
aplicada, quando voltados a usar uma teoria em alguma
nova aplicao, no necessariamente til de imediato.
Desenvolvimento Tecnolgico: ao contrrio dos
projetos cientcos, os projetos de desenvolvimento
tecnolgico nascem da idia de empresrios e
engenheiros, e esto orientados diretamente ao mercado,
buscando introduzir inovao tecnolgica, seja em
produtos diretamente para a venda, ou em processos de
produo ou comercializao dentro das empresas; por
serem projetos de inovao, esto fortemente associados
ao conhecimento cientco gerado em pesquisas bsicas
e/ou aplicadas (isso explica o vertiginoso crescimento
recente dos pases orientais e do norte europeu,
fortemente baseado em educao).
Engenharia: so os que se baseiam em conhecimentos
e tecnologias dominadas, e esto voltados a construir
prottipos e produtos com aplicao bem denida; os
projetos de engenharia mais comuns que conhecemos so
os da construo civil.
Outra forma de dividir os projetos est relacionada sua origem
institucional. Neste caso no estamos fazendo distino entre
cincia, tecnologia ou engenharia, as sim quanto ao tipo de
instituio que o originou. Uma possvel diviso desses projetos
seria a seguinte:
Comerciais: so os projetos que nascem dentro das
empresas buscando diferencial competitivo no mercado;
pode ser a idia de um novo produto, baseada em
estatsticas e pesquisas realizadas junto ao consumidor,
ou a necessidade de modicao de um processo de
venda ou de produo, com foco em melhoria comercial;
lanamentos de novas embalagens.

69
Unidade 2
Novas verses de software e novas formas de entrega
para o consumidor.
Industriais: muito prximos dos projetos do tipo
comercial, tambm esto objetivando diferencial
competitivo; no entanto so desenvolvidos no interior
da indstria buscando melhorias no processo produtivo
do cho de fbrica, sem um relacionamento direto com
perspectivas comerciais (apesar de estar claro que tais
melhorias vo colaborar na qualidade de todo o sistema);
so projetos que vo desde uma modicao de leiaute
no cho de fbrica, passando por projetos de introduo
de automatismos em mquinas at a criao de novas
mquinas-ferramenta.
Governamentais: os governos so grandes geradores de
projetos, e alguns envolvem toda a sociedade e podem
at mesmo mudar os rumos de uma regio ou de um
pas; em tese nascem das necessidades sociais e em vises
estratgicas para buscar suprir tais necessidades, mas o
que se v geralmente so as vaidades polticas e a viso
limitada como geradores de tais projetos, que muitas
vezes acabam por gastos inteis do dinheiro pblico; mas
certamente h tambm os projetos de sucesso, muitas
vezes polmicos, que so capazes de modicar todo um
panorama histrico, e para no ir muito longe lembro
aqui da construo de Braslia como nova capital do
nosso pas praticamente no serto da regio Centro-
Oeste, redirecionando o uxo do capital e das decises
para o centro da nao, redirecionando os plos de poder
em direo ao interior; e h tambm os projetos de pequeno
porte, igualmente importantes que mudam, por exemplo,
o trnsito de um bairro ou introduzem ali uma rea verde e
de preservao, ou por exemplo a introduo de um sistema
informatizado de pagamento de impostos e taxas.
De fomento: projetos de fomento so tambm, em geral,
governamentais, mas se distinguem um pouco daqueles
por estarem voltados ao desenvolvimento de algum
aspecto da economia e/ou tecnologia, ou seja, buscam
Chamamos de cho
de fbrica o ambiente
onde geralmente esto
instaladas as mquinas
da indstria, e onde o
processo operacional de
produo acontece; no
inclui, por exemplo, as
reas de administrao,
vendas, compras e
projetos.
Do ingls lay-out,
representa um esboo
ou modelo genrico de
disposio de peas,
mveis e equipamentos
num ambiente.
Mquina-ferramenta
aquela que usada para
fabricar outras mquinas,
mais especicamente para
dar forma a objetos slidos
como madeira e metal,
os quais sero usados
como peas em outras
mquinas.
70
criar ambientes favorveis para que a iniciativa privada
se desenvolva; importantssimos por sua caracterstica de
apoio estrutural, um bom exemplo desse tipo de projeto
a criao de parques tecnolgicos e incubadoras de
empresas, fomentadores de novos negcios e de inmeros
outros projetos de inovao dentro dessas empresas ou
idias nascentes.
Acadmicos: so os projetos que se desenvolvem dentro
do ambiente das instituies educacionais, tais como
monograas e teses, bem como softwares e outros
produtos, caracterizando-se por uma relativa distncia
das aplicaes industriais, e digo relativa porque isso
depende de cada regio e pas; no Brasil ainda h uma
distncia considervel entre indstrias e universidades,
infelizmente com um sentimento de desconana mtua
entre as partes, provavelmente devido s heranas de
uma sociologia de esquerda no pensamento nacional,
incapaz de perceber uma interatividade positiva entre as
partes; apesar dessa herana um relativo progresso vem
acontecendo, forado por um lado pela carncia de recursos
governamentais para novos projetos, e por outro lado pela
necessidade industrial em se distinguir tecnologicamente da
concorrncia mundial cada vez mais presente.
possvel fazer uma separao de tipos de projeto tambm
quanto ao seu impacto no conhecimento ou no mercado,
independente de sua origem ou de sua natureza tcnica. Essa
diviso nos ajuda e ver determinado projeto em relao sua
ambio:
Impacto tecnolgico ou Breakthrough: tipo de projeto
que se caracteriza por resultar em considervel impacto
em uma tecnologia ou em um mercado, modicando
hbitos de consumidores e alterando completamente
a nalidade da tecnologia anterior; um tipo raro
de projeto, porque intrinsecamente de risco, no se
sabendo determinar se ter o sucesso, o qual muitas vezes
nem era esperado.
Cabe aqui ressaltar que a Unisul

criou e mantm uma incubadora,
com o apoio do governo de Santa
Catarina.
71
Unidade 2
Introduo dos compact discs no mercado musical,
que praticamente aboliu o uso de discos de vinil e
ftas magnticas, ou o caso do uso da transmisso por
rdio na telefonia, que em poucos anos est mudando
completamente o cenrio das telecomunicaes
mundiais.
Plataforma ou sistema: projeto que envolve inmeros
conhecimentos e mdulos diferentes, geralmente
composto por uma srie de pequenos projetos (os
derivados), que sero depois arranjados num sistema
nico e maior; tipicamente multidisciplinar, envolvendo
conhecimentos diversos e vrias reas.
O atual projeto de desenvolvimento do sistema de
televiso digital brasileiro.
Isolados: so aqueles projetos independentes, no
vinculados a um sistema e nem derivados de uma
necessidade de melhoria; basicamente so os projetos
criados por indivduos (como o desejo de uma casa, por
exemplo) ou de uma pequena empresa para lanar um
novo produto no mercado.
Projetos derivados: este tipo o conjunto que contm a
grande maioria dos projetos, que se caracterizam por ser
projetos pequenos e de prazo curto, derivados de outros
maiores ou de requisies de melhorias em sistemas j em
funcionamento regular.
As criaes de novos leiautes de embalagem, um
determinado mvel ou novo dispositivo em uma
mquina-ferramenta.
Recentemente Dov Dvir et al. (2004) desenvolveram e passaram
a aplicar um esquema genrico para denir tipos de projetos.
Esse esquema, ou framework, foi denominado de Modelo UCP,
sobre o qual possvel classicar os diversos tipos de projetos
tecnolgicos.
Iniciais de Uncertainty,
Complexity e Pace,
que poderamos aqui
traduzir por Incerteza,
Complexidade e Prazo.
72
A gura a seguir mostra esse modelo como uma congurao
de trs dimenses, onde cada eixo representa uma das variveis,
tendo cada projeto uma posio nesse espao, conforme sua
posio relativa em relao a cada eixo. Devido sua utilidade
na denio dos tipos de projeto, vamos detalhar um pouco
mais o modelo de Dov Dvir et al, descrevendo os eixos e suas
sub-divises.
Complexidade
Prazos
Incerteza
Posio relativa do objeto
Figura 2.10 Modelo UCP para classifcao de projetos (DVIR et al., 2004).
O eixo da Incerteza nos apresenta os diferentes nveis de
incerteza que um projeto pode assumir, seja quanto ao tempo
necessrio para sua excuo, quanto aos recursos e equipe
que sero alocados, a tecnologia disponvel e mesmo sobre a
qualidade e sucesso do resultado nal. Nesse sentido, os criadores
do Modelo UCP dividem os projetos em quatro tipos:
Tipo A Baixa Tecnologia: so aqueles projetos
baseados em tecnologias existentes e dominadas, onde
no h necessidade de nenhum desenvolvimento ou
conhecimento adicional, a no ser os j disponveis; os
projetos de construo civil so tpicos deste nvel, pois o
grau de incerteza tecnolgica mnimo, e o mesmo tipo
de projeto j foi realizado inmeras vezes, no havendo
o que inventar; por esse motivo a gesto deve ser rgida e
no permitir variaes no plano original.
Tipo B Mdia Tecnologia: tambm so baseados
em tecnologias existentes, porm podem incorporar
alguma novidade no desejo de criar algum diferencial

73
Unidade 2
para o produto resultante; esse tipo de projeto tem
poucas incertezas e geralmente acontece em indstrias
tradicionais e bem estabelecidas onde o desenvolvimento
tecnolgico ocorre lentamente, como o caso da
indstria automobilstica ou de mquinas pesadas
onde, apesar do domnio tecnolgico, tambm
preciso incorporar algum novo dispositivo ou elemento;
devido s poucas incertezas a novidade incorporada
rapidamente ao produto, geralmente depois de um ou
dois ciclos de desenvolvimento do projeto.
Tipo C Alta Tecnologia: so os projetos onde as
tecnologias a serem empregadas so novas, apesar de j
existirem quando o projeto se inicia; a alta tecnologia se
expressa porque tais tecnologias pela primeira vez estaro
integradas num determinado produto ou processo, e o
desenvolvimento de tal projeto passa a ter uma srie de
incertezas, caracterizando-se por ter longos perodos de
planejamento, modelagem, desenvolvimento e revises,
que exigem muitas vezes retornar ao incio do processo,
levando a variaes grandes de custos e de modicaes
nos prazos originalmente denidos; para que acontea
uma estabilizao da tecnologia so necessrios vrios
ciclos de projeto e reprojeto, at a consolidao do
produto/processo.
Tipo D Super Alta Tecnologia: este o tipo de
projeto mais raro, onde se tem um objetivo claro, porm
ainda no h tecnologias disponveis para realiz-
lo; somente governos e empresas muito grandes se
lanam nesse tipo de projeto, onde o grau de incerteza
elevadssimo, e que levar a inmeros outros projetos
derivados para buscar as tecnologias necessrias; o
projeto Genoma pode se caracterizar como sendo desse
tipo, assim como o projeto aeroespacial Apollo, que
pretendia levar o homem at a Lua e envolveu milhares
de pessoas e pesquisadores, conseguindo nalmente obter
o resultado desejado, e junto a isso gerou uma enorme
variedade de subprodutos e novas tecnologias; a gura a
seguir representa as classicaes no eixo das Incertezas
com relao s tecnologias envolvidas.

74
Baixa
Tecnologia
Mdia Alta Super
Alta
Incerteza
Figura 2.11 Eixo das Incertezas no Modelo UCP (DVIR et al., 2004).
O eixo da Complexidade relaciona os diferentes projetos quanto
complexidade do sistema em desenvolvimento e, dessa forma,
o nvel de gesto necessria. Inmeros elementos podem estar
relacionados num projeto, e a forma como eles se relacionam
que dene os nveis de complexidade, conforme os seguintes
nveis:
Nvel 1 Montagem: so projetos onde diferentes
elementos so arranjados em composies simples,
ou simples montagens, de tal forma que o resultado
se congura num nico produto com funes bem
determinadas, como por exemplo uma mquina; nesse
nvel de complexidade os projetos geralmente so
desenvolvidos internamente por uma empresa, sem
relaes externas.
Nvel 2 Sistemas: os projetos com nvel de
complexidade maior, que envolvem inmeros elementos
e diferentes equipes, de diferentes empresas e sub-
contratados, tm maior nvel de complexidade e so
chamados nesse modelo de Sistemas. So exemplos
desse tipo um novo projeto de automvel ou avio, ou a
reengenharia de uma empresa inteira.
Nvel 3 Super-sistemas: so aqueles formados por
inmeros outros sistemas, em geral dispersos entre
diferentes empresas e categorias tecnolgicas, que
precisam agir em conjunto em busca dos resultados

75
Unidade 2
denidos pelo contratante, muitas vezes uma instituio
governamental ou consrcio de empresas; a construo
do tnel que liga a Inglaterra Frana um exemplo
desse tipo, assim como a construo do metr de So
Paulo; a gesto desse tipo de projeto envolve inmeros
gestores e uma imensa quantidade de documentos e
relatrios, de forma a coordenar esforos de diferentes
organizaes e lugares; o eixo da Complexidade quanto
aos sistemas envolvidos mostrado na gura abaixo.
Complexidade
Super-sistemas
Sistemas
Montagem
Figura 2.12 Eixo da Complexidade no Modelo UCP (DVIR et al., 2004).
O eixo dos Prazos divide os projetos quanto ao tempo
disponvel ou necessrio para o seu desenvolvimento. Como
j vimos na unidade 1, os prazos so ultrapassados na grande
maioria dos projetos, gerando custos no-previstos e atrasos na
entrega aos clientes e, por esse motivo, so uma fonte enorme
de preocupao. Nesse sentido, os criadores do Modelo UCP
identicam trs tipos de projetos quanto aos prazos:
Regulares: so aqueles projetos onde existe um prazo
denido mas h razovel tolerncia aos atrasos e
modicaes de agenda, como acontece, por exemplo,
na construo de edifcios residenciais e em estradas;
perturbaes e modicaes de investimento so
toleradas e admissveis; apesar de no desejveis,
temos exemplos comuns em projetos de implantao
de sistemas de software gerencial em empresas (os
ERPs), e so tolerados porque se admite que h fatores
no percebidos no comeo do projeto e que o atrasam,
e a importncia da sua implantao preponderante,
independente do prazo.

76
Competitivos: so os projetos mais comuns no ambiente
industrial/empresarial, e esto endereados a novas
oportunidades de negcios, posicionamento estratgico
ou lanamento de novas linhas de produtos. Nesses casos,
a perda do prazo no fatal para a empresa, mas atrasos
podem ser o motivo de fracasso em um lanamento e a
perda de liderana em determinado mercado.
Crticos: so os projetos onde o atraso signica o
fracasso total, implicando em falncia ou derrota;
projetos desse tipo surgem em fases crticas, como por
exemplo em guerras, quando projetos militares precisam
ser concludos no tempo justo; por esse motivo a gesto
rigorosa e h pouco tempo para documentao e outros
tipos de burocracia, levados ao mnimo necessrio (veja a
gura a seguir).
Prazos
Regulares
Competitivos
Crticos
Figura 2.13 Eixo dos Prazos no Modelo UCP (DVIR et al., 2004).
Considerando os eixos apresentados possvel posicionar um
projeto ou situao de determinado produto e buscar, ento,
um novo posicionamento estratgico.
o que se d no exemplo do artigo citado de Dvir et al. (2004),
que relata o caso do desenvolvimento de um sistema de controle
e proteo contra incndios. Veja na gura a atual posio do
produto e a posio futura numa disposio bidimensional.

77
Unidade 2
Tecnologia
Complexidade
Incerteza
Posio atual
Mdia Alta Super Alta
Super-sistemas
Sistemas
Montagem
Requisitada
Baixa
Figura 2.14 Exemplo de projeto apresentado no artigo de DVIR et al. (2004).
Certamente decorar todos esses tipos e nomes no necessrio,
tampouco formalizar cada novo projeto numa dessas categorias
acima descritas.
O que importante ter uma compreenso profunda
de como eles se dividem, sabendo que os diversos
esquemas se ajustam aos projetos conforme o ponto
de vista que estamos tomando para estud-los ou
prepar-los.
Com essa compreenso possvel ter sempre uma viso
estratgica na criao e na gesto do projeto, que o que nos
interessa.
78
Sntese
Nesta unidade voc conheceu os diferentes tipos de projeto,
como so classicados e, especialmente, no que se relaciona
complexidade tecnolgica, riscos variados e prazos. Essa
classicao atual e deriva do desenvolvimento cientco e
tecnolgico recente. Alm disso, foram discutidas algumas outras
classicaes, mas a nfase foi colocada na inter-relao entre
conhecimento cientco e desenvolvimento tecnolgico como
fontes de novos projetos.
Com essa viso abrangente do nascimento e da motivao
dos novos projetos, voc pode agora iniciar a unidade 3,
onde aprofundaremos a concepo do planejamento de um
determinado projeto.
Voc vai estudar os requisitos do cliente e ver como fazer as
avaliaes prvias; anlises iniciais quanto viabilidade e riscos;
como administrar riscos e como determinar um prazo global,
estimado, para tais projetos.
A partir da, voc vai estar mergulhando no planejamento e
gesto de projetos, sempre mantendo o necessrio distanciamento
que a viso estratgica exige.
Enquanto isso, bom trabalho nas atividades, e ca o convite para
navegar em outras referncias, artigos e livros. Boa sorte e at a
prxima!
79
Unidade 2
1) Veja o diagrama a seguir. Voc lembra do desenvolvimento do CD? Ento
pesquise um produto ou servio, que esteja presente no mercado, que tenha sido
desenvolvido seguindo esses passos, e descreva brevemente as diversas etapas.
Necessidades
Conhecimento
e Tecnologia
Novas idias Seleo
Desenvolvimento
do projeto
Uso e
difuso
80
2) Na fgura a seguir voc pode ver que tecnologia e cincia so atividades
diferentes, porm interligadas. E isso se estabelece na base da revoluo
tecnolgica atual, impulsionada por projetos de grande impacto. Como voc
diferencia tecnologia e cincia?
A cincia como pr-requisito fundamental
Tecnologia fornece diretrizes
Atual revoluo tcnico- cientfica
3) Conforme voc viu nesta unidade:
a obsolescncia de uma determinada tecnologia acontece, por exemplo,
quando h o aparecimento de uma nova tecnologia, que a substitui, ou h
mudanas de preos ou no fornecimento de insumos. Pode tambm acontecer
de os consumidores mudarem seus hbitos, ou os competidores passaram
frente, fornecendo produtos com melhorias que voc no dispe.
Faa uma pesquisa ou debate, e comente sobre alguns produtos que tenham
sido substitudos por outros devido a mudanas tecnolgicas ou de consumo.
81
Unidade 2
4) A fgura a seguir apresenta o Modelo UCP de classifcao de projetos.
Considere os seguintes casos:
(A) A construo de uma casa e classifque esse projeto segundo o modelo UCP,
marcando no desenho com eixos complexidade x incerteza a posio relativa
do projeto.
(B) Faa o mesmo considerando um projeto de desenvolvimento de software
para controle de biblioteca, por exemplo, e faa a marcao.
(C) Em Santa Catarina est sendo desenvolvido o projeto de um novo carro,
com tecnologia brasileira e trao 4x4. Classifque e marque tambm este
projeto no desenho.
Comente no fnal as diferenas que voc v entre os trs tipos de projeto.
Tecnologia
Complexidade
Incerteza
Super-sistemas
Sistemas
Montagem
Baixa
82
Saiba mais
Links teis
Alguns links so muito teis para a comunidade de cincia e
tecnologia. D uma olhada nesses:
1. www.nep.gov.br este o stio da Financiadora
de Estudos e Projetos, do Ministrio de Cincia e
Tecnologia do Brasil. Vrios editais de nanciamento
para inovao tecnolgica so colocados ali
constantemente, e so dedicados ao fomento industrial
e empresarial. H, inclusive, investimentos em
projetos tecnolgicos a fundo perdido, ou seja, no-
reembolsveis. No stio da Finep voc vai saber como
est o andamento da maioria dos grandes projetos
tecnolgicos do pas.
2. www.cnpq.br o Ministrio da Cincia e
Tecnologia tambm dispe do Conselho Nacional
do Desenvolvimento Cientco e Tecnolgico
CNPq que tambm nancia bolsas e projetos
tecnolgicos diversos, com nfase em pesquisadores
e desenvolvedores cursando graduao ou recm-
formados. Alm disso traz uma srie de informativos e
editais importantes.
3. Veja no seguinte stio um artigo muito interessante
sobre criatividade no desenvolvimento de novos
projetos. Aponta oito tpicos como sendo
importantssimos para a carreira criativa na rea de
desenvolvimento de tecnologia. http://carreiras.
empregos.com.br/carreira/administracao/
comportamento/131101-criatividade_fraley.shtm
4. Veja no Brasil a ANPEI - Associao Nacional
de Pesquisa, Desenvolvimento e Engenharia das
Empresas Inovadoras, cujo stio www.anpei.org.
br. Vrios artigos importantes, estatsticas e outras
informaes sobre projetos de pesquisa e inovao
tecnolgica, bem como oportunidades de negcios.
3
UNIDADE 3
Viso geral do projeto
Compreender os aspectos prticos iniciais de um
projeto, sendo que a determinao exata do escopo do
projeto o primeiro passo para seu sucesso.
Perceber que as requisies do cliente, seja externo, interno

ou voc mesmo, que traam o caminho geral a ser
seguido pelo projeto, e que preciso sempre ter uma viso
geral e estratgica de tal caminho, para evitar de se perder.
Compreender questes prticas quanto viabilidade

e riscos inerentes a qualquer projeto, e formas de
administrar tais questes.
Verifcar itens fundamentais como recursos, custos,

benefcios e prazos, como componentes determinantes
da viabilidade do projeto.
Sees de estudo
Seo 1 Identifcao e avaliao inicial.
Seo 2 Requisitos do cliente e soluo de
problemas.
Seo 3 Algoritmo do projeto.
Seo 4 Prazo geral.
Seo 5 Viabilidade do projeto.
Seo 6 Antecipando e administrando riscos.
84
Esta unidade est dividida em seis sees, as quais se dedicam
a mostrar como uma viso geral, de partido amplo, pode ser
determinante para a deciso sobre a viabilidade do projeto, e seu
posterior sucesso. Inicialmente apresento as caractersticas de
avaliao prvia e de identicao das necessidades e requisitos
do cliente. Se o cliente tem clareza do que pretende obter, seja
esse cliente um contratante externo, uma demanda interna, ou
voc mesmo, tal clareza de objetivos ser determinante no sucesso
da empreitada.
Com base nessas prerrogativas iniciais apresento, ento, um
modelo genrico de algoritmo para planejamento e realizao
de projetos. Passam a existir, da em diante, vrios elementos
que aprofundaro a anlise do projeto, e especicamente a
anlise de sua viabilidade quanto a prazos, recursos necessrios,
custos e benefcios que sero atingidos. Esses quatro itens, inter-
relacionados, determinaro a viabilidade, ou no, de qualquer
projeto.
Por m o grande problema das ameaas de perda: os riscos. Todo
projeto traz embutido o fator risco, que atinge todos os quatro
itens acima relacionados, e que precisa ser analisado e estimado
com a maior preciso possvel (que nunca ser exata). Estimados
os riscos voc estudar que maneiras voc tem para evit-los e,
caso no seja possvel, administr-los ento.
Espero que esta unidade seja estimulante e motive a viso geral
e estratgica quanto gesto de projetos e de equipes, fator
determinante para obter projetos de qualidade e de impacto
positivo.
Bom estudo!

85
Unidade 3
SEO 1 Identicao e avaliao inicial
Para os projetos terem sucesso preciso ter, antes de tudo,
uma viso clara sobre a nalidade e sobre o seu resultado nal
esperado. Em recente artigo sobre lideranas em equipes de
projetos, Christenson e Walker (2004) denem esse tipo de
atitude, vinculada a uma comunicao objetiva do projeto, como
fatores essenciais para que toda a equipe tenha real compromisso
com o seu sucesso.
Voc viu, na unidade anterior, que uma srie de diferentes
fatores inuencia no surgimento de um projeto. Mas para que
ele tome uma forma e possa evoluir ainda h muito que fazer.
Invertendo, ento, o que est escrito no pargrafo acima,
possvel dizer que o fracasso de todo projeto tem origem numa
viso distorcida do objetivo. Ou seja, quem encomendou o
projeto, quem teve a idia, quem sentiu a sua necessidade,
muitas vezes no sabe exatamente o que quer nem onde quer
chegar.
A primeira pergunta que se deve fazer : qual o
problema?
Vamos nos surpreender com a resposta, pois o real problema
no aparece e, em seu lugar, vm meias palavras e pedaos de
problemas.
Para chegar sua raiz preciso argumentar um pouco mais, na
tentativa de clarear a prpria idia do projeto, pois geralmente o
usurio, o fabricante, o empresrio, no tem claro o problema a
ser resolvido.
Provavelmente algum dir: preciso melhorar o tempo de
produo desta linha de montagem. de fato um grande
problema, e ento precisaramos de um grande projeto (sem
saber direito que projeto seria esse). Talvez o tempo da linha
de montagem seja grande porque, ao nalizar cada etapa da
montagem, algum pra para contar peas.
86
Ento se houvesse um sistema de contagem automtica esse
tempo poderia ser reduzido. Essa automao poderia ser um
contador em determinados trechos da esteira, mas tal contador j
existe no mercado, basta comprar e instalar.
Porm, temos que pegar os dados gerados pelo contador e enviar
para o departamento de estoque, onde planilhas so construdas.
Bem, esse processo de anlise pode ir bem longe, at chegarmos
de fato a um problema com uma soluo a ser implementada, e
para termos tal soluo um projeto ser criado. Parece simples,
mas no .
O primeiro passo, o passo fundamental, transformar
o assunto onde est o problema em uma defnio
exata, pois um trabalho de desenvolvimento s tem
sentido quando se procura uma soluo, ou seja,
quando se sabe o resultado a ser obtido, o que s
acontece se h clareza no problema a ser resolvido. A
isso chamaremos de escopo do problema.
H vrios tipos de projetos, e se considerarmos a diviso
estabelecida na unidade 2, os projetos de baixa tecnologia so
razoavelmente bem conhecidos por todos, e com eles fcil
chegar a uma boa denio do resultado.
O exemplo da construo civil cabe perfeitamente
nesse caso, onde o contratante tem uma idia bem
razovel da casa ou edifcio que quer construir, e dos
recursos dos quais dispe, sendo que o resultado fnal
no fugir em muito dessa idia. Conforme o grau de
tecnologia aumenta (portanto aumenta a incerteza)
e tambm conforme aumenta a complexidade, mais
difcil chegar nessa idia geral.
Clientes tm idias confusas sobre os seus prprios desejos. E
se nossa tarefa criar solues para problemas de tecnologia
complexos, ser preciso envolver a associao de:
87
Unidade 3
conhecimentos adquiridos em etapas de pesquisa e
desenvolvimento cientco e/ou;
conhecimentos de engenharia e/ou;
conhecimentos empricos.
- No parece fcil?
Conforme a complexidade e incerteza do projeto a ser trabalhado,
maior a necessidade de envolver diferentes membros na equipe,
buscando complementaridades. Da mesma maneira, para haver
uma aproximao ao problema, preciso criar para ele um
modelo de representao. Voc vai conhecer mais sobre esses
dois assuntos - equipe e modelagem - nas prximas unidades.
Na tentativa de defnir o escopo do problema, o passo
inicial a identifcao exata da necessidade a ser
atendida.
A atividade de reconhecer uma necessidade, identic-la e
compreender o seu teor exige criatividade, e isso no um
fato corriqueiro. Enquanto a necessidade algo genrico,
abrangente, o problema o seu detalhamento, a especicao
da necessidade.
Na tentativa de denir um problema h duas maneiras de
encar-lo:
Partido geral, ou amplo: denir o problema de maneira
ampla permite criar solues menos usuais, pois o
universo de anlise maior. Com isso quero dizer que
ngulos diferentes podem ser analisados, e solues que
estavam fora do alcance de viso do cliente ou da equipe,
por exemplo, podem surgir e resolver a questo.
Na gura a seguir, voc pode observar que na regio do problema
h vrias causas e efeitos que no esto imediatamente visveis, a
no ser que um partido geral seja tomado, e que uma capacidade
de viso ampla esteja em ao. Com isso vrios aspectos podem
ser analisados, e propostas de solues abrangentes e variadas
podem ser assumidas.

88
Efeitos no
visveis
Causas no
visveis
Efeitos no
visveis
Causas no
visveis
Causas e efeitos
visveis
Viso ampla
Solues abrangentes e variadas
REGIO DO PROBLEMA
Figura 3.1 Representao esquemtica do problema com abordagem de viso ampla.
Partido restrito: vises restritivas levam a solues de
pequeno alcance, ao contrrio de uma percepo ampla
que pode levar a solues de maior alcance. Problemas
atacados desde o incio de maneira pormenorizada
podem gerar solues deslocadas, e um gasto excessivo de
tempo e dinheiro.
Veja a gura, onde um conjunto de causas e efeitos no est no
campo de viso dado por um partido restrito. Isso gera uma
soluo de alcance limitado, que muito provavelmente no agir
sobre causas e efeitos no percebidos.
Figura 3.2 Representao esquemtica do problema com abordagem de viso restrita.

89
Unidade 3
Considero essa dualidade de vises, a ampla e a restrita, como
o problema fundamental das reas de pesquisa, desenvolvimento
e engenharia, seja em setores de software ou de construo, da
indstria ou do servio, da nossa vida prossional ou da nossa
vida privada.
Por esse motivo vou explorar um pouco mais esses conceitos
com alguns exemplos e estudos de caso (obviamente com a
expectativa de inuenciar a busca por um partido amplo!).
Veja o quadro a seguir:
Caso 1
Falha de monitores
H alguns anos atrs, atuando em uma empresa de projetos e
consultoria em engenharia eltrica, fui chamado para apresentar
uma soluo para problema que estava intrigando diversos
tcnicos de uma grande empresa cermica.
Em determinado setor administrativo da indstria, um conjunto
de monitores, que fcava na lateral de uma das salas, oscilava
continuamente, variando porm a intensidade da oscilao
durante o dia. s vezes, noite, oscilava menos e at chegava a
no ser notado.
Esse problema afetava seriamente os usurios, chegando a
causar irritao nos olhos e grande cansao. Os engenheiros e
tcnicos eletricistas da fbrica foram chamados para resolver o
problema.
A primeira soluo (restrita)
que apresentaram foi trocar o
circuito de alimentao eltrica
daqueles computadores, mas os
monitores continuaram oscilando.
Acusaram ento o aterramento
como causador do problema e a
segunda soluo apresentada, e
implementada, foi construir uma
malha de aterramento nova para
esse circuito e todos os outros
do departamento. Mas os monitores continuaram oscilando.
SEGUE
90
Caso 1 - continuao
A se pensou o seguinte: como os monitores da outra sala no oscilavam,
provavelmente o circuito alimentador deles era o bom.
A terceira soluo apresentada foi puxar uma extenso daquele circuito para
atender os computadores com problema. No funcionou. A quarta e imaginativa
soluo apresentada foi trocar os monitores de lugar, e dessa vez funcionou. No
entanto, isso foi s uma experincia, pois todas as salas estavam cheias de pessoas
trabalhando, e no era possvel deixar metade de uma sala vazia apenas porque
no descobriram a soluo do problema (antes, estavam correndo dele).
Sem mais idias (restritas) para apresentar, comearam a procurar algum capaz
de fazer uma mgica qualquer e, ento, encontraram nossa empresa. Quando
cheguei na indstria me cercaram e contaram toda essa histria, e insistiram em
de novo fazer os mesmos testes de movimentar os monitores, fazer extenses etc.
Aps ouvir todos os comentrios, inclusive um sobre um sapo morto e enterrado
prximo, comecei a fazer algumas perguntas mais genricas e descrever o
problema de um modo mais abrangente. Aquele tipo de monitor usava tubo de
raios catdicos, como a maioria dos televisores, e tais raios poderiam desviar da
trajetria se fossem afetados por campos eletromagnticos interferentes. Se os
raios desviassem da trajetria criando uma espcie de oscilao, provavelmente
os campos interferentes eram oscilantes.
A pergunta que fz foi: existem fontes de energia, subestaes ou cabos
alimentadores prximos, mesmo que fora da sala, que pudessem ser os
causadores de tais campos? A viso do problema era to diferente daquele
partido que inicialmente tomaram, que imediatamente comearam a raciocinar
de outra forma. Rapidamente acharam vrias possveis fontes, mas eram todas
muito distantes da regio dos monitores. Algum voltou com a histria do sapo
fantasma. Perguntei ento como eram as instalaes eltricas da sala, e fui junto
com o eletricista ver os quadros eltricos. O quadro principal tinha um duto que
ia em direo ao teto e outro para o piso. Reparei que entre vrios cabos havia
um azul que descia para o piso (era o neutro) e um vermelho que ia para o teto
(era a fase).
Bem, isso todos os eletricistas sabem: fase e neutro devem estar juntos para
eliminar efeitos de campos eletromagnticos indesejveis. E o eletricista da
fbrica me disse que fzeram a instalao dessa maneira porque o duto estava
muito apertado e os cabos no passaram juntos, por isso lanou um pelo piso
(embaixo da regio dos monitores) e o outro pelo teto (sobre os monitores).
Desliguei esse circuito e fez-se a mgica: os monitores pararam de oscilar. A
soluo era realmente muito simples, bastava ter olhado o problema com um
pouco mais de pacincia e analisado os efeitos com maior acuidade (sim, est
certo que era preciso ter conhecimento para isso, mas o conhecimento algo que
podemos obter!). Uma grande quantidade de dinheiro, tempo e irritao poderia
ter sido economizada se o partido amplo tivesse prevalecido.
91
Unidade 3
- E ento? Viu agora? A seguir trago mais um caso para que voc
compreenda melhor, veja:
Caso 2
Implantao de um ERP
Conheci uma empresa que tinha vrias fliais espalhadas por extenso
territrio e mais de mil e quinhentos funcionrios. No vou contar
aqui a novela e os dramas que aconteceram na escolha do software
ou na sua implantao. Vou iniciar o caso no momento em que uma
rede de comunicao IP foi contratada de uma grande empresa de
telecomunicaes. Qual era o problema?
Antes do contrato dessa grande rede IP, todos os usurios reclamavam
de imensos problemas de demora para resolver qualquer coisa com
o tal software ERP, que tinha vindo para ser a salvao do sistema de
informaes dessa empresa. O usurio evidentemente achava que
isso seria um novo problema para ele, to acostumado em preencher
papeizinhos. Mas cada vez que fazia uso do novo sistema, o mesmo no
respondia ou demorava demais para dar uma resposta, muitas vezes travando.
Ento surgiu a primeira soluo (restrita) do
problema: era a infra-estrutura de rede que no
funcionava bem. Foi contratada, ento, a nova
rede IP e a esperana surgiu no corao de todos.
Nesse momento, fz a minha primeira anlise e
relatei a todos: o problema est no sistema, e a rede
no vai alterar seu comportamento. Bem, eu no queria frustrar as esperanas de
ningum. Veio a nova rede e tudo continuou como era antes (e minha equipe j
tinha apresentado todos os grfcos de performance, antes e depois da existncia
da rede, mas ningum estava disposto a abandonar suas crenas at que cada um
visse novamente, em sua prpria mquina, que tudo continuava igual).
Chegou a vez da segunda soluo (restrita): se o sistema no funciona bem
deve ser problema com o servidor, ento a soluo trocar o servidor (isso foi
feito). Acredito que tenha melhorado um por cento ( uma crena particular,
baseada na reduo proporcional de reclamaes). Fiz as seguintes perguntas:
o sistema lento em todas as solicitaes? Apenas das fliais? Poderia haver
problemas nas rotinas implementadas para acesso ao banco de dados? Quanto
mais as perguntas foram cercando diferentes aspectos do sistema, cada vez mais as
respostas indicaram que o problema estava na prpria construo do sistema.
Bem, se essas perguntas tivessem sido feitas numa etapa muito anterior, talvez
as coisas fossem diferentes, mas na vida real a empresa deixou por isso mesmo
e passou a conviver com o ERP, como se fosse uma espcie de flho defeituoso,
vivendo para sempre dentro de casa.
ERP Sigla para
Enterprise Resource
Planning, sistema
informatizado para
planejamento e
apoio operao
dos recursos de uma
empresa, tais como
nanceiro, estoque,
pessoal, linha de
produo etc.
92
- Voc observou como muitas vezes nos acostumamos com os problemas,
e perdemos a oportunidade de elimin-los? Veja o terceiro caso agora.
Caso 3
Encomenda de um novo site corporativo
Estive em uma determinada companhia onde a cultura tecnolgica
remontava ainda poca da segunda revoluo industrial, ou seja, a
cultura tinha conseguido evoluir do ambiente das mquinas a vapor
para as mquinas eltricas. Isto no uma crtica companhia, pois
ela estava adequada ao seu mercado, que a enxergava como capaz de
entregar produtos tradicionais (e conservadores) e nisso era muito boa.
No entanto seu problema que o discurso da nova direo era de
remodelagem dos seus objetivos, e nisso o foco era estar a par com as
novas tecnologias e com os novos processos de qualidade, tanto que
fazia questo de participar dos concursos de qualidade regionais, e
para ganhar alguns pontinhos nisso, sabia inteligentemente manipular
referenciais comparativos (e por isso que os concursos de Qualidade
no tm valor, a no ser para os ignorantes sobre o assunto).
Pois bem, uma das suas iniciativas era a de
aumentar a interatividade com os clientes
e melhorar a imagem junto ao mercado, e
reformular o site da empresa era um dos
planos. J havia um site em funcionamento,
mas era to fraco e desestruturado que o
nmero de visitas era muito baixo, e mesmo
menor que o de alguns sites especializados
de algumas de suas sees industriais, que
tinham feito os seus de forma independente.
O gerente geral de marketing da empresa, que surpreendentemente
tambm acumulava a funo de gerente tcnico geral, resolveu
mudar essa situao contratando um novo ambiente, de tal forma que
embutisse os sites das sees, no permitindo assim que tivessem tal
independncia de relacionamento com o mercado.
Esse era o clima geral do negcio e tal era o problema a resolver:
um novo site corporativo com esse conjunto de premissas, sejam de
marketing, sejam de poltica. Tanto esse gerente quanto seu diretor,
ambos tendo conquistado suas posies a partir de negociaes
polticas (e no por talento empreendedor ou por conhecimento do
mercado), desprezavam as novas tecnologias, a tal nvel que o primeiro
escrevia e-mails como se fossem ofcios e o segundo mal conhecia as
regras do portugus escrito.
Site corporativo:
espao virtual de
determinada empresa
no ambiente da
World Wide Web
na internet em
portugus algumas
vezes se usa a palavra
stio, que aos poucos
est se tornando
corrente no Brasil.
93
Unidade 3
Isso no consistia num grande problema no ambiente em que
viviam, mas era grave quando resolveram infuenciar nas defnies
do novo site. O gerente geral de marketing assumiu a funo de
gestor desse projeto e trouxe a primeira soluo (restrita) para
o caso: passou a incumbncia para o assessor de marketing da
empresa. Ele mesmo no tinha uma viso geral da empresa e sabia
disso. O assessor de marketing tinha dois problemas, que todos
conheciam: no dominava tecnologias e no conhecia a cultura da
empresa (mas imaginava que, aps ter lido algumas revistas sobre
publicidade, podia discutir qualquer assunto).
O assessor trouxe, ento, a segunda soluo (restrita) para o
problema: fez uma licitao entre empresas de design para
contratar o tal site, e ganhou a que tinha o menor preo.
Certamente a descrio do propsito da contratao estava
escrito conforme os objetivos desse assessor, e as empresas
fzeram seus oramentos praticamente no escuro. Ganhou o
menor preo e ento chegou a terceira soluo (restritssima)
para o problema, que foi o de dar uma melhorada no site
existente. Todos os funcionrios da empresa, seus gestores,
aqueles que formulavam suas novas estratgias, bem como seus
principais clientes e fornecedores, fcaram fora desse processo
de anlise de defnies e, enfm, aps uns seis meses de atraso
o novo site foi publicado. Sem interao com as aplicaes
informatizadas da empresa, sem dinamismo e sem capacidade
de mostrar as prprias atividades da empresa, foi um fracasso (as
prprias estatsticas do site mostravam isso).
Para o diretor e para o gerente isso no teve importncia, afnal j
tinham um novo site, e era o que importava para os concursos
regionais de qualidade (e sua publicidade e poltica pessoal). Para
o assessor de marketing isso tambm no tinha importncia, pois
ele cumpriu seu dever e o emprego estava mantido. No entanto
essa viso restrita (e neste caso tambm mesquinha) fazia a
empresa dar um passo para trs (talvez irreversvel).
Caso 3 - continuao
Eu poderia continuar dando exemplos e mais exemplos desse tipo
de viso restrita aplicada soluo de problemas, e infelizmente
parece que esse o caso da maioria. Temos que lutar contra isso.
Deixe-me dar, ento, apenas um exemplo de viso ampla, que
mesmo fazendo parte da minoria, quando acontece pode mudar
os rumos de toda uma empresa ou mesmo de um pas.
94
Caso 4
Uma gigante da telefonia celular
Assim como nos trs casos anteriores, verdicos, tambm neste no vou nominar
a empresa onde o fato ocorreu (apesar de ser muito fcil adivinhar). E apesar de
ter vivido o dia-a-dia daqueles trs casos, neste ltimo, infelizmente, no. Bem,
mais ou menos no meio dos anos 70 a empresa vivia uma crise no seu mercado,
sendo que os grandes compradores de seus produtos, voltados rea eltrica e
eletrnica, estavam perdendo o poder de compra.
A empresa tinha um grande problema nas mos, que era o da sua prpria
sobrevivncia no futuro. Comeou ento a tomar um partido amplo para analisar
o problema, e iniciou um conjunto de aes em seqncia, sempre com solues
criativas e tomadas por uma viso de conjunto.
Em primeiro lugar, no mudou completamente de ramo, para no desperdiar
seu conhecimento tcnico em eletrnica e sua cultura de fabricao de produtos
com excelncia. Ao mesmo tempo assumiu como soluo (de ampla viso) no
competir diretamente com empresas orientais que tinham preos baixos em
produtos eletrnicos.
Outra soluo foi competir num mercado nascente e de alto valor
agregado, que naquele momento ainda consistia numa promessa: o da
telefonia celular. No incio dos anos noventa a empresa j detinha um
razovel conhecimento na rea, e um domnio consistente do seu mercado
local que, no entanto, era de dimenso restrita.
Tambm com uma viso ampla e estratgica do mercado mundial,
previu que a produo de aparelhos de telefonia celular teria valor
agregado quando inserisse qualidade no software, e no no hardware do
equipamento. Adotou uma soluo (ampla) de pesquisar e desenvolver
novas interfaces e aplicativos, voltados facilidade de manuseio por parte
do usurio, muito mais do que desenvolver simplesmente a miniaturizao
dos aparelhos ou a qualidade de baterias, o que considerou como
commodities.
Na poca um dos lderes mundiais nesse mercado era uma empresa
americana, que valorizava a robustez do aparelho. O que aconteceu foi que em
aproximadamente cinco anos essa empresa assumiu a liderana mundial na
venda de aparelhos, partindo de uma simples empresa de eletrnica perifrica,
sendo atualmente copiada pela enxurrada de novos fabricantes orientais, que
para disputar o mercado insistem numa estratgia de preos reduzidos. A srie de
solues (amplas) adotadas pela empresa, sempre com uma viso geral sobre o
seu mercado e sobre os costumes, tendncias e interesses dos seus clientes fnais,
fez com que conquistasse e mantivesse a posio de lder. Essa mesma viso que
criou um ambiente aberto de discusso com desenvolvedores de software de todo
o mundo, que continuam colaborando para sua expanso e liderana.
Commodities:
palavra da lngua
inglesa que indica
que o produto ou
sistema de uso
ou conhecimento
genrico, tendo
poucas diferenas de
valor, independente
de quem os fabrica
ou fornece.
95
Unidade 3
importante observar que h nesses quatro casos, sejam de
sucesso ou de fracasso, algumas caractersticas e alguns traos
comuns. Observe:
Ambiente de cooperao um partido amplo de viso
no acontece onde as pessoas sentem-se limitadas no
seu relacionamento; a viso centrada em si mesmo
naturalmente limita um olhar descompromissado, capaz
de enxergar outras facetas fora do seu mundo particular.
Ambientes onde h uma cultura de cooperao, ou seja,
onde as pessoas gostam de ajudar e de receber ajuda,
admitindo que isso no seja uma forma disfarada
de aproveitamento, permitem liberdade de expresso
(mesmo que seja a idia do sapo enterrado!).
Conhecimento tcnico aliado viso de mercado
certamente apenas um ambiente de cooperao no
suciente, pois em problemas tcnicos necessrio um
conhecimento especco. Porm apenas o conhecimento
tcnico algo limitante, e deve ser contrabalanado com
uma viso externa, voltada para o mercado e para outras
facetas no-tcnicas.
Multidisciplinaridade ao mesmo tempo difcil
ter conhecimento tcnico em muitas e variadas reas,
especialmente na atualidade onde h tantas tecnologias
e elas se desenvolvem to rapidamente. Equipes
trabalhando em conjunto e com alto grau de cooperao
so capazes de reunir conhecimentos de diferentes
disciplinas, capazes de gerar solues de ampla viso.
Viso medocre o contrrio desse ambiente de
cooperao e multidisciplinar acontece onde impera uma
viso medocre, aquela que no admite relacionamentos
e que acredita que, se algum d uma sugesto, porque
est planejando algo. Tambm faz parte da viso
medocre a confuso que une cincia exata e crenas,
fazendo com que um problema seja analisado sob o
ponto de vista do achismo. Muitos tcnicos excelentes,
engenheiros que conheci e que eram tidos por gnios na
universidade, resolveram car alheios ao desenvolvimento
dos seus colegas, supondo que sua imensa capacidade

96
seria o bastante para resolver os grandes problemas do
futuro. Hoje, infelizmente, muitos deles esto presos
s suas baias, resolvendo mini-problemas sob as ordens
de gerentes pouco espertos, porm politicamente
articulados.
Poltica pessoal a articulao poltica de carter
pessoal , necessariamente, a viso restrita. Centrada no
eu, torna-se incapaz de um partido abrangente para
as solues, mesmo que para problemas estritamente
pessoais. Isso se estende para a postura de soluo de
quaisquer problemas, e quando se d no nvel empresarial
pode ser uma catstrofe. Nos casos citados acima vimos
o que signicou na contratao do website corporativo,
apesar de, pessoalmente, os contratantes terem
aparentemente se dado bem. No entanto, nesse tipo de
ambiente, muitos dos que estavam em volta esperavam
ansiosos a queda dos chefes, muitas vezes para substitu-
los com as mesmas prticas (renovadamente restritas).
Por m, para completar esta seo, cabe dizer que as estratgias
so denidas e implementadas com uma viso de partido amplo,
e as questes operacionais esto denidas sobre questes restritas,
ou partes de uma estratgia. O momento em que uma ou outra
devem acontecer que dene o tipo de viso a tomar.
SEO 2 Requisitos do cliente e soluo de problemas
A expresso requisitos do cliente comum entre os
desenvolvedores de software, e para muitos outros prossionais,
de outras reas, parece uma expresso nova.
O cliente nesse caso aquele que precisa resolver
um problema, ou que est gerando uma demanda
especfca e, deste modo, tem uma idia aproximada
daquilo que quer obter.


97
Unidade 3
Como voc j viu anteriormente, esse cliente conhece talvez
alguns dos efeitos de um problema, mas geralmente no todos.
E quando tem um desejo, no fundo no sabe exatamente como
express-lo. Considere que muitas vezes voc mesmo o cliente,
e perceba o quanto voc no sabe expressar suas necessidades
com exatido.
Aquele que foi chamado, por algum motivo, para resolver o
problema de um requisitante qualquer, antes de tudo precisar
saber anal qual o problema a resolver e qual o resultado
esperado, seja para arrumar um conjunto de monitores
com oscilaes, seja para desenvolver um novo software de
relacionamento com fornecedores e clientes nais.
O primeiro passo a tomar coletar o maior nmero possvel de
informaes. A coleta de informaes est presente em todas
as etapas do trabalho, desde a primeira reunio com um cliente
ou no nascimento da idia de um projeto, passando por todas as
etapas do projeto at a chegada do resultado, sendo um precioso
instrumento de aperfeioamento e correo contnua. Nesse
sentido, cada etapa de um projeto pode ser vista como um novo
comeo, onde os requisitos das etapas devem ser novamente
levantados e analisados.
Nas etapas iniciais, a coleta vem diretamente do cliente que
solicita a soluo de um problema, mas em casos onde h uma
idia de produto, por exemplo, tais informaes podem vir da
literatura e de experincias prvias, seja dos desenvolvedores, seja
de outros envolvidos no projeto.
Alguns procedimentos para levantar os requisitos bsicos do
cliente, ou as informaes para o desenvolvimento de um novo
produto ou sistema, e encaminhar uma primeira viso geral do
problema/soluo so:
se o problema a ser resolvido est escrito, devem-se listar
as informaes que esto no seu enunciado, na tentativa
de detalhar o melhor possvel suas partes;
se for um defeito a eliminar, descrever todos os efeitos
conhecidos e enumerar todas as possveis causas;

98
se for um novo produto ou processo a desenvolver, listar
o que deve ser determinado pela soluo, ou seja, denir
com a maior clareza possvel o que est sendo buscado;
a partir dos dados levantados e do partido amplo
do problema, deve-se criar modelos e esquemas de
representao, permitindo uma melhor visualizao do
conjunto. Nesse sentido o desenvolvimento de desenhos
esquemticos, diagramas e uxogramas, torna-se til
para a compreenso do todo, mesmo que tais desenhos
no sigam modelos padronizados (isto no importa nesse
momento);
alm das informaes listadas, dos desenhos e de outros
dados coletados, importante vericar as leis fsicas
associadas e suas equaes, no caso dos problemas
cientcos, mas tambm outros impeditivos e limitantes,
tais como questes jurdicas, restries tcnicas,
restries ambientai etc.;
tomar proveito de modelos computacionais e simuladores
como ferramentas de apoio para compreender o
problema, retrat-lo e simular situaes, bem como
aprimorar o desenho de diagramas, grcos de
planejamento (os quais veremos e estudaremos ainda
neste livro), aplicar hipteses de soluo e desenvolver
esquemas gerais e/ou detalhados.
O desenho da gura a seguir reproduz esses passos na forma
de um diagrama de coleta de informaes para a soluo de
problemas. Como se pode notar um diagrama genrico que no
esgota as possibilidades de tipos de problemas ou idias originais
a serem transformadas em projetos. Mas d uma clara percepo
da necessidade de coleta do maior nmero de informaes,
inclusive de fontes externas ao problema, para ento chegar fase
de se criar hipteses de soluo.

99
Unidade 3
ou
ou
Problema
definido
Defeito a
eliminar
Novo
produto
Dados
coletados
Desenho,
diagrama
ou modelo
Hipteses
de soluo
Outras
informaes
Objetivos
do projeto
Figura 3.3 Diagrama do nascimento do projeto com coleta de informaes e requisitos do cliente.
Com as hipteses de soluo formuladas, podemos traar
objetivos de chegada considerando as hipteses com maior chance
de sucesso. Esses objetivos traados sero perseguidos em todo o
projeto, e para isso preciso denir um caminho de trabalho para
abordar o projeto. Esse caminho est denido no algoritmo do
projeto, apresentado na prxima seo.
SEO 3 Algoritmo do projeto
Como voc j estudou na disciplina de Lgica de Programao,
o algoritmo permite modelar um determinado programa (ou
projeto) de maneira que voc deve entender e denir com
exatido todos os passos que devem ser seguidos, para que o
mesmo chegue ao resultado esperado. Tendo um objetivo bem
denido, conforme voc observou na seo anterior (veja de novo
a gura e o ltimo quadro, direita), preciso determinar um
uxograma genrico de atividades, at o objetivo ser atingido
com sucesso (ou no!, mas isso outro problema e voc ver mais
adiante).
O algoritmo apresentado na gura a seguir foi adaptado a partir
de uma proposta de Meillir Page-Jones (1990). O uxograma se
inicia a partir dos objetivos denidos, e vai ser encerrado quando
os mesmos forem alcanados.
100
Nesse algoritmo podemos ver o conjunto de atividades que
determina a Gesto do Projeto:
planejamento;
denio e organizao dos recursos;
acompanhamento da execuo;
medio dos resultados obtidos; e
reviso, quando ento o ciclo reinicia, se necessrio.
- Acompanhe o desenho a seguir e analise cada uma das etapas,
vericando o uxo das atividades.
Os objetivos
foram alcanados
Objetivos do projeto
Planejamento
das atividades
Definio dos
recursos
Obteno dos
recursos
Integrao dos
recursos
Execuo das
atividades
Acompanhamento
e medies
Reviso do projeto
Encerramento do projeto
SIM
NO
Ferramentas de apoio
Figura 3.4 Algoritmo genrico com o fuxograma do desenvolvimento do projeto.

101
Unidade 3
Planejamento das atividades o planejamento consiste
em dividir o objetivo geral do projeto num conjunto
de pequenas tarefas, ou pequenos objetivos, que vo se
encadeando numa seqncia determinada, a m de atingir
o resultado esperado do projeto. Tambm consiste em
denir recursos materiais, nanceiros e de pessoal, para
cada um desses pequenos objetivos, com os trabalhos a
serem feitos num determinado prazo preestabelecido. O
tema do planejamento ser estudado na unidade 4.
Denio dos recursos a denio dos recursos
uma das tarefas do planejamento, porm, coloco
parte no algoritmo e logo aps a fase do planejamento
para destacar a importncia dessa etapa. Muitas
vezes a denio dos recursos necessrios no bem
determinada, o que pode acarretar em carncias na
etapa da execuo, que podem ento ser fatais. Denir
com a maior exatido os recursos necessrios, sejam eles
nanceiros, materiais, equipamentos ou pessoal com
a qualicao necessria, contribuir para completar a
fase do planejamento e para diminuir riscos. Recursos
subestimados levaro a importantes faltas, enquanto
recursos superestimados levaro a custos altos,
inviabilizando o projeto em alguns casos.
Obteno dos recursos somente com uma boa
denio de recursos possvel partir para a fase da
sua obteno, o que pode ser uma tarefa bastante difcil
no processo do projeto. Se for um projeto dentro de
uma grande organizao, talvez os recursos j estejam
previamente alocados, mas se for o caso do projeto de
uma pequena empresa empreendedora, eles podem ser
bastante escassos. Nesse caso, recursos externos sero
necessrios, o que tomar um determinado tempo at ser
obtido. Essa demora no favorvel, por exemplo, nas
reas de alta tecnologia.
Integrao dos recursos os recursos podem vir de
fontes diferentes e, muitas vezes, guardam grandes
diferenas entre si. Pense, por exemplo, num conjunto
de pessoas, com diferentes habilidades, e que ainda no
se conhecem. Ou ento na utilizao de equipamentos
novos, ainda no dominados por todos. Nesse sentido

102
que a integrao dos recursos assume importante papel,
determinante para o progresso do projeto dentro do
prazo estipulado. Nesse momento que so organizadas
as equipes, distribudas as tarefas e feitas as discusses
iniciais de repasse de informaes. Arranjos de layout
de produo, organizao de mquinas, montagem de
laboratrio, treinamento e comunicao do planejamento
completo para todos os envolvidos, so atividades desta
etapa. A unidade 5 estar dedicada ao estudo dos
recursos humanos na equipe de projeto.
Execuo das atividades muitos enxergam que o
projeto s est de fato em desenvolvimento quando
se inicia a execuo das atividades. Isto um grande
engano, como j pudemos ver pela quantidade e
importncia das etapas precedentes, que so etapas
preparatrias e de planejamento. A etapa da execuo
onde os recursos materiais so utilizados pela equipe, que
desenvolve a srie de tarefas designadas no planejamento,
tendo em vista atingir os sub-objetivos, numa ordem
tal que permita chegar aos objetivos nais desejados.
Vamos tomar como exemplo algo muito simples como
a construo de uma casa. Depois de elaborados os
projetos e tendo listagens de materiais e memoriais
descritivos, que denem em detalhe como se construir
a casa (essa a etapa do planejamento), passa-se a
fazer os oramentos, contratar pessoal e reuni-los para
discutir, com um partido amplo, como ser a construo
e os prazos a serem cumpridos (essas so as etapas dos
recursos). A partir de ento, comea a execuo do
projeto, que provavelmente foi subdivido em fundaes,
alvenaria, telhado, rebocos, instalaes etc. Na unidade
6 estudaremos a etapa da execuo, acompanhamento e
revises do projeto.
Acompanhamento e medies como a execuo
deve seguir o planejamento, certamente dever haver
o acompanhamento e a vericao do andamento do
projeto, avaliando periodicamente a concordncia entre
uma coisa e outra. Muitas vezes nessa etapa onde se faz
mais visvel a presena da gerncia, devido ao controle
do planejamento. Como o objetivo geral deve ter sido
subdividido em pequenos objetivos, com metas e prazos

103
Unidade 3
menores, faz-se necessrio vericar o alcance de tais
metas com medies peridicas, ou seja, nos prazos
determinados para cada sub-objetivo. Voltando ao
exemplo do pargrafo anterior, o acompanhamento
da obra se dar com a vericao, por exemplo,
da qualidade e do prazo atingidos para acabar
as fundaes, depois para se levantar as paredes,
sempre comparando com o prazo inicialmente
denido. Desta forma possvel prever com maior
segurana os possveis atrasos e/ou estouros do
oramento (que no so desejados!!).
Reviso do projeto durante o acompanhamento e
medies, caso os objetivos no sejam alcanados, seja
devido ao tempo gasto para chegar at aquele ponto,
seja pela qualidade diferente da esperada, o projeto
deve passar por revises. Rever o projeto durante o
seu andamento signica reavaliar constantemente o
planejamento, bem como redenir os objetivos quando
necessrio. Caso a reviso seja feita apenas no nal
do projeto, pode acarretar em enormes frustraes
(nanceiras ou de expectativa). A gura abaixo
representa esse ciclo de reviso a cada etapa do projeto,
que deve seguir adiante caso os sub-objetivos, esperados
naquela etapa, tenham sido alcanados. Se no foram
alcanados, uma reviso da etapa deve ser feita, deve
indicar possibilidades de modicao e reticao, que
devem passar ento por um replanejamento para seguir
adiante. Satisfeita a condio, vai-se para a prxima etapa
at alcanar os objetivos gerais do projeto.
Os sub-objetivos
foram alcanados?
Replanejamento
Reviso da etapa
SIM
NO
Prxima etapa
Figura 3.5 Fluxograma especfco da fase da reviso.

104
Encerramento do projeto encerrar o projeto
signica alcanar aos objetivos. (Bem, infelizmente
nem sempre isso acontece, como veremos na unidade
7, onde discutiremos sucesso e fracasso de projetos).
A nalizao do projeto no simplesmente acabar
um produto ou compilar um cdigo. O encerramento
uma etapa bem denida do projeto, onde toda a
documentao dever ser organizada e entregue quele
que o encomendou, com a comunicao mais completa
e abrangente possvel sobre o resultado alcanado e os
problemas e solues que se encontrou. Esta etapa ser
estudada na unidade 7.
Ferramenta de apoio esta no uma etapa de um
projeto, no entanto algo importantssimo e vem
ganhando ainda mais destaque com a informatizao
atual. Voc viu anteriormente que os grcos de
Gantt, foram desenvolvidos para poder visualizar,
esquematicamente, as etapas de um projeto ao
longo do tempo. Esses grcos constituram-se em
ferramentas fundamentais no planejamento de projetos
e em seu acompanhamento. Muitas inovaes foram
introduzidas sobre ele posteriormente e, recentemente,
tais grcos, que eram manuscritos, passaram a fazer
parte de programas computacionais, sendo gerados
automaticamente a partir dos dados de entrada
cadastrados durante o planejamento. Existem vrias
ferramentas desse tipo atualmente, e voc poder usar
uma delas, gratuita, para os exerccios de xao que
desenvolver ao longo deste livro (o software chama-
se jxProject). No quadro a seguir voc observar
algumas das atualmente mais conhecidas ferramentas
computacionais de apoio a projetos.
Um produto muito interessante de apoio ao gerenciamento
de projetos foi desenvolvido com a Linguagem Java e est
disponvel para uso gratuito. O nome do produto Free Project
Management Software, mais conhecido como jxProject, e est
disponvel para download no stio www.jxproject.com. Este
software de uso bastante simples, porm de grande utilidade
pois cria grcos de Gantt de grande qualidade com a incluso
de dependncias entre tarefas (o que voc ver em detalhes na
prxima unidade deste livro).

105
Unidade 3
Veja a seguir uma traduo que z diretamente do texto de
apresentao do jxProject, que est disponvel em ingls no
original, no stio mencionado anteriormente.
Se voc est buscando um Software de Gesto de Projetos
Gratuito, ento voc veio ao lugar certo. Voc pode instalar
jxProject em todos os seus computadores sem nenhum custo.
Voc tambm pode compartilhar seus planejamentos de projetos
com qualquer um que tenha acesso Internet, pois qualquer
pessoa na Internet pode acessar e instalar jxProject. Plataformas
Windows, Linux e Solaris suportam o jxProject, e muitos
usurios de Mac OSX tm relatado seu grande sucesso usando
este software. E como possvel? O aplicativo fnanciado por
propaganda, colocada na parte superior direita da janela do
aplicativo, e tal propaganda que fnancia o desenvolvimento e
manuteno desse sistema.
Histria: fundado em 2001 por Peter Hawkins, com a misso
de colocar uma cpia de jxProject em todos os computadores.
Palavras de Peter Hawkins: Tenho trabalhado em computao
desde que me formei em Engenharia Mecnica em 1986. De 1986
a 1994 trabalhei nas reas de engenharia e manufatura, incluindo
processos de controle de manufatura e sistemas CAD/CAM,
geralmente usando UNIX/C. De 1994 a 2001 trabalhei com vrias
tecnologias aplicadas a negcios com TCP/IP, HTTP, RDBMS, OLAP,
Java e Windows em indstrias diversas como a de produtos de
software, sade, comunicaes sem fo e comrcio eletrnico.
Em outro trecho do seu depoimento Peter Hawkins comenta:
Existem duas tecnologias que mudaram fundamentalmente
a maneira como softwares devem ser desenvolvidos. So:
Arquitetura Orientada e Objeto e execuo Multi-threaded.
Tenho visto companhias desenvolvendo software do mesmo jeito
que elas faziam nos anos 70, ainda que as tecnologias tenham
mudado completamente. A falha em implementar processos de
trabalho que incorporem essas diferentes tecnologias contribui
signifcativamente para a falta de efcincia no desenvolvimento
de software hoje em dia. Parte do que venho fazendo com
o jxProject est aperfeioando meus prprios mtodos para
incorporar tais novas tecnologias. Vejo positivamente os escritos
de Eliyahu M. Goldratt, cujos livros Theory of Constraints e
Critical Chain nos do uma viso mais completa das foras que
agem sobre os processos de negcios.
106
O mais popular software comercial de gesto o da Microsoft,
e se chama Microsoft Project MSProject. Voc ver que
muitas empresas usam essa ferramenta, que pode ser adquirida
nas revendas autorizadas e est disponvel tambm em www.
microsoft.com/brasil/o ce/project/standard.asp. O MSProject
uma marca registrada e o produto de maior sucesso hoje da
Microsoft, depois do O ce.
Veja a seguir algumas informaes gerais sobre esse produto,
extrados do stio da Microsoft (www.microsoft.com).
Certamente tais informaes so de mbito comercial, e cada
usurio dever vericar com cautela se o produto se ajusta ou no
s suas necessidades, especialmente em produtos como esse, que
no esto voltados para aplicaes especcas, mas sim pretendem
atender a uma gama de atividades. Esse tipo de pretenso em
softwares tem a desvantagem de abrigar um nmero excessivo de
mdulos e acessrios, o que acaba por incluir uma complexidade
desnecessria para o usurio.
O Microsoft Of ce Project Standard 2003 utilizado pelos gerentes de
projetos que precisam de uma ferramenta de rea de trabalho para
gerenciar seus projetos de maneira independente, mas que no exigem
coordenao rigorosa com outros gerentes de projeto nem a capacidade
de gerenciar recursos a partir de um repositrio central. O Project Standard
2003 foi projetado para aprimorar a capacidade de organizar o trabalho e
para comunicar de maneira efciente e sucinta por ferramentas familiares e
fceis de serem usadas.
Segundo a Microsoft (www.microsoft.com), o Project Standard 2003
ajuda a organizar e gerenciar melhor o trabalho e pessoas para garantir
que os projetos sejam entregues na data e que estejam dentro do
oramento. Com o Project Standard 2003, possvel:
Organizar seu trabalho de maneira mais efciente, com recursos e
poder de planejamento poderoso.
Controlar e avaliar os impactos do planejamento e alteraes de
recursos em todos os planos do projeto.
Personalizar planos para capturar informaes especfcas para seus
projetos.
Exibir as informaes do projeto que voc deseja revisar.
Dar enfoque s informaes que precisam de sua ateno com fltros
e grupos.

107
Unidade 3
Algumas facilidades para quem j usa os pacotes da Microsoft:
O Project Standard 2003 ajuda a projetar seus planos de projeto
e status de maneira efciente e sucinta, permitindo que voc:
Aumente seu impacto sobre o trabalho, usando Copiar
Imagem para o Assistente do Of ce para comunicar e
apresentar idias e informaes do Project Standard 2003 em
outros programas do Of ce System como Microsoft Of ce
Word 2003, Microsoft Of ce PowerPoint 2003 e Microsoft
Of ce Visio 2003.
Comunique mais claramente usando novos aprimoramentos
de impresso para imprimir cpias de uma pgina de
planejamentos de projeto.
Compartilhar informaes do projeto com membros da
equipe, salvando arquivos do Project (MPP) em um site do
Microsoft Windows SharePoint
TM
Services (WSS). WSS
um componente do Microsoft Windows Server 2003 que
permite que os usurios criem sites para compartilhamento de
informaes e colaborao de documentos.
Iniciar rapidamente as ferramentas que auxiliam na
metodologia de gerenciamento de projetos para que voc
possa confgurar agendas e gerenciar recursos de maneira
mais efciente.
Acessar ajuda online e treinamento para obter assistncia e
suporte atualizado e relevante.
Baixar um modelo da Galeria de Modelos em vez de iniciar um
projeto a partir do rascunho.
Usar ferramentas familiares para fazer um trabalho mais
sofsticado e de impacto sem a necessidade de treinamento
extensivo.
Economizar tempo movendo informaes do projeto
facilmente entre o Project 2003 e outros programas do Of ce
como Microsoft Of ce Excel 2003.
Navegar e aprender o Project Standard 2003 rapidamente com
uma interface atualizada consistente com os programas do
Microsoft Of ce 2003.
Esses so outros softwares de gesto disponveis no mercado, mas

a introduo de novos produtos comerciais continua todos os dias.
Cada empresa ou gestor deve escolher o que melhor se adapta ao
seu estilo:
108
SEO 4 Prazo geral
Prazo um tema especial em Gesto de Projetos e de Equipes.
Projetos so estabelecidos com prazo determinado.
Como vimos, se no houver uma data aproximada para o
empreendimento ser encerrado, ento no temos um projeto e
sim uma tarefa de rotina.
A defnio do prazo algo que nasce dos requisitos
do cliente, pois os objetivos por ele defnidos s tm
sentido se forem cumpridos at uma determinada
poca, onde ento podem ser aplicados.
Observe um exemplo bem prtico de no cumprimento do prazo:
Voc lembra do exemplo das pirmides do Egito? Essa
noo no estava muito clara naquele tempo, onde
muitas vezes a pirmide no fcava pronta antes de o
fara morrer (tambm no era possvel prever a sua
morte, ou seja, o projeto no tinha um prazo muito
fcil de determinar).
Gantt Project
Pert Chart Expert.
WBS Chart Pro.
Mindmanager.
Primavera Team Play.
PMOf ce.
Open Project System.

Rational Project
Manager.
PS8.
Tassc Estimator
Manager.

109
Unidade 3
A discusso sobre prazos deve se dar considerando as
vantagens que o projeto busca, as condies reais da equipe de
desenvolvimento e os recursos disponveis. Na opinio de Meillir
Page-Jones (1990) h quatro questes que fazem os projetos
terem prazos irreais. Tais prazos irreais, primeira vista, so
exeqveis, porm quando o conjunto de fatores que determina
o andamento do projeto entra em jogo, o prazo se perde. Vamos
analisar esses quatro fatores geradores de prazos irreais:
a) Racionalizao do desejo
Page-Jones considera que esse primeiro fator se d
quando algum, que tem poder sobre a equipe, imagina
um prazo qualquer e, conforme seu desejo, impe uma
data nal aleatria. Isso pode acontecer, por exemplo,
quando um poltico dene a data para uma inaugurao,
sem ter a mnima noo do tempo e das questes legais que
envolvem a contratao e a execuo da respectiva obra. Ou
quando o diretor de uma empresa determina que tal software
dever estar funcionado em sua empresa em determinado
momento, sem buscar saber se tal software sequer existe ou
adaptvel. Partindo dessa data estabelecida por um desejo, aquele
que vai gerenciar o projeto tenta dividir as tarefas em prazos
menores para adaptar ao prazo global.
Ajustando ao mximo, ele talvez consiga congurar um conjunto
de pequenas tarefas com prazos muito justos, dando a entender
que talvez seja possvel cumprir a meta. Aps uma partida
acelerada os membros da equipe tero que fazer paradas de
reviso, talvez correes e ajustes e, ento, o prazo comea a ceder
e a equipe, cansada, diminui a capacidade de produo.
b) Estimativa prematura
Se a estimativa do prazo total for feita muito no comeo da
anlise do que ser o projeto, tal data pode parecer imutvel
(para os membros da equipe) e muito provavelmente ser irreal.
Ora, muitas das particularidades do projeto sero percebidas
conforme se aprofunda a discusso e o planejamento do projeto,
e s ento ser possvel prever com maior acuidade os prazos
das diversas etapas, culminando com um prazo global mais
prximo da realidade de execuo. A estimativa prematura
acontece no af de se ter uma data nal para o projeto car
110
pronto, mas devemos controlar esse desejo. Certamente
a estimativa depender em muito do domnio que se
tem da tecnologia empregada no projeto. Tomemos
como exemplo o caso da construo civil. Esse setor
tradicional e as tecnologias empregadas so dominadas
e se repetem de uma obra para outra. Nesse caso,
relativamente fcil perceber todas as implicaes das
etapas do projeto, e os gestores conseguem denir
datas realistas. O mesmo no acontece com projetos
mais complexos como, por exemplo, o desenvolvimento
de uma nova mquina ou um sistema computacional para
automatizar um processo industrial. Mesmo que as tecnologias,
individualmente, sejam bem dominadas, provavelmente
a inter-relao entre conhecimentos diversos, e mesmo as
reais necessidades do cliente, sero de difcil coordenao e
necessitaro de reajustes e re-anlises contnuas.
c) Compromisso progressivo
Page-Jones atribui uma conotao bastante negativa para esse fator,
por considerar de procedimento no-tico. Consiste em estabelecer
um escopo de projeto reduzido para a equipe, que ento dene um
prazo para tal escopo. A partir do incio da execuo o contratante,
ou mesmo o gestor, vai ampliando o escopo e mostrando sua
verdadeira composio, com constantes incrementos de necessidades
e de compromissos. No dando mais para voltar atrs, a equipe tenta
ajustar as novas necessidades dentro do planejamento, estressando
dessa forma todo o trabalho. Perdas e danos podem ser irreparveis,
nesse caso, especialmente pelo sentimento de ter sido enganado, e
certamente no haver prazo cumprido.
111
Unidade 3
d) Escala de valores
O que Page-Jones chama de escala de valores est apresentado
na gura 3.6 a seguir. O projeto tem um determinado custo
para ser desenvolvido, que est representado pela linha tracejada,
enquanto os ganhos a serem auferidos com o projeto nalizado
esto representados pela linha contnua. A denio da melhor
data para entregar o projeto est relacionada com o melhor valor
agregado possvel. Parta do princpio que tal primeira data
seja exeqvel, e que todas as anlises levaram a denir essa
data como adequada. Os atrasos que ocorreram faro a data de
entrega escorregar para a direita no grco, e o valor adicional
de vantagens vai diminuindo proporcionalmente, at atingir um
ponto onde no h mais valor agregado, e os prejuzos comearo
a aumentar progressivamente.
Considere o projeto para desenvolver um novo
alimento, algo que ser lanado na Pscoa, por
exemplo. Caso o lanamento se d muito prximo da
data festiva, no ser possvel vencer a concorrncia
e o encalhe de produtos pode ser catastrfco. Ou o
lanamento de um novo veculo no fnal do ano. Se
o projeto no for concludo a tempo, voc j sabe
como ser o resultado para o fabricante. Nessa escala
de valores que se baseiam as datas para defnir
lanamento de novas verses de software, ou novas
plataformas, e assim por diante. No , portanto, algo
aleatrio ou baseado em desejos, e desta forma deve
ser bem medida a capacidade de realizar o projeto,
para que a frustrao no seja fatal.
112
Tempo
$
Incio do
projeto
Primeira
data de
entrega
Data fatal
onde os custos
superam as
vantagens
Curva dos
custos do
projeto
Curva do
valor gerado
pelo projeto
Valor agregado
Figura 3.6 Representao das vantagens relativas de um projeto considerando o prazo
(adaptado de Page-Jones, 1990).
- Ento, o que no fazer no momento de denir prazos de um projeto?
Bem, considerando as implicaes que voc acabou de ver,
importante:
No ceder ao primeiro impulso de se denir uma data,
sem antes analisar o mximo possvel de dados do
projeto.
Perceber quando a data denida no passa de um desejo
racionalizado, e ento buscar esclarecer o porqu
da data, ou mesmo declinar do projeto para evitar o
fracasso.
Discutir em detalhes todos os objetivos do projeto, para
evitar depois uma srie de novos compromissos que no
haviam cado claros no incio.
Perceber com a maior clareza possvel a escala de valores
do projeto ao longo do tempo, evitando embarcar em um
projeto onde a primeira data de entrega esteja prxima
demais da data fatal.

113
Unidade 3
SEO 5 Viabilidade do projeto
Voc j estudou sobre a origem das idias de novos projetos,
das suas motivaes, dos requisitos do cliente, da viso geral do
projeto e do conceito de prazo nesse tipo de empreendimento
com hora marcada para terminar. Porm resta analisar, antes
de comear um projeto, se de fato ele vivel e quais os riscos
envolvidos na sua execuo.
Muitas vezes um projeto iniciado sem um estudo de
da sua viabilidade nem dos seus riscos, o que tem sido
a fonte de inmeros fracassos.
Mesmo os projetos muito simples precisam de um estudo de
viabilidade, e tal estudo dar condies de se tomar as melhores
decises desde o seu incio, minimizando riscos, despesas
extraordinrias e atrasos.
Projetos complexos, que envolvem mltiplas disciplinas
e grandes custos, podem exigir um estudo de viabilidade
como documento preparado por consultoria externa e
anlise aprofundada.
Alguns autores denem como sendo trs os fatores
preponderantes a serem analisados num estudo de
viabilidade: recursos, custos e benefcios. Considero que
o prazo um quarto fator, apesar de ser visto como parte
dos recursos disponveis (o tempo um recurso, assim como o
dinheiro), pois o prazo muitas vezes determinado externamente
e no varivel.
Assim, esses quatro fatores podem ser vistos como elementos
inter-relacionados, como apresentado na Figura 3.7 a seguir.
Voc observar cada um deles em separado e depois suas inter-
relaes, observando que no estudo de viabilidade tais fatores
ainda no so estimados com grande nvel de detalhamento, mas
apenas o suciente para se ter uma viso geral do projeto.
114
custos prazo
recursos
benefcios
Figura 3.7 Fatores fundamentais na viabilidade dos projetos.
Benefcios
Os benefcios so os resultados positivos esperados do projeto
depois de nalizado. Alguns dos benefcios so facilmente
mensurveis e outros no. Os mensurveis so aqueles que
poderemos comparar com o que se tinha antes do projeto ter sido
realizado.
Observe a lista de exemplos:
Aumento do patrimnio (construo de mquina-
ferramenta, edifcao).
Aumento do faturamento (ascenso das vendas,
reduo de desistncias).
Maior lucratividade (diminuio de custos, maior
preo de venda devido ao valor agregado ao
produto).
Maior agilidade (na produo, na resposta a
solicitaes externas e internas).
O projeto pode trazer tambm uma srie de benefcios cuja

medio no to simples quanto comparar lucros ou tempo de
resposta. Nesse caso estamos falando de benefcios intangveis,
que podem ser to ou mais importantes que os tangveis.
115
Unidade 3
Pense nos seguintes itens:
Aumento da satisfao dos clientes (apesar de ser possvel
medir por meio de pesquisas, este um item subjetivo e
bastante varivel).
Fixao de determinada marca como lder de qualidade.
Sensao de time vencedor.
Recursos
Considere os recursos como sendo materiais (equipamentos,
instalaes, softwares etc.) e humanos (a equipe do projeto).
Projetos que envolvem o desenvolvimento de novas mquinas, por
exemplo, exigiro como parte dos recursos o acesso a laboratrios
de testes.
Acompanhei, por um perodo, o desenvolvimento de
novos equipamentos de telefonia de uma empresa bastante
inovadora. Para que seus produtos pudessem ter sucesso na
acirrada competio desse mercado, era necessrio que tivesse
determinadas certicaes emitidas por laboratrio credenciado
em organismos nacionais e internacionais.
Esse tipo de laboratrio era raro na sua regio e, desta forma, a
empresa se via obrigada a recorrer a laboratrios do exterior. Esse
era um recurso difcil para ela. Diferente do setor de hardware,
o setor de software dispe de maiores facilidades de recursos,
e nisso se baseia o crescimento de certas regies carentes de
recursos caros (como o exemplo do laboratrio).
Pases como o Brasil, China e ndia conseguem crescer
rapidamente nesse setor por esse motivo, onde os recursos
materiais so escassos, mas recursos humanos talentosos so
abundantes.
Voc vai conhecer, em detalhes, sobre a questo dos recursos
humanos e sobre a constituio de equipes neste livro, mas
importante ressaltar aqui que os recursos humanos adequados
no so apenas os que detm certo tipo de conhecimento tcnico,
algo que no o bastante. preciso dispor de pessoas com
conhecimento tcnico e com capacidade de trabalho cooperativo,
base fundamental de todo projeto.
Para obter outras

informaes acesse o stio
da SOFTEX - Sociedade para
Promoo da Excelncia do
Software Brasileiro, sobre
os mercados de software
do Brasil, China e ndia,
disponvel em: http://www.
softex.br/cgi/cgilua.exe/sys/
start.htm?sid=177 .
116
Custos
Considerando os recursos materiais e humanos necessrios para o
desenvolvimento do projeto, recursos nanceiros sero necessrios
para custe-lo. A esses recursos damos o nome de custos do
projeto, geralmente considerada a sua parte mais delicada.
Ora, possvel dispor de excelente pessoal, idias brilhantes,
domnio tecnolgico e um mercado potencial, mas as diculdades
da sobrevivncia diria podem impedir o uso de certo montante
de dinheiro em um projeto, mesmo considerando seu provvel
sucesso.
Isso no um contra-senso, pois o uso de tal montante pode
signicar a paralisao de uma estrutura j em andamento ( o
que acontece, por exemplo, com as pequenas empresas de base
tecnolgica, que para nanciar novos projetos necessitam de
recursos externos, geralmente governamentais).
H tambm projetos importantssimos, mas com custo to
alto que os inviabiliza. Veja o exemplo do Projeto Iridium, de
telefonia global com o uso de estaes em satlites, que acabou
falindo devido aos seus enormes custos.
Essa foi uma entre as 20 maiores falncias da histria
americana, onde cada simples telefone com acesso
a algum dos 66 satlites do sistema custava U$
3.000. Com esse preo houve poucos usurios
dispostos a comprar, o que inviabilizou a construo
a manuteno do sistema que custou perto de U$ 5
bilhes.
O projeto Iridium no conseguiu emplacar mais de 10 mil
usurios. O problema que alm do custo do aparelho havia
tambm o problema do alto custo do minuto, a diculdade de
usar o equipamento dentro de edicaes e as falhas constantes
de sinal. Junto a isso ainda tivemos a introduo da telefonia
celular, muito mais barata e til em suas aplicaes. Calculem o
prejuzo e a falta de anlise de custos e benefcios deste caso.
117
Unidade 3
Prazo
A questo da denio de prazos voc j estudou na seo
anterior, e aqui cabe ressaltar seu papel fundamental na anlise
da viabilidade de um projeto.
Certamente, se os prazos denidos forem irreais, o projeto ser
invivel e fracassar
O estudo de viabilidade deve considerar o prazo com especial
cuidado.
Muitas vezes o projeto encomendado tem os recursos
necessrios, pessoal especializado e com grande domnio
da tecnologia, e o pagamento bastante bom, mas o prazo
exageradamente curto no pode ser resolvido com a incluso de
mais pessoas, por exemplo.
No desenvolvimento de um sistema computacional o acrscimo
de membros na equipe pode, s vezes, signicar o acrscimo de
confuso.
Voltando agora gura 3.7, voc pode observar que esses quatro
fatores so elementos inter-relacionados. Considerando tais
relaes possvel aprofundar o estudo de viabilidade.
Vericando esse conjunto de fatores e suas inter-relaes,
percebe-se que uma espcie de sombra est o tempo todo
rondando a anlise: estamos falando dos riscos.
Repetidas vezes essa palavra apareceu ou cou subentendida,
e ela denota algo inerente a todo empreendimento humano: a
chance do erro e do fracasso, seja no conjunto ou no detalhe.
118
Benefcios versus custos
Apesar de benefcios evidentes, um projeto pode ter custos to altos
que no vivel execut-lo. Ou, ao contrrio, custos muito altos
podem fazer parecer que os benefcios no so razoveis. Em questes
estratgicas, a viso dos benefcios ultrapassa a capacidade de medir
valores fnanceiros. O gestor (operacional) enxerga as questes
fnanceiras imediatas, enquanto o lder (estratgico) poder ver
oportunidades fnanceiras futuras.
Gostaria de colocar aqui uma experincia que tive e que ilustra
essa situao. Durante os anos 70 e 80 o Brasil teve de considerar se
investia ou no no desenvolvimento de tecnologia para a fabricao
de circuitos integrados. Gestores, e no lderes, consideraram o custo
alto demais para um pas pobre como o nosso e preferiram questes
imediatas (na poca) como formar contingentes de mo de obra
barata para a indstria de transformao, construir grandes obras
e negligenciar a educao bsica. O mundo deu muitas voltas e
hoje quase a totalidade dos equipamentos incorpora chips, fazendo
deles uma infra-estrutura necessria e de alto valor agregado. Bem,
acontece que novamente agora nos anos 2000 o debate sobre o
desenvolvimento tecnolgico da fabricao de chips se colocou em
nosso pas, e uma iniciativa do governo gacho, em parceira com o
Ministrio da Cincia e Tecnologia, est colocando a duras penas uma
unidade de fabricao em Porto Alegre. Comentei o assunto com um
ex-professor de engenharia (graas aos cus no foi meu professor!),
que disse que esse no era assunto para um pas pobre como o
nosso. Defensor tcito de um sistema de submisso, ex-professores,
como esse, fazem linha com os que condenam nossa sociedade a
compradora de bens de alto valor agregado. Ele no soube (nem nunca
poderia saber) enxergar os benefcios daquele investimento. Enquanto
isso a China trilhou aquele caminho que negamos a ns mesmos, e
agora est prestes a se igualar capacidade tecnologia dos norte-
americanos (os resultados todos ns podemos ver).
Benefcios versus recursos
Aquele que contrata o projeto, ou que tem a idia geradora do mesmo,
percebe seus benefcios, porm ser necessrio avaliar se os recursos
para sua produo esto disponveis. No se trata aqui de ter condies
fnanceiras para desenvolver o projeto (seus custos). Pode-se ter
clareza dos benefcios a atingir e condies econmicas, mas talvez os
recursos humanos no sejam apropriados, no estejam disponveis e
119
Unidade 3
nem mesmo possvel contrat-los. No exemplo do laboratrio
de certifcao, citado anteriormente, pode acontecer de estar
disponvel apenas em um outro pas e com agenda lotada para
muitos meses, independente de podermos pag-lo ou no.
Tomemos outro exemplo, o do Projeto Apolo para levar o
homem Lua. Havia dinheiro e benefcios a conquistar, mas os
recursos tecnolgicos e os conhecimentos para tanto ainda nem
existiam quando o projeto comeou. Nesse caso o estudo de
viabilidade apontava para um projeto de alto risco, que acabou
sendo decidido por questes polticas, e foi vencido depois de
vrios anos.
Ou seja, preciso que os recursos estejam ajustados aos
benefcios a serem conquistados, e o estudo de viabilidade deve
estar atento a isso.
Benefcios versus prazo
preciso avaliar se os benefcios ainda tero valor, considerando
o prazo que o projeto poder tomar para chegar aos objetivos.
Nesse caso, estamos avaliando a viabilidade do projeto sobre a
sua escala de valores. E alm dos valores fnanceiros preciso
tambm considerar valores intangveis do projeto.
No exemplo do Projeto Apolo, bem provvel que os valores
nanceiros mensurveis poca tenham sido desastrosos,
mas de maneira alguma foram ruins os ganhos polticos e
cientcos, de difcil medio naquele momento (estamos
falando de 1969), mas enormes dali em diante. Lanamento
de novos produtos no mercado, no entanto, no tm um
valor poltico associado, mas sim a busca de liderana e
posicionamento de marca.
Nesses casos o benefcio est fortemente vinculado ao prazo. Essa
anlise comparativa deve ser feita na avaliao da viabilidade do
projeto.
SEGUE
120
Ao atravessarmos a rua h o risco de surgir um carro
em alta velocidade, ao entrar no mar h o risco
de uma corrente mais forte, ao sair para o passeio
no campo h o risco da chuva, ao iniciarmos uma
empresa h o risco de uma falncia, ao fazermos uma
venda h o risco da inadimplncia, e assim por diante.
Por mais que tentemos prever todas as chances de erro, l elas
estaro. Isso to presente em nossas vidas que os riscos entram
at no anedotrio. Quem nunca ouviu as famosas (e s vezes
trgicas) Leis de Murphy?
Recursos versus custos
Essa anlise parece bastante simples: possvel pagar pelos recursos
necessrios? O projeto invivel se a resposta for negativa.
Recursos versus prazo
A pergunta agora passa a ser: os recursos estaro disponveis pelo
tempo necessrio? Pois possvel que se tenha todos os recursos
necessrios e dinheiro sufciente para pag-los, mas tudo continuar
funcionando pelo tempo necessrio para o projeto.
Equipes, por exemplo, sofrem desgaste, e as tecnologias
envelhecem (ao contrrio do conhecimento cientco).
Prazo versus custos
Por fm, importante considerar por quanto tempo o fnanciamento
do projeto se manter. Inicialmente o valor a ser investido pode
parecer adequado, os recursos esto ajustados e os benefcios so
promissores. Mas qualquer extenso do prazo pode signifcar uma
chamada de investimento, que talvez no esteja disponvel. Este risco
real e sempre muito provvel, e tal considerao merece ateno
especial no estudo de viabilidade. Inmeros projetos fracassam nesse
momento.
121
Unidade 3
Uma delas diz que, se vrias coisas podem dar errado,
elas daro, e na pior seqncia possvel!
- E ento, o que voc achou? Observe agora o quadro a seguir!
Leis de Murphy da Tecnologia
As Leis de Murphy j caram no anedotrio popular, pois
todo mundo que tem algum sentimento de que o risco vai,
inevitavelmente, se transformar em realidade, manifesta esse
sentimento na forma de uma lei. Certamente no so leis, mas
levam muita gente a considerar com mais cuidado os riscos.
Veja abaixo as Leis de Murphy para a tecnologia, conforme
publicado no stio da Universidade Federal da Bahia no endereo
http://www.facom.ufba.br/com024/murphya/tecno.htm
(acessado em 12/junho/2005).
O progresso no consiste
em substituir uma teoria
errada por uma certa, e
sim uma errada por uma
aparentemente certa.
O defeito s aparece depois
que a unidade passou pela
inspeo fnal.
Depois que um
equipamento foi montado
e funciona perfeitamente,
encontram-se em baixo
do banco diversas peas
fundamentais.
Se sua experincia
fracassou, destrua todas as
provas que tentou.
As variveis variam menos
que as constantes.
A nica pea que a fbrica
esqueceu de embarcar
indispensvel para a
montagem de 75% do
equipamento.
A fbrica no esqueceu de
entregar, ela nem fabricou
a pea.
Como os teoremas da
matemtica se relacionam
com a realidade, no so
seguros. Sendo seguros
no se relacionam com a
realidade.
Em qualquer circuito
eletrnico o componente
de vida mais curta ser
instalado no lugar de mais
difcil acesso.
Qualquer desenho de
circuito eletrnico deve
conter pelo menos: uma
pea obsoleta, duas
impossveis de encontrar, e
trs ainda sendo testadas
(por voc, claro).
Depois que o ltimo dos
parafusos foi retirado da
tampa de acesso de um
SEGUE
122
equipamento, verifca-se que
foi removida a tampa errada.
Depois que o ltimo dos
parafusos da tampa de um
equipamento foi apertado,
verifca-se que alguma pea
fcou para fora.
O xito de uma demonstrao
inversamente proporcional
ao nmero de pessoas
importantes que assistem a
essa demonstrao.
Todo arame cortado no
tamanho indicado ser curto
demais.
No h nenhum problema
mecnico to difcil que no
possa ser resolvido com fora
bruta e ignorncia.
mais fcil separ-los do que
colocar tudo junto novamente.
Regra de advertncia: Para
escrever uma bula de remdio,
primeiro convena o leitor de
que ele tem a doena sobre a
qual ele est lendo; depois de
que, ela curvel.
Leis do Desenho:
Se voc desenhou, poderia
ter copiado.
Se copiou, poderia ter
decalcado.
Se decalcou, poderia cortar

e colar.
Se recortou e colou, poderia
ter xerocado.
Se xerocou, estava disponvel
na internet.
Leis da Dieta:
Pra no engordar h quem
coma somente verduras. Os
elefantes s comem verdura.
Pra no engordar h quem
coma somente peixe. As
baleias s comem peixe.
Nada to fcil quanto parece,
nem to difcil quanto a
explicao do manual.
A explicao mais simples
sucede a soluo mais
complexa.
Se tudo que voc tem um
martelo, trate tudo como um
prego.
Especialista aquele cara que
sabe cada vez mais sobre cada
vez menos.
Super-especialista aquele
que sabe absolutamente tudo
sobre absolutamente nada.
Cincia exata profetizar
sobre o que j aconteceu.
Leis de Murphy - continuao

123
Unidade 3
Em projetos o que h so riscos:
riscos de acabar o dinheiro;
risco de a idia no ser assim to boa;
risco de ningum se interessar;
risco de o prazo estourar vrias e vrias vezes;
risco de o cdigo nunca apresentar a sada esperada etc.
Estudar a viabilidade do projeto , antes de mais
nada, pesar os possveis benefcios, os custos, a
disponibilidade dos recursos e do prazo, comparando
com os riscos previsveis capazes de estragarem tudo.
No quadro a seguir voc observar um modelo de questionrio/
relatrio, bastante simplicado (e subjetivo), para um Estudo de
Viabilidade de Projetos. Ele no esgota todas as possibilidades
de anlise, pelo contrrio. Mas encaminha uma srie de questes
iniciais, com as quais devemos nos preocupar, para tentar
perceber se vivel prosseguir com o desenvolvimento do projeto
e contra quais riscos devemos nos resguardar.
Cada projeto, obviamente, trar questes particulares, que devem
ser tratadas e resumidamente descritas. Posteriormente, no caso
do projeto seguir em desenvolvimento, as estimativas detalhadas
de custos, benefcios e recursos sero tratadas, como voc poder
analisar na unidade 4.

124
Estudo de viabilidade
<nome do projeto>
Equipe de estudo:
Local e data:
Resumo do projeto (escopo, objetivos, estratgias)
Benefcios:
quais so as vantagens mensurveis que o projeto trar?
quais so os valores comparativos?

Descrio:
Benefcios:
que vantagens intangveis ele trar?
como se poder vericar?

Descrio:
Recursos:
quais os recursos materiais necessrios para o projeto?
esses recursos esto disponveis?
caso no disponveis, possvel obt-los?

Descrio:
Recursos:
quais os recursos humanos necessrios para o projeto?
essas pessoas esto disponveis para o projeto?
caso no disponveis, h outras pessoas para substitu-las?

Descrio:
Custos:
considerando os recursos necessrios, quanto dinheiro ser

necessrio para desenvolver o projeto?
esse montante est disponvel?

Descrio:
Custos:
h fontes de nanciamento?
Descrio:
Prazo:
qual o prazo pr-denido pelo cliente para o projeto?

Descrio:
Prazo:
considerando a experincia da equipe, qual o prazo estimado para o

projeto? igual ao pr-denido?
Descrio:
Concluses quanto viabilidade do projeto:
Recomendaes:
Anexos (tabelas, demonstrativos, estatsticas, reportagens, tendncias tecnolgicas e comerciais etc.)
Quadro 3.1 Modelo de relatrio para estudo de viabilidade de projetos.
125
Unidade 3
SEO 6 Antecipando e administrando riscos
Como voc estudou na seo anterior, os riscos de um projeto j
esto l antes mesmo de ele nascer.
Voc ver que possvel prever os riscos com a maior antecipao
possvel e, ento, administrar a sua existncia (j que no
possvel elimin-los completamente). Encare o risco como uma
ameaa, que pode levar o projeto ao erro, s perdas e ao fracasso.
Geralmente no possvel evitar essa ameaa.
Voc deve considerar os riscos conforme a
probabilidade de ocorrer e conforme o impacto que
ter sobre o projeto, caso ocorra.
H riscos de enorme impacto como, por exemplo, a falta de
recursos nanceiros bem no meio do projeto essa falta faz
simplesmente o projeto ser abortado. Voc deve ento
avaliar se h de fato a probabilidade de isso ocorrer. Se o
recurso nanceiro para custear o projeto no est depositado
previamente e depende de nanciamento externo, a
probabilidade de falta pode ser considervel.
Outra questo se refere ao impacto do risco do atraso do
projeto em um benefcio esperado. Se for o lanamento de um
produto de rea de forte concorrncia, o impacto enorme
e deve ser avaliada a probabilidade de ocorrer. H outros casos
onde a probabilidade de ocorrncia dos riscos alta, porm o
impacto deles mnimo.
Durante o perodo da construo de uma casa a
probabilidade de chuvas altssima, e sendo assim
uma srie de atividades alternativas programada,
fazendo com que esse risco tenha baixo impacto no
projeto.
Outra questo importante se refere origem dos riscos, onde
a gura a seguir apresenta de modo esquemtico. Os riscos
em projetos podem basicamente ser de origem interna e de
origem externa. Essa diferena de origem leva tais riscos a um
tratamento diferente quanto sua previso, administrao e
eliminao.
126
Risco interno
rea do projeto
Risco externo
Figura 3.8 Riscos internos e externos.
Riscos de origem interna
Os riscos de origem interna passam a existir a partir do
nascimento do projeto, e porque esse projeto assumiu certas
proposies e no outras.
Como voc observou na seo anterior, em um projeto existem
os recursos, os custos, os benefcios e os prazos. A escolha de
determinados recursos materiais, e no outros, pode determinar
a existncia ou no de certos riscos. Assim como a escolha de
membros para compor a equipe, considerados competentes
tecnicamente, mas que depois se verica a incapacidade de
trabalho em grupo.
Podem ser considerados tpicos riscos internos dos projetos:
Equipamentos defeituosos;
Equipe despreparada para trabalho em grupo;
Falta de domnio tecnolgico;
Gastos excessivos;
Estouro de prazo devido a falhas de desenvolvimento;
Estouro de prazo devido a erros no gerenciamento;
Necessidades tecnolgicas desconsideradas durante o
planejamento das etapas;
A complexidade do sistema, no devidamente percebida
nas etapas iniciais;
Alteraes no escopo do projeto.

127
Unidade 3
Riscos de origem externa
So aqueles que independem de qualquer atividade ou
planejamento do projeto, mas podem acontecer e afetar
seriamente o seu andamento. Um dos membros da equipe
adoecer no era previsvel internamente, e aconteceu devido a
causas externas. Dependendo da posio dessa pessoa na equipe,
isto pode afetar seriamente todo o desenvolvimento.
Podem ser considerados tpicos riscos vindos de agentes externos
aos projetos:
causas/fenmenos naturais;
crises polticas de uma regio ou pas;
crises econmicas;
doenas;
problemas do nanciador do projeto ou do fornecedor de
insumos/recursos;
alteraes na legislao;
presses da organizao, da sociedade, do cliente;
alteraes no mercado quanto s suas necessidades ou
capacidade de compra.
Com essas consideraes sobre origem, probabilidade e impacto
dos riscos sobre o projeto, h duas possibilidades de ao:
Deixar acontecer e ento tentar resolver. Por incrvel
que possa parecer esse o procedimento mais usual,
e a expresso descascar o abacaxi a que melhor
caracteriza esse procedimento. O gestor do projeto e
sua equipe esperam os abacaxis chegarem e tentam, do
jeito que der (se der), descasc-los. O resultado disso
bvio: desgaste, custos elevados, atrasos, e a sensao de
fracasso.
Antecipar e administrar os riscos. Essa abordagem
consiste em vericar antecipadamente a existncia de
riscos, planejar uma atuao sobre eles tentando elimin-
los ou, caso isso no seja possvel, administr-los.

128
Recentemente a Microsoft desenvolveu um framework
para a gesto de seus projetos, onde chama essa atividade
de gerenciamento proativo de risco (MSF, 1998), mas a
literatura j vem h muito tempo tratando desse assunto
simplesmente como gesto de riscos (Valeriano, 1998).
O processo de administrao de riscos deve ser contnuo, desde
o planejamento inicial do projeto at as suas ltimas etapas,
e consiste em um ciclo de atividades, conforme se pode ver
na Figura 3.9. Esse ciclo deve se repetir a cada nova etapa, e
os riscos identicados devem ser comunicados para todos os
participantes do projeto, seja para os de nvel inferior, seja para os
de nvel superior (mesmo que isso possa desagradar).
O ciclo para o tratamento dos riscos composto pelo seguinte:
Identicao de riscos;
Anlise;
Planejar ao sobre esses riscos;
Controlar/eliminar os riscos;
Nova etapa do projeto e nova identicao de riscos.
Identificar os riscos
Analisar os riscos
Planejar ao
sobre os riscos
administrar
Eliminar ou
os riscos
Etapa Nova Etapa
Figura 3.9 Antecipando e administrando riscos.

129
Unidade 3
Identicao de riscos
Este o primeiro passo na administrao dos riscos, e consiste
em sua identicao. O modelo apresentado no quadro 2,
abaixo, aponta diversas causas de riscos e proporciona uma
viso do projeto sob a perspectiva de suas ameaas. Esse tipo de
identicao deve ser feita reunindo a equipe do projeto, e a sua
experincia ser fator-chave para perceber proativamente os riscos
possveis. Eles devem ser colocados nas suas respectivas categorias
(quanto a recursos, quanto a custos, quanto a benefcios, quanto
a prazos) de tal maneira que a risco seja o melhor conhecido
possvel. A partir da sua identicao, deve ser descrito com
clareza, declarando sua origem e a conseqncia que trar ao
projeto, caso acontea.
Anlise
Partindo da identicao e da expresso clara e objetiva dos
riscos do projeto, o segundo passo consiste em analis-los, seja
quanto probabilidade, seja quanto ao impacto. Se o risco tiver
probabilidade de 100%, ser uma certeza, e no apenas um
risco. Se o risco tiver probabilidade prxima de zero, poder ser
desprezado.
Quanto ao impacto, se for muito reduzido, talvez no seja
necessrio despender esforos na tentativa de elimin-lo, esforos
esses que devem ser destinados a outras atividades. No h
certamente uma regra ou uma lei para esse tipo de tratamento.
Talvez alguns livros de gesto de projetos tragam frmulas
mgicas e escalas com pesos e medidas, mas a anlise do risco
detectado depender, na verdade, da experincia e bom senso da
equipe. A inexperincia de uma equipe , em si, um fator de alto
risco em um projeto. Claro que uma equipe iniciante deve ter
chance de se responsabilizar por um projeto, e necessrio que
isso acontea, para que se obtenha experincia!
Nesses casos projetos de baixa complexidade so os
recomendados, e ento um processo de identicao e anlise
de riscos, bem elaborado e estudado, trar conhecimentos
importantssimos para a carreira (digo isso porque vejo que a
maioria dos envolvidos em projetos no realiza tais estudos, e s
obtm experincia aps excessivos erros).
130
Uma sugesto muito interessante a tcnica dos 10 Mais,
apresentada pela Microsoft em seu framework para projetos
(MSF, 1998). Consiste em considerar apenas os dez riscos
avaliados como mais importantes para o projeto, por sua
probabilidade e impacto, e desprezar os demais. Esses 10 Mais
sero os considerados no planejamento para aes de controle.
Planejar aes sobre esses riscos
Identicados os riscos, conhecidas as suas probabilidades e o
impacto que podem causar no projeto, preciso planejar aes
para evitar ou reduzir tal impacto.
O processo de planejamento passa pelas seguintes perguntas:
Conhecemos o risco?
Podemos conviver com ele, se acontecer?
Como possvel atenuar seu impacto?
O que possvel fazer para evit-lo?
As respostas a essas perguntas levaro o projeto a um conjunto de
planos de ao.
Para que voc compreenda melhor, retorne ao
exemplo da construo da casa, e como o risco de
chuvas pode ser administrado. Ns conhecemos
esse risco e no possvel conviver com ele, ou seja,
no possvel continuar o projeto normalmente
enquanto chove. Evitar a chuva no possvel, a no
ser que se gaste uma elevada soma e se construa
uma enorme lona de circo sobre a rea do projeto (o
que no parece vivel). O que possvel fazer ento
para atenuar o risco? Em alguns casos o proprietrio
simplesmente pra a obra e aguarda o perodo de
chuvas ir embora. Se ele considerou isso no prazo da
obra, parece ser uma soluo. Outra ao possvel
seria deixar preparada uma rea coberta da obra para
preparao de caixarias, ferragens, e outras atividades
desse tipo.
Num projeto de desenvolvimento de software um risco
considervel est relacionado ao prazo. Se esse risco de
grande impacto, e uma possvel causa sejam as decincias

131
Unidade 3
de conhecimento tecnolgico pela equipe, a ao proativa de
treinamentos intensivo pode amenizar tal risco. Outra ao a
de incluir um membro experiente naquela tecnologia (se houver
recursos nanceiros para isso). Enm, cada risco detectado
merecer uma discusso sobre aes preparatrias, e quando
os riscos do projeto forem altos demais, talvez seja melhor no
aceitar o projeto.
Controlar/eliminar os riscos
Identicados os riscos, analisados e criados os planos de ao, a
hora de colocar as coisas para andar. As aes devem ter data para
comear, e uma vez colocadas em andamento, os riscos devem ser
monitorados. Se determinada ao teve sucesso, o risco pode ter
sido eliminado. Caso no tenha sido eliminado e surja no meio
do projeto, deve ento ser controlado para determinar o mnimo
impacto possvel no projeto. Se havia o risco de um atraso,
por exemplo, e o atraso aconteceu, o plano de contingncia
de ampliar a equipe ou terceirizar partes do projeto deve ser
colocado em prtica, buscando a todo custo manter a data nal de
entrega em garantia.
Controlar os riscos o ltimo passo do ciclo da administrao
dos riscos, e basicamente se divide em:
controlar os planos de ao preventivos;
monitorar a ecloso dos riscos previstos;
responder ecloso de tais riscos com aes corretivas;
monitorar o surgimento de novos riscos, no previstos;
refazer o planejamento de aes;
integrar-se ao processo global da gesto do projeto.
No quadro 3.2 - Modelo de relatrio para estudo de riscos de
projetos, so apresentadas diversas questes importantes para
deteco, anlise e aes preparatrias contra os riscos do projeto.
Tal modelo pode, e deve, ser adaptado para as condies de cada
projeto e cada equipe. Toma tempo inicial da equipe do projeto,
mas garantir ganhos substanciais no decorrer dos trabalhos, seja
por evitar riscos, seja pelo conhecimento aprofundado que trar a
todos os envolvidos sobre o trabalho que vir pela frente.

132
Estudo de riscos
<nome do projeto>
Equipe de estudo:
Local e data:
Resumo do projeto (escopo, objetivos, estratgias)
Riscos quanto aos benefcios:
- o cliente tem uma idia exata do resultado a ser obtido?
- ou tem uma idia aproximada?
- possvel medir os benefcios?
Descrio:
Riscos quanto aos benefcios:
- qual a probabilidade desse tipo de riscos?
- qual o seu impacto?
Descrio:
Riscos quanto aos recursos:
- h equipamentos de reserva?
- h pessoal de reserva?
- a tecnologia empregada inteiramente dominada?
Descrio:
Riscos quanto aos recursos:
Descrio:
Riscos quanto aos custos:
- o nanciamento de todo o projeto est garantido?
- h um montante de reserva?
Descrio:
Riscos quanto aos custos:
Descrio:
Riscos quanto ao prazo:
- h fatores internos ou externos, no considerados, que podem
afetar o prazo do projeto?
Descrio:
- a equipe de projeto experiente?
Descrio:
Descrio:
Lista dos 10 riscos mais importantes:
Podemos conviver com eles?
possvel atenu-los?
possvel evit-los?
Concluses quanto aos riscos do projeto:
Anexos (tabelas, demonstrativos, estatsticas, reportagens, tendncias tecnolgicas e comerciais etc.)
Quadro 3.2 Modelo de relatrio para estudo de riscos de projetos.
133
Unidade 3
Sntese
Na primeira seo desta unidade foram discutidas as formas de
se identicar o problema que pode dar origem a um novo projeto,
e como avaliar tal projeto. O principal conceito explorado de
que se deve desenvolver uma viso geral, de partido amplo, para
que se tenha de fato uma concepo estratgica, e no meramente
ttica ou operacional, do projeto. Essa questo bastante
importante e deve car xada, para evitar o desenvolvimento
futuro de projetos inconsistentes.
Em seguida, voc estudou que na origem de um projeto esto
presentes certos requisitos, que foram chamados de requisitos
do cliente, que so as verdadeiras expectativas de resultado
do projeto, e que, caso no satisfeitas, levaro ao fracasso do
mesmo. Ora, perceber com acuidade tais expectativas , portanto,
determinante e ateno especial deve estar a colocada.
Entendidos tais requisitos e colocados sob uma ampla
perspectiva, uma srie de passos deve ser determinada ento
para planejar e executar o projeto, cujo algoritmo visto na
terceira seo um modelo importante. Seguir tal algoritmo no
determinar o sucesso do projeto, mas no segui-lo trar, com
grande probabilidade, seu fracasso (a no ser que o projeto seja
muito pequenino).
Algoritmo um uxo, e tal uxo traz inmeros passos que
devem ser executados num determinado prazo. Projetos, por
denio, tm prazo para acabar. O grande problema ento est
em determinar esse prazo, o qual muitas vezes nasce do requisito
do cliente e de necessidades de mercado, mas isso tudo deve
ser ajustado factibilidade de execuo. Devemos evitar prazos
irreais apenas para fechar um negcio.
Por m voc estudou riscos. Ao nascer o projeto traz no seu
DNA a condio do risco, o risco inerente a qualquer projeto.
Em primeiro lugar porque os projetos tm sempre data para
terminar e o tempo no algo simples de controlar. E como
os riscos esto entranhados nos projetos preciso prev-los e
administr-los, da melhor maneira possvel, para evitar perdas e
corresponder expectativa dos requisitos do cliente. H formas
134
de evitar riscos, ou conviver com eles, mas para isso preciso
conhecer de onde vm e qual seu impacto. Para isso foram
desenvolvidos modelos de relatrios e questionrios de procura, e
seu uso, aliado experincia individual dos membros da equipe,
dar tranqilidade para continuar projetos, mesmo que sob
tempestades.
Na prxima unidade voc vai colocar a mo na massa do
planejamento, onde vrias tcnicas e metodologias sero
apresentadas, estudadas e exercitadas. Enquanto isso, rememore
os conceitos que esto aqui, leia os artigos indicados e trabalhe
nas atividades de auto-avaliao. Os projetos esperam voc!
135
Unidade 3
1) Considere o seguinte problema, colocado por um cliente:
Atualmente meu pessoal da rea comercial emite propostas de
servios usando planilhas de clculo Excel e documentos gerados no
Word. Quando o cliente d o aceite na proposta, muitas vezes vrios
itens da proposta foram modifcados, porm isso no ajustado na
planilha. O pessoal de vendas precisa ajustar a lista de produtos a
serem entregues e faz isso manualmente, gerando uma nova lista. A
nota fscal emitida mo, e fnalmente a reposio do estoque feita
por meio de constantes verifcaes nas prateleiras. Eu gostaria de
automatizar meu processo de reposio de estoques.
Em sua opinio, qual o escopo do problema segundo uma avaliao
restrita, e qual seria uma viso ampla desse mesmo problema?
136
2) Quando o cliente descreve o seu problema, ele o faz com a prpria
linguagem e com uma viso particular, que muitas vezes indica um
caminho de soluo. Voc sabe que muitas vezes esse caminho pode
no levar melhor soluo. Veja a fgura a seguir, que apresenta um
diagrama com a coleta de informaes e requisitos do cliente, visando
o melhor entendimento do problema proposto. Considerando esse
diagrama e sua experincia, liste as principais aes que voc deve
tomar para chegar ao melhor entendimento do problema.
ou
ou
Problema
definido
Defeito a
eliminar
Novo
produto
Dados
coletados
Desenho,
diagrama
ou modelo
Hipteses
de soluo
Outras
informaes
Objetivos
do projeto
137
Unidade 3
3) Qual a funo do algoritmo no planejamento do projeto?
4) Qual a funo da reviso durante o projeto? No seria o mais correto
realizar a reviso apenas aps a sua concluso?
138
5) Como voc defne a data fatal do projeto ? (veja a fgura abaixo)
Tempo
$
Incio do
projeto
Primeira
data de
entrega
Data fatal
Curva dos
custos do
projeto
Curva do
valor gerado
pelo projeto
Valor agregado
139
Unidade 3
6) Para uma anlise de viabilidade, quais fatores devem ser considerados?
D um exemplo de projeto de sua prpria experincia de trabalho, e
como tais fatores foram considerados.
7) Riscos so inerentes a qualquer projeto. Por qu?
140
Saiba mais
1 - www.softex.br/cgi/cgilua.exe/sys/start.htm?sid=177 -
link para estudo da SOFTEX, Sociedade para Promoo
da Excelncia do Software Brasileiro, sobre os mercados de
software do Brasil, China e ndia.
2 - http://www.softex.br/cgi/cgilua.exe/sys/start.htm?sid=37 ,
neste link h um conjunto de estudos e artigos sobre a situao
do software no Brasil, constantemente atualizados e que
permitem uma viso ampla das oportunidades de negcio no
mercado da informtica.
4
UNIDADE 4
Planejamento
Compreender os diversos modelos que representam o

desenvolvimento de projetos, especialmente aqueles
voltados para as inovaes tecnolgicas.
Distinguir duas tcnicas de planejamento de projetos,

uma que j tem um sculo desde sua criao e que
extremamente popular e til, e outra que surgiu h mais
ou menos 50 anos e que veio complementar diversas
lacunas e desvantagens da primeira.
Analisar essas diferentes tcnicas e mtodos de

planejamento, com exerccios e exemplos prticos.
Incorporar o planejamento, por meio de ferramentas, s

atividades iniciais de um projeto.
Verifcar que as estimativas de recursos, custos e prazos
so mais coerentes e consistentes quando embasadas
em um planejamento detalhado.
Sees de estudo
Seo 1 Modelagem do fuxo de atividades.
Seo 2 Metodologias de planejamento Grfco de Gantt.
Seo 3 Metodologias de planejamento PERT/CPM.
Seo 4 Estimativa de recursos.
Seo 5 Estimativa de custos.
142
Esta unidade fundamental para dar o primeiro passo prtico na
execuo de um projeto.
Nas unidades anteriores voc percebeu que a histria dos projetos
na humanidade comeou com obras marcantes, mas que no
contavam com um planejamento detalhado. Com a Revoluo
Industrial muitas coisas mudaram, especialmente a forma de se
produzir, e o tempo de produo at chegar ao mercado. Voc
viu tambm que, atualmente, para que um projeto possa ser
planejado e conduzido durante a sua execuo, necessrio ter
uma viso abrangente e estratgica, com um comportamento
muito mais de liderana do que de simples controle. Mas controle
necessrio.
Nesta unidade voc ver algumas ferramentas muito teis para
apoio ao planejamento, para a estimativa de recursos e de custos,
para a denio de prazos e para a administrao dos riscos. Sem
essas ferramentas os projetos seriam praticamente impossveis
de gerenciar. Ser apresentado o Grco de Gantt, que
provavelmente voc j conhece. Ultimamente esse tipo de grco
sofreu alteraes e foi incorporado pelos softwares de gesto de
projetos, sendo provavelmente a tela mais popular de todos eles
(quando no a nica). Junto ao Grco de Gantt voc aprender,
tambm, como construir diagramas que mostram o caminho
crtico de um projeto, ou seja, aquela seqncia de atividades que
dependem umas das outras, e que denem ento um prazo e uma
conduo crtica do projeto. Qualquer alterao nesse caminho
vai afetar todo o projeto (e prazo, em especial).
Tais ferramentas so teis para o controle do projeto, mas
tambm permitem toda espcie de estimativas, sejam de recursos
necessrios ao projeto, sejam de custos ou de prazos. O estudo
de como realizar essas estimativas o objeto da concluso desta
unidade. Bons estudos!!
143
Unidade 4
SEO 1 Modelagem do uxo de atividades
Na unidade anterior voc estudou que preciso ter uma viso
geral do projeto que permita avaliar sua viabilidade, os possveis
riscos, as necessidades gerais para que seja desenvolvido e para
que se obtenham os resultados esperados.
Certamente durante esse processo de viso geral e estratgica,
no possvel detalhar todos os elementos do projeto, mas
suciente para decidir sobre a sua viabilidade e ento dar um
passo alm: partir para o desenvolvimento do projeto.
A partir dessa idia geral ser necessrio agora comear a
detalhar o projeto, e o primeiro elemento a sua modelagem e a
denio de um uxo de atividades.
O modelo de um objeto uma representao,
uma simplifcao desse objeto de forma que
possamos entend-lo de forma abrangente.
- Para car mais claro, veja o exemplo a seguir:
A maquete de um prdio um modelo de como
ser o prdio ao fcar pronto. Ele mostra as partes do
edifcio, seu aspecto geral, numa proporo muito
boa para que voc possa entend-lo antes de fcar
pronto. Ele no o prdio, apenas o modelo do
prdio. No entanto, voc pode comear a detalhar
mais e mais o modelo desse prdio, como por
exemplo fazendo os projetos de instalaes eltricas
e de telecomunicaes dele. Os desenhos dessas
instalaes so representaes, bem detalhadas, de
como sero tais instalaes, porm continuam sendo
modelos pois no so as instalaes em si.
144
Os modelos so usados para facilitar a viso do futuro
objeto, e ao mesmo tempo podem ser usados para
ajudar a construir tal objeto, ou seja, o modelo pode
ajudar a realizar o projeto e chegar ao resultado fnal
esperado.
H um modelo muito interessante de representao da
realidade, que todos ns usamos, mas no nos damos conta:
a nossa lngua. As palavras, e a forma como elas se relacionam,
permitem que ns possamos representar o real e comunicar para
outras pessoas as nossas idias. Estas, por sua vez, precisam
compreender esse modelo de representao para decodicar o
que falamos, criar as imagens mentais (compilar), e responder
novamente usando esse modelo comum.
Pessoas que falam lnguas diferentes no conseguem se
comunicar, pois no dominam a mesma modelagem.
Nesses casos usam outras formas de representao,
como a mmica, por exemplo, que, no entanto, muito
mais limitada. Na comunicao entre o ser humano e a
mquina preciso tambm uma linguagem.
Modelar, dessa forma, signifca representar um
sistema, ou parte dele, em forma fsica (a maquete,
por exemplo) ou simblica (desenho do projeto
eltrico, por exemplo), de tal maneira que se possa
predizer ou descrever seu comportamento. Assim,
o modelo de representao uma idealizao do
sistema fsico, e ele nos auxilia na anlise e na soluo
dos problemas. Sem os modelos no haveria a
civilizao como a conhecemos.
Algumas das principais caractersticas dos modelos, e que fazem
com que tenham grande valor, so:
usando um modelo no preciso trabalhar diretamente
com o sistema fsico real, ou seja, no necessrio pegar
a ma para querer dizer ma, basta pronunciar a
palavra, ou ainda, no preciso construir o prdio inteiro
para mostr-lo, basta desenhar uma fachada ou construir
uma maquete;

145
Unidade 4
prtico e seguro trabalhar com modelos, pois caso as
coisas no se agurem to boas, voc pode abandonar
tudo no comeo;
graus de preciso dependero do aprimoramento
do modelo, ou seja, conforme voc queira ter maior
preciso de como ser o projeto no nal, voc pode ir
aprimorando paulatinamente o prprio modelo;
reduo de tempo na anlise, pois no necessrio ter o
projeto pronto para fazer as primeiras simulaes;
o modelo abstrai o problema para o campo de domnio
daquele que o analisa, quer dizer, ao modelar um
problema, cada um o faz no campo que tem domnio;
se um desenhista, faz o desenho, se um escultor,
cria a maquete, se um matemtico, coloca na forma de
equaes, se um escritor, coloca na forma de uma co
ou poema, e assim por diante;
os modelos no so nicos, ou seja, possvel diversos
tipos diferentes de modelo para uma mesma coisa;
no caso do prdio, pode ser representado por meio de
uma maquete de madeira e papelo, ou ento por uma
maquete eletrnica, ou pelo desenho artstico da fachada
etc., sendo que todas tero o seu valor;
como o modelo apenas uma representao, uma
reduo do real, ele contm erros, os quais so inerentes
ao seu carter de reduo.
Com essas caractersticas voc pode perceber que os modelos tm
inmeras utilidades, no s para planejar a gesto de projetos,
mas para planejar o prprio projeto. Basicamente pode-se
considerar como utilidades dos modelos de representao:
modelos ajudam a PENSAR modelos so instrumentos
que permitem visualizar e pensar acerca de um sistema
e do seu comportamento; boa parte dos problemas e
das solues de um projeto voc consegue perceber e
imaginar sobre esse instrumento;

146
permitem COMUNICAR com um modelo bem
representado possvel transmitir informaes sobre o
projeto, e isto importantssimo na gesto da equipe;
possvel PREVER com um modelo apropriado
possvel simular o comportamento do sistema, e com isso
prever ser provvel comportamento;
permitem CONTROLAR com um modelo voc tem
condies de criar sistemas que simulam comportamento,
e dessa forma possvel criar critrios de controle,
inicialmente usados no modelo e depois associados ao
sistema fsico real;
ajudam a ENSINAR assim como os modelos ajudam a
comunicar, passam, assim, a ser importante instrumento
de auxlio na educao e no treinamento, pois
representam o objeto numa escala menor e de testes.
Conforme Bazzo (1997), os modelos para apoio a projetos de
engenharia e tecnologia podem ser divididos em quatro tipos:
Modelo Icnico o modelo que representa com alto grau de
semelhana o sistema fsico, seja em duas dimenses (como no
caso das fotos e mapas, como na gura 4.1) ou em trs dimenses
(maquetes, esculturas, prottipos).
Figura 4.1 Exemplo de representao icnica mapa urbano.
Modelo Diagramtico tem pouca semelhana com o sistema
fsico, e apresentado por meio de smbolos, linhas, diagramas.
Facilita a compreenso do funcionamento de uma mquina, um

147
Unidade 4
processo ou sistema, sem dispersar a ateno em detalhes de outra
ordem, e um bom exemplo disso so os uxogramas que usamos
nas empresas, mostrando como se d o uxo de processos, ou
ento o organograma dessa mesma empresa, que mostra como se
distribuem os cargos e departamentos. No entanto, por ser uma
representao um pouco mais especializada, serve para aqueles
que conhecem a conveno usada no diagrama (veja exemplo na
gura 4.2).
Figura 4.2 Exemplo de representao diagramtica diagrama de atividades da UML
Linguagem de Modelagem Unifcada (GOOCH, 2000).
Modelo Matemtico um modelo simblico abstrato, que
est cada vez mais associado aos problemas de tecnologia
avanada, sendo o de aplicao mais importante na engenharia.
Os modelos matemticos so os mais poderosos instrumentos
de representao, e tm permitido modelos computacionais
sosticados, porm so altamente especializados e exigem
conhecimento avanado dos usurios.
148
Modelo Grco o modelo que representa o comportamento
de fenmenos por meio de curvas, grcos, facilitando a sua
vericao. H diversos tipos de grcos, como por exemplo os
de linhas, com barras, em forma de pizza, etc. (veja por exemplo
aqueles disponveis no Microsoft Excel), sendo que o traado se
d a partir de um conjunto de valores previamente denidos pelo
usurio.
Para desenvolver um projeto voc precisar, antes
de tudo, criar um modelo de como se dar o
desenvolvimento desse projeto.
Projetos muito pequenos no precisam de um modelo, assim
como a construo da casinha do cachorro no precisa certamente
de uma planta dessa casinha. Se, no entanto, ela tiver algum grau
de complexidade maior, melhor desenhar.
Tendo o modelo em mos voc poder, dessa maneira, utilizar
mtodos de planejamento (que voc ver na prxima seo) e
criar um detalhamento de como se desenvolver o projeto.
Na gura 4.3 voc pode perceber como se d o uxo do
conhecimento durante o desenvolvimento de um projeto
tecnolgico. As diferenas entre os trs tipos de uxos denem
prazos diferentes de entrega, mas podem depender de como se
deu a contratao e quais os riscos aceitveis. A percepo clara
de como se dar o desenvolvimento do projeto permitir uma boa
diviso e detalhamento das atividades.
Tempo
Idias,
Pesquisa
Preparao,
Desenvolvimento
Execuo,
Piloto,
Engenharia
MODELO
SEQUENCIAL
MODELO
SEQUENCIAL
COM
SOLAPAMENTO
MODELO
COM
SOLAPAMENTO
Tempo
Tempo
Figura 4.3 Trs modelos de fuxo de conhecimento no desenvolvimento de projetos
tecnolgicos.
149
Unidade 4
Na etapa inicial das idias, chamada de pesquisa,
so adquiridos os conhecimentos e informaes
necessrias para dar incio ao projeto.
Veja como se d o uxo no modelo seqencial, cujo diagrama
est apresentado na gura 4.4.
No h passagem para a prxima etapa, chamada de
desenvolvimento, sem que todas as atividades da primeira
etapa tenham sido concludas. Na etapa do desenvolvimento
ocorrem as primeiras implementaes do projeto como, por
exemplo, a escrita das primeiras verses de um software, a criao
do prottipo, os testes iniciais, as simulaes, etc.
No modelo seqencial a passagem para a etapa de
engenharia s ocorrer quando a etapa anterior
estiver concluda. Na engenharia se dar a
implantao do projeto, a criao de um piloto e sua
colocao efetiva no mercado como, por exemplo,
na nalizao e entrega de um novo produto, o
que inclui o incio do funcionamento e suporte, ou
a colocao em linha de fabricao de uma nova
mquina. No modelo seqencial o conhecimento
adquirido em cada etapa no inuencia a etapa anterior, e novas
decises so tomadas apenas com os conhecimentos j obtidos.
Esse modelo de desenvolvimento de projetos conservador, e
toma maior tempo de realizao total, pois nenhuma atividade
segue seu andamento se a atividade anterior no tiver sido
totalmente concluda.
A construo civil, por exemplo, usa esse modelo
seqencial como padro e isso faz sentido, pois o
tipo de projeto pressupe fases bem divididas e com
requisitos de precedncia.
Precedncia: em projetos
as atividades podem ter
relaes de dependncia
com outras atividades
anteriores, as quais so
pr-requisitos para o seu
incio.
150
Conhecimentos obtidos na etapa.
Problemas a serem resolvidos na etapa.
MODELO SEQUENCIAL
Desenvolvimento
Pesquisa
Engenharia
Figura 4.4 Modelo seqencial de desenvolvimento de projeto, conforme Senz (2001).
Se, no entanto, as etapas sofrerem um certo grau de mesclagem,
de tal forma que a etapa seguinte tenha incio enquanto a etapa
anterior ainda est na fase de encerramento, chamamos tal
modelo de seqencial com solapamento.
Esse no ainda um modelo radical de desenvolvimento de
projetos, pois a ordem das etapas est bem denida, mas o fato de
uma etapa j ter incio enquanto a outra ainda se desenrola, faz
com que conhecimentos e problemas da etapa seguinte interram
positivamente na etapa anterior, obrigando revises dinmicas do
processo.
Como voc pode ver no desenho da gura 4.5, os conhecimentos
adquiridos em uma etapa podem interferir na soluo de
problemas ainda da etapa anterior. Com isso h ganho de
tempo no projeto, pois algumas decises tomadas faro com
que determinado problema ou risco futuro sejam controlados ou
mesmo eliminados.
Projetos de equipamentos ou softwares so exemplos
para esse tipo de modelagem.
151
Unidade 4
Desenvolvimento
Pesquisa
Engenharia
Modelo Sequencial com Solapamento
Figura 4.5 Diagrama de modelo seqencial com solapamento, inspirado em Senz (2001).
A situao radical de desenvolvimento de projetos aquela onde
as diferentes etapas esto totalmente entremeadas. Certamente
esse o caso onde possvel obter o resultado do projeto no
menor prazo possvel, mas isso exige um enorme controle e
gesto detalhada. O que no simples!
O diagrama da gura 4.6 mostra essa situao, chamada de
modelo com solapamento, e percebe-se que os conhecimentos
e problemas de uma etapa interferem nas solues de todas as
outras etapas, sejam anteriores ou posteriores.
Controlar tais interferncias, para que sejam proveitosas
para o projeto, passa a ser um dos grandes problemas desse
modelo. Problemas relativos montagem e engenheirizao
de determinado produto podem gerar conhecimentos que
tero grande valor l na etapa das idias iniciais, pois com tais
conhecimentos seria possvel j imaginar solues que vo alterar
o formato nal do produto.
152
O uxo de tais informaes precisa ento ser contnuo, e esse
tipo de modelo pressupe nfase nos ambientes de comunicao e
integrao de equipes, assunto que ser discutido nas unidades 5
e 6.
Desenvolvimento
Pesquisa
Engenharia
Modelo com Solapamento
Figura 4.6 Soluo radical: modelo com solapamento (inspirado em Senz, 2001).
Nesta seo voc conheceu a modelagem do uxo das atividades
de um projeto, e como podem ser os diversos modelos de
representao, sejam do uxo ou mesmo do projeto como um
todo. A modelagem permite uma viso estratgica do projeto.
A partir dessa viso estratgica possvel dar incio sua
operacionalizao e, para isso, voc pode contar com mtodos e
ferramentas, assunto da prxima seo.
153
Unidade 4
SEO 2 Metodologias de planejamento Grco de Gantt
Caso seja importante representar todo o projeto por um modelo
estratgico, geral, para fazermos o seu planejamento necessrio
descer nos detalhes, ou seja, decompor todo o trabalho em suas
menores partes.
Essa decomposio signica dividir em tarefas cada vez menores
as diversas atividades do projeto.
H duas maneiras de se decompor um projeto: na forma de um
organograma ou rvore de decomposio ou na forma de tabelas
(VALERIANO, 1998). Tanto a rvore quanto a tabela trazem as mesmas
informaes, sendo que a diferena est na forma de apresentao.
Veja as guras 4.7 e 4.8 a seguir. Ambas nos mostram uma
diviso de tarefas do projeto ctcio denominado Exemplo.
Na gura 4.7 voc pode ver a tabela com o rascunho da diviso
de etapas e com as diversas tarefas que sero necessrias para
compor cada uma delas.
Essa tabela permite que se anotem as diversas tarefas, e tal
ferramenta, muito simples, permite que se escrevam todas as
tarefas componentes.
Projeto EXEMPLO
Etapa 1
Denies
Compra materiais
Organiza equipe
Documentao
.....
Etapa 2
Desenho
Montagem
Documentao
.....
Etapa 3
Teste 1
Teste 2
Documentao
Encerramento
.....
Figura 4.7 Tabela com diviso de tarefas de um projeto Exemplo.
154
A rvore da gura 4.8 representa as mesmas tarefas e etapas,
porm numa representao espacial, o que para algumas pessoas
facilita a compreenso dos diversos componentes. uma questo
de escolha.
Projeto EXEMPLO
Etapa 2
Montagem Documentao Desenho
Etapa 3
Etapa 1
Definies Compra Org. Equipe
Teste 1 Documentao Teste 2 Teste 1
Documentao
Figura 4.8 O mesmo projeto da fgura 4.7 em uma diviso por rvore de decomposio.
Com esse tipo de diviso de tarefas voc pode imaginar e
localizar todos os componentes do projeto. A partir dessa diviso,
voc poder iniciar a construo do planejamento para execuo e
gesto do projeto.
Agora voc vai estudar trs mtodos para planejar o
desenvolvimento do projeto:
Grco de Gantt;
Diagramas PERT e
Mtodo do Caminho Crtico CPM.
So mtodos que vm sendo desenvolvidos nos ltimos cem
anos, especialmente aps a Segunda Guerra Mundial, tendo tido
grande nfase nos anos recentes com os projetos que envolvem
desenvolvimento de software e sistemas de alta tecnologia.

155
Unidade 4
Grco de Gantt
O grfco de Gantt tambm chamado de grfco
de barras. Foi concebido pelo engenheiro norte-
americano Henry L. Gantt (1861-1919) (Hinojosa,
2003) para tentar resolver o problema da
programao de diferentes atividades industriais.
Essas atividades foram distribudas no calendrio de
maneira que o conjunto de atividades pudesse ser
visualizado, com a facilidade de se perceber, pelo
tamanho de uma determinada barra, qual seria a
durao da atividade que tal barra representaria.
Ou seja, o incio da barra marcaria a data de comeo da atividade
e o nal da barra seu trmino, sendo que a barra se estende por
todo o perodo compreendido entre as duas datas.
A gura 4.9 mostra um exemplo de Grco de Gantt desenhado
em planilha (neste caso com o auxlio do MS Excel). Voc
pode ver que o projeto se estende do dia 14/maro at 15/abril,
e constitudo de quatro etapas, havendo dois projetistas neste
trabalho. As barras pretas mostram os prazos previstos para a
execuo de cada Etapa/Tarefa.
Figura 4.9 Exemplo de Grfco de Gantt.
Este tipo de grco permite desenhar uma barra com a durao
prevista, e junto a ela outra barra que vai sendo preenchida
conforme as tarefas vo sendo cumpridas, de tal forma que
possvel acompanhar o andamento do projeto e a proporo de
atraso ou quanto se est adiantado em relao ao previsto.
156
Na gura 4.9 voc pode ver a barra cinza da Etapa 1 mostrando
o andamento do projeto at aquele momento. Se o grco estiver
nessa posio no dia 21 de maro, ento voc pode perceber que o
projeto est cumprindo seu prazo.
Nesse exemplo, no eixo horizontal h um calendrio com a
escala de tempo pertinente e mais adequada ao projeto (dias,
semanas, meses etc). E, no eixo vertical as atividades que sero
executadas, sendo que a barra de durao da atividade pintada
no eixo horizontal ocupando o prazo previsto.
O formato da barra, sua cor, grossura da linha, etc., depende
apenas de quem a est construindo e da facilidade de visualizao
que se requer. Projetos com equipes muito grandes costumam
imprimir tais grcos em painis grandes, para que num nico
relance voc possa ver as etapas, como vai indo o dia-a-dia do
projeto, os principais responsveis, datas de incio e m etc.
O grco que Henry Gantt criou tornou-se imensamente
popular e passou a ser utilizado, sem grandes modicaes,
no gerenciamento de todos os tipos de projetos em todo o
mundo.
Uma das desvantagens apontadas era que o grco no
interligava uma atividade outra, ou seja, no deixava clara
a interdependncia entre as diferentes atividades.
Verses recentes desse tipo de grco passaram, assim,
a utilizar setas de ligao entre as diferentes barras, para
mostrar esse tipo de dependncia, especialmente a partir do uso
de softwares como o MS Project.
Porm, no necessrio um software para se construir o Grco
de Gantt, e justamente por isso to popular e essa uma das
suas grandes vantagens: o traado simples e direto.
Com isso passa a ser muito til nas etapas iniciais de
planejamento (HINOJOSA, 2003), mas quando o projeto passa
a se desenvolver e modicaes no planejamento acontecem, o
grco comea a se tornar confuso. A replanicao exige que se
faa um novo grco.
157
Unidade 4
Tambm outra desvantagem o fato de que o
grfco de Gantt no apresenta custos das etapas, e
difcilmente se adapta a projetos muito complexos
com mltiplas tarefas simultneas. Nesses casos se
usam outros mtodos, como PERT e CPM, que sero
apresentados adiante.
- Para que voc compreenda melhor, observe o exemplo a seguir:
Voc agora vai conhecer um exemplo simples para aplicao do
Grco de Gantt. Voc ir construir uma rea de lazer com 30
metros quadrados, churrasqueira, pia e banheiro (e no nal da
disciplina a gente faz uma festa para comemorar, o que acham?).
Este no um exemplo de projeto de software, mas
sucientemente comum para que voc explore todas as questes
relacionadas ao gerenciamento de um projeto que envolve equipe.
A idia partiu do cliente, que pretende fazer uma comemorao,
e deu a voc o prazo de oito semanas para entregar a obra pronta,
sendo que todos os materiais para a obra so fornecidos por ele.
Tudo comea pela decomposio do projeto em tarefas e, para
isso, voc deve utilizar a decomposio em tabela, como aquela
mostrada no exemplo da gura 4.7.
Que tal dar o nome a este novo projeto de Churrasqueira?
Cada gestor de projeto poderia dividir as tarefas de forma
diferente, pois no h uma regra especca para isso, a no ser o
conhecimento e a experincia particular de cada um.
Proponho ento a seguinte diviso:
158
Projeto CHURRASQUEIRA
Etapa 1 Preparao do terreno
Limpeza do terreno
Medies e marcaes
Escavaes
Etapa 2 Fundaes
Montagem das madeiras de caixaria
Montagem das ferragens da fundao
Concretagem
Etapa 3 Alvenaria
Construo das paredes
Montagem da churrasqueira
Rebocos
Etapa 4 Telhado
Montagem da estrutura de madeira
Colocao de Telhas
Etapa 5 Piso
Concretagem do piso
Assentamento da Cermica do piso
Etapa 6 Carpintaria
Colocao de janelas
Colocao de portas
Etapa 7 Instalao Hidrulica
Tubulaes de gua
Colocao da caixa dgua
Montagem de torneiras, descargas, acessrios
Esgoto
Etapa 8 Instalao Eltrica
Instalao das Tubulaes
Passagem dos cabos alimentadores
Montagem das tomadas, luminrias e quadros
Etapa 9 Pinturas e acabamento
Pintura externa
Pintura interna
Limpeza nal e entrega da obra
Figura 4.10 Tabela com diviso de tarefas do projeto Churrasqueira.
159
Unidade 4
Ao analisar a diviso acima, voc ir perceber que o projeto
no to simples quanto podia parecer primeira vista, pois h
inmeras tarefas, as quais ainda poderiam ser mais detalhadas.
Por ser um exemplo, suciente o que est denido acima.
Considerando essas nove etapas, voc pode construir um grco
de Gantt simples e til para este projeto.
Voc pode comear com uma planilha dividida em nove barras
horizontais, onde voc deve anotar as etapas, e oito colunas onde
voc deve anotar as semanas, como o da gura 4.11 a seguir.
Neste desenho inclu algumas divises para facilitar o
trabalho, tais como a diviso das colunas das semanas nos
seus sete dias, com marcao do sbado (S) e do domingo
(D), e nas barras horizontais h uma diviso que marca o
prazo previsto (Prev) e outra diviso para depois se anotar
o realizado (Real), conforme o projeto for andando.
Alm disso, no espao reservado para escrever o nome das etapas,
h tambm um questionamento sobre quem ir realizar aquela
tarefa, ou seja, quem o responsvel por aquela tarefa especca.
Isso muito til para poder distribuir as responsabilidades, e da
mesma forma til para aquele que vai trabalhar nela, pois pode
compreender sua funo no conjunto das atividades bem como o
impacto de seu prazo sobre o restante.
Figura 4.11 Planilha para Grfco de Gantt do projeto Churrasqueira.
160
O prazo de dois meses parece ser bastante enxuto, ento preciso
ser cuidadoso na distribuio dos prazos para que se tenha
sucesso. Veja que neste projeto o sucesso signica acabar antes
do dia da comemorao, no sendo admitida outra possibilidade.
A equipe que trabalhar neste projeto ser constituda, alm
do gestor (voc), tambm de um mestre de obras, um pedreiro,
um servente, um carpinteiro, um eletricista, um encanador e
um pintor. So oito pessoas, sendo que alguns estaro presentes
apenas em algumas etapas da obra. Fazendo uma reunio
preliminar com todos os membros da equipe, so estimados os
seguintes prazos de execuo para cada etapa:
Projeto CHURRASQUEIRA Prazos estimados pela equipe Dependncia
Etapa 1 Preparao do terreno 2 dias
Etapa 2 Fundaes e Estrutura 1 semana Etapa 1
Etapa 3 Alvenaria 4 semanas Etapa 2
Etapa 4 Telhado 1 semana Etapa 2
Etapa 5 Piso 2 semanas Etapa 4
Etapa 6 Carpintaria 1 semana
Etapa 7 Instalao Hidrulica 1 semana Etapa 4
Etapa 8 Instalao Eltrica 1 semana Etapa 4
Etapa 9 Pinturas e acabamento 2 semanas Etapas 2 e 4
Figura 4.12 Estimando prazos para as etapas do projeto Churrasqueira.
Se voc somar essa estimativa de prazos, voc e sua equipe
chegaro a 13 semanas e 3 dias, o que supera a data nal
denida. Porm, algumas atividades podem ser feitas em
paralelo, e nesse sentido que voc pode traar o primeiro esboo
de grco de Gantt, que est apresentado na gura 4.13.
161
Unidade 4
Figura 4.13 Grfco de Gantt do projeto Churrasqueira primeiro esboo.
Algo que voc pode notar neste grco que, para adequar o
projeto ao prazo total, necessrio colocar algumas atividades em
paralelo, e isso muito natural. O servio do telhado comeou
mais ou menos no meio das atividades de alvenaria, e o piso est
dividido em duas fases, sendo que a segunda fase aparece apenas
aps o encerramento de todo o trabalho da alvenaria. Da mesma
forma as instalaes hidrulicas e eltricas esto divididas em
duas etapas.
Este projeto simples, ento no difcil perceber
essas possibilidades de trabalho em paralelo para
otimizar o tempo e a equipe. Porm, se algum
que no conhece o projeto der uma olhada neste
grfco, no entender porque h uma interrupo na
instalao hidrulica em determinado ponto, e nem
porque ela comea na quinta semana e no apenas na
stima, por exemplo.
Uma diviso mais detalhada facilitaria essa viso externa, e
certamente tambm facilitaria a prpria gesto do projeto.
Uma nova opo de grco de Gantt deste mesmo projeto est
apresentada na gura 4.14.
162
Figura 4.13.2 Grfco de Gantt do projeto Churrasqueira (assumimos a sequncia de atividades defnidas pelo
mestre de obras).
Este grco detalha melhor algumas fases, que permite que se
veja a dependncia entre um servio e outro. A dependncia no
est explcita no grco, porm algum com mais experincia
perceber que o servio de telhados depende da nalizao
da construo das paredes, e aps o telhado car pronto sero
colocadas as tubulaes eltricas e hidrulicas. A concretagem do
piso poder ser feita tambm aps a concluso do telhado, e voc
comear a pintura externa aps a colocao das janelas e portas.
Depois da concluso do piso, sero feitos os acabamentos das
instalaes eltricas, passando todos os cabos e instalando
tomadas e luminrias, bem como instalando acessrios da parte
hidrulica. Por m, ser feita a pintura externa e limpeza geral da
obra, e anal haver uma festa no domingo!
Bem, este exemplo obviamente uma suposio de servio, mas
ele espelha exatamente o que ocorre em todos os projetos.
comum que se tenham muitas dvidas quando o servio est por
comear e, assim, necessrio fazer alguns desenhos iniciais e
avaliar se ser til a diviso que voc pensou inicialmente. Caso
no seja, ou caso voc perceba que possvel detalhar um pouco
mais, ento importante faz-lo.
163
Unidade 4
No grco anterior foi tambm preenchido o nome da pessoa da
equipe responsvel por cada etapa. Desta forma possvel denir
as atividades de cada um, e assim o trabalho individual ser
otimizado.
O eletricista, por exemplo, poder participar de vrios
outros projetos, bastando para isso preparar sua
agenda conforme a distribuio de tarefas em cada
projeto.
Para relembrar alguns tpicos estudados nas unidades e
sees anteriores, analise um pouco mais esse exemplo da
churrasqueira.
Do ponto de vista do modelo geral do projeto, pode-
se dizer que foi considerado o modelo seqencial
de trabalho, ou teria sido o modelo seqencial com
solapamento?
Se voc voltar gura 4.4 perceber que no modelo seqencial
existe a passagem de uma etapa do trabalho para outra sem
alternativa de retorno. J na gura 4.5 se percebe que as
atividades de uma etapa podem interferir numa etapa anterior,
de tal forma que as duas ocorrem em paralelo (pelo menos em
parte), sendo que o que acontece em uma atividade faz com que
algumas coisas possam ser aprendidas e interram na
maneira de se realizar algo na outra atividade.
Este o caso das atividades de instalao hidrulica e
eltrica, que acontecem quando ainda se est realizando
a alvenaria. Certamente algumas solues pensadas em
quaisquer dessas atividades podem interferir positivamente
nas demais, como por exemplo:
combinar passagem de tubulaes pelos mesmos
caminhos, evitando desperdcios;
nvel de caimento para as guas;
existncia de espaos de reserva (como cantos e
reentrncias na parede);
e muitos outros.

164
Por essa anlise, conclui-se que o modelo de desenvolvimento do
projeto o seqencial com solapamento, que j tradicional na
construo civil.
E quanto aos prazos, houve uma estimativa de prazos?
Houve uma estimativa de recursos? Estimativa de
custos e de benefcios?
Essas questes foram debatidas na unidade anterior, onde frisei
a necessidade de se fazer tais levantamentos e anlises para
permitir, s ento, o desenvolvimento do projeto.
Considere esse projeto como bastante simples, que partiu de uma
contratao onde o cliente j deniu algumas dessas questes.
Veja:
Prazo o ponto de partida do projeto foi justamente
um resultado desejado num determinado prazo: a
comemorao com churrasco. Essa data deniu o prazo
limite, para o qual tivemos de nos adequar.
Benefcios se prestarmos ateno na resposta anterior
j se percebe claramente o benefcio: a churrasqueira
do cliente, onde ele poder realizar suas festas; nesse
caso no h um produto a ser lanado no mercado, onde
o valor ser medido pelo retorno nanceiro, mas sim
haver valor pelo retorno em qualidade de vida.
Recursos no tivemos problemas com recursos
materiais, pois o contratante previu o seu fornecimento;
precisamos ento nos preocupar com a equipe (nossos
recursos humanos).
Custos com base na quantidade de trabalho envolvida,
no nmero de horas e nas especialidades de pessoal,
um oramento foi entregue ao cliente, que neste caso
aceitou tais custos e teve de fazer os aportes nanceiros
semanalmente ( a prtica na construo civil).
E quanto aos riscos? Voc consegue prev-los?

165
Unidade 4
Como voc pode ver na gura 4.13, o prazo estimado em cada
atividade faz com que voc tenha pouca folga no projeto, caso
algum problema acontea. E eles podem acontecer!
Considere que ocorra um perodo de chuvas justamente durante
as trs primeiras atividades: preparao do terreno, fundaes e
alvenaria. Certamente haver atrasos nessas etapas, e isso poder
afetar todo o projeto, pois como tais atividades esto encadeadas
e delas dependem todas as restantes, dizemos que tais atividades
perfazem um caminho crtico.
O mtodo do caminho crtico ser discutido mais adiante. O
gestor do projeto ter que pensar em alternativas. Outros riscos
so a falta de pessoal por motivos alheios (doenas, mudanas),
problemas nanceiros do contratante, falta de algum material no
mercado etc.
Para todos eles devemos pensar em alternativas, pois
o sucesso desse projeto est vinculado a uma coisa:
cumprir o prazo para a festa.
Volte agora ao grco da gura 4.13 para analisar outra
caracterstica desse tipo de diagrama. Apesar de voc j saber
que uma atividade deve comear apenas quando a outra terminar
(como por exemplo o telhado somente aps as paredes e estrutura
estarem montadas, nesse caso), isso no est evidente no desenho.
A pessoa que no conhece o projeto no perceber esse tipo de
dependncia. Foi preciso avanar na construo desse tipo de
diagramas e introduzir relaes de dependncia, o que se d em
todos os modernos softwares de gerao de grcos de Gantt.
Voc pode criar dependncias de quatro tipos entre atividades:
Dependncia m-incio, quando o incio de uma
Atividade B s possvel aps o m da Atividade A.
Dependncia m-m, quando o nal da Atividade B deve,
necessariamente, coincidir com o m da Atividade A.
Dependncia incio-incio, quando o incio da Atividade
B deve, necessariamente, coincidir com o incio da
Atividade A.

166
Dependncia m-incio com folga, quando o incio de
uma Atividade B s possvel aps o m da Atividade
A, porm h um tempo de folga para o incio da
Atividade B.
A representao grca dessas relaes de dependncias feita
com setas interligando as extremidades das atividades, como voc
pode ver nas guras seguintes:
Atividade A
Atividade B
Figura 4.14 Dependncia Fim-Incio num Grfco de Gantt, onde B depende de A.
Atividade A
Atividade B
Figura 4.15 Dependncia Fim-Fim num Grfco de Gantt, onde B depende de A.
Atividade A
Atividade B
Figura 4.16 Dependncia Incio-Incio num Grfco de Gantt, onde B depende de A.
Atividade A
Atividade B
FOLGA
Figura 4.17 Dependncia Fim-Incio com folga num Grfco de Gantt, onde B depende de A.


167
Unidade 4
A introduo das setas que mostram dependncias foi um
grande avano na visualizao do planejamento, antes apenas
possvel pela distribuio das barras num grco com escala de
tempo. Essa introduo permitiu perceber que as setas poderiam
indicar algo mais no grco, e da em diante um novo conjunto
de grcos e diagramas foi desenvolvido e chegaremos, ento, ao
Mtodo do Caminho Crtico (CPM) e diagramas PERT. Mas
isso ser assunto para a prxima seo.
Antes, para encerrar esta seo, veja duas ilustraes com
exemplos de softwares que usam Grco de Gantt com setas de
dependncia.
Na gura 4.18 voc pode ver uma tela gerada pelo jxProject de
um projeto exemplo. Na gura 4.19 h outro projeto, onde a tela
foi gerada pelo Microsoft O ce Project.
Figura 4.18 Exemplo de Grfco de Gantt, software jxProject.
168
Figura 4.19 Exemplo de Grfco de Gantt, software Microsoft Of ce Project.
SEO 3 Metodologias de planejamento PERT/CPM
Aps a Segunda Guerra Mundial surgiu um projeto do governo
norte-americano que acabou gerando uma profunda inuncia
na disciplina de gesto de projetos. Era o projeto Polaris, da
Marinha, para produzir uma srie de submarinos nucleares em
cinco anos.
Esse projeto iria envolver mais de 9000 empreiteiros diferentes
e devia ter o de acordo do Congresso, o que teve um enorme
impacto tal o clima de desconana que o projeto gerou, pois
se sabia que os prazos e custos de projetos militares eram
constantemente estourados (PRADO, 1998). Para inverter esse
quadro de desconana e ter o projeto aprovado, foi criada uma
equipe especialmente para planejar e scalizar o andamento
do projeto e a construo dos submarinos. Essa equipe foi
denominada Program Evaluation and Review Task Force, gerando
a sigla PERT, que posteriormente viria a denominar a tcnica de
169
Unidade 4
representao do planejamento do projeto por eles desenvolvida
Program Evaluation and Review Technique - PERT.
O projeto Polaris surpreendeu e foi desenvolvido em
apenas trs anos, o que atraiu grande ateno para a
equipe e para a tcnica que eles desenvolveram para
a gesto de projetos.
Na dcada de 60 muitas melhorias foram incrementadas
tcnica, incluindo o Critical Path Method CPM (Mtodo
do Caminho Crtico), e todas as tcnicas de representao de
projetos por redes de atividades e dependncias acabaram sendo
reunidas atualmente no que se denomina PERT/CPM.
A idia dessas tcnicas era criar um diagrama que vericasse
os pr-requisitos de cada atividade, de tal forma que se pudesse
compreender qual seria o conjunto de atividades, com seus prazos
e em seqncia cronolgica, de tal maneira que fosse possvel
traar o caminho crtico do projeto, ou seja, a seqncia de
atividades que determinariam o menor tempo possvel do projeto.
Dentre as vrias aplicaes das tcnicas PERT/CPM pode-se citar:
denir as atividades de um projeto;
determinar a durao de cada atividade;
com base nos prazos de cada atividade, buscar o
prazo mnimo para o projeto total;
encontrar as ligaes temporais entre as diversas
atividades, ou seja, vericar os tempos de folga
entre atividades seqenciadas;
identicar quais atividades so crticas no projeto, ou
seja, aquelas cujo prazo determina o andamento de todo
o projeto, e que se ocorrer um problema qualquer de
atraso, todo o projeto sofrer retardo;
determinar qual a seqncia crtica do projeto
considerando as atividades crticas, ou seja, determinar a
seqncia de atividades crticas que perfazem o caminho
crtico do projeto;

170
vericar os tempos de folga que existem entre as
atividades, de tal modo que se possa trabalhar com esses
prazos durante a execuo do projeto sem afetar o prazo
total.
Diferente do Grco de Gantt, onde cada atividade ocupa uma
barra do painel, nessas tcnicas de reviso e do caminho crtico
so usadas setas para compor o diagrama, como no desenho
da gura abaixo (gura 4.20), onde cada seta representa uma
determinada atividade (atividade A, atividade B....) e os crculos
representam um evento ou n, que a concluso de uma ou mais
atividades.
Como voc pode ver no diagrama, a durao de cada
atividade no est representada pelo comprimento
da seta, pois os comprimentos dessas no tm escala.
O que mais importa aqui verifcar qual atividade
depende de outra, sua precedente.
No caso do exemplo da gura 4.20, voc pode ver que a atividade
B s ocorre depois de A, e D ocorre depois de B. No entanto,
para que a atividade H possa acontecer, necessariamente
precisaremos ter concludas as atividades C e D. Ou seja,
o diagrama de setas dene uma lgica para a seqncia de
execuo.
Figura 4.20 Diagrama de setas simples com ns, que denotam a concluso de atividades.

171
Unidade 4
As diferenas entre os mtodos como o Grfco de
Gantt e as tcnicas PERT/CPM acontecem devido ao
tipo de representao e de escala utilizada.
No Grco de Gantt h uma escala de tempo bem denida, mas
a representao das precedncias, da vinculao entre diferentes
atividades e do caminho crtico no so evidentes.
Para dar incio ao estudo das tcnicas PERT/CPM, faa
primeiramente uma comparao grca entre os diferentes
mtodos, e ento evolua a partir desse ponto.
Na gura 4.21 h duas representaes para o projeto
Churrasqueira, que j foi tratado na seo anterior. Na parte
superior da gura voc pode ver o Grco de Gantt, exatamente
o mesmo que foi apresentado na gura 4.13 (para maior clareza
do desenho, retirei as linhas que representam prazo realizado).
Na parte inferior da gura est uma representao por diagrama
de setas do mesmo projeto, onde as letras denominam as
atividades, conforme a seguinte tabela de correspondncia:
A preparao do terreno
B fundaes
C alvenaria - paredes
D alvenaria - reboco e cermicas
E telhado
F piso
G carpintaria
H tubulao hidrulica
I instalao hidrulica
J tubulao eltrica
K instalao eltrica
L pintura externa
M pintura interna e acabamento
172
Figura 4.21 Diagrama de setas com escala e acima o Grfco de Gantt do projeto Churrasqueira.
O diagrama de setas do projeto Churrasqueira da gura 4.21
est construdo dentro da escala de tempo denida no grco de
barras que est acima dele, como voc pode ver.
Perceba que cada n est colocado exatamente na coluna que
representa o incio ou nal de uma determinada atividade.
Repare, por exemplo, na atividade E Telhado: o n onde
comea a seta est no incio do dia 7 de abril, e o n no nal da
seta est no dia 13. A seta E, ento, compreende 7 dias.
Mesmo para um projeto simples como este o
desenho com setas acaba se tornando razoavelmente
complexo e, de fato, no mostra muitas coisas. Da
forma como est apresentado parece um modelo
diagramtico ruim, e o Grfco de Gantt estava bem
melhor, no ?
Acontece que a riqueza desse tipo de diagrama no est em
representar na escala temporal o desenvolvimento do projeto,
mas sim nos mostrar os seus pontos crticos de atraso. Vamos
ento fazer duas modicaes no diagrama de setas do projeto
Churrasqueira:
173
Unidade 4
Redesenhe o diagrama para que que mais claro,
retirando a escala de tempo.
Para no perder a referncia das atividades quanto ao seu
prazo estimado, coloque sob cada seta o nmero de dias
de sua durao.
Com essas duas modicaes simples voc ter o diagrama da
gura 4.22 (Apesar de atividades diferentes, reunimos A,B e C
em apenas um arco para simplicar o diagrama).
Figura 4.22 Diagrama de setas modifcado do projeto Churrasqueira.
Bem, apesar de ser um desenho limpo, ainda no
sucientemente claro para ajudar no planejamento do projeto.
o momento, agora, de denir alguns conceitos e smbolos
para construir os diagramas PERT/CPM. Com tais smbolos,
apresentados no quadro da gura abaixo, voc poder fazer a
construo nal do diagrama do projeto Churrasqueira e partir
para sua anlise como ferramenta de apoio na gesto de projetos.

174
Figura 4.23 Quadro com simbologia e nomenclatura utilizados em diagamas PERT/CPM.
Como se v na gura 4.23, alguns novos conceitos esto
apresentados, tais como data mais cedo e mais tarde, folgas e
smbolos com informaes.
A data mais cedo (dc) representa a primeira data onde pode
ocorrer o evento.
J a data mais tarde (dt) a ltima data em que esse evento
pode ocorrer, sem afetar o prazo do projeto. Essa data mais
tarde existe quando h uma folga no projeto, e a folga especca
da atividade chamada de folga.
175
Unidade 4
A sequncia de atividades que dene o prazo crtico do projeto,
ou seja, aquela seqncia onde alteraes implicam uma alterao
do prazo total do projeto, chamada de caminho crtico.
Volte agora ao diagrama da gura 4.22. possvel, ainda,
simplicar um pouco mais o desenho. Veja que o n ao nal da
atividade D, o n que d origem atividade L e o n ao nal da
atividade G podem ser reunidos em um s, sem alterar a ordem
das atividades. Assim, o diagrama passaria a ser:
Figura 4.24 Diagrama PERT/CPM do projeto Churrasqueira, simplifcao 1.
Voc sabia que este diagrama pode ser simplicado mais uma
vez? Veja a seguir como isto pode acontecer:
A seta fantasma que une os ns do nal da atividade E e do
incio da atividade G pode ser suprimida, juntando ento
esses dois ns. Com um pequeno rearranjo das setas e dos ns
voc teria, dessa forma, o desenho simplicado do diagrama,
conforme apresentado na gura 4.25.
Repare como o diagrama cou mais simples e objetivo, e como
foi alterado desde o original, que desenhamos na gura 4.21.
importante reparar que todo esse processo de construo foi
realizado aqui para demonstrar a construo do diagrama PERT/
CPM, mas na prtica voc pode desenh-lo diretamente, apenas
sabendo as atividades, suas precedncias e respectivas duraes.
Voc ver isso num exerccio futuro.
176
Figura 4.25 Diagrama PERT/CPM do projeto Churrasqueira, simplifcao 2.
Tendo agora o diagrama desenhado, voc ir introduzir os smbolos
que permitem colocar as informaes detalhadas do plano.
Em primeiro lugar coloque os ns e para cada um d um nome,
neste caso uma dezena para cada n de forma que, se voc
precisar posteriormente inserir algum novo n, voc possa usar a
numerao intermediria (ver gura 4.26).
Como voc pode reparar, todas as datas de incio, mais cedo e
mais tarde, esto em branco. Opte pela data mais cedo para o n
10 como sendo 1, ou seja, o primeiro dia da atividade A, e a
partir da conte as datas em dias (poderamos tambm comear
com 0 e isso no faz diferena, pois os totais sero os mesmos).
Figura 4.26 Diagrama projeto Churrasqueira, detalhamento 1.
177
Unidade 4
Tendo a primeira data mais cedo denida, voc pode ir
preenchendo as dc dos outros ns. A dc do n 20 ser a dc do n
10 mais a durao da atividade ABC, ou seja,
dc
20
= dc
10
+ durao
ABC
Com isso o diagrama passa a ser detalhado e temos a gura 4.27
com o n 20 preenchido.
Considerando a data mais cedo do n 20 (onde dc
20
= 25) voc
pode preencher as datas dc dos ns 30 e 40, conforme gura 4.28.
178
Denido o n 30 (cujo dc
30
= 32) voc pode preencher os ns 50 e
60. Repare que o n 60 ser preenchido com a soma da dc do n
30 e a durao da atividade F, que mais longa que a atividade
HJ. Assim voc ter:
Incidem sobre o n 70 duas atividades com duraes diferentes:
L e IK. Se voc considerar a atividade L, ter dc
70
igual a 43, mas
se consider a atividade IK, teramos dc
70
igual a 48, que uma
data mais tarde do que a denida a partir do caminho L. Nesse
caso, obrigatoriamente, deve-se assumir essa segunda data, que
o dia 48, dia de incio da atividade nal M. Com isso o diagrama
ca assim preenchido:
179
Unidade 4
O n 80 representa o evento de encerramento do projeto e
ter tambm uma marcao de data mais cedo, que nesse caso
representa o dia da entrega do projeto. Por ser esse o dia nal,
ento a data mais tarde coincide com a data mais cedo, ou
seja,
dc
80
= dt
80
= dia da entrega do projeto.
Denida a data nal do projeto, voc ter ento preenchido
completamente o ltimo n, e poder fazer o caminho inverso
do diagrama preenchendo agora a data mais tarde de incio de
cada atividade. Faa isso e tire as concluses. Inicialmente voc
deve preencher o ltimo n (ver gura 4.30).
Figura 4.30 Diagrama projeto Churrasqueira, detalhamento 5 incio do caminho
inverso de preenchimento.
A data mais tarde do n 70, dt
70
, ser encontrada subtraindo-se a
durao da atividade M, da seguinte forma:
dt
70
= dt
80
durao
M
Com isso voc obter dt
70
= 48, o que coincide com a data mais
cedo desse mesmo n. Veja a gura 4.31, a seguir.
180
Figura 4.31 Diagrama projeto Churrasqueira, detalhamento 6 preenchimento das
datas mais tarde de incio de cada atividade.
Adote o mesmo procedimento para os ns 40 e 60. Para o n
60 perceba que novamente as datas mais cedo e mais tarde
coincidem, porm para o n 40 h uma diferena entre elas. Veja
a gura 4.32.
A diferena entre datas que se v no n 40 a folga livre (FL).
A atividade L pode comear entre os dias 38 e 43 sem afetar o
desenvolvimento geral do projeto. Esse conceito de folga livre
muito importante para o gestor do projeto pois, a partir desse
dado, ele pode escolher, a partir de outras estimativas, como
custos, equipe, riscos etc, a melhor data de incio dentro dessa
margem de folga.
181
Unidade 4
O n 50 est ligado ao 60 por uma atividade fantasma, que no
tem durao. Assim a sua dt
50
ser igual dt
70
, ou seja, 45. E
o n 30, como car? H trs ns na sua seqncia: 40, 50 e 60.
Veja as trs expresses possveis e seus resultados:
dt
30
= dt
60
durao
F
= 45 13 = 32
dt
30
= dt
50
durao
HJ
= 45 2 = 43
dt
30
= dt
40
durao
G
= 43 5 = 38
- Certamente devemos escolher o menor, pois seno afetaramos todos os
prazos do projeto, certo?
Nossa inteno na gesto do projeto desenvolver o trabalho no
menor prazo possvel, cumprindo ou antecipando o prazo nal.
Com isso obtemos o seguinte diagrama:
Para denir o n 20 novamente voc dever fazer uma escolha
entre duas opes: iniciar o clculo a artir de dt
30
ou de dt
40
.
Com dt
30
obtemos para o n 20 a data 25 (dt
20
= 25), que a
menor e que ser ento adotada.
Assim, preenchendo tambm o n 10, voc chegar ao diagrama
PERT/CPM nal do projeto Churrasqueira, apresentado
na gura 4.34. Sem dvida, no um diagrama fcil de ser
entendido primeira vista, e para ser til preciso ter ao lado a
182
tabela de referncia das atividades. Porm, ao analisar o desenho
com maior cuidado, voc ver como poderosa essa ferramenta
para tratar a questo dos prazos gerais do projeto, e como o gestor
pode acompanhar e interferir sobre as diversas etapas visando seu
controle efetivo e constante.
Figura 4.34 Diagrama PERT/CPM fnal do projeto Churrasqueira.
Voc pode vericar que no diagrama o caminho de atividades
onde no h folga dene o caminho crtico das atividades do
projeto. Sobre esse conjunto de atividades o gestor deve prestar
ateno especial e preparar suas estimativas de recursos e custos.
possvel desenhar o diagrama PERT/CPM sem ter
montado o Grfco de Gantt?
Sim, mas importante perceber que os diagramas so diferentes
e complementares para o gestor.
Enquanto no Grco de Gantt possvel ver a escala temporal
claramente, bem como a pessoa responsvel por cada atividade e
tambm acompanhar o andamento do projeto ao longo do tempo
(preenchendo uma barra das tarefas executadas), no diagrama
PERT/CPM possvel determinar a seqncia de atividades com
suas precedncias, e perceber claramente quais atividades podem
afetar todo o andamento do projeto.
Neste sentido importante ter as duas ferramentas como
instrumentos objetivos de apoio ao gestor.
183
Unidade 4
Para criar diretamente um diagrama PERT/CPM, necessrio
partir da tabela de diviso de tarefas, conforme visto no exemplo
da gura 4.7. No entanto, aquela tabela apresenta apenas a
diviso das tarefas, e ser ento necessrio incluir duas colunas:
uma para anotar o tempo estimado de realizao da tarefa, e
outra para anotar quais as tarefas precedentes obrigatrias.
Faa esse exerccio considerando a tabela que voc utilizou no
exemplo do Projeto Churrasqueira. Na gura 4.35 reapresento
a tabela de distribuio de tarefas, mas incluindo os prazos
estimados e as tarefas precedentes. Para cada etapa procurei
desenhar uma seta, com o nome da etapa sobre ela e o prazo
abaixo. A seta deve chegar a um n. A seta correspondente a uma
nova etapa deve partir do n onde se encerrou a etapa precedente.
Setas de atividades-fantasma so desenhadas quando uma
atividade tem mais de uma precedncia, e neste caso diferentes
ns de origem. Ao nal do desenho so feitas as simplicaes.
Seguindo esse roteiro voc chegar ao diagrama da gura 4.34.
ETAPA Projeto CHURRASQUEIRA
Tempo estimado da
etapa (dias)
Precedncia
A Preparao do terreno 2 -
B Fundaes 7 A
C Alvenaria paredes 15 B
D Alvenaria reboco e cermicas 13 C
E Telhado 7 C
F Piso 13 E
G Carpintaria 5 E
H Tubulao Hidrulica 2 C, E
I Instalao Hidrulica 3 H, F
J Tubulao Eltrica 2 C, E
K Instalao Eltrica 3 J, F
L Pintura Externa 5 G
M Pintura Interna e acabamento 7 I, K, L
Figura 4.35 Diviso de tarefas, com prazos e precedncias, do projeto Churrasqueira.
184
Um dos maiores problemas na montagem desse tipo de tabela
ser na denio dos prazos de cada etapa. A estimativa de
tempo deve ser feita, quando possvel, com a ajuda dos membros
da equipe. O tempo estimado algo subjetivo, pois se considera a
experincia de cada um. Nesse sentido, h as previses otimistas,
as pessimistas e as provveis. A bibliograa (Keeling, 2002)
prope denir um tempo provvel com a seguinte frmula para
clculo do Tempo Estimado de uma determinada tarefa:
te

= ( to + 4tm + tp ) / 6
Onde:
te tempo estimado da tarefa;
to tempo otimista, ou seja, durao prevista mais curta;
tm tempo provvel, ou seja, durao mdia prevista;
tp tempo pessimista, ou seja, durao prevista mais
longa.
Ainda assim, h os que consideram o Tempo Estimado nesta
frmula muito otimista, podendo-se ento aplicar a seguinte
alternativa mais conservadora (KEELING, 2002):
te

= ( to + 3tm + 2tp ) / 6
Com isso voc conclui o estudo de ferramentas de apoio para o
planejamento das etapas de um projeto.
Na seo anterior voc viu que para o projeto ser iniciado era
preciso analisar sua viabilidade quanto aos recursos, custos,
prazo e benefcios. Tendo o planejamento realizado e os
prazos estimados, preciso agora estimar os recursos e custos
necessrios ao projeto.

185
Unidade 4
SEO 4 Estimativa de recursos
Tendo um planejamento do projeto, voc pode agora estimar os
recursos necessrios para ele. Bem, estimar no uma cincia exata.
DeMarco (1991) prope algumas denies diferentes, tais como:
Estimativa a previso mais otimista que no tem
uma probabilidade zero de tornar-se realidade.
Ou
Uma estimativa uma previso que tanto pode estar
acima quanto abaixo do resultado real.
Essas denies soam estranhas, mas dizem muito sobre o ato de
estimar: um chute que pode marcar o gol ou apenas passar
mais ou menos perto. Voce deve ter claro que precisa estimar o
melhor possvel para evitar riscos durante o projeto.
Quanto aos recursos necessrios a um projeto, basicamente h os
seguintes:
Materiais so os produtos necessrios
para confeccionar o projeto, tais como
matrias-primas, produtos manufaturados,
componentes, hardware etc.
Equipamentos so as mquinas e
ferramentas necessrias para poder trabalhar
as matrias-primas, escrever o cdigo de um
software, facilitar uma construo, etc.
Pessoal os recursos humanos aparecem como o principal
requisito em projetos, especialmente em projetos de
tecnologia; a prxima unidade discutir este item.
Financeiros so os custos do projeto, que advm dos
gastos relativos a materiais, equipamentos, locaes,
fretes, transportes, pessoal, licenas, direitos autorais, etc
(a estimativa de custos o assunto da prxima seo).

186
Como voc estudou na seo anterior, o planejamento do
projeto tem um foco muito intenso no prazo geral, pois como
projetos so trabalhos com data marcada para acabar, o prazo
determinante.
Para realizar o planejamento foi feita uma diviso de tarefas, e
essa diviso o fator que ir permitir estimar recursos, tarefa por
tarefa. Desta forma deve-se partir da tabela onde as tarefas foram
divididas e incluir colunas especcas para descrever recursos
necessrios.
A tabela apresentada na fgura abaixo um exemplo
de relatrio a ser preenchido no incio do projeto.
Este exemplo partiu de tabela anterior, descrita na
fgura 4.10. Para cada projeto especfco dever ser
construda uma tabela exclusiva, sendo que a coluna
dos recursos defnir uma lista de necessidades.
Projeto CHURRASQUEIRA Recursos necessrios
Etapa 1 Preparao do terreno
Limpeza do terreno Tratores (dois dias)
Medies e marcaes Topgrafo
Escavaes Tratores (um dia)
Etapa 2 Fundaes
Montagem das madeiras de caixaria
XX dzias de madeira para caixaria;
Pessoal para montagem da caixaria;
Montagem das ferragens da fundao XX barras de ferro;
Concretagem XX caminhes de concreto
Etapa 3 Alvenaria
Construo das paredes
XX milheiros de tijolos;
Xx sacos de cimento;
Etc.
........ ...........
Figura 4.36 Diviso de tarefas com estimativa de recursos.
187
Unidade 4
SEO 5 Estimativa de custos
A distribuio de custos do projeto feita num grco chamado
de cronograma fsico-nanceiro.
Este deve aproveitar o grco de barras que voc viu no Grco
de Gantt, sendo que os custos do projeto podem ser distribudos
ao longo do tempo de durao do projeto. Para cada item,
denido nos recursos estimados para o desenvolvimento do
projeto, voc dever fazer uma estimativa de gastos.
O uso do grco de barras interessante, nesse caso, devido
clareza visual de apresentao.
- Veja um exemplo para entender melhor esse tipo de cronograma.
A gura 4.37 apresenta o Grco de Gantt de um projeto
hipottico com sete atividades Tarefas A at G cujos
trabalhos transcorrem em 16 semanas, aproximadamente quatro
meses. Tendo estimados os recursos necessrios para desenvolver
cada tarefa, os custos podem ser distribudos por tarefa e por
unidade de tempo, neste caso por semana. Sobre o prprio
grco os valores so anotados, semanalmente.
Figura 4.37 Estimando custos cronograma fsico-fnanceiro.
Fazendo a estimativa de custos por atividade e por unidade de
tempo possvel chegar a valores mais prximos do real. Quanto
maior a diviso das tarefas, melhor. Anotados todos os valores
voc far a somatria, tambm por unidade de tempo. A cada
semana voc chega a um valor total, conforme vemos na ltima
linha do grco. Com tais valores possvel estimar o valor
188
total de custos do projeto, apresentado no canto inferior direito
da gura. Outra visualizao dos custos desse mesmo projeto
apresentada na gura 4.38, a qual decorre dos valores obtidos na
estimativa do grco de barras.
Figura 4.38 Grfco de linha do cronograma fsico-fnanceiro.
Percebemos pelo grco da gura 4.38 que o projeto dever
dispor de recursos nanceiros bem maiores do que a mdia
nas semanas 6 e 7. Fazendo essa anlise pode-se retornar ao
planejamento do projeto e, caso necessrio, alterar a durao das
tarefas que impactam nesses valores, nesse caso especialmente
a Tarefa C. Se no for possvel alterar, ento o caixa do projeto
dever estar preparado para tal uxo.
189
Unidade 4
Sntese
Nesta unidade foram apresentados modelos e mtodos muito
importantes para o gestor de projetos e de suas equipes. Em
primeiro lugar foi feita uma avaliao de como o uxo de
atividades pode ser distribudo em um projeto, de acordo com
o tipo de projeto e de suas necessidades especcas. Projetos
de tecnologias mais tradicionais, ou com contratos de mbito
conservador, levam a modelos de desenvolvimento com uma
cadncia diferente, por exemplo, daqueles projetos onde o tempo
de chegada ao mercado fator decisivo de sucesso, ou onde as
tecnologias no so dominadas e precisamos fazer revises e
retornos constantes a etapas anteriores.
Depois voc viu as tcnicas de planejamento que foram
desenvolvidas nos ltimos cem anos, que basicamente o
perodo onde a disciplina de gesto de projetos tomou forma.
O grco que apresenta as diversas atividades em forma
de barras ao longo do tempo foi desenvolvido por Gantt e
cou extremamente popular, sendo ainda a base das diversas
ferramentas de planejamento, especialmente os softwares
recentes como o MSProject, o jxProject e diversos outros. A
popularidade do Grco de Gantt deve-se fora de sua clareza
visual para representar o projeto e, recentemente, a implantao
de setas de precedncia interligando as barras, aumentou ainda
mais a sua qualidade como modelo. Esse grco tambm
permite acompanhar as tarefas previstas comparando-as com
as realizadas, por meio de uma barra extra desenhada ao lado
ou diretamente sobre a barra original. Outra utilidade est na
representao dos custos dos projetos discretizados por tarefa e
por unidade de tempo adotada, facilitando em muito a estimativa
de custos gerais do projeto.
190
Apesar de a imensa utilidade do Grco de Gantt, outro
mtodo foi desenvolvido para facilitar o planejamento do
tempo de durao do projeto trata-se do mtodo do caminho
crtico, denominado genericamente de PERT/CPM. Esse
grco permite distinguir num projeto qual a seqncia crtica
de atividades, de tal forma que o gestor pode prestar ateno
especca em tais atividades, e at mesmo alter-las para que o
projeto seja adiantado ou tenha seu prazo corrigido.
Com tais ferramentas de planejamento e anlise pode-se, ento,
chegar a estimativas bastante realistas quanto aos recursos
necessrios ao projeto, e quais seus custos.
Na prxima unidade voc vai conhecer aquele que provavelmente
o ponto crtico dos projetos de desenvolvimento tecnolgico:
recursos humanos e estruturao de equipes.
191
Unidade 4
1) Considere o seguinte problema: ser implantado um novo sistema
de qualidade na EMPRESA, e uma equipe interna foi designada para
montar o projeto de implantao, o qual no deve superar dois meses,
e que deve ser primeiro implantado no setor administrativo e somente
depois no setor de produo da empresa. O projeto tem as seguintes
atividades: reunies do grupo do projeto para defnir o programa;
redao do programa de qualidade; treinamento do pessoal do
setor administrativo; treinamento do pessoal do setor de produo;
implantao do programa de qualidade no setor Administrativo;
implantao do programa no setor de produo; avaliao dos
resultados e concluso, com entrega dos relatrios direo. Faa sua
anlise e, com base nela, preencha o quadro a seguir:
Projeto Qualidade
Prazos estimados pela
equipe de implantao
A -
B -
C -
D -
E -
F -
G -
2) Prepare o Grfco de Gantt para a planilha de atividades do exerccio
anterior Projeto QUALIDADE, e considere ainda que os treinamentos
podem ser feitos em seqncia, independente do incio do trabalho de
implantao no setor de produo.
(quadro na pgina 188)
3) Baseado no Grfco de Gantt que voc criou no Projeto Qualidade,
reproduza-o e faa logo abaixo dele o diagrama de setas com escala.
(quadro na pgina 189)
192
P
r
o
j
e
t
o

Q
u
a
l
i
d
a
d
e
S
D
S
D
S
D
S
D
S
D
S
D
S
D
S
D

ABCDEFG
26 / out
25 / out
24 / out
23 / out
22 / out
21 / out
20 / out
19 / out
18 / out
17 / out
16 / out
15 / out
14 / out
13 / out
12 / out
11 / out
10 / out
09 / out
08 / out
07 / out
06 / out
05 / out
04 / out
03 / out
02 / out
01 / out
30 / set
29 / set
28 / set
27 / set
26 / set
25 / set
24 / set
23 / set
22 / set
21 / set
20 / set
19 / set
18 / set
17 / set
16 / set
15 / set
14 / set
13 / set
12 / set
11 / set
10 / set
09 / set
08 / set
07 / set
06 / set
05 / set
04 / set
03 / set
02 / set
01 / set
193
Unidade 4
S
D
S
D
S
D
S
D
S
D
S
D
S
D
S
D

ABCDEFG
26 / out
25 / out
24 / out
23 / out
22 / out
21 / out
20 / out
19 / out
18 / out
17 / out
16 / out
15 / out
14 / out
13 / out
12 / out
11 / out
10 / out
09 / out
08 / out
07 / out
06 / out
05 / out
04 / out
03 / out
02 / out
01 / out
30 / set
29 / set
28 / set
27 / set
26 / set
25 / set
24 / set
23 / set
22 / set
21 / set
20 / set
19 / set
18 / set
17 / set
16 / set
15 / set
14 / set
13 / set
12 / set
11 / set
10 / set
09 / set
08 / set
07 / set
06 / set
05 / set
04 / set
03 / set
02 / set
01 / set
194
4) Modifque o diagrama de setas do exerccio 3, simplifque-o e crie o
Diagrama PERT/CPM do mesmo, usando a simbologia aplicada nesta
disciplina e reproduzida abaixo.
Desenhe o diagrama passo a passo, calculando para cada n a data
mais cedo e posteriormente a data mais tarde para cada atividade
(use os modelos abaixo para desenhar o diagrama).
195
Unidade 4
196
5) No exerccio anterior, onde h uma Folga Livre (FL)? O que isso signifca
para o gestor do projeto QUALIDADE?
197
Unidade 4
Saiba mais
Na seo 1 desta unidade voc estudou modelos de representao
como forma de entender um projeto, a partir de uma viso geral.
Para o desenvolvimento de software surgiu uma tecnologia que
busca criar modelos de representao, por meio de diagramas,
que muito se assemelham aos diagramas genricos que usamos
aqui. Essa tecnologia chamada UML Unied Modelling
Language, e est baseada na modelagem de diversos tipos
de diagramas, os quais abrangem diferentes vises de um
projeto de software, seja ele simples como o Hello World
/ Al Mundo, que se v em Java, seja de sistemas das mais
variadas complexidades. Os diagramas UML de Caso de
Uso e de Atividades, em especial, se assemelham com o que
foi tratado aqui, e devem participar com ferramentas naturais
no planejamento de projetos de software e de tecnologia em
geral. A UML desenvolvida atualmente por uma organizao
internacional sem ns lucrativos, e toda sua documentao
pode ser encontrada em www.uml.org. Vrios softwares para
desenvolvimento UML esto disponveis hoje para download
gratuito, como por exemplo o POSEIDON (veja em http://
www.gentleware.com/index.php). Veja tambm o stio http://
www.cragsystems.co.uk/ITMUML/index.htm para estudar
uma introduo UML.
Veja em www.gestiopolis.com/recursos/documentos/fulldocs/
ger/pertcpm.htm um artigo bastante completo e com exemplos
variados do uso de PERT/CPM, em espanhol. Casos prticos e
exerccios, bem como exemplos de tabelas e relatrios.
As idias da Microsoft para gesto de projetos de software esto
disponveis no endereo http://www.microsoft.com/technet/
itsolutions/msf/default.mspx. Anlises de risco, estimativas,
grupos de trabalhos e diversos outros conceitos so discutidos no
que eles chamaram Microsoft Solutions Framework MSF.
5
UNIDADE 5
Estruturando a equipe
Compreender aspectos da formao e estruturao de
equipes, conforme cada tipo de projeto discutido nas
unidades anteriores.
Perceber como contornar os problemas de

estruturao de uma equipe.
Reconhecer os diversos modelos de estruturao de

equipes em diferentes organizaes.
Compreender as difculdades que um gestor pode

trazer ao trabalho com projetos quando no se ajusta a
um perfl de liderana criativa.
Compreender que, em projetos, as equipes precisam

trabalhar com objetivos defnidos de cooperao e de
participao proativa.
Sees de estudo
Seo 1 Estruturando a equipe.
Seo 2 Recursos humanos e perfs.
Seo 3 Treinamento.
Seo 4 Responsabilidade e diviso de tarefas.
Seo 5 Terceirizao.
200
Voc ver que esta unidade contm muito mais opinies pessoais
do que tcnicas e dicas infalveis. So opinies baseadas
em anos de atuao em diferentes projetos, seja com equipes
trabalhando dentro do escritrio ou em trabalhos de campo,
seja com pequenas empresas ou em grandes corporaes, e com
modelos de estrutura hierrquica os mais diversos possveis.
No entanto, no so somente opinies, mas tambm algumas
tcnicas e mtodos so apresentados aqui.
De incio, voc ver um modelo de formao de equipes e
como se do os problemas no comeo dos relacionamentos,
especialmente quando a equipe tem vrias pessoas de origens
diversas. Esses problemas acontecem devido aos diferentes pers
humanos, ou seja, s diferentes caractersticas de comportamento
e atitude, muito mais do que diferenas de conhecimento tcnico.
As questes tcnicas, muitas vezes, podem ser resolvidas por
meio de treinamentos especcos e dirigidos. No o caso
quando temos grandes diferenas comportamentais. Nesses casos,
precisamos ter lderes frente das equipes, pois o que interessa
em projetos ter ambientes de grande cooperao e o interesse
sincero (e ousado!) pelo sucesso. Falaremos um pouco sobre
liderana, mas deixaremos o principal para a prxima unidade.
Nesta unidade voc estudar apenas algumas alegorias (que
espero que sejam divertidas, e esclarecedoras tambm!).
Voc ver tambm cinco diferentes modelos de estruturao
de equipes, que so os mais usados pelos grupos de projetos,
variando desde os casos mais complexos, nas grandes empresas,
at os trabalhos mais simples e com pequenas equipes. Esses
modelos so muito teis e nos ajudam a estruturar o grupo de
pessoas e comunicar as funes e interfaces de trabalho.
201
Unidade 5
Treinamento e terceirizao so os outros dois tpicos tratados
aqui, sendo que o processo de terceirizao assumiu, nos ltimos
tempos, um carter estratgico para as empresas e especialmente
para os pases dominantes, o que tem trazido muita discusso
para a arena econmica e poltica, e isto est ligado diretamente
ao nosso objeto de estudo.
Bom estudo a todos!
SEO 1 Estruturando a equipe
Considere um campeonato de futebol como um
projeto: cada time traa seus objetivos, contrata
jogadores, treinador, busca recursos e tem datas
denidas para chegar aos resultados.
H inmeros riscos, pois uma competio com
muitas variveis. Sabemos que uma questo muito
importante, sempre discutida pelos comentaristas
e que tambm a conversa do incio de cada
semana aps uma rodada emocionante, trata da formao e do
entrosamento dos jogadores dentro de campo.
Cada jogador tem sua funo, sabemos mais ou menos sobre suas
qualidades e alguns so reconhecidos por sua competncia. No
entanto em cada partida h um comportamento diferente, h
um jeito diferente de jogo, e simultaneamente encantamentos e
decepes.
Certamente os projetos de pesquisa, de engenharia, de software,
no so assim to famosos nem to visveis, mas muitas vezes so
bastante emocionantes. E vo depender de quanto h de sensao
de time na equipe.
Constituir uma equipe relativamente fcil, constituir
um time, no tanto.

202
A equipe constituda a partir da denio de funes, ento
possvel determinar as caractersticas necessrias de um
indivduo para que preencha tal funo. Grandes companhias
preparam uma lista de requisitos mnimos para que se procurem
funcionrios para determinada vaga.
Em algumas equipes h pessoas trabalhando no recrutamento
que atuam como mquinas de vericao: olham currculos e
buscam aquelas que preenchem tais requisitos, depois fazem as
entrevistas e as anlises de perl (psiclogos trabalham nisso) e,
por m, algum contratado e passa a integrar a equipe.
Essas companhias enxergam o trabalho como atividade rotineira
e, muitas vezes, mquinas e pessoas no fazem grande diferena.
Atividades rotineiras suportam equipes assim, mas penso que
projetos no.
Projetos, assim como campeonatos, exigem pessoas que
trabalhem em cooperao e que gostem, realmente, de chegar aos
resultados com sucesso. Em uma equipe convencional, de rotina,
cada um faz a sua funo (no precisaria ser assim!). Em um
projeto os membros da equipe trabalham para ajudar os outros,
fazendo a sua funo e colaborando para que os outros realizem
as suas.
O primeiro conceito importante na formao de
uma equipe a cooperao. O segundo conceito
importante o objetivo comum.
Os membros da equipe devem trabalhar em regime de
cooperao em busca de um objetivo comum. Isto j estava claro
desde o comeo de nosso estudo, pois voc viu que uma das
chaves de sucesso do projeto a viso clara sobre o resultado
esperado.
Formar uma equipe que trabalhe com objetivo comum e de forma
cooperativa um verdadeiro desao (basta ver que muitas vezes
os times com os melhores jogadores no ganham o campeonato
algo cou faltando!). Isso quer dizer que no basta analisar
as competncias pelo currculo. necessrio que alm da
competncia a pessoa que vai fazer parte da equipe de projeto
tenha a cultura da colaborao. Isso no pode ser detectado sem a
convivncia. E gerentes de projetos que no sejam lderes, muitas
A pessoa nesse caso um agente
que toma decises e tem liberdade
de ao, ao contrrio da mquina.
203
Unidade 5
vezes no conseguiro sacar essa caracterstica. Essa percepo
exige experincia e intuio. Aqui estamos saindo do campo
das cincias exatas e entrando no campo pantanoso das relaes
humanas (nada exatas...).
Na estruturao da equipe de um projeto, conforme
Valeriano (1998), h quatro momentos distintos:
Formao. Quando se renem os membros do projeto
e as funes so distribudas, ainda no h clareza das
atividades a serem realizadas As pessoas no se conhecem e
o tratamento formal. Por no haver conhecimento h um
ambiente de confuso inicial.
Turbulncia. A partir do incio das atividades comeam a se
formar subgrupos a partir de afnidades pessoais, e muitas
vezes principiam atritos, especialmente em equipes grandes
com pessoas de variados tipos. A turbulncia comum em
projetos, especialmente quando os riscos so grandes e
iminentes.
Normalizao. Se os perodos de turbulncia so resolvidos
pela liderana, os processos de trabalho passam a ser bem
conhecidos e aceitos por todos, as atividades tornam-se
claras, assim como os objetivos, estabelecem-se normas
internas e o trabalho passa a andar.
Desempenho. Nesse perodo a equipe entra em equilbrio
criativo e cooperativo, e o projeto tem alto rendimento. Os
membros sentem-se parte do time de trabalho, reconhecem
a liderana e os companheiros como importantes em seu
prprio papel.
Essas quatro fases de estruturao podem acontecer ou no,

sendo que muitos projetos chegam a crescer at a normalizao
apenas, sem atingir o ambiente propcio do desempenho.
Sustentar a fase do desempenho , alm de tudo, uma tarefa
difcil que exige esforo contnuo. Veja na gura a seguir o
diagrama esquemtico dessa estrutura.
204
Fase 1
FORMAO
Fase 2
TURBULNCIA
Fase 4
DESEMPENHO
Fase 3
NORMALIZAO
Reunio inicial, formalidade, confuso sobre
as funes, atividades indefinidas.
Formao de subgrupos (panelinhas),
atritos, incio da acomodao.
Esprito de colaborao, cooperao
criativa, alto rendimento.
As funes esto definidas, os grupos se ajustam,
a liderana se impe e normas so claras.
Figura 5.1 Representao esquemtica das fases de estruturao da equipe de projeto.
SEO 2 Recursos humanos e pers
Como voc viu na seo anterior, a escolha de pers humanos
para trabalhar em uma equipe de projeto est fora da escolha de
caractersticas exatas, caractersticas pr-denidas e nas quais
algumas pessoas especiais se encaixariam. Esse o campo das
relaes humanas, relaes sempre sutis, delicadas, que variam
innitamente.
Os membros da equipe acabam por se moldar
s caractersticas do gestor. Se o gestor for
um lder, poder conduzir sua equipe para a
fase do desempenho. Se no, provavelmente
permanecero na fase da normalizao.
Portanto ser importante discutirmos os pers
dos gestores, sejam lderes ou no. Mas antes
de falar dos gestores/lderes, vamos tentar
descrever alguns pers tpicos das pessoas que
viro a fazer parte de nossas equipes de projeto.
205
Unidade 5
Keeling (2002) apresenta diversos tipos de pers citando outros
autores como Margerison e McCann, que comentam sobre oito
diferentes papis, Belbin, que classica nove grupos descritivos,
ou Parker, com apenas quatro papis. Os quatro papis de Parker,
citados por Keeling (2002) so:
Contribuidor. Aquele que
contribui com atividades
e resultados, mas no
participativo.
Colaborador. O que participa
do desenvolvimento em
conjunto.
Comunicador. Capaz de
comunicar as atividades e de
integrar grupos por meio da
comunicao.
Essas tentativas de classicao muitas vezes caem no vazio,

tal o nmero de possibilidades e de percepes. Muito
provavelmente no possvel ser cientco nesse caso,
e a classicao ser local e temporal, ou seja, depender
do ambiente, da situao e das condies culturais de um
determinado grupo.
Pela diculdade do tratamento cientco (se que isso
necessrio), posso fazer uma brincadeira e descrever alguns pers
que j participaram de projetos junto comigo, e que no decorrer
das experincias foram se formando como tipos, facilmente
reconhecveis. Veja alguns:
Desafador. O que sempre
apresenta as questes e
participa dos trabalhos num
esprito de desafo (o que pode
ser bom ou ruim, depende da
situao e do caso).

206
O que est sempre disposto. Esse o tipo de pessoa que
est sempre cheia de energia, e para qualquer atividade que se
apresenta, logo j quer sair fazendo coisas; tem disposio e
energia, mas por esse motivo acaba por se entregar ao trabalho
antes de saber exatamente o que fazer, prejudicando todo o
desempenho.
O que nunca entrega. Tive projetistas trabalhando comigo que
sempre estavam a um passo de fechar um projeto ou parte dele,
mas por algum motivo estranho esse passo nunca acontecia;
personaliza aquela Lei de Murphy que diz que ao completar 90%
do trabalho, fcam faltando os outros 90%. O problema da entrega
um dos mais importantes em projeto, pois chama a ateno sobre
o fato dos projetos em geral no serem entregues no prazo, e isso
decorre da difculdade em ver, claramente, o fm de cada etapa.
O que fnge ser especialista. O ditado popular diz que
especialista aquele que sabe quase tudo sobre quase nada.
Como geralmente as pessoas normais no conhecem tudo sobre
tudo, muitas vezes algum que domina meia dzia de belas frases
tcnicas e alguns acrnimos da moda, passa por especialista. Na
informtica isso muito comum, e tenho visto em conferncias
por a aqueles profssionais que aparentam grande conhecimento
e que no resistem a mais do que duas perguntas; para nossos
projetos, vamos nos cuidar com esse tipo.
O que especialista, mas no se entende com os outros. Vale
a mesma mxima de especialista do item anterior, porm nesse
caso ele de fato conhece um quase tudo sobre um quase nada
que interessa ao projeto, o problema que, por esse motivo, o tipo
acredita que vale mais do que os outros e tem enorme difculdade
de relacionamento. Se projetos so trabalhos de cooperao, sua
especialidade perde o valor automaticamente; melhor algum que
sabe um pouco sobre o quase nada, e que possa cooperar com
aqueles que esto sua volta.
O que puxa-saco. No preciso pensar muito para lembrar
de pessoas com esse perfl, pois no h grupo que no tenha
esse membro (infelizmente); concorda sempre com o superior
hierrquico, e inconscientemente se move para fcar sua sombra
(e com as suas sobras); caso haja um atrito, vai se colocar do lado
do que tem mais fora, e no consegue agir com opinio prpria;
deve ser eliminado da equipe sempre que for descoberto.
O que suga energia. Em uma equipe de alto desempenho
buscamos cooperao e boa vontade, e quando h divergncias

207
Unidade 5
elas so tratadas como geradoras de novas solues.
Contudo h o perfl de pessoa que funciona como um
buraco negro, sugando idias e a energia do resto dos
membros de equipe; difcil perceber essa ao, e muitas
vezes s fca evidente depois de muito tempo, e muito
estrago.
O que no comunica. Comunicao fator crtico de
sucesso em projetos, mas a difculdade de comunicar com
clareza e objetividade algo muito comum; no estamos
livres desse problema, e temos que fcar atentos em ns
mesmos e em nossas aes; a busca por comunicar deve ser
uma meta paralela meta por entregar.
O que detalhista operacional. A pessoa que logo
se entrega ao trabalho e vai direto para a bancada,
querendo produzir algo, geralmente tem essa caracterstica
do detalhista operacional: no consegue parar para
ver o projeto em linhas gerais e j quer realizar alguma
parte dele. Boa parte dos softwares que conhecemos foi
desenvolvida por pessoas assim, e por isso a difculdade
de integrao, a difculdade de melhorar, a difculdade de
achar erros etc.
O que generalista estratgico. Perfl diametralmente
oposto ao anterior, sempre est olhando o projeto, e
qualquer atividade, de um ponto de vista muito genrico;
tem difculdade para colocar a mo na massa, pois sempre
tem uma viso nova, geral, para colocar, e no percebe
o momento de partir da superfcie para o fundo, ou seja,
consegue navegar mas no mergulhar.
Esta lista pode se estender por pginas e pginas. Deixarei para

voc imaginar alguns outros pers problemticos.
Analisando perfs problemticos, voc consegue
avaliar quem manter e quem evitar em sua equipe de
trabalho? Refita sobre isso!
208
Por outro lado temos a gura do gestor, e variados pers tambm
tm sido escritos sobre ele. As publicaes sobre gesto e estudos
de gerenciamento discorrem sobre tcnicas e mtodos de gesto,
mas ultimamente h nfase sobre as caractersticas da liderana
acopladas atividade gestora.
Conheci um sujeito que no gostava da palavra lder, pois
associava essa imagem com a gura do carisma, a algum cheio
de seguidores fanticos. Esse sujeito certamente no era um lder
de projetos, nem de empresas (de fato no era, pois fugia das
situaes crticas, amedrontado).
Se, nos pargrafos anteriores, discorremos sobre variados pers
de membros de equipes de projeto, cabe tambm apresentar
alguns pers de gestores.
Na prxima unidade, as funes dos lderes e suas
relaes com os membros da equipe, durante a
execuo do projeto, sero discutidas em maior
profundidade. Aqui vamos fcar apenas com algumas
notas sobre perfs de gestores, na forma de caricaturas
(ou seja: como no ser um gestor!).
A brincadeira a seguinte: sem ofender o mundo animal vamos
descrever trs modelos diferentes de gestores comparando-os
com o comportamento de animais. Obviamente esses animais
no se comportam exatamente assim mas, como metfora, podem
ser teis e voc perceber que h muitas pessoas agi ndo assim
(no s em lmes!). Bem, eu j conheci. Vamos a eles:
209
Unidade 5
Gestor-rinoceronte. Quando voc vir aquele gerente
andando em passos largos e falando alto na direo de um
funcionrio da equipe, o tom ameaador j denunciar
a performance de rinoceronte; ele no precisa ser gordo
nem grande, basta esse comportamento de quem quer
resultado pelo aspecto ameaador. A cara de tonto e o
seu contedo de conhecimento quase nulo, mas no se
pode duvidar que se esbarrar com ele, trar conseqncias
fsicas (mas no intelectuais, pois seu estilo no esse). Esse
o famoso gerento, que pensa em obter resultados de
sua equipe de projeto chamando a todos todo o tempo
para cobrar algum resultado, resultado que ele mesmo no
tem certeza qual seria, devido sua falta de domnio. Esse
tipo introjetado no cargo por algum outro superior (talvez
um gerente-raposa), e sua equipe se divide entre os que
tm medo e os que querem distncia.
Como evitar ser um gestor-rinoceronte? Respeitando os
membros da equipe, ouvindo com educao, estudando
o projeto, respeitando as difculdades, assumindo os riscos
em parceria, participando como um colaborador e no
como um cobrador truculento.
Gestor-cobra. Diferente do rinoceronte, esse tipo de
gestor evita confrontos e prefere agir sorrateiramente. Voc
no est vendo, mas sabe que ele est observando suas
aes de longe, pronto para atacar se qualquer coisa sair
errada. Em sua frente ele est quieto, muitas vezes com
aquela educao disfarada e o esforo para parecer no
controle. Se alguma apresentao pblica do projeto for
necessria ele designar um membro da equipe, pois ele
mesmo no vai se expor. Compartilha com o rinoceronte o
desconhecimento dos detalhes do projeto, mas como fala
pouco no possvel determinar at onde conhece ou no
conhece. tica para ele uma palavra de dicionrio, no
um comportamento. Com esse tipo de gestor o grupo de
projeto acaba se conformando a entregar apenas o mnimo
necessrio, e aqueles que ousam destoar so aniquilados
sorrateiramente.
Como evitar ser um gestor-cobra? Admitindo as
diferentes vises da equipe, expondo-se, sendo claro,
agindo com tica nos relacionamentos, no destilando o
veneno da negatividade entre pessoas que esperam criao
e liberdade.
SEGUE
210
Gestor-raposa. Enquanto o tipo rinoceronte coordena a
equipe de projeto derrubando o que encontra pela frente e o tipo
cobra coordena a equipe pelo medo do que no est vendo, o
tipo raposa muito mais sutil e muitas vezes engana inmeras
pessoas com seu ar de sabedoria. Por isso chamamos determinado
poltico de raposa: ele esperto e gil, e sempre quer se dar bem
pelas articulaes que faz (em proveito prprio, certamente). Esse
tipo de gestor no se importa com os membros da equipe, e afaga
suas cabeas enquanto esses lhe servem. No entanto no dia que
algo ameaa sua posio, busca uma maneira sutil de desviar o
inconveniente. No h projeto criativo que ande bem com esse
tipo de gestor, pois no admite as diferenas. O que o distingue
do tipo cobra que no articula um ataque s escondidas, e de
fato estuda e conhece muitas coisas. Seu problema o medo e a
difculdade de relacionamento, pois se comporta de forma arredia,
distante e fria. Uma boa idia dentro da equipe para ele uma
ameaa, pois aquele membro poderia ser superior a ele. Se tiver
um rinoceronte e uma cobra a seu servio, eles faro o servio sujo
por ele.
Como evitar ser um gestor-raposa? Fazendo um exerccio por
admitir as diferenas, abrindo-se aos relacionamentos, permitindo
o trabalho em grupo e participando dele, aproximando-se, e
muitas vezes simplesmente cumprimentando os membros da sua
equipe. Parece simples, no ? Mas a realidade tem mostrado que
a maioria dos gestores, infelizmente, acaba se adequando a um
desses papis, ou hbridos deles.
Por m, na denio de pers para escolher os membros da

equipe de projetos, podemos tentar nos guiar por algumas notas
de trabalho. Uma alternativa interessante criar a matriz de
qualidades desejveis e de funes necessrias em um projeto.
Digamos que se tenha um grupo de pessoas na empresa que
possa vir a participar do projeto, e precisamos denir suas
posies. Ao mesmo tempo sabe-se as competncias tcnicas
necessrias, e comportamentais tambm, para trabalhar nele.
Criar e preencher uma matriz, como a do exemplo da gura 5.2,
ajuda a perceber os pers e como distribuir os papis. Olhando
para a matriz temos a tendncia a eleger o prossional F
como lder da equipe, pois tem experincia e dispe de tempo,
enquanto o prossional D novo na empresa, e isso pode
211
Unidade 5
gerar algum desconforto. Em domnio tcnico vemos que os
prossionais B e E so capacitados, mas no dispem de tempo
livre (podem estar engajados em outros projetos), e a alternativa
ser discutir com eles as possibilidades de rearranjo de trabalhos.
Perl e necessidades
Conhecer
tecnologia
1
Conhecer
tecnologia
2
Conhecer
tecnologia
3
Dominar
uso de
X
Exp. de
trabalho
em equipe
Exp. de
trabalho
em equipe
Disp. de
tempo
Novo na
empresa
Membro da equipe
Prossional A
X X X
Prossional B
X X X X
Prossional C
X X
Prossional D
X X X X
Prossional E
X X X X
Prossional F
X X X
Figura 5.2 Matriz de perfs e competncias profssionais.
SEO 3 Treinamento
A educao anterior ao treinamento. Para que haja algum
treinamento necessrio que os membros da equipe tenham uma
educao prvia e apropriada.
A formao do conhecimento e a aprendizagem
passam pela anlise crtica e pela refexo, prprias
do ser humano, enquanto que o treinamento para
atividades rotineiras pode ser feito at mesmo com
animais.
No incio da revoluo industrial
foi necessria mo-de-obra treinada
para operar mquinas, e tal operao
passava por uma repetio contnua
de procedimentos. Muitas crticas
foram dirigidas a tais atividades, que
de alguma forma se repetem at hoje,
especialmente nos pases em processo
de industrializao.
212
Esse ambiente de incio de industrializao teve espao no Brasil
mais ou menos no meio do sculo passado, quando grandes
indstrias de base foram criadas.
Nosso pas, de certa maneira, no evoluiu muito desse ambiente
de indstrias bsicas, processadoras de matria-prima, e
facilmente se percebe isto vendo a importncia econmica que
tais empresas tm entre as 500 maiores. Indstrias da era da
informao (que exigem mais educao do que treinamento)
ainda so incipientes, ao contrrio do que acontece na Europa ou
Amrica do Norte.
Considerando que estamos aqui estudando projetos
de desenvolvimento e inovao, o treinamento cabe
como complemento e ajuste para a equipe.
Veja o exemplo de matriz da gura 5.2. Precisamos de algumas
competncias especcas de tecnologias para o desenvolvimento
do projeto, alguns treinamentos sero necessrios para
uniformizar os conhecimentos dos membros da equipe. Isso
deve estar no foco da gerncia do projeto, para evitar que o
desconhecimento tcnico seja empecilho ou fator de risco. Mas
se o projeto for de longo prazo, melhor criar alternativas de
educao em grupo do que meros treinamentos de curta durao,
cuja funo atender objetivos bem denidos e de alcance
imediato.
Ainda na matriz da gura 5.2, se observa que h pers desejveis
e que, aparentemente, no so preenchidas pelos seus membros
(como liderana, por exemplo). Ultimamente tm tido nfase os
treinamentos para lderes, e tenho visto nas empresas o interesse
(supercial em muitos casos) de oportunizar o surgimento de
lideranas.
Treinamentos so criados para esses casos, e gerentes so
envolvidos neles.
Nessa poca foi criado o Senai, at
hoje responsvel por treinamento
de mo-de-obra para esse tipo de
indstria.
213
Unidade 5
A liderana , no entanto, mais uma questo de comportamento
e atitude do que de tcnica. O incentivo a esse surgimento deve
passar por um ambiente que estimule a liberdade de expresso e
experimentao.
Treinamentos so feitos para tecnologias, no para
comportamentos.
SEO 4 Responsabilidades e diviso de tarefas
Em um projeto as atividades so divididas ao mximo, como voc
viu na composio de Diagramas de Gantt, unidade 4. A diviso
das atividades feita para se ter clareza dos objetivos e para
perceber as entregas parciais. Tambm no Diagrama de Gantt
atribumos tarefas para os membros da equipe e, assim, cada
um enxerga suas metas e seus prazos. Atividades diferentes para
pessoas diferentes.
A distribuio de responsabilidades ser feita de acordo com
o modelo adotado pela gerncia do projeto. H gestores que
centralizam em excesso as decises, e outros que delegam. O
equilbrio depender bastante do seu perl, assim como da
acomodao dos membros da equipe.
Segundo Page-Jones (1990), prioridades so para gerentes, no
para funcionrios. Com isso ele quer armar a distribuio de
responsabilidades conforme o papel de cada um na equipe. Para
a gerncia do negcio a meta o resultado global e a satisfao
do cliente, enquanto para o desenvolvedor a meta a entrega
conforme a especicao da sua tarefa. Este o Modelo de
Equipe denido no framework da Microsoft (MSF, 1998) quando
dene papis em uma equipe. Assim, para cada um, uma tarefa
de cada vez.
Para denir os papis e comunic-los equipe importante
criar um organograma, denindo as funes e a hierarquia
dos membros. H inmeras possibilidades de estruturar tal
organograma, e isso depender da complexidade do projeto, da
214
empresa onde a equipe de projeto est sendo montada, de como o
projeto interfere nas atividades da empresa, etc. Segundo Keeling
(2002), h cinco estruturas tpicas de grupos de projetos:
Estruturas diferenciadas e exclusivas.
Estruturas hbridas.
Estruturas matriciais.
Estruturas modulares.
Estruturas horizontais.
Vamos discutir as principais delas e ver como podem se adequar
aos nossos projetos.
Estruturas exclusivas
Projetos de pequeno porte, que consigam ter seu prprio pessoal
e recursos exclusivos, e tm pequena complexidade, podem
montar estruturas organizacionais simples e funcionais. Esse
tipo de estrutura direta em seus procedimentos e fcil de ser
compreendida pelos membros da equipe. Pequenas empresas
de engenharia da construo, por exemplo, trabalham desta
maneira, onde o gestor do projeto trabalha com um conjunto
de tcnicos e pessoas de apoio administrativo, e ele reporta
diretamente ao cliente nal. A gura 5.3 apresenta o diagrama
desse modelo, que chamado de estrutura exclusiva porque os
membros do projeto so dedicados a um projeto apenas.
Cliente
/ proprietrio do projeto
Gestor
/ lder do projeto
Apoio administrativo
Membro TCNICO 1 Membro TCNICO 2 Membro TCNICO 3
Figura 5.3 Estrutura exclusiva.
1.
2.
3.
4.
5.
215
Unidade 5
Estruturas hbridas
Em projetos internos s empresas maiores, onde vrios projetos
ocorrem ao mesmo tempo, as estruturas hbridas passam a
ocorrer com maior freqncia. Veja a gura 5.4, onde um
organograma tpico desse modelo de estrutura apresentado. O
gestor do projeto conta com membros dedicados exclusivamente
quele trabalho, mas precisa paralelamente recorrer a outras
pessoas, que no estaro dedicadas a esse projeto, mas que so
importantes para ele e que simultaneamente se dedicam a outras
reas dentro da empresa. Se o gestor do projeto tiver liberdade
de trabalho para recrutar tais pessoas, e dispuser de parte do seu
tempo, o projeto ter sucesso. Empecilhos ocorrem quando essa
liberdade no lhe permitida, o que levar o projeto a atrasos e
disperses.
Gerncia geral
da empresa
rea
administrativa
rea
financeira
Engenharia
rea
comercial
Gestor
/ lder do projeto
Membro
TCNICO 1
Membro
TCNICO n
Figura 5.4 Estrutura hbrida.
Estruturas matriciais
Estruturas matriciais so bem mais complexas e exigem grande
maturidade de trabalho, tanto por parte da empresa quanto por
parte dos membros das diversas equipes. A gura 5.5 apresenta
esse tipo de estrutura, onde vemos que diversos projetos ocorrem
ao mesmo tempo, sendo que os membros fazem parte das reas
da empresa, e no dos projetos exclusivamente, ou seja, cada
funcionrio est inserido em determinado setor da empresa e
216
executa servios que atendem ora a um projeto, ora a outro.
Algum estar responsvel pelo projeto, e ser denido como
seu gestor, mas mesmo esse gestor pode estar designado para
mais de um projeto, ou para partes de um projeto, sendo que esse
mesmo gestor est alocado a um determinado setor/departamento
da empresa. Sem dvida a coordenao desse tipo de estrutura
mais complexa, e exige alto grau de organizao geral da
empresa, especialmente em relao aos planos de produo.
Projeto 2
Projeto 3
Projeto n
Projeto 1
Gerncia geral
da empresa
rea
administrativa
rea
financeira
Engenharia
rea
comercial
rea
tcnica 1
rea
tcnica n
Figura 5.5 Estrutura matricial.
Estruturas modulares
Estruturas modulares ocorrem quando, dentro da empresa, h
grupos com relativa autonomia e determinada especializao, que
realizam determinado tipo de servio. O gestor de determinado
projeto emprega esse grupo modular para desenvolver parte
do projeto, e vai distribuindo assim as atividades conforme
as especializaes. Internamente o grupo (ou mdulo de
desenvolvimento) tem autonomia para gerenciar aquela etapa,
sendo que o gestor geral do projeto percebe a entrada e a sada do
mdulo, mas no propriamente o que acontece em seu interior.
Projetos de software, por exemplo, envolvendo grandes equipes
com diferentes conhecimentos, podem usar esse tipo de estrutura.
217
Unidade 5
Gestor
/ lder do projeto
Grupo
TCNICO 1
Grupo
TCNICO 2
Grupo
TCNICO 3
Desenvolvimento
HARDWARE
Grupo
TCNICO 4
DESIGN
grfico
:
Figura 5.6 Estrutura modular.
Estruturas horizontais
As estruturas horizontais geralmente so formadas por poucos
membros, onde h uma grande maturidade no trabalho em
conjunto. As relaes se do em rede, onde todas as pessoas se
relacionam com todas as outras. O lder do grupo tem a funo
de acompanhar o andamento das atividades, e ele mesmo muitas
vezes membro ativo do desenvolvimento do projeto, como
por vezes acontece em trabalhos de pesquisa e desenvolvimento
reunindo pesquisadores diversos. Projetos que usam esse tipo
de estrutura renem especialistas e, por esse motivo, o lder
geralmente tambm um especialista tcnico ou cientco, de tal
forma que sua ascendncia sobre o grupo seja inequvoca.
A gura 5.7 mostra exemplo de congurao de uma estrutura
horizontal. O modelo de desenvolvimento de aplicativos
da Microsoft (MSF, 1998) tambm se baseia nesse modelo
horizontal, denido por pequena equipe de pares ou especialistas
trabalhando em papis multidisciplinares e interdependentes. A
questo da multidisciplinaridade, que surge aqui, tem especial
interesse em projetos de inovao tecnolgica, como no caso
dos aplicativos. O ambiente proporcionado por uma estrutura
horizontal permite os dilogos constantes e a troca positiva de
idias, nascedouro de solues criativas.
218
Cliente
/ contratante
/ diretoria
Gestor
/ lder do projeto
Especialista
TCNICO 1
Especialista
TCNICO 2
Especialista
TCNICO 3
Engenheiro
SOFTWARE
Designer
GRFICO
Figura 5.7 Estrutura horizontal de equipe de projeto.
SEO 5 Terceirizao
A palavra terceirizao entrou na moda h uns dez ou vinte anos
atrs, e foi uma soluo adotada na indstria para otimizar seus
modelos de produo. Basicamente consistia em contratar partes
da produo com empresas externas, ou terceiras, em vez de
produzir com equipes prprias.
Com isso era possvel obter uma concentrao de esforos,
dentro da empresa, em atividades e conhecimentos que lhe eram
prprias, no sendo necessrio desenvolver competncias diversas.
O uso de empresas de transporte foi uma terceirizao do servio
de entregas, por exemplo. A terceirizao caminhou cada vez
mais para dentro das empresas e, ento, partes do produto
passaram a ser feitas por outras empresas (por exemplo, as peas
diversas de um carro. E por isso que as fbricas de automveis
so chamadas hoje de montadoras.
219
Unidade 5
Mas isso implicou tambm um enorme esforo de controle de
qualidade e de prazos de entrega, pois uma parte do processo
que falhasse comprometia todo o conjunto. Veio do Japo ento
a expresso just in time, para signicar os procedimentos de
entrega no prazo exato.
Com o passar do tempo percebeu-se que a terceirizao poderia
avanar muito mais, pois fabricar pedaos de ferro e mont-los
no era o segredo de uma empresa, e sim a concepo, o desenho,
a inteligncia da criao do produto. A partir disso uma cadeia
imensa de pequenos fabricantes se estabeleceu, e hoje muitos
esforos dos governos por trazer grandes empresas se do pela
inteno de formar cadeias produtoras ao redor delas.
No entanto, estamos falando de terceirizao de
tarefas contnuas da indstria, enquanto que no caso
dos projetos, a idia um pouco diferente, por se
tratar de servios de durao limitada e com objetivos
pr-defnidos.
A terceirizao tem sido utilizada para ganhar produtividade,
para ganhar tempo, para colocar especialistas fazendo as
especialidades. Em projetos a produtividade est relacionada
ao prazo. Para que seja possvel a terceirizao, necessria
uma sincronizao muito forte entre o trabalho que est sendo
executado pela equipe interna do projeto e a equipe ou pessoa que
car responsvel pelo trabalho externo, ou terceirizado.
A estrutura modular, mostrada na gura 5.6 anteriormente,
uma possibilidade de trabalhos desse tipo, pois cada grupo ou
mdulo, pode ser visto como uma unidade independente que tem
uma determinada tarefa a cumprir. Identicar as competncias de
tais grupos e ter os trabalhos alinhados entre os diferentes grupos
o desao.
A indstria da construo civil j atingiu essa maturidade
para a terceirizao de servios de um projeto.
Equipes de empreiteiros diversos, grupos externos
de eletricistas e tcnicos hidrulicos, entre outros,
atuam como terceirizados no projeto. Isso funciona
adequadamente porque a indstria da construo
civil repete os procedimentos obra aps obra, e cabe ao
engenheiro da obra fazer a gesto desses diferentes grupos.
220
Mais recentemente a indstria de software tem
trazido exemplos de terceirizao.
Metodologias como o do PMI Project Management Institute
(PMBOK, 2004), modelos como o CMM (Capability Mature
Model) e linguagens com a UML (Unied Modeling Language),
vm trazendo um alto grau de prossionalizao para o setor de
software, fazendo com que haja uma segmentao bem delimitada
na produo dos aplicativos.
Isso vem gerando grandes debates nos Estados Unidos, pois
muitas atividades consideradas estratgicas nessa indstria
passaram a ser terceirizadas em outros pases, especialmente
ndia e China, que competem utilizando mo-de-obra
qualicada, porm muito mais barata do que a americana. So
os efeitos da globalizao numa indstria que no precisa mais do
que uma rede como a internet para fazer todo o transporte das
partes e peas terceirizadas.
Para encerrar esse assunto, veja os dois quadros reproduzidos
abaixo, onde o primeiro aponta para o aumento dos contratos
de terceirizao, publicado no site da ASSESPRO SC, e o
segundo com a matria publicada no site da SOFTEX, que
reproduz texto a respeito dos riscos da terceirizao apontados
pela empresa de consultoria Gartner dos Estados Unidos.
Esse um assunto bastante atual e que dever perdurar nos
debates devido ao processo de globalizao acelerado dos
mercados, especialmente os ligados s inovaes tecnolgicas e
informao.
221
Unidade 5
Terceirizao de software e servios de TI cresce
Mercado mundial de terceirizao dever crescer 7,9%.
De acordo com um estudo do Gartner esse percentual
corresponde aos anos de 2003 a 2008.
A terceirizao continua crescendo em todo o mundo, embora
em ritmo diferente, em relao regio analisada, de acordo
com estudo do Gartner.
A taxa Composta de Crescimento Anual (CAGR) de
terceirizao ser de 7,9%, entre 2003 e 2008, enquanto a taxa
total de crescimento de TI atingir 5,4%.
Os gastos com terceirizao de TI e terceirizao de processos
de negcios (BPO), em mbito mundial, crescem mais
rapidamente do que os gastos com servios individuais e
aqueles baseados em projetos.
Isso refete uma tendncia de crescimento da terceirizao,
que vai alm do mero gerenciamento de sistemas e processos
j implementados. As empresas terceirizadas esto assumindo
cada vez mais as responsabilidades de desenvolver e oferecer
novos sistemas e processos, bem como seu gerenciamento.
De acordo com estudo existem dois fatores que impulsionam
o avano do mercado de servios em regies diferentes: o
primeiro refere-se cultura local e s prticas de negcios; e o
segundo, diz respeito aos padres estabelecidos pelas grandes
companhias globai s que compem o mercado.
Sobre a situao do mercado local, o Brasil e o Mxico so os
lderes em terceirizao na Amrica Latina, seguidos do Chile e
da Colmbia.
Quadro 5.1 Sobre o aumento da terceirizao, publicado em 09/06/2005 em
http://www.softex.br/cgi/cgilua.exe/sys/start.htm?sid=4
222
Gartner aponta riscos da terceirizao ofshore
Por COMPUTERWORLD
Empresas de todo o mundo gastaro mais de 50 bilhes de dlares
com iniciativas de terceirizao ofshore (fora do pas) ou near-shore
(dentro do pas) de TI at 2007, aponta a consultoria Gartner. No
entanto, alerta a companhia em um novo estudo, muitos projetos
falharo devido a planejamentos mal estruturados.
Muitas companhias tm buscado nas estratgias de terceirizao
de TI uma forma de obter vantagem competitiva frente aos
concorrentes, seja com reduo de custos ou aumento de
produtividade. Mas estes objetivos podem ser seriamente
comprometidos por diversos fatores.
Em seu estudo, o Gartner selecionou os cinco maiores riscos que
podem comprometer o sucesso da terceirizao, seja esta feita por
meio de um parceiro local ou por um especializado de outro pas.
1. Reduo de custos impraticvel
Muitas companhias decidem buscar servios em outros pases, com
o propsito de reduzir custos. Segundo o Gartner, um profssional
de manuteno de aplicaes indiano, por exemplo, ganha cerca
de 25 dlares por hora, contra a mdia de 87 dlares cobrados pelo
mesmo servio, nos Estados Unidos.
Contudo, um erro limitar os custos da operao apenas ao salrio
do funcionrio. A consultoria alerta para outros gastos atrelados a
fatores como infra-estrutura, comunicaes, viagens e treinamento
relacionado a questes culturais. Portanto, o custo inicial da
operao alto e, em muitos casos, pode ser mais rentvel aps um
ano de operao.
2. Perda de produtividade
Pelo menos inicialmente, os prestadores de servios ofshore
tendem a no apresentar a mesma produtividade que a companhia
mantinha internamente. De acordo com o Gartner, em mercados
emergentes muitos programadores so jovens e no possuem a
mesma experincia que a companhia encontra em seu pas de
origem.
223
Unidade 5
3. Comprometimento e comunicao enfraquecidos
Muitos executivos simplesmente esquecem seus contratos
depois que so assinados. A consultoria alerta para a
necessidade de se estar engajado com o prestador de
servios para que se mantenha a qualidade de servios pr-
acordados.
Estabelecer uma boa comunicao entre as partes crucial,
defnindo claramente projetos, objetivos e expectativas.
Dentro de casa, o diretor de tecnologia tem que deixar muito
claro porque mandar as operaes para outro pas traz mais
benefcios para a companhia.
4. Diferenas culturais
Estilos de comunicao e atitudes de autoridade mudam
conforme a regio e estas diferenas podem trazer
problemas. Em algumas culturas, o ato de questionar a
autoridade de determinada pessoa considerado falto de
respeito. Empresas interessadas na terceirizao ofshore
devem realizar treinamento entre equipes para evitar esse
tipo de situao, alerta o Gartner.
5. Distncia entre teoria e prtica
Algumas organizaes podem vender mais do que realmente
oferecem. preciso que o prestador de servios tenha todos
os processos internalizados com suporte e segurana, antes
de colocar um projeto em operao. O Gartner tambm
destaca para a necessidade de se verifcar o grau de
maturidade dos processos da empresa, utilizando padres
reconhecidos de mercado como o CMM, do Software
Engineering Institute. Fraquezas nesta rea podem se
transformar em projetos mal-sucedidos.
Quadro 5.2 Problemas da terceirizao, publicado em 28/06/2005 em
http://www.softex.br/cgi/cgilua.exe/sys/start.htm?sid=4.
224
Sntese
Nesta unidade voc estudou os princpios da estruturao
de uma equipe de projeto. O conceito fundamental, muitas
vezes repetido e exemplicado, o do trabalho cooperativo. A
cooperao criativa e sincera entre os membros de uma equipe de
projetos o passo decisivo para o seu sucesso. E vimos tambm
que, para isso, de vital importncia o papel do gestor como
lder.
Inicialmente foram apresentados os quatro passos que se do na
formao das equipes de projeto: o perodo inicial da formao,
seguido muitas vezes de um ambiente turbulento, quando os
primeiros subgrupos se formam e h distncias a romper, depois
o perodo onde as normas de trabalho se impem e a liderana
institui uma normalizao, seguido ento do perodo de
desempenho cooperativo e onde, de fato, os resultados comeam
a aparecer.
Depois vimos que os pers so muito variados, e tambm so
dinmicos, ou seja, as pessoas tm comportamentos diferentes
conforme o meio em que esto. Para dividir as tarefas e encontrar
os pers corretamente, uma tcnica interessante preparar uma
matriz de competncias, conforme vimos exemplo na gura 5.2.
Com essa matriz possvel estudar diferentes composies
de pessoas na equipe. Ajustes de competncias tcnicas e de
habilidades de trabalho podem ser feitas, dessa forma, por meio
de treinamentos. Mas importante destacar que o treinamento
ser ecaz se as pessoas da equipe tm uma educao de base
adequada. Nisto que se diferencia o treinamento da educao.
225
Unidade 5
Para organizar o grupo de trabalho em diferentes tarefas, cinco
modelos estruturais foram apresentados:
1. Estruturas diferenciadas e exclusivas, com pessoas dedicadas
exclusivamente ao projeto;
2. Estruturas hbridas, onde h uma composio de dedicaes
exclusivas e outras parciais;
3. Estruturas matriciais, em que pessoas de uma organizao
trabalham em difentes projetos simultaneamente, conforme
suas habilidades, sendo que o gestor do projeto o
responsvel por administrar essa locao e os resultados
parciais,
4. Estruturas modulares, formadas por pequenos grupos
dedicados a sub-projetos, os quais podem colaborar para um
projeto ou vrios, e;
5. Estruturas horizontais, geralmente em projetos pequenos e
que envolvem pares de especialistas, os quais no tm um
comando central.
Esses modelos podem ser ajustados caso a caso, e dependero
da experincia e liderana do gestor para que obtenham o
desempenho desejado.
Por m, esta unidade tratou da terceirizao como uma variao
a mais dos modelos estruturais anteriores. A terceirizao vem se
expandindo em todas as atividades produtivas e alcana tambm
os processos de trabalho relacionados a projetos. No caso do
desenvolvimento de tecnologias da informao h apreenso, pois
a terceirizao tem deslocado os servios para regies remotas,
que tm preocupado tanto no sentido da perda de empregos
quanto na perda do controle do conhecimento como do prprio
andamento do projeto.
Na prxima unidade, voc ver o dia-a-dia do projeto
durante sua execuo, seus problemas de rotina e
os aspectos importantes da liderana no sucesso da
empreitada. At l!
226
1) Quais so as quatro fases de estruturao da equipe e, em sua
opinio, qual a mais problemtica? Por que a fase escolhida a mais
problemtica?
2) Como uma matriz de perfs e competncia pode ajudar na estruturao
de uma equipe?
3) Em sua opinio, qual tipo de estrutura de equipe melhor se ajusta
ao desenvolvimento de software em uma pequena empresa, cujos
projetos so iniciados apenas sob a demanda do cliente?
227
Unidade 5
4) Qual o modelo de estrutura representado na fgura abaixo? Qual o seu
grande problema?
Projeto 2
Projeto 3
Projeto n
Projeto 1
Gerncia geral
da empresa
rea
administrativa
rea
financeira
Engenharia
rea
comercial
rea
tcnica 1
rea
tcnica n
5) Em que tipo de estrutura possvel uma grande troca de
conhecimentos, sendo que as pessoas trabalham entre pares? Qual a
vantagem desse tipo de estrutura na indstria de softwares?
228
6) Como voc avalia os riscos da terceirizao na rea de software?
Saiba mais
Veja em www.teses.usp.br a dissertao de mestrado de Leandro
Patah, Alinhamento estratgico de estrutura organizacional de
projetos: uma anlise de mltiplos casos. Este trabalho foca em
diversos tipos de estrutura, especialmente a matricial, e trar
conhecimentos aprofundados sobre o tema.
Entre novamente no site da SOFTEX (www.softex.br) e veja
os estudos sobre terceirizao, bem como o estudo comparativo
entre as indstrias de software no Brasil, China e ndia. H
exemplos de como a terceirizao alavancou a indstria indiana,
por exemplo.
6
UNIDADE 6
Executando o projeto
Compreender aspectos do incio de um projeto e
como o seu bom entendimento permite a gerncia e o
controle efcaz da qualidade.
Perceber as diferenas bsicas entre lderes e gestores.

Estudar tcnicas e prticas para controle de prazos e
recursos, encontros de trabalho e gesto de confitos.
Verifcar as vrias subdivises e etapas intermedirias

que um projeto de sucesso demanda.
Sees de estudo
Seo 1 Preparao e incio dos trabalhos.
Seo 2 Liderana versus gesto.
Seo 3 Tomada de decises.
Seo 4 Motivao e comunicao.
Seo 5 Reunies.
Seo 6 Gerenciando qualidade, tempo e recursos.
Seo 7 Gesto de confitos.
Seo 8 Simulao, testes e validao.
230
Tendo uma srie de ferramentas e prticas de planejamento
em mos, estudadas anteriormente, chegamos ao dia-a-dia
de trabalho do projeto. Neste momento teremos que colocar
em prtica o planejamento, e novas diculdades certamente
surgiro. Esta unidade apresenta questes prticas relacionadas
com o incio do projeto, com os possveis conitos advindos do
choque entre pessoas da equipe com variados pers, bem como
as caractersticas do gestor do projeto para tratar tais conitos e
diculdades.
Em especial debatido o perl do gestor quando comparado
com o do lder, assunto que vem tomando parte de muitos
debates sobre desenvolvimento tecnolgico e inovao j que tais
diferenas de pers podem afetar positiva ou negativamente o
desenvolvimento do projeto e mesmo dicultar a administrao
de conitos, por exemplo.
Tambm nesta unidade tratado o tema das simulaes e testes
de reviso contnua, assunto que foi abordado anteriormente
quando se defendeu a necessidade de segmentar o projeto em
pequenas etapas e atividades, facilitando a busca, durante a fase
de desenvolvimento do projeto, de conquistas parciais. Tais
conquistas parciais que garantem, como veremos aqui, o
resultado positivo esperado do projeto. Bom estudo!
SEO 1 Preparao e incio dos trabalhos
At agora j falamos muito sobre planejamento, sobre estimativas
de recursos, anlise de riscos, formao de equipes de trabalho
e muitas outras coisas, mas chegou a hora de colocar a mo na
massa, ou seja, de fazer as coisas acontecerem. s vezes pode
parecer que se perde muito tempo com planejamento, que o certo
ir direto ao assunto e j sair produzindo. Esse o risco que
correm todos os inexperientes (e muitos experientes tambm).
Na realidade, a produo em projetos uma decorrncia do
planejamento, pois como j foi dito vrias vezes, o projeto um
trabalho com data marcada para acabar, enquanto as atividades
231
Unidade 6
de produo de rotina no tm tal nalidade e as pessoas entram
no trabalho de uma empresa ou indstria, por exemplo, quando
as coisas j esto acontecendo.
Outro fator importante e, por isso, aparentemente
tanta preparao, que em um projeto preciso sempre
ter a viso do conjunto e no apenas das partes.
Tendo realizado tal planejamento, previsto os recursos
disponveis e tendo os objetivos claros e o contrato
estabelecido junto ao cliente, hora de comearmos os
trabalhos.
Para preparar e comear o projeto interessante voc
considerar as seguintes observaes:
muitas pessoas imaginam que trabalhar em um projeto
comear imediatamente a programar, ou a perfurar, ou a
martelar, ou seja l o que for que parea demandar muito
esforo. Dessa forma, a energia despendida logo no comeo
e, na maioria das vezes por no se saber onde se quer chegar,
rapidamente tudo esvaece e o projeto perde, ento, o sentido;
trabalhar em um projeto no despender um enorme
esforo em direo a um objetivo desconhecido,
para aparentar que o suor faz o trabalho. Projeto,
necessariamente, exige reexo;
muitos pensam que algum tem que dar as ordens e que esse
algum que tem todo o projeto na cabea, bastando seguir
seus passos. Provavelmente h um algum responsvel e lder
num projeto, no entanto esse responsvel certamente no tem o
projeto todo na cabea;
no existe um ser sagrado que sabe tudo sobre o
trabalho a ser realizado, e o responsvel depende
inteiramente da sua equipe;
como o projeto uma atividade inerentemente coletiva,
fundamental que haja o esprito do trabalho cooperativo;
no h como fazer projetos com algum nvel de
complexidade sem a participao criativa e positiva
de vrias pessoas. vi recentemente um grupo de
projetistas que inventou uma espcie de jogo em rede

232
de computadores, uma espcie de gincana, em que eles
brincavam de colocar partes do projeto num diretrio
comum, e a vitria era cumprir tal demanda num prazo
cada vez mais curto era uma brincadeira que fazia do
projeto uma diverso em forma de game!
O incio de um projeto deve acontecer com uma reunio. Nessa
reunio o escopo do projeto deve ser exposto com a maior
clareza possvel, os detalhes devem ser discutidos at a exausto,
o plano de produo deve ser detalhado, as tarefas divididas
e as responsabilidades atribudas. neste momento que o
uxograma geral (lembra do algoritmo do projeto?) deve ser
apresentado, discutido e suas cpias distribudas. A comunicao
dos procedimentos, j discutidos aqui, deve ser feita a partir dessa
reunio de contato inicial.
Geralmente as reunies so muito mal vistas. Por qu? Algumas
pessoas pensam que reunies so chatas, que no dizem nada,
que o chefe senta na extremidade da mesa apenas para mandar.
Essa uma viso de reunies normalmente veiculadas em
lmes e novelas. Podemos imit-las e ento ter
pssimas reunies ou ento optarmos em seguir
um caminho muito mais objetivo e perceber
que reunies so timos momentos para fazer
o trabalho, de fato, andar rumo ao sucesso. As
reunies sero interessantes se:
tiverem uma pauta bem denida;
a pauta no for extensa;
os assuntos forem claros e de conhecimento dos
presentes;
o horrio de comeo e m forem bem denidos;
forem sucientemente breves; (as CPIs do governo so
longas e repetitivas, mas no so reunies, percebe?)
houver um coordenador, capaz de gerenciar as falas entre
os diversos presentes;
houver um lder, capaz de decidir quando for necessria
uma deciso.
Se houver a necessidade, consulte

novamente a Unidade 3, Seo 3:
Algoritmo do projeto.
233
Unidade 6
H empresas que fazem tantas reunies que as algumas pessoas
chegam a pensar que trabalhar participar de reunies e, outras
pessoas pensam que a pior coisa do mundo uma reunio. Nem
uma nem outra est correta. Provavelmente, nestas empresas as
reunies esto sendo mal conduzidas.
Depois da fase de reunies iniciais o projeto tem, ento, seu
comeo. Os grupos de trabalho esto com suas atividades
denidas, prazos estabelecidos e resultados por alcanar. Resta
cumprir as etapas, j estabelecidas no Grco de Gantt do
projeto. Se o planejamento foi bem feito, h uma denio bem
clara de objetivos e atividades e, possivelmente, com sub-etapas
de prazos curtos.
A Microsoft, por exemplo, trabalha com uma
orientao designada como zero-defeito com
prazos curtos de entregas intermedirias como
objetivo de maior desenvolvimento (MSF, 1998). Assim
que comeam os trabalhos de desenvolvimento,
a mentalidade de uma entrega a cada dia
estabelecida entre todos os membros da equipe. Com
isso, h a sensao comum de que os projetos devem
andar e que devem estar no prazo.
Na Microsoft o gerente de projeto Chris Peters
considera que a atividade de um projetista no
simplesmente colaborar no projeto para que ele
chegue ao resultado fnal. Ele considera que cada
projetista, ao comear seu trabalho, deve estar
pensando em entregar. Leia o seguinte pargrafo e
pense nisso:
Todos [os projetistas] tm o mesmo trabalho. Eles
tm exatamente a mesma descrio de trabalho. E esta
entregar (embarcar) produtos. Seu trabalho no
escrever cdigo. Seu trabalho no testar. Seu trabalho
no escrever especifcaes. Seu trabalho entregar
produtos. Isto o que um grupo de desenvolvimento
faz. Seu papel como um desenvolvedor ou como um
testador secundrio. No estamos dizendo que no so
importantes mas so secundrios para seu trabalho
real, o qual entregar um produto. Quando voc acorda
cedo de manh e vem para seu trabalho, voc diz,
Qual o focoestamos tentando entregar ou estamos
tentando escrever cdigo? A resposta : ns estamos
tentando entregar. Voc no est tentando escrever
cdigo. (MSF, 1998)
Consulte unidade 4, seo 2.
234
Este pargrafo elucida sobre a atitude esperada de um projetista
ao participar de um grupo de trabalho. com este foco que o
trabalho deve ser iniciado.
SEO 2 Liderana versus gesto
Conforme voc estudou anteriormente na unidade
5, foram ressaltadas diferenas entre as atitudes da
liderana e da gesto, sendo dados, por brincadeira, os
exemplos do gestor-rinoceronte, gestor-cobra e gestor-
raposa. Agora hora de falar um pouco mais srio
sobre o assunto.
Estamos muito mais acostumados a trabalhar com
gestores, ou gerentes, do que com lderes. A funo
da gerncia tem sido muitas vezes confundida com uma espcie
de atuao por cobrana e controle que coloca os gerentes numa
condio de animosidade com seu grupo de gerenciados. Ou seja,
aqueles que cam submetidos ao gerente se sentem diminudos
e perdem, geralmente, a motivao do trabalho criativo. Muitas
vezes isso, de fato, acontece. Voc, com certeza, deve conhecer
casos ou mesmo gerentes que se sentem muito satisfeitos em
simplesmente mandar.
H os gestores que tm ojeriza por liderana, pois vem na gura
do lder uma espcie de ser sagrado que detm a verdade.
possvel que essa imagem falsa tenha origem de duas fontes:
a primeira a mitologia criada sobre lderes carismticos, que
levam as pessoas a fazer coisas que normalmente no fariam; a
segunda que esse tipo de gestor no consegue cumprir funes
muito mais simples, essas sim dos lderes, como tomar decises,
se arriscar mais e apoiar verdadeiramente cada um dos membros
de sua equipe. A ojeriza acaba se dando por no conseguirem
cumprir nenhum dos dois papis. No assumem a gura
carismtica por no concordarem ou no se adaptarem a ela.
235
Unidade 6
Tambm acabam no assumindo a funo de liderana objetiva
e criativa por no terem a habilidade de relacionamento humano
necessria. Com esse distanciamento, acabam manifestando uma
ojeriza generalizante, denegrindo todos os tipos de liderana.
No entendimento de Page-Jones (1990) so as seguintes as
qualidades de um gerente de projetos:
integridade pessoal,
sensibilidade,
capacidade de estabelecer objetivos,
capacidade de cumprir objetivos,
tenacidade,
capacidade de inspirar,
disposio de servir,
coragem de delegar,
competncia tcnica,
capacidade para comunicar a realidade,
capacidade de pensar e ser inovador,
coragem de tomar decises.
Estas caractersticas cabem perfeitamente para os lderes,
especialmente as qualidades de inspirar, ser inovador e ter
coragem de tomar decises. Nem sempre os gerentes so
inspiradores, inovadores e decisores e, mesmo assim, so timos
gerentes, pois so capazes de coordenar os prazos e distribuir
tarefas adequadamente e os membros da equipe conam nele
para conduzir o trabalho at o nal.
Em seu livro sobre gerenciamento de projetos, Valeriano (1998)
cita Denis Donaire, este considera que os atributos desejveis em
um gerente esto divididos em trs grandes reas: conhecimentos,
habilidades e atitudes. O detalhamento dessa diviso o
seguinte:

236
a) Conhecimentos desejveis
Em relao ao conhecimento organizacional o gestor
necessita:
ter conhecimento do sistema administrativo e
nanceiro da organizao onde trabalha;
conhecer o funcionamento do sistema de RH
(recursos humanos) e como se do as relaes
jurdicas com relao aos funcionrios e
terceirizados da empresa;
prticas, polticas e valores, que a percepo
clara de perceber como funciona a organizao
em suas prticas no dia-a-dia, a poltica interna
das relaes e por quais valores se orientam
aqueles que trabalham nela;
ter conscincia do custo e das implicaes das
decises tcnicas; o que implica reconhecer as
relaes entre as aes e o que isso signica no
tocante aos gastos no projeto e para a empresa;
ter conhecimento das atividades econmicas
da organizao, dos seus produtos, misses
e mercados ou clientes da organizao, que
signica um conhecimento profundo das
atividades econmicas da organizao.
Em relao ao conhecimento tcnico, o gestor necessita:
conhecer reas correlatas especializao de
que trata o projeto, com uma viso geral das
competncias tecnolgicas;
ter competncia tcnica em pelo menos uma rea
de especializao;
ter domnio de mtodos de pesquisa, que
permitam relacionar os diversos membros da
equipe em um desenvolvimento equilibrado e
voltado a resultados.
a)
b)
c)
d)
e)
a)
b)
c)
237
Unidade 6
b) Habilidades desejveis
Em relao s habilidades de comando o gestor
necessita:
ter a capacidade (e isso deve ser perceptvel)
de planejamento, organizao e controle das
atividades do projeto;
desenvolver sua capacidade de liderana (pois
consideramos que a capacidade de liderar inata
a todas as pessoas);
capacidade de auto-anlise, ou seja,
constantemente fazer a auto-crtica das
suas atitudes, dos seus conhecimentos e das
necessidades de aprimoramento tcnico;
capacidade de alocao de recursos que advm
do conhecimento dos recursos disponveis
e daqueles que sero necessrios buscar no
desenvolvimento do projeto;
capacidade de gerar conana no superior e
isso se d pela integridade e pela segurana ao
trabalhar orientado a resultados;
perceber e escolher o estilo de liderana
adequado a equipe de trabalho, o tipo de projeto
e do cliente contratante, seja externo ou um
superior da empresa;
habilidade de tomada de decises, condio
essencial numa funo de comando (o gerente
que no toma decises considerado fraco por
sua equipe, o que desmotiva o grupo).
Outras habilidades:
trabalhar em equipe, habilidade esta que j
comentamos muitas vezes ao longo deste livro e
que est relacionada capacidade de cooperar e
gerenciar conitos;
a)
b)
c)
d)
e)
f)
g)
a)
238
criatividade, especialmente na soluo de
problemas inesperados e distantes daqueles que
foram avaliados como riscos inerentes ao projeto,
sendo que a criatividade tambm est relacionada
habilidade de manter dilogos constantes
com os membros da equipe e com a inspirao
motivacional, gerando idias diferentes das
convencionais;
capacidade de redigir com clareza, preciso e
conciso, habilidades relacionadas capacidade
de se comunicar, necessria para o andamento do
projeto de forma coordenada e racional;
relacionamento pessoal, habilidade relacionada
ao dia-a-dia do trabalho em equipe, s atitudes
de educao na convivncia (infelizmente no
nada difcil encontrarmos gerentes que se
dirigem aos membros de sua equipe aos berros).
Sobre o relacionamento pessoal temos um caso
interessante: disse certa vez numa reunio de
gerentes que eu no aceitaria trabalhar numa empresa
onde os chefes se acham no direito de humilhar seus
funcionrios, e os resultados foram dois: primeiro,
fui estigmatizado por tais gerentes e sado da
empresa um tempo depois; segundo, a empresa
surpreendentemente entrou na lista da revista Exame
como uma das melhores para se trabalhar (!!), e at
hoje no entendo se os funcionrios mentem nas
entrevistas ou se tais listas so arranjadas.
c) Atitudes
Posicionamento em relao a aspectos internos e
externos:
interesse por questes administrativas, que
implicam conhecer e se posicionar em relao
aos diversos aspectos do trabalho, na empresa e
no projeto, mesmo que no sejam suas funes
as atividades executivas da administrao
empresarial;
b)
c)
d)
a)
239
Unidade 6
disciplina de trabalho, que envolve ao mesmo
tempo a dedicao produtiva diria ao prprio
trabalho e, na sua condio de gestor, do
exemplo aos membros da equipe de que a
disciplina a geradora da produo e do
resultado;
entrosamento com pessoal externo organizao,
pois isso essencial para realizar as interfaces de
negociao de requisitos, solicitao de recursos
extraordinrios, vericao de pendncias,
soluo de conitos diversos etc.;
ambio prossional, que necessria para o
crescimento tanto do indivduo quanto do seu
grupo de projeto; ambiente sem ambio de
crescimento e sucesso desmotivador.
Estratgias de ao:
hbito de comear o ataque ao problema pela
reviso da literatura, pela reviso dos projetos da
mesma rea que o antecederam, seja na empresa
ou outros locais e, principalmente, a capacidade
de exercitar sempre uma viso geral do problema
e do ambiente de negcios onde o projeto est
envolvido;
hbito de leitura sistemtica de textos tcnicos,
pois com isso h atualizao constante em
relao s inovaes tecnolgicas e gerao de
novas idias, ponto fundamental para lanar
novos projetos, como os discutidos na unidade 1
deste livro.
Essas so consideraes gerais sobre gerncia, mas o que
defendemos como principal para o sucesso de um projeto a
atitude da liderana. Nos tpicos citados anteriormente, a maioria
das atribuies que voc estudou serve tanto para gerentes quanto
para lderes enquanto outras so caractersticas especcas da
liderana. preciso que voc entenda que as caractersticas
de lder so inerentes a todos ns mas, em geral, no so
estimuladas nos indivduos em uma sociedade que procura,
b)
c)
d)
a)
b)
240
de certa maneira, uniformizar procedimentos e atitudes. Tal
uniformizao (ou mediocrizao) pode ser considerada uma
doena que afeta o nosso desenvolvimento como indivduos e, por
conseqncia, como sociedade. No o caso de dizer que todos
devem ser lderes em todas as atividades, mas sim, que saibamos
nos posicionar sempre em que tal comportamento de liderana se
faa necessrio. A liderana implica tambm o discernimento da
compreenso do momento em que precisamos ser parte de um
grupo onde j h um lder no qual devemos depositar conana
no trabalho.
Stephen Covey (2005) criou uma tabela que relaciona diferenas
entre liderana e gerncia e, no quadro abaixo, apresento uma
adaptao de tal tabela de acordo com os conceitos desenvolvidos
para este livro:
Quadro 6.1. Diferenas entre Liderana e Gerncia, adaptado de Covey (2005).
LIDERANA GERNCIA
Interessado nas pessoas Interessado nas coisas
Trabalha na espontaneidade Trabalha com a estrutura
Liberao e fortalecimento das idias Controle das atividades e das idias
Eccia Ecincia
Prefere planejar e programar Prefere trabalhar sob um programa
Considera gasto como investimento Considera gasto como despesa
Trabalha baseado em princpios Trabalha baseado em tcnicas
Procura transformao Procura transao
Poder centrado em princpios Poder centrado em utilidade
Procura resolver por discernimento Procura resolver por medio
Fazer a coisa certa Fazer certo as coisas
Resolve baseado numa direo Resolve baseado em rapidez
Pensa numa linha superior Pensa em resultados
Tem propsitos Tem mtodos
Decide baseado em princpios Decide baseado em prticas
Busca algo acima das coisas Busca algo dentro dos sistemas
Para o lder a pergunta : a escada est
junto da parede certa?
Para o gestor o que importa : subir
rapidamente a escada
241
Unidade 6
Especicamente sobre lideranas, Christenson (2004) avana
ainda mais sobre seus conceitos dividindo-as em quatro diferentes
tipos, descritas abaixo:
a que considera os indivduos, ou seja, capaz de
estimular as pessoas de sua equipe e seus seguidores a
terem uma viso nova de seu prprio trabalho;
a que estimula intelectualmente, gerando um
alinhamento positivo das idias das pessoas em relao
organizao e ao projeto;
a que inuencia os ideais, ou seja, estimula seus colegas
de trabalho a alcanarem altos nveis de habilidade;
a que motiva inspiraes, levando seu grupo de colegas
a olharem alm do interesse prprio e em direo ao
benefcio de todo o time.
Bem, no necessrio fazer um juzo de valor sobre qual o
melhor, lder ou gestor, pois os papis dependero da atividade,
do tamanho do problema ou do tipo do projeto. De certa forma,
os dois papis devem estar combinados (e no agir como o gestor
que execrava lderes em sua organizao).
Comeado o projeto, tendo um planejamento claro das atividades
(veja tambm as unidades anteriores com os Diagramas de Gantt
e as ferramentas PERT/CPM), consideradas as funes de
liderana e de gesto, passa-se agora aos detalhes do dia-a-dia
do projeto. Um dos pontos nevrlgicos de qualquer projeto a
tomada de deciso, assunto da prxima seo.
1.
2.
3.
4.
242
SEO 3 Tomada de decises
Hoje uma grande parte dos textos sobre administrao
empresarial dirige seu olhar para o problema da tomada de
deciso.
Decidir signifca escolher uma opo entre vrias
e, com isso, h sempre o risco da escolha no recair
sobre a melhor opo.
Um campeo de xadrez decide o melhor movimento a cada
vez e seu exerccio de escolha renovado a cada nova jogada.
Aquele que cometer mais decises erradas, perder o jogo. Assim
tambm o goleiro na hora do pnalti: a deciso do seu movimento
poder implicar ou no a defesa do gol. Sabe-se que os grandes
craques de qualquer esporte, especialmente os coletivos, aliam s
habilidades pessoais e de relacionamento, a capacidade de antever
os movimentos do jogo e tomar a deciso que levar ao gol, ao
ponto, enm, ao sucesso.
Que milagre poderia ser esse, capaz de levar a uma
deciso certa no momento certo?
Alguns traos so comuns entre esses tomadores de deciso:
experincia anterior;
treino em decidir e executar (as jogadas, os chutes);
o exerccio da viso ampla (do jogo);
coragem de, aps um erro, calibrar os movimentos para
tentar de novo at acertar.
Quem ama os esportes j viu algum desses momentos mgicos
quando o atleta resolve arriscar um difcil movimento, muitas
vezes num momento crtico onde a chance da derrota era enorme
e, cheio de conana, decidir uma partida.

243
Unidade 6
Um jogo coletivo como um projeto: h um
objetivo a ser atingido, o prazo est estabelecido
e s possvel vencer se a equipe estiver unida e
entusiasmada.
Para Page-Jones (1990) a tomada de deciso durante um projeto
envolve quatro passos:
identicar possveis modos de ao e chegar a um
entendimento comum do que cada opo signica;
identicar as ramicaes de cada opo, incluindo
vantagens e desvantagens;
discutir e avaliar cada uma dessas ramicaes;
escolher o modo de ao mais vantajoso e partir para ele.
Como vemos, em um projeto, h a necessidade da constante
avaliao das opes possveis e disponveis e isso combinado
experincia prvia do decisor, denir as prximas aes.
SEO 4 Motivao e comunicao
Em um projeto, outro fator importante para o bom
andamento do trabalho, a clara comunicao para
toda a equipe e interessados, sobre os objetivos,
os resultados a serem alcanados e sobre como
se daro todas as pequenas divises e etapas at
chegar aos resultados esperados. Nesse sentido,
um planejamento utilizando o Grco de Gantt
parece ser fundamental, uma vez que ele utiliza o
grco de barras ao longo de tempo e conhecido de todos. A
comunicao, seja inicial ou a cada etapa do projeto, deve se dar
sobre tal grco e deve ser acompanhada da marcao sobre o j
realizado e sobre o que falta realizar.

244
A comunicao clara das atividades deve ser feita a cada momento
importante, tal como incios e encerramentos de etapas, mas o dia-
a-dia de cada etapa exige entusiasmo e motivao por continuar.
Infelizmente, muitos entre ns sofrem de um mal moderno
conhecido como depresso que, em geral, os impede de continuar.
Como evitar e como superar tal mal?
Parece que uma das formas de felicidade do ser humano o
sentir-se til, para si mesmo e para seu meio social, assim como
tambm a constante necessidade de superao de desaos. Assim,
primar por uma comunicao que motive e que entusiasme o
indivduo mister para se alcanar resultados positivos.
Em uma pesquisa sobre a motivao para o trabalho, Page-
Jones (1990) cita a obra de Maslow para denir as necessidades
bsicas dos seres humanos e, como tais necessidades, precisam
ser satisfeitas para que se sintam motivados. O quadro abaixo
representa tais necessidades.
Quadro 6.2. Necessidades bsicas e motivao (Page-Jones, 1990).
Necessidades Nveis Exemplos
BSICAS
Fisiolgicas
segurana
sociais
Fome, sono, sede
no emprego, tranqilidade
pertencer a grupo, famlia, amigos
DE CRESCIMENTO
Estima
auto-realizao
Sensao do trabalho bem feito
desao vencido, desenvolvimento
Pelo que voc pode observar no quadro, enquanto as necessidades
bsicas parecem satisfeitas em boa parte da sociedade atual
(salvo nas regies mais pobres e de maior desigualdade no pas
e no mundo), o mesmo j no se pode dizer das necessidades de
crescimento. Mesmo nos pases mais ricos e de maior distribuio
de renda, os nveis de auto-estima e auto-realizao parecem
no estar ainda bem resolvidos. Neste ponto voltamos s sees
anteriores para perceber que so motivacionais as atitudes dos
lderes, que se posicionam frente a desaos e que sabem valorizar
o trabalho e o esforo de todos. Gestores sem tais habilidades,
sem dvida, faro projetos fracassarem.
245
Unidade 6
SEO 5 Reunies
Reunies... isso no lhe parece um assunto bastante
pueril para um livro sobre gesto de projetos?
De fato seria, caso as reunies no tivessem assumido
um papel de tortura e de desgaste para muito de ns.
H empresas, especialmente as pblicas, ou alguns
partidos e agremiaes polticas, que parecem se
movimentar apenas por meio de reunies. Por causa
disso, esses encontros de trabalho passaram a ser
encarados por muitas pessoas como inteis, mas,
certamente, no o so.
Atribuo grande importncia s reunies de projeto,
pois so momentos especiais de comunicao e deciso.
So nesses momentos que os planos, as discusses e os rumos
do trabalho so colocados e precisam ser enfrentados como
ambientes coletivos para o desenvolvimento do prprio projeto.
Para que uma reunio venha a ser bem-sucedida, Page-Jones
(1990) coloca as seguintes sugestes de ao:
1. Antes da reunio:
o grupo de trabalho ou o gestor/lder, deve denir um
lugar conveniente para a reunio;
os participantes devem ser selecionados conforme o
assunto em pauta e no simplesmente reunir todos do
grupo;
antes de marcar uma agenda, importante vericar se
todos podem, de fato, participar;
se h consenso sobre uma data e horrio, fazer ento o
aviso com antecedncia;
a pauta de reunio deve ser bem denida e levada aos
participantes com antecedncia;
o nmero de itens em pauta deve ser restrito, evitando
disperso e supercialidade.

246
2. Durante a reunio:
deve ser designado um moderador capaz de organizar/
gerenciar as falas e questes propostas pelos indivduos
do grupo;
tambm deve ser designado um secretrio que anote os
pontos principais discutidos, bem como, as resolues
adotadas, criando ento uma ata;
o grupo deve prender-se pauta, evitando entrar em
assuntos diversos;
denir regras de procedimento conforme o objetivo dos
itens de pauta (planejamento, comunicao, resoluo de
problemas, deciso).
3. Depois da reunio:
todos os itens de ao devem ser anotados e devem ser
atribudas responsabilidades por item de ao;
distribuir a ata da reunio.
Tenho certeza que voc, ao ler essas linhas, estar pensando
em reunies em que j tomou parte e que no se seguiram tais
recomendaes. Aquelas que tiveram algum capaz de conduzir
as conversas talvez, tenham tido bons resultados, porm, a
maioria, deve ter sido enfadonha e sem resultados, sem contar
com a sensao do tempo perdido.
Para o projeto de desenvolvimento de uma inovao tecnolgica,
um software, um novo produto, haver, com certeza, vrias
reunies e caber a cada um de ns interferir para garantir o seu
bom andamento. Se a reunio no tiver pauta, solicite uma. Se a
hora de acabar no estiver denida, pergunte qual .

247
Unidade 6
SEO 6 Gerenciando qualidade, tempo e recursos
Gerenciar a qualidade buscar a ausncia de erros. Muitas
vezes, no prestamos ateno aos erros e criamos metas de
qualidade que podem ser bem baixas para nossa vida social,
apesar de parecerem excelentes para a vida prossional. Leia
com ateno o seguinte texto:
As pessoas foram condicionadas a acreditar
que o erro inevitvel. No apenas aceitamos
o erro, ns o prevemos. Quando projetamos
circuitos, programamos um computador, fazemos um
planejamento, soldamos conexes, datilografamos
uma carta, fazemos um oramento, ou montamos
componentes, no nos preocupamos se cometemos alguns
erros; e a gerncia prev o acontecimento desses erros.
Achamos que os seres humanos possuem um fator de erro
integrado a eles.
Entretanto, no mantemos o mesmo padro, quando
a coisa passa para o campo da vida pessoal. Se
mantivssemos, aceitaramos com naturalidade receber
troco errado (a menos); aceitaramos que as enfermeiras
deixassem cair no cho um percentual de recm-nascidos;
acharamos natural entrar na casa errada de vez em
quando. Como indivduos, no toleramos esses erros.
Portanto, temos dois pesos e duas medidas: um para ns
e um para a empresa.
A razo para isso que a famlia cria para ns padres de
desempenho bem mais altos do que as empresas...
Muitas empresas gastam 10, 15 ou at mesmo 20% do
faturamento de suas vendas com sucata, retrabalho,
garantias, consertos, testes e inspees. Os erros que
produzem esse desperdcio so causados diretamente
pelo pessoal da empresa, tanto pelos funcionrios quanto
pela administrao. Para eliminar esse desperdcio,
para melhorar o funcionamento e aumentar a eccia,
precisamos nos concentrar na preveno dos defeitos e
dos erros que nos assolam. O erro que prevenido no
precisa de consertos, exames ou explicaes. O primeiro
passo adotar uma atitude de preveno de defeitos. Essa
atitude chamada, simbolicamente, de Defeito-Zero.
Texto de Philip Crosby, citado por Tom DeMarco, (1991)
248
Como voc pode observar, o controle da qualidade passa
antes por um conceito do que o defeito e at onde estamos
dispostos a aceit-lo. Entender o que defeito nos ajuda a ter
distncia dele, de um ponto de vista conceitual. Muitas empresas
buscam entender defeitos na produo a partir de ndices de
erro encontrados numa linha de fabricao, na quantidade de
bugs do sistema, ou diversos outros indicadores preparados
para apontar uma no-conformidade. Ora, defeito no
necessariamente um ndice, mas sim a atitude de aceitar a sua
existncia ou no nos nossos procedimentos de rotina. Tanto
que DeMarco (1991), para projetos de software, tenta extinguir a
palavra bug e substitu-la por defeito, pois considera que isso
traz um impacto maior no processo de qualidade.
Conforme o artigo Managing project quality, o
gerenciamento da qualidade em projetos passa por dois momentos
crticos: a abertura do trabalho e seu encerramento. Os pontos
fundamentais a serem tratados nesses dois momentos so:
1. Fase inicial do projeto
Identicao dos objetivos do projeto;
alinhamento estratgico com a empresa e com o objetivo
do cliente;
alinhamento operacional com as capacidades de produo
da estrutura disponvel;
seleo dos recursos necessrios;
contrato detalhado do projeto descrevendo:
o porqu do projeto (onde se apresentam as
justicativas do trabalho e as causas que o
inspiraram);
o qu? (onde o escopo detalhado do trabalho
deve ser colocado, denindo claramente os
resultados esperados);
a)
b)
Kloppeborg & Petrick, 2004.
249
Unidade 6
quando? (em que apresentado o cronograma
geral do trabalho, denindo datas de incio e
m, bem como de interao entre equipe de
projetos e cliente/contratante)
quanto custa? (especicando o valor global do
projeto e medies nanceiras parciais, quando
necessrio)
Quais os riscos? (descrevendo condicionantes
e possveis problemas, capazes de alterar o
andamento do projeto, seja em prazos, seja em
custos)
como fazer? (apresentando os fatores crticos
do sucesso, o plano de comunicao, os
conhecimentos necessrios e os compromissos,
bem como outras aes que afetaro o processo
de produo do projeto).
2. Fase de encerramento
Denio e comunicao dos benefcios reais entregues
para o cliente;
expresso de reconhecimento aos participantes;
entregar prmios quando h mritos especiais (evitando
aquele tipo de mediocrizao que evita prmios para no
magoar os mais fracos).
Para o gerenciamento do tempo e dos recursos do projeto,
retorne aos uxogramas das guras 3.4 e 35, onde vemos a
necessidade de reviso constante do projeto. De posse de um
Diagrama de Gantt, com acompanhamento constante das etapas
realizadas, sabemos dos custos envolvidos e do tempo gasto a
cada momento. Fazendo a reviso da etapa (gura 3.5), possvel
replanejar o projeto e avaliar as condies de tempo restante e
recursos disponveis e ainda necessrios.
c)
d)
e)
f)

250
SEO 7 Gesto de conitos
Como no podia deixar de ser, o trabalho em equipe , quase
sempre, um ambiente de conitos. Isso acontece devido ao
dinamismo dos pensamentos e sentimentos humanos em
constante movimento e readequao. Segundo Valeriano (1998),
existem trs tipos de conitos:
o de ordem intrapessoal, que ocorre em cada indivduo,
consigo mesmo;
o interpessoal, que ocorre entre diferentes indivduos;
o intergrupos, que se d entre diferentes grupos.
Os conitos esto presentes em todos os ambientes sociais,
sejam de trabalho, familiar ou de comunidades em geral e,
obviamente, esto presentes tambm nas equipes de projeto
as quais, muitas vezes, esto reunidas por um pequeno
perodo de tempo e de forma muito intensa o que, via de
regra, potencializa as relaes.
Esses trs tipos de conito, intrapessoal, interpessoal
e intergrupos, esto presentes no decorrer dos projetos
segundo as seguintes causas potenciais (KEELING, 2002):
na denio de cronogramas, quando diferentes
interesses tendem a se contrapor na preparao das
agendas de trabalho;
na denio das prioridades;
na composio dos recursos humanos a trabalhar no
projeto, onde anidades pessoais tendem a se manifestar;
opinies tcnicas e de desempenho, durante o desenrolar
dos trabalhos;
procedimentos administrativos, geralmente um ponto
delicado de discusses entre a equipe do projeto e suas
liberdades de ao contra as amarras muitas vezes
necessrias da burocracia administrativa;
custos, na batalha inndvel por uns solicitando mais
dinheiro e outros negando;

251
Unidade 6
conitos de personalidade (sobre isso, nem h o que
comentar).
No quadro 6.3, abaixo, voc poder observar os conitos
em projetos oriundos de diferenas entre os indivduos e as
organizaes devido a seus diferentes objetivos. As pessoas
tm diversas necessidades e intenes que, muitas vezes, no
combinam ou se ajustam s das organizaes, mesmo que
tais organizaes, paradoxalmente, tenham sido construdas
por indivduos. O quadro apresenta uma tabela de exemplos,
adaptada de Valeriano (1998).
Quadro 6.3. Fontes de confitos, adaptada de Valeriano (1998).
Diferenas de objetivos como fonte de conitos
Indivduo / prossional Organizao / gerncia
Busca a inovao tecnolgica Busca o lucro
Quer autonomia de ao Quer integrar os prossionais na organizao
Quer livrar-se de regras e procedimentos Estabelece as regras e procedimentos
Quer autoridade baseada em mrito Autoridade baseada em hierarquia
Quer ser recompensado com base em seu
desempenho
Recompensa conforme o interesse da organizao
Quer ampla comunicao entre pares Bloqueia a comunicao interna
Busca otimizao do prprio trabalho Busca cumprimento de cronogramas e custos
Voc percebe como so diferentes os interesses e os
objetivos entre os diferentes grupos?
Em um projeto isso pode ser a fonte de um grande fracasso.
Assim, o gestor do projeto dever estar atento para saber
criar suciente blindagem entre os objetivos mais gerais da
organizao e os especcos do projeto que, por sua vez, devem
reetir sobre os indivduos que o compem. H organizaes
que trabalham orientadas por projetos, porm com a mentalidade
tradicional. No ser possvel vencer a contradio se no
houver um repensar de princpios. Organizaes envelhecidas,
nascidas ainda com a mentalidade dos princpios da revoluo
industrial, por exemplo, buscam renovao adotando prticas de

252
reengenharia e gesto por projetos e, normalmente, fracassam
logo em seguida sem saber o porqu. A orientao por projetos
uma orientao s pessoas, pois os projetos so movidos
pelas pessoas que compem as equipes de projetos. Assim, ser
necessria uma mentalidade direcionada ao relacionamento das
pessoas, e no a um conjunto de regras rgidas, protocoladas
por inmeros papis e procedimentos tcnicos, apropriados para
controlar mquinas, no indivduos. Sem tal mentalidade, os
projetos fracassam.
No entanto, mesmo que teoricamente saibamos onde esto as
supostas razes dos problemas, no estaremos, necessariamente
livres de conitos em um projeto, ento ser imprescindvel
administr-los. Para Valeriano (1998), h as seguintes
possibilidades de se administrar conitos num projeto:
por confronto ou soluo de problemas, quando as
partes envolvidas encaram o problema e buscam juntos
alternativas de soluo;
por comprometimento, que a busca de solues
alternativas, por parte do gerente do projeto, dando
algum grau de satisfao s partes envolvidas;
por acomodao, onde so enfatizadas as reas onde h
acordo, e esquecidas ou desprezadas as reas conitantes;
haver perda para o projeto se as reas de atrito eram, de
alguma forma, importantes para seu prosseguimento;
por prevalncia, que quando uma das partes prevalece
sobre a outra, numa relao ganha-perde;
por retirada, quando o conito deixado de lado,
sem soluo, o que pode causar um aprofundamento
da crise; muitas vezes a retirada usada como modo
de administrar a crise, considerando a retomada do
problema algum tempo depois, quando houve tempo
para melhor reexo.
Considerando tais possibilidades, ser funo do gestor escolher a
maneira de lidar com o conito. Com certeza a melhor forma de
administrar os conitos se d quando so percebidos o mais cedo
possvel. Como muitas doenas, se o conito for detectado no
incio mais fcil de curar e, se muito tarde, pode ser impossvel.
Por isso a ateno do gestor primordial.

253
Unidade 6
SEO 8 Simulao, testes e validao
Projetos podem ter resultados melhores se forem testados em
etapas, como resultados parciais e no aguardar at o nal
para ver o que deu certo e o que deu errado. Nesse sentido
importante para cada etapa e sub-diviso do projeto, buscar
conseguir um resultado palpvel. No caso da construo civil,
por exemplo, a nalizao da etapa das fundaes tem como
resultado as prprias fundaes, que podem ser testadas quanto
s caractersticas necessrias de resistncia e dimenses.
Qualquer problema a detectado pode ser resolvido
imediatamente, no sendo necessrio aguardar at
o fnal da obra para perceber que os alicerces no
suportaram o peso da construo seria um desastre!
Em projetos de software h a possibilidade de dividir
o sistema em pequenos mdulos, de tal forma que,
cada um tenha caractersticas especcas, denidas
inicialmente e que, atingi-las o objetivo a ser alcanado
no nal da etapa. Quanto maior a diviso de etapas e,
desta forma, de objetivos intermedirios, mais fcil ser
detectar possveis problemas e corrigi-los a tempo.
Um exemplo de diviso em etapas desse tipo, est
defnida nos pacotes dirios e nos prottipos de
prova do Microsoft Solutions Framework (MSF, 1998).
O objetivo chegar no fnal de cada dia com um
prottipo testvel. Esse prottipo compilado e deve
funcionar. S se passa para a etapa seguinte se o
pacote dirio anterior alcanou o sucesso.
Outra alternativa o uso de simuladores em projetos mais
complexos. Nesses casos, uma boa forma de testes prvios o
uso de simulaes computacionais que permitem uma viso do
produto, possibilitando fazer testes variados em um ambiente
computacional.
Veja sistemas e super-
sistemas no modelo UCP,
gura 2.10.
254
Um timo exemplo disso so os softwares de apoio
a projeto (CAD), que em mecnica e arquitetura
permitem visualizar e testar peas, mquinas e
ambientes. A deteco de falhas durante a simulao
permite enormes economias de tempo e dinheiro.
A validao do projeto feita por etapas e por simulaes, sendo
que no nal de cada etapa, e mesmo durante cada uma delas,
um processo de reviso contnua a melhor soluo de qualidade
para a continuidade de um projeto de sucesso. Segundo Page-
Jones (1990) h vrias revises a serem feitas no decorrer do
projeto, visando a testes contnuos e validao a cada etapa.
Especicamente sobre projetos, as revises e testes so:
reviso do escopo do projeto, que analisa constantemente
se o projeto est adequado s intenes e necessidades
dos usurios/clientes;
reviso de anlise, que verica se os problemas
anunciados no escopo esto sendo cuidados;
reviso do projeto, que verica se preenche as
especicaes, os padres de qualidade e se tem
condies de ser implementado;
reviso da programao e do sistema, que verica se os
resultados dos testes do prottipo esto adequados;
reviso da aceitao, que verica se aps os testes do
prottipo j possvel colocar o resultado do projeto em
produo;
reviso de produo, que verica se o sistema de
produo est adequado e se h oportunidades de
melhoria no produto;
reviso dos aspectos tcnicos do projeto;
reviso dos aspectos comerciais;
reviso ps-projeto, que busca aprender com os
resultados nais do projeto.

255
Unidade 6
Simulaes, revises e testes so atividades do dia-a-dia do
projeto e, como visto, interferem inclusive no seu nal e podem
se estender produo, atividade que j no pertencer ao escopo
do projeto em si, mas rotina. Quando chegar este momento,
teremos o nal do projeto, assunto da prxima unidade.
Sntese
Nesta unidade voc viu como se do os preparativos iniciais
do projeto e quais as atividades so importantes para que a
produo tenha incio acompanhando o planejamento denido
previamente. O incio do projeto dene tambm o padro de
qualidade que ser buscado em toda a fase de desenvolvimento,
especialmente se for implantada uma cultura de defeito-zero.
Como fundamento desta unidade est a comparao entre as
caractersticas do gestor e as do lder. Em unidades anteriores
esse tema j havia sido iniciado, mas aqui foi aprofundado e
percebeu-se que a liderana capaz de motivar a equipe, condio
essencial para que todos busquem um resultado comum, de forma
entusiasmada e ambicionando o sucesso coletivo. Com certeza
a gura do lder aqui denida no a do sujeito carismtico,
que conduz seguidores fanticos, mas sim a do que capaz
de criar ambientes de cooperao e de trabalho criativo. Para
isso, muitas vezes necessrio administrar conitos, mostrar
caminhos produtivos e tomar decises que denam rumos para o
projeto. Sem dvida, uma das caractersticas fundamentais nessas
atividades a de motivar e inspirar.
Por m, tomando por base a necessidade de, durante a fase de
planejamento, segmentar o projeto em pequenas tarefas e etapas,
a fase de desenvolvimento pressupe um conjunto de revises e
testes, que pode ser bem-sucedido se o projeto tiver resultados
claros a serem atingidos em cada uma de tais etapas. Casos
mais complexos podem exigir simuladores para facilitar essas
revises e anlises, e o exemplo de prottipos intermedirios foi
apresentado como soluo para busca de melhorias e conquistas
parciais, visando obteno do objetivo nal do projeto por meio
de vrios incrementos parciais bem-sucedidos.
256
1) Dos quatro tipos de lderes defnidos por Christenson (o que considera
os indivduos, o que estimula intelectualmente, o que infuencia os
ideais, e o que motiva inspiraes), qual , na sua opinio, o mais
importante? Justifque.
2) Como voc descreve os quatro passos da deciso? D um exemplo
prtico, a partir da sua experincia.
3) Descreva as principais fontes de confito entre os indivduos e as
instituies, dando exemplos de sua prpria experincia.
257
Unidade 6
4) Quais as formas de administrar um confito, e qual delas melhor se
adapta ao seu estilo de gesto? Por que essa forma de atuar e no as
outras? Faa um comparativo e publique na Exposio.
5) Qual a importncia do uso de simuladores no desenvolvimento de
projetos?
258
Saiba mais
As reunies geralmente so esperadas como atividades no muito
proveitosas. Isso acontece porque no existe uma boa preparao
para elas. Uma reunio bem preparada conduz a decises
importantes e, geralmente, sucesso nas realizaes. Veja no
link abaixo algumas sugestes e prticas para uma boa reunio,
no artigo intitulado A boa geometria da reunio, de Carlos
Cardoso Aveline.
http://www.terra.com.br/planetanaweb/ash/reconectando/
ambiente/334/reuniao.htm
O uso de simuladores pode ser importante para vericar
prottipos de produtos, antes mesmo de eles serem construdos.
No caso do desenvolvimento eletrnico, por exemplo, h um
interessante conjunto de simuladores, desenvolvidos com Java,
que podem ser vistos no endereo http://www.amanogawa.
com/index.html.
O exemplo o seguinte: no projeto de uma antena o projetista
tem como variar as caractersticas do produto, e testar seus
resultados. Se for construir um circuito eletrnico, poder fazer
simulaes especcas. Voc quer fazer um projeto de um novo
modelo de pipa/papagaio/maranho? (cada regio usa um nome
diferente). Pois veja o simulador computacional da NASA que
est no site http://www.grc.nasa.gov/WWW/K-12/airplane/
kiteprog.html. Este mais um timo exemplo de como
simuladores apoiam o trabalho de novos projetos.
7
UNIDADE 7
Finalizando o projeto
Compreender aspectos relativos fnalizao do
projeto, dissoluo das equipes e aos registros
documentais do trabalho.
Verifcar que o sucesso do projeto ou o fracasso est

intimamente ligado, por um lado, s expectativas
do cliente e, por outro, capacidade de liderana do
gestor.
Perceber que todo trabalho de projeto uma fonte de

aprendizagem, mas para que o aprendizado ocorra
necessrio extrair lies e refetir sobre elas.
Verifcar que um projeto pode ser a origem de muitos

outros, mas para isso os membros da equipe precisam
estar atentos s oportunidades.
Sees de estudo
Seo 1 Fase de fnalizao.
Seo 2 Planos de contingncia em caso de problemas.
Seo 3 Atendendo as expectativas do cliente.
Seo 4 Sobre o sucesso (ou fracasso) do projeto.
Seo 5 Desfazendo a equipe.
Seo 6 Documentao.
Seo 7 Lies aprendidas.
Seo 8 Idias para um novo projeto.
260
Esta a unidade que encerra o livro e justamente trata do
encerramento do trabalho de projeto. As atividades de
encerramento do projeto so comentadas considerando aspectos
diversos como o processo de documentao dos trabalhos
que permitiro, por exemplo, gerar o trabalho de suporte ao
produto quando o mesmo entrar em ciclo de produo e venda
ou para implementar melhorias contnuas durante sua fase de
consolidao.
Trata tambm da dissoluo da equipe e das anlises nais,
quando ento se vericar o grau de sucesso ou fracasso
alcanado pelo trabalho. Esse sucesso estar ligado demanda
original, vinda do cliente, seja esse cliente um contratante
externo ou voc mesmo. Se a expectativa for atendida, a sensao
de misso cumprida estar no ar. Seno, ser a frustrao do
fracasso.
Porm, com o fracasso tambm se aprende muito e assim
precisamos tirar lies para aproveitar no desenvolvimento
dos novos projetos, pois esses, com certeza viro. E, por esse
motivo, a ltima seo mostra uma gura representativa de
oportunidades de novos projetos no ambiente atual de negcios.
Mas para ver tais oportunidades preciso ter os olhos bem
abertos. Bom estudo!
261
Unidade 7
SEO 1 Fase de nalizao
A nalizao do projeto pode acontecer por dois motivos:
o resultado esperado est sendo atingido;
nada deu certo e melhor nalizar antes que piore.
Bem, vamos primeiro considerar a opo a, deixando a opo
b para a prxima seo.
A avaliao de que o resultado est sendo atingido obtida
por medies que devem ser feitas a cada etapa do trabalho.
Voc acompanhou isso desde a unidade 3, quando estudamos
o algoritmo do projeto e tratamos do acompanhamento e das
medies em cada atividade. Atingir o grau satisfatrio em cada
uma dessas medies, faz o projeto caminhar rumo ao objetivo
nal que o sucesso.
Uma das marcas principais do encerramento do projeto a
data limite, ou prazo nal. Muitas vezes, no teremos como
discutir contra uma data previamente estipulada, no haver
prorrogaes. Ento, deveremos trabalhar tendo em vista tal
data. O controle quanto a isso se dar no preenchimento e na
atualizao constante do Grco de Gantt (veja a unidade 4)
preenchendo as atividades realizadas e comparando com o
previsto. Da mesma forma avaliando a cada passo o caminho
crtico do projeto no diagrama PERT/CPM.
Fechado o projeto, ser importante avaliar as estatsticas quanto
ao tempo gasto, recursos utilizados, os riscos previstos
que acontecerem e os que no aconteceram, se os custos
previstos foram sucientes, e todos os demais dados
que possam ajudar a compreender melhor a gesto dos
prximos projetos.
Encerrar o projeto no ser apenas concluir os
trabalhos e fechar a porta. Este ser o momento de
avaliar se as expectativas do cliente foram atingidas e,
se foram, avaliar o grau de sucesso do trabalho. Ser o
momento de reunir toda a documentao (obrigatoriamente)
gerada para que, com isso, a histria do trabalho seja preservada,
permitindo a introduo do resultado do projeto num ciclo de
a)
b)
262
vida de produo, bem como, permitir avanar em melhorias e
mesmo em novos projetos a partir das lies aprendidas. Ser
tambm o momento de desfazer a equipe que, nos casos em que
se obteve sucesso, se transforma num momento triste e, nos casos
em que se vericou fracasso, uma libertao. Nas prximas sees
discutiremos com maior profundidade esses tpicos.
SEO 2 Planos de contingncia em
caso de problemas
Na seo anterior, falamos das duas possibilidades de opes,
a e b e j discutimos a primeira opo. Chegou a hora
de discutirmos sobre a segunda. Voc j viu que, em muitos
lmes ou brincadeiras se diz que, caso as coisas saiam errado,
vamos ativar o plano B. Ora, esse plano B o plano de
contingncia.
O plano de contingncia, infelizmente, no uma carta na
manga que facilmente lanada sobre a mesa, mudando todo o
jogo. Geralmente um conjunto de aes, tomadas sob presso,
geradoras de conitos e de crises, pois o plano de contingncia
um plano de soluo de crises. A percepo do erro geralmente
postergada ao mximo e isso, muitas vezes, ocorre de forma
inconsciente dado que no gostamos de errar. Para isso temos as
ferramentas de planejamento, acompanhamento e controle do
projeto (vimos vrias neste livro) que devem fazer parte de cada
momento de reviso para que possamos constatar se estamos de
acordo, ou no, com o planejado. Tais ferramentas apontam os
erros, basta fazer as marcaes e ler os indicadores. E, tendo visto
os erros, no certo trabalhar com desculpas, pois esse outro
defeito do ser humano, aceitvel apenas em algumas questes
sentimentais, mas no de trabalho.
Realizando as revises e percebendo erros capazes de afetar
seriamente o projeto, um plano de contingncia deve ser aplicado
imediatamente. Conforme o trabalho de Iacovou e Dexter
(2004), vrias aes devem ser tomadas quando um projeto sai
dos trilhos rumo ao fracasso. Tais autores, apontam as seguintes
aes corretivas como tentativas de remediar a situao:
263
Unidade 7
desenvolver um plano de recuperao;
redenir e gerenciar o propsito do projeto, ou seja,
avaliar novamente o escopo do projeto e o que, de fato, se
quer atingir;
reavaliar o negcio e considerar o cancelamento do
projeto, quando de fato no h soluo de continuidade
(deve haver um grande desprendimento para isso!);
replanejar o projeto usando mtodos de estimativa
apropriados e comprovados;
gerenciar as expectativas dos clientes, pois estes
percebero rapidamente que as coisas no esto indo
bem;
formular um plano de comunicao objetivo e
aberto, tanto para os membros da equipe quanto para
fornecedores e clientes isso trar conana;
dividir o restante do projeto em pequenas partes ou
atividades, o que facilitar o controle, a percepo
de objetivos menores e mais prximos, bem como a
capacidade de acreditar no sucesso;
tratar as diculdades pessoais da equipe do projeto,
especialmente quando essa equipe se sentiu culpada pela
aproximao do insucesso;
incorporar prticas corretivas no processo de
desenvolvimento do restante do projeto;
por m, reavaliar a liderana, vericando se essa
liderana capaz de alinhar as diversas foras
componentes do projeto rumo ao seu objetivo.
O ponto principal de um plano de contingncia, dessa
forma, a tomada de deciso. Tomar decises a tarefa
dos lderes empenhados no sucesso. Por esse motivo,
ao perceber que um projeto no vai bem, importante
vericar se o lder vai bem.

264
SEO 3 Atendendo as expectativas do cliente
Toda propaganda hoje diz o seguinte: fazemos de tudo para
atender as expectativas do cliente. Sabemos que isso apenas
propaganda e ningum atende, exatamente, as expectativas do
cliente. Provavelmente porque tais expectativas no so bem
conhecidas, nem mesmo pelos prprios clientes.
Quando um de ns diz: vou comprar um quilo de acar,
muito fcil atender tal expectativa. No entanto, se dizemos:
queria um software para gerenciar a venda em balco, a
expectativa muito mais complexa do que est expressa nessa
simples frase. No fcil apreender do cliente como seria tal
software, o tempo de resposta, a interface, quanto est disposto
a gastar e muitas outras questes desse tipo. No h uma
regra sobre como avaliar todos esses requisitos, mas uma srie
de procedimentos foi apresentada na unidade 3, seo 2, que
discutiu sobre os requisitos do cliente. A anlise aprofundada de
tais requisitos e a comunicao clara do que se entendeu como
escopo do problema, tanto para o cliente quanto para os membros
da equipe de projeto condio bsica para atender expectativas.
E rero expectativas no plural por entender que h aquelas
especcas do cliente e aquelas da equipe e ambas devem ser
atendidas para que haja sucesso.
Alm disso, no acredito em empresas que vivem alardeando
que fazem tudo pelo cliente. As empresas fazem antes, algo
por si mesmas, depois pelo cliente. E nisto no h um juzo de
certo ou errado, mas simplesmente o fato de que, para sobreviver,
a empresa precisa olhar para si mesma. No se trata tambm de
ultrapassar limites de tica ou avanar em atitudes oportunistas,
mas sim, de ser realista quanto s nalidades de cada sujeito neste
jogo. A expectativa do cliente deve ser tratada como algo objetivo
e deve car claro para ambas as partes o que possvel realizar e
o que no .
Chegar ao m do projeto , ento, contemplar a expectativa
desse cliente, seja ele um contratante externo, uma demanda
da empresa ou um desejo de ns mesmos. Ao confrontar
tal contemplao, teremos uma medida do sucesso do nosso
trabalho.
265
Unidade 7
SEO 4 Sobre o sucesso (ou fracasso) do projeto
O projeto foi entregue no prazo, gastou menos do que o previsto,
o produto alcanou ou at mesmo superou as expectativas, os
benefcios mensurveis pelo seu resultado so enormes...Temos,
ento, um projeto de sucesso. A equipe ser condecorada, haver
prmios para os responsveis, a empresa passar a vender mais
ou conquistar um nicho que antes no detinha. Inovaes sero
incorporadas pela indstria e pelo mercado e, dependendo do
grau, podero at mesmo revolucionar um setor ou um hbito.
Vamos nos debruar, porm, na situao inversa - o fracasso.
Todos queremos evit-lo, contudo, mesmo quando o fracasso
for inevitvel, precisamos aprender com ele para crescer. No h
vitorioso que no tenha fracassado alguma vez. preciso ento
prevenir, mas como poderemos nos prevenir dos fracassos em
projetos?
Para Keeling (2002), existe fracasso em projetos quando:
objetivos no so alcanados no prazo;
custos vo alm dos limites aceitveis;
resultados so obtidos com nvel de qualidade
comprometido.
Nesses trs itens resumem-se os fatores que denem um projeto:
prazo, custos, recursos e benefcios. Se algum deles no for
contemplado, temos indcios de fracassos. No entanto, podemos
fazer uma anlise mais sutil. H casos de projetos que foram
concludos com custo excessivo, muito alm do oramento
original e ainda acima do prazo estipulado. So exemplos desse
tipo: a pera de Sydney, na Austrlia e o Eurotnel, que liga
a Inglaterra Frana. No entanto, quem ousaria hoje dizer
que so fracassos? Do ponto de vista dos custos e dos prazos, o
foram. Mas os benefcios aparentemente superam em muito essas
falhas. Esses so casos de projetos estratgicos e visionrios que
so considerados no incio como equivocados ou previamente
fracassados. Porm, com o passar do tempo se percebe o quanto
foram importantes para os desdobramentos futuros. Isso se deve
viso poderosa, intuio e persistncia de lideranas e no aos
clculos e estudos de burocratas annimos.

266
Figura 7.1. pera de Sydney, na Austrlia, projetada em 1957 pelo
dinamarqus Jorn Utzon, que hoje Patrimnio Nacional da Austrlia.
Atualmente, muitos projetos na rea de software tm sido vtimas
da sndrome do fracasso. Por esse motivo, boa parte dos estudos
recente sobre gesto de projetos tem se voltado a analisar tais
casos, sendo que o interesse sobre os trabalhos do PMI (Project
Management Institute) sintomtico de uma realidade de
mercado. Nas palavras de Page-Jones (1990, p. 83), embora todo
projeto de Processamento de Dados enfrente diculdades tcnicas, elas
no so a causa principal de fracassos. Os desastres verdadeiramente
impressionantes so devidos a gerenciamento inadequado ou inepto de
projetos.
Esse autor destaca exatamente o ponto o qual estamos estudando:
os problemas relativos a projetos no esto nas questes tcnicas
e tampouco em atrasos ou gastos, pois esses, via de regra, so
conseqncias de um problema maior: o fracasso da gesto.
Como evitar o fracasso da gesto? Conforme Keeling (2002),
pode-se evitar fracassos com:
melhor avaliao de viabilidade;
anlise de riscos criteriosa;
uso de mtodos de planejamento;
uso de sistemas de controle.

267
Unidade 7
Porm, isso no suciente, apesar de necessrio. Um grupo
de trabalho pode se reunir e fazer vrias avaliaes, considerar
inmeros riscos e gerar grandes relatrios, preencher planilhas
e usar softwares de planejamento de projetos. Mas tudo isso
incuo se no houver o poder da deciso e o poder da deciso
uma atividade humana. Com isso quero dizer que preciso
ter liderana para que um projeto aspire ao sucesso. Para
encerrar esta seo, veja o caso do projeto de construo de uma
embarcao de guerra, no sculo XVII. Esse um caso clssico
de fracasso, motivo de estudos e pesquisas dos interessados em
administrao.
Figura 7.2. Representao em escala reduzida,
Museu do VASA (Fairley e Willshire, 2003).
268
Estudo de Caso
VASA um projeto fracassado do sculo XVII
O caso da embarcao Vasa foi apresentado no artigo de Kessler
et al. (2004), do qual retirei a seguinte histria: No comeo do sculo
XVII a Sucia estava engajada numa srie de batalhas navais contra
a Dinamarca, Rssia e Polnia. Em 1625, dez embarcaes de guerra
suecas foram abatidas quando estavam patrulhando a Baa de Riga.
Por esse motivo foram aceleradas as atividades de construo de
uma das maiores naves de guerra daquele tempo: Vasa. Por ter
descoberto que a Dinamarca planejava construir um barco ainda
maior que o Vasa, o rei da Sucia Gustavus Adolphus ordenou
alteraes na especifcao do navio para introduzir um segundo
nvel de canhes, mais canhes do que originalmente planejado.
Com tais modifcaes, o Vasa excedeu, em muito, o que poderia
ser suportado pelo lastro original. Alm disso, o mestre construtor
Henrik Hybertson faleceu, o que deixou a construo nas mos de
um gerente inexperiente e mais fraco nas decises e controle dos
operrios.
No vero de 1628 um teste de estabilidade foi conduzido pelo
Almirante Klas Fleming e pelo Capito Sofring Hansson. Trinta
homens correram de um lado ao outro do navio. Depois da
terceira corrida o navio inclinava to violentamente que o teste
foi interrompido. No entanto Fleming decidiu no postergar o
lanamento do navio, alegando que o mestre construtor j tinha
feito navios antes e no havia com o que se preocupar. Menos de
um ms depois, em 10 de agosto de 1968, o Vasa foi levado ao mar.
Para mostrar o poder dos armamentos da embarcao, o Capito
Hansson velejou com as portas dos canhes abertas, o que no
era usual. Depois de navegar pouco mais de mil metros em mar
calmo, o Vasa entornou e naufragou, levando consigo cinqenta
marinheiros para o fundo do porto de Estocolmo. Era uma
embarcao magnfca, que tinha custado cerca de 5% do tesouro
sueco, com 64 canhes pesados e para 300 marinheiros. Feito
para simbolizar a fora e a beleza da Sucia e para meter medo no
corao dos seus inimigos.
Muitas discusses foram realizadas para descobrir os culpados
pelo desastre, mas ningum foi formalmente acusado. O rei foi
parcialmente culpado por ter demandas pouco realistas, Hybertson
pelo desenho medocre do projeto, Fleming por no ter dado
ateno aos testes realizados e Hansson pela inabilidade no
comando da embarcao.
269
Unidade 7
Os erros, porm, foram bem mais graves do que esses.
Analisando alguns, podemos considerar os seguintes
detalhes:
1. Os construtores tentaram imitar o projeto da embarcao
dinamarquesa Sancta Sophia, no entanto no tinham
conhecimento tcnico nem capacidade de desenvolver
procedimentos construtivos para tanto.
2. nfase na elegncia e no poder de fogo e pouca
importncia estabilidade e navegabilidade.
3. Excesso de pressa na construo do barco e pouca
ateno sua qualidade, especialmente se considerar a
sua dimenso e a quantidade de novas tecnologias que
estavam incorporadas o que atribua ao projeto uma srie
de riscos e incertezas.
4. Os testes durante a fase de desenvolvimento eram
incompletos, houve desprezo pelos resultados de tais
testes e excesso de otimismo com o resultado do projeto,
desconsiderando os sinais em contrrio.
5. Trs diferentes pessoas fzeram especifcaes e defnies
para o projeto de forma independente, modifcando o
conjunto (o Rei, Hybertson e o ltimo mestre).
6. O projetista principal, Hybertson, faleceu um ano antes
de o navio ser concludo e no deixou documentao ou
memria, ou seja, no houve transferncia tecnolgica.
7. O rei no tinha conhecimentos tcnicos para resolver o
problema proposto, e mesmo assim interferiu no projeto
como seu chefe supremo.
Devido a esse conjunto de fatores, verifca-se o exemplar
fracasso.
Figura 7.3. Representao da embarcao ao afundar,
Museu do VASA (Fairley e Willshire, 2003).
270
SEO 5 Desfazendo a equipe
Equipes de projeto podem criar anidades de tal monta que,
desfaz-las, no tarefa fcil. Permanecem as anidades e o
entusiasmo, especialmente se houve sucesso. O encerramento das
atividades deve passar por uma avaliao de nalizao. Uma
discusso franca sobre erros e acertos, principalmente no que se
refere ao modelo de gesto adotado, bem como o dia-a-dia da
equipe, trar benefcios e crescimento a todos.
Reconhecer os mritos: eis uma obrigao.
H muitos casos de projetistas que empenham horas de esforo
e imaginao num projeto e sabemos todos que no so apenas
aquelas horas que esto l escritas na planilha. Essas horas so
doaes espontneas daqueles que gostam de desaos e almejam
sempre a qualidade e a realizao. O reconhecimento disso deve
ser manifestado claramente e quando houver oportunidade e
condies, deve ser premiado.
Receber um prmio, mesmo que seja uma simples palavra de
agradecimento sincero, algo honroso. Conheo gestores que
no sabem premiar e que consideram que realizar o trabalho
a obrigao de cada um. Desejo a esses a sorte que se deseja aos
ratos de esgoto.
SEO 6 Documentao
Documentao um ponto falho em quase todos os projetos.
Quando Joozinho e Mariazinha entraram pelo caminho
desconhecido na oresta, a trilha de pedras que eles deixaram
foi seu documento principal, o documento que permitiu que
voltassem para casa. Esse era o caminho das pedras. No
entanto, quando o nico material que ele tinha, para documentar
o caminho, na segunda vez que entrou pela oresta, eram
pedaos de miolo de po, os pssaros comeram sua marcao e
eles se perderam. Essa documentao era efmera. A memria
uma documentao efmera.
271
Unidade 7
A documentao no adequada se no for clara, estiver
arquivada, acessvel e possvel de ser entendida por outros. Vimos,
desde a primeira unidade, que o planejamento est baseado em
anlises, avaliaes, relatrios, depois planilhas e diagramas.
Muitos desses documentos sero usados ao longo do projeto
para revises, bem como sero realizadas reunies que devero
gerar atas e assim por diante. Alm disso, o trabalho tcnico ser
baseado em desenhos, rascunhos, anotaes, resultados de testes
e muitos outros documentos de variados tipos. uma obrigao
dos responsveis de cada etapa do projeto e do gestor, organizar,
arquivar e preservar a documentao do projeto a qual deve ser
parte do resultado nal do trabalho.
Nenhum projeto poder ser considerado encerrado se a
documentao no estiver adequadamente preservada e
organizada.
SEO 7 Lies aprendidas
Cada projeto uma oportunidade de aprendizagem e,
geralmente, aprendemos com os erros. A constante reviso
do projeto, em cada uma das suas etapas, ser um exerccio
de anlise e, para isso, contamos com diversos instrumentos
como, relatrios preenchidos l no comeo e que devem
ser analisados em comparao com o realizado, passo a
passo. Muitas crticas e idias surgiro nesses momentos e
importante avanar sobre isso. Como dito na seo anterior,
a documentao gerada ser uma fonte de recursos de
aprendizado.
A leitura do caso Vasa tambm uma oportunidade de
aprendizagem, pois podemos estudar erros e acertos em projetos
realizados por outros para avaliar caminhos. O estudo de casos
proporciona, em contraste com nossa prpria experincia, uma
fonte rica de aprendizagem. Vamos considerar novamente o
caso Vasa e comparar com projetos na rea de software. Foi
exatamente isso que zeram Fairley e Willshire (2003) em
seu artigo sobre problemas em projetos de software, buscando
antdotos para tais problemas numa srie de sugestes, cujas
272
principais esto apresentadas no quadro 7.1. Aparentemente um
projeto de embarcao nada tem a ver com o desenvolvimento
de software, mas no bem isso que nos sugere esse conjunto de
problemas e seus antdotos.
Quadro 7.1. Problemas em projetos de software e seus antdotos, adaptado de (Fairley &
Willshire, 2003).
PROBLEMA ANTDOTOS
Presso excessiva de prazos
Estimativas objetivas de prazo
Mais e melhores recursos
Priorizaes
Mudanas no escopo e nas necessidades
Desenvolvimento interativo
Modicar gesto de controle e planejamento
Falta de especicaes tcnicas
Desenvolvimento de especicaes prvias
Atualizao das especicaes com base em eventos
Indicao de um arquiteto de software
Falta de documentao de planejamento
Desenvolvimento de planejamento prvio
Atualizaes peridicas e baseadas em eventos
Indicao de um gestor de projetos
Inovaes excessivas ou secundrias
Maior controle sobre a linha de trabalho
Anlise de impactos
Gesto contnua dos riscos
Falta de mtodos cientcos
Uso de prottipos
Desenvolvimento incremental
Uso de mtricas de medio da performance tcnica
Ignorando o bvio Assimilar as lies aprendidas anteriormente
Comportamento antitico
Cultura de trabalho baseada em tica
nos relacionamentos
Uso e aderncia a cdigos de tica formais
273
Unidade 7
Vendo o quadro 7.1 percebemos que as lies tiradas do episdio
so muitas e algumas das mais importantes dizem respeito ao uso
de mtricas de performance, ao desenvolvimento incremental,
diviso do projeto em pequenas etapas, ao controle constante
do desenvolvimento e a uma cultura baseada em tica e bom
relacionamento. Podemos ainda listar mais algumas, tais como:
No se deve imitar projetos sem o suciente
conhecimento tcnico;
Buscar conciso e usabilidade;
No se submeter pressa e dar ateno especial
qualidade;
Realizao constante e contnua de testes, durante todas
as etapas;
Reduzir os cargos de responsabilidade, para evitar o
empurra-empurra da deciso;
Gerar documentao sempre e no apenas no nal;
Aqueles que no tm conhecimento tcnico no devem
interferir em assuntos que no so de sua competncia.
Se retornarmos unidade 1 deste livro, veremos como os
projetos foram se modicando no decorrer do tempo e as lies
aprendidas foram sendo incorporadas pouco a pouco. No incio
houve desperdcio imenso de recursos nanceiros e mesmo de
vidas humanas. Um esforo enorme de melhoria se deu na poca
da revoluo industrial e, logo depois, chegando ao comeo do
sculo XX com teorias e ferramentas especcas. Hoje temos um
nmero muito maior de ferramentas, sistemas computacionais
especiais e disputas tericas em revistas especializadas. Porm, ao
mesmo tempo, os resultados no so to animadores, como voc
pode conferir no quadro 1.2. Ento, vamos trabalhar rmemente
para no colocarmos nossos prprios projetos naquela estatstica.

274
SEO 8 Idias para um novo projeto
Na seo anterior discorremos sobre aprendizagem e sobre o
processo de tirar lies dos casos de insucessos, das diculdades
e solues que vamos encontrando no decorrer do trabalho de
desenvolvimento do projeto. Porm, acredito que tais lies s so
percebidas e aprendidas por pessoas e equipes especiais, cheias
de idias e criatividade. Acabar um projeto, geralmente serve de
pretexto para dar origem a um novo projeto, pois todas as idias
que foram surgindo no meio do caminho so sementes para novos
trabalhos. Empresas buscam pessoas assim, para que sobrevivam
no mercado criando oportunidades de novos negcios.
Voc estudou nas unidades 1 e 2, as formas como se originam
projetos, os quais podem ser muito simples, tal como um
incremento de qualidade num produto que j temos, ou
complexos, como a criao e o lanamento de um produto
totalmente novo. Anotaes feitas durante o trajeto de
desenvolvimento sero geradoras de oportunidades em ambos
os sentidos. Por um lado, vrios apontamentos diro da
necessidade de acrescentar melhorias incrementais, as quais no
caberiam no decorrer do projeto, pois atrasariam o trabalho
ou determinariam custos impossveis de cumprir. Por outro
lado, idias completamente novas podero surgir, apontando
para solues radicalmente diferentes. Um exemplo? A criao
do Compact Disc foi uma soluo totalmente diferente para o
problema da gravao em tas magnticas.
importante, tambm, perceber que o fracasso de um projeto
no , necessariamente, o encerramento das oportunidades.
Fracassos ou graves problemas de um projeto chamam a ateno
para novas oportunidades de desenvolvimento. Contudo, para
renascer preciso ter o esprito e a convico dos lderes.
Por m, gostaria de encerrar chamando a ateno para a
estrutura de negcios da gura 7.3, com uma representao em
trs dimenses onde os eixos denem diferentes atuaes no
interior da empresa ou organizao. Este desenho est pleno de
idias para novos projetos. Vamos ver mais de perto.
275
Unidade 7
Gesto dos
Processos de
Negcio
Processos de
Suporte a
Produto
Gesto dos
Processos
Operacionais
Processos
de Compra
Projeto de
produto
Processos
de Venda
Processos de
Cho-de-Fbrica
Processos de
Desenvolvimento
Administrao
Suporte
Clientes
Produo
Fornecedores
Figura 7.4. Processos em um ambiente de negcios. Adaptado de Greef (2005).
O eixo horizontal conecta a cadeia de fornecimento a de
relacionamento com o cliente, o vertical estabelece a ligao entre
a produo e a administrao do negcio e o diagonal apresenta o
desenvolvimento do produto e o suporte a ele durante seu ciclo de
vida. Se estivermos presos apenas rea de desenvolvimento de
novos produtos, estaremos condicionados a um pequeno terreno
de idias de novos projetos. Mas hoje o essencial est nas ligaes
entre o maior conjunto possvel de eixos e a isso poderamos
chamar de gesto dos processos. Projetos podem surgir para
interligar o processo de produo no cho-de-fbrica ao
ambiente administrativo, por exemplo, e o que est comeando
a acontecer, neste exato momento, com a interligao entre a
automao industrial e o ERP das companhias. Iguais a essa,
inmeras oportunidades esto nossa frente. Ou seja, a hora de
comear um novo projeto. Boa sorte!
ERP: iniciais de Enterprise
Resource Planning, que
representa o sistema
computacional integrado
para gesto empresarial,
composto de mdulos
diversos como os de
contabilidade, nanas,
recursos humanos,
compras, oramentos,
estoques, entre outros,
facilitando o uxo de
informaes entre
os departamentos
da empresa visando
a otimizao do seu
planejamento.
276
Sntese
Nesta unidade voc estudou sobre a importncia de uma anlise
criteriosa de todos os passos dados durante o projeto e que tais
passos precisam ser cuidadosamente documentados. Com isso
ser possvel dar continuidade s melhorias que o projeto exigir,
permitir o suporte ao produto quando for o caso, aprender com
os erros e acertos do processo e tambm gerar novas idias de
projetos.
Outra questo importante refere-se ao reconhecimento dos
membros da equipe como os verdadeiros responsveis pelas
conquistas obtidas. Evidenciar tais mritos uma obrigao
pois, a partir do momento que o projeto se encerra, as pessoas
se voltaro para outros trabalhos e funes, porm se lembraro
desses momentos de desao e sentiro satisfao por saber que
foram reconhecidas.
Haver os casos de fracassos, no estaremos livres disso. Esses
casos devem ser analisados com ainda maior rigor, permitindo
nosso crescimento pessoal e tambm a propagao da experincia
para todos os interessados. Vimos que casos famosos de fracassos
so um bom objeto de estudo e, tambm, que h vezes onde um
suposto fracasso se revelou como sendo um empreendimento de
sucesso ao longo do tempo. Tambm esses so casos importantes
de pesquisa e anlise, especialmente por considerar que foram,
geralmente, conduzidos por lderes obstinados e capazes de
inspirar e motivar suas equipes a despeito dos fatores negativos
momentneos.
Oportunidades de novos projetos esto nossa disposio. A
ltima seo fala justamente disso e, de certa forma, nos liga
ao incio deste livro que discute a origem dos projetos. Que seja
aqui, ento, o ponto de ligao para o eterno recomear, seja dos
estudos, seja dos projetos, seja dos novos empreendimentos de
sucesso. At mais!
277
Unidade 7
1) Quais so os passos para implantar um plano de recuperao, em um
projeto em crise? Exemplifque com projetos de sua experincia.
2) Que grandes difculdades existem no atendimento das expectativas do
cliente?
3) Como se pode prevenir um projeto do fracasso? Que atitudes podemos
tomar nesse sentido?
4) Quais lies voc tira do fracasso do projeto VASA para seus prprios
projetos?
278
5) Considere seu prprio campo de trabalho e sua experincia
profssional, e analise a fgura abaixo. Que nova idia de projeto,
concreta e exeqvel, voc pode sugerir?
Gesto dos
Processos de
Negcio
Processos de
Suporte a
Produto
Gesto dos
Processos
Operacionais
Processos
de Compra
Projeto de
produto
Processos
de Venda
Processos de
Cho-de-Fbrica
Processos de
Desenvolvimento
Administrao
Suporte
Clientes
Produo
Fornecedores
279
Unidade 7
Saiba mais
Visite o site http://www.arcweb.com/ e veja inmeros estudos e
oportunidades de novos projetos na rea empresarial e industrial.
Veja tambm estudos de casos e anlises de mercado.
O IEEE Institute of Electric and Electronic Engineers mantm
uma Sociedade voltada gesto de engenharia e projetos,
de mbito mundial. a IEEE Engineering Management
Society. Visite o site http://www.ewh.ieee.org/soc/ems/ e veja
inmeras oportunidades de trabalho, estudo, artigos, revistas etc.
Estudantes de graduao, de qualquer rea, podem se associar
com valores de taxas anuais especiais.
Para concluir o estudo
Chego ao nal deste trabalho e espero ter cumprido boa
parte das suas intenes! Quem dir isso ser voc, leitor
e estudante. Pois tambm sou um estudante deste tema,
que muito me interessa e sempre me desaa. Ao longo
do tempo fui reunindo informaes tericas e, ao mesmo
tempo, agindo em diferentes projetos, alguns de sucesso,
outros nem tanto. Tentei colocar o mximo desses
conhecimentos e experincias aqui, e simultaneamente
comparar e reetir sobre novas tendncias neste campo.
Apresentei algumas tcnicas e modelo de apoio,
seja nas anlises iniciais ou para o planejamento,
acompanhamento e controle do projeto at seu nal,
sabendo, no entanto, que tais tcnicas e modelos vo
sendo alterados com o tempo e com o desenvolvimento
das tecnologias de gesto. Dessa forma, o foco principal
no foi em tais modelos, mas sim no seu uso como
ferramentas de auxlio numa viso ampla do processo
de trabalho envolvido em projetos, sejam eles de que
tamanho forem. Assim, ateno foi dada essencialmente
na aprendizagem e na discusso que gera conhecimento.
Por esse motivo, acredito que tenha acompanhado ao
lado do cunho acadmico de um livro de graduao,
tambm uma abordagem direcionada s aplicaes
prticas e ao nvel estratgico, fundamentais para o
progresso do nosso dia-a-dia.
Tambm importante frisar que este livro seja uma
introduo ao tema da gesto de projetos e das equipes
que os compem, sendo que inmeros artigos, estudos
e pesquisas continuam sendo feitos e publicados sobre
isso no mundo, com crescente interesse nessa forma de
desenvolvimento por projetos, que embalou toda a nova
era de tecnologia que vivemos. Devemos estar atentos a
tais estudos, e ns mesmos devemos contribuir no debate.
282
Por m, gostaria de frisar a importncia da liderana em
projetos, tema tantas vezes abordado aqui. A gesto que
desenvolve os aspectos da liderana saber conduzir seu trabalho
ao aprendizado constante, ao sucesso, e especialmente ao bem-
estar das pessoas, nosso objetivo primordial. Sucesso a todos!
Prof. Mauro Faccioni Filho
Referncias
BAZZO, Walter Antnio, PEREIRA, Luiz Teixeira do Vale.
Introduo Engenharia, 5.ed. Florianpolis, Editora da UFSC,
1997.
CHRISTENSON, Dale; WALKER, Derek H. T. Understanding
the role of vision in project success. IEEE Engineering
Management Review, vol 32, no. 4, 2004. pp 57-73.
CLELAND, David. The evolution of project management. IEEE
Transactions on Engineering Management, v.51, no. 4, 2004, pp.
396-397.
COURAU, Christophe. Muralhas que dividiram os homens,
Histria Viva, edio 13, novembro de 2004. http://www2.uol.
com.br/historiaviva/home.html (acessado em 18/02/2005)
COVEY, Stephen. O 8. Hbito: da efccia grandeza. Rio de
Janeiro: Elsevier, 2005. 413 p.
DeMARCO, Tom. Controle de projetos de software. Editora
Campus, Rio de Janeiro, 1991. 304 pp.
DVIR, Dov, SHENHAR, Aaron., ALKAHER, Shlomo. From a single
discipline product to a multidisciplinary system: adapting the
right style to the right project. IEEE Engineering Management
Review, vol 32, no. 1, 2004. pp 12-23.
FACCIONI, Mauro. Especifcao e soluo de problemas de
engenharia. (Apostila) curso de Especializao Automao
e Computao Industrial, fevereiro de 2004, CTAI/Senai/SC,
Florianpolis.
FAIRLEY, Richard E., WILLSHIRE, Mary Jane. Why the Vasa Sank:
10 Problems and Some Antidotes for Software Projects. IEEE
Software. March/April, 2003. pp 18-25 (disponvel em http://
computer.org/software )
FERNANDES, Jorge Monteiro. Gesto da Tecnologia como parte
da estratgia competitiva das empresas. Braslia: IPDE, 2003.
275 p.
GOOCH, Tom. Object Oriented Analysis and Design Team.
Kennesaw State University, 2000. (disponvel em http://pigseye.
kennesaw.edu/~dbraun/csis4650/A&D/index.htm, acessado em
24/04/2005).
284
GREEFF, Gerhard. Staying in sync. ISA Intech/Industrial Computing, vol 52,
no. 6, June 2005. pp. 51-55. (www.isa.org/intech)
HINOJOSA, Mara Alejandra. DIAGRAMA DE GANTT. 2003. Disponvel em
www.gestiopolis.com, acessado em 24/04/2005.
HOUAISS, Antnio. Dicionrio Houaiss da Lngua Portuguesa. Editora
Objetiva / Instituto Antnio Houaiss. Rio da Janeiro, 2004. 2922 pp.
IACOVOU, Charalambos, DEXTER, Albert. Turning around runaway
information technology projects. IEEE Engineering Management
Review, vol 32, no. 4, 2004. pp 97-112.
KEELING, Ralph. Gesto de projetos, uma abordagem global. Editora
Saraiva, 2002, 294 pp.
KESSLER, Eric H., BIERLY, Paul, GOPALAKRISHNAN, Shanthi. VASA
Syndrome: insights from a 17th-Century new-product disaster. IEEE
Engineering Management Review, vol 32, no. 1, 2004. pp 38-48.
KLOPPENBORG, Timothy; PETRICK, Joseph. Managing Project Quality.
IEEE Engineering Management Review, vol 32, no. 4, 2004. pp 86-790.
MSF Microsoft Solutions Framework, 1998. Disponvel em www.
microsoft.com/technet/itsolutions/msf/default.mspx
PAAP, Jay, KATZ, Ralph. Anticipating disruptive innovation. IEEE
Engineering Management Review, vol 32, no. 2, 2004. pp 74-85.
PAGE-JONES, Meillir. Gerenciamento de projetos: guia prtico para
restaurao da qualidade em projetos e sistemas de processamento de
dados. So Paulo: McGraw-Hill, 1990. 328 pp.
PQA - History of Project Management, www.pqa.net , acessado em
15/02/2004. Process Quality Associates Inc.
PMBOK, Guide to the Project Management Body of Knowledge, Project
Management Institute, 2004, 3a. edio, 388 pp.
PRADO, Darci Santos do. PERT/COM Srie Gerncia de Projetos, volume
4. 1998. Belo Horizonte. Editora DG.
RAZ, Tzvi, BARNES, Robert, DVIR, Dov. A critical look at Critical Chain
Project Management. IEEE Engineering Management Review, vol 32, no.
2, 2004. pp 35-44.
SENZ, Tirso W., CAPOTE, Emilio G. Cincia, Inovao e Gesto
Tecnolgica, IEL/SENAI, Braslia, 2002.
SISK, Toney. The History of Project Management. http://of ceupdate.
microsoft.com/downloadDetails/projhistory.htm (acessado em
20/02/2005).
VALERIANO, Dalton L. Gerncia em projetos pesquisa, desenvolvimento
e engenharia. So Paulo: Makron Books, 1998. 438 pp.
Sobre o professor conteudista
Mauro Faccioni Filho nasceu em Maring, PR, em 29
de outubro de 1962. Formou-se em Engenharia Eltrica
pela Universidade Federal de Santa Catarina (UFSC)
no comeo do ano de 1985, e nesse mesmo ano fundou
a empresa Creare Engenharia, junto com dois colegas
da universidade. Posteriormente concluiu, tambm
na UFSC, Mestrado (1997) e Doutorado (2001) em
Engenharia Eltrica, com estudos sobre representaes
tridimensionais e modelagem numrica computacional.
Nos anos 2002 a 2004 atuou como diretor do Centro de
Tecnologia em Automao e Informtica CTAI, em
Florianpolis, tendo participado na criao de cursos
superiores e de pr-incubadora empresarial tecnolgica,
alm de ter editado revista tcnica em automao e
informtica.
Desde 2002 na UNISUL, como professor, participou do
desenvolvimento em 2004 do projeto do Curso Superior
de Tecnologia em Web Design e Programao, do qual
atualmente coordenador e onde atua tambm como tutor.
Com vrios artigos tcnicos e cientcos publicados,
lanou ainda trs livros de poemas. Seu currculo
completo est disponvel para consulta on-line no banco
de dados do CNPq, no endereo http://buscatextual.
cnpq.br/buscatextual/index.jsp.
Respostas e comentrios das
atividades de auto-avaliao
Unidade 1
1) O exemplo descrito deve claramente identifcar um objetivo e
um prazo determinado de execuo.
2) Durante a revoluo industrial h maior interesse em
desenvolver mtodos de gerncia, para evitar gastos
desnecessrios, perdas de tempos, atrasos, etc. Um cientista
da administrao surge nessa poca e comea a estudar
detalhadamente o trabalho, mostrando que a produtividade
pode ser aumentada se o trabalho for dividido em pequenas
tarefas separadas. Seu nome Frederick Taylor (1856-1915),
e ele considerado o pai da cincia da administrao (SISK,
2004).
3) Na prtica no houve mudanas, e os ndices so muito
prximos e at piores, apesar da implementao de variadas
tcnicas para controle de produo introduzidas durante o
sculo XX. Isso indica que as empresas no esto utilizando
tais tcnicas, e continuam realizando seus trabalhos sem
gerenciamento.
4) A construo das grandes pirmidades, onde:
O prazo era o enterro do fara, mas isso era indeterminado;
Objetivo estabelecido: sim, a morada do fara aps a
morte;
Custos planejados: no, o investimento no importava
nesse caso;
Recursos previamente alocados: no, recursos humanos e
materiais eram usados conforme a demanda da obra.
288
5)
Exemplo de tarefa de
rotina ou atividade
contnua
Concessionria de
energia eltrica
Projeto de nova hidreltrica Operao da hidreltrica
Software Nova plataforma de e-commerce Manuteno de aplicativo
Indstria
Automobilstica
Desenho de novo lanamento Linha de montagem
Bancos
Criar nova linha de
nanciamento e lanar
no mercado
Operar carteiras de crdito
Governo
Desenvolver sistema de
eleio eletrnica
Emisso de ttulos eleitorais
Unidade 2
1)
Necessidade: um sistema de marcao do tempo que fosse porttil;
conhecimentos: tecnologia mecnica dominada;
idias: relgio de pulso, de bolso;
seleo: de pulso;
desenvolvimento: artesos suos;
uso de difuso: relgios de quartzo, com ponteiros e com visor
digital, etc.
2) A cincia e a tecnologia so instituies sociais, mas enquanto a cincia
tem como fnalidade a gerao do conhecimento, a tecnologia a
aplicao de tais conhecimentos. Enquanto os conhecimentos sobre
eletromagnetismo e microonda so cientfcos, os conhecimentos sobre
rdios e telefones celulares so tecnolgicos, por exemplo.
3) Um caso importante o telgrafo sendo substitudo pelo telefone.
Outro caso a televiso substituindo o cinema, porm houve tambm
289
uma mudana de hbitos que fez retornar o cinema. O uso da telefonia
sobre IP (VoIP) certamente encerrar a gerao dos telefones fxos
atuais. Os sistemas digitais de fxao de imagens encerraram a carreira
das cmeras fotogrfcas tradicionais.
4)
Tecnologia
Complexidade
Incerteza
Super-sistemas
Sistemas
Montagem
CASA SOFTWARE
CARRO 4x4
Baixa
Unidade 3
1) Viso restrita: instalar um software de controle de estoque, que
relaciona os produtos em prateleira e d a baixa a partir da emisso
da nota fscal de venda, com controle feito por um responsvel pelo
estoque;
Viso ampla: sistema integrado que verifca o estoque durante o
processo de emisso de propostas, que deve ser atualizada a cada
modifcao solicitada pelo cliente, sendo que quando este d o aceite,
imediatamente o estoque recebe o aviso da baixa e a reposio
requisitada automaticamente.
2)
Listar as informaes que esto no enunciado, na tentativa de
detalhar o melhor possvel suas partes;
descrever todos os efeitos conhecidos do produto, quando for o
caso, e enumerar todas as possveis causas;
290
listar o que deve ser determinado pela soluo, ou seja, defnir com a
maior clareza possvel o que est sendo buscado;
criar modelos e esquemas de representao, permitindo uma melhor
visualizao do conjunto;
desenvolver desenhos esquemticos, diagramas e fuxogramas;
verifcar as leis fsicas associadas e tambm outros impeditivos e
limitantes, tais como questes jurdicas, restries tcnicas, restries
ambientais, etc;
usar simuladores como ferramentas de apoio.
3) O algoritmo permite modelar o planejamento do projeto de maneira
que voc entenda e defna todos os passos que devem ser seguidos na
execuo do projeto, para que o mesmo chegue ao resultado esperado.
4) O projeto deve passar por revises em todas as suas etapas, para
verifcar se as atividades intermedirias foram atendidas. Rever o
projeto durante o seu andamento signifca reavaliar constantemente
o planejamento, bem como redefnir os objetivos quando necessrio.
Reviso seja feita apenas no fnal do projeto, pode acarretar no fracasso
total, ou em perdas irreversveis, ou atrasos extraordinrios.
5) A partir de um certo prazo o projeto perde o sentido. Isso no
signifca apenas que ele d prejuzo, mas simplesmente no h mais
possibilidade de se obter sucesso, como por exemplo no lanamento
de um produto especfco para uma data, ou quando h uma
concorrncia, ou devido a um fenmeno natural, etc.
6) Os fatores so recursos, custos, benefcios e prazo.
7) Porque projetos so trabalhos que envolvem variveis muito diversas,
e como h um prazo determinado para seu encerramento, fatores
como custos e recursos tendem a variar conforme a complexidade do
problema, e com isso difcil manter todas as previses.
291
Unidade 4
1)
Programa Qualidade
Prazos estimados pela
equipe de implantao
A - reunies do grupo do projeto para denir o programa 1 semana, 7 dias
B - redao do programa de qualidade 2 semanas, 14 dias
C - treinamento do pessoal do setor administrativo 3 dias
D - implantao do programa de qualidade no setor Administrativo; 2 semanas, 14 dias
E - treinamento do pessoal do setor de produo 3 dias
F - implantao do programa no setor de produo; 2 semanas, 14 dias
G - avaliao dos resultados e concluso 3 dias
2)
3)
292
4)
5) H uma Folga Livre de 11 dias para a atividade E. Neste caso o gestor
pode decidir a melhor data para que tal atividade seja executada,
otimizando os recursos disponveis dentro de tal folga, sem afetar o
andamento geral do projeto.
Unidade 5
1) As quatro fases so Formao, Turbulncia, Normalizao e
Desempenho. Geralmente a mais problemtica a segunda fase, pois
h a formao de sub-grupos de poder, as chamadas panelinhas, que
podem fazer a equipe dispersar suas energias.
2) A matriz ajuda a defnir as necessidades de um projeto, e alinhar aos
recursos humanos disponveis para o trabalho. No havendo recursos
humanos na empresa ou grupo, pode-se buscar por recrutamento
externo. Da mesma forma a matriz ajuda a defnir os investimentos
fnanceiros do projeto, pois possvel defnir os gastos com equipe, de
acordo com os custos de hora-homem dos membros escolhidos.
3) Geralmente a estrutura exclusiva, com um organograma bem defnido,
o que melhor se adapta nessas condies. Nesse modelo os membros
do projeto so dedicados a um projeto apenas.
4) Esta a estrutura matricial, e seu grande problema a complexidade,
que exige maturidade da empresa e das equipes de projeto, para
poderem trabalhar em vrios projetos simultaneamente, com equipes
alterando conforme o cronograma e o setor/atividade.
293
5) Na estrutura do tipo horizontal, pois os membros da equipe se
reconhecem como pares, mesmo quando os domnios e os interesses
tcnicos so muito diferentes. Esse tipo de estrutura tipicamente
multidisciplinar, com grande nmero de idias e solues criativas, o
que favorece desenvolvimento de aplicativos de software.
6) Resposta subjetiva. Comentrios sobre produtividade, sobre riscos de
atraso, sobre falta de qualidade, sobre diferenas culturais afetando os
resultados, sobre queda de preos.
Unidade 6
1) Resposta subjetiva. O que considera os indivduos tem o perfl de
humano, o intelectual o que lana desafos, o que infuencia ideais e
inspiraes o motivador das pessoas.
2) Os quatros passos so: (1) identifcar possveis modos de ao, (2)
verifcar vantagens e desvantagens; (3) discutir e avaliar; (4) escolher o
modo de ao mais vantajoso, e partir para ele.
3) Resposta subjetiva baseada no seguinte quadro:
Diferenas
Indivduo / prossional Organizao / gerncia
Busca a inovao tecnolgica Busca o lucro
Quer autonomia de ao Quer integrar os prossionais na organizao
Quer livrar-se de regras e procedimentos Estabelece as regras e procedimentos
Quer autoridade baseada em mrito Autoridade baseada em hierarquia
Quer ser recompensado com base em seu desempenho Recompensa conforme o interesse da organizao
Quer ampla comunicao entre pares Bloqueia a comunicao interna
Busca otimizao do prprio trabalho Busca cumprimento de cronogramas e custos
4) As formas apresentadas so: por confronto, por comprometimento,
por acomodao, por prevalncia, por retirada.
294
5) O uso de simuladores pode ser importante para verifcar prottipos
de produtos, antes mesmo de eles serem construdos. Os simuladores
passaram a ser ainda mais importantes com o avano da informtica,
que permitiu o uso de simulao computacional, que poupa tempo e
dinheiro, especialmente em projetos de produtos complexos ou muito
grandes, como mquinas, grandes hidreltricas, grandes construes etc.
Unidade 7
1) Os passos so:
desenvolver um plano de recuperao;
redenir e gerenciar o propsito do projeto;
reavaliar o negcio;
replanejar o projeto usando mtodos de estimativa;
gerenciar as expectativas dos clientes;
formular um plano de comunicao;
dividir o restante do projeto em pequenas partes;
tratar as diculdades pessoais da equipe do projeto;
incorporar prticas corretivas;
reavaliar a liderana
(Os exemplos sero individuais).
2) Erros de comunicao no incio do projeto causam frustraes na fase
fnal. Os clientes tm difculdades para defnir seus requisitos, e muitas
vezes tm expectativas exageradas.

295
3) Pode-se evitar fracassos tomando as seguintes atitudes:
avaliando detalhadamente a viabilidade do projeto antes de come-lo;
fazendo uma anlise de riscos criteriosa;
usando mtodos de planejamento;
usando sistemas de controle durante a fase de desenvolvimento.
4) Resposta subjetiva. Poder haver citaes sobre o descontrole, sobre a
falta de liderana, sobre as interrupes constantes feitas pela lei, sobre
a falta de conhecimento tcnico apropriado, sobre o planejamento
fraco, sobre a falta de documentao.
5) Resposta subjetiva, individual.


Unisul Gestao de Projetos e Equipes

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Unisul Gestao de Projetos e Equipes

Caricato da

Copyright:

Formati disponibili

Universidade do Sul de Santa Catarina

gestao_de_projetos_e_de_equipes.indb 11 28/5/2007 15:28:27

gestao_de_projetos_e_de_equipes.indb 12 28/5/2007 15:28:27

gestao_de_projetos_e_de_equipes.indb 14 28/5/2007 15:28:27

Compreender diferenas entre projetos e atividades

Verifcar um breve histrico dos projetos e de sua gesto.

Analisar a evoluo da gesto de projetos e de equipes

Conhecer os principais conceitos sobre projetos, equipes

gestao_de_projetos_e_de_equipes.indb 22 28/5/2007 15:28:29

Iniciais do ttulo em ingls Critical

gestao_de_projetos_e_de_equipes.indb 32 28/5/2007 15:28:32

gestao_de_projetos_e_de_equipes.indb 35 28/5/2007 15:28:33

Perceber que os projetos ocupam uma posio

Reconhecer os principais tipos de projeto e analisar as

Verifcar que a inovao tecnolgica um processo que

gestao_de_projetos_e_de_equipes.indb 49 28/5/2007 15:28:36

gestao_de_projetos_e_de_equipes.indb 51 28/5/2007 15:28:36

gestao_de_projetos_e_de_equipes.indb 52 28/5/2007 15:28:36

gestao_de_projetos_e_de_equipes.indb 55 28/5/2007 15:28:37

gestao_de_projetos_e_de_equipes.indb 60 28/5/2007 15:28:38

gestao_de_projetos_e_de_equipes.indb 63 28/5/2007 15:28:39

gestao_de_projetos_e_de_equipes.indb 64 28/5/2007 15:28:39

gestao_de_projetos_e_de_equipes.indb 68 28/5/2007 15:28:40

Cabe aqui ressaltar que a Unisul

gestao_de_projetos_e_de_equipes.indb 72 28/5/2007 15:28:41

gestao_de_projetos_e_de_equipes.indb 73 28/5/2007 15:28:41

gestao_de_projetos_e_de_equipes.indb 74 28/5/2007 15:28:41

gestao_de_projetos_e_de_equipes.indb 75 28/5/2007 15:28:41

gestao_de_projetos_e_de_equipes.indb 76 28/5/2007 15:28:41

Perceber que as requisies do cliente, seja externo, interno

Compreender questes prticas quanto viabilidade

Verifcar itens fundamentais como recursos, custos,

gestao_de_projetos_e_de_equipes.indb 87 28/5/2007 15:28:43

gestao_de_projetos_e_de_equipes.indb 88 28/5/2007 15:28:43

gestao_de_projetos_e_de_equipes.indb 95 28/5/2007 15:28:45

gestao_de_projetos_e_de_equipes.indb 96 28/5/2007 15:28:45

gestao_de_projetos_e_de_equipes.indb 97 28/5/2007 15:28:45

gestao_de_projetos_e_de_equipes.indb 98 28/5/2007 15:28:46

gestao_de_projetos_e_de_equipes.indb 100 28/5/2007 15:28:46

gestao_de_projetos_e_de_equipes.indb 101 28/5/2007 15:28:46

gestao_de_projetos_e_de_equipes.indb 102 28/5/2007 15:28:47

gestao_de_projetos_e_de_equipes.indb 103 28/5/2007 15:28:47

gestao_de_projetos_e_de_equipes.indb 104 28/5/2007 15:28:47

Esses so outros softwares de gesto disponveis no mercado, mas

Open Project System.

gestao_de_projetos_e_de_equipes.indb 108 28/5/2007 15:28:48

gestao_de_projetos_e_de_equipes.indb 112 28/5/2007 15:28:48

O projeto pode trazer tambm uma srie de benefcios cuja

Para obter outras

Se decalcou, poderia cortar

Leis de Murphy - continuao

gestao_de_projetos_e_de_equipes.indb 123 28/5/2007 15:28:51

quais so as vantagens mensurveis que o projeto trar?

quais so os valores comparativos?

que vantagens intangveis ele trar?

como se poder vericar?

quais os recursos materiais necessrios para o projeto?

esses recursos esto disponveis?

caso no disponveis, possvel obt-los?

quais os recursos humanos necessrios para o projeto?

essas pessoas esto disponveis para o projeto?

caso no disponveis, h outras pessoas para substitu-las?

considerando os recursos necessrios, quanto dinheiro ser

esse montante est disponvel?