CAMILA DE ARAUJO

SOFTWARES DE APOIO AO GERENCIAMENTO GIL DE

PROJETOS COLABORATIVOS DE NOVOS PRODUTOS:
ANLISE TERICA E IDENTIFICAO DE REQUISITOS

Dissertao apresentada Escola de Engenharia

de So Carlos da Universidade de So Paulo,
para

obteno do ttulo de Mestre em

Engenharia de Produo.

rea de Concentrao: Processos e Gesto de

Operaes
Orientador: Prof. Dr. Daniel Capaldo Amaral

So Carlos
2008

Dedico este trabalho aos meus pais, Eduardo e Marcia

e ao meu companheiro de todos os momentos nesta trajetria, rico.

AGRADECIMENTOS
Agradeo primeiramente a minha famlia, pais, irms, avs, tios e primos, pelo apoio
em todos os momentos da minha vida. Mas principalmente aos meus pais, que sempre
confiaram em minhas decises e atitudes.
Ao meu companheiro rico, que durante toda a trajetria do mestrado entendeu meus
problemas e ofereceu seu carinho e compreenso.
Ao meu orientador, Prof. Dr. Daniel Capaldo Amaral, pela orientao, ensinamentos,
pacincia e apoio.
Ao Prof. Dr. Henrique Rozenfeld, pelos ensinamentos e exemplo de trabalho.
s sinceras e queridas amigas, Lie e Carol, que tanto apoiaram e acompanharam
minha caminhada no mestrado. Essa amizade vai permanecer pelo resto de nossas vidas.
Aos amigos de longa data, Simone, Ana Cludia, Danilo, Luclia e Raquel, que apesar
da distncia, sempre compreenderam a minha ausncia e ofereceram palavras de incentivo.
s amigas Letcia, Vanda, Aline e Mariana, companheiras de vrios episdios e boas
risadas.
Aos amigos e companheiros de pesquisa: Eduardo, Euclides, Edivandro, Joo, Mauro,
Juliana, Lus, Fabio, Maicon, Janana, Andra, Angelita, Sayuri e prof. Srgio, pelas
experincias e bons momentos compartilhados. Aos demais integrantes do grupo de pesquisa.
Cris, Fernandinho, Simone e Francis pelo apoio tcnico e administrativo.
Aos funcionrios do SEP pela ajuda, principalmente ao Z Luiz.
s empresas que colaboraram com esta pesquisa.
Universidade de So Paulo, pelo ensino gratuito e de qualidade.
Capes e ao Ministrio da Cincia e Tecnologia pelo apoio financeiro.

A mais bela teoria s tem valor atravs das obras que realiza.
(Romain Rolland)

Resumo
ARAUJO, C. Softwares de apoio ao gerenciamento gil de projetos colaborativos de
novos produtos: anlise terica e identificao de requisitos. Dissertao (Mestrado)
Escola de Engenharia de So Carlos, Universidade de So Paulo, So Carlos, 2008.
A competncia em gerenciamento de projetos (GP) reconhecida como um fator crtico para
o desenvolvimento de novos produtos e possuir sistemas de informao adequados um
quesito fundamental para apoi-la. H uma disponibilidade de ferramentas e em contrapartida,
um nmero significativo de crticas sua utilizao, especialmente no caso de produtos
inovadores e complexos. O trabalho tem por objetivo identificar os desafios a serem
enfrentados para o desenvolvimento de ferramentas de software para apoiar prticas com esse
enfoque. Empregou-se a reviso bibliogrfica combinada com o estudo de caso mltiplo.
Compilou-se os desafios apontados na literatura, revisando os temas: colaborao,
gerenciamento gil de projetos e softwares para gerenciamento de projetos. O resultado,
organizado segundo as reas de processo do PMI, foi comparado com problemas reais,
coletados por meio do mtodo de estudo de caso. O setor de bens de capital foi escolhido para
garantir a complexidade dos projetos (nmero de peas do produto e presena de
colaborao). A unidade de anlise o sistema de informao para gerenciamento dos
projetos (SIGP) de cada empresa. Descreveu-se o SIGP e o papel dos softwares de GP, de
forma a identificar os desafios e classific-los segundo reas de conhecimento de GP. Os
instrumentos utilizados foram roteiros de entrevistas, observaes e anlise de documentos.
Os desafios foram confrontados com o esforo da comunidade cientfica, identificado por
meio de uma reviso bibliogrfica, classificada segundo as mesmas reas de GP. Ao final,
comparam-se os desafios das empresas com a teoria e identifica-se uma lista de requisitos
para o desenvolvimento de softwares na rea. A anlise indica tambm que as ferramentas de
GP so utilizadas de forma restrita na indstria de bens de capital e que h discordncias entre
o esforo dos pesquisadores e necessidades dos profissionais da rea. Por fim, esta pesquisa
identifica como temas relevantes: a integrao de dados, o desenvolvimento de
funcionalidades de aquisio e de gerenciamento de interfaces, riscos, recursos e
multiprojetos.
Palavras-chave: gerenciamento de projetos, software de gerenciamento de projetos,
gerenciamento gil de projetos, desenvolvimento de produtos.

Abstract
ARAUJO, C. Software to support the agile collaborative project management of new
products: theoretical analysis and requirements identification. M. Sc. (Dissertation)
Escola de Engenharia de So Carlos, Universidade de So Paulo, So Carlos, 2008.
The project management competence has been recognized as a critical factor to develop new
products. Information systems are a fundamental factor to support it. There is an exceptional
amount of tools. In opposition there are a significant number of critics about its utilization, in
special in projects like innovative and collaborative product projects. The critics pointed
needs for new methods and practices to support the agile project management. This research
aims to identify challenges of developing project management tool to support this approach.
The method used combines a bibliographical review with a multiple case study. The literature
challenges were compiled, reviewing the themes: collaboration, agile project management and
project management software. The result, organized by PMI process areas, was compared
with case study real problems. The capital goods (BK) sector was chosen to ensure the
projects complexity (by the product and collaboration presence). The analysis unit is the
project management information system (PMIS) of each company. The PMIS and the role of
the project management software were described to identify the challenges and classify them
according to project management areas. The data collection instruments are plan interview,
non-participant observations and document analysis. The challenges were faced with the
scientific community effort, identified through a literature review and classified according to
the same areas of PM. Following, the challenges of companies was compared with the
literature and a requirement list is identified to develop PM software. The analysis indicates
that the PM tools used in the BK industry are restricted. There is a mismatch between the
researcher efforts and necessities of professionals in the area. Finally, this research identifies
as relevant themes: data integration, development of acquisition features, interfaces, risks,
resources and multi-projects management.
Keywords: project management, project management software, agile project management,
product development.

Lista de Figuras

Figura 1. Tipologia de Projetos para o desenvolvimento de Produtos .................................................. 23

Figura 2. Relacionamento entre as abordagens clssica e gil de gerenciamento de projetos .............. 34
Figura 3. Princpios do Gerenciamento gil de Projetos ...................................................................... 38
Figura 4. Plataforma do Processo de Gerenciamento gil de Projetos................................................. 39
Figura 5. Estrutura operacional para apoio ao gerenciamento gil de projetos..................................... 43
Figura 6. Ambientes para aplicao do enfoque gil............................................................................. 45
Figura 7. Coerncia entre as direes do EPSRC e idias do enfoque gil.......................................... 46
Figura 8. Sntese e relao entre os desafios encontrados na literatura................................................. 48
Figura 9. Quadrante de classificao dos softwares comerciais............................................................ 54
Figura 10. Desafios para os SGPs Colaborativos .................................................................................. 63
Figura 11. Problema de Pesquisa........................................................................................................... 67
Figura 12. Representao dos tipos de empresas estudadas.................................................................. 69
Figura 13. Etapas da Pesquisa ............................................................................................................... 73
Figura 14. Modelo representativo do macro-fluxo de informaes de projeto da Empresa A.............. 76
Figura 15. Organograma da Empresa B ................................................................................................ 82
Figura 16. Modelo representativo do macro-fluxo de informaes de projetos da empresa B ............. 84
Figura 17. Modelo representativo do macro-fluxo de informaes dos projetos da Empresa C........... 89
Figura 18. Modelo representativo do macro-fluxo de informaes dos projetos da Empresa D .......... 95
Figura 19. Distribuio dos trabalhos nas reas .................................................................................. 107
Figura 20. rea de Comunicaes....................................................................................................... 108
Figura 21. rea de Escopo .................................................................................................................. 108
Figura 22. rea de Integrao ............................................................................................................. 109
Figura 23. rea de Tempo................................................................................................................... 110
Figura 24. rea de Colaborao.......................................................................................................... 111
Figura 25. Tela do software VersionOne ............................................................................................ 113
Figura 26. Tela do software Rally relatrio Burndown.................................................................... 114
Figura 27. Tela do software Rally - Defects........................................................................................ 115
Figura 28. Tela do software Target - Dashboard................................................................................. 116

Lista de Quadros

Quadro 1. Alinhamento de fatores para sucesso de um projeto colaborativo ....................................... 25

Quadro 2. Linhas para futuras pesquisas em GP................................................................................... 31
Quadro 3. Correspondncia entre as abordagens clssica e gil de GP ................................................ 42
Quadro 4. Novos desafios para o gerenciamento de projetos colaborativos ......................................... 59
Quadro 5. Critrios para anlise dos softwares da literatura ............................................................... 102
Quadro 6. Artigos encontrados na reviso da literatura ...................................................................... 105
Quadro 7. Comparao entre a literatura e estudos de casos .............................................................. 127

Lista de Abreviaturas e Siglas

APM

Agile Project Management

ATO

Assembly-To-Order

BPMN

Business Process Modeling Notation

CAD

Computer Aided Design

CAE

Computer Aided Engineering

CAM

Computer Aided Manufacturing

CE

Concurrent Engineering

CSCW

Computer Supported Cooperative Work

DSDM

Dynamic Systems Development Method

EPM

Enterprise Project Management

EPSRC

Engineering and Physical Sciences Research Council

ERP

Enterprise Resource Planning

ETO

Engineer-To-Order

GP

Gerenciamento de Projetos

GPC

Gerenciamento de Projetos Colaborativos

MTS

Make-To-Stock

P&D

Pesquisa e Desenvolvimento

PDM

Product Data Management

PDP

Processo de Desenvolvimento de Produto

PMBOK

Project Management Body of Knowledge

PMI

Project Management Institute

RF

Requisito Funcional

RNF

Requisito No Funcional

SGP

Software de Gerenciamento de Projeto

SIGP

Sistema de Informao de Gerenciamento de Projeto

SW

Software

TI

Tecnologia da Informao

WBS

Work Breakdown Structure

XP

eXtreme Programming

SUMRIO
1.

Introduo............................................................................................................................... 14

2.
2.1.

Desafios para o gerenciamento gil de projetos colaborativos........................................... 19

Desafios no gerenciamento de projetos colaborativos ............................................................. 19

2.1.1.

Definio e conceitos bsicos da colaborao ......................................................................... 19

2.1.2.

Definio de projeto colaborativo ............................................................................................ 22

2.1.3.

Sntese dos desafios no gerenciamento de projetos colaborativos ........................................... 24

2.2.

Desafios do gerenciamento de projetos e o gerenciamento gil de projetos ............................ 26

2.2.1.

Crticas aos mtodos tradicionais de gerenciamento de projetos ............................................. 26

2.2.2.

Definio do gerenciamento gil de projetos ........................................................................... 33

2.2.3.

Objetivos, valores, princpios e fases do GP gil ..................................................................... 35

2.2.4.

Aplicabilidade do gerenciamento gil de projetos ................................................................... 44

2.3.

Sntese dos desafios encontrados ............................................................................................. 46

3.
3.1.

Softwares para gerenciamento de projetos .......................................................................... 49

Definio e funcionalidades dos softwares de gerenciamento de projetos .............................. 49

3.2.

Softwares de GP segundo a literatura ...................................................................................... 50

3.2.1.

Softwares de cdigo fechado.................................................................................................... 52

3.2.2.

Softwares de cdigo aberto ...................................................................................................... 57

3.3.

Sntese dos softwares de GP frente colaborao e agilidade................................................. 58

4.
4.1.

Mtodo..................................................................................................................................... 65
Motivao e Justificativa.......................................................................................................... 65

4.2.

Objetivo.................................................................................................................................... 65

4.3.

Classificao do Mtodo de Pesquisa ...................................................................................... 67

4.4.

Etapas da pesquisa.................................................................................................................... 72

5.
5.1.

Resultados ............................................................................................................................... 74
Estudos de Caso ....................................................................................................................... 74

5.1.1.

Empresa A................................................................................................................................ 74

5.1.2.

Empresa B ................................................................................................................................ 81

5.1.3.

Empresa C ................................................................................................................................ 86

5.1.4.

Empresa D................................................................................................................................ 92

5.1.5.

Sntese dos Casos ..................................................................................................................... 98

5.2.

Anlise de softwares de Gerenciamento de Projetos.............................................................. 100

5.2.1.

Softwares pesquisados na literatura ....................................................................................... 100

5.2.2.

Softwares para gerenciamento gil de projetos...................................................................... 111

5.3.

Requisitos para um software de gerenciamento gil de projetos colaborativos..................... 117

6.

Concluses e pesquisas futuras ........................................................................................... 126

Referncias Bibliogrficas ................................................................................................................ 130

Apndices ........................................................................................................................................... 136
Anexo ................................................................................................................................................ 143

14

1. Introduo
O gerenciamento por projetos (GP) o modelo dominante em muitas organizaes
para implementao de estratgias, transformao de negcios, melhoria contnua e
desenvolvimento de novos produtos (WINTER et al., 2006). H um conjunto significativo de
tcnicas, ferramentas e conceitos que foram desenvolvidos para apoiar este tipo de
gerenciamento, elaborados a partir dos anos 50 (WIKIPEDIA, 2008; KERZNER, 1984; e
HIRSCHFELD, 1985). Os marcos principais foram o desenvolvimento do grfico de Gantt,
do mtodo do caminho crtico, da anlise de rede (PERT) e a criao das primeiras
associaes profissionais na dcada de 70.
A aplicao inicial aconteceu com os grandes projetos de infra-estrutura, construo
civil e defesa. Essas tcnicas eram pouco difundidas entre empresas de outras reas, como as
de manufatura de bens de consumo seriados e prestadoras de servios. A situao alterou-se
no incio da dcada de 90. Impulsionados por vrias mudanas no ambiente empresarial,
popularizaram-se e difundiram-se em todos os setores industriais. Esse fenmeno
perceptvel no crescimento significativo do nmero de eventos, formao de profissionais
especializados e no investimento de empresas na rea.
No caso do desenvolvimento de produtos manufaturados, a procura por esses
conhecimentos deu-se com o aumento da intensidade e complexidade dos projetos. A
subcontratao de servios de engenharia, o crescimento do grau de inovao dos produtos, a
necessidade de tempos menores de desenvolvimento e o crescimento dos riscos associados
aos novos produtos explicam o aumento da complexidade.
O aumento da colaborao como estratgia para o desenvolvimento de novos produtos
tambm contribuiu. Nos anos 80, as empresas de produtos seriados possuam os setores de
Engenharia e de Pesquisa e Desenvolvimento (P&D) totalmente verticalizados. A empresa era

15

capaz de produzir todas as informaes necessrias para a produo de seus produtos

(WOMACK e JONES, 1992). Esse cenrio mudou radicalmente e dificilmente uma empresa
consegue reunir todas as competncias necessrias para o desenvolvimento de um produto. A
insero de fornecedores e clientes nas equipes de projeto tornou-se freqente (ROZENFELD
et al., 2006). As parcerias com universidades e institutos de pesquisa tambm se tornaram
mais comuns e fundamentais para atender demanda de inovaes do mercado
(NOOTEBOOM, 1999; OSTERGAARD e SUMMERS, 2003).
O resultado que a competncia em gerenciamento de projetos est se tornando um
fator crtico para o desenvolvimento de novos produtos e, conseqentemente, para a
competitividade das empresas.
Porm, no caso de projetos inovadores realizados por pequenas e mdias empresas,
significativo o relato de problemas e dificuldades em introduzir esses mtodos de
gerenciamento. Pesquisas como a de Jugend et al. (2006) e Juc Junior e Amaral (2005) tm
revelado que o gerenciamento de projetos ainda um dos problemas enfrentado por essas
empresas. Mas h vrios casos de empresas que desenvolvem produtos do tipo classe
mundial, onde as tcnicas tradicionais de gerenciamento de projetos, como planejamento com
PERT/CPM e grfico de Gantt, no so empregados (MAYLOR, 2001; KENEDY apud
CORREA, 2008)
Esses problemas podem estar relacionados com limitaes da teoria de gerenciamento
de projetos. Segundo Maylor (2001), os mtodos tradicionais, aqueles divulgados por
associaes, por exemplo, seriam propcios apenas para o contexto em que foram originados:
grandes projetos de infra-estrutura, aeroespacial e de defesa. Realizados por equipes com
dedicao exclusiva; em ambientes com poucos projetos por vez; e de projetos com
caractersticas semelhantes. O autor afirma que h vrias empresas com excelncia em
gerenciamento de projetos e que no os utilizam, pois estariam em contextos distintos, onde

16

outras tcnicas seriam necessrias. Afirma ainda que a teoria, em geral, no avanou para
considerar de maneira apropriada esses casos (MAYLOR, 2001).
Essa crtica vem sendo realizada por inmeros autores nos ltimos anos. Uma das mais
contundentes surgiu em 2002. Denominado de Manifesto gil, foi realizado por profissionais
da rea de gerenciamento de projetos de tecnologia da informao. Os autores questionaram o
foco exagerado na documentao, planejamento de tarefas e controle externo (BECK et al.,
2001). Em oposio, propuseram o desenvolvimento de novos mtodos, que deveriam seguir
diferentes princpios, aos quais denominaram de gil. Mais recentemente, Winter et al.
(2006) conduziram uma srie de estudos sobre os problemas da teoria de gerenciamento de
projetos e identificaram problemas semelhantes, apontando a necessidade de estudo e
desenvolvimento de novos mtodos e tcnicas, mais simples e com maior capacidade de
reagir s contingncias durante a execuo do projeto.
Chin (2004) e Highsmith (2004) so exemplos de autores que vm se dedicando ao
desenvolvimento de novas teorias na rea. Esses mtodos seriam especialmente adequados
para empresas que atuam em mercados inovadores e/ou pequenas e mdias empresas
(HIGHSMITH, 2004).
Uma das ferramentas fundamentais para o gerenciamento de projetos so as solues
computacionais, isto , os softwares de GP. Eles garantem a qualidade das informaes e,
portanto, desempenham um papel fundamental na tomada de decises que, por sua vez, a
essncia da gesto.
A evoluo dos princpios e mtodos geis de gerenciamento de projetos depende,
portanto, da adaptao ou desenvolvimento de softwares que utilizem estes princpios. No h
estudos que avaliem os softwares existentes, frente s novas tendncias da teoria de
gerenciamento de projetos. Qual a capacidade dos softwares em apoiar a introduo de

17

princpios do gerenciamento de projetos gil? Quais as mudanas necessrias? O que precisa

ser desenvolvido nesta rea?
Esta pesquisa procurou abordar esse problema. O objetivo foi investigar quais
mudanas e requisitos seriam necessrios para o desenvolvimento de softwares de
gerenciamento de projetos dentro desse novo contexto de projetos colaborativos e inovadores,
e segundo as novas tendncias em termos da teoria de gerenciamento de projetos. Ao designar
essas novas tendncias, optou-se por utilizar o rtulo de Gerenciamento gil de Projetos
(Agile Project Management APM), seguindo a denominao mais conhecida. O captulo 2
deste trabalho apresenta esse conceito de APM e as crticas sobre os mtodos tradicionais de
gerenciamento de projetos (seo 2.2), bem como os desafios encontrados no gerenciamento
de projetos colaborativos, incluindo o conceito de colaborao adotado (seo 2.1).
A anlise foi feita por meio da composio de diferentes mtodos de pesquisa. Partiuse de revises bibliogrficas com o objetivo de se identificar as novas tendncias em GP,
funcionalidades de software de GP e modelos de softwares para GP propostos na literatura
especfica da rea. Em seguida, foram feitas anlises de sistemas comerciais que se propem a
apoiar o gerenciamento gil de projetos e que hoje esto disponveis especificamente para a
rea de desenvolvimento de software. O captulo 3 apresenta os tipos de softwares de
gerenciamento de projetos, fazendo uma sntese desses softwares frente colaborao e
agilidade.
Incluram-se tambm estudos de caso sobre a utilizao de softwares no
gerenciamento de projetos colaborativos e inovadores na indstria de bens de capital,
apresentados no captulo 5, na seo 5.1. J na seo 5.2, consta a anlise das propostas de
softwares da literatura acadmica e dos softwares para gerenciamento gil de projeto.
Os problemas encontrados, tanto na reviso da literatura como nos estudos de caso,
foram sintetizados de forma a identificar os desafios que precisam ser superados para o

18

desenvolvimento de sistemas especficos para o gerenciamento gil de projetos. Baseado

nesses desafios, identificou-se um conjunto de requisitos que sintetizam a anlise e podem ser
utilizados para o desenvolvimento de softwares para esse fim (5.3.)
Por fim, o captulo 6 apresenta as concluses deste trabalho, indicando as reas
relevantes para pesquisas futuras.

19

2. Desafios para o gerenciamento gil de projetos colaborativos

O objetivo deste captulo apresentar as definies e, principalmente, os desafios
envolvidos no gerenciamento de projetos colaborativos, gerenciamento de projetos
tradicionais e propostos no enfoque do gerenciamento gil de projetos, contrapondo-os aos
conceitos dito tradicionais (clssicos) de gerenciamento de projetos. No se pretende
descrever os tradicionais, pois h uma vasta literatura sobre o tema, de fcil acesso e
padronizada por associaes profissionais1. A primeira seo, 2.1, apresenta a definio de
Gerenciamento de Projetos Colaborativos e seus conceitos bsicos como colaborao e
classificao de projetos. Em seguida, a seo 2.2 apresenta as crticas teoria de
gerenciamento de projetos (2.2.1) e o enfoque gil no gerenciamento de projetos com sua
definio (2.2.2), seus objetivos, princpios e valores (2.2.3) e sua aplicabilidade no
gerenciamento de projetos de desenvolvimento de produtos (2.2.4). Por fim, a seo 2.2.5 faz
uma sntese dos desafios identificados.

2.1. Desafios no gerenciamento de projetos colaborativos

2.1.1. Definio e conceitos bsicos da colaborao
Nooteboom (1999) diz que a razo fundamental pela qual as empresas se associam a
oportunidade de complementar suas competncias para produzir valor agregado e inovao. A
associao com outras empresas fundamental no atual cenrio de desenvolvimento
tecnolgico. O caso da Procter & Gamble, apresentado por Huston e Sakkab (2006),
demonstra claramente esse problema. Uma empresa que possui uma estrutura de
desenvolvimento tecnolgico significativa, frente ao padro da maioria das empresas, e que,
apesar disso, reconhece a dificuldade de manter-se atualizada nas vrias tecnologias
1

Gesto tradicional, aqui tratada como clssica. Sugere-se que se consulte a seguinte bibliografia:
VERZUH(2000); PMBOK(2004); e KERZNER(2002)

20

necessrias ao seu negcio. Assim, apesar do tradicional investimento em P&D, a empresa

permanece na busca de parcerias, criando redes de colaborao.
Rycroft e Kash (2004) identificam a globalizao como sendo a fora que induz
colaborao entre vrios tipos de organizao. Combinando a fora, a percia e o
conhecimento de equipes tcnicas diversas e dispersas geograficamente, as tecnologias podem
ser desenvolvidas em menos tempo (DAVIS, KEYS e CHEN, 2004). Talvez, no futuro, as
empresas que conseguiro manter-se na liderana do desenvolvimento tecnolgico e de
produtos sejam aquelas que consigam se associar s redes que contemplem todas as
competncias necessrias para o desenvolvimento dos produtos e que saibam melhor como
atuar de forma colaborativa (HUSTON e SAKKAB, 2006). Empresas que sejam tambm
capazes de criar processos de negcio capazes de acessar o conhecimento compartilhado
(KODAMA, 2007).
O desenvolvimento colaborativo , portanto, um fenmeno atual. Na literatura existem
vrias definies de colaborao em termos de desenvolvimento de produto. Desde a dcada
de 80 que esse fenmeno vem sendo desenvolvido do ponto de vista gerencial, com diversos
nomes (alianas estratgicas, parcerias, etc.) e sob diferentes aspectos. Amaral (1997) e
Amaral e Toledo (2000) apresentam uma compilao especfica sobre a colaborao no
desenvolvimento de produtos, na qual identificam linhas de pesquisa distintas e comparam
diferentes definies.
Em um estudo recente, Emden, Calantone e Droge (2006) apresentam uma extensa
reviso sobre colaborao no desenvolvimento de produto. Os autores definem colaborao
no desenvolvimento de produto como um tipo de relacionamento interorganizacional,
caracterizado por nveis elevados de transparncia e onde cada ente contribui com uma
parcela significativa do resultado final do projeto. Essas duas caractersticas - interao e
objetivos comuns - so os aspectos fundamentais que designam praticamente todas as

21

definies de colaborao. Exemplos de definies que seguem essa linha so as de

Mattessich e Monsey (1992), segundo a qual colaborao uma relao bem definida e
mutuamente benfica entre duas ou mais organizaes, a fim de atingir objetivos comuns; e a
de Katz e Martin (1997), como o trabalho conjunto de indivduos para atingir objetivos
comuns.
Mas essas definies no exploram em profundidade um aspecto do trabalho
colaborativo: a criao conjunta. Duas empresas que trabalham em um mesmo projeto podem,
no necessariamente, influenciar da mesma maneira no resultado final. Assim corre-se o risco
de confundir colaborao com outros tipos de relacionamentos que no apresentam nveis
similares de complexidade gerencial. Um caso emblemtico a subcontratao de servios de
desenvolvimento. O cliente concebe o produto, define as caractersticas essenciais e delega a
outra empresa trabalhos especficos de detalhamento, sem que haja interao ou contribuio
do fornecedor no resultado preconcebido. Neste caso, pode haver uma diviso de tarefas clara
e bem delimitada, que faz o esforo no ser realmente de cooperao, na medida em que
envolve pequena interao entre as partes.
O estudo de Camarinha-Matos et al. (2006) descreve os vrios nveis de integrao
entre parceiros, que foram analisados e utilizados na definio de colaborao. Os autores
apresentam uma classificao de quatro tipos de envolvimento: rede, coordenao,
cooperao e colaborao. O mais avanado, dito colaborao, envolve objetivos, identidades,
responsabilidades e trabalho conjuntos, quer dizer, a criao do produto final realizada
conjuntamente pelos parceiros: por meio de intensa troca de informaes. Por deixar esse
aspecto mais evidente, adota-se neste trabalho a definio do nvel mais avanado desses
autores (CAMARINHA-MATOS et al., 2006):

22

Um processo em que entidades compartilham informaes, recursos

e responsabilidades para planejar, implementar e validar um
programa de atividades para atingir um objetivo comum.

2.1.2.

Definio de projeto colaborativo

Um dos fatores que contriburam para a difuso da literatura de gerenciamento de

projetos foi o lanamento, a partir de 1987, do PMBOK (Project Management Body of
Knowledge) pelo PMI (Project Management Institute), difundindo e padronizando os termos
empregados no gerenciamento de projetos.
Segundo esse padro, um projeto um esforo temporrio para criar um produto (item
final ou componente), servio (funes de negcio para suporte ou distribuio) ou resultado
exclusivo (documentos, por exemplo, de conhecimento aplicado de pesquisa cientfica)
(PMBOK, 2004). Os membros dessa associao consideram tambm o conceito de programa,
definido como um conjunto de projetos visando um resultado principal (PMBOK, 2004).
At 2003, os projetos eram classificados, de forma simples, como nicos ou mltiplos
(programa). Evaristo e Fenema (1999) propuseram uma tipologia de projetos e programas de
acordo com a localizao fsica. Segundo os autores, os projetos ou programas podem ser
realizados e gerenciados dentro de uma nica organizao ou distribudos em diferentes
organizaes, com localizaes distintas. Essa diferena representaria desafios e esforos
gerenciais distintos, justificando a necessidade da categorizao.
Quando comparada ao conceito de projetos colaborativos, descrito na seo anterior,
nota-se que essa classificao considera apenas o aspecto do envolvimento de diferentes
organizaes em um mesmo projeto, porm no caracteriza o aspecto da diviso de tarefas.
H projetos que so realizados por duas ou mais organizaes e distribudos, nos quais o
trabalho concebido, planejado e controlado por apenas uma delas, como o caso de projetos
de desenvolvimento de produtos totalmente controlados pelos clientes. Segundo a teoria de

23

projetos colaborativos, esses casos seriam distintos daqueles nos quais os membros das duas
organizaes tenham que definir e criar as solues conjuntamente, negociar prazos e
mtodos de trabalho, como o caso do envolvimento de parceiros de risco no
desenvolvimento de novos produtos. As duas situaes representam problemas com nveis de
complexidade distintos em termos de gerenciamento de projetos.
Portanto, prope-se para este trabalho uma adaptao da tipologia de Evaristo e
Fenema (1999). A Figura 1 representa a adaptao dessa tipologia, que considera no somente
o conceito de distribuio fsica, como tambm o de colaborao.

Figura 1. Tipologia de Projetos para o desenvolvimento de Produtos

Fonte: adaptado de Evaristo e Fenema (1999)

Definem-se como colaborativos, ento, os projetos onde h um esforo compartilhado

no contedo e, portanto, prazos, metas e o controle gerencial negociados; independentemente
de as equipes de cada organizao estarem em um mesmo local ou de trabalharem
distribudas.

24

A tipologia a ser empregada neste trabalho utiliza, portanto, quatro classificaes,

conforme apresentadas na figura 1.
A literatura sobre projetos colaborativos de desenvolvimento de produtos
tradicionalmente aborda os projetos do tipo Colaborativo-Distribudos (KVAN, 2000;
NAOUM, 2003; e HUSTON e SAKKAB, 2006).
Este trabalho ocupa-se dos problemas e limitaes dessa teoria. Foram observadas
crticas e desafios em dois tipos de literatura: nos trabalhos sobre gerenciamento colaborativo
de projetos de produtos e na literatura sobre gerenciamento de projetos em geral. Optou-se por
dividir os tpicos.

2.1.3. Sntese dos desafios no gerenciamento de projetos colaborativos

Dodgson (1992) afirmava que a interao entre os parceiros era um ponto crtico no
desenvolvimento de projetos (DODGSON, 1992). Esses problemas ainda so perceptveis.
Moody e Dodgson (2006) apresentam um estudo de caso de um chamado projeto complexo,
de desenvolvimento de satlite, que envolveu a colaborao de vrias organizaes. Uma das
concluses do estudo que a influncia da liderana significativamente maior se comparada
aos projetos tradicionais. Ela fundamental para garantir uma interao suficiente entre as
equipes das diferentes organizaes.
No comeo da atual dcada, Kerzner (2002) afirmou que, com as constantes fuses e
aquisies de empresas, o gerenciamento de projetos multinacionais ser um dos grandes
desafios desta dcada, pois existem muitas dificuldades inerentes s fronteiras
organizacionais (BARNES, PASHBY e GIBBONS, 2006).
Pesquisas sobre projetos colaborativos de engenharia apresentam alguns fatores que os
impedem de atingirem seus objetivos (HAMERI e PUITTINEN, 2003):

