Gerencia de Projetos - UNISUL

Universidade do Sul de Santa Catarina

Palhoça

UnisulVirtual

2007

Gerência de Projetos

Disciplina na modalidade a distância

book.indb 1book.indb 1 31/5/2007 14:23:1831/5/2007 14:23:18

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

Campus UnisulVirtualAvenida dos Lagos, 41 Cidade Universitária Pedra BrancaPalhoça – SC - 88137-100Fone/fax: (48) 3279-1242 e3279-1271E-mail: [email protected]: 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 SulDiretor: Valter Alves Schmitz NetoDiretora adjunta: Alexandra Orsoni

Campus NorteDiretor: Ailton Nazareno SoaresDiretora adjunta: Cibele Schuelter

Campus UnisulVirtualDiretor: João VianneyDiretora adjunta: Jucimara Roesler

Equipe UnisulVirtual

AdministraçãoRenato André LuzValmir Venício Inácio

Avaliação InstitucionalDênia Falcão de Bittencourt

BibliotecaSoraya Arruda Waltrick

Capacitação e Apoio Pedagógico à TutoriaAngelita Marçal Flores (Coordenadora)Caroline BatistaEnzo de Oliveira MoreiraPatrícia MeneghelVanessa Francine Corrêa

Coordenação dos CursosAdriano Sérgio da CunhaAloísio José RodriguesAna Luisa MülbertAna Paula Reusing PachecoCharles CesconettoDiva Marília FlemmingFabiano CerettaItamar Pedro BevilaquaJanete Elza FelisbinoJucimara RoeslerLauro José BallockLívia da Cruz (Auxiliar)Luiz Guilherme Buchmann FigueiredoLuiz Otávio Botelho LentoMarcelo CavalcantiMaria da Graça PoyerMaria de Fátima Martins (Auxiliar)Mauro Faccioni FilhoMichelle D. Durieux Lopes DestriMoacir FogaçaMoacir HeerdtNélio HerzmannOnei Tadeu DutraPatrícia AlbertonRaulino Jacó BrüningRodrigo Nunes LunardelliSimone Andréa de Castilho (Auxiliar)

Criação e Reconhecimento de CursosDiane Dal MagoVanderlei Brasil

Desenho EducacionalDaniela Erani Monteiro Will (Coordenadora)Carmen Maria Cipriani PandiniCarolina Hoeller da Silva BoeingDênia Falcão de BittencourtFlávia Lumi MatuzawaKarla Leonora Dahse NunesLeandro Kingeski PachecoLigia Maria Soufen TumoloMárcia LochViviane BastosViviani Poyer

Núcleo de AcessibilidadeVanessa de Andrade Manoel

Núcleo de Avaliação da AprendizagemMárcia Loch (Coordenadora)Cristina Klipp de OliveiraSilvana Denise Guimarães

Design Gráfi coCristiano Neri Gonçalves Ribeiro (Coordenador) Adriana Ferreira dos SantosAlex Sandro XavierEvandro Guedes MachadoFernando Roberto Dias ZimmermannHigor Ghisi LucianoPedro Paulo Alves TeixeiraRafael PessiVilson Martins Filho

Disciplinas a DistânciaTade-Ane de AmorimCátia Melissa Rodrigues (Auxiliar)

Gerência AcadêmicaPatrícia Alberton

Gerência de EnsinoAna Paula Reusing Pacheco

Logística de Encontros PresenciaisMárcia Luz de Oliveira (Coordenadora) Aracelli AraldiGraciele Marinês LindenmayrJosé Carlos TeixeiraLetícia Cristina BarbosaKênia Alexandra Costa HermannPriscila Santos Alves

Núcleo de Formatura e EventosJackson Schuelter Wiggers

Logística de MateriaisJeferson Cassiano Almeida da Costa (Coordenador)Eduardo Kraus

Monitoria e SuporteRafael da Cunha Lara (coordenador)Adriana SilveiraAndréia DrewesCaroline MendonçaCristiano DalazenDyego RachadelEdison Rodrigo ValimFrancielle ArrudaGabriela Malinverni BarbieriJonatas Collaço de SouzaJosiane Conceição LealMaria Eugênia Ferreira CeleghinRachel Lopes C. PintoVinícius Maykot Serafi m

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

Relacionamento com o MercadoWalter Félix Cardoso Júnior

Secretaria de Ensino a DistânciaKarine Augusta Zanoni Albuquerque(Secretária de ensino)Ana Paula Pereira Andréa Luci MandiraCarla Cristina SbardellaDeise Marcelo AntunesDjeime Sammer Bortolotti Franciele da Silva BruchadoGrasiela MartinsJames Marcel Silva RibeiroJenniff er CamargoLamuniê SouzaLauana de Lima BezerraLiana Pamplona Marcelo José SoaresMarcos Alcides Medeiros JuniorMaria Isabel AragonOlavo LajúsPriscilla Geovana PaganiRosângela Mara SiegelSilvana Henrique SilvaVanilda Liordina HeerdtVilmar Isaurino Vidal

Secretária ExecutivaViviane Schalata Martins

TecnologiaOsmar de Oliveira Braz Júnior(Coordenador)Jeff erson Amorin OliveiraRicardo Alexandre BianchiniRodrigo de Barcelos Martins


Apresentação

Bem-vindo!

Parabéns, você está recebendo o livro didático da disciplina Gerência de Projetos.

O processo de ensino e aprendizagem na UnisulVirtual leva em conta instrumentos que se articulam e se complementam, portanto, 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 EVA (Espaço UnisulVirtual de Aprendizagem);

Atividades de avaliação (complementares, a distância e presenciais).

Os materiais didáticos foram construídos especialmente para este curso, levando em consideração o seu perfi l e as necessidades da sua formação. Como os materiais estarão, a cada nova versão, recebendo melhorias, pedimos que você encaminhe suas sugestões sempre que achar oportuno via professor-tutor ou monitor.

Recomendamos que antes de você começar os seus estudos, verifi que as datas-chave e elabore o seu plano de estudo pessoal, garantindo assim a boa produtividade no curso. Lembre: você não está só nos seus estudos. Conte com o Sistema Tutorial da UnisulVirtual sempre que precisar de ajuda ou alguma orientação.

Desejamos que você tenha êxito neste curso!

Equipe UnisulVirtual.



Mauro Faccioni Filho

Palhoça

UnisulVirtual

2007

Design instrucional

Dênia Falcão de Bittencourt

2ª ed. revista e atualizada


Livro didático


Edição – Livro Didático

Professor ConteudistaMauro Faccioni Filho

Design InstrucionalDênia Falcão de Bittencourt

Projeto Gráfi co e CapaEquipe UnisulVirtual

DiagramaçãoEvandro Guedes Machado

Revisão Ortográfi caB2B

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

658.404F12 Faccioni Filho, Mauro Gerência de projetos : livro didático / Mauro Faccioni Filho; design instrucional Dênia Falcão de Bittencourt. 2. ed. rev. – Palhoça : UnisulVirtual, 2007. 218 p. : il. ; 28 cm.

Inclui bibliografi a.

1. Administração de projetos. I. Bittencourt, Dênia Falcão de. II. Título.

Copyright © UnisulVirtual 2007

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


Palavras do professor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9Plano de estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

UNIDADE 1 – Introdução aos projetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17UNIDADE 2 – Análise do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53UNIDADE 3 – Planejamento e elaboração . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99UNIDADE 4 – a execução do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155UNIDADE 5 – Análise e conclusão do projeto . . . . . . . . . . . . . . . . . . . . . . . . 183

Para concluir o estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207Sobre o professor conteudista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211Respostas e comentários das atividades de auto-avaliação . . . . . . . . . . . . 213

Sumário



Palavras do Professor

Bem vindo!

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


A idéia central desta disciplina é discorrer sobre as principais teorias de gestão de projetos, 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 estudo visa orientar você no desenvolvimento da disciplina. Ele possui elementos que o ajudarão a conhecer o contexto da disciplina e a organizar o seu tempo de estudo.

Ementa da disciplina

O processo de gerência. Modelo PMI. Planejamento do processo de desenvolvimento. Detalhamento das etapas de gerência de um projeto. Ferramentas para a gerência de projeto.

Objetivos

Apresentar os conceitos básicos da área de gerência 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 em reuniões;

Descrever um modelo para gerência de projetos;

Verifi cação dos softwares disponíveis para auxílio no gerenciamento de projetos;

Utilização de software livre para gerência de projetos.


12

Conteúdo programático/tempo de dedicação

Unidade 1 - INTRODUÇÃO AOS PROJETOS. (12 h/a)

História

Conceitos

Motivação para o projeto

Tipos de projeto

Unidade 2 - ANÁLISE DO PROJETO (12 h/a)

Avaliação inicial

Requisitos do cliente e solução de problemas

Algoritmo do projeto

Prazo

Viabilidade do projeto

Antecipando e administrando riscos

Ferramenta de apoio para análise e planejamento

Unidade 3 - PLANEJAMENTO E ELABORAÇÃO (20 h/a)

Modelagem do fl uxo de atividades

Metodologias de planejamento – Gráfi co de Gantt

Metodologias de planejamento – PERT/CPM

Estimativa de recursos e custos

Recursos humanos em projetos

Divisão de tarefas

O modelo PMI


13

Unidade 4 - A EXECUÇÃO DO PROJETO (8 h/a)

Preparação e início dos trabalhos

Liderança versus gestão

Tomada de decisões

Reuniões

Gerenciando qualidade

Gestão de confl itos

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

Unidade 5 - ANÁLISE E CONCLUSÃO DO PROJETO (8 h/a)

Fase de fi nalização

Plano de contingência

Atendendo as expectativas do cliente

Sobre o sucesso (ou fracasso) do projeto

Equipe e documentação

Lições aprendidas e novas idéias


14

Agenda de atividades / Cronograma

Verifi que com atenção o cronograma no “EVA”, organize-se para acessar periodicamente o espaço das disciplinas cursadas. Lembre-se que 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 professor tutor.

Antes de iniciar a realização das atividades de avaliação, leia com atenção os critérios de avaliação apresentados pelo professor tutor no plano de ensino da disciplina no “EVA”.

Não perca os prazos das atividades. Registre no espaço a seguir as datas-chave com base no cronograma disponibilizado no EVA.


15

Atividades obrigatórias

Avaliação a distância (AD)

Avaliação presencial (AP)

Avaliação fi nal (AF)

Demais atividades (registro pessoal)

Tenha por hábito, usar o quadro para agendar e programar as atividades relativas ao desenvolvimento da disciplina.



UNIDADE 1

Introdução aos projetos

Objetivos de aprendizagem

Ao fi nal desta unidade você terá subsídios para: Entender como os projetos se desenvolveram na história da humanidade. Compreender diferenças entre projetos e atividades rotineiras e contínuas.

Constatar quais são os motivos que levam à realização de um projeto.

Aprender os principais conceitos sobre projetos e gerência, bem como tipos de projeto e suas classifi cações.

Seções de estudo

A seguir, apresentam-se as seções para você estudar.

Seção 1 História.

Seção 2 Conceitos.

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

Seção 4 Tipos de projeto.

Após a leitura dos conteúdos, realize as atividades propostas no fi nal da unidade e no EVA.

1


18


Para início de estudo

Esta disciplina o convida a aprofundar um assunto que, em minha opinião, é fascinante: PROJETOS. Você concorda comigo, não é mesmo?

No entanto, saiba que há muitas idéias equivocadas sobre o que seriam projetos, e para evitar que você não corra o mesmo risco, o tema desta unidade é compreender teoricamente qual o conceito moderno de Projetos partindo de suas raízes históricas.

Há várias diferenças entre projetos e tarefas de rotina, assim como há diversos tipos de projetos. Neste estudo, você conhecerá a classifi cação de acordo com modelos hoje aceitos, e também as principais tendências sobre gerência de projetos, com atenção especial ao modelo PMI, que será mais bem descrito ao longo do livro.

Um fator importante é o da motivação para o projeto, que vai defi nir o caminho do seu sucesso, bem como a aderência aos requisitos do cliente e uma classifi cação do projeto, muito útil para seu futuro planejamento. São vários desafi os de estudo, então bom trabalho e boa sorte!

SEÇÃO 1 - História

A palavra “projeto” é muito comum e está presente nos diálogos de todos os dias. Porém, os conceitos que se formaram em sua volta diferem 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 você começar a aprofundar o conceito de projeto no âmbito desta disciplina, é importante conhecer de onde veio essa forma


19


Unidade 1

de trabalho e como tal defi nição vem se modifi cando ao longo da história.

Na história da humanidade o trabalho foi se organizando lentamente.

Tribos nômades andavam pelo planeta há milhares de anos buscando alimentos e lutando contra as adversidades. Com a invenção de alguns artefatos e a domesticação dos animais, o homem passou de nômade a sedentário, tendo começado a construir habitações e aglomerados de casas, formando 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, o homem passou a produzi-lo e estocá-lo. Alguns passaram a deter mais poder do que outros, começaram a poupar objetos de valor e terras, ampliando os domínios terrestres e até mesmo o patrimônio sobre as questões espirituais.

Por essa época, surgem alguns empreendimentos feitos para marcar a presença dessas pessoas poderosas para sempre sobre a Terra.

Todos se lembram das pirâmides do Egito, obras realizadas para sepultar os faraós, considerados deuses. 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.


20


Além dos faraós muitos homens ricos encomendavam suas próprias pirâmides, cada um na medida das suas riquezas. Muitas não fi cavam prontas a tempo, e vin ham então servir para o sepultamento de alguma outra pessoa. As pirâmides eram tipicamente “projetos”.

Uma das mais interessantes e importantes obras já feitas pelo homem começou a ser construída 685 anos antes da Era Cristã. 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). Não havia a China como tal como você conhece hoje, mas sim um conjunto de sete reinos em combate, todos buscando conquistar e anexar os vizinhos. Um desses reinos se chamava Qin (origem do nome atual da China) 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. 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.

Esses são exemplos de grandes projetos da antiguidade que mudaram a história da humanidade e a maneira dos homens agirem uns em relação aos outros e em relação à natureza.

Figura 1.1 - As três pirâmides do Egito, dos Faraós Quéops, Quéfren e Miquerinos.


21


Unidade 1

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 de um dique, o dia a dia das batalhas, ou as 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.

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

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. Além disso, a gerência 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 se conhece 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


22


sido sempre muito criticada e satirizada, como no fi lme “Tempos Modernos” de 1936 de Charlie Chaplin – o Carlitos.

Junto com Taylor trabalhava Henry Gantt (1861-1919), que estudou em detalhes as operações associadas a um trabalho, decompondo-as em tarefas. Para ver as diversas tarefas 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 tarefa 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ê estudará esses gráfi cos em detalhe mais à frente nesta disciplina, e poderá conferir o quanto estes poderão ajudá-lo a gerenciar seus projetos. Na fi gura a seguir, veja um exemplo de gráfi co de Gantt.

