UMA BREVE HISTRIA DO GERENCIAMENTO DE PROJETOS (A Arte do Gerenciamento de Projetos - Scott Berkun) Em muitas organizaes, o lder de um projeto no tem

o cargo de gerente de projeto. Tudo bem. Todos os programadores, gerentes, lderes de equipe, analistas e designers gerenciam projetos no seu trabalho dirio, estejam eles trabalhando sozinhos ou em equipe. Por enquanto, essas distines no so importantes. Minha inteno entender o que torna um projeto bem-sucedido e como as pessoas que lideram projetos bem-sucedidos o fazem. Essas idias e estratgias principais no requerem hierarquias, cargos ou mtodos especficos. Portanto, se voc trabalha em um projeto e tem alguma responsabilidade sobre seus resultados, esta obra se aplicar a voc. E caso seu carto de visitas o apresente como um gerente de projetos, melhor ainda. Usando a histria O gerenciamento de projetos, como uma idia, data de muito tempo. Se voc pensar em tudo o que foi criado na histria da civilizao, teremos milhares de anos de experincia com os quais aprender. Uma linha pontilhada pode ser desenhada desde os desenvolvedores de software de hoje retrocedendo no tempo at os construtores das pirmides do Egito ou os arquitetos dos aquedutos romanos. Em suas respectivas pocas, os gerentes de projeto desempenhavam papis similares, aplicando tecnologia aos problemas relevantes dos tempos. Ainda hoje, quando a maioria das pessoas tenta melhorar o modo como seus projetos de desenvolvimento de software e Web so gerenciados, raro prestar ateno s lies aprendidas no passado. A linha do tempo que usamos como escopo para o conhecimento til est muito mais prxima do dia de hoje do que deveria estar. A histria dos projetos de engenharia revela que a maioria dos projetos tem fortes semelhanas. Eles tm requisitos, projetos (designs) e restries. Eles dependem da comunicao, da tomada de deciso e de combinaes de pensamento lgico e criativo. Os projetos normalmente envolvem um cronograma (schedule), um oramento e um cliente. O mais importante, a tarefa central dos projetos combinar os trabalhos de diferentes pessoas em um todo singular e coerente que ser til para as pessoas ou clientes. Seja um projeto desenvolvido a partir do HTML, do C++ ou de cimento e ao, h sempre um conjunto principal de conceitos irrefutveis que a maioria dos projetos deve compartilhar. Minha curiosidade sobre as formas de liderar os esforos de desenvolvimento de software e Web me levou a um srio 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 solues comparveis em meu prprio trabalho. Imaginei como projetos como o Telescpio Espacial Hubble e o Boeing 777 foram desenvolvidos e construdos. Poderia eu reutilizar algo de suas complexas especificaes e processos de planejamento? Ou quando o prdio da Chrysler foi construdo na cidade de Nova York e o Parthenon em Atenas, os lderes de projeto planejaram e estimaram suas construes da mesma forma que os meus programadores o fazem? Quais foram as diferenas interessantes e o que pode ser aprendido examinando essas diferenas? O que dizer dos editores de jornais, que organizam e planejam a produo diria das informaes? Eles estavam fazendo multimdia (imagens e texto) muito antes dos primeiros sonhos de publicao na Web. E sobre a produo de filmes de longa-metragem? O lanamento da Apollo 13? Examinando essas questes, fui capaz de perceber como liderar equipes de projeto de uma nova maneira. Entretanto, essas perguntas nem sempre tinham respostas bvias. Eu no posso prometer que voc entregar o resultado mais cedo ou planejar melhor porque as informaes

deste texto foram influenciadas por essas fontes. Mas eu sei que quando retornei ao mundo do software aps pesquisar em vrios lugares, meus processos e ferramentas me pareceram diferentes. Encontrei maneiras de modific-los que antes no tinha considerado. No todo, percebi que muitas abordagens e comparaes teis que encontrei nunca tinham sido mencionadas durante meus estudos de cincia da computao na universidade. Elas nunca foram discutidas em conferncias do setor tecnolgico ou escritas em revistas do ramo. As principais lies aprendidas nas minhas investigaes sobre o passado so descritas nos trs pontos a seguir: 1. O gerenciamento de projeto e o desenvolvimento de software no so artes sagradas. Qualquer trabalho da moderna engenharia uma nova entrada no longo histrico da criao. As tecnologias e habilidades podem mudar, mas grande parte dos principais desafios que dificultam a engenharia permanece. Todas as coisas, quer linguagens de programao ou metodologias de desenvolvimento, so nicas de alguma maneira, mas derivadas de outras. Mas se quisermos reutilizar o mximo possvel de conhecimento do passado, precisamos ter certeza de que estamos abertos para examinar ambos os aspectos o nico e o derivado em comparao com o que veio antes. 2. Quanto mais simples a viso do que voc faz, mais poder e foco ter ao execut-la. Se pudermos manter periodicamente uma viso simples do nosso trabalho, poderemos encontrar comparaes teis com outras maneiras de realizar as coisas que existem em nosso redor. Existiro mais exemplos e lies da histria e das indstrias modernas que podem ser usados, comparados e contrastados. Isso similar ao conceito definido pela palavra japonesa shoshin, que significa mente do iniciante ou mente aberta, uma parte essencial de muitas disciplinas de artes marciais. Permanecer curioso e aberto o que torna o crescimento possvel e necessrio praticar para manter essa atitude. Para continuarmos a aprender, temos de evitar a tentao de aceitarmos vises estreitas e seguras sobre o que fazemos. 3. Simples no quer dizer fcil. Os melhores atletas, escritores, programadores e gerentes tendem a ser aqueles que sempre vem o que fazem como simples em sua essncia, mas, simultaneamente, difcil. Lembre-se de que simples no o mesmo que fcil. Por exemplo, correr uma maratona uma coisa simples. Voc comea a correr e no pra at completar 42 km. O que poderia ser mais simples? O fato de ser difcil no nega sua simplicidade. Liderana e gerenciamento tambm so difceis, mas sua natureza executar tarefas de uma maneira especfica para atingir uma meta especfica simples. Aprendendo com os erros Os seres humanos, que so praticamente os nicos (entre os animais) que tm a habilidade de aprender com a experincia alheia, so tambm notveis em sua aparente m vontade para fazer isso. (Douglas Adams) Uma questo simples que surge no estudo da histria dos projetos esta: por que algum concorda em sofrer com os erros e desapontamentos se eles podem ser evitados? Se a histria das engenharias antiga e moderna est (amplamente) no domnio pblico e somos pagos para fazer coisas inteligentes independentemente da fonte de inspirao, por que to poucas organizaes recompensam as pessoas por buscar lies no passado? Enquanto projetos so concludos ou cancelados (e muitos projetos de desenvolvimento terminam dessa maneira) todos os dias, pouco feito para aprendermos com o que aconteceu. Parece que os gerentes da maioria das organizaes raramente recompensam as pessoas por buscar esse tipo de conhecimento. Talvez seja por medo do que encontraro (e o medo de serem considerados responsveis por isso). Ou talvez seja apenas falta de interesse da parte de algum em rever as experincias dolorosas e frustrantes quando o tempo poderia ser gasto na prxima mudana para algo novo.