Falta de informao sobre o que as outras equipes do projeto esto fazendo

(progresso das tarefas);

25

Falha no controle de mudana do projeto;

Vises diferentes sobre os objetivos do projeto;

Rigidez no planejamento do projeto e das rotinas;

Reaes pouco produtivas em relao s mudanas repentinas no ambiente do

projeto;

Dificuldades tecnolgicas inesperadas;

Barnes, Pashby e Gibbons (2006) realizaram uma reviso da literatura e identificaram

os fatores de sucesso dos projetos colaborativos no caso indstria-indstria:

Objetivos claramente definidos;

Responsabilidades claramente definidas;

Plano de projeto aceito pelas partes;

Recursos adequados;

Marcos de projeto definidos;

Monitoramento regular do progresso;

Comunicao efetiva;

Entrega garantida dos colaboradores.

Pode-se notar que existe um alinhamento dos fatores crticos de sucessos observados
por Barnes, Pashby e Gibbons (2006) com os fatores que impedem o alcance dos objetivos de
um projeto, por Hameri e Puittinen (2003), apresentados no quadro 1.
Fatores de Hameri e Puittinen (2003)
Falta de informao sobre o que as outras equipes
do projeto esto fazendo
Vises diferentes sobre os objetivos do projeto
Falha no controle de mudana do projeto

Fatores de Barnes, Pashby e Gibbons (2006)

Comunicao efetiva
Objetivos claramente definidos
Plano de Projeto aceito pelas partes, Recursos

adequados.

Quadro 1. Alinhamento de fatores para sucesso de um projeto colaborativo

26

Portanto, para tentar superar os desafios existentes, o gerenciamento de projetos

colaborativos necessita do apoio de ferramentas que privilegiem a comunicao, a atualizao
das informaes e um controle da progresso das atividades regulado por entregas efetivas.

2.2. Desafios do gerenciamento de projetos e o gerenciamento gil de projetos

2.2.1. Crticas aos mtodos tradicionais de gerenciamento de projetos
A teoria tradicional de gerenciamento de projetos recebeu grande ateno no incio dos
anos 90, com a publicao de padres de corpos de conhecimentos pelas associaes
profissionais de gerenciamento de projetos. O mais difundido a proposta pelo Project
Management Institute (PMBOK, 2004). Esse padro prope a descrio dos conceitos em um
conjunto de processos do gerenciamento de projetos. Esses processos so organizados em
reas do Conhecimento. So nove reas do conhecimento: Integrao, Escopo, Tempo,
Custos, Qualidade, Recursos Humanos, Comunicao, Riscos e Aquisies. E consideram
cinco grupos de processo: Iniciao, Planejamento, Execuo, Controle e Encerramento.
Essas reas e grupos de processo so empregados no trabalho, mas no sero descritos em
detalhe, pois h muitas referncias de fcil acesso sobre o assunto, tais como: PMBOK
(2004); Carvalho e Rabechini (2005), entre outros.
No final dos anos 90, ao mesmo tempo em que houve uma expanso na difuso e
aplicao dos mtodos e tcnicas de gerenciamento de projetos, surgiram abordagens
alternativas e propostas de modificao.
Uma das primeiras foi a atualmente conhecida como Teoria da Corrente Crtica,
proposta por Goldratt (2005). Trata-se de uma modificao em alguns aspectos da teoria de
gerenciamento de projetos, segundo os conceitos da Teoria das Restries, desenvolvida pelo
mesmo autor. Neste enfoque gerencial, os problemas so analisados sempre sob o ponto de
vista da restrio. No caso do gerenciamento de projetos, tais autores propem a realizao de

27

planejamentos em qual os recursos so programados segundo a capacidade mxima do

recurso-gargalo, isto , aquele com maior carga de trabalho. Para faz-lo, os autores propem
pequenas alteraes, introduzindo conceitos como pulmo de projeto e recurso-tambor
(GOLDRATT, 2005).
Maylor (2001), citado na introduo desta dissertao, afirma que muitas empresas
que apresentam excelncia em gerenciamento de projetos, em determinadas reas de atividade
no fazem uso da teoria tradicional de gerenciamento de projetos. Empregam outras tcnicas e
simplificaes que no tm sido sistematicamente estudadas pelos tericos da rea de
gerenciamento e que, por isso, as tcnicas teriam evoludo pouco nos ltimos 20 anos at
2001. As questes principais a serem estudadas, segundo o autor, seriam:

Relacionamento entre estratgia organizacional e a estratgia na conduo

dos projetos. Segundo o autor, a teoria apresentaria um relacionamento fraco
entre as duas estratgias por haver poucos mtodos e tcnicas que relacionem
estratgia organizacional, gerenciamento de portiflio (plano agregado de
projetos) e a definio e estratgias na conduo dos projetos.

Medidas para avaliao dos projetos. Segundo o autor, o enfoque tradicional

mediria o sucesso do projeto em termos apenas de cumprimento das metas do
projeto: oramento, escopo e restries de tempo. Questes como necessidade
de excelncia, melhoria contnua e superao das necessidades dos clientes no
estariam sendo tratadas.

Alterao do enfoque da manufatura para o enfoque de servios. De

acordo com o autor, o enfoque da teoria atual ajusta-se aos padres e
especificaes, comuns em um ambiente de grandes projetos, onde o mais
importante o produto fsico obtido, manufaturado. Atualmente, os servios
seriam to, ou mais, importantes. O grau de orientao ao cliente teria que ser

28

muito maior, fazendo com que a gesto das expectativas dos interessados
(stakeholders), a percepo deles quanto ao sucesso do projeto, seja
fundamental para a avaliao do resultado do projeto.

Foco na fase de execuo. O autor afirma que a fase de execuo pouco

desenvolvida na teoria de gerenciamento de projetos e que muitos textos da
rea parecem sugerir que o planejamento e uso de sistemas de informao
seriam suficientes para controle do projetos.

Incertezas quanto s estimativas empregadas no planejamento de

projetos. O autor afirma que, para planejar um projeto, necessrio que as
estimativas possuam certo nvel de confiana, que difcil de ser obtida. Na
prtica, seria possvel apenas em intervalos de curto prazo, diferentemente dos
que so utilizados no planejamento tradicional de projetos. Cita ainda, neste
aspecto, as crticas realizadas por Goldratt (2005)2.

Foco no Grfico de Gantt. Segundo o autor, haveria uma valorizao e

emprego excessivo do Grfico de Gantt na abordagem tradicional. Na opinio
deste, o grfico bem elaborado, por meio do uso de ferramentas
computacionais, teria como efeito a criao de uma forte credibilidade e a
iluso de que h um bom plano de projeto; mesmo quando as atividades e
recursos no tenham sido bem definidos e/ou estimados. Mais, o Grfico
encorajaria uma abordagem de planejamento de um nico passo, isto , sem o
necessrio acompanhamento e contnuo replanejamento. Em terceiro lugar, o
Grfico de Gantt encorajaria o gerente de projeto a controlar todas as
atividades do projeto, transferindo parte da responsabilidade da equipe pelo
controle de tempo. Segundo o autor, isso estaria levando tendncia de

Referenciamos a edio em portugus. Maylor (2001) cita a referncia original de 1997. Goldratt apud Maylor
(2001).

29

transformar gerentes de projeto em operadores de softwares computacionais,

mais do que pessoas responsveis pela discusso e negociao.

Uso de recursos alternativos de planejamento. O autor cita um caso de uma

empresa transnacional que obteve um desempenho de excelncia em projetos
de desenvolvimento de produtos utilizando recursos como quadro branco e
post-its. Eles eram empregados para planejar o conjunto de projetos de maneira
hbrida, com as ferramentas computacionais, onde os colaboradores utilizavam
softwares de planejamento de projetos para subprojetos ou entregas
especficas. O autor cita outro caso de um gerente de projetos de construo
civil em que as ferramentas computacionais atuais, baseadas no Grfico de
Gantt e PERT/COM, foram consideradas inadequadas e ultrapassadas.

Mais recentemente, em 2002, surgiu uma crtica que se tornou conhecida como a
teoria do Gerenciamento gil de Projetos (Agile Project Management - APM). Trata-se do
manifesto, lanado em 2001, conhecido como Manifesto gil. Ele foi elaborado por
profissionais da rea de desenvolvimento de software que queriam melhorar o desempenho de
seus projetos.
De acordo com esses autores, haveria cinco objetivos principais que consistiriam a
base do APM (HIGHSMITH, 2004, p. 6): inovao contnua - para entregar produtos que
atendam os requisitos atuais dos clientes; adaptabilidade do produto - para entregar produtos
que atendam os requisitos futuros dos clientes; tempo de entrega reduzido - para encontrar
novos mercados e melhorar o retorno de investimento; capacidade de adaptao do processo e
das pessoas para responder rapidamente s mudanas de negcios e produtos; e resultados
confiveis para apoiar o crescimento e aumento de lucratividade.
Em 2003, foi fundado um projeto de pesquisa chamado de Rethinking Project
Management (2004-2006), apoiado pelo Engineering and Physical Sciences Research

30

Council (EPSRC) do Reino Unido. Trata-se de um projeto em rede, desenvolvido com o

intuito de avaliar as idias dominantes da literatura de gerenciamento de projetos e apresentar
direes para futuras pesquisas sobre o tema (WINTER et al., 2006).
O grupo identificou cinco principais linhas de pesquisa para a melhoria do
gerenciamento de projetos, que foram agrupadas em trs subtemas Teoria sobre Prtica
(direo 1), Teoria para Prtica (direes 2-4) e Teoria na Prtica (direo 5), demonstrados
no Quadro 2 (WINTER et al., 2006).
Na Teoria sobre a Prtica, apresentada a necessidade do desenvolvimento de novos
modelos devido complexidade dos projetos e do seu gerenciamento. Segundo os autores, os
modelos empregariam um padro de ciclo de vida fechado, isto , previamente definido. A
crtica que o aumento da complexidade exigiria modelos de ciclo de vida mais flexveis, e
pesquisas neste sentido deveriam ser conduzidas. Para os autores, os novos modelos
precisaro demonstrar a realidade das prticas de GP, que procuram atender a um ambiente
dinmico, de rpidas mudanas e altos riscos (WINTER et al., 2006).
A segunda linha de pesquisa identificada foi chamada de Teoria para Prtica. Na
viso dos autores, os projetos so em geral imprevisveis e multidimensionais, mais
complexos que os modelos racionais e determinsticos, que predominariam na literatura de
GP. Assim, aprimoramentos que possam considerar de forma mais eficiente os aspectos,
como a mudana contnua do fluxo de eventos, os efeitos da interao social e da ao
humana. As interaes entre organizaes e relaes entre diferentes grupos com interesses
diferentes fazem parte dessa direo (WINTER et al., 2006).
A terceira linha de pesquisa destaca a mudana de foco na criao do produto para a
criao do valor. As metodologias que focam a produo de um produto fsico ou de um
sistema mudam para a entrega de um valor e no unicamente de um produto. Por exemplo,
o foco pode estar na estratgia de escolha de um projeto de um produto que seja relacionado

31

com as estratgias de negcio da organizao, permanecendo o valor do projeto mesmo aps a

entrega do produto. (WINTER et al., 2006).
A linha de pesquisa 4, ainda na Teoria para Prtica, apresenta a mudana de concepo
estreita do projeto para uma ampla concepo dele. Isso quer dizer entender o projeto do
produto mais do que simples aes para criar um objeto fsico, olhar para ele de vrias
perspectivas e, assim, criar um conjunto de imagens que podem indicar novas idias e formas
de gerenciar projetos (WINTER et al., 2006).
A ltima linha de pesquisa, Teoria na Prtica, diz que os praticantes de GP no devem
ser apenas tcnicos treinados nos procedimentos e ferramentas de GP, mas devem ser
praticantes reflexivos e crticos, que aprendem e aplicam suas experincias no
desenvolvimento de um projeto (WINTER et al., 2006).

Teoria sobre Prtica

Direo 1
Modelo de Ciclo de Vida de GP

Teorias da Complexidade de GP

Teoria para Prtica

Direo 2
Projetos como Processo Instrumental

Projetos como Processo Social

Direo 3
Foco na Criao do Produto

Foco na Criao do Valor

Direo 4
Concepo Estreita dos Projetos

Concepo Ampla dos Projetos

Teoria na Prtica
Direo 5
Praticantes como Tcnicos Treinados

Praticantes como Praticantes Crticos

Quadro 2. Linhas para futuras pesquisas em GP

Fonte: adaptado de Winter et al. (2006)

32

Trs fatores so identificados por Cicmil et al. (2006) que causam atropelamento na
execuo dos projetos, quando esses so gerenciamentos pelo modelo clssico:

Complexidade estrutural do produto;

Mudanas devido ao desconhecimento de atividades e aes necessrias;

Tempo restrito para execuo das atividades.

Ento, o projeto de um produto de alta complexidade possui na sua gnese, em sua

complexidade estrutural e tecnolgica, uma fonte de incertezas que dificulta a sua execuo.
O planejamento do tempo , portanto, impreciso, e, como conseqncia, muitas vezes h
restrio dele para execuo das atividades. Os gerentes de projeto so forados a tomar aes
paliativas, que acelerem o ritmo do projeto e podem gerar novos problemas (CICMIL et al.,
2006). Assim, cria-se um crculo vicioso difcil de romper.
Winter et al. (2006) propem que se deve aprofundar a pesquisa em tcnicas e
mtodos, visando o desenvolvimento de solues capazes de gerenciar a complexidade.
Essa idia prxima da proposta de Highsmith (2004) e demais autores do Gerenciamento
gil de Projetos, que criticam os mtodos tradicionais de gerenciamento de projetos por no
conseguirem lidar com o ambiente de incerteza, gerado pela complexidade dos projetos
atuais. A soluo, segundo os autores, seria a utilizao de equipes auto gerenciadas e
flexveis. No h dvida, portanto, da concordncia dos autores de que a teoria tradicional,
dita clssica, no seria til para projetos de alta complexidade, com alto grau de inovao e
envolvendo diferentes organizaes.
Em um exemplo de gerenciamento de um projeto de alta complexidade, descrito por
Moody e Dodgson (2006), observou-se que as tarefas so continuamente ajustadas e
redefinidas conforme o projeto se desenvolve, sendo necessria a adaptao constante do
planejamento das atividades. A interao constante entre os colaboradores, mais informal e
independente da posio hierrquica, tambm foi observada como mais adequada. Desta

33

forma, segundo Moody e Dodgson (2006), os mtodos para o gerenciamento do projeto

devem ser adaptados, de forma a atender essas necessidades de flexibilidade, corroborando as
opinies de Winter et al. (2006) e dos autores do Gerenciamento gil.
A contribuio do grupo de pesquisa Rethinking Project Management importante,
porm, limita-se a criticar a teoria. Esses autores no propem solues prticas, como
mtodos, tcnicas ou ferramentas. J os autores do Gerenciamento gil de Projetos propem
solues que visam formar um novo corpo terico, segundo eles, uma nova abordagem para o
gerenciamento de projetos e que se distinguiria fundamentalmente da abordagem tradicional.
Nas prximas sees, analisa-se de maneira crtica os conceitos e mtodos propostos pelos
autores do Gerenciamento gil de Projetos. Pelo mesmo motivo, optou-se por utilizar o termo
Gerenciamento gil de Projetos para diferenciar do gerenciamento clssico de projetos.

2.2.2. Definio do gerenciamento gil de projetos

As empresas de software operam em um ambiente de rpidas mudanas e altos riscos.
O gerenciamento de projetos fundamental, porm sua introduo no havia sido fcil,
devido ao que se considerava como rigidez e foco excessivo no planejamento. Em 2001,
lanou-se o Manifesto Agile for Software Development (BECK et al., 2001), que procura
enfatizar o uso dos mtodos chamados de geis, voltado para a colaborao com o cliente, nos
indivduos e respostas rpidas s mudanas. Alguns exemplos desses mtodos geis, aplicados
para o desenvolvimento de softwares, so o Extreme Programming (XP), Scrum e Crystal
Methods.
Outras indstrias passaram a adotar prticas denominadas de geis, criando adaptaes
nos mtodos e tcnicas de Gerenciamento Clssico de Projetos, para suprir suas necessidades
no gerenciamento de projetos complexos. Mas, muitas vezes, essas adaptaes apresentam
restries devido aos mtodos e tcnicas do Gerenciamento Clssico e podem apresentar um
desempenho ruim, com reduo da eficincia e eficcia dos resultados (CHIN, 2004).

34

Chin (2004), ento, prope o que ele denomina de uma nova abordagem para o
gerenciamento de projetos, quebrando a viso do forte planejamento prvio das atividades.
Assim, temos o incio do Agile Project Management (APM) ou Gerenciamento gil de
Projetos.
O APM foi definido por Highsmith (2004) como []... um conjunto de valores,
princpios e prticas que auxiliam a equipe a entregar produtos ou servios de valor em um
ambiente desafiador.
A figura 2 mostra esquematicamente a distino entre as duas abordagens. A base de
tijolos representa a eficincia, eficcia de uma plataforma de gerenciamento de projetos. A
figura tem por objetivo transmitir a mensagem de que a teoria clssica necessitaria de uma
dedicao maior em atividades exclusivas de gerenciamento (base maior). Ao passo que no
gerenciamento gil, parte dessas atividades so substitudas por autocontrole da equipe ou
atenuadas por meio do emprego de tcnicas simplificadas e visuais.

Figura 2. Relacionamento entre as abordagens clssica e gil de gerenciamento de projetos

Fonte: CHIN, 2004, p. 3

A figura 2 no suficiente para descrever as diferenas entre as abordagens gil e

clssica. Uma forma de faz-lo descrevendo os objetivos, valores e princpios.

35

2.2.3. Objetivos, valores, princpios e fases do GP gil

So cinco os objetivos principais para um bom processo de explorao do APM
(HIGHSMITH, 2004, p. 6):
1. Inovao contnua. Um dos objetivos bsicos do APM entregar produtos que
atendam aos requisitos atuais dos clientes de maneira inovadora. A gerao de
idias inovadoras no ocorreria em ambientes autoritrios e burocraticamente
estruturados, isto , com regras bem definidas e tarefas cuidadosamente planejadas.
Mas, sim, em ambientes que eles denominam de adaptativos, onde a inovao e
novas solues so priorizadas. Segundo esses tericos, as prticas como o
planejamento prvio e detalhado das atividades de cada membro e atribuio do
controle dos projetos para estruturas organizacionais especficas estimulariam o
comportamento individualista e inibiriam a proposio de idias inovadoras e o
envolvimento da equipe em tarefas como planejamento e controle;
2. Adaptabilidade do produto. Segundo os autores da rea, o APM busca entregar
produtos que atendam os requisitos futuros dos clientes. As prticas geis integram
o custo de mudanas como parte do processo de desenvolvimento, para atender as
mudanas do mercado. Na teoria clssica, o produto definido com todas as suas
caractersticas no incio do projeto, gerando o planejamento detalhado de todas as
atividades. Dessa forma, alterar uma caracterstica do produto para atender a um
requisito, por exemplo, pode se tornar uma barreira. O resultado que os
integrantes podem adiar demasiadamente as mudanas, gerando custos diretos
mais elevados, conseqentemente, prejuzo para a organizao e o cliente;
3. Tempo de entrega reduzido. O APM tem o objetivo de encontrar novos mercados
e melhorar o retorno de investimento. A principal idia a iteratividade, gerando
entregas de curto prazo. Sugere-se que equipes pequenas e qualificadas poderiam

36

manter ateno constante nas caractersticas do produto e foco no curto prazo. Elas
deveriam tambm considerar cuidadosamente quais caractersticas devem ser
includas no produto e criar, assim, um processo de desenvolvimento concentrado
em atividades que agregam valor. A crtica subentendida, que no explicitamente
apresentada por Highsmith (2004), a de que a teoria de GP tradicional
incentivaria planejamentos detalhados e de longo prazo, diminuindo o senso de
urgncia e distanciando a equipe do foco no valor agregado pelas atividades;
4. Capacidade de adaptao do processo e das pessoas. O APM procura responder
rapidamente s mudanas de negcios e produtos. A meta proposta pelo autor
que os membros da equipe no resistam s mudanas no decorrer do projeto, mas
entendam que os produtos podem ser modificados ao longo do seu
desenvolvimento. As equipes tambm precisam ser receptivas s novas idias. A
crtica ao gerenciamento de projetos clssico a de que a especializao e
distanciamento dos membros da equipe fazem com que resistam s mudanas na
forma como conduzir as atividades de projeto, isto , tenderiam a replicar formas
de conduta realizadas em projetos anteriores. E que prticas como controle de
mudana e verificao desestimulariam alteraes nos projetos nas fases iniciais,
gerando problemas futuros. Especialmente no caso de projetos inovadores em que,
segundo o autor, tais mudanas so necessrias;
5. Resultados confiveis. O APM possui o objetivo de apoiar o crescimento e
aumento de lucratividade do negcio. O processo de desenvolvimento deve medir
a importncia da entrega para o cliente ou se a entrega est compatvel com o custo
e o tempo estabelecidos para o projeto. Na teoria clssica, como dito
anteriormente, o foco est no planejamento e controle, com nfase na
documentao e atividades. Isso diminui a preocupao com o valor efetivo. J no

37

enfoque gil, a maior preocupao com o cliente, deixando em segundo plano as

metas definidas para o projeto, j que o cliente quem vai indicar o sucesso do
projeto pelo seu nvel de satisfao. Assim, mais do que se preocupar com a
satisfao de metas previamente estipuladas, os membros das equipes estariam
preocupados se os resultados esto de acordo com as expectativas do cliente: uma
anlise mais qualitativa, portanto.
Alm dos objetivos, os autores de APM descrevem um conjunto de valores e
princpios que norteiam o desenvolvimento de suas atividades, e que, em tese, habilitariam os
gerentes de projetos a alcanar o desenvolvimento de produtos inovadores.
Os quatro valores descritos no Manifesto Agile for Software Development so tambm
os valores centrais nos textos de Gerenciamento gil de Projetos (HIGHSMITH, 2004):
1. Respostas s mudanas: as respostas s mudanas so mais importantes do que
seguir um plano previamente definido;
2. Entrega de produtos: a entrega de produtos mais importante do que a entrega
da documentao;
3. Colaborao do cliente: a colaborao do cliente mais importante do que a
negociao de contratos;
4. Indivduos e interaes: os indivduos e suas interaes so mais importantes que
os processos e ferramentas.
O APM foca nos clientes, produtos e pessoas. Ele visa agregar valor e procura gerar
produtos adaptados s necessidades e visa unir as pessoas em torno de um trabalho
efetivamente colaborativo (HIGHSMITH, 2004).
Cockburn e Highsmith (2001) afirmam que um gerente de projeto tradicional
preocupa-se principalmente com o contrato inicial e com o sistema em si, avaliando-os

38

principalmente nos parmetros tempo e custo. J um gerente gil de projeto preocupa-se em

ajustar continuamente os resultados por meio de uma relao colaborativa com os clientes.

Figura 3. Princpios do Gerenciamento gil de Projetos

Fonte: HIGHSMITH, 2004, p. 28

So seis os princpios do APM, divididos em duas categorias. A primeira relacionada

ao produto/cliente e a segunda, ao gerenciamento (HIGHSMITH, 2004). Esses princpios e
seus relacionamentos esto apresentados na figura 3.
Esses princpios possuem pontos importantes para a caracterizao do APM, tais como
a gerao de entregas iterativas, que incluem o pressuposto de que um projeto possa ser
estruturado em iteraes curtas e de perodo fixo, e a construo de equipes adaptativas, que
possuem formao varivel, de acordo com as necessidades e mudanas necessrias durante o
desenvolvimento do projeto, ajustando-se s variaes do ambiente.
Apesar de o APM enfatizar as pessoas frente ao processo, os prprios autores
enfatizam que o processo de negcio no deve ser ignorado. Highsmith (2004) afirma que o
processo, como qualquer outro elemento da organizao, deve estar totalmente alinhado com
os objetivos de negcio.

39

Mas, se a plataforma gil voltada adaptao, flexibilidade e aprendizado, ento

seus processos devem contemplar essas caractersticas, que definem seu ciclo de vida e fases.
So cinco as fases do Gerenciamento gil de Projetos e esto apresentadas na figura 4
(HIGHSMITH, 2004, p. 81):

Figura 4. Plataforma do Processo de Gerenciamento gil de Projetos

Fonte: Adaptado de Highsmith, 2004, p. 81

1. Viso: determinao da viso do produto e do escopo do projeto, identificao

da comunidade participante do projeto e definio de como a equipe do projeto
trabalhar em conjunto. A principal diferena entre o escopo, derivado da
prtica clssica, e a viso, da prtica gil, est na nfase no produto. A
descrio principal que se faz na viso a das especificaes do produto,

40

primando pela simplificao da documentao, que deve fornecer uma

descrio de alto nvel do produto para os desenvolvedores, de forma a facilitar
a especulao e explorao. Acredita-se que isso levaria a um envolvimento
maior com o cliente do que nas prticas clssicas de iniciao do projeto,
devido ao enfoque contratual (obteno de regras e leis) em linguagem
textual.
2. Especulao: planejamento preliminar, que ser seguido por planejamentos
especficos detalhados a cada iterao. Consiste na identificao dos requisitos
para o produto, desenvolvimento de um plano de projeto, contendo entregas,
marcos, iteraes, cronograma de trabalho e alocao de recursos,
incorporao de estratgias para mitigao de riscos e estimativas de custos e
outras informaes financeiras relevantes. Uma grande diferena da explorao
gil para o planejamento clssico o nvel de detalhe. Aqui, o planejamento s
feito at um futuro previsvel, onde colocado um prximo marco ou ponto
de deciso, evitando assim riscos de planejamentos de longo prazo. A fase
repete-se ao longo do projeto quantas vezes for necessrio.
3. Explorao: composta de trs atividades crticas. A primeira a entrega dos
produtos planejados, atravs do gerenciamento da carga de trabalho. A segunda
a criao de uma comunidade auto organizada do projeto e a terceira, o
gerenciamento das interaes das equipes com os clientes, gerente de projeto e
stakeholders, que so as partes interessadas no projeto. Nesta fase, o
autocontrole um diferencial. A proposta que a comunidade do projeto esteja
comprometida em realizar as entregas e no sejam apenas participantes
passivos, aguardando ordens para cumprir tarefas. Eles ajudam a gerenciar sua
carga de trabalho da melhor maneira, contando com a ajuda do gerente do

41

projeto e no esperando que esse ltimo tome todas as decises necessrias

para entregar o produto ao cliente e apresentar os resultados aos stakeholders.
4. Adaptao: reviso dos resultados entregues, anlise da situao atual,
avaliao do desempenho da equipe de projeto e mudanas, se necessrias.
Essa reviso considera tambm, alm da comparao do realizado versus o
planejado, o realizado versus informaes e requisitos atualizados do projeto.
Esta fase, junto com a especulao e explorao, ocorre vrias vezes durante o
projeto e envolve o esforo no s do gerente do projeto, mas de toda a
comunidade. Ela caracteriza os vrios ciclos de mudanas que ocorrem ao
longo do projeto para suprir as demandas atuais e atingir o sucesso do projeto.
Nas prticas clssicas, o planejamento detalhado, que feito no incio do
projeto, inibe adaptaes necessrias, conforme apresentado nos objetivos do
gil. Aqui o objetivo adaptar o projeto segundo as necessidades atuais,
incentivando a equipe do projeto a ter um esprito crtico e participar da
prxima especulao do projeto.
5. Encerramento: finalizao das atividades do projeto, transferncia dos
aprendizados-chave e celebrao. Como ltima fase, aps uma adaptao onde
no so identificados mais requisitos e realizadas as avaliaes de entregas e
status do realizado versus planejado, o projeto pode ser encerrado. Aqui as
prticas geis e clssicas so idnticas. Nos dois casos realizado um histrico
do projeto para possveis consultas futuras.

O quadro 3 apresenta uma correspondncia entre os principais grupos de processo da

plataforma Clssica de GP e as fases do APM.

42

Grupo de Processos da GP Clssica

Iniciao: autorizao/definio
escopo preliminar

de

Fases do GP gil
um Viso: do produto e escopo inicial do projeto

Planejamento: detalhamento de todo projeto

Especulao: plano inicial, planejamento a

cada iterao

Execuo: execuo do plano do projeto

Explorao: entrega funcionalidade/produto

a cada ciclo

Monitoramento e Controle: progresso do Adaptao: reviso dos resultados entregues

trabalho e gerenciamento de mudanas
e adaptaes do escopo
Encerramento: Formalizao do aceite final Encerramento: aceites do cliente a cada
do projeto
ciclo e formalizao final
Quadro 3. Correspondncia entre as abordagens clssica e gil de GP
Fonte: Dias (2005)

Segundo Chin (2004), uma estrutura que apie as prticas de GP indicada e pode
trazer benefcios. O mesmo autor prope que essa estrutura deve incluir: processos, prticas,
ferramentas de software, modelos de documentos e formulrios, representados na figura 5,
com as suas interaes. Esses elementos auxiliariam na elaborao de relatrios e documentos
contendo informaes valiosas para a tomada de deciso no projeto. Highsmith (2004)
enfatiza que os relatrios de status de projeto devem adicionar valor para o gerente do projeto,
gerente de produto, stakeholders e para a prpria equipe de projeto.
Analisando-se a estrutura operacional de Chin (2004), possvel reconhecer uma
significativa influncia com os modelos de estruturas para gerenciamento tradicional de
projetos, tais como escritrios de projetos e modelos de gesto de projetos. Notem-se as
definies de responsabilidades, cronogramas, uso de padres. Isso se explica na premissa de
que a proposta dos tericos do gil no significa negligenciar controles, planos e
padronizao.

43

Figura 5. Estrutura operacional para apoio ao gerenciamento gil de projetos

Fonte: Adaptado de CHIN, 2004 p. 166

A anlise leva a crer que a proposta desses autores mant-los, porm com uma
diferena na forma de aplicao desses conceitos. Trata-se, portanto, de uma proposta de
processos de gerenciamento de projetos que busca procedimentos mais simples por meio das
estratgias como: emprego de quadros e elementos visuais; eliminao de atividades de
gerenciamento que no agregam valor; e transferncia de mecanismos de controles
burocrticos para a equipe, por meio da autogesto (HIGHSMITH, 2004 e CHIN, 2004).
Em virtude dessa anlise que se convencionou neste trabalho o uso do termo
enfoque para designar o APM, em lugar do termo paradigma, amplamente empregado
pelos tericos do APM. A palavra enfoque remete a modelo, padro3. Portanto, dizer novo
3

