gestao de projetos e equipes_livro_completo

Universidade do Sul de Santa Catarina

Palhoça

UnisulVirtual

2006

Gestão de Projetos e de Equipes

Disciplina na modalidade a distância

3ª edição revista e atualizada

gestao_de_projetos_e_de_equipes.indb 1gestao_de_projetos_e_de_equipes.indb 1 28/5/2007 15:27:2628/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 signifi ca 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

Palhoça

UnisulVirtual

2006

Design instrucional

Daniela Erani Monteiro Will

Maria Isabel Orofi no

3ª edição revista e atualizada


Livro didático


Copyright © UnisulVirtual 2006

Nenhuma parte desta publicação pode ser reproduzida por qualquer meio sem a prévia autorização desta instituição.

Ficha catalográfi ca elaborada pela Biblioteca Universitária da Unisul

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 Orofi no; [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 bibliografi a.

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.

CréditosUnisul - Universidade do Sul de Santa CatarinaUnisulVirtual - Educação Superior a Distância

Campus UnisulVirtualRua João Pereira dos Santos, 303

Palhoça - SC - 88130-475

Fone/fax: (48) 3279-1541 e 3279-1542

E-mail: [email protected]

Site: www.virtual.unisul.br

Reitor UnisulGerson Luiz Joner da Silveira

Vice-Reitor e Pró-Reitor AcadêmicoSebastião Salésio Heerdt

Chefe de gabinete da ReitoriaFabian Martins de Castro

Pró-Reitor AdministrativoMarcus Vinícius Anátoles da Silva Ferreira

Campus Tubarão e AraranguáDiretor: Valter Alves Schmitz Neto

Diretora adjunta: Alexandra Orseni

Campus Grande Florianópolis e Norte da IlhaDiretor: Ailton Nazareno Soares

Diretora adjunta: Cibele Schuelter

Campus UnisulVirtualDiretor: João Vianney

Diretora adjunta: Jucimara Roesler

Equipe UnisulVirtual

AdministraçãoRenato André Luz

Valmir Venício Inácio

BibliotecáriaSoraya Arruda Waltrick

Coordenação dos CursosAdriano Sérgio da Cunha

Ana Luisa Mülbert

Ana Paula Reusing Pacheco

Charles Cesconetto

Diva Marília Flemming

Elisa Flemming Luz

Itamar Pedro Bevilaqua

Janete Elza Felisbino

Jucimara Roesler

Lauro José Ballock

Luiz Guilherme Buchmann Figueiredo

Luiz Otávio Botelho Lento

Marcelo Cavalcanti

Mauri Luiz Heerdt

Mauro Faccioni Filho

Nélio Herzmann

Onei Tadeu Dutra

Patrícia Alberton

Patrícia Pozza

Rafael Peteffi da Silva

Raulino Jacó Brüning

Design Gráfi coCristiano Neri Gonçalves Ribeiro

(coordenador)

Adriana Ferreira dos Santos

Alex Sandro Xavier

Evandro Guedes Machado

Fernando Roberto Dias Zimmermann

Higor Ghisi Luciano

Pedro Paulo Alves Teixeira

Rafael Pessi

Vilson Martins Filho

Equipe Didático-PedagógicaAngelita Marçal Flores

Carmen Maria Cipriani Pandini

Carolina Hoeller da Silva Boeing

Cristina Klipp de Oliveira

Daniela Erani Monteiro Will

Dênia Falcão de Bittencourt

Elisa Flemming Luz

Enzo de Oliveira Moreira

Flávia Lumi Matuzawa

Karla Leonora Dahse Nunes

Leandro Kingeski Pacheco

Ligia Maria Soufen Tumolo

Márcia Loch

Patrícia Meneghel

Silvana Denise Guimarães

Tade-Ane de Amorim

Vanessa de Andrade Manuel

Vanessa Francine Corrêa

Viviane Bastos

Viviani Poyer

Logística de Encontros PresenciaisCaroline Batista (Coordenadora)

Aracelli Araldi

Graciele Marinês Lindenmayr

José Carlos Teixeira

Letícia Cristina Pinheiro

Kênia Alexandra Costa Hermann

Marcia Luz de Oliveira

Priscila Santos Alves

Logística de MateriaisJeferson Cassiano Almeida da Costa

(coordenador)

Eduardo Kraus

Monitoria e SuporteRafael da Cunha Lara (coordenador)

Adriana Silveira

Caroline Mendonça

Edison Rodrigo Valim

Francielle Arruda

Gabriela Malinverni Barbieri

Gislane Frasson de Souza

Josiane Conceição Leal

Maria Eugênia Ferreira Celeghin

Simone Andréa de Castilho

Vinícius Maycot Serafi m

Produção Industrial e SuporteArthur Emmanuel F. Silveira (coordenador)

Francisco Asp

Projetos CorporativosDiane Dal Mago

Vanderlei Brasil

Secretaria de Ensino a DistânciaKarine Augusta Zanoni

(secretária de ensino)

Djeime Sammer Bortolotti

Carla Cristina Sbardella

Grasiela Martins

James Marcel Silva Ribeiro

Lamuniê Souza

Liana Pamplona

Maira Marina Martins Godinho

Marcelo Pereira

Marcos Alcides Medeiros Junior

Maria Isabel Aragon

Olavo Lajús

Priscilla Geovana Pagani

Silvana Henrique Silva

Secretária ExecutivaViviane Schalata Martins

TecnologiaOsmar de Oliveira Braz Júnior

(coordenador)

Ricardo Alexandre Bianchini

Rodrigo de Barcelos Martins

Edição – Livro Didático

Professor ConteudistaMauro Faccioni Filho

Design InstrucionalDaniela Erani Monteiro Will

Maria Isabel Orofi no

Flavia Lumi Matuzawa (2ª ed. rev.)

Leandro Kingeski Pacheco (3ª ed.

rev. e atual.)

Projeto Gráfi co e CapaEquipe UnisulVirtual

DiagramaçãoRafael Pessi

Revisão Ortográfi caRevisare


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 . . . . . . . . . . . . . 18SEÇÃO 2 – O que é Projeto? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31SEÇÃO 3 – O que é Gestão? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35SEÇÃ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 . . . . . . . . 46SEÇÃO 2 – Identifi cando oportunidades . . . . . . . . . . . . . . . . . . . . . . . . . . 59SEÇÃO 3 – Motivação para o projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66SEÇÃO 4 – Quais são os tipos de projeto? . . . . . . . . . . . . . . . . . . . . . . . . . 67

UNIDADE 3 – Visão geral do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83

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

UNIDADE 4 – Planejamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

SEÇÃO 1 – Modelagem do fl uxo de atividades . . . . . . . . . . . . . . . . . . . 143SEÇÃO 2 – Metodologias de planejamento – Gráfi co de Gantt . . . 153SEÇÃO 3 – Metodologias de planejamento – PERT/CPM . . . . . . . . . . 168SEÇÃO 4 – Estimativa de recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185SEÇÃO 5 – Estimativa de custos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

UNIDADE 5 – Estruturando a equipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

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

Sumário


UNIDADE 6 – Executando o projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

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

UNIDADE 7 – Finalizando o projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

SEÇÃO 1 – Fase de fi nalização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261SEÇÃO 2 – Planos de contingência em caso de problemas . . . . . . . 262SEÇÃO 3 – Atendendo as expectativas do cliente . . . . . . . . . . . . . . . . 264SEÇÃO 4 – Sobre o sucesso (ou fracasso) do projeto . . . . . . . . . . . . . 265SEÇÃO 5 – Desfazendo a equipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270SEÇÃO 6 – Documentação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270SEÇÃO 7 – Lições aprendidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271SEÇÃ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 efi ciência e efi cá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 benefi ciar 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.


10

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.


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.

EmentaAná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 fl uxo de trabalho e sincronismo de equipe e recursos. Controle da qualidade em projetos para Web. Encerramento de projetos. Verifi cação da satisfação do cliente. Feedback.

�

�

�

�


12


Objetivo geralApresentar 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.

Verifi caçã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ífi cas, invenções ou de inovações tecnológicas, mas é preciso motivação para o seu desenvolvimento. Nesta unidade são ainda apresentadas as diversas classifi cações de projetos, segundo diferentes propósitos e diferentes visões.

�

�

�

�

�

�


13


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áfi co de Gantt, PERT/CPM, estimativa de recursos e cronogramas físico-fi nanceiros são desenvolvidos e aplicados em projetos típicos.

Unidade 5: Estruturando a equipe

A formação da equipe, descrição dos principais perfi s 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 confl itos e aspectos diversos como motivação da equipe e gestão da qualidade. Como projetos são atividades com prazo defi nido, 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, verifi cando 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.


14


Agenda de atividades/ Cronograma

Verifi que 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.

�

�

�


15


Atividades atividades

Demais atividades (registro pessoal)


UNIDADE 1

Introdução à gestão de projetos

Objetivos de aprendizagem

� Compreender diferenças entre projetos e atividades rotineiras e contínuas.

� Verifi car 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.

1


18


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 refl exã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ífi cas 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ê


19


Unidade 1

conheça a origem desta forma de trabalho e como ela vem se modifi cando 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 difi culdades. 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 modifi cou, 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ífi co 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,


20


cada um na medida das suas riquezas. Muitas não fi cavam 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 defi nido 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).


21


Unidade 1

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 os outros reinos, unifi cando todos eles. E em 220 AC decidiu realizar essa obra gigantesca, ligando os trechos de muralhas existentes e criando de fato as Grandes Muralhas da China.

E qual era a intenção ao construir essa obra?

Com o objetivo de separar o país dos bárbaros, e internamente defi nir 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 fortifi caçõ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)

Origem do nome atual da

China.


22


Enquanto a China buscava unifi car 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 fortifi cações, geralmente tendo rios como elementos divisores. Os rios difi cultavam 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 fortifi cada, 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

�

�


23


Unidade 1

portões fortifi cados 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 modifi cado durante as obras, e muitas vezes a edifi cação em pedra foi substituída por barro misturado com galhos. Tipicamente resultado de alterações de prazo de projeto, e também da difi culdade 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 fortifi cado 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, fi losofi a 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.


24


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 fi nalmente 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 defi nido (mesmo que longo) com objetivos diretos e quase sempre ligados às guerras.

Você sabia?

Passados muitos séculos, já no fi nal da Idade Média e quando os países ocidentais começaram a se defi nir como nações, houve um país que fi cou com uma área territorial muito restrita, impedindo seu crescimento e riqueza.

Deu-se início então a um enorme projeto, que na verdade fi cou dividido em inúmeros subprojetos, que consistiram em aumentar o território da Holanda, conquistando espaço do mar. Como?


25


Unidade 1

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 defi nidos 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.


26


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 fi nanceiros e prazos pré-defi nidos.

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 modifi car 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 fi lme “Tempos Modernos” de 1936 de Charlie Chaplin – o Carlitos.


27


Unidade 1

Junto com Taylor trabalhava Henry Gantt (1861-1919), que estudou em detalhes as 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 fi nal de um determinado projeto, Gantt inventou um gráfi co constituído de barras, sendo que cada barra representa uma etapa e seu tamanho representa uma duração.

Os gráfi cos de Gantt fi caram famosíssimos e até hoje são usados para gerenciar projetos. Você vai estudar esses gráfi cos em detalhe, mais à frente nesta disciplina, e vai ver como eles poderão lhe ajudar a gerenciar futuros projetos.

Veja na fi gura a seguir um exemplo de gráfi co de Gantt.

Figura 1.5 – Exemplo de gráfi co 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 fi m da guerra, fi cou evidente que havia um campo do conhecimento específi co da administração de projetos, que fi cou conhecido em inglês por project management; e em português por gestão de projetos.


28


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 infl uenciado 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 empresa buscava melhorar suas técnicas de planejamento 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 signifi ca “técnica de avaliação e revisão de programas/projetos”.

Na época uma pesquisa foi realizada nos EUA para verifi car 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).

�

�

Iniciais do título em inglês Critical

Path Method - CPM.


29


Unidade 1

Quadro 1.1 – Desvios no planejamento.

Desvio entre o planejado e o realizado

Projeto Desvio de tempo Desvio de custo

Governamental / militar 40 a 50% 100 a 200%

Privado 40% 70%

Esses dados foram divulgados e foram alarmantes. Projetos governamentais podiam superar em até 200% os custos inicialmente estimados! No entanto, com o uso do PERT, o projeto Polaris foi realizado com sucesso – dentro do 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ífi cos. 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).


30


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áfi cos de Gantt, Caminho Crítico, PERT, CCPM e outros métodos resolveram o problema, infelizmente está enganado. No ano de 1998 o Th e 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.

Desafi os e sintomas típicos de projetos Média nacional EUA (1998)

AtrasoApenas 44% dos projetos são concluídos 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 técnicos planejados.

70% dos projetos.

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


31


Unidade 1

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 desafi o. Com este desafi o 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 profi ssionais.

Para discutir e estudar Gestão de Projetos e de Equipes é importante, antes de tudo, que você compreenda alguns conceitos, a fi m 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 fi nal, 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 fi lósofos do século passado, Ludwig Wittgenstein, considera que boa parte das questões fi losófi cas 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.