Em seu livro, To Engineer Is Human: The Role of Failure in Successful Design (Vintage Books, 1992), Henry Petroski explica como ocorreram descobertas na engenharia como resultado de falhas. Em parte, isso acontece porque as falhas nos foram a prestar ateno. Elas nos obrigam a reexaminar as premissas que havamos esquecido que existiam ( difcil fingir que tudo est bem quando o prottipo pegou fogo). Como Karl Popper sugeriu, h apenas dois tipos de teorias: as que esto erradas e as que esto incompletas. Sem os fracassos, ns esquecemos arrogantemente que nossa compreenso das coisas nunca to completa quanto pensamos ser. O artifcio, ento, aprender o mximo possvel com as falhas de outras pessoas. Devemos usar suas experincias para influenciar o futuro. Embora os detalhes superficiais da falha possam ser totalmente diferentes de projeto para projeto, as causas bsicas ou as aes da equipe que levaram a elas podero ser plenamente transferveis (e evitveis). Mesmo em nossos prprios projetos, precisamos evitar o hbito de fugirmos e nos escondermos de nossas falhas. Em vez disso, devemos v-las como oportunidades para aprender algo. Que fatores contriburam para que isso acontecesse? Quais deles seriam mais fceis de minimizar ou eliminar? De acordo com Petroski, o conhecimento real obtido a partir da falha real a mais poderosa fonte de progresso que temos, desde que tenhamos a coragem de examinar cuidadosamente o que aconteceu. Talvez seja por isso que a Boeing, uma das maiores empresas de projeto e engenharia de aeronaves do mundo, mantenha um livro negro de lies aprendidas a partir de falhas de projeto e engenharia. A Boeing mantm esse documento desde que a empresa foi criada e o utiliza para ajudar os novos projetistas a aprenderem com as tentativas do passado. Qualquer organizao com esse tipo de orientao no apenas aumenta suas chances de projetos bem-sucedidos, como tambm ajuda a criar um ambiente onde se pode discutir e confrontar as falhas abertamente, em vez de neg-las e escond-las. Parece que os desenvolvedores de software precisam manter seus prprios livros negros. Desenvolvimento para a Web, cozinhas e salas de emergncia Um problema com a histria que ela nem sempre referencivel. Pode ser difcil aplicar lies ao longo de dcadas e manter a empatia por coisas que parecem to diferentes do modo como o trabalho realizado nos dias de hoje. Uma alternativa fazer comparaes com tipos diferentes de projetos modernos. Embora no tenha o mesmo impacto da histria da engenharia, isso permite observaes e experincias pessoais. Com freqncia, ver as coisas na fonte a nica maneira de fornecer informaes suficientes para fazer conexes entre idias diferentes. Como exemplo, eu conheo um desenvolvedor para a Web que acredita que seu trabalho diferente de tudo o que existe na histria do universo. Ele sente que como o desenvolvimento para a Web exige que ele tome decises de engenharia complexas projetando e coordenando medida que avana, verificando alteraes em questo de horas ou mesmo minutos e, em seguida, publicando para todo o mundo seu projeto e gerenciamento de tarefas so diferentes de tudo que j foi visto antes. Ele se orgulha em listar CSS, XHTML, Flash, Java e outras tecnologias que domina, afirmando que elas teriam confundido as maiores mentes de 50 anos atrs. Eu tenho certeza de que na sua experincia voc j encontrou pessoas como ele. Ou talvez tenha trabalhado em situaes onde parecia improvvel que algum mais no universo pudesse ter gerenciado algo to complexo como o que voc estava fazendo. 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 razes, interessante caminhar pelas cozinhas (consulte o excelente livro de Anthony Bourdain, Kitchen Confidential, Ecco, 2001), mas meu ponto especfico era sobre produtividade. A primeira vez que algum v o gerenciamento e a coordenao de tarefas rpidas que ocorrem em uma cozinha profissional atarefada, provavelmente reconsiderar a dificuldade de seu prprio trabalho. Os cozinheiros esto freqentemente distribuindo frigideiras com diferentes pedidos em diferentes estados de concluso