Segundo Larousse (1992), paradigma um substantivo que designa modelo, padro ou norma. O mesmo
dicionrio fornece o significado de enfoque como ao de enfocar, modo de considerar ou entender um assunto
ou questo.

44

paradigma parece representar uma forma totalmente inovadora de se gerenciar projeto.

Enfoque, ao contrrio, significaria uma nova forma de utilizar as ferramentas existentes. A
reviso aqui apresentada permite concluir que as propostas dos autores de APM representam
mais uma especializao da teoria de gerenciamento de projetos, para um caso especfico, que
o de projetos complexos e de produtos inovadores.

2.2.4. Aplicabilidade do gerenciamento gil de projetos

A comunidade de desenvolvimento de software foi a primeira a adotar na prtica os
conceitos do gerenciamento gil em seus projetos. A literatura sobre o tema principalmente
constituda de casos nessa rea (BECK, 1998; BOEHM, 2002; COCKBURN, 2002; COHN e
FORD, 2003; FOWLER, 2000; AUGUSTINE e WOODCOCK, 2003).
Chin (2004) e Highsmith (2004) indicam o uso do gerenciamento gil para projetos
tambm para o desenvolvimento de produtos manufaturados, desde que com aspectos
inovadores e em ambientes competitivos. A figura 6 apresenta os possveis ambientes de
projeto para aplicao da abordagem gil, segundo Highsmith (2004).

45

Figura 6. Ambientes para aplicao do enfoque gil

Fonte: adaptado de Highsmith (2004) por Conforto e Amaral (2007)

A aplicao do gerenciamento gil no desenvolvimento de produtos fsicos ainda est

em fase de estudos. Benassi e Amaral (2007) e Conforto e Amaral (2007a; 2007b) apresentam
anlises tericas da aplicao do APM para o desenvolvimento de produtos. Benassi e Amaral
(2007) revisaram a literatura sobre gerenciamento de projetos e identificaram apenas um
trabalho de aplicaes do APM fora do contexto de software. Mais, os trabalhos identificados
so em sua totalidade tericos. Portanto, no h dados efetivos de campo, verificando a
aplicao desses mtodos. Mesmo tendo se passado vrios anos desde que Maylor (2001)
apresentou a mesma dificuldade.

46

2.3. Sntese dos desafios encontrados

A seo 2.2 apresentou as crticas realizadas pelos tericos da rea de gerenciamento
de projetos e tambm pelos autores do enfoque gil. A anlise dos trabalhos permite mostrar
uma convergncia em termos de crticas teoria de gerenciamento de projetos. Conforme
ilustrado na figura 7, as direes de pesquisa apontadas no estudo de Winter et al. (2006) so
coerentes com as idias propostas no enfoque gil.

Figura 7. Coerncia entre as direes do EPSRC e idias do enfoque gil

Fonte: elaborado pela autora, com base em Winter et al. (2006) e Highsmith (2004)

A partir da literatura analisada, podem-se identificar, alm da convergncia das

crticas, os principais desafios:
a) Falta de modelos e tcnicas capazes de adequar-se s mudanas dos
projetos. Existe a necessidade de tcnicas e mtodos para o planejamento
e controle capazes de: aumentar a velocidade da elaborao de planos e
sua atualizao; criar tcnicas de planejamento com planos mais

47

sintticos, sem perder a preciso e efetividade; criar sistemas de controle

que sejam mais rpidos na identificao das necessidades de mudana;
b) Falta de modelos e tcnicas que apiem o acompanhamento e
alteraes constantes no resultado final. Em virtude das maiores
mudanas, devem-se criar solues para aprimorar o acompanhamento
dos resultados no produto do projeto. Assim, preciso criar tcnicas de
gerenciamento de requisitos e controles de configurao do produto.
c) Compartilhamento efetivo de recursos. As tcnicas tradicionais
priorizam o gerenciamento centralizado de dados de recursos, por meio da
criao de pools de recursos. Em projetos compartilhados ou onde
competncias so identificadas no decorrer do projeto, geram-se
problemas. necessrio criar tcnicas e mtodos que facilitem o
planejamento de recursos compartilhados entre projetos de diferentes
nveis de complexidade.
d) Consumo de tempo em extensa documentao do projeto. A
padronizao, sem dvida, algo importante. O desafio, ento, realizla de forma adequada, garantindo que ela seja o suficiente para agregar
valor ao projeto. Formas mais simples, rpidas e eficientes de
documentao e criao dos padres so fundamentais. Outro desafio
combinar a utilizao de padres com a melhoria contnua, isto , a
atualizao constante desses padres de forma a garantir a introduo de
melhorias conforme as experincias em projetos anteriores.
e) Implantar tcnicas que permitam o emprego dos princpios propostos
pelo gerenciamento gil de projetos. Conforme demonstrado, embora os
tericos do gerenciamento gil de projetos tenham proposto um conjunto

48

bem organizado de princpios, h falta de mtodos e tcnicas que

permitam utiliz-los. Ou, ento, a identificao de como adaptar os
mtodos e tcnicas atuais. Os principais desafios so: foco nas pessoas;
equipes auto gerenciadas e flexveis; criao de valor para o cliente;
explorao e adaptabilidade do produto; capacidade de adaptao do
processo e das pessoas.
A figura 8 apresenta uma sntese dos desafios identificados na literatura de
gerenciamento de projetos e na de gerenciamento gil. Identifica tambm a relao entre eles,
por meio de flechas, que indicam quais os desafios so equivalentes.

Figura 8. Sntese e relao entre os desafios encontrados na literatura

Fonte: elaborada pela autora

49

3. Softwares para gerenciamento de projetos

Esta seo apresenta a definio de Software para Gerenciamento de Projetos (SGP),
as funcionalidades que caracterizam tais solues (3.1) e uma anlise da situao atual dos
principais sistemas disponveis no mercado (3.2). Ao final, apresenta uma sntese dos
principais desafios, considerando a situao atual dos SGPs segundo a literatura e os desafios
apontados no captulo 2, segundo a literatura de mtodos de gerenciamento de projetos (3.3).

3.1. Definio e funcionalidades dos softwares de gerenciamento de projetos

O gerenciamento de projetos inclui uma mistura complexa de atividades de
planejamento, avaliao e tomada de decises. As informaes geradas no decorrer do projeto
so fundamentais para o sucesso. Elas precisam ser coletadas, atualizadas e apresentadas de
forma correta a todos os envolvidos no projeto. Para auxiliar nesse gerenciamento, tornou-se
importante o uso de softwares especficos, chamados de Softwares de Gerenciamento de
Projetos (SGP). O PMBOK (2004) define os SGPs como:
aplicativos de software especificamente projetados para auxiliar a equipe
de gerenciamento de projetos no planejamento, monitoramento e controle
do projeto, inclusive: estimativa de custos, elaborao de cronogramas,
comunicao, colaborao, gerenciamento de configurao, controle de
documentos, gerenciamento de registros e anlise de risco.

Um conjunto de funcionalidades tpicas pode ser observado para os SGPs, tais como
(ROZENFELD et al., 2005):

Gerenciamento de Atividades: registro, visualizao e organizao das

atividades do projeto. Envolve vrias definies, tais como: de precedncia, de
durao, de esforo, Grfico de Gantt e WBS (Work Breakdown Structure);

50

Gerenciamento de Calendrio e Agenda: organizao e programao de um ou

mais calendrios para o projeto, recursos ou tarefas;

Gerenciamento de Recursos: gerenciamento das pessoas e materiais

necessrios para o projeto. Envolve funes de anlise de alocao de recursos
e seu nivelamento;

Gerenciamento

de

Custos:

ajuda

preparao

do

oramento

acompanhamento dos gastos do projeto;

Ferramentas de Monitoramento: funes para acompanhamento do projeto,

como armazenamento de linhas de base e comparaes entre parmetros de
planejamento atual com os parmetros das linhas de base, bem como anlise do
valor agregado;

Gerenciamento de mltiplos projetos: funes para anlise do portiflio da

empresa e compartilhamento de dados entre os projetos.

Na prxima seo (3.2), realizada a reviso de softwares, mostrando-se suas

categorias, segundo a forma de distribuio.

3.2. Softwares de GP segundo a literatura

Nesta seo, procura-se mostrar um panorama geral dos SGPs disponveis atualmente.
Deve-se observar que o objetivo no fazer um estudo exaustivo de todas as ferramentas, mas
apresentar uma descrio das funcionalidades dos SGPs encontrados no mercado, segundo
informaes da literatura.
Os SGPs podem ser classificados em trs grandes categorias, segundo a forma de
comercializao:

Cdigo Fechado: so os softwares distribudos com o cdigo inacessvel ao

usurio final. Segundo a Wikipedia (2008), o que caracteriza este tipo de

51

software que ele no distribudo com seu cdigo fonte e, para alter-lo,
seria necessrio utilizar a prtica da engenharia reversa, o que costuma ser
dificultado seja pelo uso de licenas, seja pela distribuio apenas de arquivos
compilados e ou outros mecanismos de segurana como Hard-Keys. Em sua
maioria, os softwares utilizam licenas de comercializao tradicionais, isto ,
por meio da compra do cdigo por pacote, nmero de usurios ou acesso. A
Licena Comercial pode reservar tambm direitos de uso, tais como suporte,
atualizao peridica e acesso documentao e outros materiais. Outro
modelo de software que se encaixa na categoria de cdigo fechado o
denominado freeware, que tambm no apresenta o cdigo fonte, apesar de
sua utilizao no implicar o pagamento de licenas de uso.

Cdigo Aberto: So softwares onde o cdigo-fonte est disponvel para ser

lido, estudado ou modificado por qualquer pessoa interessada. Os softwares
desta categoria so chamados de software livre e o cdigo-fonte aberto a
principal caracterstica desses (REIS, 2003). Um software livre tambm
concede as seguintes 4 liberdades: a liberdade de executar o programa, para
qualquer propsito (liberdade n. 0); a liberdade de estudar como o programa
funciona e adapt-lo para as suas necessidades (liberdade n. 1); a liberdade de
redistribuir cpias de modo que se possa ajudar ao seu prximo (liberdade n.
2) e a liberdade de aperfeioar o programa, e liberar os seus aperfeioamentos,
de modo que toda a comunidade se beneficie (liberdade n. 3). As licenas de
software livre permitem que eles sejam comercializados. Na prtica, j que
possvel copiar o cdigo de qualquer pessoa que j o tenha, o preo que o
usurio paga por um software livre tende a ser baixo o suficiente para motivar
as pessoas a comprarem e no o copiarem. (REIS, 2003).

52

Modelos Cientficos: so prottipos de softwares propostos em estudos

acadmicos, que testam novos conceitos e funcionalidades. Esses modelos
visam avanos cientficos, solucionando os problemas apresentados nos
sistemas de cdigo fechado e/ou aberto, apresentados pelas necessidades do
mercado ou para viabilizar prova de conceito de alguma teoria. A principal
caracterstica que a ferramenta est em estudo, em fase de prototipao ou
validao, no sendo acessvel ao mercado.

A seguir, apresentam-se as anlises realizadas, a partir de documentos, nos dois

primeiros tipos: softwares comerciais para gerenciamento de projetos e softwares livres.
No caso dos modelos cientficos, no foi identificada nenhuma reviso bibliogrfica
exaustiva. H apenas artigos que realizam revises limitadas como os de Voropajev e
Schinberg (1992), Nicolo (1993), Li et al. (2001), Ren et al. (2006) e Liu et al. (2005).
Portanto, optou-se por realizar uma reviso especfica desses tipos de software, descrita na
subseo 5.2.1, como parte da contribuio deste trabalho.

3.2.1. Softwares de cdigo fechado

Em uma avaliao dos softwares comerciais de Gerenciamento de Projetos de alta
representatividade no mercado, realizada pelo Gartner Group (2007), pde-se observar alguns
aspectos das funcionalidades disponveis. Foi desenvolvido um quadrante de classificao dos
softwares (Quadrante Mgico), com dois eixos: habilidades para executar e abrangncia da
viso. O eixo Habilidade para Executar refere-se ao desenvolvimento e desempenho do
fornecedor de software (vendor) e incluiu os critrios: lucratividade, nvel e crescimento dos
rendimentos da empresa; equipe de gerenciamento do vendor; integridade; aprofundamento
(detalhamento) das funcionalidades das ferramentas de aplicao; servio e suporte; vendas e
marketing. J o eixo Abrangncia da Viso inclui critrios relacionados s funcionalidades
dos softwares como Abrangncia, so eles: compatibilidade com plataformas; colaborao,

53

funcionalidades especficas; tecnologia e mercado; gerenciamento de recursos; e servios de

suporte.
No quadrante dos Lderes, no basta o sistema ter funcionalidades abrangentes, mas
tambm o fornecedor do software (vendor) deve incluir as tecnologias de desenvolvimento
mais modernas e comprometimento com um servio de excelncia. O quadrante dos
Desafiantes, segundo esta anlise, contm os softwares que oferecem funcionalidades, que,
apesar de limitadas, podem impulsionar o canal de vendas. Sua presena internacional e
possuem base instalada. Esses produtos seguem as funcionalidades tradicionais, descritas em
Rozenfeld et al. (2006) e na seo 3.1. Isso foi confirmado analisando-se a documentao
tcnica de Microsoft Project (EPM) e a do Primavera , disponveis na internet (MICROSOFT,
2008; PRIMAVERA, 2008).

54

Figura 9. Quadrante de classificao dos softwares comerciais

Fonte: relatrio do Gartner Group (2007)

Para esta pesquisa, interessam os dois ltimos quadrantes: visionrios e nichos. Os

Visionrios so aqueles, segundo a pesquisa, que possuem funcionalidades e ou configuraes
alternativas. Para verific-las, empregou-se uma anlise da documentao tcnica presente na
internet dos softwares indicados na figura 9. O critrio utilizado foi a busca de funes
diferentes das citadas na seo 3.1. A seguir, apresentada uma breve descrio das

55

funcionalidades diferenciais de cada software verificado, isto , aquelas que diferem da lista
apresentada por Rozenfeld et al. (2005).
O IBM RPM inclui o controle de colaborao no projeto, alm das funcionalidades j
citadas como bsicas dos SGPs. Ele fornece aos gerentes e participantes do projeto
informaes sobre acontecimentos e alteraes durante o decorrer do projeto, utilizando
notificaes de estado e condies de disparo de e-mails configurados pelo usurio
especificamente para cada projeto (IBM, 2008).
Nas informaes tcnicas publicadas sobre o Serena (Serena Mariner), no h
explicaes suficientes sobre suas funcionalidades (SERENA, 2008). Portanto,no foi
possvel avaliar o diferencial. O texto destaca uma funcionalidade de monitor de desempenho
do projeto em tempo real (SERENA, 2008).
O aplicativo da Borland (Borland Tempo), pelas informaes tcnicas disponveis no
site, disponibiliza as funcionalidades bsicas dos SGPs, incluindo tambm coleta de
informaes que permite modelar documentos padro do projeto e do planejamento, como
formulrios on-line; relatrio de acompanhamento de sanidade do projeto, como relatrios
imediatos de progresso, alertas de vencimento de prazo de tarefas e notificaes aos membros
da equipe (BORLAND, 2008). Portanto, no foi possvel identificar funcionalidades
diferenciais.
J o software da EProject (Daptiv PPM) possui foco em funcionalidades de
colaborao. Um exemplo a troca de mensagens assncronas integrada s funes
tradicionais de GP, incluso de documentos no projeto utilizando funo drag-and-drop
(arrastar e soltar) nas janelas; e funcionalidade para registro e gerenciamento de Lies
Aprendidas (EPROJECT, 2008).
O Sciforma (PS8) tem como diferencial o apoio criao de templates para os
projetos. Dispe de funcionalidades para criar grficos e relatrios, alm dos existentes no

56

software, com o intuito de melhorar o acompanhamento e avaliaes do projeto. Ele tambm

disponibiliza troca de mensagens assncronas pelo software (SCIFORMA, 2008).
O site da Powersteering no disponibilizou informaes tcnicas do seu produto, por
isso no foi possvel avali-lo (POWERSTEERING, 2008). Pelo mesmo motivo, tambm no
foi possvel avaliar o software da ITM (ITM, 2008).
A anlise, embora parcial, indica que os softwares ditos visionrios no apresentam
funcionalidades to distantes dos softwares tradicionais. A diferena est principalmente na
incluso de ferramentas de troca de mensagens, nos relatrios de acompanhamento mais
avanados e nas lies aprendidas.
No quadrante do Nicho, esto os softwares que, segundo a anlise, atendem
necessidades especficas de determinado grupo de clientes, como funcionalidades especficas
de gerenciamento de portfolios ou adaptaes para padres de regies geogrficas.
Os softwares da Instantis e Augeo Software possuem funcionalidades especficas para
projetos de desenvolvimento de novos produtos, mas no detalham essas funcionalidades em
seus sites. Os demais softwares que compem o quadrante no apresentaram, pelas
informaes tcnicas nos sites, funcionalidades diferenciais.
Conforme o objetivo deste trabalho, chamam a ateno nessa categoria as solues
voltadas para o desenvolvimento de projetos de TI, pois entre os sistemas de nicho h
fabricantes que se propem a implementar funcionalidades conforme as diretrizes do enfoque
gil de desenvolvimento de produtos. Analisando-se sua documentao, identificaram-se
como funes diferenciais o cadastro dos projetos, iteraes e entregas programadas por
iterao, registro para acompanhamento dos problemas e mudanas necessrias no decorrer
do projeto e controle dos Releases do software desenvolvido integrado com os planos de
iterao. Suas funcionalidades so baseadas nos mtodos Scrum, XP (eXtreme Programming),
DSDM (Dynamic Systems Development Method) e Agile Up. Por serem solues que visam o

57

mesmo propsito dessa pesquisa, julgou-se que seria fundamental uma anlise pormenorizada
desses softwares. Portanto, optou-se por realizar uma avaliao especfica, a partir do contato
com o prprio sistema, indo alm da documentao. Essa anlise apresentada na subseo
5.2.2, pois faz parte de um dos resultados da pesquisa.

3.2.2. Softwares de cdigo aberto

Os softwares de cdigo aberto disponveis no mercado so muitos. Nos sites
http://freshmeat.net/ e http://sourceforge.net/ possivel observar dezenas de ferramentas nessa
categoria.
Roriz, Juc Junior e Amaral (2004) realizaram um estudo dessas ferramentas de
cdigo aberto e encontraram mais de 50 softwares. O mtodo empregou as seguintes etapas:
1) Anlise da ferramenta MSProject 2002 e Primavera para a elaborao dos critrios
de anlise das funcionalidades;
2) Criao dos critrios de anlise das funcionalidades do GP, gerando uma lista com
58 critrios, divididos em nove categorias;
3) Depois de uma primeira seleo dos softwares disponveis, que descartou as
ferramentas com funcionalidades especficas ou com graves limitaes, obteve-se uma lista
com 25 softwares. Utilizando-se consultas a duas listas de discusses de gerentes de projeto,
foram selecionados os seis mais citados (TUTOS, 2008; PHPROJEKT, 2008; PHPCOLLAB,
2008; DOTPROJECT, 2008; PLANNER, 2008; OPEN WORKBENCH, 2008), que foram
analisados segundo os 58 critrios;
O quadro final apresentado na tabela 1, onde 100% significaria o atendimento a
todas as funcionalidades presentes no software PRIMAVERA e MS PROJECT.
Portanto, a ferramenta que recebeu a melhor pontuao na anlise, em relao sua
aplicao nas empresas de base tecnolgica, encontra-se em nvel de sofisticao bem inferior
dos softwares proprietrios utilizados como base para os critrios. Desta forma, nas

58

concluses do trabalho, foi demonstrado um panorama onde as ferramentas de cdigo aberto

apresentam deficincias e no possuem maturidade suficiente para sua utilizao direta, sem
implementaes de novas funcionalidades (RORIZ, JUC JUNIOR e AMARAL, 2005). O
estudo completo das ferramentas encontra-se anexo a esta dissertao.

TUTOS PHProjekt PHPcollab Dotproject Planner

Open
Workbench

Banco de dados

100%

100%

100%

90%

25%

5%

Calendrio e agenda

23%

13%

3%

13%

37%

37%

Gesto de atividades

38%

36%

30%

42%

46%

64%

Gesto de recursos

36%

32%

10%

14%

22%

32%

Gesto de custos
Gesto de
documentos relatrios
e impresso

30%

10%

0%

10%

15%

55%

33%

40%

27%

27%

27%

33%

Ferramentas de
monitoramento

10%

3%

10%

10%

3%

50%

Gesto de mltiplos
projetos

4%

4%

4%

4%

0%

36%

38%
65%
75%
65%
3%
Tabela 1. Avaliao dos softwares de cdigo aberto
Fonte: Roriz, Juc Junior e Amaral (2005)

13%

Ferramentas de
comunicao e
integrao

3.3. Sntese dos softwares de GP frente colaborao e agilidade

Os primeiros softwares de gerenciamento de projetos foram concebidos no contexto de
grandes projetos, com localizao nica. Um exemplo um dos SGPs comerciais mais
conhecidos, o Microsoft Project, que teve sua primeira verso lanada em 1987. No decorrer
desse perodo at hoje, esses softwares evoluram no sentido de apoiar praticamente todas as
reas do gerenciamento de projetos tradicional, apresentadas na seo 2.1.2. Na seo 3.1,
foram descritas as funcionalidades comumente encontradas nesses softwares.

59

Observou-se, porm, na seo 2.1., que os projetos de desenvolvimento de produtos

com altos nveis de inovao so dinmicos e incertos, com escopo impreciso e acontecem em
colaborao com universidades, institutos de pesquisa ou outras empresas fornecedoras e
clientes - organizaes com caractersticas significativamente distintas. Essa realidade
bastante diferente do contexto no qual os primeiros SGPs foram concebidos, conforme
constatado por vrios autores da reviso bibliogrfica. Como resultado, h uma srie de
problemas especficos e desafios, apresentados no quadro 4.
Desafios
Falta de informao sobre o que as outras
equipes do projeto esto fazendo (progresso
das tarefas);
Falha no controle de mudana do projeto
Vises diferentes sobre os objetivos do
projeto
Rigidez no planejamento do projeto e das
rotinas
Reaes pobres em relao s mudanas
repentinas no ambiente do projeto
Dificuldades tecnolgicas inesperadas
Falha no controle de mudana do projeto
Falta de Responsabilidades claramente
definidas
Criao de um plano de projeto aceito entre as
partes
Falta de marcos de projeto definidos
Falta de recursos adequados
Falha no monitoramento regular do progresso
Falta de comunicao efetiva
Falta de compromisso na entrega por parte
dos colaboradores

Fonte
Hameri e Puittinen (2003)
Hameri e Puittinen (2003)
Hameri e Puittinen (2003); Barnes, Pashby
e Gibbons (2006)
Hameri e Puittinen (2003)
Hameri e Puittinen (2003)
Hameri e Puittinen (2003)
Hameri e Puittinen (2003)
Barnes, Pashby e Gibbons (2006)
Barnes, Pashby e Gibbons (2006)
Barnes, Pashby e Gibbons (2006)
Barnes, Pashby e Gibbons (2006)
Barnes, Pashby e Gibbons (2006)
Barnes, Pashby e Gibbons (2006)
Barnes, Pashby e Gibbons (2006)

Quadro 4. Novos desafios para o gerenciamento de projetos colaborativos

Na seo 2.2, demonstrou-se que h novas tendncias na teoria de Gerenciamento de

Projetos, como o enfoque gil e os trabalhos de autores como o grupo do ESPRC. Elas
caminham no sentido de criticar o foco da teoria atual. Sugerem que os mtodos e
ferramentas existentes, que denominam usualmente de Gerenciamento de Projetos Clssico,

60

no responderiam s necessidades das organizaes que convivem nesse novo cenrio. Seria
preciso desenvolver mtodos e tcnicas que fossem capazes de atender aos seguintes desafios:

Adequar-se s mudanas dos projetos;

Apoiar o acompanhamento e alteraes no resultado final;

Compartilhar recursos entre projetos;

Consumir pouco tempo com documentao;

Empregar os princpios do gerenciamento gil.

A reviso bibliogrfica demonstrou a inexistncia de estudos empricos com

avaliaes de problemas no uso de SGPs existentes, em casos de projetos reais e segundo a
perspectiva dos usurios. H trabalhos correlatos, que descrevem a aplicao de uma soluo
especfica ou que, entre outras questes, abordam tambm o aspecto SGP. Apesar da
quantidade pequena, eles indicam que h ineficincias e problemas que precisam ser
solucionados.
Dentre os estudos que apontam problemas nos SGPs, est o de White e Fortune
(2002). Os autores apresentam um survey sobre experincias reais de gerenciamento de
projetos. O questionrio foi desenvolvido para identificar os mtodos, ferramentas e tcnicas
em uso atualmente, e estabelecer uma lista de fatores crticos de sucesso em gerenciamento de
projetos. Foram escolhidos 995 gerentes de projetos, que representavam 620 organizaes
diferentes, tanto do setor pblico como do privado. Do total de questionrios enviados (995),
236 retornaram e foram avaliados no desenvolvimento da pesquisa. Nesse estudo, os
softwares de gerenciamento de projetos aparecem como uma das principais limitaes
entre os mtodos/ferramentas/tcnicas do gerenciamento de projetos. A explicao
apresentada que esses softwares seriam inadequados s necessidades das empresas,
principalmente para projetos complexos. As autoras chamam de complexo um projeto onde
vrias organizaes participam de seu desenvolvimento, caso dos projetos colaborativos.

61

Coterrel (1998)4 apud White e Fortune (2002) diz que poucos softwares de gerenciamento de
projetos possuem funcionalidades que apiem o compartilhamento de recursos e informaes
segundo as necessidades desses tipos de projeto.
Bergman e Baker (2000) afirmam que as solues para o compartilhamento dos dados
de projetos utilizadas nas empresas, na poca do estudo, eram ferramentas ou famlia de
ferramentas simples de escritrio, como o MS-Office. Segundo os autores, elas so
insuficientes para engenheiros, porque eles usam muitas ferramentas diferentes e diversas
plataformas computacionais. Liu (2003) prope uma arquitetura para integrar os diferentes
sistemas utilizados pelas empresas para ajudar no gerenciamento de seus projetos,
convertendo informaes de um sistema para o outro.
Ren et al. (2006), baseados na experincia de proposio de uma soluo especfica
para gerenciamento de projetos colaborativos, afirmam que uma nova gerao de ferramentas
de planejamento de projetos colaborativos precisa ser construda. Seu estudo direcionado
para as parcerias de pequenas e mdias empresas, e o modelo apresentado foca na preparao
e planejamento dos projetos colaborativos. Segundo Woerner e Woern (2005), a maioria das
plataformas de colaborao possui uma arquitetura centralizada e focada nas fases de
desenvolvimento de novos produtos e novos processos de produo. Esse um aspecto
inadequado quando se trata de colaborao em pequenas e mdias empresas, onde o controle
sobre os dados um critrio fundamental.
Outro dado relevante apresentado na pesquisa de White e Fortune (2002) a
dificuldade de um modelo que demonstre o mundo real dos projetos e a documentao
extensa do projeto, que consome muito tempo na sua execuo e torna-o mais burocrtico.
Portanto, os problemas enfrentados no gerenciamento de projetos colaborativos pelas
empresas so:

COTTERREL, S. Annual Software Review 1998. Project Manager Today 1998; August: 22-3.

62

falta de recursos que apiem o acompanhamento e alteraes constantes

no resultado final, isto , no produto do projeto;

falta de compartilhamento efetivo de recursos, j que os softwares

tradicionais centralizam as informaes em um lugar e no permitem
que cada empresa tenha seus dados em formatos distintos;

falta de um modelo capaz de adequar-se s mudanas dos projetos;

consumo de tempo em extensa documentao do projeto.

Portanto, os trabalhos citados, que avaliam casos reais de SGPs, reforam ainda mais a
necessidade de avano nas solues. Nota-se tambm que os problemas so especialmente
maiores no caso de projetos de alta complexidade e alto grau de inovao. Esses problemas
seguem na mesma linha das crticas do gerenciamento de projetos tradicional.
Ao analisarmos as mudanas em desenvolvimento atualmente nos softwares de
gerenciamento de projetos, possvel identificar preocupaes semelhantes. O levantamento
realizado na seo 3.2.1 demonstra que os sistemas mais inovadores esto incorporando:

funcionalidades de colaborao integradas com as funcionalidades de

gerenciamento de projetos;

funcionalidades para acompanhamento contnuo das mudanas no

produto;

funcionalidades para apoio na elaborao de relatrio de controles e

acompanhamentos mais sofisticados.

A anlise dos SGPs existentes identificou tambm o surgimento de sistemas que se

propem especificamente o Gerenciamento de Projetos segundo o modelo do Gerenciamento
gil. As novas ferramentas englobam, de forma geral, o cadastro dos projetos, suas iteraes
e as entregas programadas para cada iterao, com acompanhamento dos problemas e
mudanas necessrias ao decorrer do projeto e controle dos Releases do software

63

desenvolvido. Suas funcionalidades so baseadas nos mtodos Scrum, XP (eXtreme

Programming), DSDM (Dynamic Systems Development Method) e Agile Up.
Os resultados obtidos demonstram uma coerncia entre os problemas identificados no
gerenciamento colaborativo de projetos, as tendncias de melhoria das tcnicas e mtodos de
GP e as inovaes em funcionalidades dos SGPs. A figura 10 demonstra a relao.

Figura 10. Desafios para os SGPs Colaborativos

Fonte: elaborada pela autora

Portanto, os desafios para a evoluo de SGPs envolvem os seguintes aspectos:

Desenvolver ambientes customizados para cada projeto com funcionalidades

que privilegiem a viso do produto final, isto , a agregao de valor;

Criar sistemas que explorem planos baseados em entregas e iteraes, e que

sejam mais visuais;

64

Criar funcionalidades que facilitem as alteraes constantes no produto e

gerem informaes realistas e em tempo real sobre o andamento do projeto;

Apoiar a colaborao, com ferramentas e funcionalidades que facilitem a troca

rpida de informaes, garantindo tambm a privacidade das partes
interessadas

Utilizar plataformas heterogneas (promovendo a descentralizao da

informao e permitindo inclusive que diferentes equipes possam utilizar
sistemas distintos conforme sua convenincia).

Alm dessas concluses, a reviso demonstra que anlises mais profundas precisariam
ser feitas, ao menos em trs aspectos:

H poucos estudos empricos sobre os problemas na utilizao de SGPs

sob a tica da empresa. Assim, foram includos estudos de casos nesta
pesquisa, apresentados na seo 5.1;

No h estudos avaliando o estado da arte dos SGPs propostos na

literatura cientfica. Assim, realizou-se uma anlise especfica,
apresentada na seo 5.2;

H propostas de softwares comerciais voltados para as necessidades do

gerenciamento gil de projetos. Assim, incluiu-se uma anlise dos
softwares comerciais, apresentada na seo 5.2.

65

