Gerência de Projetos de Software

Joo Alberto Arantes do Amaral
GERNCIA DE PROJETOS DE SOFTWARE
ditora
i ditora
Gerncia de Projetos de Software
Todos os direitos desta edio reservados ao autor. Publicado por Editco Comercial Ltda. Rua Pedroso Alvarenga, 1046, 9 andar sala 95 Itaim 04531-004 So Paulo-SP Tel: (11) 3706-1492 Fax: (11) 3071-2567 e-mail: info@ieditora.com.br
So Paulo 2002
2002 AMARAL, Joo Alberto Arantes do GERNCIA DE PROJETOS DE SOFTWARE 1 edio, So Paulo: 2002. Reviso: Elina Correa Miotto Editorao: Jean Carlos Barbaro Capa: Jean Carlos Barbaro
ISBN 85-87916-42-4
PROIBIDA A REPRODUO Nenhuma parte desta obra poder ser reproduzida, copiada, transcrita ou mesmo transmitida por meios eletrnicos ou gravaes, assim como traduzida, sem a permisso, por escrito, do autor. Os infratores sero punidos pela Lei n 9.610/98. Impresso no Brasil / Printed in Brazil
Dedicatria
memria de minha me, Neyde Curvo do Amaral
Agradecimentos
Como no podia deixar de ser, vou fazer um breve agradecimento s pessoas especiais que me ajudaram direta ou indiretamente na criao deste livro. Em especial gostaria de agradecer minha amiga, a Prof. Dr. Joyce Warmkessel, do departamento de Aeronutica e Astronutica do MIT, pelo apoio e orientao que me deu no perodo em que estive nos EUA. Helena e Renato Pakter, Patrcia e Elizabeth Sikar pelos passeios de bicicleta e de trem pela Nova Inglaterra, passeios que serviram de inspirao para as estrias que vocs iro ler em breve. Agradeo tambm a meu pai, Jos Roberto e aos meus amigos Nelson e Fabienne Monnerat, Erica, Frederico Sauer, Mrcia Anjos, Maurcio Kiwielewickz , Paulo e Luisinha Atkinson pelas sugestes e por terem me ajudado ao longo de todos esses anos, em especial no perodo em que estive no MIT. Gostaria de agradecer tambm ao Prof. Pea-Mora e aos 32 estudantes do Projeto IeCollab.
ndice
Introduo
CAPTULO
I Preparao para o Projeto Estudo de Caso 01 O caminho que leva ao inferno pavimentado de boas intenes Tpicos para discusso ............................... Referncias .................................................
17 37 38
II Planejamento do Projeto Estudo de Caso 02 No h ventos favorveis para aqueles que no sabem aonde ir 43 Referncias ................................................. 63
CAPTULO CAPTULO
III Execuo do Projeto Estudo de Caso 03 Os sete pecados capitais do projeto ............................................ Tpicos para discusso ............................... Referncias .................................................
67 83 85
CAPTULO
IV Adaptao do Projeto Estudo de Caso 04 Perseverar tornar o impossvel possvel ............................... 89 Tpicos para discusso ............................... 105 Referncias ................................................. 107 Concluso .................................................. 109
Introduo
Sobre o que este livro

Este livro sobre gerncia 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 idia dar uma viso geral das fases pelas quais um projeto de software passa, desde o seu nascimento at a sua finalizao. De um modo geral, livros sobre gerncia de projetos so muito maantes, incrivelmente longos, caros, cheios de termos tcnicos, definies cansativas e metodologias sonferas. Procurei evitar tudo isso; tentei escrever um livro divertido que retratasse de uma maneira bem informal as preocupaes do diaa-dia de um gerente de projetos de software. Este livro na verdade a compilao de quatro estrias, uma sobre preparao, outra sobre planejamento, a terceira sobre execuo e a ltima sobre adaptao do projeto. Estas estrias so vividas por trs personagens. Enquanto eles curtem o vero na regio da Nova Inglaterra, EUA, eles discutem as aventuras e desventuras de Manopoulos, um gerente de projeto de software
11
malsucedido. Espero que voc se divirta acompanhando os nossos intrpidos heris em seus passeios pela Nova Inglaterra e aprenda um pouco sobre as atividades principais envolvidas na gerncia 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 ps-graduao e graduao em reas relacionadas tecnologia da informao e gerncia de sistemas de informao. Caso voc tenha conhecimentos bsicos de engenharia de software, ou j tenha trabalhado em desenvolvimento de sistemas voc ter facilidade de entender os conceitos expostos. Caso voc no tenha muita vivncia na rea, provavelmente ter um pouco mais de dificuldade, mas ainda assim conseguir entender os principais conceitos envolvidos.
Porque eu escrevi este livro

A estria da criao deste livro de certa forma curiosa. Durante o perodo em que estive no MIT (Massachusetts Institute of Technology-EUA) tive a oportunidade de trabalhar como gerente de projeto de desenvolvimento de um ASP (application service provider), em um projeto acadmico chamado IeCollab (Intelligent electronic Collaboration), conduzido pelo Prof. Feniosky Pea-Mora, do grupo de tecnologia da informao 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 Investigacin Cientfica y de Educacin Superior de Ensenada) no Mxico e PUC (Pontificia Universidad Catlica) no Chile. Foi uma experincia nica, muito interessante, o objetivo deste projeto era fazer com que os estudantes se familiarizassem com as responsabilidades dos diversos times de desenvolvimento, bem como tomassem conhecimento das peculiaridades envolvidas no desenvolvimento de um sistema por equipes situadas em pases diferentes. Aps a concluso deste curso tive a oportunidade de trabalhar como Assistente de Pesquisa (Research Assistant) e posteriormente como Assistente do Professor (Teacher Assistant) no Programa de Gerenciamento e Projeto de Sistemas (Systems Design and Management Program) do MIT, com a professora Dr. Joyce Warmkessel. Na ocasio ela me pediu que escrevesse alguns estudos de casos que pudessem ser usados pelos estudantes de ps-graduao no curso de Gerncia de Projetos que seria oferecido no prximo semestre. Escrevi os casos tendo por base dados do projeto IeCollab. Para no melindrar ningum transformei o projeto IeCollab em PATOLAB e criei uma srie de situaes que permitissem narrar o que aconteceu ao longo do projeto. Estas estrias foram escritas no vero, normalmente noite e de madrugada. Confesso que de dia s vezes conseguia escapulir de minhas obrigaes, pegar a minha bicicleta e sair com os meus amigos pedalando pelas cidades prximas. Outras vezes eu saa para velejar pelo rio Charles ou mesmo caminhar pelas colinas de Blue Hills. Os estudos de caso refletem esse perodo divertido e atribulado. De noite eu escrevia sobre coisas que havia feito
13
durante o dia, misturando fico com realidade. Muitas das situaes relatadas nos estudos de caso realmente aconteceram. Outras so pura fantasia. Enfim, foi divertido escrever os textos, mas confesso que escrever em ingls foi bem trabalhoso, agradeo Prof. Joyce pela pacincia infinita de ler os casos e tornar o texto mais digervel ao paladar americano. Enfim, os casos foram criados e usados 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 gerncia de projetos de software noite em cursos de ps-graduao. Resolvi ento 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 tiveram uma aceitao muito boa, e vrios alunos me cobraram que eu publicasse um livro sobre o assunto. Posterguei o quanto pude, dei infinitas desculpas mas no final no 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
CAPTULO
PREPARAO PARA O PROJETO