e correndo entre vrios conjuntos de queimadores em cantos opostos da cozinha, enquanto os garons correm para l e para c, entregando notcias de ajustes e problemas com os clientes. Tudo isso acontece em espaos pequenos e apertados, bem acima de 30 C, com luminosas luzes fluorescentes brilhando acima. E apesar do nmero de pedidos que saem a cada segundo, novos pedidos entram com a mesma velocidade. Alguns pedidos so enviados de volta ou, como em muitos projetos de software, exigem modificaes personalizadas e de ltima hora (a mesa 1 tem intolerncia a lactose; a mesa 2 precisa de molho separado etc.). maravilhoso observar cozinhas grandes e atarefadas. Apesar de parecerem caticas primeira vista, as cozinhas grandes funcionam com um nvel de intensidade e preciso que deixam a maioria das equipes de desenvolvimento no chinelo. Os chefes de cozinha e os cozinheiros regulares so gerentes de projetos culinrios, ou como Bourdain se refere a eles, controladores de trfego areo (outra profisso para o introspectivo considerar). Embora a equipe de cozinha trabalhe em uma escala menor e menos celebrada do que um gerente de equipe de desenvolvimento de software, sua intensidade diria incomparvel. Se voc duvida de mim, na prxima vez em que estiver em um restaurante cheio, pergunte ao garom se possvel dar uma espiada na cozinha. Talvez ele no permita, mas se permitir, voc no ficar desapontado. (Alguns restaurantes e bares mais modernos tm cozinhas abertas. Se encontrar um, sente-se o mais prximo possvel dela. Depois, acompanhe uma pessoa por alguns minutos. Observe como os pedidos so colocados, controlados, construdos e entregues. Se voc for num dia em que ele estiver cheio, pensar de maneira diferente sobre como os erros de software so registrados, rastreados e corrigidos.) Outra lio de campo interessante no gerenciamento de projetos vem das salas de emergncia dos hospitais. Eu assisti no Discovery Channel e no PBS como pequenas equipes de mdicos, enfermeiras e especialistas experientes trabalham juntos como uma equipe de projeto para tratar de situaes mdicas diversas e algumas vezes bizarras que surgem nas portas dos hospitais. No surpreende que tenha sido a profisso que inventou o processo de triagem, um termo comumente usado em projetos de software para priorizar problemas e defeitos. O ambiente mdico, especialmente em situaes de trauma, oferece uma comparao fascinante para trabalho baseado em equipe, tomadas de deciso sob alto estresse e resultados de projetos que afetam muitas pessoas todos os dias (consulte a Figura 1.1 para obter uma comparao grosseira desse e outros ambientes de trabalho). Como Atul Gawande escreveu em seu excelente livro, Complications: A Surgeons Notes on an Imperfect Science (Picador USA, 2003): Ns esperamos que a medicina seja um campo regular de conhecimento e procedimento. Mas no . Ela uma cincia imperfeita, um empreendimento de conhecimento em constante mudana, informaes incertas, indivduos passveis de falhas e ao mesmo tempo prontos para o combate. H cincia no que fazemos, mas tambm hbito, intuio e s vezes simples suposies. O vcuo entre o que sabemos e o que almejamos persiste. E esse vcuo complica tudo o que fazemos.

Esse ponto, e muitos outros do livro esclarecedor de Gawande, permanecem verdadeiros para o desenvolvimento de software. Fred Brooks, no livro clssico sobre engenharia de software, The Mythical Man-Month, faz comparaes similares entre equipes de cirurgies e equipes de programadores. Embora vidas raramente estejam em risco quando trabalhamos em sites ou bancos de dados da Web, existem muitas semelhanas vlidas nos desafios que essas diferentes equipes de pessoas precisam enfrentar. A funo principal do gerenciamento de projetos O gerenciamento de projetos pode ser uma profisso, uma tarefa, uma funo ou uma atividade. Algumas empresas tm gerentes de projeto cuja tarefa supervisionar projetos de 200 pessoas. Outras usam o ttulo para gerentes juniores, cada um deles responsvel por uma pequena rea de um grande projeto. Dependendo de como uma organizao est estruturada, da sua cultura e das metas do projeto, o gerenciamento de projetos pode ser uma funo informal (ela realizada por qualquer pessoa, sempre que necessrio) ou altamente definida (Vincent, Claude e Raphael so gerentes de projeto em tempo integral). Usarei principalmente o termo gerente de projeto, ou GP, para fazer referncia a quem est envolvido na atividade de liderana e gerenciamento de projetos. Por atividade de gerenciamento de projeto quero dizer liderar a equipe na soluo do projeto (planejamento, programao e reunio de requisitos), orientar o projeto no trabalho de design e desenvolvimento (comunicao, tomada de deciso e estratgia de meio de jogo) e executar o projeto at a concluso (liderana, gerenciamento das crises e estratgia de final de jogo). Se esse tipo de trabalho menos estruturado no seu mundo, basta traduzir gerente de projeto ou GP para significar pessoa que executa as tarefas de gerenciamento do projeto, embora esse no seja seu trabalho principal ou pessoa que pensa no projeto na ntegra. Encontrei muitas maneiras diferentes para essas atividades serem distribudas pelas equipes e a recomendao deste texto totalmente indiferente para elas. O contedo deste texto menos sobre os ttulos e formalizaes de cargos e mais sobre executar tarefas e faz-las acontecer. Mas, para manter meu texto o mais simples possvel, usarei o termo gerente de projeto ou GP. s vezes, a ausncia de um gerente de projeto exclusivo funciona bem. Os programadores e seus chefes mantm seus cronogramas e planos de engenharia (se houver) e um analista de negcios ou pessoa de marketing faz o planejamento ou gerenciamento de requisitos. Tudo o mais que