4. Mtodo
Este captulo apresenta os objetivos da pesquisa e o mtodo empregado para
desenvolv-la. Inicia-se com a apresentao da motivao e justificativa do trabalho, seo
4.1. Em seguida, apresentam-se os objetivos, delimitados por meio de questes de pesquisa,
na seo 4.2. A classificao do mtodo descrita na seo 4.3. Por fim, as etapas realizadas
so descritas na seo 4.4.

4.1. Motivao e Justificativa

Conforme demonstrado nos captulos iniciais, em especial nas sees 2.1 e 2.2, a
colaborao vem se tornando uma das estratgias mais importantes para o desenvolvimento
de novos produtos e tecnologias. Desenvolver softwares que a apiem essencial para a
competitividade das empresas.
Demonstrou-se tambm (seo 3.3) que os softwares atuais de Gerenciamento de
Projetos precisam avanar em vrias frentes para se adequar aos novos desafios de projetos
colaborativos e complexos.
Os princpios e conceitos do enfoque de Gerenciamento gil de Projetos podem ser
uma soluo, conforme demonstrado na reviso bibliogrfica, captulos 2 e 3. A utilizao de
suas diretrizes pode ser um caminho para a criao de uma nova classe de softwares de
gerenciamento de projetos. Resta saber como estes conceitos podem ser aproveitados, e que
mudanas poderiam ser realizadas nos softwares de GP.

4.2. Objetivo
O tema geral de pesquisa a identificao das necessidades de evoluo dos softwares
de gerenciamento de projetos (SGP) frente s necessidades de desenvolvimento colaborativo e
aos princpios do gerenciamento gil de projetos. O objetivo central, portanto, identificar

66

quais os requisitos necessrios para o desenvolvimento de softwares que sejam capazes de

apoiar o Gerenciamento gil de Projetos (APM), no caso de projetos que envolvam
colaborao e produtos complexos.
Este objetivo pode ser desdobrado em objetivos secundrios:
a) compilar os desafios enfrentados pelos mtodos e tcnicas de gerenciamento de
projetos de desenvolvimento de produtos, segundo a literatura de projetos
colaborativos, gerenciamento gil de projetos e a literatura de gerenciamento de
projetos no geral;
b) identificar os problemas enfrentados em casos reais de utilizao de softwares
como apoio ao gerenciamento de projetos colaborativos para o desenvolvimento
de produtos;
c) identificar as tendncias tecnolgicas em funcionalidades de software de
gerenciamento de projetos;
d) sintetizar os resultados encontrados na forma de requisitos necessrios para a
construo de um software para gerenciamento gil de projetos colaborativos.
Este trabalho procura responder s seguintes perguntas de pesquisa:
Q1) Segundo a literatura, quais os desafios em termos de mtodos e tcnicas de
gerenciamento de projetos colaborativos?
Q1.1) Quais os desafios no gerenciamento de projetos colaborativos?
Q1.2) Quais os desafios frente s teorias de gerenciamento de projetos?
Q1.3) Quais os desafios e propostas identificados no enfoque gil de GP?
Q2) Quais as tendncias em desenvolvimento de softwares de GP?
Q2.1. Quais tendncias segundo casos reais de utilizao?
Q2.2. Quais as tendncias segundo os softwares propostos na literatura?

67

Q3) Quais os requisitos necessrios para o desenvolvimento de um software para

gerenciamento gil de projetos colaborativos?
A figura 11 demonstra a relao entre os elementos e as questes que compem esta
pesquisa.

Figura 11. Problema de Pesquisa

Fonte: elaborada pela autora

4.3. Classificao do Mtodo de Pesquisa

O estudo proposto combina diferentes abordagens de pesquisa, de forma a responder
satisfatoriamente todas as questes.

Reviso Bibliogrfica Inicial

Na avaliao inicial dos problemas e desafios em projetos colaborativos e no prprio
gerenciamento de projetos, alm das propostas e diferenas do enfoque gil, empregou-se
principalmente o mtodo de reviso bibliogrfica. Essas informaes foram coletadas em

68

livros, teses e revistas cientficas internacionais que fazem referncia aos temas de
gerenciamento de projeto e projetos colaborativos de desenvolvimento de produtos. A
investigao sobre a aplicabilidade do enfoque do gerenciamento gil para a construo de
softwares de gerenciamento de projetos de produtos manufaturados tambm se enquadra neste
mtodo.
A identificao dos requisitos do software de GP foi realizada por meio de uma
combinao de reviso bibliogrfica, anlise das ferramentas de GP gil disponvel na internet
e estudos de casos mltiplos.

Estudo de Casos Mltiplos de Aplicao de SIGPs

O estudo de caso uma investigao emprica de um fenmeno atual dentro do seu
contexto de realidade, quando as fronteiras entre o fenmeno e o contexto no so bem
definidas (YIN, 2001), caracterizando-se pela "... capacidade de lidar com uma completa
variedade de evidncias - documentos, artefatos, entrevistas e observaes." (YIN, 1989, p.
19). A vantagem da abordagem mltipla do estudo de caso a composio de um estudo
robusto. Assim, optou-se por essa forma devido ao detalhamento das informaes e solidez
dos resultados.
A unidade de anlise adotada o sistema de informao utilizado para gerenciar os
projetos de cada empresas e no somente os SGPs. Laudon e Laudon (2002) definem os
sistemas de informaes como um conjunto de componentes inter-relacionados utilizado para
coletar, processar, armazenar e distribuir informaes a fim de facilitar o processo decisrio
em empresas e organizaes. Este trabalho aborda exclusivamente os sistemas de informao
baseados em computadores, mais especificamente, aqueles voltados ao apoio do
gerenciamento de projetos. A distino entre ferramenta (softwares) e sistema de informao
tambm utilizada pelo PMBOK(2004). O manual emprega o mesmo conceito de Laudon e
Laudon (2004) e recomenda o uso da sigla SIGP. Segundo PMBOK(2004), consiste de

69

ferramentas e tcnicas usadas para reunir, integrar e disseminar as sadas dos processos de
gerenciamento de projetos. Ele usado para dar suporte a todos os aspectos do projeto, da
iniciao ao encerramento, e pode incluir sistemas manuais e automatizados (PMBOK, 2004,
p.377). Assim, este trabalho avaliou o uso dos SGPs e sua inter-relao no apoio aos projetos
das empresas.
Os instrumentos utilizados foram roteiros de entrevistas, com perguntas semi-abertas,
observaes e anlise de documentos. O roteiro encontra-se no Apndice A. Os entrevistados,
em todas as empresas, estavam diretamente relacionados com o gerenciamento dos projetos e
possuam conhecimento de todo o PDP.

Figura 12. Representao dos tipos de empresas estudadas

Fonte: elaborada pela autora

As visitas nas empresas foram realizadas pela prpria pesquisadora e equipe de

pesquisa do Grupo de Engenharia Integrada e de Integrao, do Departamento de Engenharia
de Produo, da Escola de Engenharia de So Carlos, USP. Alm do roteiro de entrevista, em

70

todas as empresas foi possvel conhecer os vrios setores que compem o PDP e assim fazer a
modelagem do PDP, apresentando a utilizao dos softwares ao longo do processo,
caracterizando o SIGP. Para essa modelagem, foi utilizado o padro BPMN (Business Process
Modeling Notation), que vem se consolidando como um dos mais importantes padres de
notao grfica aberta para modelar processos de negcios. O apndice B apresenta a notao
utilizada para a modelagem.
Os estudos de casos foram realizados em quatro empresas de bens de capital, de
tamanhos variados - pequena, mdia e grande, de acordo com a classificao do BNDES
(Banco Nacional de Desenvolvimento Econmico e Social) - que trabalham com os modelos
de produo ETO (Engineer-To-Order), MTS (Make-To-Stock) e ATO (Assembly-To-Order),
alm de desenvolverem tipos de produtos diferentes (desde metalurgia at alta tecnologia
tica) e realizarem colaborao com outras organizaes no seu PDP.
A indstria de bens de capital foi escolhida por desenvolver projetos complexos e
colaborativos. As demais caractersticas, como tamanho da empresa, tipo de produtos e
sistema de produo, foram combinadas com a finalidade de obter problemas diferentes de
gerenciamento de projetos e assim elaborar uma lista de requisitos mais robusta, obtendo
confiabilidade na aplicao do software em diferentes organizaes. A figura 12 mostra o
quadrante que representa os tipos de empresas estudadas, de acordo com suas caractersticas.

Reviso Bibliogrfica para Levantamento de Requisitos de SGPs Cientficos

Na investigao para a identificao dos requisitos de softwares cientficos,
empregaram-se mtodos de reviso bibliogrfica, compreendendo os anos de 2001 a 2007. Os
peridicos que serviram como fontes principais so: International Journal of Project
Management e Computers & Industry. A partir deles foram procuradas publicaes
envolvendo palavras-chave: Collaborative engineering, collaborative design, project
management, product development. As referncias bibliogrficas sobre softwares dos artigos

71

encontrados na base principal foram analisadas e includas na reviso, envolvendo assim

outros peridicos como International Journal of Computer Integrated Manufacturing e
Concurrent Engineering: Research And Applications. A seo 5.2.1 apresenta a anlise dessa
reviso bibliogrfica.

Anlise de SGPs voltado para o APM

Uma vez que a literatura acadmica no contempla propostas de softwares para apoiar
os mtodos geis de gerenciamento de projetos (seo 3.4), foi necessria uma anlise dos
softwares disponveis no mercado para GP gil, para conhecimento de suas funcionalidades e
seus pontos diferenciais dos SGPs baseados na abordagem clssica. As ferramentas foram
identificadas por meio de buscas na internet e publicaes em fruns especializados em APM.
As buscas foram realizadas em sites de instituies sobre gerenciamento de projetos e em
sites sobre desenvolvimento de software, uma vez que as referncias encontradas sobre GP
gil esto relacionadas rea de software. O critrio utilizado foi a busca de funes
diferentes das citadas na seo 3.1. Na seo 5.2.2, apresentada essa anlise, onde feita
breve descrio das funcionalidades diferenciais.

Anlise e Concluses
Os dados analisados dos estudos de casos, dos softwares disponveis para GP gil e
das concluses da reviso bibliogrfica sobre os softwares da literatura foram compilados de
forma a verificar os pontos necessrios para o modelo e gerar assim a lista de requisitos. Cada
ponto considerado necessrio para o modelo de software est listado na seo 5.3,
devidamente acompanhado do estudo que o justifica.
A pesquisa em questo classificada dentro da abordagem qualitativa, que
caracterizada pela utilizao do ambiente natural como fonte direta de dados e do pesquisador
como instrumento fundamental (GODOY, 1995). Na pesquisa qualitativa, o pesquisador

72

procura entender os fenmenos segundo a perspectiva dos participantes dela e, depois, sua
interpretao.

4.4. Etapas da pesquisa

As etapas realizadas na pesquisa esto descritas nesta seo e representadas na figura
13.
1. Reviso Terica: composta de duas subetapas, a primeira referindo-se ao
levantamento da bibliografia existente sobre Gerenciamento de Projetos
Colaborativos (GPC), apresentada na seo 2.1, Gerenciamento gil de
Projetos (sees 2.2.2 e 2.2.3) e softwares para GP (captulo 3). Na segunda
subetapa, tem-se a anlise da literatura sobre os desafios no gerenciamento de
projetos (seo 2.2.5), desafios no gerenciamento de projetos colaborativos
(seo 2.1.3), aplicabilidade do gerenciamento gil (seo 2.2.4) e desafios dos
softwares frente colaborao e agilidade (seo 3.3);
2. Trabalho de Campo e Pesquisa: aps a realizao da reviso terica, foram
realizados quatro estudos de caso em empresas de bens de capital, avaliando-se
os softwares utilizados para gerenciamento de projetos e suas inter-relaes
(seo 5.1). Nesta etapa, tambm foram realizadas anlises de softwares
comerciais de gerenciamento de projetos voltados para o enfoque gil (seo
5.2.2), alm da avaliao dos softwares pesquisados na literatura (seo 5.2.1).
3. Sntese da Reviso Terica e Pesquisa: a partir da compilao dos dados dos
estudos de casos, anlise dos softwares para GP gil e das propostas da
literatura, dos desafios dos softwares para GPC e implicaes do gil para um
sistema de informao, foram levantados os requisitos para o modelo de
software de gerenciamento de projetos colaborativos com base no enfoque gil

73

(seo 5.3). J com os requisitos, foi possvel propor o modelo em si e tambm

observar possibilidades de projetos futuros, dando continuidade pesquisa.

Figura 13. Etapas da Pesquisa

Fonte: elaborada pela autora

74

5. Resultados
Este captulo apresenta os resultados da pesquisa. Inicia com os quatro estudos de caso
(seo 5.1) que compem a pesquisa de campo. Em seguida (seo 5.2), a anlise dos
softwares de GP encontrados na literatura e voltados para o enfoque gil. Os requisitos
obtidos dessas anlises so sintetizados na seo 5.3.

5.1. Estudos de Caso

5.1.1. Empresa A
Trata-se de uma empresa de grande porte, com capital aberto e nacional. Atua no ramo
de bens de capital e sua principal caracterstica a engenharia sob encomenda (ETO,
Engineer-To-Order), que atualmente suportada por sistemas computacionais integrados.
Tem atuado nos mercados nacional e internacional durante as ltimas dcadas (PEREIRA,
2005). Conta com aproximadamente 1100 colaboradores diretos, atuando nas reas de
metalurgia, energia, leo e gs e laminao/trefilao.
A empresa possui um sistema de gesto que inclui certificaes como a ISO
9001/2000, que valida os nveis de qualidade apresentados pelos produtos e servios da
empresa; a ISO 14001, que diz respeito gesto ambiental da empresa; e a OHSAS 18001,
que diz respeito sade e segurana no trabalho.
A empresa tem duas plantas. A primeira possui setores de engenharia, usinagem,
montagem, trefilao e laminao. A segunda engloba os setores de corte, caldeiraria, solda,
usinagem, tratamento trmico e de superfcie, engenharia e um centro de pesquisas.
A sua estrutura organizacional funcional, sendo organizada por grandes reas,
classificadas em duas categorias: uma relacionada ao produto e a outra de apoio. As reas
relacionadas ao desenvolvimento do produto so: Vendas; Gerenciamento; Engenharia;

75

Suprimentos; Manufatura; Entrega e Ps-Entrega. Dentro das reas de desenvolvimento de

produto, so utilizados tambm os grupos virtuais, em que os engenheiros e tcnicos so
divididos por especialidades, para gerenciar a capacidade dos recursos. J as reas de apoio
so: Financeiro, Administrativo, Recursos e Liderana.

Sistema de informao utilizado no gerenciamento de projetos

O gerenciamento de projetos da empresa feito de uma maneira prpria, por meio da
integrao de determinados softwares ao longo do Processo de Desenvolvimento do Produto
(PDP) da empresa.
Seguem abaixo os principais softwares utilizados em cada etapa do macro fluxo da
empresa:


Software PDM (Product Data Management), que atua nos processos de Venda
e Gerenciamento. O PDM o sistema de frente para as engenharias de produto
(PEREIRA, 2005);

Software ERP (Enterprise Resources Planning), utilizado a partir da venda do

produto. Utiliza os dados de estrutura do produto provenientes do PDM;

Software de gerenciamento de projetos, utilizado nos processos de Engenharia

para gerenciamento das atividades prprias. O software no utilizado para
gerenciamento do projeto como um todo, mas apenas nas atividades
especficas da rea funcional denominada engenharia. Tambm utilizado um
segundo software de gerenciamento de projetos como ferramenta de
apresentao de resultados e acompanhamento de tarefas por clientes;

Planilha eletrnica, utilizada para gerar relatrios desde a venda do produto

at o gerenciamento de projetos finalizados.

76

Figura 14. Modelo representativo do macro fluxo de informaes de projeto da Empresa A

77

As etapas e quais softwares do apoio ao processo esto representados na figura 14. O

primeiro passo o da definio do portiflio. As novas oportunidades so tratadas no nvel da
diretoria. Utilizando dados de planilhas de capacidade e uso de recursos, enviadas pelos
grupos virtuais da engenharia, a rea de vendas juntamente com a rea de gerenciamento
realizam a escolha das oportunidades a serem atendidas, parte delas por meio de licitaes.
Esta primeira parte no apoiada por softwares com funcionalidades de gerenciamento de
projetos.
O gerenciamento de projeto de um novo produto se inicia propriamente aps a
aprovao da proposta. A partir dessa fase, a empresa se utiliza principalmente dos softwares
de ERP e PDM. Os demais softwares citados apresentam funes de gerenciamento mais
especficas dentro do PDP. Existe uma integrao entre o ERP e PDM, feita atravs de
customizaes nos dois softwares. Essa integrao inclui a estrutura de produto e custos de
fabricao. Assim, no sistema PDM so armazenadas as informaes sobre o projeto e a
estrutura de produto. Quando a fabricao de parte do produto liberada, os dados so
transferidos ao sistema ERP, que passa a controlar a produo e horas gastas. No existe
integrao com os demais softwares utilizados pela empresa.
Existe uma metodologia de integrao com fornecedores e parceiros externos
empresa, com padres e contratos de confidencialidade. A troca de informaes registrada
formalmente (segundo regras do contrato) e ocorre, basicamente, por e-mail, reunies,
videoconferncias e telefone. No caso de contato com clientes, o acompanhamento das
atividades feito com grficos de GANTT e PERT, gerados com apoio do software de
gerenciamento de projetos, que so utilizados somente nas atividades do processo de
engenharia.

78

A escolha de fornecedores baseia-se no nvel de qualidade apresentado por eles.

Nenhuma pea ou material adquirido sem que o fornecedor j esteja previamente cadastrado
e avaliado de acordo com padres e normas da empresa. Alm disso, antes de se efetuar a
compra, analisado o nvel de criticidade da pea ou material, ou seja, analisam-se a
importncia e a necessidade do material ou da pea no produto finalizado.
De acordo com o PDP, existem diferentes tipos de usurios para cada software
utilizado dentro da empresa, com permisses predeterminadas, baseadas nas normas da
empresa.

Desafios a serem enfrentados

Como se trata de uma empresa de grande porte, os desafios a serem enfrentados
tambm so muitos. Para um melhor entendimento, eles foram agrupados em tpicos,
descritos a seguir:

Planejamento e Funes para gerenciamento da capacidade. O desenvolvimento do

produto depende de tcnicos e engenheiros com experincia. O gerenciamento da
capacidade dos tcnicos, visando a melhor utilizao nos projetos, fundamental. A
soluo adotada dividir o plano por especialidades, denominadas grupos virtuais.
Todos os engenheiros e tcnicos so divididos por tais grupos, e o responsvel pelo
grupo gerencia aquele grupo de recursos. Em um novo projeto, o responsvel de cada
grupo informa a capacidade do grupo. A partir destas informaes, que o plano
macro do projeto ser elaborado. Como realizar isso de forma mais rpida e eficiente
com o apoio dos softwares um dos desafios da empresa. A principal ferramenta aqui
so planilhas eletrnicas.

Aquisio de materiais. O controle desta rea no projeto um fator crtico. A empresa

possui um sistema sofisticado para isso no ERP, baseado em grupos de compra (NQ1,

79

NQ2, NQ3, NQ4, NQMS) atrelados aos nveis de certificao dos fornecedores (CI,
CII, CIII). Portanto, toda pea cadastrada em um grupo e, conforme o grupo, h um
procedimento especfico e controlado para a aquisio. Incluir funcionalidades como
esta, integradas ao gerenciamento de projetos, seria um aspecto a ser estudado.
Significa que o acompanhamento da aquisio alimentaria indicadores de
desempenho do projeto. Segundo os entrevistados, anlises mais sofisticadas de
suprimentos poderiam melhorar o projeto e diminuir significativamente os custos
nesta indstria.

Responsabilidade pelo projeto e anlise de risco. O risco uma das caractersticas

diferenciais dos produtos da empresa. Como so produtos que podem trazer prejuzos
graves de diferentes naturezas, como humanas, materiais e ambientais, a formalizao
de clculos e especificaes e, conseqentemente, as responsabilidades por eles
devem ser claramente definidas, registradas e controladas. Isso feito por meio de
contrato. A principal ferramenta a dar apoio neste caso o sistema PDM, que registra
e controla os documentos gerados durante as etapas de desenvolvimento. Este pode
ser um campo a ser explorado pelas ferramentas de apoio ao gerenciamento
colaborativo de projeto. As atividades de projeto subcontratadas exigem, no mnimo,
uma planilha de impacto. Outras medidas so exigncia de memoriais de clculo,
construo e outras documentaes que comprovem o atendimento aos padres
internacionais de projeto (como no caso da solda). A empresa no possui um painel
resumo dos riscos de um projeto. As anlises de risco realizadas pelas reas ficam
restritas a cada setor. Um desafio seria criar um software com a funcionalidade de um
painel integrado demonstrando, para a gerncia, os riscos gerais do projeto.

Colaborao com assessoria jurdica e sigilo nas contrataes externas. Outro ponto
interessante foi a deteco de potenciais parceiros na colaborao. Existem casos em

80

que necessrio utilizar pareceres de assessoria jurdica para validar requisitos de

projeto. Muito comum, por exemplo, em aspectos ambientais. Deve-se, portanto,
considerar este tipo de parceria. J nas contrataes de parceiros externos, so
utilizadas ferramentas tradicionais como e-mail, telefone e troca de arquivos para a
realizao de projetos com fornecedores e parceiros, e no momento no h problemas
relativos confidencialidade nestes casos. As transaes so garantidas por meio de
contratos separados de sigilo (no disclosed agreement).

No caso dos indicadores de desempenho aplicados ao projeto, a empresa enfrenta

certas dificuldades. Os indicadores de resultado principais, como lucro ,so difceis de
serem inseridos no contexto do projeto. O prazo de desenvolvimento dos projetos
muito longo. Portanto, os indicadores passam de um ano e no so muitos para efeito
de controle dos projetos.

Troca de informaes formalizada e rastrevel. Em conseqncia do item anterior, a

troca de informaes com os parceiros precisa ser rastreada e controlada. Portanto,
um desafio para sistemas colaborativos seria apoiar o controle das alteraes nos
documentos de maneira integrada com o controle do status do projeto.

Interfaces bem definidas. Um fator que auxilia a colaborao a interface de projeto

bem definida. A maioria dos itens (sistemas, subsistemas e componentes), desenhados
e contratados pela empresa, so peas com tecnologias conhecidas pela empresa e,
parte delas, normalizadas. Por isso, a comunicao com os fornecedores, parceiros e
entre engenheiros facilitada, e a empresa no tem experimentado, segundo os
entrevistados, problemas de colaborao na rea de projeto. O caso demonstra,
porm, que a identificao das interfaces e a definio do que ser entregue
fundamental.

81

Identificao de requisitos crticos. Os respondentes reforaram os fatores tradicionais

crticos para a colaborao: apoio da alta gerncia, comprometimento e cultura em
sistemas de gesto integrados. Apenas um difere da literatura. Trata-se da
identificao de requisitos crticos de projeto. Isso poderia ser explorado em um
sistema de informao. Gerenciar os requisitos de projeto de forma a diferenciar
requisitos crticos, garantindo a priorizao durante a execuo do projeto.

O gerenciamento de multiprojetos ainda um desafio devido complexidade dos

produtos e tamanhos dos projetos (equipes e pessoas). Possuir sistemas de
informaes mais eficientes na rea poderiam melhorar muito a eficincia e qualidade
das informaes, bem como as decises. Portanto, pesquisar sistemas que possam
auxiliar a suprir estes desafios um aspecto importante para a indstria.
No que diz respeito integrao de sistemas, o desafio da empresa integrar a

Engenharia do Produto aos mtodos e processos atravs de uma ferramenta CAD 3D.

5.1.2. Empresa B
A empresa possui capital aberto e aproximadamente 300 colaboradores diretos,
divididos entre sua sede, escritrios em duas capitais brasileiras e uma em Miami, nos Estados
Unidos. Tambm h representantes na Europa, sia e Oceania. Duas unidades nacionais
realizam operaes industriais, e as restantes, apenas operaes de venda e assistncia tcnica.
Suas linhas de produtos atendem ao setor mdico-odontolgico e setor tico, aplicados s
reas mdica, militar e espacial.
Por possuir uma gama vasta de produtos de alta tecnologia, a empresa pode ser
enquadrada em trs estratgias de produo distintas: ATO (Assembly-To-Order), para uma
linha de produtos de catlogo, englobando aparelhos oftalmolgicos e odontolgicos; ETO
(Engineer-To-Order), para projetos do ramo espacial, cuja durao dos projetos geralmente

82

excessivamente longa; MTO (Make-To-Order) que representa os produtos provenientes de

parcerias governamentais.
A estrutura organizacional da empresa pode ser observada na figura 15. O estudo de
caso foi realizado junto ao desenvolvimento de projetos de alta inovao, que est relacionado
com a rea de Pesquisa e Desenvolvimento (P&D). Um fato relevante que dentro da rea de
P&D existe um grupo que iniciou suas atividades realizando somente a documentao dos
projetos e que, atualmente, realiza o trabalho do escritrio de projetos (PMO Project
Management Office).

Figura 15. Organograma da Empresa B

Sistema de informao utilizado no gerenciamento de projetos

Na rea de P&D, a empresa possui indicadores referentes produo, aquisio,
cronograma de projetos e qualidade. Dentro de cada uma dessas grandes reas de indicadores,
existem indicadores especficos de tempo, custos, lead-time de produo de peas, de entrega
de produtos finalizados, o caminho crtico do cronograma dos projetos, controle de atividades
e mudanas e metas:

83

Quanto ao seu SIGP, a empresa utiliza uma plataforma heterognea. Os softwares

utilizados so:

Software ERP: armazena dados de custo, aquisio e planos de produo.

Editor de texto: empregam-se editores de texto comuns para produzir e

armazenar os dados de estrutura do produto e informaes sobre verses e
liberaes para a fbrica. O mesmo recurso utilizado para gerar e armazenar
relatrios em geral. Os arquivos so armazenados em reas de rede interna da
empresa.

Software de gerenciamento de projetos: utilizado para acompanhar o

cronograma dos projetos. Faz-se apenas um cronograma macro, isto , com as
fases e grandes atividades. No se utiliza o controle de recursos do software.

Planilha eletrnica: as informaes geradas pelo software de gerenciamento de

texto so armazenadas em planilhas eletrnicas e geram uma base de dados,
utilizada para histrico, acompanhamento de cada projeto e gerao de
relatrios de indicadores. O armazenamento das planilhas feito em reas de
rede interna da empresa.

84

Figura 16. Modelo representativo do macrofluxo de informaes de projetos da empresa B

85

Desafios a serem enfrentados

A partir da anlise das tecnologias de informao utilizadas no PDP da empresa B,
pode-se dizer que os principais desafios esto relacionados ausncia de integrao dos
softwares utilizados. A seguir, temos cada um dos desafios encontrados:

Dificuldades na gerao de indicadores automaticamente. Os indicadores so

calculados utilizando-se planilhas automatizadas. Os dados para o clculo so
alimentados manualmente a partir dos demais sistemas empregados na empresa. Isso
gera esforo elevado e risco de erros nos indicadores;

Ausncia de integrao dos sistemas que armazenam os dados do produto. As

informaes de configurao esto espalhadas em diversos documentos. Isso gera
retrabalho, como burocracia para aprovao e registro dos desenhos, duplicao de
arquivos em diretrios especficos para as reas de produo e engenharia, havendo
riscos de modificaes incorretas por falhas das pessoas;

Ausncia de banco de dados para gerenciamento de recursos, utilizando-se dados de

esforo. A empresa no utiliza um histrico de esforo dos projetos anteriores e, por
isso, h dificuldade em estabelecer os recursos necessrios para novos projetos. Esse
um aspecto que pode ser aprimorado e trazer resultados positivos em projetos futuros;

Colaborao com parceiros externos ou colaboradores de outras unidades. A

colaborao com parceiros no apoiada por sistemas de informao. As
comunicaes e trocas de documentos so informais e, segundo os entrevistados, no
apresenta maiores desafios. Mas a empresa no utiliza ferramentas que possibilitam
guardar um histrico das operaes realizadas e, assim, gerar as lies aprendidas dos
projetos, com relao s decises tomadas de forma no presencial.
Pode-se notar que o foco principal do gerenciamento de projetos da empresa B est na

criao de indicadores de resultado. Alm disso, controla-se em detalhes a estrutura do

86

produto e pouco as atividades dos projetos. Portanto, embora haja um controle efetivo e
muito bem elaborado da configurao do produto, a empresa ressente-se de um planejamento
mais elaborado das atividades da equipe. Ainda assim, so notveis o esforo e os resultados
da utilizao dos indicadores de desempenho nos projetos em desenvolvimento.

5.1.3. Empresa C
A empresa de pequeno porte, capital 100% nacional e administrao familiar. Possui
cerca de 200 funcionrios e certificado de qualidade ISO-9001:2000. Atua no
desenvolvimento de solues para indstrias, tanto nas reas de logstica interna quanto na de
servios de montagens industriais, fornecendo produtos sob encomenda; portanto, o sistema
de produo utilizado ETO.
Possui uma vasta quantidade de clientes, os quais esto distribudos nos setores
alimentcio, cosmtico, qumico, metal-mecnico, de papel e celulose, de tubos e conexes.
Desenvolve e fabrica equipamentos para paletizao e despaletizao, equipamentos para
encaixotamento, linhas transportadores, elevadores e descedores de produtos, mesas
acumuladoras, desviadores e viradores magnticos e no magnticos, processadores de latas e
fundos, lavadores de vidros e sistemas para movimentao de vidros.

Sistema de informao utilizado no gerenciamento de projetos

Quanto utilizao de sistemas de informao no Processo de Desenvolvimento do
Produto (PDP), a empresa possui uma estrutura de desenvolvimento funcional e
departamentalizada. Portanto, mais conveniente apresentar o PDP da empresa em setores, de
forma a mostrar quais ferramentas (softwares) so utilizados em cada setor dentro do PDP da
empresa.
Os setores envolvidos do PDP so: Vendas, Engenharia, Engenharia de Processos,
Planejamento e Controle de Produo (PCP), Compras, Produo e Controle de Qualidade.

87

Os softwares utilizados dentro desses setores so:

Software ERP: basicamente, em todos esses setores, utiliza-se um sistema ERP

para controle de atividades, com nfase no mdulo de PCP. No setor de vendas
especificamente, utiliza-se o mdulo do ERP relativo ao cadastro de produtos e
peas para o desenvolvimento de oramentos;

Software de gerenciamento de projetos: no setor de Engenharia, existe uma

pessoa responsvel pelo controle dos projetos em andamento, que utiliza um
software de GP para planejamento e acompanhamento das atividades. Com
esse controle, possvel monitorar o tempo e os recursos disponveis, dando
um panorama geral dos andamentos dos projetos. Utiliza-se a funcionalidade
de marcos (milestones) como uma forma de acompanhamento;

Software CAD: tambm no setor de Engenharia utiliza-se um software CAD

