Gerencia de Projetos de Software (Ieditora)

João Alberto Arantes do Amaral
GERÊNCIA DE PROJETOS
DE SOFTWARE
GERÊNCIA DE PROJETOS DE SOFTWARE
ditora
i ditora
i
Gerência de Projetos
de Software
Todos os direitos desta edição reservados ao autor.
Publicado por Editco Comercial Ltda.

Rua Pedroso Alvarenga, 1046, 9º andar – sala 95
Itaim – 04531-004 – São Paulo-SP
Tel: (11) 3706-1492 – Fax: (11) 3071-2567
e-mail: info@ieditora.com.br
Gerência de Projetos
de Software
São Paulo – 2002

©2002 AMARAL, João Alberto Arantes do
1ª edição, São Paulo: 2002.
Revisão:
Elina Correa Miotto
Editoração:
Jean Carlos Barbaro
Capa:
Jean Carlos Barbaro
ISBN 85-87916-42-4
É PROIBIDA A REPRODUÇÃO
Nenhuma parte desta obra poderá ser reproduzida, copiada, transcrita ou mesmo transmitida
por meios eletrônicos ou gravações, assim como traduzida, sem a permissão, por escrito, do
autor. Os infratores serão punidos pela Lei nº 9.610/98.
Impresso no Brasil / Printed in Brazil
Dedicatória
À memória de minha mãe, Neyde Curvo do

Amaral
Agradecimentos
Como não podia deixar de ser, vou fazer um

breve agradecimento às pessoas especiais que me
ajudaram direta ou indiretamente na criação
deste livro.
Em especial gostaria de agradecer à minha ami-
ga, a Prof. Dr. Joyce Warmkessel, do departamento
de Aeronáutica e Astronáutica do MIT, pelo apoio
e orientação que me deu no período em que esti-
ve nos EUA. À Helena e Renato Pakter, Patrícia
e Elizabeth Sikar pelos passeios de bicicleta e de
trem pela Nova Inglaterra, passeios que serviram
de inspiração para as estórias que vocês irão ler
em breve. Agradeço também a meu pai, José Ro-
berto e aos meus amigos Nelson e Fabienne Mon-
nerat, Erica, Frederico Sauer, Márcia Anjos,
Maurício Kiwielewickz , Paulo e Luisinha Atkin-
son pelas sugestões e por terem me ajudado ao
longo de todos esses anos, em especial no período
em que estive no MIT. Gostaria de agradecer tam-
bém ao Prof. Peña-Mora e aos 32 estudantes do
Projeto IeCollab.
Índice
Introdução
CAPÍTULO I Preparação para o Projeto
Estudo de Caso 01 “O caminho que leva ao
inferno é pavimentado de boas intenções” 17
Tópicos para discussão ............................... 37
Referências ................................................. 38
CAPÍTULO II Planejamento do Projeto
Estudo de Caso 02 “Não há ventos favorá-
veis para aqueles que não sabem aonde ir” 43
Referências ................................................. 63
CAPÍTULO III Execução do Projeto
Estudo de Caso 03 “Os sete pecados capitais
do projeto” ............................................ 67
Referências ................................................. 85
CAPÍTULO IV Adaptação do Projeto
Estudo de Caso 04 “Perseverar é tornar o
impossível possível” ............................... 89
Referências ................................................. 107
Conclusão .................................................. 109
Introdução
Sobre o que é este livro

Este livro é sobre gerência de um tipo especial
de projeto, projeto de software. Eu procurei
descrever as atividades principais envolvidas
no gerenciamento de projetos de software de
uma maneira bem informal. A idéia é dar uma
visão geral das fases pelas quais um projeto de
software passa, desde o seu nascimento até a
sua finalização. De um modo geral, livros so-
bre gerência de projetos são muito maçantes,
incrivelmente longos, caros, cheios de termos
técnicos, definições cansativas e metodologias
soníferas. Procurei evitar tudo isso; tentei es-
crever um livro divertido que retratasse de uma
maneira bem informal as preocupações do dia-
a-dia de um gerente de projetos de software.
Este livro é na verdade a compilação de qua-
tro estórias, uma sobre preparação, outra so-
bre planejamento, a terceira sobre execução e
a última sobre adaptação do projeto. Estas
estórias são vividas por três personagens. En-
quanto eles curtem o verão na região da Nova
Inglaterra, EUA, eles discutem as aventuras e
desventuras de Manopoulos, um gerente de
projeto de software
11
Gerência de Projetos de Software
malsucedido. Espero que você se divirta acompanhando

os nossos intrépidos heróis em seus passeios pela Nova
Inglaterra e aprenda um pouco sobre as atividades prin-
cipais envolvidas na gerência de projetos de software.
Divirta-se!
A quem se destina este livro

Este livro se destina a gerentes de projetos de software,
analistas de sistemas, estudantes de MBA e a alunos de
cursos de pós-graduação e graduação em áreas relaciona-
das à tecnologia da informação e gerência de sistemas de
informação. Caso você tenha conhecimentos básicos de
engenharia de software, ou já tenha trabalhado em desen-
volvimento de sistemas você terá facilidade de entender os
conceitos expostos. Caso você não tenha muita vivência
na área, provavelmente terá um pouco mais de dificulda-
de, mas ainda assim conseguirá entender os principais con-
ceitos envolvidos.
Porque eu escrevi este livro

A estória da criação deste livro é de certa forma curiosa.
Durante o período em que estive no MIT (Massachusetts
Institute of Technology-EUA) tive a oportunidade de tra-
balhar como gerente de projeto de desenvolvimento de
um ASP (application service provider), em um projeto
acadêmico chamado IeCollab (Intelligent electronic Co-
llaboration), conduzido pelo Prof. Feniosky Peña-Mora,
do grupo de tecnologia da informação do Departamento
de Engenharia Civil e Ambiental do MIT. Este projeto
envolveu 32 estudantes e professores de 03 universidades,
12
MIT nos Estados Unidos, CICESE (Centro de Investiga-

ción Científica y de Educación Superior de Ensenada) no
México e PUC (Pontificia Universidad Católica) no Chile.
Foi uma experiência única, muito interessante, o objetivo
deste projeto era fazer com que os estudantes se familiari-
zassem com as responsabilidades dos diversos times de de-
senvolvimento, bem como tomassem conhecimento das
peculiaridades envolvidas no desenvolvimento de um sis-
tema por equipes situadas em países diferentes. Após a
conclusão deste curso tive a oportunidade de trabalhar
como Assistente de Pesquisa (Research Assistant) e poste-
riormente como Assistente do Professor (Teacher Assis-
tant) no Programa de Gerenciamento e Projeto de Siste-
mas (Systems Design and Management Program) do MIT,
com a professora Dr. Joyce Warmkessel. Na ocasião ela
me pediu que escrevesse alguns estudos de casos que pu-
dessem ser usados pelos estudantes de pós-graduação no
curso de Gerência de Projetos que seria oferecido no pró-
ximo semestre. Escrevi os casos tendo por base dados do
projeto IeCollab. Para não melindrar ninguém transfor-
mei o projeto IeCollab em PATOLAB e criei uma série de
situações que permitissem narrar o que aconteceu ao lon-
go do projeto. Estas estórias foram escritas no verão, nor-
malmente à noite e de madrugada. Confesso que de dia às
vezes conseguia escapulir de minhas obrigações, pegar a
minha bicicleta e sair com os meus amigos pedalando pe-
las cidades próximas. Outras vezes eu saía para velejar pelo
rio Charles ou mesmo caminhar pelas colinas de Blue Hills.
Os estudos de caso refletem esse período divertido e atri-
bulado. De noite eu escrevia sobre coisas que havia feito
13
durante o dia, misturando ficção com realidade. Muitas

das situações relatadas nos estudos de caso realmente acon-
teceram. Outras são pura fantasia. Enfim, foi divertido
escrever os textos, mas confesso que escrever em inglês foi
bem trabalhoso, agradeço à Prof. Joyce pela paciência in-
finita de ler os casos e tornar o texto mais digerível ao
paladar americano. Enfim, os casos foram criados e usa-
dos no curso do MIT.
Voltei ao Brasil e me esqueci dos estudos de caso por
uns seis meses. Meio que por acaso recebi um convite e
comecei a lecionar gerência de projetos de software à noite
em cursos de pós-graduação. Resolvi então traduzir um a
um os estudos de casos e modificá-los de modo a usá-los
nas aulas. Para a minha surpresa, os estudos de caso tive-
ram uma aceitação muito boa, e vários alunos me cobra-
ram que eu publicasse um livro sobre o assunto. Poster-
guei o quanto pude, dei infinitas desculpas mas no final
não teve jeito: tive de escrever o livro! Pois bem, a culpa é
deles. Aqui está o livro, espero que você se divirta tanto
em lê-lo como eu me diverti em escrevê-lo.
14
CAPÍTULO I PREPARAÇÃO
PARA O PROJETO
15
Estudo de Caso 01
“O caminho que leva ao inferno é
pavimentado de boas intenções”
“O tempo gasto na reflexão é na

verdade uma economia de tempo”
Publius, 1 A.C.
É verão em Boston. Meu nome é Nel-

son; eu estou conversando com Manopoulos, o
gerente de um projeto malsucedido. Ele está can-
sado e estressado. Ele trabalhou duro durante
muitos meses em PATOLAB, um projeto de
software distribuído e colaborativo que envol-
veu times localizados em três países diferentes.
Este projeto teve vários problemas, como a de-
terioração do esforço de desenvolvimento, atra-
sos e custos acima do orçamento. O projeto
nunca atingiu seus objetivos. O time do projeto
não foi capaz de integrar todos os componentes
de software em um produto final. Eu estou ten-
tando entender porque o projeto dele falhou
apesar do grande esforço da equipe de desenvol-
vimento. Estou procurando trazer à tona os seus
modelos mentais de modo a entender as causas
do fracasso. Comecei perguntando a Manopou-
los sobre o que era o seu projeto.
17
“Meu projeto tinha por objetivo a criação de um apli-

cativo colaborativo para ambiente WEB. Em resumo,
eu poderia dizer que visávamos criar um tipo especial de
software cliente-servidor que permitisse compartilhamento
de documentos e comunicação. Nós pretendíamos cobrar
por prover este tipo de serviço.” – respondeu Manopoulos.
“Parece que você iria construir um tipo de Application
Service Provider (ASP), é isso mesmo?” – eu perguntei.
“Exatamente. O projeto envolveu times localizados nos
EUA, Chile e México. Era um projeto de curto prazo que
começou em novembro de 1999 e terminou em abril de
2000. O time, composto por 32 desenvolvedores, estava geo-
graficamente disperso: cinco no Chile, cinco do México e 22
nos EUA.” – Manopoulos respondeu.
“Como você poderia descrever as fases de projeto?”
– eu perguntei.
“Nelson, está claro para mim que o projeto teve fases
distintas: preparação, planejamento e execução. Claro que
o projeto também sofria modificações baseadas nos resulta-
dos da execução. Talvez eu possa chamar isto adaptação do
projeto. É mais fácil se eu fizer um desenho para explicar.”
Este é o desenho que Manopoulos me mostrou (Ama-
ral, 2000):
Figura 1
18
“O.k., vamos falar um pouco sobre os pontos princi-

pais envolvidos na preparação do projeto” – eu disse. “Qual
foi a estrutura de times que vocês adotaram para o projeto
PATOLAB e quão motivados vocês estavam no início de
projeto?”
Manopoulos respondeu: “No começo do projeto nós
estávamos muito entusiasmados e confiantes. Nossa estru-
tura de time era bastante boa, nós tínhamos 10 equipes
trabalhando simultaneamente”. Ele me mostrou a seguin-
te figura que representa a estrutura dos times.
Figura 2
Ele continuou a explicação: “Todos os membros dos

times tinham alguma formação em tecnologia da infor-
mação ou informática de um modo geral. A maioria de
nós era generalista, tínhamos idéias básicas dos proces-
sos envolvidos no desenvolvimento de software e todos
sabiam ao menos uma linguagem de programação, Java.
Nós também contávamos com um par de especialistas
na área de desenvolvimento de aplicações do tipo cliente-
servidor.”
Enquanto Manopoulos falava eu pensava com os meu
botões quão boa era a proporção entre o número de es-
19
pecialistas e generalistas. Um grupo de trinta e duas pes-

soas trabalhando no desenvolvimento de uma aplicação
do tipo cliente-servidor e só dois especialistas neste as-
sunto soou um tanto estranho para mim. Eu lhe pergun-
tei como os times foram formados.
“Todos tiveram a liberdade para escolher entre os
diversos times. Eu, como gerente de projeto, só defini o
tamanho de cada time e deixei que as pessoas escolhessem
livremente o time no qual elas queriam trabalhar.”
“E o que você me diz sobre a escolha dos líderes dos
times?” – eu perguntei.
“A mesma coisa, eu também pedi por voluntários.
Nós tivemos a liderança dos times dividida entre os países.
Por exemplo, o líder do time de Análise era do México e
o líder do time de Gerência de Negócios era do Chile, por
exemplo.”
Ele me mostrou a seguinte tabela (tabela 1)
Tabela I
Times Número de participantes
USA México Chile
Gerente do Projeto 01 — —
Analistas 03 01 02
Projetistas 02 01 02
Programadores 03 — —
Testadores 02 01 —
Gerentes de Qualidade 03 01 —
Gerentes de Documentação 02 — —
Gerentes de Configuração 02 01 —
Gerentes de Marketing 02 — —
Gerentes de Negócios 02 — 01
20
“E como funcionou?” – eu perguntei.