15
Estudo de Caso
01
O caminho que leva ao inferno pavimentado de boas intenes
O tempo gasto na reflexo na verdade uma economia de tempo Publius, 1 A.C.
vero em Boston. Meu nome Nelson; eu estou conversando com Manopoulos, o gerente de um projeto malsucedido. Ele est cansado e estressado. Ele trabalhou duro durante muitos meses em PATOLAB, um projeto de software distribudo e colaborativo que envolveu times localizados em trs pases diferentes. Este projeto teve vrios problemas, como a deteriorao do esforo de desenvolvimento, atrasos e custos acima do oramento. O projeto nunca atingiu seus objetivos. O time do projeto no foi capaz de integrar todos os componentes de software em um produto final. Eu estou tentando entender porque o projeto dele falhou apesar do grande esforo da equipe de desenvolvimento. Estou procurando trazer tona os seus modelos mentais de modo a entender as causas do fracasso. Comecei perguntando a Manopoulos sobre o que era o seu projeto.
17
Meu projeto tinha por objetivo a criao de um aplicativo colaborativo para ambiente WEB. Em resumo, eu poderia dizer que visvamos criar um tipo especial de software cliente-servidor que permitisse compartilhamento de documentos e comunicao. Ns pretendamos cobrar por prover este tipo de servio. 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 Mxico. Era um projeto de curto prazo que comeou em novembro de 1999 e terminou em abril de 2000. O time, composto por 32 desenvolvedores, estava geograficamente disperso: cinco no Chile, cinco do Mxico 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: preparao, planejamento e execuo. Claro que o projeto tambm sofria modificaes baseadas nos resultados da execuo. Talvez eu possa chamar isto adaptao do projeto. mais fcil se eu fizer um desenho para explicar. Este o desenho que Manopoulos me mostrou (Amaral, 2000):
Figura 1
18
O.k., vamos falar um pouco sobre os pontos principais envolvidos na preparao do projeto eu disse. Qual foi a estrutura de times que vocs adotaram para o projeto PATOLAB e quo motivados vocs estavam no incio de projeto? Manopoulos respondeu: No comeo do projeto ns estvamos muito entusiasmados e confiantes. Nossa estrutura de time era bastante boa, ns tnhamos 10 equipes trabalhando simultaneamente. Ele me mostrou a seguinte figura que representa a estrutura dos times.
Figura 2
Ele continuou a explicao: Todos os membros dos times tinham alguma formao em tecnologia da informao ou informtica de um modo geral. A maioria de ns era generalista, tnhamos idias bsicas dos processos envolvidos no desenvolvimento de software e todos sabiam ao menos uma linguagem de programao, Java. Ns tambm contvamos com um par de especialistas na rea de desenvolvimento de aplicaes do tipo clienteservidor. Enquanto Manopoulos falava eu pensava com os meu botes quo boa era a proporo entre o nmero de es19
pecialistas e generalistas. Um grupo de trinta e duas pessoas trabalhando no desenvolvimento de uma aplicao do tipo cliente-servidor e s dois especialistas neste assunto soou um tanto estranho para mim. Eu lhe perguntei 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 lderes dos times? eu perguntei. A mesma coisa, eu tambm pedi por voluntrios. Ns tivemos a liderana dos times dividida entre os pases. Por exemplo, o lder do time de Anlise era do Mxico e o lder do time de Gerncia de Negcios era do Chile, por exemplo. Ele me mostrou a seguinte tabela (tabela 1)
Tabela I
Times Nmero de participantes USA Gerente do Projeto Analistas Projetistas Programadores Testadores Gerentes de Qualidade Gerentes de Documentao Gerentes de Configurao Gerentes de Marketing Gerentes de Negcios 01 03 02 03 02 03 02 02 02 02 Mxico 01 01 01 01 01 Chile 02 02 01
20
E como funcionou? eu perguntei. No funcionou muito bem, seria melhor se o grupo inteiro das pessoas de cada pas pertencesse a um nico time. Por exemplo, no Mxico ns tnhamos uma pessoa que pertencia ao time de Analistas, outra que pertencia ao time de Projetistas, outra ao time de Gerncia de Configuraes, outra ao time de Testadores e uma moa que pertencia ao time de Garantia de Qualidade. Seria muito melhor se as cinco pessoas do Mxico pertencessem a um nico time, por exemplo o time de Gerncia de Configuraes. Essa medida daria maior poder de deciso aos times localizados fora dos EUA.
21
O modo que ns dividimos os times nos trouxe vrios problemas. Ns tnhamos 22 membros da equipe trabalhando juntos nos EUA e isto causou um desbalanceamento na estrutura do projeto. A tendncia natural era decidir nos E.U.A o que fazer e comunicar as decises aos times situados em outros pases. Isso foi realmente ruim; as pessoas que trabalhavam em outros pases no gostaram nada disso. Eu ainda me lembro do conselho do vice-presidente da empresa para mim: Manopoulos, voc vai perder os desenvolvedores do Mxico se voc no mudar esta estrutura. Voc os perdeu? perguntei curiosamente. Sim, a maioria dos membros da equipe de desenvolvimento do Mxico e do Chile deixou o projeto quando problemas apareceram. Eu estava to envolvido com os problemas dos times dos EUA que no dei a ateno devida aos sentimentos e frustraes dos nossos colaboradores estrangeiros. Bom, pelo menos voc tinha os lderes dos times para ajud-lo a resolver este problema, no tinha? Deveria ter, mas no tive. Eu deveria ter tido mais cuidado na escolha dos lderes dos times. Mas no comeo do projeto eu no conhecia muito bem a personalidade de cada um dos participantes. Se eu os conhecesse tanto quanto os conheo agora, certamente teria escolhido outras pessoas para serem os lderes de time. Em termos de liderana, ficou claro a mim desde o princpio do projeto que ns precisvamos confiar no apenas na minha capacidade de liderana, mas tambm na capacidade dos lderes de cada time. A maioria dos
22
problemas enfrentados no projeto PATOLAB no foi devido falha de medidas de gerenciamento do projeto, mas falta de liderana efetiva de cada um dos lderes dos times (Smith, 1999). A falta de liderana causou a maioria dos problemas de comunicao que ns tivemos. Os lderes dos times no se comunicavam eficientemente com os integrantes do time. Os lderes dos times no tinham uma idia clara do que os seus subordinados estavam fazendo; muitas vezes os e-mails enviados pelos lderes sequer foram respondidos pelos seus subordinados. O projeto PATOLAB tambm sofreu de falta de comunicao entre os diversos times, embora todos os membros tivessem acesso a uma variedade de ferramentas de comunicao (e-mail, repositrio Web para o projeto, ICQ, etc.). As ferramentas estavam disponveis e eram fceis de se usar; no entanto elas no foram usadas adequadamente. Para melhorar a comunicao entre times, semanalmente fazamos uma reunio, ocasio em que todos os integrantes do projeto falavam livremente sobre os problemas internos de cada time ou de problemas que os outros times estavam causando a eles. A pergunta que eu fazia mais freqentemente era se os lderes dos times tinham conversado previamente sobre os problemas comuns, e a resposta na maior parte de vezes era no. Se os lderes dos times tivessem tido mais liderana, estes problemas de comunicao teriam sido superados facilmente. Eu notei um certo tom de ressentimento na voz dele. Procurei mudar de assunto, eu no queria estress-lo ainda mais.
23
Todos os integrantes dos times estavam trabalhando apenas neste projeto? Infelizmente no, a firma tinha vrios outros projetos em andamento, quase todos estavam trabalhando em pelo menos outros dois projetos. O que mais voc fez na fase de preparao? Ns gastamos algum tempo selecionando ferramentas de software que permitissem colaborao entre os times dispersos geograficamente. Gastamos algum tempo tambm revisando documentos de projetos de anos anteriores. Ns tentamos usar as mesmas normas (standards) que ns usamos no projeto de software do ano anterior, normas da IEEE. Ns procuramos identificar os usurios finais e as necessidades deles. Gastamos tambm um bom tempo providenciando os recursos necessrios. Rapidamente eu rascunhei as atividades principais da preparao para o projeto PATOLAB e mostrei a Manopoulos (figura 3).
Figura 3 24
Baseado no desenho que fiz ns comeamos a discutir cada componente da fase de preparao para o projeto. Eu comecei lhe perguntando como foi definido o escopo do projeto. Manopoulos tinha uma idia clara do que deveria ser includo no escopo do projeto: O escopo delimita as fronteiras do projeto: quais sero as caractersticas do produto (funes e desempenho), quais so as restries de contexto, quando o projeto ser entregue, quando ser terminado, quais sero as mtricas que definiro o sucesso do projeto e quais os recursos envolvidos. Ele me mostrou um documento (Amaral et. al., 1999) com a seguinte sentena sublinhada. Este documento fazia parte da definio do escopo do projeto PATOLAB: O pacote de software far uso da Internet, permitindo colaborao entre times localizados em diferentes localizaes geogrficas. Permitir compartilhamento de documentos e reunies on-line. Caractersticas principais: Aplicao para Internet Compartilhamento de documentos Compartilhamento de aplicativos Independncia de plataforma especfica Gerenciamento de reunies Depois de ler esse trecho sobre o escopo do projeto ele ficou quieto, algo o estava perturbando. Ento eu perguntei: Voc acha que faltou algo em sua definio de escopo do projeto?
25
Sim, eu suponho que sim. Ns no cobrimos as restries de contexto. Com o desdobramento do projeto ficou claro que teramos de refinar nossa definio de escopo. Nosso escopo inicial do projeto se tornou impossvel de ser alcanada em virtude do pouco tempo de que dispnhamos. Eu sabia que a firma de Manopoulos tinha desenvolvido um projeto de software similar um ano antes. Talvez a equipe de desenvolvimento do ano anterior tivesse enfrentado problemas semelhantes. Eu lhe perguntei quo til foi revisar ou reutilizar documentos do projeto do ano anterior. Ns no tivemos muito xito reutilizando documentos e cdigos do projeto anterior. As normas e documentos usados no ltimo projeto serviram apenas como uma diretriz, um ponto de partida para o nosso planejamento. Sob este aspecto foi muito til. Porm, a reutilizao de documentos tcnicos no foi bem sucedida. Como voc sabe, em projetos de software voc quer no apenas reutilizar o cdigo, mas tambm os documentos de Anlise, de Projeto, os Casos de Teste, etc. A Anlise e Projeto no foram reutilizados em nada. Ns no reutilizamos quase nenhum cdigo porque o software desenvolvido no ano anterior continha muitos erros. Ns tentamos consertar os erros inicialmente, mas sem muito sucesso. Ns percebemos que levaria mais tempo para consertar o cdigo anterior do que construir um cdigo totalmente novo. Que chato! eu disse, mas pelo menos voc usou as mesmas normas. Conte-me mais sobre as normas.
26
Bem, no h muito o que dizer. A maioria das normas que ns escolhemos eram normas da IEEE. Foram providenciadas cpias das normas para todos os times e o time de Garantia de Qualidade teve por funo assegurar 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 Hardware 32 desenvolvedores localizados em trs pases diferentes 32 Computadores Pessoais.
Ferramentas de Desenvolvimento Java 2.0, Corba, Rational Rose de Software: Ferramentas de banco de dados Ferramentas de escritrio Ferramentas de Projeto Ferramentas de comunicao Web-repositrios Oracle MS-Word, MS-Excel, MS-PowerPoint MS-Project, Primavera, Netmeeting, ICQ, CVS, Apache
Depois desta conversa ficou claro para mim que Manopoulos seguiu uma metodologia de preparao para o projeto. Mas o projeto no foi bem sucedido apesar dessa metodologia. Eu estava curioso para saber o que poderia ter sido feito de um modo diferente. Eu lhe perguntei quais foram as deficincias principais na preparao para o projeto.
27
Ns no gastamos muito tempo revisando os documentos do projeto do ano anterior. No houve nenhuma discusso formal sobre aqueles documentos, embora vrios grupos tivessem consultado os documentos por sua prpria iniciativa. Eu mesmo li o plano de gerncia 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, ns teramos evitado incorrer nos mesmos erros. Que erros? perguntei prontamente. Por exemplo, a definio da misso do projeto. Seria muito melhor se ns tivssemos definido claramente nossas prioridades e as caractersticas desejadas do sistema antes de comear o projeto. Ns poderamos ter criado uma matriz que representasse quais eram as caractersticas mais importantes e definir quais as nossas prioridades (Figura 4). De modo a tornar mais clara a sua explicao, Manopoulos desenhou a seguinte matriz rapidamente (Highsmith 2000):
Figura 4 28
E qual a importncia disso? eu perguntei um pouco incrdulo. Isto muito importante, Nelson! Basicamente ajuda a visualizar o que deve ser alcanado, ajuda a definir quais so as caractersticas realmente importantes para a sua equipe de desenvolvimento. Em nosso caso ns queramos ser os primeiros a lanar um aplicativo desse tipo no mercado, ns queramos conquistar a maior parcela de mercado possvel. Voc sabe, a primeira verso poderia ter um nmero aceitvel de erros de cdigo, os tais bugs. Ns resolveramos esses problemas nas verses seguintes. Eu tinha l minhas dvidas quanto sua afirmao sobre erros Ento voc pensa que entregar um software com um monte de erros no problemtico? Olha, Nelson, eu acho que impossvel entregar um software que foi desenvolvido rapidamente sem defeitos. Defeitos estaro l, um fato; no h nenhum modo de se evitar isto completamente. O truque ter os defeitos sob controle. H uma relao de compromisso como em qualquer outro produto de engenharia. Em nosso caso, nossos defeitos no causariam danos srios. Ns no estvamos desenvolvendo um software que colocaria em risco a vida humana. Caramba, se os produtos da Microbobs1, depois de muitas verses ainda tm vrios bugs, por que o meu software no poderia ter nenhum?
Microbobs uma firma que desenvolve software, feroz competidora da firma em que Manopoulos trabalhava
1
29
Ns rimos e concordamos. Sim, sempre h uma relao de compromisso em qualquer projeto. Mas eu ainda estava pensando por que a misso deveria ser definida do modo que ele props e pedi a ele mais detalhes. A definio da misso muito importante. Se voc tiver uma definio clara do que a sua misso, ficar mais simples de escolher o processo de desenvolvimento (ciclo de vida). Por exemplo, no nosso caso ns no tnhamos uma idia clara de que ciclo de vida seguir. Agora eu sei que dependendo da natureza do software, um processo de desenvolvimento mais adequado. No 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 misso 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 no apenas ao objetivo que se quer alcanar, mas tambm ao ambiente em que o sistema ir operar e velocidade de desenvolvimento. Isso era uma novidade para mim. Manopoulos salientou que o modelo de ciclo de vida em cascata bastante apropriado para o desenvolvimento de aplicaes que iro operar em ambientes que mudam pouco. Ele me deu o exemplo do desenvolvimento de um sistema para monitorao de pacientes em UTI hospitalar. O software no deve ter erros, a velocidade de desenvolvimento no deve ser alta. O ambiente em que o sistema ir operar provavelmente ser um computador dedicado apenas a essa fun30
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 estria era totalmente oposta: tnhamos que ser os primeiros a chegar no mercado, tnhamos 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 diferenas entre Desenvolvimento de Software Monumental e Desenvolvimento de Software Acidental (Highsmith, 2000). Ficou claro para mim que o desenvolvimento pode se situar entre dois extremos, pode variar desde um processo totalmente definido, o assim chamado Desenvolvimento de Software Monumental at um processo totalmente catico, o Desenvolvimento de Software Acidental. Ele explicou que Modelos de Maturidade de Capacidade so mais satisfatrios para processos de desenvolvimento de software repetitivos. Para um projeto de caractersticas especiais como o PATOLAB ele usaria uma outra abordagem, chamada de Desenvolvimento Adaptativo de Software (Highsmith, 2000). Eu lhe perguntei se ele tinha esta viso clara no comeo do projeto. Infelizmente, no. Ns no definimos claramente as nossas prioridades no incio do projeto. Ns escolhemos um ciclo de vida de prototipagem no comeo do projeto e no meio do projeto ns resolvemos mudar e seguir o ciclo de vida em cascata. Realmente foi uma baguna! E ao trmino do projeto ns estvamos discutindo em qual fase do Modelo de Maturidade de Capacidade ns nos encontrvamos! Ele fez o seguinte desenho para mostrar como foi a evoluo do projeto (Figura 6). Ele tambm me falou que no foi realizado um estudo de viabilidade adequado. Eu achei estranho e perguntei o porque disso. Talvez porque ns estivssemos bastante confiantes das nossas habilidades. Talvez exageradamente otimistas
32
Figura 6
ou talvez porque naquele momento ns no tnhamos idia de quo complexo seria o projeto que ns iramos enfrentar. Se ns fssemos fazer o mesmo projeto novamente eu conduziria a realizao de um estudo de viabilidade imediatamente na fase de preparao. Deste modo ns poderamos definir um escopo de projeto mais reals33
tico. Ns dividiramos o projeto em verses e definiramos as caractersticas principais de cada verso. Manopoulos, fale me mais sobre essa idia de verses. eu perguntei curioso. Ele pensou um pouco e disse: Eu acredito ser importante definir as metas para cada verso do software. Nosso escopo inicial era muito abrangente, difcil de ser realizado em um ano. Seria melhor se ns tivssemos definido metas especficas a serem alcanadas 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 sucesso de um projeto? ele retrucou. Olha, para mim um projeto bem sucedido deve atender a um ou a todos dos seguintes critrios: cumprir os requisitos estabelecidos, ser entregue dentro do prazo estipulado, no ultrapassar o oramento previsto. Bem, evidente34
mente o projeto deve assegurar a qualidade do produto e proporcionar satisfao profissional e oportunidade de crescimento aos integrantes dos times (Highsmisht, 2000). Manopoulos pensou um pouco e disse: Talvez seja impossvel atender a todos esses critrios, talvez voc deva escolher alguns dentre eles e definilos como suas metas de sucesso. Mas eu posso lhe dizer que ns no atingimos nenhum desses critrios de sucesso plenamente. De fato, ns deveramos ter definido como medir o sucesso do projeto ainda na fase de preparao para o projeto. Manopoulos estava com uma expresso amarga, alguma coisa o estava perturbando. Eu tentei descobrir em que ele estava pensando. Que mais voc poderia me dizer sobre a preparao para o projeto? Eu penso que na fase de preparao todos os integrantes dos times deveriam ter estudado mais sobre os conceitos bsicos de desenvolvimento de software para ambiente cliente-servidor. Todos os componentes dos times sabiam programar usando a linguagem Java, mas isso no era o suficiente. Tnhamos apenas um analista no time que era especialista em Corba e Oracle. Se todos os componentes dos times tivessem as noes bsicas de arquitetura do tipo cliente-servidor isso teria evitado muitos problemas que tivemos durante o desenvolvimento do projeto. Talvez ns no tivssemos as habilidades necessrias, sei l. Talvez eu mesmo no tivesse maturidade e habilidade necessria para gerenciar um projeto daquele porte
35
Calma Manopoulos, no se culpe tanto! Minha me sempre diz que a cura para a tristeza uma boa refeio! Era hora do almoo, ns precisvamos comer algo. Decidimos que oportunamente conversaramos sobre planejamento de projeto. Manopoulos me convidou a ir a um restaurante prximo, 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
Tpicos para discusso
1) PATOLAB era um projeto colaborativo-distribudo; os desenvolvedores moravam no Mxico, Chile e EUA. O que voc faria para assegurar uma comunicao eficiente entre os times? Quais ferramentas voc usaria? 2) Manopoulos esqueceu de falar sobre a nacionalidade dos integrantes do time que trabalhava nos EUA. Os desenvolvedores eram de vrias nacionalidades diferentes tais como ndia, China, Lbano, Brasil e EUA. Voc pensa que esta diversidade poderia causar alguns problemas? Voc acha que diferenas culturais e barreiras de idioma 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 contratar? Como voc dividiria os times? 5) Talvez o modelo de fases do projeto seguido por Manopoulos seja muito simples (Figura 1). Crie um novo modelo, mais elaborado.
37
6) Eu no gosto das atividades listadas na preparao para o projeto (Figura 3). Talvez eu acrescentasse mais alguns componentes e retirasse outros. O que voc faria? 7) Manopoulos no falou muito sobre o cliente para esse tipo de aplicao. Como envolver os clientes na fase de preparao para o projeto? 8) Quais foram os maiores erros de Manopoulos na fase de preparao 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 companhia tem um catlogo de lies aprendidas de projetos anteriores? Que tipo de informao seria til de se obter de projetos prvios? 10) Voc pode explicar qual era o problema representado pela figura 6?
38
Referncias
[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., 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 managing complex systems, New York, USA: Dorset House Publishing Company. [Smith, 1999] Smith G. (1999, August). Project leadership: Why project management alone doesnt work, Hospital Materiel Management Quarterly, 21(1), 88-92.
39
CAPTULO
II
PLANEJAMENTO DO P ROJETO
Estudo de Caso
02
No h ventos favorveis para aqueles que no sabem aonde ir
Seres humanos so notveis em sua habilidade de aprender com experincia de outros, mas tambm so igualmente notveis em sua falta de vontade de fazer isso. Douglas Adams
s fomos para Miracle of Science, um bar bem rstico perto do MIT. Mesas toscas de madeira macia, janelas amplas, sempre apinhado de gente. O bar um ponto de referncia em Cambridge, para l convergem todas as tribos na hora do almoo. Ali ns nos encontramos com Beth, uma mulher notvel. Alta, bonita e esbelta, olhos verdes atentos a tudo. Ela possui uma firma prpria, especializada na fabricao de cromatgrafos. Beth e o seu pai fazem de tudo: contatam os clientes, projetam e constroem os dispositivos mecnicos e as interfaces eletrnicas, desenvolvem o software, testam as mquinas e cuidam do transporte aos clientes. Ela realmente incrvel! Beth est em Boston por um ms, em visita
43
ao seu irmo que vai se casar em breve. Ns trs nos sentamos a uma mesa perto da janela. Manopoulos e eu pedimos sanduches; Beth pediu uma salada. Todos pedimos cervejas. Afinal sexta-feira e ningum de ferro. Enquanto ns espervamos, Beth perguntou a Manopoulos 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 intenes? Pois , ns tnhamos um time de desenvolvedores muito bom e planejamos muito bem; porm, no conseguimos entregar o projeto no prazo. A gente planejou, programou, pelejou, pelejou, mas no teve jeito, a vaca caminhou firme e resolutamente para o brejo. Manopoulos chamou o garom Uma cerveja a mais, por favor! Isto era uma coisa que a Beth simplesmente no conseguia entender. Como 32 desenvolvedores no conseguiram criar um produto? Mas por que vocs falharam? ela perguntou incrdula. O que deu errado? Eu lhe falei que ns tnhamos discutido os assuntos relacionados preparao para o projeto pela manh. A preparao para o projeto me parecera um tanto problemtica. Eu lhe falei brevemente sobre os problemas que Manopoulos teve escolhendo os lderes de time, a reutilizao inadequada de documentos e cdigos do projeto de software do ano anterior e a falta de experincia dos times em assuntos relacionados a ambientes cliente-servidor. Eu tambm falei para Beth que nenhuma rea especfica a causa de todos problemas. Explo44
rando o processo de planejamento talvez ns pudssemos descobrir outras reas que contriburam para o fracasso. Beth normalmente no gasta muito tempo fazendo planejamento quando ela cria suas mquinas, por isso ela est interessada em aprender mais sobre planejamento. Fale-me sobre planejamento, Manopoulos. Voc pensa que isso realmente importante? ela perguntou com um olhar maroto. Manopoulos pegou um guardanapo e escreveu as seguintes palavras.
Figura 1
Beth olhou curiosamente para o guardanapo e nos falou que ela tinha lido ontem uma frase assim: no h nenhum vento favorvel para aqueles que no 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 caudaloso que separa Cambridge de Boston. As cervejas chegaram e eu perguntei a Manopoulos como era a estrutura de times adotada. Ele sacou da sua pasta uma tabela que mostrava a constituio dos dez times (tabela 1)
Tabela I
Times Gerente de Projeto Gerentes de Negcios Gerentes de Marketing Analistas Projetistas Gerentes de Configurao Garantia da Qualidade Gerentes de Conhecimento Programadores Testadores Nmero de Pessoas 1 3 2 6 5 3 4 2 3 3
Eu perguntei a Manopoulos se havia algo errado na composio dos times. Como um projeto de software poderia ter to poucos programadores? Em nosso projeto, todo o mundo tinha por segunda funo ser programador. Os trs programadores mostrados
46
nesta tabela eram na verdade os lderes de sub-times de programao. Um liderava o desenvolvimento das GUI, o segundo conduzia o desenvolvimento das classes em JAVA e o terceiro liderava a criao do Banco de Dados, ele explicou. Beth estava surpresa. Ela nunca havia trabalhado com tantos desenvolvedores em um nico projeto. Ela tambm 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 membros do projeto. Respondendo sua segunda pergunta em primeiro lugar, as responsabilidades estavam definidas no plano de gerncia de projeto (Amaral et. al., 1999). Bem, eu vou te dizer as responsabilidades de cada time rapidamente, pois sei de cabea. O time de Gerncia de Marketing o responsvel por identificar as caractersticas de mercado, tendncias de tecnologia, necessidades dos clientes e estratgia de propaganda. O time de Gerncia de Negcios analisa os competidores no mercado e desenvolve a estratgia competitiva. O time de Gerncia de Negcios responsvel tambm por definir as caractersticas desejveis para o produto baseado nas necessidades de mercado. Os Gerentes de Negcios trabalharam conjuntamente com os Gerentes de Marketing a maior parte do tempo.
47
Enquanto Manopoulos falava, eu pensava na diferena entre as responsabilidades do time de Gerncia de Marketing e do time de Gerncia de Negcios. Parecia-me que ambos os times tinham responsabilidades complementares. Bem, eu preferi no dizer nada e deixar que Manopoulos falasse.
Ele estava se tornando mais agitado, gesticulava nervosamente. Era fcil perceber que ele gostava de seu trabalho. Do que eu gosto? Sem dvida dos olhos verdes de Beth, mas isso outra histria As cervejas chegaram finalmente nossa mesa. O fator cerveja fez Manopoulos falar mais rapidamente: O gerente de projetos o responsvel pela organizao, planejamento, monitorao e controle do projeto. O gerente de projetos responsvel pela criao do Plano de Gerncia do Projeto e por tomar as medidas necessrias para assegurar que o plano seja seguido. Ele tambm o responsvel por alocar recursos para os times de acordo com a necessidade, dando o apoio necessrio, coordenando as atividades e mantendo canais de
48
comunicao eficientes. O Gerente do Projeto o responsvel pela entrega de um produto de qualidade, dentro do prazo e do oramento. Os Analistas so os responsveis por traduzir as metas dos Gerentes de Negcios em requerimentos de software. O time usa vrias ferramentas (por exemplo os diagramas de Uso de Casos da UML) para especificar as funcionalidades desejadas para o sistema. Os analistas interagem bastante com os clientes, procurando entender as suas necessidades. A responsabilidade principal do Time de Projetistas detalhar os requerimentos do software, definidos pelo time de Anlise, de forma a dar condies ao time de Programadores de criar o cdigo. Os projetistas usam ferramentas tais como o Rational Rose, Diagramas da UML etc. O papel do Time de Programadores criar cdigo de qualidade, bem documentado, conciso e que siga fielmente o que foi estabelecido pelos Projetistas. A responsabilidade principal dos testadores descobrir erros e verificar se o programa opera da forma desejada. Casos de teste so ferramentas utilizadas para identificar erros. Eu confesso que a essa altura do campeonato eu j estava quase dormindo. Eu j havia estudado desenvolvimento 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 graduao. A propsito, ela Fsica. Finalmente, meu hambrguer com queijo chegou e minha vida comeou a fazer sentido novamente. Manopoulos continuou o seu discurso:
49
O time de Garantia de Qualidade responsvel por conduzir as inspees, revises de projeto e auditorias. O time responsvel por criar o plano de garantia de qualidade. Neste ponto eu o interrompi e fiz um comentrio: Manopoulos, o time de Garantia de Qualidade responsvel 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 Gerncia de Conhecimento e de Gerenciamento de Configuraes. Manopoulos explicou: O time de Gerncia de Conhecimento o responsvel por manter o repositrio WEB do projeto e por definir o formato padro para os documentos de projeto. Os gerentes de conhecimento conferem diariamente o contedo do repositrio WEB de forma a assegurar que os documentos estejam seguindo o padro estabelecido e verificar se os mesmos foram publicados nas datas
50
previstas. Se problemas surgissem, os gerentes de conhecimento contatariam os outros times e informariam o gerente de projeto. O time de Gerncia de Configuraes controla e armazena os produtos que so gerados pelo diferentes times e prontamente informa todos os integrantes dos times do estado atual do software (i.e. mudanas, verso, 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 segurana, evita que qualquer documento/cdigo seja perdido ou apagado acidentalmente. Este time tambm responsvel por prevenir atualizaes simultneas de cdigo e por notificar os programadores de erros que foram consertados (Humphrey,1990). Beth gostou do modo que Manopoulos definiu as responsabilidades dos times. Tudo parecia to claro a ela. Mas por que voc teve problemas em explicar as responsabilidades aos membros dos times? ela lhe perguntou. Bem, sei l, a definio 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. Quando voc divide um grupo em times pequenos h uma tendncia natural de cada time se especializar em seu prprio trabalho e se esquecer da otimizao 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 youre joking, Mr. Feynman: Adventures of a Curious Character. Preciso conferir o nome do livro; Richard Feynman um fsico, ganhador do prmio Nobel. Ele foi chamado para descobrir o que deu errado com o projeto do nibus Espacial Challenger. Como voc sabe, ele descobriu aquele problema com os anis de vedao, os tais O-rings. Mas ele tambm percebeu (e no gostou) que os times que construram a astronave no trabalharam de um modo muito integrado. Eles otimizaram o prprio trabalho em detrimento da otimizao do produto final. Bem, em um projeto monstruoso assim, bastante possvel que os desenvolvedores no tivessem tempo para falar com os membros de outros times Mas eu achei esta desvantagem do trabalho segmentado bem interessante. engraado como os mesmos tipos de problemas esto sempre presentes em qualquer projeto, independente 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 so requerimentos de performance. Em geral, ns podemos dizer que requerimentos de performance so as caractersticas desejadas para o produto final. Em projetos de software, as caractersticas desejadas podem ser definidas em termos de portabilidade, velocidade, tipo de interface grfica, caractersticas do banco de dados, arquitetura cliente-servidor, recursos multimdia, interfaces com outros sistemas e uso da Internet, ele respondeu.
52
E o que so os produtos a serem entregues ? eu perguntei. So os componentes principais do projeto. Em projetos de software os produtos a serem entregues so os cdigos, os documentos tcnicos e o guia do usurio. Eu nunca trabalhei com times situados em pases diferentes observou Beth. Qual foi a estrutura de comunicao que voc usou? A comunicao diria entre times foi feita por meio de e-mails e pelo uso do software ICQ. Videoconferncia e teleconferncia foram usados raramente devido aos custos financeiros envolvidos. Ns definimos os seguintes mecanismos para reportar o progresso feito:

Reunies semanais de todos os componentes dos times com o gerente de projeto. Todos os relatrios escritos foram colocados no repositrio de projetos na Web. Os documentos seguiram o formato especificado pelo time de Gerncia do Conhecimento. Tambm foram colocados na Web todos os comentrios e discusses sobre os documentos. Foi pedido aos lderes de cada time que lessem os comentrios e que os discutissem com o gerente de projeto nas nossas reunies semanais. Inspees e revises conduzidas pelo time de Garantia de Qualidade Recomendaes do gerente de projeto. Estas recomendaes eram fruto de nossas reunies de quinta-feira e eram enviadas a todos via e-mail. Palestras de curta durao sobre as atividades desenvolvidas por cada time.
53
A estrutura de comunicao me parece bastante boa eu disse, e Beth concordou. Beth tem muita experincia em identificar as atividades envolvidas na criao de um produto tangvel como um cromatgrafo. Ela disse a Manopoulos que estava curiosa em saber quais eram as atividades principais envolvidas no desenvolvimento de software, um produto intangvel. Projetos de software envolvem atividades de desenvolvimento, apoio ao projeto e atividades empresariais (tabela 2).
Tabela II
Atividades de desenvolvimento

Anlise Projeto Codificao Teste Gerncia de Projeto Garantia de Qualidade Gerncia de Configurao Gerncia do Conhecimento Gerncia de Negcios Gerncia de Marketing
Atividades de Apoio de projeto
Atividades empresariais
As atividades de desenvolvimento so a parte principal do processo de criao de software. So as tarefas tcnicas: anlise dos requerimentos, projeto, codificao e teste. As atividades de apoio ao projeto so atividades que ajudam a organizar o processo de desenvolvimento. Uma vez que ns definimos quais so as atividades, calculamos a durao delas e criamos a rede de atividades. Neste momento, ele abriu sua maleta e nos mostrou o seguinte desenho (Figura 2). Beth perguntou como ele calculou a durao de cada atividade e como criou a rede.
54
Figura 2
55
H vrios modos de se calcular a durao de cada atividade, depende do seu tipo. Por exemplo, para se determinar o tamanho do cdigo a ser gerado, bastante comum se fazer estimativas atravs de Anlise de Pontos de Funo. Ns no tivemos tempo para fazer estimativas precisas. Nossa estimativa estava baseada principalmente na durao das atividades do projeto do ano anterior e em nossa experincia profissional. A rede de atividades foi criada baseada no ciclo de vida que ns escolhemos. Se voc olhar para a rede (Figura 2) poder notar que h vrias atividades planejadas para serem executadas em paralelo. Por exemplo, de modo a otimizar a utilizao de nossos recursos, ns planejamos desenvolver atividades de Anlise e de Projeto simultaneamente. As atividades de Codificao e o Teste tambm foram planejados de modo a serem realizados simultaneamente. Ns pretendamos comear a testar o software sete dias aps os programadores terem comeado a desenvolver o cdigo. Mais cervejas chegaram, deliciosamente geladas. Cambridge no vero muito quente e seco, o que fazia o nosso consumo de cerveja aumentar consideravelmente. Beth, j ligeiramente bria, olhava atentamente aquele guardanapo (Figura 1) onde Manopoulos havia escrito as atividades bsicas envolvidas no planejamento do projeto. Ela estava interessada em saber o que era mitigao de riscos. Voc ouviu falar da Lei de Murphy, Beth? eu perguntei, j meio zonzo de tanta cerveja. Sim ela disse. Se voc percebe que h quatro possveis modos nos quais algo pode dar errado, e evita estes,
56
ento um quinto modo para o qual voc est desprevenido se desenvolver prontamente! Manopoulos somou uma idia: Eu ouvi isto de um modo diferente, se voc no atacar os riscos efetivamente, eles que te atacaro efetivamente! Ns estvamos rindo muito, talvez por causa do efeito da cerveja que torna tudo mais engraado. Mas Manopoulos estava procurando algo na maleta dele. Aha, aqui esto eles! Ele retirou algumas folhas de
papel e as ps sobre a mesa. A essa altura a nossa mesa j era uma baguna total cheia de restos dos sanduches, o capacete de bicicleta da Beth, guardanapos rabiscados e agora mais essas folhas. A garonete comeou a dar sinais de que queria nos ver pelas costas. Ns pedimos mais algumas cervejas de modo a melhorar nossa capacidade de raciocnio e tornar a garonete mais feliz. Manopoulos nos mostrou em seqncia vrias tabelas e explicou que ele seguira a abordagem de Pressman (Pressman,1997) para mitigao de riscos.
57
Primeiro ns definimos as categorias dos riscos e os identificamos.

Tabela III - Itens de Risco
Lista de Riscos Riscos associados ao Tamanho de Produto Riscos associados ao Impacto Empresarial Riscos relacionados ao Cliente Riscos associados ao Processo Riscos associados Tecnologia Riscos associados ao Ambiente de Desenvolvimento Riscos associados ao nmero de pessoas e sua experincia Riscos associados ao Desempenho Riscos associados estrutura de Apoio Riscos associados ao cronograma (schedule) Abreviao TP IE CL PR TC DE SS DO AP SH
Ento ns demos valores de impacto aos riscos

Tabela IV - Valores de Impacto para os Riscos
Grau de impacto Catastrfico Crtico Marginal Desprezvel Valores de Impacto 1 2 3 4
Depois disso ns listamos todos os riscos que fomos capazes de antecipar. Numeramos e classificamos por meio das categorias definidas anteriormente. Ns tambm definimos uma probabilidade de ocorrncia para cada risco.
58
Tabela V - Riscos de Projeto

ID 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 PR PR PR PR PR DE DE SS TC TC SS SS DO TC SH Baixa Alta Mdia Alta Alta Alta Alta Baixa Alta Mdia Alta Mdia Mdia Mdia Alta 2 1 2 3 2 3 4 2 1 2 2 2 1 1 1 TP TP TP IE Alta Mdia Alta Mdia 3 2 2 1
Riscos
Categoria Probabilidade
Impacto
Estimativas imprecisas quanto ao tamanho do software a ser criado Quantia pequena de software reutilizado Excessiva quantidade de documentao a ser gerada Grande nmero de sistemas com os quais o nosso software deve ser interopervel Pouca reutilizao de documentos e cdigos do projeto anterior Inconsistncia entre sistemas diferentes Falta de treinamento em ferramentas de desenvolvimento Falta de ferramentas de software para apoiar processo de teste Falta de mtricas de produtividade Poucas ferramentas disponveis para gerenciamento de configuraes Ferramentas de software no integrveis Pouca experincia prvia em desenvolvimento de software Uso de rotinas no testadas do projeto do ano anterior Problemas de integrao com outros sistemas Desenvolvedores envolvidos em outros projetos Desenvolvedores abandonando o projeto Projeto no satisfaz todas as exigncias Problemas na implementao de funes Qualidade afetada por escorregamento no cronograma
59
E finalmente ns agrupamos os riscos, em funo do grau de impacto e da probabilidade de ocorrncia.

Tabela VI - Riscos Agrupados
Riscos ID 6,13,19 3,9,15 4,17,18 2,7,14 1,8,10 5,12,16 11 Probabilidade Alta Alta Mdia Mdia Alta Baixa Alta Impacto Catastrfico Crtico Catastrfico Crtico Marginal Crtico Desprezvel
Baseado em cada categoria definida na tabela anterior ns desenvolvemos as estratgias de mitigao. Ele nos mostrou um exemplo:
Tabela VII - Exemplo de Estratgias
Estratgia para mitigao de Riscos de Probabilidade Alta e de Impacto Catastrfico Risco 6 - Para assegurar consistncia entre sistemas diferentes, ns implementamos as seguintes medidas: Um Comit foi formado com os lderes dos times. Este comit se encontraria todas as semanas ou sempre que necessrio para administrar as mudanas que poderiam afetar outras partes do projeto Se uma reunio de um time tratasse de informao que tambm fosse pertinente a outro time, um membro do time externo deveria comparecer quela reunio. Essa medida ajudaria a manter consistncia e coerncia entre os documentos e planos. Os times de Anlise e Projeto deveriam concordar nas ferramentas comuns a serem usadas desde o comeo de desenvolvimento. Sugesto: usar UML. 60
Risco 13 Uso rotinas de projeto no testadas (do projeto do ano anterior) Ns decidimos nomear dois testadores para executar testes nos programas do projeto anterior. Todo o cdigo seria testado, mesmo que j tivesse sido testado no ano anterior. Risco 19 Qualidade afetada por derrapagem no cronograma Uma anlise crtica na viabilidade dos requerimentos deve ser feita. Os requerimentos para as Verses 1 e 2 devem ser realsticos, levando em conta a curta durao do projeto e os vrios compromissos assumidos. Um pacote de software pequeno e seguro melhor que um grande e incerto. Se ocorrer alguma derrapagem no cronograma ns cortaremos alguns requerimentos; ns no queremos sacrificar a qualidade.
Neste ponto ns todos estvamos cansados. Eu confesso que no estava prestando muita ateno ao contedo das tabelas, s na idia principal. Eu penso que Beth estava fazendo o mesmo. Eu tambm no estava certo de quo sbrios ns estvamos. Ns havamos bebido muito! Pelo menos ns concordamos em um ponto: estava na hora de voltarmos para casa! No nosso caminho de volta Manopoulos estava cabisbaixo, pensando nos possveis 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 prximos projetos de cromatgrafos. E eu pensava nos olhos verdes da Beth... Ns combinamos de andar de bicicleta de Manchester-by-the-sea at Gloucester no prximo fim de semana; talvez ns pudssemos falar sobre assuntos relacionados execuo do projeto durante o percurso.
61
Referncias
[Amaral, 2000] Amaral, J.A.A (2000) Project Management in Distributed Collaborative Environment: The ieCollabCase Study , MIT, MSc Thesis, Ocean Engineering 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 managing complex systems, New York, USA: Dorset House Publishing Company. [Limansky et al. 1999] Limansky I. et all, Master of Engineering 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 practitioners approach. New York, USA: McGrawHill. [Humphrey,1990] Humphrey W.S. (1990). Managing the Software Process, Berkeley, USA: Addison-Wesley
63
CAPTULO
III
EXECUO DO PROJETO
Estudo de Caso
03
Os sete pecados capitais do projeto O pessimista reclama do vento; o otimista espera que ele mude de direo; o realista ajusta as velas. William Arthur Ward
o 08:35 de uma manh de domingo deslumbrante. Beth, Manopoulos e eu estamos no trem, indo de Boston para Manchester. Nossas bicicletas se encontram amontoadas no final do vago, amarradas no local apropriado. Ns pretendemos andar de bicicleta o dia todo e voltar no ltimo trem antes do cair da noite. Eis o plano disse Beth. Ir at Manchester de trem, andar de bicicleta at Gloucester 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 aproximadamente cinco horas para fazer isso. No meio do caminho ns podemos fazer uma parada estratgica em Singing Beach e descansar por algum tempo na praia. Se ns ainda tivermos energia, podemos andar de bicicleta de Man67
chester at Beverly. Que tal jantar em Lynch Park? Deixeme ver, ns podemos tomar o trem das 08:04 p.m. de Beverly para Boston. O que vocs acham? Eu concordei com ela, que mais eu poderia fazer? Ela uma tima ciclista e sempre tem idias bacanas. Manopoulos estava com muito sono para protestar, de forma que este ficou sendo o plano que ns iramos seguir, aprovado agora por deciso unnime! Beth estava cheia de energia, ela abriu uma revista e comeou a ler um artigo sobre o filme Seven. Olha que interessante, aqui esto listados os sete pecados capitais (Hornby, 1995), ela passou ento a l-los um a um: Avareza: ganncia, um desejo extremo para riqueza ou ganho. Inveja : um desejo forte para ter as posses ou qualidades de outra pessoa. Glutonice: o hbito ou prtica de comer ou beber muito. Preguia: indolncia, averso ao trabalho. Luxria: lascvia, desejo desenfreado. Vaidade: auto-estima exacerbada. Ira: raiva, fria, rancor. Ela sorriu maliciosamente para mim e perguntou Qual o seu pecado favorito, Nelson? Glutonice, eu respondi prontamente, definitivamente este meu pecado favorito. E o seu, Manopoulos? Preguiiiiiiiiiiia ele respondeu enquanto se espreguiava. Bom dia, Manopoulos! troou Beth Voc pode nos contar quais foram os seus pecados capitais durante a fase preparao para o projeto PATOLAB? Manopoulos pensou por algum tempo e disse:
68
Em termos de preparao para o projeto, eu poderia dizer Glutonice. Ns tentamos morder mais do que ns podamos mastigar. Ns fomos muito ambiciosos em termos de nossas metas: ns queramos fazer tudo. Quase todos os participantes do projeto PATOLAB tambm estavam envolvidos em outros projetos. O tempo que ns dispnhamos para trabalhar neste projeto era bastante limitado. Eu tambm poderia adicionar Vaidade. Nesta fase ns no fizemos nenhum estudo de viabilidade. Ns definimos o escopo do projeto, mas ns no analisamos se seria possvel alcanar as metas estabelecidas. Talvez porque ns fssemos muito vaidosos das nossas habilidades. Talvez porque ns estivssemos muito otimistas. Sei l, talvez porque ns no soubssemos quo complexo o projeto viria a ser. E quanto Preguia? perguntou Beth, com uma expresso engraada em seu rosto. Sim, ns tambm fomos muito preguiosos. Ns no gastamos o tempo necessrio revisando os documentos do projeto do ano anterior. E quais foram os seus pecados no processo de planejamento? eu perguntei. Eu poderia dizer Ganncia; eu criei o plano de gerncia do projeto sozinho. Eu deveria ter convidado a todos para participar na criao do plano, especialmente da definio das responsabilidades dos times. Cheelseeeaaaaaa, Chelsea. Lynn a prxima parada o cobrador anunciou. Seus tickets, por favor. Obrigado. Beth entregou nossos tickets ao cobrador e voltouse a Manopoulos: Manopoulos, a gente combinou semana passada de discutir como foi a execuo do seu projeto. No seu ponto
69
de vista, quais so as atividades mais importantes na execuo de um projeto? Manopoulos escreveu as seguintes palavras em um guardanapo e entregou para Beth.
Figura 1
O que monitorao e controle de um projeto? Beth perguntou. Monitorar um projeto pode ser entendido como o conjunto de aes realizadas de modo a se acompanhar o desenvolvimento do projeto. Por meio delas checamos se o projeto est seguindo o planejamento. Controle de projeto so as medidas usadas para corrigir as divergncias entre o projeto atual e o planejado. Est relacionado diretamente monitorao, uma vez que a informao obtida pelo processo de monitorao usada pelo controle, de modo a se tomar aes apropriadas. H trs reas que so monitoradas e controladas durante a execuo de um projeto: custo/cronograma, trabalho de engenharia realizado e desempenho tcnico do produto. Todas as reas so necessrias e complementares. Eu me dediquei bastante medio do trabalho de engenharia, que a rea que sei mais. Bem, pelo menos eu pensava que sabia... Eu percebi que Beth no entendeu bem as diferenas entre monitorao e controle de projeto. Assim eu
70
criei um novo desenho em outro guardanapo (Figura 2). Eu queria contribuir para ampliar a coleo de guardanapos dela. Para falar a verdade eu queria mesmo era chamar a ateno da moa, voc sabe como
Figura 2
Obrigada, Nelson. ela agradeceu com um sorriso terno. Mas o que isso significa? Significa que eu quero chamar sua ateno, Beth eu pensei. Mas no ousei dizer isso... Este desenho (figura 2) mostra a relao entre monitorao e controle de projeto eu expliquei. O nvel desejado para o projeto definido no plano de gerncia do projeto. O nvel atual do projeto verificado por meio do monitoramento. Relatrios do projeto trazem os dados colhidos pelos diversos times. Mas como o gerente de projeto pode controlar o projeto? Quais so as aes de controle? Beth insistiu. O gerente de projeto pode controlar o projeto somando mais recursos, re-alocando pessoal, mudando cronogramas, ou modificando o escopo eu respondi. Os resultados das aes tomadas no projeto so tambm monitorados e este processo continua durante toda a dura71
o de projeto. Talvez Manopoulos tenha mais a dizer sobre isso. Como voc monitorou e controlou o projeto PATOLAB? eu lhe perguntei. No incio do projeto PATOLAB,tornamos claro a todos os objetivos principais do projeto, tarefas e responsabilidades. Havia muitos objetivos, por conseguinte foi necessrio salientar quais eram os objetivos chaves e desenvolver mecanismos para ajudar a rastrear o cumprimento destes objetivos. Para facilitar a verificao de que o projeto estava se desenvolvendo como planejado foram criados pontos de checagem. Monitorao est diretamente relacionada medida do progresso nestes pontos de checagem. Como algum j disse, se voc no pode medir o progresso voc no poder controlar o projeto (Thamhain, 1992). Mas de que forma voc mediu o progresso do projeto? insistiu Beth, com a sua curiosidade infinita. Bem, ns criamos nossas prprias mtricas. As mtricas usadas em PATOLAB, apesar de serem simples, foram bastante eficientes. Para verificar o estado atual do projeto ns desenvolvemos planilhas que comparavam o estado planejado de cada tarefa com o seu estado atual. Swaaaaaaaaaampscott, Swampscott gritou o cobrador. Salem a prxima estao! A regio da Nova Inglaterra muito bonita, ainda mais no vero. Casas antigas de madeira circundadas por muita vegetao ladeiam os trilhos. O trem (commuter rail) liga todas as cidades do Estado de Massachusetts. Alm de ser um meio de transporte barato, sempre pontual. Cortar o Estado de ponta a ponta de trem uma experincia nica, ainda mais se voc tiver esprito aventureiro 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 100 100 100 100 0 0 15 45 65 75 100 25 50 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100
An. MM
100
100
An. TM
50
100
Des. MM
50
100
Des. TM
50
50
Prog
Test
Feito 100 100 60 50 0 0 0 0 100 100 100 100
An. MM
50
100
An. TM
50
50
Des. MM
25
50
Des. TM
15
25
Prog
Test
cidades. Manopoulos comeou a tirar da sua mochila algumas planilhas e alguns grficos. Aqui est um exemplo da planilha que ns usamos ele falou, enquanto mostrava a seguinte tabela (Figura 3).
Figura 3
73
Manopoulos, percebendo que Beth estava confusa com tanta abreviao, explicou rapidamente as abreviaes que ele usou na sua tabela (Figura 3). Test significa atividades de teste, Prog, atividades de programao, Des.TM significa projeto dos mdulos de gerncia de transaes, Des.MM projeto dos mdulos de gerncia de reunies, An.TM significa anlise do mdulo gerncia de transaes, An.MM anlise do mdulo de gerncia de reunies. Ficou mais claro? Agora sim, consegui entender Beth respondeu sorrindo. Mas bem que voc podia ter usado uma notao menos 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 lderes dos times em seus relatrios semanais. Semanalmente eu reunia toda a equipe do projeto e mostrava alguns grficos que indicavam onde o projeto estava. Estes grficos, fruto da compilao dos dados enviados pelos times, davam uma idia clara do andamento do projeto. Tambm mostravam os pontos de checagem. Dem uma olhada no tipo de grfico que eu me refiro (Figura 4).
Figura 4 74
Beth gostou do grfico. Ela tem alma de artista, gosta de cores, desenhos, figuras e grficos. Eu ainda estava curioso em saber detalhes de como ele coletou a informao usada para monitorar e controlar o projeto. Mas como foi criado o relatrio semanal dos times e que tipo de informao ele trazia? eu perguntei. Isso uma longa histria, Nelson. Para monitorar o projeto, eu pedi aos lderes que enviassem um relatrio semanal das atividades realizadas por seus times via e-mail. Nestes relatrios eles declaravam as tarefas a fazer e a porcentagem das tarefas efetivamente realizadas. Alm disso, eles me escreviam sobre os problemas enfrentados, sugestes e crticas. Baseado nos relatrios dos times, eu criava o Relatrio Semanal da Gerncia do Projeto. Este relatrio era apresentado aos times todas as teras-feiras pela manh. Eu geralmente apresentava uma srie de slides por meio de um equipamento de datashow. A apresentao era planejada para no durar mais que 15 minutos. A idia desta apresentao 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 gerente de projeto de forma a reduzir estes problemas. Tambm era uma oportunidade para coletar mais informaes sobre o projeto e para se discutir tpicos controversos. Ns seguimos a estrutura de tpicos (Tabela 1) proposta por Thamhain (Thamhain, 1992). Aqui esto os tpicos que ns cobrimos nas apresentaes e as ferramentas que ns usamos.
75
Tabela I
Relatrio da Gerncia de Projetos Ferramentas usadas
Situao dos Trabalhos em andamento Grficos: Estado das Atividades, Estados do Projeto e Realizaes dos Times Mudanas introduzidas Problemas e seu impacto Progresso feito Tpicos em abertos
Redes de atividades e grficos de Gantt
Diagramas de causa-efeito Matriz de soluo Resumo das atividades de

time
Lista de tpicos para discutir
Beverly, Montserrat prxima parada o cobrador anunciou. A cada parada do trem embarcavam pessoas interessantes. Chamou-me a ateno uma senhora j idosa, por volta dos seus sessenta anos, que trazia um patinete dobrvel a tiracolo. Ela se sentou prximo ao nosso grupo e nos cumprimentou amigavelmente. Ns a cumprimentamos e Manopoulos continuou a sua explicao: Como voc pode imaginar, as apresentaes no cobriam apenas o controle e monitorao do projeto, mas tambm a adaptao do projeto a riscos emergentes. Eu lhe explicarei sobre adaptao do projeto outro dia, por hoje melhor que s falemos em execuo de projeto. Todas as apresentaes foram planejadas para conter alguns slides preparados e apresentados pelo time de Garantia de Qualidade. A idia era que o projeto tinha de evoluir seguindo o plano, porm com qualidade. O gerente de
76
projeto e time de garantia de qualidade trabalharam juntos para fazer esta apresentao til para todos os times. Beth olhou para o guardanapo (Figura 1) e notou que Manopoulos ainda no havia falado nada sobre a garantia da qualidade. Manopoulos, como vocs lidaram com garantia de qualidade?-perguntou Beth. Para reduzir a quantidade de retrabalho, ns tentamos gerenciar o projeto com qualidade. O mtodo mais usado para assegurar a qualidade do processo de desenvolvimento de produto o modelo PDCA (Planeje(Plan), Faa(Do), Confira(Check), Atue(Act)). Eu descreverei as idias bsicas de PDCA brevemente (Clausing, 1994; et de Shiba al.1994). O modelo de PDCA composto de quatro sucesses de aes definidas pelo verbos Planejar, Fazer, Conferir e Atuar. A parte de PLANEJAR do PDCA se refere definio de metas e objetivos. No projeto PATOLAB o planejamento global foi descrito pelo plano de Gerncia do Projeto. A parte FAZER est relacionada ao trabalho desenvolvido. Todas as semanas ns tnhamos vrios times trabalhando em paralelo nas diversas atividades. A parte CONFERIR est relacionada monitorao de atividades e a parte ATUAR est relacionada s atividades de controle de projeto. No projeto PATOLAB a atividade de CONFERIR era realizada conjuntamente pelo gerente de projeto e pelo time de garantia de qualidade. O relatrio semanal dos times era a ferramenta usada para conferir se o projeto estava seguindo o planejamento. Baseado nestes relatrios, o gerente tomava duas aes diferentes (a parte ATUAR de PDCA) todas as semanas: aes de reativas e aes pr-ativas. Aes reativas estavam relacionadas com a melhoria do processo de
77
desenvolvimento e com o melhoramento do plano de gerncia de projeto para o prximo produto. Baseado no que os lderes dos times realavam como sendo seus principais problemas, o gerente de projeto poderia alocar pessoal de modo a ajudar os times em dificuldades ou programar cursos sobre tpicos especficos. O relatrio semanal tambm incluiu as sugestes de todos os integrantes do projeto. Estas sugestes ficaram registradas de modo a melhorar o plano de gerncia de projetos do prximo ano. A ao prativa estava relacionada a modificaes no planejamento. Durante o ciclo de vida do projeto PATOLAB foram feitas vrias modificaes no plano original. Manopoulos deu para a Beth o seguinte desenho (Figura 5) que resume as suas explicaes sobre PDCA.
Figura 5 78
Parece-me que a criao de um catlogo de lies aprendidas foi um subproduto da execuo de projeto eu disse. Exatamente! O modelo de PDCA era muito efetivo para assegurar qualidade no desenvolvimento do processo. Foram trs os resultados bsicos alcanados pelo uso do PDCA: a melhoria do processo de desenvolvimento, criao de um catlogo de lies aprendidas e aperfeioamento do plano de gerncia do projeto. A melhoria do processo de desenvolvimento foi alcanada por meio de aes reativas, utilizadas para assegurar que o projeto seguisse o planejamento. Todas as semanas quando havia uma mudana no modo como o gerente de projeto estava monitorando e/ou controlando o projeto, estas mudanas eram incorporadas ao relatrio semanal da gerncia de projeto e o catlogo de lies aprendidas era atualizado. Eu, como gerente, tambm tive que fazer muitos ajustes no plano ao longo do projeto. Os ajustes do plano de gerncia do projeto so exemplos de aes pr-ativas. Eu tenho um outro desenho que mostra isto de um modo mais claro. Deixe-me ver, aqui est (Figura 7). Beth, neste desenho a sigla FFA significa aes pr-ativas, e FBA significa aes reativas.
79
80
Figura 7- Os ciclos de PDCA (Clausing, 1994) (Shiba et al., 1993)
Ns estvamos chegando ao nosso destino. Beth guardou rapidamente tudo em sua mochila: guardanapos, desenhos, refrigerante, biscoitos e a revista. Mancheeeeeestaaaah, Manchester-by-the-sea! o cobrador anunciou.
81
1) Algum uma vez disse diga-me como voc vai medir meu esforo e eu lhe falarei como eu vou me comportar. O que pensa voc disto? 2) Quando ns estvamos andando de bicicleta, eu perguntei a Manopoulos sobre os aspectos negativos dos relatrios dos times. Ele disse: Um ponto negativo para acentuar aqui que o relatrio semanal s vezes era criado sempre pela mesma pessoa de cada time. s vezes as informaes do relatrio semanal refletiam apenas a sua opinio pessoal no lugar da opinio do time. Outro aspecto negativo do relatrio semanal que s vezes as sugestes e comentrios no eram to construtivos. Alguns times entenderam mal a natureza dos relatrios e criticavam o trabalho feito pelos outros times de um modo inesperado. Em suma, usavam o relatrio como instrumento de vingana! Eu, como gerente do projeto, tive que filtrar estes comentrios em nossa apresentao semanal para evitar piorar o nvel de conflito entre times.
83
O que pensa voc da idia de relatrio semanal dos times? Voc alguma vez tentou monitorar e controlar um projeto? Como voc tratou os dados do projeto? 3) Quais foram os pecados capitais realizados no projeto PATOLAB, no seu ponto de vista?
84
Referncias
[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 effectively in technology-based organizations . New York, USA: Wiley Series in Engineering and Technology Management. [Shiba et. al. 1993] Shiba S., Grahan A. and Walden D. (1993). A New American TQM: Four Practical Revolutions in Management. 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 Advanced Leaners Dictionary, Oxford University Press, New York, USA
85
CAPTULO
VI
ADAPTAO DO PROJETO
Estudo de Caso
04
Perseverar tornar o impossvel possvel
Qualquer problema que enfrentamos no to importante quanto nossa atitude em relao a ele, isto que ir determinar nosso sucesso ou fracasso. Norman Vincent Peale
oje dia 3 de julho. Os trs mosqueteiros (Beth, Manopoulos e eu) estamos preparando nosso barco para nos unirmos amanh flotilha de embarcaes que participar dos festejos de Celebrao do Dia 4 de julho (Dia da Independncia dos EUA) no rio Charles. Estamos terminando de limpar o convs, aduchar os cabos e remendar algumas velas. O nosso barco, o Moleza, tem 34 ps, um nico mastro. Ns j demos uma volta ao redor do mundo com este barco valente, mas isso outra histria que eu posso lhe contar outro dia, quando voc tiver tempo. Est muito quente e mido, por isso ns decidimos dar um tempo nas atividades marinheiras e beber um pouco em um bar prximo que fica situado no meio do Es89
planade Park, prximo ao Hatch Shell. Enquanto ns estvamos esperando pela comida e refrigerantes, Beth perguntou a Manopoulos sobre o seu projeto. Manopoulos, eu estou curiosa sobre o que aconteceu com o projeto de PATOLAB. Na ltima vez que ns nos encontramos voc me falou sobre os assuntos relacionados Execuo do Projeto. Voc ficou de me explicar o modo que voc lidou com as mudanas, com os imprevistos que ocorreram ao longo do projeto. Bem respondeu Manopoulos, isso tem que ver com o que eu chamo de Adaptao de Projeto. Eu posso dizer que a Adaptao 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 mudana significativa acontecia, todos os membros dos times eram avisados quanto ao impacto desta mudana. Por exemplo, olhe para este desenho (Figura 2). Ele mostra claramente a mudana na rede de atividades de projeto.
90
Figura 2
91
Esta figura foi usada por mim em uma reunio semanal para mostrar a todos os integrantes do projeto as mudanas realizadas. Neste caso especfico eu usei este desenho para mostrar a todos que ao invs de realizarmos dois esforos de integrao de cdigo nos realizaramos apenas um esforo, ao final do projeto. Essa mudana foi baseada nas sugestes dos times de desenvolvimento. Os desenhistas e programadores haviam sugerido em seus relatrios semanais que seria melhor codificar as funes de Gerncia de Transaes e Gerenciamento de Reunies ao mesmo tempo, porque isso reduziria os problemas de integrao entre os dois mdulos. A sugesto foi aceita por mim e a modificao de cronograma foi implementada e apresentada a todos. Note que as sugestes dos desenhistas e programadores foram baseadas em um melhor entendimento dos problemas tcnicos envolvidos na criao do software. medida que o nvel de entendimento aumentava gradualmente, o planejamento ficava mais preciso. O que voc quer dizer com um melhor entendimento de problemas tcnicos? Beth perguntou curiosamente. Fazia um calor infernal naquela tarde, estvamos 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 incio do projeto impossvel prever em detalhes todas as atividades envolvidas. Eu, como gerente, criei um plano de desenvolvimento baseado no que sabamos sobre o pro92
duto desejado no comeo do projeto. O problema que, quando o plano do projeto foi concebido, nem eu e nem ningum tinha uma viso clara de todas as tarefas envolvidas e de todas as dificuldades tcnicas que aconteceriam. Com o desdobramento do projeto, os times foram descobrindo atividades novas que deveriam ser acrescentadas ao projeto. Ns sabamos o que fazer, mas ns no tnhamos uma idia clara de como fazer. Por exemplo, ns sabamos que o software teria trs partes principais, a parte de rotinas de entradas de dados, o que ns chamamos simplesmente de parte do Cliente, a parte de rotinas de negcios, que ns apelidamos de parte do Servidor e a parte do Banco de Dados. Esta ltima parte envolvia no s a criao de rotinas de acesso e atualizao do Banco de Dados, mas tambm a criao de um banco de dados propriamente dito. Porm ns no estvamos seguros sobre as ferramentas que ns iramos usar para construir cada parte. medida que o projeto evolua, o time de Anlise de Reque93
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 trs componentes: ClienteGUI (Interface Grfica do Usurio), 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 (Figura 3):
Figura 3 94
Dividir os sistemas em componentes torna mais fcil a compreenso e mais simples o gerenciamento. Uma vez que o sistema foi dividido, ns dividimos os programadores em cinco times (Figura 4). Tentamos fazer a diviso em times de modo a casar as habilidades individuais de cada programador com a dificuldade do mdulo.
Figura 4
Eu voltei a olhar para a figura no guardanapo (Figura 1). Acredito que entendi as idias de Manopoulos sobre responder problemas emergentes. O que no estava claro
95
para mim era o conceito de mitigar riscos emergentes. Ns tnhamos discutido o seu plano de mitigao de riscos h algum tempo (Estudo de Caso 01), eu me recordo que era um plano bastante razovel: O que voc quer dizer por mitigar riscos emergentes? Havia riscos que no foram cobertos pelo seu plano de mitigao de riscos? eu perguntei atnito. Se eu tivesse uma bola de cristal naquele momento, minha vida seria muito mais fcil. Sempre h algo de novo surgindo, algo inesperado, algo que voc no estava preparado para enfrentar respondeu Manopoulos. Voc pode dar um exemplo? Beth perguntou. Ok, Beth, eu darei um exemplo de como ns mitigamos os riscos emergentes. Todas as semanas os lderes de time enviavam um relatrio com as atividades que deveriam ser feitas naquela semana, o que foi efetivamente realizado, problemas e sugestes. Baseado na avaliao deles, o gerente do projeto (eu, digase de passagem) listava os riscos emergentes e trabalhava para descobrir uma soluo para eles. Por exemplo, olhe para os riscos emergentes listados pelos times na nona semana do projeto. Ele nos mostrou a seguinte tabela (Tabela 1):
Tabela I
Problemas da semana 09 (1) Controle de projeto ineficiente Assuntos discutidos & Riscos Emergentes Os lderes dos times no passavam informaes quanto ao andamento das atividades ao gerente do projeto Ignorncia sobre os problemas dos times
96
Falta de coordenao e controle de atividades com o time do Mxico Liderana pobre e falta de habilidade para ad ministrar conflitos Pouco envolvimento dos lderes 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) Comunicao Todo o tipo de problemas de comunicao entre inadequada os times situados em outros pases e o time local (times dos E.U.A. x time de Mxico x time do Chile). Problemas de comunicao entre times (time de Analistas x time de Projetistas) e entre os membros de cada time (3) Dificuldades Tcnicas Dificuldade para definir o trabalho em detalhes Falta de conhecimento em banco de dados e middleware (Corba, JDBC, Client/Server) Muitas mudanas de ltima hora nas especificaes Falta de reconhecimento pelo trabalho realizado Pouco crescimento profissional Vrios membros dos times do Mxico e E.U.A. abandonaram o projeto Ausncia de um sistema de recompensa /punio
(4) Falta de motivao
Indiferena e apatia (5) Falta de comprometimento (6) Conflito e confuso Pouca confiana mtua Cooperao pequena entre times Nenhum controle dos lderes dos times sobre seus subordinados Compartilhamento ineficiente de conhecimento
97
Ok, mas o que fez voc quanto a isso?, eu perguntei. Baseado nas informaes disponveis, 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 diagrama (Figura 5) na sua mochila.
Figura 5 98
Uau! Beth disse, que desenho bonito! Mas para que isso serve? Uma vez determinadas as razes dos problemas (retngulos hachurados), o prximo passo foi nomear pessoas para que atacassem esses problemas. Ns criamos uma matriz de soluo (Tabela 2). A matriz resume as medidas levadas a cabo de modo a enderear os riscos emergentes. Basicamente esta matriz mostra as razes dos problemas, as pessoas que foram escolhidas para atacar os problemas, as datas estabelecidas para se alcanar resultados e a descrio do modo que o problema seria resolvido.
Tabela II
Descrio Quem do Problema (Ao) O que Quando Como
Curso 24 de Insuficiente Gerente conhecimento de Projeto sobre CORBA/JDBC fevereiro Palestras tcnicas em Maro tcnico assuntos relacionados ao desenvolvimento em ambiente de Cliente-Servidor
Curso
de curta durao para programadores Palestra tcnica com especialista
Falta de feedback dos lderes ao gerente
Gerente Obrigar os lderes a enviar de Projeto o relatrio semanal
Toda e-mail Segundafeira at 12:00
Falta de coor- Subdenao com gerente A o Mxico Pouca liderana por parte dos lderes dos times Organizao de projeto pobre Lderes dos times
Manter contato semanal com Toda Por o time do Mxico Segunda- e-mail ou feira at telefone 12:00 Enviar cpias de e-mails trocados entre os times para o gerente do projeto Diariamente e-mail
Gerente Planejar a incluso de de Projeto elementos de ligao no planejamento
Sugesto para o prximo projeto
Incluir no catlogo de lies aprendidas
99
Esta tabela e a figura anterior (Figura 5) que eu mostrei a vocs do uma viso clara dos problemas que aconteceram na nona semana do projeto e das aes de corretivas implementadas de modo a solucionar estes problemas. Eu mostrava figuras e tabelas deste tipo na reunio semanal que fazia com todos. Isto era uma mensagem clara aos times de que os relatrios semanais que eles me enviavam eram lidos e as recomendaes dos times, levadas em conta. O que voc quer dizer por comunicar as mudanas? Beth perguntou enquanto olhava para o guardanapo rabiscado por Manopoulos (Figura 1). Eu estava sentando ao lado dela tentando organizar a sua coleo de guardanapos. Bem, eu no tenho muito a dizer sobre isso. Todas as mudanas introduzidas no projeto de PATOLAB eram discutidas com os times em nossas reunies semanais. Os times localizados em outros pases participavam da maior parte de nossas reunies, s vezes por meio de Web-conferncia e outras vezes por Vdeo-Conferncia ou Tele-conferncia. A matriz de soluo, o diagrama de causa-efeito e o cronograma do projeto foram colocados na parede da nossa sala de reunio. Ns tambm colocamos os documentos que detalhavam as mudanas introduzidas em nosso repositrio-Web. E sobre a atualizao do plano de gerncia de projeto, o que voc pode nos contar? eu perguntei. Bem, eu tenho uma histria interessante sobre isso. Eu, como gerente do projeto, tive que fazer muitos ajustes no plano durante a execuo do projeto. Os ajustes do plano de gerncia de projeto so exemplos de aes pr100
ativas. Voc se lembra da ferramenta de garantia da qualidade, o PDCA que ns 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 incrdula. As razes principais para uma paralisia de projeto so falta de foco, de direo e de prioridades claras (Lewis, 1998). Em nosso caso ns sofremos dos trs problemas durante as semanas 10, 11 e 12 de projeto. Primeiro, tivemos os problemas de falta de direo e prioridades claras. O lder do time de programadores teve um pro101
blema pessoal srio durante a semana 10 e viajou repentinamente para a ndia, no tendo tempo de definir tarefas aos lderes de programao. S para relembrar, ns tnhamos trs lderes de sub-times: um responsvel pelo desenvolvimento do mdulo Servidor, outro responsvel pelo mdulo Cliente e outro responsvel para o mdulo Banco de dados (Figura 4). Estes 03 lderes eram subordinados ao lder do time de programao. O lder do time de programao no pde enviar qualquer relatrio ao gerente do projeto. Como o time de programao no tinha ningum designado para assumir as atividades do lder dos programadores em sua ausncia, o caos se estabeleceu. Os programadores normalmente executavam as tarefas dadas pelos lderes dos sub-times, mas estes no tiveram a iniciativa para se reunir para dividir as tarefas entre si. Eles no definiram as prioridades claramente, o que causou o segundo problema, a perda do foco. Uma vez que todos os programadores tambm estavam envolvidos em outros projetos, quando eles perceberam este problema simplesmente passaram a se dedicar mais a outros projetos. Conseqentemente quase nenhum progresso foi feito durante as semanas 11 e 12 em termos de programao. Em contrapartida, foi feito um bom progresso em termos de controle do projeto. Ficou claro para o gerente do projeto que o controle poderia ser melhorado se fosse criado um mecanismo para quantificar o esforo de cada time de programao. Dem uma olhada nesta tabela, que torna claro o mecanismo que ns criamos para medir e informar o progresso de cada time de programao separadamente. Ele nos mostrou a seguinte tabela (Tabela 3).
102
Tabela III
Item Projeto MM Projeto TM Cliente GUI Cliente Classes Java Interface CORBA Cliente Interface CORBA Servidor Classes Java Servidor Interface SQL/JDBC Projeto Banco de Dados 2.1 2.2 3.1.1 3.1.2 3.1.3 3.2.1 3.2.2 3.3.1 3.3.2 Planejado 100 70 50 50 40 30 10 40 30 Feito 100 70 10 20 30 30 10 30 30 Lder A D B B B A A C C
O uso de um mecanismo de controle novo melhorou o processo de desenvolvimento e ajudou resolver o problema de paralisia. Os lderes dos sub-times de programao se tornaram mais ativos, as atividades individuais de programao foram definidas e o projeto avanou. 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 Independncia. Ns decidimos voltar para nosso barco e terminar nossos arranjos. Manopoulos nos convidou para uma caminhada em Blue Hills na prxima semana.
103
1) Eu estava pensando no que Manopoulos me disse sobre a paralisia do projeto. Ele disse que o lder do time de programao no pde enviar qualquer relatrio ao gerente do projeto. Eu estava pensando como isto poderia afetar a visibilidade do projeto. O que visibilidade de um projeto? Como a situao descrita anteriormente pode afetar a monitorao e controle? 2) Beth me falou que para ela responder a problemas emergentes e responder a riscos emergentes quase a mesma coisa. Eu discordo, o que pensa voc disso? 3) O que pensa voc sobre Adaptao do Projeto? Voc alguma vez trabalhou em algo semelhante? Voc pode me falar como fez adaptaes a um projeto? 4) Em PATOLAB, Manopoulos usou a ferramenta de Garantia de Qualidade chamada diagrama de causa e efeito. Que outras ferramentas voc poderia sugerir para ele usar?
105
Referncias
[Amaral, 2000] Amaral, J.A.A (2000) Project Management in Distributed Collaborative 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/October). Participative leadership or project paralysis. Women in Business, 50(5), 36-39.
107
Concluso
Espero que voc tenha se divertido lendo sobre o Projeto PATOLAB. Escrevi este livro sem pretenses acadmicas, apenas relatei o que eu acho importante na gerncia de projetos de software. Tenha em mente que h atividades que podem ser adicionadas ao conjunto das atividades citadas relacionadas preparao, planejamento e adaptao. O modelo apresentado apenas uma orientao, um guia inicial. Voc pode adicionar ou suprimir atividades em funo da complexidade de seu projeto. Cada projeto tem peculiaridades, mas de um modo geral, o modelo apresentado abrangente o bastante para cobrir um grande nmero de projetos de software. Caso voc tenha tido alguma dificuldade em tpicos relacionados engenharia de software, no se preocupe, tenha um pouco de pacincia que em breve lanarei um outro livro sobre o assunto. Mas h inmeros sites interessantes sobre gerncia de projetos, eu poderia recomendar os seguintes:
109
Uma boa dica o site do Project Management Institute http://www.pmi.org/publictn/pmboktoc.htm Vale a pena visitar este site, voc pode inclusive fazer o download de manuais e estudos. Outro site bem interessante o da Carnegie Mellon Software Engineering Institute, http://www.sei.cmu. edu/cmm/cmm.html, uma vez que voc leu algo a respeito de Modelos de Maturidade de Capacidade no estudo de caso 01. H livros de engenharia de software interessantes, entre eles eu ressalto o livro do Pressman (Software Engineering) e do Sommerville. Recomendo tambm a leitura do livro Adaptive Software Development: A Collaborative Approach to Managing Complex Systems , de James A. Highsmith II
Vrias pessoas me perguntam o que aconteceu com Beth e Nelson. Isto uma longa estria, talvez voc fique sabendo no meu prximo livro! Caso voc tenha comentrios ou dvidas sobre o livro, por favor me escreva jarantes@alum.mit.edu Felicidades! Joo Arantes
110
JOO ARANTES graduado em Engenharia Mecatrnica pela Escola Politcnica da USP, Mestre em Computao e Sistemas pela COPPE-UFRJ, Master of Science pelo MIT (Massachusetts Institute of Technology), Doutor em Computao de Alto Desempenho pela COPPE-UFRJ.