32


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 fi caram mais claros e mais especializados, os prazos cada vez mais curtos, os custos sempre maiores e os recursos cada vez mais escassos.

�

�

�

�


33


Unidade 1

Conforme Antônio Houaiss em seu dicionário de língua portuguesa (2004), projeto pode ser defi nido 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á defi nida pelo Project Management Institute como:

“Um projeto é um conjunto de tarefas, arranjado numa seqüência ou relação defi nida, que produz um efeito ou saída pré-defi nida. Um projeto sempre tem um começo, meio e um fi nal.”

(“A project is a series of tasks, arranged in a defi ned sequence or relationship, that produce a pre-defi ned output or eff ect. 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 defi nido, pois “um projeto sempre tem um começo, meio e um fi nal”.

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 exemplifi car 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).


34


Quadro 1.3 – Exemplos comparativos entre atividades de rotina e projetos.

Área Exemplo de projeto Exemplo de tarefa de rotina ou atividade contínua

CulináriaLançamento de um restaurante temático.

Administração do restaurante temático.

Construção civilDesenhar e construir um prédio comercial.

Manter e operar o sistema elétrico e de automação do prédio.

EletrônicaDesenvolver novo tipo de condensador eletrônico.

Construir telefones celulares.

AgriculturaPesquisar planta resistente a determinado tipo de praga.

Plantar e colher as safras.

SoftwarePesquisar novo sistema de reconhecimento de fala.

Suporte técnico aos usuários de 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 fi nalidades bem defi nidas. 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, enfi m, todas as comunicações que hoje usam a Internet como meio, fi zeram 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.


35


Unidade 1

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

Conforme Antônio Houaiss (2004), em seu dicionário de língua portuguesa, gestão pode ser defi nida 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

�

�

�

�

�


36


nível do projeto, enquanto a gestão seria aplicada a parcelas, ou tópicos específi cos, de um determinado projeto.

Nesta disciplina adotei uma defi nição mais genérica, que engloba 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é-defi nido.

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 defi nição de prazo:

Considerando o objetivo do projeto, prazo é o tempo disponível para chegar ao resultado.

Como por exemplo, gestão da

qualidade, gestão dos documentos

etc.


37


Unidade 1

Recursos

Muitas vezes se confunde recursos com dinheiro, ou recursos com custos. Porém vamos usar uma defi nição mais abrangente, pois as condições fi nanceiras 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 defi niçã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 fi nanceiros 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


38


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 defi nidas, trabalhando em regime de cooperação e focados no sucesso da empreitada.


39


Unidade 1

Síntese

Você viu, na primeira seção, que os projetos, como atividades com início, meio e fi m, bem datados e com resultados claramente esperados, já existem há milhares de anos. Diversos desses projetos resultaram em obras que perduram até hoje.

Com o tempo os projetos foram se desenvolvendo e fi cando 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 identifi cadas, 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.


40


Atividades de auto-avaliação

1) Considerando que projetos têm “objetivos defi nidos 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?


41


Unidade 1

3 – Veja os dois quadros a seguir. O primeiro é de um levantamento realizado em 1958 e o segundo tem dados de 1998. Compare os índices e analise se houve 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).

Desafi os e sintomas típicos de projetos Média nacional EUA (1998)

AtrasoApenas 44% dos projetos são concluídos 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 técnicos planejados.

70% dos projetos.

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


42


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

• Prazos defi nidos.

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

Área Exemplo de projeto Exemplo de tarefa de rotina ou atividade contínua

Concessionária de energia elétrica

Software

Indústria Automobilística

Bancos

Governo


43


Unidade 1

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ífi ca sobre Gestão de Tecnologia. Nesse mesmo site podemos encontrar diversas outras publicações (em inglês) sobre temas de interesse da computação.


2UNIDADE 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.

�

Verifi car 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 Identifi cando oportunidades.

Seção 3 Motivação para o projeto.

Seção 4 Quais são os tipos de projeto?


46



Nesta unidade você vai conhecer como nascem os projetos, sejam eles pequenos empreendimentos pessoais ou grandes projetos transformadores de uma era tecnológica.

Vamos refl etir sobre a infl uência da ciência e da pesquisa como geradores tecnológicos, os quais passam pelo desenvolvimento de projetos específi cos. É 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ífi ca 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 sufi ciente 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 difi culdades.

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ífi cas e tecnológicas dos projetos, e de que forma os conhecimentos são gerados na


47


Unidade 2

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:

necessidades;

conhecimentos e tecnologias disponíveis.

Veja na fi gura 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, enfi m, problemas que surgem todos os dias, estão constantemente nos desafi ando pela busca de soluções. Quando alguém aceita esse desafi o, e simultaneamente há conhecimentos científi cos 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.

��

��

��

��

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.

1.

2.


48


- Para entender melhor como o conhecimento científi co 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, fi lmes, arquivamento de dados, está marcado pela inovação do uso do laser. Antes disso, se fazia gravação de dados em fi tas magnéticas. Esse novo ciclo tecnológico teve origem num projeto de desenvolvimento de um grupo de engenheiros da Philips e da Sony. O desafi o 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 fi tas magnéticas.

O processo de inovação tecnológica compreende a identifi caçã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


49


Unidade 2

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ífi cas, 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ífi cos 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ífi cos sobre materiais semicondutores), também o caso das fi bras óticas (transmissão de ondas de luz), sistema just in time na produção industrial, o uso do laser na medicina etc.

�

�

�


50


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ífi cos 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 modifi cações no gabinete visando a melhorar sua compatibilidade eletromagnética ou dissipação de calor; outro exemplo são as modifi cações feitas nas linhas de produção dentro das fábricas, visando a maior qualidade do produto fi nal 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 superfi ciais na tecnologia e também são “puxados pela demanda”, pois o mercado defi ne tendências de consumo, que demandam desta forma algumas modifi caçõ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 (como temos visto recentemente com os telefones celulares), mas também as mudanças de resistência da embalagem (no caso de alimentos), e muitos outros.

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ífi co, 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.

A ergonomia estuda as relações

entre os seres humanos e as

máquinas, buscando uma interação

de qualidade ótima e de segurança.


51


Unidade 2

Em nossa sociedade a ciência assumiu um papel importantíssimo, e a fi gura 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 infl uê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, fi losófi cas ou artísticas.

Certamente há teorias no pensamento religioso, na fi losofi a especialmente, porém esses modelos de pensar não utilizam métodos científi cos, o que os distingue da ciência (e os projetos que virão a partir daí).

�

�

�

�

�


52


A introdução do método científi co 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ífi co. 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 artifi ciais, técnicas, a sociedade, o pensamento, os próprios métodos científi cos 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ífi cos 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).

�

�

�

�

�

�

�

�

�


53


Unidade 2

O método científi co é a ordem defi nida 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ífi co para a solução de um problema. Veja quais são:

Defi nir o problema, ou seja, caracterizar adequadamente os seus limites, saber o que se pretende resolver com a maior exatidão possível.

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.

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.

Executar o projeto de pesquisa propriamente dito, verifi cando as hipóteses, testando as possibilidades, confi rmando e rejeitando soluções intermediárias, a fi m 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ífi cos, 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.

1.

2.

3.

4.


54


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ífi co, 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ífi co 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ífi ca.

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ífi co, o que as torna interdependentes. A fi gura a seguir mostra essa interdependência e como isso tem permitido a revolução técnico-científi ca que vivemos.

��

��

��

Figura 2.2 - Revolução tecnológica como interação entre ciência e tecnologia.

Essa revolução técnico-científi ca se dá por meio de diversos projetos de pesquisa e desenvolvimento, que podem ser classifi cados da seguinte forma (SÁENZ, 2002):


55


Unidade 2

Pesquisa básica: pesquisa original, teórica ou experimental, com o propósito de adquirir conhecimento sobre determinado fenômeno, porém sem uma fi nalidade 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 modifi caçõ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 modifi caçõ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 classifi caçã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.

�

�

�

�

�


56


ETAPA ENTRADA SAÍDA RETROALIMENTAÇÃO

Pesquisa básicaIdéias de pesquisadores, dos laboratórios, linhas de pesquisa.

Hipóteses, descobertas, teorias, artigos científi cos, livros, equações.

Outras pesquisas básicas, solicitações externas, invenções, novos problemas.

Pesquisa aplicada

Saída da pesquisa aplicada, idéias de pesquisadores, dos laboratórios, de empresas, de engenheiros, necessidades sociais.

Patentes, invenções, maquetes, protótipos, softwares de simulação.

Outras pesquisas básicas e aplicadas, solicitações externas, novos problemas técnicos e científi cos, fracassos anteriores.

Desenvolvimento tecnológico

Idéias de engenheiros e de empresários, invenções, resultados de pesquisas e outros trabalhos.

Projetos, planos, protótipos, novos produtos e processos, especifi cações.

Novos problemas técnicos e científi cos, necessidades de invenção, relatórios de êxitos e fracassos.

Melhoria de processo / produto

Produtos e processos em uso, necessidades de usuários, idéias de engenheiros e empresários.

Produtos e processos modifi cados, novo design, modifi cações de fabricação, automação de processos.

Necessidades de alteração em linhas de produção, modifi cação comercial, novos desejos de consumo.

Assistência técnica e tecnológica

Necessidades de norma e de legislação, padrões de qualidade, manutenção, bugs.

Calibrações, ensaios, padronizações.

Percepção de melhorias, novos 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 é fi nita. A ciência, ao contrário, busca verdades perenes, leis fundamentais e duráveis, independentes no espaço e no tempo.

Quadro 2.1 – Painel sobre diferentes modelos de pesquisa, suas entradas e saídas.


57


Unidade 2

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áfi co da fi gura 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.

��

��!��

��!��

��"�� #�� $��

��

��

��

Figura 2.3 – Ciclo de vida de produtos tecnológicos.


58


A duração maior ou menor da vida do produto depende de vários fatores. Analise os três exemplos apresentados na fi gura a seguir.

��

��

��

�

��%��&�� '��(��&��)*

��&�� &�� '��+�� )*

�� '�� (��)�

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ífi ca 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ífi cas.

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!).


59


Unidade 2

- Bem, até aqui você tive uma visão geral das fontes de conhecimento

científi co e tecnológico, e como eles se desenvolvem para gerar mais

conhecimento e mais tecnologia. Na seção 2 você vai identifi car onde

pode haver oportunidades de novos desenvolvimentos, pois essas

oportunidades poderão ser as fontes de novos projetos.

SEÇÃO 2 – Identifi cando oportunidades

Certamente não existe um “manual de novidades” a ser explorado, onde pudéssemos consultar e verifi car 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 modifi cações profundas em um processo industrial ou nos hábitos do consumidor.

Para identifi car 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.


60


Na verdade as oportunidades de novos projetos estão bem à nossa frente, basta sabermos ler. Porém, apenas identifi car 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 fi gura 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ífi ca 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.

�� !�� !��

$��,�� &�- ��%��

$��,�� &�- ��

!��&�� %��

Figura 2.5 – Diferenças entre descoberta, invenção e inovação.

Boa parte das descobertas científi cas 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.

�

�

�


61


Unidade 2

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ífi cos 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ífi cos 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ífi ca 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á fi nalizada. 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 fi ca em segundo plano. Isso acaba isolando tais centros de pesquisa,


62


que por não estarem prestando atenção no que acontece no mercado, consideram terminada sua tarefa ao concluir o projeto.

A fi gura 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.

!�"!#�� $��

%��$��

��

�� &��

'��(��

�� )��

��

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ífi ca.


63


Unidade 2

A fi gura 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.

��

��*�� !�"!#

�� $��

'��

�� &��

'��(��

�� )��

��

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ífi cos.

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ífi ca, produtiva e comercial para desenvolver o produto;

�

�

�


64


sejam alocados recursos fi nanceiros 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 fi gura, 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.

!�"!#'��(��

�� )��

��

'��

��*��

��'��+��

�� +��

��

�� &��

��

,��

��

Figura 2.8 – Modelo de “Sistema Tecnológico”.

�

�

�

�

�

�


65


Unidade 2

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 fi gura, onde necessidades e oportunidades técnicas se juntam para gerar idéias e defi nir, então, um caminho, que pode ser trilhado ou não, para o desenvolvimento de um novo projeto.

��)��-��

%��

��

.��

/��

/��&��

/��

/��

% �� !�-��

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.


66


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 fi nal, 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 fi nal, 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 defi ne 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.


67


Unidade 2

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 fi nanceiro. O prêmio em dinheiro dá motivação para perseguir o projeto até o fi nal, 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ífi co. 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 classifi cados em diversas categorias, e essa classifi cação vai variar conforme interesses comerciais, científi cos e industriais, ou então conforme graus de difi culdade, ou mesmo conforme o ambiente em que se desenvolvem.

Veja agora algumas dessas possíveis divisões e, ao fi nal, você vai conhecer uma sistematização dessas classifi caçõ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 classifi cados quanto à natureza científi ca e tecnológica e, neste sentido, podem ser, grosso modo, divididos nos seguintes tipos:


68


Projetos de Pesquisa: são os projetos científi cos, 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ífi cos, 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ífi co 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 defi nida; 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 modifi cação de um processo de venda ou de produção, com foco em melhoria comercial; lançamentos de novas embalagens.

�

�

�

�


69


Unidade 2

Novas versões de software e novas formas de entrega para o consumidor.

