Você está na página 1de 12

UMA BREVE HISTÓRIA DO GERENCIAMENTO DE PROJETOS

(A Arte do Gerenciamento de Projetos - Scott Berkun)

Em muitas organizações, o líder de um projeto não tem o cargo de gerente de projeto. Tudo bem. Todos os programadores, gerentes, líderes de equipe, analistas e designers gerenciam projetos no seu trabalho diário, estejam eles trabalhando sozinhos ou em equipe. Por enquanto, essas distinções não são importantes. Minha intenção é entender o que torna um projeto bem-sucedido

e como as pessoas que lideram projetos bem-sucedidos o fazem.

Essas idéias e estratégias principais não requerem hierarquias, cargos ou métodos específicos. Portanto, se você trabalha em um projeto e tem alguma responsabilidade sobre seus resultados, esta obra se aplicará a você. E caso seu cartão de visitas o apresente como um gerente de projetos, melhor ainda.

Usando a história

O gerenciamento de projetos, como uma idéia, data de muito tempo. Se você pensar em tudo o

que foi criado na história da civilização, teremos milhares de anos de experiência com os quais

aprender. Uma linha pontilhada pode ser desenhada desde os desenvolvedores de software de hoje retrocedendo no tempo até os construtores das pirâmides do Egito ou os arquitetos dos aquedutos 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 o modo como seus projetos de desenvolvimento de software

e Web são gerenciados, é raro prestar atenção às lições aprendidas no passado. A linha do tempo

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 semelhanças.

Eles têm requisitos, projetos (designs) e restrições. Eles dependem da comunicação, da tomada de decisão e de combinações de pensamento lógico e criativo. Os projetos normalmente envolvem um cronograma (schedule), um orçamento 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 aço, há sempre um conjunto principal de conceitos irrefutáveis que a maioria dos projetos deve compartilhar.

Minha curiosidade sobre as formas de liderar os esforços 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 soluções comparáveis em meu próprio trabalho. Imaginei como projetos como o Telescópio Espacial Hubble e o Boeing 777 foram desenvolvidos e construídos. Poderia eu

reutilizar algo de suas complexas especificações e processos de planejamento? Ou quando o prédio da Chrysler foi construído na cidade de Nova York e o Parthenon em Atenas, os líderes de projeto planejaram e estimaram suas construções da mesma forma que os meus programadores

o fazem? Quais foram as diferenças interessantes e o que pode ser aprendido examinando essas

diferenças?

O que dizer dos editores de jornais, que organizam e planejam a produção diária das informações?

Eles estavam fazendo multimídia (imagens e texto) muito antes dos primeiros sonhos de publicação na Web. E sobre a produção de filmes de longa-metragem? O lançamento da Apollo 13?

Examinando essas questões, fui capaz de perceber como liderar equipes de projeto de uma nova maneira. Entretanto, essas perguntas nem sempre tinham respostas óbvias. Eu não posso prometer que você entregará o resultado mais cedo ou planejará melhor porque as informações

deste texto foram influenciadas por essas fontes. Mas eu sei que quando retornei ao mundo do software após pesquisar em vários lugares, meus processos e ferramentas me pareceram diferentes. Encontrei maneiras de modificá-los que antes não tinha considerado. No todo, percebi que muitas abordagens e comparações úteis que encontrei nunca tinham sido mencionadas durante meus estudos de ciência da computação na universidade. Elas nunca foram discutidas em conferências do setor tecnológico ou escritas em revistas do ramo.

As principais lições aprendidas nas minhas investigações sobre o passado são descritas nos três pontos a seguir:

1.

O

gerenciamento de projeto e o desenvolvimento de software não são artes sagradas. Qualquer

trabalho da moderna engenharia é uma nova entrada no longo histórico da criação. As tecnologias e habilidades podem mudar, mas grande parte dos principais desafios que dificultam a engenharia permanece. Todas as coisas, quer linguagens de programação ou metodologias de desenvolvimento, são únicas de alguma maneira, mas derivadas de outras. Mas se quisermos reutilizar o máximo possível de conhecimento do passado, precisamos ter certeza de que estamos abertos para examinar ambos os aspectos – o único e o derivado – em comparação com o que veio antes.

2.

Quanto mais simples a visão do que você faz, mais poder e foco terá ao executá-la. Se pudermos manter periodicamente uma visão simples do nosso trabalho, poderemos encontrar comparações úteis com outras maneiras de realizar as coisas que existem em nosso redor. Existirão mais exemplos e lições da história e das indústrias 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 possível e é necessário praticar para manter essa atitude. Para continuarmos a aprender, temos de evitar a tentação de aceitarmos visões estreitas e seguras sobre o que fazemos.