Figura 1.2 – Exemplo de gráfi co de Gantt.

O reconhecimento do campo de conhecimento denominado Gerência de Projetos.

Durante a Segunda Guerra Mundial, muitos projetos tecnológicos foram desenvolvidos pelos militares dos países em luta. Com o fi m da guerra, evidenciou-se a existência de um campo do conhecimento específi co da administração de projetos, que fi cou conhecido em inglês por “project management”, e em


23


Unidade 1

português por gerência de projetos, ou gerência de projetos. A maior associação mundial de engenheiros eletrônicos e eletricistas – o IEEE, Institute of Electrical and Electronic Engineers – criou, em 1954, a revista Transactions on Engineering Management especialmente para discutir temas relacionados à gerência de projetos e produção em engenharia, que tem infl uenciado consideravelmente a área.

Também nos anos 50 surgem dois métodos ( CPM e PERT ) que se tornaram muito importantes na “gerência 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).

O primeiro surgiu na empresa Du Pont em 1957, com o título de Método do Caminho Crítico – CPM (iniciais do título em inglês Critical Path Method). 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.

Quase simultaneamente 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 PERT (Program Evaluation and Review Technique), 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).

Tabela 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%


24


Esses dados foram divulgados e criaram polêmica. 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ê irá estudá-lo e exercitá-lo no decorrer desta disciplina.

A evolução dos sistemas computacionais, na segunda metade do século XX, é que vai contribuir para a melhoria dos métodos de gerência 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.

Algumas normas começaram a ser escritas para a gerência de projetos, e nos EUA foi criado o “Instituto de Gerência de Projetos” – PMI (Project Management Institute), o qual tem sido responsável pelas mais recentes e importantes contribuições nesse campo, especialmente o livro “Guide to the Project Management Body of Knowledge”, conhecido como PMBOK (PMBOK, 2004). Você irá estudar o modelo defi nido por esse instituto nas próximas unidades.

Figura 1.3 – Logo do instituto PMI e fac-símile da capa da 3ª. Edição do PMBOK.


25


Unidade 1

Uma alternativa aos métodos normatizados pelo PMBOK foi apresentada por Eliyahu Goldratt em 1997, com o nome de CCPM – Critical Chain Project Management, que pode ser traduzido como “gerência de projetos pelo encadeamento crítico” (RAZ, 2004). Isso demonstra o quanto ainda está em desenvolvimento a área da gerência de projetos.

Mas quem 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, Th e Standish Group realizou uma pesquisa nos EUA e descobriu que muita coisa estava fora do lugar. Conforme reportado pela empresa Process Quality Associates Inc., de acordo com alguns resultados contidos no quadro abaixo, procure ver o quanto ainda há por fazer.

Tabela 1.2 – Estatísticas apresentando problemas típicos de projetos.

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

Atraso Apenas 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

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. É necessário criarmos métodos capazes de auxiliar a gerência de projetos, de um lado, e fazer com que tais métodos não sejam, em si mesmos, empecilhos burocráticos à dinâmica do trabalho.

Uma vez compreendida a história da área gerência de projetos, a próxima seção abordará o estudo de alguns conceitos introdutórios relativos à matéria em exame.


26


SEÇÃO 2 - Conceitos

Antes de você começar a interagir e estudar o conceito de Gerência de Projetos, é importante entender algumas defi nições, tentando evitar equívocos ou interpretações errôneas.

2.1. O que é projeto?

A primeira palavra importante a considerar é, obviamente, “projeto”. No histórico das grandes obras e empreendimentos humanos que você acompanhou na seção anterior, pôde perceber alguns elementos em comum: prazos, objetivos, custos, recursos. Mas a importância desses componentes foi mudando com o tempo.

Por exemplo, 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. Na construção das Muralhas da China ninguém se importava com as equipes de construtores. Morriam trabalhando e eram substituídos depois de se exaurirem, ou seja, ninguém se importava com os recursos humanos.

Com o passar das eras e chegando já nos tempos modernos, pôde-se verifi car 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.

Conforme Antônio Houaiss, em seu dicionário de língua portuguesa (Houaiss, 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.


27


Unidade 1

Neste livro foi adotada uma visão voltada à gerência 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 considerar que a visão de projeto neste livro 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 ressaltar que o projeto tem um ciclo de vida bem defi nido, pois “um projeto sempre tem um começo, meio e um fi nal”.

Qual é a 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, veja na tabela a seguir um determinado campo de trabalho ou área de atividades humanas relacionado a um tipo de projeto, bem como a uma atividade rotineira (que não é projeto).


28


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

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

Culinária Lançamento de um restaurante temático

Administração do restaurante temático

Construção civil Desenhar e construir um prédio comercial

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

Eletrônica Desenvolver novo tipo de condensador eletrônico

Construir telefones celulares

Agricultura Pesquisar planta resistente a determinado tipo de praga

Plantar e colher as safras

Software Pesquisar novo sistema de reconhecimento de fala

Suporte técnico aos usuários de determinada plataforma

Pelo quadro se percebe 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.

2.2. Qual é o conceito de Gerência?

Conforme Houaiss (2004), em seu dicionário de língua portuguesa, gerência pode ser defi nida como: “ato ou efeito de gerir; administração, gerência”

Uma característica de muitas disciplinas dedicadas à gerência de projetos, 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


29


Unidade 1

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 gerência 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.

Desta forma, neste livro, busque olhar a palavra “gerência” visando ir além da gerência operacional, tentando encontrar as brechas para um trabalho de liderança e cooperação, sempre voltadas a 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.

A gerência 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.

Para o estudo desta disciplina, adote uma defi nição mais genérica, que engloba essas atividades, pois assim está sendo compreendida atualmente a função de gerência em projetos.


30


2.3. Qual é a defi nição de Prazo?

Prazo é a palavra do momento. Há uma preocupação enorme com prazos, pois os recursos são sempre escassos, e colocar um produto no mercado antes do que a concorrência pode ser o fator do sucesso.

E justamente nos prazos é onde acontecem os maiores erros de previsão. Por quê?

Você irá estudar isso mais adiante. Por enquanto, refl ita sobre a seguinte defi nição de prazo:

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

resultado.

2.4. Como é a defi nição de recursos na abordagem desta disciplina?

É comum confundir recursos com dinheiro, ou recursos com custos. Porém, extraia deste estudo uma defi nição mais abrangente, pois as condições fi nanceiras possibilitam obter diversos recursos, mas não todos. Veja o caso em que se precisa de um determinado especialista, um engenheiro de grandes estruturas, por exemplo. Mesmo com dinheiro para contratá-lo, é 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.


31


Unidade 1

2.5. E a defi nição de custos?

Idéias maravilhosas, projetos visionários, nada disso pode ser concretizado 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.

2.6. E a Equipe de trabalho?

O principal elemento de um projeto, independentemente de sua dimensão ou importância, é o conjunto de pessoas responsáveis pela sua consecução. Impossível seria construir as muralhas da China sem os milhares de operários que lá estiveram, e no entanto, 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 homem passou a ter “valor”.

Mas projetos (a não ser os muito pequenos) não são para um homem só. Precisam constituir grupos, com atividades e responsabilidades diversas, interagindo todo o tempo e em busca de um objetivo comum. Com isso chega-se ao trabalho cooperativo. Em projeto, é imprescindível a presença de grupos de pessoas trabalhando de forma cooperada. Nesta disciplina, conceba como conceito de equipe de projeto o seguinte:


32


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.

SEÇÃO 3 - Como se dá a 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, chegando a um resultado próximo do esperado, ele precisa de 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ê irá estudar nesta disciplina 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.

São exemplos de motivação:

Alguém em uma pequena empresa teve a “visão” de um novo produto, que 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 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.


33


Unidade 1

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.

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


34


Como se dá o nascimento de projetos de Tecnologia?

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.

Acompanhe a fi gura a seguir, inspirada no trabalho de Jay Paap (2004), que mostra um modelo de inovação tecnológica.

Figura 1.4 - 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 a buscar novas 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.

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.

Cada ciclo tecnológico tem origem numa inovação.


35


Unidade 1

A inovação tecnológica pode ser caracterizada como a primeira vez em 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.

Os processos inovadores 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.

Como melhor conduzir os projetos de inovação tecnológica?

Projetos de inovação tecnológica, nas empresas, podem assumir a metodologia científi ca, onde quatro passos críticos estão colocados para a solução de um problema:

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.

1.

2.


36


Formular hipóteses de solução, que possam ser estudadas e testadas dentro do escopo do trabalho. Nessa 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.

Uma vez compreendidos alguns conceitos introdutórios ao estudo da área de Gestão de projetos, na próxima seção conheça quais são os tipos de projetos.

SEÇÃO 4 - Tipos de projeto?

Os projetos podem ser classifi cados em diversas categorias, e essa classifi cação vai variar conforme os interesses comerciais, científi cos e industriais, ou então conforme os graus de difi culdade, ou mesmo conforme o ambiente em que se desenvolvem.

A seqüência de estudo sugere que você conheça algumas dessas possíveis divisões, e ao fi nal propõe a sistematização dessas classifi cações, de modo a facilitar a visão estratégica sobre tipos de projetos.

Como os projetos podem ser classifi cados? Quais são os tipos existentes?

Os projetos podem ser classifi cados:

De acordo com o que você estudou nas Seções 1 e 2 desta Unidade, eles podem ser classifi cados quanto à natureza científi ca e tecnológica, e neste sentido podem ser, a grosso modo, divididos nos seguintes tipos:

a) 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á

3.

4.


37


Unidade 1

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;

b) 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;

c) 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, mas sim quanto ao tipo de instituição que os 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, novas versões de software e novas formas de entrega para o consumidor são exemplos desse tipo;

a)


38


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 de 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 em 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 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;

De fomento – projetos de fomento são também, em geral, governamentais, mas se distinguem um pouco daqueles por estarem voltados a desenvolver algum aspecto da economia e/ou tecnologia, ou seja, buscam criar ambientes favoráveis para que a iniciativa privada se desenvolva; importantíssimos por sua característica de apoio estrutural, um bom exemplo desse tipo de projeto é a criação de parques tecnológicos e incubadoras de empresas, fomentadores de novos negócios e de inúmeros outros projetos de inovação dentro dessas empresas ou idéias nascentes (cabe aqui ressaltar que a Unisul criou e mantém uma incubadora, com o apoio do governo de Santa Catarina);

b)

c)

d)

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.


39


Unidade 1

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.

É 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 pode ajudá-lo a 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á sucesso, o qual muitas vezes nem era esperado; veja-se o exemplo da 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 é um exemplo;

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;

e)

a)

b)

c)


40


Projetos Derivados – caracterizam-se por ser projetos pequenos e de prazo curto, derivados de outros maiores ou de requisições de melhorias em sistemas já em funcionamento regular; são exemplos as criações de novos leiautes de embalagem, um determinado móvel ou novo dispositivo em uma máquina-ferramenta.

Como defi nir o tipo de projeto tecnológico?

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” (iniciais de Uncertainty, Complexity e Pace, que pode ser traduzido aqui por Incerteza, Complexidade e Prazo), sobre o qual é possível classifi car os diversos tipos de projetos tecnológicos.

O desenho da 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 cada eixo.

Figura 1.5 – Modelo UCP para classifi cação de projetos (DVIR et al., 2004).

Devido a sua utilidade na defi nição dos tipos de projeto, a seguir você irá acompanhar um pouco mais o modelo de Dov Dvir et al, a descrição dos eixos e suas subdivisões.

d)


41


Unidade 1

O eixo da Incerteza apresenta os diferentes níveis de incerteza que um projeto pode assumir, seja quanto ao tempo necessário para sua execuçã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:

a) 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 gerência deve ser rígida e não permitir variações no plano original;

b) 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 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;

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


42


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;

d) Tipo D – Super Alta Tecnologia: esse é 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 abaixo representa as classifi cações no eixo das Incertezas com relação às tecnologias envolvidas.

Figura 1.6 – Eixo das Incertezas no Modelo UCP (DVIR et al., 2004).


43


Unidade 1

O eixo da Complexidade relaciona os diferentes projetos quanto à complexidade do sistema em desenvolvimento, e dessa forma o nível de gerência 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:

a) 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;

b) Nível 2 – Sistemas: os projetos com nível de complexidade maior, que envolvem inúmeros elementos e diferentes equipes, de diferentes empresas e subcontratados, 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;

c) Nível 3 – Supersistemas: 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 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 gerência 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 é apresentado na fi gura a seguir.


44


Figura 1.7 – 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 você estudou 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”:

a) 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;

b) 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,


45


Unidade 1

mas atrasos podem ser o motivo de fracasso em um lançamento e a perda de liderança em determinado mercado;

c) 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 gerência é 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).

Figura 1.8 – 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. Na fi gura a seguir é representada a atual posição do produto e a posição futura numa disposição bidimensional.


46


Figura 1.9 – Exemplo de projeto apresentado no artigo de DVIR et al. (2004).

É importante ter uma compreensão de como os projetos 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 gerência do projeto.

Agora que você já acompanhou a leitura desta unidade, para praticar os novos conhecimentos, realize as atividades propostas a seguir e no EVA.

Atividades de auto-avaliação

Leia com atenção os enunciados e realize as atividades.

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.


47


Unidade 1

2) Com respeito à administração dos projetos ao longo da história, você estudou 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?

3) Na seqüência veja os dois quadros. O primeiro é de um levantamento realizado em 1958, e o segundo tem dados de 1998. Compare os índices, analise se houve mudanças nesse período, e a seguir, descreva suas observações nas linhas em branco.

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)

Atraso Apenas 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


48


4) Considere o quadro a seguir, onde exemplos de projetos são comparados com exemplo de tarefas de rotina. Escreva no quadro alguns novos exemplos para as áreas determinadas.

Á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

5) Veja o diagrama a seguir. Pesquise um produto ou serviço presente no mercado que tenha sido desenvolvido seguindo esses passos, e descreva brevemente as diversas etapas.


49


Unidade 1

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

Considere os seguintes casos, classifi cando-os e marcando no gráfi co:

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


50


Síntese

Nesta unidade você estudou como os projetos se desenvolveram na história da humanidade, e como eles se separaram, primeiro na prática, depois conceitualmente, das atividades rotineiras e contínuas. Aprendeu os principais conceitos sobre projetos e gerência, avaliando os motivos que levam à sua realização.

Alguns tipos de classifi cação de projeto foram apresentados, e o principal deles, o Modelo UCP, atribui níveis de incerteza, complexidade e prazo, o que permite ao gestor uma visão ampla das características do trabalho que o espera.