poderia ser qualificado como um gerenciamento de projeto simplesmente distribudo pela equipe. Talvez as pessoas da equipe tenham sido contratadas por seus interesses que vo alm de escrever um cdigo. Elas poderiam no se dedicar ao planejamento inicial, design de interface de usurio ou estratgia de negcios. Trabalhar dessa maneira pode acarretar otimizaes significativas. Desde que todos queiram pagar o preo da responsabilidade por manter essas coisas juntas e distribuir por toda a equipe o nus que um gerente de projeto exclusivo pode suportar, a equipe precisar de menos um funcionrio. Eficincia e simplicidade so coisas boas. Mas outras vezes, a ausncia de um gerente de projeto cria disfuno. Sem uma pessoa cuja funo principal seja reunir o esforo geral, as tendncias e interesses individuais podem desviar as direes da equipe. Fortes faces adversrias podem ser desenvolvidas em torno das funes de engenharia e negcios, retardando o progresso e frustrando todas as pessoas envolvidas. Considere que nas salas de emergncia de um hospital, um mdico tome a liderana na deciso do curso de ao para um paciente. Isso apressa muitas decises e d clareza s funes 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 no houver uma pessoa com uma funo clara para liderar a triagem de erros ou algum dedicado a rastrear os problemas de cronograma e sinalizao, essas tarefas podero ficar perigosamente para trs das atividades de programao individuais. Embora eu ache que muitos dos melhores programadores entendem o suficiente de gerenciamento de projetos para gerenci-los sozinhos, eles tambm reconhecem o valor nico de uma pessoa boa e dedicada desempenhando o papel de gerente. Gerenciamento de projetos e programas na Microsoft A Microsoft enfrentou dificuldades no final dos anos 80 na coordenao dos esforos de engenharia com a rea de marketing e negcios de cada diviso (alguns podero dizer que isso ainda um problema para a Microsoft e muitas outras empresas). Um homem sbio chamado Jabe Blumenthal percebeu que poderia existir uma tarefa especial onde um indivduo estivesse envolvido com essas duas funes, desempenhando um papel de liderana e coordenao. Essa pessoa estaria envolvida no projeto desde o primeiro dia do planejamento at o ltimo dia de teste. Tinha que ser algum que tivesse conhecimento tcnico suficiente para trabalhar com os programadores e ser respeitado por eles, mas tambm algum que tivesse talento e interesse para uma participao mais abrangente no modo como os produtos fossem feitos. Para desempenhar bem esse papel, ele teria de gostar de passar seus dias executando tarefas to variadas quanto escrever especificaes, rever planos de marketing, gerar cronogramas de projeto, liderar equipes, fazer planejamento estratgico, executar triagem de erros/falhas, cultivar a moral da equipe e fazer tudo o que precisa ser feito e que ningum est fazendo (bem). Esse novo papel na Microsoft foi chamado de gerente de programa. Nem todos na equipe se reportariam diretamente a ele, mas o gerente de programa teria autoridade para liderar e orientar um projeto. (Na teoria de gerenciamento, essa , grosso modo, a idia de uma organizao matricial, onde existem duas linhas de estrutura hierrquica para os indivduos: uma baseada na funo e a outra baseada no projeto. Portanto, um programador ou testador individual poderia ter dois relacionamentos hierrquicos um principal para seu papel funcional e um secundrio, mas forte, para o projeto no qual trabalha.) Jabe desempenhou esse papel em um produto denominado Multiplan (mais tarde tornou-se o Microsoft Excel) e funcionou. Os processos de engenharia e desenvolvimento melhoraram juntos com a qualidade da coordenao com a equipe de negcios e em todos os corredores da Microsoft havia muita alegria. Aps muitos memorandos e reunies, a maioria das equipes na empresa adotou lentamente a funo. No importam os produtos resultantes, bons ou ruins, a idia faz sentido. Ao definir um papel para um generalista no nvel de linha, que no tenha sido um auxiliar de baixa qualificao,