Industriais: muito próximos dos projetos do tipo “comercial”, também estão objetivando diferencial competitivo; no entanto são desenvolvidos no interior da indústria buscando melhorias no processo produtivo do chão de fábrica, sem um relacionamento direto com 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 modifi cação de leiaute no chão de fábrica, passando por projetos de introdução de automatismos em máquinas até a criação de novas máquinas-ferramenta.

Governamentais: os governos são grandes geradores de 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 estratégicas para buscar suprir tais necessidades, mas o que se vê geralmente são as vaidades políticas e a visão limitada como geradores de tais projetos, que muitas vezes acabam por gastos inúteis do dinheiro público; mas certamente há também os projetos de sucesso, muitas vezes polêmicos, que são capazes de modifi car todo um panorama histórico, e para não ir muito longe lembro 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 fl uxo 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

�

�

�

Chamamos de chão de fábrica o ambiente

onde geralmente estão

instaladas as máquinas

da indústria, e onde o

processo operacional de

produção acontece; não

inclui, por exemplo, as

áreas de administração,

vendas, compras e

projetos.

Do inglês lay-out,

representa um esboço

ou modelo genérico de

disposição de peças,

móveis e equipamentos

num ambiente.

Máquina-ferramenta é

aquela que é usada para

fabricar outras máquinas,

mais especifi camente para

dar forma a objetos sólidos

como madeira e metal,

os quais serão usados

como peças em outras

máquinas.


70


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.

Acadêmicos: são os projetos que se desenvolvem dentro do ambiente das instituições educacionais, tais como monografi as 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 desconfi anç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, modifi cando hábitos de consumidores e alterando completamente a fi nalidade 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.

�

�

Cabe aqui ressaltar que a Unisul

criou e mantém uma incubadora,

com o apoio do governo de Santa

Catarina.


71


Unidade 2

Introdução dos compact discs no mercado musical, que praticamente aboliu o uso de discos de vinil e fi tas 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.

Recentemente Dov Dvir et al. (2004) desenvolveram e passaram a aplicar um esquema genérico para defi nir tipos de projetos. Esse esquema, ou framework, foi denominado de “Modelo UCP”, sobre o qual é possível classifi car os diversos tipos de projetos tecnológicos.

�

�

�

Iniciais de Uncertainty,

Complexity e Pace,

que poderíamos aqui

traduzir por Incerteza,

Complexidade e Prazo.


72


A fi gura a seguir mostra esse modelo como uma confi guraçã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 defi niçã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.

��)��

'��0�

!��0�

��-.��

Figura 2.10 – Modelo UCP para classifi caçã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 fi nal. 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

�

�


73


Unidade 2

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 modifi cações nos prazos originalmente defi nidos; 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 fi nalmente obter o resultado desejado, e junto a isso gerou uma enorme variedade de subprodutos e novas tecnologias; a fi gura a seguir representa as classifi cações no eixo das Incertezas com relação às tecnologias envolvidas.

�

�


74


/��0�

��

"�� # ��

!��0�

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 defi ne 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 confi gura 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

�

�

�


75


Unidade 2

defi nidos 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 fi gura abaixo.

��)��# ��

#��

"��

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 identifi cam três tipos de projetos quanto aos “prazos”:

Regulares: são aqueles projetos onde existe um prazo defi nido mas há razoável tolerância aos atrasos e modifi cações de agenda, como acontece, por exemplo, na construção de edifícios residenciais e em estradas; perturbações e modifi caçõ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.

�


76


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 signifi ca 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 fi gura a seguir).

'��0�

1��

$��

$��

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 fi gura a atual posição do produto e a posição futura numa disposição bidimensional.

�

�


77


Unidade 2

��

��)��

!��0��

"�� # ��

# ��

#��

"��

1��

/��0�

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.


78


Síntese

Nesta unidade você conheceu os diferentes tipos de projeto, como são classifi cados e, especialmente, no que se relaciona à complexidade tecnológica, riscos variados e prazos. Essa classifi cação é atual e deriva do desenvolvimento científi co e tecnológico recente. Além disso, foram discutidas algumas outras classifi cações, mas a ênfase foi colocada na inter-relação entre conhecimento científi co 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 fi ca o convite para navegar em outras referências, artigos e livros. Boa sorte e até a próxima!


79


Unidade 2


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.

��

��

��

��


80


2) Na fi gura 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”?

��

��

��

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.


81


Unidade 2

4) A fi gura a seguir apresenta o Modelo UCP de classifi cação de projetos.

Considere os seguintes casos:

(A) A construção de uma casa e classifi que 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. Classifi que e marque também este projeto no desenho.

Comente no fi nal as diferenças que você vê entre os três tipos de projeto.

��

��)��

!��0�

"�� # ��

# ��

#��

"��

/��0�


82


Saiba mais

Links úteis

Alguns links são muito úteis para a comunidade de ciência e tecnologia. Dê uma olhada nesses:

1. www.fi nep.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 fi nanciamento 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ífi co e Tecnológico – CNPq – que também fi nancia 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.


3UNIDADE 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.

�

Verifi car itens fundamentais como recursos, custos, benefícios e prazos, como componentes determinantes da viabilidade do projeto.

�

Seções de estudo

Seção 1 Identifi caçã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.


84



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 identifi caçã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 especifi camente 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 fi m 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!


85


Unidade 3

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

Para os projetos terem sucesso é preciso ter, antes de tudo, uma visão clara sobre a fi nalidade e sobre o seu resultado fi nal esperado. Em recente artigo sobre lideranças em equipes de projetos, Christenson e Walker (2004) defi nem 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 infl uencia 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 fi nalizar cada etapa da montagem, alguém pára para contar peças.


86


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 defi niçã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 defi niçã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 fi nal 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:


87


Unidade 3

conhecimentos adquiridos em etapas de pesquisa e desenvolvimento científi co 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 defi nir o escopo do problema, o passo inicial é a identifi cação exata da necessidade a ser atendida.

A atividade de reconhecer uma necessidade, identifi cá-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 especifi cação da necessidade.

Na tentativa de defi nir um problema há duas maneiras de encará-lo:

Partido geral, ou amplo: defi nir 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 fi gura 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.

�

�

�

�


88


��

$� ��

��

$� ��

$� ��

2��

#�� 3��-��

1�4!56��6��16/7�"�

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 fi gura, 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”.

�


89


Unidade 3

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 profi ssional 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 infl uenciar a busca por um partido amplo!).

Veja o quadro a seguir:

Caso 1Falha 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 fi cava 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


90


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 fi z 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 fi zeram 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.



91


Unidade 3

- E então? Viu agora? A seguir trago mais um caso para que você

compreenda melhor, veja:

Caso 2Implantação de um ERP

Conheci uma empresa que tinha várias fi liais espalhadas por extenso território e mais de mil e quinhentos funcionários. Não vou contar aqui a novela e os dramas que aconteceram na escolha do software ou na sua implantação. Vou iniciar o caso no momento em que uma rede de comunicação IP foi contratada de uma grande empresa de telecomunicações. Qual era o problema?

Antes do contrato dessa grande rede IP, todos os usuários reclamavam de imensos problemas de demora para resolver qualquer coisa com o tal software ERP, que tinha vindo para ser “a salvação do sistema de informações” dessa empresa. O usuário evidentemente achava que 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, fi z 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áfi cos 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 fi liais? 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 fi lho defeituoso, vivendo para sempre dentro de casa.

ERP – Sigla para

Enterprise Resource

Planning, sistema

informatizado para

planejamento e

apoio à operação

dos recursos de uma

empresa, tais como

fi nanceiro, estoque,

pessoal, linha de

produção etc.



92


- Você observou como muitas vezes nos acostumamos com os problemas,

e perdemos a oportunidade de eliminá-los? Veja o terceiro caso agora.

Caso 3Encomenda de um novo site corporativo

Estive em uma determinada companhia onde a cultura tecnológica remontava ainda à época da segunda revolução industrial, ou seja, a cultura tinha conseguido evoluir do ambiente das máquinas a vapor para as máquinas elétricas. Isto não é uma crítica à companhia, pois ela estava adequada ao seu mercado, que a enxergava como capaz de entregar produtos tradicionais (e conservadores) e nisso era muito boa.

No entanto seu problema é que o discurso da nova direção era de remodelagem dos seus objetivos, e nisso o foco era estar a par com as novas tecnologias e com os novos processos de qualidade, tanto é que fazia 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.

Site corporativo:

espaço virtual de

determinada empresa

no ambiente da

“World Wide Web”

na internet – em

português algumas

vezes se usa a palavra

“sítio”, que aos poucos

está se tornando

corrente no Brasil.


93


Unidade 3

Isso não consistia num grande problema no ambiente em que viviam, mas era grave quando resolveram infl uenciar nas defi niçõ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 fi zeram 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, fi caram fora desse processo de análise de defi nições e, enfi m, 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, afi nal 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).

Caso 3 - continuação

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.


94


Caso 4Uma 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 telefonia celular. No início dos anos noventa a empresa já detinha um razoável conhecimento na área, e um domínio consistente do seu mercado local que, no entanto, era de dimensão restrita.

Também com uma visão ampla e estratégica do mercado mundial, previu que a produção de aparelhos de telefonia celular teria valor agregado quando inserisse qualidade no software, e não no hardware do equipamento. Adotou uma solução (ampla) de pesquisar e desenvolver novas interfaces e aplicativos, voltados à facilidade de manuseio por parte do usuário, muito mais do que desenvolver simplesmente a miniaturização dos aparelhos ou a qualidade de baterias, o que considerou como 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 fi nais, 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.

Commodities: palavra da língua

inglesa que indica

que o produto ou

sistema é de uso

ou conhecimento

genérico, tendo

poucas diferenças de

valor, independente

de quem os fabrica

ou fornece.


95


Unidade 3

É importante observar que há nesses quatro casos, sejam de sucesso ou de fracasso, algumas 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 é sufi ciente, pois em problemas técnicos é necessário um conhecimento específi co. 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 fi car alheios ao desenvolvimento dos seus colegas, supondo que sua imensa capacidade

�

�

�

�


96


seria o bastante para resolver os grandes problemas do futuro. Hoje, infelizmente, muitos deles 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 signifi cou 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 fi m, para completar esta seção, cabe dizer que as estratégias são defi nidas e implementadas com uma visão de partido amplo, e as questões operacionais estão defi nidas sobre questões restritas, ou partes de uma estratégia. O momento em que uma ou outra devem acontecer é que defi ne 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 profi ssionais, 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ífi ca e, deste modo, tem uma idéia aproximada daquilo que quer obter.

�


97


Unidade 3

Como você já viu anteriormente, esse cliente conhece talvez alguns dos efeitos de um problema, mas geralmente 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 afi nal “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 fi nais.

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;

�

�


98


se for um novo produto ou processo a desenvolver, listar o que deve ser determinado pela solução, ou seja, defi nir 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 fl uxogramas, 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 verifi car as leis físicas associadas e suas equações, no caso dos problemas científi cos, 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áfi cos 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 fi gura 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.

�

�

�

�


99


Unidade 3

�

�

��-��

��

8��

��

�� &��

9��:��

6 ��3��

6-.��.��

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 defi nir um caminho de trabalho para abordar o projeto. Esse caminho está defi nido 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 defi nir com exatidão todos os passos que devem ser seguidos, para que o mesmo chegue ao resultado esperado. Tendo um objetivo bem defi nido, conforme você observou na seção anterior (veja de novo a fi gura e o último quadro, à direita), é preciso determinar um fl uxograma 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 fi gura a seguir foi adaptado a partir de uma proposta de Meillir Page-Jones (1990). O fl uxograma se inicia a partir dos objetivos defi nidos, e vai ser encerrado quando os mesmos forem alcançados.


100


Nesse algoritmo podemos ver o conjunto de atividades que determina a Gestão do Projeto:

planejamento;

defi niçã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,

verifi cando o fl uxo das atividades.

6��-.��

6-.��.��

��.��

��

6-��

!��

�0��

�� 3��

1��.��

��.��

#!"

856

;��

Figura 3.4 – Algoritmo genérico com o fl uxograma do desenvolvimento do projeto.

�

�

�

�

�


101


Unidade 3

Planejamento das atividades – o planejamento consiste em dividir o objetivo geral do projeto num conjunto de pequenas tarefas, ou pequenos objetivos, que vão se encadeando numa seqüência determinada, a fi m de atingir o resultado esperado do projeto. Também consiste em defi nir recursos materiais, fi nanceiros e de pessoal, para cada um desses pequenos objetivos, com os trabalhos a serem feitos num determinado prazo preestabelecido. O tema do “planejamento” será estudado na unidade 4.

Defi nição dos recursos – a defi niçã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 defi niçã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. Defi nir com a maior exatidão os recursos necessários, sejam eles fi nanceiros, materiais, equipamentos ou pessoal com a qualifi caçã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 defi niçã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 é

�

�

�

�


102


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 fi nais 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 defi nem 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 verifi caçã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

�

�


103


Unidade 3

menores, faz-se necessário verifi car 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 verifi caçã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 defi nido. 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 signifi ca reavaliar constantemente o planejamento, bem como redefi nir os objetivos quando necessário. Caso a revisão seja feita apenas no fi nal do projeto, pode acarretar em enormes frustrações (fi nanceiras ou de expectativa). A fi gura 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 modifi cação e retifi caçã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.