“Não funcionou muito bem, seria melhor se o gru-
po inteiro das pessoas de cada país pertencesse a um
único time. Por exemplo, no México nós tínhamos uma
pessoa que pertencia ao time de Analistas, outra que
pertencia ao time de Projetistas, outra ao time de Ge-
rência de Configurações, outra ao time de Testadores e
uma moça que pertencia ao time de Garantia de Qua-
lidade. Seria muito melhor se as cinco pessoas do Méxi-
co pertencessem a um único time, por exemplo o time
de Gerência de Configurações. Essa medida daria maior
poder de decisão aos times localizados fora dos EUA.
21
O modo que nós dividimos os times nos trouxe vários

problemas. Nós tínhamos 22 membros da equipe traba-
lhando juntos nos EUA e isto causou um desbalancea-
mento na estrutura do projeto. A tendência natural era
decidir nos E.U.A o que fazer e comunicar as decisões
aos times situados em outros países. Isso foi realmente
ruim; as pessoas que trabalhavam em outros países não
gostaram nada disso. Eu ainda me lembro do conselho
do vice-presidente da empresa para mim: Manopoulos,
você vai perder os desenvolvedores do México se você não
mudar esta estrutura.”
“Você os perdeu?” – perguntei curiosamente.
“Sim, a maioria dos membros da equipe de desen-
volvimento do México e do Chile deixou o projeto quan-
do problemas apareceram. Eu estava tão envolvido com
os problemas dos times dos EUA que não dei a atenção
devida aos sentimentos e frustrações dos nossos colabora-
dores estrangeiros.”
“Bom, pelo menos você tinha os líderes dos times para
ajudá-lo a resolver este problema, não tinha?”
“Deveria ter, mas não tive. Eu deveria ter tido
mais cuidado na escolha dos líderes dos times. Mas no
começo do projeto eu não conhecia muito bem a perso-
nalidade de cada um dos participantes. Se eu os conhe-
cesse tanto quanto os conheço agora, certamente teria
escolhido outras pessoas para serem os líderes de time.
Em termos de liderança, ficou claro a mim desde o prin-
cípio do projeto que nós precisávamos confiar não ape-
nas na minha capacidade de liderança, mas também
na capacidade dos líderes de cada time. A maioria dos
22
problemas enfrentados no projeto PATOLAB não foi

devido à falha de medidas de gerenciamento do proje-
to, mas à falta de liderança efetiva de cada um dos lí-
deres dos times (Smith, 1999). A falta de liderança cau-
sou a maioria dos problemas de comunicação que nós
tivemos. Os líderes dos times não se comunicavam efi-
cientemente com os integrantes do time. Os líderes dos
times não tinham uma idéia clara do que os seus subor-
dinados estavam fazendo; muitas vezes os e-mails envia-
dos pelos líderes sequer foram respondidos pelos seus su-
bordinados. O projeto PATOLAB também sofreu de
falta de comunicação entre os diversos times, embora
todos os membros tivessem acesso a uma variedade de
ferramentas de comunicação (e-mail, repositório Web
para o projeto, ICQ, etc.). As ferramentas estavam dis-
poníveis e eram fáceis de se usar; no entanto elas não
foram usadas adequadamente. Para melhorar a comu-
nicação entre times, semanalmente fazíamos uma reu-
nião, ocasião em que todos os integrantes do projeto fa-
lavam livremente sobre os problemas internos de cada
time ou de problemas que os outros times estavam cau-
sando a eles. A pergunta que eu fazia mais freqüente-
mente era se os líderes dos times tinham conversado pre-
viamente sobre os problemas comuns, e a resposta na
maior parte de vezes era “não”. Se os líderes dos times
tivessem tido mais liderança, estes problemas de comuni-
cação teriam sido superados facilmente.”
Eu notei um certo tom de ressentimento na voz dele.
Procurei mudar de assunto, eu não queria estressá-lo ainda
mais.
23
“Todos os integrantes dos times estavam trabalhando

apenas neste projeto?”
“Infelizmente não, a firma tinha vários outros proje-
tos em andamento, quase todos estavam trabalhando em
pelo menos outros dois projetos.”
“O que mais você fez na fase de preparação?”
“Nós gastamos algum tempo selecionando ferramen-
tas de software que permitissem colaboração entre os
times dispersos geograficamente. Gastamos algum tem-
po também revisando documentos de projetos de anos
anteriores. Nós tentamos usar as mesmas normas (stan-
dards) que nós usamos no projeto de software do ano
anterior, normas da IEEE. Nós procuramos identifi-
car os usuários finais e as necessidades deles. Gastamos
também um bom tempo providenciando os recursos ne-
cessários.”
Rapidamente eu rascunhei as atividades principais da
preparação para o projeto PATOLAB e mostrei a Mano-
poulos (figura 3).
Figura 3
24
Baseado no desenho que fiz nós começamos a discu-

tir cada componente da fase de preparação para o projeto.
Eu comecei lhe perguntando como foi definido o escopo
do projeto. Manopoulos tinha uma idéia clara do que
deveria ser incluído no escopo do projeto:
“O escopo delimita as fronteiras do projeto: quais
serão as características do produto (funções e desempe-
nho), quais são as restrições de contexto, quando o proje-
to será entregue, quando será terminado, quais serão as
métricas que definirão o sucesso do projeto e quais os
recursos envolvidos.”
Ele me mostrou um documento (Amaral et. al.,
1999) com a seguinte sentença sublinhada. Este docu-
mento fazia parte da definição do escopo do projeto
PATOLAB:
“O pacote de software fará uso da Internet, permi-
tindo colaboração entre times localizados em diferentes
localizações geográficas. Permitirá compartilhamento de
documentos e reuniões on-line.
Características principais:
• Aplicação para Internet
• Compartilhamento de documentos
• Compartilhamento de aplicativos
• Independência de plataforma específica
• Gerenciamento de reuniões”
Depois de ler esse trecho sobre o escopo do projeto

ele ficou quieto, algo o estava perturbando. Então eu per-
guntei: “Você acha que faltou algo em sua definição de
escopo do projeto?”
25
“Sim, eu suponho que sim. Nós não cobrimos as res-

trições de contexto. Com o desdobramento do projeto ficou
claro que teríamos de refinar nossa definição de escopo.
Nosso escopo inicial do projeto se tornou impossível de
ser alcançada em virtude do pouco tempo de que dispú-
nhamos.”
Eu sabia que a firma de Manopoulos tinha desen-
volvido um projeto de software similar um ano antes.
Talvez a equipe de desenvolvimento do ano anterior ti-
vesse enfrentado problemas semelhantes. Eu lhe pergun-
tei quão útil foi revisar ou reutilizar documentos do pro-
jeto do ano anterior.
“Nós não tivemos muito êxito reutilizando docu-
mentos e códigos do projeto anterior. As normas e docu-
mentos usados no último projeto serviram apenas como
uma diretriz, um ponto de partida para o nosso plane-
jamento. Sob este aspecto foi muito útil. Porém, a reu-
tilização de documentos técnicos não foi bem sucedida.
Como você sabe, em projetos de software você quer não
apenas reutilizar o código, mas também os documentos
de Análise, de Projeto, os Casos de Teste, etc. A Análise
e Projeto não foram reutilizados em nada. Nós não reu-
tilizamos quase nenhum código porque o software de-
senvolvido no ano anterior continha muitos erros. Nós
tentamos consertar os erros inicialmente, mas sem muito
sucesso. Nós percebemos que levaria mais tempo para
consertar o código anterior do que construir um código
totalmente novo.”
“Que chato!” – eu disse, “mas pelo menos você usou
as mesmas normas. Conte-me mais sobre as normas”.
26
“Bem, não há muito o que dizer. A maioria das nor-

mas que nós escolhemos eram normas da IEEE. Foram
providenciadas cópias das normas para todos os times e o
time de Garantia de Qualidade teve por função assegu-
rar que as normas seriam seguidas durante toda a vida
do projeto.”
“E quais foram os recursos do projeto?”
“Os recursos do projeto PATOLAB eram o pessoal, o
material e o equipamento usado no projeto. Os seguintes
recursos foram usados:” (tabela 2)
Tabela II
Pessoal 32 desenvolvedores localizados
em três países diferentes
Hardware 32 Computadores Pessoais.
Ferramentas de Desenvolvimento Java 2.0, Corba, Rational Rose
de Software:
Ferramentas de banco de dados Oracle
Ferramentas de escritório MS-Word, MS-Excel, MS-Power-
Point
Ferramentas de Projeto MS-Project, Primavera,
Ferramentas de comunicação Netmeeting, ICQ,
Web-repositórios CVS, Apache
Depois desta conversa ficou claro para mim que Ma-

nopoulos seguiu uma metodologia de preparação para o
projeto. Mas o projeto não foi bem sucedido apesar des-
sa metodologia. Eu estava curioso para saber o que po-
deria ter sido feito de um modo diferente. Eu lhe per-
guntei quais foram as deficiências principais na prepara-
ção para o projeto.
27
“Nós não gastamos muito tempo revisando os do-

cumentos do projeto do ano anterior. Não houve ne-
nhuma discussão formal sobre aqueles documentos,
embora vários grupos tivessem consultado os documen-
tos por sua própria iniciativa. Eu mesmo li o plano de
gerência do projeto do ano anterior cuidadosamente.
Isto foi muito útil, aprendi bastante com essa leitura.
Se todos os times tivessem lido os planos e documentos
do ano anterior, nós teríamos evitado incorrer nos mes-
mos erros.”
“Que erros?” – perguntei prontamente.
“Por exemplo, a definição da missão do projeto. Se-
ria muito melhor se nós tivéssemos definido claramente
nossas prioridades e as características desejadas do siste-
ma antes de começar o projeto. Nós poderíamos ter cria-
do uma matriz que representasse quais eram as caracte-
rísticas mais importantes e definir quais as nossas prio-
ridades” (Figura 4).
De modo a tornar mais clara a sua explicação, Mano-
poulos desenhou a seguinte matriz rapidamente (Highs-
mith 2000):
Figura 4
28
“E qual é a importância disso?” – eu perguntei um

pouco incrédulo.
“Isto é muito importante, Nelson! Basicamente aju-
da a visualizar o que deve ser alcançado, ajuda a defi-
nir quais são as características realmente importantes
para a sua equipe de desenvolvimento. Em nosso caso
nós queríamos ser os primeiros a lançar um aplicativo
desse tipo no mercado, nós queríamos conquistar a maior
parcela de mercado possível. Você sabe, a primeira ver-
são poderia ter um número aceitável de erros de código,
os tais “bugs”. Nós resolveríamos esses problemas nas
versões seguintes.”
Eu tinha lá minhas dúvidas quanto à sua afirmação
sobre erros – “Então você pensa que entregar um software
com um monte de erros não é problemático?”
“Olha, Nelson, eu acho que é impossível entregar
um software que foi desenvolvido rapidamente sem de-
feitos. Defeitos estarão lá, é um fato; não há nenhum
modo de se evitar isto completamente. O truque é ter os
defeitos sob controle. Há uma relação de compromisso
como em qualquer outro produto de engenharia. Em
nosso caso, nossos defeitos não causariam danos sérios.
Nós não estávamos desenvolvendo um software que co-
locaria em risco a vida humana. Caramba, se os pro-
dutos da Microbob’s1, depois de muitas versões ainda
têm vários “bugs”, por que o meu software não poderia
ter nenhum?”
1Microbob’s é uma firma que desenvolve software, feroz competidora da firma em

que Manopoulos trabalhava
29
Nós rimos e concordamos. Sim, sempre há uma re-

lação de compromisso em qualquer projeto. Mas eu ain-
da estava pensando por que a missão deveria ser definida
do modo que ele propôs e pedi a ele mais detalhes.
“A definição da missão é muito importante. Se você
tiver uma definição clara do que é a sua missão, ficará mais
simples de escolher o processo de desenvolvimento (ciclo de
vida). Por exemplo, no nosso caso nós não tínhamos uma
idéia clara de que ciclo de vida seguir. Agora eu sei que
dependendo da natureza do software, um processo de desen-
volvimento é mais adequado. Não faz sentido usar modelos
de ciclo de vida em cascata para software que necessita ser
desenvolvido rapidamente e que seja projetado para operar
em ambientes que mudem rapidamente, como a Internet
por exemplo. Definir a missão claramente ajuda a escolher
o modelo de desenvolvimento mais adequado.”
Eu já havia estudado os diversos modelos de ciclo de
vida para desenvolvimento de software, mas nunca havia
percebido que a escolha deles está ligada não apenas ao
objetivo que se quer alcançar, mas também ao ambiente
em que o sistema irá operar e à velocidade de desenvolvi-
mento. Isso era uma novidade para mim. Manopoulos sa-
lientou que o modelo de ciclo de vida em cascata é bastan-
te apropriado para o desenvolvimento de aplicações que
irão operar em ambientes que mudam pouco. Ele me deu
o exemplo do desenvolvimento de um sistema para moni-
toração de pacientes em UTI hospitalar. O software não
deve ter erros, a velocidade de desenvolvimento não deve
ser alta. O ambiente em que o sistema irá operar provavel-
mente será um computador dedicado apenas a essa fun-
30
ção, ou seja, um ambiente que muda pouco. O modelo de