Com base na motivação do projeto, pode-se passar à fase de análises de viabilidade e planejamento, assuntos da próxima unidade. Até lá!

Saiba mais

Para aprofundar os temas abordados na unidade sugere-se:

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

Links úteis

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

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


51


Unidade 1

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



UNIDADE 2

Análise do projeto


Ao fi nal desta unidade você terá subsídios para: Compreender a importância da avaliação e análise prévia em projetos.

Constatar que os requisitos do cliente defi nem o planejamento geral do projeto, que deve ser elaborado a partir de um algoritmo.

Analisar a questão dos prazos, sua infl uência na viabilidade de um projeto, e quais os riscos inerentes ao processo.

Conhecer algumas das ferramentas computacionais que apóiam o planejamento dos projetos.

Seções de estudo


Seção 1 Avaliação inicial

Seção 2 Requisitos do cliente e solução de problemas

Seção 3 Algoritmo do projeto

Seção 4 Prazo

Seção 5 Viabilidade do projeto

Seção 6 Antecipando e administrando riscos

Seção 7 Ferramenta de apoio para análise e planejamento


2


54



Nesta unidade você irá ver que é fundamental, para o sucesso de um projeto, que seja feita uma análise ampla do problema a ser resolvido. O cliente, aquele que está solicitando o projeto, muitas vezes não consegue mostrar todas as nuances do problema, então uma análise profunda e ampla será necessária.

Junto à defi nição dos motivos do projeto, está o estabelecimento de um “caminho bem planejado” para sua execução, que será traduzido aqui por “algoritmo” do projeto, o qual permite traçar um caminho preciso de execução. Os métodos de planejamento partem desse algoritmo para avaliar os recursos necessários e fazer o planejamento das etapas de desenvolvimento.

Também será analisada a questão do prazo e dos riscos de um projeto que podem ser previstos e, desta forma, criadas alternativas para sua administração. Além disso, muitas ferramentas computacionais têm surgido ultimamente para apoiar o planejamento dos projetos. Ao longo deste estudo você irá conhecer algumas delas e saber como utilizá-las para estabelecer um plano geral.

Ao estudo!

SEÇÃO 1 - Avaliação inicial

Para que os projetos tenham sucesso é preciso ter, antes de tudo, uma visão clara sobre a sua fi nalidade e sobre o 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 forma e possa evoluir ainda há muito que fazer. Quem


55


Unidade 2

encomendou o projeto, quem teve a idéia, quem sentiu a sua necessidade, muitas vezes não sabe exatamente o que quer nem aonde quer chegar. A primeira pergunta que se deve fazer, nesses casos, é:

Qual é o problema?

Você irá se 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 a 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 clareza sobre o problema a ser resolvido.

- preciso melhorar o tempo de produção desta linha de montagem.

É de fato um “grande” problema, e então seria necessário contar com 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.

- Então, se houvesse um sistema de contagem automático, esse tempo poderia ser reduzido.

Essa automação poderia ser um contador em determinados trechos da esteira, o que já existe no mercado, basta comprar e instalar.

Porém, seria necessário pegar os dados gerados pelo contador e envia-los para o departamento de estoque, onde planilhas são construídas.

Bem, esse processo de análise pode ir bem longe, até se chegar de fato a um problema com uma solução a ser implementada, e para se ter tal solução um projeto será criado.

Parece simples, mas não é.


56


O primeiro passo, o passo fundamental, é transformar o assunto no qual está inserido 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 quando há clareza no problema a ser resolvido.

A isso se denomina escopo do problema.

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 conhecimentos:

adquiridos em etapas de pesquisa e desenvolvimento científi co e/ou;

de engenharia e/ou;

empíricos.

Não parece fácil. Quanto maiores a complexidade e incerteza do projeto a ser trabalhado, maior a necessidade de envolver diferentes membros na equipe, buscando complementaridades.

Da mesma maneira,

para que se aproxime do problema, é preciso criar para ele um modelo de representação.

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 se quer dizer que ângulos diferentes podem ser analisados, e soluções que


57


Unidade 2

estavam fora do alcance de visão do cliente ou da equipe, por exemplo, podem surgir e resolver a questão. Observe a fi gura:

Figura 2.1 – Representação esquemática do problema com abordagem de “visão ampla”.

Na fi gura, você observou 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.

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. Observe a fi gura:

��

��

��

��

��

��

��

�� !��"#�$%


58


Figura 2.2 – Representação esquemática do problema com abordagem de “visão restrita”.

Você percebeu na fi gura, que 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.

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 você a buscar um partido amplo!). Leia com atenção:

��

��

��

��

��

��

��

�� !��"#�$%


59


Unidade 2

Caso 1 – implantaçã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 do 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 desempenho, 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 funcionava bem deveria ser problema com o servidor, então a solução seria 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


60


própria construção do sistema. Bem, se essas perguntas tivessem sido feitas numa etapa bem anterior, talvez as coisas tivessem ocorrido de modo diverso, 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.

Outro caso que também destaca a falta da visão ampla:

Caso 2 – encomenda de um novo “site corporativo”

Estive em certa 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. Isso 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 razoável.

No entanto, o discurso da nova direção era de remodelagem dos seus objetivos, e o foco era estar a par das novas tecnologias e dos novos processos de qualidade, tanto é que fazia questão de participar dos concursos de qualidade regionais, e para

ganhar alguns pontinhos 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, sendo que 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 ainda menor ao 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.


61


Unidade 2

Tanto esse gerente como 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, em um nível tal que o primeiro escrevia e-mails como se fossem ofícios e o segundo mal conhecia as regras do português escrito. Isso não consistia num grande problema no ambiente em que viviam, mas tornou-se 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 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 a 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).


62


Para o assessor de marketing isso também não tinha importância, pois ele cumpriu seu dever e o emprego estava mantido (tempos depois foi promovido!).

No entanto essa visão restrita (e neste caso também mesquinha) fez a empresa dar um passo para trás (talvez irreversível).

Caso 3 – uma gigante da telefonia celular

Assim como nos dois casos anteriores, verídicos, também neste não vou revelar o nome da empresa onde o fato ocorreu (apesar de ser muito fácil adivinhar). E apesar de ter vivido o dia a dia daqueles dois casos, neste último, infelizmente, não tive participação.

Bem, em meados 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

Eu poderia continuar descrevendo casos e mais casos desse tipo de visão restrita aplicada à solução de problemas, e infelizmente parece ser adotada por uma ampla maioria. Temos que lutar contra isso. Deixem-me dar então apenas um exemplo de visão ampla que, mesmo fazendo parte da minoria, pode mudar os rumos de toda uma empresa ou mesmo de um país. Acompanhe:


63


Unidade 2

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.


64


É importante que você observe nesses casos, sejam de sucesso ou de fracasso, algumas características e 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.

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.

Multidiscipli-naridade

Ao mesmo tempo, é difícil ter conhecimento técnico em muitas e variadas áreas, especialmente na atualidade onde há tantas tecnologias que 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 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 antes citados você viu o que signifi cou na contratação do “web site 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).


65


Unidade 2

Por fi m, para completar o estudo desta seção, você deve entender 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 deve acontecer é que defi ne o tipo de visão a ser adotada.

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 desse modo tem uma idéia aproximada daquilo que quer obter. Como acompanhou 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.

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.

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 o 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. Neste sentido, cada etapa de um projeto pode ser vista como um novo


66


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.

Quais os procedimentos para levantar os requisitos básicos do cliente?

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;

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


67


Unidade 2

científi cos, mas também outros impeditivos e limitantes, tais como questões jurídicas, restrições técnicas, restrições ambientais, 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, aplicar hipóteses de solução e desenvolver esquemas gerais e/ou detalhados.

O desenho da fi gura abaixo 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.

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, é possível traçar objetivos de chegada considerando as hipóteses que têm maior chance de sucesso. Esses objetivos 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.

��

��

!��

��

&��

��'��

��(�)��

*��+��

��

��,��,��


68


SEÇÃO 3 - Algoritmo do projeto

O algoritmo é a uma seqüência lógica de passos, que permite modelar um determinado programa, ou projeto, entendidos e defi nidos com exatidão para que o projeto chegue ao resultado esperado. Tendo um objetivo bem defi nido, conforme você estudou na seção anterior, é preciso determinar um fl uxograma genérico de atividades, até o objetivo ser atingido.

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.

Qual é o conjunto de atividades que determina a Gerência de Projeto?

Neste algoritmo, pode-se ver o conjunto de atividades que determina a Gerência do Projeto, as quais são:

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, procurando observar o fl uxo das atividades.


69


Unidade 2

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

Para compreender o que consiste cada etapa, acompanhe a seguir uma breve descrição de cada uma delas:

a) Planejamento das atividades – o planejamento consiste em dividir o objetivo geral do projeto em tarefas, ou pequeno 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 pré-estabelecido.

��,��'��

��,��,��

!��,��

��'��

��'��

��'��

�-�'��

%'��(��

��,��

�'��,��

��$

&��

.��


70


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

c) Obtenção dos recursos – somente com uma boa defi nição de recursos é possível partir para a fase da sua obtençã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 o projeto for empreendido por uma pequena empresa, eles podem ser escassos. Neste caso, recursos externos serão necessários, o que tomará um determinado tempo até serem obtidos. Essa demora não é favorável, por exemplo, nas áreas de alta tecnologia.

d) Integração dos recursos – os recursos podem vir de fontes diferentes, e muitas vezes guardam grandes diferenças entre si. Nesse momento é que são organizadas as equipes, distribuídas as tarefas e feitas as discussões iniciais de repasse de informações.

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


71


Unidade 2

todos. Nesse sentido é que a integração dos recursos assume importante papel, determinante para o progresso do projeto dentro do prazo estipulado.

Arranjos de lay-out 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.

e) Execução das atividades – muitos consideram que o projeto só está de fato em desenvolvimento quando se inicia a execução das atividades. Isto é um grande engano, como você já pôde ver pela quantidade e importância das etapas precedentes, que são etapas preparatórias e de planejamento. A etapa da execução é aquela em que 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.

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

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


72


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

g) 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, poderão acontecer enormes frustrações (fi nanceiras ou de expectativa).

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

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

Se não foram alcançados os objetivos, uma revisão da etapa deve ser feita, indicando possibilidades de modifi cação e retifi cação, que precisam passar então por um replanejamento

��/��,��'��0

��,��

��

��$

&��

!�+-��


73


Unidade 2

para seguir adiante. Satisfeita a condição, vai-se para a próxima etapa até serem alcançados os objetivos gerais do projeto.

h) Encerramento do projeto – encerrar o projeto signifi ca atingir seus objetivos. A fi nalização do projeto não é simplesmente acabar um produto ou compilar um código. O encerramento é uma etapa bem defi nida, na qual 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 encontrados.

Tendo sido bem entendido o algoritmo do projeto, a próxima seção trata de um tema especial para a Gerência de projetos: Prazo.

SEÇÃO 4 - Prazo

Projetos são estabelecidos com prazo determinado. Como você pode perceber, se não houver uma data aproximada para o empreendimento ser encerrado, então não haverá um projeto e sim uma tarefa de rotina.

A defi nição do prazo é algo que nasce a partir dos requisitos do cliente, pois os objetivos por ele defi nidos só têm sentido se forem cumpridos até uma determinada época, na qual então podem ser aplicados.

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 fatores que fazem os projetos terem prazos irreais. Tais prazos irreais à primeira vista são exeqüíveis, porém quando o conjunto de fatores


74


que determina o andamento do projeto entra em jogo, o prazo se perde.

O que leva os projetos a serem assumidos como prazos irreais?

A seguir analise esses quatro fatores geradores de prazos irreais.

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

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.

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 deva estar funcionado em sua empresa em determinado momento, sem buscar saber se tal software sequer existe ou é adaptável.

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


75


Unidade 2

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 pronto, mas devemos controlar esse desejo. Certamente a estimativa dependerá em muito do domínio que se tem da tecnologia empregada no projeto.

3. Compromisso progressivo - Page-Jones atribui uma conotação bastante negativa para esse fator, por considerá-lo 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 sendo mais possível 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, especialmente pelo sentimento de ter sido enganado, e certamente não haverá prazo cumprido.

4. Escala de valores - O que Page-Jones chama de escala de valores está apresentado na fi gura 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.


76


Figura 3.6 – Representação das vantagens relativas de um projeto considerando o prazo (adaptado de Page-Jones, 1990).

Parta do princípio segundo o qual 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 adicional, e os prejuízos começarão a aumentar progressivamente.

Então, o que não fazer no momento de defi nir prazos de um projeto?

Considerando as implicações estudadas, é 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;


77


Unidade 2

discutir em detalhe 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”.

SEÇÃO 5 - Viabilidade do projeto

Você já estudou a origem das idéias de novos projetos, das motivações, dos requisitos do cliente, da visão geral do projeto e do conceito de prazo. 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 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 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 um documento preparado por consultoria externa e análise aprofundada.

Quais fatores analisar ao estudar a viabilidade?

São os seguintes os fatores preponderantes a serem analisados num estudo de viabilidade: benefícios, recursos, custos e tempo.


78


Esses quatro fatores podem ser vistos como elementos inter-relacionados, como apresentado na fi gura a seguir:

Figura 3.7 – Fatores fundamentais na viabilidade dos projetos.

Acompanhe a descrição de cada um deles e suas relações. Procu-re observar 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”.

a) 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 você pode comparar com o que se tinha antes do projeto ter sido realizado.

Veja a seguinte 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).

'�� 1�

��'�� '��


79


Unidade 2

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, está-se falando de benefícios intangíveis, que podem ser tão ou mais importantes que os tangíveis.

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);fi xação de determinada marca como líder de qualidade;sensação de “time vencedor”.

b) 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. Também é importante ressaltar 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.

c) Custos - considerando os recursos materiais e humanos necessários para o desenvolvimento do projeto, recursos fi nanceiros serão necessários para custeá-lo, 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.


80


c) Tempo (Prazo) - lembre-se de que você já estudou a questão da defi nição de prazos 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 acréscimo de confusão.

O projeto é viável?

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, acompanhe um modelo de questionário / relatório, bastante simplifi cado (e subjetivo), para um Estudo de Viabilidade de Projetos.


81


Unidade 2

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 1 – Modelo de relatório para estudo de viabilidade de projetos.


82


Observe que este modelo não esgota todas as possibilidades de análise, pelo contrário. Mas encaminha uma série de questões iniciais, com as quais é necessário você se preocupar para tentar perceber se é viável prosseguir com o desenvolvimento do pro-jeto e contra quais riscos é preciso se 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 deverão ser tratadas.

SEÇÃO 6 - Antecipando e administrando riscos

Os riscos de um projeto já estão lá antes mesmo de ele nascer. Você poderá verifi car como prevê-los com a maior antecipação possível, e então administrar a sua existência (já que não é possível eliminá-los completamente). Você tem que encarar 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.