mas um lder ou um orientador, a dinmica 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 e trabalhei em equipes de produto que incluram o Internet Explorer, MSN e Windows. Gerenciei tambm equipes de pessoas que desempenhavam esse papel. At hoje, no sei de muitas empresas que tenham ido to longe na redefinio e formalizao de gerenciamento de projeto. Era raro, em minhas interaes com outras firmas de desenvolvimento de software e Web, encontrar algum que desempenhasse um tipo de funo similar (eles eram engenheiros ou administradores, ou em raras ocasies, designers). Muitas companhias usam estruturas de time para organizar o trabalho, mas poucas definem os papis que atravessam deliberadamente as hierarquias de engenharia e negcios. Hoje existem mais de 5.000 gerentes de programa na Microsoft (em mais de 50.000 funcionrios no total) e embora a fora da idia tenha sido diluda (e em muitos casos mal utilizada), o esprito principal dela ainda pode ser encontrado em muitas equipes e grupos dentro da empresa. Mas, independentemente do que dito no meu carto de visitas, ou em que histria da Microsoft voc decide acreditar ou ignorar, minhas funes dirias como um gerente de programa eram funes de gerenciamento de projeto. Em termos mais simples, isso significava que eu tinha a responsabilidade de tornar o projeto e quem quer que estivesse contribuindo para ele to bemsucedido quanto possvel. Sob essas habilidades, surgem certas atitudes e traos de personalidade. Sem o conhecimento delas, uma pessoa que lidera ou gerencia um projeto est em sria desvantagem. O equilbrio no gerenciamento de projetos difcil encontrar bons gerentes de projeto porque eles precisam manter um equilbrio de atitudes. Tom Peters, no seu ensaio Pursuing the Perfect Project Manager , chama essas atitudes conflitantes de paradoxos ou dilemas. Esse nome apropriado porque situaes diferentes exigem comportamento diferente. Isso significa que um gerente de projeto precisa no apenas estar ciente dessas peculiaridades, mas tambm desenvolver instintos para saber quais so apropriados em que ocasies. Isso contribui para a idia de gerenciamento de projeto como uma arte: ele requer intuio, julgamento e experincia para usar essas foras. A lista de traos a seguir aproximadamente derivada do ensaio de Peters: Ego/no-ego. Devido responsabilidade que carregam os gerentes de projeto, eles freqentemente tm grande satisfao pessoal com seu trabalho. compreensvel que tenham um alto investimento emocional no que esto fazendo e, para muitos, essa conexo emocional que os permite manter a intensidade necessria para ser eficiente. Mas, ao mesmo tempo, os gerentes de projeto devem evitar colocar seus interesses frente do projeto. Eles devem delegar tarefas importantes ou divertidas e compartilhar elogios e prmios com a equipe inteira. Por mais que o ego possa ser um combustvel, um gerente de projeto tem de reconhecer quando o seu ego est atrapalhando. Autocrata/delegador. Em algumas situaes, as coisas mais importantes so uma linha de autoridade clara e um tempo de resposta rpido. Um gerente de projeto tem de ser seguro e obstinado o bastante para controlar e forar certas aes para uma equipe. Entretanto, o objetivo geral deve ser evitar a necessidade dessas situaes extremas. Um projeto bem gerenciado deve criar um ambiente onde o trabalho possa ser delegado e haja cooperao. Tolerar a ambigidade/perseguir a perfeio. As fases iniciais de qualquer projeto so experincias altamente abertas e fluidas onde o desconhecido excede em muito o conhecido. A ambigidade controlada essencial para que boas idias surjam e um gerente de projeto deve respeit-la, se no gerenci-la. Mas em outros momentos, particularmente nas fases finais de um