ciclo de vida em cascata, neste caso, seria o adequado.
“Mas no caso do projeto PATOLAB a estória era
totalmente oposta: tínhamos que ser os primeiros a che-
gar no mercado, tínhamos que desenvolver rapidamente
para um ambiente que muda muito, a Web” – ressaltou
Manopoulos.
Ele desenhou a seguinte figura de modo a tornar o
conceito mais claro (Figura 5).
Figura 5
31
Ele me explicou rapidamente as diferenças entre “De-

senvolvimento de Software Monumental” e “Desenvol-
vimento de Software Acidental” (Highsmith, 2000).
Ficou claro para mim que o desenvolvimento pode se
situar entre dois extremos, pode variar desde um proces-
so totalmente definido, o assim chamado “Desenvolvi-
mento de Software Monumental” até um processo to-
talmente caótico, o “Desenvolvimento de Software Aci-
dental”. Ele explicou que Modelos de Maturidade de Ca-
pacidade são mais satisfatórios para processos de desen-
volvimento de software repetitivos. Para um projeto de
características especiais como o PATOLAB ele usaria uma
outra abordagem, chamada de Desenvolvimento Adap-
tativo de Software (Highsmith, 2000). Eu lhe perguntei
se ele tinha esta visão clara no começo do projeto.
“Infelizmente, não. Nós não definimos claramente
as nossas prioridades no início do projeto. Nós escolhe-
mos um ciclo de vida de prototipagem no começo do pro-
jeto e no meio do projeto nós resolvemos mudar e seguir o
ciclo de vida em cascata. Realmente foi uma bagunça!
E ao término do projeto nós estávamos discutindo em
qual fase do Modelo de Maturidade de Capacidade nós
nos encontrávamos!”
Ele fez o seguinte desenho para mostrar como foi a
evolução do projeto (Figura 6).
Ele também me falou que não foi realizado um estu-
do de viabilidade adequado. Eu achei estranho e pergun-
tei o porque disso.
“Talvez porque nós estivéssemos bastante confiantes
das nossas habilidades. Talvez exageradamente otimistas
32
Figura 6
ou talvez porque naquele momento nós não tínhamos

idéia de quão complexo seria o projeto que nós iríamos
enfrentar. Se nós fôssemos fazer o mesmo projeto nova-
mente eu conduziria a realização de um estudo de viabi-
lidade imediatamente na fase de preparação. Deste modo
nós poderíamos definir um escopo de projeto mais realís-
33
tico. Nós dividiríamos o projeto em versões e definiría-

mos as características principais de cada versão.”
“Manopoulos, fale me mais sobre essa idéia de ver-
sões.” – eu perguntei curioso.
Ele pensou um pouco e disse:
“Eu acredito ser importante definir as metas para cada
versão do software. Nosso escopo inicial era muito abran-
gente, difícil de ser realizado em um ano. Seria melhor se
nós tivéssemos definido metas específicas a serem alcança-
das ao longo do tempo, da seguinte forma:”
Ele fez este desenho (Figura 7):
Figura 7
“Manopoulos, você pensa que seu projeto teve algum

sucesso?”
“Bom, depende como você define sucesso. O que é su-
cesso de um projeto?” – ele retrucou.
“Olha, para mim um projeto bem sucedido deve aten-
der a um ou a todos dos seguintes critérios: cumprir os re-
quisitos estabelecidos, ser entregue dentro do prazo estipu-
lado, não ultrapassar o orçamento previsto. Bem, evidente-
34
mente o projeto deve assegurar a qualidade do produto e

proporcionar satisfação profissional e oportunidade de cres-
cimento aos integrantes dos times (Highsmisht, 2000).”
Manopoulos pensou um pouco e disse:
“Talvez seja impossível atender a todos esses crité-
rios, talvez você deva escolher alguns dentre eles e defini-
los como suas metas de sucesso. Mas eu posso lhe dizer
que nós não atingimos nenhum desses critérios de sucesso
plenamente. De fato, nós deveríamos ter definido como
medir o sucesso do projeto ainda na fase de preparação
para o projeto.”
Manopoulos estava com uma expressão amarga, al-
guma coisa o estava perturbando. Eu tentei descobrir em
que ele estava pensando.
“Que mais você poderia me dizer sobre a preparação
para o projeto?”
“Eu penso que na fase de preparação todos os inte-
grantes dos times deveriam ter estudado mais sobre os
conceitos básicos de desenvolvimento de software para
ambiente cliente-servidor. Todos os componentes dos ti-
mes sabiam programar usando a linguagem Java, mas
isso não era o suficiente. Tínhamos apenas um analista
no time que era especialista em Corba e Oracle. Se to-
dos os componentes dos times tivessem as noções básicas
de arquitetura do tipo cliente-servidor isso teria evita-
do muitos problemas que tivemos durante o desenvolvi-
mento do projeto. Talvez nós não tivéssemos as habili-
dades necessárias, sei lá. Talvez eu mesmo não tivesse
maturidade e habilidade necessária para gerenciar um
projeto daquele porte…”
35
“Calma Manopoulos, não se culpe tanto! Minha mãe

sempre diz que a cura para a tristeza é uma boa refeição!”
Era hora do almoço, nós precisávamos comer algo.
Decidimos que oportunamente conversaríamos sobre pla-
nejamento de projeto. Manopoulos me convidou a ir a um
restaurante próximo, cujo nome era “Miracle of Science”.
Ele iria me apresentar uma amiga dele, Beth. Eu estava
ansioso por conhecê-la pessoalmente, já tinha ouvido falar
bem sobre ela.
36
Tópicos para discussão
1) PATOLAB era um projeto colaborativo-dis-

tribuído; os desenvolvedores moravam no
México, Chile e EUA. O que você faria para
assegurar uma comunicação eficiente entre
os times? Quais ferramentas você usaria?
2) Manopoulos esqueceu de falar sobre a na-
cionalidade dos integrantes do time que
trabalhava nos EUA. Os desenvolvedores
eram de várias nacionalidades diferentes
tais como Índia, China, Líbano, Brasil e
EUA. Você pensa que esta diversidade po-
deria causar alguns problemas? Você acha
que diferenças culturais e barreiras de idio-
ma poderiam dificultar o andamento do
projeto?
3) Este é um exemplo de um projeto de software
complexo e de curto prazo. Se você fosse
selecionar os componentes dos times, que
tipo de profissional você procuraria contra-
tar? Como você dividiria os times?
5) Talvez o modelo de fases do projeto segui-
do por Manopoulos seja muito simples
(Figura 1). Crie um novo modelo, mais
elaborado.
37
6) Eu não gosto das atividades listadas na preparação para

o projeto (Figura 3). Talvez eu acrescentasse mais al-
guns componentes e retirasse outros. O que você faria?
7) Manopoulos não falou muito sobre o cliente para esse
tipo de aplicação. Como envolver os clientes na fase
de preparação para o projeto?
8) Quais foram os maiores erros de Manopoulos na fase
de preparação para o projeto?
9) Você pensa que revisar projetos de anos anteriores é
importante? Você alguma vez revisou algum projeto
anterior antes de trabalhar em um novo? Sua compa-
nhia tem um catálogo de “lições aprendidas” de pro-
jetos anteriores? Que tipo de informação seria útil de
se obter de projetos prévios?
10) Você pode explicar qual era o problema representado
pela figura 6?
38
Referências
[Amaral, 2000] Amaral, J.A.A (2000) Project

Management in Distributed Collaborative
Environment: The ieCollabCase Study,
MIT MscThesis, Ocean Engineering
[Amaral et. al., 1999] Amaral, J.A.A., Li-
mansky I. and Abbot E. (1999). The ie-
Collab Project Management Plan, obtido
em 25 de maio de 2000, Web: http://
www.collaborate.mit.edu/FTP/P1
[Highsmith, 2000] Highsmith III, J. A.
(2000). Adaptive Software Development: a
collaborative approach to managing complex
systems, New York, USA: Dorset House
Publishing Company.
[Smith, 1999] Smith G. (1999, August). Pro-
ject leadership: Why project management
alone doesn’t work, Hospital Materiel Ma-
nagement Quarterly, 21(1), 88-92.
39
CAPÍTULO II PLANEJAMENTO
DO P ROJETO
Estudo de Caso 02
“Não há ventos favoráveis para
aqueles que não sabem aonde ir”
“Seres humanos são notáveis em sua

habilidade de aprender com experiên-
cia de outros, mas também são
igualmente notáveis em sua falta de
vontade de fazer isso.”
Douglas Adams
N ós fomos para “Miracle of Science”,

um bar bem rústico perto do MIT. Mesas tos-
cas de madeira maciça, janelas amplas, sempre
apinhado de gente. O bar é um ponto de refe-
rência em Cambridge, para lá convergem to-
das as tribos na hora do almoço. Ali nós nos
encontramos com Beth, uma mulher notável.
Alta, bonita e esbelta, olhos verdes atentos a
tudo. Ela possui uma firma própria, especializa-
da na fabricação de cromatógrafos. Beth e o
seu pai fazem de tudo: contatam os clientes,
projetam e constroem os dispositivos mecâni-
cos e as interfaces eletrônicas, desenvolvem o
software, testam as máquinas e cuidam do
transporte aos clientes. Ela é realmente incrível!
Beth está em Boston por um mês, em visita
43
ao seu irmão que vai se casar em breve. Nós três nos senta-
mos a uma mesa perto da janela. Manopoulos e eu pe-
dimos sanduíches; Beth pediu uma salada. Todos pedi-
mos cervejas. Afinal é sexta-feira e ninguém é de ferro.
Enquanto nós esperávamos, Beth perguntou a Manopou-
los como foi o projeto de software que ele liderou.
“Você conhece aquele ditado, Beth, que diz que a
estrada para o inferno é pavimentada de boas inten-
ções? Pois é, nós tínhamos um time de desenvolvedores
muito bom e planejamos muito bem; porém, não conse-
guimos entregar o projeto no prazo. A gente planejou,
programou, pelejou, pelejou, mas não teve jeito, a vaca
caminhou firme e resolutamente para o brejo.” – Mano-
poulos chamou o garçom – “Uma cerveja a mais, por
favor!”
Isto era uma coisa que a Beth simplesmente não con-
seguia entender. Como 32 desenvolvedores não consegui-
ram criar um produto?
“Mas por que vocês falharam?” – ela perguntou in-
crédula. “– O que deu errado?”
Eu lhe falei que nós tínhamos discutido os assun-
tos relacionados à preparação para o projeto pela ma-
nhã. A preparação para o projeto me parecera um tanto
problemática. Eu lhe falei brevemente sobre os proble-
mas que Manopoulos teve escolhendo os líderes de time,
a reutilização inadequada de documentos e códigos do
projeto de software do ano anterior e a falta de expe-
riência dos times em assuntos relacionados a ambientes
cliente-servidor. Eu também falei para Beth que nenhu-
ma área específica é a causa de todos problemas. Explo-
44
rando o processo de planejamento talvez nós pudésse-

mos descobrir outras áreas que contribuíram para o fra-
casso. Beth normalmente não gasta muito tempo fa-
zendo planejamento quando ela cria suas máquinas, por
isso ela está interessada em aprender mais sobre plane-
jamento.
“Fale-me sobre planejamento, Manopoulos. Você pen-
sa que isso é realmente importante?” – ela perguntou com
um olhar maroto.
Manopoulos pegou um guardanapo e escreveu as se-
guintes palavras.
Figura 1
Beth olhou curiosamente para o guardanapo e nos fa-

lou que ela tinha lido ontem uma frase assim: “não há ne-
nhum vento favorável para aqueles que não sabem aonde ir”.
Manopoulos pensou um pouco e disse: “Essa frase
tem tudo a ver com planejamento de projetos. Planejar é
45
definir as medidas que você vai tomar de modo a atingir

o seu objetivo. Mas onde foi mesmo que você leu essa
frase?”
“Eu li em um panfleto de um curso de vela do MIT
ontem à tarde”, respondeu Beth sorrindo. Ela velejava às
quartas e sextas à tarde, no Charles River, um rio caudalo-
so que separa Cambridge de Boston. As cervejas chegaram
e eu perguntei a Manopoulos como era a estrutura de ti-
mes adotada.
Ele sacou da sua pasta uma tabela que mostrava a
constituição dos dez times (tabela 1)
Tabela I
Times Número de Pessoas
Gerente de Projeto 1
Gerentes de Negócios 3
Gerentes de Marketing 2
Analistas 6
Projetistas 5
Gerentes de Configuração 3
Garantia da Qualidade 4
Gerentes de Conhecimento 2
Programadores 3
Testadores 3
Eu perguntei a Manopoulos se havia algo errado na

composição dos times. Como um projeto de software po-
deria ter tão poucos programadores?
“Em nosso projeto, todo o mundo tinha por segunda
função ser programador. Os três programadores mostrados
46
nesta tabela eram na verdade os líderes de sub-times de