Os riscos podem ser considerados conforme a probabilidade de ocorrerem e conforme o impacto que terão sobre o projeto, caso ocorram.

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ê terá então de 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


83


Unidade 2

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, que o desenho a seguir apresenta de modo esquemático:

Figura 3.8 – Riscos internos e externos.

Observe que 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. Acompanhe como é identifi cada cada origem:

a) Riscos de origem interna - os riscos de origem interna passam a existir a partir do nascimento do projeto.

��'��2��,��

��'��-��


84


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.

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

Podem ser considerados típicos riscos provocados por 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.


85


Unidade 2

Como agir diante dos riscos?

Com essas considerações sobre origem, probabilidade e impacto dos riscos sobre o projeto, há duas possibilidades de ação:

a) Deixar acontecer e, então, tentar resolver.

b) Antecipar e administrar os riscos.

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 você pode ver na fi gura a seguir:

Figura 3.9 – Antecipando e administrando riscos.

Esse ciclo deve se repetir a cada nova etapa, e os riscos identifi cados devem ser comunicados a todos os participantes do projeto, seja para os de nível inferior, seja para os de nível superior (mesmo que isso possa desagradar).

��'��'��

%��'��

!��,��'��

��

��'��

�� &��


86


O ciclo para o tratamento dos riscos é composto do seguinte:

1. Identifi cação de riscos;

2. análise;

3. planejamento da ação contra esses riscos;

4. controle/eliminação dos riscos;

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

Acompanhe a descrição de cada um deles:

a ) Identifi cação de riscos - esse é o primeiro passo na administração dos riscos, e consiste em sua identifi cação. O modelo apresentado no quadro abaixo aponta diversas causas de riscos e proporciona uma visão do projeto sob a perspectiva de suas ameaças. Essa 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. A partir da sua identifi cação, devem ser descritos com clareza, declarando sua origem e a conseqüência que trarão ao projeto caso aconteçam.

b ) 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 dispender esforços na tentativa de eliminá-lo, esforços esses que devem ser destinados a outras atividades. A inexperiência de uma equipe é, em si, um fator de alto risco num 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).


87


Unidade 2

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

d ) Controle/eliminação dos riscos -identifi cados os riscos, analisados e criados os planos de ação, é 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;


88


integrar-se ao processo global da gerência do projeto.

No quadro 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. Observe:

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:- qual a probabilidade desse tipo de riscos?- qual o seu impacto?

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:- qual a probabilidade desse tipo de riscos?- qual o seu impacto?

Descrição:


89


Unidade 2

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

Descrição:

Riscos quanto ao prazo:- a equipe de projeto é experiente?

Descrição:

Riscos quanto ao prazo:- qual a probabilidade desse tipo de riscos?- qual o seu impacto?

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 2 – Modelo de relatório para estudo de riscos de projetos.

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 com o trabalho que virá pela frente.

SEÇÃO 7 - Ferramenta de apoio para análise e planejamento

Existem atualmente várias ferramentas computacionais para apoio na análise e planejamento de projetos. A seguir, são citadas algumas dessas ferramentas, que poderão ser utilizadas por você para a prática de gerência de projetos.


90


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

Acompanhe 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 site mencionado acima.

“Se você está buscando um Software de Gerência 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,


91


Unidade 2

O mais popular software comercial de gerência é o da Microsoft, e se chama Microsoft Project – MSProject. O MSProject é uma marca registrada e é o produto de maior sucesso hoje da Microsoft depois do Offi ce.

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.

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

Acompanhe a seguir algumas informações gerais sobre esse produto, extraídos do sítio da Microsoft. 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 muito extensa 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.


92


“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 degerenciar 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, “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.”

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.


93


Unidade 2

Esses são outros softwares de gerência 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:

Pert Chart Expert

WBS Chart Pro

Mindmanager

Primavera Team Play

PMOffi ce

Open Project System

Rational Project Manager

PS8

Tassc Estimator Manager

Gantt Project (grátis e disponível em www.ganttproject.org.)

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, ao invés 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.”


94


Agora que você já concluiu a leitura desta unidade, pratique os novos conhecimentos, realizando as atividades propostas a seguir e no EVA.



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


95


Unidade 2

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.

3) Qual a função do algoritmo no planejamento do projeto?

��

��

!��

��

&��

��'��

��(�)��

*��+��

��

��,��,��


96


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


97


Unidade 2

5) Riscos são inerentes a qualquer projeto. Por quê?

Síntese

Nesta unidade, você pôde entender a importância da avaliação e análise prévia em projetos, e como os requisitos do cliente defi nem o planejamento geral do projeto, que deve ser elaborado a partir de um algoritmo. Esse “algoritmo” do projeto permite traçar um caminho preciso de execução, e muitas vezes você terá que utilizar ferramentas computacionais para apoiar o planejamento dos projetos, estabelecendo e desenhando um plano geral.

Você estudou também a importância do prazo e como os riscos podem interferir em um projeto. Se forem antecipados, você poderá criar formas de administrar tais riscos e até mesmo tirar vantagem deles.

Na próxima unidade, você irá estudar e praticar alguns métodos gráfi cos de planejamento de projetos.

Até lá!


98


Saiba mais

Para aprofundar os temas abordados na unidade, sugere-se:

1. Atualmente é importantíssimo estar atualizado sobre o que acontece no Project Management Institute (PMI), que edita o PMBOK e 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 gerência de projetos.

2. Outro local importante no desenho de métodos e teorias sobre a gerência de projetos é a Sociedade de Gerência de Engenharia do IEEE (IEEE Engineering Management Society (EMS). Essa sociedade está no endereço http://www.ewh.ieee.org/soc/ems/, e o sítio do IEEE geral é o www.ieee.org.

3. Algumas revistas muito interessantes sobre a área de gerência 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 Gerência de Tecnologia. Nesse mesmo sítio, você poderá encontrar diversas outras publicações (em inglês) sobre temas de interesse da computação.


UNIDADE 3

Planejamento e elaboração


Ao fi nal desta unidade você terá subsídios para: Conhecer as técnicas de planejamento de projetos.

Analisar essas diferentes técnicas e métodos de planejamento, com exercícios e exemplos práticos.

Aprender a 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.

Aprender a dividir tarefas de projeto entre os membros da equipe.

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 e custos

Seção 5 Recursos humanos em projetos

Seção 6 Divisão de tarefas

Seção 7 O modelo PMI


3


100



Nesta unidade você vai aprender técnicas de modelagem e planejamento de projetos. A primeira delas, e mais antiga, é o Gráfi co de Gantt, que permite colocar em um gráfi co de barras todas as atividades e tarefas, distribuídas ao longo do tempo. A outra técnica é chamada atualmente de PERT/CPM, e permite verifi car quais atividades representam o “caminho crítico” de um projeto, ou seja, aquele que estabelece a seqüência crítica de atividades.

Vocês estudará o papel dos membros da equipe de projeto, e como dividir a tarefa entre eles, visando um trabalho produtivo e um ambiente de cooperação, considerando diferentes estruturas. Saberá ainda como o modelo PMI está presente nas técnicas de gerência de projetos e sua infl uência nas técnicas modernas de gestão.

Bom estudo!

SEÇÃO 1 - Modelagem do fl uxo de atividades

Para que um projeto seja desenvolvido e se obtenham os resultados esperados, é preciso ter uma visão geral que permita avaliar sua viabilidade, os possíveis riscos e suas necessidades gerais. Certamente, durante esse processo de visão geral, 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: o desenvolvimento do projeto.

Para detalhar o projeto, o primeiro passo é a sua modelagem e a defi nição de um fl uxo de atividades. Um modelo de um objeto é uma representação, é uma simplifi cação desse objeto para que você possa entendê-lo de forma abrangente.


101


Unidade 3

Por exemplo, 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 possamos entendê-lo antes de fi car pronto. Ele não é o prédio, é apenas o modelo do prédio. No entanto, a gente 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.

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.

Usa-se os modelos para facilitar a visão do futuro objeto, e ao mesmo tempo usa-se o modelo para ajudar a construir tal objeto, ou seja, o modelo pode lhe ajudar a realizar o projeto e chegar ao resultado fi nal esperado.

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 teríamos 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, não é preciso construir o prédio inteiro para mostrá-lo, basta desenhar um fachada ou construir uma maquete;

é prático e seguro trabalhar com modelos, pois caso as coisas não se afi gurem tão boas, podemos abandonar tudo no começo;


102


graus de precisão dependerão do aprimoramento do modelo, ou seja, conforme a gente queira ter maior precisão de como será o projeto no fi nal, podemos ir aprimorando paulatinamente sobre o próprio modelo;

redução de tempo na análise, pois não precisamos 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 fazer diversos tipos diferentes de modelo para uma mesma coisa; no caso do prédio, podemos representá-lo 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 considere como utilidades dos modelos de representação:

modelos ajudam a PENSAR;permitem COMUNICAR;é possível PREVER;permitem CONTROLAR;nos ajudam a ENSINAR.


103


Unidade 3

Os modelos para apoio a projetos de engenharia e tecnologia, conforme Bazzo (1997) 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) ou em três dimensões (maquetes, esculturas, protótipos).

Figura 3.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 processo ou sistema, sem dispersar a atenção em detalhes de outra ordem, e um bom exemplo disso são os fl uxogramas usados 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.

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.


104


Modelo GRÁFICO – é 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, 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 – como você estudará, o Gráfi co de Gantt é um modelo gráfi co de representação.

Projetos muito pequenos obviamente 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, a casinha tiver algum grau de complexidade maior, é melhor desenhar.

Tendo o modelo em mãos pode-se, então utilizar métodos de planejamento e criar um detalhamento de como se desenvolverá o projeto.

Observe na fi gura 3.2, como se dá o fl uxo do conhecimento durante o desenvolvimento de um projeto tecnológico.

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

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

Como lidar com a escolha dos modelos?

��3��)!��4��

!��) ��

�-�'��)!��)��(��

��

��

��

��

��


105


Unidade 3

A percepção clara de como se dará o desenvolvimento do projeto permitirá uma boa divisão e detalhamento das atividades.

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. 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 é bastante 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


106


construção civil 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.

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, denomina-se tal modelo de seqüencial com solapamento. Conhecimentos e problemas da etapa seguinte interferem positivamente na etapa anterior, obrigando revisões dinâmicas do processo. Projetos de equipamentos ou softwares são exemplos para esse tipo de modelagem.

A situação radical de desenvolvimento de projetos é aquela onde as diferentes etapas estão totalmente entremeadas, 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. O fl uxo de 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.

Nesta seção você interagiu com 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 você poderia dar início a sua operacionalização, e para isso necessitará contar com métodos e ferramentas, assunto da próxima seção.

SEÇÃO 2 - Metodologias de planejamento – Gráfi co de Gantt

Para fazer o planejamento do projeto é 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.

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.


107


Unidade 3

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 3.3 e 3.4 a seguir que mostram uma divisão de tarefas do projeto fi ctício denominado “Exemplo”.

Na fi gura 3.3 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 sejam anotadas as diversas tarefas, e tal ferramenta, muito simples, permite que se escrevam todas as tarefas componentes.

Projeto EXEMPLO

Etapa 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 3.3 – Tabela com divisão de tarefas de um projeto “Exemplo”.


108


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

Figura 3.4 – O mesmo projeto da fi gura 3.3 em uma divisão por árvore de decomposição.

Com esse tipo de divisão de tarefas é possível imaginar e localizar todos os componentes do projeto. A partir dessa divisão você iniciará a construção do planejamento para execução e gestão do projeto.

Como planejar o desenvolvimento do projeto?

Para tal, a seguir você 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.

��

��

$�� '�� (�

��

��

�� 5��4��

6��7 �'��6��8 6��7

�'��


109


Unidade 3

a) 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, distribuindo-as 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 3.5 mostra um exemplo de Gráfi co de Gantt desenhado em planilha (neste caso com o auxílio do MS Excel). Veja que o projeto se estende do dia 14/março até 17/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.

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. Na fi gura veja a barra cinza da Etapa 1 mostrando o andamento do projeto até aquele momento. Se você estiver com o gráfi co nessa posição no dia 21 de março, então perceberá que o projeto está cumprindo seu prazo.

Figura 3.5 – Exemplo de Gráfi co de Gantt.


110


Como você pode ver nesse exemplo, no eixo horizontal apresenta-se um calendário com a escala de tempo pertinente e mais adequada ao projeto (dias, semanas, meses, etc.). No eixo vertical estão incluídas 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 se 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 Grantt 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. Umas das desvantagens apontada era que 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 então 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 grande 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. Também uma desvantagem é 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.

A seguir acompanhe o desenvolvimento de um exemplo simples para aplicação do Gráfi co de Gantt.


111


Unidade 3

Vamos supor a construção de uma área de lazer com 30 metros quadrados, churrasqueira, pia e banheiro. E é um exemplo sufi cientemente comum para explorarmos 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 nos deu o prazo de oito semanas para entregarmos a obra pronta, sendo que todos os materiais para a obra são fornecidos por ele.

Vamos começar fazendo a decomposição do projeto em tarefas, e para isso utilizaremos a decomposição em tabela. Chamaremos este novo projeto de “Churrasqueira”. Proponho a seguinte divisão:

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


112


• 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 3.6 – Tabela com divisão de tarefas do projeto “Churrasqueira”.

Ao analisar a divisão acima percebemos que o projeto não é tão simples como podia parecer à primeira vista, pois há inúmeras tarefas, as quais ainda poderiam ser mais detalhadas.

Por ser um exemplo, fi caremos com o que está defi nido acima. Considerando essas nove etapas vamos construir um gráfi co de Gantt simples e útil para nosso projeto. Vamos começar com uma planilha dividida em nove barras horizontais, onde anotaremos as etapas, e oito colunas onde anotaremos as semanas, como o da fi gura 3.7 abaixo.

Neste desenho incluí algumas divisões para facilitar nosso 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 fi z uma divisão para marcarmos o prazo previsto (Prev) e outra divisão para depois podermos 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 também é ú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.


113


Unidade 3

Figura 3.7 – Planilha para Gráfi co de Gantt do projeto “Churrasqueira”.

O prazo de dois meses parece ser bastante enxuto, então teremos que ser cuidadosos na distribuição dos prazos para termos sucesso. E vejam que neste projeto o sucesso signifi ca acabar antes do dia da comemoração, não sendo admitida outra possibilidade. A equipe que trabalhará conosco 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 estimamos 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 3.8 – Estimando prazos para as etapas do projeto “Churrasqueira”.

Se repararmos nessa estimativa de prazos, chegamos a 13 semanas e 3 dias, o que supera a data fi nal que dispomos. Porém, sabemos que algumas atividades podem ser feitas em paralelo, e nesse sentido é que