para apoiar a produo de desenhos. Quanto ao controle dos desenhos, h um
arquivo fsico de todos os projetos j realizados, porm todos os cdigos dos
desenhos tambm ficam registrados no ERP, relacionados ao seu projeto;

Editor de texto: utilizado para relatrios em geral sobre o projeto;

Planilha eletrnica: utilizada para a gerao de relatrios grficos, com

indicadores sobre os projetos.

O sistema ERP foi implantado h pouco tempo; existem funcionalidades que ainda no
esto sendo utilizadas pela empresa. Assim, no desenvolvimento de produtos, os indicadores
so gerados em planilhas. Pretende-se eliminar a utilizao de planilhas eletrnicas,
centralizando todos os relatrios no ERP.
O contato com colaboradores externos, que desenvolvem partes especficas do projeto
por meio de contratos, feito por e-mails, telefonemas e reunies presenciais. Os acordos de

88

mudanas necessrias ao longo do projeto so oficializados por e-mails, que so arquivados

em reas da rede. Esses colaboradores externos no possuem acesso aos sistemas da empresa.
Independentemente do software utilizado durante o desenvolvimento de um projeto,
todos os dados so arquivados de forma fsica tambm. Cada projeto possui uma pasta onde
so colocadas cpias de todos os dados que o compem. A figura 17 representa o macro fluxo
das informaes dos projetos da Empresa C.

89

Figura 17. Modelo representativo do macro fluxo de informaes dos projetos da Empresa C

90

Desafios a serem enfrentados

A partir da anlise das informaes, pode-se afirmar que a empresa no possui
problemas significativos com o gerenciamento dos documentos e dos projetos, apesar de no
haver muita integrao e adoo de sistemas sofisticados atendendo suas necessidades.
H um grau grande de organizao, devido ao controle dos documentos de forma
fsica. Os projetos so controlados por um gerente, e o fato de a empresa atuar em mercados
de nicho, com poucos projetos por ms, no so evidentes grandes deficincias.
Com a implantao e utilizao do mdulo PCP, componente do ERP utilizado, a
empresa deixou de controlar manualmente as atividades desenvolvidas ao longo do projeto de
um novo produto. Todos os processos que sero utilizados em um projeto so registrados no
ERP e acompanhados pelo gerente.
Entretanto, podem-se destacar desafios a serem realizados pela Empresa C:

Falhas de automao em fases do processo de desenvolvimento de produto. Embora

no apontado pelos entrevistados como um problema, a empresa no possui sistemas
em determinadas partes do desenvolvimento que, se fossem atendidas, poderiam
trazer benefcios. A fase inicial de identificao das novas oportunidades a primeira
ausncia. Uma ferramenta de gesto de portiflio que permitisse gerar informaes
sobre a capacidade no desenvolvimento de projetos, integrada com custos, poderia
melhorar a qualidade das decises, revertendo em melhor desempenho e priorizao
dos projetos. Essa deciso tomada conforme a experincia e pode limitar no futuro o
crescimento da empresa. Outra etapa a montagem do produto. Depende de vistorias
fsicas. Coletores de dados mveis permitiriam que a empresa melhorasse o controle
tambm dessa fase do PDP;

Utilizao do ERP para a gerao dos relatrios de desempenho. Em setores, como no

setor de Qualidade, ainda so utilizadas planilhas eletrnicas para controle de ndices

91

de desempenho e de seu acompanhamento, o que pode gerar inconsistncia em

algumas informaes, j que os dados precisam ser digitados novamente. A gerao
automtica de indicadores evitaria a divulgao de informaes e, conseqentemente,
melhoraria o desempenho das reunies presenciais semanais de acompanhamento;

Integrao e compartilhamento de dados entre as reas envolvidas no PDP. Melhorias

so necessrias no que diz respeito ao compartilhamento de dados e documentos, com
regras de acesso dos usurios. A utilizao do mdulo de PCP por todas as reas do
PDP proporcionar melhores resultados para a empresa, devido possibilidade de
acesso a informaes consistentes;

Gerenciamento das informaes financeiras do projeto. As informaes financeiras,

geradas na oramentao, tambm poderiam ser gerenciadas diretamente pelo ERP.
Hoje so realizados somente o oramento no incio do projeto e o estudo da sua
viabilidade. Um acompanhamento dos valores ao longo do projeto, utilizando o
software para seu gerenciamento, poderia gerar um histrico e permitiria avaliar
melhor o desempenho da equipe;

Anlise de risco. A ausncia de anlise de risco tambm foi notada, sendo realizada
apenas informalmente no incio do projeto. Nota-se a necessidade de um software que
apie essa anlise e armazene os problemas. Poderia ser criada uma funcionalidade
dentro do prprio ERP ou ser utilizada alguma outra ferramenta para esse tipo de
anlise e acompanhamento ao longo do projeto. A gerncia e anlise de riscos
poderiam garantir maiores nveis de sucesso de projetos futuros;

Compartilhamento de dados do projeto com colaboradores. Outro desafio o

compartilhamento de dados e informaes com colaboradores externos, minimizando
custos de deslocamentos com reunies presenciais e arquivamento fsico de
documentos. A importncia dessa integrao com os colaboradores externos deve-se

92

ao fato de proporcionar melhor conhecimento do produto desenvolvido, por todas as

partes.

5.1.4. Empresa D
Atua no ramo de automao e controle industrial e tem como principal mercado-alvo
usinas de cana-de-acar no centro-sul e nordeste do Brasil. Ela possui filiais no Sul, Sudeste
e Nordeste do pas, alm de representaes em toda a Amrica Latina. Exporta para mais de
vinte pases, inclusive pases africanos.
Com cerca de 350 colaboradores diretos, a empresa passou por um crescimento
recente, o que gerou necessidade de ampliao da planta e adequaes na empresa como um
todo. Possui certificao ISO 9001, referente ao seu Sistema de Gesto da Qualidade, relativo
ao escopo de fornecimento de projeto, produo, comercializao, instalao e assistncia
tcnica para sistemas eletrnicos de controle e automao.
A empresa apresenta uma vasta linha de produtos, todos voltados s necessidades de
automao e controle de pequenas, mdias e grandes empresas. Essa linha de produtos
dividida em linhas de instrumentao industrial, sistemas completos para instrumentao,
projetos de instrumentao, sistemas supervisrios, assistncia tcnica e treinamento para
clientes. Os produtos da empresa esto presentes em cerca de 60% das usinas de cana-deacar da Brasil, o que representa participao significativa no mercado sucroalcooleiro
brasileiro.
A estrutura organizacional da empresa composta pela diretoria, P&D, PCP, compras,
engenharia, a qual dividida em eletrnica e mecnica, e o setor de manufatura, composto por
produo mecnica, montagem eletrnica, montagem de sistemas e testes eletrnicos.

Sistema de informao utilizado no gerenciamento de projetos

93

De forma simplificada, o PDP da empresa baseia-se no requisito 7.3 da norma ISO

9001. Esse requisito se refere ao projeto e ao desenvolvimento de produto, aplicado com os
respectivos softwares da seguinte forma:

Planejamento. realizado por meio de um cronograma de atividades, elaborado pela

diretoria em conjunto com a engenharia. O software utilizado um editor de texto;

Entradas do desenvolvimento. So formadas pelos requisitos e caractersticas

funcionais dos produtos. Customizaes exigidas por clientes tambm representam
entradas do desenvolvimento. Esses requisitos ficam documentados em arquivos
fsicos como pastas. O software utilizado nesse ponto tambm o editor de texto;

Validao. Testes internos e externos (laboratrios conceituados e testes em campo,

nas usinas). Tem como objetivo garantir qualidade ao produto final que ser vendido.
A documentao dos testes realizada por relatrios feitos em editor de texto e
arquivada de forma fsica;

Sadas do desenvolvimento. Documentao do produto, manuais tcnicos, parmetros

do treinamento que ser oferecido a clientes em relao aquele produto. Todas as
sadas de desenvolvimento so feitas em editor de texto e armazenadas nas reas da
empresa independentemente: especificaes mecnicas no setor de projeto mecnico
e eletrnicas no setor de automao;

Alteraes no projeto. So baseadas no feedback dos clientes, em possveis

dificuldades de manufatura, problemas no controle de qualidade baseados nos testes
de validao. O contato dos clientes feito pessoalmente, por telefone ou e-mail.
Qualquer registro necessrio das alteraes do projeto feito em editor de texto e
arquivado com a documentao do respectivo projeto.
Outros softwares utilizados no PDP da empresa so:

Software CAD, para desenho dos componentes do hardware;

94

Planilha eletrnica, para a lista de materiais de um projeto;

Software de gerenciamento de projetos, para um acompanhamento muito especfico

dentro das reas de engenharia.
No que diz respeito ao PDP da empresa, o desenvolvimento dos processos ocorre

simultaneamente ao desenvolvimento do produto. No existe um engenheiro processista ou

algum encarregado de desenvolver os processos de fabricao do produto.
A anlise crtica do PDP da empresa ocorre por meio de reunies entre os participantes
do desenvolvimento. No existe uma poltica de monitoramento do desenvolvimento de
produtos, mas sim um acompanhamento por projetos, que se baseia no tempo estipulado para
desenvolvimento do produto. Trata-se de uma avaliao bimestral que analisa o andamento
das atividades que estavam presentes no cronograma. Existe uma tolerncia de 20% a mais
que o tempo previsto no desenvolvimento das atividades.
A figura 18 esquematiza todos os processos do PDP da empresa, na forma de macro
fluxo:

95

Figura 18. Modelo representativo do macro fluxo de informaes dos projetos da Empresa D

96

Desafios a serem enfrentados

De acordo com as entrevistas e a anlise realizada, possvel apresentar algumas
solues gerais que podem melhorar o gerenciamento e o desenvolvimento das atividades de
PDP na empresa.
No momento do estudo, a empresa no possua uma metodologia para gerenciamento e
acompanhamento de seus projetos. Assim, no h medidas objetivas do desempenho e falhas
em projetos anteriores e atuais. Depende somente do conhecimento tcito de seus
colaboradores. A primeira ao o desenvolvimento de uma metodologia de gerenciamento
de projetos. Aps o desenvolvimento dessa metodologia, viria a escolha dos softwares
adequados para apoiar essa metodologia. Dessa forma, seria possvel a anlise do desempenho
de seus projetos e, conseqentemente, a gerao de aes de melhoria.
Os pontos crticos identificados e que podem ser apontados na anlise desta pesquisa
so:

Uso de software de gerenciamento de projetos para melhorar a definio das

interfaces entre a engenharia mecnica e eletrnica. A empresa hoje no possui um
planejamento integrado entre as reas de engenharia mecnica e eletrnica.
Compartilhar dados, como cronograma e atividades, melhoraria o relacionamento
entre as equipes, fazendo que as duas reas trabalhem integradas, suprimindo certos
problemas que acontecem na manufatura do produto. O desafio para os softwares,
neste caso, o de compartilhar dados de duas reas que trabalham de forma muito
distinta. Na rea eletrnica, h reunies semanais de acompanhamento, e os projetos
so mais longos. Na mecnica, os projetos so mais rpidos, e no feito um
acompanhamento sistemtico, pois geralmente encaminhado a uma nica pessoa
que domina o tema. Possibilitar nveis de controle, isto , horizonte de planejamento e
freqncia, uma necessidade de sistemas de GP para essa empresa;

97

Desenvolvimento de ambientes para gerenciamento de documentos e fluxos de

trabalho, sem a necessidade de um documento fsico controlado por protocolos. Como
o volume de projetos simultneos da empresa ainda no tem propores grandiosas, a
empresa no experimenta o problema de controle de verses, porm as perspectivas
de crescimento exigem que aprimoramentos neste aspecto devam ser feitos. O desafio
neste caso desenvolver sistemas de informao que controlem fluxo e documentos
de forma muito simples. A utilizao de sistemas muito sofisticados do tipo PDM
poderia acarretar uma sobrecarga de atividades de controle de verso e mudanas
incompatveis com o tamanho e estrutura da empresa;

Repositrios mais inteligentes e integrados de componentes. Uma parte fundamental

do projeto eletrnico a escolha dos componentes. Segundo a impresso dos
entrevistados (no havia dados objetivos sobre o tema), a maior parte do tempo na
rea de projeto eletrnico era gasto na busca e especificao de componentes.
Atualmente, eles recebiam apoio da rea comercial, mas muitos dados eram
vasculhados dentro do ERP. Dados ultrapassados ou confusos tornavam a busca
onerosa. Um agravante a rapidez com que os componentes eletrnicos so
descontinuados, gerando situaes onde um componente era especificado e, no
momento da montagem, descobria-se que no era mais possvel compr-lo.
Funcionalidades de busca de componentes e de e-procurenment poderiam auxiliar nos
projetos de desenvolvimento;

Implantao e uso do sistema ERP, a fim de gerenciar as atividades referentes aos

planos de processo (para a engenharia mecnica) e integrar as reas de Engenharia,
PCP e Compras da engenharia eletrnica. De imediato, poderamos apontar os setores
de P&D e aquisies como os mais necessitados, uma vez que o sistema ERP traria a
possibilidade de especificao de fornecedores e de sua classificao;.

98

Desenvolver sistemas e metodologias que apiem a anlise de riscos dos projetos, j

que cada projeto possui caractersticas distintas e pode apresentar necessidades
variadas, gerando riscos de vrios graus: desde mercadolgicos at tcnicos;

Um desafio especial como gerar informaes para estabelecer sistemas de

indicadores de desempenho do projeto, envolvendo dados das equipes de engenharia
mecnica e eletrnica, tornando possvel a anlise do desempenho dos projetos como
um todo. Esse sistema teria que ser simples, evitando-se apontamentos detalhados de
horas, em virtude de a empresa apresentar uma estrutura significativamente enxuta.

5.1.5. Sntese dos Casos

O primeiro aspecto que chama a ateno nos casos a confirmao das crticas aos
softwares de gerenciamento de projetos apresentadas na literatura. Note-se que, em todos os
casos citados, de empresas que se destacam em suas reas de atuao e porte, no foi
encontrado nenhum caso de implantao de sistemas integrados voltados para o
gerenciamento de projetos, isto , solues completas do tipo Enterprise Project Management
(EPM). O projeto como um todo gerenciado com o auxlio de vrias ferramentas.
Configura-se, ainda, o conceito de ilhas de automao. Conforme o projeto realizado em
cada rea funcional, um conjunto de sistemas utilizado e sem as devidas integraes. O
resultado so redundncias e necessidades de retrabalho ou realimentao de dados. Esse
resultado alinha-se com o estudo de Castro e Carvalho (2007), que demonstra a ausncia de
um processo integrado de GP em trs grandes empresas do setor de telecomunicaes.
Chama a ateno, na anlise dos casos, o fato de que, embora tenham sido escolhidas
intencionalmente,

empresas

com

caractersticas

significativamente

distintas,

foram

encontradas situaes semelhantes no que diz respeito utilizao de softwares de

gerenciamento de projetos. H, na verdade, uma utilizao bsica das funcionalidades.

99

Alinha-se, portanto, com as crticas realizadas por Maylor (2001), por Winter et al.
(2006) e autores do ESPRC e do enfoque gil de projetos. Conforme a crtica de Maylor
(2001) os softwares de gerenciamento de projetos so utilizados principalmente para a
elaborao de grficos de Gantt, e o acompanhamento complexo, retirando muito do
trabalho do gerente.
Os desafios comuns em que os softwares poderiam auxiliar e que so comuns em
todos os casos seriam em: anlise de risco, aquisio, gerenciamento de recursos, dificuldade
em utilizao de ferramentas que gerenciem multiprojetos e gerao automatizada de
indicadores de desempenho.
Outro fato que comum a todos e chama a ateno o uso muito restrito de softwares
para apoiar a colaborao com parceiros e fornecedores externos. O controle do projeto bem
como a troca de informaes so feitos informalmente pelos profissionais, empregando-se
ferramentas comuns.
Em relao ao identificado na reviso bibliogrfica, os aspectos que no foram citados
por autores da rea, mas que foram encontrados nos estudos de caso so:

Interface. Os casos mostram que, tanto na colaborao externa como interna, a

descrio da interface entre as partes do produto (sistema, subsistema, etc.)
fundamental. No caso do segmento industrial utilizado, isso se mostrou
fundamental, pois muitas das avaliaes precisam se basear em parmetros de
desempenho bem definidos;

Gerenciamento de aquisio. Os SGPs tradicionais trazem pouco apoio a esta

etapa do gerenciamento de projetos. Ela se revelou um aspecto comum em
todos os casos analisados;

Gerenciamento de riscos. A gesto de riscos citada em alguns artigos, mas

no com significativa evidncia, como pode ser visto nos captulos 2 e 3. O

100

resultado dos casos demonstra, porm, que este um aspecto mais relevante do
que o visto na literatura.

5.2. Anlise de softwares de Gerenciamento de Projetos

O captulo 2 apresentou uma reviso da literatura sobre os softwares existentes, de
cdigo fechado e aberto, que possuem funcionalidades ditas clssicas, isto , os sistemas j
consolidados no mercado. Empregaram-se relatrios e revises j disponveis na literatura.
H, porm, dois temas que no puderam ser avaliados: a) as propostas e tendncias em termos
de literatura acadmica sobre gerenciamento de projetos; b) os softwares comerciais mais
recentes que se propem a apoiar mtodos de gerenciamento gil de projetos. Essa seo
busca cobrir esses dois aspectos, visando identificar outros requisitos e necessidades mais
inovadores que estejam sendo desenvolvidos nessas duas reas. Nas sees seguintes (5.2.1 e
5.2.2), so apresentadas anlises sobre as propostas de softwares da literatura e sobre os
softwares comerciais voltados ao enfoque gil, respectivamente.

5.2.1. Softwares pesquisados na literatura

Empreendeu-se uma reviso bibliogrfica sistemtica. O perodo de pesquisa foi de
seis anos, compreendendo os anos de 2001 a 2007, tendo como base principal dois peridicos:
International Journal of Project Management e Computers & Industry. Dos artigos desses
peridicos que estavam relacionados com Gerenciamento de Projetos, foi possvel identificar
que as principais palavras-chave eram: Collaborative engineering, collaborative design,
project management e product development. Obteve-se assim, uma base de dados de artigos,
palavras-chave e peridicos principais. Os artigos encontrados nessa base principal
permitiram identificar outros peridicos: International Journal of Computer Integrated
Manufacturing e Concurrent Engineering: Research And Applications.

101

Realizou-se, ento, uma busca detalhada em todos os nmeros desses peridicos no

perodo citado para a pesquisa (de 2001 at 2007). Em cada nmero analisado, procuraram-se
artigos que satisfizessem dois critrios: a) apresentar uma proposta de software; e b) ao menos
parte das funcionalidades do sistema pudesse apoiar funes de gerenciamento de projetos
segundo a descrio apresentada na seo 3.1. Os artigos foram analisados em seu contedo e
classificados segundo as reas do PMBoK. O quadro 5 apresenta os critrios de classificao.
A classificao envolveu o seguinte procedimento: identificaram-se quais as funcionalidades
eram propostas no software; em seguida, fez-se uma anlise cada funcionalidade de forma a
verificar que tipo de atividade de gerenciamento de projeto ela apoiava e qual a respectiva
rea de apoio relacionada a esta atividade. A mesma funcionalidade de um software proposto
pode, portanto, ser classificado em mais de uma rea.
Houve o acrscimo de uma categoria denominada colaborao. Ela foi utilizada para
identificar funcionalidades propostas que tinham como meta apoiar o gerenciamento de
projetos do tipo colaborativo. Justifica-se a criao da dcima rea no critrio pela
necessidade de avaliao dos processos de colaborao existentes nos softwares. A meta era
descobrir se havia tendncia ou no de focalizar a rea. Outra mudana em relao ao
PMBoK foi a incluso de uma categoria de processo adicional denominado Integrao de
Dados de Software na rea de Integrao. Nesta categoria classificaram-se as propostas que
possuam solues para a integrao de dados de diferentes softwares de gerenciamento de
projetos. Houve necessidade da criao e incluso desse processo devido ao foco em software,
e da verificao de possveis integraes de dados nos sistemas avaliados. Para a dcima rea,
foram definidos trs processos: Controle de contribuio dos colaboradores, Controle de
informaes confidenciais e pblicas e Registros de acordos de colaborao. Esses
processos foram baseados em uma pesquisa de Barnes, Pashby e Gibbons (2006), onde foram
definidos fatores de sucesso relacionados colaborao.

102

REA

10

SUB REA
1.1
Desenvolver o termo de abertura do projeto
1.2
Desenvolver a declarao do escopo preliminar do projeto
1.3
Desenvolver o plano de gerenciamento do projeto
1.4
Orientar e gerenciar a execuo do projeto
Integrao
1.5
Monitorar e controlar o trabalho do projeto
1.6
Controle integrado de mudanas
1.7
Encerrar o projeto
1.8
Integrao de dados de software
2.1
Definio da atividade
2.2
Seqenciamento de atividades
2.3
Estimativa de recursos da atividade
Tempo
2.4
Estimativa de durao da atividade
2.5
Desenvolvimento do cronograma
2.6
Controle do cronograma
3.1
Planejamento do escopo
3.2
Definio do escopo
Escopo
3.3
Criar WBS
3.4
Verificao do escopo
3.5
Controle do escopo
4.1
Estimativa de custos
Custos
4.2
Oramentao
4.3
Controle de custos
5.1
Planejamento da qualidade
Qualidade
5.2
Realizar a garantia da qualidade
5.3
Realizar o controle da qualidade
6.1
Planejamento de recursos humanos
6.2
Recursos
Contratar ou mobilizar a equipe do projeto
Humanos
6.3
Desenvolver a equipe do projeto
6.4
Gerenciar a equipe do projeto
7.1
Planejamento das comunicaes
7.2
Distribuio das informaes
Comunicaes
7.3
Relatrio de desempenho
7.4
Gerenciar as partes interessadas
8.1
Planejamento do gerenciamento de riscos
8.2
Identificao de riscos
8.3
Anlise qualitativa de riscos
Riscos
8.4
Anlise quantitativa de riscos
8.5
Planejamento de respostas a riscos
8.6
Monitoramento e controle de riscos
9.1
Planejar compras e aquisies
9.2
Planejar contrataes
9.3
Solicitar respostas de fornecedores
Aquisies
9.4
Selecionar fornecedores
9.5
Administrao de contrato
9.6
Encerramento do contrato
10.1
Controle de contribuio dos colaboradores
Colaborao
10.2
Controle de informaes confidenciais e pblicas
10.3
Registros de acordos de colaborao
Quadro 5. Critrios para anlise dos softwares da literatura
Fonte: elaborado pela autora

103

O quadro 6 apresenta os softwares encontrados, breves descries e contribuies,

sendo includa uma identificao (ID) para cada um. Essa ID utilizada na tabela 2, presente
no apndice C deste trabalho, onde aparece a classificao dos softwares dentro dos critrios
apresentados.

104

ID

Sistema/Autor

Descrio / Caractersticas-chaves

Contribuies

S1

Rodgers et al. (2001)

WebCADET Proposta de um servidor/repositrio (WedCADET) de A proposta procura melhorar a captura, distribuio e gerenciamento
conhecimentos em design, baseado na Web para apoio tomada de do conhecimento durante a fase de design, no desenvolvimento de
deciso durante os estgios iniciais de design
novos produtos.

S2

Chung e Lee (2002)

Um framework que emprega o formato XML e CORBA na web, como Aumentar a eficincia e colaborao de equipes multidisciplinares de
um sistema de padres de troca de dados para colaborao no design divididos geograficamente com a utilizao de um framework,
desenvolvimento de injeo de moldes.
a fim de interpretar as informaes de design em um formato legvel.

S3

Huang e Mak (2002)

CyberCO uma framework de gerenciamento de Workflow para o A proposta visa oferecer a execuo paralela de mltiplas aplicaes
desenvolvimento colaborativo de produtos em ambientes baseados da Web, com relao ao gerenciamento do workflow. Nos sistemas
na Web.
tradicionais de gerenciamento do workflow, o controle e fluxo de
dados determinado pela precedncia das aplicaes; no CyberCO,
os papis so definidos para os agentes iniciarem e terminarem suas
tarefas.

S4

Huang (2002)

CyberReview Um sistema baseado na web para reviso de design

de produtos, utilizando o conceito de colaborativo.

S5

Liang e Huang (2002)

ICA - Prope um sistema baseado em agentes de informao A proposta utiliza o conceito de mdulos, montando um novo produto
colaborativa para um projeto de produtos modulares.
de acordo com os requisitos apresentados, e com as informaes
disponibilizadas pelos seus respectivos colaboradores.

S6

Qian e Shensheng
(2002)

P_PROCE Um arquitetura e implementao de gerenciamento de O artigo prope integrao de um WFMS com um PDMs,
processo de desenvolvimento de produto, com modelo de workflow gerenciando os dados do produto e tambm lida com informao do
integrado.
processo, informao de recursos, informao da organizao e
informao de controle e avaliao.

S7

Hameri e Puittinen
(2003)

Apresenta um framework para gerenciamento de projetos baseado

na WWW

S8

Qin et al. (2003)

Apresenta um portal para reviso dos marcos de um projeto,

compartilhando diferentes documentos entre equipes distribudas
geograficamente.

Apresenta um framework conceitual, utilizando a Web como base de

funcionamento. Utiliza os conceitos de gerenciamento de recursos,
gerenciamento da comunicao, gerenciamento do escopo e
gerenciamento do tempo.
Prottipo de um sistema para design conceitual, baseado na web, A proposta visa integrar modelos geomtricos em 3D, definindo o
que simula a atuao da pea, para um posterior detalhamento.
comportamento do esboo para simular dinamicamente sua atuao.
Essa simulao pode ser acessada via Internet por outros usurios,
de modo que estes possam compartilhar suas idias com todos os
parceiros envolvidos sem que haja a necessidade de ferramentas
especficas (CAD) para a visualizao. A proposta permite, ainda,
transferncia das idias conceituais para ferramentas CAD onde o
detalhamento de design e processo de manufatura comeam a ser
feitos.

ID
S9

Sistema/Autor
Tay e Roy (2003)

Descrio / Caractersticas-chaves
CyberCAD Um sistema, baseado na web, de integrao de CAD
com videoconferncia.

Contribuies
A proposta contribui com um sistema sncrono de comunicao de
associado ao sistema CAD, para colaboradores distribudos
geograficamente em um projeto.

S10 Wang, Shen e

Ghenniwa (2003)

WebBlow - Apresenta um software composto de uma combinao de A contribuio o compartilhamento de informaes de um projeto
tecnologias como agentes de softwares, Web, XML e Java para entre gerentes e designers, sem necessidade de uso de um nico
compartilhar informaes de produtos durante seu projeto. Voltado tipo de software entre as partes.
especificamente para o projeto de peas automotivas.

S11 Li, Fuh e Wong (2004)

Prope um sistema baseado na web para apoiar a engenharia

colaborativa, com equipes distribudas.

S12 Rodriguez e Al-Ashaab

(2005)

KdCPD - Proposta de uma arquitetura de sistema baseada na web

para desenvolvimento colaborativo de produtos

S13 Woerner & Woern

(2005)

CSCE - Apresenta um modelo de gerenciamento de relaes de Contribui com funcionalidade de formar relacionamentos formais
parceiros nos projetos de engenharia, usando o conceito de CSCW. entre parceiros, designando tarefas para cada uma das partes. E
Possui foco na construo de confiana entre parceiros.
cada parceiro, dependendo da sua plataforma de trabalho, pode
utilizar uma diferente implementao do sistema.

S14 Wu et al. (2006)

Apresenta uma arquitetura que captura, por meio de agentes, os A proposta contribui com troca de informao entre pessoas
interesses e comportamentos de usurios de sistemas de design interessadas em uma mesma rea, buscando e armazenando
colaborativo.
histrico de conhecimento em uma base.

S15 Meja, Lopez e Molina

(2007)