programação. Um liderava o desenvolvimento das GUI, o
segundo conduzia o desenvolvimento das classes em JAVA
e o terceiro liderava a criação do Banco de Dados”, ele
explicou.
Beth estava surpresa. Ela nunca havia trabalhado com
tantos desenvolvedores em um único projeto. Ela também
estava confusa sobre quais eram as responsabilidades de
cada um destes times.
“Quais eram as responsabilidades de cada time? Onde
elas foram definidas?” – ela perguntou. Manopoulos sabia
as responsabilidades de cor. Afinal, ele penou um bocado
para explicar as responsabilidades de cada time aos mem-
bros do projeto.
“Respondendo à sua segunda pergunta em primeiro
lugar, as responsabilidades estavam definidas no plano de
gerência de projeto” (Amaral et. al., 1999).
“Bem, eu vou te dizer as responsabilidades de cada
time rapidamente, pois sei de cabeça. O time de Gerên-
cia de Marketing é o responsável por identificar as carac-
terísticas de mercado, tendências de tecnologia, necessi-
dades dos clientes e estratégia de propaganda. O time de
Gerência de Negócios analisa os competidores no merca-
do e desenvolve a estratégia competitiva. O time de Ge-
rência de Negócios é responsável também por definir as
características desejáveis para o produto baseado nas ne-
cessidades de mercado. Os Gerentes de Negócios traba-
lharam conjuntamente com os Gerentes de Marketing a
maior parte do tempo.”
47
Enquanto Manopoulos falava, eu pensava na diferença

entre as responsabilidades do time de Gerência de Marke-
ting e do time de Gerência de Negócios. Parecia-me que
ambos os times tinham responsabilidades complementares.
Bem, eu preferi não dizer nada e deixar que Manopoulos
falasse.
Ele estava se tornando mais agitado, gesticulava ner-

vosamente. Era fácil perceber que ele gostava de seu tra-
balho. Do que eu gosto? Sem dúvida dos olhos verdes de
Beth, mas isso é outra história… As cervejas chegaram
finalmente à nossa mesa. O fator cerveja fez Manopou-
los falar mais rapidamente:
“O gerente de projetos é o responsável pela orga-
nização, planejamento, monitoração e controle do pro-
jeto. O gerente de projetos é responsável pela criação do
Plano de Gerência do Projeto e por tomar as medidas
necessárias para assegurar que o plano seja seguido. Ele
também é o responsável por alocar recursos para os ti-
mes de acordo com a necessidade, dando o apoio neces-
sário, coordenando as atividades e mantendo canais de
48
comunicação eficientes. O Gerente do Projeto é o res-

ponsável pela entrega de um produto de qualidade, den-
tro do prazo e do orçamento. Os Analistas são os res-
ponsáveis por traduzir as metas dos Gerentes de Negó-
cios em requerimentos de software. O time usa várias
ferramentas (por exemplo os diagramas de Uso de Ca-
sos da UML) para especificar as funcionalidades dese-
jadas para o sistema. Os analistas interagem bastante
com os clientes, procurando entender as suas necessi-
dades. A responsabilidade principal do Time de Proje-
tistas é detalhar os requerimentos do software, defini-
dos pelo time de Análise, de forma a dar condições ao
time de Programadores de criar o código. Os projetistas
usam ferramentas tais como o Rational Rose, Diagra-
mas da UML etc. O papel do Time de Programadores é
criar código de qualidade, bem documentado, conciso e
que siga fielmente o que foi estabelecido pelos Proje-
tistas. A responsabilidade principal dos testadores é des-
cobrir erros e verificar se o programa opera da forma
desejada. Casos de teste são ferramentas utilizadas para
identificar erros.”
Eu confesso que a essa altura do campeonato eu já
estava quase dormindo. Eu já havia estudado desenvolvi-
mento de software em alguns cursos; esta conversa estava
me enfadando, mas Beth estava interessada. Ela nunca
tinha feito qualquer curso relacionado à engenharia de
software na sua graduação. A propósito, ela é Física.
Finalmente, meu hambúrguer com queijo chegou e mi-
nha vida começou a fazer sentido novamente. Manopou-
los continuou o seu discurso:
49
“O time de Garantia de Qualidade é responsável por

conduzir as inspeções, revisões de projeto e auditorias.
O time é responsável por criar o plano de garantia de qua-
lidade.” Neste ponto eu o interrompi e fiz um comentário:
“Manopoulos, o time de Garantia de Qualidade é res-
ponsável pela qualidade do produto ou pela qualidade do
processo de desenvolvimento?”
“Ambos” – ele respondeu. “Na realidade durante o
projeto eu trabalhei bastante em conjunto com o time de
Garantia de Qualidade.”
Beth perguntou quais eram as responsabilidades dos
times de Gerência de Conhecimento e de Gerenciamento
de Configurações. Manopoulos explicou:
“O time de Gerência de Conhecimento é o respon-
sável por manter o repositório WEB do projeto e por
definir o formato padrão para os documentos de projeto.
Os gerentes de conhecimento conferem diariamente o
conteúdo do repositório WEB de forma a assegurar que
os documentos estejam seguindo o padrão estabeleci-
do e verificar se os mesmos foram publicados nas datas
50
previstas. Se problemas surgissem, os gerentes de conhe-

cimento contatariam os outros times e informariam o
gerente de projeto.
O time de Gerência de Configurações controla e ar-
mazena os produtos que são gerados pelo diferentes times
e prontamente informa todos os integrantes dos times do
estado atual do software (i.e. mudanças, versão, local de
armazenamento). A responsabilidade principal deste time
é ajudar os programadores a se organizarem, controlar e
rastrear o trabalho deles. O time age como uma rede de
segurança, evita que qualquer documento/código seja per-
dido ou apagado acidentalmente. Este time também é
responsável por prevenir atualizações simultâneas de có-
digo e por notificar os programadores de erros que foram
consertados (Humphrey,1990).”
Beth gostou do modo que Manopoulos definiu as res-
ponsabilidades dos times. Tudo parecia tão claro a ela.
“Mas por que você teve problemas em explicar as
responsabilidades aos membros dos times?” – ela lhe per-
guntou.
“Bem, sei lá, a definição de responsabilidades de
times de projeto de software pode ser encontrada em
qualquer bom livro de software. O problema é fazer o
time entender e seguir suas responsabilidades, fazê-lo
trabalhar harmoniosamente com os outros times. Quan-
do você divide um grupo em times pequenos há uma
tendência natural de cada time se especializar em seu
próprio trabalho e se esquecer da otimização do produto
final.”
Beth concordou: “Muito interessante! Isso me faz
lembrar de um livro que eu li há algum tempo, eu acho
51
que o nome do livro é “Surely you’re joking, Mr. Feyn-

man: Adventures of a Curious Character”. Preciso con-
ferir o nome do livro; Richard Feynman é um físico,
ganhador do prêmio Nobel. Ele foi chamado para des-
cobrir o que deu errado com o projeto do Ônibus Es-
pacial Challenger. Como você sabe, ele descobriu aquele
problema com os anéis de vedação, os tais “O-rings”.
Mas ele também percebeu (e não gostou) que os times
que construíram a astronave não trabalharam de um
modo muito integrado. Eles otimizaram o próprio tra-
balho em detrimento da otimização do produto final.
Bem, em um projeto monstruoso assim, é bastante pos-
sível que os desenvolvedores não tivessem tempo para
falar com os membros de outros times… Mas eu achei
esta desvantagem do trabalho segmentado bem interes-
sante. É engraçado como os mesmos tipos de problemas
estão sempre presentes em qualquer projeto, indepen-
dente de sua natureza.”
É por isso que eu gosto de Beth, ela sempre tem algo
interessante para dizer. Beth olhou novamente para aquele
guardanapo (Figura 1) e perguntou a Manopoulos o que
são requerimentos de performance.
“Em geral, nós podemos dizer que requerimentos de
performance são as características desejadas para o produ-
to final. Em projetos de software, as características deseja-
das podem ser definidas em termos de portabilidade, velo-
cidade, tipo de interface gráfica, características do banco
de dados, arquitetura cliente-servidor, recursos multimí-
dia, interfaces com outros sistemas e uso da Internet”, ele
respondeu.
52
“E o que são os produtos a serem entregues ?” – eu

perguntei.
“São os componentes principais do projeto. Em proje-
tos de software os produtos a serem entregues são os códi-
gos, os documentos técnicos e o guia do usuário.”
“Eu nunca trabalhei com times situados em países
diferentes” – observou Beth. “Qual foi a estrutura de co-
municação que você usou?”
“A comunicação diária entre times foi feita por meio
de e-mails e pelo uso do software ICQ. Videoconferência e
teleconferência foram usados raramente devido aos custos
financeiros envolvidos. Nós definimos os seguintes meca-
nismos para reportar o progresso feito:
• Reuniões semanais de todos os componentes dos times
com o gerente de projeto.
• Todos os relatórios escritos foram colocados no repositó-
rio de projetos na Web. Os documentos seguiram o for-
mato especificado pelo time de Gerência do Conheci-
mento. Também foram colocados na Web todos os co-
mentários e discussões sobre os documentos. Foi pedido
aos líderes de cada time que lessem os comentários e que
os discutissem com o gerente de projeto nas nossas reu-
niões semanais.
• Inspeções e revisões conduzidas pelo time de Garantia
de Qualidade
• Recomendações do gerente de projeto. Estas recomen-
dações eram fruto de nossas reuniões de quinta-feira e
eram enviadas a todos via e-mail.
• Palestras de curta duração sobre as atividades desen-
volvidas por cada time.”
53
“A estrutura de comunicação me parece bastante boa”

– eu disse, e Beth concordou. Beth tem muita experiência
em identificar as atividades envolvidas na criação de um
produto tangível como um cromatógrafo. Ela disse a Ma-
nopoulos que estava curiosa em saber quais eram as ativi-
dades principais envolvidas no desenvolvimento de sof-
tware, um produto intangível.
“Projetos de software envolvem atividades de desen-
volvimento, apoio ao projeto e atividades empresariais
(tabela 2).”
Tabela II
Atividades de desenvolvimento • Análise
• Projeto
• Codificação
• Teste
Atividades de Apoio de projeto • Gerência de Projeto
• Garantia de Qualidade
• Gerência de Configuração
• Gerência do Conhecimento
Atividades empresariais • Gerência de Negócios
• Gerência de Marketing
“As atividades de desenvolvimento são a parte princi-

pal do processo de criação de software. São as tarefas técni-
cas: análise dos requerimentos, projeto, codificação e teste.
As atividades de apoio ao projeto são atividades que aju-
dam a organizar o processo de desenvolvimento. Uma vez
que nós definimos quais são as atividades, calculamos a
duração delas e criamos a rede de atividades”. Neste mo-
mento, ele abriu sua maleta e nos mostrou o seguinte de-
senho (Figura 2).
Beth perguntou como ele calculou a duração de cada
atividade e como criou a rede.
54
Figura 2
55
“Há vários modos de se calcular a duração de cada

atividade, depende do seu tipo. Por exemplo, para se de-
terminar o tamanho do código a ser gerado, é bastante
comum se fazer estimativas através de Análise de Pontos
de Função. Nós não tivemos tempo para fazer estimativas
precisas. Nossa estimativa estava baseada principalmente
na duração das atividades do projeto do ano anterior e em
nossa experiência profissional. A rede de atividades foi cria-
da baseada no ciclo de vida que nós escolhemos. Se você
olhar para a rede (Figura 2) poderá notar que há várias
atividades planejadas para serem executadas em paralelo.
Por exemplo, de modo a otimizar a utilização de nossos
recursos, nós planejamos desenvolver atividades de Análise
e de Projeto simultaneamente. As atividades de Codifica-
ção e o Teste também foram planejados de modo a serem
realizados simultaneamente. Nós pretendíamos começar a
testar o software sete dias após os programadores terem
começado a desenvolver o código.”
Mais cervejas chegaram, deliciosamente geladas. Cam-
bridge no verão é muito quente e seco, o que fazia o nosso
consumo de cerveja aumentar consideravelmente.
Beth, já ligeiramente ébria, olhava atentamente aque-
le guardanapo (Figura 1) onde Manopoulos havia escrito
as atividades básicas envolvidas no planejamento do pro-
jeto. Ela estava interessada em saber o que era mitigação
de riscos.
“Você ouviu falar da Lei de Murphy, Beth?” – eu per-
guntei, já meio zonzo de tanta cerveja.
“Sim” – ela disse. “Se você percebe que há quatro pos-
síveis modos nos quais algo pode dar errado, e evita estes,
56
então um quinto modo para o qual você está despreveni-

do se desenvolverá prontamente!“
Manopoulos somou uma idéia: “Eu ouvi isto de um
modo diferente, se você não atacar os riscos efetivamente,
eles é que te atacarão efetivamente!”
Nós estávamos rindo muito, talvez por causa do efei-
to da cerveja que torna tudo mais engraçado.
Mas Manopoulos estava procurando algo na maleta
dele. “Aha, aqui estão eles!” Ele retirou algumas folhas de
papel e as pôs sobre a mesa. A essa altura a nossa mesa já