6�� -�-.��<

1��.��

1��

#!"

856

��:0��

Figura 3.5 – Fluxograma específi co da fase da revisão.

�


104


Encerramento do projeto – encerrar o projeto signifi ca alcançar aos objetivos. (Bem, infelizmente nem sempre isso acontece, como veremos na unidade 7, onde discutiremos “sucesso e fracasso” de projetos). A fi nalização do projeto não é simplesmente acabar um produto ou compilar um código. O encerramento é uma etapa bem defi nida 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áfi cos de Gantt”, foram desenvolvidos para poder visualizar, esquematicamente, as etapas de um projeto ao longo do tempo. Esses gráfi cos 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áfi cos, 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áfi cos 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).

�

�


105


Unidade 3

Veja a seguir uma tradução que fi z 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 é fi nanciado por propaganda, colocada na parte superior à direita da janela do aplicativo, e tal propaganda é que fi nancia 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 fi o 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 signifi cativamente para a falta de efi ciê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.


106


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/offi ce/project/standard.asp. O MSProject é uma marca registrada e é o produto de maior sucesso hoje da Microsoft, depois do Offi ce.

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á verifi car 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ífi cas, 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 Offi ce Project Standard 2003 é utilizado pelos gerentes de projetos que precisam de uma ferramenta de área de trabalho para gerenciar seus projetos de maneira independente, mas que 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 efi ciente 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 efi ciente, 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ífi cas 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 fi ltros e grupos.”

�

�

�

�

�


107


Unidade 3

Algumas facilidades para quem já usa os pacotes da Microsoft: “O Project Standard 2003 ajuda a projetar seus planos de projeto e status de maneira efi ciente e sucinta, permitindo que você:

Aumente seu impacto sobre o trabalho, usando Copiar Imagem para o Assistente do Offi ce para comunicar e apresentar idéias e informações do Project Standard 2003 em outros programas do Offi ce System como Microsoft Offi ce Word 2003, Microsoft Offi ce PowerPoint® 2003 e Microsoft Offi ce 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 confi gurar agendas e gerenciar recursos de maneira mais efi ciente.

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 sofi sticado 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 Offi ce como Microsoft Offi ce Excel 2003.

Navegar e aprender o Project Standard 2003 rapidamente com uma interface atualizada consistente com os programas do Microsoft Offi ce 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:


108


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 defi nição do prazo é algo que nasce dos requisitos do cliente, pois os objetivos por ele defi nidos 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 fi cava 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).

Gantt ProjectPert Chart Expert.WBS Chart Pro.Mindmanager.Primavera Team Play.PMOffi ce.

�

�

�

�

�

�

Open Project System.Rational Project Manager.PS8.Tassc Estimator Manager.

�

�

�

�


109


Unidade 3

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 fi nal aleatória. Isso pode acontecer, por exemplo, quando um político defi ne 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 confi gurar 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 fi nal para o projeto fi car


110


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 defi nir 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 defi ne 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.


111


Unidade 3

d) “Escala de valores”

O que Page-Jones chama de escala de valores está apresentado na fi gura 3.6 a seguir. O projeto tem um determinado custo para ser desenvolvido, que está representado pela linha tracejada, enquanto os ganhos a serem auferidos com o projeto fi nalizado estão representados pela linha contínua. A defi niçã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 defi nir essa data como adequada. Os atrasos que ocorreram farão a data de entrega escorregar para a direita no gráfi co, 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ófi co. Ou o lançamento de um novo veículo no fi nal 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 defi nir 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.


112


=��

�

!��.��

��

��>��?��

$ �� .��

$ ��.��

2��

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 defi nir prazos de um projeto?

Bem, considerando as implicações que você acabou de ver, é importante:

Não ceder ao primeiro impulso de se defi nir uma data, sem antes analisar o máximo possível de dados do projeto.

Perceber quando a data defi nida 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 fi cado 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”.

�

�

�

�


113


Unidade 3

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 defi nem 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 sufi ciente para se ter uma “visão geral do projeto”.


114


� ��

�� -��

Figura 3.7 – Fatores fundamentais na viabilidade dos projetos.

Benefícios

Os benefícios são os resultados positivos esperados do projeto depois de fi nalizado. 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, edifi caçã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.


115


Unidade 3

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 certifi caçõ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, o setor de software dispõe de maiores facilidades de recursos, e nisso se baseia o crescimento de certas regiões carentes de recursos caros (como o exemplo do laboratório).

Países como o Brasil, China e Índia conseguem crescer rapidamente nesse setor por esse motivo, onde os recursos materiais são escassos, mas recursos humanos talentosos são abundantes.

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.

�

�

�

Para obter outras

informações acesse o sítio

da SOFTEX - Sociedade para

Promoção da Excelência do

Software Brasileiro, sobre

os mercados de software

do Brasil, China e Índia,

disponível em: http://www.

softex.br/cgi/cgilua.exe/sys/

start.htm?sid=177 .


116


Custos

Considerando os recursos materiais e humanos necessários para o desenvolvimento do projeto, recursos fi nanceiros 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 difi culdades 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 signifi car a paralisação de uma estrutura já em andamento (é o que acontece, por exemplo, com as pequenas empresas de base tecnológica, que para fi nanciar 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 difi culdade de usar o equipamento dentro de edifi caçõ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.


117


Unidade 3

Prazo

A questão da defi niçã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 defi nidos 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, signifi car o acréscimo de confusão.

Voltando agora à fi gura 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.

Verifi cando 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 fi cou subentendida, e ela denota algo inerente a todo empreendimento humano: a chance do erro e do fracasso, seja no conjunto ou no detalhe.


118


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 fi nanceiros. O gestor (operacional) enxerga as questões fi nanceiras imediatas, enquanto o líder (estratégico) poderá ver oportunidades fi nanceiras 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 fi nanceiras 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


119


Unidade 3

nem mesmo é possível contratá-los. No exemplo do laboratório de certifi caçã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 fi nanceiros é preciso também considerar valores intangíveis do projeto.

No exemplo do Projeto Apolo, é bem provável que os valores

fi nanceiros mensuráveis à época tenham sido desastrosos,

mas de maneira alguma foram ruins os ganhos políticos e

científi cos, 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


120


Ao atravessarmos a rua há o risco de surgir um carro em alta velocidade, ao entrar no mar há o risco de uma corrente mais forte, ao sair para o passeio no campo há o risco da chuva, ao iniciarmos uma empresa há o risco de uma 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?

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 sufi ciente 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ífi co).

Prazo versus custos

Por fi m, é importante considerar por quanto tempo o fi nanciamento 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 signifi car 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.


121


Unidade 3

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 TecnologiaAs 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 em substituir uma teoria errada por uma certa, e sim uma errada por uma aparentemente certa.

O defeito só aparece depois que a unidade passou pela inspeção fi nal.

Depois que um equipamento foi montado e funciona perfeitamente, encontram-se em baixo do banco diversas peças fundamentais.

Se sua experiência fracassou, destrua todas as provas que tentou.As variáveis variam menos que as constantes.

A única peça que a fábrica esqueceu de embarcar é indispensável para a montagem de 75% do equipamento.

�

�

�

�

�

�

A fábrica não esqueceu de entregar, ela nem fabricou a peça.

Como os teoremas da matemática se relacionam com a realidade, não são seguros. Sendo seguros não se relacionam com a realidade.Em qualquer circuito eletrônico o componente de vida mais curta será instalado no lugar de mais difícil acesso.

Qualquer desenho de circuito eletrônico deve conter pelo menos: uma peça obsoleta, duas impossíveis de encontrar, e três ainda sendo testadas (por você, é claro).

Depois que o último dos parafusos foi retirado da tampa de acesso de um

�

�

�

�

�

SEGUE


122


equipamento, verifi ca-se que foi removida a tampa errada.

Depois que o último dos parafusos da tampa de um equipamento foi apertado, verifi ca-se que alguma peça fi cou para fora.

O êxito de uma demonstração é inversamente proporcional ao número de pessoas importantes que assistem a essa demonstração.

Todo arame cortado no tamanho indicado será curto demais.

Não há nenhum problema mecânico tão difícil que não possa ser resolvido com força bruta e ignorância.

É mais fácil separá-los do que colocar tudo junto novamente.

Regra de advertência: Para escrever uma bula de remédio, primeiro convença o leitor de que ele tem a doença sobre a qual ele está lendo; depois de que, ela é curável.

Leis do Desenho:

� Se você desenhou, poderia ter copiado.

� Se copiou, poderia ter decalcado.

�

�

�

�

�

�

�

� Se decalcou, poderia cortar e colar.

� Se recortou e colou, poderia ter xerocado.

� Se xerocou, estava disponível na internet.

Leis da Dieta:

� Pra não engordar há quem coma somente verduras. Os elefantes só comem verdura.

� Pra não engordar há quem coma somente peixe. As baleias só comem peixe.

Nada é tão fácil quanto parece, nem tão difícil quanto a explicação do manual.

A explicação mais simples sucede a solução mais complexa.

Se tudo que você tem é um martelo, trate tudo como um prego.

Especialista é aquele cara que sabe cada vez mais sobre cada vez menos.

Super-especialista é aquele que sabe absolutamente tudo sobre absolutamente nada.

Ciência exata é profetizar sobre o que já aconteceu.

�

�

�

�

�

�

�

Leis de Murphy - continuação


123


Unidade 3

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 simplifi cado (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.

�

�

�

�

�


124


Estudo de viabilidade <nome do projeto>

Equipe de estudo:

Local e data:

Resumo do projeto (escopo, objetivos, estratégias)

Benefícios:

� quais são as vantagens mensuráveis que o projeto trará?

� quais são os valores comparativos?

Descrição:

Benefícios:

� que vantagens intangíveis ele trará?

� como se poderá verifi car?

Descrição:

Recursos:

� quais os recursos materiais necessários para o projeto?

� esses recursos estão disponíveis?

� caso não disponíveis, é possível obtê-los?

Descrição:

Recursos:

� 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?

Descrição:

Custos:

� considerando os recursos necessários, quanto dinheiro será necessário para desenvolver o projeto?

� esse montante está disponível?

Descrição:

Custos:

� há fontes de fi nanciamento?

Descrição:

Prazo:

� qual o prazo pré-defi nido pelo “cliente” para o projeto?

Descrição:

Prazo:

� considerando a experiência da equipe, qual o prazo estimado para o projeto? É igual ao pré-defi nido?

Descrição:

Conclusões quanto à viabilidade do projeto:

Recomendações:

Anexos (tabelas, demonstrativos, estatísticas, reportagens, tendências tecnológicas e comerciais etc.)

Quadro 3.1 – Modelo de relatório para estudo de viabilidade de projetos.


125


Unidade 3

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 fi nanceiros 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 fi nanceiro para custear o projeto não está depositado previamente e depende de fi nanciamento 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 fi gura 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.


126


1��@��.��

1��0��

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 verifi ca 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.

�

�

�

�

�

�

�

�

�


127


Unidade 3

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 fi nanciador 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 verifi car 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.

�

�

�

�

�

�

�

�

�

�


128


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 identifi cados 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:

Identifi cação de riscos;

Análise;

Planejar ação sobre esses riscos;

Controlar/eliminar os riscos;

Nova etapa do projeto e nova identifi cação de riscos.

!��

��

��.��-��

��

��

�� 8��

Figura 3.9 – Antecipando e administrando riscos.

�

�

�

�

�


129


Unidade 3

Identifi cação de riscos

Este é o primeiro passo na administração dos riscos, e consiste em sua identifi caçã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 identifi caçã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 identifi cação, deve ser descrito com clareza, declarando sua origem e a conseqüência que trará ao projeto, caso aconteça.

Análise

Partindo da identifi caçã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 identifi caçã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).


130


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

Identifi cados 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 defi ciências

�

�

�

�


131


Unidade 3

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 fi nanceiros para isso). Enfi m, 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

Identifi cados 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 fi nal 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.

�

�

�

�

�

�


132


Estudo de riscos<nome do projeto>Equipe de estudo:

Local e data:

Resumo do projeto (escopo, objetivos, estratégias)

Riscos quanto aos benefícios:

- o cliente tem uma idéia exata do resultado a ser obtido?

- ou tem uma idéia aproximada?

- é possível medir os benefícios?

Descrição:

Riscos quanto aos benefícios:

- qual a probabilidade desse tipo de riscos?

- qual o seu impacto?

Descrição:

Riscos quanto aos recursos:

- há equipamentos de reserva?

- há pessoal de reserva?

- a tecnologia empregada é inteiramente dominada?

Descrição:

Riscos quanto aos recursos:



Descrição:

Riscos quanto aos custos:

- o fi nanciamento de todo o projeto está garantido?

- há um montante de reserva?

Descrição:

Riscos quanto aos custos:



Descrição:

Riscos quanto ao prazo:

- há fatores internos ou externos, não considerados, que podem afetar o prazo do projeto?

Descrição:


- a equipe de projeto é experiente?

Descrição:




Descrição:

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

Quadro 3.2 – Modelo de relatório para estudo de riscos de projetos.


133


Unidade 3

Síntese