Proposta de desenvolvimento de um ambiente de engenharia O principal propsito do artigo contribuir com um melhor
colaborativa, utilizando ferramentas de engenharia colaborativa entendimento das condies de desenvolvimento e a atual tecnologia
existentes.
disponvel para o desenvolvimento de um ambiente de engenharia
colaborativa, que os autores chamam de (Collaborative Engineering
Environment (CEE).

Contribui com funes para detalhamento do produto (CAD) e plano

de processo em espaos de trabalho colaborativo, com uma
arquitetura aberta e genrica.
A proposta engloba gerenciamento de equipes, mdulo de
comunicao, modelo e representao geomtrica do produto,
gerenciamento das atividades, lies aprendidas e ferramentas de
engenharia, bem como integrao com CAD/CAE/CAM.

Quadro 6. Artigos encontrados na reviso da literatura

Fonte: elaborado pela autora

105

106

Avaliao da tabela e consideraes

Chama a ateno o fato de que grande parte dos softwares encontrados na reviso tem
como principal funcionalidade as aplicaes de engenharia, tal como o compartilhamento de
arquivos CAD. As funcionalidades de gerenciamento de projetos so, muitas vezes,
acessrias. Um dos artigos encontrados na reviso, de Li, Fu e Wong (2004), tambm realiza
uma reviso de trabalhos recentes relacionados com a engenharia simultnea (Concurrent
Engineering - CE), onde se pode observar a nfase em aplicaes para engenharia, como o
compartilhamento de arquivos CAD/CAM.
O levantamento identificou apenas 15 propostas na literatura, sendo que, apenas 2 so
voltadas especialmente para apoiar o gerenciamento de projetos. Trata-se de um nmero
modesto, principalmente se levarmos em conta as consideraes nos captulos iniciais desse
trabalho, que demonstram que as ferramentas de gerenciamento de projetos so ainda uma
fonte de dificuldade para as empresas que realizam projetos colaborativos.
Portanto, a primeira concluso que faltam propostas de softwares para apoiar as
atividades de gerenciamento em projetos de novos produtos, realizados de forma colaborativa,
e que contemplem funcionalidades relacionadas ao gerenciamento de projetos. Rodriguez e
Al-Ashaab (2005) tambm apresentam uma reviso da literatura sobre sistemas de
desenvolvimento colaborativo de produtos, e somente duas propostas de sistemas, anteriores
ao ano de 2001, envolvem requisitos de gerenciamento de projetos.
Dentre os trabalhos propostos, pode-se observar que o foco das funcionalidades est
nas comunicaes. A figura 19 deixa isso bem evidente. Trinta e sete por cento (37%) de
todas as ocorrncias de funcionalidades propostas so voltadas para apoiar a comunicao,
isto , so ferramentas para distribuio de informaes. Elas so seguidas respectivamente
pelas funcionalidades de definio de escopo (21%), integrao de dados (17%), estimativas
de tempo (13%), colaborao (10%), aquisies (2%). As reas de custo, qualidade, recursos

107

humanos e riscos no foram encontradas nos artigos pesquisados. Assim, evidente a

necessidade de propostas que englobem essas reas.

Colaborao
10%
Integrao
17%

Aquisies
2%
Riscos
0%

Tempo
13%

Comunicaes
37%
Escopo
21%
Qualidade
0%

Rec. Humanos
0%
Custo
0%

Figura 19. Distribuio dos trabalhos nas reas

Fonte: elaborada pela autora

Cada rea possui suas subreas (quadro 5). Foi analisado o detalhamento de cada rea
e observadas ausncias nas funcionalidades das propostas, em relao ao gerenciamento de
projetos. Cada rea foi desdobrada em suas respectivas subreas e representada graficamente.
A seqncia de apresentao segue a ordem de representatividade das reas.
A figura 20 mostra que a rea de comunicaes possui todas as subreas
representadas, e 72% das funcionalidades so voltadas para a distribuio das informaes. J
as funcionalidades para gerenciar as partes interessadas representam 17%. O planejamento
das comunicaes e relatrios de desempenho representam apenas 6% da rea de
comunicaes.

108

Comunicaes

72%
80%
60%
40%
20%

17%
6%

6%

0%
Planejamento das comunicaes

Distribuio das informaes

Relatrio de desempenho

Gerenciar as partes interessadas

Figura 20. rea de Comunicaes

A prxima rea Escopo, que possui cinco subreas, mas somente trs possuem
representatividade nas funcionalidades. A definio de escopo representa 60% da rea,
seguida de 30% de verificao do escopo e 10% de planejamento (Figura 21). As subreas
que representam as funcionalidades de criao de WBS e controle do escopo no aparecem
nas propostas estudadas.
Escopo
60%
60%
50%
30%

40%
30%
20%

10%

10%
0%
Planejamento do escopo

Definio do escopo

Verificao do escopo

Figura 21. rea de Escopo

109

A rea de Integrao (figura 22) apresenta funcionalidades somente em duas subreas,

com valores iguais: 50% no monitoramento e controle do projeto, e 50% na integrao de
dados de softwares. Aqui se observa a ausncia de propostas com funcionalidade para
desenvolver o termo de abertura do projeto; a declarao do escopo preliminar do projeto; o
plano de gerenciamento do projeto; orientar e gerenciar a execuo do projeto, fazer o
controle integrado de mudanas e encerrar o projeto. Na seo 3.3, onde foram demonstrados
os desafios para os softwares de GP frente colaborao e agilidade, so apresentadas
necessidades de desenvolvimento de funcionalidades que privilegiem a viso do produto final,
que est diretamente relacionada com o termo de abertura e declarao preliminar de escopo
do projeto. Tambm na seo 3.3, dito que existe necessidade de funcionalidades que
facilitem as alteraes constantes no produto, que implica diretamente o controle integrado de
mudanas. Assim temos a constatao das deficincias de funcionalidades dos softwares de
GP na rea de Integrao.

Integrao
50%

50%

50%
40%
30%
20%
10%
0%
Monitorar e controlar o trabalho do projeto

Integrao de dados de software

Figura 22. rea de Integrao

110

Dentro da rea de Tempo (Figura 24), as subreas de definio de atividade,

estimativas de recursos da atividade e estimativa de durao da atividade obtiveram,
respectivamente, 50%, 33% e 13% de representatividade. J as subreas de seqenciamento
de atividades, desenvolvimento do cronograma e controle do cronograma no foram
contempladas nas propostas de softwares estudados.
Tempo
50%
50%

33%

40%
30%

17%

20%
10%
0%
Definio da atividade

Estimativa de recursos da atividade

Estimativa de durao da atividade

Figura 23. rea de Tempo

A rea de colaborao (Figura 24) apresenta propostas de funcionalidades que esto

nas subreas de controle de contribuio dos colaboradores (80%) e controle de informaes
confidenciais e pblicas (20%), porm no existem funcionalidades voltadas aos registros de
acordos de colaborao entre as partes. Aqui observada outra necessidade de estudo para os
novos softwares de gerenciamento de projetos colaborativos.

111

Colaborao
80%
80%
60%
40%

20%

20%
0%
Controle de contribuio dos colaboradores
Controle de informaes confidenciais e pblicas

Figura 24. rea de Colaborao

A ltima rea que possui representatividade a de Aquisies. Ela possui somente

uma proposta de funcionalidade, de Liang e Huang (2002), para solicitar respostas de
fornecedores.
Foi possvel verificar que a literatura apresenta conceitos tericos para solucionar
algumas dessas ausncias, como Chen e Chen (2003) com uma proposta de DSM (Design
Structure Matrix) para seqenciar e controlar as atividades de desenvolvimento de um novo
produto. Ghosh e Varghese (2004) destacam a necessidade de um framework para
gerenciamento de projetos de desenvolvimento de produtos desenvolvidos de forma
geograficamente distribuda. Mas esses conceitos no esto associados a nenhum software.

5.2.2. Softwares para gerenciamento gil de projetos

Conforme apresentado na seo 3.4, a literatura acadmica no contempla propostas
de softwares para apoiar o gerenciamento gil de projetos. Porm, foram encontradas solues
voltadas para esse enfoque. As buscas na internet e em grupos de discusso sobre APM
identificaram trs sistemas comerciais. Todos so especficos para o gerenciamento de

112

projetos de desenvolvimento de softwares. As ferramentas encontradas so de cdigo fechado,

comercializadas por meio de licenas, mas possuem uma verso Trial, para teste de 30 dias,
as quais foram utilizadas para efeito de avaliao.
Os softwares avaliados, com seus respectivos sites, foram:
- VersionOne - http://www.versionone.com
- Target - http://www.targetprocess.com
- Rally - http://www.rallydev.com
A avaliao seguiu o procedimento de cenrio. Criou-se um cenrio de um projeto
fictcio, envolvendo dois profissionais. Assumiram esses papis o pesquisador e um aluno de
Iniciao Cientfica. Simulaes do uso do software em condies de alteraes do projeto e
controle foram realizadas. As impresses e diferenas em relao aos sistemas tradicionais,
comparadas segundo as funcionalidades apresentadas na seo 3.1, foram coletadas e
registradas.
As principais diferenas em relaes s funcionalidades tradicionais so as seguintes:

Utilizam como principal idia um planejamento inicial simplificado (Workitem

Planning) e iteraes (Sprints) dentro do projeto. Dentro de cada iterao so
registradas as entregas que devem ser realizadas e seu prazo. A figura seguinte (25)
um exemplo da viso geral do processo de desenvolvimento do projeto, utilizado no
software VersionOne. A representao mostra desde o planejamento do projeto at o
andamento das iteraes. possvel observar na figura que esse software no segue o
mesmo padro e as funcionalidades tpicas dos softwares de gerenciamento clssico
de projetos (seo 3.1). Os demais softwares analisados seguem padres similares.
Cada entrega pode ser detalhada em subentregas, que tambm possuem prazo
estipulado. A responsabilidade de cada entrega ou subentrega associada a um
recurso humano.

113

Figura 25. Tela do software VersionOne

Fonte: www.versionone.com

O tradicional grfico de Gantt no utilizado, mas existem outras ferramentas para

acompanhamento visual do andamento do projeto, como status de cada iterao,
entrega, subentrega e relatrios Burndown, isto , que descrevem progresso de uma
equipe e o denominado Roadmap, relacionado ao escopo do projeto e suas
mudanas ao longo do projeto. A figura 26 demonstra um relatrio do tipo
Burndown das iteraes no software Rally.

114

Figura 26. Tela do software Rally relatrio Burndown

Fonte: www.rallydev.com

Outra funcionalidade existente o registro das aes necessrias para as prximas

entregas, como correes de problemas (Defects). O registro de problemas feito da
mesma forma que uma entrega, relatando o problema a ser resolvido, e associado a
uma iterao dentro do projeto. A figura 27 do software Rally demonstra o registro de
problemas, Defects. Note-se que no muito diferente de um relatrio de issues
(problemas) nos SGPs tradicionais, a no ser pela relao direta com cada uma das
entregas.

115

Figura 27. Tela do software Rally - Defects

Fonte: www.rallydev.com

Uso de painis de controle, chamado nesses softwares de Dashboard. Trata-se de

relatrios resumidos que proporcionam uma viso geral do projeto. Os relatrios
apresentados nesses softwares contm informaes similares como prximas
atividades a serem desenvolvidas e ltimas mudanas que ocorreram no projeto. A
figura 28 d exemplo do Dashboard do software Target.

116

Figura 28. Tela do software Target - Dashboard

Fonte: www.targetprocess.com

Possuem tambm rea para guardar as retrospectivas, que seriam as lies aprendidas,
alm das anlises das estimativas iniciais do projeto.

Nos softwares voltados para o enfoque gil de gerenciamento de projetos, todas as

mudanas de escopo so gerenciadas e podem ser analisadas em relatrios,
permitindo aos colaboradores acompanhar as alteraes do projeto. A diferena dos
softwares tradicionais que os relatrios, alm de indicarem as mudanas de escopo,
indicam tambm as tendncias de estimativas de tempo, atividades e problemas para
as novas entregas.
As funcionalidades citadas, apesar de estarem voltadas ao desenvolvimento de

softwares, podem ser estudadas para serem adaptadas ao desenvolvimento de produtos. Dessa

117

forma, seria possvel a criao de um software para gerenciamento de projetos de

desenvolvimento de produtos utilizando-se o enfoque gil.

5.3. Requisitos para um software de gerenciamento gil de projetos colaborativos

Este estudo procurou obter informaes sobre softwares de gerenciamento de projetos
de vrias fontes, visando identificar requisitos para uma nova proposta de software de
gerenciamento de projetos voltados ao desenvolvimento colaborativo de produtos, utilizandose o enfoque gil de GP. Nesse primeiro momento, o foco de aplicao do software seriam
empresas pequenas que desenvolvem produtos inovadores e tecnolgicos, com a colaborao
de outras organizaes. Assim, o objetivo dessa seo apresentar um resumo de requisitos
para indicar possibilidades de estudos futuros no desenvolvimento de ferramentas geis.
Quando feita a proposta de desenvolvimento de um software, primeiramente
necessrio entender o seu objetivo principal e quais problemas ele ir resolver. Algumas
condies devem ser cumpridas para se chegar ao objetivo, ou seja, satisfazer alguns
requisitos. Leite (1994)5 apud Cysneiros (2001) define requisito como condio necessria
para a obteno de certo objetivo, ou para o preenchimento de certo objetivo.
A aquisio de requisitos uma etapa essencial do processo de desenvolvimento de
software. por meio deles que se pode avaliar se o software ir contemplar as
funcionalidades para atender o propsito para o qual foi criado.
No decorrer deste trabalho, foram identificados vrios objetivos que precisam ser
enfrentados para o desenvolvimento de sistemas de informao que apiem o gerenciamento
de projetos colaborativos de novos produtos, segundo os princpios do gerenciamento gil de
projetos (APM). Portanto, uma forma de sintetiz-los compilando-os na forma de uma lista
de requisitos.

Leite J.C.S.P., Engenharia de Requisitos- Notas de Aula, 1994

118

Os requisitos formam uma viso sinttica das anlises obtidas por meio da: a) reviso
da literatura; b) estudo de casos mltiplos; e c) anlises de sistemas existentes de
gerenciamento de projetos geis voltados para softwares.
Essa etapa do trabalho tem a inteno de formar uma sntese dos resultados das
diferentes anlises conduzidas. A meta facilitar a identificao de temas que precisam ser
detalhados para o desenvolvimento do software. Eles podem ainda ser utilizados como
referncia tanto para a customizao de softwares existentes de gerenciamento de projetos,
como tambm para o desenvolvimento de novas solues que possam apoiar esse processo.
Uma classificao dos requisitos com bastante aceitao na comunidade acadmica a
de requisitos funcionais e requisitos no funcionais (MYLOPOULOS et al., 1992;
SOMMERVILLE e SAWYER, 1998). Cysneiros (2001) diz que requisitos funcionais so os
que expressam funes ou servios executados por um software. As funes ou servios so,
em geral, processos que transformam entradas em sadas. J os requisitos no funcionais so
os que declaram restries, ou atributos de qualidade para um software e/ou para o processo
de desenvolvimento deste sistema. Segurana, preciso, usabilidade, desempenho e
manutenibilidade so exemplos de requisitos no funcionais.
vlido lembrar que o foco deste trabalho no est na engenharia de requisitos e, por
esse motivo, no feita uma reviso bibliogrfica exaustiva da rea. Procurou-se adotar os
princpios consagrados da engenharia de requisitos para uma elaborao mais rigorosa da
proposta de pesquisa.
Primeiramente, foram listados os requisitos funcionais, separados em grupos conforme
suas funcionalidades. Em seguida, foram avaliadas as necessidades apresentadas no
levantamento bibliogrfico e na compilao dos estudos de casos para a gerao dos
requisitos no-funcionais. Essa ordem foi utilizada pelo prprio fato de que os requisitos no
funcionais esto sempre relacionados a um requisito funcional (EAGLE, 1995; CHUNG et al.,

119

20006 apud CYSNEIROS, 2001). Para a descrio dos requisitos, tanto no funcionais como
funcionais, foi utilizada a linguagem natural.
A seguir, so apresentados os grupos de requisitos funcionais:
1) Permitir o registro e controle de usurios
a. Permitir a incluso/edio/excluso do cadastro de organizaes;
b. Permitir a incluso/edio/excluso do cadastro de usurio relacionado sua
organizao;
c. Permitir a definio de privacidade de informaes;
d. Possibilitar o cadastro/edio de controle de permisses de acesso e relacionlo aos usurios;
e. Registrar os acessos e aes dos usurios, gerando um registro de log;
f. Permitir o backup de informaes pelas organizaes, respeitando as restries
de acesso e privacidade de informaes.

2) Deve apoiar a elaborao da viso do produto e especulao

a. Permitir a criao de uma viso do produto, isto , uma descrio sinttica do
produto que ser desenvolvido, por meio da insero e combinao de
diferentes documentos, como modelos de estrutura de funes e esboos
iniciais da concepo do produto final;
b. Possibilitar especulao em torno da viso: registro de alternativas propostas
por usurios e ferramentas de apoio na seleo das alternativas;
c. Armazenar o histrico das alteraes na viso e decises sobre ela;
d. Apresentar para o usurio o modelo final da viso de maneira sinttica.

EAGLE, 1995 - Evaluation of Natural Language Processing Systems, http://www.issco.unige.ch/ewg95 1995 e

Chung, L. et al. Non-FunctionalRequirements in Software Engineering Kluwer Academic Publishers 1999.

120

3) Planejar o projeto de forma simples

a. Possibilitar o planejamento por etapas, com base em iteraes e entregas
(resultados), ao invs de atividades e fases;
b. Permitir a definio de equipes e sua associao s entregas;
c. Registrar as atividades principais, sendo essas relacionadas s entregas e
usurios responsveis;
d. Permitir o registro do prazo mximo das entregas do projeto;
e. Permitir a utilizao de informaes da viso para gerar o planejamento do
projeto, possibilitando: relacionar partes da viso do produto com entregas, e
partes do produto por meio da descrio das interfaces;
f. Registrar as limitaes, restries e metas de custo do projeto;
g. Permitir a identificao e priorizao dos riscos do projeto;
h. Registrar alteraes do planejamento: entregas, viso, restries, responsveis
e demais elementos;
i. Manter os dados do planejamento-base e permitir comparaes do atual com o
planejamento-base;
j. Gerar uma forma grfica de visualizao do planejamento;
k. Permitir a definio de indicadores de desempenho, utilizando os dados
existentes.

4) Acompanhar o andamento do projeto

a. Controlar status das entregas do projeto;
b. Controlar e registrar alteraes/validaes das entregas;
c. Possibilitar avaliao das entregas e avaliao parcial do projeto;
d. Registrar novos requisitos;

121

e. Permitir a associao de documentos de vrios tipos, execuo das entregas;

f. Gerar relatrios de indicadores de desempenho a partir de dados de entrega e
interaes;
g. Controlar verses de documentos;
h. Registrar as interaes entre os membros do projeto;
i. Possibilitar a visualizao detalhada do andamento do projeto;
j. Possibilitar acompanhamento e avaliao pelo cliente, de maneira contnua
durante o projeto;
k. Criar um painel para o acompanhamento dos riscos envolvidos no projeto.

5) Finalizar do projeto
a. Solicitar avaliao final do projeto;
b. Gerar indicadores de desempenho finais;
c. Gerar forma grfica de demonstrao do resultado final do projeto;
d. Guardar validaes finais do projeto;
e. Permitir o acesso ao histrico do projeto, depois de finalizado, respeitando as
restries de acesso de cada usurio;
f. Permitir avaliao final do projeto pelos clientes.

6) Comunicao e Integrao
a. Possuir diferentes formas de comunicao entre os membros do projeto,
incluindo ferramentas sncronas e assncronas;
b. Registrar as interaes sncronas ou assncronas entre os usurios e seus
resultados, de forma que as informaes possam ser distribudas entre os
demais membros do projeto ou consultadas posteriormente;

122

c. Deve possibilitar o uso e integrao de documentos de diferentes tipos, por

exemplo, textos oriundos de diferentes editores;
d. Possibilitar o uso de dados dos sistemas de gerenciamento de projetos
tradicionais;
e. Permitir a integrao com sistemas de workflow para disparar fluxos de
atividades;
f. Possuir recursos de Comunidades de Prtica, de modo a apoiar a formao da
comunidade de projeto.

A seguir, temos os requisitos no funcionais identificados. Cada requisito est

acompanhado da justificativa da fonte, da literatura consultada, da anlise de softwares ou dos
estudos de casos realizados. No apndice D, h uma tabela resumindo os requisitos e suas
fontes.
1) A interface deve ser baseada na web: todas as propostas da literatura empregam
interface web, de forma a garantir a distribuio das informaes entre os
colaboradores, com fcil acesso, no necessitando da instalao de softwares
locais. Das 15 propostas de softwares analisadas, todas trocavam dados via web e
tinham como interface um browser. Os trs softwares de APM tambm. Hameri e
Puittinen (2003) propem que se deve utilizar essa plataforma, assim como Ren et
al. (2006), justificando pela disponibilidade dessa tecnologia e pelo fato dela vir se
tornando um padro para os usurios.
2) Uso de ferramentas de comunicao variadas: j que o foco a colaborao no
projeto de desenvolvimento de produto, existe a necessidade de vrias formas de
comunicao e interao entre os colaboradores. Este requisito apresentado na
reviso da literatura, onde se nota um fator de sucesso do projeto na comunicao

123

efetiva. Tambm pode ser observada no estudo de caso da empresa A, que

apresenta a necessidade da integrao de comunicao com colaboradores externos
de forma rastrevel. J a anlise do estudo de caso da Empresa C aponta
diminuio de custos de deslocamentos com reunies presenciais se existisse
integrao on-line com pessoal externo.
3) Interface homem-computador simplificada e resumida por meio do uso
intensivo de grficos: o enfoque gil prope o uso de relatrios simples e com o
mximo de aproveitamento de recursos grficos. Portanto, o software deve utilizar
formas grficas variadas de modo a facilitar o entendimento de uma entrega ou do
prprio produto final, como o uso de modelos grficos 3D para esboos do
produto, demonstrados na anlise dos softwares para gerenciamento gil de
desenvolvimento de software. Nas propostas de softwares da literatura, essa
necessidade est presente e j foi identificada por outros autores (CHUNG e LEE,
2002; QIN et al., 2003; TAY e ROY, 2003; LI, FUH e WONG, 2004;
RODRIGUEZ e AL-ALSHAAB, 2005). Tambm podem ser includas novas
formas de visualizao de fases do projeto, como foi visto nos novos SGP para
desenvolvimento de software baseados no enfoque gil.
4) Integrao com funcionalidades de sistemas de engenharia como CAD: o
estudo de caso da empresa B aponta para a integrao dos dados do projeto com os
dados do produto. Portanto, na medida do possvel, o sistema deve permitir a
migrao de dados do projeto oriundas de sistemas de engenharia como CAD e
CAE.
5) Descentralizao dos dados: permitir que os usurios possam exportar os dados e
trabalhar nas ferramentas de gerenciamento de projetos que julgarem mais
apropriadas. Uma concluso geral dos estudos de caso a de que as ferramentas de

124

planejamento e controle no so utilizadas na colaborao com agentes externos.

Um problema o acesso aos sistemas da empresa. Viabilizar a utilizao de multiplataformas poder facilitar esse compartilhamento, na medida em que usurios
externos podero utilizar o software que mais lhe convier (seja pelo costume,
conhecimento ou investimento j realizado).
6) Rastreabilidade das discusses sobre as entregas e decises em gates: na
reviso da literatura, seo 2.1.3, nota-se que o objetivo do projeto deve ser
claramente definido e este um fator de sucesso nos projetos colaborativos. Nos
estudos de caso, identificou-se que um dos aspectos importantes a
rastreabilidade. E que isso seria tanto legalmente como contratualmente
importante.
7) Flexibilidade de alterao das entregas/tarefas para atender s mudanas do
ambiente: na reviso da literatura sobre gil (seo 2.2), um dos principais focos
a criao de mtodos de planejamento e controle onde as mudanas nos planos
sejam realizadas facilmente, de forma a garantir a flexibilidade necessria no
transcorrer do projeto. A falha no controle de mudana do projeto pode impedir o
sucesso do projeto, justificando a necessidade. Nas propostas dos softwares de
literatura, na avaliao da rea de Integrao, tambm foi identificada a ausncia
de propostas que englobem essa necessidade (seo 5.2.1).
8) Rastreabilidade dos dados: todas as discusses, definies e alteraes do
projeto devem ter a possibilidade de ser rastreadas: o estudo de caso da empresa A
demonstra essa necessidade de rastreabilidade.
9) Garantir o sigilo de dados: na reviso da literatura e, principalmente nos estudos
de caso, pode-se notar que o controle de informaes um ponto crtico para as

125

empresas. Nos desafios da empresa A, temos o exemplo prtico de troca de

informaes confidenciais, que poderia ser gerenciada por um software.
10) Controle de verso e fluxo de documentos: o estudo de caso da Empresa D
demonstra a necessidade de se tornar mais confivel o controle de documentos,
independentemente do tamanho da empresa. O estudo de caso da empresa B
tambm demonstra a necessidade de melhorar o controle de documento, para
garantir a confiabilidade e segurana das informaes.
11) Indicadores de desempenho de forma grfica e sinttica: o estudo de caso da
empresa C demonstra esta necessidade de gerao de relatrios dos indicadores de
desempenho, bem como o estudo de caso da empresa B aponta esses indicadores
como fator importante para acompanhamento do projeto e apresenta necessidade
de uma gerao automtica destes, utilizando-se os dados atualizados do projeto. O
estudo de caso da empresa A tambm aponta necessidade de melhorar a gerao de
indicadores de desempenho. Os desafios do GP e do enfoque gil, verificados na
reviso da literatura, tambm indicam necessidade de indicadores visuais e gerados
automaticamente.
12) Controle de multiprojetos: o estudo de caso da empresa A apresenta a
necessidade deste controle, integrando as informaes sobre recursos disponveis e
ocupados para os projetos, garantindo uma melhor programao de datas e prazos.
Exigir o menor tempo possvel durante a execuo das atividades rotineiras: Foco no
resultado e simplicidade. Esta necessidade apresentada na reviso da literatura, onde
apontada a burocracia do gerenciamento clssico de um projeto e no surgimento de novas
ferramentas comerciais para gerenciamento de projetos com foco na entrega do produto.

126

6. Concluses e pesquisas futuras

Este trabalho identifica, por meio de investigaes tericas e de campo, os desafios do
gerenciamento de projetos colaborativos de desenvolvimento de produtos. Foram avaliados e
compilados os problemas, segundo os tericos da rea de gerenciamento dos projetos
colaborativos, gerenciamento de projetos e do enfoque gil de gerenciamento de projetos,
alm de anlises de quatro casos reais de empresas de bens de capital e anlises de softwares
comerciais.
A partir dos desafios do gerenciamento dos projetos colaborativos, possvel concluir
que para extinguir os diferentes entendimentos sobre os objetivos e andamento do projeto
entre seus participantes, as informaes devem ser constantemente atualizadas e
disponibilizadas para as partes que integram o projeto.
A partir da avaliao da literatura acadmica sobre gerenciamento de projetos e o
enfoque gil, conclui-se que faltam modelos e tcnicas para apoiar as mudanas constantes
nos projetos, capazes de gerar um acompanhamento rpido das alteraes ocorridas e atualizar
o resultado final do produto, sem consumir tempo com extensa documentao.
A anlise da literatura acadmica sobre SGP permite concluir que faltam propostas de
pesquisas sobre softwares de gerenciamento de projetos. A anlise demonstrou que autores
das trs reas analisadas indicam problemas com as ferramentas existentes. O principal
problema identificado a falta de capacidade de lidar com controles de multiprojetos em
ambientes dinmicos, isto , ambientes de desenvolvimento de produtos complexos e
inovadores. Em especial, identificaram-se problemas no planejamento de projeto,
necessitando-se de funcionalidades que privilegiem a viso do produto final e acordos de
colaborao entre as partes. Um grande problema o surgimento da necessidade de mtodos

127

que sejam flexveis ao ambiente de incerteza, com foco nas pessoas, que criem mais valor
para o cliente e encorajem a adaptao do processo e das pessoas.
Tambm foram avaliadas as tendncias dos softwares de GP. Pela anlise do relatrio
do Gartner (2007), em conjunto com a avaliao das ferramentas de GP geis de softwares,
foi possvel concluir que as novas ferramentas de GP tendem a utilizar as funcionalidades do
gerenciamento de projetos de desenvolvimento de softwares, que adota o enfoque gil
(APM), alm de incorporar funcionalidades integradas de colaborao com gerenciamento de
projetos. Os novos softwares de GP tambm possuem tendncia de apresentar funcionalidades
para o acompanhamento contnuo das mudanas necessrias ao decorrer do projeto.
O quadro 7, a seguir, apresenta a comparao entre os desafios encontrados na
literatura e nos estudos de casos.
reas do
Gerenciamento
de Projetos

Foco das Pesquisas

% de
trabalhos

Foco das pesquisas

Integrao

17

Monitorar e controlar o trabalho do

projeto e integrao dos dados dos
softwares

Tempo

13

Definio das atividades,

estimativa de recurso e durao das
atividades

Escopo

21

Definio e verificao do escopo

Custos

Qualidade
Recursos
Humanos

Desafios Enfrentados pelas Empresas

Ocorrncia
Temas a serem resolvidos
nos casos
Definio e gerenciamento
das interfaces entre partes do
A, B, C e D
projeto, Integrao de dados
entre todos os softwares
Gerenciamento de recursos
Gerenciamento multiA, B, C e D
projetos
Indicadores de desempenho
Identificao de requisitos
A
crticos
Controle das informaes
C
financeiras

Comunicaes

37

Distribuio das informaes e

gerenciar as partes interessadas do
projeto

Riscos

Aquisies

Solicitar resposta de fornecedores

Colaborao

10

Controle de contribuio dos

colaboradores, controle do sigilo
das informaes

A, B e C

CeD
A, C e D

Compartilhamento de dados
entre partes do projeto
Planejamento e controle dos
riscos durante o projeto
Controle das aquisies no
decorrer do projeto
Ferramentas de apoio
realizao do contrato
Foco no registro das
informaes e rastreabilidade

Quadro 7. Comparao entre a literatura e estudos de casos

Fonte: elaborado pela autora

128

As exigncias e os desafios identificados nos estudos de caso permitem duas

concluses principais. A primeira que eles reforam as dificuldades identificadas na reviso
bibliogrfica, como a utilizao bsica das funcionalidades dos SGPs e ausncia de sistemas
integrados do tipo EPM ou integrao entre as vrias ferramentas utilizadas, que acabam por
gerar redundncia de dados e retrabalho. A segunda a identificao de novas
funcionalidades que merecem ser desenvolvidas. Certos aspectos identificados como desafios
para os casos estudados no haviam sido citados na reviso da literatura, apesar de parecerem
fundamentais. Os principais so as necessidades de funcionalidades de software para apoiar:
a) a gesto da aquisio durante o desenvolvimento de produtos;
b) o gerenciamento contnuo dos riscos no decorrer dos projetos;
c) e a constatao da baixa utilizao de ferramentas durante o trabalho colaborativo.
Os casos restringem-se a um setor industrial e so apenas quatro empresas. Porm,
considerando tratar-se de empresas lderes em seus setores e com perfis significativamente
distintos, a presena em todos os casos um forte indcio de ser um problema significativo.
Portanto, sugere-se que esses aspectos sejam uma importante hiptese de pesquisa a ser
investigada para aprimoramento dos softwares de gerenciamento de projetos.
A primeira grande contribuio do trabalho, portanto, demonstrar que h espao para
o desenvolvimento de softwares que apiem o planejamento e controle de projetos
colaborativos, de uma forma mais simples e flexvel, conforme as crticas realizadas ao
gerenciamento de projetos. Isso permitir a adoo de prticas de gerenciamento gil em
projetos colaborativos, o que seria especialmente vantajoso para empresas que atuam com
produtos inovadores e pequenas empresas de base tecnolgica.
Adicionalmente, compilou-se o resultado dessas anlises em uma primeira verso de
requisitos para um software que cumprisse essa misso, facilitando assim a continuidade do
trabalho e servindo como sntese das evidncias coletadas. Esse resultado demonstrou que h

129

um conjunto deles que, por sua singularidade, merecem ser pesquisados e estudados com
maior ateno.
Este trabalho representa um primeiro esforo na identificao dos requisitos e
necessita de estudos futuros. Em um processo de desenvolvimento de software, a elicitao de
requisitos, utilizada para compreender a real necessidade dos usurios e delimitar o escopo do
projeto, est em constante mudana ao longo do projeto. Da mesma maneira, a lista de
requisitos apresentada est sujeita s alteraes necessrias para o desenvolvimento futuro
deste trabalho, com avaliaes seqentes para a elicitao de novos requisitos.
Algumas sugestes de pesquisas futuras, dando continuidade a este trabalho so:

Estudo de um mtodo para a descrio grfica e avaliao da viso do produto,

que possui grande importncia para a compreenso do produto a ser
desenvolvido por todos os envolvidos no projeto;

Estudo de mtodos para apresentar e organizar o plano de iteraes e entregas,

Estudo do enfoque gil para o gerenciamento de projetos para indstrias que

desenvolvem produtos fsicos, com o intuito de criar um modelo, adaptando as
tcnicas aplicadas na indstria de desenvolvimento de software;

Estudo das possibilidades de integrao de documentos oriundos de diferentes

softwares, para viabilizar a colaborao entre diferentes organizaes, sem a
necessidade da adoo de uma plataforma nica para a troca de arquivos;

Estudo das possveis ferramentas sncronas de comunicao e do mtodo de

armazenamento dos arquivos gerados pelas comunicaes, associados s suas
relativas atividades;

Estudo de metodologias para a gerao visual de indicadores de desempenho e

acompanhamento do projeto, avaliando-se as tecnologias disponveis que
podem ser agregadas ao software.

130

