Gestao de Projetos e Equipes - Livro - Completo

Universidade do Sul de Santa Catarina
Gestão de Projetos e de Equipes

Disciplina na modalidade a distância
3ª edição revista e atualizada
Palhoça
UnisulVirtual
2006
gestao_de_projetos_e_de_equipes.indb 1 28/5/2007 15:27:26

Apresentação
Este livro didático corresponde à disciplina de Gestão de Projetos

e de Equipes.
O material foi elaborado visando a uma aprendizagem autônoma,

abordando conteúdos especialmente selecionados e adotando uma
linguagem que facilite seu estudo a distância.
Por falar em distância, isso não significa que você estará sozinho.
Não esqueça que sua caminhada nesta disciplina também
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

Livro didático
Design instrucional
Daniela Erani Monteiro Will
Maria Isabel Orofino
3ª edição revista e atualizada
Palhoça
UnisulVirtual
2006

Copyright © UnisulVirtual 2006
Nenhuma parte desta publicação pode ser reproduzida por qualquer meio sem a prévia autorização desta instituição.
658.404
F12 Faccioni Filho, Mauro
Gestão de projetos e de equipes : livro didático / Mauro Faccioni Filho ; design
instrucional Daniela Erani Monteiro Will, Maria Isabel Orofino; [Flavia Lumi
Matuzawa, Karla Leonora Dahse Nunes, Leandro Kingeski Pacheco] — 3. ed. rev. e
atual – Palhoça : UnisulVirtual, 2006.
295 p. : il. ; 28 cm.
Inclui bibliografia.
1. Administração de projetos. I. Will, Daniela Erani Monteiro. II. Matuzawa,

Flavia Lumi. III. Nunes, Karla Leonora Dahse. IV. Pacheco, Leandro Kingeski. V. Título.
Ficha catalográfica elaborada pela Biblioteca Universitária da Unisul
Créditos
Unisul - Universidade do Sul de Santa Catarina
UnisulVirtual - Educação Superior a Distância
Campus UnisulVirtual Charles Cesconetto Silvana Denise Guimarães Djeime Sammer Bortolotti
Rua João Pereira dos Santos, 303 Diva Marília Flemming Tade-Ane de Amorim Carla Cristina Sbardella
Palhoça - SC - 88130-475 Elisa Flemming Luz Vanessa de Andrade Manuel Grasiela Martins
Fone/fax: (48) 3279-1541 e 3279-1542 Itamar Pedro Bevilaqua Vanessa Francine Corrêa James Marcel Silva Ribeiro
E-mail: cursovirtual@unisul.br Janete Elza Felisbino Viviane Bastos Lamuniê Souza
Site: www.virtual.unisul.br Jucimara Roesler Viviani Poyer Liana Pamplona
Lauro José Ballock Maira Marina Martins Godinho
Reitor Unisul Luiz Guilherme Buchmann Figueiredo Logística de Encontros Presenciais Marcelo Pereira
Gerson Luiz Joner da Silveira Luiz Otávio Botelho Lento Caroline Batista (Coordenadora) Marcos Alcides Medeiros Junior
Marcelo Cavalcanti Aracelli Araldi Maria Isabel Aragon
Vice-Reitor e Pró-Reitor Acadêmico Mauri Luiz Heerdt Graciele Marinês Lindenmayr Olavo Lajús
Sebastião Salésio Heerdt Mauro Faccioni Filho José Carlos Teixeira Priscilla Geovana Pagani
Nélio Herzmann Letícia Cristina Pinheiro Silvana Henrique Silva
Chefe de gabinete da Reitoria Onei Tadeu Dutra Kênia Alexandra Costa Hermann
Fabian Martins de Castro Patrícia Alberton Marcia Luz de Oliveira Secretária Executiva
Patrícia Pozza Priscila Santos Alves Viviane Schalata Martins
Pró-Reitor Administrativo Rafael Peteffi da Silva
Marcus Vinícius Anátoles da Silva Ferreira Raulino Jacó Brüning Logística de Materiais Tecnologia
Jeferson Cassiano Almeida da Costa Osmar de Oliveira Braz Júnior
Campus Tubarão e Araranguá Design Gráfico (coordenador) (coordenador)
Diretor: Valter Alves Schmitz Neto Cristiano Neri Gonçalves Ribeiro Eduardo Kraus Ricardo Alexandre Bianchini
Diretora adjunta: Alexandra Orseni (coordenador) Rodrigo de Barcelos Martins
Adriana Ferreira dos Santos Monitoria e Suporte
Campus Grande Florianópolis e Alex Sandro Xavier Rafael da Cunha Lara (coordenador)
Norte da Ilha Evandro Guedes Machado Adriana Silveira Edição – Livro Didático
Diretor: Ailton Nazareno Soares Fernando Roberto Dias Zimmermann Caroline Mendonça
Diretora adjunta: Cibele Schuelter Higor Ghisi Luciano Edison Rodrigo Valim Professor Conteudista
Pedro Paulo Alves Teixeira Francielle Arruda Mauro Faccioni Filho
Campus UnisulVirtual Rafael Pessi Gabriela Malinverni Barbieri
Diretor: João Vianney Vilson Martins Filho Gislane Frasson de Souza Design Instrucional
Diretora adjunta: Jucimara Roesler Josiane Conceição Leal Daniela Erani Monteiro Will
Equipe Didático-Pedagógica Maria Eugênia Ferreira Celeghin Maria Isabel Orofino
Angelita Marçal Flores Simone Andréa de Castilho Flavia Lumi Matuzawa (2ª ed. rev.)
Equipe UnisulVirtual Carmen Maria Cipriani Pandini Vinícius Maycot Serafim Leandro Kingeski Pacheco (3ª ed.
Carolina Hoeller da Silva Boeing rev. e atual.)
Administração Cristina Klipp de Oliveira Produção Industrial e Suporte
Renato André Luz Daniela Erani Monteiro Will Arthur Emmanuel F. Silveira (coordenador) Projeto Gráfico e Capa
Valmir Venício Inácio Dênia Falcão de Bittencourt Francisco Asp Equipe UnisulVirtual
Elisa Flemming Luz
Bibliotecária Enzo de Oliveira Moreira Projetos Corporativos Diagramação
Soraya Arruda Waltrick Flávia Lumi Matuzawa Diane Dal Mago Rafael Pessi
Karla Leonora Dahse Nunes Vanderlei Brasil
Coordenação dos Cursos Leandro Kingeski Pacheco Revisão Ortográfica
Adriano Sérgio da Cunha Ligia Maria Soufen Tumolo Secretaria de Ensino a Distância Revisare
Ana Luisa Mülbert Márcia Loch Karine Augusta Zanoni
Ana Paula Reusing Pacheco Patrícia Meneghel (secretária de ensino)

Sumário
Palavras do professor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Plano de estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11
UNIDADE 1 – Introdução à gestão de projetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

SEÇÃO 1 – História e evolução da gestão de projetos . . . . . . . . . . . . . 18
SEÇÃO 2 – O que é Projeto? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
SEÇÃO 3 – O que é Gestão? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
SEÇÃO 4 – Prazo, Recursos, Custos e Grupos de Trabalho . . . . . . . . . . 36
UNIDADE 2 – Nascimento do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45

SEÇÃO 1 – Inovação tecnológica: fonte de novos projetos . . . . . . . . 46
SEÇÃO 2 – Identificando oportunidades . . . . . . . . . . . . . . . . . . . . . . . . . . 59
SEÇÃO 3 – Motivação para o projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
SEÇÃO 4 – Quais são os tipos de projeto? . . . . . . . . . . . . . . . . . . . . . . . . . 67
UNIDADE 3 – Visão geral do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83

SEÇÃO 1 – Identificação e avaliação inicial . . . . . . . . . . . . . . . . . . . . . . . . 85
SEÇÃO 2 – Requisitos do cliente e solução de problemas . . . . . . . . . 96
SEÇÃO 3 – Algoritmo do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
SEÇÃO 4 – Prazo geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
SEÇÃO 5 – Viabilidade do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
SEÇÃO 6 – Antecipando e administrando riscos . . . . . . . . . . . . . . . . . . 125
UNIDADE 4 – Planejamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

SEÇÃO 1 – Modelagem do fluxo de atividades . . . . . . . . . . . . . . . . . . . 143
SEÇÃO 2 – Metodologias de planejamento – Gráfico de Gantt . . . 153
SEÇÃO 3 – Metodologias de planejamento – PERT/CPM . . . . . . . . . . 168
SEÇÃO 4 – Estimativa de recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
SEÇÃO 5 – Estimativa de custos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
UNIDADE 5 – Estruturando a equipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

SEÇÃO 1 – Estruturando a equipe .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
SEÇÃO 2 – Recursos humanos e perfis . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
SEÇÃO 3 – Treinamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
SEÇÃO 4 – Responsabilidade e divisão de tarefas . . . . . . . . . . . . . . . . 213
SEÇÃO 5 – Terceirização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218

UNIDADE 6 – Executando o projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
SEÇÃO 1 – Preparação e início dos trabalhos . . . . . . . . . . . . . . . . . . . . . 230
SEÇÃO 2 – Liderança versus gestão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
SEÇÃO 3 – Tomada de decisões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
SEÇÃO 4 – Motivação e comunicação . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
SEÇÃO 5 – Reuniões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
SEÇÃO 6 – Gerenciando qualidade, tempo e recursos . . . . . . . . . . . . 247
SEÇÃO 7 – Gestão de conflitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
SEÇÃO 8 – Simulação, testes e validação . . . . . . . . . . . . . . . . . . . . . . . . . 253
UNIDADE 7 – Finalizando o projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

SEÇÃO 1 – Fase de finalização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
SEÇÃO 2 – Planos de contingência em caso de problemas . . . . . . . 262
SEÇÃO 3 – Atendendo as expectativas do cliente . . . . . . . . . . . . . . . . 264
SEÇÃO 4 – Sobre o sucesso (ou fracasso) do projeto . . . . . . . . . . . . . 265
SEÇÃO 5 – Desfazendo a equipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
SEÇÃO 6 – Documentação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
SEÇÃO 7 – Lições aprendidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
SEÇÃO 8 – Idéias para um novo projeto . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Para concluir o estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281

Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Sobre o professor conteudista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
Respostas e comentários das atividades de auto-avaliação . . . . . . . . . . . . . . . 287

Palavras do professor
Os livros dedicados à gestão de projetos dividem-se

basicamente em dois tipos: aqueles que listam uma
série de técnicas práticas de planejamento, e aqueles que
discutem teoricamente a disciplina de gestão.
Os do primeiro tipo acreditam que simplesmente

aplicando alguma metodologia pré-concebida de gestão
será possível gerenciar um projeto com eficiência e
eficácia. Baseiam-se em métodos e técnicas - uma série
imensa de planilhas e relatórios - e mais recentemente
dedicam-se a explicar e implantar ferramentas
computacionais.
Os do segundo tipo analisam a gestão como uma

disciplina capaz de apoiar e beneficiar aqueles que se
dedicam ao planejamento e ao desenvolvimento de
projetos, mas carecem de uma real experiência em
diferentes tipos de projetos, os quais envolvem sempre
um agente essencialmente subjetivo: o ser humano.
Este livro didático explora esse assunto de uma outra

forma. Aqui o foco será essencialmente na aprendizagem
e na discussão que gera um tipo de conhecimento que
pode e deve ser útil aos que se interessam pelo tema.
Neste sentido este não é um livro puramente acadêmico,
com unidades e seções que apresentam teorias e exemplos
desvinculados da realidade e de uma visão aplicada aos
negócios e aos trabalhos práticos. Sem dúvida muitas
questões aqui colocadas vieram de pesquisas e análises
acadêmicas, porém estão sempre focadas em aplicações.

A idéia central desta disciplina é discorrer sobre as principais
teorias de gestão de projetos e de equipes, mas com o olhar
voltado às aplicações e ao nível estratégico. A palavra “gestão”
está intimamente relacionada à função de “gerência”, como
veremos, e a gerência se assemelha a uma função operacional
voltada ao controle. Mas em projetos isso não funciona. O
melhor foco para a gestão de projetos deve estar colocado no
conceito de liderança, pois a liderança submete a gestão, e não o
inverso.
Com essas palavras iniciais gostaria então de convidá-lo a

essa aventura do conhecimento – o estudo dos projetos, sua
organização, planejamento e, acima de tudo, trabalho de redes
sociais participativas e cooperativas. Bom estudo!
Professor Mauro Faccioni Filho.
10

Plano de estudo
O plano de estudos visa a orientá-lo/a no desenvolvimento da

Disciplina. Nele, você encontrará elementos que esclarecerão
o contexto da Disciplina e sugerirão 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 construção de competências se dá sobre a articulação
de metodologias e por meio das diversas formas de ação/
mediação.
São elementos desse processo:
o livro didático;
o Espaço UnisulVirtual de Aprendizagem – EVA;
as atividades de avaliação (complementares, a distância
e presenciais);
o Sistema Tutorial.
Ementa
Análise de requisitos do cliente. Análise de custos, recursos
e prazos. Descrição do escopo do problema. Planejamento e
gestão de recursos materiais e humanos. Divisão de tarefas
e etapas, considerando riscos. Criação de plano com fluxo
de trabalho e sincronismo de equipe e recursos. Controle da
qualidade em projetos para Web. Encerramento de projetos.
Verificação da satisfação do cliente. Feedback.

Objetivo geral
Apresentar os conceitos básicos da área de gestão de
projetos.
Fornecer subsídios para a avaliação de riscos de um
projeto, com ênfase nos projetos de base tecnológica.
Apresentar técnicas de planejamento, execução e
controle de projetos, formação de equipes e seu
gerenciamento de reuniões.
Descrever um modelo para gestão de projetos.
Verificação dos softwares disponíveis para auxílio no
gerenciamento de projetos.
Utilização de software livre para gestão de projetos.
Conteúdo programático
Unidade 1: Introdução à gestão de projetos

Apresentação da história e evolução dos grandes projetos
desenvolvidos pelo homem, e como surgiu a disciplina de Gestão
de Projetos para gerenciar esse tipo especial de trabalho. Nesta
unidade são apresentados os conceitos fundamentais da disciplina
de gestão de projeto e equipes.
Unidade 2: Nascimento do projeto

O papel da inovação tecnológica como geradora de projetos é
discutido, e os diferentes tipos de inovação são apresentados.
Oportunidades de projetos podem surgir de descobertas
científicas, invenções ou de inovações tecnológicas, mas é preciso
motivação para o seu desenvolvimento. Nesta unidade são ainda
apresentadas as diversas classificações de projetos, segundo
diferentes propósitos e diferentes visões.
12

Unidade 3: Visão geral do projeto

Os primeiros passos de um projeto são descritos, o que inclui
o levantamento de requisitos do cliente e os problemas a serem
solucionados. Descreve-se um modelo genérico de algoritmo para
o planejamento e realização de projetos, e fatores como prazo,
viabilidade e riscos são apresentados e discutidos.
Unidade 4: Planejamento
As principais metodologias de planejamento de projeto são
apresentadas nesta unidade, bem como técnicas para sua aplicação
em problemas práticos. Métodos como Gráfico de Gantt, PERT/
CPM, estimativa de recursos e cronogramas físico-financeiros são
desenvolvidos e aplicados em projetos típicos.
Unidade 5: Estruturando a equipe

A formação da equipe, descrição dos principais perfis e
organização dos recursos humanos para o trabalho em projetos é
o tema desta unidade. Problemas como terceirização, treinamento
e métodos para dividir tarefas são estudados e as teorias sobre o
assunto são apresentadas.
Unidade 6: Executando o projeto

Unidade que reúne os temas relacionados ao dia a dia dos
projetos, desde o comportamento da liderança, tomada de
decisões, estruturação de reuniões, gestão de conflitos e aspectos
diversos como motivação da equipe e gestão da qualidade.
Como projetos são atividades com prazo definido, são descritos
passos intermediários com simulação, testes e validação como
ferramentas de ajuste e melhoria contínua dos projetos e dos seus
resultados.
Unidade 7: Finalizando o projeto

Unidade que relata as atividades de encerramento do projeto, os
planos de contingência em caso de problemas, e aspectos relativos
às demandas originais do cliente, verificando então o sucesso (ou
fracasso) da empreitada. Mostra ainda que lições serão aprendidas
no decorrer do trabalho, e que sem dúvida idéias para novos
projetos deverão surgir.
13

Agenda de atividades/ Cronograma

Verifique com atenção o EVA, organize-se para acessar
periodicamente o espaço da Disciplina. O sucesso nos
seus estudos depende da priorização do tempo para a
leitura; da realização de análises e sínteses do conteúdo; e
da interação com os seus colegas e tutor.
Não perca os prazos das atividades. Registre no espaço

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.
14

Atividades atividades
Demais atividades (registro pessoal)
15

1
UNIDADE 1
Introdução à gestão de projetos
Objetivos de aprendizagem
Compreender diferenças entre projetos e atividades
rotineiras e contínuas.
Verificar um breve histórico dos projetos e de sua gestão.
Analisar a evolução da gestão de projetos e de equipes

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

e gestão.
Seções de estudo
Seção 1 História e evolução da gestão de projetos.
Seção 2 O que é Projeto?
Seção 3 O que é Gestão?
Seção 4 Prazo, Recursos, Custos e Grupos de
Trabalho.

Para início de conversa

Você acabou de ler nas palavras iniciais deste livro que projetos
são atividades feitas geralmente por grupos de pessoas em
trabalho cooperativo. Para dar continuidade a esta reflexão, você
poderá agora aprofundar seus conhecimentos sobre o que são
projetos e por que eles se destacam como atividade especial.
Esta unidade apresenta em sua primeira seção um breve

histórico sobre projetos e como eles assumiram importância
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 magníficas do ser
humano. Como disciplina de estudo, no entanto, tem não mais
do que cem anos.
Na segunda seção são enfocados os principais conceitos da

matéria e diversos exemplos e contra-exemplos são apresentados
para que você exercite o seu entendimento.
Pretendo que este trabalho sirva de estímulo ao desenvolvimento

de novos e bem planejados projetos, pois, como já ouvi certa vez,
“o planejamento é a mãe da sorte”.
Bom estudo, bom planejamento e boa sorte!
SEÇÃO 1 – História e evolução da gestão de projetos

Todo mundo tem uma noção do que seja um projeto. Você,
com certeza, deve ter uma.
A palavra projeto é muito comum e está presente nos

diálogos de todos os dias. Porém, os conceitos que se
formaram à sua volta são bastante distintos de uma
pessoa para a outra, e isso acontece porque o uso
convencional dessa palavra varia de situação a situação.
Mas antes de começar a discutir o conceito de projeto, e acima

disso o que é a sua gestão, como se formam as equipes, que
métodos e que ferramentas podemos usar, é importante que você
18

conheça a origem desta forma de trabalho e como ela vem se

modificando ao longo da história.
Mas qual é a origem dos projetos como forma de

organização do trabalho?
Na história da humanidade o trabalho foi se organizando

lentamente. Tribos nômades andavam pelo planeta há
milhares de anos, buscando todos os dias o alimento diário
e lutando contra as intempéries, contra os animais, contra as
doenças e todas as dificuldades. Justamente como os animais
fazem até hoje.
Com a invenção de alguns artefatos e com a domesticação dos

animais, o ser humano passou de nômade a sedentário, começou
a construir habitações e aglomerados de casas, formando então
aldeias, vilas e cidades. O arranjo do trabalho se modificou, e
não tendo mais que buscar o alimento por meio da caça, passou
a produzi-lo e estocá-lo. Alguns passaram a deter mais poder
do que outros, começaram a poupar objetos de valor, terras,
ampliando os domínios terrestres e até mesmo um patrimônio
sobre as questões espirituais.
Por essa época surgem alguns empreendimentos que deviam

marcar a presença dessas pessoas poderosas, deixar para sempre
suas marcas sobre a Terra.
Não é preciso avançar muito e você vai se lembrar das

pirâmides do Egito, obras realizadas para sepultar
os faraós, considerados deuses. Acompanhe a seguir
mais informações.
Com esse propósito específico de sepultamento, a pirâmide

era encomendada pelo próprio faraó (que iria usá-la após a
morte!) e então projetistas e construtores desenvolviam seu
desenho e passavam a executar a obra. O prazo da execução
era aproximadamente o da duração da vida do faraó, ou
preferivelmente menor, obviamente. Milhares de homens
formavam as equipes e literalmente eram “usados” na construção,
quebrando e carregando pedras até a exaustão. Além dos faraós
muitos homens ricos encomendavam suas próprias pirâmides,
Unidade 1 19

cada um na medida das suas riquezas. Muitas não ficavam

prontas a tempo, e vinham então servir para o sepultamento de
alguma outra pessoa.
Figura 1.1 - As três pirâmides do Egito, dos Faraós Quéops, Quéfren

e Miquerinos.
As pirâmides eram tipicamente “projetos”. Em outras culturas,

como a dos Maias e dos Incas, assim como a dos Astecas, as
pirâmides eram construídas para cultos religiosos e sacrifícios,
e da mesma forma eram encomendadas e construídas com mão-
de-obra escrava, tendo grupos de comando e um prazo definido
para entrega.
Uma das mais interessantes e importantes obras já

feita pelo ser humano, começou a ser construída
685 anos antes da Era Cristã (685 AC). As Grandes
Muralhas da China tiveram seu início com a
pretensão de defesa de diferentes reinos, naquela
época em luta pela expansão dos seus territórios
(COURAU, 2004).
20

Não 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 Origem do nome atual da
os outros reinos, unificando todos eles. E em 220 AC decidiu China.
realizar essa obra gigantesca, ligando os trechos de muralhas
existentes e criando de fato as Grandes Muralhas da China.
E qual era a intenção ao construir essa obra?
Com o objetivo de separar o país dos bárbaros, e internamente

definir a unidade da nação e a civilização, a obra teve um prazo
de aproximadamente 10 anos de construção, uma extensão de
mais de 6.000 quilômetros de muros com altura de até 16 metros
e fortificações para soldados a cada 60 metros, recursos humanos
da ordem de centenas de milhares de operários em regime de
trabalho forçado e um plano de produção rígido (na verdade,
cruel), esse é um típico projeto, evidentemente impossível de se
realizar hoje em dia.
Figura 1.2 - A Grande Muralha da China, projeto de mais de dois mil

anos atrás. (COURAU, 2004)
Unidade 1 21

Enquanto a China buscava unificar seu território e criar

uma verdadeira civilização, mais a oeste outro império
se desenvolvia e seria praticamente uma das bases da
nossa civilização ocidental: o Império Romano.
Desde Júlio César, o Império Romano cresceu incessantemente,

chegando a fazer divisa com o Império Chinês. Os romanos
são conhecidos por seus grandes projetos civilizatórios, e muitas
das obras que resultaram desses projetos resistem até hoje. Você
certamente se lembra do Coliseu, aquela grande arena construída
em Roma para festejos, lutas entre gladiadores e espetáculos.
Durante centenas de anos o Coliseu foi utilizado nessas
atividades, que entraram em sua rotina, porém houve, antes de
tudo, o projeto de sua construção.
Também outros projetos importantíssimos foram desenvolvidos

pelos romanos, mas não para diversão e sim para melhoria das
cidades, como:
os aquedutos;
as estradas calçadas em pedras, que cruzaram a Europa
em todas as direções e que até hoje têm alguns trechos
mantidas (quando as pedras não foram roubadas!).
Um outro caso de projeto muito interessante foi desenvolvido

na fronteira norte do Império Romano. A ilha onde hoje
está a Inglaterra foi dominada pelos romanos (que por sinal
fundaram Londres), porém a extremidade norte da Bretanha
não foi conquistada (é a região onde hoje está a Escócia). Os
romanos buscavam marcar suas divisas com os territórios não
conquistados, e criavam fortificações, geralmente tendo rios como
elementos divisores. Os rios dificultavam a invasão dos bárbaros.
Porém, ao norte da Bretanha não 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 correligionários: construir uma
Muralha fortificada, 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 Atlântico, a oeste. Esse muro era
de aproximadamente 117 quilômetros, construído em pedra, com
22

portões fortificados e 16 fortes para soldados, distribuídos ao

longo do Muro. Com o exíguo prazo de 6 anos para construção,
o projeto foi sendo modificado durante as obras, e muitas vezes
a edificação em pedra foi substituída por barro misturado com
galhos. Tipicamente resultado de alterações de prazo de projeto,
e também da dificuldade de obter recursos materiais (as pedras
eram raras na região), a substituição por barro criou pontos falhos
na obra, que posteriormente tiveram de ser corrigidos.
Como você vai ver adiante, problemas no dia-a-dia da execução

dos projetos são muito comuns. Tão comuns, que vai chegar um
momento na história que algumas metodologias serão criadas
para tentar controlar esses problemas. Mas sobre isso, você vai
aprofundar o estudo nas próximas unidades.
Figura 1.3 - Portão fortificado nas Muralhas de Adriano (representação, em demonstração

no Hadrian’s Wall Museum).
Os projetos da Antigüidade citados até agora (as pirâmides, as

muralhas) referem-se a grandes obras. Mas houve outros tipos de
projetos, alguns muito bem-sucedidos.
Os gregos fundaram a civilização ocidental,

colocando as bases da nossa cultura, filosofia e
ciência.
Uma das mais importantes obras literárias de todos os tempos, o

poema Ilíada, de Homero, descreve um projeto elaborado pelos
combatentes gregos para tentar invadir e dominar a lendária
cidade de Tróia. Em guerra contra os troianos, os gregos sitiaram
por dez anos a cidade de Tróia, sem conseguir invadi-la.
Unidade 1 23

Agamenon, chefe dos gregos, arquitetou então um projeto que

consistia em construir um cavalo de madeira gigante (a primeira
etapa) e colocá-lo em frente aos portões de Tróia 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 portões e trouxeram
para a praça central da cidade. A terceira etapa do projeto
de Agamenon estava concluída. Naquela noite, quando todos
dormiam, os soldados gregos que estavam dentro do cavalo,
escondidos, saíram e abriram os portões da cidade, permitindo
que o exército grego entrasse e vencesse finalmente a batalha.
Quarta etapa concluída!
Figura 1.4 - O Cavalo de Tróia sendo puxado para dentro da cidade, segundo o pintor
Giovanni Battista Tiepolo.
Muitos desses projetos tiveram um prazo bem definido (mesmo

que longo) com objetivos diretos e quase sempre ligados às guerras.
Você sabia?
Passados muitos séculos, já no final da Idade Média e
quando os países ocidentais começaram a se definir
como nações, houve um país que ficou com uma área
territorial muito restrita, impedindo seu crescimento
e riqueza.
Deu-se início então a um enorme projeto, que na
verdade ficou dividido em inúmeros subprojetos, que
consistiram em aumentar o território da Holanda,
conquistando espaço do mar. Como?
24

Imensas regiões 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 então
não era apropriado para a agricultura.
O projeto de conquista de terras consistiu em criar uma divisa

entre terra e mar (barreiras), criando regiões alagadas. No interior
dessas regiões, chamados polders, eram construídos diversos
canais para drenar a água até um dique. Esse dique então
bombeava a água de volta ao mar. Inicialmente com o auxílio
de moinhos de vento (imagem que popularizou a Holanda),
atualmente o bombeamento é feito com motores elétricos e não
mais com a força do vento. Inúmeros diques foram construídos,
fazendo parte de um grande projeto que hoje garante à Holanda
40% do seu território (em áreas muito férteis!).
Esses exemplos de grandes projetos da Antigüidade mudaram

a história da humanidade e a maneira dos seres humanos agirem
uns em relação aos outros e em relação à natureza. Pessoas
envolvidas nesses projetos começaram a perceber algumas
características típicas de um projeto, que eram diferentes, por
exemplo, de uma tarefa rotineira como a manutenção do dique,
o dia-a-dia das batalhas, ou das tarefas administrativas de
condução da política imperial romana ou chinesa.
Projetos têm objetivos definidos e prazo de conclusão

e, para que isso aconteça com sucesso, é preciso
conduzir, coordenar e controlar um projeto e as
pessoas que o integram.
Com toda essa experiência prática, acumulada em tantos projetos

ao longo da história, não tardou para alguns pensadores se
voltassem para esse tipo de produção, e começassem 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 começam a se
desenvolver projetos com uma outra mentalidade, especialmente
com o advento da revolução industrial, no século 18.
Unidade 1 25

Um pouco depois, durante o século 19, os governos dos países

mais desenvolvidos começaram a contratar grandes projetos
de infra-estrutura, tais como ferrovias, pontes, embarcações
etc, demandando enormes esforços das companhias para a seu
execução, com valores financeiros e prazos pré-definidos.
Decisões importantes deviam ser tomadas nos projetos, para

que atendessem às solicitações desses grandes clientes, e tais
decisões eram gerenciais, administrativas. Não era mais possível
escravizar milhares de homens para construir uma estrada, como
tantas vezes na história já tinha acontecido. E também não havia
fundos ilimitados. E a gestão desses projetos tinha que seguir
algum tipo de planejamento.
Um cientista da administração surge nessa época e começa

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 ciência da administração
(SISK, 2004).
Com a sua contribuição, a indústria pôde modificar 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 são feitos em série.
Fundamental para a revolução

industrial em curso, a contribuição
de Taylor também teve seu
lado negativo, transformando
o trabalhador numa espécie de
máquina, de engrenagem dentro
do processo produtivo, que tem
sido sempre muito criticada e
satirizada, como no filme “Tempos
Modernos” de 1936 de Charlie Chaplin – o Carlitos.
26

Junto com Taylor trabalhava Henry Gantt (1861-1919), que

estudou em detalhes as operações associadas a um trabalho,
decompondo-as em etapas. Para ver as diversas etapas em
seqüência, e como elas vão se sucedendo até o final de um
determinado projeto, Gantt inventou um gráfico constituído de
barras, sendo que cada barra representa uma etapa e seu tamanho
representa uma duração.
Os gráficos de Gantt ficaram famosíssimos e até hoje são

usados para gerenciar projetos. Você vai estudar esses gráficos
em detalhe, mais à frente nesta disciplina, e vai ver como eles
poderão lhe ajudar a gerenciar futuros projetos.
Veja na figura a seguir um exemplo de gráfico de

Gantt.
Figura 1.5 – Exemplo de gráfico de Gantt.
Durante a Segunda Guerra Mundial, muitos projetos

tecnológicos foram desenvolvidos pelos militares dos
países em luta.
Sabemos do desenvolvimento dos mísseis; o que posteriormente

levou à conquista do espaço, de vários tipos de aviões, de bombas,
de tratamentos etc.
Com o fim da guerra, ficou evidente que havia um campo do

conhecimento específico da administração de projetos, que ficou
conhecido em inglês por project management; e em português
por gestão de projetos.
Unidade 1 27

A maior associação mundial de engenheiros eletrônicos e

eletricistas, o Institute of Electrical and Electronic Engineers
(IEEE), criou em 1954 a revista Transactions on Engineering
Management especialmente para discutir temas relacionados
à gestão de projetos e produção em engenharia, que tem
influenciado consideravelmente a área.
Também nos anos 50 surgem dois métodos que se tornaram

muito importantes na “gestão de projetos”, disciplina que
passou a fazer parte de todos os currículos de Administração e
Engenharia de Produção desde então (PRADO, 1998). Veja a
seguir quais são:
O primeiro surgiu na empresa Du Pont em 1957, com

o título de Método do Caminho Crítico (CPM). A
Iniciais do título em inglês Critical empresa buscava melhorar suas técnicas de planejamento
Path Method - CPM. e controle de projetos de engenharia, e o método fez
enorme sucesso desde o início.
O segundo foi desenvolvido quase simultaneamente,
quando a marinha americana lançou um projeto
complexo para a construção de submarinos atômicos,
o projeto Polaris. Devido à complexidade do projeto,
ao relacionamento de diversas empresas (eram mais
de 9.000 empreiteiros!), e à complexidade tecnológica
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 significa “técnica de avaliação e
revisão de programas/projetos”.
Na época uma pesquisa foi realizada nos EUA para verificar

como se comportavam os projetos governamentais e privados,
com relação ao que era planejado e ao efetivamente realizado. O
quadro a seguir mostra os desvios encontrados (PRADO, 1998).
28

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 orçamento
e em apenas três anos. A partir daí, os métodos PERT e CPM
acabaram se fundindo e assumindo inclusive o formato de
Diagrama de Precedências, técnica desenvolvida na França em
1964 (PRADO, 1998).
- Você vai estudá-lo e exercitá-lo no decorrer desta disciplina.
A evolução dos sistemas computacionais na segunda metade do

século vinte é que vai contribuir para a melhoria dos métodos
de gestão de projetos, mesmo porque os próprios sistemas
computacionais são desenvolvidos na forma de projetos, e por
isso demandam técnicas de planejamento e controle específicos.
Normas começaram a ser escritas para a gestão de projetos, e
nos EUA foi criado o “Instituto de Gestão de Projetos” – Project
Management Institute (PMI), tem sido responsável pelas mais
recentes e importantes contribuições neste campo, especialmente
o livro “Guide to the Project Management Body of Knowledge”,
conhecido como PMBOK (PMBOK, 2004).
Unidade 1 29

Figura 1.6 – Logo do instituto PMI e fac-símile da capa da 3ª edição do PMBOK.
Uma alternativa aos métodos normatizados pelo PMBOK

foi apresentada por Eliyahu Goldratt em 1997, com o nome
de Critical Chain Project Management (CCPM), que pode
ser traduzido como “gestão de projetos pelo encadeamento
crítico” (RAZ, 2004). Isso demonstra o quanto ainda está em
desenvolvimento a área da gestão de projetos.
Mas se você pensa que o uso de gráficos de Gantt, Caminho

Crítico, PERT, CCPM e outros métodos resolveram o problema,
infelizmente está enganado. No ano de 1998 o The 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 estão no quadro a seguir e nos
mostram o quanto ainda há por fazer.
Quadro 1.2 – Estatísticas apresentando problemas típicos de projetos.
Desafios e sintomas típicos de projetos Média nacional EUA (1998)
Apenas 44% dos projetos são concluídos

Atraso no prazo. Na média os projetos costumam
atrasar em até 222% do prazo programado.
Acima do custo estimado. 189%.
Não atingem satisfatoriamente os requisitos 70% dos projetos.

técnicos planejados.
Cancelados antes do término. 30% dos projetos.
30

A rápida evolução da computação, especialmente da

década de 1990 em diante, e também das tecnologias
da comunicação e informação, onde a Internet é o
maior símbolo, representa um novo desafio. Com
este desafio em mente é que esta disciplina foi
construída.
Com este breve histórico sobre projetos e sobre a crescente

necessidade de seu gerenciamento, espero que você tenha uma
primeira visão a respeito do “que é um projeto”, como ele se
diferencia de outras atividades humanas, e também sobre a
importância de um sistema de planejamento e controle para
conseguir obter sucesso.
Nas próximas seções, você vai conhecer alguns conceitos que vão
estar presentes em toda a disciplina e que certamente vão ajudá-lo
muito, seja em seus trabalhos educacionais ou profissionais.
Para discutir e estudar Gestão de Projetos e de Equipes

é importante, antes de tudo, que você compreenda alguns
conceitos, a fim de evitar equívocos ou interpretações errôneas.
SEÇÃO 2 – O que é Projeto?
Quem nunca participou de uma conversa ou

um debate, onde se perdem horas em acalorada
discussão para, no final, se perceber que tudo
começou porque uma simples palavra foi entendida
de forma diferente pelas pessoas?
Esse problema é tão grave que um dos maiores filósofos do século

passado, Ludwig Wittgenstein, considera que boa parte das
questões filosóficas não passa do desentendimento das palavras
por parte dos que a usam. Ao mesmo tempo ele percebe que há
palavras que não podem ser entendidas igualmente por todos.
Unidade 1 31

Bem, você não vai encontrar essa discussão nesta disciplina, mas
vamos trabalhar alguns conceitos importantes e se manter perto
deles. Começemos pelo conceito de projeto.
A primeira palavra importante a considerar é, obviamente,

projeto. No histórico das grandes obras e empreendimentos
humanos que você estudou na seção anterior, pode perceber
algumas coisas em comum:
Prazos.
Objetivos.
Custos.
Recursos.
Mas a importância desses componentes foi mudando com o

tempo. Acompanhe um exemplo a seguir.
O prazo de construção das pirâmides deveria ser

menor que o tempo de vida do faraó. Mas como
isso não podia ser determinado, muitas vezes o
serviço ultrapassava do prazo. Já para o caso das
Muralhas de Adriano, o prazo de poucos anos era
absolutamente importante, para evitar as constantes
invasões, tanto é que algumas vezes eles optaram
por mudar os recursos materiais (substituíram as
pedras pela construção em barro) para ganhar tempo.
Há casos mais dramáticos, como as Muralhas da
China, onde ninguém se importava com as equipes
de construtores. Morriam trabalhando e eram
substituídos depois de exaurirem, ou seja, ninguém se
importava com os recursos humanos.
Com o passar das eras e chegando já nos tempos modernos,

o que se vê é que os objetivos ficaram mais claros e mais
especializados, os prazos cada vez mais curtos, os custos sempre
maiores e os recursos cada vez mais escassos.
32

Conforme Antônio Houaiss em seu dicionário de língua

portuguesa (2004), projeto pode ser definido como: “Idéia,
desejo, intenção de fazer ou realizar (algo), no futuro; plano;
descrição escrita e detalhada de um empreendimento a ser
realizado; delineamento, esquema.”
Para esta disciplina adotei uma visão voltada à gestão de projetos,

a qual está definida pelo Project Management Institute como:
“Um projeto é um conjunto de tarefas, arranjado

numa seqüência ou relação definida, que produz um
efeito ou saída pré-definida. Um projeto sempre tem
um começo, meio e um final.”
(“A project is a series of tasks, arranged in a defined
sequence or relationship, that produce a pre-defined
output or effect. A project always has a start, middle,
and an end.”)
É importante, ainda, que você observe que a visão 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 política, ou o projeto de salvação das
baleias, dar a volta ao mundo numa bicicleta etc.
Também é importante ter em vista que o projeto tem um ciclo

de vida bem definido, pois “um projeto sempre tem um começo,
meio e um final”.
Diferença entre projeto e tarefas de rotina / atividades contínuas

Projetos não são empreendimentos de rotina, são
empreendimentos completos e independentes (KEELING,
2002), com recursos e administração próprios.
Para exemplificar essa questão 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 não é projeto).
Unidade 1 33

Quadro 1.3 – Exemplos comparativos entre atividades de rotina e projetos.
Área Exemplo de projeto Exemplo de tarefa de rotina ou

atividade contínua
Lançamento de um restaurante Administração do restaurante
Culinária temático. temático.
Desenhar e construir um prédio Manter e operar o sistema elétrico e de
Construção civil comercial. automação do prédio.
Desenvolver novo tipo de
Eletrônica Construir telefones celulares.
condensador eletrônico.
Pesquisar planta resistente a
Agricultura Plantar e colher as safras.
determinado tipo de praga.
Pesquisar novo sistema de Suporte técnico aos usuários de
Software reconhecimento de fala. determinada plataforma.
Pelo quadro, podemos perceber que, enquanto os projetos têm

um objetivo preciso, fácil de medir e um resultado previsível,
as atividades contínuas são planejadas a longo prazo, o controle
pode mudar bastante durante o tempo, sempre procurando novas
oportunidades e mesmo outros resultados, diferentes daqueles
pensados no início.
Lançar o restaurante, por exemplo, tem apenas um

resultado: a sua inauguração. Porém sua operação
pode trazer resultados tão diferentes quanto a
mudança dos pratos, variações de cardápio conforme
o gosto dos clientes, diminuição ou aumento da
equipe conforme as vendas, mudança de gerentes, e
assim por diante.
A internet é um projeto?
Assim, como você já estudou na disciplina Introdução à Internet,
no início houve um projeto para constituir uma grande rede,
interligando computadores com finalidades bem definidas. A sua
expansão, a inclusão das transações comerciais, a interligação
de redes de pesquisa, de telecomunicações, os negócios, os
empreendimentos pessoais, enfim, todas as comunicações
que hoje usam a Internet como meio, fizeram dela uma
infra-estrutura de telecomunicações mundial. Hoje pode ser
considerada uma atividade de uso rotineiro, base para outros
projetos, que se superpõem a ela.
34

SEÇÃO 3 - O que é Gestão?

Conforme Antônio Houaiss (2004), em seu dicionário de língua
portuguesa, gestão pode ser definida como: “ato ou efeito de
gerir; administração, gerência”.
Uma característica de muitas disciplinas dedicadas à gestão 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 gerência. No entanto, disponibilizar e ensinar a usar
ferramentas e métodos de gerência é um assunto estritamente
operacional, e não estratégico. Compreendo que a simples gestão
de um projeto pode ser feita com o uso de ferramentas de apoio,
mas o sucesso de um projeto depende de liderança e cooperação,
assuntos que extrapolam, e muito, o campo operacional.
Dessa forma, olharemos sempre a palavra “gestão”

nesta disciplina visando a ir além da gerência
operacional, tentando encontrar as brechas para um
trabalho de liderança e cooperação, sempre voltadas
para uma visão abrangente e estratégica do projeto.
A gerência está associada à idéia de controle, de administração.

Para Page-Jones (1990), a gerência de projetos está associada a
cinco atividades:
planejar o projeto;
organizar todos os recursos;
integrar os diversos elementos durante a execução do
projeto;
medir o andamento das atividades e
revisar o plano para corrigir eventuais discrepâncias,
para alcançar o objetivo do projeto.
Na opinião de Valeriano (1998) há diferenças entre

administração, gerência e gestão. Para esse autor, a administração
se dá no nível da organização, como um todo. A gerência está no
Unidade 1 35

nível do projeto, enquanto a gestão seria aplicada a parcelas, ou

tópicos específicos, de um determinado projeto.
Como por exemplo, gestão da
qualidade, gestão dos documentos Nesta disciplina adotei uma definição mais genérica, que engloba
etc. essas atividades, pois assim está sendo compreendida atualmente
a função de gestão em projetos. Veja só:
A gestão de projetos compreende as funções de

planejamento, organização de recursos, distribuição
e comunicação das tarefas às pessoas da equipe, com
monitoramento constante das atividades e motivação
do grupo para a conquista do objetivo pré-definido.
SEÇÃO 4 – Prazo, Recursos, Custos e Grupos de Trabalho
Prazo
Prazo é a palavra do momento. Como você já leu, no passado
muitas vezes não havia uma preocupação com os prazos
dos projetos. Porém, hoje ela é enorme pois os recursos são
sempre escassos, e colocar um produto no mercado antes que a
concorrência pode ser o fator do sucesso ou do fracasso.
Mas justamente nos prazos é onde acontecem os

maiores erros de previsão, e não me lembro de muitos
projetos concluídos no prazo cujos resultados tenham
sido satisfatórios. Por quê?
Vamos discutir isso mais adiante. Por enquanto é importante que

você compreenda a seguinte definição de prazo:
Considerando o objetivo do projeto, prazo é o tempo

disponível para chegar ao resultado.
36

Recursos
Muitas vezes se confunde recursos com dinheiro, ou recursos
com custos. Porém vamos usar uma definição mais abrangente,
pois as condições financeiras possibilitam obter diversos recursos,
mas não todos.
Veja o caso onde se precisa de um determinado especialista, um

engenheiro de grandes estruturas, por exemplo. Mesmo com
dinheiro para pagar um, é possível que não exista alguém com
disponibilidade.
Uma definição útil é:
Recursos são as condições econômicas, materiais,

equipamentos e pessoal necessário para desenvolver
determinado projeto a contento.
Custos
Idéias maravilhosas, projetos visionários, nada disso
pode ir além se não houver condições de pagar os
custos de desenvolvimento. Recursos são necessários, os
equipamentos custam dinheiro, materiais de consumo
também, cada vez mais caras são as horas de trabalho
das pessoas e dos especialistas em particular.
Custos são os gastos financeiros necessários para

que todos os outros recursos sejam adequadamente
distribuídos no projeto, desde o início até a sua
conclusão.
Grupos de trabalho
O principal elemento de um projeto, não interessa sua dimensão
ou importância, é o conjunto de pessoas responsáveis pela sua
consecução. Isso não quer dizer que as pessoas tenham seu valor
considerado adequadamente, basta ver os exemplos históricos
que mencionamos. Impossível seria construir as Muralhas da
China sem os milhares de operários que lá estiveram. No entanto
Unidade 1 37

eles eram considerados descartáveis, trabalhavam como

escravos. Com o avanço da civilização isso mudou, e
além de imprescindível num projeto, o ser humano
passou a ter “valor”.
Mas projetos (a não ser os muito pequenos) não são

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 é
imprescindível a presença de grupos de pessoas trabalhando de
forma cooperada. Nesta disciplina usaremos o conceito de equipe
de projeto como:
Grupo de indivíduos dedicados ao projeto, com

funções e responsabilidades bem definidas,
trabalhando em regime de cooperação e focados no
sucesso da empreitada.
38

Síntese
Você viu, na primeira seção, que os projetos, como atividades

com início, meio e fim, 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 ficando

mais complexos, sendo que ultimamente o desenvolvimento
de softwares e produtos de alta tecnologia têm exigido enormes
esforços de organização e cooperação. Estudos sobre como
planejar e realizar projetos passaram a tomar importância e
resultaram no desenvolvimento de diversas metodologias e
técnicas. Ultimamente tais técnicas têm sido implementadas
em sistemas de software e em redes distribuídas, favorecendo
imensamente os líderes e gestores de projetos.
A segunda seção apresentou os principais conceitos sobre essa

área do conhecimento, de tal forma que tais conceitos sejam uma
base comum para nossas próximas discussões e estudos.
Na próxima unidade você vai ver como se dá a gênese de novos

projetos, e o que pode determinar as sementes do seu sucesso
ou fracasso. Você verá, também, como as oportunidades são
identificadas, quais as motivações e quais os diferentes tipos de
projetos.
Não deixe de fazer as atividades de auto-avaliação para a melhor

compreensão e fi xação dos conceitos, bem como de participar
ativamente nos fóruns de discussão, sejam desta disciplina, sejam
dos ambientes atuais de estudo e discussão que se movimentam
na internet.
Unidade 1 39

Atividades de auto-avaliação
1) Considerando que projetos têm “objetivos definidos e prazo de

conclusão”, encontre um exemplo de projeto em sua própria
experiência, ou na história, e descreva o mesmo.
2) Com respeito à administração dos projetos ao longo da história, você

viu que houve um momento em que se passou do trabalho realizado
sem planejamento para um início de teorização e implantação de
práticas gerenciais. Em que época isso acontece, e por que motivos?
40

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 mudanças nesse período.
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 – Estatísticas apresentando problemas típicos de projetos (1998).
Desafios e sintomas
Média nacional EUA (1998)
típicos de projetos
Apenas 44% dos projetos são concluídos no prazo.

Atraso Na média os projetos costumam atrasar em até
222% do prazo programado.
Acima do custo estimado. 189%.
Não atingem satisfatoriamente os 70% dos projetos.

requisitos técnicos planejados.
Cancelados antes do término. 30% dos projetos.
Unidade 1 41

4) Vimos que os projetos atualmente têm, em comum, o seguinte:

• Prazos definidos.
• Objetivos estabelecidos.
• Custos planejados.
• Recursos previamente alocados.
No entanto isso não era assim nos grandes projetos da antiguidade.
Cite um desses casos e comente quais dessas características não se
apresentam.
5) Considere o quadro a seguir, onde exemplos de projetos são

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

Área Exemplo de projeto
atividade contínua
Concessionária de energia
elétrica
Software
Indústria Automobilística
Bancos
Governo
42

Saiba mais
1 - É importantíssimo 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, conferências, possibilidade de se associar,
comprar livros e saber o que acontece de novo no mundo da
gestão de projetos.
2 - Outro local importante no desenho de métodos e teorias

sobre a gestão de projetos é a Sociedade de Gestão de Engenharia
do IEEE (IEEE Engineering Management Society (EMS). Esta
sociedade está no endereço 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 gestão

de projetos de tecnologia estão hoje disponíveis e abertas na
Internet. Um exemplo é a revista http://www.worldscinet.com/
compsci.shtml, específica sobre Gestão de Tecnologia. Nesse
mesmo site podemos encontrar diversas outras publicações (em
inglês) sobre temas de interesse da computação.
Unidade 1 43

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 posição

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

diferenças entre tecnologia e ciência, bem como entre
os diferentes tipos de pesquisa.
Verificar que a inovação tecnológica é um processo que

passa pela geração do conhecimento e sua aplicação, e
que os projetos inovadores são os principais geradores
de tecnologia.
Seções de estudo
Seção 1 Inovação tecnológica: fonte de novos
projetos.
Seção 2 Identificando oportunidades.
Seção 3 Motivação para o projeto.
Seção 4 Quais são os tipos de projeto?


Nesta unidade você vai conhecer como nascem os projetos, sejam
eles pequenos empreendimentos pessoais ou grandes projetos
transformadores de uma era tecnológica.
Vamos refletir sobre a influência da ciência e da pesquisa como

geradores tecnológicos, os quais passam pelo desenvolvimento
de projetos específicos. É preciso considerar que os ambientes
de grande desenvolvimento tecnológico e, por conseqüência
econômico, são justamente aqueles onde acontece a pesquisa
científica e acadêmica, voltadas para a geração do conhecimento.
E mais: o papel das empresas neste processo, sejam grandes

ou pequenas, e como o empreendedorismo de inovação é
importante para o crescimento e manutenção empresarial.
Isso tudo, no entanto, não é possível sem o suficiente nível de
motivação, que nasce muitas vezes de uma necessidade básica,
mas que para existir precisa daqueles líderes que enxergam
viabilidade onde muitos outros só percebem riscos e dificuldades.
Foi com essas idéias que esta unidade foi escrita. Convido você a
participar e contribuir!
SEÇÃO 1 – Inovação tecnológica: fonte de

novos projetos
Os projetos das áreas tecnológicas nascem de uma
sucessão de avanços no conhecimento humano. Tais
conhecimentos vão se acumulando e uns se servem dos
outros para avançar 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. Porém, agora o
nosso foco vai recair sobre como eles se dão nas áreas
de tecnologia.
Nesta seção você vai conhecer as fontes científicas e tecnológicas

dos projetos, e de que forma os conhecimentos são gerados na
46

busca de “solução 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”. Alguém tem

que imaginar algum tipo de solução, alguém tem que sugerir
uma idéia. Mas as idéias não surgem do nada, e em se tratando
de projetos tecnológicos elas surgem de duas fontes:
1. necessidades;
2. conhecimentos e tecnologias disponíveis.
Veja na figura a seguir, inspirada no trabalho de Jay Paap (2004),

um modelo de inovação tecnológica. Necessidades que surgem
no negócio, ou na vida diária das pessoas, ou de renovação do
mercado, enfim, problemas que surgem todos os dias, estão
constantemente nos desafiando pela busca de soluções. Quando
alguém aceita esse desafio, e simultaneamente há conhecimentos
científicos e tecnológicos disponíveis, idéias surgem. Uma
criteriosa seleção dessas idéias pode levar ao desenvolvimento de
novos produtos ou novos processos que, se alcançarem sucesso,
serão amplamente utilizados e difundidos.
Necessidades
Desenvolvimento Uso e
Novas idéias Seleção
do projeto difusão
Conhecimento
e Tecnologia
Figura 2.1 - Um modelo de inovação tecnológica.
A transformação dessas idéias em produtos ou

processos é considerada uma Inovação Tecnológica,
e pode ser algo tão simples como uma nova maneira
de assentar tijolos numa construção, ou tão complexa
quanto lançar uma nova linguagem de programação.
Unidade 2 47

- Para entender melhor como o conhecimento científico e as tecnologias

podem levar a projetos de inovação tecnológica, leia um pouco mais
sobre esses conceitos.
Cada ciclo tecnológico tem origem numa inovação. A inovação

tecnológica pode ser caracterizada como a primeira vez que se
utiliza um determinado produto, processo, sistema ou serviço,
sejam novos ou melhorados, introduzidos num determinado
mercado, ou numa produção. O centro de gravidade da inovação
tecnológica é a empresa.
Veja por exemplo o caso do CD – Compact Disc. Todo

um novo ciclo tecnológico de gravações musicais,
filmes, arquivamento de dados, está marcado
pela inovação do uso do laser. Antes disso, se fazia
gravação de dados em fitas magnéticas. Esse novo
ciclo tecnológico teve origem num projeto de
desenvolvimento de um grupo de engenheiros da
Philips e da Sony. O desafio que eles se propuseram
resolver era o da gravação de imensa quantidade de
dados num pequeno espaço, e que uma vez gravados
não pudessem se perder, como acontecia com as fitas
magnéticas.
O processo de inovação tecnológica compreende a identificação

de uma necessidade ou de uma oportunidade. Uma necessidade
de um determinado grupo de usuários como, por exemplo,
dentro de uma planta fabril onde um novo equipamento ou novo
processo se faz necessário para dar agilidade a uma produção. Ou
uma oportunidade de negócios, como a telefonia sobre a Internet,
que exige projetos especiais de desenvolvimento.
A geração ou adaptação tecnológica para atender

essa necessidade ou oportunidade é também um
processo de inovação.
No entanto, para que essa inovação aconteça é preciso ter a

capacidade de pesquisa, desenvolvimento e engenharia, para
fazer a devida geração ou adaptação tecnológica, bem como
a capacidade de conduzir essa tecnologia ao mercado ou à
sociedade que a demandou. Não só isso, pois levar depois ao
mercado exige também ações competitivas, ou seja, o projeto
48

estará realizado quando cumpriu prazos e cumpriu demandas “antes”

do que a concorrência. Fazer tudo certo e chegar depois é “fracasso”.
Os processos inovativos são bastante complexos, pois estão

ligados ao desenvolvimento de projetos nas áreas de engenharia e
tecnologia avançadas, e com isso podem apresentar as seguintes
incertezas:
São irregulares, quando há diferentes etapas de

trabalho, possibilidades de retrocessos, re-análises
constantes etc.
São de alto risco, quando não há certeza de que
corresponderão ao que originalmente foi imaginado.
São excessivamente lentos ou prolongados, com
resultados que demoram para chegar ao mercado, muitas
vezes comprometendo sua receptividade.
A inovação tecnológica é atualmente assunto da política nacional,

e grande atenção está sendo dada a ela neste início de século,
tendo em vista que projetos originais na área podem criar grande
diferencial e valor agregado, com grande ganhos econômicos e
distribuição de renda.
No entanto, o tipo da inovação divide projetos em três linhas

principais:
1) Projetos de inovação básica ou radical, que constituem

uma mudança histórica e geralmente são decorrentes de
descobertas científicas, dando origem a novos produtos,
novos processos ou serviços, qualitativamente diferentes
dos produtos, processos ou serviços anteriormente usados.
Essa categoria de inovação é considerada como sendo
“empurrada pela ciência”, pois novos conhecimentos
científicos literalmente forçam o desenvolvimento de
tecnologias.
Exemplo de projeto de inovação tecnológica

básica foi o que deu origem aos transistores (com
os conhecimentos científicos sobre materiais
semicondutores), também o caso das fibras óticas
(transmissão de ondas de luz), sistema just in time na
produção industrial, o uso do laser na medicina etc.
Unidade 2 49

2) Projetos de melhoria ou de inovação Incremental; é

o que produz melhoria em tecnologias existentes, mas
não altera suas características fundamentais, ou seja, não
parte de novos conhecimentos científicos que forçam sua
existência, mas antes são “puxados pela demanda”, quer
dizer, a demanda tecnológica é que força uma inovação,
e por isso ela é chamada de incremental, pois coloca um
“incremento” sobre a tecnologia já existente.
Um exemplo típico de melhoria incremental é o que

vem sendo feito nos computadores pessoais, os PCs,
pois constantemente são feitas modificações no
gabinete visando a melhorar sua compatibilidade
eletromagnética ou dissipação de calor; outro
exemplo são as modificações feitas nas linhas de
produção dentro das fábricas, visando a maior
qualidade do produto final ou maior quantidade de
produção.
3) Projetos de inovação menor, ou seja, são aqueles que

não alteram qualitativamente os produtos, mas apenas
alteram suas relações com o mercado. Basicamente
são melhorias superficiais na tecnologia e também
são “puxados pela demanda”, pois o mercado define
tendências de consumo, que demandam desta forma
algumas modificações e adaptações no produto.
Um exemplo típico de inovação “menor”, mas

certamente muito importante, são as mudanças
de design de um produto, ou de ergonomia
A ergonomia estuda as relações (como temos visto recentemente com os telefones
entre os seres humanos e as celulares), mas também as mudanças de resistência da
máquinas, buscando uma interação embalagem (no caso de alimentos), e muitos outros.
de qualidade ótima e de segurança.
Por essa divisão, você percebe que os projetos de inovação

tecnológica são gerados por forças que vêm de dois lados: de
um está o avanço científico, e do outro estão as necessidades
das pessoas e do mercado. Se olharmos com mais atenção para
a Ciência, vamos perceber que ela também tem seu progresso
muitas vezes baseado em projetos, os chamados projetos de
pesquisa e desenvolvimento – P&D.
50

Em nossa sociedade a ciência assumiu um papel importantíssimo,

e a figura do cientista praticamente surge como a de alguém
desassociado da realidade cotidiana. Esta imagem é falsa e
nasce de uma visão deturpada do que seja a ciência e de como as
pessoas atuam nesse campo.
Como a ciência deve ser considerada?

uma instituição social, bem comum de todas as pessoas;
um método para adquirir conhecimentos;
uma tradição que acumula conhecimentos adquiridos;
um fator que apóia o desenvolvimento e a manutenção da
produção de bens e de serviços;
uma influência fundamental no comportamento do ser
humano.
A ciência combina teoria e prática e tem suas próprias formas

de comunicar, sua metodologia e seus critérios de sucesso, que
são diferentes de outras atividades humanas. A ciência 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 geração a geração, que se transformou na raiz da atual ciência.
Para que a ciência se transformasse na atividade como a

conhecemos hoje, foi preciso separar a teoria da prática, ou
seja, separar o trabalho do pensamento do trabalho manual.
Essa separação começou a acontecer a partir do surgimento
das sociedades escravistas. Com o uso do trabalho escravo
começaram a surgir pessoas com tempo livre para teorizar
sobre as coisas da natureza. A ciência é possível apenas com o
pensamento teórico, e esse tipo de pensamento é distinto de
concepções religiosas, filosóficas ou artísticas.
Certamente há teorias no pensamento religioso, na filosofia

especialmente, porém esses modelos de pensar não utilizam
métodos científicos, o que os distingue da ciência (e os projetos
que virão a partir daí).
Unidade 2 51

A introdução do método científico se deu na Grécia, quando os

conhecimentos começaram a sofrer uma:
Categorização (divisão dos campos do conhecimento).

Sistematização (colocou-se uma lógica para relacionar os
conhecimentos).
Teorização (argumentos, conclusões e conceitos teóricos
foram sendo colocados para as diversas categorias de
conhecimento).
O retorno à causalidade “religiosa”, durante o período da era

medieval, fez com que houvesse um retrocesso científico. A
causalidade religiosa é a que explica todos os acontecimentos
da natureza como de origem sobrenatural ou espiritual, sendo,
então, desnecessário buscar causas naturais para explicar os
fenômenos (como vinham fazendo os gregos e os romanos). Mas
depois das grandes navegações, das descobertas, e da retomada
do estudo dos clássicos gregos, a ciência voltou a ocupar um
importante e fundamental lugar na história da humanidade (e é
por isso que você está fazendo este curso!).
A ciência é uma atividade e desta forma tem seus:
atores: todos aqueles envolvidos num determinado

projeto de estudo e produção de conhecimentos; são os
membros da equipe;
objetos de investigação e estudo: a natureza e seus
fenômenos, o homem, sistemas artificiais, técnicas, a
sociedade, o pensamento, os próprios métodos científicos etc.;
objetivos: obter informações, novos conhecimentos e
aplicações para os objetos de estudo;
meios materiais ou recursos: as informações, os recursos
humanos, o lugar de trabalho;
resultados, que são os conhecimentos científicos básicos,
ou fundamentais, e também as técnicas e tecnologias
desenvolvidas;
métodos e processos de trabalho: que é a articulação
coordenada e objetivada dos membros da equipe, dos
meios e dos objetos, visando à obtenção dos resultados
(SÁENZ, 2002).
52

O método científico é a ordem definida de atividades,

organizadas de maneira consciente e aplicadas com constância
para chegar aos resultados almejados: conhecimentos,
demonstração de verdades, novas técnicas etc. Se olharmos com
atenção, vamos perceber que esse método é justamente o que
aplicaremos para a gestão de projetos. Quatro passos críticos
estão colocados no método científico para a solução de um
problema. Veja quais são:
1. Definir o problema, ou seja, caracterizar adequadamente

os seus limites, saber o que se pretende resolver com a
maior exatidão possível.
2. Descrever o problema, determinando onde está inserido

e com que outros fatos o problema está relacionado. A
descrição do problema deve ser feita com o máximo de
detalhamento.
3. Formular hipóteses de solução, que possam ser estudadas

e testadas dentro do escopo do trabalho. Nesta etapa será
criado um plano de trabalho.
4. Executar o projeto de pesquisa propriamente dito,

verificando as hipóteses, testando as possibilidades,
confirmando e rejeitando soluções intermediárias, a fim
de obter os resultados esperados.
Você Sabia?
Ciência muitas vezes é confundida com “tecnologia”.

Apesar de muitos pontos em comum, ciência e
tecnologia não são a mesma coisa. Assim como a
ciência, a tecnologia é uma instituição social, ou
seja, algo que nasce no seio da sociedade e por
sua necessidade. É um conjunto de conhecimentos
(científicos, empíricos), habilidades e procedimentos
capazes de produzir, distribuir, comercializar e utilizar
bens e serviços. Porém, ao contrário da ciência, a
tecnologia pode ser entendida como a aplicação dos
conhecimentos existentes.
Unidade 2 53

O avanço tecnológico (que vem com as inovações tecnológicas)

pode ocorrer com ou sem a ciência, pois além do conhecimento
científico, o conhecimento prático também é uma fonte para seu
desenvolvimento.
Um exemplo de avanço tecnológico, independente

da ciência, ocorreu no início da revolução industrial,
quando houve o desenvolvimento da máquina a
vapor no século XVIII. Isso se deu sem o conhecimento
científico das Leis da Termodinâmica, que viriam a ser
descritas apenas no século XIX a partir de 1850. Mas a
alta tecnologia de hoje é dependente da ciência, não
é possível avançar sem a contribuição da pesquisa
científica.
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, além de
permitir instrumentos mais poderosos para o trabalho científico,
o que as torna interdependentes. A figura a seguir mostra essa
interdependência e como isso tem permitido a revolução técnico-
científica que vivemos.
A ciência como pré-requisito fundamental
Atual revolução técnico- científica
Tecnologia fornece diretrizes
Figura 2.2 - Revolução tecnológica como interação entre ciência e tecnologia.
Essa revolução técnico-científica se dá por meio de diversos

projetos de pesquisa e desenvolvimento, que podem ser
classificados da seguinte forma (SÁENZ, 2002):
54

Pesquisa básica: pesquisa original, teórica ou

experimental, com o propósito de adquirir conhecimento
sobre determinado fenômeno, porém sem uma finalidade
prática em vista (é o que se chama da pesquisa pura).
Pesquisa aplicada: também é original, mas deverá
resultar numa aplicação por meio da obtenção de novos
produtos, processos ou métodos; esse tipo de pesquisa se
dá por meio de projetos multidisciplinares; um exemplo
desse tipo acontece atualmente com o desenvolvimento
de um padrão de TV Digital no Brasil.
Desenvolvimento tecnológico: parte de conhecimentos
existentes e visa desenvolver produtos, processos ou
métodos; o desenvolvimento de um novo software é
tipicamente um “desenvolvimento tecnológico”.
Melhoria de processo/produto: trabalho que visa a
aprimorar algo existente e já desenvolvido, geralmente
devido a modificações da tecnologia e do mercado;
um exemplo deste caso é a constante melhoria de
softwares por meio de novas versões, adaptadas às novas
necessidades do mercado ou devido a modificações do
hardware.
Assistência técnica e tecnológica: atividade que se
destina a manter produtos e processos de acordo com as
normas e os padrões de qualidade de uso.
Veja no quadro a seguir essa classificação em cinco etapas,

e também a origem de cada etapa na coluna “Entrada”. Na
coluna “Saída” estão os resultados obtidos em cada etapa, e na
coluna “Retroalimentação” você pode ver que o resultado de
determinado projeto pode ser uma nova “entrada” de pesquisa e
desenvolvimento, dando origem a diferentes projetos.
Unidade 2 55

Quadro 2.1 – Painel sobre diferentes modelos de pesquisa, suas entradas e saídas.
ETAPA ENTRADA SAÍDA RETROALIMENTAÇÃO

Idéias de pesquisadores, Hipóteses, descobertas, Outras pesquisas básicas,
Pesquisa básica dos laboratórios, linhas de teorias, artigos científicos, solicitações externas,
pesquisa. livros, equações. invenções, novos problemas.
Saída da pesquisa aplicada, Patentes, invenções, Outras pesquisas básicas
idéias de pesquisadores, maquetes, protótipos, e aplicadas, solicitações
Pesquisa aplicada dos laboratórios, de softwares de simulação. externas, novos problemas
empresas, de engenheiros, técnicos e científicos,
necessidades sociais. fracassos anteriores.
Idéias de engenheiros e de Projetos, planos, protótipos, Novos problemas técnicos e
Desenvolvimento empresários, invenções, novos produtos e processos, científicos, necessidades de
tecnológico resultados de pesquisas e especificações. invenção, relatórios de êxitos
outros trabalhos. e fracassos.
Produtos e processos Produtos e processos Necessidades de alteração
Melhoria de processo em uso, necessidades modificados, novo design, em linhas de produção,
/ produto de usuários, idéias de modificações de fabricação, modificação comercial, novos
engenheiros e empresários. automação de processos. desejos de consumo.
Necessidades de norma e Calibrações, ensaios, Percepção de melhorias,
Assistência técnica e de legislação, padrões de padronizações. novos bugs.
tecnológica qualidade, manutenção,
bugs.
O desenvolvimento tecnológico é uma atividade

multidisciplinar, e as tecnologias não podem ser
consideradas como atividades isoladas ou unidades
independentes – geralmente elas são “pacotes
tecnológicos”.
Esse conceito de pacotes tecnológicos é muito importante para

o desenvolvimento de um projeto, pois mostra claramente a
necessidade de vários tipos de relacionamento e vários tipos de
competências na equipe. Essa é uma noção de sistema, onde
diversas tecnologias sustentam-se de forma global e, para isso, o
desenvolvedor do projeto deve considerar sempre o conjunto de
relações. Outra questão importantíssima que você deve conhecer
é que as tecnologias têm um ciclo de vida, que pode ser longo
ou não. Mas toda tecnologia perece, ela é finita. A ciência, ao
contrário, busca verdades perenes, leis fundamentais e duráveis,
independentes no espaço e no tempo.
56

A obsolescência de uma determinada tecnologia

acontece, por exemplo, quando há o aparecimento de
uma nova tecnologia, que a substitui, ou há mudanças
de preços ou no fornecimento de insumos. Pode
também acontecer de os consumidores mudarem
seus hábitos, ou os competidores passaram à frente,
fornecendo produtos com melhorias que você não
dispõe.
Veja com atenção o gráfico da figura a seguir. Ele mostra o ciclo

de vida de determinado produto. Se tomarmos as três primeiras
fases como as etapas de projeto, veremos que envolve muitos gastos,
especialmente na fase de introdução no mercado. A partir daí, há
o amadurecimento e o crescimento das vendas do produto gerado
no projeto, até uma fase de estabilização seguida da crise e morte.
A fase de estabilidade pode durar se, por exemplo,

novos projetos de melhorias forem introduzidos,
retardando ao máximo a chegada da inevitável crise.
+$
Tempo
-$
. Pesquisa . Investimento e . Introdução no . Maturação . Saturação . Crise
. Desenvolvimento Produção mercado
. Engenharia
Figura 2.3 – Ciclo de vida de produtos tecnológicos.
Unidade 2 57

A duração maior ou menor da vida do produto depende de vários

fatores. Analise os três exemplos apresentados na figura a seguir.
+$ A
B
Tempo
A - tecnologia de impacto econômico, mas de envelhecimento precoce (softwares, aplicativos);

B - lento crescimento, mas de grande duração, permitindo ganhos contínuos (indústria dos computadores);
C - pequeno impacto e vida curta (alguns softwares).
Figura 2.4 – Diferentes ciclos de vida relacionados ao impacto econômico.
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 específica
e rapidamente caem em desuso. A curva B mostra outro caso,
também com um bom impacto econômico porém com uma vida
bem mais longa.
É o caso, por exemplo, da indústria de computadores,

e poderíamos dizer, também, da indústria de
aparelhos de telefonia celular. Ano após ano a
indústria se mantém, com melhorias constantes e
desenvolvimento tecnológico baseado em pesquisas
científicas.
Já a curva C mostra um caso diferente, onde o impacto

econômico foi pequeno e teve uma duração curta (mas maior que
a de A!).
58

- Bem, até aqui você tive uma visão geral das fontes de conhecimento
científico e tecnológico, e como eles se desenvolvem para gerar mais
conhecimento e mais tecnologia. Na seção 2 você vai identificar onde
pode haver oportunidades de novos desenvolvimentos, pois essas
oportunidades poderão ser as fontes de novos projetos.
SEÇÃO 2 – Identificando oportunidades

Certamente não existe um “manual de novidades” a ser
explorado, onde pudéssemos consultar e verificar onde estão os
projetos que darão origem às grandes inovações.
A busca por oportunidades de novos projetos depende, em

primeiro lugar, de uma postura investigativa por parte de cada
um de nós.
Esse olhar atento deve estar voltado para todos os detalhes.

Muitos imaginam que os grandes projetos são aqueles que vão
revolucionar uma empresa ou um mercado inteiro, geralmente
imaginando inovações de grande impacto. A realidade nos
mostra algo muito diferente: pequenas alterações, ou mesmo
idéias aparentemente sem valor, acabam provocando modificações
profundas em um processo industrial ou nos hábitos do
consumidor.
Para identificar oportunidades e gerar novas idéias é preciso

ter uma “mente sem pudor” (não pense em bobagem!). As
crianças são um bom exemplo disso. Sempre por descobrir o
mundo, tentam o tempo todo entender o que acontece
na natureza e têm idéias mirabolantes para resolver
quaisquer problemas. Mas aos poucos a ordem e a
disciplina da sociedade vão tolhendo essa característica
“despudorada” de explicar o mundo, colocando em
seu lugar uma organização esquemática e que permite
poucas distorções. Aqueles que conservam algo dessa postura
“aberta” geralmente se destacam por procedimentos criativos,
mesmo que às vezes “chutem algumas bolas fora” – mas não se
importam com isso, logo estão de novo tentando.
Unidade 2 59

Na verdade as oportunidades de novos projetos estão bem à

nossa frente, basta sabermos ler. Porém, apenas identificar uma
oportunidade não é 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 figura a seguir nos mostra três aspectos inter-

relacionados do avanço tecnológico, que são:
A descoberta, que corresponde ao resultado de um

projeto de pesquisa científica e geralmente não está
associada a uma necessidade comercial.
A invenção já está mais próxima da realidade do
mercado, porém ainda com uma visão de criar um
produto, sem a certeza de que terá aproveitamento
econômico.
A inovação, por sua vez, está intimamente atrelada
a uma racionalidade econômica, pois nasce das
necessidades vindas do mercado, seja diretamente do
consumidor, seja da empresa interessada em atuar sobre
esse consumidor.
Descoberta Invenção Inovação

Corresponde à pesquisa Corresponde à pesquisa Intenção de novas
científica, busca a verdade aplicada, busca um novo tecnologias, mas com uma
e a compreensão dos produto e uma racionalidade econômica.
fenômenos da natureza. racionalidade técnica.
Figura 2.5 – Diferenças entre descoberta, invenção e inovação.
Boa parte das descobertas científicas pode levar muito tempo

até ser aproveitada em algum projeto prático e, por esse motivo,
são criticadas como “sem serventia”. Esse tipo de crítica (ou
sarcasmo) é comum em nosso país, infelizmente. Professores
e pesquisadores universitários sofrem gozações por gerarem
dissertações e teses que apenas serviriam para “encher as
estantes”. Esse tipo de comentário é um enorme equívoco.
60

Há teoremas que levaram séculos até serem aproveitados em

aplicações.
Um exemplo importante é a Álgebra Booleana, de

1847, base da atual informática. Outro é a Teoria da
Relatividade, de 1905, aproveitada muito tempo
depois no desenvolvimento da energia nuclear.
Como você já sabe, os conhecimentos científicos são perenes

e estarão sempre disponíveis para permitir o avanço do
conhecimento.
Já a maioria das invenções acaba numa prateleira, sem utilidade

prática e sem algum industrial interessado. Poucas obtêm sucesso,
especialmente aquelas que nascem de idéias aparentemente
brilhantes, mas que se esqueceram de perguntar: a quem
interessa? E a que preço?
Pude observar uma Feira de Inventores onde vários objetos

eram bastante curiosos, os inventores eram talentosos, mas
cujo resultado prático foi nulo. Motivo de frustração para os
inventores, certamente o equívoco estava na organização 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 edições, ano após ano.)
Por outro lado a inovação tecnológica, objetivo

da imensa maioria dos projetos, é orientada para
o mercado, seja a partir de novos conhecimentos
científicos que possibilitam tal inovação (ou seja,
“empurram” a inovação), seja a partir de novas
demandas que “puxam” tal desenvolvimento.
Quando se diz que a inovação é do modo “empurrado pela

ciência”, isso acontece geralmente sem uma demanda específica
da sociedade. É também chamada de modo “ofertista”, pois
oferta novidades e um modelo de produção linear, onde cada
etapa só começa quando a anterior já está finalizada. O centro de
gravidade da inovação passa a ser a universidade, o instituto ou o
centro de Pesquisa & Desenvolvimento, e não a empresa, que fica
em segundo plano. Isso acaba isolando tais centros de pesquisa,
Unidade 2 61

que por não estarem prestando atenção no que acontece no

mercado, consideram terminada sua tarefa ao concluir o projeto.
A figura a seguir é um esquema genérico de projeto de inovação

tecnológica empurrada pela ciência, sendo que o princípio está
numa idéia e num módulo de Pesquisa & Desenvolvimento. Na
seqüência vêm os novos conhecimentos tecnológicos e uma oferta,
que só então parte em busca de uma necessidade e uma demanda.
Conhecimentos Necessidade
existentes Social
Pesquisa e Novos
IDÉIA conhecimentos Oferta
Desenvolvimento tecnológicos tecnológica
Técnicas de Demanda
engenharia de Mercado
Figura 2.6 – Modelo genérico de inovação “empurrada pela ciência”.
O caso oposto acontece quando uma oportunidade

de projeto tecnológico nasce do mercado, então
é dito como “puxado pela demanda”. Este é um
comportamento gerado pela demanda empresarial,
ou seja, deve haver esse desejo de inovação por
parte da indústria, a qual percebeu uma demanda e
pretende supri-la.
Em países ou regiões que têm a indústria pouco desenvolvida,

ou sem a cultura da inovação, não há esse tipo de solicitação de
projetos inovadores. Para que esse modo exista são necessárias
políticas de ciência e tecnologia que propiciem esse tipo
de demanda ou, o que é mais difícil nos países pobres ou
periféricos, uma cultura industrial empreendedora genuína.
O risco que esse modo corre é o de acreditar que tudo pode ser
resolvido apenas pela inovação tecnológica, esquecendo da ciência
e de dar condições de existência à pesquisa básica, gerando o
truncamento da criatividade científica.
62

A figura a seguir representa um esquema típico de geração de

inovação tecnológica a partir de demandas de mercado e de
necessidades sociais. A partir disso e havendo disponibilidade
de tecnologias, há o surgimento da idéia de projetos, e só então
acontece o desenvolvimento até chegar numa produção capaz de
atender aquela demanda original.
Necessidade Conhecimentos
Social existentes
Tecnologia Pesquisa e Novos

IDÉIA conhecimentos Produção
necessária Desenvolvimento tecnológicos
Técnicas de
engenharia
Demanda
de Mercado
Figura 2.7 – Modelo genérico de inovação “puxada pela demanda”.
Atualmente o que se busca é uma complementação desses dois

modos que são, então, chamados de modos de integração ou de
sistemas em rede, pois o desenvolvimento tecnológico é o tempo
todo retroalimentado com informações do mercado e de novos
conhecimentos científicos.
Para que um projeto de inovação tecnológica tenha sucesso é

preciso que:
a necessidade social esteja vinculada a uma demanda

atual ou potencial, ou seja, além de querer ter, o usuário
precisa ter condições para isso;
exista uma estratégia empresarial e competitiva para
colocar o produto no mercado;
haja capacidade técnica, científica, produtiva e comercial
para desenvolver o produto;
Unidade 2 63

sejam alocados recursos financeiros convenientes;

as equipes de pesquisa, engenharia e comercial trabalhem
de forma interativa;
haja uma sistemática comercial e de marketing adequada,
bem como pós-venda, manutenção e aperfeiçoamento
constantes;
seja compatível com os critérios dos consumidores;
a complexidade relativa seja baixa e exista a possibilidade
de avanços contínuos;
o impacto ambiental e social seja positivo.
Com todas essas condições de contorno percebe-se que uma

boa oportunidade de projeto nasce quando está inserida num
“sistema tecnológico”, que é algo bem maior do que simplesmente
a inovação tecnológica do produto. Tal sistema tecnológico pode
ser modelado de acordo com a figura, onde um grande número de
relações entre diferentes módulos está presente. Projetos inovadores
podem surgir em qualquer um desses módulos, num conjunto
deles, e nos casos mais complexos envolvendo todo o sistema.
Conhecimentos
existentes
Necessidade
Social
Pesquisa e
Competidores Desenvolvimento IDÉIA
Demanda
de Mercado
Técnicas de
engenharia
Tecnologia de Produção, Tecnologia de

Distribuição e vendas Consumo, social
Produção e
Fornecedores Distribuição
Serviços técnicos Usuários
Figura 2.8 – Modelo de “Sistema Tecnológico”.
64

Tendo ocorrido o surgimento de uma oportunidade de projeto

dentro de tal sistema, um modelo genérico de desenvolvimento
tecnológico pode ser apresentado como na seguinte figura, onde
necessidades e oportunidades técnicas se juntam para gerar idéias
e definir, então, um caminho, que pode ser trilhado ou não, para
o desenvolvimento de um novo projeto.
Oportunidade Necessidade Necessidade

técnica explícita latente
Geração de
idéias
Escolha de
alternativas
Estudos de
Mercado
Estudos de
viabilidade
Elaboração Obtenção de
Início do projeto
de projeto recursos
Figura 2.9 – Geração tecnológica – uma representação.
- Na seção seguinte, você vai conhecer o que pode motivar um projeto

para que seja, de fato, realizado.
Unidade 2 65

SEÇÃO 3 – Motivação para o projeto

Se um projeto tem origem numa idéia, por causa de uma
necessidade social, comercial ou por um novo conhecimento
tecnológico disponível, para que ele possa crescer e chegar à etapa
do desenvolvimento e ir até o final, entregando um resultado
próximo do esperado, ele precisa ter uma motivação que o
alimente.
Diversas são as motivações possíveis, desde o empenho

unicamente pessoal até um contrato abrangente e inviolável.
Você agora vai conhecer algumas dessas motivações, sabendo
antecipadamente que muitas vezes elas estão mescladas no dia-a-
dia dos projetos, umas com mais força, outras menos.
Alguém em uma pequena empresa teve a “visão”

de um novo produto, que ele acredita ser capaz de
alterar o futuro de sua empresa. Essa visão passa a
ser então um guia e um objetivo, capaz de motivar
e ajustar cada momento de desenvolvimento do
projeto que é então gerado. Os líderes são muitas
vezes movidos por essas “visões”, que são perseguidas
constantemente até o final, sem descanso. Tal visão
pode surgir na busca de resolver um problema,
pessoal ou empresarial.
Para uma determinada empresa que vem perdendo posições no

mercado, o projeto de um novo produto pode nascer como a
reação ao produto concorrente e que vem se destacando. Essa
“reação” comercial motiva o nascimento e a execução do projeto,
geralmente com forte pressão por resultados e prazos. É uma
motivação reativa.
Por outro lado, a empresa ativa busca sua ampliação no mercado

não apenas pela reação ao que já surgiu, mas pela criação de
novos produtos. Essa cultura criativa define as empresas que
lideram o mercado, pois constantemente estão criando produtos
inovadores ou lançando novas formas de se relacionar com
seus clientes, o que acaba mudando o comportamento geral
do mercado e as favorece. Como não podia deixar de ser, as
empresas criativas são mais raras do que as reativas, e ambas são
motivadas pela competição.
66

Nos dois casos anteriores, há uma motivação que é o

denominador comum: sucesso da empresa. Esse motivador
movimenta o mundo do capital e está na base do crescimento
econômico. Também há o motivador que é o sucesso pessoal,
perseguido não pelas empresas, mas pelos indivíduos.
Na base do sucesso pessoal um dos grandes motivadores é o

ganho financeiro. O prêmio em dinheiro dá motivação para
perseguir o projeto até o final, mesmo que a pessoa muitas
vezes não dê valor algum ao projeto em si, mas simplesmente à
remuneração.
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 ecológicos e
ambientalistas, onde um determinado grupo social, interessado
em melhorias locais ou regionais, empreende projetos de caráter
específico. Sindicatos, associações, organizações civis de interesse
público e partes do governo também são geradores de projetos
especiais, voltados ao bem-estar social.
SEÇÃO 4 – Tipos de projeto

Os projetos podem ser classificados em diversas
categorias, e essa classificação vai variar conforme
interesses comerciais, científicos e industriais, ou
então conforme graus de dificuldade, ou mesmo
conforme o ambiente em que se desenvolvem.
Veja agora algumas dessas possíveis divisões e, ao

final, você vai conhecer uma sistematização dessas classificações,
de modo a facilitar uma visão estratégica sobre tipos de projetos.
De acordo com o que você estudou nas seções 1 e 2 desta

unidade, os projetos podem ser classificados quanto à natureza
científica e tecnológica e, neste sentido, podem ser, grosso
modo, divididos nos seguintes tipos:
Unidade 2 67

Projetos de Pesquisa: são os projetos científicos, que

geralmente acontecem em universidades e centros de
pesquisa, e nascem da idéia de pesquisadores e linhas de
pesquisa já em andamento; podem ser de pesquisa básica,
quando direcionados a resolver problemas genéricos e
teóricos, sem aplicação prática em vista, ou de pesquisa
aplicada, quando voltados a usar uma teoria em alguma
nova aplicação, não necessariamente útil de imediato.
Desenvolvimento Tecnológico: ao contrário dos

projetos científicos, os projetos de desenvolvimento
tecnológico nascem da idéia de empresários e
engenheiros, e estão orientados diretamente ao mercado,
buscando introduzir inovação tecnológica, seja em
produtos diretamente para a venda, ou em processos de
produção ou comercialização dentro das empresas; por
serem projetos de inovação, estão fortemente associados
ao conhecimento científico gerado em pesquisas básicas
e/ou aplicadas (isso explica o vertiginoso crescimento
recente dos países orientais e do norte europeu,
fortemente baseado em educação).
Engenharia: são os que se baseiam em conhecimentos

e tecnologias dominadas, e estão voltados a construir
protótipos e produtos com aplicação bem definida; os
projetos de engenharia mais comuns que conhecemos são
os da construção civil.
Outra forma de dividir os projetos está relacionada à sua origem

institucional. Neste caso não estamos fazendo distinção entre
ciência, tecnologia ou engenharia, as sim quanto ao tipo de
instituição que o originou. Uma possível divisão desses projetos
seria a seguinte:
Comerciais: são os projetos que nascem dentro das

empresas buscando diferencial competitivo no mercado;
pode ser a idéia de um novo produto, baseada em
estatísticas e pesquisas realizadas junto ao consumidor,
ou a necessidade de modificação de um processo de
venda ou de produção, com foco em melhoria comercial;
lançamentos de novas embalagens.
68

Chamamos de chão
Novas versões de software e novas formas de entrega de fábrica o ambiente
para o consumidor. onde geralmente estão
instaladas as máquinas
da indústria, e onde o
Industriais: muito próximos dos projetos do tipo processo operacional de
produção acontece; não
“comercial”, também estão objetivando diferencial inclui, por exemplo, as
competitivo; no entanto são desenvolvidos no interior áreas de administração,
da indústria buscando melhorias no processo produtivo vendas, compras e
do chão de fábrica, sem um relacionamento direto com projetos.
perspectivas comerciais (apesar de estar claro que tais
melhorias vão colaborar na qualidade de todo o sistema);
são projetos que vão desde uma modificação de leiaute
no chão de fábrica, passando por projetos de introdução Do inglês lay-out,
de automatismos em máquinas até a criação de novas representa um esboço
ou modelo genérico de
máquinas-ferramenta. disposição de peças,
móveis e equipamentos
Governamentais: os governos são grandes geradores de num ambiente.
projetos, e alguns envolvem toda a sociedade e podem
até mesmo mudar os rumos de uma região ou de um
país; em tese nascem das necessidades sociais e em visões Máquina-ferramenta é
estratégicas para buscar suprir tais necessidades, mas o aquela que é usada para
que se vê geralmente são as vaidades políticas e a visão fabricar outras máquinas,
limitada como geradores de tais projetos, que muitas mais especificamente para
dar forma a objetos sólidos
vezes acabam por gastos inúteis do dinheiro público; mas como madeira e metal,
certamente há também os projetos de sucesso, muitas os quais serão usados
vezes polêmicos, que são capazes de modificar todo um como peças em outras
panorama histórico, e para não ir muito longe lembro máquinas.
aqui da construção de Brasília como nova capital do
nosso país praticamente no sertão da região Centro-
Oeste, redirecionando o fluxo do capital e das decisões
para o centro da nação, redirecionando os pólos de poder
em direção ao interior; e há também os projetos de pequeno
porte, igualmente importantes que mudam, por exemplo,
o trânsito de um bairro ou introduzem ali uma área verde e
de preservação, ou por exemplo a introdução de um sistema
informatizado de pagamento de impostos e taxas.
De fomento: projetos de fomento são também, 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
Unidade 2 69

criar ambientes favoráveis para que a iniciativa privada

se desenvolva; importantíssimos por sua característica de
apoio estrutural, um bom exemplo desse tipo de projeto
é a criação de parques tecnológicos e incubadoras de
empresas, fomentadores de novos negócios e de inúmeros
outros projetos de inovação dentro dessas empresas ou
idéias nascentes.
Cabe aqui ressaltar que a Unisul
criou e mantém uma incubadora, Acadêmicos: são os projetos que se desenvolvem dentro
com o apoio do governo de Santa
do ambiente das instituições educacionais, tais como
Catarina.
monografias e teses, bem como softwares e outros
produtos, caracterizando-se por uma relativa distância
das aplicações industriais, e digo relativa porque isso
depende de cada região e país; no Brasil ainda há uma
distância considerável entre indústrias e universidades,
infelizmente com um sentimento de desconfiança mútua
entre as partes, provavelmente devido às heranças de
uma sociologia de esquerda no pensamento nacional,
incapaz de perceber uma interatividade positiva entre as
partes; apesar dessa herança um relativo progresso vem
acontecendo, forçado por um lado pela carência de recursos
governamentais para novos projetos, e por outro lado pela
necessidade industrial em se distinguir tecnologicamente da
concorrência mundial cada vez mais presente.
É possível fazer uma separação de tipos de projeto também

quanto ao seu impacto no conhecimento ou no mercado,
independente de sua origem ou de sua natureza técnica. Essa
divisão nos ajuda e ver determinado projeto em relação à sua
“ambição”:
Impacto tecnológico ou Breakthrough: tipo de projeto

que se caracteriza por resultar em considerável impacto
em uma tecnologia ou em um mercado, modificando
hábitos de consumidores e alterando completamente
a finalidade da tecnologia anterior; é um tipo raro
de projeto, porque intrinsecamente é de risco, não se
sabendo determinar se terá o sucesso, o qual muitas vezes
nem era esperado.
70

Introdução dos compact discs no mercado musical,

que praticamente aboliu o uso de discos de vinil e
fitas magnéticas, ou o caso do uso da transmissão por
rádio na telefonia, que em poucos anos está mudando
completamente o cenário das telecomunicações
mundiais.
Plataforma ou sistema: projeto que envolve inúmeros

conhecimentos e módulos diferentes, geralmente
composto por uma série de pequenos projetos (os
derivados), que serão depois arranjados num sistema
único e maior; tipicamente é multidisciplinar, envolvendo
conhecimentos diversos e várias áreas.
O atual projeto de desenvolvimento do sistema de

televisão digital brasileiro.
Isolados: são aqueles projetos independentes, não

vinculados a um sistema e nem derivados de uma
necessidade de melhoria; basicamente são os projetos
criados por indivíduos (como o desejo de uma casa, por
exemplo) ou de uma pequena empresa para lançar um
novo produto no mercado.
Projetos derivados: este tipo é o conjunto que contém a

grande maioria dos projetos, que se caracterizam por ser
projetos pequenos e de prazo curto, derivados de outros
maiores ou de requisições de melhorias em sistemas já em
funcionamento regular.
As criações de novos leiautes de embalagem, um

determinado móvel ou novo dispositivo em uma
máquina-ferramenta.
Iniciais de Uncertainty,
Complexity e Pace,
Recentemente Dov Dvir et al. (2004) desenvolveram e passaram que poderíamos aqui
a aplicar um esquema genérico para definir tipos de projetos. traduzir por Incerteza,
Esse esquema, ou framework, foi denominado de “Modelo UCP”, Complexidade e Prazo.
sobre o qual é possível classificar os diversos tipos de projetos
tecnológicos.
Unidade 2 71

A figura a seguir mostra esse modelo como uma configuração

de três dimensões, onde cada eixo representa uma das variáveis,
tendo cada projeto uma posição nesse espaço, conforme sua
posição relativa em relação a cada eixo. Devido à sua utilidade
na definição dos tipos de projeto, vamos detalhar um pouco
mais o modelo de Dov Dvir et al, descrevendo os eixos e suas
sub-divisões.
Complexidade
Posição relativa do objeto
Incerteza
Prazos
Figura 2.10 – Modelo UCP para classificação de projetos (DVIR et al., 2004).
O eixo da Incerteza nos apresenta os diferentes níveis de

incerteza que um projeto pode assumir, seja quanto ao tempo
necessário para sua excução, quanto aos recursos e equipe
que serão alocados, a tecnologia disponível e mesmo sobre a
qualidade e sucesso do resultado final. Nesse sentido, os criadores
do Modelo UCP dividem os projetos em quatro tipos:
Tipo A – Baixa Tecnologia: são aqueles projetos

baseados em tecnologias existentes e dominadas, onde
não há necessidade de nenhum desenvolvimento ou
conhecimento adicional, a não ser os já disponíveis; os
projetos de construção civil são típicos deste nível, pois o
grau de incerteza tecnológica é mínimo, e o mesmo tipo
de projeto já foi realizado inúmeras vezes, não havendo
o que inventar; por esse motivo a gestão deve ser rígida e
não permitir variações no plano original.
Tipo B – Média Tecnologia: também são baseados
em tecnologias existentes, porém podem incorporar
alguma novidade no desejo de criar algum diferencial
72

para o produto resultante; esse tipo de projeto tem

poucas incertezas e geralmente acontece em indústrias
tradicionais e bem estabelecidas onde o desenvolvimento
tecnológico ocorre lentamente, como é o caso da
indústria automobilística ou de máquinas pesadas
onde, apesar do domínio tecnológico, também é
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: são os projetos onde as
tecnologias a serem empregadas são novas, apesar de já
existirem quando o projeto se inicia; a alta tecnologia se
expressa porque tais tecnologias pela primeira vez estarão
integradas num determinado produto ou processo, e o
desenvolvimento de tal projeto passa a ter uma série de
incertezas, caracterizando-se por ter longos períodos de
planejamento, modelagem, desenvolvimento e revisões,
que exigem muitas vezes retornar ao início do processo,
levando a variações grandes de custos e de modificações
nos prazos originalmente definidos; para que aconteça
uma estabilização da tecnologia são necessários vários
ciclos de projeto e reprojeto, até a consolidação do
produto/processo.
Tipo D – Super Alta Tecnologia: este é o tipo de
projeto mais raro, onde se tem um objetivo claro, porém
ainda não há tecnologias disponíveis para realizá-
lo; somente governos e empresas muito grandes se
lançam nesse tipo de projeto, onde o grau de incerteza
é elevadíssimo, e que levará a inúmeros outros projetos
derivados para buscar as tecnologias necessárias; 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 finalmente obter
o resultado desejado, e junto a isso gerou uma enorme
variedade de subprodutos e novas tecnologias; a figura a
seguir representa as classificações no eixo das Incertezas
com relação às tecnologias envolvidas.
Unidade 2 73

Tecnologia
Baixa Média 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 nível de gestão necessária. Inúmeros elementos podem estar
relacionados num projeto, e a forma como eles se relacionam
é que define os níveis de complexidade, conforme os seguintes
níveis:
Nível 1 – Montagem: são projetos onde diferentes

elementos são arranjados em composições simples,
ou simples montagens, de tal forma que o resultado
se configura num único produto com funções bem
determinadas, como por exemplo uma máquina; nesse
nível de complexidade os projetos geralmente são
desenvolvidos internamente por uma empresa, sem
relações externas.
Nível 2 – Sistemas: os projetos com nível de

complexidade maior, que envolvem inúmeros elementos
e diferentes equipes, de diferentes empresas e sub-
contratados, têm maior nível de complexidade e são
chamados nesse modelo de “Sistemas”. São exemplos
desse tipo um novo projeto de automóvel ou avião, ou a
reengenharia de uma empresa inteira.
Nível 3 – Super-sistemas: são aqueles formados por

inúmeros outros sistemas, em geral dispersos entre
diferentes empresas e categorias tecnológicas, que
precisam agir em conjunto em busca dos resultados
74

definidos pelo contratante, muitas vezes uma instituição

governamental ou consórcio de empresas; a construção
do túnel que liga a Inglaterra à França é um exemplo
desse tipo, assim como a construção do metrô de São
Paulo; a gestão desse tipo de projeto envolve inúmeros
gestores e uma imensa quantidade de documentos e
relatórios, de forma a coordenar esforços de diferentes
organizações e lugares; o eixo da Complexidade quanto
aos sistemas envolvidos é mostrado na figura 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

disponível ou necessário para o seu desenvolvimento. Como
já vimos na unidade 1, os prazos são ultrapassados na grande
maioria dos projetos, gerando custos não-previstos e atrasos na
entrega aos clientes e, por esse motivo, são uma fonte enorme
de preocupação. Nesse sentido, os criadores do Modelo UCP
identificam três tipos de projetos quanto aos “prazos”:
Regulares: são aqueles projetos onde existe um prazo

definido mas há razoável tolerância aos atrasos e
modificações de agenda, como acontece, por exemplo,
na construção de edifícios residenciais e em estradas;
perturbações e modificações de investimento são
toleradas e admissíveis; apesar de não desejáveis,
temos exemplos comuns em projetos de implantação
de sistemas de software gerencial em empresas (os
ERPs), e são tolerados porque se admite que há fatores
não percebidos no começo do projeto e que o atrasam,
e a importância da sua implantação é preponderante,
independente do prazo.
Unidade 2 75

Competitivos: são os projetos mais comuns no ambiente

industrial/empresarial, e estão endereçados a novas
oportunidades de negócios, posicionamento estratégico
ou lançamento de novas linhas de produtos. Nesses casos,
a perda do prazo não é fatal para a empresa, mas atrasos
podem ser o motivo de fracasso em um lançamento e a
perda de liderança em determinado mercado.
Críticos: são os projetos onde o atraso significa o

fracasso total, implicando em falência ou derrota;
projetos desse tipo surgem em fases críticas, como por
exemplo em guerras, quando projetos militares precisam
ser concluídos no tempo justo; por esse motivo a gestão
é rigorosa e há pouco tempo para documentação e outros
tipos de burocracia, levados ao mínimo necessário (veja a
figura a seguir).
Regulares
Competitivos
Prazos Críticos
Figura 2.13 – Eixo dos Prazos no Modelo UCP (DVIR et al., 2004).
Considerando os eixos apresentados é possível posicionar um

projeto ou situação de determinado produto e buscar, então,
um novo posicionamento estratégico.
É 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 proteção contra incêndios. Veja na figura a atual posição do
produto e a posição futura numa disposição bidimensional.
76

Complexidade
Super-sistemas
Requisitada
Sistemas
Montagem Incerteza
Posição atual
Baixa Média Alta Super Alta
Tecnologia
Figura 2.14 – Exemplo de projeto apresentado no artigo de DVIR et al. (2004).
Certamente decorar todos esses tipos e nomes não é necessário,

tampouco formalizar cada novo projeto numa dessas categorias
acima descritas.
O que é importante é ter uma compreensão 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 compreensão é possível ter sempre uma visão

estratégica na criação e na gestão do projeto, que é o que nos
interessa.
Unidade 2 77

Síntese
Nesta unidade você conheceu os diferentes tipos de projeto,

como são classificados e, especialmente, no que se relaciona
à complexidade tecnológica, riscos variados e prazos. Essa
classificação é atual e deriva do desenvolvimento científico e
tecnológico recente. Além disso, foram discutidas algumas outras
classificações, mas a ênfase foi colocada na inter-relação entre
conhecimento científico e desenvolvimento tecnológico como
fontes de novos projetos.
Com essa visão abrangente do nascimento e da motivação

dos novos projetos, você pode agora iniciar a unidade 3,
onde aprofundaremos a concepção do planejamento de um
determinado projeto.
Você vai estudar os requisitos do cliente e verá como fazer as

avaliações prévias; análises 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

gestão de projetos, sempre mantendo o necessário distanciamento
que a visão estratégica exige.
Enquanto isso, bom trabalho nas atividades, e fica o convite para

navegar em outras referências, artigos e livros. Boa sorte e até a
próxima!
78

1) Veja o diagrama a seguir. Você lembra do desenvolvimento do CD? Então

pesquise um produto ou serviço, que esteja presente no mercado, que tenha sido
desenvolvido seguindo esses passos, e descreva brevemente as diversas etapas.
Necessidades
Desenvolvimento Uso e
Novas idéias Seleção
do projeto difusão
Conhecimento
e Tecnologia
Unidade 2 79

2) Na figura a seguir você pode ver que tecnologia e ciência são atividades
diferentes, porém interligadas. E isso se estabelece na base da revolução
tecnológica atual, impulsionada por projetos de grande impacto. Como você
diferencia “tecnologia” e “ciência”?
A ciência como pré-requisito fundamental
Atual revolução técnico- científica
Tecnologia fornece diretrizes
3) Conforme você viu nesta unidade:
“a obsolescência de uma determinada tecnologia acontece, por exemplo,

quando há o aparecimento de uma nova tecnologia, que a substitui, ou há
mudanças de preços ou no fornecimento de insumos. Pode também acontecer
de os consumidores mudarem seus hábitos, ou os competidores passaram à
frente, fornecendo produtos com melhorias que você não dispõe.”
Faça uma pesquisa ou debate, e comente sobre alguns produtos que tenham
sido substituídos por outros devido a mudanças tecnológicas ou de consumo.
80

4) A figura a seguir apresenta o Modelo UCP de classificação de projetos.
Considere os seguintes casos:
(A) A construção de uma casa e classifique esse projeto segundo o modelo UCP,
marcando no desenho com eixos “complexidade x incerteza” a posição relativa
do projeto.
(B) Faça o mesmo considerando um projeto de desenvolvimento de software

para controle de biblioteca, por exemplo, e faça a marcação.
(C) Em Santa Catarina está sendo desenvolvido o projeto de um novo carro,

com tecnologia brasileira e tração 4x4. Classifique e marque também este
projeto no desenho.
Comente no final as diferenças que você vê entre os três tipos de projeto.
Complexidade
Super-sistemas
Sistemas
Montagem Incerteza
Tecnologia
Unidade 2 81

Saiba mais
Links úteis
Alguns links são muito úteis para a comunidade de ciência e
tecnologia. Dê uma olhada nesses:
1. www.finep.gov.br – este é o sítio da Financiadora

de Estudos e Projetos, do Ministério de Ciência e
Tecnologia do Brasil. Vários editais de financiamento
para inovação tecnológica são colocados ali
constantemente, e são dedicados ao fomento industrial
e empresarial. Há, inclusive, investimentos em
projetos tecnológicos a fundo perdido, ou seja, não-
reembolsáveis. No sítio da Finep você vai saber como
está o andamento da maioria dos grandes projetos
tecnológicos do país.
2. www.cnpq.br – o Ministério da Ciência e

Tecnologia também dispõe do Conselho Nacional
do Desenvolvimento Científico e Tecnológico
– CNPq – que também financia bolsas e projetos
tecnológicos diversos, com ênfase em pesquisadores
e desenvolvedores cursando graduação ou recém-
formados. Além disso traz uma série de informativos e
editais importantes.
3. Veja no seguinte sítio um artigo muito interessante

sobre criatividade no desenvolvimento de novos
projetos. Aponta oito tópicos como sendo
importantíssimos 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 - Associação Nacional

de Pesquisa, Desenvolvimento e Engenharia das
Empresas Inovadoras, cujo sítio é www.anpei.org.
br. Vários artigos importantes, estatísticas e outras
informações sobre projetos de pesquisa e inovação
tecnológica, bem como oportunidades de negócios.
82

3
UNIDADE 3
Visão geral do projeto
Compreender os aspectos práticos iniciais de um
projeto, sendo que a determinação exata do escopo do
projeto é o primeiro passo para seu sucesso.
Perceber que as requisições do cliente, seja externo, interno

ou você mesmo, é que traçam o caminho geral a ser
seguido pelo projeto, e que é preciso sempre ter uma visão
geral e estratégica de tal caminho, para evitar de se perder.
Compreender questões práticas quanto à viabilidade

e riscos inerentes a qualquer projeto, e formas de
administrar tais questões.
Verificar itens fundamentais como recursos, custos,

benefícios e prazos, como componentes determinantes
da viabilidade do projeto.
Seções de estudo
Seção 1 Identificação e avaliação inicial.
Seção 2 Requisitos do cliente e solução de
problemas.
Seção 3 Algoritmo do projeto.

Seção 4 Prazo geral.
Seção 5 Viabilidade do projeto.
Seção 6 Antecipando e administrando riscos.


Esta unidade está dividida em seis seções, as quais se dedicam
a mostrar como uma visão geral, de partido amplo, pode ser
determinante para a decisão sobre a viabilidade do projeto, e seu
posterior sucesso. Inicialmente apresento as características de
avaliação prévia e de identificação 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, então, um

modelo genérico de algoritmo para planejamento e realização
de projetos. Passam a existir, daí em diante, vários elementos
que aprofundarão a análise do projeto, e especificamente a
análise de sua viabilidade quanto a prazos, recursos necessários,
custos e benefícios que serão atingidos. Esses quatro itens, inter-
relacionados, determinarão a viabilidade, ou não, de qualquer
projeto.
Por fim o grande problema das ameaças 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 precisão possível (que nunca será exata). Estimados
os riscos você estudará que maneiras você tem para evitá-los e,
caso não seja possível, administrá-los então.
Espero que esta unidade seja estimulante e motive a visão geral

e estratégica quanto à gestão de projetos e de equipes, fator
determinante para obter projetos de qualidade e de impacto
positivo.
Bom estudo!
84

SEÇÃO 1 – Identificação e avaliação inicial

Para os projetos terem sucesso é preciso ter, antes de tudo,
uma visão clara sobre a finalidade e sobre o seu resultado final
esperado. Em recente artigo sobre lideranças em equipes de
projetos, Christenson e Walker (2004) definem esse tipo de
atitude, vinculada a uma comunicação 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 série de diferentes

fatores influencia no surgimento de um projeto. Mas para que
ele tome uma forma e possa evoluir ainda há muito que fazer.
Invertendo, então, o que está escrito no parágrafo acima, é

possível dizer que o fracasso de todo projeto tem origem numa
visão distorcida do objetivo. Ou seja, quem encomendou o
projeto, quem teve a idéia, quem sentiu a sua necessidade,
muitas vezes não 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

não aparece e, em seu lugar, vêm meias palavras e pedaços de
problemas.
Para chegar à sua raiz é preciso argumentar um pouco mais, na

tentativa de clarear a própria idéia do projeto, pois geralmente o
usuário, o fabricante, o empresário, não tem claro o problema a
ser resolvido.
Provavelmente alguém dirá: preciso melhorar o tempo de

produção desta linha de montagem. É de fato um “grande”
problema, e então precisaríamos de um “grande” projeto (sem
saber direito que projeto seria esse). Talvez o tempo da linha
de montagem seja grande porque, ao finalizar cada etapa da
montagem, alguém pára para contar peças.
Unidade 3 85

Então se houvesse um sistema de contagem automática esse

tempo poderia ser reduzido. Essa automação poderia ser um
contador em determinados trechos da esteira, mas tal contador já
existe no mercado, basta comprar e instalar.
Porém, temos que pegar os dados gerados pelo contador e enviar

para o departamento de estoque, onde planilhas são construídas.
Bem, esse processo de análise pode ir bem longe, até chegarmos
de fato a um problema com uma solução a ser implementada, e
para termos tal solução um projeto será criado. Parece simples,
mas não é.
O primeiro passo, o passo fundamental, é transformar

o assunto onde está o “problema” em uma definição
exata, pois um trabalho de desenvolvimento só tem
sentido quando se procura uma solução, 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á vários tipos de projetos, e se considerarmos a divisão

estabelecida na unidade 2, os projetos de baixa tecnologia são
razoavelmente bem conhecidos por todos, e com eles é fácil
chegar a uma boa definição do resultado.
O exemplo da construção civil cabe perfeitamente

nesse caso, onde o contratante tem uma idéia bem
razoável da casa ou edifício que quer construir, e dos
recursos dos quais dispõe, sendo que o resultado final
não fugirá em muito dessa idéia. Conforme o grau de
tecnologia aumenta (portanto aumenta a incerteza)
e também conforme aumenta a complexidade, mais
difícil é chegar nessa idéia geral.
Clientes têm idéias confusas sobre os seus próprios desejos. E

se nossa tarefa é criar soluções para problemas de tecnologia
complexos, será preciso envolver a associação de:
86

conhecimentos adquiridos em etapas de pesquisa e

desenvolvimento científico e/ou;
conhecimentos de engenharia e/ou;
conhecimentos empíricos.
- Não parece fácil?
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 aproximação ao problema, é preciso criar para ele um
modelo de representação. Você vai conhecer mais sobre esses
dois assuntos - equipe e modelagem - nas próximas unidades.
Na tentativa de definir o escopo do problema, o passo

inicial é a identificação exata da necessidade a ser
atendida.
A atividade de reconhecer uma necessidade, identificá-la e

compreender o seu teor exige criatividade, e isso não é um
fato corriqueiro. Enquanto a necessidade é algo genérico,
abrangente, o problema é o seu detalhamento, é a especificação
da necessidade.
Na tentativa de definir um problema há duas maneiras de

encará-lo:
Partido geral, ou amplo: definir o problema de maneira

ampla permite criar soluções menos usuais, pois o
universo de análise é maior. Com isso quero dizer que
ângulos diferentes podem ser analisados, e soluções que
estavam fora do alcance de visão do cliente ou da equipe,
por exemplo, podem surgir e resolver a questão.
Na figura a seguir, você pode observar que na região do problema

há várias causas e efeitos que não estão imediatamente visíveis, a
não ser que um partido geral seja tomado, e que uma capacidade
de visão ampla esteja em ação. Com isso vários aspectos podem
ser analisados, e propostas de soluções abrangentes e variadas
podem ser assumidas.
Unidade 3 87

Soluções abrangentes e variadas
Visão ampla
Efeitos não Efeitos não

visíveis visíveis
Causas e efeitos
visíveis
Causas não Causas não
visíveis visíveis
REGIÃO DO PROBLEMA
Figura 3.1 – Representação esquemática do problema com abordagem de “visão ampla”.
Partido restrito: visões restritivas levam a soluções de

pequeno alcance, ao contrário de uma percepção ampla
que pode levar a soluções de maior alcance. Problemas
atacados desde o início de maneira pormenorizada
podem gerar soluções deslocadas, e um gasto excessivo de
tempo e dinheiro.
Veja a figura, onde um conjunto de causas e efeitos não está no
campo de visão dado por um partido restrito. Isso gera uma
solução de alcance limitado, que muito provavelmente não agirá
sobre causas e efeitos não percebidos.
Figura 3.2 – Representação esquemática do problema com abordagem de “visão restrita”.
88

Considero essa dualidade de visões, a ampla e a restrita, como

o problema fundamental das áreas de pesquisa, desenvolvimento
e engenharia, seja em setores de software ou de construção, da
indústria ou do serviço, da nossa vida profissional 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 influenciar a busca por um partido amplo!).
Veja o quadro a seguir:
Caso 1
Falha de monitores
Há alguns anos atrás, atuando em uma empresa de projetos e
consultoria em engenharia elétrica, fui chamado para apresentar
uma solução para problema que estava intrigando diversos
técnicos de uma grande empresa cerâmica.
Em determinado setor administrativo da indústria, um conjunto
de monitores, que ficava na lateral de uma das salas, oscilava
continuamente, variando porém a intensidade da oscilação
durante o dia. Às vezes, à noite, oscilava menos e até chegava a
não ser notado.
Esse problema afetava seriamente os usuários, chegando a
causar irritação nos olhos e grande cansaço. Os engenheiros e
técnicos eletricistas da fábrica foram chamados para resolver o
problema.
A primeira solução (restrita)
que apresentaram foi trocar o
circuito de alimentação elétrica
daqueles computadores, mas os
monitores continuaram oscilando.
Acusaram então o aterramento
como causador do problema e a
segunda solução 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
Unidade 3 89

Universidade do
Universidade
Sul de Santa
doCatarina
Sul de Santa Catarina
Caso 1 - continuação
Aí se pensou o seguinte: como os monitores da outra sala não oscilavam,

provavelmente o circuito alimentador deles era o “bom”.
A terceira solução apresentada foi puxar uma extensão daquele circuito para
atender os computadores com problema. Não funcionou. A quarta e imaginativa
solução apresentada foi trocar os monitores de lugar, e dessa vez funcionou. No
entanto, isso foi só uma experiência, pois todas as salas estavam cheias de pessoas
trabalhando, e não era possível deixar metade de uma sala vazia apenas porque
não descobriram a solução do problema (antes, estavam “correndo” dele).
Sem mais idéias (restritas) para apresentar, começaram a procurar alguém capaz
de fazer uma mágica qualquer e, então, encontraram nossa empresa. Quando
cheguei na indústria me cercaram e contaram toda essa história, e insistiram em
de novo fazer os mesmos testes de movimentar os monitores, fazer extensões etc.
Após ouvir todos os comentários, inclusive um sobre um sapo morto e enterrado
próximo, comecei a fazer algumas perguntas mais genéricas e descrever o
problema de um modo mais abrangente. Aquele tipo de monitor usava tubo de
raios catódicos, como a maioria dos televisores, e tais raios poderiam desviar da
trajetória se fossem afetados por campos eletromagnéticos interferentes. Se os
raios desviassem da trajetória criando uma espécie de oscilação, provavelmente
os campos interferentes eram oscilantes.
A pergunta que fiz foi: existem fontes de energia, subestações ou cabos
alimentadores próximos, mesmo que fora da sala, que pudessem ser os
causadores de tais campos? A visão do problema era tão diferente daquele
partido que inicialmente tomaram, que imediatamente começaram a raciocinar
de outra forma. Rapidamente acharam várias possíveis fontes, mas eram todas
muito distantes da região dos monitores. Alguém voltou com a história do sapo
fantasma. Perguntei então como eram as instalações elétricas da sala, e fui junto
com o eletricista ver os quadros elétricos. O quadro principal tinha um duto que
ia em direção ao teto e outro para o piso. Reparei que entre vários 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 eletromagnéticos indesejáveis. E o eletricista da
fábrica me disse que fizeram a instalação dessa maneira porque o duto estava
muito “apertado” e os cabos não passaram juntos, por isso lançou um pelo piso
(embaixo da região dos monitores) e o outro pelo teto (sobre os monitores).
Desliguei esse circuito e fez-se a mágica: os monitores pararam de oscilar. A
solução era realmente muito simples, bastava ter olhado o problema com um
pouco mais de paciência 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 irritação poderia
ter sido economizada se o partido amplo tivesse prevalecido.
90

Gestão de Projetos
Gestão
e de Equipes
de Projetos e de Equipes
- E então? Viu agora? A seguir trago mais um caso para que você
compreenda melhor, veja:
Caso 2
Implantação de um ERP
ERP – Sigla para
Conheci uma empresa que tinha várias filiais espalhadas por extenso
Enterprise Resource
território e mais de mil e quinhentos funcionários. Não vou contar
Planning, sistema
aqui a novela e os dramas que aconteceram na escolha do software
informatizado para
ou na sua implantação. Vou iniciar o caso no momento em que uma
planejamento e
rede de comunicação IP foi contratada de uma grande empresa de
apoio à operação
telecomunicações. Qual era o problema?
dos recursos de uma
Antes do contrato dessa grande rede IP, todos os usuários reclamavam empresa, tais como
de imensos problemas de demora para resolver qualquer coisa com financeiro, estoque,
o tal software ERP, que tinha vindo para ser “a salvação do sistema de pessoal, linha de
informações” dessa empresa. O usuário evidentemente achava que produção etc.
isso seria um novo problema para ele, tão acostumado em preencher
papeizinhos. Mas cada vez que fazia uso do novo sistema, o mesmo não
respondia ou demorava demais para dar uma resposta, muitas vezes “travando”.
Então surgiu a primeira solução (restrita) do
problema: era a infra-estrutura de rede que não
funcionava bem. Foi contratada, então, a nova
rede IP e a esperança surgiu no coração de todos.
Nesse momento, fiz a minha primeira análise e
relatei a todos: o problema está no sistema, e a rede
não vai alterar seu comportamento. Bem, eu não queria frustrar as esperanças de
ninguém. Veio a nova rede e tudo continuou como era antes (e minha equipe já
tinha apresentado todos os gráficos de performance, antes e depois da existência
da rede, mas ninguém estava disposto a abandonar suas crenças até que cada um
visse novamente, em sua própria máquina, que tudo continuava igual).
Chegou a vez da segunda solução (restrita): se o sistema não funciona bem
deve ser problema com o servidor, então a solução é trocar o servidor (isso foi
feito). Acredito que tenha melhorado um por cento (é uma crença particular,
baseada na redução proporcional de reclamações). Fiz as seguintes perguntas:
o sistema é lento em todas as solicitações? Apenas das filiais? 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 própria construção 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 espécie de filho defeituoso,
vivendo para sempre dentro de casa.
Unidade 3 91

- 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
Site corporativo:
espaço virtual de Estive em uma determinada companhia onde a cultura tecnológica
determinada empresa remontava ainda à época da segunda revolução industrial, ou seja, a
no ambiente da cultura tinha conseguido evoluir do ambiente das máquinas a vapor
“World Wide Web” para as máquinas elétricas. Isto não é uma crítica à companhia, pois
na internet – em ela estava adequada ao seu mercado, que a enxergava como capaz de
português algumas entregar produtos tradicionais (e conservadores) e nisso era muito boa.
vezes se usa a palavra
No entanto seu problema é que o discurso da nova direção era de
“sítio”, que aos poucos
remodelagem dos seus objetivos, e nisso o foco era estar a par com as
está se tornando
novas tecnologias e com os novos processos de qualidade, tanto é que
corrente no Brasil.
fazia questão 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
não têm valor, a não 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 tão fraco e desestruturado que o
número de visitas era muito baixo, e mesmo
menor que o de alguns sites especializados
de algumas de suas seções industriais, que
tinham feito os seus de forma independente.
O gerente geral de marketing da empresa, que surpreendentemente
também acumulava a função de gerente técnico geral, resolveu
mudar essa situação contratando um novo ambiente, de tal forma que
embutisse os sites das seções, não permitindo assim que tivessem tal
independência de relacionamento com o mercado.
Esse era o clima geral do negócio e tal era o problema a resolver:
um novo site corporativo com esse conjunto de premissas, sejam de
marketing, sejam de política. Tanto esse gerente quanto seu diretor,
ambos tendo conquistado suas posições a partir de negociações
políticas (e não por talento empreendedor ou por conhecimento do
mercado), desprezavam as novas tecnologias, a tal nível que o primeiro
escrevia e-mails como se fossem ofícios e o segundo mal conhecia as
regras do português escrito.
92

Caso 3 - continuação
Isso não consistia num grande problema no ambiente em que

viviam, mas era grave quando resolveram influenciar nas definições
do novo site. O gerente geral de marketing assumiu a função de
gestor desse projeto e trouxe a primeira solução (restrita) para
o caso: passou a incumbência para o assessor de marketing da
empresa. Ele mesmo não tinha uma visão geral da empresa e sabia
disso. O assessor de marketing tinha dois problemas, que todos
conheciam: não dominava tecnologias e não conhecia a cultura da
empresa (mas imaginava que, após ter lido algumas revistas sobre
publicidade, podia discutir qualquer assunto).
O assessor trouxe, então, a segunda solução (restrita) para o
problema: fez uma licitação entre empresas de design para
contratar o tal site, e ganhou a que tinha o menor preço.
Certamente a descrição do propósito da contratação estava
escrito conforme os objetivos desse assessor, e as empresas
fizeram seus orçamentos praticamente “no escuro”. Ganhou o
menor preço e então chegou a terceira solução (restritíssima)
para o problema, que foi o de dar uma “melhorada” no site
existente. Todos os funcionários da empresa, seus gestores,
aqueles que formulavam suas novas estratégias, bem como seus
principais clientes e fornecedores, ficaram fora desse processo
de análise de definições e, enfim, após uns seis meses de atraso
o novo site foi publicado. Sem interação com as aplicações
informatizadas da empresa, sem dinamismo e sem capacidade
de mostrar as próprias atividades da empresa, foi um fracasso (as
próprias estatísticas do site mostravam isso).
Para o diretor e para o gerente isso não teve importância, afinal já
tinham um “novo” site, e era o que importava para os concursos
regionais de qualidade (e sua publicidade e política pessoal). Para
o assessor de marketing isso também não tinha importância, pois
ele cumpriu seu dever e o emprego estava mantido. No entanto
essa visão restrita (e neste caso também mesquinha) fazia a
empresa dar um passo para trás (talvez irreversível).
Eu poderia continuar dando exemplos e mais exemplos desse tipo

de visão restrita aplicada à solução de problemas, e infelizmente
parece que esse é o caso da maioria. Temos que lutar contra isso.
Deixe-me dar, então, apenas um exemplo de visão ampla, que

mesmo fazendo parte da minoria, quando acontece pode mudar
os rumos de toda uma empresa ou mesmo de um país.
Unidade 3 93

Caso 4
Uma gigante da telefonia celular
Assim como nos três casos anteriores, verídicos, também neste não vou nominar
a empresa onde o fato ocorreu (apesar de ser muito fácil adivinhar). E apesar de
ter vivido o dia-a-dia daqueles três casos, neste último, infelizmente, não. 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 elétrica e
eletrônica, estavam perdendo o poder de compra.
A empresa tinha um grande problema nas mãos, que era o da sua própria
sobrevivência no futuro. Começou então a tomar um partido amplo para analisar
o problema, e iniciou um conjunto de ações em seqüência, sempre com soluções
criativas e tomadas por uma visão de conjunto.
Em primeiro lugar, não mudou completamente de ramo, para não desperdiçar
seu conhecimento técnico em eletrônica e sua cultura de fabricação de produtos
com excelência. Ao mesmo tempo assumiu como solução (de ampla visão) não
competir diretamente com empresas orientais que tinham preços baixos em
produtos eletrônicos.
Outra solução foi competir num mercado nascente e de alto valor
agregado, que naquele momento ainda consistia numa promessa: o da
Commodities: telefonia celular. No início dos anos noventa a empresa já detinha um
palavra da língua razoável conhecimento na área, e um domínio consistente do seu mercado
inglesa que indica local que, no entanto, era de dimensão restrita.
que o produto ou Também com uma visão ampla e estratégica do mercado mundial,
sistema é de uso previu que a produção de aparelhos de telefonia celular teria valor
ou conhecimento agregado quando inserisse qualidade no software, e não no hardware do
genérico, tendo equipamento. Adotou uma solução (ampla) de pesquisar e desenvolver
poucas diferenças de novas interfaces e aplicativos, voltados à facilidade de manuseio por parte
valor, independente do usuário, muito mais do que desenvolver simplesmente a miniaturização
de quem os fabrica dos aparelhos ou a qualidade de baterias, o que considerou como
ou fornece. commodities.
Na época um dos líderes 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 liderança mundial na
venda de aparelhos, partindo de uma simples empresa de eletrônica periférica,
sendo atualmente copiada pela enxurrada de novos fabricantes orientais, que
para disputar o mercado insistem numa estratégia de preços reduzidos. A série de
soluções (amplas) adotadas pela empresa, sempre com uma visão geral sobre o
seu mercado e sobre os costumes, tendências e interesses dos seus clientes finais,
fez com que conquistasse e mantivesse a posição de líder. Essa mesma visão é que
criou um ambiente aberto de discussão com desenvolvedores de software de todo
o mundo, que continuam colaborando para sua expansão e liderança.
94

É importante observar que há nesses quatro casos, sejam de

sucesso ou de fracasso, algumas características e alguns traços
comuns. Observe:
Ambiente de cooperação – um partido amplo de visão

não acontece onde as pessoas sentem-se limitadas no
seu relacionamento; a visão 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 cooperação, ou seja,
onde as pessoas gostam de ajudar e de receber ajuda,
admitindo que isso não seja uma forma disfarçada
de aproveitamento, permitem liberdade de expressão
(mesmo que seja a idéia do “sapo enterrado”!).
Conhecimento técnico aliado à visão de mercado

– certamente apenas um ambiente de cooperação não é
suficiente, pois em problemas técnicos é necessário um
conhecimento específico. Porém apenas o conhecimento
técnico é algo limitante, e deve ser contrabalançado com
uma visão externa, voltada para o mercado e para outras
facetas não-técnicas.
Multidisciplinaridade – ao mesmo tempo é difícil

ter conhecimento técnico em muitas e variadas áreas,
especialmente na atualidade onde há tantas tecnologias
e elas se desenvolvem tão rapidamente. Equipes
trabalhando em conjunto e com alto grau de cooperação
são capazes de reunir conhecimentos de diferentes
disciplinas, capazes de gerar soluções de ampla visão.
Visão medíocre – o contrário desse ambiente de

cooperação e multidisciplinar acontece onde impera uma
visão medíocre, aquela que não admite relacionamentos
e que acredita que, se alguém dá uma sugestão, é porque
está “planejando algo”. Também faz parte da visão
medíocre a confusão que une ciência exata e crenças,
fazendo com que um problema seja analisado sob o
ponto de vista do “achismo”. Muitos técnicos excelentes,
engenheiros que conheci e que eram tidos por gênios na
universidade, resolveram ficar alheios ao desenvolvimento
dos seus colegas, supondo que sua imensa capacidade
Unidade 3 95

seria o bastante para resolver os grandes problemas do

futuro. Hoje, infelizmente, muitos deles estão presos
às suas baias, resolvendo mini-problemas sob as ordens
de gerentes pouco espertos, porém politicamente
articulados.
Política pessoal – a articulação política de caráter

pessoal é, necessariamente, a visão restrita. Centrada no
“eu”, torna-se incapaz de um partido abrangente para
as soluções, mesmo que para problemas estritamente
pessoais. Isso se estende para a postura de solução de
quaisquer problemas, e quando se dá no nível empresarial
pode ser uma catástrofe. Nos casos citados acima vimos
o que significou na contratação 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 práticas (renovadamente restritas).
Por fim, para completar esta seção, cabe dizer que as estratégias
são definidas e implementadas com uma visão de partido amplo,
e as questões operacionais estão definidas sobre questões restritas,
ou partes de uma estratégia. O momento em que uma ou outra
devem acontecer é que define o tipo de visão a tomar.
SEÇÃO 2 – Requisitos do cliente e solução de problemas

A expressão “requisitos do cliente” é comum entre os
desenvolvedores de software, e para muitos outros profissionais,
de outras áreas, parece uma expressão nova.
O cliente nesse caso é aquele que precisa resolver

um problema, ou que está gerando uma demanda
específica e, deste modo, tem uma idéia aproximada
daquilo que quer obter.
96

Como você já viu anteriormente, esse cliente conhece talvez

alguns dos efeitos de um problema, mas geralmente não todos.
E quando tem um desejo, no fundo não sabe exatamente como
expressá-lo. Considere que muitas vezes você mesmo é o cliente,
e perceba o quanto você “não” sabe expressar suas necessidades
com exatidão.
Aquele que foi chamado, por algum motivo, para resolver o

problema de um requisitante qualquer, antes de tudo precisará
saber afinal “qual é o problema a resolver” e qual é o resultado
esperado, seja para arrumar um conjunto de monitores
com oscilações, seja para desenvolver um novo software de
relacionamento com fornecedores e clientes finais.
O primeiro passo a tomar é coletar o maior número possível de

informações. A coleta de informações está presente em todas
as etapas do trabalho, desde a primeira reunião com um cliente
ou no nascimento da idéia de um projeto, passando por todas as
etapas do projeto até a chegada do resultado, sendo um precioso
instrumento de aperfeiçoamento e correção contínua. Nesse
sentido, cada etapa de um projeto pode ser vista como um novo
começo, onde os requisitos das etapas devem ser novamente
levantados e analisados.
Nas etapas iniciais, a coleta vem diretamente do cliente que

solicita a solução de um problema, mas em casos onde há uma
idéia de produto, por exemplo, tais informações podem vir da
literatura e de experiências prévias, seja dos desenvolvedores, seja
de outros envolvidos no projeto.
Alguns procedimentos para levantar os requisitos básicos do

cliente, ou as informações para o desenvolvimento de um novo
produto ou sistema, e encaminhar uma primeira visão geral do
problema/solução são:
se o problema a ser resolvido está escrito, devem-se listar

as informações que estão no seu enunciado, na tentativa
de detalhar o melhor possível suas partes;
se for um defeito a eliminar, descrever todos os efeitos

conhecidos e enumerar todas as possíveis causas;
Unidade 3 97

se for um novo produto ou processo a desenvolver, listar

o que deve ser determinado pela solução, ou seja, definir
com a maior clareza possível o que está sendo buscado;
a partir dos dados levantados e do partido amplo

do problema, deve-se criar modelos e esquemas de
representação, permitindo uma melhor visualização do
conjunto. Nesse sentido o desenvolvimento de desenhos
esquemáticos, diagramas e fluxogramas, torna-se útil
para a compreensão do todo, mesmo que tais desenhos
não sigam modelos padronizados (isto não importa nesse
momento);
além das informações listadas, dos desenhos e de outros

dados coletados, é importante verificar as leis físicas
associadas e suas equações, no caso dos problemas
científicos, mas também outros impeditivos e limitantes,
tais como questões jurídicas, restrições técnicas,
restrições ambientai etc.;
tomar proveito de modelos computacionais e simuladores

como ferramentas de apoio para compreender o
problema, retratá-lo e simular situações, bem como
aprimorar o desenho de diagramas, gráficos de
planejamento (os quais veremos e estudaremos ainda
neste livro), aplicar hipóteses de solução e desenvolver
esquemas gerais e/ou detalhados.
O desenho da figura a seguir reproduz esses passos na forma

de um diagrama de coleta de informações para a solução de
problemas. Como se pode notar é um diagrama genérico que não
esgota as possibilidades de tipos de problemas ou idéias originais
a serem transformadas em projetos. Mas dá uma clara percepção
da necessidade de coleta do maior número de informações,
inclusive de fontes externas ao problema, para então chegar à fase
de se criar hipóteses de solução.
98

Problema
definido
ou
Dados Desenho, Hipóteses Objetivos

Defeito a diagrama
eliminar coletados de solução do projeto
ou modelo
ou
Novo Outras
produto informações
Figura 3.3 – Diagrama do nascimento do projeto com coleta de informações e requisitos do cliente.
Com as hipóteses de solução formuladas, podemos traçar

objetivos de chegada considerando as hipóteses com maior chance
de sucesso. Esses objetivos traçados serão perseguidos em todo o
projeto, e para isso é preciso definir um caminho de trabalho para
abordar o projeto. Esse caminho está definido no algoritmo do
projeto, apresentado na próxima seção.
SEÇÃO 3 – Algoritmo do projeto

Como você já estudou na disciplina de Lógica de Programação,
o algoritmo permite modelar um determinado programa (ou
projeto) de maneira que você deve entender e definir com
exatidão todos os passos que devem ser seguidos, para que o
mesmo chegue ao resultado esperado. Tendo um objetivo bem
definido, conforme você observou na seção anterior (veja de novo
a figura e o último quadro, à direita), é preciso determinar um
fluxograma genérico de atividades, até o objetivo ser atingido
com sucesso (ou não!, mas isso é outro problema e você verá mais
adiante).
O algoritmo apresentado na figura a seguir foi adaptado a partir

de uma proposta de Meillir Page-Jones (1990). O fluxograma se
inicia a partir dos objetivos definidos, e vai ser encerrado quando
os mesmos forem alcançados.
Unidade 3 99

Nesse algoritmo podemos ver o conjunto de atividades que

determina a Gestão do Projeto:
planejamento;
definição e organização dos recursos;
acompanhamento da execução;
medição dos resultados obtidos; e
revisão, quando então o ciclo reinicia, se necessário.
- Acompanhe o desenho a seguir e analise cada uma das etapas,

verificando o fluxo das atividades.
Objetivos do projeto
Planejamento
Ferramentas de apoio
das atividades
Definição dos
recursos
Obtenção dos
recursos
Integração dos
recursos
Execução das Acompanhamento

atividades e medições
Revisão do projeto Os objetivos

NÃO foram alcançados
SIM
Encerramento do projeto
Figura 3.4 – Algoritmo genérico com o fluxograma do desenvolvimento do projeto.
100

Planejamento das atividades – o planejamento consiste

em dividir o objetivo geral do projeto num conjunto
de pequenas tarefas, ou pequenos objetivos, que vão se
encadeando numa seqüência determinada, a fim de atingir
o resultado esperado do projeto. Também consiste em
definir recursos materiais, financeiros 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.
Definição dos recursos – a definição dos recursos
é uma das tarefas do planejamento, porém, coloco à
parte no algoritmo e logo após a fase do planejamento
para destacar a importância dessa etapa. Muitas
vezes a definição dos recursos necessários não é bem
determinada, o que pode acarretar em carências na
etapa da execução, que podem então ser fatais. Definir
com a maior exatidão os recursos necessários, sejam eles
financeiros, materiais, equipamentos ou pessoal com
a qualificação necessária, contribuirá para completar a
fase do planejamento e para diminuir riscos. Recursos
subestimados levarão a importantes faltas, enquanto
recursos superestimados levarão a custos altos,
inviabilizando o projeto em alguns casos.
Obtenção dos recursos – somente com uma boa
definição de recursos é possível partir para a fase da
sua obtenção, o que pode ser uma tarefa bastante difícil
no processo do projeto. Se for um projeto dentro de
uma grande organização, 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 serão
necessários, o que tomará um determinado tempo até ser
obtido. Essa demora não é favorável, por exemplo, nas
áreas de alta tecnologia.
Integração dos recursos – os recursos podem vir de
fontes diferentes e, muitas vezes, guardam grandes
diferenças entre si. Pense, por exemplo, num conjunto
de pessoas, com diferentes habilidades, e que ainda não
se conhecem. Ou então na utilização de equipamentos
novos, ainda não dominados por todos. Nesse sentido é
Unidade 3 101

que a integração dos recursos assume importante papel,

determinante para o progresso do projeto dentro do
prazo estipulado. Nesse momento é que são organizadas
as equipes, distribuídas as tarefas e feitas as discussões
iniciais de repasse de informações. Arranjos de layout
de produção, organização de máquinas, montagem de
laboratório, treinamento e comunicação do planejamento
completo para todos os envolvidos, são atividades desta
etapa. A unidade 5 estará dedicada ao estudo dos
recursos humanos na equipe de projeto.
Execução das atividades – muitos enxergam que o
projeto só está de fato em desenvolvimento quando
se inicia a execução das atividades. Isto é um grande
engano, como já pudemos ver pela quantidade e
importância das etapas precedentes, que são etapas
preparatórias e de planejamento. A etapa da execução é
onde os recursos materiais são utilizados pela equipe, que
desenvolve a série de tarefas designadas no planejamento,
tendo em vista atingir os sub-objetivos, numa ordem
tal que permita chegar aos objetivos finais desejados.
Vamos tomar como exemplo algo muito simples como
a construção de uma casa. Depois de elaborados os
projetos e tendo listagens de materiais e memoriais
descritivos, que definem em detalhe como se construirá
a casa (essa é a etapa do planejamento), passa-se a
fazer os orçamentos, contratar pessoal e reuni-los para
discutir, com um partido amplo, como será a construção
e os prazos a serem cumpridos (essas são as etapas dos
recursos). A partir de então, começa a execução do
projeto, que provavelmente foi subdivido em fundações,
alvenaria, telhado, rebocos, instalações etc. Na unidade
6 estudaremos a etapa da execução, acompanhamento e
revisões do projeto.
Acompanhamento e medições – como a execução
deve seguir o planejamento, certamente deverá haver
o acompanhamento e a verificação do andamento do
projeto, avaliando periodicamente a concordância entre
uma coisa e outra. Muitas vezes é nessa etapa onde se faz
mais visível a presença da gerência, devido ao controle
do planejamento. Como o objetivo geral deve ter sido
subdividido em pequenos objetivos, com metas e prazos
102

menores, faz-se necessário verificar o alcance de tais

metas com medições periódicas, ou seja, nos prazos
determinados para cada sub-objetivo. Voltando ao
exemplo do parágrafo anterior, o acompanhamento
da obra se dará com a verificação, por exemplo,
da qualidade e do prazo atingidos para acabar
as fundações, depois para se levantar as paredes,
sempre comparando com o prazo inicialmente
definido. Desta forma é possível prever com maior
segurança os possíveis atrasos e/ou estouros do
orçamento (que não são desejados!!).
Revisão do projeto – durante o acompanhamento e
medições, caso os objetivos não sejam alcançados, seja
devido ao tempo gasto para chegar até aquele ponto,
seja pela qualidade diferente da esperada, o projeto
deve passar por revisões. Rever o projeto durante o
seu andamento significa reavaliar constantemente o
planejamento, bem como redefinir os objetivos quando
necessário. Caso a revisão seja feita apenas no final
do projeto, pode acarretar em enormes frustrações
(financeiras ou de expectativa). A figura abaixo
representa esse ciclo de revisão a cada etapa do projeto,
que deve seguir adiante caso os sub-objetivos, esperados
naquela etapa, tenham sido alcançados. Se não foram
alcançados, uma revisão da etapa deve ser feita, deve
indicar possibilidades de modificação e retificação, que
devem passar então por um replanejamento para seguir
adiante. Satisfeita a condição, vai-se para a próxima etapa
até alcançar os objetivos gerais do projeto.
Replanejamento
Os sub-objetivos
Revisão da etapa
foram alcançados?
NÃO
SIM
Próxima etapa
Figura 3.5 – Fluxograma específico da fase da revisão.
Unidade 3 103

Encerramento do projeto – encerrar o projeto

significa alcançar aos objetivos. (Bem, infelizmente
nem sempre isso acontece, como veremos na unidade
7, onde discutiremos “sucesso e fracasso” de projetos).
A finalização do projeto não é simplesmente acabar
um produto ou compilar um código. O encerramento
é uma etapa bem definida do projeto, onde toda a
documentação deverá ser organizada e entregue àquele
que o encomendou, com a comunicação mais completa
e abrangente possível sobre o resultado alcançado e os
problemas e soluções que se encontrou. Esta etapa será
estudada na unidade 7.
Ferramenta de apoio – esta não é uma etapa de um
projeto, no entanto é algo importantíssimo e vem
ganhando ainda mais destaque com a informatização
atual. Você viu anteriormente que os “gráficos de
Gantt”, foram desenvolvidos para poder visualizar,
esquematicamente, as etapas de um projeto ao
longo do tempo. Esses gráficos constituíram-se em
ferramentas fundamentais no planejamento de projetos
e em seu acompanhamento. Muitas inovações foram
introduzidas sobre ele posteriormente e, recentemente,
tais gráficos, que eram manuscritos, passaram a fazer
parte de programas computacionais, sendo gerados
automaticamente a partir dos dados de entrada
cadastrados durante o planejamento. Existem várias
ferramentas desse tipo atualmente, e você poderá usar
uma delas, gratuita, para os exercícios de fi xação 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á
disponível para uso gratuito. O nome do produto é “Free Project
Management Software”, mais conhecido como jxProject, e está
disponível para download no sítio www.jxproject.com. Este
software é de uso bastante simples, porém de grande utilidade
pois cria gráficos de Gantt de grande qualidade com a inclusão
de dependências entre tarefas (o que você verá em detalhes na
próxima unidade deste livro).
104

Veja a seguir uma tradução que fiz diretamente do texto de

apresentação do jxProject, que está disponível em inglês no
original, no sítio mencionado anteriormente.
Se você está buscando um Software de Gestão de Projetos

Gratuito, então você veio ao lugar certo. Você pode instalar
jxProject em todos os seus computadores sem nenhum custo.
Você também 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
usuários de Mac OSX têm relatado seu grande sucesso usando
este software. E como é possível? O aplicativo é financiado por
propaganda, colocada na parte superior à direita da janela do
aplicativo, e tal propaganda é que financia o desenvolvimento e
manutenção desse sistema.
História: fundado em 2001 por Peter Hawkins, com a missão

de colocar uma cópia de jxProject em todos os computadores.
Palavras de Peter Hawkins: ‘Tenho trabalhado em computação
desde que me formei em Engenharia Mecânica 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 várias
tecnologias aplicadas a negócios com TCP/IP, HTTP, RDBMS, OLAP,
Java e Windows em indústrias diversas como a de produtos de
software, saúde, comunicações sem fio e comércio eletrônico.
Em outro trecho do seu depoimento Peter Hawkins comenta:

Existem duas tecnologias que mudaram fundamentalmente
a maneira como softwares devem ser desenvolvidos. São:
Arquitetura Orientada e Objeto e execução 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
significativamente para a falta de eficiência no desenvolvimento
de software hoje em dia. Parte do que venho fazendo com
o jxProject está aperfeiçoando meus próprios métodos para
incorporar tais novas tecnologias. Vejo positivamente os escritos
de Eliyahu M. Goldratt, cujos livros ‘Theory of Constraints’ e
‘Critical Chain’ nos dão uma visão mais completa das forças que
agem sobre os processos de negócios.
Unidade 3 105

O mais popular software comercial de gestão é 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á disponível também em www.
microsoft.com/brasil/office/project/standard.asp. O MSProject
é uma marca registrada e é o produto de maior sucesso hoje da
Microsoft, depois do Office.
Veja a seguir algumas informações gerais sobre esse produto,

extraídos do sítio da Microsoft (www.microsoft.com).
Certamente tais informações são de âmbito comercial, e cada
usuário deverá verificar com cautela se o produto se ajusta ou não
às suas necessidades, especialmente em produtos como esse, que
não estão voltados para aplicações específicas, mas sim pretendem
atender a uma gama de atividades. Esse tipo de pretensão em
softwares tem a desvantagem de abrigar um número excessivo de
módulos e acessórios, o que acaba por incluir uma complexidade
desnecessária para o usuário.
O Microsoft Office 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 não exigem
coordenação rigorosa com outros gerentes de projeto nem a capacidade
de gerenciar recursos a partir de um repositório central. O Project Standard
2003 foi projetado para aprimorar a capacidade de organizar o trabalho e
para comunicar de maneira eficiente e sucinta por ferramentas familiares e
fáceis 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
orçamento. Com o Project Standard 2003, é possível:
Organizar seu trabalho de maneira mais eficiente, com recursos e
poder de planejamento poderoso.
Controlar e avaliar os impactos do planejamento e alterações de

recursos em todos os planos do projeto.
Personalizar planos para capturar informações específicas para seus

projetos.
Exibir as informações do projeto que você deseja revisar.
Dar enfoque às informações que precisam de sua atenção com filtros

e grupos.”
106

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 eficiente e sucinta, permitindo que você:
Aumente seu impacto sobre o trabalho, usando Copiar
Imagem para o Assistente do Office para comunicar e
apresentar idéias e informações do Project Standard 2003 em
outros programas do Office System como Microsoft Office
Word 2003, Microsoft Office PowerPoint® 2003 e Microsoft
Office Visio® 2003.
Comunique mais claramente usando novos aprimoramentos
de impressão para imprimir cópias de uma página de
planejamentos de projeto.
Compartilhar informações do projeto com membros da
equipe, salvando arquivos do Project (MPP) em um site do
Microsoft Windows® SharePointTM Services (WSS). WSS é
um componente do Microsoft Windows Server 2003 que
permite que os usuários criem sites para compartilhamento de
informações e colaboração de documentos.
Iniciar rapidamente as ferramentas que auxiliam na
metodologia de gerenciamento de projetos para que você
possa configurar agendas e gerenciar recursos de maneira
mais eficiente.
Acessar ajuda online e treinamento para obter assistência 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
sofisticado e de impacto sem a necessidade de treinamento
extensivo.
Economizar tempo movendo informações do projeto
facilmente entre o Project 2003 e outros programas do Office
como Microsoft Office Excel 2003.
Navegar e aprender o Project Standard 2003 rapidamente com
uma interface atualizada consistente com os programas do
Microsoft Office 2003.”
Esses são outros softwares de gestão disponíveis no mercado, mas

a introdução de novos produtos comerciais continua todos os dias.
Cada empresa ou gestor deve escolher o que melhor se adapta ao
seu estilo:
Unidade 3 107

Gantt Project Open Project System.

Pert Chart Expert. Rational Project
WBS Chart Pro. Manager.

Mindmanager. PS8.
Primavera Team Play. Tassc Estimator

Manager.
PMOffice.
SEÇÃO 4 – Prazo geral

Prazo é um tema especial em Gestão de Projetos e de Equipes.
Projetos são estabelecidos com prazo determinado.

Como vimos, se não houver uma data aproximada para o
empreendimento ser encerrado, então não temos um projeto e
sim uma tarefa de rotina.
A definição do prazo é algo que nasce dos requisitos

do cliente, pois os objetivos por ele definidos só têm
sentido se forem cumpridos até uma determinada
época, onde então podem ser aplicados.
Observe um exemplo bem prático de não cumprimento do prazo:
Você lembra do exemplo das pirâmides do Egito? Essa

noção não estava muito clara naquele tempo, onde
muitas vezes a pirâmide não ficava pronta antes de o
faraó morrer (também não era possível prever a sua
morte, ou seja, o projeto não tinha um prazo muito
fácil de determinar).
108

A discussão sobre prazos deve se dar considerando as

vantagens que o projeto busca, as condições reais da equipe de
desenvolvimento e os recursos disponíveis. Na opinião de Meillir
Page-Jones (1990) há quatro questões que fazem os projetos
terem prazos irreais. Tais prazos irreais, à primeira vista, são
exeqüíveis, porém 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) “Racionalização do desejo”
Page-Jones considera que esse primeiro fator se dá
quando alguém, que tem poder sobre a equipe, imagina
um prazo qualquer e, conforme seu desejo, impõe uma
data final aleatória. Isso pode acontecer, por exemplo,
quando um político define a data para uma inauguração,
sem ter a mínima noção do tempo e das questões legais que
envolvem a contratação e a execução 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 é
adaptável. 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 máximo, ele talvez consiga configurar um conjunto

de pequenas tarefas com prazos muito justos, dando a entender
que talvez seja possível cumprir a meta. Após uma partida
acelerada os membros da equipe terão que fazer paradas de
revisão, talvez correções e ajustes e, então, o prazo começa a ceder
e a equipe, cansada, diminui a capacidade de produção.
b) “Estimativa prematura”
Se a estimativa do prazo total for feita muito no começo da
análise do que será o projeto, tal data pode parecer imutável
(para os membros da equipe) e muito provavelmente será irreal.
Ora, muitas das particularidades do projeto serão percebidas
conforme se aprofunda a discussão e o planejamento do projeto,
e só então será possível prever com maior acuidade os prazos
das diversas etapas, culminando com um prazo global mais
próximo da realidade de execução. A estimativa prematura
acontece no afã de se ter uma data final para o projeto ficar
Unidade 3 109

pronto, mas devemos controlar esse desejo. Certamente

a estimativa dependerá em muito do domínio que se
tem da tecnologia empregada no projeto. Tomemos
como exemplo o caso da construção civil. Esse setor é
tradicional e as tecnologias empregadas são dominadas
e se repetem de uma obra para outra. Nesse caso, é
relativamente fácil perceber todas as implicações das
etapas do projeto, e os gestores conseguem definir
datas realistas. O mesmo não acontece com projetos
mais complexos como, por exemplo, o desenvolvimento
de uma nova máquina ou um sistema computacional para
automatizar um processo industrial. Mesmo que as tecnologias,
individualmente, sejam bem dominadas, provavelmente
a inter-relação entre conhecimentos diversos, e mesmo as
reais necessidades do cliente, serão de difícil coordenação e
necessitarão de reajustes e re-análises contínuas.
c) “Compromisso progressivo”
Page-Jones atribui uma conotação bastante negativa para esse fator,
por considerar de procedimento não-ético. Consiste em estabelecer
um escopo de projeto reduzido para a equipe, que então define um
prazo para tal escopo. A partir do início da execução o contratante,
ou mesmo o gestor, vai ampliando o escopo e mostrando sua
verdadeira composição, com constantes incrementos de necessidades
e de compromissos. Não dando mais para voltar atrás, a equipe tenta
ajustar as novas necessidades dentro do planejamento, estressando
dessa forma todo o trabalho. Perdas e danos podem ser irreparáveis,
nesse caso, especialmente pelo sentimento de ter sido enganado, e
certamente não haverá prazo cumprido.
110

d) “Escala de valores”
O que Page-Jones chama de escala de valores está apresentado
na figura 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 finalizado
estão representados pela linha contínua. A definição da melhor
data para entregar o projeto está relacionada com o melhor valor
agregado possível. Parta do princípio que tal “primeira data”
seja exeqüível, e que todas as análises levaram a definir essa
data como adequada. Os atrasos que ocorreram farão a data de
entrega escorregar para a direita no gráfico, e o valor adicional
de vantagens vai diminuindo proporcionalmente, até atingir um
ponto onde não há mais valor agregado, e os prejuízos começarão
a aumentar progressivamente.
Considere o projeto para desenvolver um novo

alimento, algo que será lançado na Páscoa, por
exemplo. Caso o lançamento se dê muito próximo da
data festiva, não será possível vencer a concorrência
e o encalhe de produtos pode ser catastrófico. Ou o
lançamento de um novo veículo no final do ano. Se
o projeto não for concluído a tempo, você já sabe
como será o resultado para o fabricante. Nessa “escala
de valores” é que se baseiam as datas para definir
lançamento de novas versões de software, ou novas
plataformas, e assim por diante. Não é, portanto, algo
aleatório ou baseado em “desejos”, e desta forma deve
ser bem medida a capacidade de realizar o projeto,
para que a frustração não seja fatal.
Unidade 3 111

$
Curva dos
custos do
projeto
Valor agregado Curva do

valor gerado
pelo projeto
Início do Primeira Data fatal Tempo

projeto data de onde os custos
entrega superam as
vantagens
Figura 3.6 – Representação das vantagens relativas de um projeto considerando o prazo

(adaptado de Page-Jones, 1990).
- Então, o que não fazer no momento de definir prazos de um projeto?
Bem, considerando as implicações que você acabou de ver, é

importante:
Não ceder ao primeiro impulso de se definir uma data,

sem antes analisar o máximo possível de dados do
projeto.
Perceber quando a data definida não passa de um “desejo
racionalizado”, e então 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 série de novos compromissos que não
haviam ficado claros no início.
Perceber com a maior clareza possível a escala de valores
do projeto ao longo do tempo, evitando embarcar em um
projeto onde a primeira data de entrega esteja próxima
demais da data “fatal”.
112

SEÇÃO 5 – Viabilidade do projeto

Você já estudou sobre a origem das idéias de novos projetos,
das suas motivações, dos requisitos do cliente, da visão geral do
projeto e do conceito de prazo nesse tipo de empreendimento
com hora marcada para terminar. Porém resta analisar, antes
de começar um projeto, se de fato ele é viável e quais os riscos
envolvidos na sua execução.
Muitas vezes um projeto é iniciado sem um estudo de

da sua viabilidade nem dos seus riscos, o que tem sido
a fonte de inúmeros fracassos.
Mesmo os projetos muito simples precisam de um estudo de

viabilidade, e tal estudo dará condições de se tomar as melhores
decisões desde o seu início, minimizando riscos, despesas
extraordinárias e atrasos.
Projetos complexos, que envolvem múltiplas disciplinas

e grandes custos, podem exigir um estudo de viabilidade
como documento preparado por consultoria externa e
análise aprofundada.
Alguns autores definem como sendo três os fatores

preponderantes a serem analisados num estudo de
viabilidade: recursos, custos e benefícios. Considero que
o prazo é um quarto fator, apesar de ser visto como parte
dos recursos disponíveis (o tempo é um recurso, assim como o
dinheiro), pois o prazo muitas vezes é determinado externamente
e não é variável.
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-

relações, observando que no estudo de viabilidade tais fatores
ainda não são estimados com grande nível de detalhamento, mas
apenas o suficiente para se ter uma “visão geral do projeto”.
Unidade 3 113

custos prazo
recursos benefícios
Figura 3.7 – Fatores fundamentais na viabilidade dos projetos.
Benefícios
Os benefícios são os resultados positivos esperados do projeto
depois de finalizado. Alguns dos benefícios são facilmente
mensuráveis e outros não. Os mensuráveis são aqueles que
poderemos comparar com o que se tinha antes do projeto ter sido
realizado.
Observe a lista de exemplos:
Aumento do patrimônio (construção de máquina-

ferramenta, edificação).
Aumento do faturamento (ascensão das vendas,
redução de desistências).
Maior lucratividade (diminuição de custos, maior
preço de venda devido ao valor agregado ao
produto).
Maior agilidade (na produção, na resposta a
solicitações externas e internas).
O projeto pode trazer também uma série de benefícios cuja

medição não é tão simples quanto comparar lucros ou tempo de
resposta. Nesse caso estamos falando de benefícios intangíveis,
que podem ser tão ou mais importantes que os tangíveis.
114

Pense nos seguintes itens:
Aumento da satisfação dos clientes (apesar de ser possível

medir por meio de pesquisas, este é um item subjetivo e
bastante variável).
Fixação de determinada marca como líder de qualidade.
Sensação de “time vencedor”.
Recursos
Considere os recursos como sendo materiais (equipamentos,
instalações, softwares etc.) e humanos (a equipe do projeto).
Projetos que envolvem o desenvolvimento de novas máquinas, por
exemplo, exigirão como parte dos recursos o acesso a laboratórios
de testes.
Acompanhei, por um período, o desenvolvimento de

novos equipamentos de telefonia de uma empresa bastante
inovadora. Para que seus produtos pudessem ter sucesso na
acirrada competição desse mercado, era necessário que tivesse
determinadas certificações emitidas por laboratório credenciado
em organismos nacionais e internacionais.
Esse tipo de laboratório era raro na sua região e, desta forma, a

empresa se via obrigada a recorrer a laboratórios do exterior. Esse
era um recurso difícil para ela. Diferente do setor de hardware, Para obter outras
o setor de software dispõe de maiores facilidades de recursos, informações acesse o sítio
e nisso se baseia o crescimento de certas regiões carentes de da SOFTEX - Sociedade para
Promoção da Excelência do
recursos caros (como o exemplo do laboratório). Software Brasileiro, sobre
os mercados de software
Países como o Brasil, China e Índia conseguem crescer do Brasil, China e Índia,
rapidamente nesse setor por esse motivo, onde os recursos disponível em: http://www.
materiais são escassos, mas recursos humanos talentosos são softex.br/cgi/cgilua.exe/sys/
abundantes. start.htm?sid=177 .
Você vai conhecer, em detalhes, sobre a questão dos recursos

humanos e sobre a constituição de equipes neste livro, mas é
importante ressaltar aqui que os recursos humanos adequados
não são apenas os que detêm certo tipo de conhecimento técnico,
algo que não é o bastante. É preciso dispor de pessoas com
conhecimento técnico e com capacidade de trabalho cooperativo,
base fundamental de todo projeto.
Unidade 3 115

Custos
Considerando os recursos materiais e humanos necessários para o
desenvolvimento do projeto, recursos financeiros serão necessários
para custeá-lo. A esses recursos damos o nome de custos do
projeto, geralmente considerada a sua parte mais delicada.
Ora, é possível dispor de excelente pessoal, idéias brilhantes,

domínio tecnológico e um mercado potencial, mas as dificuldades
da sobrevivência diária podem impedir o uso de certo montante
de dinheiro em um projeto, mesmo considerando seu provável
sucesso.
Isso não é um contra-senso, pois o uso de tal montante pode

significar a paralisação de uma estrutura já em andamento (é o
que acontece, por exemplo, com as pequenas empresas de base
tecnológica, que para financiar novos projetos necessitam de
recursos externos, geralmente governamentais).
Há também projetos importantíssimos, mas com custo tão

alto que os inviabiliza. Veja o exemplo do Projeto Iridium, de
telefonia global com o uso de estações em satélites, que acabou
falindo devido aos seus enormes custos.
Essa foi uma entre as 20 maiores falências da história

americana, onde cada simples telefone com acesso
a algum dos 66 satélites do sistema custava U$
3.000. Com esse preço houve poucos usuários
dispostos a comprar, o que inviabilizou a construção
a manutenção do sistema que custou perto de U$ 5
bilhões.
O projeto Iridium não conseguiu emplacar mais de 10 mil

usuários. O problema é que além do custo do aparelho havia
também o problema do alto custo do minuto, a dificuldade de
usar o equipamento dentro de edificações e as falhas constantes
de sinal. Junto a isso ainda tivemos a introdução da telefonia
celular, muito mais barata e útil em suas aplicações. Calculem o
prejuízo e a falta de análise de custos e benefícios deste caso.
116

Prazo
A questão da definição de prazos você já estudou na seção
anterior, e aqui cabe ressaltar seu papel fundamental na análise
da viabilidade de um projeto.
Certamente, se os prazos definidos forem irreais, o projeto será

inviável e fracassará
O estudo de viabilidade deve considerar o prazo com especial

cuidado.
Muitas vezes o projeto encomendado tem os recursos

necessários, pessoal especializado e com grande domínio
da tecnologia, e o pagamento é bastante bom, mas o prazo
exageradamente curto não pode ser resolvido com a inclusão de
mais pessoas, por exemplo.
No desenvolvimento de um sistema computacional o acréscimo

de membros na equipe pode, às vezes, significar o acréscimo de
confusão.
Voltando agora à figura 3.7, você pode observar que esses quatro
fatores são elementos inter-relacionados. Considerando tais
relações é possível aprofundar o estudo de viabilidade.
Verificando esse conjunto de fatores e suas inter-relações,

percebe-se que uma espécie de sombra está o tempo todo
rondando a análise: estamos falando dos riscos.
Repetidas vezes essa palavra apareceu ou ficou subentendida,

e ela denota algo inerente a todo empreendimento humano: a
chance do erro e do fracasso, seja no conjunto ou no detalhe.
Unidade 3 117

Benefícios versus custos

Apesar de benefícios evidentes, um projeto pode ter custos tão altos
que não é viável executá-lo. Ou, ao contrário, custos muito altos
podem fazer parecer que os benefícios não são razoáveis. Em questões
estratégicas, a visão dos benefícios ultrapassa a capacidade de medir
valores financeiros. O gestor (operacional) enxerga as questões
financeiras imediatas, enquanto o líder (estratégico) poderá ver
oportunidades financeiras futuras.
Gostaria de colocar aqui uma experiência que tive e que ilustra

essa situação. Durante os anos 70 e 80 o Brasil teve de considerar se
investia ou não no desenvolvimento de tecnologia para a fabricação
de circuitos integrados. Gestores, e não líderes, consideraram o custo
alto demais para um país pobre como o nosso e preferiram questões
imediatas (na época) como formar contingentes de mão de obra
barata para a indústria de transformação, construir grandes obras
e negligenciar a educação básica. O mundo deu muitas voltas e
hoje quase a totalidade dos equipamentos incorpora chips, fazendo
deles uma infra-estrutura necessária e de alto valor agregado. Bem,
acontece que novamente agora nos anos 2000 o debate sobre o
desenvolvimento tecnológico da fabricação de chips se colocou em
nosso país, e uma iniciativa do governo gaúcho, em parceira com o
Ministério da Ciência e Tecnologia, está colocando a duras penas uma
unidade de fabricação em Porto Alegre. Comentei o assunto com um
ex-professor de engenharia (graças aos céus não foi meu professor!),
que disse que esse não era assunto para um país pobre como o
nosso. Defensor tácito de um sistema de submissão, ex-professores,
como esse, fazem linha com os que condenam nossa sociedade a
compradora de bens de alto valor agregado. Ele não soube (nem nunca
poderia saber) enxergar os benefícios daquele investimento. Enquanto
isso a China trilhou aquele caminho que negamos a nós mesmos, e
agora está prestes a se igualar à capacidade tecnologia dos norte-
americanos (os resultados todos nós podemos ver).
Benefícios versus recursos

Aquele que contrata o projeto, ou que tem a idéia geradora do mesmo,
percebe seus benefícios, porém será necessário avaliar se os recursos
para sua produção estão disponíveis. Não se trata aqui de ter condições
financeiras para desenvolver o projeto (seus custos). Pode-se ter
clareza dos benefícios a atingir e condições econômicas, mas talvez os
recursos humanos não sejam apropriados, não estejam disponíveis e
118

nem mesmo é possível contratá-los. No exemplo do laboratório

de certificação, citado anteriormente, pode acontecer de estar
disponível apenas em um outro país e com agenda lotada para
muitos meses, independente de podermos pagá-lo ou não.
Tomemos outro exemplo, o do Projeto Apolo para levar o

homem à Lua. Havia dinheiro e benefícios a conquistar, mas os
recursos tecnológicos e os conhecimentos para tanto ainda nem
existiam quando o projeto começou. Nesse caso o estudo de
viabilidade apontava para um projeto de alto risco, que acabou
sendo decidido por questões políticas, e foi vencido depois de
vários anos.
Ou seja, é preciso que os recursos estejam ajustados aos

benefícios a serem conquistados, e o estudo de viabilidade deve
estar atento a isso.
Benefícios versus prazo

É preciso avaliar se os benefícios ainda terão 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 além dos valores financeiros é preciso
também considerar valores intangíveis do projeto.
No exemplo do Projeto Apolo, é bem provável que os valores

financeiros mensuráveis à época tenham sido desastrosos,
mas de maneira alguma foram ruins os ganhos políticos e
científicos, de difícil medição naquele momento (estamos
falando de 1969), mas enormes dali em diante. Lançamento
de novos produtos no mercado, no entanto, não têm um
valor político associado, mas sim a busca de liderança e
posicionamento de marca.
Nesses casos o benefício está fortemente vinculado ao prazo. Essa

análise comparativa deve ser feita na avaliação da viabilidade do
projeto.
SEGUE
Unidade 3 119

Recursos versus custos

Essa análise parece bastante simples: é possível pagar pelos recursos
necessários? O projeto é inviável se a resposta for negativa.
Recursos versus prazo

A pergunta agora passa a ser: os recursos estarão disponíveis pelo
tempo necessário? Pois é possível que se tenha todos os recursos
necessários e dinheiro suficiente para pagá-los, mas tudo continuará
funcionando pelo tempo necessário para o projeto.
Equipes, por exemplo, sofrem desgaste, e as tecnologias

envelhecem (ao contrário do conhecimento científico).
Prazo versus custos

Por fim, é importante considerar por quanto tempo o financiamento
do projeto se manterá. Inicialmente o valor a ser investido pode
parecer adequado, os recursos estão ajustados e os benefícios são
promissores. Mas qualquer extensão do prazo pode significar uma
chamada de investimento, que talvez não esteja disponível. Este risco
é real e sempre muito provável, e tal consideração merece atenção
especial no estudo de viabilidade. Inúmeros projetos fracassam nesse
momento.
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 falência, ao fazermos uma
venda há o risco da inadimplência, e assim por diante.
Por mais que tentemos prever todas as chances de erro, lá elas

estarão. Isso é tão presente em nossas vidas que os riscos entram
até no anedotário. Quem nunca ouviu as famosas (e às vezes
trágicas) Leis de Murphy?
120

Uma delas diz que, “se várias coisas podem dar errado,
elas darão, e na pior seqüência possível”!
- E então, o que você achou? Observe agora o quadro a seguir!
“Leis de Murphy” da Tecnologia

As Leis de Murphy já caíram no anedotário 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 não são leis, mas
levam muita gente a considerar com mais cuidado os riscos.
Veja abaixo as “Leis de Murphy” para a tecnologia, conforme
publicado no sítio da Universidade Federal da Bahia no endereço
http://www.facom.ufba.br/com024/murphya/tecno.htm
(acessado em 12/junho/2005).
O progresso não consiste A fábrica não esqueceu de

em substituir uma teoria entregar, ela nem fabricou
errada por uma certa, e a peça.
sim uma errada por uma
aparentemente certa. Como os teoremas da
matemática se relacionam
O defeito só aparece depois com a realidade, não são
que a unidade passou pela seguros. Sendo seguros
inspeção final. não se relacionam com a
realidade.
Depois que um
Em qualquer circuito
equipamento foi montado
eletrônico o componente
e funciona perfeitamente,
de vida mais curta será
encontram-se em baixo
instalado no lugar de mais
do banco diversas peças
difícil acesso.
fundamentais.
Qualquer desenho de
Se sua experiência
circuito eletrônico deve
fracassou, destrua todas as
conter pelo menos: uma
provas que tentou.
peça obsoleta, duas
As variáveis variam menos
impossíveis de encontrar, e
que as constantes. três ainda sendo testadas
A única peça que a fábrica (por você, é claro).
esqueceu de embarcar Depois que o último dos
é indispensável para a parafusos foi retirado da
montagem de 75% do tampa de acesso de um
equipamento.
SEGUE
Unidade 3 121

Leis de Murphy - continuação
equipamento, verifica-se que Se decalcou, poderia cortar

foi removida a tampa errada. e colar.
Depois que o último dos Se recortou e colou, poderia
parafusos da tampa de um ter xerocado.
equipamento foi apertado, Se xerocou, estava disponível
verifica-se que alguma peça na internet.
ficou para fora.
O êxito de uma demonstração Leis da Dieta:
é inversamente proporcional Pra não engordar há quem
ao número de pessoas coma somente verduras. Os
importantes que assistem a elefantes só comem verdura.
essa demonstração.
Pra não engordar há quem
Todo arame cortado no coma somente peixe. As
tamanho indicado será curto baleias só comem peixe.
demais.
Não há nenhum problema Nada é tão fácil quanto parece,
mecânico tão difícil que não nem tão difícil quanto a
possa ser resolvido com força explicação do manual.
bruta e ignorância. A explicação mais simples
É mais fácil separá-los do que sucede a solução mais
colocar tudo junto novamente. complexa.
Regra de advertência: Para Se tudo que você tem é um

escrever uma bula de remédio, martelo, trate tudo como um
primeiro convença o leitor de prego.
que ele tem a doença sobre a Especialista é aquele cara que
qual ele está lendo; depois de sabe cada vez mais sobre cada
que, ela é curável. vez menos.
Leis do Desenho: Super-especialista é aquele

que sabe absolutamente tudo
Se você desenhou, poderia sobre absolutamente nada.
ter copiado.
Ciência exata é profetizar
Se copiou, poderia ter
sobre o que já aconteceu.
decalcado.
122

Em projetos o que há são riscos:
riscos de acabar o dinheiro;

risco de a idéia não ser assim tão boa;
risco de ninguém se interessar;
risco de o prazo estourar várias e várias vezes;
risco de o código nunca apresentar a saída esperada etc.
Estudar a viabilidade do projeto é, antes de mais

nada, pesar os possíveis benefícios, os custos, a
disponibilidade dos recursos e do prazo, comparando
com os riscos previsíveis capazes de estragarem tudo.
No quadro a seguir você observará um modelo de questionário/

relatório, bastante simplificado (e subjetivo), para um Estudo de
Viabilidade de Projetos. Ele não esgota todas as possibilidades
de análise, pelo contrário. Mas encaminha uma série de questões
iniciais, com as quais devemos nos preocupar, para tentar
perceber se é viável prosseguir com o desenvolvimento do projeto
e contra quais riscos devemos nos resguardar.
Cada projeto, obviamente, trará questões particulares, que devem

ser tratadas e resumidamente descritas. Posteriormente, no caso
do projeto seguir em desenvolvimento, as estimativas detalhadas
de custos, benefícios e recursos serão tratadas, como você poderá
analisar na unidade 4.
Unidade 3 123

Quadro 3.1 – Modelo de relatório para estudo de viabilidade de projetos.
Estudo de viabilidade
<nome do projeto>
Equipe de estudo:
Local e data:
Resumo do projeto (escopo, objetivos, estratégias)
Benefícios: Descrição:
quais são as vantagens mensuráveis que o projeto trará?
quais são os valores comparativos?
Benefícios: Descrição:
que vantagens intangíveis ele trará?
como se poderá verificar?
Recursos: Descrição:
quais os recursos materiais necessários para o projeto?
esses recursos estão disponíveis?
caso não disponíveis, é possível obtê-los?
Recursos: Descrição:
quais os recursos humanos necessários para o projeto?
essas pessoas estão disponíveis para o projeto?
caso não disponíveis, há outras pessoas para substituí-las?
Custos: Descrição:
considerando os recursos necessários, quanto dinheiro será
necessário para desenvolver o projeto?
esse montante está disponível?
Custos: Descrição:
há fontes de financiamento?
Prazo: Descrição:
qual o prazo pré-definido pelo “cliente” para o projeto?
Prazo: Descrição:
considerando a experiência da equipe, qual o prazo estimado para o
projeto? É igual ao pré-definido?
Conclusões quanto à viabilidade do projeto:
Recomendações:
Anexos (tabelas, demonstrativos, estatísticas, reportagens, tendências tecnológicas e comerciais etc.)
124

SEÇÃO 6 – Antecipando e administrando riscos

Como você estudou na seção anterior, os riscos de um projeto já
estão lá antes mesmo de ele nascer.
Você verá que é possível prever os riscos com a maior antecipação

possível e, então, administrar a sua existência (já que não é
possível eliminá-los completamente). Encare o risco como uma
ameaça, que pode levar o projeto ao erro, às perdas e ao fracasso.
Geralmente não é possível evitar essa ameaça.
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 financeiros bem no meio do projeto – essa falta faz
simplesmente o projeto ser abortado. Você deve então
avaliar se há de fato a probabilidade de isso ocorrer. Se o
recurso financeiro para custear o projeto não está depositado
previamente e depende de financiamento externo, a
probabilidade de falta pode ser considerável.
Outra questão se refere ao impacto do risco do atraso do

projeto em um benefício esperado. Se for o lançamento de um
produto de área de forte concorrência, o impacto é enorme
e deve ser avaliada a probabilidade de ocorrer. Há outros casos
onde a probabilidade de ocorrência dos riscos é alta, porém o
impacto deles é mínimo.
Durante o período da construção de uma casa a

probabilidade de chuvas é altíssima, e sendo assim
uma série de atividades alternativas é programada,
fazendo com que esse risco tenha baixo impacto no
projeto.
Outra questão importante se refere à origem dos riscos, onde

a figura a seguir apresenta de modo esquemático. Os riscos
em projetos podem basicamente ser de origem interna e de
origem externa. Essa diferença de origem leva tais riscos a um
tratamento diferente quanto à sua previsão, administração e
eliminação.
Unidade 3 125

Risco externo
Área do projeto Risco interno
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
proposições e não outras.
Como você observou na seção anterior, em um projeto existem

os recursos, os custos, os benefícios e os prazos. A escolha de
determinados recursos materiais, e não outros, pode determinar
a existência ou não de certos riscos. Assim como a escolha de
membros para compor a equipe, considerados competentes
tecnicamente, mas que depois se verifica a incapacidade de
trabalho em grupo.
Podem ser considerados típicos riscos internos dos projetos:
Equipamentos defeituosos;
Equipe despreparada para trabalho em grupo;
Falta de domínio tecnológico;
Gastos excessivos;
Estouro de prazo devido a falhas de desenvolvimento;
Estouro de prazo devido a erros no gerenciamento;
Necessidades tecnológicas desconsideradas durante o
planejamento das etapas;
A complexidade do sistema, não devidamente percebida
nas etapas iniciais;
Alterações no escopo do projeto.
126

Riscos de origem externa

São 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 não era previsível internamente, e aconteceu devido a
causas externas. Dependendo da posição dessa pessoa na equipe,
isto pode afetar seriamente todo o desenvolvimento.
Podem ser considerados típicos riscos vindos de agentes externos

aos projetos:
causas/fenômenos naturais;
crises políticas de uma região ou país;
crises econômicas;
doenças;
problemas do financiador do projeto ou do fornecedor de
insumos/recursos;
alterações na legislação;
pressões da organização, da sociedade, do cliente;
alterações no mercado quanto às suas necessidades ou
capacidade de compra.
Com essas considerações sobre origem, probabilidade e impacto

dos riscos sobre o projeto, há duas possibilidades de ação:
Deixar acontecer e então tentar resolver. Por incrível

que possa parecer esse é o procedimento mais usual,
e a expressão “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 sensação de
fracasso.
Antecipar e administrar os riscos. Essa abordagem
consiste em verificar antecipadamente a existência de
riscos, planejar uma atuação sobre eles tentando eliminá-
los ou, caso isso não seja possível, administrá-los.
Unidade 3 127

Recentemente a Microsoft desenvolveu um framework

para a gestão 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 “gestão de riscos” (Valeriano, 1998).
O processo de administração de riscos deve ser contínuo, 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 identificados devem ser comunicados para todos os
participantes do projeto, seja para os de nível inferior, seja para os
de nível superior (mesmo que isso possa desagradar).
O ciclo para o tratamento dos riscos é composto pelo seguinte:
Identificação de riscos;
Análise;
Planejar ação sobre esses riscos;
Controlar/eliminar os riscos;
Nova etapa do projeto e nova identificação de riscos.
Etapa Nova Etapa

Identificar os riscos
Analisar os riscos
Planejar ação
sobre os riscos
Eliminar ou
administrar
os riscos
Figura 3.9 – Antecipando e administrando riscos.
128

Identificação de riscos
Este é o primeiro passo na administração dos riscos, e consiste
em sua identificação. O modelo apresentado no quadro 2,
abaixo, aponta diversas causas de riscos e proporciona uma
visão do projeto sob a perspectiva de suas ameaças. Esse tipo de
identificação deve ser feita reunindo a equipe do projeto, e a sua
experiência será fator-chave para perceber proativamente os riscos
possíveis. Eles devem ser colocados nas suas respectivas categorias
(quanto a recursos, quanto a custos, quanto a benefícios, quanto
a prazos) de tal maneira que a risco seja o melhor conhecido
possível. A partir da sua identificação, deve ser descrito com
clareza, declarando sua origem e a conseqüência que trará ao
projeto, caso aconteça.
Análise
Partindo da identificação e da expressão 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 não apenas um
risco. Se o risco tiver probabilidade próxima de zero, poderá ser
desprezado.
Quanto ao impacto, se for muito reduzido, talvez não seja

necessário despender esforços na tentativa de eliminá-lo, esforços
esses que devem ser destinados a outras atividades. Não há
certamente uma regra ou uma lei para esse tipo de tratamento.
Talvez alguns livros de gestão de projetos tragam fórmulas
mágicas e escalas com pesos e medidas, mas a análise do risco
detectado dependerá, na verdade, da experiência e bom senso da
equipe. A inexperiência 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 é necessário que
isso aconteça, para que se obtenha experiência!
Nesses casos projetos de baixa complexidade são os

recomendados, e então um processo de identificação e análise
de riscos, bem elaborado e estudado, trará conhecimentos
importantíssimos para a carreira (digo isso porque vejo que a
maioria dos envolvidos em projetos não realiza tais estudos, e só
obtém experiência após excessivos erros).
Unidade 3 129

Uma sugestão muito interessante é a técnica 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”
serão os considerados no planejamento para ações de controle.
Planejar ações sobre esses riscos

Identificados os riscos, conhecidas as suas probabilidades e o
impacto que podem causar no projeto, é preciso planejar ações
para evitar ou reduzir tal impacto.
O processo de planejamento passa pelas seguintes perguntas:
Conhecemos o risco?
Podemos conviver com ele, se acontecer?
Como é possível atenuar seu impacto?
O que é possível fazer para evitá-lo?
As respostas a essas perguntas levarão o projeto a um conjunto de

planos de ação.
Para que você compreenda melhor, retorne ao

exemplo da construção da casa, e como o risco de
chuvas pode ser administrado. Nós conhecemos
esse risco e não é possível conviver com ele, ou seja,
não é possível continuar o projeto normalmente
enquanto chove. Evitar a chuva não é possível, a não
ser que se gaste uma elevada soma e se construa
uma enorme lona de circo sobre a área do projeto (o
que não parece viável). O que é possível fazer então
para atenuar o risco? Em alguns casos o proprietário
simplesmente pára a obra e aguarda o período de
chuvas ir embora. Se ele considerou isso no prazo da
obra, parece ser uma solução. Outra ação possível
seria deixar preparada uma área coberta da obra para
preparação de caixarias, ferragens, e outras atividades
desse tipo.
Num projeto de desenvolvimento de software um risco

considerável está relacionado ao prazo. Se esse risco é de
grande impacto, e uma possível causa sejam as deficiências
130

de conhecimento tecnológico pela equipe, a ação proativa de

treinamentos intensivo pode amenizar tal risco. Outra ação é a
de incluir um membro experiente naquela tecnologia (se houver
recursos financeiros para isso). Enfim, cada risco detectado
merecerá uma discussão sobre ações preparatórias, e quando
os riscos do projeto forem altos demais, talvez seja melhor não
aceitar o projeto.
Controlar/eliminar os riscos
Identificados os riscos, analisados e criados os planos de ação, é a
hora de colocar as coisas para andar. As ações devem ter data para
começar, e uma vez colocadas em andamento, os riscos devem ser
monitorados. Se determinada ação teve sucesso, o risco pode ter
sido eliminado. Caso não tenha sido eliminado e surja no meio
do projeto, deve então ser controlado para determinar o mínimo
impacto possível no projeto. Se havia o risco de um atraso,
por exemplo, e o atraso aconteceu, o plano de contingência
de ampliar a equipe ou terceirizar partes do projeto deve ser
colocado em prática, buscando a todo custo manter a data final de
entrega em garantia.
Controlar os riscos é o último passo do ciclo da administração

dos riscos, e basicamente se divide em:
controlar os planos de ação preventivos;

monitorar a eclosão dos riscos previstos;
responder à eclosão de tais riscos com ações corretivas;
monitorar o surgimento de novos riscos, não previstos;
refazer o planejamento de ações;
integrar-se ao processo global da gestão do projeto.
No quadro 3.2 - Modelo de relatório para estudo de riscos de

projetos, são apresentadas diversas questões importantes para
detecção, análise e ações preparatórias contra os riscos do projeto.
Tal modelo pode, e deve, ser adaptado para as condições 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.
Unidade 3 131

Quadro 3.2 – Modelo de relatório para estudo de riscos de projetos.
Estudo de riscos
<nome do projeto>
Equipe de estudo:
Local e data:
Resumo do projeto (escopo, objetivos, estratégias)
Riscos quanto aos benefícios: Descrição:
- o cliente tem uma idéia exata do resultado a ser obtido?
- ou tem uma idéia aproximada?
- é possível medir os benefícios?
Riscos quanto aos benefícios: Descrição:
- qual a probabilidade desse tipo de riscos?
- qual o seu impacto?
Riscos quanto aos recursos: Descrição:
- há equipamentos de reserva?
- há pessoal de reserva?
- a tecnologia empregada é inteiramente dominada?
Riscos quanto aos recursos: Descrição:
Riscos quanto aos custos: Descrição:
- o financiamento de todo o projeto está garantido?
- há um montante de reserva?
Riscos quanto aos custos: Descrição:
Riscos quanto ao prazo: Descrição:
- há fatores internos ou externos, não considerados, que podem
afetar o prazo do projeto?
- a equipe de projeto é experiente?
Lista dos 10 riscos mais importantes:
Podemos conviver com eles?
É possível atenuá-los?
É possível evitá-los?
Conclusões quanto aos riscos do projeto:
Anexos (tabelas, demonstrativos, estatísticas, reportagens, tendências tecnológicas e comerciais etc.)
132

Síntese
Na primeira seção desta unidade foram discutidas as formas de

se identificar 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 visão geral, de partido amplo, para
que se tenha de fato uma concepção estratégica, e não meramente
tática ou operacional, do projeto. Essa questão é bastante
importante e deve ficar fi xada, para evitar o desenvolvimento
futuro de projetos inconsistentes.
Em seguida, você estudou que na origem de um projeto estão

presentes certos requisitos, que foram chamados de requisitos
do cliente, que são as verdadeiras expectativas de resultado
do projeto, e que, caso não satisfeitas, levarão ao fracasso do
mesmo. Ora, perceber com acuidade tais expectativas é, portanto,
determinante e atenção especial deve estar aí colocada.
Entendidos tais requisitos e colocados sob uma ampla

perspectiva, uma série de passos deve ser determinada então
para planejar e executar o projeto, cujo algoritmo visto na
terceira seção é um modelo importante. Seguir tal algoritmo não
determinará o sucesso do projeto, mas não segui-lo trará, com
grande probabilidade, seu fracasso (a não ser que o projeto seja
muito pequenino).
Algoritmo é um fluxo, e tal fluxo traz inúmeros passos que

devem ser executados num determinado prazo. Projetos, por
definição, têm prazo para acabar. O grande problema então 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 execução. Devemos evitar prazos
irreais apenas para fechar um negócio.
Por fim você estudou “riscos”. Ao nascer o projeto traz no seu

“DNA” a condição do risco, o risco é inerente a qualquer projeto.
Em primeiro lugar porque os projetos têm sempre data para
terminar e o tempo não é algo simples de controlar. E como
os riscos estão entranhados nos projetos é preciso prevê-los e
administrá-los, da melhor maneira possível, para evitar perdas e
corresponder à expectativa dos requisitos do cliente. Há formas
Unidade 3 133

de evitar riscos, ou conviver com eles, mas para isso é preciso

conhecer de onde vêm e qual seu impacto. Para isso foram
desenvolvidos modelos de relatórios e questionários de procura, e
seu uso, aliado à experiência individual dos membros da equipe,
dará tranqüilidade para continuar projetos, mesmo que sob
tempestades.
Na próxima unidade você vai colocar a mão na massa do

planejamento, onde várias técnicas e metodologias serão
apresentadas, estudadas e exercitadas. Enquanto isso, rememore
os conceitos que estão aqui, leia os artigos indicados e trabalhe
nas atividades de auto-avaliação. Os projetos esperam você!
134

1) Considere o seguinte problema, colocado por um cliente:

“Atualmente meu pessoal da área comercial emite propostas de
serviços usando planilhas de cálculo Excel e documentos gerados no
Word. Quando o cliente dá o “aceite” na proposta, muitas vezes vários
itens da proposta foram modificados, porém isso não é 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 fiscal é emitida à mão, e finalmente a reposição do estoque é feita
por meio de constantes verificações nas prateleiras. Eu gostaria de
automatizar meu processo de reposição de estoques.”
Em sua opinião, qual é o escopo do problema segundo uma avaliação
“restrita”, e “qual seria uma visão ampla” desse mesmo problema?
Unidade 3 135

2) Quando o cliente descreve o seu problema, ele o faz com a própria

linguagem e com uma visão particular, que muitas vezes indica um
caminho de solução. Você sabe que muitas vezes esse caminho pode
não levar à melhor solução. Veja a figura a seguir, que apresenta um
diagrama com a coleta de informações e requisitos do cliente, visando
o melhor entendimento do problema proposto. Considerando esse
diagrama e sua experiência, liste as principais ações que você deve
tomar para chegar ao melhor entendimento do problema.
Problema
definido
ou
Dados Desenho, Hipóteses Objetivos

Defeito a diagrama
eliminar coletados de solução do projeto
ou modelo
ou
Novo Outras
produto informações
136

3) Qual a função do algoritmo no planejamento do projeto?
4) Qual a função da revisão durante o projeto? Não seria o mais correto

realizar a revisão apenas após a sua conclusão?
Unidade 3 137

5) Como você define a data “fatal” do projeto ? (veja a figura abaixo)
$
Curva dos
custos do
projeto
Valor agregado Curva do

valor gerado
pelo projeto
Início do Primeira Data fatal Tempo

projeto data de
entrega
138

6) Para uma análise de viabilidade, quais fatores devem ser considerados?

Dê um exemplo de projeto de sua própria experiência de trabalho, e
como tais fatores foram considerados.
7) Riscos são inerentes a qualquer projeto. Por quê?
Unidade 3 139

Saiba mais
1 - www.softex.br/cgi/cgilua.exe/sys/start.htm?sid=177 -
link para estudo da SOFTEX, Sociedade para Promoção
da Excelência 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 situação
do software no Brasil, constantemente atualizados e que
permitem uma visão ampla das oportunidades de negócio no
mercado da informática.
140

4
UNIDADE 4
Planejamento
Compreender os diversos modelos que representam o
desenvolvimento de projetos, especialmente aqueles
voltados para as inovações tecnológicas.
Distinguir duas técnicas de planejamento de projetos,

uma que já tem um século desde sua criação 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 técnicas e métodos de

planejamento, com exercícios e exemplos práticos.
Incorporar o planejamento, por meio de ferramentas, às

atividades iniciais de um projeto.
Verificar que as estimativas de recursos, custos e prazos

são mais coerentes e consistentes quando embasadas
em um planejamento detalhado.
Seções de estudo
Seção 1 Modelagem do fluxo de atividades.
Seção 2 Metodologias de planejamento – Gráfico de Gantt.
Seção 3 Metodologias de planejamento – PERT/CPM.
Seção 4 Estimativa de recursos.
Seção 5 Estimativa de custos.


Esta unidade é fundamental para dar o primeiro passo prático na
execução de um projeto.
Nas unidades anteriores você percebeu que a história dos projetos

na humanidade começou com obras marcantes, mas que não
contavam com um planejamento detalhado. Com a Revolução
Industrial muitas coisas mudaram, especialmente a forma de se
produzir, e o tempo de produção até chegar ao mercado. Você
viu também que, atualmente, para que um projeto possa ser
planejado e conduzido durante a sua execução, é necessário ter
uma visão abrangente e estratégica, com um comportamento
muito mais de liderança do que de simples controle. Mas controle
é necessário.
Nesta unidade você verá algumas ferramentas muito úteis para

apoio ao planejamento, para a estimativa de recursos e de custos,
para a definição de prazos e para a administração dos riscos. Sem
essas ferramentas os projetos seriam praticamente impossíveis
de gerenciar. Será apresentado o Gráfico de Gantt, que
provavelmente você já conhece. Ultimamente esse tipo de gráfico
sofreu alterações e foi incorporado pelos softwares de gestão de
projetos, sendo provavelmente a tela mais popular de todos eles
(quando não a única). Junto ao Gráfico de Gantt você aprenderá,
também, como construir diagramas que mostram o caminho
crítico de um projeto, ou seja, aquela seqüência de atividades que
dependem umas das outras, e que definem então um prazo e uma
condução crítica do projeto. Qualquer alteração nesse caminho
vai afetar todo o projeto (e prazo, em especial).
Tais ferramentas são úteis para o controle do projeto, mas

também permitem toda espécie de estimativas, sejam de recursos
necessários ao projeto, sejam de custos ou de prazos. O estudo
de como realizar essas estimativas é o objeto da conclusão desta
unidade. Bons estudos!!
142

SEÇÃO 1 – Modelagem do fluxo de atividades

Na unidade anterior você estudou que é preciso ter uma visão
geral do projeto que permita avaliar sua viabilidade, os possíveis
riscos, as necessidades gerais para que seja desenvolvido e para
que se obtenham os resultados esperados.
Certamente durante esse processo de visão geral e estratégica,

não é possível detalhar todos os elementos do projeto, mas é
suficiente para decidir sobre a sua viabilidade e então dar um
passo além: partir para o desenvolvimento do projeto.
A partir dessa idéia geral será necessário agora começar a

detalhar o projeto, e o primeiro elemento é a sua modelagem e a
definição de um fluxo de atividades.
O modelo de um objeto é uma representação,

é uma simplificação desse objeto de forma que
possamos entendê-lo de forma abrangente.
- Para ficar mais claro, veja o exemplo a seguir:
A maquete de um prédio é um modelo de como

será o prédio ao ficar pronto. Ele mostra as partes do
edifício, seu aspecto geral, numa proporção muito
boa para que você possa entendê-lo antes de ficar
pronto. Ele não é o prédio, é apenas o modelo do
prédio. No entanto, você pode começar a detalhar
mais e mais o modelo desse prédio, como por
exemplo fazendo os projetos de instalações elétricas
e de telecomunicações dele. Os desenhos dessas
instalações são representações, bem detalhadas, de
como serão tais instalações, porém continuam sendo
modelos pois não são as instalações em si.
Unidade 4 143

Os modelos são usados para facilitar a visão 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 final
esperado.
Há um modelo muito interessante de representação da

realidade, que todos nós usamos, mas não nos damos conta: é
a nossa língua. As palavras, e a forma como elas se relacionam,
permitem que nós possamos representar o real e comunicar para
outras pessoas as nossas idéias. Estas, por sua vez, precisam
compreender esse modelo de representação para decodificar o
que falamos, criar as imagens mentais (compilar), e responder
novamente usando esse modelo comum.
Pessoas que falam línguas diferentes não conseguem se
comunicar, pois não dominam a mesma modelagem.
Nesses casos usam outras formas de representação,
como a mímica, por exemplo, que, no entanto, é muito
mais limitada. Na comunicação entre o ser humano e a
máquina é preciso também uma linguagem.
Modelar, dessa forma, significa representar um

sistema, ou parte dele, em forma física (a maquete,
por exemplo) ou simbólica (desenho do projeto
elétrico, por exemplo), de tal maneira que se possa
predizer ou descrever seu comportamento. Assim,
o modelo de representação é uma idealização do
sistema físico, e ele nos auxilia na análise e na solução
dos problemas. Sem os modelos não haveria a
civilização como a conhecemos.
Algumas das principais características dos modelos, e que fazem

com que tenham grande valor, são:
usando um modelo não é preciso trabalhar diretamente

com o sistema físico real, ou seja, não é necessário pegar
a maçã para querer dizer “maçã”, basta pronunciar a
palavra, ou ainda, não é preciso construir o prédio inteiro
para mostrá-lo, basta desenhar uma fachada ou construir
uma maquete;
144

é prático e seguro trabalhar com modelos, pois caso as

coisas não se afigurem tão boas, você pode abandonar
tudo no começo;
graus de precisão dependerão do aprimoramento

do modelo, ou seja, conforme você queira ter maior
precisão de como será o projeto no final, você pode ir
aprimorando paulatinamente o próprio modelo;
redução de tempo na análise, pois não é necessário ter o

projeto pronto para fazer as primeiras simulações;
o modelo abstrai o problema para o campo de domínio

daquele que o analisa, quer dizer, ao modelar um
problema, cada um o faz no campo que tem domínio;
se é um desenhista, faz o desenho, se é um escultor,
cria a maquete, se é um matemático, coloca na forma de
equações, se é um escritor, coloca na forma de uma ficção
ou poema, e assim por diante;
os modelos não são únicos, ou seja, é possível diversos

tipos diferentes de modelo para uma mesma coisa;
no caso do prédio, pode ser representado por meio de
uma maquete de madeira e papelão, ou então por uma
maquete eletrônica, ou pelo desenho artístico da fachada
etc., sendo que todas terão o seu valor;
como o modelo é apenas uma representação, uma

redução do real, ele contém erros, os quais são inerentes
ao seu caráter de redução.
Com essas características você pode perceber que os modelos têm

inúmeras utilidades, não só para planejar a gestão de projetos,
mas para planejar o próprio projeto. Basicamente pode-se
considerar como utilidades dos modelos de representação:
modelos ajudam a PENSAR – modelos são instrumentos

que permitem visualizar e pensar acerca de um sistema
e do seu comportamento; boa parte dos problemas e
das soluções de um projeto você consegue perceber e
imaginar sobre esse instrumento;
Unidade 4 145

permitem COMUNICAR – com um modelo bem

representado é possível transmitir informações sobre o
projeto, e isto é importantíssimo na gestão da equipe;
é possível PREVER – com um modelo apropriado é
possível simular o comportamento do sistema, e com isso
prever ser provável comportamento;
permitem CONTROLAR – com um modelo você tem
condições de criar sistemas que simulam comportamento,
e dessa forma é possível criar critérios de controle,
inicialmente usados no modelo e depois associados ao
sistema físico real;
ajudam a ENSINAR – assim como os modelos ajudam a
comunicar, passam, assim, a ser importante instrumento
de auxílio na educação 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 Icônico – é o modelo que representa com alto grau de

semelhança o sistema físico, seja em duas dimensões (como no
caso das fotos e mapas, como na figura 4.1) ou em três dimensões
(maquetes, esculturas, protótipos).
Figura 4.1 – Exemplo de representação icônica – mapa urbano.
Modelo Diagramático – tem pouca semelhança com o sistema

físico, e é apresentado por meio de símbolos, linhas, diagramas.
Facilita a compreensão do funcionamento de uma máquina, um
146

processo ou sistema, sem dispersar a atenção em detalhes de outra

ordem, e um bom exemplo disso são os fluxogramas que usamos
nas empresas, mostrando como se dá o fluxo de processos, ou
então o organograma dessa mesma empresa, que mostra como se
distribuem os cargos e departamentos. No entanto, por ser uma
representação um pouco mais especializada, serve para aqueles
que conhecem a convenção usada no diagrama (veja exemplo na
figura 4.2).
Figura 4.2 – Exemplo de representação diagramática – diagrama de atividades da UML

– Linguagem de Modelagem Unificada (GOOCH, 2000).
Modelo Matemático – é um modelo simbólico abstrato, que

está cada vez mais associado aos problemas de tecnologia
avançada, sendo o de aplicação mais importante na engenharia.
Os modelos matemáticos são os mais poderosos instrumentos
de representação, e têm permitido modelos computacionais
sofisticados, porém são altamente especializados e exigem
conhecimento avançado dos usuários.
Unidade 4 147

Modelo Gráfico – é o modelo que representa o comportamento

de fenômenos por meio de curvas, gráficos, facilitando a sua
verificação. Há diversos tipos de gráficos, como por exemplo os
de linhas, com barras, em forma de pizza, etc. (veja por exemplo
aqueles disponíveis no Microsoft Excel), sendo que o traçado se
dá a partir de um conjunto de valores previamente definidos pelo
usuário.
Para desenvolver um projeto você precisará, antes

de tudo, criar um modelo de como se dará o
desenvolvimento desse projeto.
Projetos muito pequenos não precisam de um modelo, assim

como a construção da casinha do cachorro não precisa certamente
de uma planta dessa casinha. Se, no entanto, ela tiver algum grau
de complexidade maior, é melhor desenhar.
Tendo o modelo em mãos você poderá, dessa maneira, utilizar
métodos de planejamento (que você verá na próxima seção) e
criar um detalhamento de como se desenvolverá o projeto.
Na figura 4.3 você pode perceber como se dá o fluxo do

conhecimento durante o desenvolvimento de um projeto
tecnológico. As diferenças entre os três tipos de fluxos definem
prazos diferentes de entrega, mas podem depender de como se
deu a contratação e quais os riscos aceitáveis. A percepção clara
de como se dará o desenvolvimento do projeto permitirá uma boa
divisão e detalhamento das atividades.
Execução,
Idéias, Preparação, Piloto,
MODELO Engenharia
Tempo
Pesquisa Desenvolvimento
SEQUENCIAL
MODELO
SEQUENCIAL
COM Tempo
SOLAPAMENTO
MODELO
COM Tempo
SOLAPAMENTO
Figura 4.3 – Três modelos de fluxo de conhecimento no desenvolvimento de projetos

tecnológicos.
148

Na etapa inicial das idéias, chamada de “pesquisa”,

são adquiridos os conhecimentos e informações
necessárias para dar início ao projeto.
Veja como se dá o fluxo no modelo seqüencial, cujo diagrama

está apresentado na figura 4.4.
Não há passagem para a próxima etapa, chamada de

“desenvolvimento”, sem que todas as atividades da primeira
etapa tenham sido concluídas. Na etapa do desenvolvimento
ocorrem as primeiras implementações do projeto como, por
exemplo, a escrita das primeiras versões de um software, a criação
do protótipo, os testes iniciais, as simulações, etc.
No modelo seqüencial a passagem para a etapa de

“engenharia” só ocorrerá quando a etapa anterior
estiver concluída. Na engenharia se dará a
implantação do projeto, a criação de um piloto e sua
colocação efetiva no mercado como, por exemplo,
na finalização e entrega de um novo produto, o
que inclui o início do funcionamento e suporte, ou
a colocação em linha de fabricação de uma nova
máquina. No modelo seqüencial o conhecimento
adquirido em cada etapa não influencia a etapa anterior, e novas
decisões são tomadas apenas com os conhecimentos já obtidos.
Esse modelo de desenvolvimento de projetos é conservador, e

toma maior tempo de realização total, pois nenhuma atividade
segue seu andamento se a atividade anterior não tiver sido
totalmente concluída.
A construção civil, por exemplo, usa esse modelo

seqüencial como padrão e isso faz sentido, pois o
tipo de projeto pressupõe fases bem divididas e com
requisitos de precedência.
Precedência: em projetos
as atividades podem ter
relações de dependência
com outras atividades
anteriores, as quais são
pré-requisitos para o seu
início.
Unidade 4 149

MODELO SEQUENCIAL
Pesquisa
Desenvolvimento
Engenharia
Conhecimentos obtidos na etapa.
Problemas a serem resolvidos na etapa.
Figura 4.4 – Modelo seqüencial de desenvolvimento de projeto, conforme Sáenz (2001).
Se, no entanto, as etapas sofrerem um certo grau de mesclagem,

de tal forma que a etapa seguinte tenha início enquanto a etapa
anterior ainda está na fase de encerramento, chamamos tal
modelo de seqüencial com solapamento.
Esse não é ainda um modelo radical de desenvolvimento de

projetos, pois a ordem das etapas está bem definida, mas o fato de
uma etapa já ter início enquanto a outra ainda se desenrola, faz
com que conhecimentos e problemas da etapa seguinte interfiram
positivamente na etapa anterior, obrigando revisões dinâmicas do
processo.
Como você pode ver no desenho da figura 4.5, os conhecimentos

adquiridos em uma etapa podem interferir na solução de
problemas ainda da etapa anterior. Com isso há ganho de
tempo no projeto, pois algumas decisões tomadas farão com
que determinado problema ou risco futuro sejam controlados ou
mesmo eliminados.
Projetos de equipamentos ou softwares são exemplos

para esse tipo de modelagem.
150

Modelo Sequencial com Solapamento
Pesquisa
Desenvolvimento
Engenharia
Figura 4.5 – Diagrama de modelo seqüencial com solapamento, inspirado em Sáenz (2001).
A situação radical de desenvolvimento de projetos é aquela onde

as diferentes etapas estão totalmente entremeadas. Certamente
esse é o caso onde é possível obter o resultado do projeto no
menor prazo possível, mas isso exige um enorme controle e
gestão detalhada. O que não é simples!
O diagrama da figura 4.6 mostra essa situação, chamada de

modelo com solapamento, e percebe-se que os conhecimentos
e problemas de uma etapa interferem nas soluções de todas as
outras etapas, sejam anteriores ou posteriores.
Controlar tais interferências, para que sejam proveitosas

para o projeto, passa a ser um dos grandes problemas desse
modelo. Problemas relativos à montagem e engenheirização
de determinado produto podem gerar conhecimentos que
terão grande valor lá na etapa das idéias iniciais, pois com tais
conhecimentos seria possível já imaginar soluções que vão alterar
o formato final do produto.
Unidade 4 151

O fluxo de tais informações precisa então ser contínuo, e esse

tipo de modelo pressupõe ênfase nos ambientes de comunicação e
integração de equipes, assunto que será discutido nas unidades 5
e 6.
Modelo com Solapamento
Pesquisa
Desenvolvimento
Engenharia
Figura 4.6 – Solução radical: modelo com solapamento (inspirado em Sáenz, 2001).
Nesta seção você conheceu a modelagem do fluxo das atividades

de um projeto, e como podem ser os diversos modelos de
representação, sejam do fluxo ou mesmo do projeto como um
todo. A modelagem permite uma visão estratégica do projeto.
A partir dessa visão estratégica é possível dar início à sua

operacionalização e, para isso, você pode contar com métodos e
ferramentas, assunto da próxima seção.
152

SEÇÃO 2 – Metodologias de planejamento – Gráfico de Gantt

Caso seja importante representar todo o projeto por um modelo
estratégico, geral, para fazermos o seu planejamento é necessário
descer nos detalhes, ou seja, decompor todo o trabalho em suas
menores partes.
Essa decomposição significa 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 decomposição” ou na forma de tabelas
(VALERIANO, 1998). Tanto a árvore quanto a tabela trazem as mesmas
informações, sendo que a diferença está na forma de apresentação.
Veja as figuras 4.7 e 4.8 a seguir. Ambas nos mostram uma

divisão de tarefas do projeto fictício denominado “Exemplo”.
Na figura 4.7 você pode ver a tabela com o rascunho da divisão
de etapas e com as diversas tarefas que serão necessárias 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
• Definições
• Compra materiais
• Organiza equipe
• Documentação
• .....
Etapa 2
• Desenho
• Montagem
• Documentação
• .....
Etapa 3
• Teste 1
• Teste 2
• Documentação
• Encerramento
• .....
Figura 4.7 – Tabela com divisão de tarefas de um projeto “Exemplo”.
Unidade 4 153

A árvore da figura 4.8 representa as mesmas tarefas e etapas,

porém numa representação espacial, o que para algumas pessoas
facilita a compreensão dos diversos componentes. É uma questão
de escolha.
Projeto EXEMPLO
Etapa 1 Etapa 2
Definições Compra Org. Equipe Documentação Desenho Montagem Documentação
Etapa 3
Teste 1 Teste 2 Documentação Teste 1
Figura 4.8 – O mesmo projeto da figura 4.7 em uma divisão por árvore de decomposição.
Com esse tipo de divisão de tarefas você pode imaginar e

localizar todos os componentes do projeto. A partir dessa divisão,
você poderá iniciar a construção do planejamento para execução e
gestão do projeto.
Agora você vai estudar três métodos para planejar o

desenvolvimento do projeto:
Gráfico de Gantt;
Diagramas PERT e
Método do Caminho Crítico – CPM.
São métodos que vêm sendo desenvolvidos nos últimos cem
anos, especialmente após a Segunda Guerra Mundial, tendo tido
grande ênfase nos anos recentes com os projetos que envolvem
desenvolvimento de software e sistemas de alta tecnologia.
154

Gráfico de Gantt
O gráfico de Gantt também é chamado de gráfico

de barras. Foi concebido pelo engenheiro norte-
americano Henry L. Gantt (1861-1919) (Hinojosa,
2003) para tentar resolver o problema da
programação de diferentes atividades industriais.
Essas atividades foram distribuídas no calendário 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
duração da atividade que tal barra representaria.
Ou seja, o início da barra marcaria a data de começo da atividade

e o final da barra seu término, sendo que a barra se estende por
todo o período compreendido entre as duas datas.
A figura 4.9 mostra um exemplo de Gráfico de Gantt desenhado
em planilha (neste caso com o auxílio do MS Excel). Você
pode ver que o projeto se estende do dia 14/março até 15/abril,
e é constituído de quatro etapas, havendo dois projetistas neste
trabalho. As barras pretas mostram os prazos previstos para a
execução de cada Etapa/Tarefa.
Figura 4.9 – Exemplo de Gráfico de Gantt.
Este tipo de gráfico permite desenhar uma barra com a duração

prevista, e junto a ela outra barra que vai sendo preenchida
conforme as tarefas vão sendo cumpridas, de tal forma que é
possível acompanhar o andamento do projeto e a proporção de
atraso ou quanto se está adiantado em relação ao previsto.
Unidade 4 155

Na figura 4.9 você pode ver a barra cinza da Etapa 1 mostrando

o andamento do projeto até aquele momento. Se o gráfico estiver
nessa posição no dia 21 de março, então você pode perceber que o
projeto está cumprindo seu prazo.
Nesse exemplo, no eixo horizontal há um calendário com a

escala de tempo pertinente e mais adequada ao projeto (dias,
semanas, meses etc). E, no eixo vertical as atividades que serão
executadas, sendo que a barra de duração 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 visualização
que se requer. Projetos com equipes muito grandes costumam
imprimir tais gráficos em painéis grandes, para que num único
relance você possa ver as etapas, como vai indo o dia-a-dia do
projeto, os principais responsáveis, datas de início e fim etc.
O gráfico que Henry Gantt criou tornou-se imensamente

popular e passou a ser utilizado, sem grandes modificações,
no gerenciamento de todos os tipos de projetos em todo o
mundo.
Uma das desvantagens apontadas era que o gráfico não

interligava uma atividade à outra, ou seja, não deixava clara
a interdependência entre as diferentes atividades.
Versões recentes desse tipo de gráfico passaram, assim,

a utilizar setas de ligação entre as diferentes barras, para
mostrar esse tipo de dependência, especialmente a partir do uso
de softwares como o MS Project.
Porém, não é necessário um software para se construir o Gráfico

de Gantt, e justamente por isso é tão popular e essa é uma das
suas grandes vantagens: o traçado 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 modificações no planejamento acontecem, o
gráfico começa a se tornar confuso. A replanificação exige que se
faça um novo gráfico.
156

Também é outra desvantagem o fato de que o

gráfico de Gantt não apresenta custos das etapas, e
dificilmente se adapta a projetos muito complexos
com múltiplas tarefas simultâneas. Nesses casos se
usam outros métodos, como PERT e CPM, que serão
apresentados adiante.
- Para que você compreenda melhor, observe o exemplo a seguir:
Você agora vai conhecer um exemplo simples para aplicação do

Gráfico de Gantt. Você irá construir uma área de lazer com 30
metros quadrados, churrasqueira, pia e banheiro (e no final da
disciplina a gente faz uma festa para comemorar, o que acham?).
Este não é um exemplo de projeto de software, mas é

suficientemente comum para que você explore todas as questões
relacionadas ao gerenciamento de um projeto que envolve equipe.
A idéia partiu do cliente, que pretende fazer uma comemoração,
e deu a você o prazo de oito semanas para entregar a obra pronta,
sendo que todos os materiais para a obra são fornecidos por ele.
Tudo começa pela decomposição do projeto em tarefas e, para

isso, você deve utilizar a decomposição em tabela, como aquela
mostrada no exemplo da figura 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 não há uma regra específica para isso, a não ser o
conhecimento e a experiência particular de cada um.
Proponho então a seguinte divisão:
Unidade 4 157

Projeto CHURRASQUEIRA
Etapa 1 – Preparação do terreno
• Limpeza do terreno
• Medições e marcações
• Escavações
Etapa 2 – Fundações
• Montagem das madeiras de caixaria
• Montagem das ferragens da fundação
• Concretagem
Etapa 3 – Alvenaria
• Construção das paredes
• Montagem da churrasqueira
• Rebocos
Etapa 4 – Telhado
• Montagem da estrutura de madeira
• Colocação de Telhas
Etapa 5 – Piso
• Concretagem do piso
• Assentamento da Cerâmica do piso
Etapa 6 – Carpintaria
• Colocação de janelas
• Colocação de portas
Etapa 7 – Instalação Hidráulica
• Tubulações de água
• Colocação da caixa dágua
• Montagem de torneiras, descargas, acessórios
• Esgoto
Etapa 8 – Instalação Elétrica
• Instalação das Tubulações
• Passagem dos cabos alimentadores
• Montagem das tomadas, luminárias e quadros
Etapa 9 – Pinturas e acabamento
• Pintura externa
• Pintura interna
• Limpeza final e entrega da obra
Figura 4.10 – Tabela com divisão de tarefas do projeto “Churrasqueira”.
158

Ao analisar a divisão acima, você irá perceber que o projeto

não é tão simples quanto podia parecer à primeira vista, pois há
inúmeras tarefas, as quais ainda poderiam ser mais detalhadas.
Por ser um exemplo, é suficiente o que está definido acima.

Considerando essas nove etapas, você pode construir um gráfico
de Gantt simples e útil para este projeto.
Você pode começar 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 figura 4.11 a seguir.
Neste desenho incluí algumas divisões para facilitar o

trabalho, tais como a divisão das colunas das semanas nos
seus sete dias, com marcação do sábado (S) e do domingo
(D), e nas barras horizontais há uma divisão que marca o
prazo previsto (Prev) e outra divisão para depois se anotar
o realizado (Real), conforme o projeto for andando.
Além disso, no espaço reservado para escrever o nome das etapas,

há também um questionamento sobre quem irá realizar aquela
tarefa, ou seja, quem é o responsável por aquela tarefa específica.
Isso é muito útil para poder distribuir as responsabilidades, e da
mesma forma é útil para aquele que vai trabalhar nela, pois pode
compreender sua função no conjunto das atividades bem como o
impacto de seu prazo sobre o restante.
Figura 4.11 – Planilha para Gráfico de Gantt do projeto “Churrasqueira”.
Unidade 4 159

O prazo de dois meses parece ser bastante enxuto, então é preciso

ser cuidadoso na distribuição dos prazos para que se tenha
sucesso. Veja que neste projeto o sucesso significa acabar antes
do dia da comemoração, não sendo admitida outra possibilidade.
A equipe que trabalhará neste projeto será constituída, além
do gestor (você), também de um mestre de obras, um pedreiro,
um servente, um carpinteiro, um eletricista, um encanador e
um pintor. São oito pessoas, sendo que alguns estarão presentes
apenas em algumas etapas da obra. Fazendo uma reunião
preliminar com todos os membros da equipe, são estimados os
seguintes prazos de execução para cada etapa:
Projeto CHURRASQUEIRA Prazos estimados pela equipe Dependência

Etapa 1 – Preparação do terreno 2 dias —
Etapa 2 – Fundações 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 – Instalação Hidráulica 1 semana Etapa 4
Etapa 8 – Instalação Elétrica 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

chegarão a 13 semanas e 3 dias, o que supera a data final
definida. Porém, algumas atividades podem ser feitas em
paralelo, e nesse sentido é que você pode traçar o primeiro esboço
de gráfico de Gantt, que está apresentado na figura 4.13.
160

Figura 4.13 – Gráfico de Gantt do projeto “Churrasqueira” – primeiro esboço.
Algo que você pode notar neste gráfico é que, para adequar o
projeto ao prazo total, é necessário colocar algumas atividades em
paralelo, e isso é muito natural. O serviço do telhado começou
mais ou menos no meio das atividades de alvenaria, e o piso está
dividido em duas fases, sendo que a segunda fase aparece apenas
após o encerramento de todo o trabalho da alvenaria. Da mesma
forma as instalações hidráulicas e elétricas estão divididas em
duas etapas.
Este projeto é simples, então não é difícil perceber

essas possibilidades de trabalho em paralelo para
otimizar o tempo e a equipe. Porém, se alguém
que não conhece o projeto der uma olhada neste
gráfico, não entenderá porque há uma interrupção na
instalação hidráulica em determinado ponto, e nem
porque ela começa na quinta semana e não apenas na
sétima, por exemplo.
Uma divisão mais detalhada facilitaria essa visão externa, e

certamente também facilitaria a própria gestão do projeto.
Uma nova opção de gráfico de Gantt deste mesmo projeto está
apresentada na figura 4.14.
Unidade 4 161

Figura 4.13.2 – Gráfico de Gantt do projeto “Churrasqueira” (assumimos a sequência de atividades definidas pelo
“mestre de obras”).
Este gráfico detalha melhor algumas fases, que permite que se

veja a dependência entre um serviço e outro. A dependência não
está explícita no gráfico, porém alguém com mais experiência
perceberá que o serviço de telhados depende da finalização
da construção das paredes, e após o telhado ficar pronto serão
colocadas as tubulações elétricas e hidráulicas. A concretagem do
piso poderá ser feita também após a conclusão do telhado, e você
começará a pintura externa após a colocação das janelas e portas.
Depois da conclusão do piso, serão feitos os acabamentos das

instalações elétricas, passando todos os cabos e instalando
tomadas e luminárias, bem como instalando acessórios da parte
hidráulica. Por fim, será feita a pintura externa e limpeza geral da
obra, e afinal haverá uma festa no domingo!
Bem, este exemplo é obviamente uma suposição de serviço, mas

ele espelha exatamente o que ocorre em todos os projetos. É
comum que se tenham muitas dúvidas quando o serviço está por
começar e, assim, é necessário fazer alguns desenhos iniciais e
avaliar se será útil a divisão que você pensou inicialmente. Caso
não seja, ou caso você perceba que é possível detalhar um pouco
mais, então é importante fazê-lo.
162

No gráfico anterior foi também preenchido o nome da pessoa da

equipe responsável por cada etapa. Desta forma é possível definir
as atividades de cada um, e assim o trabalho individual será
otimizado.
O eletricista, por exemplo, poderá participar de vários

outros projetos, bastando para isso preparar sua
agenda conforme a distribuição de tarefas em cada
projeto.
Para relembrar alguns tópicos estudados nas unidades e

seções 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 seqüencial
de trabalho, ou teria sido o modelo seqüencial com
solapamento?
Se você voltar à figura 4.4 perceberá que no modelo seqüencial

existe a passagem de uma etapa do trabalho para outra sem
alternativa de retorno. Já na figura 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 interfiram na
maneira de se realizar algo na outra atividade.
Este é o caso das atividades de instalação hidráulica e
elétrica, que acontecem quando ainda se está realizando
a alvenaria. Certamente algumas soluções pensadas em
quaisquer dessas atividades podem interferir positivamente
nas demais, como por exemplo:
combinar passagem de tubulações pelos mesmos

caminhos, evitando desperdícios;
nível de caimento para as águas;
existência de espaços de reserva (como cantos e
reentrâncias na parede);
e muitos outros.
Unidade 4 163

Por essa análise, conclui-se que o modelo de desenvolvimento do

projeto é o seqüencial com solapamento, que já é tradicional na
construção civil.
E quanto aos prazos, houve uma estimativa de prazos?

Houve uma estimativa de recursos? Estimativa de
custos e de benefícios?
Essas questões foram debatidas na unidade anterior, onde frisei

a necessidade de se fazer tais levantamentos e análises para
permitir, só então, o desenvolvimento do projeto.
Considere esse projeto como bastante simples, que partiu de uma

contratação onde o cliente já definiu algumas dessas questões.
Veja:
Prazo – o ponto de partida do projeto foi justamente

um resultado desejado num determinado prazo: a
comemoração com churrasco. Essa data definiu o prazo
limite, para o qual tivemos de nos adequar.
Benefícios – se prestarmos atenção na resposta anterior
já se percebe claramente o benefício: a churrasqueira
do cliente, onde ele poderá realizar suas festas; nesse
caso não há um produto a ser lançado no mercado, onde
o valor será medido pelo retorno financeiro, mas sim
haverá valor pelo retorno em qualidade de vida.
Recursos – não tivemos problemas com recursos
materiais, pois o contratante previu o seu fornecimento;
precisamos então nos preocupar com a equipe (nossos
recursos humanos).
Custos – com base na quantidade de trabalho envolvida,
no número de horas e nas especialidades de pessoal,
um orçamento foi entregue ao cliente, que neste caso
aceitou tais custos e teve de fazer os aportes financeiros
semanalmente (é a prática na construção civil).
E quanto aos riscos? Você consegue prevê-los?
164

Como você pode ver na figura 4.13, o prazo estimado em cada

atividade faz com que você tenha pouca folga no projeto, caso
algum problema aconteça. E eles podem acontecer!
Considere que ocorra um período de chuvas justamente durante
as três primeiras atividades: preparação do terreno, fundações e
alvenaria. Certamente haverá atrasos nessas etapas, e isso poderá
afetar todo o projeto, pois como tais atividades estão encadeadas
e delas dependem todas as restantes, dizemos que tais atividades
perfazem um caminho crítico.
O método do caminho crítico será discutido mais adiante. O

gestor do projeto terá que pensar em alternativas. Outros riscos
são a falta de pessoal por motivos alheios (doenças, mudanças),
problemas financeiros 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 gráfico da figura 4.13 para analisar outra

característica desse tipo de diagrama. Apesar de você já saber
que uma atividade deve começar apenas quando a outra terminar
(como por exemplo o telhado somente após as paredes e estrutura
estarem montadas, nesse caso), isso não está evidente no desenho.
A pessoa que não conhece o projeto não perceberá esse tipo de

dependência. Foi preciso avançar na construção desse tipo de
diagramas e introduzir relações de dependência, o que se dá em
todos os modernos softwares de geração de gráficos de Gantt.
Você pode criar dependências de quatro tipos entre atividades:
Dependência fim-início, quando o início de uma

Atividade B só é possível após o fim da Atividade A.
Dependência fim-fim, quando o final da Atividade B deve,
necessariamente, coincidir com o fim da Atividade A.
Dependência início-início, quando o início da Atividade
B deve, necessariamente, coincidir com o início da
Atividade A.
Unidade 4 165

Dependência fim-início com folga, quando o início de

uma Atividade B só é possível após o fim da Atividade
A, porém há um tempo de folga para o início da
Atividade B.
A representação gráfica dessas relações de dependências é feita

com setas interligando as extremidades das atividades, como você
pode ver nas figuras seguintes:
Atividade A
Atividade B
Figura 4.14 – Dependência Fim-Início num Gráfico de Gantt, onde B depende de A.
Atividade A
Atividade B
Figura 4.15 – Dependência Fim-Fim num Gráfico de Gantt, onde B depende de A.
Atividade A
Atividade B
Figura 4.16 – Dependência Início-Início num Gráfico de Gantt, onde B depende de A.
Atividade A
Atividade B
FOLGA
Figura 4.17 – Dependência Fim-Início com folga num Gráfico de Gantt, onde B depende de A.
166

A introdução das setas que mostram dependências foi um

grande avanço na visualização do planejamento, antes apenas
possível pela distribuição das barras num gráfico com escala de
tempo. Essa introdução permitiu perceber que as setas poderiam
indicar algo mais no gráfico, e daí em diante um novo conjunto
de gráficos e diagramas foi desenvolvido e chegaremos, então, ao
Método do Caminho Crítico (CPM) e diagramas PERT. Mas
isso será assunto para a próxima seção.
Antes, para encerrar esta seção, veja duas ilustrações com

exemplos de softwares que usam Gráfico de Gantt com setas de
dependência.
Na figura 4.18 você pode ver uma tela gerada pelo jxProject de
um projeto exemplo. Na figura 4.19 há outro projeto, onde a tela
foi gerada pelo Microsoft Office Project.
Figura 4.18 – Exemplo de Gráfico de Gantt, software jxProject.
Unidade 4 167

Figura 4.19 – Exemplo de Gráfico de Gantt, software Microsoft Office Project.
SEÇÃO 3 – Metodologias de planejamento – PERT/CPM

Após a Segunda Guerra Mundial surgiu um projeto do governo
norte-americano que acabou gerando uma profunda influência
na disciplina de gestão de projetos. Era o projeto Polaris, da
Marinha, para produzir uma série 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 desconfiança 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 desconfiança e ter o projeto aprovado, foi criada uma
equipe especialmente para planejar e fiscalizar o andamento
do projeto e a construção dos submarinos. Essa equipe foi
denominada Program Evaluation and Review Task Force, gerando
a sigla PERT, que posteriormente viria a denominar a técnica de
168

representação do planejamento do projeto por eles desenvolvida

– Program Evaluation and Review Technique - PERT.
O projeto Polaris surpreendeu e foi desenvolvido em

apenas três anos, o que atraiu grande atenção para a
equipe e para a técnica que eles desenvolveram para
a gestão de projetos.
Na década de 60 muitas melhorias foram incrementadas à

técnica, incluindo o Critical Path Method – CPM (Método
do Caminho Crítico), e todas as técnicas de representação de
projetos por redes de atividades e dependências acabaram sendo
reunidas atualmente no que se denomina PERT/CPM.
A idéia dessas técnicas era criar um diagrama que verificasse

os pré-requisitos de cada atividade, de tal forma que se pudesse
compreender qual seria o conjunto de atividades, com seus prazos
e em seqüência cronológica, de tal maneira que fosse possível
traçar o “caminho crítico” do projeto, ou seja, a seqüência de
atividades que determinariam o menor tempo possível do projeto.
Dentre as várias aplicações das técnicas PERT/CPM pode-se citar:
definir as atividades de um projeto;

determinar a duração de cada atividade;
com base nos prazos de cada atividade, buscar o
prazo mínimo para o projeto total;
encontrar as ligações temporais entre as diversas
atividades, ou seja, verificar os tempos de folga
entre atividades seqüenciadas;
identificar quais atividades são críticas 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 seqüência crítica do projeto
considerando as atividades críticas, ou seja, determinar a
seqüência de atividades críticas que perfazem o “caminho
crítico” do projeto;
Unidade 4 169

verificar os tempos de folga que existem entre as

atividades, de tal modo que se possa trabalhar com esses
prazos durante a execução do projeto sem afetar o prazo
total.
Diferente do Gráfico de Gantt, onde cada atividade ocupa uma
barra do painel, nessas técnicas de revisão e do caminho crítico
são usadas setas para compor o diagrama, como no desenho
da figura abaixo (figura 4.20), onde cada seta representa uma
determinada atividade (atividade A, atividade B....) e os círculos
representam um evento ou nó, que é a conclusão de uma ou mais
atividades.
Como você pode ver no diagrama, a duração de cada

atividade não está representada pelo comprimento
da seta, pois os comprimentos dessas não têm escala.
O que mais importa aqui é verificar qual atividade
depende de outra, sua precedente.
No caso do exemplo da figura 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 concluídas as atividades C e D. Ou seja,
o diagrama de setas define uma lógica para a seqüência de
execução.
Figura 4.20 – Diagrama de setas simples com nós, que denotam a conclusão de atividades.
170

As diferenças entre os métodos como o Gráfico de

Gantt e as técnicas PERT/CPM acontecem devido ao
tipo de representação e de escala utilizada.
No Gráfico de Gantt há uma escala de tempo bem definida, mas

a representação das precedências, da vinculação entre diferentes
atividades e do “caminho crítico” não são evidentes.
Para dar início ao estudo das técnicas PERT/CPM, faça

primeiramente uma comparação gráfica entre os diferentes
métodos, e então evolua a partir desse ponto.
Na figura 4.21 há duas representações para o projeto

“Churrasqueira”, que já foi tratado na seção anterior. Na parte
superior da figura você pode ver o Gráfico de Gantt, exatamente
o mesmo que foi apresentado na figura 4.13 (para maior clareza
do desenho, retirei as linhas que representam “prazo realizado”).
Na parte inferior da figura está uma representação por diagrama

de setas do mesmo projeto, onde as letras denominam as
atividades, conforme a seguinte tabela de correspondência:
A preparação do terreno
B fundações
C alvenaria - paredes
D alvenaria - reboco e cerâmicas
E telhado
F piso
G carpintaria
H tubulação hidráulica
I instalação hidráulica
J tubulação elétrica
K instalação elétrica
L pintura externa
M pintura interna e acabamento
Unidade 4 171

Figura 4.21 – Diagrama de setas com escala e acima o Gráfico de Gantt do projeto “Churrasqueira”.
O diagrama de setas do projeto “Churrasqueira” da figura 4.21

está construído dentro da escala de tempo definida no gráfico de
barras que está acima dele, como você pode ver.
Perceba que cada nó está colocado exatamente na coluna que

representa o início ou final de uma determinada atividade.
Repare, por exemplo, na atividade E – Telhado: o nó onde
começa a seta está no início do dia 7 de abril, e o nó no final da
seta está no dia 13. A seta E, então, compreende 7 dias.
Mesmo para um projeto simples como este o

desenho com setas acaba se tornando razoavelmente
complexo e, de fato, não mostra muitas coisas. Da
forma como está apresentado parece um modelo
diagramático ruim, e o Gráfico de Gantt estava bem
melhor, não é?
Acontece que a riqueza desse tipo de diagrama não está em

representar na escala temporal o desenvolvimento do projeto,
mas sim nos mostrar os seus pontos críticos de atraso. Vamos
então fazer duas modificações no diagrama de setas do projeto
“Churrasqueira”:
172

Redesenhe o diagrama para que fique mais claro,

retirando a escala de tempo.
Para não perder a referência das atividades quanto ao seu
prazo estimado, coloque sob cada seta o número de dias
de sua duração.
Com essas duas modificações simples você terá o diagrama da
figura 4.22 (Apesar de atividades diferentes, reunimos A,B e C
em apenas um arco para simplificar o diagrama).
Figura 4.22 – Diagrama de setas modificado do projeto “Churrasqueira”.
Bem, apesar de ser um desenho limpo, ainda não é

suficientemente claro para ajudar no planejamento do projeto.
É o momento, agora, de definir alguns conceitos e símbolos

para construir os diagramas PERT/CPM. Com tais símbolos,
apresentados no quadro da figura abaixo, você poderá fazer a
construção final do diagrama do projeto “Churrasqueira” e partir
para sua análise como ferramenta de apoio na gestão de projetos.
Unidade 4 173

Figura 4.23 – Quadro com simbologia e nomenclatura utilizados em diagamas PERT/CPM.
Como se vê na figura 4.23, alguns novos conceitos estão

apresentados, tais como “data mais cedo e mais tarde”, folgas e
símbolos com informações.
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 específica
da atividade é chamada de “folga”.
174

A sequência de atividades que define o prazo crítico do projeto,

ou seja, aquela seqüência onde alterações implicam uma alteração
do prazo total do projeto, é chamada de “caminho crítico”.
Volte agora ao diagrama da figura 4.22. É possível, ainda,

simplificar um pouco mais o desenho. Veja que o nó ao final da
atividade D, o nó que dá origem à atividade L e o nó ao final 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”, simplificação 1.
Você sabia que este diagrama pode ser simplificado mais uma
vez? Veja a seguir como isto pode acontecer:
A seta fantasma que une os nós do final da atividade E e do

início da atividade G pode ser suprimida, juntando então
esses dois nós. Com um pequeno rearranjo das setas e dos nós
você teria, dessa forma, o desenho simplificado do diagrama,
conforme apresentado na figura 4.25.
Repare como o diagrama ficou mais simples e objetivo, e como

foi alterado desde o original, que desenhamos na figura 4.21.
É importante reparar que todo esse processo de construção foi
realizado aqui para demonstrar a construção do diagrama PERT/
CPM, mas na prática você pode desenhá-lo diretamente, apenas
sabendo as atividades, suas precedências e respectivas durações.
Você verá isso num exercício futuro.
Unidade 4 175

Figura 4.25 – Diagrama PERT/CPM do projeto “Churrasqueira”, simplificação 2.
Tendo agora o diagrama desenhado, você irá introduzir os símbolos

que permitem colocar as informações detalhadas do plano.
Em primeiro lugar coloque os nós 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
numeração intermediária (ver figura 4.26).
Como você pode reparar, todas as datas de início, mais cedo e

mais tarde, estão 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 (poderíamos também começar
com “0” e isso não faz diferença, pois os totais serão os mesmos).
Figura 4.26 – Diagrama projeto “Churrasqueira”, detalhamento 1.
176

Tendo a primeira “data mais cedo” definida, você pode ir

preenchendo as dc dos outros nós. A dc do nó 20 será a dc do nó
10 mais a duração da atividade ABC, ou seja,
dc20 = dc10 + duraçãoABC
Com isso o diagrama passa a ser detalhado e temos a figura 4.27

com o nó 20 preenchido.
Considerando a data mais cedo do nó 20 (onde dc20 = 25) você

pode preencher as datas dc dos nós 30 e 40, conforme figura 4.28.
Unidade 4 177

Definido o nó 30 (cujo dc30 = 32) você pode preencher os nós 50 e

60. Repare que o nó 60 será preenchido com a soma da dc do nó
30 e a duração da atividade F, que é mais longa que a atividade
HJ. Assim você terá:
Incidem sobre o nó 70 duas atividades com durações diferentes:

L e IK. Se você considerar a atividade L, terá dc70 igual a 43, mas
se consider a atividade IK, teríamos dc70 igual a 48, que é uma
data mais tarde do que a definida a partir do caminho L. Nesse
caso, obrigatoriamente, deve-se assumir essa segunda data, que é
o dia 48, dia de início da atividade final M. Com isso o diagrama
fica assim preenchido:
178

O nó 80 representa o evento de encerramento do projeto e

terá também uma marcação de data mais cedo, que nesse caso
representa o dia da entrega do projeto. Por ser esse o dia final,
então a “data mais tarde” coincide com a “data mais cedo”, ou
seja,
dc80 = dt80 = dia da entrega do projeto.
Definida a data final do projeto, você terá então preenchido

completamente o último nó, e poderá fazer o caminho inverso
do diagrama preenchendo agora a “data mais tarde” de início de
cada atividade. Faça isso e tire as conclusões. Inicialmente você
deve preencher o último nó (ver figura 4.30).
Figura 4.30 – Diagrama projeto “Churrasqueira”, detalhamento 5 – início do caminho

inverso de preenchimento.
A data mais tarde do nó 70, dt70 , será encontrada subtraindo-se a

duração da atividade M, da seguinte forma:
dt70 = dt80 – duraçãoM
Com isso você obterá dt70 = 48, o que coincide com a data mais
cedo desse mesmo nó. Veja a figura 4.31, a seguir.
Unidade 4 179

Figura 4.31 – Diagrama projeto “Churrasqueira”, detalhamento 6 – preenchimento das

“datas mais tarde” de início de cada atividade.
Adote o mesmo procedimento para os nós 40 e 60. Para o nó

60 perceba que novamente as datas “mais cedo” e “mais tarde”
coincidem, porém para o nó 40 há uma diferença entre elas. Veja
a figura 4.32.
A diferença entre datas que se vê no nó 40 é a folga livre (FL).

A atividade L pode começar 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 início dentro dessa
margem de folga.
180

O nó 50 está ligado ao 60 por uma atividade fantasma, que não

tem duração. Assim a sua dt50 será igual à dt70 , ou seja, 45. E
o nó 30, como ficará? Há três nós na sua seqüência: 40, 50 e 60.
Veja as três expressões possíveis e seus resultados:
dt30 = dt60 – duraçãoF = 45 – 13 = 32

dt30 = dt50 – duraçãoHJ = 45 – 2 = 43
dt30 = dt40 – duraçãoG = 43 – 5 = 38
- Certamente devemos escolher o menor, pois senão afetaríamos todos os

prazos do projeto, certo?
Nossa intenção na gestão do projeto é desenvolver o trabalho no

menor prazo possível, cumprindo ou antecipando o prazo final.
Com isso obtemos o seguinte diagrama:
Para definir o nó 20 novamente você deverá fazer uma escolha

entre duas opções: iniciar o cálculo a artir de dt30 ou de dt40 .
Com dt30 obtemos para o nó 20 a data “25” (dt 20 = 25), que é a
menor e que será então adotada.
Assim, preenchendo também o nó 10, você chegará ao diagrama

PERT/CPM final do projeto “Churrasqueira”, apresentado
na figura 4.34. Sem dúvida, não é um diagrama fácil de ser
entendido à primeira vista, e para ser útil é preciso ter ao lado a
Unidade 4 181

tabela de referência das atividades. Porém, ao analisar o desenho

com maior cuidado, você verá como é poderosa essa ferramenta
para tratar a questão 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 final do projeto “Churrasqueira”.
Você pode verificar que no diagrama o caminho de atividades

onde não há folga define o “caminho crítico” das atividades do
projeto. Sobre esse conjunto de atividades o gestor deve prestar
atenção especial e preparar suas estimativas de recursos e custos.
É possível desenhar o diagrama PERT/CPM sem ter

montado o Gráfico de Gantt?
Sim, mas é importante perceber que os diagramas são diferentes

e complementares para o gestor.
Enquanto no Gráfico de Gantt é possível ver a escala temporal

claramente, bem como a pessoa responsável por cada atividade e
também acompanhar o andamento do projeto ao longo do tempo
(preenchendo uma barra das tarefas “executadas”), no diagrama
PERT/CPM é possível determinar a seqüência de atividades com
suas precedências, 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.
182

Para criar diretamente um diagrama PERT/CPM, é necessário

partir da tabela de divisão de tarefas, conforme visto no exemplo
da figura 4.7. No entanto, aquela tabela apresenta apenas a
divisão das tarefas, e será então necessário incluir duas colunas:
uma para anotar o tempo estimado de realização da tarefa, e
outra para anotar quais as tarefas precedentes obrigatórias.
Faça esse exercício considerando a tabela que você utilizou no

exemplo do Projeto Churrasqueira. Na figura 4.35 reapresento
a tabela de distribuição 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 são desenhadas quando uma
atividade tem mais de uma precedência, e neste caso diferentes
nós de origem. Ao final do desenho são feitas as simplificações.
Seguindo esse roteiro você chegará ao diagrama da figura 4.34.
ETAPA Projeto CHURRASQUEIRA Tempo estimado da Precedência

etapa (dias)
A Preparação do terreno 2 -
B Fundações 7 A
C Alvenaria – paredes 15 B
D Alvenaria – reboco e cerâmicas 13 C
E Telhado 7 C
F Piso 13 E
G Carpintaria 5 E
H Tubulação Hidráulica 2 C, E
I Instalação Hidráulica 3 H, F
J Tubulação Elétrica 2 C, E
K Instalação Elétrica 3 J, F
L Pintura Externa 5 G
M Pintura Interna e acabamento 7 I, K, L
Figura 4.35 – Divisão de tarefas, com prazos e precedências, do projeto “Churrasqueira”.
Unidade 4 183

Um dos maiores problemas na montagem desse tipo de tabela

será na definição dos prazos de cada etapa. A estimativa de
tempo deve ser feita, quando possível, com a ajuda dos membros
da equipe. O tempo estimado é algo subjetivo, pois se considera a
experiência de cada um. Nesse sentido, há as previsões otimistas,
as pessimistas e as prováveis. A bibliografia (Keeling, 2002)
propõe definir um tempo provável com a seguinte fórmula para
cálculo do “Tempo Estimado” de uma determinada tarefa:
te = ( to + 4tm + tp ) / 6
Onde:
te – tempo estimado da tarefa;

to – tempo otimista, ou seja, duração prevista mais curta;
tm – tempo provável, ou seja, duração média prevista;
tp – tempo pessimista, ou seja, duração prevista mais
longa.
Ainda assim, há os que consideram o Tempo Estimado nesta

fórmula muito “otimista”, podendo-se então 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 seção anterior você viu que para o projeto ser iniciado era
preciso analisar sua viabilidade quanto aos recursos, custos,
prazo e benefícios. Tendo o planejamento realizado e os
prazos estimados, é preciso agora estimar os recursos e custos
necessários ao projeto.
184

SEÇÃO 4 – Estimativa de recursos

Tendo um planejamento do projeto, você pode agora estimar os
recursos necessários para ele. Bem, estimar não é uma ciência exata.
DeMarco (1991) propõe algumas definições diferentes, tais como:
Estimativa é a previsão mais otimista que não tem

uma probabilidade zero de tornar-se realidade.
Ou
Uma estimativa é uma previsão que tanto pode estar
acima quanto abaixo do resultado real.
Essas definições 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 possível para evitar riscos durante o projeto.
Quanto aos recursos necessários a um projeto, basicamente há os

seguintes:
Materiais – são os produtos necessários

para confeccionar o projeto, tais como
matérias-primas, produtos manufaturados,
componentes, hardware etc.
Equipamentos – são as máquinas e
ferramentas necessárias para poder trabalhar
as matérias-primas, escrever o código de um
software, facilitar uma construção, etc.
Pessoal – os recursos humanos aparecem como o principal
requisito em projetos, especialmente em projetos de
tecnologia; a próxima unidade discutirá este item.
Financeiros – são os custos do projeto, que advêm dos
gastos relativos a materiais, equipamentos, locações,
fretes, transportes, pessoal, licenças, direitos autorais, etc
(a estimativa de custos é o assunto da próxima seção).
Unidade 4 185

Como você estudou na seção anterior, o planejamento do

projeto tem um foco muito intenso no prazo geral, pois como
projetos são trabalhos com data marcada para acabar, o prazo é
determinante.
Para realizar o planejamento foi feita uma divisão de tarefas, e

essa divisão é 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 específicas para descrever recursos
necessários.
A tabela apresentada na figura abaixo é um exemplo

de relatório a ser preenchido no início do projeto.
Este exemplo partiu de tabela anterior, descrita na
figura 4.10. Para cada projeto específico deverá ser
construída uma tabela exclusiva, sendo que a coluna
dos recursos definirá uma lista de necessidades.
Projeto CHURRASQUEIRA Recursos necessários
Etapa 1 – Preparação do terreno
• Limpeza do terreno Tratores (dois dias)
• Medições e marcações Topógrafo
• Escavações Tratores (um dia)
Etapa 2 – Fundações
XX dúzias de madeira para caixaria;
• Montagem das madeiras de caixaria
Pessoal para montagem da caixaria;
• Montagem das ferragens da fundação XX barras de ferro;
• Concretagem XX caminhões de concreto

Etapa 3 – Alvenaria
XX milheiros de tijolos;
• Construção das paredes Xx sacos de cimento;
Etc.
• ........ ...........
Figura 4.36 – Divisão de tarefas com estimativa de recursos.
186

SEÇÃO 5 – Estimativa de custos

A distribuição de custos do projeto é feita num gráfico chamado
de “cronograma físico-financeiro”.
Este deve aproveitar o gráfico de barras que você viu no Gráfico

de Gantt, sendo que os custos do projeto podem ser distribuídos
ao longo do tempo de duração do projeto. Para cada item,
definido nos recursos estimados para o desenvolvimento do
projeto, você deverá fazer uma estimativa de gastos.
O uso do gráfico de barras é interessante, nesse caso, devido à

clareza visual de apresentação.
- Veja um exemplo para entender melhor esse tipo de cronograma.
A figura 4.37 apresenta o Gráfico de Gantt de um projeto

hipotético com sete atividades – Tarefas A até G – cujos
trabalhos transcorrem em 16 semanas, aproximadamente quatro
meses. Tendo estimados os recursos necessários para desenvolver
cada tarefa, os custos podem ser distribuídos por tarefa e por
unidade de tempo, neste caso por semana. Sobre o próprio
gráfico os valores são anotados, semanalmente.
Figura 4.37 – Estimando custos – cronograma físico-financeiro.
Fazendo a estimativa de custos por atividade e por unidade de

tempo é possível chegar a valores mais próximos do real. Quanto
maior a divisão das tarefas, melhor. Anotados todos os valores
você fará a somatória, também por unidade de tempo. A cada
semana você chega a um valor total, conforme vemos na última
linha do gráfico. Com tais valores é possível estimar o valor
Unidade 4 187

total de custos do projeto, apresentado no canto inferior direito

da figura. Outra visualização dos custos desse mesmo projeto é
apresentada na figura 4.38, a qual decorre dos valores obtidos na
estimativa do gráfico de barras.
Figura 4.38 – Gráfico de linha do cronograma físico-financeiro.
Percebemos pelo gráfico da figura 4.38 que o projeto deverá

dispor de recursos financeiros bem maiores do que a média
nas semanas 6 e 7. Fazendo essa análise pode-se retornar ao
planejamento do projeto e, caso necessário, alterar a duração das
tarefas que impactam nesses valores, nesse caso especialmente
a Tarefa C. Se não for possível alterar, então o caixa do projeto
deverá estar preparado para tal fluxo.
188

Síntese
Nesta unidade foram apresentados modelos e métodos muito

importantes para o gestor de projetos e de suas equipes. Em
primeiro lugar foi feita uma avaliação de como o fluxo de
atividades pode ser distribuído em um projeto, de acordo com
o tipo de projeto e de suas necessidades específicas. Projetos
de tecnologias mais tradicionais, ou com contratos de âmbito
conservador, levam a modelos de desenvolvimento com uma
cadência diferente, por exemplo, daqueles projetos onde o tempo
de chegada ao mercado é fator decisivo de sucesso, ou onde as
tecnologias não são dominadas e precisamos fazer revisões e
retornos constantes a etapas anteriores.
Depois você viu as técnicas de planejamento que foram

desenvolvidas nos últimos cem anos, que basicamente é o
período onde a disciplina de gestão de projetos tomou forma.
O gráfico que apresenta as diversas atividades em forma
de barras ao longo do tempo foi desenvolvido por Gantt e
ficou 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 Gráfico de Gantt deve-se à força de sua clareza
visual para representar o projeto e, recentemente, a implantação
de setas de precedência interligando as barras, aumentou ainda
mais a sua qualidade como modelo. Esse gráfico também
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
representação dos custos dos projetos discretizados por tarefa e
por unidade de tempo adotada, facilitando em muito a estimativa
de custos gerais do projeto.
Unidade 4 189

Apesar de a imensa utilidade do Gráfico de Gantt, outro

método foi desenvolvido para facilitar o planejamento do
tempo de duração do projeto – trata-se do método do caminho
crítico, denominado genericamente de PERT/CPM. Esse
gráfico permite distinguir num projeto qual a seqüência crítica
de atividades, de tal forma que o gestor pode prestar atenção
específica 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 análise pode-se, então,

chegar a estimativas bastante realistas quanto aos recursos
necessários ao projeto, e quais seus custos.
Na próxima unidade você vai conhecer aquele que provavelmente

é o ponto crítico dos projetos de desenvolvimento tecnológico:
recursos humanos e estruturação de equipes.
190

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 implantação, o qual não deve superar dois meses,
e que deve ser primeiro implantado no setor administrativo e somente
depois no setor de produção da empresa. O projeto tem as seguintes
atividades: reuniões do grupo do projeto para definir o programa;
redação do programa de qualidade; treinamento do pessoal do
setor administrativo; treinamento do pessoal do setor de produção;
implantação do programa de qualidade no setor Administrativo;
implantação do programa no setor de produção; avaliação dos
resultados e conclusão, com entrega dos relatórios à direção. Faça sua
análise e, com base nela, preencha o quadro a seguir:
Prazos estimados pela

Projeto Qualidade
equipe de implantação
A-
B-
C-
D-
E-
F-
G-
2) Prepare o Gráfico de Gantt para a planilha de atividades do exercício

anterior – Projeto QUALIDADE, e considere ainda que os treinamentos
podem ser feitos em seqüência, independente do início do trabalho de
implantação no setor de produção.
(quadro na página 188)
3) Baseado no Gráfico de Gantt que você criou no Projeto Qualidade,

reproduza-o e faça logo abaixo dele o diagrama de setas com escala.
(quadro na página 189)
Unidade 4 191

26 / out
SD
25 / out
24 / out
23 / out
22 / out
21 / out
20 / out
19 / out
SD
18 / out
17 / out
16 / out
15 / out
14 / out
13 / out
12 / out
SD
11 / out
10 / out
09 / out
08 / out
07 / out
06 / out
05 / out
SD
04 / out
03 / out
02 / out
01 / out
30 / set
29 / set
28 / set
SD
27 / set
26 / set
25 / set
24 / set
23 / set
22 / set
21 / set
SD
20 / set
19 / set
18 / set
17 / set
16 / set
15 / set
14 / set
SD
13 / set
12 / set
11 / set
10 / set
09 / set
08 / set
07 / set
SD
06 / set
Projeto Qualidade
05 / set
04 / set
03 / set
02 / set
01 / set
D
G
B
A
192

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

4) Modifique o diagrama de setas do exercício 3, simplifique-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).
194

Unidade 4 195

5) No exercício anterior, onde há uma Folga Livre (FL)? O que isso significa
para o gestor do projeto QUALIDADE?
196

Saiba mais
Na seção 1 desta unidade você estudou modelos de representação

como forma de entender um projeto, a partir de uma visão geral.
Para o desenvolvimento de software surgiu uma tecnologia que
busca criar modelos de representação, por meio de diagramas,
que muito se assemelham aos diagramas genéricos que usamos
aqui. Essa tecnologia é chamada “UML – Unified Modelling
Language”, e está baseada na modelagem de diversos tipos
de diagramas, os quais abrangem diferentes visões 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 organização
internacional sem fins lucrativos, e toda sua documentação
pode ser encontrada em www.uml.org. Vários softwares para
desenvolvimento UML estão disponíveis hoje para download
gratuito, como por exemplo o POSEIDON (veja em http://
www.gentleware.com/index.php). Veja também o sítio http://
www.cragsystems.co.uk/ITMUML/index.htm para estudar
uma introdução à 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 práticos e
exercícios, bem como exemplos de tabelas e relatórios.
As idéias da Microsoft para gestão de projetos de software estão

disponíveis no endereço http://www.microsoft.com/technet/
itsolutions/msf/default.mspx. Análises de risco, estimativas,
grupos de trabalhos e diversos outros conceitos são discutidos no
que eles chamaram “Microsoft Solutions Framework – MSF”.
Unidade 4 197

5
UNIDADE 5
Estruturando a equipe
Compreender aspectos da formação e estruturação de
equipes, conforme cada tipo de projeto discutido nas
unidades anteriores.
Perceber como contornar os problemas de

estruturação de uma equipe.
Reconhecer os diversos modelos de estruturação de

equipes em diferentes organizações.
Compreender as dificuldades que um gestor pode

trazer ao trabalho com projetos quando não se ajusta a
um perfil de liderança criativa.
Compreender que, em projetos, as equipes precisam

trabalhar com objetivos definidos de cooperação e de
participação proativa.
Seções de estudo
Seção 1 Estruturando a equipe.
Seção 2 Recursos humanos e perfis.
Seção 3 Treinamento.
Seção 4 Responsabilidade e divisão de tarefas.
Seção 5 Terceirização.


Você verá que esta unidade contém muito mais opiniões pessoais
do que “técnicas e dicas infalíveis”. São opiniões baseadas
em anos de atuação em diferentes projetos, seja com equipes
trabalhando dentro do escritório ou em trabalhos de campo,
seja com pequenas empresas ou em grandes corporações, e com
modelos de estrutura hierárquica os mais diversos possíveis.
No entanto, não são somente opiniões, mas também algumas
técnicas e métodos são apresentados aqui.
De início, você verá um modelo de formação de equipes e

como se dão os problemas no começo dos relacionamentos,
especialmente quando a equipe tem várias pessoas de origens
diversas. Esses problemas acontecem devido aos diferentes perfis
humanos, ou seja, às diferentes características de comportamento
e atitude, muito mais do que diferenças de conhecimento técnico.
As questões técnicas, muitas vezes, podem ser resolvidas por

meio de treinamentos específicos e dirigidos. Não é o caso
quando temos grandes diferenças comportamentais. Nesses casos,
precisamos ter líderes à frente das equipes, pois o que interessa
em projetos é ter ambientes de grande cooperação e o interesse
sincero (e ousado!) pelo sucesso. Falaremos um pouco sobre
liderança, mas deixaremos o principal para a próxima unidade.
Nesta unidade você estudará apenas algumas alegorias (que

espero que sejam divertidas, e esclarecedoras também!).
Você verá também cinco diferentes modelos de estruturação

de equipes, que são 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 são muito úteis e nos ajudam a estruturar o grupo de
pessoas e comunicar as funções e interfaces de trabalho.
200

Treinamento e terceirização são os outros dois tópicos tratados

aqui, sendo que o processo de terceirização assumiu, nos últimos
tempos, um caráter estratégico para as empresas e especialmente
para os países dominantes, o que tem trazido muita discussão
para a arena econômica e política, e isto está ligado diretamente
ao nosso objeto de estudo.
Bom estudo a todos!
SEÇÃO 1 – Estruturando a equipe

Considere um campeonato de futebol como um
projeto: cada time traça seus objetivos, contrata
jogadores, treinador, busca recursos e tem datas
definidas para chegar aos resultados.
Há inúmeros riscos, pois é uma competição com

muitas variáveis. Sabemos que uma questão muito
importante, sempre discutida pelos comentaristas
e que também é a conversa do início de cada
semana após uma rodada emocionante, trata da formação e do
entrosamento dos jogadores dentro de campo.
Cada jogador tem sua função, sabemos mais ou menos sobre suas
qualidades e alguns são reconhecidos por sua competência. No
entanto em cada partida há um comportamento diferente, há
um jeito diferente de jogo, e simultaneamente encantamentos e
decepções.
Certamente os projetos de pesquisa, de engenharia, de software,

não são assim tão famosos nem tão visíveis, mas muitas vezes são
bastante emocionantes. E vão depender de quanto há de sensação
de “time” na equipe.
Constituir uma equipe é relativamente fácil, constituir

um time, não tanto.
Unidade 5 201

A equipe é constituída a partir da definição de funções, então

é possível determinar as características necessárias de um
indivíduo para que preencha tal função. Grandes companhias
preparam uma lista de requisitos mínimos para que se procurem
funcionários para determinada vaga.
Em algumas equipes há pessoas trabalhando no recrutamento

que atuam como máquinas de verificação: olham currículos e
buscam aquelas que preenchem tais requisitos, depois fazem as
entrevistas e as análises de perfil (psicólogos trabalham nisso) e,
por fim, alguém é contratado e passa a integrar a equipe.
Essas companhias enxergam o trabalho como atividade rotineira

e, muitas vezes, máquinas e pessoas não fazem grande diferença.
A pessoa nesse caso é um agente Atividades rotineiras suportam equipes assim, mas penso que
que toma decisões e tem liberdade projetos não.
de ação, ao contrário da máquina.
Projetos, assim como campeonatos, exigem pessoas que
trabalhem em cooperação e que gostem, realmente, de chegar aos
resultados com sucesso. Em uma equipe convencional, de rotina,
cada um faz a sua função (não precisaria ser assim!). Em um
projeto os membros da equipe trabalham para ajudar os outros,
fazendo a sua função e colaborando para que os outros realizem
as suas.
O primeiro conceito importante na formação de

uma equipe é a cooperação. O segundo conceito
importante é o objetivo comum.
Os membros da equipe devem trabalhar em regime de

cooperação em busca de um objetivo comum. Isto já estava claro
desde o começo de nosso estudo, pois você viu que uma das
chaves de sucesso do projeto é a visão clara sobre o resultado
esperado.
Formar uma equipe que trabalhe com objetivo comum e de forma

cooperativa é um verdadeiro desafio (basta ver que muitas vezes
os times com os melhores jogadores não ganham o campeonato
– algo ficou faltando!). Isso quer dizer que não basta analisar
as competências pelo currículo. É necessário que além da
competência a pessoa que vai fazer parte da equipe de projeto
tenha a cultura da colaboração. Isso não pode ser detectado sem a
convivência. E gerentes de projetos que não sejam líderes, muitas
202

vezes não conseguirão sacar essa característica. Essa percepção

exige experiência e intuição. Aqui estamos saindo do campo
das ciências exatas e entrando no campo pantanoso das relações
humanas (nada exatas...).
Na estruturação da equipe de um projeto, conforme

Valeriano (1998), há quatro momentos distintos:
Formação. Quando se reúnem os membros do projeto
e as funções são distribuídas, ainda não há clareza das
atividades a serem realizadas As pessoas não se conhecem e
o tratamento é formal. Por não haver conhecimento há um
ambiente de confusão inicial.
Turbulência. A partir do início das atividades começam a se
formar subgrupos a partir de afinidades pessoais, e muitas
vezes principiam atritos, especialmente em equipes grandes
com pessoas de variados tipos. A turbulência é comum em
projetos, especialmente quando os riscos são grandes e
iminentes.
Normalização. Se os períodos de turbulência são resolvidos
pela liderança, 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 período a equipe entra em equilíbrio
criativo e cooperativo, e o projeto tem alto rendimento. Os
membros sentem-se parte do time de trabalho, reconhecem
a liderança e os companheiros como importantes em seu
próprio papel.
Essas quatro fases de estruturação podem acontecer ou não,

sendo que muitos projetos chegam a crescer até a normalização
apenas, sem atingir o ambiente propício do “desempenho”.
Sustentar a fase do desempenho é, além de tudo, uma tarefa
difícil que exige esforço contínuo. Veja na figura a seguir o
diagrama esquemático dessa estrutura.
Unidade 5 203

Fase 1 Reunião inicial, formalidade, confusão sobre

FORMAÇÃO as funções, atividades indefinidas.
Fase 2 Formação de subgrupos (panelinhas),

TURBULÊNCIA atritos, início da acomodação.
Fase 3 As funções estão definidas, os grupos se ajustam,

NORMALIZAÇÃO a liderança se impõe e normas são claras.
Fase 4 Espírito de colaboração, cooperação

DESEMPENHO criativa, alto rendimento.
Figura 5.1 – Representação esquemática das fases de estruturação da equipe de projeto.
SEÇÃO 2 – Recursos humanos e perfis

Como você viu na seção anterior, a escolha de perfis humanos
para trabalhar em uma equipe de projeto está fora da escolha de
características exatas, características pré-definidas e nas quais
algumas pessoas “especiais” se encaixariam. Esse é o campo das
relações humanas, relações sempre sutis, delicadas, que variam
infinitamente.
Os membros da equipe acabam por se moldar

às características do gestor. Se o gestor for
um líder, poderá conduzir sua equipe para a
fase do “desempenho”. Se não, provavelmente
permanecerão na fase da “normalização”.
Portanto será importante discutirmos os perfis
dos gestores, sejam líderes ou não. Mas antes
de falar dos gestores/líderes, vamos tentar
descrever alguns perfis típicos das pessoas que
virão a fazer parte de nossas equipes de projeto.
204

Keeling (2002) apresenta diversos tipos de perfis citando outros

autores como Margerison e McCann, que comentam sobre oito
diferentes papéis, Belbin, que classifica nove grupos descritivos,
ou Parker, com apenas quatro papéis. Os quatro papéis de Parker,
citados por Keeling (2002) são:
Contribuidor. Aquele que

contribui com atividades
e resultados, mas não é
participativo.
Colaborador. O que participa
do desenvolvimento em
Desafiador. O que sempre
conjunto.
apresenta as questões e
Comunicador. Capaz de participa dos trabalhos num
comunicar as atividades e de espírito de desafio (o que pode
integrar grupos por meio da ser bom ou ruim, depende da
comunicação. situação e do caso).
Essas tentativas de classificação muitas vezes caem no vazio,

tal é o número de possibilidades e de percepções. Muito
provavelmente não é possível ser “científico” nesse caso,
e a classificação será local e temporal, ou seja, dependerá
do ambiente, da situação e das condições culturais de um
determinado grupo.
Pela dificuldade do tratamento “científico” (se é que isso é

necessário), posso fazer uma brincadeira e descrever alguns perfis
que já participaram de projetos junto comigo, e que no decorrer
das experiências foram se formando como tipos, facilmente
reconhecíveis. Veja alguns:
Unidade 5 205

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 disposição 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, ficam faltando os outros 90%”. O problema da entrega
é um dos mais importantes em projeto, pois chama a atenção sobre
o fato dos projetos em geral não serem entregues no prazo, e isso
decorre da dificuldade em ver, claramente, o fim de cada etapa.
O que finge ser especialista. O ditado popular diz que

“especialista é aquele que sabe quase tudo sobre quase nada”.
Como geralmente as pessoas normais não conhecem tudo sobre
tudo, muitas vezes alguém que domina meia dúzia de belas frases
técnicas e alguns acrônimos da moda, passa por especialista. Na
informática isso é muito comum, e tenho visto em conferências
por aí aqueles profissionais que aparentam grande conhecimento
e que não resistem a mais do que duas perguntas; para nossos
projetos, vamos nos cuidar com esse tipo.
O que é especialista, mas não se entende com os outros. Vale

a mesma máxima de especialista do item anterior, porém 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 dificuldade
de relacionamento. Se projetos são trabalhos de cooperação, sua
especialidade perde o valor automaticamente; melhor alguém que
sabe “um pouco” sobre o “quase nada”, e que possa cooperar com
aqueles que estão à sua volta.
O que “puxa-saco”. Não é preciso pensar muito para lembrar

de pessoas com esse perfil, pois não há grupo que não tenha
esse membro (infelizmente); concorda sempre com o superior
hierárquico, e inconscientemente se move para ficar à sua sombra
(e com as suas sobras); caso haja um atrito, vai se colocar do lado
do que tem mais força, e não consegue agir com opinião própria;
deve ser eliminado da equipe sempre que for descoberto.
O que suga energia. Em uma equipe de alto desempenho

buscamos cooperação e boa vontade, e quando há divergências
206

elas são tratadas como geradoras de novas soluções.

Contudo há o perfil de pessoa que funciona como um
“buraco negro”, sugando idéias e a energia do resto dos
membros de equipe; é difícil perceber essa ação, e muitas
vezes só fica evidente depois de muito tempo, e muito
estrago.
O que não comunica. Comunicação é fator crítico de

sucesso em projetos, mas a dificuldade de comunicar com
clareza e objetividade é algo muito comum; não estamos
livres desse problema, e temos que ficar atentos em nós
mesmos e em nossas ações; 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 característica
do detalhista operacional: não 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 dificuldade
de integração, a dificuldade de melhorar, a dificuldade de
achar erros etc.
O que é generalista estratégico. Perfil diametralmente

oposto ao anterior, sempre está olhando o projeto, e
qualquer atividade, de um ponto de vista muito genérico;
tem dificuldade para “colocar a mão na massa”, pois sempre
tem uma visão nova, geral, para colocar, e não percebe
o momento de partir da superfície para o fundo, ou seja,
consegue navegar mas não mergulhar.
Esta lista pode se estender por páginas e páginas. Deixarei para

você imaginar alguns outros perfis problemáticos.
Analisando perfis problemáticos, você consegue

avaliar quem manter e quem evitar em sua equipe de
trabalho? Reflita sobre isso!
Unidade 5 207

Por outro lado temos a figura do gestor, e variados perfis também

têm sido escritos sobre ele. As publicações sobre gestão e estudos
de gerenciamento discorrem sobre técnicas e métodos de gestão,
mas ultimamente há ênfase sobre as características da liderança
acopladas à atividade gestora.
Conheci um sujeito que não gostava da palavra “líder”, pois

associava essa imagem com a figura do carisma, a alguém cheio
de seguidores fanáticos. Esse sujeito certamente não era um líder
de projetos, nem de empresas (de fato não era, pois fugia das
situações críticas, amedrontado).
Se, nos parágrafos anteriores, discorremos sobre variados perfis

de membros de equipes de projeto, cabe também apresentar
alguns perfis de gestores.
Na próxima unidade, as funções dos líderes e suas

relações com os membros da equipe, durante a
execução do projeto, serão discutidas em maior
profundidade. Aqui vamos ficar apenas com algumas
notas sobre perfis de gestores, na forma de caricaturas
(ou seja: como não ser um gestor!).
A brincadeira é a seguinte: sem ofender o mundo animal vamos

descrever três modelos diferentes de gestores comparando-os
com o comportamento de animais. Obviamente esses animais
não se comportam exatamente assim mas, como metáfora, podem
ser úteis e você perceberá que há muitas pessoas agi ndo assim
(não só em filmes!). Bem, eu já conheci. Vamos a eles:
208

Gestor-rinoceronte. Quando você vir aquele gerente

andando em passos largos e falando alto na direção de um
funcionário da equipe, o tom ameaçador já denunciará
a performance de rinoceronte; ele não precisa ser gordo
nem grande, basta esse comportamento de quem quer
resultado pelo aspecto ameaçador. A cara é de tonto e o
seu conteúdo de conhecimento é quase nulo, mas não se
pode duvidar que se esbarrar com ele, trará conseqüências
físicas (mas não intelectuais, pois seu estilo não é esse). Esse
é o famoso “gerentão”, que pensa em obter resultados de
sua equipe de projeto chamando a todos todo o tempo
para cobrar algum resultado, resultado que ele mesmo não
tem certeza qual seria, devido à sua falta de domínio. Esse
tipo é introjetado no cargo por algum outro superior (talvez
um gerente-raposa), e sua equipe se divide entre os que
têm medo e os que querem distância.
Como evitar ser um gestor-rinoceronte? Respeitando os
membros da equipe, ouvindo com educação, estudando
o projeto, respeitando as dificuldades, assumindo os riscos
em parceria, participando como um colaborador e não
como um cobrador truculento.
Gestor-cobra. Diferente do rinoceronte, esse tipo de

gestor evita confrontos e prefere agir sorrateiramente. Você
não está vendo, mas sabe que ele está observando suas
ações de longe, pronto para atacar se qualquer coisa sair
errada. Em sua frente ele está quieto, muitas vezes com
aquela educação disfarçada e o esforço para parecer no
controle. Se alguma apresentação pública do projeto for
necessária ele designará um membro da equipe, pois ele
mesmo não vai se expor. Compartilha com o rinoceronte o
desconhecimento dos detalhes do projeto, mas como fala
pouco não é possível determinar até onde conhece ou não
conhece. Ética para ele é uma palavra de dicionário, não
um comportamento. Com esse tipo de gestor o grupo de
projeto acaba se conformando a entregar apenas o mínimo
necessário, e aqueles que ousam destoar são aniquilados
sorrateiramente.
Como evitar ser um gestor-cobra? Admitindo as
diferentes visões da equipe, expondo-se, sendo claro,
agindo com ética nos relacionamentos, não destilando o
veneno da negatividade entre pessoas que esperam criação
e liberdade.
SEGUE
Unidade 5 209

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 não está vendo, o
tipo “raposa” é muito mais sutil e muitas vezes engana inúmeras
pessoas com seu ar de sabedoria. Por isso chamamos determinado
político de “raposa”: ele é esperto e ágil, e sempre quer se dar bem
pelas articulações que faz (em proveito próprio, certamente). Esse
tipo de gestor não se importa com os membros da equipe, e afaga
suas cabeças enquanto esses lhe servem. No entanto no dia que
algo ameaça sua posição, busca uma maneira sutil de desviar o
inconveniente. Não há projeto criativo que ande bem com esse
tipo de gestor, pois não admite as diferenças. O que o distingue
do tipo “cobra” é que não articula um ataque às escondidas, e de
fato estuda e conhece muitas coisas. Seu problema é o medo e a
dificuldade de relacionamento, pois se comporta de forma arredia,
distante e fria. Uma boa idéia dentro da equipe para ele é uma
ameaça, pois aquele membro poderia ser superior a ele. Se tiver
um rinoceronte e uma cobra a seu serviço, eles farão o serviço sujo
por ele.
Como evitar ser um gestor-raposa? Fazendo um exercício por
admitir as diferenças, 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, não é? Mas a realidade tem mostrado que
a maioria dos gestores, infelizmente, acaba se adequando a um
desses papéis, ou híbridos deles.
Por fim, na definição de perfis 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 desejáveis e de funções necessárias em um projeto.
Digamos que se tenha um grupo de pessoas na empresa que
possa vir a participar do projeto, e precisamos definir suas
posições. Ao mesmo tempo sabe-se as competências técnicas
necessárias, e comportamentais também, para trabalhar nele.
Criar e preencher uma matriz, como a do exemplo da figura 5.2,

ajuda a perceber os perfis e como distribuir os papéis. Olhando
para a matriz temos a tendência a eleger o “profissional F”
como líder da equipe, pois tem experiência e dispõe de tempo,
enquanto o “profissional D” é novo na empresa, e isso pode
210

gerar algum desconforto. Em domínio técnico vemos que os

profissionais B e E são capacitados, mas não dispõem de tempo
livre (podem estar engajados em outros projetos), e a alternativa
será discutir com eles as possibilidades de rearranjo de trabalhos.
Perfil e necessidades Conhecer Conhecer Conhecer Dominar Exp. de Exp. de Disp. de Novo na
tecnologia tecnologia tecnologia uso de trabalho trabalho tempo empresa
Membro da equipe “1” “2” “3” “X” em equipe em equipe
Profissional A X X X
Profissional B X X X X
Profissional C X X
Profissional D X X X X
Profissional E X X X X
Profissional F X X X
Figura 5.2 – Matriz de perfis e competências profissionais.
SEÇÃO 3 – Treinamento
A educação é anterior ao treinamento. Para que haja algum
treinamento é necessário que os membros da equipe tenham uma
educação prévia e apropriada.
A formação do conhecimento e a aprendizagem

passam pela análise crítica e pela reflexão, próprias
do ser humano, enquanto que o treinamento para
atividades rotineiras pode ser feito até mesmo com
animais.
No início da revolução industrial

foi necessária mão-de-obra treinada
para operar máquinas, e tal operação
passava por uma repetição contínua
de procedimentos. Muitas críticas
foram dirigidas a tais atividades, que
de alguma forma se repetem até hoje,
especialmente nos países em processo
de industrialização.
Unidade 5 211

Esse ambiente de início de industrialização teve espaço no Brasil

mais ou menos no meio do século passado, quando grandes
Nessa época foi criado o Senai, até indústrias de base foram criadas.
hoje responsável por treinamento
de mão-de-obra para esse tipo de Nosso país, de certa maneira, não evoluiu muito desse ambiente
indústria. de indústrias básicas, processadoras de matéria-prima, e
facilmente se percebe isto vendo a importância econômica que
tais empresas têm entre as “500 maiores”. Indústrias da era da
informação (que exigem mais educação do que treinamento)
ainda são incipientes, ao contrário do que acontece na Europa ou
América do Norte.
Considerando que estamos aqui estudando projetos

de desenvolvimento e inovação, o treinamento cabe
como complemento e ajuste para a equipe.
Veja o exemplo de matriz da figura 5.2. Precisamos de algumas

competências específicas de tecnologias para o desenvolvimento
do projeto, alguns treinamentos serão necessários para
uniformizar os conhecimentos dos membros da equipe. Isso
deve estar no foco da gerência do projeto, para evitar que o
desconhecimento técnico seja empecilho ou fator de risco. Mas
se o projeto for de longo prazo, é melhor criar alternativas de
educação em grupo do que meros treinamentos de curta duração,
cuja função é atender objetivos bem definidos e de alcance
imediato.
Ainda na matriz da figura 5.2, se observa que há perfis desejáveis

e que, aparentemente, não são preenchidas pelos seus membros
(como liderança, por exemplo). Ultimamente têm tido ênfase os
treinamentos para líderes, e tenho visto nas empresas o interesse
(superficial em muitos casos) de oportunizar o surgimento de
lideranças.
Treinamentos são criados para esses casos, e gerentes são

envolvidos neles.
212

A liderança é, no entanto, mais uma questão de comportamento

e atitude do que de técnica. O incentivo a esse surgimento deve
passar por um ambiente que estimule a liberdade de expressão e
experimentação.
Treinamentos são feitos para tecnologias, não para

comportamentos.
SEÇÃO 4 – Responsabilidades e divisão de tarefas

Em um projeto as atividades são divididas ao máximo, como você
viu na composição de Diagramas de Gantt, unidade 4. A divisão
das atividades é feita para se ter clareza dos objetivos e para
perceber as entregas parciais. Também no Diagrama de Gantt
atribuímos tarefas para os membros da equipe e, assim, cada
um enxerga suas metas e seus prazos. Atividades diferentes para
pessoas diferentes.
A distribuição de responsabilidades será feita de acordo com

o modelo adotado pela gerência do projeto. Há gestores que
centralizam em excesso as decisões, e outros que delegam. O
equilíbrio dependerá bastante do seu perfil, assim como da
acomodação dos membros da equipe.
Segundo Page-Jones (1990), “prioridades são para gerentes, não

para funcionários”. Com isso ele quer afirmar a distribuição de
responsabilidades conforme o papel de cada um na equipe. Para
a gerência do negócio a meta é o resultado global e a satisfação
do cliente, enquanto para o desenvolvedor a meta é a entrega
conforme a especificação da sua tarefa. Este é o Modelo de
Equipe definido no framework da Microsoft (MSF, 1998) quando
define papéis em uma equipe. Assim, para cada um, uma tarefa
de cada vez.
Para definir os papéis e comunicá-los à equipe é importante

criar um organograma, definindo as funções e a hierarquia
dos membros. Há inúmeras possibilidades de estruturar tal
organograma, e isso dependerá da complexidade do projeto, da
Unidade 5 213

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 típicas de grupos de projetos:
1. Estruturas diferenciadas e exclusivas.
2. Estruturas híbridas.
3. Estruturas matriciais.
4. Estruturas modulares.
5. 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 próprio pessoal
e recursos exclusivos, e têm pequena complexidade, podem
montar estruturas organizacionais simples e funcionais. Esse
tipo de estrutura é direta em seus procedimentos e fácil de ser
compreendida pelos membros da equipe. Pequenas empresas
de engenharia da construção, por exemplo, trabalham desta
maneira, onde o gestor do projeto trabalha com um conjunto
de técnicos e pessoas de apoio administrativo, e ele reporta
diretamente ao cliente final. A figura 5.3 apresenta o diagrama
desse modelo, que é chamado de estrutura exclusiva porque os
membros do projeto são dedicados a um projeto apenas.
Cliente
/ proprietário do projeto
Gestor
/ líder do projeto
Apoio administrativo
Membro TÉCNICO 1 Membro TÉCNICO 2 Membro TÉCNICO 3
Figura 5.3 – Estrutura exclusiva.
214

Estruturas híbridas
Em projetos internos às empresas maiores, onde vários projetos
ocorrem ao mesmo tempo, as estruturas híbridas passam a
ocorrer com maior freqüência. Veja a figura 5.4, onde um
organograma típico desse modelo de estrutura é apresentado. O
gestor do projeto conta com membros dedicados exclusivamente
àquele trabalho, mas precisa paralelamente recorrer a outras
pessoas, que não estarão dedicadas a esse projeto, mas que são
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 não lhe é permitida, o que levará o projeto a atrasos e
dispersões.
Gerência geral
da empresa
Área Área Área

administrativa financeira Engenharia
comercial
Gestor
/ líder do projeto
Membro Membro
TÉCNICO 1 TÉCNICO n
Figura 5.4 – Estrutura híbrida.
Estruturas matriciais
Estruturas matriciais são bem mais complexas e exigem grande
maturidade de trabalho, tanto por parte da empresa quanto por
parte dos membros das diversas equipes. A figura 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 não dos projetos exclusivamente, ou seja, cada
funcionário está inserido em determinado setor da empresa e
Unidade 5 215

executa serviços que atendem ora a um projeto, ora a outro.

Alguém estará responsável pelo projeto, e será definido 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 dúvida a coordenação desse tipo de estrutura
é mais complexa, e exige alto grau de organização geral da
empresa, especialmente em relação aos planos de produção.
Gerência geral
da empresa
Área Área Área Área Área

administrativa Engenharia
financeira comercial técnica 1 técnica n
Projeto 1
Projeto 2
Projeto 3
Projeto n
Figura 5.5 – Estrutura matricial.
Estruturas modulares
Estruturas modulares ocorrem quando, dentro da empresa, há
grupos com relativa autonomia e determinada especialização, que
realizam determinado tipo de serviço. O gestor de determinado
projeto emprega esse grupo modular para desenvolver parte
do projeto, e vai distribuindo assim as atividades conforme
as especializações. Internamente o grupo (ou módulo de
desenvolvimento) tem autonomia para gerenciar aquela etapa,
sendo que o gestor geral do projeto percebe a entrada e a saída do
módulo, mas não propriamente o que acontece em seu interior.
Projetos de software, por exemplo, envolvendo grandes equipes
com diferentes conhecimentos, podem usar esse tipo de estrutura.
216

Gestor
/ líder do projeto
Grupo Grupo Grupo

TÉCNICO 1 TÉCNICO 2 TÉCNICO 3
:
Desenvolvimento Grupo DESIGN
HARDWARE TÉCNICO 4 gráfico
Figura 5.6 – Estrutura modular.
Estruturas horizontais
As estruturas horizontais geralmente são formadas por poucos
membros, onde há uma grande maturidade no trabalho em
conjunto. As relações se dão em rede, onde todas as pessoas se
relacionam com todas as outras. O líder do grupo tem a função
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 reúnem especialistas e, por esse motivo, o líder
geralmente é também um especialista técnico ou científico, de tal
forma que sua ascendência sobre o grupo seja inequívoca.
A figura 5.7 mostra exemplo de configuração de uma estrutura

horizontal. O modelo de desenvolvimento de aplicativos
da Microsoft (MSF, 1998) também se baseia nesse modelo
horizontal, definido por “pequena equipe de pares ou especialistas
trabalhando em papéis multidisciplinares e interdependentes”. A
questão da multidisciplinaridade, que surge aqui, tem especial
interesse em projetos de inovação tecnológica, como no caso
dos aplicativos. O ambiente proporcionado por uma estrutura
horizontal permite os diálogos constantes e a troca positiva de
idéias, nascedouro de soluções criativas.
Unidade 5 217

Cliente
/ contratante
/ diretoria
Gestor
/ líder do projeto
Especialista Especialista
TÉCNICO 1 TÉCNICO 2
Engenheiro Designer
SOFTWARE GRÁFICO
Especialista
TÉCNICO 3
Figura 5.7 – Estrutura horizontal de equipe de projeto.
SEÇÃO 5 – Terceirização
A palavra terceirização entrou na moda há uns dez ou vinte anos
atrás, e foi uma solução adotada na indústria para otimizar seus
modelos de produção. Basicamente consistia em contratar partes
da produção com empresas externas, ou terceiras, em vez de
produzir com equipes próprias.
Com isso era possível obter uma concentração de esforços,

dentro da empresa, em atividades e conhecimentos que lhe eram
próprias, não sendo necessário desenvolver competências diversas.
O uso de empresas de transporte foi uma terceirização do serviço
de entregas, por exemplo. A terceirização caminhou cada vez
mais para dentro das empresas e, então, partes do produto
passaram a ser feitas por outras empresas (por exemplo, as peças
diversas de um carro. E é por isso que as fábricas de automóveis
são chamadas hoje de “montadoras”.
218

Mas isso implicou também um enorme esforço de controle de

qualidade e de prazos de entrega, pois uma parte do processo
que falhasse comprometia todo o conjunto. Veio do Japão então
a expressão “ just in time”, para significar os procedimentos de
entrega no prazo exato.
Com o passar do tempo percebeu-se que a terceirização poderia

avançar muito mais, pois fabricar pedaços de ferro e montá-los
não era o segredo de uma empresa, e sim a concepção, o desenho,
a inteligência da criação do produto. A partir disso uma cadeia
imensa de pequenos fabricantes se estabeleceu, e hoje muitos
esforços dos governos por trazer grandes empresas se dão pela
intenção de formar cadeias produtoras ao redor delas.
No entanto, estamos falando de terceirização de

tarefas contínuas da indústria, enquanto que no caso
dos projetos, a idéia é um pouco diferente, por se
tratar de serviços de duração limitada e com objetivos
pré-definidos.
A terceirização 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 possível a terceirização, é necessária
uma sincronização muito forte entre o trabalho que está sendo
executado pela equipe interna do projeto e a equipe ou pessoa que
ficará responsável pelo trabalho externo, ou terceirizado.
A estrutura modular, mostrada na figura 5.6 anteriormente, é
uma possibilidade de trabalhos desse tipo, pois cada grupo ou
módulo, pode ser visto como uma unidade independente que tem
uma determinada tarefa a cumprir. Identificar as competências de
tais grupos e ter os trabalhos alinhados entre os diferentes grupos
é o desafio.
A indústria da construção civil já atingiu essa maturidade

para a terceirização de serviços de um projeto.
Equipes de empreiteiros diversos, grupos externos
de eletricistas e técnicos hidráulicos, entre outros,
atuam como terceirizados no projeto. Isso funciona
adequadamente porque a indústria da construção
civil repete os procedimentos obra após obra, e cabe ao
engenheiro da obra fazer a gestão desses diferentes grupos.
Unidade 5 219

Mais recentemente a indústria de software tem

trazido exemplos de terceirização.
Metodologias como o do PMI – Project Management Institute

(PMBOK, 2004), modelos como o CMM (Capability Mature
Model) e linguagens com a UML (Unified Modeling Language),
vêm trazendo um alto grau de profissionalização para o setor de
software, fazendo com que haja uma segmentação bem delimitada
na produção dos aplicativos.
Isso vem gerando grandes debates nos Estados Unidos, pois
muitas atividades consideradas estratégicas nessa indústria
passaram a ser terceirizadas em outros países, especialmente
Índia e China, que competem utilizando mão-de-obra
qualificada, porém muito mais barata do que a americana. São
os efeitos da globalização numa indústria que não precisa mais do
que uma rede como a internet para fazer todo o “transporte” das
partes e peças terceirizadas.
Para encerrar esse assunto, veja os dois quadros reproduzidos

abaixo, onde o primeiro aponta para o aumento dos contratos
de terceirização, publicado no site da ASSESPRO – SC, e o
segundo com a matéria publicada no site da SOFTEX, que
reproduz texto a respeito dos riscos da terceirização apontados
pela empresa de consultoria Gartner dos Estados Unidos.
Esse é um assunto bastante atual e que deverá perdurar nos
debates devido ao processo de globalização acelerado dos
mercados, especialmente os ligados às inovações tecnológicas e à
informação.
220

Terceirização de software e serviços de TI cresce

Mercado mundial de terceirização deverá crescer 7,9%.
De acordo com um estudo do Gartner esse percentual
corresponde aos anos de 2003 a 2008.
A terceirização continua crescendo em todo o mundo, embora
em ritmo diferente, em relação à região analisada, de acordo
com estudo do Gartner.
A taxa Composta de Crescimento Anual (CAGR) de
terceirização será de 7,9%, entre 2003 e 2008, enquanto a taxa
total de crescimento de TI atingirá 5,4%.
Os gastos com terceirização de TI e terceirização de processos
de negócios (BPO), em âmbito mundial, crescem mais
rapidamente do que os gastos com serviços individuais e
aqueles baseados em projetos.
Isso reflete uma tendência de crescimento da terceirização,
que vai além do mero gerenciamento de sistemas e processos
já implementados. As empresas terceirizadas estão 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 avanço do mercado de serviços em regiões diferentes: o
primeiro refere-se à cultura local e às práticas de negócios; e o
segundo, diz respeito aos padrões estabelecidos pelas grandes
companhias globai s que compõem o mercado.
Sobre a situação do mercado local, o Brasil e o México são os
líderes em terceirização na América Latina, seguidos do Chile e
da Colômbia.
Quadro 5.1 – Sobre o aumento da terceirização, publicado em 09/06/2005 em

http://www.softex.br/cgi/cgilua.exe/sys/start.htm?sid=4
Unidade 5 221

Gartner aponta riscos da terceirização offshore

Por COMPUTERWORLD
Empresas de todo o mundo gastarão mais de 50 bilhões de dólares

com iniciativas de terceirização offshore (fora do país) ou near-shore
(dentro do país) de TI até 2007, aponta a consultoria Gartner. No
entanto, alerta a companhia em um novo estudo, muitos projetos
falharão devido a planejamentos mal estruturados.
Muitas companhias têm buscado nas estratégias de terceirização
de TI uma forma de obter vantagem competitiva frente aos
concorrentes, seja com redução 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 terceirização, seja esta feita por
meio de um parceiro local ou por um especializado de outro país.
1. Redução de custos impraticável

Muitas companhias decidem buscar serviços em outros países, com
o propósito de reduzir custos. Segundo o Gartner, um profissional
de manutenção de aplicações indiano, por exemplo, ganha cerca
de 25 dólares por hora, contra a média de 87 dólares cobrados pelo
mesmo serviço, nos Estados Unidos.
Contudo, é um erro limitar os custos da operação apenas ao salário
do funcionário. A consultoria alerta para outros gastos atrelados a
fatores como infra-estrutura, comunicações, viagens e treinamento
relacionado a questões culturais. Portanto, o custo inicial da
operação é alto e, em muitos casos, pode ser mais rentável após um
ano de operação.
2. Perda de produtividade
Pelo menos inicialmente, os prestadores de serviços offshore
tendem a não apresentar a mesma produtividade que a companhia
mantinha internamente. De acordo com o Gartner, em mercados
emergentes muitos programadores são jovens e não possuem a
mesma experiência que a companhia encontra em seu país de
origem.
222

3. Comprometimento e comunicação enfraquecidos

Muitos executivos simplesmente esquecem seus contratos
depois que são assinados. A consultoria alerta para a
necessidade de se estar engajado com o prestador de
serviços para que se mantenha a qualidade de serviços pré-
acordados.
Estabelecer uma boa comunicação entre as partes é crucial,
definindo claramente projetos, objetivos e expectativas.
Dentro de casa, o diretor de tecnologia tem que deixar muito
claro porque mandar as operações para outro país traz mais
benefícios para a companhia.
4. Diferenças culturais
Estilos de comunicação e atitudes de autoridade mudam
conforme a região e estas diferenças podem trazer
problemas. Em algumas culturas, o ato de questionar a
autoridade de determinada pessoa é considerado falto de
respeito. Empresas interessadas na terceirização offshore
devem realizar treinamento entre equipes para evitar esse
tipo de situação, alerta o Gartner.
5. Distância entre teoria e prática

Algumas organizações podem vender mais do que realmente
oferecem. É preciso que o prestador de serviços tenha todos
os processos internalizados com suporte e segurança, antes
de colocar um projeto em operação. O Gartner também
destaca para a necessidade de se verificar o grau de
maturidade dos processos da empresa, utilizando padrões
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 terceirização, publicado em 28/06/2005 em

http://www.softex.br/cgi/cgilua.exe/sys/start.htm?sid=4.
Unidade 5 223

Síntese
Nesta unidade você estudou os princípios da estruturação

de uma equipe de projeto. O conceito fundamental, muitas
vezes repetido e exemplificado, é o do trabalho cooperativo. A
cooperação criativa e sincera entre os membros de uma equipe de
projetos é o passo decisivo para o seu sucesso. E vimos também
que, para isso, é de vital importância o papel do gestor como
líder.
Inicialmente foram apresentados os quatro passos que se dão na

formação das equipes de projeto: o período inicial da formação,
seguido muitas vezes de um ambiente turbulento, quando os
primeiros subgrupos se formam e há distâncias a romper, depois
o período onde as normas de trabalho se impõem e a liderança
institui uma normalização, seguido então do período de
desempenho cooperativo e onde, de fato, os resultados começam
a aparecer.
Depois vimos que os perfis são muito variados, e também são

dinâmicos, ou seja, as pessoas têm comportamentos diferentes
conforme o meio em que estão. Para dividir as tarefas e encontrar
os perfis corretamente, uma técnica interessante é preparar uma
matriz de competências, conforme vimos exemplo na figura 5.2.
Com essa matriz é possível estudar diferentes composições

de pessoas na equipe. Ajustes de competências técnicas e de
habilidades de trabalho podem ser feitas, dessa forma, por meio
de treinamentos. Mas é importante destacar que o treinamento
será eficaz se as pessoas da equipe têm uma educação de base
adequada. Nisto é que se diferencia o treinamento da educação.
224

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 híbridas, onde há uma composição de dedicações
exclusivas e outras parciais;
3. Estruturas matriciais, em que pessoas de uma organização
trabalham em difentes projetos simultaneamente, conforme
suas habilidades, sendo que o gestor do projeto é o
responsável por administrar essa locação e os resultados
parciais,
4. Estruturas modulares, formadas por pequenos grupos
dedicados a sub-projetos, os quais podem colaborar para um
projeto ou vários, e;
5. Estruturas horizontais, geralmente em projetos pequenos e
que envolvem pares de especialistas, os quais não têm um
comando central.
Esses modelos podem ser ajustados caso a caso, e dependerão

da experiência e liderança do gestor para que obtenham o
desempenho desejado.
Por fim, esta unidade tratou da terceirização como uma variação

a mais dos modelos estruturais anteriores. A terceirização vem se
expandindo em todas as atividades produtivas e alcança também
os processos de trabalho relacionados a projetos. No caso do
desenvolvimento de tecnologias da informação há apreensão, pois
a terceirização tem deslocado os serviços para regiões remotas,
que têm preocupado tanto no sentido da perda de empregos
quanto na perda do controle do conhecimento como do próprio
andamento do projeto.
Na próxima unidade, você verá o dia-a-dia do projeto

durante sua execução, seus problemas de rotina e
os aspectos importantes da liderança no sucesso da
empreitada. Até lá!
Unidade 5 225

1) Quais são as quatro fases de estruturação da equipe e, em sua
opinião, qual a mais problemática? Por que a fase escolhida é a mais
problemática?
2) Como uma matriz de perfis e competência pode ajudar na estruturação

de uma equipe?
3) Em sua opinião, qual tipo de estrutura de equipe melhor se ajusta

ao desenvolvimento de software em uma pequena empresa, cujos
projetos são iniciados apenas sob a demanda do cliente?
226

4) Qual o modelo de estrutura representado na figura abaixo? Qual o seu

grande problema?
Gerência geral
da empresa
Área Área Área Área Área

administrativa Engenharia
financeira comercial técnica 1 técnica n
Projeto 1
Projeto 2
Projeto 3
Projeto n
5) Em que tipo de estrutura é possível uma grande troca de

conhecimentos, sendo que as pessoas trabalham entre pares? Qual a
vantagem desse tipo de estrutura na indústria de softwares?
Unidade 5 227

6) Como você avalia os riscos da terceirização na área de software?
Saiba mais
Veja em www.teses.usp.br a dissertação de mestrado de Leandro

Patah, “Alinhamento estratégico de estrutura organizacional de
projetos: uma análise de múltiplos 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 terceirização, bem como o estudo comparativo
entre as indústrias de software no Brasil, China e Índia. Há
exemplos de como a terceirização alavancou a indústria indiana,
por exemplo.
228

UNIDADE 6
Executando o projeto
6
Compreender aspectos do início de um projeto e
como o seu bom entendimento permite a gerência e o
controle eficaz da qualidade.
Perceber as diferenças básicas entre líderes e gestores.
Estudar técnicas e práticas para controle de prazos e

recursos, encontros de trabalho e gestão de conflitos.
Verificar as várias subdivisões e etapas intermediárias

que um projeto de sucesso demanda.
Seções de estudo
Seção 1 Preparação e início dos trabalhos.
Seção 2 Liderança versus gestão.
Seção 3 Tomada de decisões.
Seção 4 Motivação e comunicação.
Seção 5 Reuniões.
Seção 6 Gerenciando qualidade, tempo e recursos.
Seção 7 Gestão de conflitos.
Seção 8 Simulação, testes e validação.


Tendo uma série de ferramentas e práticas de planejamento
em mãos, estudadas anteriormente, chegamos ao dia-a-dia
de trabalho do projeto. Neste momento teremos que colocar
em prática o planejamento, e novas dificuldades certamente
surgirão. Esta unidade apresenta questões práticas relacionadas
com o início do projeto, com os possíveis conflitos advindos do
choque entre pessoas da equipe com variados perfis, bem como
as características do gestor do projeto para tratar tais conflitos e
dificuldades.
Em especial é debatido o perfil do gestor quando comparado

com o do líder, assunto que vem tomando parte de muitos
debates sobre desenvolvimento tecnológico e inovação já que tais
diferenças de perfis podem afetar positiva ou negativamente o
desenvolvimento do projeto e mesmo dificultar a administração
de conflitos, por exemplo.
Também nesta unidade é tratado o tema das simulações e testes

de revisão contínua, 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!
SEÇÃO 1 – Preparação e início dos trabalhos

Até agora já falamos muito sobre planejamento, sobre estimativas
de recursos, análise de riscos, formação de equipes de trabalho
e muitas outras coisas, mas chegou a hora de “colocar a mão 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 também).
Na realidade, a produção em projetos é uma decorrência do
planejamento, pois como já foi dito várias vezes, o projeto é um
trabalho com data marcada para acabar, enquanto as atividades
230

de produção de rotina não têm tal finalidade e as pessoas entram

no trabalho de uma empresa ou indústria, por exemplo, quando
as coisas já estão acontecendo.
Outro fator importante e, por isso, aparentemente

tanta preparação, é que em um projeto é preciso sempre
ter a visão do conjunto e não apenas das partes.
Tendo realizado tal planejamento, previsto os recursos
disponíveis e tendo os objetivos claros e o contrato
estabelecido junto ao cliente, é hora de começarmos os
trabalhos.
Para preparar e começar o projeto é interessante você

considerar as seguintes observações:
muitas pessoas imaginam que trabalhar em um projeto é

começar imediatamente a programar, ou a perfurar, ou a
martelar, ou seja lá o que for que pareça demandar muito
esforço. Dessa forma, a energia é despendida logo no começo
e, na maioria das vezes por não se saber onde se quer chegar,
rapidamente tudo esvaece e o projeto perde, então, o sentido;
trabalhar em um projeto não é despender um enorme
esforço em direção a um objetivo desconhecido,
para aparentar que o suor faz o trabalho. Projeto,
necessariamente, exige reflexão;
muitos pensam que ‘alguém’ tem que dar as ordens e que esse
‘alguém’ é que tem todo o projeto na cabeça, bastando seguir
seus passos. Provavelmente há um ‘alguém’ responsável e líder
num projeto, no entanto esse responsável certamente não tem o
projeto todo na cabeça;
não existe um “ser sagrado” que sabe tudo sobre o
trabalho a ser realizado, e o responsável depende
inteiramente da sua equipe;
como o projeto é uma atividade inerentemente coletiva, é

fundamental que haja o espírito do trabalho cooperativo;
não há como fazer projetos com algum nível de
complexidade sem a participação criativa e positiva
de várias pessoas. – vi recentemente um grupo de
projetistas que inventou uma espécie de jogo em rede
Unidade 6 231

de computadores, uma espécie de gincana, em que eles

brincavam de colocar partes do projeto num diretório
comum, e a vitória era cumprir tal demanda num prazo
cada vez mais curto – era uma brincadeira que fazia do
projeto uma diversão em forma de game!
O início de um projeto deve acontecer com uma reunião. Nessa

reunião o escopo do projeto deve ser exposto com a maior
clareza possível, os detalhes devem ser discutidos até a exaustão,
o plano de produção deve ser detalhado, as tarefas divididas
e as responsabilidades atribuídas. É neste momento que o
fluxograma geral (lembra do algoritmo do projeto?) deve ser
Se houver a necessidade, consulte apresentado, discutido e suas cópias distribuídas. A comunicação
novamente a Unidade 3, Seção 3: dos procedimentos, já discutidos aqui, deve ser feita a partir dessa
Algoritmo do projeto. reunião de contato inicial.
Geralmente as reuniões são muito mal vistas. Por quê? Algumas

pessoas pensam que reuniões são chatas, que não dizem nada,
que o chefe senta na extremidade da mesa apenas para mandar.
Essa é uma visão de reuniões normalmente veiculadas em
filmes e novelas. Podemos imitá-las e então ter
péssimas reuniões ou então optarmos em seguir
um caminho muito mais objetivo e perceber
que reuniões são ótimos momentos para fazer
o trabalho, de fato, andar rumo ao sucesso. As
reuniões serão interessantes se:
tiverem uma pauta bem definida;

a pauta não for extensa;
os assuntos forem claros e de conhecimento dos
presentes;
o horário de começo e fim forem bem definidos;
forem suficientemente breves; (as CPIs do governo são
longas e repetitivas, mas não são reuniões, percebe?)
houver um coordenador, capaz de gerenciar as falas entre
os diversos presentes;
houver um líder, capaz de decidir quando for necessária
uma decisão.
232

Há empresas que fazem tantas reuniões que as algumas pessoas

chegam a pensar que trabalhar é participar de reuniões e, outras
pessoas pensam que a pior coisa do mundo é uma reunião. Nem
uma nem outra está correta. Provavelmente, nestas empresas as
reuniões estão sendo mal conduzidas.
Depois da fase de reuniões iniciais o projeto tem, então, seu

começo. Os grupos de trabalho estão com suas atividades
definidas, prazos estabelecidos e resultados por alcançar. Resta
cumprir as etapas, já estabelecidas no Gráfico de Gantt do
projeto. Se o planejamento foi bem feito, há uma definição bem Consulte unidade 4, seção 2.
clara de objetivos e atividades e, possivelmente, com sub-etapas
de prazos curtos.
A Microsoft, por exemplo, trabalha com uma

orientação designada como “zero-defeito” com
prazos curtos de entregas intermediárias como
objetivo de maior desenvolvimento (MSF, 1998). Assim
que começam os trabalhos de desenvolvimento,
a mentalidade de “uma entrega a cada dia” é
estabelecida entre todos os membros da equipe. Com
isso, há a sensação 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 não é
simplesmente colaborar no projeto para que ele
chegue ao resultado final. Ele considera que cada
projetista, ao começar seu trabalho, deve estar
pensando em “entregar”. Leia o seguinte parágrafo e
pense nisso:
“Todos [os projetistas]… têm o mesmo trabalho. Eles
têm exatamente a mesma descrição de trabalho. E esta
é entregar (embarcar) produtos. Seu trabalho não é
escrever código. Seu trabalho não é testar. Seu trabalho
não é escrever especificações. Seu trabalho é entregar
produtos. Isto é o que um grupo de desenvolvimento
faz. Seu papel como um desenvolvedor ou como um
testador é secundário. Não estamos dizendo que não são
importantes – mas são secundários para seu trabalho
real, o qual é entregar um produto. Quando você acorda
cedo de manhã e vem para seu trabalho, você diz,
‘Qual é o foco—estamos tentando entregar ou estamos
tentando escrever código? ’ A resposta é: nós estamos
tentando entregar. Você não está tentando escrever
código.” (MSF, 1998)
Unidade 6 233

Este parágrafo elucida sobre a atitude esperada de um projetista

ao participar de um grupo de trabalho. É com este foco que o
trabalho deve ser iniciado.
SEÇÃO 2 – Liderança versus gestão

Conforme você estudou anteriormente na unidade
5, foram ressaltadas diferenças entre as atitudes da
liderança e da gestão, sendo dados, por brincadeira, os
exemplos do gestor-rinoceronte, gestor-cobra e gestor-
raposa. Agora é hora de falar um pouco mais sério
sobre o assunto.
Estamos muito mais acostumados a trabalhar com

gestores, ou gerentes, do que com líderes. A função
da gerência tem sido muitas vezes confundida com uma espécie
de atuação por cobrança e controle que coloca os gerentes numa
condição de animosidade com seu grupo de gerenciados. Ou seja,
aqueles que ficam submetidos ao gerente se sentem diminuídos
e perdem, geralmente, a motivação 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 têm ojeriza por liderança, pois vêem na figura

do líder uma espécie de ser “sagrado” que detêm a verdade. É
possível que essa imagem falsa tenha origem de duas fontes:
a primeira é a mitologia criada sobre líderes carismáticos, que
levam as pessoas a fazer coisas que normalmente não fariam; a
segunda é que esse tipo de gestor não consegue cumprir funções
muito mais simples, essas sim dos líderes, como tomar decisões,
se arriscar mais e apoiar verdadeiramente cada um dos membros
de sua equipe. A ojeriza acaba se dando por não conseguirem
cumprir nenhum dos dois papéis. Não assumem a figura
carismática por não concordarem ou não se adaptarem a ela.
234

Também acabam não assumindo a função de liderança objetiva

e criativa por não terem a habilidade de relacionamento humano
necessária. Com esse distanciamento, acabam manifestando uma
ojeriza generalizante, denegrindo todos os tipos de liderança.
No entendimento de Page-Jones (1990) são as seguintes as

qualidades de um gerente de projetos:
integridade pessoal,
sensibilidade,
capacidade de estabelecer objetivos,
capacidade de cumprir objetivos,
tenacidade,
capacidade de inspirar,
disposição de servir,
coragem de delegar,
competência técnica,
capacidade para comunicar a realidade,
capacidade de pensar e ser inovador,
coragem de tomar decisões.
Estas características cabem perfeitamente para os líderes,

especialmente as qualidades de “inspirar, ser inovador e ter
coragem de tomar decisões”. Nem sempre os gerentes são
inspiradores, inovadores e decisores e, mesmo assim, são ótimos
gerentes, pois são capazes de coordenar os prazos e distribuir
tarefas adequadamente e os membros da equipe confiam nele
para conduzir o trabalho até o final.
Em seu livro sobre gerenciamento de projetos, Valeriano (1998)

cita Denis Donaire, este considera que os atributos desejáveis em
um gerente estão divididos em três grandes áreas: conhecimentos,
habilidades e atitudes. O detalhamento dessa divisão é o
seguinte:
Unidade 6 235

a) Conhecimentos desejáveis
Em relação ao conhecimento organizacional o gestor
necessita:
a) ter conhecimento do sistema administrativo e
financeiro da organização onde trabalha;
b) conhecer o funcionamento do sistema de RH

(recursos humanos) e como se dão as relações
jurídicas com relação aos funcionários e
terceirizados da empresa;
c) práticas, políticas e valores, que é a percepção

clara de perceber como funciona a organização
em suas práticas no dia-a-dia, a política interna
das relações e por quais valores se orientam
aqueles que trabalham nela;
d) ter consciência do custo e das implicações das

decisões técnicas; o que implica reconhecer as
relações entre as ações e o que isso significa no
tocante aos gastos no projeto e para a empresa;
e) ter conhecimento das atividades econômicas

da organização, dos seus produtos, missões
e mercados ou clientes da organização, que
significa um conhecimento profundo das
atividades econômicas da organização.
Em relação ao conhecimento técnico, o gestor necessita:

a) conhecer áreas correlatas à especialização de
que trata o projeto, com uma visão geral das
competências tecnológicas;
b) ter competência técnica em pelo menos uma área

de especialização;
c) ter domínio de métodos de pesquisa, que

permitam relacionar os diversos membros da
equipe em um desenvolvimento equilibrado e
voltado a resultados.
236

b) Habilidades desejáveis
Em relação às habilidades de comando o gestor
necessita:
a) ter a capacidade (e isso deve ser perceptível)
de planejamento, organização e controle das
atividades do projeto;
b) desenvolver sua capacidade de liderança (pois

consideramos que a capacidade de liderar é inata
a todas as pessoas);
c) capacidade de auto-análise, ou seja,

constantemente fazer a auto-crítica das
suas atitudes, dos seus conhecimentos e das
necessidades de aprimoramento técnico;
d) capacidade de alocação de recursos que advém

do conhecimento dos recursos disponíveis
e daqueles que serão necessários buscar no
desenvolvimento do projeto;
e) capacidade de gerar confiança no superior e

isso se dá pela integridade e pela segurança ao
trabalhar orientado a resultados;
f) perceber e escolher o estilo de liderança

adequado a equipe de trabalho, o tipo de projeto
e do cliente contratante, seja externo ou um
superior da empresa;
g) habilidade de tomada de decisões, condição

essencial numa função de comando (o gerente
que não toma decisões é considerado fraco por
sua equipe, o que desmotiva o grupo).
Outras habilidades:
a) trabalhar em equipe, habilidade esta que já
comentamos muitas vezes ao longo deste livro e
que está relacionada à capacidade de cooperar e
gerenciar conflitos;
Unidade 6 237

b) criatividade, especialmente na solução de

problemas inesperados e distantes daqueles que
foram avaliados como riscos inerentes ao projeto,
sendo que a criatividade também está relacionada
à habilidade de manter diálogos constantes
com os membros da equipe e com a inspiração
motivacional, gerando idéias diferentes das
convencionais;
c) capacidade de redigir com clareza, precisão e

concisão, habilidades relacionadas à capacidade
de se comunicar, necessária para o andamento do
projeto de forma coordenada e racional;
d) relacionamento pessoal, habilidade relacionada

ao dia-a-dia do trabalho em equipe, às atitudes
de educação na convivência (infelizmente não
é nada difícil encontrarmos “gerentes” que se
dirigem aos membros de sua equipe aos berros).
Sobre o relacionamento pessoal temos um caso

interessante: disse certa vez numa reunião de
gerentes que eu não aceitaria trabalhar numa empresa
onde os “chefes” se acham no direito de humilhar seus
funcionários, e os resultados foram dois: primeiro,
fui estigmatizado por tais “gerentes” e “saído” 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 não entendo se os funcionários mentem nas
entrevistas ou se tais listas são arranjadas.
c) Atitudes
Posicionamento em relação a aspectos internos e
externos:
a) interesse por questões administrativas, que
implicam conhecer e se posicionar em relação
aos diversos aspectos do trabalho, na empresa e
no projeto, mesmo que não sejam suas funções
as atividades executivas da administração
empresarial;
238

b) disciplina de trabalho, que envolve ao mesmo

tempo a dedicação produtiva diária ao próprio
trabalho e, na sua condição de gestor, do
exemplo aos membros da equipe de que a
disciplina é a geradora da produção e do
resultado;
c) entrosamento com pessoal externo à organização,

pois isso é essencial para realizar as interfaces de
negociação de requisitos, solicitação de recursos
extraordinários, verificação de pendências,
solução de conflitos diversos etc.;
d) ambição profissional, que é necessária para o

crescimento tanto do indivíduo quanto do seu
grupo de projeto; ambiente sem ambição de
crescimento e sucesso é desmotivador.
Estratégias de ação:
a) hábito de começar o ataque ao problema pela
revisão da literatura, pela revisão dos projetos da
mesma área que o antecederam, seja na empresa
ou outros locais e, principalmente, a capacidade
de exercitar sempre uma visão geral do problema
e do ambiente de negócios onde o projeto está
envolvido;
b) hábito de leitura sistemática de textos técnicos,

pois com isso há atualização constante em
relação às inovações tecnológicas e geração de
novas idéias, ponto fundamental para lançar
novos projetos, como os discutidos na unidade 1
deste livro.
Essas são considerações gerais sobre gerência, mas o que

defendemos como principal para o sucesso de um projeto é a
atitude da liderança. Nos tópicos citados anteriormente, a maioria
das atribuições que você estudou serve tanto para gerentes quanto
para líderes enquanto outras são características específicas da
liderança. É preciso que você entenda que as características
de “líder” são inerentes a todos nós mas, em geral, não são
estimuladas nos indivíduos em uma sociedade que procura,
Unidade 6 239

de certa maneira, uniformizar procedimentos e atitudes. Tal

uniformização (ou mediocrização) pode ser considerada uma
doença que afeta o nosso desenvolvimento como indivíduos e, por
conseqüência, como sociedade. Não é o caso de dizer que todos
devem ser líderes em todas as atividades, mas sim, que saibamos
nos posicionar sempre em que tal comportamento de liderança se
faça necessário. A liderança implica também o discernimento da
compreensão do momento em que precisamos ser parte de um
grupo onde já há um líder no qual devemos depositar confiança
no trabalho.
Stephen Covey (2005) criou uma tabela que relaciona diferenças

entre liderança e gerência e, no quadro abaixo, apresento uma
adaptação de tal tabela de acordo com os conceitos desenvolvidos
para este livro:
Quadro 6.1. Diferenças entre Liderança e Gerência, adaptado de Covey (2005).
LIDERANÇA GERÊNCIA
Interessado nas pessoas Interessado nas coisas
Trabalha na espontaneidade Trabalha com a estrutura
Liberação e fortalecimento das idéias Controle das atividades e das idéias
Eficácia Eficiência
Prefere planejar e programar Prefere trabalhar sob um programa
Considera gasto como investimento Considera gasto como despesa
Trabalha baseado em princípios Trabalha baseado em técnicas
Procura transformação Procura transação
Poder centrado em princípios Poder centrado em utilidade
Procura resolver por discernimento Procura resolver por medição
Fazer a coisa certa Fazer certo as coisas
Resolve baseado numa direção Resolve baseado em rapidez
Pensa numa linha superior Pensa em resultados
Tem propósitos Tem métodos
Decide baseado em princípios Decide baseado em práticas
Busca algo acima das coisas Busca algo dentro dos sistemas
Para o líder a pergunta é: “a escada está Para o gestor o que importa é: subir
junto da parede certa?” rapidamente a escada
240

Especificamente sobre lideranças, Christenson (2004) avança

ainda mais sobre seus conceitos dividindo-as em quatro diferentes
tipos, descritas abaixo:
1. a que considera os indivíduos, ou seja, é capaz de

estimular as pessoas de sua equipe e seus seguidores a
terem uma visão nova de seu próprio trabalho;
2. a que estimula intelectualmente, gerando um

alinhamento positivo das idéias das pessoas em relação à
organização e ao projeto;
3. a que influencia os ideais, ou seja, estimula seus colegas

de trabalho a alcançarem altos níveis de habilidade;
4. a que motiva inspirações, levando seu grupo de colegas

a olharem além do interesse próprio e em direção ao
benefício de todo o time.
Bem, não é necessário fazer um juízo de valor sobre qual o

melhor, líder ou gestor, pois os papéis dependerão da atividade,
do tamanho do problema ou do tipo do projeto. De certa forma,
os dois papéis devem estar combinados (e não agir como o gestor
que execrava “líderes” em sua organização).
Começado o projeto, tendo um planejamento claro das atividades

(veja também as unidades anteriores com os Diagramas de Gantt
e as ferramentas PERT/CPM), consideradas as funções de
liderança e de gestão, passa-se agora aos detalhes do dia-a-dia
do projeto. Um dos pontos nevrálgicos de qualquer projeto é a
tomada de decisão, assunto da próxima seção.
Unidade 6 241

SEÇÃO 3 – Tomada de decisões

Hoje uma grande parte dos textos sobre administração
empresarial dirige seu olhar para o problema da tomada de
decisão.
Decidir significa escolher uma opção entre várias

e, com isso, há sempre o risco da escolha não recair
sobre a melhor opção.
Um campeão de xadrez decide o melhor movimento a cada

vez e seu exercício de escolha é renovado a cada nova jogada.
Aquele que cometer mais decisões erradas, perderá o jogo. Assim
também o goleiro na hora do pênalti: a decisão do seu movimento
poderá implicar ou não 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 decisão que levará ao gol, ao
ponto, enfim, ao sucesso.
Que “milagre” poderia ser esse, capaz de levar a uma

decisão certa no momento certo?
Alguns traços são comuns entre esses “tomadores de decisão”:
experiência anterior;
treino em decidir e executar (as jogadas, os chutes);
o exercício da visão ampla (do jogo);
coragem de, após um erro, calibrar os movimentos para
tentar de novo até acertar.
Quem ama os esportes já viu algum desses momentos mágicos
quando o atleta resolve arriscar um difícil movimento, muitas
vezes num momento crítico onde a chance da derrota era enorme
e, cheio de confiança, decidir uma partida.
242

Um jogo coletivo é como um projeto: há um

objetivo a ser atingido, o prazo está estabelecido
e só é possível vencer se a equipe estiver unida e
entusiasmada.
Para Page-Jones (1990) a tomada de decisão durante um projeto

envolve quatro passos:
identificar possíveis modos de ação e chegar a um

entendimento comum do que cada opção significa;
identificar as ramificações de cada opção, incluindo
vantagens e desvantagens;
discutir e avaliar cada uma dessas ramificações;
escolher o modo de ação mais vantajoso e partir para ele.
Como vemos, em um projeto, há a necessidade da constante

avaliação das opções possíveis e disponíveis e isso combinado à
experiência prévia do decisor, definirá as próximas ações.
SEÇÃO 4 – Motivação e comunicação

Em um projeto, outro fator importante para o bom
andamento do trabalho, é a clara comunicação para
toda a equipe e interessados, sobre os objetivos,
os resultados a serem alcançados e sobre como
se darão todas as pequenas divisões e etapas até
chegar aos resultados esperados. Nesse sentido,
um planejamento utilizando o Gráfico de Gantt
parece ser fundamental, uma vez que ele utiliza o
gráfico de barras ao longo de tempo e é conhecido de todos. A
comunicação, seja inicial ou a cada etapa do projeto, deve se dar
sobre tal gráfico e deve ser acompanhada da marcação sobre o “já
realizado” e sobre o que falta realizar.
Unidade 6 243

A comunicação clara das atividades deve ser feita a cada momento

importante, tal como inícios e encerramentos de etapas, mas o dia-
a-dia de cada etapa exige entusiasmo e motivação por continuar.
Infelizmente, muitos entre nós sofrem de um mal moderno
conhecido como depressão 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
também a constante necessidade de superação de desafios. Assim,
primar por uma comunicação que motive e que entusiasme o
indivíduo é mister para se alcançar resultados positivos.
Em uma pesquisa sobre a motivação para o trabalho, Page-
Jones (1990) cita a obra de Maslow para definir as necessidades
básicas 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 básicas e motivação (Page-Jones, 1990).
Necessidades Níveis Exemplos

· Fisiológicas · Fome, sono, sede
BÁSICAS · segurança · no emprego, tranqüilidade
· sociais · pertencer a grupo, família, amigos
· Estima · Sensação do trabalho bem feito
DE CRESCIMENTO
· auto-realização · desafio vencido, desenvolvimento
Pelo que você pode observar no quadro, enquanto as necessidades

básicas parecem satisfeitas em boa parte da sociedade atual
(salvo nas regiões mais pobres e de maior desigualdade no país
e no mundo), o mesmo já não se pode dizer das necessidades de
crescimento. Mesmo nos países mais ricos e de maior distribuição
de renda, os níveis de auto-estima e auto-realização parecem
não estar ainda bem resolvidos. Neste ponto voltamos às seções
anteriores para perceber que são motivacionais as atitudes dos
líderes, que se posicionam frente a desafios e que sabem valorizar
o trabalho e o esforço de todos. Gestores sem tais habilidades,
sem dúvida, farão projetos fracassarem.
244

SEÇÃO 5 – Reuniões
Reuniões... isso não lhe parece um assunto bastante

pueril para um livro sobre gestão de projetos?
De fato seria, caso as reuniões não tivessem assumido

um papel de tortura e de desgaste para muito de nós.
Há empresas, especialmente as públicas, ou alguns
partidos e agremiações políticas, que parecem se
movimentar apenas por meio de reuniões. Por causa
disso, esses encontros de trabalho passaram a ser
encarados por muitas pessoas como inúteis, mas,
certamente, não o são.
Atribuo grande importância às reuniões de projeto,
pois são momentos especiais de comunicação e decisão.
São nesses momentos que os planos, as discussões e os rumos
do trabalho são colocados e precisam ser enfrentados como
ambientes coletivos para o desenvolvimento do próprio projeto.
Para que uma reunião venha a ser bem-sucedida, Page-Jones
(1990) coloca as seguintes sugestões de ação:
1. Antes da reunião:
o grupo de trabalho ou o gestor/líder, deve definir um
lugar conveniente para a reunião;
os participantes devem ser selecionados conforme o
assunto em pauta e não simplesmente reunir todos do
grupo;
antes de marcar uma agenda, é importante verificar se
todos podem, de fato, participar;
se há consenso sobre uma data e horário, fazer então o
aviso com antecedência;
a pauta de reunião deve ser bem definida e levada aos
participantes com antecedência;
o número de itens em pauta deve ser restrito, evitando
dispersão e superficialidade.
Unidade 6 245

2. Durante a reunião:
deve ser designado um moderador capaz de organizar/
gerenciar as falas e questões propostas pelos indivíduos
do grupo;
também deve ser designado um secretário que anote os
pontos principais discutidos, bem como, as resoluções
adotadas, criando então uma ata;
o grupo deve prender-se à pauta, evitando entrar em
assuntos diversos;
definir regras de procedimento conforme o objetivo dos
itens de pauta (planejamento, comunicação, resolução de
problemas, decisão).
3. Depois da reunião:
todos os itens de ação devem ser anotados e devem ser
atribuídas responsabilidades por item de ação;
distribuir a ata da reunião.
Tenho certeza que você, ao ler essas linhas, estará pensando

em reuniões em que já tomou parte e que não se seguiram tais
recomendações. Aquelas que tiveram alguém capaz de conduzir
as conversas talvez, tenham tido bons resultados, porém, a
maioria, deve ter sido enfadonha e sem resultados, sem contar
com a sensação do tempo perdido.
Para o projeto de desenvolvimento de uma inovação tecnológica,

um software, um novo produto, haverá, com certeza, várias
reuniões e caberá a cada um de nós interferir para garantir o seu
bom andamento. Se a reunião não tiver pauta, solicite uma. Se a
hora de acabar não estiver definida, pergunte qual é.
246

SEÇÃO 6 – Gerenciando qualidade, tempo e recursos

Gerenciar a qualidade é buscar a ausência de erros. Muitas
vezes, não prestamos atenção aos erros e criamos metas de
qualidade que podem ser bem baixas para nossa vida social,
apesar de parecerem excelentes para a vida profissional. Leia
com atenção o seguinte texto:
As pessoas foram condicionadas a acreditar
que o erro é inevitável. Não apenas aceitamos
o erro, nós o prevemos. Quando projetamos
circuitos, programamos um computador, fazemos um
planejamento, soldamos conexões, datilografamos
uma carta, fazemos um orçamento, ou montamos
componentes, não nos preocupamos se cometemos alguns
erros; e a gerência prevê o acontecimento desses erros.
Achamos que os seres humanos possuem um fator de erro
integrado a eles.
Entretanto, não mantemos o mesmo padrão, quando

a coisa passa para o campo da vida pessoal. Se
mantivéssemos, aceitaríamos com naturalidade receber
troco errado (a menos); aceitaríamos que as enfermeiras
deixassem cair no chão um percentual de recém-nascidos;
acharíamos natural entrar na casa errada de vez em
quando. Como indivíduos, não toleramos esses erros.
Portanto, temos dois pesos e duas medidas: um para nós
e um para a empresa.
A razão para isso é que a família cria para nós padrões 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 inspeções. Os erros que
produzem esse desperdício são causados diretamente
pelo pessoal da empresa, tanto pelos funcionários quanto
pela administração. Para eliminar esse desperdício,
para melhorar o funcionamento e aumentar a eficácia,
precisamos nos concentrar na prevenção dos defeitos e
dos erros que nos assolam. O erro que é prevenido não
precisa de consertos, exames ou explicações. O primeiro
passo é adotar uma atitude de prevenção de defeitos. Essa
atitude é chamada, simbolicamente, de Defeito-Zero.
Texto de Philip Crosby, citado por Tom DeMarco, (1991)
Unidade 6 247

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
distância dele, de um ponto de vista conceitual. Muitas empresas
buscam entender “defeitos” na produção a partir de índices de
erro encontrados numa linha de fabricação, na quantidade de
“bugs” do sistema, ou diversos outros indicadores preparados
para apontar uma não-conformidade. Ora, defeito não é
necessariamente um índice, mas sim a atitude de aceitar a sua
existência ou não 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

Kloppeborg & Petrick, 2004. gerenciamento da qualidade em projetos passa por dois momentos
críticos: a abertura do trabalho e seu encerramento. Os pontos
fundamentais a serem tratados nesses dois momentos são:
1. Fase inicial do projeto

Identificação dos objetivos do projeto;
alinhamento estratégico com a empresa e com o objetivo
do cliente;
alinhamento operacional com as capacidades de produção
da estrutura disponível;
seleção dos recursos necessários;
contrato detalhado do projeto descrevendo:
a) o porquê do projeto (onde se apresentam as
justificativas do trabalho e as causas que o
inspiraram);
b) o quê? (onde o escopo detalhado do trabalho

deve ser colocado, definindo claramente os
resultados esperados);
248

c) quando? (em que é apresentado o cronograma

geral do trabalho, definindo datas de início e
fim, bem como de interação entre equipe de
projetos e cliente/contratante)
d) quanto custa? (especificando o valor global do

projeto e medições financeiras parciais, quando
necessário)
e) Quais os riscos? (descrevendo condicionantes

e possíveis problemas, capazes de alterar o
andamento do projeto, seja em prazos, seja em
custos)
f) como fazer? (apresentando os fatores críticos

do sucesso, o plano de comunicação, os
conhecimentos necessários e os compromissos,
bem como outras ações que afetarão o processo
de produção do projeto).
2. Fase de encerramento
Definição e comunicação dos benefícios reais entregues
para o cliente;
expressão de reconhecimento aos participantes;
entregar prêmios quando há méritos especiais (evitando
aquele tipo de mediocrização que evita prêmios para não
“magoar” os mais fracos).
Para o gerenciamento do tempo e dos recursos do projeto,

retorne aos fluxogramas das figuras 3.4 e 35, onde vemos a
necessidade de revisão 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 revisão da etapa (figura 3.5), é possível
replanejar o projeto e avaliar as condições de tempo restante e
recursos disponíveis e ainda necessários.
Unidade 6 249

SEÇÃO 7 – Gestão de conflitos

Como não podia deixar de ser, o trabalho em equipe é, quase
sempre, um ambiente de conflitos. Isso acontece devido ao
dinamismo dos pensamentos e sentimentos humanos em
constante movimento e readequação. Segundo Valeriano (1998),
existem três tipos de conflitos:
o de ordem intrapessoal, que ocorre em cada indivíduo,

consigo mesmo;
o interpessoal, que ocorre entre diferentes indivíduos;
o intergrupos, que se dá entre diferentes grupos.
Os conflitos estão presentes em todos os ambientes sociais,

sejam de trabalho, familiar ou de comunidades em geral e,
obviamente, estão presentes também nas equipes de projeto
as quais, muitas vezes, estão reunidas por um pequeno
período de tempo e de forma muito intensa o que, via de
regra, potencializa as relações.
Esses três tipos de conflito, intrapessoal, interpessoal

e intergrupos, estão presentes no decorrer dos projetos
segundo as seguintes causas potenciais (KEELING, 2002):
na definição de cronogramas, quando diferentes

interesses tendem a se contrapor na preparação das
agendas de trabalho;
na definição das prioridades;
na composição dos recursos humanos a trabalhar no
projeto, onde afinidades pessoais tendem a se manifestar;
opiniões técnicas e de desempenho, durante o desenrolar
dos trabalhos;
procedimentos administrativos, geralmente um ponto
delicado de discussões entre a equipe do projeto e suas
liberdades de ação contra as amarras muitas vezes
necessárias da burocracia administrativa;
custos, na batalha infindável por uns solicitando mais
dinheiro e outros negando;
250

conflitos de personalidade (sobre isso, nem há o que

comentar).
No quadro 6.3, abaixo, você poderá observar os conflitos
em projetos oriundos de diferenças entre os indivíduos e as
organizações devido a seus diferentes objetivos. As pessoas
têm diversas necessidades e intenções que, muitas vezes, não
combinam ou se ajustam às das organizações, mesmo que
tais organizações, paradoxalmente, tenham sido construídas
por indivíduos. O quadro apresenta uma tabela de exemplos,
adaptada de Valeriano (1998).
Quadro 6.3. Fontes de conflitos, adaptada de Valeriano (1998).
Diferenças de objetivos como fonte de conflitos

Indivíduo / profissional Organização / gerência
Busca a inovação tecnológica Busca o lucro
Quer autonomia de ação Quer integrar os profissionais na organização
Quer livrar-se de regras e procedimentos Estabelece as regras e procedimentos
Quer autoridade baseada em mérito Autoridade baseada em hierarquia
Quer ser recompensado com base em seu Recompensa conforme o interesse da organização
desempenho
Quer ampla comunicação entre pares Bloqueia a comunicação interna
Busca otimização do próprio trabalho Busca cumprimento de cronogramas e custos
Você percebe como são 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 suficiente blindagem entre os objetivos mais gerais da
organização e os específicos do projeto que, por sua vez, devem
refletir sobre os indivíduos que o compõem. Há organizações
que trabalham orientadas por projetos, porém com a mentalidade
tradicional. Não será possível vencer a contradição se não
houver um repensar de princípios. Organizações envelhecidas,
nascidas ainda com a mentalidade dos princípios da revolução
industrial, por exemplo, buscam renovação adotando práticas de
Unidade 6 251

reengenharia e gestão por projetos e, normalmente, fracassam

logo em seguida sem saber o porquê. A orientação por projetos
é uma orientação às pessoas, pois os projetos são movidos
pelas pessoas que compõem as equipes de projetos. Assim, será
necessária uma mentalidade direcionada ao relacionamento das
pessoas, e não a um conjunto de regras rígidas, protocoladas
por inúmeros papéis e procedimentos técnicos, apropriados para
controlar máquinas, não indivíduos. Sem tal mentalidade, os
projetos fracassam.
No entanto, mesmo que teoricamente saibamos onde estão as
supostas raízes dos problemas, não estaremos, necessariamente
livres de conflitos em um projeto, então será imprescindível
administrá-los. Para Valeriano (1998), há as seguintes
possibilidades de se administrar conflitos num projeto:
por confronto ou solução de problemas, quando as

partes envolvidas encaram o problema e buscam juntos
alternativas de solução;
por comprometimento, que é a busca de soluções
alternativas, por parte do gerente do projeto, dando
algum grau de satisfação às partes envolvidas;
por acomodação, onde são enfatizadas as áreas onde há
acordo, e esquecidas ou desprezadas as áreas conflitantes;
haverá perda para o projeto se as áreas de atrito eram, de
alguma forma, importantes para seu prosseguimento;
por prevalência, que é quando uma das partes prevalece
sobre a outra, numa relação ganha-perde;
por retirada, quando o conflito é deixado de lado,
sem solução, 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 reflexão.
Considerando tais possibilidades, será função do gestor escolher a

maneira de lidar com o conflito. Com certeza a melhor forma de
administrar os conflitos se dá quando são percebidos o mais cedo
possível. Como muitas doenças, se o conflito for detectado no
início é mais fácil de curar e, se muito tarde, pode ser impossível.
Por isso a atenção do gestor é primordial.
252

SEÇÃO 8 – Simulação, testes e validação

Projetos podem ter resultados melhores se forem testados em
etapas, como resultados parciais e não aguardar até o final
para ver o que deu certo e o que deu errado. Nesse sentido é
importante para cada etapa e sub-divisão do projeto, buscar
conseguir um resultado palpável. No caso da construção civil,
por exemplo, a finalização da etapa das fundações tem como
resultado as próprias fundações, que podem ser testadas quanto
às características necessárias de resistência e dimensões.
Qualquer problema aí detectado pode ser resolvido

imediatamente, não sendo necessário aguardar até
o final da obra para perceber que os alicerces não
suportaram o peso da construção – seria um desastre!
Em projetos de software há a possibilidade de dividir

o sistema em pequenos módulos, de tal forma que,
cada um tenha características específicas, definidas
inicialmente e que, atingi-las é o objetivo a ser alcançado
no final da etapa. Quanto maior a divisão de etapas e,
desta forma, de objetivos intermediários, mais fácil será
detectar possíveis problemas e corrigi-los a tempo.
Um exemplo de divisão em etapas desse tipo, está

definida nos “pacotes diários” e nos “protótipos de
prova” do Microsoft Solutions Framework (MSF, 1998).
O objetivo é chegar no final de cada dia com um
protótipo testável. Esse protótipo é compilado e deve
funcionar. Só se passa para a etapa seguinte se o
pacote diário anterior alcançou o sucesso.
Outra alternativa é o uso de simuladores em projetos mais

complexos. Nesses casos, uma boa forma de testes prévios é o Veja sistemas e super-
uso de simulações computacionais que permitem uma visão do sistemas no modelo UCP,
produto, possibilitando fazer testes variados em um ambiente figura 2.10.
computacional.
Unidade 6 253

Um ótimo exemplo disso são os softwares de apoio

a projeto (CAD), que em mecânica e arquitetura
permitem visualizar e testar peças, máquinas e
ambientes. A detecção de falhas durante a simulação
permite enormes economias de tempo e dinheiro.
A validação do projeto é feita por etapas e por simulações, sendo

que no final de cada etapa, e mesmo durante cada uma delas,
um processo de revisão contínua é a melhor solução de qualidade
para a continuidade de um projeto de sucesso. Segundo Page-
Jones (1990) há várias revisões a serem feitas no decorrer do
projeto, visando a testes contínuos e validação a cada etapa.
Especificamente sobre projetos, as revisões e testes são:
revisão do escopo do projeto, que analisa constantemente
se o projeto está adequado às intenções e necessidades
dos usuários/clientes;
revisão de análise, que verifica se os problemas
anunciados no escopo estão sendo cuidados;
revisão do projeto, que verifica se preenche as
especificações, os padrões de qualidade e se tem
condições de ser implementado;
revisão da programação e do sistema, que verifica se os
resultados dos testes do protótipo estão adequados;
revisão da aceitação, que verifica se após os testes do
protótipo já é possível colocar o resultado do projeto em
produção;
revisão de produção, que verifica se o sistema de
produção está adequado e se há oportunidades de
melhoria no produto;
revisão dos aspectos técnicos do projeto;
revisão dos aspectos comerciais;
revisão pós-projeto, que busca aprender com os
resultados finais do projeto.
254

Simulações, revisões e testes são atividades do dia-a-dia do

projeto e, como visto, interferem inclusive no seu final e podem
se estender à produção, atividade que já não pertencerá ao escopo
do projeto em si, mas à rotina. Quando chegar este momento,
teremos o final do projeto, assunto da próxima unidade.
Síntese
Nesta unidade você viu como se dão os preparativos iniciais

do projeto e quais as atividades são importantes para que a
produção tenha início acompanhando o planejamento definido
previamente. O início do projeto define também o padrão 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 comparação entre as

características do gestor e as do líder. Em unidades anteriores
esse tema já havia sido iniciado, mas aqui foi aprofundado e
percebeu-se que a liderança é capaz de motivar a equipe, condição
essencial para que todos busquem um resultado comum, de forma
entusiasmada e ambicionando o sucesso coletivo. Com certeza
a figura do líder aqui definida não é a do sujeito carismático,
que conduz seguidores fanáticos, mas sim a do que é capaz
de criar ambientes de cooperação e de trabalho criativo. Para
isso, muitas vezes é necessário administrar conflitos, mostrar
caminhos produtivos e tomar decisões que definam rumos para o
projeto. Sem dúvida, uma das características fundamentais nessas
atividades é a de motivar e inspirar.
Por fim, tomando por base a necessidade de, durante a fase de

planejamento, segmentar o projeto em pequenas tarefas e etapas,
a fase de desenvolvimento pressupõe um conjunto de revisões 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
revisões e análises, e o exemplo de protótipos intermediários foi
apresentado como solução para busca de melhorias e conquistas
parciais, visando à obtenção do objetivo final do projeto por meio
de vários incrementos parciais bem-sucedidos.
Unidade 6 255

1) Dos quatro tipos de líderes definidos por Christenson (o que considera
os indivíduos, o que estimula intelectualmente, o que influencia os
ideais, e o que motiva inspirações), qual é, na sua opinião, o mais
importante? Justifique.
2) Como você descreve os quatro passos da decisão? Dê um exemplo

prático, a partir da sua experiência.
3) Descreva as principais fontes de conflito entre os indivíduos e as

instituições, dando exemplos de sua própria experiência.
256

4) Quais as formas de administrar um conflito, e qual delas melhor se

adapta ao seu estilo de gestão? Por que essa forma de atuar e não as
outras? Faça um comparativo e publique na “Exposição”.
5) Qual a importância do uso de simuladores no desenvolvimento de

projetos?
Unidade 6 257

Saiba mais
As reuniões geralmente são esperadas como atividades não muito

proveitosas. Isso acontece porque não existe uma boa preparação
para elas. Uma reunião bem preparada conduz a decisões
importantes e, geralmente, sucesso nas realizações. Veja no
link abaixo algumas sugestões e práticas para uma boa reunião,
no artigo intitulado “A boa geometria da reunião”, de Carlos
Cardoso Aveline.
http://www.terra.com.br/planetanaweb/flash/reconectando/
ambiente/334/reuniao.htm
O uso de simuladores pode ser importante para verificar

protótipos de produtos, antes mesmo de eles serem construídos.
No caso do desenvolvimento eletrônico, por exemplo, há um
interessante conjunto de simuladores, desenvolvidos com Java,
que podem ser vistos no endereço http://www.amanogawa.
com/index.html.
O exemplo é o seguinte: no projeto de uma antena o projetista

tem como variar as características do produto, e testar seus
resultados. Se for construir um circuito eletrônico, poderá fazer
simulações específicas. Você quer fazer um projeto de um novo
modelo de “pipa/papagaio/maranhão”? (cada região 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.
258

UNIDADE 7
Finalizando o projeto
7
Compreender aspectos relativos à finalização do
projeto, à dissolução das equipes e aos registros
documentais do trabalho.
Verificar que o sucesso do projeto ou o fracasso está

intimamente ligado, por um lado, às expectativas
do cliente e, por outro, à capacidade de liderança do
gestor.
Perceber que todo trabalho de projeto é uma fonte de

aprendizagem, mas para que o aprendizado ocorra é
necessário extrair lições e refletir sobre elas.
Verificar que um projeto pode ser a origem de muitos

outros, mas para isso os membros da equipe precisam
estar atentos às oportunidades.
Seções de estudo
Seção 1 Fase de finalização.
Seção 2 Planos de contingência em caso de problemas.
Seção 3 Atendendo as expectativas do cliente.
Seção 4 Sobre o sucesso (ou fracasso) do projeto.
Seção 5 Desfazendo a equipe.
Seção 6 Documentação.
Seção 7 Lições aprendidas.
Seção 8 Idéias para um novo projeto.


Esta é a unidade que encerra o livro e justamente trata do
encerramento do trabalho de projeto. As atividades de
encerramento do projeto são comentadas considerando aspectos
diversos como o processo de documentação dos trabalhos
que permitirão, por exemplo, gerar o trabalho de suporte ao
produto quando o mesmo entrar em ciclo de produção e venda
ou para implementar melhorias contínuas durante sua fase de
consolidação.
Trata também da dissolução da equipe e das análises finais,

quando então se verificará o grau de sucesso ou fracasso
alcançado 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 sensação
de missão cumprida estará no ar. Senão, será a frustração do
fracasso.
Porém, com o fracasso também se aprende muito e assim

precisamos tirar lições para aproveitar no desenvolvimento
dos novos projetos, pois esses, com certeza virão. E, por esse
motivo, a última seção mostra uma figura representativa de
oportunidades de novos projetos no ambiente atual de negócios.
Mas para ver tais oportunidades é preciso ter os olhos bem
abertos. Bom estudo!
260

SEÇÃO 1 – Fase de finalização

A finalização do projeto pode acontecer por dois motivos:
a) o resultado esperado está sendo atingido;
b) nada deu certo e é melhor finalizar antes que piore.
Bem, vamos primeiro considerar a opção “a”, deixando a opção

“b” para a próxima seção.
A avaliação de que o resultado está sendo atingido é obtida

por medições 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
medições em cada atividade. Atingir o grau satisfatório em cada
uma dessas medições, faz o projeto caminhar rumo ao objetivo
final que é o sucesso.
Uma das marcas principais do encerramento do projeto é a

data limite, ou prazo final. Muitas vezes, não teremos como
discutir contra uma data previamente estipulada, não haverá
prorrogações. Então, deveremos trabalhar tendo em vista tal
data. O controle quanto a isso se dará no preenchimento e na
atualização constante do Gráfico de Gantt (veja a unidade 4)
preenchendo as atividades “realizadas” e comparando com o
“previsto”. Da mesma forma avaliando a cada passo o “caminho
crítico” do projeto no diagrama PERT/CPM.
Fechado o projeto, será importante avaliar as estatísticas quanto

ao tempo gasto, recursos utilizados, os riscos previstos
que acontecerem e os que não aconteceram, se os custos
previstos foram suficientes, e todos os demais dados
que possam ajudar a compreender melhor a gestão dos
próximos projetos.
Encerrar o projeto não 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 documentação (obrigatoriamente)
gerada para que, com isso, a história do trabalho seja preservada,
permitindo a introdução do resultado do projeto num ciclo de
Unidade 7 261

vida de produção, bem como, permitir avançar em melhorias e

mesmo em novos projetos a partir das lições aprendidas. Será
também 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 verificou fracasso, uma libertação. Nas próximas seções
discutiremos com maior profundidade esses tópicos.
SEÇÃO 2 – Planos de contingência em

caso de problemas
Na seção anterior, falamos das duas possibilidades de opções,
“a” e “b” e já discutimos a primeira opção. Chegou a hora
de discutirmos sobre a segunda. Você já viu que, em muitos
filmes ou brincadeiras se diz que, caso as coisas saiam errado,
vamos ativar o plano “B”. Ora, esse plano “B” é o plano de
contingência.
O plano de contingência, infelizmente, não é uma “carta na

manga” que facilmente é lançada sobre a mesa, mudando todo o
jogo. Geralmente é um conjunto de ações, tomadas sob pressão,
geradoras de conflitos e de crises, pois o plano de contingência é
um plano de solução de crises. A percepção do erro geralmente
é postergada ao máximo e isso, muitas vezes, ocorre de forma
inconsciente dado que não gostamos de errar. Para isso temos as
ferramentas de planejamento, acompanhamento e controle do
projeto (vimos várias neste livro) que devem fazer parte de cada
momento de revisão para que possamos constatar se estamos de
acordo, ou não, com o planejado. Tais ferramentas apontam os
erros, basta fazer as marcações e ler os indicadores. E, tendo visto
os erros, não é certo trabalhar com desculpas, pois esse é outro
defeito do ser humano, aceitável apenas em algumas questões
sentimentais, mas não de trabalho.
Realizando as revisões e percebendo erros capazes de afetar

seriamente o projeto, um plano de contingência deve ser aplicado
imediatamente. Conforme o trabalho de Iacovou e Dexter
(2004), várias ações devem ser tomadas quando um projeto sai
dos trilhos rumo ao fracasso. Tais autores, apontam as seguintes
ações corretivas como tentativas de remediar a situação:
262

desenvolver um plano de recuperação;

redefinir e gerenciar o propósito do projeto, ou seja,
avaliar novamente o escopo do projeto e o que, de fato, se
quer atingir;
reavaliar o negócio e considerar o cancelamento do
projeto, quando de fato não há solução de continuidade
(deve haver um grande desprendimento para isso!);
replanejar o projeto usando métodos de estimativa
apropriados e comprovados;
gerenciar as expectativas dos clientes, pois estes
perceberão rapidamente que “as coisas não estão indo
bem”;
formular um plano de comunicação objetivo e
aberto, tanto para os membros da equipe quanto para
fornecedores e clientes – isso trará confiança;
dividir o restante do projeto em pequenas partes ou
atividades, o que facilitará o controle, a percepção
de objetivos menores e mais próximos, bem como a
capacidade de acreditar no sucesso;
tratar as dificuldades pessoais da equipe do projeto,
especialmente quando essa equipe se sentiu culpada pela
aproximação do insucesso;
incorporar práticas corretivas no processo de
desenvolvimento do restante do projeto;
por fim, reavaliar a liderança, verificando se essa
liderança é capaz de alinhar as diversas forças
componentes do projeto rumo ao seu objetivo.
O ponto principal de um plano de contingência, dessa

forma, é a tomada de decisão. Tomar decisões é a tarefa
dos líderes empenhados no sucesso. Por esse motivo,
ao perceber que um projeto não vai bem, é importante
verificar se o líder vai bem.
Unidade 7 263

SEÇÃO 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 ninguém atende, exatamente, as expectativas do
cliente. Provavelmente porque tais expectativas não são bem
conhecidas, nem mesmo pelos próprios clientes.
Quando um de nós diz: “vou comprar um quilo de açúcar”, é

muito fácil atender tal expectativa. No entanto, se dizemos:
“queria um software para gerenciar a venda em balcão”, a
expectativa é muito mais complexa do que está expressa nessa
simples frase. Não é fácil apreender do cliente como seria tal
software, o tempo de resposta, a interface, quanto está disposto
a gastar e muitas outras questões desse tipo. Não há uma
regra sobre como avaliar todos esses requisitos, mas uma série
de procedimentos foi apresentada na unidade 3, seção 2, que
discutiu sobre os requisitos do cliente. A análise aprofundada de
tais requisitos e a comunicação clara do que se entendeu como
escopo do problema, tanto para o cliente quanto para os membros
da equipe de projeto é condição básica para atender expectativas.
E refiro expectativas no plural por entender que há aquelas
específicas do cliente e aquelas da equipe e ambas devem ser
atendidas para que haja sucesso.
Além disso, não acredito em empresas que vivem alardeando

que “fazem tudo pelo cliente”. As empresas fazem antes, algo
por si mesmas, depois pelo cliente. E nisto não há um juízo de
certo ou errado, mas simplesmente o fato de que, para sobreviver,
a empresa precisa olhar para si mesma. Não se trata também de
ultrapassar limites de ética ou avançar em atitudes oportunistas,
mas sim, de ser realista quanto às finalidades de cada sujeito neste
jogo. A expectativa do cliente deve ser tratada como algo objetivo
e deve ficar claro para ambas as partes o que é possível realizar e
o que não é.
Chegar ao fim do projeto é, então, contemplar a expectativa

desse cliente, seja ele um contratante externo, uma demanda
da empresa ou um desejo de nós mesmos. Ao confrontar
tal contemplação, teremos uma medida do sucesso do nosso
trabalho.
264

SEÇÃO 4 – Sobre o sucesso (ou fracasso) do projeto

O projeto foi entregue no prazo, gastou menos do que o previsto,
o produto alcançou ou até mesmo superou as expectativas, os
benefícios mensuráveis pelo seu resultado são enormes...Temos,
então, um projeto de sucesso. A equipe será condecorada, haverá
prêmios para os responsáveis, a empresa passará a vender mais
ou conquistar um nicho que antes não detinha. Inovações serão
incorporadas pela indústria e pelo mercado e, dependendo do
grau, poderão até mesmo revolucionar um setor ou um hábito.
Vamos nos debruçar, porém, na situação inversa - o fracasso.

Todos queremos evitá-lo, contudo, mesmo quando o fracasso
for inevitável, precisamos aprender com ele para crescer. Não há
vitorioso que não tenha fracassado alguma vez. É preciso então
prevenir, mas como poderemos nos prevenir dos fracassos em
projetos?
Para Keeling (2002), existe fracasso em projetos quando:
objetivos não são alcançados no prazo;

custos vão além dos limites aceitáveis;
resultados são obtidos com nível de qualidade
comprometido.
Nesses três itens resumem-se os fatores que definem um projeto:

prazo, custos, recursos e benefícios. Se algum deles não for
contemplado, temos indícios de fracassos. No entanto, podemos
fazer uma análise mais sutil. Há casos de projetos que foram
concluídos com custo excessivo, muito além do orçamento
original e ainda acima do prazo estipulado. São exemplos desse
tipo: a Ópera de Sydney, na Austrália e o Eurotúnel, que liga
a Inglaterra à França. No entanto, quem ousaria hoje dizer
que são fracassos? Do ponto de vista dos custos e dos prazos, o
foram. Mas os benefícios aparentemente superam em muito essas
falhas. Esses são casos de projetos estratégicos e visionários que
são considerados no início como equivocados ou previamente
fracassados. Porém, com o passar do tempo se percebe o quanto
foram importantes para os desdobramentos futuros. Isso se deve à
visão poderosa, à intuição e à persistência de lideranças e não aos
cálculos e estudos de burocratas anônimos.
Unidade 7 265

Figura 7.1. Ópera de Sydney, na Austrália, projetada em 1957 pelo

dinamarquês Jorn Utzon, que hoje é Patrimônio Nacional da Austrália.
Atualmente, muitos projetos na área de software têm sido vítimas

da síndrome do fracasso. Por esse motivo, boa parte dos estudos
recente sobre gestão de projetos tem se voltado a analisar tais
casos, sendo que o interesse sobre os trabalhos do PMI (Project
Management Institute) é sintomático de uma realidade de
mercado. Nas palavras de Page-Jones (1990, p. 83), “embora todo
projeto de Processamento de Dados enfrente dificuldades técnicas, elas
não são a causa principal de fracassos. Os desastres verdadeiramente
impressionantes são devidos a gerenciamento inadequado ou inepto de
projetos.”
Esse autor destaca exatamente o ponto o qual estamos estudando:

os problemas relativos a projetos não estão nas questões técnicas
e tampouco em atrasos ou gastos, pois esses, via de regra, são
conseqüências de um problema maior: o fracasso da gestão.
Como evitar o fracasso da gestão? Conforme Keeling (2002),

pode-se evitar fracassos com:
melhor avaliação de viabilidade;

análise de riscos criteriosa;
uso de métodos de planejamento;
uso de sistemas de controle.
266

Porém, isso não é suficiente, apesar de necessário. Um grupo

de trabalho pode se reunir e fazer várias avaliações, considerar
inúmeros riscos e gerar grandes relatórios, preencher planilhas
e usar softwares de planejamento de projetos. Mas tudo isso é
inócuo se não houver o poder da decisão e o poder da decisão
é uma atividade humana. Com isso quero dizer que é preciso
ter liderança para que um projeto aspire ao sucesso. Para
encerrar esta seção, veja o caso do projeto de construção de uma
embarcação de guerra, no século XVII. Esse é um caso clássico
de fracasso, motivo de estudos e pesquisas dos interessados em
administração.
Figura 7.2. Representação em escala reduzida,

Museu do VASA (Fairley e Willshire, 2003).
Unidade 7 267

Estudo de Caso
VASA – um projeto fracassado do século XVII

O caso da embarcação “Vasa” foi apresentado no artigo de Kessler
et al. (2004), do qual retirei a seguinte história: No começo do século
XVII a Suécia estava engajada numa série de batalhas navais contra
a Dinamarca, Rússia e Polônia. Em 1625, dez embarcações de guerra
suecas foram abatidas quando estavam patrulhando a Baía de Riga.
Por esse motivo foram aceleradas as atividades de construção 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 Suécia Gustavus Adolphus ordenou
alterações na especificação do navio para introduzir um segundo
nível de canhões, mais canhões do que originalmente planejado.
Com tais modificações, o Vasa excedeu, em muito, o que poderia
ser suportado pelo lastro original. Além disso, o mestre construtor
Henrik Hybertson faleceu, o que deixou a construção nas mãos de
um gerente inexperiente e mais fraco nas decisões e controle dos
operários.
No verão de 1628 um teste de estabilidade foi conduzido pelo
Almirante Klas Fleming e pelo Capitão Sofring Hansson. Trinta
homens correram de um lado ao outro do navio. Depois da
terceira corrida o navio inclinava tão violentamente que o teste
foi interrompido. No entanto Fleming decidiu não postergar o
lançamento do navio, alegando que o mestre construtor já tinha
feito navios antes e não havia com o que se preocupar. Menos de
um mês depois, em 10 de agosto de 1968, o Vasa foi levado ao mar.
Para mostrar o poder dos armamentos da embarcação, o Capitão
Hansson velejou com as portas dos canhões abertas, o que não
era usual. Depois de navegar pouco mais de mil metros em mar
calmo, o Vasa entornou e naufragou, levando consigo cinqüenta
marinheiros para o fundo do porto de Estocolmo. Era uma
embarcação magnífica, que tinha custado cerca de 5% do tesouro
sueco, com 64 canhões pesados e para 300 marinheiros. Feito
para simbolizar a força e a beleza da Suécia e para meter medo no
coração dos seus inimigos.
Muitas discussões foram realizadas para descobrir os culpados
pelo desastre, mas ninguém foi formalmente acusado. O rei foi
parcialmente culpado por ter demandas pouco realistas, Hybertson
pelo desenho medíocre do projeto, Fleming por não ter dado
atenção aos testes realizados e Hansson pela inabilidade no
comando da embarcação.
268

Os erros, porém, foram bem mais graves do que esses.

Analisando alguns, podemos considerar os seguintes
detalhes:
1. Os construtores tentaram imitar o projeto da embarcação
dinamarquesa Sancta Sophia, no entanto não tinham
conhecimento técnico nem capacidade de desenvolver
procedimentos construtivos para tanto.
2. Ênfase na elegância e no poder de fogo e pouca
importância à estabilidade e navegabilidade.
3. Excesso de pressa na construção do barco e pouca
atenção à sua qualidade, especialmente se considerar a
sua dimensão e a quantidade de novas tecnologias que
estavam incorporadas o que atribuía ao projeto uma série
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 contrário.
5. Três diferentes pessoas fizeram especificações e definições
para o projeto de forma independente, modificando o
conjunto (o Rei, Hybertson e o último mestre).
6. O projetista principal, Hybertson, faleceu um ano antes
de o navio ser concluído e não deixou documentação ou
memória, ou seja, não houve transferência tecnológica.
7. O rei não tinha conhecimentos técnicos para resolver o
problema proposto, e mesmo assim interferiu no projeto
como seu chefe supremo.
Devido a esse conjunto de fatores, verifica-se o exemplar
fracasso.
Figura 7.3. Representação da embarcação ao afundar,

Museu do VASA (Fairley e Willshire, 2003).
Unidade 7 269

SEÇÃO 5 – Desfazendo a equipe

Equipes de projeto podem criar afinidades de tal monta que,
desfazê-las, não é tarefa fácil. Permanecem as afinidades e o
entusiasmo, especialmente se houve sucesso. O encerramento das
atividades deve passar por uma avaliação de finalização. Uma
discussão franca sobre erros e acertos, principalmente no que se
refere ao modelo de gestão adotado, bem como o dia-a-dia da
equipe, trará benefícios e crescimento a todos.
Reconhecer os méritos: eis uma obrigação.
Há muitos casos de projetistas que empenham horas de esforço

e imaginação num projeto e sabemos todos que não são apenas
aquelas horas que estão lá escritas na planilha. Essas horas são
doações espontâneas daqueles que gostam de desafios e almejam
sempre a qualidade e a realização. O reconhecimento disso deve
ser manifestado claramente e quando houver oportunidade e
condições, deve ser premiado.
Receber um prêmio, mesmo que seja uma simples palavra de

agradecimento sincero, é algo honroso. Conheço gestores que
não sabem premiar e que consideram que realizar o trabalho é
a obrigação de cada um. Desejo a esses a sorte que se deseja aos
ratos de esgoto.
SEÇÃO 6 – Documentação
Documentação é um ponto falho em quase todos os projetos.
Quando Joãozinho e Mariazinha entraram pelo caminho
desconhecido na floresta, 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 floresta, eram
pedaços de miolo de pão, os pássaros comeram sua marcação e
eles se perderam. Essa documentação era efêmera. A memória é
uma documentação efêmera.
270

A documentação não é adequada se não for clara, estiver

arquivada, acessível e possível de ser entendida por outros. Vimos,
desde a primeira unidade, que o planejamento está baseado em
análises, avaliações, relatórios, depois planilhas e diagramas.
Muitos desses documentos serão usados ao longo do projeto
para revisões, bem como serão realizadas reuniões que deverão
gerar atas e assim por diante. Além disso, o trabalho técnico será
baseado em desenhos, rascunhos, anotações, resultados de testes
e muitos outros documentos de variados tipos. É uma obrigação
dos responsáveis de cada etapa do projeto e do gestor, organizar,
arquivar e preservar a documentação do projeto a qual deve ser
parte do resultado final do trabalho.
Nenhum projeto poderá ser considerado encerrado se a

documentação não estiver adequadamente preservada e
organizada.
SEÇÃO 7 – Lições aprendidas

Cada projeto é uma oportunidade de aprendizagem e,
geralmente, aprendemos com os erros. A constante revisão
do projeto, em cada uma das suas etapas, será um exercício
de análise e, para isso, contamos com diversos instrumentos
como, relatórios preenchidos lá no começo e que devem
ser analisados em comparação com o realizado, passo a
passo. Muitas críticas e idéias surgirão nesses momentos e é
importante avançar sobre isso. Como dito na seção anterior,
a documentação gerada será uma fonte de recursos de
aprendizado.
A leitura do caso “Vasa” também é 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 própria experiência, uma
fonte rica de aprendizagem. Vamos considerar novamente o
caso “Vasa” e comparar com projetos na área de software. Foi
exatamente isso que fizeram Fairley e Willshire (2003) em
seu artigo sobre problemas em projetos de software, buscando
antídotos para tais problemas numa série de sugestões, cujas
Unidade 7 271

principais estão apresentadas no quadro 7.1. Aparentemente um

projeto de embarcação nada tem a ver com o desenvolvimento
de software, mas não é bem isso que nos sugere esse conjunto de
“problemas e seus antídotos”.
Quadro 7.1. Problemas em projetos de software e seus antídotos, adaptado de (Fairley &
Willshire, 2003).
PROBLEMA ANTÍDOTOS
· Estimativas objetivas de prazo
Pressão excessiva de prazos · Mais e melhores recursos
· Priorizações
· Desenvolvimento interativo
Mudanças no escopo e nas necessidades
· Modificar gestão de controle e planejamento
· Desenvolvimento de especificações prévias
Falta de especificações técnicas · Atualização das especificações com base em eventos
· Indicação de um arquiteto de software
· Desenvolvimento de planejamento prévio

Falta de documentação de planejamento · Atualizações periódicas e baseadas em eventos
· Indicação de um gestor de projetos
· Maior controle sobre a linha de trabalho

Inovações excessivas ou secundárias · Análise de impactos
· Gestão contínua dos riscos
· Uso de protótipos
Falta de métodos científicos · Desenvolvimento incremental
· Uso de métricas de medição da performance técnica
Ignorando o óbvio · Assimilar as lições aprendidas anteriormente

· Cultura de trabalho baseada em ética
Comportamento antiético nos relacionamentos
· Uso e aderência a códigos de ética formais
272

Vendo o quadro 7.1 percebemos que as lições tiradas do episódio

são muitas e algumas das mais importantes dizem respeito ao uso
de métricas de performance, ao desenvolvimento incremental,
à divisão 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:
Não se deve imitar projetos sem o suficiente

conhecimento técnico;
Buscar concisão e usabilidade;
Não se submeter à pressa e dar atenção especial à
qualidade;
Realização constante e contínua de testes, durante todas
as etapas;
Reduzir os cargos de responsabilidade, para evitar o
“empurra-empurra” da decisão;
Gerar documentação sempre e não apenas no final;
Aqueles que não têm conhecimento técnico não devem
interferir em assuntos que não são de sua competência.
Se retornarmos à unidade 1 deste livro, veremos como os

projetos foram se modificando no decorrer do tempo e as lições
aprendidas foram sendo incorporadas pouco a pouco. No início
houve desperdício imenso de recursos financeiros e mesmo de
vidas humanas. Um esforço enorme de melhoria se deu na época
da revolução industrial e, logo depois, chegando ao começo do
século XX com teorias e ferramentas específicas. Hoje temos um
número muito maior de ferramentas, sistemas computacionais
especiais e disputas teóricas em revistas especializadas. Porém, ao
mesmo tempo, os resultados não são tão animadores, como você
pode conferir no quadro 1.2. Então, vamos trabalhar firmemente
para não colocarmos nossos próprios projetos naquela estatística.
Unidade 7 273

SEÇÃO 8 – Idéias para um novo projeto

Na seção anterior discorremos sobre aprendizagem e sobre o
processo de tirar lições dos casos de insucessos, das dificuldades
e soluções que vamos encontrando no decorrer do trabalho de
desenvolvimento do projeto. Porém, acredito que tais lições só são
percebidas e aprendidas por pessoas e equipes especiais, cheias
de idéias e criatividade. Acabar um projeto, geralmente serve de
pretexto para dar origem a um novo projeto, pois todas as idéias
que foram surgindo no meio do caminho são sementes para novos
trabalhos. Empresas buscam pessoas assim, para que sobrevivam
no mercado criando oportunidades de novos negócios.
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 criação e o lançamento de um produto
totalmente novo. Anotações feitas durante o trajeto de
desenvolvimento serão geradoras de oportunidades em ambos
os sentidos. Por um lado, vários apontamentos dirão da
necessidade de acrescentar melhorias incrementais, as quais não
caberiam no decorrer do projeto, pois atrasariam o trabalho
ou determinariam custos impossíveis de cumprir. Por outro
lado, idéias completamente novas poderão surgir, apontando
para soluções radicalmente diferentes. Um exemplo? A criação
do Compact Disc foi uma solução totalmente diferente para o
problema da gravação em fitas magnéticas.
É importante, também, perceber que o fracasso de um projeto

não é, necessariamente, o encerramento das oportunidades.
Fracassos ou graves problemas de um projeto chamam a atenção
para novas oportunidades de desenvolvimento. Contudo, para
renascer é preciso ter o espírito e a convicção dos líderes.
Por fim, gostaria de encerrar chamando a atenção para a

estrutura de negócios da figura 7.3, com uma representação em
três dimensões onde os eixos definem diferentes atuações no
interior da empresa ou organização. Este desenho está pleno de
idéias para novos projetos. Vamos ver mais de perto.
274

Administração
Suporte
Gestão dos
Processos de
Negócio
Processos de
Suporte a
Produto
Fornecedores Gestão dos Clientes

Processos
Processos Processos de Venda
de Compra
Operacionais
Processos de
Desenvolvimento Processos de
Chão-de-Fábrica
Projeto de
produto
Produção
Figura 7.4. Processos em um ambiente de negócios. Adaptado de Greeff (2005).

ERP: iniciais de Enterprise
Resource Planning, que
O eixo horizontal conecta a cadeia de fornecimento a de representa o sistema
relacionamento com o cliente, o vertical estabelece a ligação entre computacional integrado
para gestão empresarial,
a produção e a administração do negócio e o diagonal apresenta o
composto de módulos
desenvolvimento do produto e o suporte a ele durante seu ciclo de diversos como os de
vida. Se estivermos presos apenas à área de desenvolvimento de ‘contabilidade, finanças,
novos produtos, estaremos condicionados a um pequeno terreno recursos humanos,
de idéias de novos projetos. Mas hoje o essencial está nas ligações compras, orçamentos,
estoques’, entre outros,
entre o maior conjunto possível de eixos e a isso poderíamos
facilitando o fluxo de
chamar de gestão dos processos. Projetos podem surgir para informações entre
interligar o processo de produção no chão-de-fábrica ao os departamentos
ambiente administrativo, por exemplo, e é o que está começando da empresa visando
a acontecer, neste exato momento, com a interligação entre a a otimização do seu
planejamento.
automação industrial e o ERP das companhias. Iguais a essa,
inúmeras oportunidades estão à nossa frente. Ou seja, é a hora de
começar um novo projeto. Boa sorte!
Unidade 7 275

Síntese
Nesta unidade você estudou sobre a importância de uma análise

criteriosa de todos os passos dados durante o projeto e que tais
passos precisam ser cuidadosamente documentados. Com isso
será possível 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 também gerar novas idéias de
projetos.
Outra questão importante refere-se ao reconhecimento dos

membros da equipe como os verdadeiros responsáveis pelas
conquistas obtidas. Evidenciar tais méritos é uma obrigação
pois, a partir do momento que o projeto se encerra, as pessoas
se voltarão para outros trabalhos e funções, porém se lembrarão
desses momentos de desafio e sentirão satisfação por saber que
foram reconhecidas.
Haverá os casos de fracassos, não estaremos livres disso. Esses

casos devem ser analisados com ainda maior rigor, permitindo
nosso crescimento pessoal e também a propagação da experiência
para todos os interessados. Vimos que casos famosos de fracassos
são um bom objeto de estudo e, também, que há vezes onde um
suposto fracasso se revelou como sendo um empreendimento de
sucesso ao longo do tempo. Também esses são casos importantes
de pesquisa e análise, especialmente por considerar que foram,
geralmente, conduzidos por líderes obstinados e capazes de
inspirar e motivar suas equipes a despeito dos fatores negativos
momentâneos.
Oportunidades de novos projetos estão à nossa disposição. A

última seção fala justamente disso e, de certa forma, nos liga
ao início deste livro que discute a origem dos projetos. Que seja
aqui, então, o ponto de ligação para o eterno recomeçar, seja dos
estudos, seja dos projetos, seja dos novos empreendimentos de
sucesso. Até mais!
276

1) Quais são os passos para implantar um plano de recuperação, em um
projeto em crise? Exemplifique com projetos de sua experiência.
2) Que grandes dificuldades existem no atendimento das expectativas do

cliente?
3) Como se pode prevenir um projeto do fracasso? Que atitudes podemos

tomar nesse sentido?
4) Quais lições você tira do fracasso do projeto VASA para seus próprios
projetos?
Unidade 7 277

5) Considere seu próprio campo de trabalho e sua experiência

profissional, e analise a figura abaixo. Que nova idéia de projeto,
concreta e exeqüível, você pode sugerir?
Administração
Suporte
Gestão dos
Processos de
Negócio
Processos de
Suporte a
Produto
Fornecedores Gestão dos Clientes

Processos
Processos Processos de Venda
de Compra
Operacionais
Processos de
Desenvolvimento Processos de
Chão-de-Fábrica
Projeto de
produto
Produção
278

Saiba mais
Visite o site http://www.arcweb.com/ e veja inúmeros estudos e

oportunidades de novos projetos na área empresarial e industrial.
Veja também estudos de casos e análises de mercado.
O IEEE – Institute of Electric and Electronic Engineers – mantém

uma Sociedade voltada à gestão de engenharia e projetos,
de âmbito mundial. É a IEEE Engineering Management
Society. Visite o site http://www.ewh.ieee.org/soc/ems/ e veja
inúmeras oportunidades de trabalho, estudo, artigos, revistas etc.
Estudantes de graduação, de qualquer área, podem se associar
com valores de taxas anuais especiais.
Unidade 7 279

Para concluir o estudo
Chego ao final deste trabalho e espero ter cumprido boa

parte das suas intenções! Quem dirá isso será você, leitor
e estudante. Pois também sou um estudante deste tema,
que muito me interessa e sempre me desafia. Ao longo
do tempo fui reunindo informações teóricas e, ao mesmo
tempo, agindo em diferentes projetos, alguns de sucesso,
outros nem tanto. Tentei colocar o máximo desses
conhecimentos e experiências aqui, e simultaneamente
comparar e refletir sobre novas tendências neste campo.
Apresentei algumas técnicas e modelo de apoio,

seja nas análises iniciais ou para o planejamento,
acompanhamento e controle do projeto até seu final,
sabendo, no entanto, que tais técnicas e modelos vão
sendo alterados com o tempo e com o desenvolvimento
das tecnologias de gestão. Dessa forma, o foco principal
não foi em tais modelos, mas sim no seu uso como
ferramentas de auxílio numa visão ampla do processo
de trabalho envolvido em projetos, sejam eles de que
tamanho forem. Assim, atenção foi dada essencialmente
na aprendizagem e na discussão que gera conhecimento.
Por esse motivo, acredito que tenha acompanhado ao
lado do cunho acadêmico de um livro de graduação,
também uma abordagem direcionada às aplicações
práticas e ao nível estratégico, fundamentais para o
progresso do nosso dia-a-dia.
Também é importante frisar que este livro seja uma

introdução ao tema da gestão de projetos e das equipes
que os compõem, sendo que inúmeros 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 nós mesmos devemos contribuir no debate.

Por fim, gostaria de frisar a importância da liderança em

projetos, tema tantas vezes abordado aqui. A gestão que
desenvolve os aspectos da liderança 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
282

Referências
BAZZO, Walter Antônio, PEREIRA, Luiz Teixeira do Vale.

Introdução à Engenharia, 5.ed. Florianópolis, 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,
História Viva, edição 13, novembro de 2004. http://www2.uol.
com.br/historiaviva/home.html (acessado em 18/02/2005)
COVEY, Stephen. O 8º. Hábito: da eficácia à 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. Especificação e solução de problemas de
engenharia. (Apostila) curso de Especialização “Automação
e Computação Industrial”, fevereiro de 2004, CTAI/Senai/SC,
Florianópolis.
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 (disponível em http://
computer.org/software )
FERNANDES, Jorge Monteiro. Gestão da Tecnologia como parte
da estratégia competitiva das empresas. Brasília: IPDE, 2003.
275 p.
GOOCH, Tom. Object Oriented Analysis and Design Team.
Kennesaw State University, 2000. (disponível em http://pigseye.
kennesaw.edu/~dbraun/csis4650/A&D/index.htm, acessado em
24/04/2005).

GREEFF, Gerhard. Staying in sync. ISA Intech/Industrial Computing, vol 52,

no. 6, June 2005. pp. 51-55. (www.isa.org/intech)
HINOJOSA, María Alejandra. DIAGRAMA DE GANTT. 2003. Disponível em
www.gestiopolis.com, acessado em 24/04/2005.
HOUAISS, Antônio. Dicionário Houaiss da Língua Portuguesa. Editora
Objetiva / Instituto Antônio 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. Gestão 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. Disponível 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 prático para
restauração da qualidade em projetos e sistemas de processamento de
dados. São 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. edição, 388 pp.
PRADO, Darci Santos do. PERT/COM – Série Gerência 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.
SÁENZ, Tirso W., CAPOTE, Emilio G. Ciência, Inovação e Gestão
Tecnológica, IEL/SENAI, Brasília, 2002.
SISK, Toney. The History of Project Management. http://officeupdate.
microsoft.com/downloadDetails/projhistory.htm (acessado em
20/02/2005).
VALERIANO, Dalton L. Gerência em projetos – pesquisa, desenvolvimento
e engenharia. São Paulo: Makron Books, 1998. 438 pp.
284

Sobre o professor conteudista
Mauro Faccioni Filho nasceu em Maringá, PR, em 29

de outubro de 1962. Formou-se em Engenharia Elétrica
pela Universidade Federal de Santa Catarina (UFSC)
no começo do ano de 1985, e nesse mesmo ano fundou
a empresa Creare Engenharia, junto com dois colegas
da universidade. Posteriormente concluiu, também
na UFSC, Mestrado (1997) e Doutorado (2001) em
Engenharia Elétrica, com estudos sobre representações
tridimensionais e modelagem numérica computacional.
Nos anos 2002 a 2004 atuou como diretor do Centro de

Tecnologia em Automação e Informática – CTAI, em
Florianópolis, tendo participado na criação de cursos
superiores e de pré-incubadora empresarial tecnológica,
além de ter editado revista técnica em automação e
informática.
Desde 2002 na UNISUL, como professor, participou do

desenvolvimento em 2004 do projeto do Curso Superior
de Tecnologia em Web Design e Programação, do qual é
atualmente coordenador e onde atua também como tutor.
Com vários artigos técnicos e científicos publicados,

lançou ainda três livros de poemas. Seu currículo
completo está disponível para consulta on-line no banco
de dados do CNPq, no endereço http://buscatextual.
cnpq.br/buscatextual/index.jsp.

Respostas e comentários das
atividades de auto-avaliação
Unidade 1
1) O exemplo descrito deve claramente identificar um objetivo e

um prazo determinado de execução.
2) Durante a revolução industrial há maior interesse em

desenvolver métodos de gerência, para evitar gastos
desnecessários, perdas de tempos, atrasos, etc. Um cientista
da administração surge nessa época e começa 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 ciência da administração (SISK,
2004).
3) Na prática não houve mudanças, e os índices são muito

próximos e até piores, apesar da implementação de variadas
técnicas para controle de produção introduzidas durante o
século XX. Isso indica que as empresas não estão utilizando
tais técnicas, e continuam realizando seus trabalhos sem
gerenciamento.
4) A construção das grandes pirâmidades, onde:

• O prazo era o enterro do faraó, mas isso era indeterminado;
• Objetivo estabelecido: sim, a morada do faraó após a
morte;
• Custos planejados: não, o investimento não importava
nesse caso;
• Recursos previamente alocados: não, recursos humanos e
materiais eram usados conforme a demanda da obra.

5)
Exemplo de tarefa de
Área Exemplo de projeto rotina ou atividade
contínua
Concessionária de Projeto de nova hidrelétrica Operação da hidrelétrica
energia elétrica
Software Nova plataforma de e-commerce Manutenção de aplicativo
Indústria Desenho de novo lançamento Linha de montagem
Automobilística
Criar nova linha de
Bancos financiamento e lançar Operar carteiras de crédito
no mercado
Desenvolver sistema de
Governo Emissão de títulos eleitorais
eleição eletrônica
Unidade 2
1)
• Necessidade: um sistema de marcação do tempo que fosse portátil;
• conhecimentos: tecnologia mecânica dominada;
• idéias: relógio de pulso, de bolso;
• seleção: de pulso;
• desenvolvimento: artesãos suíços;
• uso de difusão: relógios de quartzo, com ponteiros e com visor
digital, etc.
2) A ciência e a tecnologia são instituições sociais, mas enquanto a ciência

tem como finalidade a geração do conhecimento, a tecnologia é a
aplicação de tais conhecimentos. Enquanto os conhecimentos sobre
eletromagnetismo e microonda são científicos, os conhecimentos sobre
rádios e telefones celulares são tecnológicos, por exemplo.
3) Um caso importante é o telégrafo sendo substituído pelo telefone.
Outro caso é a televisão substituindo o cinema, porém houve também
288

uma mudança de hábitos que fez retornar o cinema. O uso da telefonia

sobre IP (VoIP) certamente encerrará a geração dos telefones fixos
atuais. Os sistemas digitais de fixação de imagens encerraram a carreira
das câmeras fotográficas tradicionais.
4)
Complexidade
Super-sistemas CARRO 4x4
Sistemas
CASA SOFTWARE
Montagem Incerteza
Tecnologia
Unidade 3
1) Visão restrita: instalar um software de controle de estoque, que

relaciona os produtos em prateleira e dá a baixa a partir da emissão
da nota fiscal de venda, com controle feito por um “responsável” pelo
estoque;
Visão ampla: sistema integrado que verifica o estoque durante o
processo de emissão de propostas, que deve ser atualizada a cada
modificação solicitada pelo cliente, sendo que quando este dá o aceite,
imediatamente o estoque recebe o aviso da baixa e a reposição é
requisitada automaticamente.
2)
• Listar as informações que estão no enunciado, na tentativa de
detalhar o melhor possível suas partes;
• descrever todos os efeitos conhecidos do produto, quando for o
caso, e enumerar todas as possíveis causas;
289

• listar o que deve ser determinado pela solução, ou seja, definir com a
maior clareza possível o que está sendo buscado;
• criar modelos e esquemas de representação, permitindo uma melhor
visualização do conjunto;
• desenvolver desenhos esquemáticos, diagramas e fluxogramas;
• verificar as leis físicas associadas e também outros impeditivos e
limitantes, tais como questões jurídicas, restrições técnicas, restrições
ambientais, etc;
• usar simuladores como ferramentas de apoio.
3) O algoritmo permite modelar o planejamento do projeto de maneira

que você entenda e defina todos os passos que devem ser seguidos na
execução do projeto, para que o mesmo chegue ao resultado esperado.
4) O projeto deve passar por revisões em todas as suas etapas, para

verificar se as atividades intermediárias foram atendidas. Rever o
projeto durante o seu andamento significa reavaliar constantemente
o planejamento, bem como redefinir os objetivos quando necessário.
Revisão seja feita apenas no final do projeto, pode acarretar no fracasso
total, ou em perdas irreversíveis, ou atrasos extraordinários.
5) A partir de um certo prazo o projeto perde o sentido. Isso não

significa apenas que ele dá prejuízo, mas simplesmente não há mais
possibilidade de se obter sucesso, como por exemplo no lançamento
de um produto específico para uma data, ou quando há uma
concorrência, ou devido a um fenômeno natural, etc.
6) Os fatores são recursos, custos, benefícios e prazo.
7) Porque projetos são trabalhos que envolvem variáveis 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 é difícil manter todas as previsões.
290

Unidade 4
1)
Programa Qualidade Prazos estimados pela

equipe de implantação
A - reuniões do grupo do projeto para definir o programa 1 semana, 7 dias
B - redação do programa de qualidade 2 semanas, 14 dias
C - treinamento do pessoal do setor administrativo 3 dias
D - implantação do programa de qualidade no setor Administrativo; 2 semanas, 14 dias
E - treinamento do pessoal do setor de produção 3 dias
F - implantação do programa no setor de produção; 2 semanas, 14 dias
G - avaliação dos resultados e conclusão 3 dias
2)
3)
291

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 disponíveis dentro de tal folga, sem afetar o
andamento geral do projeto.
Unidade 5
1) As quatro fases são “Formação, Turbulência, Normalização e
Desempenho”. Geralmente a mais problemática é a segunda fase, pois
há a formação de sub-grupos de poder, as chamadas “panelinhas”, que
podem fazer a equipe dispersar suas energias.
2) A matriz ajuda a definir as necessidades de um projeto, e alinhar aos

recursos humanos disponíveis para o trabalho. Não havendo recursos
humanos na empresa ou grupo, pode-se buscar por recrutamento
externo. Da mesma forma a matriz ajuda a definir os investimentos
financeiros do projeto, pois é possível definir os gastos com equipe, de
acordo com os custos de hora-homem dos membros escolhidos.
3) Geralmente a estrutura exclusiva, com um organograma bem definido,

é o que melhor se adapta nessas condições. Nesse modelo os membros
do projeto são 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 vários projetos simultaneamente, com equipes
alterando conforme o cronograma e o setor/atividade.
292

5) Na estrutura do tipo horizontal, pois os membros da equipe se

reconhecem como pares, mesmo quando os domínios e os interesses
técnicos são muito diferentes. Esse tipo de estrutura é tipicamente
multidisciplinar, com grande número de idéias e soluções criativas, o
que favorece desenvolvimento de aplicativos de software.
6) Resposta subjetiva. Comentários sobre produtividade, sobre riscos de
atraso, sobre falta de qualidade, sobre diferenças culturais afetando os
resultados, sobre queda de preços.
Unidade 6
1) Resposta subjetiva. O que considera os indivíduos tem o perfil de
“humano”, o intelectual é o que lança desafios, o que influencia ideais e
inspirações é o motivador das pessoas.
2) Os quatros passos são: (1) identificar possíveis modos de ação, (2)

verificar vantagens e desvantagens; (3) discutir e avaliar; (4) escolher o
modo de ação mais vantajoso, e partir para ele.
3) Resposta subjetiva baseada no seguinte quadro:
Diferenças
Indivíduo / profissional Organização / gerência
Busca a inovação tecnológica Busca o lucro
Quer autonomia de ação Quer integrar os profissionais na organização
Quer livrar-se de regras e procedimentos Estabelece as regras e procedimentos
Quer autoridade baseada em mérito Autoridade baseada em hierarquia
Quer ser recompensado com base em seu desempenho Recompensa conforme o interesse da organização
Quer ampla comunicação entre pares Bloqueia a comunicação interna
Busca otimização do próprio trabalho Busca cumprimento de cronogramas e custos
4) As formas apresentadas são: por confronto, por comprometimento,

por acomodação, por prevalência, por retirada.
293

5) O uso de simuladores pode ser importante para verificar protótipos

de produtos, antes mesmo de eles serem construídos. Os simuladores
passaram a ser ainda mais importantes com o avanço da informática,
que permitiu o uso de simulação computacional, que poupa tempo e
dinheiro, especialmente em projetos de produtos complexos ou muito
grandes, como máquinas, grandes hidrelétricas, grandes construções etc.
Unidade 7
1) Os passos são:
desenvolver um plano de recuperação;

redefinir e gerenciar o propósito do projeto;
reavaliar o negócio;
replanejar o projeto usando métodos de estimativa;
gerenciar as expectativas dos clientes;
formular um plano de comunicação;
dividir o restante do projeto em pequenas partes;
tratar as dificuldades pessoais da equipe do projeto;
incorporar práticas corretivas;
reavaliar a liderança
(Os exemplos serão individuais).
2) Erros de comunicação no início do projeto causam frustrações na fase

final. Os clientes têm dificuldades para definir seus requisitos, e muitas
vezes têm expectativas exageradas.
294

3) Pode-se evitar fracassos tomando as seguintes atitudes:
avaliando detalhadamente a viabilidade do projeto antes de começá-lo;

fazendo uma análise de riscos criteriosa;
usando métodos de planejamento;
usando sistemas de controle durante a fase de desenvolvimento.
4) Resposta subjetiva. Poderá haver citações sobre o descontrole, sobre a

falta de liderança, sobre as interrupções constantes feitas pela lei, sobre
a falta de conhecimento técnico apropriado, sobre o planejamento
fraco, sobre a falta de documentação.
5) Resposta subjetiva, individual.
295


Gestao de Projetos e Equipes - Livro - Completo

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Gestao de Projetos e Equipes - Livro - Completo

Uploaded by

Copyright:

Available Formats

Universidade do Sul de Santa Catarina

Gestão de Projetos e de Equipes

3ª edição revista e atualizada

gestao_de_projetos_e_de_equipes.indb 1 28/5/2007 15:27:26

Este livro didático corresponde à disciplina de Gestão de Projetos

O material foi elaborado visando a uma aprendizagem autônoma,

Bom estudo e sucesso!

gestao_de_projetos_e_de_equipes.indb 3 28/5/2007 15:28:26

Gestão de Projetos e de Equipes

3ª edição revista e atualizada

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

1. Administração de projetos. I. Will, Daniela Erani Monteiro. II. Matuzawa,

Ficha catalográfica elaborada pela Biblioteca Universitária da Unisul

gestao_de_projetos_e_de_equipes.indb 6 28/5/2007 15:28:26

UNIDADE 1 – Introdução à gestão de projetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

UNIDADE 2 – Nascimento do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45

UNIDADE 3 – Visão geral do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83

UNIDADE 4 – Planejamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

UNIDADE 5 – Estruturando a equipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

gestao_de_projetos_e_de_equipes.indb 7 28/5/2007 15:28:26

UNIDADE 7 – Finalizando o projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

Para concluir o estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281

gestao_de_projetos_e_de_equipes.indb 8 28/5/2007 15:28:26

Os livros dedicados à gestão de projetos dividem-se

Os do primeiro tipo acreditam que simplesmente

Os do segundo tipo analisam a gestão como uma

Este livro didático explora esse assunto de uma outra

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

Com essas palavras iniciais gostaria então de convidá-lo a

Professor Mauro Faccioni Filho.

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

O plano de estudos visa a orientá-lo/a no desenvolvimento da

O processo de ensino e aprendizagem na UnisulVirtual leva

São elementos desse processo:

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

Unidade 1: Introdução à gestão de projetos

Unidade 2: Nascimento do projeto

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

Unidade 3: Visão geral do projeto

Unidade 5: Estruturando a equipe

Unidade 6: Executando o projeto

Unidade 7: Finalizando o projeto

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

Agenda de atividades/ Cronograma

Não perca os prazos das atividades. Registre no espaço

Use o quadro para agendar e programar as atividades

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

Demais atividades (registro pessoal)

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

Introdução à gestão de projetos

Verificar um breve histórico dos projetos e de sua gestão.

Analisar a evolução da gestão de projetos e de equipes

Conhecer os principais conceitos sobre projetos, equipes

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

Para início de conversa

Esta unidade apresenta em sua primeira seção um breve

Na segunda seção são enfocados os principais conceitos da

Pretendo que este trabalho sirva de estímulo ao desenvolvimento

Bom estudo, bom planejamento e boa sorte!

SEÇÃO 1 – História e evolução da gestão de projetos

A palavra projeto é muito comum e está presente nos

Mas antes de começar a discutir o conceito de projeto, e acima

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