era uma bagunça total cheia de restos dos sanduíches, o
capacete de bicicleta da Beth, guardanapos rabiscados e
agora mais essas folhas. A garçonete começou a dar sinais
de que queria nos ver pelas costas. Nós pedimos mais al-
gumas cervejas de modo a melhorar nossa capacidade de
raciocínio e tornar a garçonete mais feliz. Manopoulos nos
mostrou em seqüência várias tabelas e explicou que ele
seguira a abordagem de Pressman (Pressman,1997) para
mitigação de riscos.
57
“Primeiro nós definimos as categorias dos riscos e os

identificamos.”
Tabela III - Itens de Risco
Lista de Riscos Abreviação
Riscos associados ao Tamanho de Produto TP
Riscos associados ao Impacto Empresarial IE
Riscos relacionados ao Cliente CL
Riscos associados ao Processo PR
Riscos associados à Tecnologia TC
Riscos associados ao Ambiente de Desenvolvimento DE
Riscos associados ao número de pessoas e sua SS
experiência
Riscos associados ao Desempenho DO
Riscos associados à estrutura de Apoio AP
Riscos associados ao cronograma (schedule) SH
“Então nós demos valores de impacto aos riscos”

Tabela IV - Valores de Impacto para os Riscos
Grau de impacto Valores de Impacto

Catastrófico 1
Crítico 2
Marginal 3
Desprezível 4
“Depois disso nós listamos todos os riscos que fomos

capazes de antecipar. Numeramos e classificamos por meio
das categorias definidas anteriormente.
Nós também definimos uma probabilidade de ocor-
rência para cada risco.”
58
Tabela V - Riscos de Projeto
Riscos ID Categoria Probabilidade Impacto
Estimativas imprecisas quanto ao tamanho do software a ser criado 1 TP Alta 3
Quantia pequena de software reutilizado 2 TP Média 2
Excessiva quantidade de documentação a ser gerada 3 TP Alta 2
Grande número de sistemas com os quais o nosso software deve 4 IE Média 1
ser interoperável
Pouca reutilização de documentos e códigos do projeto anterior 5 PR Baixa 2
Inconsistência entre sistemas diferentes 6 PR Alta 1
Falta de treinamento em ferramentas de desenvolvimento 7 PR Média 2
Falta de ferramentas de software para apoiar processo de teste 8 PR Alta 3
Falta de métricas de produtividade 9 PR Alta 2
Poucas ferramentas disponíveis para gerenciamento de configurações 10 DE Alta 3
Ferramentas de software não integráveis 11 DE Alta 4
Pouca experiência prévia em desenvolvimento de software 12 SS Baixa 2
Uso de rotinas não testadas do projeto do ano anterior 13 TC Alta 1

Problemas de integração com outros sistemas 14 TC Média 2
Desenvolvedores envolvidos em outros projetos 15 SS Alta 2
Desenvolvedores abandonando o projeto 16 SS Média 2
Projeto não satisfaz todas as exigências 17 DO Média 1
Problemas na implementação de funções 18 TC Média 1
Qualidade afetada por escorregamento no cronograma 19 SH Alta 1
59
“E finalmente nós agrupamos os riscos, em função do

grau de impacto e da probabilidade de ocorrência.”
Tabela VI - Riscos Agrupados

Riscos ID Probabilidade Impacto
6,13,19 Alta Catastrófico
3,9,15 Alta Crítico
4,17,18 Média Catastrófico
2,7,14 Média Crítico
1,8,10 Alta Marginal
5,12,16 Baixa Crítico
11 Alta Desprezível
“Baseado em cada categoria definida na tabela ante-

rior nós desenvolvemos as estratégias de mitigação.” Ele
nos mostrou um exemplo:
Tabela VII - Exemplo de Estratégias

Estratégia para mitigação de Riscos de Probabilidade
Alta e de Impacto Catastrófico
Risco 6 - Para assegurar consistência entre sistemas diferentes,

nós implementamos as seguintes medidas:
• Um Comitê foi formado com os líderes dos times. Este comitê
se encontraria todas as semanas ou sempre que necessário para
administrar as mudanças que poderiam afetar outras partes do
projeto
• Se uma reunião de um time tratasse de informação que também
fosse pertinente a outro time, um membro do time externo deveria
comparecer àquela reunião. Essa medida ajudaria a manter con-
sistência e coerência entre os documentos e planos.
• Os times de Análise e Projeto deveriam concordar nas ferramen-
tas comuns a serem usadas desde o começo de desenvolvimento.
Sugestão: usar UML.
60
Risco 13 – Uso rotinas de projeto não testadas (do projeto do ano

anterior)
• Nós decidimos nomear dois testadores para executar testes nos
programas do projeto anterior. Todo o código seria testado, mes-
mo que já tivesse sido testado no ano anterior.
Risco 19 – Qualidade afetada por derrapagem no cronograma
• Uma análise crítica na viabilidade dos requerimentos deve ser feita.
Os requerimentos para as Versões 1 e 2 devem ser realísticos,
levando em conta a curta duração do projeto e os vários compro-
missos assumidos. Um pacote de software pequeno e seguro é
melhor que um grande e incerto.
• Se ocorrer alguma derrapagem no cronograma nós cortaremos al-
guns requerimentos; nós não queremos sacrificar a qualidade.
Neste ponto nós todos estávamos cansados. Eu con-

fesso que não estava prestando muita atenção ao conteú-
do das tabelas, só na idéia principal. Eu penso que Beth
estava fazendo o mesmo. Eu também não estava certo de
quão sóbrios nós estávamos. Nós havíamos bebido muito!
Pelo menos nós concordamos em um ponto: estava na hora
de voltarmos para casa!
No nosso caminho de volta Manopoulos estava ca-
bisbaixo, pensando nos possíveis enganos que cometera
em seu planejamento. Beth estava alegre, pensando no que
ela havia aprendido do papo de boteco e como ela poderia
usar essas dicas em seus próximos projetos de cromatógra-
fos. E eu pensava nos olhos verdes da Beth...
Nós combinamos de andar de bicicleta de Manches-
ter-by-the-sea até Gloucester no próximo fim de semana;
talvez nós pudéssemos falar sobre assuntos relacionados à
execução do projeto durante o percurso.
61
Referências
[Amaral, 2000] Amaral, J.A.A (2000) Project Management

in Distributed Collaborative Environment: The ieCo-
llabCase Study , MIT, MSc Thesis, Ocean Enginee-
ring Dept/Civil Engineering Dept.
[Amaral et. al., 1999] Amaral, J.A.A., Limansky I. and
Abbot E.(1999).The ieCollab Project Management
Plan, Obtido em 25 de maio de 2000, Web: http://
www.collaborate.mit.edu/FTP/P1
[Highsmith, 2000] Highsmith III, J. A. (2000). Adaptive
Software Development: a collaborative approach to ma-
naging complex systems, New York, USA: Dorset House
Publishing Company.
[Limansky et al. 1999] Limansky I. et all, Master of Engi-
neering Information Technology Class of 2000
(1999), The IeCollab project. Obtido em 25 de maio
de 2000,
Web: http://www.collaborate.mit.edu/FTP/P1 [Pressman,
1997] Pressman, R.S. (1997). Software Engineering:
A practitioner’s approach. New York, USA: McGraw-
Hill.
[Humphrey,1990] Humphrey W.S. (1990). Managing the
Software Process, Berkeley, USA: Addison-Wesley
63
CAPÍTULO III EXECUÇÃO DO
PROJETO
Estudo de Caso 03
“Os sete pecados capitais do
projeto”
“O pessimista reclama do vento;

o otimista espera que ele mude de
direção; o realista ajusta as velas.”
William Arthur Ward
S ão 08:35 de uma manhã de domingo

deslumbrante. Beth, Manopoulos e eu esta-
mos no trem, indo de Boston para Manches-
ter. Nossas bicicletas se encontram amontoa-
das no final do vagão, amarradas no local apro-
priado. Nós pretendemos andar de bicicleta
o dia todo e voltar no último trem antes do
cair da noite.
“Eis o plano” – disse Beth. “Ir até Man-
chester de trem, andar de bicicleta até Glou-
cester e fazer um piquenique no Stage Fort
Park. Depois disso, contornar de bicicleta
Cape Ann e pegar o caminho de volta para
Manchester. Acho que levará aproximadamen-
te cinco horas para fazer isso. No meio do
caminho nós podemos fazer uma parada es-
tratégica em Singing Beach e descansar por
algum tempo na praia. Se nós ainda tivermos
energia, podemos andar de bicicleta de Man-
67
chester até Beverly. Que tal jantar em Lynch Park? Deixe-

me ver, nós podemos tomar o trem das 08:04 p.m. de
Beverly para Boston. O que vocês acham?”
Eu concordei com ela, que mais eu poderia fazer?
Ela é uma ótima ciclista e sempre tem idéias bacanas.
Manopoulos estava com muito sono para protestar, de
forma que este ficou sendo o plano que nós iríamos se-
guir, aprovado agora por decisão unânime!
Beth estava cheia de energia, ela abriu uma revista e
começou a ler um artigo sobre o filme “Seven”.
“Olha que interessante, aqui estão listados os sete
pecados capitais (Hornby, 1995),” – ela passou então a
lê-los um a um: “Avareza: ganância, um desejo extremo
para riqueza ou ganho. Inveja: um desejo forte para ter
as posses ou qualidades de outra pessoa. Glutonice: o
hábito ou prática de comer ou beber muito. Preguiça:
indolência, aversão ao trabalho. Luxúria: lascívia, de-
sejo desenfreado. Vaidade: auto-estima exacerbada. Ira:
raiva, fúria, rancor.” Ela sorriu maliciosamente para
mim e perguntou – “Qual é o seu pecado favorito,
Nelson?”
“Glutonice”, eu respondi prontamente, “definiti-
vamente este é meu pecado favorito. E o seu, Mano-
poulos?”
“Preguiiiiiiiiiiiça…” – ele respondeu enquanto se
espreguiçava.
“Bom dia, Manopoulos!” – troçou Beth – “Você pode
nos contar quais foram os seus pecados capitais durante
a fase preparação para o projeto PATOLAB?”
Manopoulos pensou por algum tempo e disse:
68
“Em termos de preparação para o projeto, eu poderia

dizer Glutonice. Nós tentamos morder mais do que nós
podíamos mastigar. Nós fomos muito ambiciosos em ter-
mos de nossas metas: nós queríamos fazer tudo. Quase to-
dos os participantes do projeto PATOLAB também esta-
vam envolvidos em outros projetos. O tempo que nós dis-
púnhamos para trabalhar neste projeto era bastante limi-
tado. Eu também poderia adicionar Vaidade. Nesta fase
nós não fizemos nenhum estudo de viabilidade. Nós defini-
mos o escopo do projeto, mas nós não analisamos se seria
possível alcançar as metas estabelecidas. Talvez porque nós
fôssemos muito vaidosos das nossas habilidades. Talvez por-
que nós estivéssemos muito otimistas. Sei lá, talvez porque
nós não soubéssemos quão complexo o projeto viria a ser.”
“E quanto à Preguiça?” – perguntou Beth, com uma
expressão engraçada em seu rosto.
“Sim, nós também fomos muito preguiçosos. Nós não
gastamos o tempo necessário revisando os documentos do
projeto do ano anterior.”
“E quais foram os seus pecados no processo de pla-
nejamento?” – eu perguntei.
“Eu poderia dizer Ganância; eu criei o plano de ge-
rência do projeto sozinho. Eu deveria ter convidado a
todos para participar na criação do plano, especialmente
da definição das responsabilidades dos times.”
“Cheelseeeaaaaaa, Chelsea. Lynn é a próxima parada”
– o cobrador anunciou. “Seus tickets, por favor. Obrigado.”
Beth entregou nossos tickets ao cobrador e voltou-
se a Manopoulos:
“Manopoulos, a gente combinou semana passada de
discutir como foi a execução do seu projeto. No seu ponto
69
de vista, quais são as atividades mais importantes na exe-

cução de um projeto?”
Manopoulos escreveu as seguintes palavras em um
guardanapo e entregou para Beth.
Figura 1
“O que é monitoração e controle de um projeto?”

– Beth perguntou.
“Monitorar um projeto pode ser entendido como o
conjunto de ações realizadas de modo a se acompanhar o
desenvolvimento do projeto. Por meio delas checamos se o
projeto está seguindo o planejamento. Controle de projeto
são as medidas usadas para corrigir as divergências entre
o projeto atual e o planejado. Está relacionado diretamen-
te à monitoração, uma vez que a informação obtida pelo
processo de monitoração é usada pelo controle, de modo a
se tomar ações apropriadas. Há três áreas que são monito-
radas e controladas durante a execução de um projeto:
custo/cronograma, trabalho de engenharia realizado e de-
sempenho técnico do produto. Todas as áreas são necessá-
rias e complementares. Eu me dediquei bastante à medi-
ção do trabalho de engenharia, que é a área que sei mais.
Bem, pelo menos eu pensava que sabia...”
Eu percebi que Beth não entendeu bem as diferen-
ças entre monitoração e controle de projeto. Assim eu
70
criei um novo desenho em outro guardanapo (Figura 2).

Eu queria contribuir para ampliar a coleção de guardana-
pos dela. Para falar a verdade eu queria mesmo era chamar
a atenção da moça, você sabe como é…
Figura 2
“Obrigada, Nelson.” – ela agradeceu com um sorri-