Referncias Bibliogrficas
AMARAL, D. C. Colaborao cliente-fornecedor no processo de desenvolvimento de produtos:
estudos de caso na indstria automobilstica: escopo, integrao e qualidade do produto.
Dissertao (Mestrado em Engenharia de Produo). Universidade Federal de So Carlos, So Carlos,
1997.
AMARAL, D. C.; TOLEDO, J. C. Colaborao cliente-fornecedor no processo de desenvolvimento de
produto. Gesto & Produo, So Carlos, v. 7, n. 1, p. 56-72, abril, 2000.
AUGUSTINE, S.; WOODCOCK, S. Agile project management: emergent order through visionary
leadership. May, 2003. Disponvel em: <http:ccpace.com/resources/AgileProjectManagement.pdf>.
Acesso em: 26 jan. 2007.
BARNES, T. A.; PASHBY, I. R.; GIBBONS, A. M. Managing collaborative R&D projects
development of a practical management tool. International Journal of Project Management, vol.
24, n 5, p. 395404, julho, 2006.
BECK, K. et al. Manifesto for agile software development.
<http://www.agilemanifesto.org>. Acesso em janeiro, 2007.

2001.

Disponvel

BECK, K.et al. Chrysler goes to extremes. Out., 1998. Disponvel

<http://www.xprogramming.com/publications/dc9810cs.pdf > Acesso em: 16 jan. 2007.

em
em

BENASSI, J. L. G.; AMARAL, D. C. GERENCIAMENTO GIL DE PROJETOS APLICADO AO

DESENVOLVIMENTO DE PRODUTO FSICO. In: XIV Simpsio de Engenharia de Produo,
2007, Bauru. Anais... Bauru: FEB, 2007.
BERGMAN, R.; BAKER, J. D. Enabling collaborative engineering and science at JPL. Advances in
Engineering Software, vol. 31, n 8-9, p. 661-668, agosto, 2000.
BOEHM, B. Get ready for agile methods, with care. IEEE Computer Magazine, [S.l], p. 64-69, 2002
BORLAND. Disponvel em <http://www.borland.com/br/products/tempo/index.html>. Acesso em 27
fev 2008.
CAMARINHA-MATOS, L. M. et al. Rough reference model for Collaborative Networks. Disponvel
em < http://www.ve-forum.org/projects/284/Deliverables/D52.2_Final.pdf >. Acesso em dez. 2006.
CARVALHO, M. M.; RABECHINI JUNIOR, R. Construindo Competncias para gerenciar
projetos. So Paulo: Editora Atlas, 2005.
CASTRO, H.; CARVALHO, M. M. Project Management best practices implementation: critical issues
in telecommunication companies. Product: Management & Development, v. 5, n.1, p. 41-50, junho,
2007.
CHEN, C.H.; CHEN, W. Project scheduling for collaborative product development using DSM.
International Journal of Project Management, v 21, n. 4, p. 291-299, maio, 2003.
CHIN, G. Agile Project Management: how to succeed in the face of changing project requirements.
NY: Amacon, 2004.

131

CHUNG, J.; LEE, K. A framework of collaborative design environment for injection molding.
Computers in Industry, vol. 47, n.3, p. 319-337, maro, 2002.
CICMIL, S. et al. Rethinking Project Management: Researching the actuality of projects.
International Journal of Project Management, v. 24, n. 8, p. 675-686, novembro, 2006.
COCKBURN, A. Agile software development joins the would-be crowd. Disponvel em:
<http://www.agilealliance.org/system/article/file/782/file.pdf> Acesso em: 17 jan. 2007.
COCKBURN, A.; HIGHSMITH, J. Agile software development, the people factor. Computer, vol.
34, n 11, p.131 133, novembro, 2001.
COHN, M., FORD, D. Introducing an agile process to an organization. IEEE Computer Magazine,
June 2003, [S.l.], p. 74-78.
CONFORTO, E. C.; AMARAL, D. C. Escritrio de Projetos e Gerenciamento gil: Um Novo
Enfoque para a Estrutura de Apoio Gesto de Projetos geis. In: XXVII Encontro Nacional de
Engenharia de Produo, 2007, Foz do Iguau. Anais... Foz do Iguau: ABEPRO, 2007a.
_________________________________. Escritrio de Projetos e Metodologia gil: Anlise e
Modelo Terico para Implantao Conjunta. In: 6 Congresso Brasileiro de Gesto de
Desenvolvimento de Produto, 2007, Belo Horizonte. Anais... Belo Horizonte: IGDP, 2007b.
CORRA. F.C. Propostas de melhoria para o PDP de uma empresa de mquinas agrcolas com base
no modelo de PDP da Toyota. So Carlos: UFSCar, 2008. Dissertao (Mestrado) Universidade
Federal de So Carlos, 2007.
CYSNEIROS, L. M. Requisitos No-Funcionais: da elicitao ao modelo conceitual. Tese
(Doutorado em Cincia da Computao). Pontifcia Universidade Catlica do Rio de Janeiro, Rio de
Janeiro, 2001. Disponvel em < http://www-di.inf.puc-rio.br/~julio/Tese%20-%205.pdf>. Acesso em
03 maro 2008.
DAVIS, J. M.; KEYS, L K.; CHEN. I. J. Collaborative Engineering for Research and Development.
13th International Conference on Management of Technology. AnaisWashington, DC, April 37,
2004.
DIAS, M. V. B. Um novo enfoque para o gerenciamento de projetos de desenvolvimento de
software. Dissertao (Mestrado em Administrao). Faculdade de Economia, Administrao e
Contabilidade, Universidade de So Paulo, So Paulo, 2005.
DODGSON, M. The future for technological collaboration. Futures, p. 459-470, junho, 1992.
DOTPROJECT. Disponvel em < http://www.dotproject.net/ >. Acesso em 10 jul 2008.
EMDEN, Z.; CALANTONE, R.; DROGE, C. Collaborating for New Product Development: Selecting
the Partner with Maximum Potential to Create Value. Journal of Product Innovation Management,
v.23, n.4, p. 330-341, 2006.
EPROJECT. Disponvel em < http://www.eproject.com/>. Acesso em 27 fev 2008.
EVARISTO, R.; FENEMA P.C. A typology of project management: emergence and evolution of new
forms. International Journal of Project Management, v.17, n.5, p.275- 281, outubro, 1999.
FOWLER,
M.
The
new
methodology.
Jul.,
2000.
Disponvel
em
<http://www.martinfowler.com/articles/newMethodologyOriginal.html> Acesso em: 24 jan. 2007.

132

GARTNER GROUP. Magic Quadrant for IT Project and Portfolio Management. 2007
GHOSH, P. P.; VARGHESE, J. C. Globally distributed product development using a new project
management framework. International Journal of Project Management, v. 22, p. 699708, 2004.
GODOY, A. S. Introduo pesquisa qualitativa e suas possibilidades. Revista de Administrao de
Empresas, v. 35, n. 2, p. 57-63, mar/abr, 1995.
GOLDRATT, E. M. Corrente Crtica. Editora Nobel, Brasil: So Paulo, 2005.
HAMERI, A. PUITTINEN, R. WWW-enabled knowledge management for distributed engineering
projects. Computers in Industry, vol. 50, n. 2, p. 165-177, fevereiro, 2003.
HIGHSMITH, J. Agile Project Management: Creating Innovative Products. Boston: Adison-Wesley,
2004
HIRSCHFELD, H. Planejamento com PERT-CPM e anlise do desempenho: mtodo manual e por
computadores eletrnicos aplicados a todos os fins. Ed.8. So Paulo: Atlas, 1985.
HUANG, G, H. Web-based support for collaborative product design review. Computers in Industry,
vol. 48, n.1 , p. 71-88, maio, 2002.
HUANG, G. Q.; MAK, K. L. Agent-based Collaboration between Distributed Web Applications: Case
Study on Collaborative Design for X Using CyberCO. Concurrent Engineer: Research and
Applications, vol. 10, n. 2, p. 279-290, 2002.
HUSTON, L.; SAKKAB, N. Connect and develop: inside Procter & Gambles new model for
innovation. Harvard business review, fevereiro, 2006.
IBM. Disponvel em <http://www-306.ibm.com/software/awdtools/portfolio>. Acesso em 27 fev
2008.
ITM. Disponvel em < http://itm-software.com/products/ppm.shtml>. Acesso em 27 fev 2008.
JUC JUNIOR, A. S.; AMARAL, D. C. Estudos de caso de maturidade em gesto de projetos em
empresas de base tecnolgica. In: 25 Encontro Nacional de Engenharia de Produo, 2005, Porto
Alegre. Anais.... Porto Alegre : ABEPRO, 2005.
JUGEND, D. et al. Critical success factors in the management of product development process in
medium and small technology-based companies within the process control automation sector. Product
(IGDP), v. 4, p. 115-126, 2006.
KATZ, J.S.; MARTIN, B.R. What is research collaboration? Research Policy, v.26 , n. 1, pp. 118,
maro, 1997.
KERZNER, H. Gesto de projetos: as melhores prticas. Traduo de Marco Antonio Viana Borges
et al. Porto Alegre: Ed. Bookman, 2002.
KERZNER, H. Project management: A systems approach to planning, scheduling, and controlling. ,
Van Nostrand, New York, 1984.
KODAMA, M. Innovation and knowledge creation through leadership-based stratregic community:
case study on high-tech company in Japan. Technovation, v.27, n.3, p. 115-132, maro, 2007.
KVAN, T. Collaborative design: what is it? Automation in Construction, v.9, n. 4, p. 409-415, julho,
2000.

133

LAUNDON, K.C.; LAUDON, J.P. Management information systems: management the digital firm.
New Jersey: Pearson Education, 9 ed., 2004. 121p.
LAROUSSE CULTURAL. Dicionrio da lngua portuguesa. So Paulo: Editora Nova Cultural, 1992.
LI, H. et al. Co-operative benchmarking: a tool for partnering excellence in construction.
International Journal of Project Management, v.19, n. 3, p. 171-179, abril, 2001.
LI, W. D.; FUH, J. Y. H.; WONG, Y. S. An Internet-enabled integrated system for co-design and
concurrent engineering. Computers in Industry, v. 55, n.1, p. 87-103, setembro, 2004.
LIANG, W.Y.; HUANG, C.C. The agent-based collaboration information system of product
development. International Journal of Information Management, v. 22, n. 3, p. 211-224, junho,
2002.
LIU, D. et al. Composition of engineering web services with distributed data-flows and computations.
Advanced Engineering Informatics, v.19, n. 1, p. 2542, Janeiro, 2005.
LIU, W. D. A Distributed Data Flow Model for Composing Software Services. Tese (Doutorado
em Filosofia) Stanford University, 2003.
MATTESSICH, P. W.; MONSEY, B. R. Collaboration: What makes it work. A review of research
literature on factors influencing successful collaboration. St. Paul, MN: Amherst H. Wilder
Foundation, 1992.
MAYLOR, H. Beyound the Gantt Chart: project management moving on. Business Management
Journal, v.19, n.1, pp.92-100, 2001.
MEJA, R.; LPEZ, A.; MOLINA, A. Experiences in developing collaborative engineering
environments: An action research approach. Computers in Industry, vol. 58, n. 4, p. 329-346, maio,
2007.
MICROSOFT. Disponvel em <http://office.microsoft.com/pt-br/project/HA101656381046.aspx>.
Acesso em 27/02/2008
MOODY, J. B.; DODGSON, M. Managing Complex Collaborative Projects: Lessons from the
Development of a New Satellite. Journal of Technology Transfer, v.31, n.5, p. 568588, setembro,
2006.
MYLOPOULOS,J. et al. Representing and Using Non-functional Requirements: A Process-Oriented
Approach, IEEE Transactions on Software Engineering,, v. 18, n. 6, p. 483-497, junho, 1992.
NAOUM, S. An overview into the concept of partnering. International Journal of Project
Management, v. 21, n. 1, p.71-76, janeiro, 2003.
NICOLO, E. Metaproject analysis: multiagent virtual project networks for strategic decisions in
preplanning. International Journal of Project Management, v.11, n.4, P. 215-226, novembro, 1993.
NOOTEBOOM, B. Innovation and inter-firms linkages: new implications for policy. Research
Policy, v. 28, n. 8, p. 793- 805, novembro, 1999.
OPEN WORKBENCH. Disponvel em < http://www.openworkbench.org/>. Acesso em 10 jul 2008.
OSTERGAARD, K. J.; SUMMERS, J. D. A taxonomic classification of collaborative design. In:
SOCIETY, D. (Ed.). Anais14th International Conference on Engineering Design. Stockholm:[s.n.],
2003.

134

PEREIRA, M. M. Avaliao de um ambiente computacional integrado para desenvolvimento de

produtos no segmento de bens de capital com engenharia sob encomenda. Dissertao (Mestrado
em Engenharia de Produo). Escola de Engenharia de So Carlos, Universidade de So Paulo, So
Carlos, 2005.
PHPCOLLAB. Disponvel em < http://www.php-collab.com/blog/ >. Acesso em 10 jul 2008.
PHPROJEKT. Disponvel em < http://www.phprojekt.com/index.php > . Acesso em 10 jul 2008.
PLANNER. Disponvel em < http://live.gnome.org/Planner>. Acesso em 10 jul 2008.
PMBOK. Um guia do conjunto de conhecimentos em gerenciamento de projetos. Mass.: Project
Management Institute, Inc, 2004.
POWERSTEERING. Disponvel em <http://www.powersteeringsoftware.com>. Acesso em 27 fev
2008
PRIMAVERA. Disponvel em <http://www.primavera.com/index.asp >. Acesso em 27 fev 2008
QIAN, F.; SHENSHENG, Z. Product Development Process Management System Based on P_PROCE
Model. Concurrent Engineer: Research and Applications, vol. 10, n3, p. 203-211, 2002.
QIN, S. F. et al. A framework of web-based conceptual design. Computers in Industry, vol. 50, n. 2,
p. 153-164, fevereiro, 2003.
REIS, C. R. Caracterizao do modelo de processo para projetos de software livre. Dissertao
(Mestrado em Computao e Matemtica Computacional). Instituto de Cincias Matemticas e de
Computao Universidade de So Paulo, So Carlos, 158 f , 2003.
REN, Z. et al. Collaborative project planning: A case study of seismic risk analysis using an eengineering hub. Computers in Industry, v.57, n. 3, 218-230, abril, 2006.
RODGERS, P. A. et al. The management of concept design knowledge in modern product
development organizations. International Journal of Computer Integrated Manufacturing, vol.
14, n. 1, p. 108115, 2001.
RODRIGUEZ, K.; AL-ASHAAB, A. Knowledge web-based system architecture for collaborative
product development. Computers in Industry, vol. 56, n.1, p. 125-140, janeiro, 2005.
RORIZ, J. H. R.; JUC JUNIOR, A. S.; AMARAL, D. C. Avaliao de ferramentas de gesto de
projetos de cdigo aberto.. In: 12 Simpsio Internacional de Iniciao Cientfica, 2004, So Paulo.
Resumos.... So Paulo : USP, 2004.
ROZENFELD, H. et al. Gesto de desenvolvimento de produtos: uma abordagem por processos.
So Paulo: Saraiva, 2006.
RYCROFT, R. W. KASH, D. E. Self-organizing innovation networks: implications for globalization.
Technovation, v. 24, n. 3, p. 187-197, maro, 2004.
SCIFORMA. Disponvel em < http://www.sciforma.com/us/home/index.jsp>. Acesso em
2008.

27 fev

SERENA. Disponvel em <http://www.serena.com/products/mariner/index.html>. Acesso em 27 fev

2008.

135

SOMMERVILLE, I.; SAWYER, P. Requirements Engineering A Good Practice Guide. John

Wiley & Sons, 1997.
TAY, F. E. H.; ROY, A. CyberCAD: a collaborative approach in 3D-CAD technology in a
multimedia-supported environment. Computers in Industry, vol. 52, n.2, p. 127-145, outubro, 2003.
TUTOS. Disponvel em <http://www.tutos.org/homepage/index.html>. Acesso em 10 jul 2008.
VERZUH, E. MBA compacto: gesto de projetos. Rio de Janeiro: Campus, 2000.
VOROPAJEV, V.; SCHEINBERG, M. Project-management methods and tools for the 21st century:
the SOVNET view. Internet 92, v. 10, n. 4, novembro, 1992.
WANG, L. et al. Collaborative conceptual design: state of the art. Computer-Aided Design, v. 34, n.
13, p. 981996, novembro, 2002.
WANG, Y. D.; SHEN, W.; GHENNIWA, H. WebBlow: a Web/agent-based multidisciplinary design
optimization environment. Computers in Industry, v. 52, n. 1, p. 17-28, setembro, 2003.
WHITE, D.; FORTUNE, J. Current practice in project management: an empirical study. International
Journal of Project Management, v. 20, n. 1, p. 1-11, janeiro, 2002.
WIKIPEDIA. Disponvel em < http://pt.wikipedia.org/wiki/P%C3%A1gina_principal >. Acesso em
05 maro 2008.
WINTER, M. et al. Directions for future research in project management: the main findings of a UK
government-funded research network. International Journal of Project Management, v. 24, n. 8, p.
638-649, novembro, 2006.
WOERNER, J.; WOERN, H. A security architecture integrated co-operative engineering platform for
organised model exchange in a Digital Factory environment. Computers in Industry, v. 56, n.4, p.
347-360, maio, 2005.
WOMACK, J.P.; JONES, D.T.; ROSS, D. Projetando o automvel. In ___. A mquina que mudou o
mundo. Rio de Janeiro: Campus, 1992.
WU, S. et al. Personal assistant agents for collaborative design environments. Computers in
Industry, v. 57, n.8-9, p. 732-739, dezembro, 2006.
YIN, R. K. Case Study Research: Design and Methods. Sage Publications Inc., USA, 1989.
_________. Estudo de caso: planejamento e mtodos. 2. ed. Porto Alegre: Bookman, 2001.

136

Apndices
Apndice A - Roteiro de Entrevista do Estudo de Caso
Parte 1 Caracterizao da Empresa e do seu PDP
1. Qual o porte da empresa
Micro

Pequena

Media

Grande

2. Numero de funcionrios e tipo de capital da empresa

3. Possui algum tipo de certificao?
4. Quais as Linhas e famlias de produtos
5. Quais so as unidades e departamentos envolvidos no PDP
6. Breve descrio do processo de desenvolvimento de produto da empresa (planejamento,
documentao, detalhamento, desenvolvimento, lanamento, ps-lanamento)
7. Existe troca de informao com parceiros no Processo de Desenvolvimento de Produto? Quais os
tipos mais freqentes? (fornecedores, clientes, universidades, institutos de pesquisa)
Sim

No

8. Como feita a troca de informao (formal ou informal)?

Parte 2 Caracterizao dos softwares para Gesto de Projetos

1. A empresa possui software para gesto de projetos?
2. Qual software a empresa utiliza?
3. Os projetos possuem minuta? O software utilizado possibilita a utilizao dessas minutas para a
gesto de projetos?
4. Portfolio (Marcar se possui ou no a ferramenta/caracterstica apresentada)
Arquitetura
Integrao com banco de dados
Mltiplos usurios / permisses
Formas de acesso
Plataforma
Calendrio e Agenda
Programao do calendrio do projeto
Programao do calendrio de recursos
Programao do calendrio de tarefas
Visualizar agenda de tarefas de um determinado recurso
Visualizar agenda de determinado projeto
Visualizar agenda de tarefas que engloba todos projetos
da organizao

137

Gesto de atividades
Visualizar e formatar grfico PERT
Visualizar e formatar grfico GANTT
Gerao de WBS
Definir e visualizar nveis para as atividades
Definir restries para as atividades
Visualizao das tarefas envolvendo todos projetos
Mtodo de determinao de durao das tarefas
Gesto de Recursos
Configurar Recursos
Visualizar Disponibilidade de uso dos recursos
Nivelamento de recursos (must start on, start no earlier)
Padres de alocao de recursos
Documentos e Relatrios
Gerao de relatrios
Impresso
Gerenciamento Eletrnico de Documentos
Gesto de Mltiplos Projetos
Compartilhamento e nivelamento de recursos entre
mltiplos projetos
Anlise dos parmetros ECV e IDP
Agrupamento de Projetos
Ferramentas de Comunicao e Integrao
Notificaes por e-mail
Exportao de projetos e tarefas
Importao de projetos e tarefas
Exportao de contatos
Importao de contatos
Frum de discusses interno
Frum de discusses na internet
Comunicao com cliente
Projetos Finalizados
Armazena documentos de projetos finalizados
Gera relatrios avaliando o desenvolvimento do projeto
Banco de dados com projetos finalizados (p/ busca)
5. A empresa possui uma metodologia de gesto de projetos?
Sim

No

6. O(s) software(s) utilizado(s) possui(em) algum tipo de integrao com outros sistemas dentro da
empresa? Qual?
7. Quais so os principais usurios do software?

138

8. Quem tem acesso s informaes contidas no software?

9. Como e o controle de acesso s informaes? O software compartilha informaes com parceiros?
Essas informaes compartilhadas so confidenciais?

Parte 3 Projetos desenvolvidos em conjunto

1. No caso de projetos realizados em cooperao com clientes e fornecedores, quais sistemas de
informao citados acima so utilizados?

Parte 4 Desafios, Problemas e Melhores Prticas

1. Quais fatores de mudana (ambientais, mercado, tecnologia, competitividade) fazem necessrio
melhorar o sistema de gesto de projetos?
2. Quais so os pontos fortes e fracos do sistema de gesto de projetos atual? Quais recursos faltam
ao software para melhorar a gesto de projetos na empresa? Dos recursos que o software possui,
qual deles otimiza a gesto de projetos dentro da empresa?
3. Quais so suas sugestes para melhora dos softwares de gesto de projetos?

139

Apndice B - Notao BPMN

Associao

Pool

Lane

Objeto de dados

Uma lane uma subdiviso

dentro de um pool usado para
organizar e categorizar as
atividades.
O objeto de dado um
mecanismo para mostrar como
os dados so requeridos ou
produzidos por atividades. So
conectados s atividades com
as associaes.

Name

Fluxo de seqncia

Name

Atividade

FIGURA

Name

Evento

DESCRIO
Algo que acontece durante um
processo do negcio. Estes
eventos afetam o fluxo do
processo e tm geralmente uma
causa (trigger) ou um impacto
(result). H trs tipos de
eventos, baseados sobre
quando afetam o fluxo: Start,
Intermediate, e End.
Termo genrico para um
trabalho executado. Os tipos de
atividades so: Tarefas e subprocessos. O sub-processo
distinguido por uma pequena
cruz no centro inferior da figura.
Usado para mostrar a ordem
(seqncia) com que as
atividades sero executadas em
um processo
Usada para associar dados,
texto, e outros artefatos com os
objetos de fluxo. As
associaes so usadas para
mostrar as entradas e as sadas
das atividades.
Um pool representa um
participante em um processo.
Ele atua como um container
grfico para dividir um conjunto
de atividades de outros pools,
geralmente no contexto de
situaes de B2B.

Name

OBJETO

SubTotal

Total
0
0
0

S4

S15

S6
1

S7
1

4
0

S2

S10

S12
1

S13
1

3
1

0
2

6
1
0

S1

S5

S11

1
6

S8

S9

10
3
0
0
0

1 . 1 1.21.3 1 . 4 1 . 5 1 . 6 1 . 7 1 . 8 1 . 9 2.1 2.2 2.3 2.4 2.5 2.6 3.1 3.2 3.3 3.4 3.5 4.1 4.2 4.3

5.1

5.2

5.3

6.1

6.2

0
6.3

6.4

7.1

1
1

S3

S14

7.2

1
1

1
1
1

1
1

1
1

13

18
7.3

7.4

3
0
0
0

0
0
0
0

0
0
1

1
0
0

8.1 8.2 8.3 8.4 8.5 8.6 9.1 9.2 9.3 9.4 9.5 9.6

10.1

1
1

1
1

10.2

Registros de acordos de colaborao

Controle de informaes confidenciais e pblicas

9. Aquisies

Controle de contribuio dos colaboradores

Encerramento do contrato

Administrao de contrato

Selecionar fornecedores

Solicitar respostas de fornecedores

8. Riscos

Planejar contrataes

Planejar compras e aquisies

Monitoramento e controle de riscos

Planejamento de respostas a riscos

Anlise quantitativa de riscos

7. Comunicaes

Anlise qualitativa de riscos

Identificao de riscos

Planejamento do gerenciamento de riscos

Gerenciar as partes interessadas

Relatrio de desempenho

Distribuio das informaes

6. Rec. Humanos

Planejamento das comunicaes

Gerenciar a equipe do projeto

Desenvolver a equipe do projeto

Contratar ou mobilizar a equipe do projeto

5. Qualidade

Planejamento de recursos humanos

Realizar o controle da qualidade

Realizar a garantia da qualidade

4. Custo

Planejamento da qualidade

Controle de custos

Oramentao

3. Escopo

Estimativa de custos

Controle do escopo

Verificao do escopo

Criar WBS

2. Tempo

Definio do escopo

Planejamento do escopo

Controle do cronograma

Desenvolvimento do cronograma

Estimativa de durao da atividade

1. Integrao

Estimativa de recursos da atividade

Seqenciamento de atividades

Definio da atividade

Integrao de dados de software

Encerrar o projeto

Controle integrado de mudanas

Monitorar e controlar o trabalho do projeto

Orientar e gerenciar a execuo do projeto

ID

Desenvolver o plano de gerenciamento do projeto

Desenvolver a declarao do escopo preliminar do projeto

Desenvolver o termo de abertura do projeto

140

APNDICE C - Tabela de Classificao das Propostas de Softwares da Literatura

10. Colaborao

10.3

1
1

1
1

APNDICE D Tabela resumo dos requisitos e suas fontes

Fonte
Requisito

Tipo
(RNF/RF)

1.

Permitir registro e controle dos

usurios

RF

2.

Deve apoiar a elaborao da viso

do produto e especulao

RF

3.

Planejar o projeto de forma mais

simples

RF

4.

Acompanhar o andamento do
projeto

RF

5.

Finalizar do projeto

RF

6.

Comunicao e Integrao

7.

A interface deve ser baseada na

web

8.

Uso de ferramentas variadas de

comunicao

9.

Interface homem-computador
simplificada e resumida por meio do
uso intensivo de grficos.

RF

Reviso Bibliogrfica

AeC
Highsmith (2004),
Chin (2004)
Barnes, Pashby e Gibbons (2006),
Hameri e Puittinen (2003)
Highsmith (2004),
Chin (2004)
Maylor (2001)
Barnes, Pashby e Gibbons (2006),
Hameri e Puittinen (2003)
Highsmith (2004)
Chin (2004)

Hameri e Puitinen (2003)

Ren et al. (2006)

RNF

Barnes, Pashby e Gibbons (2006),

Hameri e Puittinen (2003)

Highsmith (2004),
Chin (2004)

Anlise dos Softwares

3 softwares de APM
15 propostas de software incluem
registro e controle dos usurios

A
A, B e D

Hameri e Puittinen (2003)

Huang (2002)

A, B, C e D

Qian e Shensheng (2002)

15 propostas de software encontradas

possuem funcionalidades que
englobam ferramentas de
comunicao
Voltados para a web:

15 propostas de software
encontradas

Barnes, Pashby e Gibbons (2006),

Hameri e Puittinen (2003)

RNF

RNF

Estudo de
Caso

3 softwares de APM
AeC
Softwares da plataforma gil
Propostas de:
Chung e Lee (2002);
Qin et al. (2003);
Tay e Roy (2003);
Li, Fuh e Wong (2004);
Rodriguez e Al-Alshaab (2005)
141

142

Proposta de:

10.

Integrao com funcionalidades de

sistemas de engenharia como CAD

RNF

Qian e Shensheng (2002)

Qin et al. (2003)
Tay e Roy (2003)
Li, Fuh e Wong (2004)

Rodriguez e Al-Alshaab (2005)

11.

12.
13.
14.
15.
16.
17.

Descentralizao dos dados

Rastreabilidade das discusses
sobre as entregas e decises em
gates
Flexibilidade de alterao das
entregas/tarefas para atender s
mudanas do ambiente
Rastreabilidade dos dados
Garantir sigilo dos dados
Controle de verso e fluxo de
documentos
Indicadores de desempenho de
forma grfica e sinttica

RNF

A, B, C e D

RNF

Barnes, Pashby e Gibbons (2006)

Hameri e Puittinen (2003)

RNF

Highsmith (2004)
Chin (2004)
Winter et al. (2006)

Ausncia de propostas que englobem

funcionalidades deste tipo

RNF
RNF

A
A, B, C e D

RNF

BeD

RNF

18.

Controle de multiprojetos

RNF

19.

Menor tempo possvel nas

atividades rotineiras

RNF

Highsmith (2004)
Chin (2004)

A, B e C
AeB

Maylor (2001)
Highsmith (2004)
Chin (2004)

Meja, Lopez e Molina (2007)

Huang e Mak (2002)
Wang, Shen e Ghenniwa (2003)
Li, Fuh e Wong (2004)
Woerner & Woern (2005)

Ausncia de propostas que englobem

funcionalidades deste tipo

143

Anexo

Avaliao de Ferramentas de Gesto de Projetos de Cdigo Aberto

RORIZ, J. H. R.; JUC JUNIOR, A. S.; AMARAL, D. C.
Introduo e Objetivos
As ferramentas de gerenciamento de projetos mais difundidas so sistemas
proprietrios. Elas possuem funcionalidades suficientes para auxiliar a maior parte do ciclo de
vida da gesto de projetos. Porm, a disseminao destes sistemas nas empresas de base
tecnolgica dificultada pelo custo de aquisio de licenas, personalizao, treinamento e
suporte. O foco principal das vendas de tais sistemas ainda so grandes corporaes.
Ns ltimos anos vem sendo desenvolvidas ferramentas de gerenciamento de projetos
que oferecem um menor custo de aquisio, so os chamados softwares de cdigo aberto.
Estes sistemas permitem que seus usurios desenvolvam e personalizem o programa para
melhor atender s suas necessidades. O desenvolvimento destas ferramentas feito por uma
comunidade de colaboradores, ao invs de uma empresa de software, o que em pode propiciar
um menor custo de servio de suporte em relao aos softwares proprietrios. Os problemas
so enviados para estas comunidades e solucionados conforme o engajamento dos seus
membros, geralmente sem custo adicional para o usurio.
Na internet possvel encontrar uma grande quantidade de sites que oferecem
livremente estas ferramentas, com nenhum ou pequeno custo de licenciamento para os
interessados. O problema atual para pesquisadores e profissionais saber se elas realmente
podem trazer benefcios concretos para a gesto de projetos, isto , se possuem
funcionalidades suficientes, com nveis adequados de usabilidade e confiabilidade. No caso
afirmativo, elas seriam uma tima opo para as pequenas e mdias empresas de tecnologia.
Este estudo apresenta um levantamento, anlise e avaliao dos sistemas de cdigo aberto
voltados para a gesto de projetos, apresentando um panorama do estgio de desenvolvimento
sob um enfoque das necessidades da pequena e mdia empresa.
Para esta anlise desenvolveu-se um conjunto especfico de critrios referentes s
funcionalidades de sistemas de gesto de projetos. As fontes de informao utilizadas na
elaborao foram uma reviso da literatura e estudo das funcionalidades das ferramentas de
gesto de projetos mais difundidas no mercado. Durante o progresso da anlise dos softwares,
esses critrios foram tambm sendo continuamente aprimorados, conforme as dificuldades
encontradas na sua aplicao. Os critrios foram agrupados em nove categorias: Arquitetura e
ODBC, calendrio e agenda, gesto de atividades, gesto de recursos, gesto de custos,
ferramentas de monitoramento, gesto de multi-projetos, gesto de documentos relatrio e
impresso e ferramentas de comunicao e integrao.
Este relatrio encontra-se dividido em cinco partes (objetivos, reviso bibliogrfica,
metodologia, resultados, concluso e referncias bibliogrficas). Ao final, demonstra-se um
interessante panorama sobre o estgio atual destas ferramentas. Estes resultados do trabalho
podem ser utilizados tanto por profissionais de gesto de projetos, focados ou no nos
problemas das pequenas empresas de base tecnolgica, como pesquisadores interessados em
conhecer melhor este tipo de ferramenta, isto , seus potenciais e reas que poderiam ser
investigadas para aumentar seu potencial de utilizao.