114


vamos traçar nosso primeiro esboço de gráfi co de Gantt, que está apresentado na fi gura 3.9, assumindo as dependências ainda de forma muito simplifi cada.

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

Algo que se nota neste gráfi co é que, para adequar o projeto ao prazo total, necessitamos 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. Esse 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 3.10.


115


Unidade 3

Figura 3.10 – Gráfi co de Gantt do projeto “Churrasqueira”.

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 começaremos a pintura externa após a colocação das janelas e portas. Depois da conclusão do piso faremos 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 faremos a pintura externa e limpeza geral da obra.

Este exemplo é obviamente uma suposição de serviço, mas ele espelha exatamente o que ocorre em todos os projetos. Você pode ter muitas dúvidas quando o serviço está por começar, e então é necessário fazer alguns desenhos iniciais e avaliar se será útil a divisão que inicialmente foi pensada. Caso não seja, ou caso você perceba que é possível detalhar um pouco mais, então é importante fazê-lo.


116


No gráfi co apresentado 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.

Volte agora ao gráfi co da fi gura 3.10 para analisar outra característica desse tipo de diagrama. Apesar de você saber que uma atividade deve começar apenas quando outra terminar (como por exemplo, o telhado somente após as paredes e estrutura estarem montadas), isso não está tão 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.

Como são as relações de dependência entre as atividades no gráfi co de Gantt?

É possível serem criadas 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;

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.

1.

2.

3.

4.


117


Unidade 3

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

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

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

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

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

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 chega-se então ao Método do Caminho Crítico (CPM) e diagramas PERT.

��

��

��

��

��

��

��

��

.�#�%


118


SEÇÃO 3 - Metodologias de planejamento – PERT/CPM

Após a Segunda Guerra Mundial, surgiu um projeto do governo norte-americano que acabou causando 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 sabia-se que os prazos e custos de projetos militares eram constantemente estourados (Prado, 1998). Para reverter esse quadro de desconfi ança e ter o projeto aprovado, foi criada uma equipe especialmente para planejar e fi scalizar o seu andamento 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 representação do planejamento do projeto por eles desenvolvida – Program Evaluation and Review Technique - PERT.

O projeto Polaris supreendeu 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 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.

Figura 3.15. Submarino Polaris – extraída de http://stores.ebay.com/The-Silent-Service-Submarine-Store


119


Unidade 3

Aonde se pode aplicar as técnicas PERT/COM?

Entre 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;

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.

Observe o desenho da fi gura a seguir (fi gura 3.16), 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..


120


Figura 3.16 – Diagrama de setas simples com nós, que denotam a conclusão de 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 desse exemplo da fi gura 3.16 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 você precisa 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.

As diferenças entre os métodos como o Gráfi co de Gantt e o as técnicas PERT/CPM acontecem devido ao tipo de representação e de escala utilizadas. No Gráfi co de Gantt existe 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”, nem sempre são evidentes.

Para entender como se dá na prática as técnicas PERT/CPM primeiramente acompanhe uma comparação gráfi ca entre os diferentes métodos, e então evoluirá seu estudo a partir desse ponto.

Na fi gura 3.17 há duas representações para projeto “Churrasqueira”, que você já estudou na seção anterior. Na parte superior da fi gura veja o Gráfi co de Gantt, exatamente o mesmo que foi estudado anteriormente.


121


Unidade 3

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

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

Figura 3.18 – Tabela com lista de atividades.

O diagrama de setas do projeto “Churrasqueira” da fi gura 3.17 está construído dentro da escala de tempo defi nida no gráfi co de barras que está acima dele, como você pode ver. Percebam 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


122


um projeto simples como este o desenho com setas acaba se tornando razoavelmente complexo, e de fato não nos mostra muitas coisas.

Da forma como foi apresentado não lhe parece um modelo diagramático ruim, e que o Gráfi co de Gantt estava bem melhor?

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.

Para você entender melhor isto, veja que a seguir são feitas duas modifi cações no diagrama de setas do projeto “Churrasqueira”:

Redesenho do 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, sob cada seta é colocado o número de dias de sua duração.

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

Com essas duas modifi cações simples se obtem o diagrama da fi gura 3.19 (apesar das atividades A, B e C serem diferentes, estas são reunidas numa seta para simplifi car o diagrama).


123


Unidade 3

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

Que conceitos e símbolos são utilizados nos diagramas PERT/COM?

Para construir os diagramas PERT/COM mais objetivos e limpos são utilizados alguns conceitos e símbolos.

Com tais símbolos, apresentados no quadro da fi gura a seguir, você poderá então 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.

Figura 3.20 – Quadro com simbologia e nomenclatura utilizados em diagramas PERT/CPM.


124


Como você pode ver na fi gura 3.20, alguns novos conceitos estão apresentados, tais como “data mais cedo e mais tarde”, folgas e símbolos com informações:

Data mais cedo (dc) - representa a primeira data onde pode ocorrer o evento.

Data mais tarde (dt) - é a última data em que esse evento pode ocorrer, sem afetar o prazo do projeto.

A “data mais tarde” existe quando há uma folga no projeto, e a folga específi ca da atividade é chamada de “folga”.

A sequência de atividades que defi ne o prazo crítico do projeto, ou seja, aquela seqüência onde alterações implicam alteração do prazo total do projeto, é chamada de “caminho crítico”.

Saiba que você ainda poderia simplifi car um pouco mais o desenho. Observe 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 3.21 – Diagrama PERT/CPM do projeto “Churrasqueira”, simplifi cação 1.

Esse diagrama pode ser simplifi cado mais uma vez. 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


125


Unidade 3

então esses dois nós. Com um pequeno rearranjo das setas e dos nós teríamos então, o desenho simplifi cado do diagrama, conforme apresentado na fi gura 3.22.

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

As ferramentas computacionais fazem isso automaticamente. Acompanhe a fi gura:

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

Tendo agora o diagrama desenhado, o próximo passo será introduzir os símbolos que permitem colocar as informações detalhadas do plano.

Em primeiro lugar se coloca os nós e para cada um se dá um “nome”, neste caso uma dezena para cada nó de forma que, se precisar posteriormente inserir algum novo nó, use a numeração intermediária (ver fi gura 3.23).

Como você pode perceber, todas as datas de início, mais cedo e mais tarde, estão em branco. Veja que é assumida a data mais cedo para o nó 10 como sendo “1”, ou seja, o “primeiro dia” da atividade ABC, e a partir daí conte as datas em dias (mas não há problema se assumir a data mais cedo como “0”).


126


Figura 3.23 – Diagrama projeto “Churrasqueira”, detalhamento 1.

Uma vez que você tenha a primeira “data mais cedo” defi nida, pode-se 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

E assim, fazendo todas as contas até o último nó, você obterá a data fi nal do projeto, como apresentado na Figura 3.24.

Figura 3.24 – Diagrama projeto “Churrasqueira”.

Preenchido completamente o último nó, é possível fazer o caminho inverso do diagrama preenchendo agora a “data mais tarde” de início de cada atividade. A data mais tarde do nó 70, dt

70 , será encontrada subtraindo-se a duração

da atividade M, da seguinte forma:


127


Unidade 3

dt70

= dt80

– duraçãoM

Adotando, assim, o mesmo procedimento para todos os nós, você obterá como resultado a fi gura 3.25, a seguir.

Figura 3.25 – Diagrama PERT/CPM fi nal do projeto “Churrasqueira”.

No diagrama veja que 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.

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 as atividades que podem afetar todo o andamento do projeto.

Nesse sentido é importante ter as duas ferramentas como instrumentos objetivos de apoio ao gestor.

Uma vez compreendido o estudo das seções iniciais desta unidade, você concluiu o estudo de ferramentas de apoio para o planejamento das etapas de um projeto.


128


E uma vez tendo o planejamento realizado e os prazos estimados, é preciso agora estimar os recursos e custos necessários ao projeto. Siga em frente!

SEÇÃO 4 - Estimativa de recursos e custos

Tendo um planejamento do projeto, é possível estimar os recursos necessários para ele. Bem, estimar não é uma ciência exata. DeMarco (1991), propõe algumas defi nições um pouco diferentes, tais como:

Estimativa é a previsão mais otimista que não tem uma probabilidade zero de tornar-se realidade.

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. Precisamos estimar o melhor possível para evitar riscos durante o projeto.

Quais são os recursos necessários a um 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.;


129


Unidade 3

Pessoal – os recursos humanos aparecem como o principal requisito em projetos, especialmente em projetos de tecnologia, na próxima unidade discutiremos este item;

Financeiros – são os custos do projeto, que advém dos gastos relativos a materiais, equipamentos, locações, transportes, pessoal, licenças, fretes, direitos autorais, etc.; a estimativa de custos é o assunto da próxima seção.

Como você já acompanhou, 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 é algo determinante. Para realizar o planejamento se faz uma divisão de tarefas, e essa divisão é o fator que irá permitir estimar recursos, tarefa por tarefa.

Dessa forma se pode partir da tabela onde as tarefas foram divididas e incluir colunas específi cas para descrever recursos necessários.


130


A tabela apresentada na fi gura a seguir é um exemplo de relatório a ser preenchido no início do projeto. Este exemplo partiu de tabela anterior.

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. A próxima etapa é realizar a estimativa dos custos.

Como realizar a estimativa de custos?

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

Aproveita o gráfi co de barras que você estudou 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, é

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

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 paredesXX milheiros de tijolos;Xx sacos de cimento;Etc.

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

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


131


Unidade 3

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

A seguir, acompanhe um exemplo para entender melhor esse tipo de cronograma.

Na fi gura 3.27 é apresentado 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, nesse caso por semana. Sobre o próprio gráfi co os valores são anotados, semanalmente, e se tem aí o CronogramaFísico-Financeiro.

Figura 3.27 – 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 fazemos a somatória, também por unidade de tempo.

A cada semana se chega a um valor total, conforme você pode ver na última linha do gráfi co.

Com tais valores se pode estimar o valor total de custos do projeto, apresentado no canto inferior direito da fi gura.


132


Outra visualização dos custos desse mesmo projeto é apresentada na fi gura 3.28, a qual decorre dos valores obtidos na estimativa do gráfi co de barras.

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

Percebe-se pelo gráfi co da fi gura 3.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.

Uma vez que você compreendeu como realizar a estimativa dos cursos, na próxima seção veja como estruturar os recursos humanos em projetos.


133


Unidade 3

SEÇÃO 5 - Recursos humanos em projetos

Para entender este tema que tal pensar um campeonato de futebol como um projeto:

Em um campeonato de futebol, onde 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. Sabe-se 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, sabe-se 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 do espírito de “time” na equipe. Constituir uma equipe é relativamente fácil, constituir um time, não tanto.

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, há pessoas trabalhando no recrutamento que atuam como máquinas de verifi cação: olham currículos e buscam


134


aquelas que preenchem tais requisitos, depois fazem as entrevistas e as análises de perfi l, 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 (a pessoa nesse caso é um agente que toma decisões e tem liberdade de ação, ao contrário da máquina). Atividades rotineiras até podem suportar equipes assim, mas com certeza projetos não.

Projetos, assim como campeonatos, exigem pessoas que trabalhem em cooperação e que gostem, realmente, de chegar aos resultados com sucesso.

Numa equipe convencional, de rotina, cada um faz a sua função (não precisaria ser assim!). Num 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 é cooperação.

O segundo conceito importante é: objetivo comum.

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 vezes não conseguirão entender essa característica. Essa percepção exige experiência e intuição.

Perceba que aqui se sai do campo das ciências exatas e entra no campo “pantanoso” das relações humanas (nada exatas...).


135


Unidade 3

Quais são os momentos distintos no processo de se estruturar uma equipe para um projeto?

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, 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 do gestor. Veja na fi gura a seguir, o diagrama esquemático dessa estrutura.


136


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

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

E, além da liderança, os perfi s das pessoas que virão a fazer parte de nossas equipes de projeto vão infl uenciar o ambiente de cooperação. Keeling (2002), apresenta diversos tipos de perfi s citando outros autores, tais 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;

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, dependendo da situação ).

Na composição dos membros de uma equipe uma alternativa interessante é criar a matriz de qualidades desejáveis e de funções necessárias em um projeto.


137


Unidade 3

Imagine que você tenha um grupo de pessoas na empresa que possa vir a participar do projeto, e precisa defi nir suas posições. Ao mesmo tempo, sabe-se as competências técnicas e comportamentais necessárias para trabalhar nele. Criar e preencher uma matriz, como a do exemplo da fi gura 3.30, ajuda a perceber os perfi s e a maneira de distribuir os papéis.

Olhando para a matriz se tem 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 gerar algum desconforto. Em domínio técnico se vê 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.

Uma vez que você compreendeu como estruturar os recursos humanos em projetos, na próxima seção aprenda como realizar a divisão de tarefas.

SEÇÃO 6 - Divisão de tarefas

Num projeto as atividades são divididas ao máximo, como você acompanhou na composição de Diagramas de Gantt. A divisão das atividades é feita para se ter clareza dos objetivos e para perceber as entregas parciais. Também no Diagrama de Gantt são atribuídas

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


138


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.

Para a gerência do negócio a meta é o resultado global e a satisfação do cliente, enquanto que para o desenvolvedor a meta é a entrega conforme a especifi cação da sua tarefa.

Segundo Page-Jones (1990), as 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.

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 empresa onde a equipe de projeto está sendo montada, de como o projeto interfere nas atividades da empresa, etc.

Quais são as estruturas típicas de grupos de projetos?

Segundo Keeling (2002), há as seguintes estruturas típicas de grupos de projetos:

estruturas diferenciadas e exclusivas,


139


Unidade 3

estruturas híbridas,

estruturas matriciais,

estruturas modulares,

estruturas horizontais.

A seguir, veja em detalhes como se confi gura cada uma delas, procure entender como elas podem se adequar aos projetos.

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

Figura 3.31 – Estrutura exclusiva.

b) 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 3.32, onde um organograma típico desse modelo de estrutura é apresentado. O gestor do projeto conta com membros dedicados exclusivamente


140


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

Figura 3.32 – Estrutura híbrida.

c) Estruturas matriciais - Estruturas matriciais são bem mais complexas e exigem grande maturidade de trabalho, tanto por parte da empresa como por parte dos membros das diversas equipes. A fi gura 3.33 apresenta esse tipo de estrutura. Veja que diversos projetos ocorrem ao mesmo tempo. Sendo que os membros fazem parte das áreas da empresa, e não exclusivamente dos projetos, ou seja, cada funcionário está inserido em determinado setor da empresa e 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 faz parte de um determinado setor/departamento


141


Unidade 3

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.

Figura 3.33 – Estrutura matricial.

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


142


Figura 3.34 – Estrutura modular.

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


143


Unidade 3