3.

Simples não quer dizer fácil. Os melhores atletas, escritores, programadores e gerentes tendem a ser aqueles que sempre vêem o que fazem como simples em sua essência, mas, simultaneamente, difícil. Lembre-se de que simples não é o mesmo que fácil. Por exemplo, correr uma maratona é uma coisa simples. Você começa a correr e não pára até completar 42 km. O que poderia ser mais simples? O fato de ser difícil não nega sua simplicidade. Liderança

gerenciamento também são difíceis, mas sua natureza – executar tarefas de uma maneira específica para atingir uma meta específica – é simples.

e

Aprendendo com os erros

“Os seres humanos, que são praticamente os únicos (entre os animais) que têm a habilidade de aprender com a experiência alheia, são também notáveis em sua aparente má vontade para fazer isso.” (Douglas Adams)

Uma questão simples que surge no estudo da história dos projetos é esta: por que alguém concorda em sofrer com os erros e desapontamentos se eles podem ser evitados? Se a história das engenharias antiga e moderna está (amplamente) no domínio público e somos pagos para fazer coisas inteligentes independentemente da fonte de inspiração, por que tão poucas organizações recompensam as pessoas por buscar lições no passado? Enquanto projetos são concluídos 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 organizações raramente recompensam as pessoas por buscar esse tipo de conhecimento. Talvez seja por medo do que encontrarão (e o medo de serem considerados responsáveis por isso). Ou talvez seja apenas falta de interesse da parte de alguém em rever as experiências dolorosas e frustrantes quando o tempo poderia ser gasto na próxima mudança 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 forçam a prestar atenção. Elas nos obrigam

a reexaminar as premissas que havíamos esquecido que existiam (é difícil fingir que tudo está bem quando o protótipo pegou fogo). Como Karl Popper sugeriu, há apenas dois tipos de teorias: as que estão erradas e as que estão incompletas. Sem os fracassos, nós esquecemos arrogantemente que nossa compreensão das coisas nunca é tão completa quanto pensamos ser.

O artifício, então, é aprender o máximo possível com as falhas de outras pessoas. Devemos usar

suas experiências para influenciar o futuro. Embora os detalhes superficiais da falha possam ser totalmente diferentes de projeto para projeto, as causas básicas ou as ações da equipe que levaram a elas poderão ser plenamente transferíveis (e evitáveis). Mesmo em nossos próprios projetos, precisamos evitar o hábito de fugirmos e nos escondermos de nossas falhas. Em vez disso, devemos vê-las como oportunidades para aprender algo. Que fatores contribuíram para que isso acontecesse? Quais deles seriam mais fáceis 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 lições aprendidas a partir de falhas de projeto e engenharia.

A Boeing mantém esse documento desde que a empresa foi criada e o utiliza para ajudar os novos

projetistas a aprenderem com as tentativas do passado. Qualquer organização com esse tipo de orientação não apenas aumenta suas chances de projetos bem-sucedidos, como também 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 próprios livros negros.

Desenvolvimento para a Web, cozinhas e salas de emergência

Um problema com a história é que ela nem sempre é referenciável. Pode ser difícil aplicar lições ao longo de décadas e manter a empatia por coisas que parecem tão diferentes do modo como o trabalho é realizado nos dias de hoje. Uma alternativa é fazer comparações com tipos diferentes de projetos modernos. Embora não tenha o mesmo impacto da história da engenharia, isso permite observações e experiências pessoais. Com freqüência, ver as coisas na fonte é a única maneira de fornecer informações suficientes para fazer conexões entre idéias diferentes.

Como exemplo, eu conheço 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 o desenvolvimento para

a Web exige que ele tome decisões de engenharia complexas – projetando e coordenando à

medida que avança, verificando alterações em questão de horas ou mesmo minutos e, em seguida,

publicando para todo o mundo – seu projeto e gerenciamento de tarefas são 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 atrás. Eu tenho certeza de que na sua experiência você já encontrou pessoas como ele. Ou talvez tenha trabalhado em situações onde parecia improvável que alguém mais no universo pudesse ter gerenciado algo tão 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 razões, é interessante caminhar pelas cozinhas (consulte o excelente livro de Anthony Bourdain, Kitchen Confidential, Ecco, 2001), mas meu ponto específico era sobre produtividade. A primeira vez que alguém vê o gerenciamento e a coordenação de tarefas rápidas que ocorrem em uma cozinha profissional atarefada, provavelmente reconsiderará a dificuldade de seu próprio trabalho. Os cozinheiros estão freqüentemente distribuindo frigideiras com diferentes pedidos em diferentes estados de conclusão