144

Objetivos
Prope-se nesta pesquisa fazer um levantamento, anlise e seleo de softwares de
cdigo aberto voltados para a Gesto de Projetos. A pesquisa buscou tambm estabelecer o
atual grau de desenvolvimento dos sistemas de cdigo aberto em relao s solues mais
aceitas no mercado.
Reviso Bibliogrfica
Gesto de Projetos
De acordo com o PMI (2000), gesto de projetos e a aplicao de conhecimentos,
habilidades, e tcnicas para projetar atividades que visem atingir os requerimentos do projeto.
Ainda segundo instituto, o gerenciamento do Projeto constitudo de processos tais como:
iniciao, planejamento, execuo, controle e encerramento.

Figura 1: Relaes entre os processos de GP

(adaptado do PMI, 2000)

De acordo com PMI (2000) e HELDMAN (2003):

Os processos de iniciao visam obter o comprometimento da organizao para
o incio do planejamento do projeto. Este processo concede aprovao para
comprometer os recursos da organizao para o projeto ou fase.
Os processos de planejamento buscam programar e manter atividades que
sejam viveis para atingir os objetivos do projeto, envolvendo a programao
do escopo, atividades, oramento e os planos do projeto. Neste grupo de
processos, os requisitos do projeto so especificados, e os stakeholders so
identificados.
A execuo consiste em coordenar pessoas e recursos para executar o plano.
Envolve principalmente a garantia da qualidade, distribuio de informaes,
seleo de fornecedores, e desenvolvimento da equipe. O processo de execuo
acompanha de perto o plano do projeto e assegura que sua prxima execuo
esteja em sincronia com os objetivos desejados.
Os processos de controle visam assegurar que os objetivos do projeto esto
sendo atingidos. Atravs do monitoramento, busca identificar variaes no
plano e fazer sua avaliao, controlando o desempenho do projeto, custos,
qualidade e riscos. Se forem detectados desvios, ser aplicada uma ao
corretiva para sincronizar as atividades ao plano do projeto.

145

Finalmente o encerramento consiste em finalizar os contratos e gerar, reunir e

disseminar informaes para formalizar o trmino da fase ou do projeto. A
documentao pode ser analisada e aproveitada para evitar possveis problemas
em projetos futuros. O contrato acaba aqui, e a aceitao e aprovao formais
so obtidas junto aos stakeholders.

Sistemas de Cdigo Aberto

De acordo com a OSI (2004), as caractersticas da licena de um software para que
este seja considerado do tipo cdigo aberto so:

Redistribuio livre: a licena de distribuio no deve restringir a venda ou cesso

do software por parte de usurios, tambm no deve cobrar direitos de propriedade ou
outras taxas pela venda do programa.

Cdigo fonte: o programa deve incluir o seu cdigo fonte e deve permitir o acesso a
ele, da mesma forma a verso compilada. Quando o produto no for distribudo com o
cdigo fonte, deve haver uma forma claramente anunciada de obt-lo, sem custo, via
Internet.

Trabalhos derivados: a licena deve permitir a realizao de modificaes e de

criao de sistemas derivados, os quais devem ser distribudos sob os mesmos termos
da licena do software original.

No discriminar pessoas ou grupos: a licena no deve discriminar contra nenhuma

pessoa ou grupo de pessoas.

No discriminar campos de interesse: a licena no deve restringir ningum de utilizar o

programa em algum campo de interesse especfico.

Distribuio da Licena: os direitos vinculados ao programa devem aplicar-se a todo aquele

para o qual o programa redistribudo, sem que haja necessidade que as partes levem a efeito
uma licena adicional.

Uma licena no deve ser especfica para determinado produto: os direitos vinculados a
um programa no devem depender do uso de uma distribuio de software especfica. Se o
programa extrado daquela distribuio e usado ou distribudo nos termos da licena do
programa, todas as partes para as quais o programa redistribudo devem ter os mesmos
direitos que so concedidos s pessoas que receberam o software original.

Integridade do cdigo fonte do autor: a licena somente pode restringir a distribuio do

cdigo fonte em forma modificada se ela permitir a distribuio de patches junto com o
cdigo fonte original, com o objetivo de modificar o programa durante a compilao. A
licena deve permitir explicitamente a distribuio de software compilado a partir do cdigo
fonte modificado. A licena pode exigir que trabalhos derivados tenham diferentes nomes ou
diferentes nmeros de verso que o software original.

Uma licena no deve contaminar outro software: a licena no deve impor restries a
outro programa que distribudo junto com o software licenciado. Por exemplo: a licena no
deve insistir que todos os outros programas distribudos no mesmo meio sejam de cdigo
aberto.

A licena deve ser tecnologicamente neutra: a licena no deve exigir que o programa
utilize uma tecnologia especifica nem ao menos um estilo de interface.

Estas caractersticas da licena do liberdade ao usurio de usufruir o mximo do

sistema, sem precisar pagar aos proprietrios dos direitos autorais pela sua instalao e uso.

146

Portanto, a diminuio do custo de licena provavelmente o primeiro argumento a favor dos

sistemas de cdigo aberto. O custo de licena nulo, havendo necessidade de investir
somente em horas de mo de obra para compreender o sistema e faz-lo funcionar.
Outra vantagem que o suporte tcnico e o aprimoramento destes sistemas podem ser
solicitados junto ao frum na internet utilizado pela comunidade de desenvolvimento da
ferramenta. Em tese, como ter acesso equipe de desenvolvimento para solucionar os
problemas sem a necessidade de pagar pelo servio. Como o cdigo pode ser consultado e a
documentao do sistema entregue tambm ao usurio, outra sada realizar estas
atividades com a equipe de desenvolvimento de sistemas da prpria empresa usuria do
software. Em ambos os casos, o custo de personalizao do sistema s necessidades
especficas e de suporte tcnico seriam extremamente baixos se comparado com ferramentas
proprietrias.
Outra vantagem destes sistemas, apontada pelos seus defensores, o tempo de
resposta na correo de bugs. A comunidade de cdigo aberto adota uma prtica chamada
full discosure na correo destes problemas. Os softwares de cdigo aberto geralmente
possuem ou so integrados com sistemas de Bug tracking, que rastreiam estes defeitos, e
quando encontrados so publicados. Os bugs so submetidos reviso pblica, o que facilita
suas solues e possibilita que haja, em um dado momento, vrias equipes de
desenvolvedores trabalhando em partes distintas do sistema.
Entre as desvantagens deste sistema encontra-se a falta de garantias de suporte tcnico,
a falta de segurana em termos de investimento na atualizao e melhorias do sistema e
tambm a inexistncia de programas de treinamento e certificao de profissionais que
garantam a disponibilidade de mo-de-obra qualificada na manuteno do servio.
Um dos maiores problemas enfrentados pelos sistemas de cdigo aberto sua
usabilidade. Estes softwares geralmente so elaborados, diferentemente dos sistemas
proprietrios, sem a participao do usurio final. De acordo com NICHOLS & TWIDALE
(2002), a principal diferena dos dois tipos de ferramentas que o desenvolvimento de
softwares comerciais reconheceu estes problemas de usabilidade, e puderam empregar
esforos em melhoria deste em favor do usurio final. J os desenvolvedores de softwares de
cdigo aberto geralmente no possuem recursos para levantar as necessidades do usurio final
ou aplic-las em seu favor.
Softwares de Gerenciamento de Projetos
De acordo com o PMBOK (2000), o gerenciamento de projetos a aplicao de
conhecimentos, habilidades, e tcnicas que auxiliam a equipe atingir os requerimentos
exigidos no projeto. Este gerenciamento composto de conjuntos de atividades, conhecidos
como processos da gesto de projetos, envolvendo a programao do escopo, atividades,
oramento e os planos do projeto. Estes processos foram classificados em cinco tipos:
iniciao, planejamento, execuo, controle e encerramento. De acordo com PMBOK (2000)
e HELDMAN (2003). As prticas desses processos esto relacionadas com nove reas de
conhecimento: gerncia de integrao, de escopo, de tempo, de custo, da qualidade, dos
recursos humanos, da comunicao, do risco e de aquisio.
O gerenciamento dessas reas e dos processos so facilitados pelo uso de ferramentas
computacionais conhecidas como os softwares de gesto de projetos. Estes sistemas
automatizam os clculos de anlises matemticas, nivelamento dos recursos e
conseqentemente, permitem uma rpida avaliao sobre diversas alternativas para o
cronograma. Elas aumentam a capacidade humana de monitorar as datas planejadas e
compar-las com as datas reais, facilitando assim a previso de efeitos de mudanas das
atividades do projeto. Em ambientes de multi-projetos ou projetos mais complexos estas

147

ferramentas podem oferecer simulaes que envolvem clculos de diferentes duraes de

projeto ou anlise de diferentes cenrios (anlise what-if), como por exemplo, avaliar como o
atraso ou adiantamento de determinadas atividades em um projeto pode afetar o cronograma
de outros projetos que compartilham os mesmos recursos. Estas anlises entre outras seriam
bastante dificultadas sem o uso destes softwares (PMBOK 2000).
O crescimento do emprego de tcnicas para gerenciamento de projetos deve muito
disponibilidade de softwares. Muitas delas exigem a manipulao de grande quantidade de
dados, que no passado era realizada apenas pelas empresas que operavam com projetos de
propores e complexidade suficientes para tornar justificvel a existncia de uma equipe de
apoio, com engenheiros, estatsticos e matemticos, dedicados exclusivamente ao trabalho de
gerenciamento. Com o auxlio dos sistemas, mesmo empresas de menor porte podem de
maneira prtica ter acesso a estas tcnicas. No entanto, no se deve esperar que o computador
substitua o tradicional processo decisrio. Na gesto de projetos o computador ainda
utilizado principalmente como uma ferramenta de apoio, facilitando a manipulao dos dados
para o emprego tcnicas e mtodos disponveis na rea. Sua principal vantagem a
velocidade de processamento de anlises quantitativas, necessrias a uma grande variedade de
processos (BADIRU, 1996). O emprego de tcnicas computacionais mais sofisticadas como a
inteligncia artificial ainda est distante das prticas dos sistemas comerciais.
O mesmo autor define seis etapas para o processo evolucionrio dos softwares de GP.
Da primeira gerao (antes da segunda guerra mundial), passando pelos sistemas dedicados
PERT/CPM, e chegando a gerao atual, com novos conceitos em inteligncia artificial e
comunicao online aliados aos conceitos passados, unindo as geraes passadas com
projetos grficos, gerao de relatrios, planilhas e anlises de custo. Sua crescente
popularidade, aceitao, e uso so evidenciados pelo grande nmero de programas comerciais
que recentemente foram introduzidos no mercado.
BADIRU (1996) considera vrios fatores importantes que devem ser levados em conta
na seleo de softwares de GP, sendo eles: custo, necessidade, planejamento do projeto,
gerenciamento de recursos, rastreamento do progresso do projeto, gerao de relatrios,
facilidade de uso, suporte de ferramentas para diferentes analises e requerimentos de
hardware.
Mtodo de Pesquisa
A abordagem metodolgica deste trabalho pode ser classificada como uma pesquisa
descritiva que, segundo ROESCH (1999), tem um carter de levantamento de informaes
sobre uma populao, caracterstico de uma pesquisa voltada a algum diagnstico, por
exemplo. Exemplos desta abordagem so censos, levantamentos de opinio pblica ou
pesquisas de mercado que procuram fatos descritivos.
A populao-alvo do estudo so as ferramentas de cdigo aberto, voltadas para o
gerenciamento de projetos e a prtica de testes como tcnica de coleta de dados. A coleta de
dados baseada em testes tem o objetivo de comparar o comportamento da amostra analisada
com um conjunto pr-definido de respostas. Neste caso, as possveis respostas so as
funcionalidades e caractersticas dos sistemas de gesto de projetos. Pretende-se verificar as
caractersticas e funcionalidades da populao, isto , os sistemas de software-aberto para
gesto de projetos, comparando-a com as caractersticas e funcionalidades dos sistemas
proprietrios existentes.
Etapas da Pesquisa

148

O trabalho foi divido em seis etapas diferentes para facilitar sua execuo:

Reviso bibliogrfica: foi realizada uma reviso bibliogrfica sobre os assuntos gesto de
projetos, softwares de gesto de projetos e sistemas de cdigo aberto. Na literatura sobre
gesto de projetos deu-se especial ateno s caractersticas e funcionalidades dos sistemas
existentes;

Anlise das ferramentas comerciais: as ferramentas MS-Project 2002 e PMOffice 2000

foram analisadas objetivando a elaborao dos critrios de anlise. A primeira delas foi
analisada a partir de uma verso completa instalada no laboratrio do grupo de pesquisa. O
sistema Project Professional 2002 foi instalado no laboratrio, enquanto a segunda ferramenta
foi avaliada com base na documentao disponvel pela empresa.

Criao dos critrios de anlise: com base nos resultados do item anterior e na reviso
bibliogrfica foram elaborados os critrios de anlise para sistemas de GP;

Levantamento de ferramentas de cdigo aberto para gerenciamento de projetos: foi

realizado um levantamento dos sistemas de GP de cdigo aberto procurando-se identificar
inicialmente uma lista dos sistemas existentes. Esta lista foi filtrada de acordo com seu grau de
popularidade, avaliado por meio de pedidos de indicaes de nomes de sistemas em listas de
discusso sobre sistemas de cdigo aberto e para especialistas em gesto de projetos. As
ferramentas indicadas foram instaladas e avaliadas em detalhe. Somente as mais promissoras
foram submetidas anlise.

Anlise dos softwares: nesta etapa foi realizada a anlise das ferramentas de gesto de
projetos de cdigo aberto com base nos critrios elaborados na etapa anterior;

Refino dos critrios com as ferramentas de cdigo aberto: iniciada a anlise das
ferramentas de cdigo aberto, os critrios de anlise foram sendo modificados conforme
surgiam dvidas ou problemas na sua aplicao, como, por exemplo, caractersticas que no
tinham sido observadas durante a proposio da lista inicial de critrios. Esta fase da pesquisa
se estendeu durante todo o perodo de analise dos softwares de cdigo aberto;

149

Figura 2: Etapas da Pesquisa

Resultados
5.1 Levantamento de sistemas
Foram cadastrados 25 sistemas de cdigo aberto de gerenciamento de projetos. Estes
sistemas foram localizados de acordo com indicaes em listas de discusses e sites de buscas
especializados em softwares de cdigo aberto. Os sites mais utilizados foram:
http://freshmeat.net/ e http://sourceforge.net/. A lista destes sistemas se encontra no apndice
A.
5.2 Definio de critrios
A elaborao de critrios para anlise dos softwares de gerenciamento de projetos foi
feita atravs da reviso bibliogrfica. As principais fontes foram VARGAS (2002),
GOLDRATT (1998) e GRC (2002), as quais descrevem, cada uma a sua maneira, as
caractersticas que estes sistemas devem possuir para dar apoio ao gerenciamento de projetos.
Foi realizado tambm um estudo de dois dos sistemas mais difundidos no mercado, MsProject
Professional 2002 e PMOffice 2000, respectivamente por meio de testes e documentao e
verso demonstrao, conforme descrito no item 4.1.
Cada critrio foi avaliado por uma escala de zero a cinco. A nota zero definida
quando o sistema no possui a funcionalidade em anlise. A nota cinco foi atribuda quando o
sistema possui todas caractersticas identificadas durante a elaborao dos critrios. As
demais notas so definidas quando o sistema possui caractersticas intermediarias. Como
exemplo, apresenta-se na Tabela 1 a escala para o critrio Visualizar e formatar grfico
GANTT.
Tabela 1: Exemplo de critrio de anlise

150

2.2

Visualizar e formatar
grfico GANTT

Formatar escala de tempo dia/ms/semana/ano e formato

das barras.
Determinar caminho crtico, mostrar dependncia entre
tarefas, mostrar recursos.

Determinar dependncia entre tarefas, mostrar caminho

critico.
Formatar escala de tempo dia/ms/semana/ano e formato
das barras.

Mostra apenas durao das tarefas

Funcionalidade inexistente

Cada critrio bem especfico e possui uma escala especialmente desenvolvida e

fechada. Durante a avaliao, comentrios sobre cada classificao foram registradas junto
ao valor atribudo. Por exemplo, no caso da Tabela 1, caso fosse atribuda a nota 3 pedia-se ao
avaliador para indicar quais formatos de barra o software permite: alterao de cor e
preenchimento ou apenas um deles.
Ao final, foram obtidos 58 critrios. Para facilitar a anlise das ferramentas estes
critrios foram divididos em nove categorias:
A categoria Arquitetura contm seis critrios: Integrao com banco de dados,
mltiplos usurios / permisses, formas de acesso, plataforma, linguagem de programao e
softwares necessrios para instalao. Estes critrios buscam avaliar uma possvel integrao
do software em anlise com outros sistemas, facilidade de alterar o cdigo e manipular a base
de dados.
A categoria calendrio e agenda contm os critrios que avaliaram a capacidade do
sistema em proporcionar a organizao a programar calendrios para o projeto, recursos ou
tarefas. A programao do calendrio envolve definir o perodo de trabalho dirio, dias de
trabalho por semana e eventuais feriados. Foi avaliado tambm se alm do sistema permitir a
escolha de calendrios base, permitia personaliz-los. O nmero de vises de agenda (do
projeto, recurso ou da tarefa), foi avaliado juntamente com a possibilidade de personalizar em
vises em escala de tempo, ou filtr-las de acordo com determinados parmetros.
A categoria gesto de atividades contm oito critrios: visualizar e formatar grfico
PERT, visualizar e formatar grfico GANTT, gerao de WBS (work breakdown struture),
configurar tarefas, visualizao das tarefas envolvendo todos projetos, visualizao das tarefas
de determinado projeto, visualizao das tarefas de determinado recurso e mtodo de
determinao de durao das tarefas. Os dois primeiros critrios avaliaram o nvel de
personalizao que o software permitiu e nos grficos PERT e GANTT, alm das capacidades
de determinar e destacar o caminho crtico do projeto e de permitir a definio dependncia
entre tarefas. Esta categoria avaliou tambm o nvel permitido de configurao das tarefas
como, por exemplo: definir restries de agendamento, anexar documentos ou alocar
recursos. A capacidade de gerar diferentes vises para as tarefas, ou por projeto recurso, e
ainda personalizar e filtrar estas vises foi tambm analisada trs critrios de visualizao.
Ainda nessa categoria, foi avaliado como a ferramenta determina a durao das tarefas, se
simplesmente por definio do usurio ou se possui mtodos mais avanados como tringulo
de Simpson ou estimativa devido ao esforo.
A categoria gesto de recursos encontra-se dividida em duas reas: o gerenciamento
de recursos usurios e os no-usurios. Em ambas as reas os critrios avaliaram a capacidade
da ferramenta em realizar funes como: nivelamento de recursos, visualizar a
disponibilidade dos recursos, gerenciar times de recursos e permitir diferentes padres de
alocao nas atividades.

151

A gesto de custos avaliou como o software efetua o clculo para o pagamento dos
recursos, clculo do custo das atividades e do projeto. A avaliao desses critrios foi feita
com base na capacidade do sistema em realizar estes clculos automaticamente ou se estes
custos so apenas inseridos pelo usurio.
A categoria gesto de documentos, relatrios e impresso avaliou se o sistema
permite a gerao de relatrios predefinidos e ainda personaliz-los, se possuem
funcionalidades de auxilio ao gerenciamento de documentos como controle de verso e
autoria ou poder import-los e export-los para outros formatos. Ainda avaliou se o software
gera vises em formato de impresso para determinados dados ou grficos.
A categoria ferramentas de monitoramento avaliou as funcionalidades do sistema
em proporcionar a equipe de projeto ferramentas de anlise do valor agregado, visualizar as
porcentagens completas das atividades e linhas de andamento e possibilitar a gravao de
linhas de base (baseline).
No gerenciamento de mltiplos projetos, os critrios avaliaram se a ferramenta
permite realizar anlise do portfolio da empresa, compartilhar e nivelar recursos entre
diferentes projetos e a possibilidade de definir dependncia entre tarefas nos diferentes
projetos. Os critrios avaliaram tambm a capacidade do software em agrupar vrios projetos
em um projeto mestre e realizar alteraes nestes projetos que reflitam nos projetos originais.
A categoria ferramentas de comunicao e integrao avaliou a capacidade do
sistema em importar e exportar dados em outros formatos, realizar notificaes por e-mail e
possuir fruns de discusses interno e na internet (para suporte de instalao e utilizao).
Tambm foi avaliada a integrao deste sistema com bancos de dados, e quais softwares
adicionais so necessrios para sua instalao.
5.3 Avaliao das ferramentas
A pesquisa inicial, realizada a partir de mecanismos de buscas e sites especficos da
rea, identificou 25 softwares livres para gesto de projetos, listados no Apndice A. Uma
anlise preliminar e descritiva destes sistemas revelou que grande parte se tratava de sistemas
com srias limitaes, seja porque se tratavam de componentes, pequenos softwares muito
especializados ou sistemas com graves limitaes em termos de funcionalidade. Decidiu-se
realizar uma anlise preliminar desses sistemas procurando identificar as melhores solues.
Alm da anlise pelo pesquisador, foram enviadas perguntas para listas de discusses de
especialistas
em
gerenciamento
de
projetos,
como
l10n_project_management@yahoogroups.com,
pm-software@yahoogroups.com,
CriticalChain@yahoogroups.com,
PMI-SP@yahoogrupos.com.br,
pmisp_FerramentasGP@yahoogrupos.com.br, onde solicitou-se indicaes de ferramentas de
cdigo-aberto.
Este esforo foi fundamental para evitar o teste de solues pouco significativas. Isto
porque a anlise de cada uma delas foi realizada a partir de testes com a ferramenta instalada,
num alto nvel de rigor. Em mdia eram trs semanas para testar cada ferramenta, incluindo
instalao, aprendizado e testes prticos para identificar o nvel correto em cada critrio.
Portanto, seria invivel realizar a anlise dos 25 sistemas identificados.
Ao final desta anlise obteve-se uma lista com as seis ferramentas consideradas mais
completas, ou seja, com o maior conjunto de funcionalidades, estes sistemas foram instalados
e observados em detalhe. A Tabela 2 abaixo mostra os seis softwares analisados:
Tabela 2: softwares analisados

152

Sistemas avaliados

Tipo de Licena

Link

TUTOS

GPL

http://www.tutos.org/homepage/

PHProjekt

GPL

http://www.phprojekt.com

Phpcollab

GPL

http://www.php-collab.com/

DotProject
Open Work Bench
Planner

BSD
Mozilla Public License 1.1 (MPL 1.1)
General Public License (GPL)

http://www.dotproject.net/
http://www.openworkbench.org/
http://www.imendio.com/projects/planner/

De acordo com os pesos associados a cada categoria e as notas segundo cada critrio,
obteve-se uma avaliao geral dos sistemas, apresentada de forma na Tabela 3, em
porcentagem. As avaliaes completas de cada software e o resumo completo de todos os
critrios podem ser consultadas respectivamente nos apndices C e B.
Tabela 3: Avaliao dos softwares.

A anlise demonstra que a ferramenta Open WorkBench a que possui caractersticas

mais prximas aos sistemas proprietrios mais difundidos no mercado. Porm, considerando a
nota mxima de valor 5, percebe-se que mesmo este sistema, considerado o melhor, se
encontra em um nvel de sofisticao bem menor em relao aos dois softwares proprietrios
utilizados na elaborao dos critrios (Microsoft Project Professional 2002 e PMOffice 2000).
Em geral, as deficincias se mostram mais acentuadas nas categorias: gesto de
mltiplos projetos e calendrio e agenda. Outro aspecto notado so as deficincias gerais,
indicando possivelmente funcionalidades de difcil implementao. Apenas o software Open
WorkBench apresentou funcionalidades como: gerao de grfico PERT, nivelamento de
recursos e contabilizao dos ndices de anlise de valor agregado. Vale ressaltar que nenhum
dos sistemas analisados apresentou ferramentas para anlise de portfolio.
A partir da tabela 3 possvel observar que os sistemas de ambiente web (TUTOS,
Phprojekt, Phpcollab e Dotproject) apresentam caractersticas semelhantes entre si e distintas
dos outros dois softwares (Planner e Open WorkBench) que so desktop based.
No primeiro grupo de sistemas percebe-se que o maior desempenho foi no item
ferramentas de comunicao e integrao. O fato de ambiente web permitiu que elas
apresentassem funcionalidades como fruns de discusses, chats e assistentes de notificaes
por e-mail, o que favoreceu a pontuao nesta categoria.

153

O segundo grupo apresenta maior desempenho nos itens calendrio e agenda e gesto
de atividades. Estas ferramentas possuem maior facilidade em construir e formatar grficos
Gantt, programar calendrios e definir restries e dependncia para as atividades.
Concluses
Este trabalho demonstra que as ferramentas para gesto de projetos de cdigo aberto
disponveis ainda no se encontram no mesmo nvel de sofisticao das ferramentas mais
utilizadas no mercado. Todas ferramentas analisadas apresentam srias deficincias em
algumas funcionalidades se comparadas s ferramentas que foram utilizadas para elaborar os
critrios.
Por outro lado, acredita-se que, com um pequeno esforo no desenvolvimento das
ferramentas existentes ou com integraes entre elas, seria possvel obter uma soluo vivel,
de tima qualidade e de baixo custo em comparao com as ferramentas proprietrias.
Um fato positivo notado a possibilidade de integrao destas ferramentas visando a
obteno de uma soluo mais completa e sofisticada, unindo as vantagens e desvantagens de
cada uma delas. Um exemplo seria a integrao da ferramenta Open WorkBench com o
TUTOS ou Phprojekt. Estas duas ferramentas possuem caractersticas complementares, sendo
que a primeira se destaca no gerenciamento de atividades, calendrio e agenda e ferramentas
de monitoramento e as outras ferramentas possuem funcionalidades mais desenvolvidas na
categoria comunicao e integrao e Arquitetura.
A aplicao dos critrios demonstrou que eles foram suficientes para avaliar os
softwares de apoio ao gerenciamento de projetos de cdigo-aberto em profundidade, devendo
ser utilizados em possveis continuaes deste trabalho.
Referncia Bibliogrfica
ANAVI-ISAKOW, S. & GOLANI, B.; Managing mult-iproject enviroments through constant work-in-process.
International Journal of Project Management, 21, pp 9-18. Elsevier Science Ltd., 2003;
BADIRU, A.B. Project management in manufacturing and high technology operations. Nova York: John Wiley
& Sons Inc, 2 ed., 1996.
COOKE-DAVIES, T.; The real success factors on projects. International Journal of Project Management, 20,
pp 185-190. Elsevier Science Ltd., 2002.
GIL, A.C. (2001). Como elaborar projetos de pesquisa. 3. ed. Atlas, So Paulo.
GODRATT, E. M. Corrente Crtica. So Paulo: Nobel. 1998;
HELDMAN, K. Gerncia de Projetos, 2 ed., Editora Campus, RJ, 2003.
HORTA, L. Estudo do processo de Alterao de Engenharia. Exemplar de Qualificao (Mestrado), Escola de
Engenharia de So Carlos-USP, 2001.
JACOB, D.B & McCLELLAND, W.T. (2001); Theory of Constraints Project Management: A Brief Introduction
into the Basics. Goldratt Institute. Disponvel em: <http://www.goldratt.com/tocpmwhitepaper.pdf>. Acesso em
27 Jan. 2004.
KELLER, D. (2002). Software Livre na Infra-estrutura de Tecnologia da Informao da Pequena e Mdia
Empresa. Disponvel em: http://softwarelivre.foz.unioeste.br/arquivos/docs_gerais/TCDouglasKellermann.pdf.
Acessado em 9 de fevereiro de 2004.

154

KERZNER, H. Project Management, Editora Van Nostrand Reinhold Company Inc., NY, 1998.
Open Source Initiation. (2004). The Open Source Definition, verso 1.9. Disponvel no site:
http://www.opensource.org/docs/definition.php. Acessado em 26 de Janeiro de 2004.
PDUA, E.M.M. (1996). Metodologia de pesquisa: abordagem terico-prtica. Campinas, SP, Papirus.
PATRICK, F.S.P. (1999). Critical Chain Sceduling and Buffer Management: Getting Out From Between
Parkinsons
Rock
and
Murphys
Hard
Place.
Focused
Performance.
Disponvel
em
<http://www.focusedperformance.com/articles/CCBM_PM.pdf.>. Acesso em Jan 10. 2004.
PMBOK. (2000) A Guide to the Project Management Body of Knowledge (PMBOK ed. 2000), Project
Management Institute Inc., Pennsylvania, USA,.
RAND, G. K.; (2000) Critical chain: the theory of constraints applied to project management. International
Journal of Project Management, 18, pp 173-177. Elsevier Science Ltd.
ROMANO, L.N.; BACK, N.; SCALICE, R.K.; (2000). A importncia do Processo de Planejamento na Gesto
de Desenvolvimento de Produtos. 2 Congresso Brasileiro de Gesto de Desenvolvimento de Produto. So
Carlos,.
RUSHINEK, A. & RUSHINEK, S.; (1991). A product evaluation and selection system for project management
software. Computers in industry, 16, pp 289-301. Elsevier Science Ltd.
Machado, S. A.; FILHO, J. P.; CARVALHO, M. M.; JUNIOR, R. R.; MPEs de Base Tecnolgica:
conceituao, formas de financiamento e anlise de casos brasileiros. Disponvel no site:
http://www.sebraesp.com.br/pesquisa/download/Embatec2.DOC. Acessado em 1 de agosto de 2003.
VALADARES, A., FLEXA, R. E PAIM, R., (2003). Gesto de projetos e Corrente Crtica: Anlise
Comparativa das Ferramentas de Suporte Metodologia. VI SIMPOI - Simpsio de Administrao da
Produo, Logstica e Operaes Internacionais, So Paulo.
VALERIANO, D.L., Gerncia em Projetos, Makron Books, So Paulo, 1998.