Na primeira seção desta unidade foram discutidas as formas de se identifi car 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 fi car 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 fl uxo, e tal fl uxo traz inúmeros passos que devem ser executados num determinado prazo. Projetos, por defi niçã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 fi m 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


134


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ê!


135


Unidade 3


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 modifi cados, 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 fi scal é emitida à mão, e fi nalmente a reposição do estoque é feita por meio de constantes verifi caçõ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?


136


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 fi gura 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.

�

�

��-��

��

8��

��

�� &��

9��:��

6 ��3��

6-.��.��


137


Unidade 3

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?


138


5) Como você defi ne a data “fatal” do projeto ? (veja a fi gura abaixo)

=��

�

!��.��

��

��>��?

$ �� .��

$ ��.��

2��


139


Unidade 3

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ê?


140


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.


4UNIDADE 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.

Verifi car 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 fl uxo de atividades.

Seção 2 Metodologias de planejamento – Gráfi co de Gantt.

Seção 3 Metodologias de planejamento – PERT/CPM.

Seção 4 Estimativa de recursos.

Seção 5 Estimativa de custos.


142



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 defi niçã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áfi co de Gantt, que provavelmente você já conhece. Ultimamente esse tipo de gráfi co 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áfi co 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 defi nem 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!!


143


Unidade 4

SEÇÃO 1 – Modelagem do fl uxo 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 é sufi ciente 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 defi nição de um fl uxo de atividades.

O modelo de um objeto é uma representação, é uma simplifi cação desse objeto de forma que possamos entendê-lo de forma abrangente.

- Para fi car mais claro, veja o exemplo a seguir:

A maquete de um prédio é um modelo de como será o prédio ao fi car pronto. Ele mostra as partes do edifício, seu aspecto geral, numa proporção muito boa para que você possa entendê-lo antes de fi car 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.


144


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 fi nal 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 decodifi car 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, signifi ca 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;

�


145


Unidade 4

é prático e seguro trabalhar com modelos, pois caso as coisas não se afi gurem 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 fi nal, 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 fi cçã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;

�

�

�

�

�

�

�


146


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 fi gura 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

�

�

�

�


147


Unidade 4

processo ou sistema, sem dispersar a atenção em detalhes de outra ordem, e um bom exemplo disso são os fl uxogramas que usamos nas empresas, mostrando como se dá o fl uxo 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 fi gura 4.2).

Figura 4.2 – Exemplo de representação diagramática – diagrama de atividades da UML – Linguagem de Modelagem Unifi cada (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 sofi sticados, porém são altamente especializados e exigem conhecimento avançado dos usuários.


148


Modelo Gráfi co – é o modelo que representa o comportamento de fenômenos por meio de curvas, gráfi cos, facilitando a sua verifi cação. Há diversos tipos de gráfi cos, 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 defi nidos 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 fi gura 4.3 você pode perceber como se dá o fl uxo do conhecimento durante o desenvolvimento de um projeto tecnológico. As diferenças entre os três tipos de fl uxos defi nem 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.

�� !��&��

��&��

�0�� &��&�� &%�/1%

�/2�/�!#1

&%�/1%�/2�/�!#1%&�%1#'#&/��%

&%�/1%%&�%1#'#&/��%

��

��

Figura 4.3 – Três modelos de fl uxo de conhecimento no desenvolvimento de projetos tecnológicos.


149


Unidade 4

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 fl uxo no modelo seqüencial, cujo diagrama está apresentado na fi gura 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 fi nalizaçã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 infl uencia 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.


150


��

��

&%�/1%��/2�/�!#1

��

'��(��

/��

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 defi nida, 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 interfi ram positivamente na etapa anterior, obrigando revisões dinâmicas do processo.

Como você pode ver no desenho da fi gura 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.


151


Unidade 4

��

��

��

'��(��

/��

&��(��

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 fi gura 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 fi nal do produto.


152


O fl uxo 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.

��

��

��

'��(��

/��

&��

Figura 4.6 – Solução radical: modelo com solapamento (inspirado em Sáenz, 2001).

Nesta seção você conheceu a modelagem do fl uxo das atividades de um projeto, e como podem ser os diversos modelos de representação, sejam do fl uxo 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.


153


Unidade 4

SEÇÃO 2 – Metodologias de planejamento – Gráfi co 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 signifi ca 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 fi guras 4.7 e 4.8 a seguir. Ambas nos mostram uma divisão de tarefas do projeto fi ctício denominado “Exemplo”. Na fi gura 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 EXEMPLOEtapa 1

• Defi niçõ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”.


154


A árvore da fi gura 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.

'��/3/&'1%

/��4

"��

/��5

/��6

��3�� $�� 6��

=��A �� =��B =��A

��

Figura 4.8 – O mesmo projeto da fi gura 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áfi co 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.

�

�

�


155


Unidade 4

Gráfi co de Gantt

O gráfi co de Gantt também é chamado de gráfi co 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 fi nal da barra seu término, sendo que a barra se estende por todo o período compreendido entre as duas datas.

A fi gura 4.9 mostra um exemplo de Gráfi co 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áfi co de Gantt.

Este tipo de gráfi co 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.


156


Na fi gura 4.9 você pode ver a barra cinza da Etapa 1 mostrando o andamento do projeto até aquele momento. Se o gráfi co 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áfi cos 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 fi m etc.

O gráfi co que Henry Gantt criou tornou-se imensamente popular e passou a ser utilizado, sem grandes modifi cações, no gerenciamento de todos os tipos de projetos em todo o mundo.

Uma das desvantagens apontadas era que o gráfi co 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áfi co 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áfi co 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 modifi cações no planejamento acontecem, o gráfi co começa a se tornar confuso. A replanifi cação exige que se faça um novo gráfi co.


157


Unidade 4

Também é outra desvantagem o fato de que o gráfi co de Gantt não apresenta custos das etapas, e difi cilmente 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áfi co de Gantt. Você irá construir uma área de lazer com 30 metros quadrados, churrasqueira, pia e banheiro (e no fi nal da disciplina a gente faz uma festa para comemorar, o que acham?).

Este não é um exemplo de projeto de software, mas é sufi cientemente 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 fi gura 4.7.

Que tal dar o nome a este novo projeto de “Churrasqueira”?

Cada gestor de projeto poderia dividir as tarefas de forma diferente, pois não há uma regra específi ca para isso, a não ser o conhecimento e a experiência particular de cada um.

Proponho então a seguinte divisão:


158


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 fi nal e entrega da obra

Figura 4.10 – Tabela com divisão de tarefas do projeto “Churrasqueira”.


159


Unidade 4

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, é sufi ciente o que está defi nido acima. Considerando essas nove etapas, você pode construir um gráfi co 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 fi gura 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ífi ca. 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áfi co de Gantt do projeto “Churrasqueira”.


160


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 signifi ca 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 fi nal defi nida. Porém, algumas atividades podem ser feitas em paralelo, e nesse sentido é que você pode traçar o primeiro esboço de gráfi co de Gantt, que está apresentado na fi gura 4.13.


161


Unidade 4

Figura 4.13 – Gráfi co de Gantt do projeto “Churrasqueira” – primeiro esboço.

Algo que você pode notar neste gráfi co é 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áfi co, 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áfi co de Gantt deste mesmo projeto está apresentada na fi gura 4.14.


162


Figura 4.13.2 – Gráfi co de Gantt do projeto “Churrasqueira” (assumimos a sequência de atividades defi nidas pelo “mestre de obras”).

Este gráfi co 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áfi co, porém alguém com mais experiência perceberá que o serviço de telhados depende da fi nalização da construção das paredes, e após o telhado fi car 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 fi m, será feita a pintura externa e limpeza geral da obra, e afi nal 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.


163


Unidade 4

No gráfi co anterior foi também preenchido o nome da pessoa da equipe responsável por cada etapa. Desta forma é possível defi nir 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 à fi gura 4.4 perceberá que no modelo seqüencial existe a passagem de uma etapa do trabalho para outra sem alternativa de retorno. Já na fi gura 4.5 se percebe que as atividades de uma etapa podem interferir numa etapa anterior, de tal forma que as duas ocorrem em paralelo (pelo menos em parte), sendo que o que acontece em uma atividade faz com que algumas coisas possam ser aprendidas e interfi ram 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.

�

�

�

�


164


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á defi niu 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 defi niu 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 fi nanceiro, 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 fi nanceiros semanalmente (é a prática na construção civil).

E quanto aos riscos? Você consegue prevê-los?

�

�

�

�


165


Unidade 4

Como você pode ver na fi gura 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 fi nanceiros do contratante, falta de algum material no mercado etc.

Para todos eles devemos pensar em alternativas, pois o sucesso desse projeto está vinculado a uma coisa: cumprir o prazo para a festa.

Volte agora ao gráfi co da fi gura 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áfi cos de Gantt. Você pode criar dependências de quatro tipos entre atividades:

Dependência fi m-início, quando o início de uma Atividade B só é possível após o fi m da Atividade A.

Dependência fi m-fi m, quando o fi nal da Atividade B deve, necessariamente, coincidir com o fi m 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.

�

�

�


166


Dependência fi m-início com folga, quando o início de uma Atividade B só é possível após o fi m da Atividade A, porém há um tempo de folga para o início da Atividade B.

A representação gráfi ca dessas relações de dependências é feita com setas interligando as extremidades das atividades, como você pode ver nas fi guras seguintes:

#��#

#��7

Figura 4.14 – Dependência Fim-Início num Gráfi co de Gantt, onde B depende de A.

#��#

#��7

Figura 4.15 – Dependência Fim-Fim num Gráfi co de Gantt, onde B depende de A.

#��#

#��7

Figura 4.16 – Dependência Início-Início num Gráfi co de Gantt, onde B depende de A.

#��#

#��7

;674�

Figura 4.17 – Dependência Fim-Início com folga num Gráfi co de Gantt, onde B depende de A.

�


167


Unidade 4

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áfi co com escala de tempo. Essa introdução permitiu perceber que as setas poderiam indicar algo mais no gráfi co, e daí em diante um novo conjunto de gráfi cos 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áfi co de Gantt com setas de dependência.

Na fi gura 4.18 você pode ver uma tela gerada pelo jxProject de um projeto exemplo. Na fi gura 4.19 há outro projeto, onde a tela foi gerada pelo Microsoft Offi ce Project.

Figura 4.18 – Exemplo de Gráfi co de Gantt, software jxProject.


168


Figura 4.19 – Exemplo de Gráfi co de Gantt, software Microsoft Offi ce 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 infl uê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 desconfi anç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 desconfi ança e ter o projeto aprovado, foi criada uma equipe especialmente para planejar e fi scalizar 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


169


Unidade 4

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 verifi casse 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:

defi nir 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, verifi car os tempos de folga entre atividades seqüenciadas;

identifi car 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;

�

�

�

�

�

�


170


verifi car 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áfi co 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 fi gura abaixo (fi gura 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 é verifi car qual atividade depende de outra, sua precedente.

No caso do exemplo da fi gura 4.20, você pode ver que a atividade B só ocorre depois de A, e D ocorre depois de B. No entanto, para que a atividade H possa acontecer, necessariamente precisaremos ter concluídas as atividades C e D. Ou seja, o diagrama de setas defi ne 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.

�


171


Unidade 4

As diferenças entre os métodos como o Gráfi co de Gantt e as técnicas PERT/CPM acontecem devido ao tipo de representação e de escala utilizada.

No Gráfi co de Gantt há uma escala de tempo bem defi nida, 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áfi ca entre os diferentes métodos, e então evolua a partir desse ponto.

Na fi gura 4.21 há duas representações para o projeto “Churrasqueira”, que já foi tratado na seção anterior. Na parte superior da fi gura você pode ver o Gráfi co de Gantt, exatamente o mesmo que foi apresentado na fi gura 4.13 (para maior clareza do desenho, retirei as linhas que representam “prazo realizado”).

Na parte inferior da fi gura 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


172


Figura 4.21 – Diagrama de setas com escala e acima o Gráfi co de Gantt do projeto “Churrasqueira”.

O diagrama de setas do projeto “Churrasqueira” da fi gura 4.21 está construído dentro da escala de tempo defi nida no gráfi co 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 fi nal 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 fi nal 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áfi co 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 modifi cações no diagrama de setas do projeto “Churrasqueira”:


173


Unidade 4

Redesenhe o diagrama para que fi que 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 modifi cações simples você terá o diagrama da fi gura 4.22 (Apesar de atividades diferentes, reunimos A,B e C em apenas um arco para simplifi car o diagrama).

Figura 4.22 – Diagrama de setas modifi cado do projeto “Churrasqueira”.

Bem, apesar de ser um desenho limpo, ainda não é sufi cientemente claro para ajudar no planejamento do projeto.

É o momento, agora, de defi nir alguns conceitos e símbolos para construir os diagramas PERT/CPM. Com tais símbolos, apresentados no quadro da fi gura abaixo, você poderá fazer a construção fi nal do diagrama do projeto “Churrasqueira” e partir para sua análise como ferramenta de apoio na gestão de projetos.

�

�


174


Figura 4.23 – Quadro com simbologia e nomenclatura utilizados em diagamas PERT/CPM.

Como se vê na fi gura 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ífi ca da atividade é chamada de “folga”.


175


Unidade 4

A sequência de atividades que defi ne 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 fi gura 4.22. É possível, ainda, simplifi car um pouco mais o desenho. Veja que o nó ao fi nal da atividade D, o nó que dá origem à atividade L e o nó ao fi nal da atividade G podem ser reunidos em um só, sem alterar a ordem das atividades. Assim, o diagrama passaria a ser:

Figura 4.24 – Diagrama PERT/CPM do projeto “Churrasqueira”, simplifi cação 1.

Você sabia que este diagrama pode ser simplifi cado mais uma vez? Veja a seguir como isto pode acontecer:

A seta fantasma que une os nós do fi nal 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 simplifi cado do diagrama, conforme apresentado na fi gura 4.25.

Repare como o diagrama fi cou mais simples e objetivo, e como foi alterado desde o original, que desenhamos na fi gura 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.


176


Figura 4.25 – Diagrama PERT/CPM do projeto “Churrasqueira”, simplifi caçã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 fi gura 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.


177


Unidade 4

Tendo a primeira “data mais cedo” defi nida, 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 fi gura 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 fi gura 4.28.



178


Defi nido 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á dc

70 igual a 43, mas

se consider a atividade IK, teríamos dc70

igual a 48, que é uma data mais tarde do que a defi nida a partir do caminho L. Nesse caso, obrigatoriamente, deve-se assumir essa segunda data, que é o dia 48, dia de início da atividade fi nal M. Com isso o diagrama fi ca assim preenchido:



179


Unidade 4

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 fi nal, então a “data mais tarde” coincide com a “data mais cedo”, ou seja,

dc80

= dt80

= dia da entrega do projeto.

Defi nida a data fi nal 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 fi gura 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 fi gura 4.31, a seguir.


180


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 fi gura 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.


181


Unidade 4

O nó 50 está ligado ao 60 por uma atividade fantasma, que não tem duração. Assim a sua dt

50 será igual à dt

70 , ou seja, 45. E

o nó 30, como fi cará? 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 fi nal. Com isso obtemos o seguinte diagrama:


Para defi nir o nó 20 novamente você deverá fazer uma escolha entre duas opções: iniciar o cálculo a artir de dt

30 ou de dt

40 .

Com dt30

obtemos para o nó 20 a data “25” (dt20

= 25), que é a menor e que será então adotada.

Assim, preenchendo também o nó 10, você chegará ao diagrama PERT/CPM fi nal do projeto “Churrasqueira”, apresentado na fi gura 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


182


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 fi nal do projeto “Churrasqueira”.

Você pode verifi car que no diagrama o caminho de atividades onde não há folga defi ne 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áfi co de Gantt?

Sim, mas é importante perceber que os diagramas são diferentes e complementares para o gestor.

Enquanto no Gráfi co 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.


183


Unidade 4

Para criar diretamente um diagrama PERT/CPM, é necessário partir da tabela de divisão de tarefas, conforme visto no exemplo da fi gura 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 fi gura 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 fi nal do desenho são feitas as simplifi cações. Seguindo esse roteiro você chegará ao diagrama da fi gura 4.34.

ETAPA Projeto CHURRASQUEIRATempo estimado da etapa (dias)

Precedência

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


184


Um dos maiores problemas na montagem desse tipo de tabela será na defi niçã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 bibliografi a (Keeling, 2002) propõe defi nir 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.

�

�

�

�


185


Unidade 4

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 defi niçõ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 defi niçõ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).

�

�

�

�


186


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ífi cas para descrever recursos necessários.

A tabela apresentada na fi gura abaixo é um exemplo de relatório a ser preenchido no início do projeto. Este exemplo partiu de tabela anterior, descrita na fi gura 4.10. Para cada projeto específi co deverá ser construída uma tabela exclusiva, sendo que a coluna dos recursos defi nirá 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

• Montagem das madeiras de caixariaXX dúzias de madeira para 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

• Construção das paredes

XX milheiros de tijolos;

Xx sacos de cimento;

Etc.

• ........ ...........

Figura 4.36 – Divisão de tarefas com estimativa de recursos.


187


Unidade 4

SEÇÃO 5 – Estimativa de custos

A distribuição de custos do projeto é feita num gráfi co chamado de “cronograma físico-fi nanceiro”.

Este deve aproveitar o gráfi co de barras que você viu no Gráfi co de Gantt, sendo que os custos do projeto podem ser distribuídos ao longo do tempo de duração do projeto. Para cada item, defi nido nos recursos estimados para o desenvolvimento do projeto, você deverá fazer uma estimativa de gastos.

O uso do gráfi co de barras é interessante, nesse caso, devido à clareza visual de apresentação.

- Veja um exemplo para entender melhor esse tipo de cronograma.

A fi gura 4.37 apresenta o Gráfi co 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áfi co os valores são anotados, semanalmente.

Figura 4.37 – Estimando custos – cronograma físico-fi nanceiro.

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áfi co. Com tais valores é possível estimar o valor


188


total de custos do projeto, apresentado no canto inferior direito da fi gura. Outra visualização dos custos desse mesmo projeto é apresentada na fi gura 4.38, a qual decorre dos valores obtidos na estimativa do gráfi co de barras.

Figura 4.38 – Gráfi co de linha do cronograma físico-fi nanceiro.

Percebemos pelo gráfi co da fi gura 4.38 que o projeto deverá dispor de recursos fi nanceiros 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 fl uxo.


189


Unidade 4

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 fl uxo de atividades pode ser distribuído em um projeto, de acordo com o tipo de projeto e de suas necessidades específi cas. 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áfi co que apresenta as diversas atividades em forma de barras ao longo do tempo foi desenvolvido por Gantt e fi cou extremamente popular, sendo ainda a base das diversas ferramentas de planejamento, especialmente os softwares recentes como o MSProject, o jxProject e diversos outros. A popularidade do Gráfi co 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áfi co 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.


190


Apesar de a imensa utilidade do Gráfi co 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áfi co permite distinguir num projeto qual a seqüência crítica de atividades, de tal forma que o gestor pode prestar atenção específi ca 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.


191


Unidade 4


1) Considere o seguinte problema: será implantado um novo sistema de qualidade na EMPRESA, e uma equipe interna foi designada para montar o projeto de 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 defi nir 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:

Projeto QualidadePrazos estimados pela equipe de implantação

A -

B -

C -

D -

E -

F -

G -

2) Prepare o Gráfi co 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áfi co 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)