projeto, a disciplina e a preciso so soberanas. necessrio sabedoria para discernir quando a busca da perfeio vale a pena, ou, ao contrrio, uma soluo medocre ou rpida suficiente. Verbal/escrito. Embora a maioria das organizaes de desenvolvimento de software sejam centradas na comunicao por emails, as habilidades verbais so importantes para o gerenciamento de projetos. Haver sempre reunies, negociaes, discusses rpidas e sesses de brainstorming, e o gerente de projeto deve ser eficiente tanto na compreenso quanto na comunicao de idias cara a cara. Quanto maior for a organizao ou o projeto, mais importantes se tornam as habilidades escritas (e a disposio para us-las). Apesar das preferncias pessoais, um gerente de projeto precisa reconhecer quando a comunicao escrita ou verbal ser mais eficaz. Reconhecer a complexidade/patrocinar a simplicidade. Muitas pessoas so vtimas da complexidade. Quando elas se deparam com um complexo desafio organizacional ou de engenharia, se perdem em detalhes e esquecem do principal. Outras negam a complexidade e tomam decises erradas porque no compreendem completamente as sutilezas envolvidas. O equilbrio aqui est em reconhecer qual viso do projeto mais til para o problema ou qual deciso conveniente e alternar confortavelmente entre elas ou mant-las em mente, ao mesmo tempo (sem que sua cabea 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 elaborao de um cdigo confivel e bem escrito. Impacincia/pacincia. Na maioria das vezes, o gerente de projeto a pessoa que incita ao, forando as pessoas a manter o trabalho direto e focado. Mas em algumas situaes, a impacincia trabalha contra o projeto. Algumas atividades polticas, burocrticas ou Inter organizacionais so inevitveis escoadouros de tempo: algum tem que estar na sala, ou estar na teleconferncia, e eles tm que ser pacientes. Portanto, saber quando forar uma questo e quando recuar e deixar as coisas acontecer, um sentido que os gerentes de projeto devem desenvolver. Coragem/medo. Um dos grandes enganos da cultura americana achar que corajosos so aqueles que no sentem medo. Isso uma mentira. Corajosos so aqueles que sentem medo, mas decidem agir de qualquer maneira. Um gerente de projeto precisa ter um grande respeito por todas as coisas que possam dar errado e v-las como totalmente possveis. Mas tambm precisa corresponder esse respeito com a coragem necessria para assumir grandes desafios. Crdulo/ctico. No h nada mais poderoso para o moral de uma equipe do que um lder respeitado que acredita no que est fazendo. importante que um gerente de projeto tenha confiana no trabalho que est executando e veja o verdadeiro valor nos objetivos que sero alcanados. Ao mesmo tempo, existe a necessidade de um certo ceticismo (no cinismo) sobre como as coisas esto indo e na maneira como esto sendo executadas. Algum tem que investigar e questionar, expor suposies e trazer as questes difceis luz. O equilbrio est em, de alguma maneira, fazer perguntas e desafiar as suposies de outros vigorosamente, sem abalar a confiana da equipe no que ela est fazendo. Como Peter destaca no seu ensaio, muito 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 cometer envolver erros de clculo ao estimar uma ou mais dessas foras conflitantes. Entretanto, qualquer um pode melhorar ao reconhecer, entender e, ento, aprimorar sua prpria capacidade de manter essas foras em equilbrio. Portanto, embora eu no venha a focar essa lista de paradoxos novamente (embora ela ainda aparea algumas vezes, mais tarde), ela vale como referncia. O exame dessa lista de foras conflitantes, mas necessrias, pode ajudlo a recuar, reconsiderar o que voc est fazendo e por que e tomar decises mais inteligentes. Presso e distrao

Um medo dos novatos no gerenciamento de projetos que o xito exige mudana. Novos projetos so criados com a inteno de alterar o estado do mundo, modificando, construindo ou destruindo algo. Manter o status quo a menos que seja o objetivo explcito, por alguma estranha razo no um bom resultado. O mundo est mudando o tempo todo e se um site da Web ou outro projeto no hoje to bom quanto era no ltimo ano, geralmente significa que est ultrapassado porque as metas foram mal orientadas ou a execuo do projeto falhou de alguma maneira. difcil ignorar a presso subjacente a isso para os gerentes de projeto, mas ela faz parte do pacote. No fique a parado; aprimore-se. H 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 liderana do que com gerenciamento, mas a distino entre os dois sutil. Independente do quanto tente separ-los, o bom gerenciamento requer qualidades de liderana e a liderana requer qualidades de gerenciamento. Qualquer pessoa envolvida em gerenciamento de projeto ser responsvel por um pouco de ambos, no importa o que a descrio do seu cargo diga. Mas, voltando ao problema da presso, conheo muitos gerentes que abdicam dos momentos de liderana (por exemplo, algum momento em que a equipe/projeto precisa de algum para decidir sobre uma ao) e se dedicam apenas a controlar os esforos dos outros em vez de facilitar ou ainda participar deles. Se tudo que algum faz manter o registro e observar do lado de fora, ele estaria mais bem preparado para trabalhar no departamento de contabilidade. Quando algum em uma funo de liderana consistentemente responde presso fugindo da raia, essa pessoa no est liderando est se escondendo. Gerentes de projeto ineficientes ou avessos presso tendem a se abrigar na periferia do projeto, onde agregam pouco valor. Confundindo o processo com metas Alguns gerentes de projeto nessa situao recorrem quantificao de coisas que no precisam ser quantificadas. Inseguros sobre o que mais fazer, ou temerosos de fazer o que precisa ser realizado, eles ocupam seu tempo em coisas secundrias. E, medida que cresce a distncia entre o gerente de projeto e o projeto, aumenta a ateno dada desnecessariamente a grficos, tabelas, listas de verificao e relatrios. possvel que, em algum ponto, os gerentes de projeto comecem a acreditar que os dados e o processo sejam o projeto. Eles focam nas coisas menos importantes e com as quais fcil trabalhar (planilhas ou relatrios), e no nas questes importantes e desafiadoras (o esforo de programao ou o cronograma). Eles podero desenvolver a crena de que se apenas seguirem perfeitamente um determinado procedimento e verificarem as coisas certas, o sucesso do projeto estar garantido (ou, de maneira mais cnica, qualquer falha que ocorra no ser tecnicamente de sua responsabilidade). Para minimizar a possibilidade de confuso, bons gerentes de projeto resistem definio de limites estritos para os tipos de trabalho que desejam ou no executar. Eles evitam as linhas amarelas brilhantes situadas entre as tarefas de gerenciamento de projeto e o projeto propriamente dito. A fidelidade s listas de verificao implica que h um processo definitivo que garante um resultado especfico, o que nunca o caso. Na verdade, sempre h apenas trs coisas: uma meta, uma pilha de trabalho e um monte de pessoas. Funes bem-definidas poderiam ajudar essas pessoas a se organizar em torno do trabalho, mas a formao de funes no a meta. Uma lista de verificao poderia ajudar a fazer o trabalho de maneira a atingir a meta, mas a lista de verificao tambm no a meta. Confundir processos com metas um dos grandes pecados do gerenciamento. Eu deveria saber, pois eu mesmo j o cometi. H alguns anos, trabalhando no projeto do Internet Explorer 4.0, eu era o gerente de projeto para muitas partes da interface de usurio. Eu me sentia pressionado: recebi a maior atribuio da minha vida. Em resposta, desenvolvi a crena de que se escrevesse tudo em listas de verificao, nunca falharia. Embora as coisas precisem ser cuidadosamente controladas em um projeto, eu havia me excedido. Criei uma planilha complexa para mostrar vrias vises de dados e os grandes quadros

brancos do meu escritrio 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 viu gastando mais tempo com minhas listas de verificao e processos do que com a minha equipe o que levantou uma grande bandeira vermelha (sinal de alerta). Um dia, ele entrou na minha sala e vendo a enorme quantidade de listas de verificao e tabelas que eu tinha escrito em todas as superfcies planas do meu escritrio, convidou-me a sentar e fechou a porta. Ele disse: Scott, tudo isso bom, mas seu projeto a sua equipe. Gerencie a equipe e no as listas de verificao. Se as listas de verificao o ajudam a gerenciar a equipe, excelente. Mas da maneira como voc est fazendo, em breve estar usando sua equipe para ajudar a gerenciar suas listas de verificao. Portanto, em vez de focar em processos e mtodos, 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 e cultura da equipe. Mais precisamente, planejamento e controle devem dar suporte equipe para alcanar as metas do projeto, no impedi-las. Eu tenho certeza de que desde que o gerente de projeto preste ateno e ganhe a confiana da equipe, quaisquer tarefas, processos, relatrios, listas de verificao ou outros mecanismos de gerenciamento de projeto necessrios se tornaro evidentes antes que os problemas que eles deveriam resolver se tornem srios. Apenas porque um livro ou um executivo diz para fazer algo, ou porque uma tcnica foi empregada no ltimo ms ou no ltimo ano, no significa que ela se aplique hoje. Cada equipe e projeto diferente e existem vrias razes para questionar julgamentos antigos. A razo para ser conservador com mtodos e processos que aqueles que so desnecessrios tendem a aumentar feito bolas de neve, arrastando as equipes para o abismo dos projetos difceis, conforme descrito no livro The Mythical Man-Month, de Fred Brooks. Quando so necessrios processos para gerenciar processos, difcil saber onde o trabalho real est sendo feito. freqentemente o lder da equipe ou o 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 infindveis seqncias de procedimentos e de avaliaes em reunies. O tipo certo de envolvimento Todos os gerentes de executivos de empresas integrantes da lista das 500 maiores da revista Fortune a tcnicos de equipes esportivas so vulnerveis a um envolvimento excessivo. Acho que em algum ponto eles sabem que representam despesas indiretas (overhead) e um envolvimento compulsivo uma maneira conveniente (embora negativa) de tentar compensar isso. Isso explica parcialmente a oferta contnua de micro gerentes; a ao mais fcil para um gerente fraco abusar do seu poder sobre seus subordinados (e em casos extremos, culpar simultaneamente a incompetncia dos subordinados pela necessidade de muita ateno). A insegurana que os gerentes tm deriva do fato de que, em termos de revoluo industrial, eles no fazem parte da linha de produo. Eles no fazem nada com as mos e no so o mesmo tipo de ativo do que aqueles que fazem. Os gerentes no so contratados para contribuir com uma quantidade linear de trabalho para a fbrica ou para o desenvolvimento de software, como se espera de um trabalhador ou programador. Em vez disso, lderes e gerentes so contratados para aumentar o valor de todos os que os cercam. Os mtodos para agregar esse tipo de valor so diferentes do trabalho em linha de produo. Mas, como muitos gerentes so programadores antigos e foram promovidos gerncia a partir da linha de produo, muito provvel que eles tenham mais segurana e habilidade para escrever cdigos do que para liderar e gerenciar pessoas que escrevem cdigos.

Como um tcnico de uma equipe de futebol, supe-se que a presena de um gerente contribua com algo de natureza diferente da adio de qualquer outro colaborador. Algumas vezes, isso acontece, decorrendo da soluo de conflitos ou da proteo da equipe em relao poltica. Outras vezes, pelo desenvolvimento de bons planos de alto nvel ou de solues inteligentes para situaes inesperadas. Como essas contribuies so mais difceis de medir, muitos gerentes de projeto lidam com a ambigidade de suas funes. Como gerentes, eles so alvos fceis de censuras e tm poucos lugares para se esconder. necessria uma combinao de convico, confiana e conscincia para ser eficiente e feliz como lder de uma equipe. Tirar vantagem da sua perspectiva A melhor maneira de encontrar pontos de alavancagem fazer uso da diferena na psicologia obtida por estar fora da linha de produo. Um gerente de projeto no desempenho de suas tarefas naturalmente gastar mais tempo trabalhando com diferentes pessoas na equipe, obtendo assim mais fontes de informaes e uma perspectiva mais ampla do projeto. O gerente de projeto entender a viso comercial do projeto assim como a viso tcnica e ajudar a equipe a compreender ambas, quando necessrio. Essa perspectiva mais ampla possibilita a passagem de informaes relevantes pessoa certa na hora certa. Uma histria simples ajuda a ilustrar esse ponto de maneira mais abrangente. Eu tinha como hbito 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, e pedia a eles que me mostrassem o material no qual estavam trabalhando. Se eles oferecessem, eu assistia a uma demonstrao do que quer que me mostrassem. Fazer isso durante alguns dias, mesmo que fosse por alguns minutos, me dava uma idia do status real do projeto. Por exemplo, uma manh, durante o projeto do IE 5.0, visitei o escritrio de Fred. Ele estava discutindo com o Steve, outro programador, sobre como iam fazer funcionar adequadamente o novo controle List View um problema de compatibilidade no-previsto tinha sido descoberto naquela manh. Nenhum deles queria fazer o trabalho. E pelo que pude ouvir, demoraria meio dia ou mais para ser corrigido. Eu me meti no assunto e me certifiquei sobre o que eles estavam falando. Eles balanaram a cabea concordando, como se dissessem: Sim, por que voc est preocupado? Ento, eu disse para eles conversarem com Bill no final do corredor. Eles perguntaram novamente por que, achando que isso era um problema de arquitetura muito especfico e que seria difcil eu entender. Sorri e disse: Porque eu acabei de sair do escritrio dele e o novo controle da rvore estava funcionando perfeitamente na sua mquina. Ele detectou o problema na noite passada e o corrigiu como parte de outro item de trabalho. Agora, claro, nessa pequena histria eu no salvei o mundo ou impedi um desastre importante. Se eu no tivesse feito essa conexo para eles, somente algumas horas ou metade de um dia teriam sido gastos (embora os cronogramas s vezes erram um pouco). Mas, esse no o ponto. Bons gerentes de projeto se empenham para conhecer todos os tipos de coisas teis sobre a situao da equipe e tambm do mundo e, ento, aplicar esse conhecimento para ajudar as pessoas a executar seus projetos. So as transferncias de informaes oportunas, como a dessa histria, que transformam equipes medocres em boas e estas em equipes excelentes. Nenhum sistema de controle de projeto ou de erros substitui completamente a necessidade de conversar com as pessoas sobre o que est acontecendo, porque as redes sociais so sempre mais fortes (e, s vezes, mais rpidas) do que as redes tecnolgicas. Os desafios importantes, como viso de projeto, listas de recursos e cronogramas sempre se traduzem em muitos pequenos desafios que so positivamente influenciados pela rapidez com que o bom conhecimento e a informao fluem atravs de uma equipe. Os gerentes de projeto desempenham um papel crtico em tornar esse fluxo ativo e saudvel. Mas, sejam coisas grandes ou pequenas, as aes e decises que os gerentes tomam devem ter benefcios claros para a equipe inteira. Elas podem demorar uma semana ou um ms para se

fazerem notar, mas um bom gerente de projeto criar um impacto positivo na qualidade do trabalho produzido e, freqentemente, na qualidade de vida de todos os envolvidos. As pessoas percebero diferentemente seus trabalhos, diro abertamente que tm uma melhor compreenso do que esto fazendo e por que, e se sentiro melhor sobre o que est por vir. Esse tipo de mudana s acontece a cada reunio, deciso ou discusso mas, ao longo de um projeto, essa vibrao e energia podem mudar e melhorar dramaticamente. Gerentes de projeto criam valor nico Como resultado, bons gerentes e lderes freqentemente ganham um tipo especial de respeito dos programadores, testadores, designers, pessoal de marketing e documentao. O gerente de projeto deve ser capaz de executar a faanha de pensar, liderar e criar estratgias que causem impacto positivo na equipe de maneira tal que poucos o conseguiriam. Freqentemente isso envolve encontrar atalhos e otimizaes inteligentes no fluxo de trabalho dirio ou dar um impulso no entusiasmo ou encorajamento da maneira certa e na hora certa. Eles no precisam ser super-homens, ou ter um brilho especial para fazer isso (como eu descobri). Precisam apenas entender a vantagem de suas perspectivas e decidir fazer uso delas. H um simples fato indiscutvel: os lderes ou gerentes de projeto gastam mais tempo com cada membro da equipe de projeto do qualquer outra pessoa. Eles esto em mais reunies, visitam mais escritrios e conversam com mais colaboradores individuais do que qualquer outra pessoa. Eles tomam mais decises ou as influenciam mais do que qualquer outra pessoa na organizao. Quando o gerente de projeto est feliz, triste, motivado ou deprimido, um pouco desse sentimento ir contagiar todos aqueles que o encontrarem naquele dia. O que os gerentes de projeto trouxerem para o projeto, seja bom ou ruim, contagiar o resto da equipe. Portanto, se o gerente de projeto for focado, comprometido, entusiasmado ou capaz de ser bemsucedido, as possibilidades de todos se comportarem da mesma maneira aumenta. Gerentes de todo tipo esto em posies similares de poder potencial, e existem poucos pontos de influncia de mesmo valor na maioria dos ambientes de trabalho. Isso significa que se for possvel cultivar as atitudes e idias descritas at aqui, no h melhor lugar para fazer esses investimentos do que em lderes e gerentes. Isso no quer dizer que um gerente de projeto precisa ter a imagem carismtica de heri que, com um simples gesto, pode liderar exrcitos de programadores em uma batalha. Em vez disso, basta estar genuinamente interessado em ajudar os relacionamentos de seus companheiros de equipe e ter mais xito do que fracassos nessa tarefa. Finalmente, acredito que a idia principal que desde que ningum saia ferido (exceto talvez os concorrentes) e voc envolva as pessoas da maneira certa, nada mais importa exceto o fato de que coisas boas sejam feitas. No importa quantas idias venham de voc ou de qualquer outra pessoa, desde que o resultado seja positivo. O gerenciamento de projeto consiste em usar todos os meios necessrios para aumentar a probabilidade e a velocidade de resultados positivos. Um mantra til que tenho usado diariamente Faa coisas boas acontecer. As pessoas poderiam me ver no corredor ou trabalhando com um programador em um quadro branco e perguntar: Ei Scott, o que voc est fazendo? E eu sorriria dizendo: Fazendo coisas boas acontecerem. Isso tornouse uma parte dominante de como eu enfrentei cada dia e, quando gerenciei outras pessoas, essa atitude se estendeu de forma a abranger toda a equipe.