e correndo entre vários conjuntos de queimadores em cantos opostos da cozinha, enquanto os

garçons correm para lá e para cá, entregando notícias de ajustes e problemas com os clientes.

Tudo isso acontece em espaços pequenos e apertados, bem acima de 30 C, com luminosas luzes fluorescentes brilhando acima. E apesar do número de pedidos que saem a cada segundo, novos pedidos entram com a mesma velocidade. Alguns pedidos são enviados de volta ou, como em muitos projetos de software, exigem modificações personalizadas e de última hora (a mesa 1 tem intolerância a lactose; a mesa 2 precisa de molho separado etc.). É maravilhoso observar cozinhas grandes e atarefadas. Apesar de parecerem caóticas à primeira vista, as cozinhas grandes funcionam com um nível de intensidade e precisão que deixam a maioria das equipes de desenvolvimento no chinelo.

Os chefes de cozinha e os cozinheiros regulares são gerentes de projetos culinários, ou como Bourdain se refere a eles, controladores de tráfego aéreo (outra profissão 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 diária é incomparável.

Se você duvida de mim, na próxima vez em que estiver em um restaurante cheio, pergunte ao garçom se é possível dar uma espiada na cozinha. Talvez ele não permita, mas se permitir, você não ficará desapontado. (Alguns restaurantes e bares mais modernos têm cozinhas abertas. Se encontrar um, sente-se o mais próximo possível dela. Depois, acompanhe uma pessoa por alguns minutos. Observe como os pedidos são colocados, controlados, construídos e entregues. Se você for num dia em que ele estiver cheio, pensará de maneira diferente sobre como os erros de software são registrados, rastreados e corrigidos.)

Outra lição de campo interessante no gerenciamento de projetos vem das salas de emergência dos hospitais. Eu assisti no Discovery Channel e no PBS como pequenas equipes de médicos, enfermeiras e especialistas experientes trabalham juntos como uma equipe de projeto para tratar de situações médicas diversas e algumas vezes bizarras que surgem nas portas dos hospitais. Não surpreende que tenha sido a profissão que inventou o processo de triagem, um termo comumente usado em projetos de software para priorizar problemas e defeitos.

O ambiente médico, especialmente em situações de trauma, oferece uma comparação fascinante

para trabalho baseado em equipe, tomadas de decisão sob alto estresse e resultados de projetos que afetam muitas pessoas todos os dias (consulte a Figura 1.1 para obter uma comparação 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):

Nós esperamos que a medicina seja um campo regular de conhecimento e procedimento. Mas não é. Ela é uma ciência imperfeita, um empreendimento de conhecimento em constante mudança, informações incertas, indivíduos passíveis de falhas e ao mesmo tempo “prontos para o combate”. Há ciência no que fazemos, mas também hábito, intuição e às vezes simples suposições. O vácuo entre o que sabemos e o que almejamos persiste. E esse vácuo complica tudo o que fazemos.

Esse ponto, e muitos outros do livro esclarecedor de Gawande, p ermanecem verdadeiros para o

Esse ponto, e muitos outros do livro esclarecedor de Gawande, permanecem verdadeiros para o desenvolvimento de software. Fred Brooks, no livro clássico sobre engenharia de software, The Mythical Man-Month, faz comparações similares entre equipes de cirurgiões e equipes de programadores. Embora vidas raramente estejam em risco quando trabalhamos em sites ou bancos de dados da Web, existem muitas semelhanças válidas nos desafios que essas diferentes equipes de pessoas precisam enfrentar.

A função principal do gerenciamento de projetos

O gerenciamento de projetos pode ser uma profissão, uma tarefa, uma função ou uma atividade. Algumas empresas têm gerentes de projeto cuja tarefa é supervisionar projetos de 200 pessoas. Outras usam o título para gerentes juniores, cada um deles responsável por uma pequena área de um grande projeto. Dependendo de como uma organização está estruturada, da sua cultura e das metas do projeto, o gerenciamento de projetos pode ser uma função informal (“ela é realizada por qualquer pessoa, sempre que necessário”) ou altamente definida (“Vincent, Claude e Raphael são gerentes de projeto em tempo integral”).

Usarei principalmente o termo gerente de projeto, ou GP, para fazer referência a quem está envolvido na atividade de liderança e gerenciamento de projetos. Por atividade de gerenciamento de projeto quero dizer liderar a equipe na solução do projeto (planejamento, programação e reunião de requisitos), orientar o projeto no trabalho de design e desenvolvimento (comunicação, tomada de decisão e estratégia de meio de jogo) e executar o projeto até a conclusão (liderança, gerenciamento das crises e estratégia 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 não seja seu trabalho principal” ou “pessoa que pensa no projeto na íntegra”. Encontrei muitas maneiras diferentes para essas atividades serem distribuídas pelas equipes e a recomendação deste texto é totalmente indiferente para elas. O conteúdo deste texto é menos sobre os títulos e formalizações de cargos e mais sobre executar tarefas e fazê-las acontecer. Mas, para manter meu texto o mais simples possível, usarei o termo gerente de projeto ou GP.

Às vezes, a ausência de um gerente de projeto exclusivo funciona bem. Os programadores e seus chefes mantêm seus cronogramas e planos de engenharia (se houver) e um analista de negócios ou pessoa de marketing faz o planejamento ou gerenciamento de requisitos. Tudo o mais que

poderia ser qualificado como um gerenciamento de projeto simplesmente é distribuído pela equipe. Talvez as pessoas da equipe tenham sido contratadas por seus interesses que vão além de escrever um código. Elas poderiam não se dedicar ao planejamento inicial, design de interface de usuário ou estratégia de negócios. Trabalhar dessa maneira pode acarretar otimizações significativas. Desde que todos queiram pagar o preço 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 funcionário. Eficiência e simplicidade são coisas boas.

Mas outras vezes, a ausência de um gerente de projeto cria disfunção. Sem uma pessoa cuja função principal seja reunir o esforço geral, as tendências e interesses individuais podem desviar as direções da equipe. Fortes facções adversárias podem ser desenvolvidas em torno das funções de engenharia e 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 liderança na decisão do curso de ação para um paciente. Isso apressa muitas decisões e dá clareza às funções 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 não houver uma pessoa com uma função clara para liderar a triagem de erros ou alguém dedicado a rastrear os problemas de cronograma e sinalização, essas tarefas poderão ficar perigosamente para trás das atividades de programação individuais.

Embora eu ache que muitos dos melhores programadores entendem o suficiente de gerenciamento de projetos para gerenciá-los sozinhos, eles também 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 coordenação dos esforços de engenharia com a área de marketing e negócios de cada divisão (alguns poderão dizer que isso ainda é um problema para a Microsoft e muitas outras empresas). Um homem sábio chamado Jabe Blumenthal percebeu que poderia existir uma tarefa especial onde um indivíduo estivesse envolvido com essas duas funções, desempenhando um papel de liderança e coordenação. Essa pessoa estaria envolvida no projeto desde o primeiro dia do planejamento até o último 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 participação mais abrangente no modo como os produtos fossem feitos.

Para desempenhar bem esse papel, ele teria de gostar de passar seus dias executando tarefas tão variadas quanto escrever especificações, rever planos de marketing, gerar cronogramas de projeto, liderar equipes, fazer planejamento estratégico, executar triagem de erros/falhas, cultivar a moral da equipe e fazer tudo o que precisa ser feito e que ninguém 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 idéia de uma organização matricial, onde existem duas linhas de estrutura hierárquica para os indivíduos: uma baseada na função e a outra baseada no projeto. Portanto, um programador ou testador individual poderia ter dois relacionamentos hierárquicos – um principal para seu papel funcional e um secundário, 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 coordenação com a equipe de negócios e em todos os corredores da Microsoft havia muita alegria.

Após muitos memorandos e reuniões, a maioria das equipes na empresa adotou lentamente a função. Não importam os produtos resultantes, bons ou ruins, a idéia faz sentido. Ao definir um papel para um generalista no nível de linha, que não tenha sido um auxiliar de baixa qualificação,

mas um líder ou um orientador, a dinâmica 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 incluíram

o Internet Explorer, MSN e Windows. Gerenciei também equipes de pessoas que desempenhavam esse papel.

Até hoje, não sei de muitas empresas que tenham ido tão longe na redefinição e formalização de gerenciamento de projeto. Era raro, em minhas interações com outras firmas de desenvolvimento de software e Web, encontrar alguém que desempenhasse um tipo de função similar (eles eram engenheiros ou administradores, ou em raras ocasiões, designers). Muitas companhias usam estruturas de time para organizar o trabalho, mas poucas definem os papéis que atravessam deliberadamente as hierarquias de engenharia e negócios. Hoje existem mais de 5.000 gerentes de programa na Microsoft (em mais de 50.000 funcionários no total) e embora a força da idéia tenha sido diluída (e em muitos casos mal utilizada), o espírito principal dela ainda pode ser encontrado em muitas equipes e grupos dentro da empresa.

Mas, independentemente do que é dito no meu cartão de visitas, ou em que história da Microsoft você decide acreditar ou ignorar, minhas funções diárias como um gerente de programa eram funções 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 – tão bem- sucedido quanto possível.

Sob essas habilidades, surgem certas atitudes e traços de personalidade. Sem o conhecimento delas, uma pessoa que lidera ou gerencia um projeto está em séria desvantagem.

O equilíbrio no gerenciamento de projetos

É difícil encontrar bons gerentes de projeto porque eles precisam manter um equilíbrio de atitudes.

Tom Peters, no seu ensaio “Pursuing the Perfect Project Manager” , chama essas atitudes conflitantes de paradoxos ou dilemas. Esse nome é apropriado porque situações diferentes exigem comportamento diferente. Isso significa que um gerente de projeto precisa não apenas estar ciente dessas peculiaridades, mas também desenvolver instintos para saber quais são apropriados em que ocasiões. Isso contribui para a idéia de gerenciamento de projeto como uma arte: ele requer intuição, julgamento e experiência para usar essas forças. A lista de traços a seguir é aproximadamente derivada do ensaio de Peters:

Ego/não-ego. Devido à responsabilidade que carregam os gerentes de projeto, eles freqüentemente têm grande satisfação pessoal com seu trabalho. É compreensível que tenham um alto investimento emocional no que estão fazendo e, para muitos, essa conexão emocional é que os permite manter a intensidade necessária 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 prêmios com a equipe inteira. Por mais que o ego possa ser um combustível, um gerente de projeto tem de reconhecer quando o seu ego está atrapalhando.

Autocrata/delegador. Em algumas situações, as coisas mais importantes são uma linha de

autoridade clara e um tempo de resposta rápido. Um gerente de projeto tem de ser seguro e obstinado o bastante para controlar e forçar certas ações para uma equipe. Entretanto, o objetivo geral deve ser evitar a necessidade dessas situações extremas. Um projeto bem gerenciado deve criar um ambiente onde o trabalho possa ser delegado e haja cooperação.

Tolerar a ambigüidade/perseguir a perfeição. As fases iniciais de qualquer projeto são

experiências altamente abertas e fluidas onde o desconhecido excede em muito o conhecido.

A ambigüidade controlada é essencial para que boas idéias surjam e um gerente de projeto deve

respeitá-la, se não gerenciá-la. Mas em outros momentos, particularmente nas fases finais de um

projeto, a disciplina e a precisão são soberanas. É necessário sabedoria para discernir quando a busca da perfeição vale a pena, ou, ao contrário, uma solução medíocre ou rápida é suficiente.

Verbal/escrito. Embora a maioria das organizações de desenvolvimento de software sejam

centradas na comunicação por emails, as habilidades verbais são importantes para o gerenciamento de projetos. Haverá sempre reuniões, negociações, discussões rápidas e sessões de brainstorming, e o gerente de projeto deve ser eficiente tanto na compreensão quanto na comunicação de idéias cara a cara. Quanto maior for a organização ou o projeto, mais importantes se tornam as habilidades escritas (e a disposição para usá-las). Apesar das preferências pessoais, um gerente de projeto precisa reconhecer quando a comunicação escrita ou verbal será mais eficaz.

Reconhecer a complexidade/patrocinar a simplicidade. Muitas pessoas são vítimas 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 decisões erradas porque não compreendem completamente as sutilezas envolvidas. O equilíbrio aqui está em reconhecer qual visão do projeto é mais útil para o problema ou qual decisão é conveniente e alternar confortavelmente entre elas ou mantê-las em mente, ao mesmo tempo (sem que sua cabeça 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 elaboração de um código confiável e bem escrito.

• Impaciência/paciência. Na maioria das vezes, o gerente de projeto é a pessoa que incita à ação, forçando as pessoas a manter o trabalho direto e focado. Mas em algumas situações, a impaciência trabalha contra o projeto. Algumas atividades políticas, burocráticas ou Inter organizacionais são inevitáveis escoadouros de tempo: alguém tem que estar na sala, ou estar na teleconferência, e eles têm que ser pacientes. Portanto, saber quando forçar uma questão 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 são

aqueles que não sentem medo. Isso é uma mentira. Corajosos são 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 possíveis. Mas também precisa corresponder esse respeito com a coragem necessária para assumir grandes desafios.

Crédulo/cético. Não há nada mais poderoso para o moral de uma equipe do que um líder

respeitado que acredita no que está fazendo. É importante que um gerente de projeto tenha confiança no trabalho que está executando e veja o verdadeiro valor nos objetivos que serão alcançados. Ao mesmo tempo, existe a necessidade de um certo ceticismo (não cinismo) sobre como as coisas estão indo e na maneira como estão sendo executadas.

Alguém tem que investigar e questionar, expor suposições e trazer as questões difíceis à luz. O equilíbrio está em, de alguma maneira, fazer perguntas e desafiar as suposições de outros vigorosamente, sem abalar a confiança 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 cálculo ao estimar uma ou mais dessas forças conflitantes. Entretanto, qualquer um pode melhorar ao reconhecer, entender e, então, aprimorar sua própria capacidade de manter essas forças em equilíbrio. Portanto, embora eu não venha a focar essa lista de paradoxos novamente (embora ela ainda apareça algumas vezes, mais tarde), ela vale como referência. O exame dessa lista de forças conflitantes, mas necessárias, pode ajudá- lo a recuar, reconsiderar o que você está fazendo e por que e tomar decisões mais inteligentes.

Pressão e distração

Um medo dos novatos no gerenciamento de projetos é que o êxito exige mudança. Novos projetos são criados com a intenção de alterar o estado do mundo, modificando, construindo ou destruindo algo. Manter o status quo – a menos que seja o objetivo explícito, por alguma estranha razão – não

é um bom resultado. O mundo está mudando o tempo todo e se um site da Web ou outro projeto

não é hoje tão bom quanto era no último ano, geralmente significa que está ultrapassado porque as metas foram mal orientadas ou a execução do projeto falhou de alguma maneira.

É difícil ignorar a pressão subjacente a isso para os gerentes de projeto, mas ela faz parte do

“pacote”. Não fique aí parado; aprimore-se. Há sempre uma nova maneira de pensar, um novo tópico para aprender e aplicar, ou um novo processo que torna o trabalho mais divertido ou eficaz. Talvez essa seja uma responsabilidade mais condizente com liderança do que com gerenciamento,

mas a distinção entre os dois é sutil. Independente do quanto tente separá-los, o bom gerenciamento requer qualidades de liderança e a liderança requer qualidades de gerenciamento. Qualquer pessoa envolvida em gerenciamento de projeto será responsável por um pouco de ambos, não importa o que a descrição do seu cargo diga.

Mas, voltando ao problema da pressão, conheço muitos gerentes que abdicam dos momentos de liderança (por exemplo, algum momento em que a equipe/projeto precisa de alguém para decidir sobre uma ação) e se dedicam apenas a controlar os esforços dos outros em vez de facilitar ou ainda participar deles. Se tudo que alguém faz é manter o registro e observar do lado de fora, ele estaria mais bem preparado para trabalhar no departamento de contabilidade. Quando alguém em uma função de liderança consistentemente responde à pressão “fugindo da raia”, essa pessoa não está liderando – está se escondendo. Gerentes de projeto ineficientes ou avessos à pressão tendem a se abrigar na periferia do projeto, onde agregam pouco valor.

Confundindo o processo com metas

Alguns gerentes de projeto nessa situação recorrem à quantificação de coisas que não precisam ser quantificadas. Inseguros sobre o que mais fazer, ou temerosos de fazer o que precisa ser realizado, eles ocupam seu tempo em coisas secundárias. E, à medida que cresce a distância entre

o gerente de projeto e o projeto, aumenta a atenção dada desnecessariamente a gráficos, tabelas,

listas de verificação e relatórios. É possível 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 é fácil trabalhar (planilhas ou relatórios), e não nas questões importantes e

desafiadoras (o esforço de programação ou o cronograma). Eles poderão desenvolver a crença de que se apenas seguirem perfeitamente um determinado procedimento e verificarem as coisas certas, o sucesso do projeto estará garantido (ou, de maneira mais cínica, qualquer falha que ocorra não será tecnicamente de sua responsabilidade).

Para minimizar a possibilidade de confusão, bons gerentes de projeto resistem à definição de limites estritos para os tipos de trabalho que desejam ou não 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 verificação implica que há um processo definitivo que garante um resultado específico, o que nunca é o caso. Na verdade, sempre há apenas três coisas: uma meta, uma pilha de trabalho e um monte de pessoas. Funções bem-definidas poderiam ajudar essas pessoas a se organizar em torno do trabalho, mas a formação de funções não é a meta. Uma lista de verificação poderia ajudar a fazer o trabalho de maneira a atingir a meta, mas a lista de verificação também não é 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 usuário. Eu me sentia pressionado: recebi a maior atribuição da minha vida. Em resposta, desenvolvi a crença de que se escrevesse tudo em listas de verificação, nunca falharia. Embora as coisas precisem ser cuidadosamente controladas em um projeto, eu havia me excedido. Criei uma planilha complexa para mostrar várias visões de dados e 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 viu gastando mais tempo com minhas listas de verificação 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 verificação e tabelas que eu tinha escrito em todas as superfícies planas do meu escritório, convidou-me a sentar e fechou a porta. Ele disse: “Scott, tudo isso é bom, mas seu projeto é a sua equipe. Gerencie a equipe e não as listas de verificação. Se as listas de verificação 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 verificação”.

Portanto, em vez de focar em processos e métodos, 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 alcançar as metas do projeto, não impedi-las. Eu tenho certeza de que desde que o gerente de projeto preste atenção e ganhe a confiança da equipe, quaisquer tarefas, processos, relatórios, listas de verificação ou outros mecanismos de gerenciamento de projeto necessários se tornarão evidentes antes que os problemas que eles deveriam resolver se tornem sérios.

Apenas porque um livro ou um executivo diz para fazer algo, ou porque uma técnica foi empregada no último mês ou no último ano, não significa que ela se aplique hoje. Cada equipe e projeto é diferente e existem várias razões para questionar julgamentos antigos. A razão para ser conservador com métodos e processos é que aqueles que são desnecessários tendem a aumentar feito bolas de neve, arrastando as equipes para o abismo dos projetos difíceis, conforme descrito no livro The Mythical Man-Month, de Fred Brooks. Quando são necessários processos para gerenciar processos, é difícil saber onde o trabalho real está sendo feito. É freqüentemente o líder 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 infindáveis seqüências de procedimentos e de avaliações em reuniões.

O tipo certo de envolvimento

Todos os gerentes – de executivos de empresas integrantes da lista das 500 maiores da revista Fortune a técnicos de equipes esportivas – são vulneráveis 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 contínua de “micro gerentes”; a ação mais fácil para um gerente fraco é abusar do seu poder sobre seus subordinados (e em casos extremos, culpar simultaneamente a incompetência dos subordinados pela necessidade de muita atenção). A insegurança que os gerentes têm deriva do fato de que, em termos de revolução industrial, eles não fazem parte da linha de produção. Eles não fazem nada com as mãos e não são o mesmo tipo de ativo do que aqueles que fazem.

Os gerentes não são contratados para contribuir com uma quantidade linear de trabalho para a fábrica ou para o desenvolvimento de software, como se espera de um trabalhador ou programador. Em vez disso, líderes e gerentes são contratados para aumentar o valor de todos os que os cercam. Os métodos para agregar esse tipo de valor são diferentes do trabalho em linha de produção. Mas, como muitos gerentes são programadores antigos e foram promovidos à gerência a partir da linha de produção, é muito provável que eles tenham mais segurança e habilidade para escrever códigos do que para liderar e gerenciar pessoas que escrevem códigos.

Como um técnico de uma equipe de futebol, supõe-se que a presença de um gerente contribua com algo de natureza diferente da adição de qualquer outro colaborador. Algumas vezes, isso acontece, decorrendo da solução de conflitos ou da proteção da equipe em relação à política. Outras vezes, pelo desenvolvimento de bons planos de alto nível ou de soluções inteligentes para situações inesperadas. Como essas contribuições são mais difíceis de medir, muitos gerentes de projeto lidam com a ambigüidade de suas funções. Como gerentes, eles são alvos fáceis de censuras e têm poucos lugares para se esconder. É necessária uma combinação de convicção, confiança e consciência para ser eficiente e feliz como líder de uma equipe.

Tirar vantagem da sua perspectiva

A melhor maneira de encontrar pontos de alavancagem é fazer uso da diferença na psicologia

obtida por estar fora da linha de produção. Um gerente de projeto no desempenho de suas tarefas naturalmente gastará mais tempo trabalhando com diferentes pessoas na equipe, obtendo assim mais fontes de informações e uma perspectiva mais ampla do projeto. O gerente de projeto entenderá a visão comercial do projeto assim como a visão técnica e ajudará a equipe a compreender ambas, quando necessário. Essa perspectiva mais ampla possibilita a passagem de informações relevantes à pessoa certa na hora certa. Uma história simples ajuda a ilustrar esse ponto de maneira mais abrangente.

Eu tinha como hábito 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 demonstração do que quer que me mostrassem. Fazer isso durante alguns dias, mesmo que fosse por alguns minutos, me dava uma idéia do status real do projeto.

Por exemplo, uma manhã, durante o projeto do IE 5.0, visitei o escritório 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 não-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 balançaram a cabeça concordando, como se dissessem: “Sim, por que você está preocupado?” Então, 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 específico e que seria difícil eu entender. Sorri e disse: “Porque eu acabei de sair do escritório dele

e o novo controle da árvore estava funcionando perfeitamente na sua máquina. Ele detectou o problema na noite passada e o corrigiu como parte de outro item de trabalho”.

Agora, é claro, nessa pequena história eu não salvei o mundo ou impedi um desastre importante. Se eu não tivesse feito essa conexão para eles, somente algumas horas ou metade de um dia teriam sido gastos (embora os cronogramas às vezes erram um pouco). Mas, esse não é o ponto. Bons gerentes de projeto se empenham para conhecer todos os tipos de coisas úteis sobre a situação da equipe e também do mundo e, então, aplicar esse conhecimento para ajudar as pessoas a executar seus projetos. São as transferências de informações oportunas, como a dessa história, que transformam equipes medíocres 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 são sempre mais fortes (e, às vezes, mais rápidas) do que as redes tecnológicas. Os desafios importantes, como visão de projeto, listas de recursos e cronogramas sempre se traduzem em muitos pequenos desafios que são positivamente influenciados pela rapidez com que o bom conhecimento e a informação fluem através de uma equipe. Os gerentes de projeto desempenham um papel crítico em tornar esse fluxo ativo e saudável.

Mas, sejam coisas grandes ou pequenas, as ações e decisões que os gerentes tomam devem ter benefícios claros para a equipe inteira. Elas podem demorar uma semana ou um mês para se

fazerem notar, mas um bom gerente de projeto criará um impacto positivo na qualidade do trabalho produzido e, freqüentemente, na qualidade de vida de todos os envolvidos. As pessoas perceberão diferentemente seus trabalhos, dirão abertamente que têm uma melhor compreensão do que estão

fazendo e por que, e se sentirão melhor sobre o que está por vir. Esse tipo de mudança só acontece

a cada reunião, decisão ou discussão mas, ao longo de um projeto, essa vibração e energia podem mudar e melhorar dramaticamente.

Gerentes de projeto criam valor único

Como resultado, bons gerentes e líderes freqüentemente ganham um tipo especial de respeito dos programadores, testadores, designers, pessoal de marketing e documentação. O gerente de projeto deve ser capaz de executar a façanha de pensar, liderar e criar estratégias que causem impacto positivo na equipe de maneira tal que poucos o conseguiriam.

Freqüentemente isso envolve encontrar atalhos e otimizações inteligentes no fluxo de trabalho diário ou dar um impulso no entusiasmo ou encorajamento da maneira certa e na hora certa. Eles não 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 indiscutível: os líderes ou gerentes de projeto gastam mais tempo com cada membro da equipe de projeto do qualquer outra pessoa. Eles estão em mais reuniões, visitam mais escritórios e conversam com mais colaboradores individuais do que qualquer outra pessoa. Eles tomam mais decisões ou as influenciam mais do que qualquer outra pessoa na organização. 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 bem- sucedido, as possibilidades de todos se comportarem da mesma maneira aumenta. Gerentes de todo tipo estão em posições similares de poder potencial, e existem poucos pontos de influência de mesmo valor na maioria dos ambientes de trabalho. Isso significa que se for possível cultivar as atitudes e idéias descritas até aqui, não há melhor lugar para fazer esses investimentos do que em líderes e gerentes. Isso não quer dizer que um gerente de projeto precisa ter a imagem carismática de herói que, com um simples gesto, pode liderar exércitos 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 idéia principal é que desde que ninguém 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. Não importa quantas idéias 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 aumentar a probabilidade e a velocidade de resultados positivos. Um mantra útil que tenho usado diariamente é “Faça 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 tornou- se 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.