192


Proj

eto

Qual

idad

e

SDSD

SDSD

SDSD

SDSD

A B C D E F G

26 / out25 / out24 / out23 / out22 / out21 / out20 / out19 / out18 / out17 / out16 / out15 / out14 / out13 / out12 / out11 / out10 / out09 / out08 / out07 / out06 / out05 / out04 / out03 / out02 / out01 / out30 / set29 / set28 / set27 / set26 / set25 / set24 / set23 / set22 / set21 / set20 / set19 / set18 / set17 / set16 / set15 / set14 / set13 / set12 / set11 / set10 / set09 / set08 / set07 / set06 / set05 / set04 / set03 / set02 / set01 / set


193


Unidade 4

SDSD

SDSD

SDSD

SDSD

A B C D E F G

26 / out25 / out24 / out23 / out22 / out21 / out20 / out19 / out18 / out17 / out16 / out15 / out14 / out13 / out12 / out11 / out10 / out09 / out08 / out07 / out06 / out05 / out04 / out03 / out02 / out01 / out30 / set29 / set28 / set27 / set26 / set25 / set24 / set23 / set22 / set21 / set20 / set19 / set18 / set17 / set16 / set15 / set14 / set13 / set12 / set11 / set10 / set09 / set08 / set07 / set06 / set05 / set04 / set03 / set02 / set01 / set


194


4) Modifi que o diagrama de setas do exercício 3, simplifi que-o e crie o Diagrama PERT/CPM do mesmo, usando a simbologia aplicada nesta disciplina e reproduzida abaixo.

Desenhe o diagrama passo a passo, calculando para cada nó a “data mais cedo” e posteriormente a “data mais tarde” para cada atividade (use os modelos abaixo para desenhar o diagrama).


195


Unidade 4


196


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


197


Unidade 4

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 – Unifi ed 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 fi ns 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”.


5UNIDADE 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 difi culdades que um gestor pode trazer ao trabalho com projetos quando não se ajusta a um perfi l de liderança criativa.

�

Compreender que, em projetos, as equipes precisam trabalhar com objetivos defi nidos de cooperação e de participação proativa.

�

Seções de estudo

Seção 1 Estruturando a equipe.

Seção 2 Recursos humanos e perfi s.

Seção 3 Treinamento.

Seção 4 Responsabilidade e divisão de tarefas.

Seção 5 Terceirização.


200



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 perfi s 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ífi cos 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.


201


Unidade 5

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 defi nidas 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.


202


A equipe é constituída a partir da defi niçã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 verifi cação: olham currículos e buscam aquelas que preenchem tais requisitos, depois fazem as entrevistas e as análises de perfi l (psicólogos trabalham nisso) e, por fi m, 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. Atividades rotineiras suportam equipes assim, mas penso que projetos não.

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 desafi o (basta ver que muitas vezes os times com os melhores jogadores não ganham o campeonato – algo fi cou 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

A pessoa nesse caso é um agente

que toma decisões e tem liberdade

de ação, ao contrário da máquina.


203


Unidade 5

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 afi nidades 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 fi gura a seguir o diagrama esquemático dessa estrutura.


204


;��A,%8&#9:%

;��B��87�1;�!#

;��C�/�/&'/�<%

;��D�%8&#1!=#9:%

1� ��&��&�� -�� 3��&��

;�� -�� '�� )&��&��

��-��&��&��

�� 3��&�� . ��&��3��

Figura 5.1 – Representação esquemática das fases de estruturação da equipe de projeto.

SEÇÃO 2 – Recursos humanos e perfi s

Como você viu na seção anterior, a escolha de perfi s humanos para trabalhar em uma equipe de projeto está fora da escolha de características exatas, características pré-defi nidas e nas quais algumas pessoas “especiais” se encaixariam. Esse é o campo das relações humanas, relações sempre sutis, delicadas, que variam infi nitamente.

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 perfi s dos gestores, sejam líderes ou não. Mas antes de falar dos gestores/líderes, vamos tentar descrever alguns perfi s típicos das pessoas que virão a fazer parte de nossas equipes de projeto.


205


Unidade 5

Keeling (2002) apresenta diversos tipos de perfi s citando outros autores como Margerison e McCann, que comentam sobre oito diferentes papéis, Belbin, que classifi ca 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 conjunto.

Comunicador. Capaz de comunicar as atividades e de integrar grupos por meio da comunicação.

�

�

�

Essas tentativas de classifi cação muitas vezes caem no vazio, tal é o número de possibilidades e de percepções. Muito provavelmente não é possível ser “científi co” nesse caso, e a classifi cação será local e temporal, ou seja, dependerá do ambiente, da situação e das condições culturais de um determinado grupo.

Pela difi culdade do tratamento “científi co” (se é que isso é necessário), posso fazer uma brincadeira e descrever alguns perfi s que já participaram de projetos junto comigo, e que no decorrer das experiências foram se formando como tipos, facilmente reconhecíveis. Veja alguns:

Desafi ador. O que sempre apresenta as questões e participa dos trabalhos num espírito de desafi o (o que pode ser bom ou ruim, depende da situação e do caso).

�


206


O que está sempre disposto. Esse é o tipo de pessoa que está sempre cheia de energia, e para qualquer atividade que se apresenta, logo já quer sair “fazendo coisas”; tem 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, fi cam 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 difi culdade em ver, claramente, o fi m de cada etapa.

O que fi nge 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 profi ssionais 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 difi culdade 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 perfi l, pois não há grupo que não tenha esse membro (infelizmente); concorda sempre com o superior hierárquico, e inconscientemente se move para fi car à 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

�

�

�

�

�

�


207


Unidade 5

elas são tratadas como geradoras de novas soluções. Contudo há o perfi l 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ó fi ca evidente depois de muito tempo, e muito estrago.

O que não comunica. Comunicação é fator crítico de sucesso em projetos, mas a difi culdade de comunicar com clareza e objetividade é algo muito comum; não estamos livres desse problema, e temos que fi car 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 difi culdade de integração, a difi culdade de melhorar, a difi culdade de achar erros etc.

O que é generalista estratégico. Perfi l diametralmente oposto ao anterior, sempre está olhando o projeto, e qualquer atividade, de um ponto de vista muito genérico; tem difi culdade 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 perfi s problemáticos.

Analisando perfi s problemáticos, você consegue avaliar quem manter e quem evitar em sua equipe de trabalho? Refl ita sobre isso!


208


Por outro lado temos a fi gura do gestor, e variados perfi s 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 fi gura 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 perfi s de membros de equipes de projeto, cabe também apresentar alguns perfi s 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 fi car apenas com algumas notas sobre perfi s 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 fi lmes!). Bem, eu já conheci. Vamos a eles:


209


Unidade 5

Gestor-rinoceronte. Quando você vir aquele gerente andando em passos largos e falando alto na 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 difi culdades, 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


210


