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
 Gerência de Projetos de Software

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
 João Alberto Arantes do Amaral

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
 Gerência de Projetos de Software

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
 João Alberto Arantes do Amaral

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
 Gerência de Projetos de Software

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
 João Alberto Arantes do Amaral

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
 Gerência de Projetos de Software

“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
 João Alberto Arantes do Amaral

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
 Gerência de Projetos de Software

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
 João Alberto Arantes do Amaral

“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
 Gerência de Projetos de Software

“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

Atividades empresariais
• Garantia de Qualidade
• Gerência de Configuração
• Gerência do Conhecimento
• 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
João Alberto Arantes do Amaral

55
 Gerência de Projetos de Software

“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
 João Alberto Arantes do Amaral

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
 Gerência de Projetos de Software

“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
João Alberto Arantes do Amaral

59
 Gerência de Projetos de Software

“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
 João Alberto Arantes do Amaral

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