so terno. “Mas o que isso significa?”
Significa que eu quero chamar sua atenção, Beth – eu
pensei. Mas não ousei dizer isso...
“Este desenho (figura 2) mostra a relação entre mo-
nitoração e controle de projeto” – eu expliquei. “O nível
desejado para o projeto é definido no plano de gerência
do projeto. O nível atual do projeto é verificado por meio
do monitoramento. Relatórios do projeto trazem os da-
dos colhidos pelos diversos times.”
“Mas como o gerente de projeto pode controlar o pro-
jeto? Quais são as ações de controle?” – Beth insistiu.
“O gerente de projeto pode controlar o projeto so-
mando mais recursos, re-alocando pessoal, mudando cro-
nogramas, ou modificando o escopo” – eu respondi. “Os
resultados das ações tomadas no projeto são também mo-
nitorados e este processo continua durante toda a dura-
71
ção de projeto. Talvez Manopoulos tenha mais a dizer

sobre isso. Como você monitorou e controlou o projeto
PATOLAB?” – eu lhe perguntei.
“No início do projeto PATOLAB,tornamos claro a to-
dos os objetivos principais do projeto, tarefas e responsabi-
lidades. Havia muitos objetivos, por conseguinte foi neces-
sário salientar quais eram os objetivos chaves e desenvol-
ver mecanismos para ajudar a rastrear o cumprimento
destes objetivos. Para facilitar a verificação de que o proje-
to estava se desenvolvendo como planejado foram criados
pontos de checagem. Monitoração está diretamente relacio-
nada à medida do progresso nestes pontos de checagem.
Como alguém já disse, se você não pode medir o progresso
você não poderá controlar o projeto (Thamhain, 1992).”
“Mas de que forma você mediu o progresso do proje-
to?” – insistiu Beth, com a sua curiosidade infinita.
“Bem, nós criamos nossas próprias métricas. As mé-
tricas usadas em PATOLAB, apesar de serem simples, fo-
ram bastante eficientes. Para verificar o estado atual do
projeto nós desenvolvemos planilhas que comparavam o
estado planejado de cada tarefa com o seu estado atual.”
“Swaaaaaaaaaampscott, Swampscott” – gritou o co-
brador. “Salem é a próxima estação!”
A região da Nova Inglaterra é muito bonita, ainda
mais no verão. Casas antigas de madeira circundadas por
muita vegetação ladeiam os trilhos. O trem (commuter
rail) liga todas as cidades do Estado de Massachusetts.
Além de ser um meio de transporte barato, é sempre pon-
tual. Cortar o Estado de ponta a ponta de trem é uma
experiência única, ainda mais se você tiver espírito aven-
tureiro e levar consigo a sua bicicleta para passear pelas
72
Chekpt 1 Chekpt 2 Chekpt 3 Chekpt 4 Chekpt 5 Chekpt 6 Chekpt 7 Chekpt 8 Chekpt 9
Planejado
An. MM 100 100 100 100 100 100 100 100 100
An. TM 50 100 100 100 100 100 100 100 100
Des. MM 50 100 100 100 100 100 100 100 100
Des. TM 50 50 100 100 100 100 100 100 100
Prog 0 0 0 25 50 100 100 100 100
Test 0 0 0 15 45 65 75 100 100
Feito
An. MM 50 100 100 100
An. TM 50 50 100 100
algumas planilhas e alguns gráficos.
Des. MM 25 50 60 100
Des. TM 15 25 50 100
Prog 0 0 0 0
Test 0 0 0 0
Figura 3
– ele falou, enquanto mostrava a seguinte tabela (Figura 3).
cidades. Manopoulos começou a tirar da sua mochila
“Aqui está um exemplo da planilha que nós usamos”
73
Manopoulos, percebendo que Beth estava confusa

com tanta abreviação, explicou rapidamente as abrevia-
ções que ele usou na sua tabela (Figura 3).
“Test significa atividades de teste, Prog, atividades
de programação, Des.TM significa projeto dos módulos
de gerência de transações, Des.MM projeto dos módulos
de gerência de reuniões, An.TM significa análise do mó-
dulo gerência de transações, An.MM análise do módulo
de gerência de reuniões. Ficou mais claro?”
“Agora sim, consegui entender” – Beth respondeu sor-
rindo. “Mas bem que você podia ter usado uma notação me-
nos chata! Mas como você sabia o estado atual do projeto?”
“O estado atual do projeto foi calculado tomando-se
por base os dados enviados pelos líderes dos times em seus
relatórios semanais. Semanalmente eu reunia toda a equi-
pe do projeto e mostrava alguns gráficos que indicavam
onde o projeto estava. Estes gráficos, fruto da compilação
dos dados enviados pelos times, davam uma idéia clara do
andamento do projeto.
Também mostravam os pontos de checagem. Dêem uma
olhada no tipo de gráfico que eu me refiro (Figura 4).”
Figura 4
74
Beth gostou do gráfico. Ela tem alma de artista, gosta

de cores, desenhos, figuras e gráficos. Eu ainda estava
curioso em saber detalhes de como ele coletou a infor-
mação usada para monitorar e controlar o projeto.
“Mas como foi criado o relatório semanal dos times e
que tipo de informação ele trazia?” – eu perguntei.
“Isso é uma longa história, Nelson. Para monito-
rar o projeto, eu pedi aos líderes que enviassem um re-
latório semanal das atividades realizadas por seus ti-
mes via e-mail. Nestes relatórios eles declaravam as ta-
refas a fazer e a porcentagem das tarefas efetivamente
realizadas. Além disso, eles me escreviam sobre os pro-
blemas enfrentados, sugestões e críticas. Baseado nos
relatórios dos times, eu criava o Relatório Semanal da
Gerência do Projeto. Este relatório era apresentado aos
times todas as terças-feiras pela manhã. Eu geralmente
apresentava uma série de slides por meio de um equi-
pamento de datashow. A apresentação era planejada
para não durar mais que 15 minutos. A idéia desta
apresentação era mostrar a todos os participantes do
projeto o estado do projeto atual, os problemas que cada
time estava enfrentando e as medidas tomadas pelo ge-
rente de projeto de forma a reduzir estes problemas.
Também era uma oportunidade para coletar mais in-
formações sobre o projeto e para se discutir tópicos con-
troversos.
Nós seguimos a estrutura de tópicos (Tabela 1) pro-
posta por Thamhain (Thamhain, 1992). Aqui estão os
tópicos que nós cobrimos nas apresentações e as ferra-
mentas que nós usamos.”
75
Tabela I
Relatório da Gerência de Projetos Ferramentas usadas
Situação dos Trabalhos em andamento • Gráficos: Estado das Ati-

vidades, Estados do Pro-
jeto e Realizações dos
Times
Mudanças introduzidas • Redes de atividades e grá-
ficos de Gantt
Problemas e seu impacto • Diagramas de causa-efeito
• Matriz de solução
Progresso feito • Resumo das atividades de
time
Tópicos em abertos • Lista de tópicos para dis-
cutir
“Beverly, Montserrat é próxima parada” – o cobra-

dor anunciou.
A cada parada do trem embarcavam pessoas interes-
santes. Chamou-me a atenção uma senhora já idosa, por
volta dos seus sessenta anos, que trazia um patinete do-
brável a tiracolo. Ela se sentou próximo ao nosso grupo e
nos cumprimentou amigavelmente. Nós a cumprimen-
tamos e Manopoulos continuou a sua explicação:
“Como você pode imaginar, as apresentações não co-
briam apenas o controle e monitoração do projeto, mas
também a adaptação do projeto a riscos emergentes. Eu
lhe explicarei sobre adaptação do projeto outro dia, por
hoje é melhor que só falemos em execução de projeto.
Todas as apresentações foram planejadas para conter al-
guns slides preparados e apresentados pelo time de Garan-
tia de Qualidade. A idéia era que o projeto tinha de evo-
luir seguindo o plano, porém com qualidade. O gerente de
76
projeto e time de garantia de qualidade trabalharam jun-

tos para fazer esta apresentação útil para todos os times.”
Beth olhou para o guardanapo (Figura 1) e notou
que Manopoulos ainda não havia falado nada sobre a ga-
rantia da qualidade. “Manopoulos, como vocês lidaram
com garantia de qualidade?”-perguntou Beth.
“Para reduzir a quantidade de retrabalho, nós tenta-
mos gerenciar o projeto com qualidade. O método mais
usado para assegurar a qualidade do processo de desenvol-
vimento de produto é o modelo PDCA (Planeje(Plan),
Faça(Do), Confira(Check), Atue(Act)). Eu descreverei as
idéias básicas de PDCA brevemente (Clausing, 1994; et
de Shiba al.1994). O modelo de PDCA é composto de
quatro sucessões de ações definidas pelo verbos Planejar,
Fazer, Conferir e Atuar. A parte de “PLANEJAR” do
PDCA se refere à definição de metas e objetivos. No proje-
to PATOLAB o planejamento global foi descrito pelo pla-
no de Gerência do Projeto. A parte “FAZER” está relacio-
nada ao trabalho desenvolvido. Todas as semanas nós tí-
nhamos vários times trabalhando em paralelo nas diver-
sas atividades. A parte “CONFERIR” está relacionada à
monitoração de atividades e a parte “ATUAR” está relacio-
nada às atividades de controle de projeto. No projeto PA-
TOLAB a atividade de “CONFERIR” era realizada con-
juntamente pelo gerente de projeto e pelo time de garantia
de qualidade. O relatório semanal dos times era a ferra-
menta usada para conferir se o projeto estava seguindo o
planejamento. Baseado nestes relatórios, o gerente tomava
duas ações diferentes (a parte “ATUAR” de PDCA) todas
as semanas: ações de reativas e ações pró-ativas. Ações rea-
tivas estavam relacionadas com a melhoria do processo de
77
desenvolvimento e com o melhoramento do plano de ge-

rência de projeto para o próximo produto. Baseado no
que os líderes dos times realçavam como sendo seus princi-
pais problemas, o gerente de projeto poderia alocar pessoal
de modo a ajudar os times em dificuldades ou programar
cursos sobre tópicos específicos. O relatório semanal tam-
bém incluiu as sugestões de todos os integrantes do projeto.
Estas sugestões ficaram registradas de modo a melhorar o
plano de gerência de projetos do próximo ano. A ação pró-
ativa estava relacionada a modificações no planejamento.
Durante o ciclo de vida do projeto PATOLAB foram fei-
tas várias modificações no plano original.”
Manopoulos deu para a Beth o seguinte desenho (Fi-
gura 5) que resume as suas explicações sobre PDCA.
Figura 5
78
“Parece-me que a criação de um catálogo de lições

aprendidas foi um subproduto da execução de projeto”
– eu disse.
“Exatamente! O modelo de PDCA era muito efe-
tivo para assegurar qualidade no desenvolvimento do
processo. Foram três os resultados básicos alcançados
pelo uso do PDCA: a melhoria do processo de desen-
volvimento, criação de um catálogo de lições aprendi-
das e aperfeiçoamento do plano de gerência do projeto.
A melhoria do processo de desenvolvimento foi alcan-
çada por meio de ações reativas, utilizadas para asse-
gurar que o projeto seguisse o planejamento. Todas as
semanas quando havia uma mudança no modo como o
gerente de projeto estava monitorando e/ou controlan-
do o projeto, estas mudanças eram incorporadas ao re-
latório semanal da gerência de projeto e o catálogo de
lições aprendidas era atualizado. Eu, como gerente, tam-
bém tive que fazer muitos ajustes no plano ao longo do
projeto. Os ajustes do plano de gerência do projeto são
exemplos de ações pró-ativas. Eu tenho um outro dese-
nho que mostra isto de um modo mais claro. Deixe-me
ver, aqui está (Figura 7). Beth, neste desenho a sigla
FFA significa ações pró-ativas, e FBA significa ações
reativas.”
79
80
Figura 7- Os ciclos de PDCA (Clausing, 1994) (Shiba et al., 1993)

Nós estávamos chegando ao nosso destino. Beth

guardou rapidamente tudo em sua mochila: guardana-
pos, desenhos, refrigerante, biscoitos e a revista.
“Mancheeeeeestaaaah, Manchester-by-the-sea!” – o
cobrador anunciou.
81
1) Alguém uma vez disse “diga-me como você

vai medir meu esforço e eu lhe falarei como
eu vou me comportar”. O que pensa você
disto?
2) Quando nós estávamos andando de bici-
cleta, eu perguntei a Manopoulos sobre os
aspectos negativos dos relatórios dos times.
Ele disse:
“Um ponto negativo para acentuar
aqui é que o relatório semanal às vezes era
criado sempre pela mesma pessoa de cada
time. Às vezes as informações do relatório
semanal refletiam apenas a sua opinião
pessoal no lugar da opinião do time. Ou-
tro aspecto negativo do relatório semanal
é que às vezes as sugestões e comentários
não eram tão construtivos. Alguns times
entenderam mal a natureza dos relatórios
e criticavam o trabalho feito pelos outros
times de um modo inesperado. Em suma,
usavam o relatório como instrumento de
vingança! Eu, como gerente do projeto, tive
que filtrar estes comentários em nossa apre-
sentação semanal para evitar piorar o ní-
vel de conflito entre times.”
83
O que pensa você da idéia de relatório semanal