Gestor-raposa. Enquanto o tipo “rinoceronte” coordena a equipe de projeto derrubando o que encontra pela frente e o tipo “cobra” coordena a equipe pelo medo do que 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 difi culdade 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 fi m, na defi nição de perfi s 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 defi nir 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 fi gura 5.2, ajuda a perceber os perfi s e como distribuir os papéis. Olhando para a matriz temos a tendência a eleger o “profi ssional F” como líder da equipe, pois tem experiência e dispõe de tempo, enquanto o “profi ssional D” é novo na empresa, e isso pode


211


Unidade 5

gerar algum desconforto. Em domínio técnico vemos que os profi ssionais 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.

Perfi l e necessidades Conhecer tecnologia

“1”

Conhecer tecnologia

“2”

Conhecer tecnologia

“3”

Dominar uso de

“X”

Exp. de trabalho

em equipe

Exp. de trabalho

em equipe

Disp. de tempo

Novo na empresa

Membro da equipe

Profi ssional A X X X

Profi ssional B X X X X

Profi ssional C X X

Profi ssional D X X X X

Profi ssional E X X X X

Profi ssional F X X X

Figura 5.2 – Matriz de perfi s e competências profi ssionais.

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 refl exã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.


212


Esse ambiente de início de industrialização teve espaço no Brasil mais ou menos no meio do século passado, quando grandes indústrias de base foram criadas.

Nosso país, de certa maneira, não evoluiu muito desse ambiente 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 fi gura 5.2. Precisamos de algumas competências específi cas 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 defi nidos e de alcance imediato.

Ainda na matriz da fi gura 5.2, se observa que há perfi s 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 (superfi cial em muitos casos) de oportunizar o surgimento de lideranças.

Treinamentos são criados para esses casos, e gerentes são envolvidos neles.

Nessa época foi criado o Senai, até

hoje responsável por treinamento

de mão-de-obra para esse tipo de

indústria.


213


Unidade 5

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 perfi l, 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 afi rmar 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 especifi cação da sua tarefa. Este é o Modelo de Equipe defi nido no framework da Microsoft (MSF, 1998) quando defi ne papéis em uma equipe. Assim, para cada um, uma tarefa de cada vez.

Para defi nir os papéis e comunicá-los à equipe é importante criar um organograma, defi nindo as funções e a hierarquia dos membros. Há inúmeras possibilidades de estruturar tal organograma, e isso dependerá da complexidade do projeto, da


214


empresa onde a equipe de projeto está sendo montada, de como o projeto interfere nas atividades da empresa, etc. Segundo Keeling (2002), há cinco estruturas típicas de grupos de projetos:

Estruturas diferenciadas e exclusivas.

Estruturas híbridas.

Estruturas matriciais.

Estruturas modulares.

Estruturas horizontais.

Vamos discutir as principais delas e ver como podem se adequar aos nossos projetos.

Estruturas exclusivas

Projetos de pequeno porte, que consigam ter seu 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 fi nal. A fi gura 5.3 apresenta o diagrama desse modelo, que é chamado de estrutura exclusiva porque os membros do projeto são dedicados a um projeto apenas.

��E��F��.��

.��E��.��

��

"��-��=G$8!$6�A "��-��=G$8!$6�B "��-��=G$8!$6�D

Figura 5.3 – Estrutura exclusiva.

1.

2.

3.

4.

5.


215


Unidade 5

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 fi gura 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.

.��

@��

@�� @��

��

.��E��.��

"��-��=G$8!$6�A

"��-��=G$8!$6��

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 fi gura 5.5 apresenta esse tipo de estrutura, onde vemos que diversos projetos ocorrem ao mesmo tempo, sendo que os membros fazem parte das áreas da empresa, e não dos projetos exclusivamente, ou seja, cada funcionário está inserido em determinado setor da empresa e


216


executa serviços que atendem ora a um projeto, ora a outro. Alguém estará responsável pelo projeto, e será defi nido 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.

��.��B

��.��D

��.��

��.��A

.��

@��

@�� @��

��@��

��A@��

��

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.


217


Unidade 5

.��E��.��

4� ��=G$8!$6�A

4� ��=G$8!$6�B

4� ��=G$8!$6�D

��9�1�H�1�

4� ��=G$8!$6�C

��#!48��F��

:

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ífi co, de tal forma que sua ascendência sobre o grupo seja inequívoca.

A fi gura 5.7 mostra exemplo de confi guração de uma estrutura horizontal. O modelo de desenvolvimento de aplicativos da Microsoft (MSF, 1998) também se baseia nesse modelo horizontal, defi nido 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.


218


��E��E��

.��E��.��

��=G$8!$6�A

��=G$8!$6�B

��=G$8!$6�D

�� #6;=H�1�

��41@;!$6

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


219


Unidade 5

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 signifi car 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é-defi nidos.

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 fi cará responsável pelo trabalho externo, ou terceirizado.

A estrutura modular, mostrada na fi gura 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. Identifi car as competências de tais grupos e ter os trabalhos alinhados entre os diferentes grupos é o desafi o.

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.


220


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 (Unifi ed Modeling Language), vêm trazendo um alto grau de profi ssionalizaçã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 qualifi cada, 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.


221


Unidade 5

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 refl ete 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


222


Gartner aponta riscos da terceirização off shore Por COMPUTERWORLD

Empresas de todo o mundo gastarão mais de 50 bilhões de dólares com iniciativas de terceirização off shore (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 profi ssional 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 off shore 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.


223


Unidade 5

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, defi nindo 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 off shore 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 verifi car 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.


224


Síntese

Nesta unidade você estudou os princípios da estruturação de uma equipe de projeto. O conceito fundamental, muitas vezes repetido e exemplifi cado, é 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 perfi s 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 perfi s corretamente, uma técnica interessante é preparar uma matriz de competências, conforme vimos exemplo na fi gura 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á efi caz se as pessoas da equipe têm uma educação de base adequada. Nisto é que se diferencia o treinamento da educação.


225


Unidade 5

Para organizar o grupo de trabalho em diferentes tarefas, cinco modelos estruturais foram apresentados:

1. Estruturas diferenciadas e exclusivas, com pessoas dedicadas exclusivamente ao projeto;

2. Estruturas 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 fi m, 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á!


226



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 perfi s 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?


227


Unidade 5

4) Qual o modelo de estrutura representado na fi gura abaixo? Qual o seu grande problema?

��.��B

��.��D

��.��

��.��A

.��

@��

@�� @��

��@��

��A@��

��

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?


228


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.


6UNIDADE 6

Executando o projeto


Compreender aspectos do início de um projeto e como o seu bom entendimento permite a gerência e o controle efi caz 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 confl itos.

�

Verifi car 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 confl itos.

Seção 8 Simulação, testes e validação.


230



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 difi culdades certamente surgirão. Esta unidade apresenta questões práticas relacionadas com o início do projeto, com os possíveis confl itos advindos do choque entre pessoas da equipe com variados perfi s, bem como as características do gestor do projeto para tratar tais confl itos e difi culdades.

Em especial é debatido o perfi l 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 perfi s podem afetar positiva ou negativamente o desenvolvimento do projeto e mesmo difi cultar a administração de confl itos, 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


231


Unidade 6

de produção de rotina não têm tal fi nalidade 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 refl exã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

�

�

�


232


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 fl uxograma geral (lembra do algoritmo do projeto?) deve ser apresentado, discutido e suas cópias distribuídas. A comunicação dos procedimentos, já discutidos aqui, deve ser feita a partir dessa 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

fi lmes 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 defi nida;

a pauta não for extensa;

os assuntos forem claros e de conhecimento dos presentes;

o horário de começo e fi m forem bem defi nidos;

forem sufi cientemente 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.

�

�

�

�

�

�

�

Se houver a necessidade, consulte

novamente a Unidade 3, Seção 3: Algoritmo do projeto.


233


Unidade 6

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 defi nidas, prazos estabelecidos e resultados por alcançar. Resta cumprir as etapas, já estabelecidas no Gráfi co de Gantt do projeto. Se o planejamento foi bem feito, há uma defi nição bem 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 fi nal. 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 especifi caçõ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)

Consulte unidade 4, seção 2.


234


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 fi cam 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 fi gura 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 fi gura carismática por não concordarem ou não se adaptarem a ela.


235


Unidade 6

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 confi am nele para conduzir o trabalho até o fi nal.

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:

�

�

�

�

�

�

�

�

�

�

�

�


236


a) Conhecimentos desejáveis

Em relação ao conhecimento organizacional o gestor necessita:

ter conhecimento do sistema administrativo e fi nanceiro da organização onde trabalha;

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;

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;

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 signifi ca no tocante aos gastos no projeto e para a empresa;

ter conhecimento das atividades econômicas da organização, dos seus produtos, missões e mercados ou clientes da organização, que signifi ca um conhecimento profundo das atividades econômicas da organização.

Em relação ao conhecimento técnico, o gestor necessita:

conhecer áreas correlatas à especialização de que trata o projeto, com uma visão geral das competências tecnológicas;

ter competência técnica em pelo menos uma área de especialização;

ter domínio de métodos de pesquisa, que permitam relacionar os diversos membros da equipe em um desenvolvimento equilibrado e voltado a resultados.

�

a)

b)

c)

d)

e)

�

a)

b)

c)


237


Unidade 6

b) Habilidades desejáveis

Em relação às habilidades de comando o gestor necessita:

ter a capacidade (e isso deve ser perceptível) de planejamento, organização e controle das atividades do projeto;

desenvolver sua capacidade de liderança (pois consideramos que a capacidade de liderar é inata a todas as pessoas);

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;

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;

capacidade de gerar confi ança no superior e isso se dá pela integridade e pela segurança ao trabalhar orientado a resultados;

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;

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:

trabalhar em equipe, habilidade esta que já comentamos muitas vezes ao longo deste livro e que está relacionada à capacidade de cooperar e gerenciar confl itos;

�

a)

b)

c)

d)

e)

f)

g)

�

a)


238


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;

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;

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:

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;

b)

c)

d)

�

a)


239


Unidade 6

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;

entrosamento com pessoal externo à organização, pois isso é essencial para realizar as interfaces de negociação de requisitos, solicitação de recursos extraordinários, verifi cação de pendências, solução de confl itos diversos etc.;

ambição profi ssional, 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:

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;

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ífi cas 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,

b)

c)

d)

�

a)

b)


240


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 confi anç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

Efi cácia Efi ciê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á junto da parede certa?”

Para o gestor o que importa é: subir rapidamente a escada


241


Unidade 6

Especifi camente sobre lideranças, Christenson (2004) avança ainda mais sobre seus conceitos dividindo-as em quatro diferentes tipos, descritas abaixo:

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;

a que estimula intelectualmente, gerando um alinhamento positivo das idéias das pessoas em relação à organização e ao projeto;

a que infl uencia os ideais, ou seja, estimula seus colegas de trabalho a alcançarem altos níveis de habilidade;

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.

1.

2.

3.

4.


242


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 signifi ca 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, enfi m, 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 confi ança, decidir uma partida.

�

�

�

�


243


Unidade 6

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:

identifi car possíveis modos de ação e chegar a um entendimento comum do que cada opção signifi ca;

identifi car as ramifi cações de cada opção, incluindo vantagens e desvantagens;

discutir e avaliar cada uma dessas ramifi caçõ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, defi nirá 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áfi co de Gantt parece ser fundamental, uma vez que ele utiliza o gráfi co 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áfi co e deve ser acompanhada da marcação sobre o “já realizado” e sobre o que falta realizar.

�

�

�

�


244


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 desafi os. 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 defi nir 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

BÁSICAS

· Fisiológicas

· segurança

· sociais

· Fome, sono, sede

· no emprego, tranqüilidade

· pertencer a grupo, família, amigos

DE CRESCIMENTO· Estima

· auto-realização

· Sensação do trabalho bem feito

· desafi o 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 desafi os e que sabem valorizar o trabalho e o esforço de todos. Gestores sem tais habilidades, sem dúvida, farão projetos fracassarem.


245


Unidade 6

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 defi nir 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 verifi car 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 defi nida e levada aos participantes com antecedência;

o número de itens em pauta deve ser restrito, evitando dispersão e superfi cialidade.

�

�

�

�

�

�


246


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;

defi nir 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 defi nida, pergunte qual é.

�

�

�

�

�

�


247


Unidade 6

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 profi ssional. 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 efi cá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)


248


Como você pode observar, o controle da qualidade passa antes por um conceito do que é o defeito e até onde estamos dispostos a aceitá-lo. Entender o que é defeito nos ajuda a ter 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 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

Identifi caçã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:

o porquê do projeto (onde se apresentam as justifi cativas do trabalho e as causas que o inspiraram);

o quê? (onde o escopo detalhado do trabalho deve ser colocado, defi nindo claramente os resultados esperados);

�

�

�

�

�

a)

b)

Kloppeborg & Petrick, 2004.


249


Unidade 6

quando? (em que é apresentado o cronograma geral do trabalho, defi nindo datas de início e fi m, bem como de interação entre equipe de projetos e cliente/contratante)

quanto custa? (especifi cando o valor global do projeto e medições fi nanceiras parciais, quando necessário)

Quais os riscos? (descrevendo condicionantes e possíveis problemas, capazes de alterar o andamento do projeto, seja em prazos, seja em custos)

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

Defi niçã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 fl uxogramas das fi guras 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 (fi gura 3.5), é possível replanejar o projeto e avaliar as condições de tempo restante e recursos disponíveis e ainda necessários.

c)

d)

