Você está na página 1de 390
A Arte do Gelincemaiie de Projetos \ \. a \ y a O’REILLY° Scott Berkun Bookman’, Scott Berkun estudou ciéncia da computacio, filosofia e design na Universidade de Carnegie Mellon. Contratado pela Microsoft em 1994, como engenheiro de usabilidade, crabalhou no Microsoft Office, Visual Basic e em outros produtos. Em 1995, tornou-se gerente de programas no projeto do Internet Explorer, liderando o design ¢ desenvolvimento de virios recursos importantes, Apés a versio 5.0, trabalhou como gerente lider de programa nas equipes de desenvolvimento do Windows e do MSN. Scott também trabalhou no grupo de exceléncia em engenharia da Microsoft, ajudando outros profissionais na empresa © no setor a conhecer as priticas consagradas no desenvolvimento para a Web e de software. Ble ministrou palestras e cursos em workshops e participou em varias formas de travessuras em diversas conferéncias da indiistria, Scott saiu da Microsoft em 2003 com o objetivo de encher a prateleira retratada acima com livros de sua autoria. Continua ensinando gerenciamento de projetos, desenvolvimento de software, pensamento criativo e design de produtos, como consultor independente. Visive wurwscottberkun.com paca participar de foruns de discussio sobre os «picos deste livro ¢ conhecer dezenas de outros ensaios e informacées sobre como ajuda- loa encher a prateleira (contar a outras pessoas sobre este livro pode ser uma 6tima maneira de comegar). Este é seu primeiro livro. Ele mora em algum lugar nas florestas 20 leste de Seattle, BS513a_—_Berkun, Scott Aarce do gs nento de projetos / Scott Berkun 5 tradugio Carlos Augusto Caldas de Moraes, Teresa Cristina Felix de Souza. ~ Porto Alegre : Bookman, 2008 388 p. sil s 25 em. ISBN 978-85-7780-170-1 1. Informatica ~ Gestio. 2. Projets ~ Gestio. 1, Titulo, CDU 004:658 Catalogagio na publicagao: Juliana Lagéas Coelho ~ CRB 10/1798 Scott Berkun A Arte do Gerenciamento de Projetos Tradugao: CARLOS AUGUSTO CALDAS DE MORAES ‘TERESA CRISTINA FELIX DE SOUZA Consultoria, supervisao e revisio técnica desta edigao: HENRIQUE J. BRODBECK Mestre em Engenharia Professor do Instituto de Informatica da UFRGS 2008 Obra originalmente publicada sob o titulo Making Things Happen: Mastering Project Management ISBN 978-0596-51771-7/0-596-51771-8. ‘Tradugio publicada ¢ vendida com aurorizagio da O'Reilly Media, Inc., pproprietiria dos respectivos direitos de publicacio e venda. Capa: Gustavo Demarchi Ate sobre capa original Leitura final: Renato Merker Supervisao editorial: Arysinha Jacques Affonso Edditoragito eletrénica: AGE — Assessoria Grafica e Editorial Ltda. © logo da O'Reilly é uma marca registrada da O'Reilly Media, Ine. Muitos dos nomes usados por fabricances vendedores para distinguir seus produtos sio reivindicados como marcas comerciais. Nes locais em que aparecem, ¢ quando 2 O'Reilly tinha conhecimento que se tratava de uma marca comercial, estes names estao impressos em letra maitiscula ou com a letra inicial em maitiscula Embora a preparagio desc livo tena sido realizada com cautela,o editor e 0 autor nifo se responsi bilizam por erros ou omissées ou por danos causados pelo uso das informa Reservados todos os direitos de publicagao em lingua portuguesa & ARTMED® EDITORA S.A. (BOOKMAN® COMPANHIA EDITORA é uma divisio da ARTMED® EDITORA S.A.) ‘Av. Jeronimo de Ornelas, 670 Santana 9040-340 Porto Alegre RS Fone (51) 3027-7000 Fax (51) 3027-7070 E proibida a duplicagio ou reprodugio deste volume, no todo ou em parte, sob quaisquer formas ou por quaisquer meios (cletrénico, mecinico, gravagio, fotocépia, distribuigio na Web c outros), sem permissio expressa da Editora. SAO PAULO Av, Angélica, 1091 - Higienépolis 1227-100 Sao Paulo SP Fone (11) 3665-1100 Fax (11) 3667-1333 SAC 0800 703-3444 IMPRESSO NO BRASIL PRINTED IN BRAZIL Agradecimentos Wires secoect en org Mike Hendvielaon, cnet elite oa O'Reliyypor ne dar o sinal verde ¢ muita corda. Imensos agradecimentos a Faisal Jawdat, Ben Lieberman e Andrew Stellman, os bravos e generosos revisores técnicos dos primeiros rascunhos. Muitas pessoas participaram deste livro: agradego a Marlowe Shaeffer (editor de produgio) por gerenciar o projeto deste livro, Marcia Friedman (designer grifica), Rob Romano (ilustrador), Jeremy Mende (designer da capa), Audrey Doyle (revisor), Ellen Troutman-Zaig (indexadora) ¢ Glenn Bisignani (gerente de marketing de produto). [As pessoas a seguir aceitaram ser entrevistadas ow apresentaram comentérios sobre 0s primeiros rascunhos dos capitulos. Muchas gracias a Michelle Breman, Pierro Sierra, Eric Brechner, Richard Stoakley, Mark Stutzman, Neil Enns, Jason Pace, Aly Valli, Joe Belfiore, Bill Staples, Laura John, Hillel Cooperman, Stacia Scott, Gwynne Stoddart, Terri Bronson, Barbara Wilson, Terrel Lefferts, Mike Glass, Chromatic ¢ Richard Grudman. Agradecimentos especiais a Ken Dye, meu primeiro gerente na Microsoft, e a Joc Belfiore, por me darem a oportunidade de participar no gerenciamento de programas ¢ por formarem minhas primeiras idéias sobre como devem ser os bons gerences e Iideres. Agradecimentos adicionais, embalados individualmente, para minha esposa, Jill “uso” Stutzman; Richard “grande paizinho” Grudman; os “cies de aluguel” (Chris “nosso heréi” McGee, Mike “todas as mudangas” Viola, David “garoto lindo” Sandberg, Joe “gourmet” Mirza, Phil “stud poker” Simon); Vanessa “NYC” Longacre; Bob “fazendo a Web funcionar” Baxley; ¢ para as boas pessoas em gnostron, unhinged ¢ pm-clinic (da clinica de gerentes de projetos (GP). Agradecimentos gerais & propria idéia do universos & palavra papaya; as grandes florestas ¢ grandes drvores; 3s pessoas que continuam bobas, curiosas ¢ divertidas muito além de suas idades; & letra Q e ao mtimero 42, Um pacore com 0 contetido Obrigado ao sistema da biblioveca de King County ¢ a todos os bibliotecitios de todos os lugares. O programa de ‘empréstimos Interlibrary foi uma béngio. Obrigado, pessoal. Os miisicos a seguir mantiveram minha sanidade durante as longas horas ao teclado: White Stripes, Palomar, Aimee Mana, The Clash, Johnny Cash, Social Distortion, Rollins Band, Sonny Rollins, Charles Mingus, Theloneous Monk, Breeders: Last Splash, AudioSlave, MC5, Chris McGee's os melhores mixes, Jack Johnson, Patty Griffin, Akiva, Flogging Molly, Sinatra, Beatles, VI_AcrADECIMENTOS Bruce Springsteen, PJ Harvey, Radiohead, Ramones, Weezer, Tom Waits, All Girl Summer Fun Band, Best of Belly, Magnetic Fields, Beth Orcon, Elliot Smith ¢ Nick Cave ¢ 0s Bad Seeds. Nenhum gerente de projeto foi lesado na confecgio deste livro. Mas infelizmente, Butch, nosso cachorro, faleceu na fase da produgio final. Butch, descanse em paz, 1991-2004. Ele se deitava junto aos meus pés, enquanto varias idéias © paginas contidas neste livro comegavam a surgir. Bom cachorro, © Butch. Sentiremos a sua falta. Prefacio MIl_Preracio, M nha palavra favorita € como. Como isto funciona? Como isto foi construido? Como fizeram isso? Sempre que vejo algo interessante, figo muitas perguntas com essa palavrinha, pequena mas poderosa. E a maioria das respostas fala de como as pessoas aplicam sua inteligencia e sabedoria, e no do seu conhecimento de tecnologias ou teorias especificas Ac longo de anos construindo coisas © comparando minhas experiéncias com as de outros gerentes, programadores e designers, desenvolvi convicsées e conclusées sobre como gerenciar projetos de modo eficiente, Este livro é um somatério dessas idéias. Ele abrange propostas para liderar equipes, trabalhar com idéias, organizar projetos, gerenciar agendas, lidar com politicas fazer coisas acontecerem, mesmo diante de grandes desafios e situagées injustas. ‘Apesar do titulo abrangente deste livro, a maior parte de minha experigncia profissional tem origem no setor técnico e, particularmente, na Microsoft Corporation. Trabalhei l4 de 1994 até 2003, liderando equipes de pessoas em projetos como o Internet Explorer, Microsoft Windows « MSN. Trabalhei alguns anos no grupo de exceléncia em engenharia da Microsoft. Enquanto estive Ii, fui responsivel por ensinar e dar consultoria a equipes na empresa inteira, e era freqiientemente solicitado a miniscrar palestras em conferéncias priblicas, corporagdes ¢ universidades. A maioria dos conselhos, ligdes e histérias contidos neste livro procede dessas experiéncias Embora cu tenha experiéncia em desenvolvimento de software ¢ para a Web, escrevi este livo de modo amplo e inclusivo, citando referencias ¢ técnicas externas aos dominios da engenharia ¢ do gerenciamento. Valorizo aqui as pessoas pertencentes 20 mundo empresarial em geral. Estou certo de que os desafios de organizar, liderar, criar designs ¢ entregar o trabalho tém muito em comum, independentemente do dominio, Os processos relacionados & fabricagao de fornos, de arranha-céus, automdveis, sites Web e produtos de software compartilham muitos dos mesmos desafios, ¢ este livro versa basicamente sobre como superé-los. Diferentemente de outros livros sobre como comandar projetos ¢ equipes, este livro no imputa qualquer grande teoria ou filosofia supostamente inovadora. Em ver disso, apostei na praticidade e diversi nha opiniio, os projetos dio bons resultados quando é aplicada a combinagio cerca de pessoas, talentos, avitudes e tdticas, a despeito de sua otigem ou (falta de) pedigree. A estructura deste livro é a mais sensivel possivel: enfoco os principais desafios e situagdes e dou conselhos sobre como lidar com eles de modo eficiente. Apostei muito em escolher os temas certos ¢ dar bons conselhos sobre eles, acima de todos os outros aspectos. Espero que vocé também ache que fiz a melhor escolha. Quem deve ler este livro A melhor maneira de saber se este livto serve pata vocé é ir para 0 Sumério, cescolher um tema de seu interesse e examinar o que falo sobre ele. Geralmente, no confio muito nos preficios ¢ recomendo isso a voce: eles raramente tém o mesmo estilo ou impeto do restante do livro. Mas enfim, aqui vamos nés. O livro € mais indicado para as pessoas que se enquadram em uma ou mais das seguintes categorias: PrerAcio IX * Lideres e gerentes de equipe experientes. Este livro é adequado para quem desempenha uma fungio de lideranga, de modo formal ou informal, em qualquer tipo de projero. Os exemplos sio oriundos do desenvolvimento de software, mas muitos conecitos sio facilmente aplicdveis a outros tipos de trabalho. Vocé pode ser o lider oficial da equipe ou apenas um dos membros mais experientes. Ainda que conhega bem alguns temas do livro, a abordagem direta ¢ pritica aqui utilizada o ajudaré a esclarecer ¢ aprimorar suas opinioes. Mesmo se discordar das minhas opinies, ter4 uma base transparente com a qual crabalhar, a0 aperfeigoar ¢ melhorar a sua perspectiva. + Novos lideres de equipe ¢ gerentes. Se vocé examinar os temas listados no Sumirio, encontrard uma visio geral sélida de tudo o que os lideres e gerentes realmente fazem nos projecos. Cada capitulo discorre sobre falhas ¢ erros comuns cometidos até mesmo por pessoas experientes, com as respectivas explicagdes, desde os motives pelos quais acontecem ¢ as titicas que podem ser usadas para eviti-los ou recuperar-se deles. O liveo propicia uma visio e nogio bdsica mais abrangente de suas novas responsabilidades, e modos mais inteligentes de gerencit-las. Por tratarem de grandes temas, geralmente a maioria dos capiculos contém referencias comentadas As fontes mais completas. * Programadores ¢ testadores individuais, ou outros colaboradores do projeto. Este livro vai melhorar sua percepgio sobre aquilo para 0 que voc’ esti contribuindo, e quais abordagens e idéias pode usar para ser eficiente e Feliz a0 agir assim. Se vocé nunca se perguinton por que os projetos mudam de rumo com tanta freqiiéncia ou parecem ser gerenciados de modo deficiente, est livro o ajudars a entender as causas e solugées. No minimo, ao ler este livro, vocé enquadrari suas contribuigdes individuais em um contexto maior, ¢ aumentard a probabilidade de que seu trabalho faca uma diferenga (e de que voc® continue sadio a0 fazer isso). Se tem interesse em gerenciar ou liderar equipes, algum dia, este livro o ajudars a examinar o que realmente significa tudo isso e se tem gabarico para essa faganha. + Estudantes de administragao de empresas, design de produtos ou engenharia de sofeware. Emprego a palavra estudantes no ambito mais abrangente: se voce tiver inceresse pessoal nesses temas ou se estiver estudando esses assuntos formalmente, este livro sera de grande valia. Diferentemente da maioria das abordagens de livros texto sobre esses temas, este livro esti bastante focado em simmagbes e narrativas. As experiéneias ¢ histérias sio reais, e represencam a base das ligdes e téticas: ndo 0 contritio. Evito deliberadamente fazer comparacées entte diferentes assuntos académicos porque, em minha experiéncia, isso nio ajuda os projetos nem contribui para perceber a realidade (0 universo nao é dividido da mesma mancira como as tniversidades coscumam ser). Em vez, disso, este livro combina a teoria comercial, psicologia, téticas de gerenciamento, processos de design engenharia de software de modo a oferecer 0 aconselhamento necessdtio sobre os remas em destaque. O que eu supus sobre vocé ao escrever este livro * Vocé nao é bobo. Acho que se escolhi os capitulos certos ¢ os escrevi bem, voce nfo precisané que eu gaste tempo construindo lenramente estruturas elaboradas de informagées. Em vez disso, eu chegarei ao ponto ¢ investirei meu tempo X_Preracio exatimente af. Presumo que voce ¢ uma espécie de parceiro — com uma experiéncia talvez maior, menor ou diferente — que passou por aqui para obter alguns conselhos. * Vocé ¢ curioso e pragmatico. Extrai exemplos e referéncias de varias disciplinas € acho que vocé dari importincia a trazer ligdes externas 20 desenvolvimento de Web software. Isso no atrapalharé, mas indicagoes de mentes curiosas virio & tona, as veres 36 em noras de rodapé. Prestimo que voct queita aprender, que esteja receptivo a idéias diferentes ¢ reconhesa 2 importincia das opinioes bem embasadas — mesmo que nio concorde com elas. * Voce nao gosta de jargoes nem de grandes teorias, Nao acho que os jargées € grandes reorias ajudam na aprendizagem e na aplicagSes de novas informagées. Evito-os, exceto quando indicam um caminho para informagies tteis ou oferecem uma estrutura que serd titil mais adiante. * Vocé nio leva muito a sério a si mesmo, 0 software ou o gerenciamento. Pode ser desagradivel ler assuntos relacionados ao desenvolvimento de sofitoare ¢ gerenciamento de projetos. Mesino que este livr0 no seja um rompante comico ou uma sétira (embora um livro de Mark Twain ou David Sedaris com explicagoes de engenharia de software possa set), nio hesivarei em fazer piadas &s minhas custas (ott as custas de alginém) ow tsar exemplos com explicagées Como usar este livro Escrevi este livro levando em conta as pessoas que gostam de saltar de um lado para outro ¢ ler capitulos soltos. Contudo, existe uma certa vantagem em ler 0 liveo em seqiiéncia; alguns conceitos posteriores dependem dos anteriores ¢ o livro segue rigorosamente @ ordem cronolégica da maioria dos projetos. E evidente que vocé nunca saberia disso, a menos que o lesse do inicio ao fim, de modo que se preferir saltar, teré que confiar em mim quanto a esse aspecto, O primeira capitulo € 0 mais abrangente do livro ¢ tem um tom mais denso do que os demais, Se estiver curioso em saber por que deve se importar com 0 gerenciamento de projetos ou que outtas pessoas importantes disseram isso, entio voce deveria certamente se dar uma chance. Se tentar e odiat, recomendo-the experimentar outro capitulo antes de abandonar o barco. Todas as referencias e URLs listadas no livro, assim como outras notas e comentitios, podem ser encontrados anline, em awwwunscottberkuun.com/bookslartofpml. O site tem um férum de discusses ¢ outros recursos para quem estiver interessado em ir além dos temas deste livro. Como vocé foi suficientemente inteligente ¢ paciente para ler esta introducio inreira, presumo que se apressars nas ourras mecinicas de leitura do liveo (ntimeros de pigina, notas de rodapé ¢ tudo © mais) ¢ nao vou mais atrapalhé-lo. Saudagées, Score Berkun Redmond, WA Sumario 1 Uma breve histéria do gerenciamento de projetos (e por que é importante) 13 Paxre 1 PLANOS 31 2. A verdade sobre os cronogramas 33 3 Como resolver o que fazer 53 4. Redigindo a visio eficiente 79 5. De onde surgem as idéias 99 6 O que fazer com as idéias quando voce as tiver 121 Parte 2 HABILIDADES 141 7. Escrevendo boas especificagoes 18 8 Como tomar boas decisdes 163 9 Comunicacio ¢ relacionamentos 183 10 Como nao incomodar as pessoas: processo, email e reunibes 199 11. que fazer quando as coisas dao errado 219 12 Por que a lideranga é baseada na confianga 247 13. Como fazer as coisas acontecerem 265 14 Estratégia de meio-jogo 285 mn Parte 3 GERENCIAMENTO. 245 15. Estratégia de final de jogo 307 16 Poder ¢ politica 333 Créditos das foros 357 Notas 359 Bibliografia comentada 367 Indice 373 Capitulo 1 Uma breve historia do gerenciamento de projetos (e por que é importante) 14_A Arte Do GERENCIAMENTO DE PRoJETOS Ii sslse ocgcieagien Medel urn pts |eentnao Corn oreaigside gevemicds projeto. Tudo bem. Todos os programadores, gerentes, lideres de equipe, analistas ¢ designers gerenciam projetos no scu trabalho didtio, estejam cles trabalhando sozinhos ou em equipe. Por enquanto, essas distingoes nio sio importantes. Minha intengio neste livro é entender 0 que torna um projeto bem-sucedido © como as pessoas que lideram projets bem-sucedidos o fazem. Essas idéias e estratégias principais nfo requerem hierarquias, cargos ou métodos especificos. Portanto, se vocé trabalha em um projeto ¢ tem alguma responsabilidade sobre seus resultados, esta obra se aplicard a voce. E caso seu cartio de visitas 0 apresente como um gerente de projetos, melhor ai Este livro foi criado para ser tril de trés maneiras: como uma colegio de ‘ensaios focados em tépicos, como uma narrativa tinica ¢ ampliada ¢ como uma referéncia para situagées comuns, Cada capitulo apresenta uma carefa diferente de alto nivel, fornece uma estrutura basica ¢ oferece estratégias ¢ téticas para concluir a tarefa com éxito, Entretanto, neste capitulo de abertura, adoto um enfoque diferente: exiscem crés tépicos amplos que tornario o restante do livro mais fécil de acompanhar, ¢ os apresentarei agora. O primeiro é um breve histrico dos projetos ¢ por que devemos aprender com o que os outros tém feito. O segundo sio alguns conceitos sobre os diferentes tipos de gerenciamento de projetos, incluindo algumas observagées da minha experincia de trabalho na Microsoft. E o tereciro é um exame dos desafios subjacences envolvidos no gerenciamento de projeto ¢ como eles podem set superados. Embora esses pontos sejam titeis mais tarde, cles nao sto necessirios para os prdximos capitulos. Portanto, se vocé achar a abordagem deste primeiro capitulo muito abrangente, sinta-se & vontade para prosseguit para o Capitulo 2 ¢ o restante deste livro. Usando a historia O gerenciamento de projetos, como uma idéia, daca de muito tempo. Se voce pensar em tudo 0 que foi criado na histéria da civilizagio, teremos milhares de anos de experiéncia com os quais aprender. Uma linha pontilhada pode ser desenhada desde os desenvolvedores de software de hoje rettocedendo no tempo até os construtores das pirmides do Egito ou os arquiteros dos aqueduros romanos. Em suas respectivas épocas, os gerentes de projeto desempenhavam papéis similares, aplicando tecnologia aos problemas relevantes dos tempos. Ainda hoje, quando a maioria das pessoas tenta melhorar 0 modo como seus projetos de desenvolvimento de software e Web sio gerenciados, € raro prestar atengio as ligées aprendidas no passado. A linha do cempo que usamos como escopo para o conhecimento til esté muito mais préxima do dia de hoje do que deveria estar. A histéria dos projetos de engenharia revela que a maioria dos projetos tem fortes semelhangas. Eles tém requisitos, projetos (designs) e restrigées. Eles dependem da comunicagao, da tomada de decisto ¢ de combinagoes de pensamento légico e criative. Os projetos normalmente envolvem uma cronograma (schedule), um orgamento ¢ um cliente. O mais importante, a tarefa central dos projetos € combinar os crabalhos de diferentes pessoas em Una Breve Historia DO GERENCIAMENTO DE Projeros 15 um todo singular e coerente que seré tiil para as pessoas ow clientes. Seja um projeto desenvolvido a partir do HTML, do C++ ou de cimento ago, hi sempre um conjunto principal de conceitos irrefuraveis que a maioria dos projetos deve compartilhar. Minha curiosidade sobre as formas de liderar os esforgos de desenvolvimento de software e Web me levou a um sério interesse por esse conjunto principal de conceitos. Estudei outros campos e setores para ver como eles solucionaram os desafios centrais para seus projetos, para que pudesse aplicar solugdes compariveis em meu préprio trabalho. Imaginei como projetos como o Telescépio Espacial Hubble ¢ 0 Boeing 777 foram desenvolvidos ¢ construidos. Poderia eu reutilizar algo de suas complexas especificagdes e processos de planejamento? Ou quando o prédio da Chrysler foi construido na cidade de Nova York ¢ 0 Parthenon em Atenas, os lideres de projeto planejaram e estimaram suas conscrugbes da mesma forma que os meus programadores o fazem? Quais foram as diferengas interessantes ¢ 0 que pode ser aprendido examinando essas diferenga © que dizer dos editores de jornais, que organizam e planejam a produgio diivia das informagoes? Eles estavam fazendo multimidia (imagens e texto) muito antes dos primeiros sonhos de publicagio na Web. E sobre a producio de filmes de longa metragem? O langamento da Apollo 132 Examinando essas questoes, fui capaz de perceber como liderar equipes de projeto de uma nova maneira. Entretanto, essas perguntas nem sempre tinham respostas ébvias. Eu nao posso promerer que voce entregari o resultado mais cedo ou planejari melhor porque as informagées deste livro foram influenciadas por essas fontes. Mas cu sei que quando retornei a0 mundo do sofiware apés pesquisar em virios lugares, meus processos ¢ ferramentas me pareceram diferentes, Encontrei maneiras de modificé-los que antes nao tinha considerado, No todo, percebi que muitas abordagens ¢ comparacées titeis que encontrei nunca tinham sido mencionadas durante meus estudos de ciéncia da computagio na universidade. Blas nunca foram discutidas em conferéncias do seror tecnolégico ou escritas em revistas do ramo. As principais ligées aprendidas nas minhas investigagdes sobre o passado sio descritas nos trés pontos a seg 1. O gerenciamento de projeto ¢ 0 desenvolvimento de software nao sio artes sagradas. Qualquer trabalho da moderna engenharia é uma nova entrada no longo histérico da criagao. As tecnologias ¢ habilidades podem mudar, mas grande parte dos principais desafios que dificultam a engenharia permanece “Todas as coisas, quer linguagens de programacio ou mecodologias de desenvolvimento, sao Gnicas de alguma maneira, mas derivadas de outras. Mas se quisermos reutilizar 0 méximo possivel de conhecimento do passado, precisamos ter certeza de que estamos abertos para examinar ambos os aspectos ~ 0 tinico e o derivado ~ em comparagao com 0 que velo antes. 2. Quanto mais simples a visio do que vocé faz, mais poder € foco terd a0 executé-la, Se pudermos manter periodicamente uma visio simples do nosso trabalho, poderemos encontrar comparacdes titeis com outras maneiras de realizar as coisas que existem em nosso redor. Existirio mais exemplos ¢ ligoes da histéria ¢ das indiistrias modernas que podem ser usados, comparados e contrastados. Isso € similar ao conceito definido pela 16_A ARTE Do GERENCIAMENTO DE PROJETOS palavra japonesa shoshin, que significa mente do iniciante! ou mente aberta, uma parte essencial de muitas disciplinas de artes marciais. Permanecer curioso ¢ aberto € 0 que torna 0 crescimento possivel e € necessdrio praticar para manter essa atitude. Para continuarmos a aprender, temos de evitar a tentagao de aceitarmos visbes estreitas ¢ seguras sobre 0 que fazemos. 3. Simples nao quer dizer facil. Os melhores atletas, escritores, programadores ¢ gerentes tendem a ser aqueles que sempre véem 0 que fazem como simples em sua esséncia, mas, simultaneamente, diff Lembre-se de que simples nao ¢ 0 mesmo que facil. Por exemplo, correr uma maratona € uma coisa simples. Voce comeca a correr e nao para até complecar 42 km, O que poderia ser mais simples? O fato de ser dificil nao nega sua simplicidade. Lideranga e gerenciamento também sio dificeis, mas sua natureza — executar tarefas de uma mancira especifica para atingir uma meta especifica — é simples. Eu farei alusio a esses conceitos em muitos capitulos. Portanto, se fizer referencias que estejam fora dos limites convencionais do desenvolvimento de software, ‘espero que vocé entenda minhas razées pata isso, E quando eu sugerir que uma romada de decisio ou um agendamento sao simples fungoes de gerencia, assumirei que vocé sabe que isso néo sugere que essas coisas sio ficeis de fazer. Aprendendo com os erros “Os seres humanos, que sido praticamente os tinicos (entre os animais) que tém a habilidade de aprender com a experiéncia alheia, sio também notiveis em sua aparente md vontade pare fazer isso.” = Douglas Adams Uma questio simples que surge no estudo da histéria dos projeros é esta: por que alguém concorda em sofrer com os erros ¢ desapontamentos se eles podem set evitados? Se a histéria das engenharias antiga e moderna esti (amplamente) no dominio piblico ¢ somos pags para fizer coisas inteligentes independentemente da fonte de inspiracio, por que tio poucas organizaces recompensam as pessoas por buscar ligées no passado? Enquanto projetos sao concluidos ou cancelados (e muitos projetos de desenvolvimento terminam dessi maneira?) todos os dias, pouico € feito para aprendermos com o que aconteceu, Parece que os gerentes da naioria das organizagoes raramente recompensam as pessoas por buscar esse tipo de conhecimento, Talvez seja por medo do que encontrario (¢ o medo de serem. considerados responsiveis por isso). Ou talvez seja apenas falta de interesse da parte de alguém em rever as experiéncias dolorosas e frustrantes quando 0 tempo poderia ser gasto na préxima mudanga para algo novo. Em seu livro, Zo Engineer is Human: The Role of Failure in Swecesful Design (Vintage Books, 1992), Henry Petroski explica como ocorreram descobertas na engenharia como resultado de falhas. Em parte, isso acontece porque as falhas nos forcam a prestar atengio. Elas nos obrigam a reexaminat as premissas que haviamos esquecido que existiam (é dificil fingir que ido esté bem quando o protétipo pegou fogo). Como Karl Popper? sugeriu, ha apenas dois tipos de Ua Breve Historia DO GERENCIAMENTO DE Proseros 17 teorias: as que estio erradas ¢ as que estio incompletas. Sem os fracassos, nds ‘esquecemos arrogantemente que nossa compreensio das coisas nunca é tio compleca quanto pensamos ser. © attificio, cntéo, ¢ aprender 0 maximo possivel com as falhas de outras pessoas. Devemos usar suas experiéncias para influenciar 0 futuro. Embora os deralhes superficiais da falha possam ser totalmente diferentes de projeto para projeto, as causas bisicas ou as ages da equipe que levaram a clas poderio ser plenamente cransferiveis (e evitéveis). Mesmo em nossos prdprios projetos, precisamos evitar 0 habito de fugitmos ¢ nos escondermos de nossas falhas. Em ver disso, devemos vé-las como oportunidades pata aprender algo. Que fatores contribuiram para que isso acontecesse? Quais deles seriam mais kiceis de minimizar ou eliminar? De acordo com Petroski, 0 conhecimento real obtido a partir da falha real é a mais poderosa fonte de progresso que temos, desde que renhamos a coragem de examinar cuidadosamente 0 que aconteceu. “Talver seja por isso que a Boeing, uma das maiores empresas de projeto ¢ engenharia de aeronaves do mundo, mantenha um livzo negro de ligdes aprendidas a partir de falhas de projeto e engenharia‘. A Boeing mantém esse documento desde que a empresa foi criada ¢ o utiliza para ajudar os novos projetistas a aprenderem com as tentativas do passado. Qualquer organizacio com esse tipo de orientagio niaio apenas aumenta suas chances de projetos bem- sucedidos, como também ajuda a criar um ambiente onde se pode discutir ¢ confrontar as falhas abertamente, em vez de negé-las ¢ escondé-las. Parece que os desenvolvedores de software precisam manter seus pr6prios livros negros. Desenvolvimento para a Web, cozinhas e salas de emergéncia Um problema com a histéria € que ela nem sempre é referencidvel. Pode ser dificil aplicar ligées a0 longo de décadas ¢ manter a empatia por coisas que parecem tio diferentes do modo como 0 trabalho € realizado nos dias de hoje. Uma aleernativa é fazer compatagdes com tipos diferentes de projetos modernos. Embora nao tenha 0 mesmo impacto da hist6ria da engenharia, isso permite observacées ¢ experiéncias pessoais. Com freqiiéncia, ver as coisas na fonte € a tinica maneira de fornecer informagées suficientes para fazer conexées entre idéias diferentes. Como exemplo, eu conhego um desenvolvedor para a Web que acredita que seu trabalho é diferente de tudo o que existe na histéria do universo. Ele sente que como 0 desenvolvimento para a Web exige que cle tome decisées de engenharia complexis ~ projetando e coordenando 4 medida que avanga, verificando alteragées em questio de horas ou mesmo minutos ¢, em seguida, publicando para rodo 0 mundo ~ seu projeto e gerenciamento de tarefas sio diferentes de tudo que jé foi visto antes. Ele se orgulha em listar CSS, XHTML, Flash, Java ¢ oucras tecnologias que domina, afirmando que elas teriam confundido as maiores mentes de 50 anos ateés. Eu tenho certeza de que na sua experiéncia voc® jé encontrou pessoas como ele, Ou talvez venha trabalhado em situagies onde parecia improvavel que alguém mais no universo pudesse ter gerenciado algo tio complexo como 0 que vocé estava fazendo. 18_A Arte Do GERENCIAMENTO DE Proseros Eu sugeri a esse amigo desenvolvedor que desse uma volta pela cozinha do seu restaurante favorito em um dia em que ele estivesse cheio. Por muitas razGes, € interessante caminhar pelas cozinhas (consulte o excelente livro de Anthony Bourdain, Kitchen Confidential, Ecco, 2001), mas meu ponto especifico era sobre produtividade. A primeira vez que alguém vé 0 gerenciamento e a coordenagio de tarefas rapidas que ocorrem em uma cozinha profissional atarefada, provavelmente reconsideraré a dificuldade de seu préprio trabalho. Os cozinheiros estio Freqiientemente distribuindo frigideiras com diferentes pedidos em diferentes estados de conclusio ¢ correndo entre vitios conjuntos de queimadores em cantos opostos da cozinha, enquanto os garcons correm para li e para ef, entregando not ajustes e problemas com os clientes. Tudo isso acontece em espagos pequenos ¢ apertados, bem acima de 30°C, com luminosas luzes luorescentes brilhando acima. E apesar do mimero de pedidos que saem a cada segundo, novos pedidos entram com a mesma velocidade. Alguns pedidos sio enviados de volta ou, como em muitos projetos de software, exigem modificagdes personalizadas e de iiltima hora (a mesa 1 tem intolerincia a lactose; a mesa 2 precisa de molho separado etc.). E maravilhoso observar cozinhas grandes ¢ ararefadas. Apesar de parecerem caéticas » primeira vista, as cozinhas grandes funcionam com um nivel de intensidade e precisio que deixam a maioria das equipes de desenvolvimento no chinelo. Os chefes de cozinha ¢ os cozinhciros regulares sao gerentes de projetos culindrios, ou como Bourdain se refere a eles, controladores de trifego aéreo (outra profissio para o introspectivo considerar). Embora a equipe de cozinha trabalhe em uma escala menor € menos celebrada do que um gerente de equipe de desenvolvimento de software, sua intensidade didria ¢ incompardvel. Se vocé duvida de mim, na préxima vez em que estiver em um restaurante cheio, pergunte ao garcom se é possivel dar uma espiada na cozinha. Talvez ele nao permita, mas se permitir, vocé nao ficard desapontado. (Alguns restaurantes ¢ bares mais modernos tém cozinhas abertas. Se encontrar wm, sente-se © mais préximo posstvel dela. Depois, acompanhe uma pessoa por alguns minutos. Observe como os pedidos sio colocados, controlados, construidos e entregues. Se vocé for num dia em que ele estiver cheio, pensars de maneira diferente sobre como os erros de software sio registrados, rastreados € corrigidos.) Outra ligio de campo interessante no gerenciamento de projecos vem das salas de emergéncia dos hospitais. Eu assisti no Discovery Channel ¢ no PBS como pequenas equipes de médicos, enfermeiras e especialistas experientes trabalham juntos como uma equipe de projeto para tratar de situag6es médicas diversas ¢ algumas vezes bizarras que surgem nas portas dos hospitais. Nao surpreende que tenha sido a profissfo que inventou 0 processo de triagem, um termo comumente usado em projetos de soffware para priorizar problemas ¢ defeitos (discutido no Capitulo 15). O ambiente médico, especialmente em situagdes de trauma, oferece uma comparagio fascinante para trabalho baseado em equipe, tomadas de decisio sob alto estresse ¢ resultados de projetos que afetam muitas pessoas todos os dias (consulte a Figura 1.1 para obcer uma comparago grosseira desse e outros ambientes de trabalho). Como Atul Gawande escreveu em seu excelente livro, Complications: A Surgeon's Notes on an Imperfect Science (Picador USA, 2003): s de Ua Breve HisroriA DO GERENCIAMENTO DE Projeros 19 Nés esperamos que a medicina seja um campo regular de conhecimento € procedimento. Mas nao é. Ela € uma ciéncia imperfeita, um empreendimento de conhecimento em constante mudanga, informagoes incertas, individues passiveis de falhas ¢ ao mesmo tempo “prontos para 0 combate”. Hd cigncia no que fuzemos, mas também habito, incuigao ¢ as veres simples suposigdes. O vcuo entre 0 que sabemos eo que almejamos persiste, E esse vécuo complica tudo 0 que fazemos. Chome Pré-produgto Produgdo yPés-produgso Desenvolvimento Dosen raquios Cason» _Coseacto Testo Dosemovineno Pcie, posi» _wenuerso ama pa ep a Sata do Dagrsico » _Talamon » _Avarso Smoginco | RR ROO conme egerpoioy Fezeropatoy __Ereegar FIGURA 1-1. Em principio, muitas disciplinas tém processos similares. Todas elas dedicam tempo para plansjar, executar e refinar. (Entretanto, vocé nunca deve ir a uma cozinha para receber tratamento médico ou comer em uma sala de emergéncia.) Esse ponto, ¢ muitos outros do livro esclarecedor de Gawande, permanecem, verdadeiros para o desenvolvimento de software. Fred Brooks, no livro ckissico sobre engenharia de sofiware, The Mythical Man-Month, fax comparagées similares entre equipes de cirurgides ¢ equipes de programadotes. Embora vidas raramente estejam em risco quando trabalhamos em sires ou bancos de dados da Web, existe muitas semelhangas vilidas nos desafios que essas diferentes equipes de pessoas precisam enfrentar. A fungao principal do gerenciamento de projetos O gerenciamento de projetos pode ser uma profissio, uma tarefa, uma fungio ou uma atividade. Algumas empresas tém gerentes de projeto cuja tarefa € supervisionar projetos de 200 pessoas. Outras usam o titulo para gerentes juniores, cada um deles responsavel por uma pequena area de um grande projeto. Dependendo de como uma organizagio esti estrururada, da sua cultura ¢ das metas do projeto, 0 gerenciamento de projetos pode ser uma fungio informal (“ela é realizada por qualquer pessoa, sempre que necessario") ou altamente definida (“Vincent, Claude e Raphael sio gerentes de projeto em tempo integral”). 20_A Arte Do GerENCIAMENTO DE PRoJETOS Neste livro, usarei principalmente o termo gerente de projeto, ou GP, para fiver referéncia a quem esti envolvido na atividade de'lideranca e gerenciamento de projetos. Por atividade de gerenciamento de projero quero dizer liderar a equipe na solucdo do projeto (planejamento, programacio c reuniio de requisitos), orientar 0 projeto no trabalho de design e desenvolvimento (comunicagio, tomada de decisio € estratégia de meio de jogo) e executar 0 projeto até a conchusio (lideranga, gerenciamento das crises ¢ estratégia de final de jogo). Se esse tipo de trabalho é menos estrucurado no seu mundo, basta traduzir gerente de projeto ou GP para significar “pessoa que executa as tarefas de gerenciamento do projeto, embora esse nao seja seu trabalho principal” ou “pessoa que pensa no projeto na integra”. Encontrei muitas maneiras diferentes para essas atividades serem distribuidas pelas equipes ea recomendagio deste livro totalmente indiferente para elas. O contetido deste livro ¢ menos sobre os titulos € formalizagbes de cargos e mais sobre execucar tarefas ¢ fazé-las acontecer. Mas, para manter meu texto o mais simples possivel, usarei o cermo gerente de projeto ou GP. As vezes, a auséncia de um gerente de projeto exclusivo funciona bem. Os programadores € seus chefes mantém seus cronogramas e planos de engenbaria (se houver) e um analista de negécios ou pessoa de marketing faz 0 planejamento ou gerenciamento de requisitos. Tudo o mais que poderia ser qualificado como um gerenciamento de projeto simplesmente é distribuido pela equipe. Talver as pessoas da equipe tenham sido contratadas por seus interesses que vio além de escrever um cédigo. Elas poderiam nao se dedicar a0 planejamento inicial, design de interface de usudtio ou estratégia de negécios. Trabalhar dessa maneira pode acarrecar otimizagbes significativas. Desde que todos queiram pagar o prego da responsabilidade por manter essas coisas juntas e distribuir por toda a equipe o dnus que um gerente de projeto exclusive pode suportar, a equipe precisard de menos um funcionétio, Eficigncia e simplicidade sio coisas boas. Mas oucras vezes, a auséncia de um gerente de projeto cria disfungio. Sem tuma pessoa cuja fungio principal seja reunir o esforgo geral, as tendéncias © interesses individuais podem desviar as diregGes da equipe. Fortes faceSes adversirias podem ser desenvolvidas em torno das fungSes de engenharia € negécios, retardando o progresso e frustrando todas as pessoas envolvidas. Considere que nas salas de emergéncia de um hospital, um médico tome a lideranga na decisio do curso de agio para um paciente. Isso apressa muitas decisdes e da clareza hs fungdes que todos os membros da equipe de trauma esperam desempenhar. Sem esse tipo de autoridade clara para problemas de gerenciamento de projeto, as equipes de desenvolvimento podem encontrar dificuldades. Se nao houver uma pessoa com uma fungio clara para liderar a triagem de erros ou alguém dedicado a rastrear os problemas de cronograma ¢ sinalizagio, essas tarcfas poderio ficar perigosamente para tris das atividades de programagio individuais. Embora eu ache que muitos dos melhores progeamadores entendem 0 suficiente de gerenciamento de projetos para gerencii-los sozinhos, eles também reconhecem o valor tinico de uma pessoa boa ¢ dedicada desempenhando © papel de gerente, Ua Breve Historia DO GERENCIAMENTO DE Projeros 21 Gerenciamento de projetos e programas na Microsoft A Microsofé enfrentou dificuldades no final dos anos 80 na coordenagio dos esforcos de engenharia com a area de marketing ¢ negécios de cada divisio (alguns poderio dizer que isso ainda é um problema para a Microsoft e muias, outras empresas). Um homem stbio chamado Jabe Blumenthal percebeu que podsria existir uma tarefa especial onde ur individuo estivesse envolvido com eseas duias fangées, desempenhando um papel de lideranga e coordenagio. Essa pessoa estaria envolvida no projeto desde o primeiro dia do planejamento até 0 tilimo dia de teste. Tinha que ser alguém que tivesse conhecimento técnico suficiente para trabalhar com os programadores e ser respeitado por eles, mas também alguém que tivesse talento e interesse para uma participagio mais abrangente no modo como os produtos fossem feitos Para desempenhar bem esse papel, ele teria de gostar de passar seus dias executando tarefas tio variadas quanto escrever especificagées, rever planos de marketing, gerar cronogramas de projeto, liderar equipes, fazer planejamento estratégico, exccurar triagem de erzos/falhas, cultivar a moral da equipe ¢ fazer tudo © que precisa ser feito ¢ que ninguém esta fazendo (bem). Esse novo papel na Microsoft foi chamado de gerente de programa. Nem todos na equipe se reportariam diretamence a cle, mas o gerente de programa teria autoridade para liderar e orientar um projeto. (Na teoria de gerenciamento, essa é, grosso modo, a idéia de uma organizagio matricial’, onde existem duas linhas de estructura hierirquica para os individuos: uma baseada na fungio e a outra baseada no projeto. Portanto, um programador ou testador individual poderia ter dois relacionamentos hierirquicos ~ um principal para seu papel funcional e um secunditio, mas forte, para 0 projeto no qual trabalha.) Jabe desempenhou esse papel em um produto denominado Multiplan (mais, tarde tornou-se 0 Microsoft Excel) ¢ funcionou. Os processos de engenharia ¢ desenvolvimento melhoraram juntos com a qualidade da coordenagao com a equipe de negécios e em todos os corredores da Microsoft havia muita alegria. Apés muitos memorandos € reunides, a maioria das equipes na empresa adotou lentamente a fungio. Nio importam os produtos resultantes, bons ou ruins, a idéia faz sentido. Ao definir um papel para um generalista no nivel de linha, que Yo tenha sido um auxiliar de baixa qualificagio, mas um lider ou um orientador, a dinamica das equipes de desenvolvimento que trabalhavam na Microsoft mudou para sempre, Esse papel de gerente de programa foi o que eu desempenhei durante quase toda a minha carreira na Microsoft ¢ trabalhei em equipes de produto que incluiram o Internet Exploser, MSN e Windows. Gerenciei também equipes de pessoas que desempenhavam esse papel. Até hoje, nao sei de muitas empresas que tenham ido tao longe na redefinicio ¢ formalizacio de gerenciamento de projero. Era raro, em minhas eragdes com outras firmas de desenvolvimento de software e Web, encontrar alguém que desempenhasse um tipo de fungio similar (eles eram engenheiros ou administradores, ou em raras ocasides, designers). Muitas companhias usam estruturas de time para organizar 0 trabalho, mas poucas definem os papéis que atravessam deliberadamente as hierarquias de engenharia ¢ negécios. Hoje existem mais de 5.000 gerentes de programa na Microsoft (em mais de 50.000 funciondrios no total) e embora a forca da ideia tenha sido diluida (e em muitos casos mal-utilizada), 0 espirico principal 22_A Arte Do GERENCIAMENTO DE PROJETOS dela ainda pode ser encontrado em muitas equipes e grupos dentro da empresa. Mas, independente do que ¢ dito no meu cartio de visitas, ou em q) histéria da Microsoft vocé decide acreditar ou ignorar, minhas fungécs didrias como um gerente de programa eram fungoes de gerenciamento de projeto. Em tetmos mais simples, isso significava que eu tinha a responsabilidade de tornar 0 projeto ~ © quem quer que estivesse contribuindo para ele ~ t20 bem-sucedido quanto possivel. ‘Todos os capitulos deste livro refletem as tarefas principais cenvolvidas nesse procedimento, desde 0 planejamento inicial (Capitulos 3 ¢ 4), & esctita espectfica (Capitulo 7), & romada de decisio (Capitulo 8), a0 gerenciamento e a liberagio da implementagao (Capitulos 14 ¢ 15). Sob essas habilidades, surgem cerras atitudes e tracos de personalidade. Sem ‘© conhecimento delas, uma pessoa que lidera ou gerencia um projero est em séria desvantagem. O equilibrio no gerenciamento de projetos E dificil encontrar bons gerentes de projeto porque eles precisam manter um. Iibrio de atitudes. ‘Tom Peters, no seu ensaio “Pursuing the Perfect Project Manager"®, chama essas atitudes conflitantes de paradoxes ou dilemas. Esse nome é apropriado porque situagdes diferentes exigem comportamento diferente. Isso significa que um gerente de projeto precisa nao apenas estar cienve dessas peculiaridades, mas também desenvolver instintos para saber quais sio apropriados em que ocasiées. Isso contribui para a idéia de gerenciamento de projeco como uma arte: ele requer intuigao, julgamento € experiéncia para usar essas forcas. A lista de tragos a seguir ¢ aproximadamente derivada do ensaio de Peters + Ego/nao-cgo. Devido a responsabilidade que carregam os gerentes de projero, eles freqiientemente cém grande satisfagio pessoal com seu trabalho. E compreensivel que tenham um alto investimento emocional no que esto fazendo e, para muitos, essa conexfio emocional é que os permite manter a intensidade necessiria para ser eficiente. Mas, ao mesmo tempo, os gerentes de projeto devem evitar colocar seus interesses 4 frente do projeto. Eles devem delegar tarefas importantes ou divertidas ¢ compartilhar clogios e prémios com a equipe inteira, Por mais que o ego possa ser um combustivel, um gerente de projeto tem de reconhecer quando o seu ego esti atrapalhando. * Autocrata/delegador. Em algumas situagées, as coisas mais importantes sio uma linha de aucoridade clara e um tempo de resposta ripido. Um gerente de projeto tem de ser seguro ¢ obstinado o bastante para controlar ¢ forgar certas agbes para uma equipe. Entrecanto, 0 objetivo geral deve ser evitar a necessi dessas situagdes extremas. Um projeto bem gerenciado deve criar um ambiente onde 0 trabalho possa ser delegado e haja cooperagio, * Tolerar a ambigiiidade/perseguir a perfeigao. AAs fases iniciais de qualquer projeto sio experiéncias altamente abertas e fluidas onde 0 desconhecido excede em muito o conhecido. Como discutizemos nos Capitulos 5 ¢ 6, a ambigitidade le Ua Breve Historia Do GERENCIAMENTO DE Proseros 23 controlada é essencial para que boas idéias surjam ¢ um gerente de projeto deve respeité-la, se nio gerencié-la. Mas em outros momentos, particularmente nas fases finais de um projeto, a disciplina ¢ a precisio sio soberanas. E necessirio sabedoria para discernir quando a busca da perfeicao vale a pena, ou, ao contrério, uma solucéo mediocre ou répida € suficiente, (Consulte a sesio “Encontrando ¢ ponderando as opgoes" no Capitulo 8.) Verbalfescrito, Embora a maioria das organizagoes de desenvolvimento de software sejam centradas na comunicagio por email, as habilidades verbais sdo importantes para o gerenciamento de projetos. Havers sempre reunides, negociagdes, discussdes ripidas e sessGes de brainstorming, e o gerenve de projeto deve ser eficiente tanto na compreensio quanto na comunicagio de ddéias cara a cara, Quanto maior for a organizagao ou © projeto, mais, importantes se tornam as habilidades escritas (¢ a disposicio para usi-las) Apesar das preferéncias pessoais, um gerente de projeto precisa reconhecer quando a comunicagio escrita ou verbal ser mais eficaz, Reconhecer a complexidade/patrocinar a simplicidade. Muitas pessoas sfio vitimas da complexidade. Quando elas se deparam com um complexo desafio organizacional ou de engenharia, se perdem em deralhes ¢ esquecem do principal. Outras negam a complexidade e tomam decisées erradas porque nao compreendem completamente as sutilezas envolvidas. O equilibrio aqui est4 em reconhecer qual visio do projeto é mais tiril para o problema ou qual decisio ¢ conveniente ¢ alternar confortavelmente entre elas ou manté-las em mente, ao mesmo tempo (sem que sua cabeca exploda). Os gerentes de projeto devem ser convincentes para conseguir que a equipe se esforce pela simplicidade e clareza no trabalho que desempenha, sem minimizar as complexidades envolvidas na elaboracio de um cédigo confidvel e bem escrito. Impaciéncia/paciéncia, Na maioria das vezes, 0 gerente de projeto € a pessoa que incita & agio, forcando as pessoas a manter o trabalho direto e focado. Mas em algumas situagoes, 2 impaciéncia trabalha contra o projeto. Algumas atividades policicas, burocriticas out interorganizacionais sio ineviciveis escoadouros de tempo: alguém tem que estar na sala, ou estar na teleconferéncia, ¢ eles tém que ser pacientes. Portanto, saber quando forgar uma questio ¢ quando recuar ¢ deixar as coisas acontecer, é um sentido que os gerentes de projero devem desenvolver. Coragem/medo. Um dos grandes enganos da cultura americana é achar que corajosos sfo aqueles que nfo sentem medo. Isso é uma mentira. Corajosos so aqueles que sentem medo, mas decidem agir de qualquer maneira, Um gerente de projero precisa ter um grande respeito por todas as coisas que possam dar errado ¢ vé-las como totalmente possiveis. Mas também precisa corresponder esse respeito com a coragem necesséria para assumir grandes desatios Crédulo/eético. Nao ha nada mais poderoso para o moral de uma equipe do que um lider respeitado que acredita no que est fazendo. E importante que um gerente de projero tenha confianga no trabalho que esta executando e veja o verdadeiro valor nos objetivos que serio alcangados. Ao mesmo 24_A ARTE DO GERENCIAMENTO DE PROJETOS tempo, existe a necessidade de um certo ceticismo (nao cinismo) sobre como as coisas esto indo ¢ na mancira como estio sendo executadas. Alguém cem que investigar e questionar, expor suposig6es € trazer as questées dificeis & luz. O equilibrio esté em, de alguma maneira, fazer perguntas e desafiar as suposigdes de outros vigorosamente, sem abalar a confianga da equipe no que ela esté fazendo Como Peter destaca no seu ensaio, é muio raro encontrar pessoas capazes de todas essas habilidades, muito menos com a capacidade de equilibré-las adequadamente. Grande parte dos erros que todo o GP cometeri envolver4 eros de cilculo ao estimar uma ou mais dessas forsas conflitantes. Entretanto, qualquer um pode melhorar ao reconhecer, entender e, entio, aprimorar sua propria capacidade de manter essas forsas em equilibrio. Portanto, embora eu nao venha a focar essa lista de paradoxos novamence (embora ela ainda apareca algumas vezes, mais tarde), ela vale como referéncia. O exame dessa lista de forgas conflirantes, mas necessirias, pode ajudi-lo a recuar, reconsiderar 0 que voc’ esta fazendo ¢ por que ¢ tomar decisdes mais inteligentes. Press&o e distragao Um medo dos novatos no gerenciamento de projetos ¢ que 0 éxito exige muidanga. Novos projetos sio criados com a intengio de alterar 0 estado do mundo, modificando, construindo ou destruindo algo. Manter o status quo ~a ‘menos que seja 0 objetivo explicito, por alguma escranha razio ~ nfo é um bom resultado. © mundo estd mudando o tempo todo e se um site da Web ou outro projeto nio € hoje to bom quanto era no iltimo ano, geralmente significa que cesta ultrapassado porque as metas foram mal-orientadas ou a execucao do projeto falhou de alguma E dificil ignorar a pressio subjacente a isso para os gerentes de projeto, mas cla faz parte do “pacote”. Nao fique ai parados aprimore-se, Hi sempre uma nova maneira de pensar, um novo tpico para aprender e aplicar, ou um novo processo que torna o trabalho mais divertido ou eficaz, Talvez essa seja uma responsabilidade mais condizente com lideranga do que com gerenciamento, mas a distingao entre os dois € sutil. Independente do quanto tente separi-los, o bom gerenciamento requer qualidades de lideranga e a lideranga requer qualidades de gerenciamento. Qualquer pessoa envolvida em gerenciamento de projeto sera responsdvel por um pouco de ambos, no importa 0 que a descrigio do seu cargo diga Mas, voliando ao problema da pressio, conhego muitos gerentes que abdicam dos momentos de lideranca (por exemplo, algum momento em que a cequipe/rojero precisa de alguém para decidir sobre uma agio) ¢ se dedicam apenas a controlar os esforgos dos outros em vez de facilitar ou ainda participar deles. Se tudo que alguém faz é mantet o registro ¢ observar do lado de fora, cle cstaria mais bem preparado para trabalhar no departamento de contabilidade. Quando alguém em uma fungio de lideranga consistentemente responde & pressio “fugindo da raid”, essa pessoa nio esti liderando ~ esta se escondendo. Gerentes de projero ineficientes ou avessos & pressio tendem a se abrigar na petiferia do projeto, onde agregam pouco valor. neira. Una Breve Historia po GerenciaMENTo pe Proseros 25 Confundindo o processo com metas Alguns gerentes de projero nessa situacio recorrem a quantificagio de coisas que do precisam ser quantificadas. Inseguros sobre 0 que mais fazer, ou temerosos de fazer © que precisa ser realizado, eles ocupam seu cempo em coisas secunditias. Ey a medida que cresce a distancia entre o gerente de projeto ¢ o projeto, aumenta a atengio dada desnecessariamente a grificos, tabelas,listas de verificagio & relatérios. F possivel que, em algum ponto, os gerentes de projeto comecem a acreditar que os dados ¢ o processo sejam 0 projeto. Eles focam nas coisas menos importantes € com as quais ¢ ficil trabalhar (planilhas ou relatérios), ¢ nao nas questées importantes desafiadoras (0 esforgo de programacio ou 0 cronograma). Bles poderio desenvolver a crenga de que se apenas seguirem perfeitamente um determinado procedimento e verificarem as coisas certas, 0 sucesso do projeto estard garantido (ou, de maneira mais cinica, qualquer falha que ocorra no seri tecnicamente de sua responsabilidade).. Para minimizar a possibilidade de confusio, bons gerentes de projeto resistem a definigdo de limites estritos para os tipos de trabalho que desejam ou rngo execucar. Eles evitam as linhas amarelas brilhantes situadas entre as tarefas de gerenciamento de projeto ¢ 0 projeto propriamente dito. A fidelidade as listas de verificagao implica que hii um processo definitivo que garance um resultado especifico, o que nunca é 0 caso, Na verdade, sempre ha apenas trés coisas: uma meta, uma pilha de trabalho ¢ um monte de pessoas. Fungoes bem-definidas (veja 0 Capitulo 9) poderiam ajudar essas pessoas a se organizar em rorno do trabalho, mas a formagio de funges nao ¢ a meta. Uma lista de verificacio poderia ajudar fazer 0 trabalho de maneira a atingir a meta, mas a lista de verificagio também nao é a meta. Confundir processos com metas é um dos grandes pecados do gerenciamento, Eu deveria saber, pois eu mesmo jé 0 cometi. Hi alguns anos, trabalhando no projeto do Internet Explorer 4.0, eu era 0 gerente de projeto para muitas partes da interface de usuitio, Eu me sent pressionado: recebi a maior atribuigio da minha vida. Em resposta, desenvolvi a crenga de que se escrevesse tudo em listas de verificagio, nunca falharia, Embora as coisas precisem ser cnidadosamente controladas em um projeto, eu havia me excedido. Criei uma planilha complexa para mostrar varias visées de dados ¢ os grandes quadros brancos do meu escritério foram cobertos com tabelas e listas (e outros quadros brancos haviam sido encomendados). Meu chefe estava de acordo porque tudo corria bem, Isto é, até que ele me gastando mais cempo com minhas listas de verificagio ¢ processos do que com a minha equipe — 0 que levantou uma grande bandeira vermelhia (sinal de aletta). Um dia, cle entrou na minha sala e vendo a enorme quantidade de listas de verificagao ¢ tabelas que eu tinha escrito em todas as superficies planas do meu escritério, convidou-me a sentar e fechou a porta. Ele disse: “Scort, tudo isso é bom, mas seu projeto éa sua equipe. Gerencie a equipe e nio as listas de verificagio. Se as listas de verificacio ajudam a gerenciar a equipe, excelente. ‘Mas da maneira como vocé esta fazendo, em breve estan usando sua equipe para ajudar a gerenciar suas listas de verificagao” Portanto, em ver de focar em processos ¢ mézodos, os gerentes de projeto devem estar focados em suas equipes. Sistemas de planejamento ou controle simples certamente devem ser usados, mas eles devem corresponder & complexidade do projeto ¢ & cultura da equipe. Mais precisamente, planejamento 26_A Arte DO GERENCIAMENTO DE PROJETOS e controle devem dar suporte & equipe para alcangar as metas do projeto, nao impedi-las. Eu cenho certeza de que desde que o gerente de projeto preste atengio ce ganhe a confianga da equipe, quaisquer tarefas, processes, relatérios, listas de verificacio ou outros mecanismos de gerenciamento de projeto necessérios se tornarao evidentes ances que os problemas que eles deveriam resolver se tornem, sétios. Conforme discutiremos no Capitulo 10, apenas porque um livro ou um cexecutivo diz para fazer algo, ou porque uma técnica foi empregada no iiltimo més ou no tiltimo ano, nao significa que cla se aplique hoje. Cada equipe ¢ projeto é diferente ¢ exiscem varias razdes para questionar julgamentos antigos. A razio para set conservador com metodos ¢ processos € que aqueles que sio desnecessirios tendem a aumentar feito bolas de neve, arrastando as equipes para © abismo dos projetos dificeis, conforme descrito no livro The Mythical Man- Month, de Fred Brooks. Quando sio necessirios processos para gerenciar processos, ¢ dificil saber onde o trabalho real est sendo feito. E freqiientemente 0 lider da equipe ou 0 gerente do projeto que tem a maior habilidade para livrar a ‘equipe da burocracia, ou mais cinicamente, de enviar a equipe a toda velocidade para infindaveis seqiiéncias de procedimentos ¢ de avaliagoes em reunides. O tipo certo de envolvimento Tacios os gerentes — de executivos de empresas integrantes da lista das 500 maiores da revista Fortune a técnicos de equipes esportivas - sao vulneréveis a um envolvimento excessivo, Acho que em algum ponto eles sabem que represencam despesas indiretas (overhead) ¢ um envolvimento compulsive é uma maneira convenience (embora negativa) de tentar compensar isso. Iss0 explica parcialmente a oferta continua de “microgerentes”; a ago mais facil para um gerente fraco € abusar do seu poder sobre seus subordinados (¢ em casos extremos, culpar simultaneamente @ incompeténcia dos subordinados pela necessidade de muita atengio). A inseguranga que os gerentes tém deriva do fato de que, em termos de revolugio industrial, eles nfo fazem parte da linha de produgio. Eles no fizem nada com as mios ¢ no sio 0 mesmo tipo de ativo do que aqueles que fazem. Os gerentes nao sio contratados para contribuir com uma quantidade linear de trabalho para a fibrica ou para 0 desenvolvimento de software, como se espera de um trabalhador ou programador. Em vez disso, Iideres ¢ gerentes sto contratados para cumentar o valor de todos os que os cercam. Os métodos para agregar esse tipo de valor sio diferentes do trabalho em linha de produgio, Mas, como muitos gerentes sio programadores antigos e foram promovidos ’ geréncia da linha de producio, é muito provével que eles renham mais seguranca € habilidade para escrever cédigos do que para liderar ¢ gerenciar pessoas que escrevem cédigos. Como um téenico de uma equipe de beisebol, supde-se que a presenga de tum gerente contribua com algo de natureza diferente da adigio de qualquer outro colaborador. Algumas veres, isso acontece, decorrendo da solugio de conflitos ou da protegio da equipe em relagio A politica, Oucras vezes, pelo desenvolvimento de bons planos de alco nivel ou de solugées inteligentes para siruagdes inesperadas. Como essas contribuigoes so mais dificeis de medir, muitos gerentes Ua Breve Historia DO GERENCIAMENTO DE Proseros 27 de projeco lidam com a ambigitidade de suas funges. Como gerentes, eles sfo alvos ficeis de censuras ¢ tém poucos lugares para se esconder. E necesséria uma combinagao de convic¢io, confianga e consciéncia para ser eficiente € feliz como lider de uma equipe. Tirar vantagem da sua perspectiva A melhor maneira de encontrar pontos de alavancagem é fazer uso da diferenga na psicologia obrida por estar fora da linha de producio. Um gerente de projero no desempenho de suas tarelas naturalmente gastard mais tempo trabalhando com diferentes pessoas na equipe, obrendo assim mais fonces de informacdes e uma perspectiva mais ampla do projeto. O gerente de projeto entenderé a visio comercial do projeco assim como a visio técnica e ajudard a equipe a compreender ambas, quando necessirio, Essa perspectiva mais ampla possibi passagem de informagies relevantes & pessoa certa na hora certa, Uma historia simples ajuda a ilustrar esse ponto de maneira mais abrangente. Eu tinha como habito caminhar pelos corredores e visitar os programadores que deixavam suas portas abertas. Normalmente mantinha uma pequena conversa informal, tentando descontrair, contando algo que nos fizesse rir, ¢ pedia a eles que me mostrassem 0 material no qual estavam trabalhando. Se cles oferecessem, cu assistia a uma demonscragio do que quer que me moscrassem. Fazer isso durante alguns dias, mesmo que fosse por alguns minutos, me dava uma idéia do status real do projeto (no Capitulo 9, discutiremos ssa pritica de gerenciamento by walking around \por observacio)). Por exemplo, uma manha, durante 0 projeto do IE 5.0, visitei 0 escritério de Fred. Ele estava discutindo com 0 Steve, outro programador, sobre como iam fazer funcionar adequadamente 0 novo controle List View — um problema de compatibilidade nao-previsto tinha sido descoberto naquela manha deles queria fazer o trabalho. E pelo que pude ouvir, demoraria meio dia ou mais para ser corrigido. Eu me meti no assunto € me certifiquei sobre o que eles estavam falando, Eles balangaram a cabega concordando, como se dissessem: im, por que voce esti preocupado?” Entio, eu disse para eles conversarem com Bill no final do corredor. Bles perguntaram novamente por que, achando que isso era um problema de arquiitetura muito especifico ¢ que seria dificil eu entender. Sorti e disse: “Porque eu acabei de sair do escrivério dele e 0 novo controle da 4rvore estava funcionando perfeitamente na sua maquina. Ele detectou 0 problema na noite passada ¢ o cortigiu como parte de outro item de trabalho”. Agora, é claro, nessa pequena histéria eu nfo salvei o mundo ou impedi um desasire importante, Se eu nio tivesse feito essa conexio para eles, somente algumas horas ou metade de um dia teriam sido gastos (embora, como discutiremos mais tarde no Capitulo 8, os cronogramas as vezes erram um pouco). Mas, esse nfo & 0 ponto. Bons gerentes de projeto se empenham para conhecer todos o8 tipos de coisas titcis sobre a situacio da equipe ¢ também do mundo ¢, entio, aplicar esse conhecimento para ajudar as pessoas a executar seus projeros. Sao as transferéncias de informagées oportunas, como a dessa hist6ria, que transformam equipes mediocres em boas ¢ estas em equipes excelentes. Nenhum sistema de controle de projero ou de erros substitui completamente a necessidade de conversar com as pessoas sobre o que est acontecendo, porque as Nenhum 28_A ARTE DO GERENCIAMENTO DE PROJETOS redes sociais sfio sempre mais fortes (e, as vezes, mais ripidas) do que as redes tecnoldgicas. Os desafios importantes, como visio de projeto, listas de recursos ¢ ccronogramas sempre se craduzem em muitos pequenos desafios que sio positivamente influenciados pela rapidez com que © bom conhecimento ¢ a informagio fluem através de uma equipe. Os gerentes de projeco desempenham tum papel critico em cornar esse fluxo ativo e saudavel Mas, sejam coisas grandes ou pequenas, as ages ¢ decisdes que os gerentes tomam devem rer beneficios claros para a equipe inteira. Elas podem demorar luma semana ou um més para se Fazerem notar, mas um bom gerente de projeo criaré um impacto positive na qualidade do trabalho produzido e, freqiientemente, na qualidade de vida de todos os envolvidos. As pessoas perceberio diferentemente seus trabalhos, dirio abertamente que tém uma melhor compreensio do que estio fazendo e por que, ¢ se sentirio melhor sobre 0 que esti por vir. Esse tipo de mudanga s6 acontece a cada reuniio, decisio ou discussio mas, ao longo de um projeto, essa vibragio ¢ energia podem mudar ¢ melhorar dramaticamente. Gerentes de projeto criam valor unico Como resultado, bons gerentes ¢ lideres freqtientemence ganham um tipo especial de respeito dos programadores, testadores, designers, pessoal de marketing ¢ documentagio. O gerence de projeto deve ser capaz de executar a faganha de pensar, liderar ¢ criar estratégias que causem impacto positive na equipe de maneita tal que poucos o conseguiriam, Freqiientemente isso envolve encontrar atalhos ¢ otimizagdes inteligentes no fluxo de trabalho didrio ou dar um impulso no entusiasmo ou encorajamento da maneira certa e na hora certa, Bles nao precisam ser super-homens, out ter um brilho especial para fazer isso (como eu descobri). Precisam apenas entender a vantagem de suas petspectivas e decidir fazer uso delas. Hi um simples fato indiscutivel: os lideres ou gerentes de projeto gastam mais tempo com cada membro da equipe de projeto do qualquer outra pessoa. Eles esto em mais reunides, visitam mais escritérios ¢ conversam com mais colaboradores individuais do que qualquer outra pessoa. Bles tomam mais decisdes out as influenciam mais do que qualquer outra pessoa na organizacio. Quando o gerente de projeco esté feliz, triste, motivado ou deprimido, um pouco desse sentimento if contagiar todos aqueles que 0 encontrarem naquele dia. O que os gerentes de projeto trouxerem para o projeto, seja bom ou ruim, contagiar o resto da equipe. Portanto, se 0 gerente de projeto for focado, comprometide, entusiasmado ou capaz de ser bem-sucedido, as possibilidades de todos se comportarem da mesma maneira aumenta, Gerentes de todo tipo esto em posigoes similares de poder potencial, ¢ existem poucos pontos de influéncia de mesmo valor na maiotia dos ambientes de trabalho. Isso significa que se for possivel cultivar as atitudes e idéias descritas até aqui, nao hi melhor lugar para fazer esses investimentos do que em lideres ¢ gerentes. Isso no quer dizer que um gerente de projeco precisa ter a imagem carismatica de herdi que, com um simples gesco, pode liderar exércitos de programadores em uma batalha (veja a seco “O complexo de heréi” no Capitulo 11). Em vez disso, basta estar genuinamente Ua Breve Historia DO GERENCIAMENTO DE Projeros 29 interessado em ajudar os relacionamentos de seus companheiros de equipe e ter mais éxiro do que fracassos nessa rarefa. Finalmente, acredito que a idéin principal é que desde que ninguém saia ferido (exceto talvez os concorrentes) ¢ vocé envolva as pessoas da mancira certa, nada mais importa exceto o faro de que coisas boas sejam feitas. Nao importa quantas idgias venham de vocé ou de qualquer outra pessoa, desde que o resultado seja positivo, O gerenciamento de projeto consiste em usar todos os meios necessérios para aumenrar a probabilidade e a velocidade de resultados positivos. Um mantra titi que tenho usado diariamente € “Faca coisas boas acontecer”. As pessoas poderiam me ver no corredor ou trabalhando com um programador em um quadro branco ¢ perguntar: “Ei Scott, 0 que voc’ esti fazendo?” E eu sorriria dizendo: *Fazendo coisas boas acontecerem’”. Isso tornou- se uma parte dominance de como cu enfrentei cada dia e, quando gerenciei outras pessoas, essa atitude se estendeu de forma a abranger toda a equipe. A medida que los deste livro forem passando, espero que voce sinta essa atitude ¢ que as idéias principais deste capitulo de abertura perdurem. Resumo Cada capftulo deste livro terminard com um pequeno resumo dos pontos-chave para ajudé-lo a revé-los mais tarde: + O gerenciamento de projeto esti em todo lugar ¢ jd existe ha muito tempo. * Se voce mantiver uma mente de iniciante, ter mais oportunidades de aprender. + O gerenciamento de projeto pode ser uma tarefa, uma fungio ou uma atividade (@ orientagao deste livro se aplica bem a todas as definigées). + O gerenciamento de programa é a funcio do gerenciamento de projeto fortemente definida pela Microsoft. Deriva da idéia de uma organizagio matricial. * Lideranga e gerenciamento exigem entendimento e intuigio sobre virios paradoxos comuns, Isso inclui ego/néo-ego, autocracia/delegagio ¢ coragem/ medo. + Esteja atento para a pretensio ¢ para o envolvimento excessivo na sua atividade de gerenciamento. O processo deve dar suporte a equipe, ¢ nio 0 contritio. * Se voce é um gerence dedicado, procure meios de capitalizar sua perspectiva tinica da equipe ¢ do projeto. SOUR «| #4¥d Capitulo 2 A verdade sobre os cronogramas 34_A ARTE DO GERENCIAMENTO DE PROJETOS CANS pest bvd ea otataraeDoslnn sarmenye agit entaunes de wee quando ou poucas vezes em uma semana, mas as pessoas estio freqiientemente atrasadas em scus compromissos didrios. (Porém, como a negacio parece ser outra grande habilidade inerente aos seres humanos, compreenderemos se recusat a admitir que essa afitmaco se aplica a vocé.) Os alunos do ensino médio se atrasam para as aulas, os adultos se atrasam para as reunides de trabalho © os amigos chegam 10 minutos atrasados ao bar para a confraternizagio. Parece que no inconsciente, acreditamos que chegar na hora combinada nao equivale a ter como objetivo um momento especifico ¢ sim um intervalo de momentos, ¢ para algumas pessoas, este intervalo € maior do que para outras. Um exemplo interessante acontece com muitas recepcionistas que nos cumprimentam nos restaurantes. Elas nos informam que uma mesa logo estat dispontvel!, mas geralmente nos fazem esperar por muito tempo. Sio essas experiéncins de atrasos em agendamentos, de ser colocado em espera no telefone ou de aguardar no consultério do médico, que nos levaram a sermos céticos em relagio aos agendamentos de horitios ~ temos muitas experiéncias de que a vida nio funciona de acordo com eles. Portanto, néo é nenhuma surpresa que tantos projetos atrasem. Como seres humanos, a maioria de nés aborda o cronograma do projeto com um histérico questionével quanto a entregar ou receber coisas na hora certa. Temos a cendéncia de fazer estimativas bascadas em suposigacs inconsistentes, prever resultados para © trabalho com base no melhor conjunto de circunstdncias possivel, e (dadas as nossas experiéncias anteriores) simultancamente cvitar depositar muita confianca em qualquer programagao que vemos ou criamos. Por que fizemos isso, como isso afeta 0 cronograma dos projetos ¢ 0 que pode ser feito para evitar esses problemas, sao 08 assuntos deste capitulo. Mas antes de entendermos como melhorar os cronogramas, p temos que compreender quais problemas sio resolvidos por cles. Se eles nio sio confidveis, por que se preocupar com eles afinal? Os cronogramas server a diversas inalidades ~ apenas algumas dessas tém © propésito de medir 0 uso do cempo. Os cronogramas tém trés finalidades ‘Todos os cronogramas, seja pata planejar uma festa de fim de semana ou para atualizar um site na intranet, servem a urs finalidades principais. A primeira ¢ mais conhecida é para agendar compromissos. O cronograma & uma forma de contrato entre as pessoas de uma equipe ou de uma organizacio, confirmando 0 que cada um inf produzir durante a préxima semana, més ou ano. Geralmente, quando as pessoas pensam em cronogramas de projetos, essa é a primeira finalidade que thes vem & cabega. Os cronogramas normalmente esto voltados para farores extenos, fora do ambito da equipe de projeto, porque sio usados para ajudar a fechar um acordo ou arender a agenda de um cliente. Preqiientemente, o cliente estard pagando pela agenda, assim como pelo servigo oferecido (pense na UPS ou FedEx). Para permitir que clientes ou parceiros figam planos baseados em um determinado projero, deve haver um acordo sobre 0 momento em que eventos especificos ocorrerio. A VERDADE SOBRE OS CRONOGRAMAS 35 ‘A segunda finalidade de um cronograma é estimular todas as pessoas que contribuem para um projeto a ver seus esforcos como parte de um todo e a se empenhar para que todas as pegas funcionem. Até que haja uma proposta de cronograma sugerindo datas ¢ hordrios especificos para a conclusio de tarefas, € pouco provavel que as conexdes ¢ dependéncias entre pessoas ¢ equipes sejam examinadas. Em ver disso, cada pessoa trabalhar4 em sua propria carefa ¢ tender a nao se preocupar a respeito de como a sua tarefa afetard as das outras. Somente apés os detalhes serem documentados, com os nomes das pessoas prdximos a eles, é que os cileulos reais podem ser feitos ¢ as premissas examinadas, Isso € verdadeiro mesmo para equipes pequenas ou pessoas que estejam trabalhando sozinhas. Hil um poder psicalégico em um cronograma que externa ¢ amplifica 0 compromisso que esti sendo assumido. Em vex de datas ¢ compromissos apenas dentro das mentes de algnmas pessoas, eles sio documentados ¢ passam a existir no universo de forma independente. Nao ¢ tao ficil esquecer ou ignorar algo que esteja exposto em um quadro de comunicagies nna entrada, lembrando a vocé ou & equipe do que precisa ser feito. E especificamente para GPs: com uma proposta de cronograma estabelecida, perguntas sobre © grau de realidade de certos fatos podem ser levantadas e podem set feitas comparagoes entre 0 que o projeto € solicitado a realizar com 0 que parece possivel em um dererminado perfodo de tempo. Essa mudanga psicolégica ou deslocamento da “pressio” é 0 que denominamos de uma “fungio compelidora” (forcing function). Uma “fangio compelidora” ¢ algo que, quando estabelecido, forsa naturalmente uma mudanca na perspectiva, aticude ou comportamento. Portanto, os cronogramas si0 importantes fungdes compelidoras para os projetos. Se usados apropriadamente por um GP 0s cronogramas obrigam todas as pessoas cujos trabalhos sao neles citados a pensar cuidadosamente no que precisam fazer e como isso se encaixa no que os outros estao fazendo. E: do relacionamento entre as partes independe um pouco do cronograma propriamente dito. Essa fungio compelidora € uma etapa crucial no sentido de realizar todo 0 potencial do projero. Mesmo que 0 cronograma seja deslocado no tempo, duplicado, reduzido A metade ou passe por uma série de outras trocas atormentadoras, os compromissos ¢ as conexées que todas as pessoas fizeram entre si sero mantidos. Portanto, essa segunda finalidade de um cronograma pode ser atingida e justificar nteiramente o esforgo despendido na sua criagio, mesmo que esse cronograma se revele, mais tarde, scriamente impreciso. Por exemplo, se 0 projeto vier a se atrasar muito, a existéncia de um cronograma seré crucial para ajudic-lo em sua conclusio. A terceira finalidade dos cronogramas é dar a equipe uma ferramenca para rastrear 0 progresso feito ¢ para desmembrar o trabalho em partes gerenciiveis. Desmembrar os procedimenros em etapas de um out dois dias realmente ajuda as pessoas 2 compreenderem o que precisam fazer. Imagine se, a0 construir uma casa, 0 construtor tenha proposto um item de linha: “Casa: 120 dias”. Com tao baixo nivel de detalhe, ¢ dificil para alguém, incluindo © préprio construtor, compreender 0 que precisa ser feito primeiro ou quais itens do trabalho sio mais caros ou trabalhosos. Mas se 0 construtor puder fornecer um desmembramento semanal das atividades, todo mundo teré uma compreensio mais clara de quais carefas serio executadas e quando, e cada membro da equipe ter4 mais oportunidade de fazer perguntas pertinentes ¢ de esclarecer as premissas. 36_A ARTE DO GERENCIAMENTO DE PROJETOS Do ponto de vista dos GPs, um bom cronograma proporciona uma visio mais clara do projeto, faz emergir os desafios ¢ as omissoes e aumenta as possibilidades de ocorréncia de fatos positivos. Quanto maior ¢ mais complexo 0 projeto, mais importantes sio os cronogramas. Em projetos maiores, ha mais dependéncias interpessoais, ¢ as decisées e horirios tém mais possibilidades de afetar outras pessoas. Quando vocé tem algumas pessoas trabalhando em uma pequena equipe, sio muito maiores possibilidades das pessoas identificarem problemas miituos no trabalho de cada luma. Atrasos de cronograma em equipes pequenas nao sio boas noticias, mas, nesse caso, tim atraso de meio dia no projeto representa uum esforgo adicional de meio dia para apenas trés pessoas, tratando-se assim de um problema recuperivel. Alguém pode trabalhar até mais tarde ou, se necessirio, toda a equipe pode se reunir ¢ concordar em ajudar a compensar 0 tempo perdido. Em um projeto maior, com dezenas ou centenas de pessoas e componentes, um atriso de um dia pode produzir rapidamente um efeito cascata e criar problemas de todos os tipos ¢ de formas imprevisiveis, 0 que geralmente esti alm do ponto de recuperagio de tuma equipe. De qualquer maneira, equipe grande ou pequena, os cronogramas proporcionam aos gerentes ¢ auditores a oportunidade de formulae perguntas, fazer ajustes ¢ ajudar a equipe identificando e respondendo as questées 1 medida que surgem, Com essas trés finalidades em mente, ¢ facil ver que cronogramas perfeitos nio solucionam todos os problemas increntes aos projetos. Um cronogeama nao pode remediar priticas de projero ou de engenharia ineficientes, nem pode proteger um projeto de uma lideranca frégil, de metas imprecisas ¢ de comunicagio inadequada. Portanto, por maior que seja o tempo consumido na elaboracio dos cronogramas, elas continuario sendo apenas listas de palaveas ¢ niimeros. Depender de alguém a sua utilizagao como uma ferramenta de gerenciamento e orientagio de um projeto. Com isto em mente, é 0 momento de apresentarmos 0 extenso vocabulitio ¢ explorarmos as metodologias de software — 0s equipamentos pesados do gerenciamento de projetos. “Balas de prata” e metodologias Hi muitos sistemas diferentes para planejar ¢ gerenciar 0 desenvolvimento de software, Basses sistemas freqiiencemente sio chamados de metodologias, que significam um conjunco de priticas direcionado para a obtengio de um certo tipo de resultado. Os métodos de softwares comuns incluem 0 modelo em cascata (warerfall model), modelo em espiral (spiral model), desenvolvimento ripido de aplicativos (Rapid Applications development), programagao extrema (Extreme Programming) e desenvolvimento orientado para recursos (Feature-driven development). Todos esses métodos tentam solucionar problemas semelhantes de organizagio ¢ gerenciamento de projetos. Cada um deles possui pontos fortes & fracos ¢ é necessitio conhecimento ¢ experiéneia pata decidir qual deles é 0 apropriado para determinado tipo de projeto. Mas meu objetivo neste capitulo, ¢ neste livro, nao é discutir ¢ comparar metodologias ¢ sistemas diferentes a serem utilizados. Acredito que haj conceitos ¢ téticas que estio subjacentes a todos deles ¢ que precisam ser dominades para se obter éxito com qualquer metodologia, Em todos os casos, A VERDADE SOBRE OS CRONOGRAMAS 37 as metodologias precisam ser ajustadas ¢ adaptadas para se encaixar As particularidades de uma equipe e de um projeto, ¢ isso sé é possivel se voce possuir uma base de conhecimentos que seja mais ampla do que as préprias metodologias. Portanto, se vocé puder compreender ¢ pér em pritica as idéias subjacentes descritas neste capitulo e no restante do livro, suas chances de atuar de forma eficaz aumentario, independence de qual metodologia esteja usando. Explicarei aspectos de certos métodos conforme a necessidade de esclarecer pontos, mas vocé precisaré procurar em outras fontes caso esteja 4 procura de metodologias?. Embora os métodos ¢ processos para o desenvolvimento de softwares sejam muito importantes, cles nao sio, em si mesmos, “balas de prata” (que resolvem 0 problema com um nico tiro) ou garantia de bons resultados. A pior atitude € seguir cegamente um conjunto de regeas ou procedimentos que claramente nao esti funcionando, simplesmente porque aparece em algum livro famoso ou sio promovidos por um guru bem conceituado, Quase sempre, tenho percebido que a dobsessio por um processo é um sinal de alerta para problemas de lideranga: pode ser uma tentativa de descarregar os desafios e responsabilidades naturais que os gerentes enfrentam em um sistema de procedimentos burocracias que sssidade de pensamento e agao reais. Talvez ainda mais devastador para uma equipe seja o fato de a fixagio na metodologia ser um sinal do que é realmente importante para a organizagio. Como ‘Tom DeMarco escreve no livro People Ware: obscurecem a nec ‘A obsessio com metodologias no local de trabalho é outro exemplo da ilusio sobre alta tecnologia. Tem sua origem na conviegio de que o que realmente importa ¢ a tecnologia... Qualquer que seja a vantagem tecnol6gica, ela s6 pode ser alcangada 20 custo de um agravamento significativo da parte sociolégica da equipe. Ao se concentrar em métodos ¢ procedimentos, em ver de na criagio de procedimentos que déem suporte ¢ amplifiquem 0 valor das pessoas, os projetos comegam 0 cronograma limitando as contribuigées dos individuos. les podem definir uma ténica de regras ¢ de cumprimento das regras, em vex. de promover 0 pensamento e o ajuste ou melhoria das regras. Portanto, tenha muito euidado com a forma como vocé aplica qualquer metodologia que utilize: nao deve ser algo imposto a equipe. Deve ser algo que dé suporte, estimule e ajude a equipe a exccutar um bom trabalho no projeto’ ‘Assim, lembre-se que 0 uso de uma ou de outta metodologia nunca € a tinica razio para que um projeto cumpra ou nfo o seu cronograma, Hi fatores que afetam todas as programagoes do projeto ¢ os gerentes tém de procurar compreendé-los antes que qualquer cronograma seja definido. Mas antes de falarmos sobre isso, precisamos abordar os componentes de um cronograma. Com o que os cronogramas se parecem Hi um principio geral bésico para todos os cronogramas: a regra dos rergos. uma estimativa extremamente imprecisa ¢ que nao deve ocupar lugar de destaque, 38_A Arte Do GeRENCIAMENTO DE PRosETOS mas é a maneira mais simples de abordar e compreender os cronogramas. Se voce possui experiéncia com o assunto, prepare-se, pois vou simplificar ainda mais todo 0 processo. Estou fazendo isso para proporcionar 0 embasamento mais simples possivel para falar sobre 0 que pode dar errado, por qui isso acontece ¢ 0 que pode ser feito a respeito. Bis aqui como © modelo ultra-simplificado de cronograma funciona: para qualquer projet, desmembre 0 tempo disponivel em trés partes ~ uma para 0 projeto, uma para a implemenracéo e uma para os testes. Dependendo das metodologias a serem usadas, ssas fases poderio ter nomes diferentes ou podem sobrepor-se mutuuamente de certas maneiras, mas todas as metodologias dedicam tempo para essas trés atividades. Em um determinado dia, vocé pode estar pensando no que deve ser feito (projerando, ou designing), ou realmente executando esse procedimento (implementando eédigo de produgio, ott programando) ou verificando, analisando e refinando © que esti pronto {testando). Aplicando a regra dos tergos De acordo com a regra geral, para cada dia que vocé espera gastar programando, um dia deverd ser gasto planejando ¢ projetando o trabalho, ¢ um outro dia seré para testar e refinar esse trabalho (consulte a Figura 2-1). E-a coisa mais simples do mundo e é uma maneira ficil de examinar algum cronograma existente ou de comecar um novo cronograma desde o inicio. Sc o tempo total nao for mais ou menos dividido nos crés tipos de trabalho, deverd haver raz6es bem compreendidas para que 0 projeto demande uma distribuicéo nao-uniforme de esforgo. Desequilibrios na regra dos tergos — digamos, 20% de tempo a mais dedicado a testes do que para a implementagio — so bem aceitos contanto que sejam deliberados Projeto Tempo; = Programacio | Testes FIGURA 2-1. 0 oronograma de projeto com a regra dos tercos. Considere um projeto de desenvolvimento hipotético para a Web: se voce tiver tum prazo de seis semanas para conclui-lo, 0 primeiro passo deve ser dividir mais ‘ou menos esse tempo em tergos ¢, usando essas divisdes, estimar quando 0 trabalho poder ser concluido. Se isso nao proporcionar tempo suficiente para fazer 0 trabalho esperado em um nivel mais alto, entao, algo esta fundamentalmente ertado. Ou o cronograma precisa ser mudado, ou o volume de trabalho que se pretende concluir precisa ser reduzido (ou algumas expectativas de qualidade precisam ser A VERDADE SOBRE OS CRONOGRAMAS 39 diminuidas). Cortar 0 tempo da fase do projeto ou dos testes apenas aumentari a possibilidade de que o tempo gasto realmente escrevendo 0 cédigo seja mal- orientado ou resulte em um eédigo mais dificil de gerenciar e manter. A regra dos tercos € titil porque forca a natureza de soma-zero de projetos a vir & tona. Adicionar novos recursos exige mais do que apenas um programador para implementé-los; ha custos inevitaveis de projeto e de testes que alguém tem de pagar. Quando os cronogramas atrasam, € porque havia custos escondidos ow ignorados que nunca foram reportados. Desenvolvimento gradual (o projeto de antiprojeto) Para finalizar, vale a pena considerar 0 caso mais simples possivel: nio hd nenhum projeto. Todo o trabalho é concluido de forma gradual — as solicitagées chegam, sio avaliadas em relagio a outros trabalhos e, em seguida, sio inseridas no proximo intervalo de tempo disponivel do cronograma. Algumas equipes de desenvolvimento, desenvolvedores de sites ou departamentos de programacio de TI tabalham muito dessa forma. Essas organizagoes raramente fazem wvestimentos ou compromissos em larga escala. Métodos Ageis (discutidos mais adiante) sio recomendados freqiientemente a essas equipes como o sistema mais natural para organizar trabalho porque esses métodos realgam a flexibilidade, simplicidade ¢ expectativas de mudanga, Se vocé erabalha em varias pequenas carefas (mio em projetos) de cada vez, teri que se basear nos exemplos centrados ‘em projetos que cu uso neste livro. Porém, a regra dos tercos ainda se aplica a essas sicuagbes. Mesmo que cada programador esteja trabalhando sozinho em pequenas tarefas, é possivel que cle giste quase um rergo de seu tempo toral descobrindo o que precisa ser feito, um terco de seu tempo executando isso ¢ 0 otttro tergo certificando-se de que tudo funciona adequadamente. Ele dispoe de alguma flexibilidade na utilizagio desse tempo, mas como uma maneira simplificada de compreender qualquer tipo de trabalho, a regra dos tergos se aplica bem em qualquer escala, Divida e conquiste (grandes cronogramas = muitos cronogramas pequenos) Se examinar a maioria das metodologias de desenvolvimento de sofiwares, voce pode ver os contornos da regea dos rercos. As metas e abordagens especificas usadas para projetar ¢ implementar os procedimentos podem ser muito diferentes, no nivel mais alto, os resultados desejados so semelhantes. ‘Onde isso se torna complexo é em projetos maiores ou mais longos, em que 0s cronogramas sio dividides em pecas menores, cada peca tendo o seu proprio cempo de projeto, implementagio ¢ teste. A Programacio Extrema (Extreme Programming, conhecida como XP) chama essas pegas de iteragoes; 0 modelo em espiral as chama de fases; e algumas organizagées as chamam de etapas. Embora a XP implique que esses intervalos de tempo sejam apenas de algumas semanas ¢ o modelo em espiral implique que eles sejam de meses, a idéia fundamental é a mesma: criar cronogramas detalhados por periodos limitados de tempo. m: 40_A Arr DO GERENCIAMENTO DE PROJETOS Quanto mais alteragées ¢ volatilidade do projeco forem esperadas, mais curta deve ser cada etapa. [sso diminui o risco global do cronograma porque 0 plano mestre foi dividido em pedagos gerencisveis. Essas quebras entre intervalos de tempo maiores do cronograma proporcionam oportunidades naturais para fazer ajustes € melhorar as chances de que a préxima etapa direcionaré seu trabalho de forma mais precisa, (Discutiremos como fazer isso no Capitulo 14.) Métodos agil e tradicional AXP ¢ outtos métodos dgeis presumem que o futuro € sempre volitil, ¢ assim apostam em processos que incorporem facilmente mudangas de diregio. Os projetos que tém custos de producéo muito elevados (digamos, construit um arranha-céu, um console de video game ou um sistema operacional incorporado) se comportam de outra maneita e investem macigamente em atividades de planejamento e projeto. Isso pode ser feito, mas todos tém de se comprometer com as decis6es tomadas durante o planejamento, ¢ com 0 custo proibitivo das alteragGes, tende a ser a nica maneira de isso acontecer. A maioria dos projeros de desenvolvimento de softwares est em algum lugar no meio disso tudo. Eles rém algum planejamento inicial, mas para ajudar a gerenciar a volarilidade furura de requisitos ¢ demandas do cliente, 0 trabalho é dividido cm fases que tém 0 tempo alocado para projeto (design), implementagao e garantia de qualidade. Se surgir um novo problema, isso pode set considerado 1a fase atual ou ser colocado no repositdtio de trabalhos para ser investigado ¢ compreendido adequadamente durante a proxima fase. Na maioria dos projetos, esse momento de planejamento inicial & usado para capturar informagoes suficientes dos clientes ¢ grupos de negécios para definir quantas fases so necessdrias € qual deve ser 0 foco de cada uma (consulte a Figura 2-2). Dependendo do plano maior, cada fase pode dedicat mais tempo para projetar ou testar. Uma fase pode ser dividida em duas fases menores {assemelhando-se a um estilo mais dgil de desenvolvimento) ou duas fases podem ser reunidas e combinadas {assemelhando-se a um desenvolvimento mais monolitico). Mas em todos os casos, o tempo deveria ser alocado entre fases para tirar vantagem do que tiver sido alterado. Isso inclui responder a problemas que surgiram durante a fase anterior e que nao puderam ser resolvidos ‘completamente. Este € 0 limite a que chegarei no que se refere A metodologia de cronograma de alto-nivel. Os Capitulos 14 15 abordaréo como gerenciar um projeto a0 longo de tedo 0 cronograma, mas eles se concentrario nas perspectivas de gerenciamento e lideranga - nao nos detalhes de como vocé aplicou uma determinada metodologia. Se puder chegar até os tiltimos parigrafos (mesmo que nao concorde totalmente com as consideragées feitas neles), entao as recomendagées constantes nos Capitulos 14 15 poderio ser pertinentes e tteis, independente de como vocé organizou ou planejou seu projeto. De qualquer maneira, pego desculpas a todos os vereranos em desenvolvimento que tenham passado mal ou adoccido durante esta secio. Agora que terminou, prometo que essa visio leve e simples de cronograma € quase tudo que vocé precisar4 para compreender os conceitos do restante do capitulo, A VERDADE SOBRE OS CRONOGRAMAS 41 Penearenta init Projeto faery | Implomentacdo ‘este Projeto | Implomantagao \Fase 2 Teste | Projeto Implomentagte | Taste FIGURA 2-2. Um grande projeto deve ser uma soqiéncia de pequenos projotos. Fase 3 Por que os cronogramas falham Os cronogramas de projetos sio os bodes expiatérios preferidos para tudo 0 que possi dar errado. Se alguém erra uma estimativa, omite um requisito ou & atingido por um énibus, é o cronograma (ea pessoa responsivel por ele) que leva a culpa, Se o fornecimento de energia do pais fosse interrompido por 10 dias ou ‘8 melhores programadores da equipe ficassem muito doentes, invariavelmente alguém diria: “Veja, eu disse que o cronograma atrasaria” e apontaria 0 dedo para 0 rosto do responsével por ele. E roralmente injusto, mas acontece o tempo todo. Tanto quanto detestam os cronogramas, as pessoas ainda os apresentam como um padco inatingivel. Mesmo os melhores desenvolvedores de cronogramas do mundo, com as mentes mais brilhantes ¢ as melhores ferramentas & disposiio, inda estio rentando prever o futuro — algo que raramente fazemos bem. ‘Mas, se uma equipe comeca um projeto muito atenta as proviveis razdes pelas quais os cronogeamas falham e roma alguma aticude para minimizar esses riscos, cle pode se tornar uma ferramenta mais titil ¢ precisa no processo de desenvolvimento. Atirando as cegas de muito, muito longe Se um cronograma ¢ criado durante 0 planejamento inicial, centenas de decisoes que 6 afetam ainda tém de ser tomadas. Havers problemas e desafios, que 42_A Arte DO GERENCIAMENTO DE PROJETOS ninguém pode prever, ¢ no hé nenhuma forma de elaborar um plano cespeculativo antecipadamente. Até que os requisitos sejam compreendidos ¢ um projeto de alco-nivel esteja bem encaminhado, um gerente de projero fica completamente is cegas € possui pouquissimas informag6es para fazer previsoes realistas. No entanto, na maioria das vezes, um cronograma rudimentar incompleto é criado com niimeros inventados e especulagoes precipitadas, e esse espantalho resultante € passado % equipe com a aparéncia de um plano de projeto possivel. Freqiientemente, as pessoas so vitimas de uma armadilha precisio verss cexatidao: um cronograma aparentemente convincente com datas ¢ horérios especificos (preciso) nfo est necessariamente reflerindo a realidade de perto (exatidao). Precisio € ficil, mas exatidio € muito dificil. Porém, é certo que todos os projetos e cronogramas tém de comecar por algum lugar. Um “tiro no escuro” pode ser usado para estimular uma equipe ¢ estabelecer alguns limites. Isso pode iniciar um processo de investigagéo para cesmiugar 0s cronogramas ¢ levantar quest6es importantes ¢ respondé-las. Mas se uma extensa especulagio sem verificacio e exame prévios for usada como base para um cronograma — sem nenhum refinamento adicional — podemos esperar grandes riscos. H4 fortes evidéncias de que € dificil para qualquer um estimar antecipadamente a quantidade de tempo necessiria a um projero Barry Bochm, em seu ensaio de 1989 sobre a engenharia de soflware, descobriu que os erros em cronogramas crescem em relacio ao grau de antecipacio com que sao feitas as estimativas do cronograma do projeto (como pode ser visto na Figura 2-3). Se as estimativas torais do cronograma sio feitas precocemente, podem se distanciar até 400%, em qualquer dire¢a0 (suspeito que os erros fém um viés contra nés, tendendo a levar mais tempo que esperamos, embora os dados disponiveis nio mostrassem isso). Durante a fase de projeto, 1 medida que mais decisoes sao esclarecidas, a variagao diminui, mas ainda é grande. Somente quando 0 projeto estiver em implementagao € que o intervalo de estimativas do cronograma se torna razoavel, mas mesmo nesse momento, ainda h4 uma oscilacio de 20% no grau de exatiddo que se espera das decisdes de cronograma. Inicio do Andlise de Projet —_implementagao ‘projeto roquistos (design) FIGURA 2-3. 0 intervalo de erros de estimativas durante os projetos (adaptado de Boehm, Software Engineering Economics). A VERDADE SOBRE OS CRONOGRAMAS 43 Isso significa que os gerentes de projetos precisam compreender que as estimativas de cronogramas crescem em exatidio 20 longo do tempo. Os cronogramas demandam mais atengio 4 medida que ocorre © progresso e que ajustes sio Feitos, conforme 0 projeto segue em frente. Um cronograma é uma probabilidade Quando era recém-formado pela universidade ¢ estava trabalhando em meus primeiros projetos de maior importancia (Windows e Internet Explorer), os cronogramas de alto nivel eram passados para a minha equipe por alguém muito mais importante do que eu. Sendo muito inexperiente para me envolver mais no processo, 0 cronograma seria apresentado um dia, ¢ era meu trabalho aplicar esse Cronograma mestre a0 pequeno ntimero de programadores e testadores com os quais trabalhava. Embora negocidssemos diferencas entre esse ctonograma mestre ¢ 0 cronograma gerado pela minha equipe baseado em itens de trabalho,> aquele cronograma de alto-nivel sempre pareceu ter surgido do nada, Descia do céu, cuidadosamente formacado, distribuido em colunas de datas ¢ mimeros perleitos. Era como se fosse um artefato roubado do futuro. No importa o satcasmo ou cinismo com que tratavamos 0 assunto, na maioria das vezes segufamos esses cronogramas fielmente. Apesar do mistério de suas origens, tfnhamos uma boa razio para confiar em nossas liderangas de equipes ¢ estévamos suficientemente ocupados com nosso préprio trabalho para no nos preocuparmos muito com os deles. (Na realidade, freqiientemente eles forneciam explicacdes bdsicas para aqueles cronogramas iniciais vindos de cima para baixo, mas estvamos muito ocupados muito confiantes para prestar atengio.) Posteriormente, quando 0 cronogtama ficou sob minha responsabilidade, percebi a verdade oculta. Eles nfo sao presentes vindos do futuro. Nao ha nenhuma {rmula magica ou ciéncia para criar cronogramas perfeitos. Apesar de minhas percepc3es imaturas, 0 cronograma nfo € uma tarefa isolada: sempre representa e engloba muitos aspectos diferentes do que o projeto € agora ¢ serd no futuro. Os cronogramas sio simplesmente um tipo de previsio. Nao impor grau de preciso com que sejam delineados ou até que ponto paregam convincentes, sio apenas uma soma de varias estimativas, cada uma evitavelmente propensa a tipos diferentes de omissdes e problemas imprevisiveis. Os bons cronogramas so provenientes somente de um lider ou de uma equipe que persiga implacavelmente ¢ alcance um bom julgamento a respeito de muitos aspectos diferentes de desenvolvimento de softwares, Vocé nao pode ser tim petito em determinadas partes do proceso de fabricacio de algo ¢ esperar que tudo sempre dé certo na criagio de cronogramas. Portanto, se todos na equipe podem concordar que 0 cronograma é um conjunto de probabilidades, entao o problema nio esti no ctonograma proptiamente dito — esté em como ele é usado. Se alguma vez um ctonograma for mostrado em uma reuniéo de equipe ot enviado por email, esta é uma pergunta valida: qual 0 grau de probabilidade com que a linha de tempo é definida? Se nenhuma probabilidade for oferecida (por exemplo, quais s0 0s cinco riscos mais provaveis ¢ uma especulagio sobre a probabilidade da ocorréncia deles) ¢ se quem 44_A ARTE DO GERENCIAMENTO DE PROJETOS criou 0 cronograma nao puder oferecer explicagbes sobre as suposig&es feiras, sempre deverfamos presumir que 0 cronograma é possivel, mas improvavel.§ A equipe deveria ser estimulada a fazer sugestGes sobre quais consideragGes ou informagies podem ser adicionadas ow alteradas no cronograma pata torné-lo factivel. Portanto, 0 segredo aqui € que um cronograma nao tem que ser perfeico (0 que é um alivio, é claro, porque nao existem cronogramas perfeitos). Os cronogramas precisam scr suficientemente bons para que a equipe ¢ o» lideres acreditem, fornecer uma base para o monitoramento € os ajtistes, e ter uma probabilidade de sucesso que satisfaga 0 cliente, 0 negécio ou o patrocinador do projeto global. Fazer estimativas é dificil Durante o processo de elaboragio do projeto (abordado nos Capitulos 5 ¢ 6), parte do trabalho dos projetistas, programadores e testadores € desmembrar 0 projeto (design) em pedagos menores de trabalho que possam ser criados. Esses pedagos, geralmente chamados de itens de trabalho (work items) ou estrucura anali de projeto (WBS? — work breakdown structure), se tornam os itens de linha do cronograma mestre do. projeto. Os itens de trabalho sio (cruze os dedos) intcligentemente distribuidos® pela equipe de programasio, e por meio de cileulos, um cronograma é criado. Cada um desses itens de trabalho tem de ter uma quantidade de tempo atribuida a ele pelo programador e, baseada nessas cstimativas, 0 cronograma é criado. Simplificando a definigio, boas estimativas de trabalho tm uma alta probabilidade de serem exaas ¢ estimativas de trabalho ruins tém uma baixa probabilidade. Nao espero receber nenhuma recompensa por essas definigoes, mas pelo menos elas sugerem algo titil: é 0 julgamento dos lideres de equipes que define o ritmo de um determinado projeto. Isso requer um processo ativo de revisio de estimativas e de estimulo, lideranca e pressio sobre outras pessoas para que as estimativas atinjam o nivel necessério. Penso que seja inteligente envolver abertamente a equipe de testes/qualidade no processo de estimativa, deixando-a participar das discussdes de projeto e fazer perguntas ou oferecer comentirios, No minimo, isso-a ajudari com suas prépris estimativas para o trabalho de testes, que podem nao ser correlatas as estimativas de trabalho de programagio. Freqtientemente, © profissional de garantia de qualidade € mais perspicaz em relacio a omissoes de projeto © a casos de possiveis fracassos que outras pessoas irfo negligenciar. © mundo é baseado em estimativas Algo que dificulta 0 cronograma ¢ 0 fato de poucas pessoas gostarem de fazer estimativas de coisas complexas pelas quais elas sero responsiveis. Sempre & divertido vangloriar-se ¢ apostar em nossas habilidades (“Esse livro/filme/site no presta: eu poderia fazer um bem melhor”), mas quando somos pressionados a melhorar ¢ a realizar ~ assinando nossos nomes em um contrato que detalhe nossas responsabilidades — a coisa muda. Sabemos que € toralmence possivel que tudo 0 que nos comprometemos a fazer hoje pode ser impossivel ow indesejével fazer quando aquele momento chegar, Isso simplesmente pode vir a ser muito A VERDADE SOBRE OS CRONOGRAMAS 45 mais dificil do que pensivamos. Os programadores so exatamente iguais a qualquer outra pessoa ¢ tém boas raz6es para ficarem ansiosos ao fazer estimativas. Ao dizer que algo pode ser feito em um decerminado periodo de tempo, estario se arriscando a cometer um grande erro, Pela minha experigncia, mesmo os programadores que compreendem bem o processo de elaborasio de estimativase acredtam nele, nao gostam de fazé-o. Parte disso ¢ fruto do desacordo entre a imaginagao (Como isso funcionari, tendo em aN inforrnagBes tain imitacas Gut possiee”) ear preeio apna! (Die me exatamente quantas horas levard para fazer isso.”). Mas a afinidade aqui deve ser limitada: todos os que trabalham em engenharia e construgio tém o mesmo tipo de desafio, seja na construgio de um arranha-céu, na reforma de uma cozinha ou no kangamento de uma astronave para pousar em oucros planetas. A partir da leicura sobre como essas pessoas fazem estimativas, no parece que os seus desafios, ou técnicas sejam fundamentalmente diferentes dos que 0s desenvolvedores para a Web ¢ engenheiros de sofiware enfrentam. A principal diferenga est em quanto tempo eles dispdem para gerar estimativas ¢ na disciplina que tém na utilizagi esse tempo (0s Capitulos 5 ¢ 6 discutirio isso detalhadamente). Boas estimativas resultam de bons projetos (designs) Para crédito de programadores de todos os lugares, a coisa mais importante que aprendi sobre boas estimativas é que elas s6 provém de projetos e requi confidveis, Boas estimativas de engenharia s6 do possiveis se vocé reunir dois fatores: boas informagdes e bons engenheiros. Se as especificagdes sdo ruins e um programador precisa evocar um mimero baseado em um rabisco incompreenstvel tno quadro de comunicagoes, todos devem saber exatamente 0 que esperar: uma estimativa de baix{ssima qualidade. Isso significa que boas estimativas si0 tesponsabilidade de todos ¢ deve constituir o trabalho de toda a equipe — gerentes de projetos ¢ projetistas em particular — para fazer 0 que puderem para dar suporte aos engenhieiros na producao de estimativas conliaveis. Se fazer estimativas se parece com uma tarefa desagradvel e um projeto de contal ou se os lideres da equipe nao estio envolvidos no proceso, nao espere estimativas confitveis ou factiveis, Se 08 lidetes admitem estimativas inconsistentes no cronograma se sentem 4 vontade com um risco maior do mesmo, niio hi nada de errado com as estimativas frigeis. Em projeros menores, mais répidos, estimativas grossciras podem ser tudo que o projeto precisa. Os requisitos podem ser alterados com freqiiéncia e a natureza do negécio ou da organizacio pode exigit menos estrutura ¢ mais flexibilidade. Nao ha nada de errado com estimativas de baixa qualidade, contanto que ninguém as confunda com estimativas de alta qualidade Uma técnica pratica que descobri foi que sempre que um programador se recusou a dar uma estimativa, eu perguntava, “Quais perguntas eu posso responder para aumentar sua confianca em dar uma estimativa?” Conseguindo que ele fosse especifico, dava a ele a oportunidade para confroncar o medo ou frustragéo que cle pudesse sentir, o que me permitia ajudé+lo a resolver o problema. Claro que eu teria de ajudar a achar as respostas as suas perguntas e possivelmente debarer 05 problemas que cu considerava como sendo trabalho de investigacao dele, mas pelo menos estarfamos falando sobre como melhorar as estimativas. idade 46 A ARTE DO GERENCIAMENTO DE PROJETOS Aqui esto algumas maneiras adicionais de assegurar boas estimativast * Estabelecer intervalos de confianga na linha de base para as estimativas. Uma suposigio ~ 40% de confianga em precisio, Uma boa estimativa = 70%, Uma anilise completa e decalhada = 90%. Os lideres de equipe precisam concordat com o grau de preciso que desejam que as estimativas tenham, assim como com 0 tempo que os programadores tera para elabori-las © como os riscos de omiss6es nas estimativas serio gerenciados. Nao se fixe nos niimeros: apenas uuse-os para ajudar a coneretizar a qualidade das estimativas. Uma estimativa de 90% deve ‘acertar na mosca’ 9 vezes em cada 10. Se vocé decidir pedir & sua equipe que melhore a qualidade das estimativas, teri de associat este pedido a mais tempo para que eles fagam isso. * Os programadores que orientam o projeto tém de definir os limites para as estimativas de boa qualidade fazendo boas perguntas ¢ adotando abordagens inteligentes que a equipe possa imitar. Faga tudo o que for necessitio para neutralizar a motivagio para comentérios maliciosos ou de repiidio (por exemplo, “Nao me prenda a isso”, “E apenas uma suposigao” etc). Descubra as necessidades legitimas que eles tém de entregar boas estimativas e proporcione 0 tempo necessitio compativel com as metas de qualidade das estimativas. * Os programadores devem merecer confianga. Se o scu neurocirurgio Ihe dissesse que a cirurgia que precisa fazer leva cinco horas, vocé o pressionaria a fazé-la em trés? Duvido. As vezes, a pressio tem de ser aplicada para manter as pessoas conscientes do que tém de fazer mas somente como uma medida de equilibrio (a necessidade chissica para isso é um programador que faz estimativas altas pata 0 que ele nao gosta, baixas para 0 que gosta). Freqiientemente, obter varias estimativas (de dois desenvolvedores diferentes) pode ser uma maneira de fazer uma verificagio da capacidade de julgamento. * As estimativas dependem da compreensio pelo programador das metas do projeto. As estimativas sio baseadas na interpretagio de um programador nio somente das especificagdes do projeto (se existirem), mas também das metas objetivos do projeto. Em The Paychology of Computer Programming (Dorset House, 1971), Gerald Weinberg registra como a falta de clareza sobre objetivos de nivel mais alco tem uma influéncia direta nas suposigées de nivel mais baixo que 6s programadores fazem. Independentemente de quo conhecido poss ser 0 problema tecnolégico, a abordagem do programador para resolvé-lo pode mudar dependendo substancialmente das intengbes de alio nivel de todo o projero. © As estimativas devem ser baseadas em um desempenho anterior. E uma boa condura para os programadores realizar 0 monitoramento de suas estimativas nos projetos, Isso deveria fazer parte de suas discusses com os gerentes, que deveriam estar interessados em compreender em que tipo de estimativas as componentes de suas equipes se destacam. A Programagio Extrema usa o termo velocidade para se referir a0 desempenho provavel de um programador (ou de uma equipe), baseado em desempenho prévio.” * A qualidade da especificagéo ou do projeto deveria se situar no nivel compativel com a necessidade da engenharia para elaborar boas estimativas. Essa é uma negociacio entre © gerenciamento do projeto ¢ os programadores. Quanto mais alta a qualidade desejada das estimativas, mais alta deve ser a qualidade das especificagdes. Falaremos mais sobre boas especificagdes no Capitulo 7. A VERDADE SOBRE OS CRONOGRAMAS 47 + Hi técnicas conhecidas para fiver estimativas melhores. A técnica mais conhecida & © PERT, que tenta minimizar os riscos calculando a média de estimativas, otimistas, pessimistas e médias para o trabalho. Isso é bom por duas razdes. Primeito, forga todo mundo a pereeber que as estimativas sio previsdes ¢ que hd um incervalo de resultados possiveis. Segundo, proporciona aos gerentes de projeros uma chance de controlar o nivel de agressividade ou conservadorismo dos (pode ser daca mais énfase as estimativas otimistas ou pessimistas). cronogra Os descuidos mais comuns Embora as boas estimativas contribuam bastante para melhorar os cronogramas, muitos dos fatores que os afetam dependem de varios itens de linha individuais. A armadilha que isso crin se caracteriza pelo fio de, apesar de todas as estimativas de itens de trabalho serem perfcitas ¢ maravilhosas, 0s riscos reais do eronograma estio as coisis que nao sio eseritas. Embora seja verdade que a possibilidade de contrair a peste seja pequuena na maior parce do mundo, a probabilidade de um engenheiro importante contrair gripe ou sair de férias é bem alta. Hai um conjunto comum desses descuidos ou omissées relativos & elaboracio de um cronograma com a qual todos os gerentes de projetos precisam se familiarizar. © problema € que somente apés softer as consoqiiéncias de algo que foi omitido ¢ que voce se dispde a procuri-lo no futuro. Essa é a razao pela qual o gerenciamento do projeto, ¢ 0 gerenciamento do cronograma em particular, exige experiéncia para se rornar proficiente. Ha muitas maneiras diferentes de cometer falhas, ¢ nenhuma forma de praticar a sua identificagio, sem ser responsivel por suas conseqiiéncias. Fis aqui a minha lista preferida de perguntas que me ajudou a identificar antecipadamente possiveis problemas de cronograma, A maioria delas vem de perguntas feitas, apds a conclusio de um projeto, sobre 0 que saiu errado, ¢ da tentativa de encontrar uma pergunta que alguém poderia ter feito antes que teria evitado 0 problema. (O que falrou? O que nio foi levado em conta? O que teria feito diferenga ou permitido a adogao de uma acio corretiva?) + As licencas médicas e férias regulamentares de todos os colaboradores foram de alguma forma incluidas no cronograma? «As pessoas tiveram acesso ao cronograma e foram solicitadas a informar regularmente seus progressos (de uma forma amével)? * Alguém supervisionava o cronograma global diariamente ou semanalmente? Essa pessoa teve autoridade suficiente para fazer boas perguntas ¢ incluir os ajustes necessirios? * A cquipe se sentia responsivel ¢ comprometida com o cronograma? Caso conrritio, por qué? A equipe contribuiu para a definigao do cronograma e do trabalho a set feito ou isso The foi simplesmente comunicado? * Os lideres da equipe adicionaram mais solicitagées de recursos do que ajudaram a eliminar? Os lideres da equipe alguma ver disseram no a um novo trabalho e proporcionaram & equipe uma “filosofia’ razoavel sobre como responder a novas (€ tardias) solicitagoes? * As pessoas da equipe foram estimuladas ¢ receberam suporte para dizer nao a novas solicitagées de trabalho que no se encaixavam nas metas e na visio do projeto? 48_A ArrE DO GERENCIAMENTO DE PROJETOS * Quais foram as probabilidades usadas na elaboragio das estimativas? 90%? 70%? 50%? Isso foi expresso no cronograma mestre de alto nivel? O cliente/VP sabia disso? Houve discussio de outra proposta que levaria mais tempo mas contemplaria uma probabilidade mais alta? * Houve perfodos no cronograma em que puderam ocorrer ajustes € renegociagdes entre lideres ¢ a geréncia? * O cronograma considerou menos horas de trabalho durante 0 periodo de feriados? (Nos Estados Unidos, o periodo entre o dia de Agio de Gragas e 0 Natal € conhecidamente uma época de baixa produtividade,) Existem eventos climaticos importantes com seus impactos considerados no cronograma (por exemplo, temporais em Chicago, tornados no Kansas, sol em Seattle)? * As especificagées ou 0 projeto foram suficientemente bem planejados para 2 engenharia fazer boas estimativas de trabalho? * A engenharia foi treinada ou tinha experiéncia em fazer boas estimativas de trabalho? O efeito bola de neve O aspecto mais desanimador em relagdo & lista anterior & que mesmo que voce a siga A risca, devido 20 fato de cada contribuigao para um cronograma ser interdependente las outras, ainda € ficil os cronogramas sofierem atrasos. Cada decisio que a equipe toma, de escolhas de projero (design) as estimativas, ser{ a base para muitas das decis6es seguintes. Um descuido no inicio do processo, que seja descoberto mais tarde, ter{ um impacto ampliado no projeto. Esse efeito combinado nos cronogramas € ficil de ser subestimado porque a causa ¢ 0 efeito geralmente no so visiveis a0 mesmo tempo (vocé pode ver o efeito bem depois da ocorréncia da causa). Nos piores casos, quando varios descuidos importantes acontecem, a probabilidade de um ‘cronograma se manter incegro é quase nenhuma (consulte a Figura 2-4), Documenta de visso fraco ou inexistente Especiicardes malescritas ou inexistentes Estimativas de wabatto agressivas ou fracas x Inexisténcia de organvento para intearagio Inexisténeta de orgamento para iteragbes de UI Cronograma com pouca possibilidade de sucesso FIGURA 2-4. 0 efeito bola de neve E, € claro, isso se tora cada vez mais dificil. Pela forma como a probabilidade funciona, a chance de uma série de eventos independentes ocorrerem equivale & multiplicagdo das chances de ocorténcia de cada um dos eventos individuais (também A VERDADE SOBRE OS CRONOGRAMAS 49 conhecida como probabilidade composta). Portanto, se a probabilidade de voce terminar este capitulo é de 9 em 10 (9/10), ea probabilidade de terminar 0 préximo capitulo € 9/10, a probabilidade total de rerminar os dois capitulos no € 9/10: ¢ 81/ 100. Isso significa que se a sta equipe tem 90% de probabilidade de cumprir os prazos a cada semana, a0 longo do tempo as possibilidades de oconréncia de atrasos aumentam continuamente. A probabilidade é fiia e nfo tem coragio, e ela ajuda a lembrar que a entropia esti em todos os lugares ¢ niio ¢ amiga de projetos ou de scus gerentes, O que deve acontecer para que os cronogramas funcionem Agora que entendemos porque os cronogramas sio tio dificeis de manter, posso oferecer recomendagées sobre como minimizar os riscos ¢ maximizar os beneficios de qualquer cronograma de projeto. Essas abordagens ¢ comportamentos perpassam 05 papéis ou experiéncias tradicionais, o que, na minha opinio, reflere a verdadeira natureza da elaboracio de um cronograma. Como o cronograma representa a toxalidade do projero, a tinica maneira de usilos de forma efetiva é entender um pouco sobre nido o que deve acontecer para que o projeto seja bem-sucedido E uma tarefa interdisciplinar e nao apenas uma atividade de engenharia ou de geréacia. * A duragéo dos marcos (milestones) deve ser compativel com a volatilidade do projeto. Quanto mais alteragées sio esperadas, mais curtos os marcos devem ser. Pequenos marcos preparam a equipe para ajustes mais ficeis durante o projeto. Isso di a geréncia intervalos mais curtos entre as revises € reduz os riscos de fazer alterages. A equipe pode set preparada para esperar mudangas nas intersegdes entre marcos ¢, dessa forma, ela esperar alteragoes em ver de resistir a clas. * Seja otimista na visio e cético no cronograma. Um importante desafio psicolégico na elaboragao de cronogramas é utilizar o ceticismo apropriado, sem diminuir a paixio e a motivacio da equipe. Ao contririo da criaséo de um documento explicitando uma visto, onde o entusiasmo ¢ 0 otimismo devem reinar, um cronograma deve vir da perspectiva oposta. Os mimeros escritos para estimar quanto tempo as atividades devem consumir, requerem um respeito rigoroso e honesto 4 Lei de Murphy ("O que pode dar errado dari errado”). Os cronogramas nio deveriam refletir 0 que deveria acontecer ou poderia acontecer em condigées étimas. Em ver disso, um bom cronograma declara © que acontecers — a despeito do fato de que vitias coisas importantes podem nao acorter como esperado. E importante tet a equipe de teste/qualidade envolvida na elaboracio do cronograma porque seus componentes nacuralmente rerio um ponto de vista mais eético ¢ critico sobre o trabalho de engenharia. * Aposte no projeto (design). O processo do projeto constitui a melhor garantia contra a ignoriincia ¢ os desafios inesperados. Melhores priticas de projeto sio a tinica maneira de melhorar o trajeto da equipe acravés da implementagio e de outras fases. As habilidades para 0 projeto nao sao as mesmas requeridas para a implementacio, ¢ © programador mais competente, ou o mais rapido, nao seré necessariamente o melhor projetista ou o melhor solucionador de problemas. Bons processos para 0 projeto nao so ensinados em muitos cursos na drea de ciéncia da computagio, a despeito de quio essencial é “pensar” os projetos de 50_A ARTE Do GERENCIAMENTO DE PROJETOS engenharia ¢ definir abordagens adequadas para sua realizacio. Consulte os Capitulos 5 ¢ 6 para obter mais informagées sobre este t6pico. * Planeje os pontos de verificagio para as discusses sobre acréscimos ¢ cortes. Os cronogramas deveriam incluir perfodos curtos de revisio onde os lideres poderiam avaliar 0 progresso atual e considerar as novas informagées ou 0s comentitios dos clientes. Isso deve ser incorporado no cronograma mestre ¢ ser uma parte explicita de qualquer contrato do projeto. Nessas revises, irens de trabalho ¢ recursos existentes podem ser exchuidos, ou outros novos podem ser adicionados, de acordo com o resultado da anslise da lideranga sobre a sicuagio corrente. Pontos naturais para aes revisdes estio situados entre as fases ou, de forma limitada, no final de cada fase de projec (design) ou implementagio, mas clas podem ocorrer sempre que houver preocupagées sérias ou discrepincias Sbvias entre o plano e a realidade, As metas dessas discusses deveriam ser 0 retorno do projeto a0 bom senso, a revisio do cronograma, o estabelecimento de novas prioridades para os itens ¢ 0 inicio da parte seguinte do projeto com clareza ¢ convicgao sobre o que vird a seguir (consulre os Capftulos 14 ¢ 15). * Informe a equipe sobre a filosofia do planejamento. Independentemente da abordagem ou técnica adotada para a claboracio do cronograma, ela deverd ser do conhecimento da equipe. Se os programadores ¢ cestadores tiverem um entendimento basico sobre como os cronogramas funcionam e sobre a estratégia expecifica utilizada pela geréncia no projero atual, eles terao condigées de fazer perguntas pertinentes ¢ possibilidades de entender ¢ acreditar no que esté sendo planejado. * Ajuste a experiéncia da equipe ao espaco do problema. Uma das varidveis migicas em um cronograma é o nivel de experiéncia da equipe com o tipo de problemas que cla deve resolver. Se a equipe esté desenvolvendo tum site baseado em banco de dados, e cinco dos seis programadores jé realizaram esse tipo de trabalho varias vezes, é Ifcito assumir que eles serio melhores na definigio do projeto ¢ na estimativa do trabalho do que uma equipe que nunca fez esse tipo de trabalho antes. Isso teri forte influéncia sobre 0 cardter conservador ou agressivo do cronograma. * Mensure a confianca da equipe ¢ a experiéncia no trabalho conjunto. Muito embora as est ‘ivas sejam obtidas individualmence dos programadores, esses profissionais estao trabalhando juntos como uma unidade para desenvolver algo completo. Mesmo uma equipe de programadores veteranos “superestrelas” no ser4 tio eficiente quanto esperado se eles nao tiverem trabalhado juntos antes (ou enfrentado desafios importantes juntos). O fato de solicitar a uma equipe recém-formada que trabalhe em um projeto grande ¢ arriscado, ou se comprometa com um cronograma agressivo, deveria ser um sinal de alerta. * Assuma os riscos logo. Se vocé sabe que a Sally tem 0 componente mais complexo, lide com esses desafios no inicio do cronograma. Quanto maior 0 risco, mais tempo voc’ desejari ter para tratar dele. Se voc’ mio cuidar dos riscos até a fase mais adiantada do cronograma, teré menor niimero de graus de liberdade para responder a eles. © mesmo vale para riscos politicos, organizacionais e relacionados a recursos. Falaremos sobre 0 gerenciamento de itens de trabalho, no wpico sobre o pipeline da codificagao, no Capitulo 14. A VERDADE SOBRE OS CRONOGRAMAS 51 Resumo + Os cronogramas rém trés fungdes: permitir que os compromissos sejam assumidos, encorajar as pessoas a ver scus trabalhos como uma contribuigio para 0 todo e possibilitar 0 monicoramento do progresso. Mesmo quando os cronogramas atrasam, eles ainda tém valor. + Grandes cronogramas deveriam ser divididas em cronogramas menores para minimizar os riscos ¢ aumentar a freqiiéncia de ajustes. + Todas as estimativas 40 probabilidades. Como os cronogramas sio um conjunto de estimativas, eles também sio probabilidades. Isso trabalha contra a exatidio dos cronogramas porque as probabilidades se acumulam (80% x 80% 64%). * Quanto mais cedo as estimativas forem feitas, menos exatas elas serio, Entretanco, estimativas mais grosseiras sio a tinica maneira de fornecer um ponto de partida para outras estimativas melhores. + Os cronogramas devem ser desenvolvidos com ceticismo ¢ nio com otimismo. Invista na fase do projeto para ressaltar as premissas ¢ para gerar confianga. Capitulo 3 Como resolver 0 que fazer 54_A ARTE DO GERENCIAMENTO DE PROJETOS [Dez pera toncnrddin sie oom pliner ce pralcaor Meqhenrenseue) durante o planejamento, grande parte do tempo € utilizada para que as pessous concordem no modo como o planejamento deve ser feito, Eu acho que as pessoas ficam obcecadas pelo planejamento porque ele € 0 ponto de contaco para muicas fungées diferentes em qualquer empresa. Todos se sentem morivados a se envolver quando as decisbes importantes que estio em jogo iro afetar as pessoas durante meses ou anos, Hi estimulo e energia renovados, mas também o medo de que se a agio nio for tomada, as oportunidades serio perdidas. Essa combinacao torna tudo mais fécil para que as pessoas assumam que sua visio de mundo é a mais itil. Ou pion que ela € a tinica visio de mundo que vale a pena ser considerada ¢ uusada no processo de planejamento de projeto. “A parte mais dificil da construsio de um sistema de software & decidir 0 que constrain Nenbuma outra parte do trabalho conceitual tio dificil no extabelecimento de requisites éenicos detalhadas, incltindo as intrftces para wsudrios, para equipamentos e para outros sistemas de software, Nenhuma outra parte do trabalho prejudica tanto os resultados se cstiver errada. Nenhuma ousra parte & mais dificil de corrgir poseriormente, Portanto, a _fauncio mais importante que 0 desenvolvedor de software executa para o cliente é a exteagio ¢ refinamento iteratives dos requisitos do produto.” Fred Brooks Nio é surpresa, entio, que os livros relativos ao planejamento existentes no meu escritério estejam em grande desacordo entre si. Alguns enfocam a estratégia empresarial, outros os processos de engenharia e de elaboragio de cronogramas (0 foco tradicional do planejamento de projeto) e alguns enfocam como compreender e projetar (design) para clientes. Mas mais angustiante do que as divergéncias entre esses livros é o fao de que no reconhecem a existéncia de coutras abordagens. Isso é estranho porque nenhuma dessas perspectivas — ‘empresa, tecnologia, cliente — pode existir sem as outras. Além disso, eu estou convencido de que o sucesso no planejamento de projetos ocorre nas intersegoes desses diferentes pontos de vista. Qualquer gerente que possa ver essas intersegdes tem uma grande vantagem sobre aqueles que nao podem percebé-las. Portanto, este capitulo ¢ sobre como abordar o processo de planejamento ¢ obter uma visio de planejamento que tenha as maiores probabilidades de levar a0 sucesso. Em primeiro lugar, eu preciso esclarecer alguns termas ¢ canceitos usados por diferentes estratégias de planejamento (é um assunto dtido, mas precisaremos disso nos capitulos que se seguem). Quando tivermos ultrapassado esse assunto, definirei e integrarei essas trés diferentes visdes, explorarci as questées a que os bons processos de planejamento respondem e discutirei como abordar o trabalho didtio para que 0 planejamento acontega. Os capitulos a seguir detalharao resultados especificos, como documentos de visto (Capitulo 4) e especificagoes (Capitulo 7). O planejamento de software desmistificado Um pequeno projeto de uma pessoa para um sife interno nao requer o mesmo processo de planejamento de um projeto de US$ 10 milhées para um sistema Como Resoiver o Que Fazer 55 operacional com tolerincia a falhas envolvendo 300 pessoas. Em geral, quanto mais pessoas e maior a complexidade com que vocé lida, mais estrurura de planejamento precisa. Encretanto, mesmo um simples projeto, de uma s6 pessoa, é beneficiado pelo planejamento, Ele fornece uma oportunidade de rever decis6es, expor assuntos ¢ esclarecer acordos entre pessoas ¢ organizagoes. Os planos atuam como uma funcio compelidora contra todos os tipos de estupidez porque demandam que problemas importantes sejam resolvidos enquanto ha tempo para considerar ourras opgées. Como ditia Abraham Lincoln, ‘Se eu tivesse seis horas para cortar uma drvore, gastaria quatro horas aflando © machado”, © que significa que uma preparagio inteligente minimiza o trabalho. planejamento de projetos envolve responder a duas questoes. A resposta da primeira questio, “O que precisamos fazer?” é geralmente denominada coleta de requisitos. A resposta & segunda questio, “Como faremos isso?” ¢ denominada projero (design) ou especificagio (veja a Figura 3-1). Um requisito € uma descrigéo cuidadosamente escrita de um critério que se espera que 0 trabalho satisfaga. (Por exemplo, um requisite para preparar uma refeigio poderia ser fazer uma comida barata que seja gostosa ¢ nutritiva.) Bons requisitos sio ficeis de entender e dificeis de ser mal-interpretados. Pode haver diferentes maneiras de projetar algo para atender a um requisico, mas deve ser facil reconhecer se 0 requisito foi atendido quando examinamos uma parte coneluida do trabalho. Uma especificacio é simplesmente um plano para criar algo que cumpriré os requisitos. Requistio ProjetorEspscificagso ——_‘mplementapao Oswanctonsten?_| Como « faremos? | [=| FIGURA 3-1. Uma visdo extremamente simples, mas util de planejamento. Se vocé nado sabe 0 que precisa fazer, 6 muito cedo para resolver como fazé-lo. Essas trés atividades ~ coleta de requisitos, projeto/especificagio ¢ implementagio = so assuntos importantes € merecem cer seus préprios livros (consulte a Bibliografia comentada). Eu abordarei os dois primeiros assuntos a partir da perspectiva do nivel de projeto nos dois capitulos seguintes, ¢ a implementagao serd enfocada mais adiante neste livro (Capitulos 14 ¢ 15) Diferentes tipos de projetos Virios critérios alteram a natureza de como os requisitos ¢ trabalho de projeto (design) sio realizados. Eu usarei rés exemplos de projetos simples e diversos para ilustrar esses critérios:! Super-homem solitério. No projeto mais simples, apenas uma pessoa esté envolvida. De escrever 0 cddigo, fazer o plangjamento comercial, a preparar seu proprio almoso, ela faz tudo sozinha e é sua prépria fonre de recursos. + Equipe pequena contratada, Uma firma com 5 ou 10 programadores e um getente € contratada por um cliente pata construir um site ou um aplicativo de software. Eles esbocam um contraco que define os compromissos firmados. 56_A ARTE Do GERENCIAMENTO DE PROJETOS Quando o contrato termina, o relacionamento também termina, a menos que uum novo contrato/projeto seja iniciado. + Equipe grande. Uma equipe de cem pessoas contratadas por uma corporacio comega a trabalhar em uma nova versio de algo. Pode set um produto vendido a0 ptiblico (também conhecido como pacore ou shrink-wrap) ou algo usado internamente (interndlware). Esscs trés tipos de projetos diferem em tamanho de equipe, estrutura organizacional e relacionamentos de autoridade, ¢ as difetengas encre eles estabelecem distingses importantes sobre como devem ser gerenciados. Portanto, embora seu projeto possa no corresponder exatamente a esses exemplos, eles serio pontos de referencia titeis nas segdes a seguir. Como as organizag6es impactam o planejamento Com os trés tipos de projetos em mente, podemos examinar os critérios bisicos, para o planejamento de projeto. Em um projeto, a qualquer momento existem questdes bisicas para as quais todos devemos conhecer as respostas. As respostas talvez.nem sempre sejam agradaveis, mas voce e sua equipe deveriam saber quais sio. Grande parte da frustragio do planejamento ocore quando hé divergéncia ‘ou ignorincia sobre essas questées. © Quem tem autoridade para definir os requisitos? Alguém tem de definir os requisitos ¢ fazer com que sejam aprovados pelas partes interessadas (cliente ou VP). No caso do super-homem solitirio, ¢ facil: o super-homem terd toda a autaridade desejada. Em uma equipe sob contraro, ser o cliente que desejard um controle rigido sobre os requisitos ¢ possivelmente sobre o projeto. Por tiltimo, uma grande equipe pode ter comiss6es on outras divisdes na corporagio que precisarao ser atendidas pelo trabalho (e aqueles cuja aprovagio de alguma maneira € necesséria). Pode haver pessoas diferentes com autoridade para requisitos de alto nivel (°O produto seri um veiculo utilitério esportivo”) ¢ autoridade para requisitos de baixo nivel (“Percorreré 20 milhas por galao de combustivel e teré tragio nas quatro rodas’). + Quem tem autoridade para 0 projeto (design)? Como nos requisitos, alguém tem de definir 0 projeto (design) do trabalho. O projeto ¢ diferente dos requisitos porque existem sempre muitos projetos diferentes possiveis para atender 2 um conjunto de requisitos. Os projetos, assim como os requisitos, sio freqiientemente negociados entre duas ou mais partes. Uma pessoa ou equipe pode ser responsdvel por conduzir 0 processo de projero ¢ desenvolver a idéia (designer), ¢ outra equipe fornece a otientagio e comentitios sobre 0 trabalho do primeiro grupo (VP). Observe que como a habilidade de projeto (design skill) esta disttibuida no universo ¢ independe do poder politico, as pessoas que recebem a autoridade sobre o projeto (design) nao devem ser pessoas que tenham muito talento pata projeto (design). * Quem tem autoridade técnica? A autoridade técnica ¢ definida por quem escolhe as abordagens de engenharia que serio usadas, incluindo as linguagens de progtamagio, as ferramentas de desenvolvimento ¢ a arquitetura técnica. Como REsotver 0 Que Fazer 57 Muitas dessas decisées podem impactar os requisitos, 0 projeto (design) e 0 orcamento. A diferenca entre as decisdes técnicas ¢ as decisses de projeto é sutil: © modo como algo se comporta e sua aparéncia freqiientemente tém muito a ver com a mancira como ele foi construido. Em algumas organizagées, a autoridade técnica suplanta a autoridade para requisites e projeto. Em outrasy € subordinada a elas. Nas melhores organizagées, ha uma relacio de colaboragio entre todos os tipos de autoridade. * Quem tem autoridade para orcamento? A capacidade de adicionar ou remover recursos de um projeto pode ser independente de outros tipos de autoridade. Por exemplo, na situagio da equipe sob contrato, a equipe deve ter o poder de definir os requisitos e projeco, mas precisa retornar ao cliente cada ver que quiser mais dinheiro ou tempo. Com que freqiiéncia os requisitos ¢ projetos (design) serio revistos e como os ajustes serio decididos? A resposta depende muito das questoes anteriores. Quanto mais pessoas envolvidas nos requisites, projeto (design) ¢ orcamentos, ima esforgos precisario ser gastos pata manté-los em sincronia durante o projeco. Como regra geral: quanto menos autoridade vocé tem, mais diligente precisa ser sobre as decisdes de revisio ¢ aprovagio, assim como na definigio dos ajustes. Embora cu cenha identificado diferentes tipos de autoridade, é possivel que uma Ainiea pessoa possua varias delas ou todas. Entretanto, na maioria das vezes, a auroridade ¢ distribuida entre os lideres da equipe. Quanro mais complexa for a distcibuigao da autoridade, mais esforso de planejamento voce precisard para set efetivo. No Capftulo 16, abordarei como lidar com situagées onde voc’ precisa de mais autoridade do que a que tem. Por enquanto, basta reconhecer que 0 planejamento envolve esses diferentes tipos de poder. Resultados comuns do planejamento Para comunicar 0s tequisitos, alguém tem de escrevé-los. Existem muitas manciras de fazer isso € eu nio estou advogando nenhum metodo especifico. O que importa é que as informag6es corretas sejam obtidas, as pessoas certas possam discuti-las facilmente e bons acordos sejam feitos para que 0 trabalho possa ser cexecutado. Se a maneira como voc’ documenta 05 requisitas fiz tudo isso, excelente. Se nao faz, entao procure um novo método com esses critérios em mente. Como referéncia, mencionarei alguns dos modos mais comuns de documentar requisitos ¢ informagées de planejamento. No minimo, 0 conhecimento do jargio comum ajuda a compreensio dos virios métodos usados por diferentes organizacdes. Vocé achari. que algumas equipes documentam os tequisitos de maneira informal: “Oh, requisitos — vé falar com Fred”. Outros tém modelos claborados ¢ procedimentos de revisio que dividem esses documentos fem partes muito pequenas (e possivelmente sobrepostas) pertencentes a pessoas diferentes. * Documento de requisitos de marketing (marketing requirements document, MRD). Essa ¢ a anilise global preparada pela equipe comercial ou de markering. O objetivo é explicar quais oportunidades comerciais existem ¢ 58_A ARTE Do GERENCIAMENTO DE PROJETOS como um projeco pode explorar essas oportunidades. Em algumas organizagées, esse é um documento de referéncia para ajudar aos tomadores de decisio em suas opinides, Em outras organizagées, cle € o miicleo da definigio do projeto ¢ tudo o que se segue deriva fortemente dele. Os MRDs ajudam a definir 0 “o qué” de um projeto. * Documento de visio/escopo. Um documento de visio encapsuli em uma tinica composigo todas as opini6es disponiveis sobre 0 que um projeto pode ser. Se houver um MRD, um documento de visio deve ser derivado dele ¢ se referenciar a ele, Um documento de visio define as metas de um projeto, por que elas fazem sentido e quais serio os recursos de alto nivel, requisitos ou datas para um projeto (consulte o Capitulo 4). Os documentos de visio definem diretamente 0 “o qué” de um projeto. * Especificagées. Abordam qual deve ser o resultado final do trabalho para uma parte do projeto. Boas especificagoes tém origem em um conjunto de requisitos. Elas so ento desenvolvidas através de um trabalho de projeto iterativo (consulte os Capitulos 5 ¢ 6), 0 que pode envolver a modificagio/melhoria dos requisitos. As especificagées esto completas quando fornecem um plano executdvel que a engenharia pode usar para preencher os requisitos (a quantidade de detalhes que elas precisam ter € coralmente negocidvel com a engenharia). As especificagdes devem derivar dos documentos de visio. As expecificagoes definem 0 “como” de um projero a partir de uma perspectiva de engenharia ¢ projeto. + WBS, estrutura analitica de projero (Work breakdown structure). Embora uma especificagio deralhe o trabalho a ser feito, uma WBS define como uma equipe de engenheiros proceder 20 executé-lo. Que trabalho seri executado em primeiro lugar? Quem o executaré? Quais so todas as partes individuais do trabalho e como podemos controlé-las? Uma WBS pode ser muito simples (uma planilha) ou muito complexa (gréficos e ferramentas), dependendo das necessidades do projeto. Os Capitulos 7 © 13 tratario das atividades do tipo WBS. A WBS define 0 “como” de um projeto a partir da perspectiva de uma equipe. Abordando os planos: as trés perspectivas Vocé pode rer abservado como cada tum dos resultados mencionados anteriormente representa uma das duas perspectivas a respeito do. projeto: empresarial ou de engenharia de software. Em muitos projetos, essis duas visbes competem entre si. Esse é um erro de planejamento fundamental. O planejamento raramente deve ser uma experiéncia do tipo binéria, ou sim ou nao. Em vez disso, ele deve ser uma integragio ¢ sintese em que todos podem contribuir, Para fazer isso acontecer, um gerente de projeto deve reconhecer que cada perspectiva contribui com algo tinico que nao pode ser substituide por algo mais {isco nenhuma concribuigio maior da estratégia de marketing melhorari a competéncia da engenharia ¢ vice-versa). Para bons resultados, todos os envolvidos em planejamento de projeto devem ter uma compreensio bisica de cada perspectiva

Você também pode gostar