dos times? Você alguma vez tentou monitorar e con-
trolar um projeto? Como você tratou os dados do pro-
jeto?
3) Quais foram os pecados capitais realizados no projeto
PATOLAB, no seu ponto de vista?
84
Referências
[Amaral , 2000] Amaral, J.A.A (2000) Project

Management in Distributed Collaborative
Environment: The ieCollabCase Study ,
MIT MSc. Thesis, Ocean Engineering
Dept.
[Thamhain, 1992] Thamhain, H.J. (1992).
Engineering Management: Managing effec-
tively in technology-based organizations.
New York, USA: Wiley Series in Engine-
ering and Technology Management.
[Shiba et. al. 1993] Shiba S., Grahan A. and
Walden D. (1993). A New American
TQM: Four Practical Revolutions in Ma-
nagement. Portland, USA: Productivity
Press.
[Clausing, 1994] Clausing, D.(1994). Total
Quality Development: a step-by-step guide
to world-class concurrent engineering. New
York, USA: ASME Press.
[Hornby, 1995] Hornby A. S., Oxford Ad-
vanced Leaner’s Dictionary, Oxford Uni-
versity Press, New York, USA
85
CAPÍTULO VI ADAPTAÇÃO DO
PROJETO
Estudo de Caso 04
“Perseverar é tornar o impossível
possível”
“Qualquer problema que enfrenta-

mos não é tão importante quanto
nossa atitude em relação a ele, isto
é que irá determinar nosso sucesso
ou fracasso”.
Norman Vincent Peale
H oje é dia 3 de julho. Os três mos-

queteiros (Beth, Manopoulos e eu) estamos
preparando nosso barco para nos unirmos
amanhã à flotilha de embarcações que parti-
cipará dos festejos de Celebração do Dia 4
de julho (Dia da Independência dos EUA)
no rio Charles. Estamos terminando de lim-
par o convés, aduchar os cabos e remendar
algumas velas. O nosso barco, o “Moleza”,
tem 34 pés, um único mastro. Nós já demos
uma volta ao redor do mundo com este bar-
co valente, mas isso é outra história que eu
posso lhe contar outro dia, quando você ti-
ver tempo. Está muito quente e úmido, por
isso nós decidimos dar um tempo nas ativi-
dades marinheiras e beber um pouco em um
bar próximo que fica situado no meio do Es-
89
planade Park, próximo ao Hatch Shell. Enquanto nós

estávamos esperando pela comida e refrigerantes, Beth
perguntou a Manopoulos sobre o seu projeto.
“Manopoulos, eu estou curiosa sobre o que aconte-
ceu com o projeto de PATOLAB. Na última vez que nós
nos encontramos você me falou sobre os assuntos relacio-
nados à Execução do Projeto. Você ficou de me explicar o
modo que você lidou com as mudanças, com os imprevis-
tos que ocorreram ao longo do projeto.”
“Bem” – respondeu Manopoulos, “isso tem que ver
com o que eu chamo de Adaptação de Projeto. Eu posso
dizer que a Adaptação de Projeto englobaria as seguintes
atividades:”
Manopoulos escreveu as seguintes atividades em um
guardanapo e entregou à Beth.
Figura 1
“O que você quer dizer por responder a problemas

emergentes?” – eu perguntei.
“Toda vez que alguma mudança significativa acon-
tecia, todos os membros dos times eram avisados quanto
ao impacto desta mudança. Por exemplo, olhe para este
desenho (Figura 2). Ele mostra claramente a mudança
na rede de atividades de projeto.
90
Figura 2
91
Esta figura foi usada por mim em uma reunião se-

manal para mostrar a todos os integrantes do projeto as
mudanças realizadas. Neste caso específico eu usei este
desenho para mostrar a todos que ao invés de realizar-
mos dois esforços de integração de código nos realizaría-
mos apenas um esforço, ao final do projeto. Essa mudan-
ça foi baseada nas sugestões dos times de desenvolvimento.
Os desenhistas e programadores haviam sugerido em seus
relatórios semanais que seria melhor codificar as funções
de Gerência de Transações e Gerenciamento de Reuniões
ao mesmo tempo, porque isso reduziria os problemas de
integração entre os dois módulos. A sugestão foi aceita
por mim e a modificação de cronograma foi implemen-
tada e apresentada a todos.
Note que as sugestões dos desenhistas e programadores
foram baseadas em um melhor entendimento dos proble-
mas técnicos envolvidos na criação do software. À medida
que o nível de entendimento aumentava gradualmente, o
planejamento ficava mais preciso.”
“O que você quer dizer com um melhor entendimen-
to de problemas técnicos?” – Beth perguntou curiosamente.
Fazia um calor infernal naquela tarde, estávamos famintos
e sedentos. Ofereci a Beth batatas fritas e refrigerante, e
ela aceitou prontamente.
Manopoulos alheio ao calor e ao que acontecia à sua
volta continuou o seu discurso.
“A maioria dos projetos é complexa. No início do
projeto é impossível prever em detalhes todas as ativi-
dades envolvidas. Eu, como gerente, criei um plano de
desenvolvimento baseado no que sabíamos sobre o pro-
92
duto desejado no começo do projeto. O problema é que,

quando o plano do projeto foi concebido, nem eu e nem
ninguém tinha uma visão clara de todas as tarefas en-
volvidas e de todas as dificuldades técnicas que aconte-
ceriam. Com o desdobramento do projeto, os times fo-
ram descobrindo atividades novas que deveriam ser
acrescentadas ao projeto. Nós sabíamos o que fazer, mas
nós não tínhamos uma idéia clara de como fazer. Por
exemplo, nós sabíamos que o software teria três partes
principais, a parte de rotinas de entradas de dados, o
que nós chamamos simplesmente de parte do “Cliente”,
a parte de rotinas de negócios, que nós apelidamos de
parte do “Servidor” e a parte do “Banco de Dados”.
Esta última parte envolvia não só a criação de rotinas
de acesso e atualização do Banco de Dados, mas tam-
bém a criação de um banco de dados propriamente dito.
Porém nós não estávamos seguros sobre as ferramentas
que nós iríamos usar para construir cada parte. À me-
dida que o projeto evoluía, o time de Análise de Reque-
93
rimentos e o time de Projetistas definiam o sistema em

detalhes, as interfaces a criar e as ferramentas a usar.
A parte “Cliente” foi dividida em três componentes: Cliente-
GUI (Interface Gráfica do Usuário), Cliente-Classes em
Java, e Interface Cliente-CORBA. A parte “Servidor”
foi dividida em dois componentes: Interface Servidor
CORBA e Classes do Servidor Java. Finalmente, a parte
“Banco de dados” foi dividida em Interface JDBC/SQL
e Banco de Dados Oracle.”
Manopoulos nos mostrou o seguinte desenho (Fi-
gura 3):
Figura 3
94
“Dividir os sistemas em componentes torna mais

fácil a compreensão e mais simples o gerenciamento.
Uma vez que o sistema foi dividido, nós dividimos os
programadores em cinco times (Figura 4). Tentamos
fazer a divisão em times de modo a casar as habilida-
des individuais de cada programador com a dificulda-
de do módulo.”
Figura 4
Eu voltei a olhar para a figura no guardanapo (Figura 1).

Acredito que entendi as idéias de Manopoulos sobre “res-
ponder problemas emergentes”. O que não estava claro
95
para mim era o conceito de mitigar riscos emergentes.

Nós tínhamos discutido o seu plano de mitigação de ris-
cos há algum tempo (Estudo de Caso 01), eu me recordo
que era um plano bastante razoável:
“O que você quer dizer por mitigar riscos emergen-
tes? Havia riscos que não foram cobertos pelo seu plano
de mitigação de riscos?” – eu perguntei atônito.
“Se eu tivesse uma bola de cristal naquele momento,
minha vida seria muito mais fácil. Sempre há algo de novo
surgindo, algo inesperado, algo que você não estava prepa-
rado para enfrentar” – respondeu Manopoulos. “Você pode
dar um exemplo?” – Beth perguntou.
“Ok, Beth, eu darei um exemplo de como nós mi-
tigamos os riscos emergentes. Todas as semanas os lí-
deres de time enviavam um relatório com as ativida-
des que deveriam ser feitas naquela semana, o que foi
efetivamente realizado, problemas e sugestões. Basea-
do na avaliação deles, o gerente do projeto (eu, diga-
se de passagem) listava os riscos emergentes e traba-
lhava para descobrir uma solução para eles. Por exem-
plo, olhe para os riscos emergentes listados pelos times
na nona semana do projeto.” Ele nos mostrou a se-
guinte tabela (Tabela 1):
Tabela I
Problemas Assuntos discutidos & Riscos Emergentes

da semana 09
(1) Controle • Os líderes dos times não passavam informa-

de projeto ções quanto ao andamento das atividades ao
ineficiente gerente do projeto
• Ignorância sobre os problemas dos times
96
• Falta de coordenação e controle de atividades

com o time do México
• Liderança pobre e falta de habilidade para ad
ministrar conflitos
• Pouco envolvimento dos líderes dos times em
atividades de planejamento/controle
• Falta de interesse dos desenvolvedores no cro
nograma
• Dificuldades em mitigar os riscos, até mesmo
os que já haviam sido identificados
(2) Comunicação • Todo o tipo de problemas de comunicação entre

inadequada os times situados em outros países e o time
local (times dos E.U.A. x time de México x time
do Chile). Problemas de comunicação entre ti-
mes (time de Analistas x time de Projetistas) e
entre os membros de cada time
(3) Dificuldades • Dificuldade para definir o trabalho em detalhes

Técnicas • Falta de conhecimento em banco de dados e
middleware (Corba, JDBC, Client/Server)
• Muitas mudanças de última hora nas especi-
ficações
(4) Falta de • Falta de reconhecimento pelo trabalho realizado

motivação • Pouco crescimento profissional
• Vários membros dos times do México e E.U.A.
abandonaram o projeto
• Ausência de um sistema de recompensa /punição
(5) Falta de • Indiferença e apatia

comprometimento
(6) Conflito e • Pouca confiança mútua

confusão • Cooperação pequena entre times
• Nenhum controle dos líderes dos times sobre
seus subordinados
• Compartilhamento ineficiente de conhecimento
97
“Ok, mas o que fez você quanto a isso?”, eu perguntei.

“Baseado nas informações disponíveis, eu e o time
de Garantia de Qualidade desenvolvemos um diagrama
de causa-efeito para entender as causas principais dos
problemas.” – Manopoulos respondeu e sacou de um dia-
grama (Figura 5) na sua mochila.
Figura 5
98
“Uau!” – Beth disse, “que desenho bonito! Mas para

que isso serve?”
“Uma vez determinadas as raízes dos problemas (re-
tângulos hachurados), o próximo passo foi nomear pessoas
para que atacassem esses problemas. Nós criamos uma ma-
triz de solução (Tabela 2). A matriz resume as medidas
levadas a cabo de modo a endereçar os riscos emergentes.
Basicamente esta matriz mostra as raízes dos problemas,
as pessoas que foram escolhidas para atacar os problemas,
as datas estabelecidas para se alcançar resultados e a des-
crição do modo que o problema seria resolvido.”
Tabela II
Descrição Quem O que Quando Como
do Problema (Ação)
Insuficiente Gerente • Curso • 24 de • Curso de curta

conhecimento de Projeto sobre CORBA/JDBC fevereiro duração para
técnico • Palestras técnicas em • Março programadores
assuntos relacionados • Palestra
ao desenvolvimento em técnica com
ambiente de Cliente-Servidor especialista
Falta de Gerente Obrigar os líderes a enviar Toda e-mail

feedback dos de Projeto o relatório semanal Segunda-
líderes ao feira até
gerente 12:00
Falta de coor- Sub- Manter contato semanal com Toda Por

denação com gerente A o time do México Segunda- e-mail ou
o México feira até telefone
12:00
Pouca Líderes Enviar cópias de e-mails Diaria- e-mail

liderança por dos times trocados entre os times mente
parte dos para o gerente do projeto
líderes dos
times
Organização Gerente Planejar a inclusão de Sugestão Incluir no

de projeto de Projeto elementos de ligação no para catálogo de
pobre planejamento o próximo lições
projeto aprendidas
99
“Esta tabela e a figura anterior (Figura 5) que eu