Figura 3.35 – Estrutura horizontal de equipe de projeto.

Uma vez compreendidas as principais técnicas para planejamento de projetos, na seção seguinte conheça em detalhes o modelo do Project Management Institute (PMI).

SEÇÃO 7 - O modelo PMI

Recentemente os trabalhos do Project Management Institute (PMI), dos Estados Unidos, têm sido difundidos em todo o mundo e têm chamado especial atenção dos gestores de projeto. Muitos confundem o PMI com um novo método, ou nova técnica, mas esse instituto tem se dedicado a reunir o conhecimento sobre gestão de projetos e difundi-lo na forma de Normas. Ficou famoso o Guia PMBOK (veja as referências bibliográfi cas ao fi nal deste livro), que é o “Guia do Conjunto de Conhecimentos


144


em Gerenciamento de Projetos” do PMI e atual Norma Nacional Americana ANSI/PMI 99-001-2004.

O Project Management Institute (PMI) foi fundado em 1969 e a primeira versão do seu guia foi publicado em 1987 com o título: “O Conjunto de Conhecimentos em Gerenciamento de Projetos”. Em 1996 foi lançada nova versão, já com o título Guia PMBOK®.

Esse conjunto de conhecimentos é preparado e revisado através de um processo voluntário de desenvolvimento, sendo que a norma é um consenso de especialistas e interessados nos tópicos do gerenciamento de projetos. O Instituto administra o processo de redação e estabelece regras para promover a imparcialidade dos conceitos a serem publicados.

Como resultado, o PMBOK torna-se uma espécie de grande manual da área de gerenciamento de projetos, compilando o conhecimento prático e teórico até o momento atual, servindo de base para gestores e para novos estudiosos.

São nove as áreas do conhecimento em gerenciamento de projetos cobertas pela terceira edição, com os seguintes tópicos e subtópicos (ver PMBOK, 3ª. Edição):

Gerenciamento de integração do projeto

Desenvolver o termo de abertura do projeto

Desenvolver a declaração do escopo preliminar do projeto

Desenvolver o plano de gerenciamento do projeto

Orientar e gerenciar a execução do projeto

Monitorar e controlar o trabalho do projeto

Controle integrado de mudanças

Encerrar o projeto

Gerenciamento do escopo do projeto

Planejamento do escopo


145


Unidade 3

Defi nição do escopo

Criar EAP (Estrutura Analítica do Projeto)

Verifi cação do escopo

Controle do escopo

Gerenciamento de tempo do projeto

Defi nição da atividade

Seqüenciamento de atividades

Estimativa de recursos da atividade

Estimativa de duração da atividade

Desenvolvimento do cronograma

Controle do cronograma

Gerenciamento de custos do projeto

Estimativa de custos

Orçamentação

Controle de custos

Gerenciamento da qualidade do projeto

Planejamento da qualidade

Realizar a garantia da qualidade

Realizar o controle da qualidade

Gerenciamento de recursos humanos do projeto

Planejamento de recursos humanos

Contratar ou mobilizar a equipe do projeto

Desenvolver a equipe do projeto

Gerenciar a equipe do projeto


146


Gerenciamento das comunicações do projeto

Planejamento das comunicações

Distribuição das informações

Relatório de desempenho

Gerenciar as partes interessadas

Gerenciamento de riscos do projeto

Planejamento do gerenciamento de riscos

Identifi cação de riscos

Análise qualitativa de riscos

Análise quantitativa de riscos

Planejamento de respostas a riscos

Monitoramento e controle de riscos

Gerenciamento de aquisições do projeto

Planejar compras e aquisições

Planejar contratações

Solicitar respostas de fornecedores

Selecionar fornecedores

Administração de contrato

Encerramento do contrato”.

Você reparou que os principais tópicos descritos acima estão presentes neste livro, e também que foram descritos algumas das novas tendências em gestão e análises teóricas realizadas em publicações do IEEE (Institute of Electrical and Electronic Engineers).

Para conhecer mais sobre este método, veja ainda nas Unidades deste livro as seções “saiba mais” e as referências bibliográfi cas no fi nal.

Antes, para exercitar os novos conhecimento, realiza as atividades propostas a seguir e no EVA.


147


Unidade 3



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 Qualidade Prazos estimados pela equipe de implantação

A -

B -

C -

D -

E -

F -

G -


148


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.

Projeto QUALIDADE

3) 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?

4) Como uma matriz de perfi s e competência pode ajudar na estruturação de uma equipe?


149


Unidade 3

5) 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?

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


150


7) 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 Gestão de TI e na indústria de softwares?


151


Unidade 3

Síntese

Nesta unidade você estudou modelos e métodos importantes para o gerente de projetos, em especial o gráfi co que apresenta as diversas atividades em forma de barras ao longo do tempo, desenvolvido por Gantt. A popularidade desse tipo de Gráfi co Gantt deve-se à força de sua clareza visual.Recentemente a implantação de setas de precedência interligando as barras aumentou ainda mais a sua qualidade como modelo.

Apesar da 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. Com tais ferramentas de planejamento e análise pode-se chegar a estimativas bastante realistas quanto aos recursos necessários ao projeto, e quais seus custos. O modelo PMI é uma abordagem que apresenta uma visão geral dos aspectos de projeto, considerando a visão particular desse Instituto americano.

Também estudou a questão da formação das equipes de projeto a partir do planejamento em gráfi cos. Você viu 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. Para organizar o grupo de trabalho em difentes tarefas, foram estudados cinco modelos estruturais, que dependerão de cada tipo de projeto a ser trabalhado.

Na próxima unidade você estudará como se dá 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á!


152


Saiba mais

Para aprofundar os temas abordados na unidade sugere-se:

1. Nesta 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. 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 a UML.

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

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

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


153


Unidade 3

5. Entre novamente no sítio da SOFTEX (www.softex.br) e veja os estudos sobre terceirização de mão-de-obra, 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. Ao mesmo tempo, isso tem trazido impacto sobre a “formação de equipes de TI” nos Estados Unidos.



UNIDADE 4

A execução do projeto


Ao fi nal desta unidade você terá subsídios para: Compreender que a preparação correta no início de um projeto permite a gerência e o controle efi caz da qualidade.

Perceber que líderes e gestores podem ser tipos bem diferentes.

Estudar técnicas e práticas para controle de prazos e recursos, para encontros de trabalho, e para gestão de confl itos.

Verifi car que um projeto de sucesso exige etapas de simulação, testes e validação dos resultados intermediários, onde são buscados incrementos de melhoria.

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 Acompanhamento e controle

Seção 7 Gerenciando tempo, recursos e qualidade

Seção 8 Gestão de confl itos

Seção 9 Simulação, testes e validação


4


156



Esta unidade apresenta questões práticas como a partida do projeto, 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 é muito abordado em debates sobre desenvolvimento tecnológico e inovação. Tais diferenças de perfi s podem afetar positiva ou negativamente o desenvolvimento do projeto e, até mesmo difi cultar a administração de confl itos, por exemplo.

Também será tema de estudo, nesta unidade, as simulações e os testes de revisão contínua, facilitando a busca, durante a fase de desenvolvimento do projeto, de conquistas parciais. Tais conquistas parciais é que garantem o resultado esperado do projeto conforme você verá. Então, está preparado? Siga em frente e bom estudo!

SEÇÃO 1 - Preparação e início dos trabalhos

A produção em projetos é uma decorrência do planejamento, pois como você já viu nas demais unidades, o projeto é um trabalho com data marcada para acabar, enquanto as atividades 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 num projeto é preciso sempre ter a visão do conjunto e não apenas das partes. Tendo o planejamento


157


Unidade 4

realizado, os recursos disponíveis, os objetivos claros e o contrato estabelecido junto ao cliente, é que se pode iniciar os trabalhos.

O que fazer para começar o projeto?

Para preparar e começar o projeto é importante você considerar que:

muitas pessoas imaginam que trabalhar em um projeto é imediatamente começar a programar, ou perfurar, ou martelar, ou seja, alguma atividade que demande muito esforço. A energia é despendida logo no começo e, por não se saber onde chegar, logo tudo esvanece e o projeto perde o sentido.

Trabalhar num projeto não é desprender um enorme esforço em direção a um objetivo desconhecido, para parecer que o suor faz o trabalho, pois projeto exige refl exão.

Outros pensam que alguém deve dar as ordens e será este alguém que terá todo o projeto “na cabeça”, basta seguir seus passos. Provavelmente há um responsável e líder num projeto (no entanto este 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, já que o responsável depende inteiramente da sua equipe.

Como o projeto é uma atividade inerentemente coletiva, é preciso 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.


158


Um exemplo de ação neste sentido foi divulgada recentemente, quando um grupo de projetistas inventou uma espécie de jogo em rede 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 – tratava-se de uma brincadeira que fazia do projeto uma diversão em forma de game!

O início de um projeto deve se dar com uma reunião!

Nesta reunião, o escopo do projeto deve ser exposto com a maior clareza possível, discutido em detalhes, o plano de produção deve ser delineado, as tarefas divididas e as responsabilidades atribuídas.

É neste momento que o fl uxograma geral (você lembra do algoritmo do projeto?) deve ser apresentado, discutido e suas cópias distribuídas. A comunicação dos procedimentos, já discutidos, deve ser feita a partir desse contato inicial.

Mas reuniões são muito mal vistas. Você sabe por quê?

As pessoas pensam que reuniões são chatas, que não dizem nada, que o chefe senta na extremidade da mesa para mandar. No entanto,


159


Unidade 4

as reuniões podem ser interessantes, se:

tiverem uma pauta bem defi nida;

a pauta não for extensa;

os assuntos são claros e de conhecimento dos presentes;

o horário de começar e acabar for bem defi nido;

forem sufi cientemente breves;

houver um coordenador, capaz de distribuir a fala entre os diversos presentes;

houver um líder, capaz de decidir quando for necessária uma decisão.

Há empresas que fazem tantas reuniões que as pessoas acham que trabalhar é participar de reuniões, enquanto que outras pessoas acham que a pior coisa do mundo é uma reunião. Nem uma nem outra está correta. Provavelmente é a reunião que está mal conduzida.

Passada a fase das reuniões iniciais, o projeto tem início. Os grupos de trabalho estão com suas atividades defi nidas, prazos estabelecidos e resultados por alcançar. Resta então cumprir tais etapas, já estabelecidas no Gráfi co de Gantt do projeto. Se o planejamento foi bem feito, há uma divisão bem clara de objetivos e atividades e possivelmente com sub-etapas de prazos curtos.

E assim que começam os trabalhos de desenvolvimento, a mentalidade de “uma entrega a cada dia” é estabelecida entre todos os membros da equipe. Com isto, há a sensação comum de que os projetos devem “andar” e que devem estar no prazo.

Orientação a“zero-defeito” e prazos curtos de entregas intermediárias – a Microsoft estabeleceu este conceito como um objetivo de desenvolvimento(MSF, 1998).


160


Na Microsoft, o gerente de projeto Chris Peters considera que a atividade de um projetista não é simplesmente colaborar no projeto para que esse chegue ao resultado fi nal. Ele considera que cada projetista, ao começar seu trabalho, deve estar pensando em “entregar”.

Sobre isso, analise o parágrafo seguinte:

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

Observe que esta citação esclarece a atitude do projetista ao participar de um grupo de trabalho. E com este foco, o trabalho deve ser iniciado.


161


Unidade 4

SEÇÃO 2 - Liderança versus gestão

Nossa sociedade está muito mais acostumada 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

a motivação do trabalho criativo. Muitas vezes isso, de fato, acontece. Conheço vários gerentes que se sentem muito satisfeitos em... mandar.

Mas aqui surge uma dúvida:

Quais são as qualidades esperadas de um gerente de projetos?

No entendimento de Page-Jones (1990), as qualidades de um gerente de projetos são as seguintes:

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;


162


capacidade para comunicar a realidade;

capacidade de pensar e ser inovador;

coragem para tomar decisões.

Tais 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, assim como os membros da equipe confi am nele para conduzir o trabalho até o fi nal.

Quais são os atributos desejáveis em um gerente de projeto?

Em seu livro sobre gerenciamento de projetos, Valeriano (1998) cita Denis Donaire, que considera que os atributos desejáveis em um gerente estão divididos em três grandes áreas: conhecimentos, habilidades e atitudes. Acompanhe a seguir o quadro apresentando cada área.


163


Unidade 4

Quadro 4.1 – Atributos desejáveis para um gerente de projeto

Atributos desejáveisAtributos desejáveisCo

nhec

imen

tos

Conhecimento organizacional

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

precisa 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, isto é, percepção clara de como funciona a organização em suas práticas no dia-a-dia, a política interna das relações e quais os valores considerados por aqueles que trabalham nela;

consciência do custo e das implicações das decisões técnicas, o que implica em reconhecer as relações entre as ações e o que isso implica em gastos no projeto e para a empresa;

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

•

•

•

•

•

Conhecimento técnico

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

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

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

•

•

•


164


Habi

lidad

es

De comando

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

para comandar sua equipe é desejável que desenvolva sua capacidade de liderança;

capacidade de auto-análise, ou seja, constantemente fazer 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; isto se dá pela integridade e pela segurança ao trabalhar orientado a resultados;

escolha do estilo de liderança adequado;

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, que está relacionada à capacidade de cooperar e gerenciar confl itos;

criatividade, especialmente na solução de problemas inesperados e distantes daqueles que foram avaliados como riscos inerentes ao projeto;

capacidade de redigir com clareza, precisão e concisão, que são habilidades relacionadas à capacidade de se comunicar, nev vcessá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 irreal o “gerente” que se dirige aos membros de sua equipe aos berros).

•

•

•

•

Atitu

des

Posicionamento em relação a aspectos internos

e externos

interesse por questões administrativas;

disciplina de trabalho;

entrosamento com pessoal externo à organização;

ambição profi ssional.

•

•

•

•

Estratégia 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.

•

•


165


Unidade 4

Stephen Covey (2005) criou uma ilustração que relaciona diferenças entre liderança e gerência. No quadro a seguir, apresento uma adaptação de tal tabela de acordo com os conceitos desenvolvidos neste livro:

Quadro 4.2 - Diferenças entre liderança e gerência

Diferenças Liderança Gerência

Interesse nas pessoas nas coisas

Trabalha na espontaneidade com a estrutura

Idéias liberação e fortalecimento controle delas e das atividades

Presteza efi cácia efi ciência

Prefere planejar e programar trabalhar sob um programa

Gasto considera como investimento considera como despesa

Trabalho baseado em princípios em técnicas

Procura transformação transação

Poder centrado em princípios utilidade

Procura resolver por discernimento medição

Fazer a coisa certa certas as coisas

Resolve baseado numa direção em rapidez

Pensa em uma linha superior resultados

Tem propósitos métodos