O livro traz uma abordagem inovadora e criativa ao ensino de Gerncia de Projetos de Software. Ensina-se por meio de exemplos, a partir de discusses sobre prticas certas e erradas. uma compilao de quatro estrias em que os personagens discutem entre si os principais aspectos envolvidos no gerenciamento de projetos de software. Eles comentam as aes tomadas pelo gerente de um projeto de desenvolvimento de um software complexo, um ASP (Application Service Provider). Os dados gerenciais apresentados no livro so na verdade dados reais coletados do projeto IeCollab (Intelligent Electronic Collaboration Project), projeto distribudo que envolveu 32 pesquisadores de trs universidades, em trs pases diferentes (MIT USA, CICESE Mxico e PUC Chile). Cada estria versa sobre uma fase pela qual o projeto passa. Os personagens, de uma maneira divertida, discutem e refletem sobre as atividades envolvidas nas fases de preparao, planejamento, execuo e adaptao de um projeto. Procurou-se abordar as atividades de uma forma bem descontrada, mantendo o foco apenas nos aspectos mais relevantes.
APLICAO Livro-texto para as disciplinas "Gerncia de Projetos de Software", "Gesto de Projetos", "Gesto de Tecnologia da Informao" de cursos de Graduao (Anlise de Sistemas/Sistemas de Informao/Tecnologia da Informao), Psgraduao, especializao e MBA. Leitura complementar para disciplinas que incluam atividades de planejamento, controle e execuo de projetos. Leitura recomendada para profissionais que tenham sob sua responsabilidade a gerncia de projetos de software.
ditora