mostrei a vocês dão uma visão clara dos problemas que
aconteceram na nona semana do projeto e das ações de
corretivas implementadas de modo a solucionar estes pro-
blemas. Eu mostrava figuras e tabelas deste tipo na reu-
nião semanal que fazia com todos. Isto era uma mensa-
gem clara aos times de que os relatórios semanais que
eles me enviavam eram lidos e as recomendações dos ti-
mes, levadas em conta.”
“O que você quer dizer por comunicar as mudan-
ças?” – Beth perguntou enquanto olhava para o guarda-
napo rabiscado por Manopoulos (Figura 1). Eu estava
sentando ao lado dela tentando organizar a sua coleção
de guardanapos.
“Bem, eu não tenho muito a dizer sobre isso. Todas
as mudanças introduzidas no projeto de PATOLAB eram
discutidas com os times em nossas reuniões semanais. Os
times localizados em outros países participavam da maior
parte de nossas reuniões, às vezes por meio de Web-confe-
rência e outras vezes por Vídeo-Conferência ou Tele-confe-
rência. A matriz de solução, o diagrama de causa-efeito e
o cronograma do projeto foram colocados na parede da
nossa sala de reunião. Nós também colocamos os docu-
mentos que detalhavam as mudanças introduzidas em
nosso repositório-Web.”
“E sobre a atualização do plano de gerência de pro-
jeto, o que você pode nos contar?” – eu perguntei.
“Bem, eu tenho uma história interessante sobre isso.
Eu, como gerente do projeto, tive que fazer muitos ajus-
tes no plano durante a execução do projeto. Os ajustes do
plano de gerência de projeto são exemplos de ações pró-
100
ativas. Você se lembra da ferramenta de garantia da qua-

lidade, o PDCA que nós discutimos semana passada? Eu
lhe darei um exemplo de como isso funcionou. Durante
as semanas 10, 11 e 12 o projeto paralisou.”
Ele nos mostrou a seguinte figura (Figura 6).
Figura 6
“Por que o projeto paralisou?”, perguntou Beth in-

crédula.
“As razões principais para uma paralisia de projeto
são falta de foco, de direção e de prioridades claras (Lewis,
1998). Em nosso caso nós sofremos dos três problemas
durante as semanas 10, 11 e 12 de projeto. Primeiro,
tivemos os problemas de falta de direção e prioridades
claras. O líder do time de programadores teve um pro-
101
blema pessoal sério durante a semana 10 e viajou repen-

tinamente para a Índia, não tendo tempo de definir ta-
refas aos líderes de programação. Só para relembrar, nós
tínhamos três líderes de sub-times: um responsável pelo
desenvolvimento do módulo “Servidor”, outro responsá-
vel pelo módulo “Cliente” e outro responsável para o
módulo “Banco de dados” (Figura 4). Estes 03 líderes
eram subordinados ao líder do time de programação.
O líder do time de programação não pôde enviar
qualquer relatório ao gerente do projeto. Como o time de
programação não tinha ninguém designado para assu-
mir as atividades do líder dos programadores em sua
ausência, o caos se estabeleceu. Os programadores nor-
malmente executavam as tarefas dadas pelos líderes dos
sub-times, mas estes não tiveram a iniciativa para se reu-
nir para dividir as tarefas entre si. Eles não definiram as
prioridades claramente, o que causou o segundo proble-
ma, a perda do foco. Uma vez que todos os programado-
res também estavam envolvidos em outros projetos, quan-
do eles perceberam este problema simplesmente passaram
a se dedicar mais a outros projetos. Conseqüentemente
quase nenhum progresso foi feito durante as semanas 11
e 12 em termos de programação. Em contrapartida, foi
feito um bom progresso em termos de controle do projeto.
Ficou claro para o gerente do projeto que o controle po-
deria ser melhorado se fosse criado um mecanismo para
quantificar o esforço de cada time de programação. Dêem
uma olhada nesta tabela, que torna claro o mecanismo
que nós criamos para medir e informar o progresso de
cada time de programação separadamente.” Ele nos mos-
trou a seguinte tabela (Tabela 3).
102
Tabela III
Item Planejado Feito Líder
Projeto MM 2.1 100 100 A
Projeto TM 2.2 70 70 D
Cliente GUI 3.1.1 50 10 B
Cliente Classes Java 3.1.2 50 20 B
Interface CORBA Cliente 3.1.3 40 30 B
Interface CORBA Servidor 3.2.1 30 30 A
Classes Java Servidor 3.2.2 10 10 A
Interface SQL/JDBC 3.3.1 40 30 C
Projeto Banco de Dados 3.3.2 30 30 C
“O uso de um mecanismo de controle novo melhorou

o processo de desenvolvimento e ajudou resolver o proble-
ma de paralisia. Os líderes dos sub-times de programação
se tornaram mais ativos, as atividades individuais de pro-
gramação foram definidas e o projeto avançou.”
Eram quase duas horas da tarde. O Esplanade Park
estava cheio de pessoas que vinham de toda parte dos EUA
para celebrar o Dia da Independência.
Nós decidimos voltar para nosso barco e
terminar nossos arranjos. Manopoulos
nos convidou para uma caminhada em
Blue Hills na pró-
xima semana.
103
1) Eu estava pensando no que Manopoulos

me disse sobre a paralisia do projeto. Ele
disse que o líder do time de programação
não pôde enviar qualquer relatório ao ge-
rente do projeto. Eu estava pensando como
isto poderia afetar a visibilidade do projeto.
O que é visibilidade de um projeto? Como
a situação descrita anteriormente pode afe-
tar a monitoração e controle?
2) Beth me falou que para ela “responder a
problemas emergentes” e “responder a ris-
cos emergentes” é quase a mesma coisa. Eu
discordo, o que pensa você disso?
3) O que pensa você sobre “Adaptação do Pro-
jeto”? Você alguma vez trabalhou em algo
semelhante? Você pode me falar como fez
adaptações a um projeto?
4) Em PATOLAB, Manopoulos usou a ferra-
menta de Garantia de Qualidade chama-
da “diagrama de causa e efeito”. Que ou-
tras ferramentas você poderia sugerir para
ele usar?
105
Referências
[Amaral, 2000] Amaral, J.A.A (2000) Project

Management in Distributed Collaborati-
ve Environment: The ieCollabCase Study,
MIT MSc. Thesis, Ocean Engineering
Dept.
[McConnell, 1996]
McConnel,S.C.(1996). Rapid Development:
taming wild software schedules. New York,
USA: Microsoft Press.
[Lewis, 1998] Lewis, J. (1998,September/Oc-
tober). Participative leadership or pro-
ject paralysis. Women in Business, 50(5),
36-39.
107
Conclusão
Espero que você tenha se divertido len-

do sobre o Projeto PATOLAB. Escrevi este
livro sem pretensões acadêmicas, apenas re-
latei o que eu acho importante na gerência
de projetos de software. Tenha em mente que
há atividades que podem ser adicionadas ao
conjunto das atividades citadas relacionadas
à preparação, planejamento e adaptação. O
modelo apresentado é apenas uma orienta-
ção, um guia inicial. Você pode adicionar
ou suprimir atividades em função da com-
plexidade de seu projeto. Cada projeto tem
peculiaridades, mas de um modo geral, o
modelo apresentado é abrangente o bastante
para cobrir um grande número de projetos
de software.
Caso você tenha tido alguma dificulda-
de em tópicos relacionados à engenharia de
software, não se preocupe, tenha um pouco
de paciência que em breve lançarei um outro
livro sobre o assunto. Mas há inúmeros sites
interessantes sobre gerência de projetos, eu
poderia recomendar os seguintes:
109
• Uma boa dica é o site do Project Management Ins-

titute http://www.pmi.org/publictn/pmboktoc.htm Vale
a pena visitar este site, você pode inclusive fazer o down-
load de manuais e estudos.
• Outro site bem interessante é o da Carnegie Me-
llon Software Engineering Institute, http://www.sei.cmu.

edu/cmm/cmm.html, uma vez que você leu algo a res-
peito de Modelos de Maturidade de Capacidade no estu-
do de caso 01.
• Há livros de engenharia de software interessan-
tes, entre eles eu ressalto o livro do Pressman (Software

Engineering) e do Sommerville.
• Recomendo também a leitura do livro Adaptive
Software Development: A Collaborative Approach to Ma-

naging Complex Systems , de James A. Highsmith II
Várias pessoas me perguntam o que aconteceu com

Beth e Nelson. Isto é uma longa estória, talvez você fique
sabendo no meu próximo livro!
Caso você tenha comentários ou dúvidas sobre o li-
vro, por favor me escreva
jarantes@alum.mit.edu
Felicidades!
João Arantes
110
JOÃO ARANTES é graduado em Engenharia Meca-
trônica pela Escola Politécnica da USP, Mestre em
Computação e Sistemas pela COPPE-UFRJ, Master
of Science pelo MIT (Massachusetts Institute of
Technology), Doutor em Computação de Alto Desem-
penho pela COPPE-UFRJ.

O livro traz uma abordagem inovadora e criativa ao ensino de Gerência de
Projetos de Software. Ensina-se por meio de exemplos, a partir de discussões
sobre práticas certas e erradas. É uma compilação de quatro estórias em que os
personagens discutem entre si os principais aspectos envolvidos no geren-
ciamento de projetos de software. Eles comentam as ações tomadas pelo ge-

rente de um projeto de desenvolvimento de um software complexo, um ASP
(Application Service Provider). Os dados gerenciais apresentados no livro são na
verdade dados reais coletados do projeto IeCollab (Intelligent Electronic Collabo-
ration Project), projeto distribuído que envolveu 32 pesquisadores de três univer-
sidades, em três países diferentes (MIT – USA, CICESE – México e PUC
– Chile). Cada estória versa sobre uma fase pela qual o projeto passa. Os per-
sonagens, de uma maneira divertida, discutem e refletem sobre as atividades
envolvidas nas fases de preparação, planejamento, execução e adaptação de um
projeto. Procurou-se abordar as atividades de uma forma bem descontraída,
mantendo o foco apenas nos aspectos mais relevantes.
APLICAÇÃO
Livro-texto para as disciplinas "Gerência de Projetos de Software", "Gestão de
Projetos", "Gestão de Tecnologia da Informação" de cursos de Graduação
(Análise de Sistemas/Sistemas de Informação/Tecnologia da Informação), Pós-
graduação, especialização e MBA. Leitura complementar para disciplinas que
incluam atividades de planejamento, controle e execução de projetos. Leitura
recomendada para profissionais que tenham sob sua responsabilidade a gerência
de projetos de software.
ditora
i

Gerencia de Projetos de Software (Ieditora)

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Gerencia de Projetos de Software (Ieditora)

Caricato da

Copyright:

Formati disponibili

João Alberto Arantes do Amaral

João Alberto Arantes do Amaral

Publicado por Editco Comercial Ltda.

São Paulo – 2002

À memória de minha mãe, Neyde Curvo do

Como não podia deixar de ser, vou fazer um

Sobre o que é este livro

malsucedido. Espero que você se divirta acompanhando

A quem se destina este livro

Porque eu escrevi este livro

MIT nos Estados Unidos, CICESE (Centro de Investiga-

durante o dia, misturando ficção com realidade. Muitas

“O tempo gasto na reflexão é na

É verão em Boston. Meu nome é Nel-

“Meu projeto tinha por objetivo a criação de um apli-

“O.k., vamos falar um pouco sobre os pontos princi-

Ele continuou a explicação: “Todos os membros dos

pecialistas e generalistas. Um grupo de trinta e duas pes-

USA México Chile

“E como funcionou?” – eu perguntei.

O modo que nós dividimos os times nos trouxe vários

problemas enfrentados no projeto PATOLAB não foi

“Todos os integrantes dos times estavam trabalhando

Baseado no desenho que fiz nós começamos a discu-

Depois de ler esse trecho sobre o escopo do projeto

“Sim, eu suponho que sim. Nós não cobrimos as res-

“Bem, não há muito o que dizer. A maioria das nor-

Depois desta conversa ficou claro para mim que Ma-

“Nós não gastamos muito tempo revisando os do-

“E qual é a importância disso?” – eu perguntei um

1Microbob’s é uma firma que desenvolve software, feroz competidora da firma em

Nós rimos e concordamos. Sim, sempre há uma re-

ção, ou seja, um ambiente que muda pouco. O modelo de

Ele me explicou rapidamente as diferenças entre “De-

ou talvez porque naquele momento nós não tínhamos

tico. Nós dividiríamos o projeto em versões e definiría-

“Manopoulos, você pensa que seu projeto teve algum

mente o projeto deve assegurar a qualidade do produto e

“Calma Manopoulos, não se culpe tanto! Minha mãe

Tópicos para discussão

1) PATOLAB era um projeto colaborativo-dis-

6) Eu não gosto das atividades listadas na preparação para

[Amaral, 2000] Amaral, J.A.A (2000) Project

“Seres humanos são notáveis em sua

N ós fomos para “Miracle of Science”,

rando o processo de planejamento talvez nós pudésse-

Beth olhou curiosamente para o guardanapo e nos fa-

definir as medidas que você vai tomar de modo a atingir

Eu perguntei a Manopoulos se havia algo errado na

nesta tabela eram na verdade os líderes de sub-times de

Enquanto Manopoulos falava, eu pensava na diferença

Ele estava se tornando mais agitado, gesticulava ner-

comunicação eficientes. O Gerente do Projeto é o res-

“O time de Garantia de Qualidade é responsável por

previstas. Se problemas surgissem, os gerentes de conhe-

que o nome do livro é “Surely you’re joking, Mr. Feyn-

“E o que são os produtos a serem entregues ?” – eu

“A estrutura de comunicação me parece bastante boa”

“As atividades de desenvolvimento são a parte princi-

“Há vários modos de se calcular a duração de cada

então um quinto modo para o qual você está despreveni-

papel e as pôs sobre a mesa. A essa altura a nossa mesa já

“Primeiro nós definimos as categorias dos riscos e os

“Então nós demos valores de impacto aos riscos”