Decide baseado em princípios em práticas

Ponto de vistaPara o líder a pergunta é: “a escada está junto da parede certa?”

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

Fonte: Adaptado de Covey (2005).

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.

Uma vez dado início ao projeto, tendo um planejamento claro das atividades e consideradas as funções de liderança e de gestão, passa-se agora aos detalhes do dia-a-dia do projeto. E um dos pontos fundamentais de qualquer projeto é a tomada de decisão, assunto de estudo na próxima seção.


166


Seção 3 - Tomada de decisões

Hoje, uma grande parte dos textos sobre administração empresarial focaliza o problema da tomada de decisão.

Decidir signifi ca escolher uma opção entre várias e, com isto, 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 tomar 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 na defesa do gol. Sabe-se que os grandes craques de qualquer esporte, especialmente os coletivos, aliam as habilidades pessoais e de relacionamento à capacidade de antever os movimentos do jogo e tomar a decisão que levará ao gol, ao ponto, ao sucesso, enfi m.

Que milagre poderia ser este, 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.

Você já deve ter assistido em algum desses momentos mágicos no esporte, quando o atleta resolve arriscar um difícil movimento, muitas vezes num momento crítico onde a chance da derrota


167


Unidade 4

é enorme e, cheio de confi ança, decidir uma partida. 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 você pôde acompanhar, num projeto há a necessidade da constante avaliação das opções possíveis e disponíveis que, combinada à experiência prévia do decisor, defi nirá as próximas ações.

Seção 4 - Reuniões

Como você já estudou nesta unidade, as reuniões de projeto são muito importantes, pois são momentos especiais de comunicação e decisão. Durante o encaminhamento do projeto, os planos, as discussões e os rumos do trabalho são colocados e precisam ser encarados como ambientes coletivos para o desenvolvimento do próprio projeto.

Como fazer para que a reunião seja bem sucedida?

Para que uma reunião venha a ser bem sucedida, Page-Jones (1990) coloca as seguintes sugestões de ação:

1.

2.

3.

4.


168


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.

•

•

•

•

•

•

2) Durante a reunião deve ser designado um moderador, capaz de controlar as falas e questões;

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 cada item de ação;

distribuir a ata da reunião.

•

•

Tenho certeza que você, ao ler estas linhas, pensou em reuniões em que já tomou parte e que não 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 a sensação do tempo perdido.

Se a reunião não tiver pauta, peça uma. Se não tiver defi nida a hora de acabar, pergunte qual é.

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 no seu bom andamento.


169


Unidade 4

Seção 5 - Gerenciando qualidade

Gerenciar a qualidade é buscar a ausência de erros. Muitas vezes não se presta atenção aos erros e se cria metas de qualidade que podem ser bem baixas para nossa vida social, apesar de parecerem excelentes para a vida profi ssional.

Para contextualizar esta questão do erro, acompanhe a seguir um texto de Philip Crosby, citado por Tom DeMarco (1991):

“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, re-trabalho, 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 como 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.


170


O primeiro passo é adotar uma atitude de prevenção de defeitos. Essa atitude é chamada, simbolicamente, de Defeito-Zero.”

Como você pode refl etir, o controle da qualidade passa antes por um conceito do que é o defeito e até onde estamos dispostos a aceitá-lo.

Quais são os momentos críticos do gerenciamento da qualidade?

Conforme o artigo “Managing project quality” (Kloppeborg & Petrick, 2004), 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 a capacidade de produção da estrutura disponível;

seleção dos recursos necessários;

contrato detalhado do projeto descrevendo:

o porquê do projeto;

o quê;

quando;

quanto custa;

quais os riscos;

como fazer;


171


Unidade 4

os fatores críticos do sucesso, o plano de comunicação, os conhecimentos necessários e os compromissos.

2) Fase de encerramento

defi nição e comunicação do 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).

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 de cada etapa é possível replanejar o projeto e avaliar as condições do tempo restante e recursos disponíveis e ainda necessários.

Seção 6 - 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.

Quais são os tipos de confl itos?

Segundo Valeriano (1998), existem três tipos de confl itos:

o de ordem intrapessoal, que ocorre em cada indivíduo, consigo mesmo;

interpessoal, que ocorre entre diferentes indivíduos;


172


intergrupos, que se dá entre diferentes grupos.

Esses confl itos estão presentes em todos os ambientes sociais, sejam de trabalho, familiar ou de comunidades em geral e, obviamente, estão presentes nas equipes de projeto, as quais muitas vezes estão reunidas por um pequeno período de tempo e de forma muito intensa, a potencializar estas relações.

Esses três tipos de confl ito, intrapessoal, interpessoal e intergrupos então presentes no decorrer dos projetos segundo as seguintes causas potenciais (KEELING, 2002):

na defi nição de cronogramas;

na defi nição das prioridades;

na composição dos recursos humanos para trabalhar no projeto;

opiniões técnicas e de desempenho;

procedimentos administrativos;

custos;

confl itos de personalidade.

No quadro 4.3 a seguir, você poderá observar quais são os confl itos em projetos como os oriundos de diferenças entre os indivíduos e as organizações devido aos seus diferentes objetivos.

Quadro 4.3 - Fontes de confl itos

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.

Fonte: Adaptada de Valeriano (1998).


173


Unidade 4

Você percebeu como são interesses e objetivos diferentes: indivíduo e organização!

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

Num projeto, isto pode ser a fonte de um grande fracasso e o gestor do projeto deverá saber criar sufi ciente blindagem entre os objetivos mais gerais da organização e os específi cos do projeto, que devem refl etir os indivíduos que o compõem.

Há organizações que trabalham orientadas para projetos, porém com a mentalidade de organização tradicional. Não será possível vencer a contradição, se não houver um repensar de seus 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 reengenharia e gestão por projetos e fracassam logo em seguida sem saber o porquê. A orientação a projetos é uma orientação às pessoas, eis a resposta.

No entanto, não estaremos livres de confl itos em um projeto, então será necessário administrá-los.

Como realizar a administração dos confl itos?

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 juntas alternativas de solução;


174


Comprometimento, que é a busca de soluções alternativas, por parte do gerente do projeto, dando algum grau de satisfação às partes envolvidas;

Acomodação, 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;

Prevalência, que é quando uma das partes prevalece sobre a outra, numa relação ganha-perde;

Retirada, quando o confl ito é deixado de lado, sem solução, o que pode trazer o 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 tratar 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.

Uma vez compreendido como administrar os confl itos durante a gestão dos projetos, na próxima seção acompanhe como realizar o teste e a validação do projeto.

Seção 7 - Simulação, testes e validação

Projetos podem ter resultados melhores se forem testados em etapas, com resultados parciais e não aguardar até o fi nal para ver o que deu certo e o que deu errado. Neste sentido, é importante, para cada etapa e subdivisão do projeto, buscar conseguir um resultado palpável.


175


Unidade 4

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 módulo tenha características específi cas, defi nidas inicialmente e 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 nido nos “pacotes diários” e nos “protótipos de prova” do Microsoft Solutions Framework (MSF, 1998). O objetivo é chegar ao fi nal de cada dia com um protótipo sendo que este deva estar testável. Esse protótipo é compilado e deve funcionar. Passa-se para a etapa seguinte se o pacote diário anterior alcançou o sucesso.

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

Um ótimo exemplo dessa situação 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.


176


A validação do projeto é feita então 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 de um projeto de sucesso.

Segundo Page-Jones (1990), há várias revisões a serem feitas no decorrer do projeto, com testes contínuos e validação a cada etapa.

Quais são as revisões e testes que necessitam ser realizados?

Especifi camente sobre projetos, as revisões e testes, deve-se realizar as seguintes ações:

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;


177


Unidade 4

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.

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.

Agora que você fi nalizou a leitura desta unidade realize as atividades propostas a seguir e no EVA.



1) O que é importante fazer para iniciar um projeto? Explique porque é importante a fase preparação para o início do projeto. Procure comentar com um exemplo que você já vivenciou.


178


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.


179


Unidade 4

4) Quais as formas de administrar um confl ito e qual delas melhor se adapta ao seu estilo de gestão? Por que esta 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?


180


Síntese

Nesta unidade, você viu como os preparativos iniciais do projeto devem ocorrer e quais atividades são importantes para que a produção tenha início acompanhando o planejamento defi nido previamente.

Você pôde aprender que o início do projeto pode defi nir 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”.

Também foi analisada a comparação entre as características do gestor e as do líder. A fi gura do líder aqui defi nida é a do sujeito capaz de criar ambientes de cooperação e de trabalho criativo. Para isto, 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 podem ser bem sucedidos se o projeto tiver resultados claros a serem atingidos em cada uma de tais etapas.

Na próxima unidade, você estudará as atividades de encerramento do projeto, o processo de documentação dos trabalhos e também da dissolução da equipe e das análises fi nais, para verifi car se os objetivos foram alcançados. Até lá!

Saiba mais


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


181


Unidade 4

decisões importantes e realizações. Acesse o link a seguir e conheça algumas sugestões e práticas para uma boa reunião citadas 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

2. 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 link: 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). 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 apóiam o trabalho de novos projetos.



UNIDADE 5

Análise e conclusão do projeto


Ao fi nal desta unidade você terá subsídios para: 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 às expectativas do cliente, por um lado, e à capacidade de liderança do gestor, por outro.

Perceber que todo trabalho de projeto é uma fonte de aprendizagem, mas para que o aprendizado ocorra será necessário extrair lições e refl etir sobre elas.

Constatar que um projeto pode ser a origem de muitos outros, mas para isto os membros da equipe precisam estar atentos às oportunidades.

Seções de estudo


Seção 1 Fase de fi nalização

Seção 2 Plano de contingência

Seção 3 Atendendo as expectativas do cliente

Seção 4 Sobre o sucesso (ou fracasso) do projeto

Seção 5 Equipe e documentação

Seção 6 Lições aprendidas e novas idéias


5


184


Para início de conversa

As atividades de encerramento do projeto são o objeto de estudo nesta unidade, as quais consideram aspectos diversos como o processo de documentação dos trabalhos e também da dissolução da equipe e das análises fi nais, quando se verifi cará o grau de sucesso ou fracasso, alcançado pelo trabalho.

O sucesso estará ligado à demanda original, vinda do cliente, seja este cliente um contratante externo ou você mesmo. Se a expectativa for atendida, a sensação de missão cumprida estará no ar. Se não, será a frustração do fracasso. Mas com o fracasso, principalmente, se aprende muito, é de onde se pode tirar lições para aproveitar no desenvolvimento dos novos projetos.

Bom estudo!

Seção 1 - Fase de fi nalização

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

(a) as coisas deram certas e o resultado esperado está sendo atingido;

(b) as coisas deram erradas e é melhor fi nalizar antes que piore.

Primeiro considere a opção “a” e deixe 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ê viu isto quando estudou o algoritmo do projeto e foram tratados o acompanhamento e as 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.


185


Unidade 5

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, não haverá prorrogações. Então deveremos trabalhar tendo em vista tal data. O controle disso se dará no preenchimento e na atualização constante do Gráfi co de Gantt, preenchendo-se as atividades “realizadas” e comparando-se com o “previsto”, assim como avaliando-se a cada passo o “caminho crítico” do projeto no diagrama PERT/CPM.

Fechado o projeto, será importante avaliar as estatísticas sobre o tempo gasto, recursos utilizados, os riscos previstos que aconteceram 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 a história do trabalho seja preservada, permitindo a introdução do resultado do projeto num ciclo de 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 de sucesso se transforma num momento triste e, nos de fracasso, uma libertação.

Nas próximas seções você estudará com maior profundidade esses tópicos.


186


Seção 2 - Plano de contingência

Na seção anterior, lembre-se que você interagiu com duas opções, “a” e “b”. Você já estudou a primeira opção e agora chegou a hora de estudar a segunda. Você já viu que em todo fi lme ou brincadeira, caso as coisas saiam erradas, diz-se que:

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 e muda 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 isto ocorre de forma inconsciente. Ninguém gosta de errar.

Para isso, tem-se as ferramentas de planejamento, acompanhamento e controle do projeto (você acompanhou várias neste livro), que devem fazer parte de cada momento de revisão para que se possa perceber 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 este é outro defeito do ser humano, aceitável apenas em questões sentimentais (e 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. Várias ações devem ser tomadas quando um projeto sai dos trilhos rumo ao fracasso.

Quais são as ações corretivas?


187


Unidade 5

Conforme o trabalho de Iacovou e Dexter (2004), são defi nidas as seguintes ações corretivas, tentando remediar a situação:

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;

replanejar o projeto usando métodos de estimativa apropriados e comprovados;

gerenciar as expectativas dos clientes, pois eles 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, como para fornecedores e clientes – isso trará confi ança;

dividir o restante do projeto em pequenas partes ou atividades, facilitando 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 esta 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 ela é capaz de alinhar as diversas forças componentes do projeto rumo ao seu objetivo.

O ponto principal de um plano de contingência, desta forma, é a tomada de decisão.


188


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.

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 isto é apenas propaganda e que ninguém atende exatamente as expectativas do cliente. Provavelmente porque tais expectativas não são bem conhecidas. Nem mesmo pelos 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 nesta simples frase.

Não é fácil compreender como o cliente deseja que o software seja, 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 neste livro ao discutir 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 próprio cliente como para os membros da equipe de projeto, é condição básica para atender expectativas. E digo expectativas no plural, por entender que há


189


Unidade 5

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. Assim,

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 você mesmo. Ao confrontar tal contemplação, tem-se uma medida do sucesso do trabalho.

Seção 4 - Sobre o sucesso (ou fracasso) do projeto

O projeto foi entregue no prazo, gastou-se 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... bem, temos 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.

Para seqüência deste estudo, imagine, porém, a situação inversa: o fracasso. Todos queremos evitá-lo e, mesmo quando houver um fracasso, precisamos aprender com ele para crescer. Não há vitorioso que não tenha fracassado alguma(s) vez(es).


190


Como você pode se 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 têm 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 atendido, tem-se indícios de fracassos.

No entanto, você pode 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 acima do prazo estipulado.

São exemplos desse tipo a Ópera de Sydney, na Austrália e o Eurotúnel, que liga a Inglaterra e França.

No entanto, quem ousaria hoje dizer que são fracassos? Do ponto de vista dos custos e dos prazos, foram. Mas os benefícios aparentemente superam em muito essas falhas.

Estes são casos de projetos estratégicos e visionários, que são considerados no início como equivocados ou previamente fracassados. Com o passar do tempo, percebe-se 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.


191


Unidade 5

Figura 5.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 este motivo, boa parte dos estudos recentes sobre gestão de projetos tem se voltado a analisar tais casos e o interesse sobre os trabalhos do PMI (Project Management Institute) é sintomático de uma realidade de mercado.

Segundo Page-Jones (1990), 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 ataca exatamente o ponto: os problemas relativos a projetos não estão nas questões técnicas e tampouco em atrasos ou gastos, pois, estes são conseqüências de um problema maior: o fracasso da gestão.

Como evitar o fracasso da gestão?


192


Pode-se evitar fracassos, conforme Keeling (2002), com:

melhor avaliação de viabilidade;

análise de riscos criteriosa;

uso de métodos de planejamento;

uso de sistemas de controle.

Porém, isto 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 isto, quero dizer que é preciso ter liderança para que um projeto aspire ao sucesso.

Para encerrar esta seção, acompanhe um caso famoso de fracasso, motivo de estudos e pesquisas dos interessados em administração sobre o projeto de construção de uma embarcação de guerra, no século XVII.


193


Unidade 5

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 história seguinte.

Figura 5.2. Representação em escala reduzida, Museu do VASA (Fairley e Willshire, 2003).

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 este 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 e 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.


194


Além disso, o mestre construtor, Henrik Hybertson, faleceu, deixando 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 quê 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.

Muita discussão foi feita 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.

Os erros, porém, foram bem mais graves do que esses e pode-se considerar os seguintes detalhes:

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;

ênfase na elegância e no poder de fogo e pouca importância à estabilidade e navegabilidade;

excesso de pressa na construção do barco e pouca atenção a 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;

1.

2.

3.


195


Unidade 5

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;

três pessoas diferentes 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);

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;