Gerência de Projetos de Software

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Gerência de Projetos de Software

Enviado por

Direitos autorais:

Formatos disponíveis

Joo Alberto Arantes do Amaral

Joo Alberto Arantes do Amaral

GERNCIA DE PROJETOS DE SOFTWARE

GERNCIA DE PROJETOS DE SOFTWARE

Gerncia de Projetos de Software

Joo Alberto Arantes do Amaral

Gerncia de Projetos de Software

memria de minha me, Neyde Curvo do Amaral

Sobre o que este livro

Gerncia de Projetos de Software

A quem se destina este livro

Porque eu escrevi este livro

Joo Alberto Arantes do Amaral

Gerncia de Projetos de Software

Joo Alberto Arantes do Amaral

PREPARAO PARA O PROJETO

O caminho que leva ao inferno pavimentado de boas intenes

O tempo gasto na reflexo na verdade uma economia de tempo Publius, 1 A.C.

Gerncia de Projetos de Software

Joo Alberto Arantes do Amaral

Gerncia de Projetos de Software

Joo Alberto Arantes do Amaral

Gerncia de Projetos de Software

Joo Alberto Arantes do Amaral

Gerncia de Projetos de Software

Joo Alberto Arantes do Amaral

Gerncia de Projetos de Software

Joo Alberto Arantes do Amaral