e)

f)

�

�

�


250


SEÇÃO 7 – Gestão de confl itos

Como não podia deixar de ser, o trabalho em equipe é, quase sempre, um ambiente de confl itos. Isso acontece devido ao dinamismo dos pensamentos e sentimentos humanos em constante movimento e readequação. Segundo Valeriano (1998), existem três tipos de confl itos:

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 confl itos 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 confl ito, intrapessoal, interpessoal e intergrupos, estão presentes no decorrer dos projetos segundo as seguintes causas potenciais (KEELING, 2002):

na defi nição de cronogramas, quando diferentes interesses tendem a se contrapor na preparação das agendas de trabalho;

na defi nição das prioridades;

na composição dos recursos humanos a trabalhar no projeto, onde afi nidades 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 infi ndável por uns solicitando mais dinheiro e outros negando;

�

�

�

�

�

�

�

�

�


251


Unidade 6

confl itos de personalidade (sobre isso, nem há o que comentar).

No quadro 6.3, abaixo, você poderá observar os confl itos 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 confl itos, adaptada de Valeriano (1998).

Diferenças de objetivos como fonte de confl itos

Indivíduo / profi ssional Organização / gerência

Busca a inovação tecnológica Busca o lucro

Quer autonomia de ação Quer integrar os profi ssionais 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

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 sufi ciente blindagem entre os objetivos mais gerais da organização e os específi cos do projeto que, por sua vez, devem refl etir 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

�


252


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 confl itos em um projeto, então será imprescindível administrá-los. Para Valeriano (1998), há as seguintes possibilidades de se administrar confl itos 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 confl itantes; 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 confl ito é 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 refl exão.

Considerando tais possibilidades, será função do gestor escolher a maneira de lidar com o confl ito. Com certeza a melhor forma de administrar os confl itos se dá quando são percebidos o mais cedo possível. Como muitas doenças, se o confl ito 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.

�

�

�

�

�


253


Unidade 6

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 fi nal 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 fi nalizaçã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 fi nal 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ífi cas, defi nidas inicialmente e que, atingi-las é o objetivo a ser alcançado no fi nal 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á defi nida nos “pacotes diários” e nos “protótipos de prova” do Microsoft Solutions Framework (MSF, 1998). O objetivo é chegar no fi nal 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 uso de simulações computacionais que permitem uma visão do produto, possibilitando fazer testes variados em um ambiente computacional.

Veja sistemas e super-

sistemas no modelo UCP,

fi gura 2.10.


254


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 fi nal 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. Especifi camente 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 verifi ca se os problemas anunciados no escopo estão sendo cuidados;

revisão do projeto, que verifi ca se preenche as especifi cações, os padrões de qualidade e se tem condições de ser implementado;

revisão da programação e do sistema, que verifi ca se os resultados dos testes do protótipo estão adequados;

revisão da aceitação, que verifi ca 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 verifi ca 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 fi nais do projeto.

�

�

�

�

�

�

�

�

�


255


Unidade 6

Simulações, revisões e testes são atividades do dia-a-dia do projeto e, como visto, interferem inclusive no seu fi nal 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 fi nal 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 defi nido previamente. O início do projeto defi ne 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 fi gura do líder aqui defi nida 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 confl itos, mostrar caminhos produtivos e tomar decisões que defi nam rumos para o projeto. Sem dúvida, uma das características fundamentais nessas atividades é a de motivar e inspirar.

Por fi m, 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 fi nal do projeto por meio de vários incrementos parciais bem-sucedidos.


256



1) Dos quatro tipos de líderes defi nidos por Christenson (o que considera os indivíduos, o que estimula intelectualmente, o que infl uencia os ideais, e o que motiva inspirações), qual é, na sua opinião, o mais importante? Justifi que.

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 confl ito entre os indivíduos e as instituições, dando exemplos de sua própria experiência.


257


Unidade 6

4) Quais as formas de administrar um confl ito, 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?


258


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/fl ash/reconectando/ambiente/334/reuniao.htm

O uso de simuladores pode ser importante para verifi car 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ífi cas. 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.


7UNIDADE 7

Finalizando o projeto


Compreender aspectos relativos à fi nalização do projeto, à dissolução das equipes e aos registros documentais do trabalho.

�

Verifi car 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 refl etir sobre elas.

�

Verifi car 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 fi nalizaçã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.


260



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 fi nais, quando então se verifi cará 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 fi gura 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!


261


Unidade 7

SEÇÃO 1 – Fase de fi nalização

A fi nalização do projeto pode acontecer por dois motivos:

o resultado esperado está sendo atingido;

nada deu certo e é melhor fi nalizar 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 fi nal que é o sucesso.

Uma das marcas principais do encerramento do projeto é a data limite, ou prazo fi nal. 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áfi co 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 sufi cientes, 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

a)

b)


262


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 verifi cou 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 fi lmes 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 confl itos 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:


263


Unidade 7

desenvolver um plano de recuperação;

redefi nir 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á confi anç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 difi culdades 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 fi m, reavaliar a liderança, verifi cando 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 verifi car se o líder vai bem.

�

�

�

�

�

�

�

�

�

�


264


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 refi ro expectativas no plural por entender que há aquelas específi cas 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 fi nalidades de cada sujeito neste jogo. A expectativa do cliente deve ser tratada como algo objetivo e deve fi car claro para ambas as partes o que é possível realizar e o que não é.

Chegar ao fi m 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.


265


Unidade 7

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 defi nem 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.

�

�

�


266


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 difi culdades 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.

�

�

�

�


267


Unidade 7

Porém, isso não é sufi ciente, 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).


268


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 especifi cação do navio para introduzir um segundo nível de canhões, mais canhões do que originalmente planejado. Com tais modifi caçõ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ífi ca, 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.


269


Unidade 7

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 fi zeram especifi cações e defi nições para o projeto de forma independente, modifi cando 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, verifi ca-se o exemplar fracasso.

Figura 7.3. Representação da embarcação ao afundar, Museu do VASA (Fairley e Willshire, 2003).


270


SEÇÃO 5 – Desfazendo a equipe

Equipes de projeto podem criar afi nidades de tal monta que, desfazê-las, não é tarefa fácil. Permanecem as afi nidades e o entusiasmo, especialmente se houve sucesso. O encerramento das atividades deve passar por uma avaliação de fi nalizaçã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 desafi os 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 fl oresta, a trilha de pedras que eles deixaram foi seu documento principal, o documento que permitiu que voltassem para casa. Esse era o “caminho das pedras”. No entanto, quando o único material que ele tinha, para documentar o caminho, na segunda vez que entrou pela fl oresta, 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.


271


Unidade 7

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 fi nal 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 fi zeram 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


272


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

Pressão excessiva de prazos

· Estimativas objetivas de prazo

· Mais e melhores recursos

· Priorizações

Mudanças no escopo e nas necessidades· Desenvolvimento interativo

· Modifi car gestão de controle e planejamento

Falta de especifi cações técnicas

· Desenvolvimento de especifi cações prévias

· Atualização das especifi cações com base em eventos

· Indicação de um arquiteto de software

Falta de documentação de planejamento

· Desenvolvimento de planejamento prévio

· Atualizações periódicas e baseadas em eventos

· Indicação de um gestor de projetos

Inovações excessivas ou secundárias

· Maior controle sobre a linha de trabalho

· Análise de impactos

· Gestão contínua dos riscos

Falta de métodos científi cos

· Uso de protótipos

· Desenvolvimento incremental

· Uso de métricas de medição da performance técnica

Ignorando o óbvio · Assimilar as lições aprendidas anteriormente

Comportamento antiético

· Cultura de trabalho baseada em ética nos relacionamentos

· Uso e aderência a códigos de ética formais


273


Unidade 7

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 sufi ciente 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 fi nal;

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 modifi cando no decorrer do tempo e as lições aprendidas foram sendo incorporadas pouco a pouco. No início houve desperdício imenso de recursos fi nanceiros 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ífi cas. 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 fi rmemente para não colocarmos nossos próprios projetos naquela estatística.

�

�

�

�

�

�

�


274


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 difi culdades 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 fi tas 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 fi m, gostaria de encerrar chamando a atenção para a estrutura de negócios da fi gura 7.3, com uma representação em três dimensões onde os eixos defi nem 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.


275


Unidade 7

4��8��:��

��# ��

.��'��%��

��$��

'��

��2��

��$ ��;F-��

��

#� ��

��

��

'��

,��

Figura 7.4. Processos em um ambiente de negócios. Adaptado de Greeff (2005).

O eixo horizontal conecta a cadeia de fornecimento a de relacionamento com o cliente, o vertical estabelece a ligação entre a produção e a administração do negócio e o diagonal apresenta o desenvolvimento do produto e o suporte a ele durante seu ciclo de vida. Se estivermos presos apenas à área de desenvolvimento de novos produtos, estaremos condicionados a um pequeno terreno de idéias de novos projetos. Mas hoje o essencial está nas ligações entre o maior conjunto possível de eixos e a isso poderíamos chamar de gestão dos processos. Projetos podem surgir para interligar o processo de produção no chão-de-fábrica ao ambiente administrativo, por exemplo, e é o que está começando a acontecer, neste exato momento, com a interligação entre a 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!

ERP: iniciais de Enterprise

Resource Planning, que

representa o sistema

computacional integrado

para gestão empresarial,

composto de módulos

diversos como os de

‘contabilidade, fi nanças,

recursos humanos,

compras, orçamentos,

estoques’, entre outros,

facilitando o fl uxo de

informações entre

os departamentos

da empresa visando

a otimização do seu

planejamento.


276


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 desafi o 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!


277


Unidade 7


1) Quais são os passos para implantar um plano de recuperação, em um projeto em crise? Exemplifi que com projetos de sua experiência.

2) Que grandes difi culdades 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?


278


5) Considere seu próprio campo de trabalho e sua experiência profi ssional, e analise a fi gura abaixo. Que nova idéia de projeto, concreta e exeqüível, você pode sugerir?

4��8��:��

��# ��

.��'��%��

��$��

'��

��2��

��$ ��;F-��

��

#� ��

��

��

'��

,��


279


Unidade 7

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.


Para concluir o estudo

Chego ao fi nal 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 desafi a. 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 refl etir 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 fi nal, 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.


282


Por fi m, 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


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 efi cá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. Especifi caçã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).


284


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://offi ceupdate.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.


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ífi cos 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 identifi car 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.


288


5)

Área Exemplo de projetoExemplo de tarefa de rotina ou atividade contínua

Concessionária de energia elétrica Projeto de nova hidrelétrica Operação da hidrelétrica

Software Nova plataforma de e-commerce Manutenção de aplicativo

Indústria Automobilística Desenho de novo lançamento Linha de montagem

BancosCriar nova linha de fi nanciamento e lançar no mercado

Operar carteiras de crédito

Governo Desenvolver sistema de eleição eletrônica

Emissão de títulos eleitorais

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 fi nalidade a geração do conhecimento, a tecnologia é a aplicação de tais conhecimentos. Enquanto os conhecimentos sobre eletromagnetismo e microonda são científi cos, 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


289


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 fi xos atuais. Os sistemas digitais de fi xação de imagens encerraram a carreira das câmeras fotográfi cas tradicionais.

4)

��

��)��

!��0�

"�� # ��

# ��

#��

"��

#�# �%,�>#8/

#88%�?)?

/��0�

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 fi scal de venda, com controle feito por um “responsável” pelo estoque;

Visão ampla: sistema integrado que verifi ca o estoque durante o processo de emissão de propostas, que deve ser atualizada a cada modifi caçã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;


290


• listar o que deve ser determinado pela solução, ou seja, defi nir 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 fl uxogramas;

• verifi car 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 defi na 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 verifi car se as atividades intermediárias foram atendidas. Rever o projeto durante o seu andamento signifi ca reavaliar constantemente o planejamento, bem como redefi nir os objetivos quando necessário. Revisão seja feita apenas no fi nal 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 signifi ca 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ífi co 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.


291


Unidade 4

1)

Programa Qualidade Prazos estimados pela equipe de implantação

A - reuniões do grupo do projeto para defi nir 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)


292


4)

5) Há uma Folga Livre de 11 dias para a atividade E. Neste caso o gestor pode decidir a melhor data para que tal atividade seja executada, otimizando os recursos 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 defi nir 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 defi nir os investimentos fi nanceiros do projeto, pois é possível defi nir os gastos com equipe, de acordo com os custos de hora-homem dos membros escolhidos.

3) Geralmente a estrutura exclusiva, com um organograma bem defi nido, é 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.


293


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 perfi l de “humano”, o intelectual é o que lança desafi os, o que infl uencia ideais e inspirações é o motivador das pessoas.

2) Os quatros passos são: (1) identifi car possíveis modos de ação, (2) verifi car 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 / profi ssional Organização / gerência

Busca a inovação tecnológica Busca o lucro

Quer autonomia de ação Quer integrar os profi ssionais 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.


294


5) O uso de simuladores pode ser importante para verifi car 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;

redefi nir 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 difi culdades 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 fi nal. Os clientes têm difi culdades para defi nir seus requisitos, e muitas vezes têm expectativas exageradas.

�

�

�

�

�

�

�

�

�

�


295


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.

�

�

�

�


gestao de projetos e equipes_livro_completo

Documents