o rei não tinha conhecimentos técnicos para o problema proposto e, mesmo assim, interferiu no projeto como seu chefe supremo.

Este conjunto de fatores gerou esse fracasso exemplar.

Seção 5 - Equipe e documentação

Equipes de projeto podem criar tal afi nidade e desfazê-las não é fácil. Ficam as afi nidades e o entusiasmo, especialmente se há sucesso. O encerramento das atividades deve passar por uma avaliação de fi nalização. Uma discussão franca sobre erros e acertos, especialmente no que se refere ao modelo de gestão adotado, bem como ao dia-a-dia da equipe, trará benefícios e crescimento a todos.

Reconhecimento dos méritos: eis uma obrigação.

Há muitos casos de projetistas que empenham horas de esforço e imaginação num projeto e sabemos que não são apenas aquelas horas que estão escritas lá na planilha. Estas horas são doações espontâneas daqueles que gostam de desafi os e almejam sempre a qualidade e a realização. O reconhecimento disto deve

4.

5.

6.

7.


196


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 consideram que realizar o trabalho é a obrigação de cada um. Tomara que você não encontre um desses pela frente!

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 ele deixou foi seu documento principal, o documento que permitiu que ele voltasse para casa. Este 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 ele se perdeu. Esta documentação era efêmera.

A memória é uma documentação efêmera.

A documentação não é adequada se não for clara, estiver arquivada, acessível e possível de ser entendida por outros.

Você acompanhou 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 usad os ao longo do projeto para revisões, 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.


197


Unidade 5

Nenhum projeto poderá ser considerado encerrado se a documentação não estiver adequadamente preservada e organizada.

É uma obrigação dos responsáveis de cada etapa do projeto e do gestor fi nalmente, organizar, arquivar e preservar a documentação do projeto, que deve ser parte do resultado fi nal do trabalho.

Seção 6 - Lições aprendidas e novas idéias

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, tais 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 isto. 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 você poderá estudar erros e acertos em projetos de outros para avaliar caminhos. O estudo de casos proporciona, em contraste com nossa própria experiência, uma fonte rica de aprendizagem. Considere novamente o caso “Vasa” e compare 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


198


tais problemas numa série de sugestões, cujas principais estão apresentadas no quadro 5.1.

Quadro 5.1. Problemas em projetos de software e seus antídotos, adaptado de (Fairley & Willshire, 2003).

PROBLEMA ANTÍDOTOS

Pressão excessiva de prazosestimativas objetivas de prazo

mais e melhores recursos priorizações

•

•

Pressão excessiva de prazosestimativas objetivas de prazo

mais e melhores recursos priorizações

•

•

Mudanças no escopo e nas necessidades

desenvolvimento iterativo

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 cosuso 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

•

Aparentemente, um projeto de embarcação nada tem a ver com o desenvolvimento de software, mas não é bem isto que nos sugere este conjunto de “problemas e seus antídotos”.

Analisando o quadro 5.1 você pode perceber 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.


199


Unidade 5

Você poderia ainda listar mais algumas lições!

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 você retornar à unidade 1 deste livro, poderá ver que 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. Basta conferir nos quadros apresentados na unidade 1 que comparam o passado e o presente. Espero que você se dedique fi rmemente para não colocar seus próprios projetos naquela estatística.

Bem, você estudou questões sobre aprendizagem e sobre o processo de tirar lições dos fatos, das difi culdades e soluções que irá encontrar no decorrer do trabalho de desenvolvimento do projeto. Porém, acredite,


200


tais lições só serão percebidas e aprendidas por pessoas e equipes especiais.

Para pessoas e equipes cheias de idéias e criatividade, encerrar 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.

Anotações feitas durante o trajeto de desenvolvimento serão geradoras de oportunidades em ambos os sentidos. Por um lado, vários apontamentos indicarão a necessidade de acrescentar melhorias incrementais, as quais não caberiam no decorrer do projeto já que 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.

É importante também perceber que o fracasso de um projeto não é, necessariamente, o encerramento das oportunidades. Os fracassos ou os graves problemas de um projeto chamam a atenção para novas oportunidades de desenvolvimento.

Mas para renascer é preciso ter o espírito e a convicção dos líderes. Inúmeras oportunidades estão a sua frente. Ou seja, é a hora de começar um novo projeto. Boa sorte!


201


Unidade 5



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

2) Que grandes difi culdades existem no atendimento das expectativas do cliente?


202


3) Como se pode prevenir um projeto do fracasso? Que atitudes você pode tomar nesse sentido?

4) Quais lições você tira do fracasso do projeto VASA para seus próprios projetos?


203


Unidade 5

Síntese

Nesta unidade, você viu que é importante uma análise criteriosa de todos os passos dados durante o projeto e documentá-los. Assim, será possível dar continuidade às melhorias que o projeto exigir, permitir o suporte ao produto, 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, e lembrando-se desses momentos de desafi o, sentirão satisfação por saber que foram reconhecidos.

Haverá os casos de fracassos, que devem ser analisados com ainda maior rigor, permitindo nosso crescimento pessoal e também a propagação da experiência para todos os interessados. Estudos de casos famosos são, também, importantes objetos de pesquisa e análise.

Oportunidades de novos projetos estão a nossa disposição. A última seção fala justamente disto e, de certa forma, nos liga ao início deste livro, que discute a origem dos projetos. Que seja aqui o ponto de ligação para o eterno recomeçar, seja dos estudos, seja dos projetos, seja dos novos empreendimentos de sucesso. Até mais!


204


Saiba mais


1 – 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.

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

Com este livro, você fez uma revisão geral da disciplina de Gerência de Projetos. Foram trabalhados os principais tópicos da matéria, desde o início da idéia de um projeto, passando por seu planejamento, técnicas de modelagem, métodos de controle durante a fase de execução, procedimentos para encerramento e documentação, chegando à entrega ao cliente ou solicitante.

O assunto da “gerência de projetos” é essencialmente moderno, apesar dos projetos fazerem parte da história do homem. É moderno porque, atualmente, os ciclos de evolução tecnológica se sucedem muito rapidamente e as empresas precisam se renovar continuamente para se manterem vivas. Esta renovação, na maioria das vezes, se dá pela criação de novos produtos e processos através de projetos.

Espero ter colocado elementos úteis para o estudante e leitor, que possibilitem a abertura de novas idéias e a revisão dos conceitos existentes. É um assunto vivo e, por isto, sujeito a críticas e novas propostas. Ficarei grato por todos os comentários e críticas que você, leitor atento, possa fazer.

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 Filho, 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.

FACCIONI Filho, Mauro. Gestão de Projetos e de Equipes. Palhoça: Unisul Virtual, 2005. 300p.

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. Acesso em: 24/Abril/2005).

GREEFF, Gerhard. Staying in sync. ISA Intech/Industrial Computing, vol 52, no. 6, June 2005. pp. 51-55. (www.isa.org/intech)

HINOJOSA, María Alejandra. DIAGRAMA DE GANTT. 2003. Disponível em www.gestiopolis.com, acessado em 24/04/2005.

HOUAISS, Antônio. Dicionário Houaiss da Língua Portuguesa. Editora Objetiva / Instituto Antônio Houaiss. Rio da Janeiro, 2004. 2922 pp.

IACOVOU, Charalambos, DEXTER, Albert. Turning around runaway information technology projects. IEEE Engineering Management Review, vol 32, no. 4, 2004. pp 97-112.

KEELING, Ralph. Gestão de projetos, uma abordagem global. Editora Saraiva, 2002, 294 pp.

KESSLER, Eric H., BIERLY, Paul, GOPALAKRISHNAN, Shanthi. VASA Syndrome: insights from a 17th-Century new-product disaster. IEEE Engineering Management Review, vol 32, no. 1, 2004. pp 38-48.

KLOPPENBORG, Timothy; PETRICK, Joseph. Managing Project Quality. IEEE Engineering Management Review, vol 32, no. 4, 2004. pp 86-790.

MSF – Microsoft Solutions Framework, 1998. Disponível em www.microsoft.com/technet/itsolutions/msf/default.mspx

PAAP, Jay, KATZ, Ralph. Anticipating disruptive innovation. IEEE Engineering Management Review, vol 32, no. 2, 2004. pp 74-85.

PAGE-JONES, Meillir. Gerenciamento de projetos: guia prático para restauração da qualidade em projetos e sistemas de processamento de dados. São Paulo: McGraw-Hill, 1990. 328 pp.

PQA - History of Project Management, www.pqa.net, acessado em 15/02/2004. Process Quality Associates Inc.

PMBOK, Guide to the Project Management Body of Knowledge, Project Management Institute, 2004, 3a. edição, 388 pp.

PRADO, Darci Santos do. PERT/COM – Série Gerência de Projetos, volume 4. 1998. Belo Horizonte. Editora DG.

RAZ, Tzvi, BARNES, Robert, DVIR, Dov. A critical look at Critical Chain Project Management. IEEE Engineering Management Review, vol 32, no. 2, 2004. pp 35-44.

SÁENZ, Tirso W., CAPOTE, Emilio G. Ciência, Inovação e Gestão Tecnológica, IEL/SENAI, Brasília, 2002.


SISK, Toney. The History of Project Management. http://offi ceupdate.microsoft.com/downloadDetails/projhistory.htm. Acesso em 20/Fev/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 (www.creare.com.br), 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 da 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 está 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.

Em 2006, fundou a empresa FAZION Sistemas, dedicada à “inteligência em redes móveis”, onde sua equipe desenvolve softwares para “web móvel” (www.fazion.com.br) .

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 online no banco de dados do CNPq, no endereço http://buscatextual.cnpq.br/buscatextual/index.jsp.


book.indb Sec1:212book.indb Sec1:212 31/5/2007 14:24:1131/5/2007 14:24:11

Respostas e comentários das atividades de auto-avaliaçãoA seguir, acompanhe as respostas sobre as atividades de auto-avaliação apresentadas ao longo de cada uma das unidades desta disciplina. Para o melhor aproveitamento do seu estudo, confi ra suas respostas somente depois de realizar as atividades propostas.

UNIDADE 1

1) Resposta: o exemplo descrito deve claramente identifi car um objetivo e um prazo determinado de execução

2) Resposta: 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) Resposta: 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. Isto indica que as empresas não estão utilizando tais técnicas e continuam realizando seus trabalhos sem gerenciamento.


214


4) Respostas:

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

Bancos (criar 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)

5) Resposta - exemplo:

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

6) Resposta: veja o desenho a seguir.

casa software

carro 4x4


215

Sistemas Informatizados Corporativos no Âmbito da Administração Pública: SIAFI, SIAFEM e SIGEF

UNIDADE 2

1) Resposta exemplo: 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, ele deve ser atualizado 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) Resposta exemplo::

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;

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) Resposta: o algoritmo permite modelar o planejamento do projeto de maneira a entendermos e defi nirmos todos os passos que devem ser seguidos na execução do projeto, para que o mesmo chegue ao resultado esperado.

4) Resposta: a partir de certo prazo o projeto perde o sentido. Isto 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.

5) Resposta: 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 por isto é difícil manter todas as previsões.


216


UNIDADE 3

1) Resposta: 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 por isto é difícil manter todas as previsões.

Projeto 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) Resposta:

4) Resposta: 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 a equipe de acordo com os custos de hora-homem dos membros escolhidos.


217

Sistemas Informatizados Corporativos no Âmbito da Administração Pública: SIAFI, SIAFEM e SIGEF

5) Resposta: 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.

6) Resposta: 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-se conforme o cronograma e o setor/atividade.

7) Resposta: 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 o desenvolvimento de aplicativos de software.

UNIDADE 4

1) Resposta: antes de começar um projeto é necessário uma etapa de refl exão para elaborar a etapa de início do projeto. A etapa de início de um projeto deve se dar por conta de uma reunião. Nesta reunião, os planos serão discutidos em detalhes, o plano de produção deve ser delineado, as tarefas divididas e as responsabilidades atribuídas. O fl uxograma geral deve ser apresentado, discutido e suas cópias distribuídas. A comunicação dos procedimentos, já discutidos, deve ser feita a partir desse contato inicial.

2) Resposta: 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: resposta subjetiva, baseada no seguinte quadro:

DiferençasIndivíduo / profi ssional Organização / gerênciaBusca a inovação tecnológica Busca o lucroQuer autonomia de ação Quer integrar os profi ssionais na organizaçãoQuer livrar-se de regras e procedimentos Estabelece as regras e procedimentosQuer autoridade baseada em mérito Autoridade baseada em hierarquiaQuer ser recompensado com base em seu desempenho Recompensa conforme o interesse da organizaçãoQuer ampla comunicação entre pares Bloqueia a comunicação internaBusca otimização do próprio trabalho Busca cumprimento de cronogramas e custos

4) Resposta: as formas apresentas são: por confronto, por comprometimento, por acomodação, por prevalência, por retirada.

5) Resposta: 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


218


tempo e dinheiro, especialmente em projetos de produtos complexos ou muito grandes, como máquinas, grandes hidrelétricas, grandes construções, etc.

UNIDADE 5

1) Resposta: 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) Resposta: 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.

3) Resposta: 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: haverá citações sobre o descontrole, sobre a falta de liderança, sobre as interrupções constantes feitas pelo rei, sobre a falta de conhecimento técnico apropriado, sobre o planejamento fraco, sobre a falta de documentação.


Documents

Gerencia de Projetos - UNISUL