Gerncia de Projetos de Software

Joo Alberto Arantes do Amaral

Gerncia de Projetos de Software

Joo Alberto Arantes do Amaral

Gerncia de Projetos de Software

Joo Alberto Arantes do Amaral

Gerncia de Projetos de Software

Joo Alberto Arantes do Amaral

Gerncia de Projetos de Software

Joo Alberto Arantes do Amaral

Tpicos para discusso

Gerncia de Projetos de Software

Joo Alberto Arantes do Amaral

No h ventos favorveis para aqueles que no sabem aonde ir

Gerncia de Projetos de Software

Joo Alberto Arantes do Amaral

Gerncia de Projetos de Software

Joo Alberto Arantes do Amaral

Gerncia de Projetos de Software

Joo Alberto Arantes do Amaral

Gerncia de Projetos de Software

Joo Alberto Arantes do Amaral

Gerncia de Projetos de Software

Joo Alberto Arantes do Amaral

Gerncia de Projetos de Software

Atividades de Apoio de projeto

Joo Alberto Arantes do Amaral

Gerncia de Projetos de Software

Joo Alberto Arantes do Amaral

Gerncia de Projetos de Software

Primeiro ns definimos as categorias dos riscos e os identificamos.

Ento ns demos valores de impacto aos riscos

Tabela V - Riscos de Projeto

Gerncia de Projetos de Software

E finalmente ns agrupamos os riscos, em funo do grau de impacto e da probabilidade de ocorrncia.

Joo Alberto Arantes do Amaral