_!..----fl

_ L----fll

A Arte do

1

roe _os ..

O'REILLYe Scott Berkun

Scott Berkun estudou ciência da computação, filosofia e design na Universidade de Carnegie Mellon. Contratado pela Microsol-i: em 1994, como engenheiro de usabilidade, trabalhou no Microsoft Office, Visual Basic e em outros produtos. Em 1995, tornou-se gerente de programas no projeto do Internet Explorer, liderando o design e desenvolvimento de vários recursos i1nportantes. Após a versão 5.0, trabalhou como gerente líder de programa nas equipes de desenvolvimento do Windows e do MSN. Scott tatnbém trabalhou no grupo de excelência e1n engenharia da Microsoft, ajudando outros profissionais na e1npresa e no setor a conhecer as práticas consagradas no desenvolvimento para a Web e de software. Ele minisrrou palestras e cursos em workshops e participou em várias formas de travessuras em d iversas conferências da indústria.

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.

Visite www.scottberkun.co1n para participar de fóruns de discussão sobre os tópicos deste livro e conhecer dezenas de outros ensaios e informações sobre como ajudá­lo a encher a prateleira (contar a outras pessoas sobre este livro pode ser uma ótima maneira de começar). Este é seu pri1neiro livro. Ele mora e1n algum lugar nas florestas ao leste de Seattle.

B513a Berkun, Scott A arre do gercncian1cnco de projetos I Scott Berkun ; tradução

Carlos Augusto Caldas de Moraes, Teresa Cristina Felix de Souza. -Porto Alegre : Bookn1an, 2008.

388 p. : il. ; 25 c1n.

ISBN 978-85-7780-170-1

1. lnfonnática - Gestão. 2. Projetos - Gestão. 1. Título.

CDU 004:658

Catalogação na publicaç.'io: Juliana Lagôas Coelho - CRB 10/1798

Scott Berkun

A Arte do

Gerenciamento de Projetos

Tradução: CAJ{LOS AUGUSTO CALDAS DE MORAES

l '"ERESA ClllS'flNA FELIX DE SOUZA

Consultoria, supervisão e revisão técnica desta edição:

HENRIQUE ]. BRODBECK Mestre em Engenharia

Professor do Instituto de Informática da UFRGS

2008

Obra originalmente publicada sob o título Making Things Happen: MllSterirzg Project Managernent

ISBN 978-0596-51771-7/0-596-51771-8.

Tradução publicada e vendida corn aucori1,ação da O'Reilly Media, lnc., proprietária dos respectivos direitos de publicação e venda.

Capa: Gustavo Demarchi Attc sobre capa original

Leitura final­Renato Merker

Supervisão editorial: Arysinha Jacques Affonso

Editoração eletrônica: AGE - A~sessoria Gráfica e Editorial Leda.

O logo da O'Reilly é urna marca regiscrada da O'Reilly Nledia, Inc. Muicos dos no1ne.s usados por fabricantes e vendedores para distinguir seus produtos são reivindicados con10 marcas comerciais. Nos locais em que aparecem, e quando a O'Reilly tinha conhecimento que se tratava de uma marca co1nercial, estes nomes escão impressos e1n !erra ntaiúscula ou com a !erra inicial em ntaiúscula.

Embora a preparação desce livro renha sido reali1Á1da con1 cautela, o editor e o autor não se responsa­biliza111 por erros ou on1issõcs ou por danos causados pelo uso das inforn1açõcs contidas nesta obra.

Reservados todos os direitos de publicação em língua portuguesa à ARTMED® EDITORAS.A.

(BOOKMAN® COMPANHIA EDITORA é urna divisão daARTMED® EDITORAS.A.) Av. Jerônimo de 01'nelas, 670 -Santana

90040-340 Porto Alegre RS Fone (51) 3027-7000 Fax (51) 3027-7070

É proibida a duplicação ou reprodução deste volume, no rodo ou e1n parte, sob quaisquer fonnas ou pol' quaisquer 1ncios (eletrônico, 1necânico, gravação, fotocópia, distribuição na Web e outros), sen1 permissão expressa da Editora.

SÃO PAULO Av. Angélica, 1091 - Higienópolis

O 1227-100 São Paulo SP Fone (11) 3665-1100 Fax (11) 3667-1333

SAC 0800 703-3444

IMPRESSO NO BRASIL PRINTED !1V BRAZIL

Agradecimentos

M ui tos agradecimentos a Mike Hendrickson, meu editor na O'Reilly, por me dar o sinal verde e 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: agradeço a Marlo"ve ShaeHer (editor de produção) por gerenciar o projeto deste livro, Mareia Friedrnan (designer gráfica), Rob Romano (ilustrador), Jeremy Mende (designer da capa), Audrey Doyle (revisor), Ellen Troutman-Zaig (indexadora) e Glenn Bisignani (gerente de marketing de produto).

As pessoas a seguir aceitaram ser entrevistadas ou apresentaram comentários sobre os prin1eiros rascunhos dos capítulos. 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, Sracia Scott, G•.vynne Scoddart, Terri Bronson, Barbara Wilson, Terrel Lefferrs, Mike Glass, Chromaric e Richard Grudman. Agradecimentos especiais a Ken Oye, meu primeiro gerente na Microsoft, e a Joe Belfiore, por me darem a oportunidade de participar no gerencian1ento de programas e por formarem n1inhas primeiras idéias sobre como deven1 ser os bons gerentes e líderes.

Agradecimentos adicionais, embalados individualrnente, para minha esposa, Jill "urso" Stutzrnan; Richard "grande paizinho" Grudman; os "cães de aluguel" (Chris "nosso herói" McGee, Mike "rodas as mudanças" Viola, David " l. d " $ db J " " M' P 1 ·1 " d k " s· ) garoto rn o an erg, oe gourmet 1rza, n1 stu po er rmon ; Vanessa "NYC" Longacre; Bob "fazendo a Web funcionar" Baxley; e para as boas pessoas em gnostron, unhinged e pm-clinic (da clínica de geren tes de projetos [GP]). Agradecimentos gerais à própria idéia do universo; à. palavra papaya; às grandes florestas e grandes árvores; às pessoas que continuam bobas, curiosas e divertidas muito além de suas idades; à letra Q e ao número 42. Um pacote com o conteúdo Obrigado ao sistema da biblioteca de King County e a todos os bibliotecários de rodos os lugares. O programa de empréstimos lnterlibrary foi uma bênção. Obrigado, pessoal.

Os músicos a seguir mantiveram minha sanidade durante as longas horas ao teclado: White Scripes, Palomar, Aimee Mann, The Clash, Johnny Cash, Social Distortion, Rollins Band, Sonny Rollins, Charles Mingus, Theloneous Monk, Breeders: Last Sp!ash, AudioSlave, MC5, Chris McGee's os melhores rnixes, Jack Johnson, Patty Griffin, Akiva, Flogging Molly, Sinatra, Beatles,

VI AGRADECIMENTOS

Bruce Springsteen, PJ Harvey, Radiohead, Ramones, Weezer, Tom Waits, Ali Girl Sumn1er Fun Band, Best of Belly, Magnetic Fields, Beth Orton, Elliot S1nith e Nick Cave e os Bad Seeds.

Nenhum gerente de projeto foi lesado na confecção deste livro. Mas infelizmente, Burch, nosso cachorro, faleceu na fase da produção final. Burch, descanse em paz, 1991-2004. Ele se deitava junto aos meus pés, enquanto várias idéias e páginas contidas neste livro começavam a surgir. Bom cachorro, o Butch. Sentiremos a sua falta .

Prefácio

VIII PREF1\C10

Minha palavra favorita é como. Corno isro funciona? Corno isro foi consrruído? Como fizeram isso? Sempre que vejo algo interessanre, faço rnuiras perguntas corn essa palavrinha, pequena mas poderosa. E a maioria das respostas fala de con10 as pessoas aplican1 sua inteligência e sabedoria, e não do seu conhecin1ento de tecnologias ou teorias específicas.

Ao longo de anos consrruindo coisas e co1nparando nlinhas experiências com as de outros gerentes, programadores e designers, desenvolvi convicções e conclusões sobre como gerenciar projeros de modo eficienre. Este livro é um somat6rio dessas idéias. Ele abrange propostas para liderar equipes, trabalhar com idéias, organizar projetos, gerenciar agendas, lidar com políticas e fazer coisas acontecerem, mesmo diante de grandes desafios e situações injustas.

Apesar do título abrangente deste livro, a maior parte de minha experiência profissional tem origem no setor técnico e, particularmente, na Microsoft Corporation . Trabalhei lá de 1994 até 2003, liderando equipes de pessoas em projetos como o Internet Explorer, Microsoft Windows e MSN. Trabalhei alguns anos no grupo de excelência e1n engenharia da Microsoft. Enquanto estive lá, fui responsável por ensinar e dar consultoria a equipes na ernpresa inteira, e era freqüenremente solici tado a rninistrar palestras em conferências públicas, corporações e universidades. A 1naioria dos conselhos, lições e histórias contidos neste livro procede dessas experiências.

E1nbora eu tenha experiência em desenvolvin1ento de software e para a Web, escrevi este livro de n1odo an1plo e inclusivo, citando referências e técnicas externas aos do1nínios da engenharia e do gerenciamento. Valorizo aqui as pessoas pertencentes ao nlundo en1presarial en1 geral. Estou certo de que os desafios de organizar, liderar, criar designs e enrregar o trabalho têm muito em comum, independentemente do domínio. Os processos relacionados à fabricação de fornos, de arranha-céus, automóveis, sites Web e produtos de software co1npartilham muitos dos 1nesmos desafios, e este livro versa basicamente sobre co1no superá-los.

Diferentemente de outros livros sobre como comandar projetos e equipes, este livro não imputa qualquer grande teoria ou filosofia supostamente inovadora. Em vez disso, apostei na pr-aticidade e diversidade. Em 1ninha opinião, os projetos dão bons resultados quando é aplicada a combinação cena de pessoas, talentos, atitudes e táticas, a despeito de sua origem ou (fàlra de) pedigree. A esrrucura desce livro é a 1nais sensível possível: enfoco os principais desafios e situações e dou conselhos sobre corno lidar com eles de modo eficienre. Apostei muito em escolher os remas cercos e dar bons conselhos sobre eles, acima de rodos os outros aspectos. Espero que você cambé1n ache que fiz a 1nelhor escolha.

Quem deve ler este livro

A 1nelhor 1naneira de saber se este livro serve para você é ir para o Su1nário, escolher um tema de seu interesse e examinar o que falo sobre ele. Geralmente, não confio n1uito nos prefácios e recon1endo isso a você: eles raramente cên1 o mesmo estilo ou ín1peto do restante do livro. Mas enfim, aqui vamos nós.

O livro é mais indicado para as pessoas que se enquadram em uma ou nlais das seguintes categorias:

PREFÁC IO IX

• Líderes e gerentes de equipe experientes. Esce livro é adequado para quem dese1npenha u1na função de liderança, de modo fonnal ou informal, em qualquer ripo de projero. Os exe1nplos são oriundos do desenvolvi1nenro de software, mas 1nuiros conceitos são faci l1nence aplicáveis a outros tipos de trabalho. Você pode ser o líder oficial da equipe ou apenas um dos membros mais experientes. Ainda que co11heça bem alguns cen1as do livro, a abordagem direta e prática aqui urilizada o ajudará a esclarecer e aprimorar suas opiniões. Mesmo se discordar das minhas opiniões, terá tuna base transparente con1 a qual trabalhar, ao aperfeiçoar e melhorar a sua perspectiva.

• Novos líderes de equipe e gerentes. Se você examinar os te1nas listados no Sumário, encontrará uma visão geral sólida de tudo o que os líderes e gerentes realmente fàzem nos projetos. Cada capítulo discorre sobre falhas e erros comuns cometidos até mesmo por pessoas experientes, com as respectivas explicações, desde os motivos pelos quais acontecem e as rácicas que pode1n ser usadas para evitá-los ou recuperar-se deles. O livro propicia uma visão e noção básica mais abrangente de suas novas responsabilidades, e 1nodos mais inteligentes de gerenciá-las. Por tratarem de grandes temas, geralmente a 1naioria dos capítulos contém referências comentadas às fontes mais co1npletas.

• Progra1nadores e testadores individuais, ou outros colaboradores do projeto. Este livro vai melhorar sua percepção sobre aquilo para o que você esrá contribuindo, e quais abordagens e idéias pode usar para ser eficiente e feliz ao agir assi1n. Se você nunca se perguntou por que os projetos mudam de rumo com canta freqüência ou parecem ser gerenciados de modo deficiente, este livro o ajudará a entender as causas e soluções. No mínimo, ao ler este livro, você enquadrará suas contribuições individuais em um contexto maior, e aumentará a probabilidade de que seu trabalho fàça un1a diferença (e de que você continue sadio ao fuzer isso). Se cem interesse em gerenciar ou liderar equipes, algun1 dia, este livro o ajudará a examinar o que realmente significa tudo isso e se cem gaba.rito para essa fuçanha.

• Estudantes de administração de empresas, design de produtos ou engenharia de software. Emprego a palavra estudantes no âmbito mais abrangente: se você tiver interesse pessoal nesses temas ou se estiver estudando esses assuntos formalmente, este livro será de grande valia. Diferentemente da maioria das abordagens de livros texto sobre esses reinas, esce livro escá baseante focado em situações e narrativas. As experiências e histórias são reais, e represenra1n a base das lições e rácicas: não o contrário. Evito deliberadamente fazer co1nparações entre diferences assuntos acadêmicos porque, en1 1ninha experiência, isso não ajuda os projetos ne1n contribui para perceber a realidade (o universo não é dividido da 1nesn1a maneira con10 as universidades costun1an1 ser). En1 vez disso, este livro combina a teoria cotnercial, psicologia, táticas de gerenciamento, processos de design e engenharia de software de modo a oferecer o aconselha1nento necessário sobre os remas em destaque.

O que eu supus sobre você ao escrever este livro

• Você não é bobo. Acho que se escolhi os capítulos cercos e os escrevi ben1, você não precisará que eu gaste tempo construindo lencamence esrrucuras elaboradas de infonnações. En1 vez disso, eu chegarei ao ponto e investirei meu cempo

X PREFÁC IO

exaramente aí. Presumo que você é uma espécie de parceiro - com u1na experiência talvez 1naior, menor ou diferente - que passou por aqui para obter alguns conselhos.

• Você é curioso e pragmático. Extraí exe1nplos e referências de várias disciplinas e acho que você daní importância a rrazer lições externas ao desenvolvi1nenro de Web e sofavare. Isso não atrapalhará, mas indicações de mentes curiosas virão à tona, às vezes só em notas de rodapé. Presumo que você queira aprender, que esteja receptivo a idéias diferentes e reconheça a importância das opiniões ben1 en1basadas - mesmo que não concorde con1 elas.

• Você não gosta de jargões nem de grandes teorias. Não acho que os jargões e grandes teorias ajudam na aprendizagem e na aplicações de novas informações. Evito-os, exceto quando indica1n um caminho para informações úteis ou oferecem uma estrutura que será útil 1nais adiante.

• Você não leva muito a sério a si mesmo, o software ou o gerenciamento. Pode ser desagradável ler assuntos relacionados ao desenvolvi1nento de sofavare e gerenciamento de projetos. Mesmo que este livro não seja um ro1npante cômico ou uma sátira (e1nbora u1n livro de Mark Tv.rain ou David Sedaris com explicações de engenharia de software possa ser), não hesitarei em fazer piadas às 1ninhas custas (ou às custas de alguém) ou usar exen1plos com explicações

A • co1n1cas.

Como usar este livro

Escrevi este livro levando em conta as pessoas que gostam de saltar de um lado para outro e ler capítulos soltos. Contudo, existe uma certa vantagem em ler o livro em seqüência; alguns conceitos posteriores dependem dos anteriores e o livro segue rigorosamente a ordem cronológica da maioria dos projetos. É evidente que você nunca saberia disso, a menos que o lesse do início ao fim, de modo que se preferir saltar, terá que confiar em mim quanto a esse aspecto. O primeiro capítulo é o mais abrangente do livro e tem um tom mais denso do que os demais. Se estiver curioso em saber por que deve se importar com o gerenciamento de projetos ou que outras pessoas iinportantes disseram isso, então você deveria cercamente se dar u1na chance. Se tentar e odiar, recomendo-lhe experimentar outro capítulo anres de abandonar o barco.

Todas as referências e URLs listadas no livro, assim co1no ourras noras e comentários, pode1n ser encontrados online, e1n wivw.scottberkun.cornlbookslartofprn/. O site ten1 un1 fórum de discussões e outros recursos para que1n estiver interessado e1n ir além dos remas desce livro.

Como você foi suficientemente inteligente e paciente para ler esta introdução inteira, presu1no que se apressará nas outras 1necânicas de leitura do livro (números de página, noras de rodapé e rudo o mais) e não vou mais atrapalhá-lo.

Saudações, - Scott Berkun Redmond, WA

Sumário

1 U1na breve história do gerencian1ento de projetos (e por que é importante) 13

PARTE 1 PLANOS 31

2 A verdade sobre os cronogramas 33 3 Como resolver o que fazer 53

4 Redigindo a visão eficiente 79 5 De onde surgem as idéias 99 6 O que fazer com as idéias quando você as tiver 121

PARTE 2 HABILIDADES 141

7 Escrevendo boas especificações 143 8 Como tomar boas decisões 163 9 Comunicação e relacionamentos 183

10 Como não incomodar as pessoas: processo, email e reuniões 199

11 O que fazer quando as coisas dão errado 219

PARTE 3 GERENCIAMENTO 245

12 Por que a lidera11ça é baseada na confiança 247 13 Como fazer as coisas acontecerem 265 14 Estratégia de meio~jogo 285 15 Estratégia de final de jogo 307

16 Poder e política 333

Créditos das fotos 357

Notas 359

Bibliografia comentada 367 Índice 373

Capítulo 1

Uma breve história do gerenciamento de projetos

(e por que é importante)

14 A AR"íE DO GERENCIAMENTO DE PROJETOS

E 1n 1ntlitas organizações, o líder de um projeto não cem o cargo de gerente de projeto. Tudo be1n. Todos os programadores, gerences, líderes de equipe, analiscas e designers gerencia1n projetos no seu trabalho diário, estejam eles trabalhando sozinhos ou e1n equipe. Por enquanto, essas distinções não são in1portantes. Minha intenção neste livro é entender o que torna um projeto bem-sucedido e como as pessoas que l ideram projetos bem-sucedidos o fazen1. Essas idéias e escracégias principais não requere1n hierarquias, cargos ou métodos específicos. Portanto, se você trabalha em um projeto e cem algu1na 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.

Este livro fo i criado para ser útil de três maneiras: como uma coleção de ensaios focados em tópicos, como uma narrativa única e ampliada e como uma referência para situações comuns. Cada capítulo apresenta un1a tarefa diferente de aho nível, fornece uma estrutura básica e oferece escrarégias e rácicas para concluir a tarefa com êxito. Entretanto, neste capítulo de abertura, adoto um enfoque diference: exisce1n crês tópicos amplos que tornarão o restante do livro 1nais fácil de acompanhar, e os apresentarei agora.

O primeiro é um breve histórico dos projetos e por que devemos aprender com o que os outros têm feito. O segundo são alguns conceitos sobre os diferences tipos de gerenciamento de projetos, incluindo algumas observações da minha experiência de trabalho na Microsoft. E o terceiro é um exa1ne dos desafios subjacentes envolvidos no gerenciamento de projeto e con10 eles pode1n ser superados. En1bora esses pontos sejam úteis 1nais carde, eles não são necessários para os próximos capírulos. Portanto, se você achar a abordagem desce primeiro capítulo nluico abrangente, sinta-se à vontade para prosseguir para o Capítulo 2 e o restante desce livro.

Usando a história

O gerencian1ento de projetos, como uma idéia, daca de muito tempo. Se você pensar e1n 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 sofauare 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 cenca melhorar o n1odo 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 usa1nos co1no escopo para o conhecimento útil está 1nuiro mais próxi1na do dia de hoje do que deveria estar.

A história dos projetos de engenharia revela que a maioria dos projetos tem forces se1nelhanças. Eles cê1n requisicos, projetos (designs) e restrições. Eles dependem da co1nunicação, da ro1nada de decisão e de combinações de pensamento lógico e criativo. Os projetos norinalmente envolvem uma cronogra1na (schedule), um orça1nenco e un1 cliente. O mais i1nportance, a tarefa central dos projetos é combinar os trabalhos de diferences pessoas em

ÜM.A BREVE H1STÓIUA DO GERE NCIAMENTO DE PROJETOS 15

um codo singular e coerence que será úcil para as pessoas ou cliences. Seja u1n projeco desenvolvido a parcir do HTML, do C++ ou de ci1nenco e aço, há se1npre u1n conjunco principal de conceicos irrefucáveis que a maioria dos projetos deve con1parrilhar.

Minha curiosidade sobre as forn1as de liderar os esforços de desenvolvimento de software e Web n1e levou a um sério inceresse por esse conjunco principal de conceitos. Escudei outros campos e setores para ver como eles solucionara1n os desafios cencrais para seus projecos, para que pudesse aplicar soluções comparáveis e1n 1neu próprio trabalho. Imaginei como projetos como o Telescópio Espacial Hubble e o Boeing 777 fora1n 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 Acenas, os líderes de projeto planejaram e estimaram suas construções da. mesma forma que os 1neus progra1nadores o fazern? Quais foram as diferenças interessantes e o que pode ser aprendido exarninando essas diferenças?

O que dizer dos editores de jornais, que organizarn e planeja1n a produção diária das infonnações? Eles escava1n fazendo 1nulti1nídia (i1nagens e cexco) 1nuico antes dos primeiros sonhos de publicação na Web. E sobre a produção de filines de longa metragem? O lançamento da Apollo 13? Examinando essas questões, fui capaz de perceber como liderar equipes de projeco de uma nova 1naneira.

Entrecanto, essas perguntas ne1n sen1pre cinham respostas óbvias. Eu não posso pro1necer que você entregará o resultado mais cedo ou planejará 1nelhor porque as infonnações desce livro foram influenciadas por essas fontes. Mas eu sei que quando recornei ao n1undo do software após pesquisar em vários lugares, meus processos e ferramencas me pareceram diferences. Enconcrei maneiras de modificá-los que antes não cinha considerado. No rodo, percebi que muicas 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 ran10.

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

l. O gerenciamento de projeto e o desenvolvimento de software não são artes sagradas. Qualquer crabalho da rnoderna engenharia é urna nova entrada no longo hiscórico da criação. As tecnologias e habilidades podem mudar, mas grande parte dos principais desafios que dificulcam a engenharia pennanece. Todas as coisas, quer linguagens de progra1nação ou metodologias de desenvolvimento, são únicas de alguma maneira, 1nas derivadas de oucras. Mas se quisennos reutilizar o máxixno possível de conhecin1ento do passado, precisamos cer cerceza de que esca1nos abercos para examinar ambos os aspeccos - o único e o derivado - em co1nparação com o que veio ances.

2. Quanto mais simples a visão do que você faz, mais poder e foco terá ao executá-la. Se pudermos mancer periodica1nenre uma visão si1nples do nosso rrabalho, poderemos enconcrar comparações úreis com outras maneiras de realizar as coisas que existen1 em nosso redor. Existirão 1nais exemplos e liçóes da história e das indúsrrias modernas que pode1n ser usados, comparados e contrastados. Isso é similar ao conceito definido pela

16 A AJ,-íE DO GERENCIAMENTO DE PROJETOS

palavra japonesa shoshin, que significa 1nente do iniciante1 ou mente aberta, uma parte essencial de 1nuitas disciplinas de artes marciais. Permanecer curioso e aberto é o que torna o crescimento possível e é necessário praticar para 1nanter essa at itude. 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 n1elhores atletas, escritores, progran1adores e gerentes tendem a ser aqueles que sen1pre vêem o que faze1n como si1nples em sua essência, nlas, simultaneamente, difícil. Lembre-se de que simples não é o rnes1no que fácil. Por exemplo, correr uma rnaratona é urna coisa sirnples. Você co1neç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 e gerenciamento também são difíceis, mas sua natureza - executar tarefas de uma maneira específica para atingir uma mera específica - é simples.

Eu farei alusão a esses conceitos em rnuicos capítulos. Portanto, se fizer referências que estejarn fora dos limites convencionais do desenvolvi1nento de software, espero que você entenda minhas razões para isso. E quando eu sugerir que uma to1nada de decisão ou um agendamento são simples funções de gerência, assu1nirei que você sabe que isso não sugere que essas coisas são fáceis de fazer.

Aprendendo com os erros

"Os seres hit1nanos, que são pratica1nente os únicos (entre os animais) que têm a httbilidade de aprender com a experiência alheia, são também notáveis em sua

aparente 1ná vontade para Jazer isso. "

- Douglas Ada1ns

U1na questão siinples que surge no estudo da história dos projetos é esta: por que alguém concorda e1n 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 so1nos pagos para fuzer 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 tenninam dessa maneira2) rodos os dias, pouco é feiro 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 calvez seja apenas fàlta 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 Hurnan: The Role of Failttre in Successfi1! Design (Vinrage Books, 1992), Henry Petroski explica corno ocorreram descobertas na engenharia como resulcado de falhas. Em parte, isso acontece porque as falhas nos forçam a prestar atenção. Elas nos obrigain a reexaminar as pre1nissas que havíamos esquecido que existiam (é difícil fingir que tudo está bem quando o protótipo pegou fogo). Como Karl Popper3 sugeriu, há apenas dois tipos de

UM.A ÊREVE H 1STÓIUA DO GERENCIAMENTO DE PROJETOS 17

reorias: as que esrão erradas e as que esrão incompleras. Se1n os fracassos, nós esquecemos arroganre1nenre que nossa co1npreensão das coisas nunca é rão complera quanro pensa1nos ser.

O artifício, então, é aprender o n1áxin10 possível com as fa lhas de outras pessoas. Devemos usar suas experiências para iníluenciar o futuro. Embora os detalhes superficiais da falha possam ser totalmente diferences de projeto para projeto, as causas básicas ou as ações da equipe que levaram a elas poderão ser plenamente rransferíveis (e evitáveis). Mes1no em nossos próprios projetos, precisamos evitar o hábito de fugirmos e nos escondermos de nossas falhas . Em vez disso, devemos vê-las con10 oportunidades para aprender algo. Que fatores contribuíram para que isso acontecesse? Quais deles seriam mais fáce is de minimizar ou eliminar? De acordo com Petroski, o conhecimento real obtido a partir da 1-àlha real é a mais poderosa fonte de progresso que temos, desde que tenhamos a corage1n de exami nar cuidadosamente o que aconteceu.

Talvez seja por isso que a Boeing, uma das maiores empresas de projeto e engenharia de aeronaves do inundo, n1antenha um livro negro de lições aprendidas a partir de tàlhas de projeto e engenharia4• A Boeing 1nanté1n esse documento desde que a empresa foi criada e o utiliza para ajudar os novos projetistas a aprenderem co1n as tentativas do passado. Qualquer organização corn esse tipo de orientação não apenas aumenta suas chances de projetos bem­sucedidos, con10 cambén1 ajuda a criar u1n ambiente onde se pode discutir e confrontar as falhas aberta1nente, en1 vez de negá-las e escondê-las. Parece que os desenvolvedores de software precisa1n 1nanter seus próprios livros negros.

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

lJm 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 e1npatia por coisas que parece1n tão diferences do 1nodo co1no o trabalho é realizado nos dias de hoje. Uma alternativa é fazer comparações co1n tipos diferentes de projetos 1nodernos. E1nbora não tenha o 1nes1no impacro da hiscória da engenharia, isso pennire observações e experiências pessoais. Co1n freqüência, ver as coisas na fonre é a única maneira de fornecer infonnações suficienres para fazer conexões entre idéias diferences.

Co1no exemplo, eu conheço u1n desenvolvedor para a Web que acredita que seu trabalho é diferente de tudo o que exisce na história do universo. Ele sente que como o desenvolvimento para a Web exige que ele come 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 tarefi1s 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 renho 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 co1no o que você escava fazendo.

18 A ARºíE DO GERENCIAMENTO DE PROJETOS

Eu sugeri a esse amigo desenvolvedor que desse urna volca pela cozinha do seu rescaurance favorico em um dia ern que ele escivesse cheio. Por muicas razões, é inceressance ca1ninhar pelas cozinhas (consulce o excelente livro de Anchony Bourdain, Kitchen Corrfidential, Ecco, 2001), mas meu ponco específico era sobre produtividade. A primeira vez que algué1n 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 diferences pedidos em diferentes escados de conclusão e correndo entre vários conjuncos d e queimadores em cantos opostos da cozinha, enquanto os garçons correm para lá e para cá, encregando 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ún1ero de pedidos que saem a cada segundo, novos pedidos entram corn a mesma velocidade. Alguns pedidos são enviados de volta ou, como em rnuicos projetos de software, exigern 1nodificações personalizadas e de úlci1na hora (a 1nesa 1 tern incolerância a laccose; a 1nesa 2 precisa de molho separado etc.). É maravilhoso observar cozinhas grandes e atarefadas. Apesar de parecerem caócicas à primeira visca, as cozinhas grandes funcionam com urn nível de intensidade e precisão que deixarn a maioria das equipes de desenvolvirnenco 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 (oucra profissão para o introspectivo considerar). E1nbora a equipe de cozinha crabalhe e1n urna escala 1nenor e menos celebrada do que um gerente de equipe de desenvolvi1nento de software, sua intensidade diária é incomparável. Se você duvida de mim, na próxima vez em que esciver em um restaurance cheio, pergunte ao garçom se é possível dar uma espiada na cozinha. Talvez ele não pern1ita, mas se permitir, você não ficará desapontado. (Alguns restaurantes e bares nlais modernos têm cozinhas abertas. Se encontrar um, sente-se o mais próximo possível dela. Depois, acompanhe uma pessoa por alguns rninutos. Observe corno os pedidos são colocados, controla.dos, construídos e entregues. Se você for num dia em que ele estiver cheio, pensará de maneira. diference sobre como os erros de software são registrados, rastreados e corrigidos.)

Outra lição de carnpo inceressante no gerenciamento de projetos vem das salas de emergência dos hospitais. Eu assisci no Discovery Channel e no PBS como pequenas equipes de médicos, enfenneiras e especialistas experientes trabalha1n juntos como uma equipe de projeto para tratar de situações rnédicas diversas e algumas vezes bizarras que surgem nas porcas dos hospitais. Não surpreende que renha sido a profissão que inventou o processo de criagem, u1n cenno comu1nente usado e1n projetos de software para priorizar problernas e defeitos (discucido no Capículo 15).

O ambiente 1nédico, especialmente em sicuações de rr-auma, oferece uma con1paraçã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 Ga,,vande escreveu em seu excelente livro, Complicatíons: A Surgeon's Notes on an lmperfect Science (Picador USA, 2003):

UM.A ÊREVE H1STÓIUA DO GERE NCIAMENTO DE PROJETOS 19

Nós espera1nos que a medicina seja um campo regular de conheciinenco e procedi1nenco. Mas não é. Ela é uma ciência imperfeica, um e1npreendi1nenro de conhecimenco e1n conscance mudança, infonnações incercas, indivíduos passíveis de Í.'llhas e ao mesmo cen1po "prontos para o combate". Há ciência no que fazemos, mas tan1bém hábito, intuição e às vezes siinples suposições. O vácuo entre o que sabemos e o que almejamos persiste. E esse vácuo complica tudo o que fazemos.

Cinema

Desenvolvimento de software

Desenvolvimento para web

Sala de emergência

Cozinha

Pré-produção J> Produção J> Pós-produção J>

Requisitos '> 0

Design '> 0

Codificação '> ==Te=st:lle "> Pré-produção'> Produção '> Manutenção '> Avaliação'>

FIGURA 1-1 . Em princípio, muitas disciplinas têm processos similares. Todas elas dedicam tempo para planejar, 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, e muitos oucros do livro esclarecedor de Ga\vande, permanecem verdadeiros para o desenvolvin1ento de software. Fred Brooks, no livro clássico sobre engenharia de software, The Mythical Man-Month, faz comparações si1nilares entre equipes de cirurgiões e equipes de programadores. E1nbora 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 diferences equipes de pessoas precisam enfrentar.

A função principal do gerenciamento de projetos

O gerenciamento de projeros pode ser uma profissão, uma rarefa, 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 u1na pequena área de u1n grande projeto. Dependendo de como u1na 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 alcamence definida ("Vincenc, Claude e Raphael são gerences de projeco em cempo incegral'') .

20 A AR-íE DO GERENCIAMENTO DE PROJETOS

N esce livro, usarei principalmence o rermo gerente de projeto, ou GP, para fazer referência a quem esrá envolvido na atividade de liderança e gerenciamento de projeros. Por atividade de gerenciamenco de projeco quero dizer liderar a equipe na solução do projeco (planejainenro, prograinação e reunião de requisitos), oriencar o projeto no trabalho de design e desenvolvin1ento (comunicaç,'io, tomada de decisão e estratégia de nleio de jogo) e executar o projeto até a conclusão (liderança, gerencian1ento das crises e estratégia de final de jogo).

Se esse cipo de crabalho é menos escrucurado no seu mundo, basca craduzir gerence de projeto ou GP para significar "pessoa que execuca as carefas de gerenciamento do projeto, e1nbora 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 desce livro é totalmente indiferente para elas. O conteúdo deste livro é menos sobre os títulos e formalizações de cargos e mais sobre executar tarefas e fazê-las acontecer. Mas, para 1nanter meu texto o 1nais sin1ples possível, usarei o termo gerente de projeto ou GP.

Às vezes, a ausência de u1n gerente de projeco exclusivo funciona be1n. Os progra1nadores e seus chefes mancê1n seus cronogra1nas e planos de engenharia (se houver) e um analista de negócios ou pessoa de marketing faz o planejamento ou gerenciamenco de requisicos. Tudo o mais que poderia ser qualificado co1no u1n gerencia1nenro de projeco simples1nenre é distribuído pela equipe. Talvez as pessoas da equipe tenhan1 sido contratadas por seus interesses que vão além de escrever un1 código. Elas poderian1 não se dedicar ao planeja1nento inicial, design de interface de usuário ou estratégia de negócios. Trabalhar dessa maneira pode acarretar otimizações significativas. Desde que rodos queiram pagar o preço da responsabilidade por 1nancer essas coisas juntas e distribuir por roda 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 fucções adversárias podem ser desenvolvidas em torno das funções de engenharia e negócios, recardando o progresso e frustrando todas as pessoas envolvidas. Considere que nas salas de emergência de u1n hospical, u1n médico come a liderança na decisão do curso de ação para um pacience. Isso apressa muicas decisões e dá clareza às funções que rodos os membros da equipe de trauma esperam desempenhar. Se1n esse ripo de autoridade clara para problemas de gerencia1nento de projeto, as equipes de desenvolvimento podem encontrar dificuldades. Se não houver u1na pessoa co1n uma funç,'ío clara para liderar a triagetn de erros ou alguém dedicado a rastrear os problemas de cronogra1na e sinalização, essas tarefas poderão ficar perigosamence para crás das aàvidades de programação individuais.

Embora eu ache que muitos dos melhores programadores encende1n 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.

UM.A BREVE H1STÓIUA DO GERENCIAMENTO DE PROJETOS 21

Gerenciamento de projetos e programas na Microsoft

A Microsoft enfrentou dificuldades no final dos anos 80 na coordenação dos esforços de engenharia con1 a área de 1narketing e negócios de cada divisão (alguns poderão dizer que isso ainda é un1 proble1na para a Microsoft e 1nuitas outras empresas). Un1 homem sábio chamado Jabe Blumenrhal percebeu que poderia existir tuna tarefa especial onde um indivíduo estivesse envolvido com essas duas funções, desen1penhando un1 papel de liderança e coordenação. Essa pessoa estaria envolvida no projeto desde o primeiro dia do planejamento aré o último dia de reste. 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 ben1 esse papel, ele teria de gostar de passar seus dias executando tarefas tão variadas quanto escrever especificações, rever planos de 1narketing, gerar cronogra1nas de projeto, liderar equipes, tàzer planeja1nento estratégico, executar rriage1n de erros/fi1lhas, cultivar a 1noral da equipe e fàzer rudo o que precisa ser feito e que ningué1n está fazendo (bem). Esse novo papel na Microsoft fo i chamado de gerente de programa. Nem rodos na equipe se reportariam diretamente a ele, mas o gerente de programa reria autoridade para liderar e orientar u1n projeto. (Na teoria de gerencia1nenco, essa é, grosso modo, a idéia de u1na organização 111atricial5, 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 progratnador ou testador ind ividual poderia cer dois relacionamentos hierárquicos - u1n principal para seu papel funcional e um secundário, 1nas force, para o projeto no qual trabalha.)

Jabe desempenhou esse papel em um produto denominado Mulriplan (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 en1 todos os corredores da Microsoft havia muita alegria. Após muitos memorandos e reuniões, a 1naioria das equipes na e1npresa adotou lentamente a função. Não i1nportam os produtos resultantes, bons ou ruins, a idéia faz sentido. Ao definir um papel para um genel"<1lista no nível de linha, que não renha 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 roda a minha carreira na Microsoft e trabalhei em equipes de produto que incluíram o Internet Explorer, MSN e Windows. Gerenciei també1n equipes de pessoas que desempenhava1n esse papel.

Até hoje, não sei de 1nuitas e1npresas que tenha1n ido cão longe na redefinição e formalização de gerencian1ento de projeto. Era raro, en1 minhas interações co1n outras finnas de desenvolvimento de software e Web, encontrar algué1n que desempenhasse u1n ripo de função si1nilar (eles era1n engenheiros ou adminiscradores, ou em raras ocasiões, designers) . Muitas companhias usan1 estrutu ras de tin1e para organizar o trabalho, 111as poucas definen1 os papéis que atravessan1 deliberadamente as hierarquias de engenharia e negócios. Hoje existem mais de 5.000 gerentes de progran1a na Microsoft (en1 mais de 50.000 funcionários no torai) e embora a força da idéia tenha sido diluída (e em muitos casos 1nal-utilizada), o espírito principal

22 A Ai,-íE DO GERENCIAMENTO DE PROJETOS

dela ainda pode ser enconcrado em 1nuicas equipes e grupos dencro da e1npresa.

Mas, independence do que é dico no 1neu carcão de visicas, ou em que hisr6ria da Microsofr você decide acredicar ou ignorar, 1ninhas funções diárias como um gerence de programa eram funções de gerenciamento de projeto. E1n termos mais simples, isso significava que eu tinha a responsabilidade de tornar o projeco - e quem quer que escivesse contribuindo para ele - tão bem-sucedido quanto possível. Todos os capírulos deste livro reflece1n as rarefas principais envolvidas nesse procedimento, desde o planejamento inicial (Capítulos 3 e 4), à escrita específica (Capículo 7), à tomada de decisão (Capículo 8), ao gerenciamento e à liberação da implementação (Capítulos 14 e 15).

Sob essas habilidades, surgem cercas 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 enconcrar bons gerences de projeto porque eles precisam 1nancer u1n equilíbrio de atitudes. Ton1 Peters, no seu ensaio "Pursuing the Perfect Project Manager"6, chan1a essas atitudes conflitantes de paradoxos ou dilen1as. Esse nome é apropriado porque situações diferentes exigem co.mportamento diferente. Isso significa que um gerente de projeto precisa não apenas estar ciente dessas peculiaridades, mas tambén1 desenvolver insc.inros para saber quais são apropriados e1n que ocasiões. Isso contribui para a idéia de gerenciamenco 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üente1nente rêm grande satisfação pessoal co1n seu trabalho. É compreensível que renham u1n alto investimenco e1nocional no que estão fazendo e, para muitos, essa conexão e1nocional é que os permice 1nancer a incensidade necessária para ser eficience. Mas, ao rnesrno cempo, os gerences de projeco devem evitar colocar seus inceresses à frence do projero. Eles devem delegar tarefas importantes ou divertidas e cornparrilhar elogios e prê1nios com a equipe inteira. Por rnais que o ego possa ser um combustível, um gerente de projeto ren1 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 gerence de projeto cem de ser seguro e obstinado o baseante para controlar e forçar certas ações para un1a equipe. Entretanto, o objetivo geral deve ser evitar a necessidade dessas situações excremas. Um projero bem gerenciado deve criar u1n ambienre 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 1nuico o conhecido. Co1no discucire1nos nos Capítulos 5 e 6, a ambigüidade

UM.A ÊREVE H1STÓIUA DO GERENCIAMENTO DE PROJETOS 23

concrolada é essencial para que boas idéias surjam e um gerence de projeco deve respeicá-la, se não gerenciá-la. Mas em oucros tnomencos, parcicularmence nas fases finais de um projeco, 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 111edíocre ou rápida é suficiente. (Consulte a seção "Encontrando e ponderando as opções" no Capítulo 8.)

• Verbal/escrito. En1bora a nlaioria das organizações de desenvolvimento de software sejam centradas na co1nunicação por e?nails, as habilidades verbais são importantes para o gerencian1ento de projetos. Haverá sempre reuniões, negociações, discussões nípidas e sessões de brainstorn1ing, 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 corna1n 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 co1nplexidade/patrocinar a simplicidade. Muitas pessoas são víti1nas da con1plexidade. Quando elas se depara1n co1n un1 co1nplexo desafio organizacional ou de engenharia, se perdem en1 detalhes e esquecern do principal. Outras negan1 a con1plexidade e tomam decisões erradas porque não co1npreenden1 co1npletamente as sutilezas envolvidas. O equilíbrio aqui escá e111 reconhecer qual visão do projeto é 1nais útil para o problema ou qual decisão é conveniente e alternar confortavelmente entre elas ou mantê-las em mente, ao mes1no 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, sen1 nlinimizar as con1plexidades 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 ern algumas situações, a irnpaciência traballut contra o projeto. Algumas atividades políticas, burocráticas ou inrerorganizacionais são inevitáveis escoadouros de ce1npo: alguérn cem 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 deve1n desenvolver.

• Coragem/medo. Um dos grandes enganos da cultura americana é achar que corajosos são aqueles que não sentem n1edo. Isso é u1na mentira. Corajosos são aqueles que sentem n1edo, n1as decidem agir de qualquer maneira. Un1 gerente de projeto precisa ter um grande respeito por rodas as coisas que possam dar errado e vê-las como totalmente possíveis. Mas ran1bén1 precisa corresponder esse respeito com a coragen1 necessária para assumir grandes desafios.

• Crédulo/cético. Não há nada mais poderoso para o moral de un1a 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

24 A Al'ºíE DO GERENCIAMENTO DE PROJETOS

rempo, exisce a necessidade de um cerco cecicismo (não cinismo) sobre como as coisas escão índo e na maneira co1no escão sendo execucadas. Algué1n rem que invescigar e quesrionar, expor suposições e rrazer as questões difíceis à luz. O equilíbrio está en1, de alguma maneira, fazer perguntas e desafiar as suposições de outros vigorosan1ente, sem abalar a confiança da equipe no que ela está fazendo .

Con10 Peter destaca no seu ensaio, é muito raro enconrrar 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 n1anter 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, 1nais tarde), ela vale como referência. O exa1ne dessa lista de forças conflitantes, 1nas necessárias, pode ajud;1-lo a recuar, reconsiderar o que você escá fazendo e por que e tomar decisões 1nais inteligentes.

Pressão e distração

Un1 medo dos novatos no gerenciamento de projetos é que o êxito exige mudança. Novos projetos são criados com a inrenção de alterar o esrado do mundo, 1nodificando, construindo ou destruindo algo. Manter o status quo - a menos que seja o objetivo explíciro, por algu1na escranha razão - não é u1n bo1n resulcado. O mundo esrá 1nudando o re1npo codo e se u1n site da Web ou outro projeto não é hoje tão bom quanto era no t'iltimo ano, geralmente significa que está ulcrapassado 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, n1as ela fàz parte do "pacote". Nã.o fique aí parado; aprimore-se. Há sempre uma nova maneira de pensar, un1 novo tópico para aprender e aplicar, ou um novo processo que torna o trabalho mais divertido ou eficaz. Talvez essa seja u1na 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 i1nporta o que a descrição do seu cargo diga.

Mas, volcando ao problen1a da pressão, conheço 1nuitos gerentes que abdicain dos mo1nentos de liderança (por exen1plo, algum momento e1n que a equipe/projeco precisa de algué1n para decidir sobre uma ação) e se dedicam apenas a concrolar os esforços dos oucros e1n vez de fàcilitar ou ainda parcicipar deles. Se tudo que alguém faz é 1nanrer o registro e observar do lado de fora, ele estaria mais bem preparado para trabalhar no departamento de contabilidade. Quando alguém e1n luna 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 agrega1n pouco valor.

ÜM.A BREVE H1STÓIUA DO GERENCIAMENTO DE PROJETOS 25

Confundindo o processo com metas

Alguns gerences de projeco nessa siruação recorrem à quancificação de coisas que não precisa1n ser quancificadas. Inseguros sobre o que n1ais fazer, ou ternerosos de fazer o que precisa ser realizado, eles ocupa1n seu ten1po ern coisas secundárias. E, à medida que cresce a distância entre o gerente de projeto e o projeto, aumenca a atenção dada desnecessariamente a gráficos, tabelas, listas de verificação e relarórios. É possível que, em algu1n ponto, os gerentes de projeto comecem a acredicar que os dados e o processo sejam o projeto. Eles focam nas coisas menos imporrances 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 cerras, o sucesso do projeto estará. garantido (ou, de maneira mais cínica, qualquer falha que ocorra não será tecnicamente de sua responsabilidade).

Para mini1nizar a possibilidade de confusão, bons gerentes de projeto resisren1 à definiç.'ío de lirnices escritos para os tipos de crabalho que desejam ou não execucar. Eles evicarn as linhas amarelas brilhances sicuadas encre as carefàs de gerenciamenco de projeto e o projeco propriamence clico. A fidelidade às !iscas de verificação implica que há um processo definicivo que garance um resulcado específico, o que nunca é o caso. Na verdade, sempre bá apenas crês coisas: uma mera, uma pilha de trabalho e um n1onte de pessoas. Funções bern-definidas (veja o Capículo 9) poderiam ajudar essas pessoas a se organizar em torno do trabalho, 1nas a fonnaç.'ío de funções não é a mera. U1na lista de verificação poderia ajudar a fuzer o trabalho de maneira a atingir a 1nera, mas a lista de verificação também não é a mera. Confundir processos com 1netas é um dos grandes pecados do gerenciamento. Eu deveria saber, pois eu mesmo já o corneei.

Há alguns anos, trabalhando no projeto do Internet Explorer 4.0, eu era o gerente de projeto para nluitas partes da interface de usuário. Eu me sentia pressionado: recebi a maior atribuição da n1inha vida. Em resposta, desenvolvi a crença de que se escrevesse tudo en1 listas de verificação, nunca falharia. Embora as coisas precise1n ser cuidadosamente controladas em um projeto, eu havia me excedido. Criei tuna planilha complexa para mostrar várias visões de dados e os grandes quadros brancos do meu escritório foram cobertos com tabelas e ]iscas (e outros quadros brancos haviam sido enco1nendados).

Meu chefe escava de acordo porque cudo corria bem. Isto é, acé que ele me viu gastando mais cempo com minhas listas de verificação e processos do que com a minha equipe - o que levantou uma grande bandeira vermelha (sinal de alerca) . Urn dia, ele entrou na 1ninha sala e vendo a enorme quantidade de !iscas de verificação e rabeias que eu tinha escrico em todas as superfícies planas do meu escritório, convidou-me a sentar e fechou a porra. Ele disse: "Scott, tudo isso é bom, 1nas seu projeto é a sua equipe. Gerencie a equipe e não as listas de verificação. Se as listas de verificação o ajuda1n a gerenciar a equipe, excelence. Mas da maneira co1no você esrá fazendo, em breve esrará 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 planeja1nenco ou controle sin1ples certa1nente deven1 ser usados, n1as eles deven1 corresponder à complexidade do projeto e à culrura da equipe. Mais precisamente, planejamenro

26 A AR"íE DO GERENCIAMENTO DE PROJETOS

e conrrole devem dar suporre à equipe para alcançar as meras do projero, não i1npedi-las. Eu renho cerreza de que desde que o gerenre de projero presre arenção e ganhe a confiança da equipe, quaisquer rarefas, processos, relarórios, lisras de verificação ou outros mecanisn1os de gerenciamenro de projeto necessários se tornarão evidentes antes que os problemas que eles deveriam resolver se tornem , .

ser1os. Conforn1e discutiremos no Capítulo 1 O, apenas porque um livro ou um

execurivo diz para fazer algo, ou porque uma récnica foi en1pregada no úlr.in10 mês ou no úlriino ano, não significa que ela se aplique hoje. Cada equipe e projeto é diference e existem várias razões para quesrionar julgamenros antigos. A razão para ser conservador com métodos e processos é que aqueles que são desnecessários rendem a aumentar feiro bolas de neve, arrastando as equipes para o abismo dos projetos difíceis, conforme descrito no livro The Mythicai Man­Month, de Fred Brooks. Quando são necessários processos para gerenciar processos, é difícil saber onde o trabalho real está sendo feiro. É freqüence1nence o líder da equipe ou o gerente do projeto que tem a maior habilidade para livrar a equipe da burocracia, ou 1nais cinicamente, de enviar a equipe a roda velocidade para infindáveis seqüências de procedimentos e de avaliações e1n reuniões.

O tipo certo de envolvimento

Todos os gerentes - de executivos de en1presas integrantes da lisra das 500 maiores da revisra Fortune a técnicos de equipes esporrivas - são vulner<Íveis a um envolviinenco excessivo. Acho que em algu1n ponto eles sabe1n que represenra1n despesas indireras (overhead) e um envolvimenro co1npulsivo é u1na rnaneira conveniente (embora negariva) de tentar compensar isso. Isso explica parcialmente a oferta contínua de "microgerences"; a ação mais fácil para um gerente fraco é abusar do seu poder sobre seus subordinados (e en1 casos extren1os, culpar simulcanean1ente 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 fuzem nada corn as mãos e não são o rnesrno 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 concracados para aumentar o valor de rodos os que os cercam. Os métodos para agregar esse tipo de valor são diferentes do trabalho ern linha de produção. Mas, como muitos gerentes são progra1nadores antigos e forarn promovidos à gerência a partir da linha de produção, é muito provável que eles tenha1n mais segurança e habilidade para escrever códigos do que para liderar e gerenciar pessoas que escrevern códigos.

Corno um récnico de Luna equipe de beisebol, supõe-se que a presença de un1 gerente contribua corn 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. Con10 essas contribuições são mais difíceis de medir, muitos gerenres

UM.A ÊREVE H 1STÓIUA DO GERENCIAMENTO DE PROJETOS 27

de projeto lidam com a ambigüidade de suas funções. Co1no gerentes, eles são alvos fáceis de censuras e tê1n poucos lugares para se esconder. É necessária uma combinação de convicção, confiança e consciência para ser eficience e feliz como líder de uma equipe.

Tirar vantagem da sua perspectiva

A 1nelhor 1naneira de encontrar pontos de alavancage1n é fuzer 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 gaseará 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 projer.o assim con10 a visão técnica e ajudará a equipe a compreender ambas, quando necessário. Essa perspectiva rnais ampla possibili ta a passagem de informações relevantes à pessoa cerra na hora certa. Urna história simples ajuda a ilustrar esse ponto de rnaneira mais abrangente.

Eu tinha co1no hábito caminhar pelos corredores e visitar os programadores que deixavam suas portas aberras. Nonnalmenre mantinha uma pequena conversa informal, tentando descontrair, contando algo que nos fizesse rir, e pedia a eles que me 111osrrassen1 o material no qual estavam trabalhando. Se eles oferecesse1n, eu assistia a urna dernonstração do que quer que me mostrassen1. Fazer isso durante alguns dias, rnesmo que fosse por alguns minutos, 1ne dava urna idéia do status real do projeto (no Capítulo 9, discutire1nos essa prática de gerencia1nento by walking around [por observação]).

Por exe1nplo, uma manhã, durante o projeto do IE 5.0, visitei o escritório de Fred. Ele estava d iscutindo com o Steve, outro programador, sobre como iarn fazer funcionar adequadamente o novo controle List View - um problema de compatibilidade não-previsto tinha sido descoberto naquela manhã. Nenhun1 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: "Sirn, 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 arqui tetura 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 rnáquina. Ele detectou o proble1na na noite passada e o corrigiu como parte de outro irem de trabalho".

Agora, é claro, nessa pequena história eu não salvei o mundo ou irnpedi un1 desastre i1nporcance. Se eu não tivesse feito essa conexão para eles, somente algurnas horas ou metade de un1 dia teria1n sido gastos (embora, como discutiremos mais tarde no Capítulo 8, os cronogramas às vezes errarn 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 sisten1a de controle de projeto ou de erros substitui con1pletamente a necessidade de conversar com as pessoas sobre o que esrá aconcecendo, porque as

28 A AR-íE DO GERENCIAMENTO DE PROJETOS

redes sociais são sernpre mais forces (e, às vezes, mais rápidas} do que as redes tecnológicas. Os desafios irnporcantes, como visão de projeto, !iscas de recursos e cronograrnas se1npre se traduzem em muitos pequenos desafios que são positivamente iníluenciados pela rapidez com que o bo1n conhecimento e a informação Auen1 através de uma equipe. Os gerentes de projeto desempenhan1 um papel crítico em tornar esse fluxo ativo e saudável.

Mas, sejan1 coisas grandes ou pequenas, as ações e decisões que os gerentes toman1 devem ter benefícios claros para a equipe inteira. Elas podem den1orar uma semana ou um mês para se fazere1n notar, mas u1n bom gerente de projeto criará u1n 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 resulrado, bons gerentes e líderes freqüenrernenre ganham un1 ripo especial de respeito dos prograrnadores, testadores, designers, pessoal de marketing e docu1nentaç.'í.o. O gerente de projeto deve ser capaz de executar a façanha de pensar, liderar e criar estratégias que cause1n impacto positivo na equipe de maneira cal que poucos o conseguiriam. Freqüente1nente isso envolve encontrar atalhos e orirnizações inteligentes no fluxo de trabalho diário ou dar u1n impulso no entusiasmo ou encorajamento da maneira cerra e na hora cerra. 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á urn simples faro indiscutível: os lfderes ou gerentes de projeto gastam mais re1npo com cada membro da equipe de projeto do qualquer outra pessoa. Eles estão em mais reuniões, visitam rnais escritórios e conversarn com mais colaboradores individuais do que qualquer outra pessoa. Eles comam 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 rodos aqueles que o encontrarem naquele dia. O que os gerentes de projeto trouxerem para o projeto, seja bo1n ou ruim, contagiará o resto da equipe.

Portanto, se o gerente de projeto for focado, co1nprometido, entusiasmado ou capaz de ser bem-sucedido, as possibilidades de todos se comportare1n da mesma 1naneira aumenta. Gerentes de rodo tipo estão e1n posições similares de poder potencial, e existem poucos pontos de influência de rnes1no valor na maioria dos ambientes de trabalho. Isso significa que se for possível culrivar as atitudes e idéias descritas até aqui, não há rnelhor lugar para fazer esses invesrin1entos do que en1 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 progra1nadores em tuna batalha (veja a seção "O complexo de herói" no Capítulo 11). En1 vez disso, basta estar genuinamente

UM.A BREVE H ISTÓRIA DO GERENCl/\MENTO DE 'PROJETOS 29

interessado em ajudar os relacionamentos de seus companheiros de equipe e ter 1nais êxico do que fracassos nessa carefa.

Finalmence, acredito que a idéia principal é que desde que ningué1n saia ferido (exceto calvez os concorrentes) e você envolva as pessoas da n1aneira cerra, nada mais importa exceto o furo de que coisas boas sejan1 feitas. Não importa quantas idéias venhan1 de você ou de qualquer outra pessoa, desde que o resultado seja positivo. O gerencian1ento de projeto consiste en1 usar rodos os meios necessários para aun1enrar a probabilidade e a velocidade de resulcados positivos. Um mancra üril que renho usado diariamente é "Faça coisas boas acontecer". As pessoas poderiam 1ne 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. À n1edida que os capítulos desce livro fore1n passando, espero que você sinta essa atitude e que as idéias principais deste capítulo de abertura perdure1n.

Resumo

Cada capículo deste livro terminará com um pequeno resun10 dos pontos-chave para ajudá-lo a revê-los mais carde:

• O gerenciamento de projeto está em todo lugar e já existe há 1nuito ten1po.

• Se você n1anciver u1na mente de iniciante, terá mais oportunidades de aprender.

• O gerenciamento de projeto pode ser uma tarefa, uma função ou un1a atividade (a orientação deste livro se aplica ben1 a rodas as definições).

• O gerenciamento de programa é a função do gerenciamento de projeto fortemente definida pela Microsoft. Deriva da idéia de uma organização rna tricial.

• Liderança e gerenciamento exigem enrendimenco e intuição sobre vários paradoxos comuns. Isso inclui ego/não-ego, autocracia/delegação e coragem/ 1nedo.

• Esteja atento para a pretensão e para o envolvi1nento excessivo na sua atividade de gerenciamento. O processo deve dar suporte à equipe, e não o contrário.

• Se você é u1n gerente dedicado, procure n1eios de capitalizar sua perspectiva ünica da equipe e do projeto.

tn o e ca a.. •

w l­a: <(

a..

Capítulo 2

A verdade sobre os cronogramas

34 A AR-íE DO GERENCIAMENTO DE PROJETOS

A s pessoas tendem a se atrasar. Pode1n ser somente alguns minutos de ve:z em quando ou poucas vezes e1n u1na sen1ana, mas as pessoas esrão freqüenremenre arrasadas en1 seus compron1issos diários. (Porén1, como a negação parece ser ourra grande habilidade inerente aos seres hu1nanos, con1preenderen1os se recusar a admitir que essa afirmação se aplica a você.) Os alunos do ensino médio se atrasam para as aulas, os adultos se atrasam para as reuniões de trabalho e os amigos chegam 10 minutos arrasados ao bar para a confraternização. Parece que no inconsciente, acrecüramos que chegar na hora combinada não equivale a ter como objetivo um momento específico e sim um intervalo de momentos, e para algumas pessoas, este intervalo é maior do que para outras. Um exemplo . . . . . 1nceressance aconrece com muttas recepc1on1stas que nos cumpnmentam nos restauranres. Elas nos informam que uma mesa logo estará disponíveP, mas geralmente nos fàzem esperar por muito te1npo. São essas experiências de atrasos e1n agendamentos, de ser colocado e1n espera no telefone ou de aguardar no consultório do médico, que nos levaram a sennos céticos em relação aos agendamentos de horários - reinos 1nuiras experiências de que a vida não funciona de acordo co1n eles.

Porranro, não é nenhuma surpresa que ranros projetos arrasem. Como seres humanos, a 1naioria de nós aborda o cronograma do projero co1n um histórico quesrionável quanro a entregar ou receber coisas na hora cerra. Te1nos a tendência de fazer esri1nativas baseadas e1n suposições inconsistentes, prever resultados para o trabalho con1 base no 1nelhor conjunto de circunstâncias possível, e (dadas as nossas experiências anteriores) simultaneamente evirar depositar muita confiança e1n qualquer progra1nação que ve1nos ou cria1nos. Por que f:12emos isso, como isso afera o cronograma dos projetos e o que pode ser feiro para evirar esses problen1as, são os assuntos desre capítulo.

Mas antes de entendermos con10 melhorar os cronogran1as, primeiro temos que con1preender quais problemas são resolvidos por eles. Se eles não são confiáveis, por que se preocupar com eles afinal? Os cronogramas servem a diversas finalida.des - apenas algun1as dessas têm o propósito de medir o uso do tempo.

Os cronogramas têm três finalidades

Todos os cronogramas, seja para planejar u1na festa de fim de semana ou para atualizar um site na inrranet, serve1n a três finalidades principais. A primeira e mais conhecida é para agendar co1npromissos. O cronograma é uma forma de contrato entre as pessoas de u1na equipe ou de uma organização, confirmando o que cada um irá produzir durante a próxima se1nana, mês ou ano. Geralmente, quando as pessoas pensam em cronogramas de projetos, essa é a prirneira finalidade que lhes vem à cabeça. Os cronogra1nas normal1nenre estão voltados para fatores externos, fora do âmbiro da equipe de projeto, porque são usados para ajudar a fechar un1 acordo ou acender a agenda de u1n cliente. Freqüentemente, o cliente estará pagando pela agenda, assi1n co1no pelo serviço oferecido (pense na UPS ou FedEx). Para permitir que clientes ou parceiros fuçam planos baseados en1 um decenninado projeto, deve haver un1 acordo sobre o mon1enco em que eventos específicos ocorrerão.

A VERDADE SOBRE os CRONOGRJ.\MAS 35

A segunda finalidade de tun cronograma é escimular rodas as pessoas que concribuem para um projeco a ver seus esforços como parte de um codo e a se empenhar para que rodas as peças funcionen1. Aré que haja uma proposca de cronogra1na sugerindo daras e horários específicos para a conclusão de tarefas, é pouco provável que as conexões e dependências entre pessoas e equipes sejam examinadas. En1 vez disso, cada pessoa trabalhará en1 sua própria tarefa e renderá a não se preocupar a respeito de como a sua tarefa afetará as das ou eras.

Somente após os decalhes serem documentados, com os nomes das pessoas próximos a eles, é que os cálculos reais pode1n ser feitos e as premissas examinadas. Isso é verdadeiro mesmo para equipes pequenas ou pessoas que estejam trabalhando sozinhas. Há um poder psicológico em um cronograma que externa e amplifica o compromisso que está sendo assumido. Em vez de datas e compromissos apenas dentro das n1e.ntes de algumas pessoas, eles são documentados e passam a existir no universo de fonna independente. Não é cão fácil esquecer ou ignorar algo que esteja exposto em u1n quadro de co1nunicações na. entrada, le1nbrando a você ou à equipe do que precisa ser feico. E especifica1nence para GPs: com uma proposta de cronograina escabelecida, perguncas sobre o grau de realidade de certos faros podem ser levancadas e podem ser feitas comparações enrre o que o projeto é solicitado a realizar co1n o que parece possível e1n u1n determinado período de tempo.

Essa mudança psicológica ou deslocamento da "pressão" é o que deno1nina1nos de u1na "função co1npelidora" (jorcíngfanction). U1na "função compelidora" é algo que, quando estabelecido, força nacurahnente u1na 1nudança na perspecciva, atitude ou con1porcan1ento. Portanto, os cronogran1as são importantes funções cotnpelidoras para os projetos. Se usados apropriadamente por um GP, os cronogramas obrigam rodas as pessoas cujos trabalhos são neles citados a pensar cuidadosa1nente no que precisan1 fàzer e con10 isso se encaixa no que os outros estão fazendo. Essa consciência do relacionan1ento entre as partes independe u1n pouco do cronograma propriamente dito. Essa função compelidora é uma etapa crucial no sentido de realizar rodo o potencial do projeto. Mesmo que o cronograma seja deslocado no tempo, duplicado, reduzido à metade ou passe por uma série de outras trocas atormentadoras, os compromissos e as conexões que todas as pessoas fizeram entre si serão mantidos. Portanro, essa segunda finalidade de um cronograma pode ser acingida e juscificar inceiramence o esforço despendido na sua criação, mesmo que esse cronograma se revele, mais carde, seria1nenre impreciso. Por exemplo, se o projeco vier a se acrasar 1nuito, a existência de u1n cronograma será crucial para ajudá-lo em sua conclusão.

A terceira finalidade dos cronogramas é dar à equipe uma ferra1nenta para rastrear o progresso feito e para desmembrar o trabalho em partes gerenciáveis. Desme1nbrar os procedimentos em etapas de u1n ou dois dias realmente ajuda as pessoas a compreendere1n o que precisain fàzer. l1nagine se, ao construir uma casa, o construcor cenha proposco um ite1n de linha: "Casa: 120 dias". Com cão baixo nível de detalhe, é difícil para alguém, incluindo o próprio conscrucor, compreender o que precisa ser feito primeiro ou quais irens do trabalho são mais caros ou trabalhosos. Mas se o construtor puder fornecer um desn1embramento semanal das atividades, todo mundo terá un1a compreensão mais clara de quais tarefas serão executadas e quando, e cada membro da equipe terá mais oporcunidade de fazer perguntas pertinenres e de esclarecer as pre1nissas.

36 A An.·rE DO GERENCIAMENTO DE PROJETOS

Do ponco de vista dos GPs, urn bom cronograma proporciona uma visão mais clara do projeco, faz e1nergir os desafios e as 01nissóes e aumenca as possibilidades de ocorrência de faros positivos.

Quanto n1aior e rnais complexo o projeto, mais importantes são os cronogramas. Em projetos maiores, há mais dependências interpessoais, e as decisões e horários têm mais possibilidades de afetar outras pessoas. Quando você tem algumas pessoas trabalhando en1 un1a pequena equipe, são muito maiores as possibilidades das pessoas identificarem problemas mútuos no trabalho de cada uma. Acrasos de cronograma em equipes pequenas não são boas norícias, mas, nesse caso, um atraso de meio dia no projeto representa um esforço adicional de meio dia para apenas três pessoas, tratando-se assim de um problema recuperável. Alguém pode trabalhar até mais carde ou, se necessário, toda a equipe pode se reunir e concordar em ajudar a compensar o tempo perdido. Em um projeto maior, com dezenas ou centenas de pessoas e componentes, um atraso de um dia pode produzir rapidamente um efeito cascara e criar proble1nas de todos os tipos e de forrnas imprevisíveis, o que geralmente está além do ponto de recuperação de urna equipe. De qualquer rnaneira, equipe grande ou pequena, os cronogramas proporcionain aos gerentes e auditores a oportunidade de formular perguntas, fazer ajustes e ajudar a equipe identificando e respondendo as questões à medida que surgem.

Com essas três finalidades em n1ente, é fácil ver que cronogramas perfeitos não solucionan1 todos os problernas inerentes aos projetos. Um cronogra1na não pode remediar práticas de projeto ou de engenharia ineficientes, nen1 pode proteger un1 projeto de urna liderança frágil, de metas imprecisas e de comunicação inadequada. Portanto, por maior que seja o ten1po consumido na elaboração dos cronogran1as, elas continuarão sendo apenas listas de palavras e números. Dependerá de alguém a sua utilização como uma ferramenta de gerenciamento e orientação de um projeto. Com isto em mente, é o momento de apresentarmos o extenso vocabulário e explorarmos as metodologias de so_{tware -os equipamentos pesados do gerenciamento de projetos.

"Balas de prata" e metodologias

H á muitos sistemas diferentes para planejar e gerenciar o desenvolvimento de software. Esses sistemas freqüentemente são chamados de metodologias, que significam um conjunto de práticas direcionado para a obtenção de um cerro ripo de resultado. Os métodos de softwares comuns incluem o modelo em cascara (wate1foll mode[), modelo ern espiral (spiral model), desenvolvirnento rápido de aplicativos (Rapid Applications development), prograrnação extre1na (Extreme Programrning) e desenvolvimento orientado para recursos (Feature-driven development). Todos esses n1étodos cencan1 solucionar proble1nas se1nelhances de organização e gerenciarnenro de projetos. Cada um deles possui pontos forres e fracos e é necessário conhecimenco e experiência para decidir qual deles é o apropriado para dererininado tipo de projeco.

Mas meu objetivo neste capítulo, e neste livro, não é discutir e co1nparar metodologias e sistemas diferences a serem utilizados. Acredico que haja conceitos e táticas que escão subjacentes a todos deles e que precisam ser dominados para se obter êxico com qualquer n1ecodologia. E1n todos os casos,

A VERDADE SOBRE os CRONOGR/1.t'v1AS 37

as rnerodologias precisam ser ajuscadas e adapcadas para se encaixar às parcicularidades de uma equipe e de urn projero, e isso só é possível se você possuir uma base de conheci1nencos que seja mais arnpla do que as próprias metodologias. Portanco, se você puder compreender e pôr em prática as idéias subjacentes descritas neste capítulo e no restante do livro, suas chances de atuar de forma eficaz aun1entarão, independente de qual metodologia esteja usando. Explicarei aspectos de certos n1étodos conforme a necessidade de esclarecer poncos, mas você precisará procurar en1 oucras fontes caso esteja à procura de metodologias2 .

Embora os métodos e processos para o desenvolvimento de sofuvares sejam muito importantes, eles não são, em si mesmos, "balas de prata" (que resolvem o problema com um único tiro) ou garantia de bons resultados. A pior atitude é seguir cegamente um conjunto de regras ou procedimentos que claramente não está funcionando, simplesmente porque aparece em algum livro famoso ou são prornovidos por un1 guru bem conceituado. Quase sempre, tenho percebido que a. obsessão por um processo é um sinal de alerta para problernas de liderança: pode ser uma tentaciva de descarregar os desafios e responsabilidades nacurais que os gerentes enfrencatn em urn siscetna de procedimentos e burocracias que obscurece1n a necessidade de pensamento e ação reais. Talvez ainda mais devastador para uma equipe seja o faro de a fixação na metodologia ser um sinal do que é realn1ente irnportance para a organização. Co1no Ton1 DeMarco escreve no livro PeopieWare:

A obsessão cotn 1netodologias no loca] de trabalho é outro exemplo da ilusão sobre alca tecnologia. Tem sua origern na convicção de que o que realmente irnporta é a tecnologia ... Qualquer que seja a vanragen1 tecnológica, ela só pode ser alcançada ao custo de um agravamento significativo da parte sociológica da equipe.

Ao se concentrar em métodos e procedimentos, em vez de na criação de procedimentos que dêem suporte e amplifiquem o valor das pessoas, os projetos começam o cronograma. limitando as contribuições dos indivíduos. Eles podem definir urna cônica de regras e de cumprimento das regras, em vez de promover o pensamenco e o ajuste ou melhoria das regras. Portanto, tenha muito cuidado com a forma como você aplica qualquer metodologia que utilize: não deve ser algo imposco à equipe. Deve ser algo que dê suporte, estimule e ajude a equipe a executar um born trabalho no projeto3.

Assirn, lembre-se que o uso de uma ou de outra metodologia nunca é a única razão para que urn projeto curnpra ou não o seu cronograma. Há fatores que afecarn todas as programações do projeto e os gerentes têrn de procurar compreendê-los antes que qualquer cronograma seja definido. Mas antes de falarrnos sobre isso, precisarnos abordar os componentes de um cronogra1na.

Com o que os cronogramas se parecem

Há u1n princípio geral básico para rodos os cronogran1as: a regra dos terços. É uma esri1nativa exrren1an1ente imprecisa e que não deve ocupar lugar de destaque,

38 A ARºIB DO GERENCl1\MENTO DE PROJETOS

mas é a maneira mais simples de abordar e compreender os cronogramas. Se você possui experiência co1n o assunco, prepare-se, pois vou siinpliflcar ainda 1nais rodo o processo. Escou fazendo isso para proporcionar o embasamenco 1nais si1nples possível para falar sobre o que pode dar errado, por que isso aconrece e o que pode ser feito a respeito.

Eis aqui como o modelo ulcra-simplificado de cronograma funciona: para qualquer projeto, desn1embre o tempo disponível em três partes - uma para o projeto, uma para a implementação e tuna para os restes. Dependendo das metodologias a serem usadas, essas fases poderão ter nomes diferences ou podem sobrepor-se mucuamence de certas maneiras, mas todas as merodologias dedicam tempo para essas três arividades. Em um dererminado dia, você pode esrar pensando no que deve ser feito (projerando, ou designing), ou realmente executando esse procedimento (implementando código de produçã.o, ou programando) ou verificando, analisando e refinando o que está. pronto ( rescando).

Aplicando a regra dos terços

De acordo com a regra geral, para cada dia que você espera gastar programando, un1 dia devení ser gasto planejando e projetando o crabalho, e um oucro dia será para tesrar e refinar esse trabalho (consulte a Figura 2-1). É a coisa 1nais sin1ples do inundo e é uma maneira fácil de exa1ninar algum cronogra1na existente ou de começar um novo cronograma desde o início. Se o ce1npo total não for mais ou menos dividido nos crês t ipos de crabaJho, deverá haver razões bem co1npreendidas para que o projeto demande u1na distribuição não-unifonne de esforço. D esequilíbrios na regra dos terços - digamos, 20o/o de tempo a mais dedicado a testes do que para a in1plementação - são bem aceitos contanto que sejam deliberados.

Projeto i Tem~ Programação

l Testes ~ FIGURA 2-1. O cronograma de projeto com a regra dos terços.

Considere um projeto de desenvolvimenco hipocécico para a Web: se você civer um prazo de seis semanas para concluí-lo, o primeiro passo deve ser dividir mais ou menos esse tempo em terços e, usando essas divisões, estimar quando o trabalho poderá ser concluído. Se isso não proporcionar tempo suficience para fazer o trabalho esperado em um nível mais alto, então, algo está fundamentalmente errado. Ou o cronograma precisa ser mudado, ou o volume de crabalho que se pretende concluir precisa ser reduzido (ou algumas expecta.tivas de qualidade precisam ser

A VERDADE SOBRE os CRONOGRr\MAS 39

diminuídas). Cortar o tetnpo da fase do projeto ou dos restes apenas au1nenrará a possibilidade de que o tempo gasto realmente escrevendo o código seja 1nal­orientado ou resulce em um código mais difícil de gerenciar e 1nancer. A regra dos terços é útil porque força a natureza de soma-zero de projetos a vir à tona. Adicionar novos recursos exige mais do que apenas um progran1ador para implementá-los; há custos inevitáveis de projeto e de testes que alguém cem de pagar. Quando os cronogramas arrasam, é porque havia custos escondidos ou ignorados que nunca foram reportados.

Desenvolvimento gradual (o projeto de antiprojeto)

Para finalizar, vale a pena considerar o caso mais simples possível: não há nenhum projeto. Todo o trabalho é concluído de forn1a gradual - as solicitações chegam, são avaliadas em relação a outros t.rabalhos e, ern seguida, são inseridas no próximo intervalo de tempo disponível do cronograma. Algumas equipes de desenvolvimento, desenvolvedores de sites ou departamentos de progra1nação de TI rrabalha1n muito dessa forma. Essas organizações raramente faze1n investi1nenros ou co1npromissos em larga escala. Métodos ágeis (discutidos 1nais adiante) são recomendados freqüentemente a essas equipes como o sistema 1nais natural para organizar trabalho porque esses métodos realçam a flexibilidade, si1nplicidade e expectativas de 1nudança. Se você trabalha em várias pequenas tarefas (não en1 projetos) de cada vez, terá que se basear nos exemplos centrados em projetos que eu uso neste livro.

Poré1n, a regra dos terços ainda se aplica a essas sicuações. Mes1no que cada programador esteja trabalhando sozinho em pequenas carefas, é possível que ele gaste quase um rerço de seu tempo total descobrindo o que precisa ser feito, um terço de seu tempo executando isso e o outro terço certificando-se de que tudo funciona adequadamente. Ele dispõe de alguma flexibilidade na utilização desse tempo, mas como uma nlaneira simplificada de con1preender qualquer tipo de trabalho, a regra dos terços se aplica bem em qualquer escala.

Divida e conquiste (grandes cronogramas= muitos cronogramas pequenos)

Se exa1ninar a maioria das metodologias de desenvolvin1ento de softwares, você pode ver os contornos da regra dos terços. As metas e abordagens específicas usadas para projetar e Ílnplementar os procedimentos podem ser 1nuito diferences, nlas no nível nlais alco, os resultados desejados são se1nelhances.

Onde isso se torna co1nplexo é em projetos maiores ou mais longos, en1 que os cronogramas são divididos em peças menores, cada peça tendo o seu próprio tempo de projeto, implementação e teste. A Programação Extrema (Extreme Programming, conhecida como XP) chama essas peças de iterações; o modelo em espiral as chama de fases; e algumas organizações as chamam de etapas. Embora a XP implique que esses intervalos de tempo seja1n apenas de algumas semanas e o modelo e1n espiral implique que eles seja1n de 1neses, a idéia fundamental é a mesma: criar cronogramas detalhados por períodos limitados de tempo.

40 A An.·rE DO GERENCIAMENTO DE PROJETOS

Quanto mais alterações e volacilidade do projeto forem esperadas, mais curca deve ser cada ecapa. Isso düninui o risco global do cronograma porque o plano mesrre foi dividido em pedaços gerenciáveis. Essas quebras encre incervalos de tempo n1aiores do cronograma proporcionam oportunidades naturais para fazer ajustes e melhorar as chances de que a próxima etapa direcionará seu trabalho de forma nlais precisa. (Discutiremos como fazer isso no Capítulo 14.)

Métodos ágil e tradicional

A XP e outros métodos ágeis presumem que o futuro é sempre volátil, e assim apostam em processos que incorporem facilmente mudanças de direção. Os projetos que têm custos de produção muito elevados (digamos, construir um arranha-céu, um console de vídeo game ou un1 sisten1a operacional incorporado) se co1nporta1n de outra maneira e investem maciçamente e1n atividades de planeja1nento e projeto. Isso pode ser feito, mas todos tê1n de se compro1neter co1n as decisões to1nadas durante o planeja1nento, e co1n o custo proibitivo das alterações, rende a ser a única maneira de isso acontecer.

A maioria dos projeros de desenvolvimenro de sofrwares está em algu1n lugar no meio disso tudo. Eles têm algum planejamento inicial, mas para ajudar a gerenciar a volatilidade futura de requisitos e de1nandas do cliente, o trabalho é dividido en1 fuses que têm o te1npo alocado para projeto (design), implementação e garantia de qualidade. Se surgir un1 novo proble1na, isso pode ser considerado na fase acuai ou ser colocado no reposicório de trabalhos para ser invescigado e compreendido adequada1nence durance a próxi1na fase.

Na maioria dos projetos, esse 1nomenro de planejamento inicial é usado para capturar infonnações suficientes dos clientes e grupos de negócios para definir quantas fases são necessárias e qual deve ser o foco de cada un1a (consulte a Figura 2-2). Dependendo do plano maior, cada fase pode dedicar mais tempo para projetar ou tescar. Uma fuse pode ser dividida em duas fases menores (assen1elhando-se a um estilo mais ágil de desenvolvimento) ou duas fàses podem ser reunidas e combinadas (assemelhando-se a urn desenvolvimento mais monolítico). Mas em todos os casos, o tempo deveria ser alocado entre fases para t irar vantagem do que tiver sido alterado. Isso inclui responder a problemas que surgiram durante a fàse anterior e que não puderam ser resolvidos completamente.

Este é o limite a que chegarei no que se refere à metodologia de cronograma de alto-nível. Os Capírulos 14 e 15 abordarão co1no gerenciar u1n projeto ao longo de todo o cronogra1na, mas eles se concentrarão nas perspectivas de gerenciamento e liderança - não nos detalhes de como você aplicou u1na detenninada metodologia. Se puder chegar até os t'ilti1nos parágrafos (mes1no que não concorde toralmence com as considerações feiras neles), encão as reco1nendações constantes nos Capítulos 14 e 15 poderão ser pertinences e t'iteis, independente de como você organizou ou planejou seu projeto.

De qualquer maneira, peço desculpas a todos os veteranos em desenvolvi1nento que tenhan1 passado mal ou adoecido durante esta seção. Agora que terminou, prometo que essa visão leve e sünples de cronogran1a é quase tudo que você precisará para compreender os conceitos do restance do capículo.

A VERDADE SOBRE OS CRONOG R/\Jv1AS 41

Planejamento inicial

1 Projeto J

Fase 1 Implementação

1 Teste l l Projeto 1

Implementação Fase2

1 Teste J

1 Projeto l Fase3

Implementação

' Teste J

FIGURA 2-2. Um grande projeto deve ser uma seqüência de pequenos projetos.

Por que os cronogramas falham

Os cronogramas de projetos são os bodes expia tórios preferidos para tudo o que possa dar errado. Se alguém erra uma estimativa, omite um requisito ou é atingido por um ônibus, é o cronograma (e a pessoa responsável por ele) que leva a culpa. Se o fornecimento de energia do país fosse interrompido por 10 dias ou os 1nelhores programadores da equipe ficassem 1nuito doentes, invariavelmente algué1n diria: "Veja, eu disse que o cronogra1na atrasaria" e apontaria o dedo para o rosto do responsável por ele. É totalinente injusto, mas acontece o tempo todo. Tanto quanto detestam os cronogramas, as pessoas ainda os apresentam co1no um padrão inatingível. Mesmo os 1nelhores desenvolvedores de cronogratnas do inundo, com as mentes 1naís brilhantes e as 1nelhores ferra1nentas à disposição, ainda estão tentando prever o futuro - algo que raratnenre fazemos ben1.

Mas, se uma equipe começa um projeto 1nuico atenta às prováveis razões pelas quais os cronogramas falham e ton1a algu1na atitude para n1ini1nizar esses riscos, ele pode se tornar u1na ferramenta mais útil e precisa no processo de desenvolvimento.

Atirando às cegas de muito, muito longe

Se um cronograma é criado durante o planejamento inicial, centenas de decisões que o afetam ainda têm de ser tomadas. Haverá proble1nas e desafios, que

42 A ARºIB DO GERENCl1\MENTO DE PROJETOS

ninguérn pode prever, e não há nenhurna forma de elaborar um plano especularivo ancecipadamence. Acé que os requisiros seja1n cotnpreendidos e um projero de alro-nível esreja betn encaminhado, u1n gerenre de projeco fica con1plecamence às cegas e possui pouquíssimas informaçóes para fazer previsóes realistas. No entanto, na maioria das vezes, um cronograma rudimentar e incompleto é criado com números inventados e especulações precipitadas, e esse espancalho resulcante é passado à equipe com a aparência de um plano de projeto possível. Freqüentemenre, as pessoas são vícimas de uma armadilha precisão versus exatidão: um cronogra1na aparencemenre convincence com datas e horários específicos (precisão) não escá necessariamence reíletindo a realidade de perto (exatidão). Precisão é fác il, mas exatidão é muito difícil.

Porém, é certo que todos os projetos e cronogramas têm de começar por algum lugar. Um "tiro no escuro" pode ser usado para estimular uma equipe e estabelecer alguns limites. Isso pode iniciar um processo de investigação para es1niuçar os cronogramas e levancar questões irnportances e respondê-las. Mas se urna extensa especulação sern verificação e ex<1me prévios for usada corno base para tun cronograma - sern nenhum refinarnento adicional - podernos esperar grandes riscos. Há forces evidências de que é difícil para qualquer urn escimar ancecipadamence a quancidade de cempo necessária a um projeto.

Barry Boehm, e1n seu ensaio de 1989 sobre a engenharia de software,4

descobriu que os erros em cronogramas cresce1n ern relação ao grau de anrecipação con1 que são feiras as estimativas do cronogran1a do projeto (con10 pode ser visto na Figura 2-3). Se as escimativas totais do cronogra1na são feitas precocernence, podem se distanciar acé 400o/o, en1 qualquer direção (suspeito que os erros cêrn urn viés concra nós, rendendo a levar 1nais cempo que esperarnos, ernbora os dados disponíveis não rnoscrassem isso). Durance a fase de projeco, à 1nedida que rnais decisões são esclarecidas, a variação diminui, mas ainda é grande. Somente quando o projeto estiver em implementação é que o intervalo de estimativas do cronogra1na se torna razoável, mas mesmo nesse momento, ainda. há uma oscilação de 20% no grau de exatidão que se espera das decisões de cronograma.

400

200

100

50

10

-10

-50

-100

-200

-400

Início do projeto

Análise de requisitos

Projeto (design)

Implementação

FIGURA 2-3. O intervalo de erros de estimativas durante os projetos (adaptado de Boehm, Software Engineering Economics).

A VERDADE SOBRE OS CRONOGRr\MAS 43

Isso significa que os gerentes de projetos precisam compreender que as escimarivas de cronogran1as crescem e1n exatidão ao longo do te1npo. Os cronogra1nas de1nandam n1ais atenção à 1nedida que ocorre o progresso e que ajustes são feicos, conforrne o projero segue en1 frenre.

Um cronograma é uma probabilidade

Quando era recém-formado pela universidade e escava rrabalhando em 1neus primeiros projetos de n1aior importância (Windows e Internet Explorer), os cronogramas de alco nível eram passados para a minha equipe por alguém muito mais importanre do que eu. Sendo muiro inexperienre para me envolver mais no processo, o cronograma seria apresentado um dia, e era meu trabalho aplicar esse cronograma mestre ao pequeno número de progra1nadores e testadores com os quais trabalhava.

E1nbora negociásse1nos diferenças entre esse cronogra1na mestre e o cronograma gerado pela 1ninha equipe baseado e1n irens de rrabalho,5 aquele cronograrna de alto-nível se1npre pareceu rer surgido do nada. Descia do céu, cuidadosamente formatado, distribuído e1n colunas de datas e nú1neros perfeitos. Era como se fosse um artefato roubado do fururo .

Não imporra o sarcas1110 ou cinismo com que tratávamos o assunto, na 1naioria das vezes seguíarnos esses cronogra1nas fieln1enre. Apesar do mistério de suas origens, tínhamos uma boa razão para confiar e1n nossas lideranças de equipes e estáva1nos suficiencemence ocupados com nosso próprio trabalho para não nos preocuparmos muico co1n os deles. (Na realidade, freqüente1nence eles forneciam explicações básicas para aqueles cronogra1nas iniciais vindos de cirna para baixo, mas estávamos muiro ocupados e muito confiantes para prestar atenção.)

Posteriormente, quando o cronograma ficou sob minha responsabilidade, percebi a verdade oculta. Eles não são presences vindos do fi.1turo. Não há nenhuma fórmula mágica ou ciência para criar cronogramas perfeicos. Apesar de minhas percepções i1naturas, o cronograma não é 111na tarefa isolada: sempre representa e engloba muitos aspectos diferentes do que o projeto é agora e será no futuro. Os cronogramas são simplesmente um tipo de previsão. Não importa o grau de precisão com que sejam delineados ou até que ponro pareçam convincentes, são apenas uma soma de várias escimarivas, cada uma inevitavel111ence propensa a tipos diferences de omissões e problemas imprevisíveis. Os bons cronogramas são provenientes somente de um líder ou de uma equipe que persiga implacavelmente e alcance um bo1n julga1nento a respeito de 1nuitos aspeccos diferentes de desenvolvirnenco de sofcwares. Você não pode ser um perico e1n decern1inadas parces do processo de fàbricação de algo e esperar que tudo sempre dê cerco na criação de cronogramas.

Porcanco, se codos na equipe pode1n concordar que o cronograma é um conjunto de probabilidades, então o problema não está no cronogra111a propriamenre dito - escá em como ele é usado. Se algun1a vez u1n cronogra1na for mostrado em uma reunião de equipe ou enviado por einail, esta é tuna pergunta válida: qual o grau de probabilidade com que a linha de tempo é definida? Se nenhu1na probabilidade for oferecida (por exemplo, quais são os cinco riscos mais prováveis e urna especulação sobre a probabilidade da ocorrência deles) e se que1n

44 A AJ,-íE DO GERENCIAMENTO DE PROJETOS

criou o cronograma não puder oferecer explicações sobre as suposições feicas, sempre deveríamos presumir que o cronograma é possível, 1nas i1nprovável.6 A equipe deveria ser escimulada a fazer sugescões sobre quais considerações ou infonnações pode1n ser adicionadas ou alceradas no cronograma para corná-lo faccfvel.

Portanto, o segredo aqui é que un1 cronogra1na não ce1n que ser perfeito (o que é um alívio, é claro, porque não existem cronogramas perfeitos). Os cronogramas precisam ser suficientemente bons para que a equipe e os líderes acredicem, fornecer uma base para o moniroramenro e os ajustes, e rer uma probabilidade de sucesso que satisfuça o cliente, o negócio ou o patrocinador do projeto global.

Fazer estimativas é difícil

Durante o processo de elaboração do projeto (abordado nos Capículos 5 e 6), parte do trabalho dos projetistas, progra1nadores e testadores é desmembrar o projeto (design) e1n pedaços 1nenores de trabalho que possam ser criados. Esses pedaços, gerahnenre chainados de irens de crabalho (work items) ou estrutura analítica de projeto (WBS7 - work breakdown structure), se tornam os itens de linha do cronograma n1esrre do projeto. Os irens de trabalho são (cruze os dedos) inreligenremente distribuídos8 pela equipe de progran1ação, e por meio de cálculos, um cronograma é criado. Cada un1 desses itens de trabalho te1n de ter un1a quantidade de re1npo atribuída a ele pelo programador e, baseada nessas estimativas, o cronogra1na é criado.

Siinplificando a definição, boas estÍinarivas de trabalho cê1n u1na alta probabilidade de sere1n exaras e esci1nacivas de crabalho ruins cêm uma baixa probabilidade. Não espero receber nenhuma reco1npensa por essas definições, mas pelo menos elas sugerem algo útil: é o julgamento dos líderes de equipes que define o ritmo de um determinado projeto. Isso requer um processo ativo de revisão de estimativas e de estímulo, liderança e pressão sobre outras pessoas para que as estimativas atinjam o nível necessário. Penso que seja inteligente envolver abertamente a equipe de testes/qualidade no processo de estimativa, deixando-a participar das discussões de projeto e fi1zer pergunras ou oferecer comentários. No mínimo, isso a ajudará com suas próprias estimativas par-a o trabalho de testes, que podem não ser correlatas às esrimacivas de trabalho de programação. Freqüentemente, o profissional de garantia de qualidade é n1ais perspicaz em relação a omissões de projeto e a casos de possíveis fracassos que outras pessoas irão negligenciar.

O mundo é baseado em estimativas

Algo que dificulta o cronograina é o fato de poucas pessoas gostarem de fazer escimacivas de coisas complexas pelas quais elas serão responsáveis. Sempre é divertido vangloriar-se e apostar em nossas habilidades ("Esse livro/fil1ne/site não presta: eu poderia fazer um bem melhor"), 1nas quando somos pressionados a melhorar e a realizar - assinando nossos no1nes e1n um contrato que detalhe nossas responsabilidades - a coisa muda. Saben1os que é totalmente possível que tudo o que nos comprometemos a fà.zer hoje pode ser impossível ou indesejável fazer quando aquele nlomento chegar. Isso sin1plesmence pode vir a ser nluico

A VERDADE SOBRE OS CRONOGRJ.\MAS 45

rnais difícil do que pensávamos. Os programadores são exararnenre iguais a qualquer ourra pessoa e rêm boas razões para ficare1n ansiosos ao fàzer esrimacivas. Ao dizer que algo pode ser feiro e1n urn dererminado período de rempo, esrarão se arriscando a comecer un1 grande erro.

Pela minha experiência, mesmo os programadores que compreendem be1n o processo de elaboração de estimativas e acreditam nele, não gostam de fuzê-lo. Parte disso é fruto do desacordo entre a imaginação ("Como isso flrncionará, rendo em vista as informações muito limiradas que possuo?") e a precisão temporal ("Diga-me exaramenre quanras horas levará para fazer isso."). Mas a afinidade aqui deve ser limirada: todos os que trabalham em engenharia e conscrução cêrn o mesmo ripo de desafio, seja na construção de um arranha-céu, na reforma de uma cozinha ou no lançamento de uma ascronave para pousar em outros planecas. A partir da lei cura sobre como essas pessoas fazem estimativas, não parece que os seus <lesai-los ou técnicas sejam fundamentalmente diferentes dos que os desenvolvedores para a Web e engenheiros de software enfrentam. A principal diferença está em quanto ternpo eles dispõern para gerar estimativas e na disciplina que têrn na utilização desse tempo (os Capfrulos 5 e 6 discutirão isso detalhadamente).

Boas estimativas resultam de bons projetos ( designs)

Para crédito de prograrnadores de todos os lugares, a coisa rnais irnportante que aprendi sobre boas estin1ativas é que elas só provêm de projetos e requisitos confiáveis. Boas estitnativas de engenharia só são possíveis se você reunir dois fatores: boas infonnações e bons engenheiros. Se as especificações são ruins e urn prograrnador precisa evocar un1 nt'1mero baseado em urn rabisco incompreensível no quadro de cornunicações, todos deve1n saber exatamente o que esperar: uma estimativa de baixíssima qual idade. Isso significa que boas estimativas são responsabilidade de todos e deve constituir o trabalho de toda a equipe - gerentes de projetos e projetistas em particular - para fazer o que puderen1 para dar suporte aos engenheiros na produção de estimativas confiáveis. Se fazer estirnativas se parece com uma tarefà desagradável e um projeto de contabilida.de ou se os líderes da equipe não estão envolvidos no processo, não espere estimativas confiáveis ou factíveis.

Se os líderes admirem estimativas inconsistentes no cronograma e se sentem à vontade com um risco maior do mesmo, não há nada de errado com as estimativas frágeis . Em projetos menores., mais rápidos, estimativas grosseiras podern ser tudo que o projeto precisa. Os requisitos podern ser alterados corn freqüência e a natureza do negócio ou da organização pode exigir rnenos estrutura e mais flexibilidade. Não há nada de errado com estimativas de baixa qualidade, contanto que ninguém as confl1nda co1n estirnativas de alra qualidade.

Uma técnica prática que descobri foi que sempre que u1n programador se recusou a dar urna estirnativa, eu perguntava, "Quais perguntas eu posso responder para aumentar sua confiança e1n dar uma estimativa?" Conseguindo que ele fosse específico, dava a ele a oportunidade para confrontar o n1edo ou frustração que ele pudesse sentir, o que me permitja ajudá-lo a resolver o problema. Claro que eu teria de ajudar a achar as respostas às suas perguntas e possivelinente debater os problemas que eu considerava como sendo trabalho de investigação dele, mas pelo menos estaríamos fulando sobre con10 n1elhorar as estimativas.

46 A An.-rE DO GERENCIAMENTO DE PROJE1-os

Aqui escão algumas maneiras adicionais de assegurar boas estimativas:

• Estabelecer intervalos de confiança na linha de base para as estin1ativas. U1na suposição = 40°/o de confiança em precisão. U1na boa esri1nariva = 70o/o. Un1a análise con1plera e detalhada = 90ºAi. Os líderes de equipe precisam concordar con1 o grau de precisão que desejam que as estimativas tenham, assim como com o tempo que os programadores terão para elaborá-las e como os riscos de on1issões nas escimacivas serão gerenciados. Não se fixe nos números: apenas use-os para ajudar a concrerizar a qualidade das estimarivas. Uma esrÍ!nariva de 90% deve 'acertar na mosca' 9 vezes e1n cada l O. Se você decidir pedir à sua equipe que melhore a qualidade das estimativas, terá de associar este pedido a mais tempo para que eles façam isso.

• Os programadores que orientam o projeto têm de definir os limites para as estimativas de boa qualidade fazendo boas perguntas e adotando abordagens inteligentes que a equipe possa imitar. Faça tudo o que for necessário para neutralizar a 1norivação para comentários maliciosos ou de repúdio (por exe1nplo, "Não 1ne prenda a isso", "É apenas u1na suposição" etc.). Descubra as necessidades legírimas que eles têm de entregar boas estimativas e proporcione o tetnpo necessário compadvel co1n as metas de qualidade das esci1nativas.

• Os programadores devem merecer confiança. Se o seu neurocirurgião lhe dissesse que a cirurgia que precisa fazer leva cinco horas, você o pressionaria a fazê-la em rrês? Ouvido. Às vezes, a pressão re1n de ser aplicada para 1nanrer as pessoas conscientes do que rêm de fazer- mas somente con10 uma medida de equilíbrio (a necessidade clássica para isso é um programador que faz estimativas altas para o que ele não gosta, e baixas para o que gosta). Freqüentemente, obter várias estin1ativas (de dois desenvolvedores diferences) pode ser uma n1aneira de fazer tuna verificação da capacidade de julgamento.

• As estimativas dependem da compreensão pelo programador das metas do projeto. As estimativas são baseadas na interpretação de um programador não so1nente das especificações do projeto (se existirem), mas também das metas e objetivos do projeto. E1n 7"he J>sychology of Computer Programrning (Dorset House, 1971), Gerald Weinberg registra como a falta de clareza sobre objetivos de nível mais alto tetn u1na influência direta nas suposições de nível 1nais baixo que os programadores faze1n. Independentemente de quão conhecido possa ser o problema tecnológico, a abordagem do programador para resolvê-lo pode mudar dependendo subsrancial1nenre das intenções de alto nível de rodo o projeto.

• As estünativas devem ser baseadas em um desempenho anterior. É uma boa conduta para os progra1nadores realizar o monitora1nento de suas esti1nativas nos projetos. Isso deveria fazer parte de suas discussões con1 os gerentes, que deverian1 estar interessados em compreender em que tipo de esrin1ativas os componentes de suas equipes se descacam. A Programação Exrren1a usa o termo velocidade para se referir ao desempenho provável de un1 programador (ou de uma equipe), baseado e1n desempenho prévio.9

• A qualidade da especificação ou do projeto deveria se situar no nível compatível com a necessidade da engenharia para elaborar boas estimativas. Essa é uma negociação entre o gerenciamento do projeto e os programadores. Quanto mais alta a qualidade desejada das estimativas, mais alta deve ser a qualidade das especificações. Falaremos mais sobre boas especificações no Capítulo 7.

A VERDADE SOBRE OS CRONOGRr\MAS 47

• Há técnicas conhecidas para fazer estimativas melhores. A [écnica mais conhecida é o PERT,1º que [en[a minünizar os riscos calculando a 111édia de esci1nacivas O[ÍJniscas, pessiinis[aS e médias para o crabalho. Isso é bom por duas razões. Prin1eiro, força rodo mundo a perceber que as escimacivas são previsões e que há u1n intervalo de resultados possíveis. Segundo, proporciona aos gerentes de projetos uma chance de controlar o nível de agressividade ou conservadorismo dos cronogran1as (pode ser dada mais ênfuse às estiinacivas otimistas ou pessimistas).

Os descuidos mais comuns

Embora as boas estimativas contribuam bastante para melhorar os cronogr,imas, muitos dos fàtores que os afetam dependem de vários itens de linha individuais. A armadilha que isso cria se caracteri7.a pelo f,ito de, apesar de todas as estimativas de itens de trabalho serem perfeitas e maravilhosas, os riscos reais do cronograma estão nas coisas que não são escritas. Embor,i seja verdade que a possibilidade de contrair a pesce seja pequena na 1naior parte do inundo, a probabilidade de u1n engenheiro imporcance con[rair gripe ou sair de ferias é be1n alca. Há urn conjun[o co1num desses descuidos ou omissões relativos à elaboração de um cronograma com a qual [odos os gerentes de projecos precisam se familiarizar. O problema é que somente após sofrer as conseqüências de algo que foi omitido é que você se dispõe a procurá-lo no fururo. Essa é a razão pela qual o gerencian1ento do projeto, e o gerencia111ento do cronograma e1n particular, exige experiência para se tornar proficience. Há n1uicas tnaneiras diferences de co1neter falhas, e nenhuma fonna de pracicar a sua idencificaç.ão, setn ser respons.ivel por suas conseqüências.

Eis aqui a minha lisca preferida de perguncas que me ajudou a identificar ancecipadamente possíveis proble1nas de cronograma. A maioria delas vem de perguntas feiras, após a conclusão de um projeto, sobre o que saiu errado, e da tentativa de encontrar uma pergunta que alguém poderia ter feito antes e que teria evitado o problema. (O que faltou? O que não foi levado em conca? O que teria feito diferença ou permitido a adoção de uma ação corretiva?)

• .As licenças médicas e férias regulamentares de todos os colaboradores forarn de alguma forma incluídas no cronograma?

• As pessoas tiverarn acesso ao cronogra1na e foram solicitadas a informar regulannence seus progressos (de u1na fonna arnávei)?

• Alguém supervisionava o cronogra1na global diariamente ou se1nanal1nente? Essa pessoa ceve aucoridade suficience para fazer boas perguntas e incluir os ajusces necessários?

• A equipe se sencia respons<ivel e co1nprometida com o cronogra1na? Caso concrário, por quê? A equipe con(ribuiu para a definição do cronogra1na e do trabalho a ser feiro ou isso lhe foi si1nplesmente comunicado?

• Os líderes da equipe adicionara111 mais solicicações de recursos do que ajudaram a eliminar? Os líderes da equipe alguma vez disseram não a um novo trabalho e proporcionaran1 à equipe uma "filosofia" razoável sobre como responder a novas (e tardias) solicitações?

• As pessoas da equipe foram estimuladas e receberam suporte para dizer náQ a novas solicitações de trabalho que não se encaixavam nas metas e na visão do projeto?

48 A AR·rn DO GERENCIAMENTO DE PROJE1-os

• Quais fora1n as probabilidades usadas na elaboração das escimacivas? 90°/o? 70o/o? 50%? Isso foi expresso no cronograma mestre de alto nível? O cliente/VP sabia disso? Houve discussão de outra proposta que levaria mais tempo 1nas contemplaria un1a probabilidade mais aJta?

• Houve períodos no cronograma em que puderam ocorrer ajustes e renegociações entre líderes e a gerência?

• O cronograma considerou menos horas de trabalho durante o período de feriados? (Nos Estados Unidos, o período entre o dia de Ação de Graças e o Natal é conhecidamente uma época de baixa produtividade.) Existem eventos climáticos importantes com seus impactos considerados no cronograma (por exemplo, temporais em Chicago, tornados no Kansas, sol em Seattle)?

• As especificações ou o projeto foram suficiencemence bem planejados para a engenharia fazer boas estimativas de trabalho?

• A engenharia foi treinada ou tinha experiência em fazer boas esti1nativas de trabalho?

O efeito bola de neve

O aspecto 1nais desani1nador em relação à !isca anterior é que mesmo que você a siga à risca, devido ao futo de cada contribuição para u1n cronograJna ser interdependente das outras, ainda é f.ícil os cronogramas sofrerem atrasos. Cada decisão que a equipe toma, de escolhas de projeto (design) às estimativas, será a base para muitas das decisões seguintes. Um descuido no início do processo, que seja descoberto mais tarde, terá um impacto ampliado no projeto. Esse efeito combinado nos cronogramas é facil de ser subestimado porque a causa e o efeito geralmente não são visíveis ao mesmo tempo (você pode ver o efeito bem depois da ocorrência da causa). Nos piores casos, quando vários descuidos imporc-.tntes acontecem, a probabilidade de um cronograma se manter íntegro é quase nenhuma (consulte a Figura 2-4).

Documento de visilo fraco ou inexistente

X Especificações mal-escritas ou inexistentes

X Estimativas de trabalho agressivas ou fracas

X lnexislencia de orçamento para integração

X lnexistencia de orçamento para iterações de UI --Cronograma com pouca possibilidade de sucesso

FIGURA 2-4. O efeito bola de neve.

E, é claro, isso se torna cada vez mais difícil. Pela fonna co1no a probabilidade funciona, a chance de u1na série de eventos independentes ocorrere1n equivale à multiplicação das chances de ocorrência de cada um dos eventos individuais (também

A VERDADE SOBRE OS CRONOGRJ.\MAS 49

conhecida co1no probabilidade composca). Porcanco, se a probabilidade de você cenninar esce capículo é de 9 e1n 10 (9/10), e a probabilidade de cern1inar o próxiino capículo é 9/10, a probabilidade cocal de cenninar os dois capículos não é 9/10: é 81/ 100. Isso significa que se a sua equipe cem 90°/o de probabilidade de cu1nprir os prazos a cada semana, ao longo do tempo as possibi lidades de ocorrência de atrasos aumentam continuamente. A probabilidade é fria e não tem coração, e ela ajuda a len1brar que a entropia esrá em todos os lugares e não é amiga de projetos ou de seus gerentes.

O que deve acontecer para que os cronogramas funcionem Agora que enrende1nos porque os cronogramas são tão difíceis de manter, posso oferecer reco1nendações sobre como 1ninimizar os riscos e maximizar os benefícios de qualquer cronogra1na de projeto. Essas abordagens e comportamentos perpassa1n os papéis ou experiências tradicionais, o que, na minha opinião, reflete a verdadeira natureza da elaboração de um cronograina. Como o cronogra1na representa a totalidade do projeto, a única mai1eira de usá-los de fonna efetiva é entender u1n pouco sobre tudo o que deve aconrecer para que o projeto seja bem-sucedido. É uma rarefu interdisciplinar e não apenas un1a atividade de engenharia ou de gerência.

• A du.ração dos marcos (milestones) deve ser compatível com a volatilidade do projeto. Quanto nlais alterações são esperadas, mais curros os 111arcos devem ser. Pequenos n1arcos preparam a equipe para ajustes mais faceis durante o projeto. Isso dá à gerência intervalos 1nais curtos entre as revisões e reduz os riscos de fazer alterações. A equipe pode ser preparada para esperar mudanças nas interseções entre marcos e, dessa forma, ela esperará alterações em vez de resistir a elas.

• Seja otimista na visão e cético no cronograma. U1n i1nportante desafio psicológico na elaboração de cronogramas é utilizar o ceticismo apropriado, sem diminuir a paixão e a morivação da equipe. Ao contrário da criação de um documento explicitando uma visão, onde o entusiasmo e o ori1nismo devem reinar, um cronograma deve vir da perspectiva oposta. Os números escritos para esrin1ar quanto ten1po as atividades devem consun1ir, requeren1 un1 respeito rigoroso e honesto à Lei de Murphy ("O que pode dar errado dará errado"). Os cronogra1nas não deveria1n refletir o que deveria acontecer ou poderia acontecer em condições óri1nas. E1n vez disso, um bom cronograma declara o que acontecerá - a despeito do faro de que várias coisas imporranres pode1n não ocorrer como esperado. É imporranre cer a equipe de teste/qualidade envolvida na elaboração do cronograma porque seus componentes naturalmente terão un1 ponro de vista n1ais cético e crítico sobre o trabalho de engenharia.

• Aposte no projeto (design). O processo do projeto constitui a melhor garantia contra a ignorlincia e os desafios inesperados. Melhores práticas de projeto são a única maneira de melhorar o trajeto da equipe através da i1nplemenração e de outras fàses. As habilidades para o projeto não são as mesmas requeridas para a implementação, e o prograrnador mais competente, ou o mais nípido, não será necessariamente o melhor projetista ou o rnelhor solucionador de proble1nas. Bons processos para o projeto não são ensinados e1n 1nuicos cursos na área de ciência da computação, a despeito de quão essencial é "pensar" os projetos de

50 A ARºíE DO GERENCIAMENTO DE PROJETOS

engenharia e definir abordagens adequadas para sua realização. Consulce os Capículos 5 e 6 para obcer 1nais infonnações sobre esce cópico.

• Planeje os pontos de verificação para as discussões sobre acréscimos e cortes. Os cronogramas deveria1n incluir períodos curcos de revisão onde os líderes poderiam avaliar o progresso acuai e considerar as novas infonnações ou os comentários dos clientes. Isso deve ser incorporado no cronogra1na mestre e ser uma parte explícita de qualquer contrato do projeto. Nessas revisões, itens de trabalho e recursos existentes podem ser excluídos, ou outros novos podem ser adicionados, de acordo con1 o resultado da análise da liderança sobre a situação corrente. Pontos naturais para essas revisões estão situados entre as F.1ses ou, de forma limitada, no final de cada fuse de projeto (design) ou irnple1nentação, mas elas podem ocorrer sempre que houver preocupações sérias ou discrepi!ncias óbvias entre o plano e a realidade. As metas dessas discussões deveriam ser o retorno do projeto ao bo1n senso, a revisão do cronogra1na, o escabelecimento de novas prioridades para os irens e o início da parte seguinte do projeto com clareza e convicção sobre o que virá a seguir (consulte os Capítulos 14 e 15).

• Informe a equipe sobre a filosofia do planejamento. Independencemenre da abordage1n ou técnica adorada para a elaboração do cronogra1na, ela deverá ser do conhecimento da equipe. Se os programadores e testadores rivere1n un1 entendimento básico sobre como os cronogramas funcionam e sobre a estratégia específica utilizada pela gerência no projeco acuai, eles cerão condições de fazer perguncas percinences e possibilidades de encender e acredicar no que esc.á sendo planejado.

• Ajuste a experiência da equipe ao espaço do problema. Urna das variáveis mágicas e1n um cronograma é o nível de experiência da equipe com o ripo de problemas que ela deve resolver. Se a equipe está desenvolvendo um site baseado em banco de dados, e cinco dos seis programadores já realizaram esse ripo de trabalho várias vezes, é lícito assumir que eles serão melhores na definição do projeto e na estimativa do trabalho do que uma equipe que nunca fez esse tipo de trabalho antes. Isso terá forre influência sobre o caráter conservador ou agressivo do cronograma.

• Mensure a confiança da equipe e a experiência no trabalho conjunto. Muito embora as esci1nacivas seja1n obtidas individualinence dos progra1nadores, esses profissionais escão trabalhando juncos corno u1na unidade para desenvolver algo co1npleco. Mesmo uma equipe de progra1nadores veceranos "superescrelas" não será cão eficience quanco esperado se eles não tiverem trabalhado juntos antes (ou enfrentado desafios in1porcanres juntos). O fato de solici tar a uma equipe recé1n-formada que trabalhe e1n um projeto grande e arriscado, ou se co1nprometa co1n u1n cronograma agressivo, deveria ser um sinal de aler ta.

• Assuma os riscos logo. Se você sabe que a Sally tem o componente mais complexo, lide com esses desafios no início do cronograma. Quanco maior o risco, mais tempo você desejará ter para tratar dele. Se você não cuidar dos riscos até a fase rnais adiantada do cronogra1na, terá menor número de graus de liberdade para responder a eles. O mesmo vale para riscos políticos, organizacionais e relacionados a recursos. Falaremos sobre o gerenciamento de itens de trabalho, no tópico sobre o pipeline da codificaçã.o, no Capítulo 14.

A VERDADE SOBRE os CRONOGRt\t\1AS 51

Resumo

• Os cronogramas rê1n rrês funções: pennirir que os compromissos seja1n assu1nidos, encorajar as pessoas a ver seus rrabalhos como un1a conrribuição para o todo e possibilitar o monitoramento do progresso. Mes1no quando os cronogran1as atrasam, eles ainda tê1n valor.

• Grandes cronogramas deveriam ser divididas em cronogramas menores para minimizar os riscos e aumentar a freqüência de ajustes.

• Todas as estimativas são probabilidades. Como os cronogramas são um conjunto de estimativas, eles também são probabilidades. Isso trabalha contra a exatidão dos cronogramas porque as probabilidades se acumulam (80ºAl x 80% = 64o/o).

• Quanto mais cedo as estimativas fore1n feiras, menos exaras elas serão. Entretanto, esti1nativas mais grosseiras são a linica maneira de fornecer un1

ponto de partida para outras estimativas 1nelhores.

• Os cronogramas devem ser desenvolvidos com ceticismo e não co1n orimismo. Invisca na fase do projeto para ressaltar as pren1issas e para gerar confiança.

Capítulo 3

Como resolver o que fazer

54 A AR-íE DO GERENCIAMENTO DE PROJETOS

P oucas pessoas concordam sobre como planejar os p rojetos. Freqüence1nence, duranre o planejamenco, grande parce do rempo é urilizada para que as pessoas concorde1n no modo como o planejamento deve ser feito. Eu acho que as pessoas fican1 obcecadas pelo planeja1nento porque ele é o ponto de contato para 1nuitas funções diferentes em qualquer empresa. Todos se sente1n motivados a se envolver quando as decisões importantes que estão em jogo irão afetar as pessoas durante meses ou anos. Há estín1tilo e energia renovados, inas ta1nbém o medo de que se a ação não for to1nada, as oportunidades serão perdidas. Essa combinação torna tudo mais fácil para que as pessoas assumam que sua visão de mundo é a mais útil. Ou pior, que ela é a única visão de mundo que vale a pena ser considerada e usada no processo de planeja.mente de projeto.

':A parte rnais diflcil da construção de um siste1na de software é decidir o que construir. Nenhumtl outra parte tÍíJ trabalho conceitua! é tão diflcil no estabelecimento de requisitos técnicos detalhados, incluintÍíJ as interfaces para usuários, para equipamentos e para outros

sistemas de software. Nenhuma outra parte do trabalho prejudica tanto os resultados se estiver errada. Nenhuma outra parte é 1nais d~flcil de corrigir poste1io1mente. Portanto, a

fanção mais importante que o desenvolvedor de sofiiuare executa para o cliente é a extração e refinarnento iterativos tÍíJs requisitos d.o produto. "

- Fred Brooks

Não é surpresa, então, 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 elaboração de cronogramas (o 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 fato de que não reconhece1n a existência de outras abordagens. Isso é estranho porque nenhuma dessas perspectivas -empresa, tecnologia, clienre - pode existir sem as outras. Alé1n disso, eu estou convencido de que o sucesso no planeja1nenro de projetos ocorre nas incerseções desses diferenres poncos de visca. Qualquer gerente que possa ver essas interseções te1n u1na grande vancage1n sobre aqueles que não poden1 percebê-las.

Portanto, este capítulo é sobre como abordar o processo de planejan1ento e obter urna visão de planejan1ento que tenha as 1naiores probabilidades de levar ao sucesso. Em pri1neiro lugar, eu preciso esclarecer alguns tennos e conceitos usados por diferentes estratégias de planeja1nento (é un1 assunto árido, nlas precisare1nos disso nos capítulos que se seguem). Quando civern1os ulcrapassado esse assunto, definirei e integrarei essas crês diferences visões, explorarei as questões a que os bons processos de planejamento responde1n e discutirei como abordar o trabalho diário para que o planeja1nento aconteça. Os capítulos a seguir detalharao resultados específicos, como documentos de visão (Capítulo 4) e especificações (Capítulo 7).

O planejamento de software desmistificado

Urn pequeno projeto de u1na pessoa para um site interno não requer o mesmo processo de planeja1nento de um projeto de US$ 1 O milhões para um sistema

COMO RESOLVER o QUE FAZER 55

operacional com tolerância a fàlhas envolvendo 300 pessoas. Em geral, quanco 1nais pessoas e maior a co1nplexidade com que você lida, 1nais estrucura de planejamenco precisa. Enrrecanto, 1nesmo u1n simples projeto, de uma só pessoa, é beneficiado pelo planeja1nenco. Ele fornece uma oportunidade de rever decisões, expor assuntos e esclarecer acordos entre pessoas e organizações. Os planos acuan1 como uma função compelidora contra todos os tipos de estupidez porque demandam que problen1as importantes sejam resolvidos enquanto há ren1po para considerar outras opções. Con10 dizia Abraham Lincoln, "Se eu tivesse seis horas para cortar tuna árvore, gasearia quatro horas afiando o machado", o que significa que un1a preparação inteligente minimiza o trabalho.

O planejamento de projetos envolve responder a duas questões. A resposta da primeira questão, "O que precisamos fàzer?" é geralmente denominada coleta de requisitos. A resposta à segunda questão, "Como fàremos isso?" é denominada projeto (design) ou especiflcaçã.o (veja a Figura 3-1 ). Um requisito é uma descrição cuidadosamente escrita de u1n critério que se espera que o trabalho satisfaça. (Por exe1nplo, urn requisito para preparar uma refeição poderia ser fazer urna cornida barata que seja gostosa e nutritiva.) Bons requisitos são fáceis de entender e difíceis de ser mal-interpretados. Pode haver diferences 1naneiras de projetar algo para acender a um requisito, 1nas deve ser fácil reconhecer se o requisito foi acendido quando examinamos uma parte concluída do trabalho. V1na especificação é si1nplesmence um plano para criar algo que curnprirá os requisitos.

Requisito Projeto/Especificação Implementação

j O que precisamos fazer? ~ 1 Como o faremos? i 1 Faça-o 1 FIGURA 3-1. Uma visão extremamente simples, mas útil de planejamento. Se você não sabe o que precisa fazer, é muito cedo para resolver como fazê-lo.

Essas crês atividades - coleta de requisitos, projeto/especificação e imple1nencação - são assuntos importantes e n1erece1n ter seus próprios livros (consulce a Bibliografia cornenrada). Eu abordarei os dois primeiros assuntos a partir da perspecciva do nível de projeto nos dois capítulos seguintes, e a irnplernencação será enfocada mais adiante neste livro (Capículos 14 e 15).

Diferentes tipos de projetos

Vários critérios alteram a natureza de como os requisitos e trabalho de projeco (design) são realizados. Eu usarei três exe1nplos de projetos simples e diversos para ilustrar esses critérios: 1

• Super-homen1 solitário. No projeto mais simples, apenas urna pessoa está envolvida. De escrever o código, fàzer o planejamento comercial, a preparar seu próprio almoço, ela faz tudo sozinha e é sua própria fonte de recursos.

• Equipe pequena contratada. Uma firma com 5 ou l O programadores e um gerente é contratada por um cliente para construir um site ou um aplicativo de software. Eles esboçam u1n contrato que define os compromissos firmados.

56 A AJ,-íE DO GERENCIAMENTO DE PROJETOS

Quando o contrato cennina, o relacionamento tarnbém cennina, a menos que um novo conrraro/projero seja iniciado.

• Equipe grande. Uma equipe de ce1n pessoas contratadas por uma corporação começa a trabalhar ern uma nova versão de algo. Pode ser um produto vendido ao público (também conhecido como pacote ou shrink-wrap) ou algo usado internamente (internalware).

Esses três tipos de projetos diferem en1 tamanho de equipe, estrutura organizacional e relacionan1entos de autoridade, e as diferenças entre eles estabelecem distinções importantes sobre como devem ser gerenciados. Portanto, embora seu projeto possa não corresponder exatamente a esses exemplos, eles serão pontos de referência úteis nas seções a seguir.

Como as organizações impactam o planejamento

Com os três tipos de projetos em n1ente, pode1nos examinar os critérios básicos para o planejamento de projeto. E1n um projeto, a qualquer mo1nento existem questões básicas para as quais rodos devemos conhecer as respostas. As respostas calvez nem sempre sejam agradáveis, 1nas você e sua equipe deveria1n saber quais são. Grande parte da frustração do planejainenro ocorre quando há divergência ou ignorância sobre essas questões.

• Quem tem autoridade para de61úr os requisitos? Alguém ren1 de definir os requisitos e fazer con1 que sejam aprovados pelas partes interessadas (cliente ou VP). No caso do super-hon1em solitário, é fácil: o super-hon1em terá roda a autoridade desejada. Em u1na equipe sob contrato, será o cliente que desejará um controle rígido sobre os requisitos e possivelmente sobre o projeto. Por último, uma grande equipe pode ter comissões ou outras divisões na corporação que precisarão ser atendidas pelo trabalho (e aqueles cuja aprovação de alguma maneira é necessária). Pode haver pessoas diferentes com autoridade para requisitos de alto nível ("O produto será. um veículo utilitário esportivo") e autoridade para requisitos de baixo nível ("Percorrerá 20 1nilhas por galão de combustível e terá tração nas quatro rodas").

• Quern tem autoridade para o p rojeto (design)? Con10 nos requisitos, algué1n tem de definir o projeto (design) do trabalho. O projeto é diferente dos requisitos porque exiscern sempre rnuiros projetos diferentes possíveis para atender a u1n conjunto de requisitos. Os projetos, assim como os requisitos, são freqüenre1nenre negociados entre duas ou mais partes. U1na pessoa ou equipe pode ser responsável por conduzir o processo de projeto e desenvolver a idéia (designer), e outra equipe fornece a orientação e co1nenrários sobre o trabalho do primeiro grupo (VP). Observe que como a habilidade de projeto (design skill) está distribuída no universo e independe do poder político, as pessoas que receben1 a autoridade sobre o projeto (design) não devem ser pessoas que tenha1n 111uito talento para projeto (design).

• Qucn1 tem autoridade técnica? A autoridade técnica é definida por quem escolhe as abordagens de engenharia que serão usadas, incluindo as linguagens de programação, as ferramentas de desenvolvimento e a arquitetura técnica.

COMO RESOLVER o QUE FAZER 57

Muitas dessas decisões pode1n i1npactar os requisitos, o projeto (design) e o orçamento. A diferença entre as decisões técnicas e as decisões de projeto é sutil: o n1odo co1no algo se co1nporta e sua aparência freqüentemente rê1n muito a ver con1 a 1naneira como ele foi construído. Em algu1nas organizações, a autoridade técnica suplanta a autoridade para requisitos e projeto. Em outras, é subordinada a elas. Nas melhores organizações, há uma relação de colaboração entre todos os tipos de autoridade.

• Quem tem autoridade para orçamento? A capacidade de adi.cionar ou ren1over recursos de un1 projeto pode ser independente de outros tipos de autoridade. Por exemplo, na situação da equipe sob contrato, a equipe deve ter o poder de definir os requisitos e projeto, mas precisa retornar ao cliente cada vez que quiser mais dinheiro ou tempo.

• Con1 que freqüência os requisitos e projetos (design) serão revistos e como os ajustes serão decididos? A resposta depende muito das questões anteriores. Quanto mais pessoas envolvidas nos requisitos, projeto (design) e orça1nentos, mais esforços precisarão ser gastos para mantê-los em sincronia durante o projeto. Como regra geral: quanto menos autoridade você te1n, 1nais diligente precisa ser sobre as decisões de revisão e aprovação, assim como na definição dos ajustes.

E1nbora eu tenha identificado diferentes tipos de autoridade, é possível que uma única pessoa possua várias delas ou todas. Entretanto, na maioria das vezes, a autoridade é distribuída entre os líderes da equipe. Quanto mais co1nplexa for a distribuição da autoridade, mais esforço de planejamento você precisará para ser efetivo. No Capfrulo 16, abordarei con10 lidar com situações onde você precisa de mais autoridade do que a que tem. Por enquanto, basta reconhecer que o planejamento envolve esses diferentes tipos de poder.

Resultados comuns do planejamento

Para comunicar os requisitos, alguém tem de escrevê-los. Existem muitas maneiras de fazer isso e eu não estou advogando nenhum método específico. O que importa é que as informações corretas sejam obtidas, as pessoas certas possam discuti-las facilmente e bons acordos sejam feitos para que o trabalho possa ser executado. Se a 1naneira como você docu1nenta os requisitos f-az tudo isso, excelente. Se não fuz, então procure um novo 1nétodo co1n esses critérios e1n mente.

Como referência, 1nencionarei alguns dos 1nodos 1nais comuns de documentar requisitos e informações de planejamento. No mínimo, o conheci1nento do jargão comum ajuda a compreensão dos vários 1nérodos usados por diferentes organizações. Você achará que algumas equipes documentam os requisitos de 1naneira infonnal: "Oh, requisitos - vá falar con1 Fred". Outros têm 1nodelos elaborados e procedi1nentos de revisão que divide1n esses docun1entos em partes muito pequenas (e possivelinente sobrepostas) pertencentes a pessoas diferentes.

• Docun1ento de requisitos de marketing (marketing 1·equirements dacurnent, MRD). Essa é a análise global preparada pela equipe co1nercial ou de marketing. O objetivo é explicar quais oportunidades comerciais existem e

58 A AJ,-íE DO GERENCIAMENTO DE PROJETOS

como um projeto pode explorar essas oporcunidades. E1n algu1nas organizações, esse é utn documenro de referêncÍ<t para ajudar aos romadores de decisão e1n suas opiniões. E1n oucras organizações, ele é o núcleo da definição do projeto e cudo o que se segue deriva fortemente dele. Os MRDs ajuda1n a definir o "o quê" de um projeto.

• Docu1nento de visão/escopo. Um documenco de visão encapsula em uma única con1posição todas as opiniões disponíveis sobre o que um projeto pode ser. Se houver um MRD, um documento de visão deve ser derivado dele e se referenciar a ele. Un1 docun1enro de visão define as 1necas de un1 projeco, por que elas fazem sentido e quais serão os recursos de alco nível, requisicos ou datas para u1n projeto (consulte o Capítulo 4). Os documentos de visão definem diretamente o "o quê" de um projeto.

• Especificações. Abordarn qual deve ser o resultado final do trabalho para uma parte do projeto. Boas especificações cêrn origem em um conjunco de requisitos. Elas são encão desenvolvidas acravés de um trabalho de projeto iterativo (consulce os Capículos 5 e 6), o que pode envolver a modificação/melhoria dos requisicos. As especificações escão completas quando fornecem urn plano executável que a engenharia pode usar para preencher os requisitos (a quantidade de detalhes que elas precisan1 ter é totalrnence negociável con1 a engenharia). As especificações devem derivar dos docutnencos de visão. As especificações definen1 o "como" de um projeto a parcir de u1na perspecciva de engenharia e projero.

• WBS, estrutura analítica de projeto ( Wórk breakdotvn structure). En1bora uma especificação detalhe o trabalho a ser feiro, uma WBS define como uma equipe de engenheiros procederá ao executá-lo. Que trabalho sen\ executado em primeiro lugar? Quem o executará? Quais são todas as parres 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 Capítulos 7 e 13 tratarão das atividades do tipo WBS. A WBS define o "como" de u1n projeto a partir da perspectiva de u1na equipe.

Abordando os planos: as três perspectivas

Você pode ter observado como cada um dos resultados mencionados anteriorrnenre representa urna das duas perspectivas a respeito do projeto: empresarial ou de engenharia de softzvare. Em muitos projecos, essas duas visões con1pete1n enrre si. Esse é um erro de planejamento fundamental. O planejamenro raramenre deve ser utna experiência do ripo binária, ou sin1 ou não. E1n vez disso, ele deve ser u1na inregração e síntese e1n que rodos pode1n contribuir.

Para fazer isso acontecer, u1n gerente de projeto deve reconhecer que cada perspecriva contribui com algo único que não pode ser substituído por algo mais (isto é, nenhuma contribuição maior da estratégia de marketing melhorará a competência da engenharia e vice-versa). Para bons resulrados, rodos os envolvidos e1n planejamenco de projeco devem cer uma compreensão básica de cada perspectiva.

COMO RESOLVER o QUE FAZER 59

AVISO

A abordagen1 de planeja1nento a seguir é baseada na indúscria. Se encontrar questões ou situações que não se aplicain devido ao ca1nanJ10 da sua equipe ou escopo do seu projeto, fique à voncadc para apenas folhe-á-la ou passar adiance. Eu não espero que cud.o que estou abordando aqui se apl ique a todos os projetos. Encrecanto, esrou rencando criar valor para você não apenas neste projeto, n1as ca1nbén1 nos próxi1nos. Exisre1n ângulos e questões aqui que provarão ser úteis para você a longo prazo, rnesmo que alguns deles não se ap liquem ao que você esní executando hoje.

A perspectiva empresarial

A visão empresarial enfoca questões que i1npacca1n a contabilidade de lucros e perdas (L&P) de u1na organização. Isso inclui vendas, lucros, despesas, concorrência e custos. Todos devem entender seus den1onstrativos de lucros e perdas: é o que paga seus salários ou seus contratos. Quando a equipe de engenharia não ce1n conhecitnento de co1no seu próprio negócio funciona, 1nuitas decisões tomadas pela adminisrração parecerão ilógicas ou estúpidas. Assim, é de interesse de rodos que são responsáveis pelo planeja1nento da empresa ajudar as outras pessoas a entender suas razões. No setor tecnológico, as pessoas com cargos como analista de negócios, marketing, desenvolvin1ento de negócios, planejador de produto ou gerente sênior representam a perspectiva da en1presa.

Alguns projetos rên1 várias perspecrivas e1npresariais. Se você trabalha para uma firma contrarada para construir um servidor de banco de dados, ce1n de considerar os interesses empresariais da sua firma, assim como os interesses empresariais do cliente ao qual você está atendendo (espera-se que eles estejam alinhados entre si). A interseção dessas perspectivas pode ficar complicada; aqui eu a manterei simples e assumirei que todos os projetos requerem equipes 1naiores. Entretanto, deveria ser fácil extrapolar as questões a seguir para situações 1nais complexas.

Uma boa perspectiva empresarial significa que a equipe tem respostas para . as seguintes perguntas:

• Quais são as necessidades ou desejos não-acendidos dos nossos clientes?

• Que recursos ou serviços que atendam a essas necessidades ou desejos poderão ser fornecidos?

• Em que base os clientes comprarão esse produto ou serviço? O que os motivará a comprá-los?

• Qual será o cusro (pessoas/recursos)? Ao longo de qual período de rempo?

• Qual o potencial de receita (ou de custos de operações organizacionais reduzidos) existente? Ao longo de qual período de ce1npo?

• O que deixaremos de desenvolver para. que possa1nos desenvolver esse produto ou serviço?

• .Ele contribuirá para a nossa estratégia de negócios a longo prazo ou protegerá outros irens que geram receita? (Mesmo organizações se1n fins lucrativos ou de TI rêm u1na esrrarégia empresarial: sempre há concas a pagar, receiras a receber ou necessidade de dar suporte a grupos que gera1n receitas.)

60 A AJ,-íE DO GERENCIAMENTO DE PROJETOS

• Co1no isso nos ajudará a igualar, obcer vancagem ou superar os concorrences?

• Quais são as janelas de cen1po de mercado que deve1nos ter co1no objecivo para esce projeco?

Os responsáveis pela perspectiva e111presarial têm visões firmes sobre a importância dessas questões. Eles acreditam que as respostas representam um futor importante para a organização e devem influenciar fortemente nas decisões do projeto.

Entretanto, a visão empresarial não significa que todos os projetos devam escar atrelados à receica. Em vez disso, ela avalia os projetos com base em suas contribuições para a estratégia da empresa. Por exemplo, um projeto estratégico poderia ser essencial para a organização mas nunca gerar receita.

Marketing não é uma palavra proibida

A crícica mais injusta sobre o pessoal de negócios é que eles são apenas "111a rqueteiros", u111 rótulo u111 tanto negativo na área tecnológica. Eu acho que o 111arkecing 1nerece uma ressalva. Em cennos de MBA, existem quatro Ps que definem o 1narkecing: produto, preço, praça (placement) e promoção. A definição de produto e preço é um processo criativo. O objetivo é desenvolver u1na idéia do produco - vendido para obter um lucro - que acenda às necessidades do cliente alvo. Pesquisa, análise e trabalho criativo são necessários para o sucesso. Praça {ou local, ou position), o terceiro P, diz respeito a como os clientes obterão o produto (através de u1n site? No supermercado? No porca-malas do carro de Fred?).

Finalmente, promoção - que é freqüenten1ence o escereócipo associado ao marketing - é como difundir a palavra posiciva sobre o produto para pessoas influentes e clientes pocenciais. Surpreendentemente, a pro111oção conscicui u1na pequena parte do tempo do analista de negócios ou do gerente de produto (talvez 10-200/o). Portanto, os planejamentos de marketing definem muito mais do que os anóncios possam indicar ou de quais acordos promocionais serão feitos . Além disso, noce que os quatro Ps do marketing se aplicam a quase tudo. Há sempre um produto (site de RH), um preço (grátis), um local (incranet) e uma promoção (e1nait} para ele.

Mas quando a perspectiva empresarial é tratada isoladamente, ela mostra apenas u1n terço do que é necessário. A qualidade de um produto influencia as vendas, mas a qualidade não é proveniente do marketing. A qualidade2 é proveniente de algum projeto de engenharia be1n-sucedido que satisfaz necessidades reais do cliente. U1n planejamento e1npresarial proposco que seja centralizado nas possibilidades tecnológicas (em vez de em conjecturas) se tornará um bom negócio.

U1n gerente de projeto, que usa apenas urna perspectiva e falha, talvez nunca encenda o que realmente deu errado. Sua tendência será trabalhar ainda mais dentro da 1nesn1a perspectiva em vez de alargar a visão.

A perspectiva tecnológica

No período em que estudei ciência da computação na Universidade Carnegie Mellon, era comum conversar com professores e alunos sobre novos produtos. Nós sen1pre focávamos nos componentes que esses novos produtos de software

COMO RESOLVER o QUE FAZER 61

usava1n e como eles se comparava1n com os que poderiam rer sido urilizados. O valor era impliciramence definido co1no qualidade de engenharia: o quanto era1n confiáveis e de dese1npenho efetivo, ou o quanto de vantagem obtinham pelo uso da tecnologia mais recente. En1 geral, achávamos tudo péssimo. Pouquíssimos produtos podiam resistir às nossas críticas. Nós nos perguntávamos por que o nlercado era composto de 1nediocridade e desapontamento. Até inventamos teorias conspiratórias bizarras para explicar as decisões do mal, que iinagináva1nos que fossem tomadas contra a pureza da engenharia e, dessa forma, fazia1n pouco ou nenhum sentido para nós. Freqüentemente, responsabilizáva1nos os departamentos de marketing dessas companhias3 (embora poucos de nós entendêssemos o que os profissionais de marketing fi1ziam) . Mesmo nos meus primeiros anos no setor, esses mesmos tipos de conversas ocorreram várias vezes. Só que, então, havia uma análise mais minuciosa porque estávamos concorrendo com muitos produtos ou sites sobre os quais falávamos.

Quando observávarnos o mundo, víamos somente as tecnologias e seus rnéritos de engenharia. Nunca entendemos por que produtos com uma tecnologia deficiente às vezes vendiam rnuito be1n ou por que producos com boa tecnologia algumas vezes não vendiam be1n. Nós também observávamos que a qualidade da engenharia nem sempre tinha relação co1n a satisfação do cliente. Para esses 1nistérios, rínhamos duas respostas. Primeira, isso tinha alguma coisa a ver com os poderes mágicos do pessoal de 1narketing do mal. Segunda, precisávamos de clientes n1ais inteligentes. Mas nós não pensávarnos rnuito sobre nossas conclusões. E111 vez disso, voltávan1os a programar ou a buscar outros produtos que pudéssemos rasgar em pedaços. Só tive condições de perceber as limicações da tninha visão depois de cer ouvido alguns profissionais de marketing inteligentes e alguns designers de produto talentosos.

A visão da tecnologia valoriza mais o modo como as coisas devem ser , conscruídas. E uma n1entalidade voltada para a construção e os materiais. Há uma estética associada a ela, nlas a partir da perspectiva da tecnologia e não da perspectiva do cliente. Há um viés para a criação das coisas, etn vez da compreensão de como, uma vez criadas, essas coisas ajudarão a empresa ou o cliente. Na visão estereotipada da engenharia, um banco de dados que atenda à estética do engenheiro é suficiente, mesmo que nenhurn cliente possa imaginar o que Fazer com ele, ou se ele não atingir as projeções de vendas.

Apesar desse último parágrafo parecer crít ico, muitas questões importantes são provenienres de uma visão apenas recnológica:

• O que ele (o projeto) precisa fuzer?

• Co1no ele funcionará? Como cada um de seus componentes funcionará?

• Como o conscruire1nos? Como verificare1nos se ele funciona da maneira esperada?

• Quão confiáveis, eficiences, extensíveis e executáveis são os siste1nas acuais ou aqueles que somos capazes de construir? Há alguma lacuna entre isso e o que o projeto requer?

• Que tecnologias ou arquiteturas estão prontamente disponíveis? Estamos apostando em novas tecnologias que ainda não estão disponíveis, mas que estarão em breve?

• Que processos e abordagens de engenharia são apropriados para essa equipe e esse projeto?

62 A AR-íE DO GERENCIAMENTO DE PROJETOS

• Que conheci1nenro e habilidade aplicáveis nosso pessoal rem? No que eles não esrarão rrabalhando para trabalhar nesse projeto?

• Co1no preencheremos as lacunas na experiência? (Treinar/conrrarar/aprender/ ignorar e esperar que as lacunas desapareçam co1no por 1nágica.)

• Quanro rempo levará para ser construído, en1 que nível de qualidade?

A perspectiva do cliente

Essa é a mais importante das crês perspectivas. Como o projeto é feiro para servir ao cliente (e calvez servir à empresa, 1nas apenas por 1neio do serviço ao cliente), a maior energia deve ser gasca na compreensão de que1n são os clientes. Isso inclui escudar o que os clientes faze1n rodos os dias, con10 eles o fazem acual1nente e que 1nodificações ou 1nelhora1nenros seriain valiosos para ajudá-los a fàzer o que faze1n . Sem essas infonnações, a engenharia e a empresa esrão arirando no escuro.

Mas, infelizmente, a perspectiva do cliente é a mais fraca em muitas organizações. Ela em geral recebe a menor equipe e menos suporte de orçamento. Na maioria das organizações há 1nenos pessoas que foran1 treinadas para compreender e projetar (design) para clientes do que suas contrapartes de negócio e tecnologia. E mesmo quando especialistas em clientes são contratados (como projetistas de interfaces de usuário ou engenheiros de usabilidade), eles são freqüen ternente restritos a funções limi tadas no processo de tomada de decisão do projeto e recebem pouca autoridade em relação aos requisitos ou ao projeto.

Em rodo caso, o ponto de vista do cliente é construído a partir de duas fontes diferentes: solicitações e pesquisa. As solicitações são tudo que o cliente explicitamente pergunta ou reclaina. Esse tipo de informação é valiosa porque o cliente tem 1naior 1notivação para identificar esses problemas ("Sim, meu computador explode se1npre que eu aperto a barra de espaço"), 1nas cambé1n é problemática porque, na maioria dos casos, os clientes não são designers. Eles freqüentetnente obscurece1n a distinção entre problemas que precisam ser resolvidos e as 1naneiras específicas de resolvê-los. Eles podem solicitar explicitainente um recurso, como u1na visualização de impressão, se1n descrever o problema real (as pessoas desperdiçam 111uiro papel). Se a equipe de projeto puder con1eçar entendendo o problen1a, calvez haja 1nuicas 1naneiras n1ais baratas ou m.elhores de resolvê-lo do que as solicitações de recursos. Mesmo designers experientes freqüenten1ente têm dificuldade para projetar para si próprios.4

Existetn dois tipos de especialistas que encende1n os clientes e projetam para eles: engenheiros de usabilidade (usability engineers) e projetiscas/designe1:r de produtos (product designers). Engenheiros de usabilidade são especialistas e1n entender como as pessoas trabalham e fornecem 1nétricas e pesquisa para ajudar as equipes de projeto a ton1ar boas decisões desde o primeiro dia de planejamento do projeto. Os designers de produto ou designers de interação, são pessoas treinadas em pegar esses dados e convertê-los em bons projetos para sites ou produtos para a Web. Se sua organização teve a sorte de empregar esses excelentes profissionais, envolva-os o mais cedo possível no projeto. Peça para eles serem advogados desse ponto de vista. Caso esteja trabalhando se1n eles, você estará em u1na desvantagem distinta corn relação aos seus concorrentes. Considere a possibilidade de contrarar alguém para consulrar e aconselhar sobre onde esses esforços seriam mais imporcanres.

COMO RESOLVER o QUE FAZER 63

Sem a ajuda de um especialisca, o gerence de projeco deve concinuar por sua conca. Isso é possível, mas como é a perspecciva rnenos inceressance para pessoas com experiência em engenharia e é a rnenos encendida pelo gerence sênior, nonnaln1ence ela cem menos suporte do que oucros poncos de visca. Recursos e experiência precisam ser investidos na perspectiva do clience para manter o equilíbrio con1 as perspectivas tecnológica e empresarial. Do contrário, surpresa: a perspectiva do cliente não terá credibilidade e não será ouvida.

As perguncas importantes da visão do clience são:

• O que as pessoas realmente fi1ze1n? (Não o que nós pensamos que elas fazem ou o que elas dizem que fazem.)

• Que problemas elas cêm ao tentar fazer essas coisas? Onde elas ficam empacadas, confusas ou frustradas?

• O que elas precisarn ou desejam fàzer rnas não se sencern capazes?

• Onde escão as oportunidades específicas para fazer as coisas de 1naneira mais f:-lcil, segura, rápida ou mais confiável para elas?

• Que idéias de design para 1nelhorar o 1nodo co1no a coisa deve funcionar - em cennos do que as pessoas realinence fazem - cê1n o maior pocencial para 1nelhorar a experiência do clience?

• Con10 essas idéias podem ser exploradas? Que protótipos, esboços ou alcernativas precisarn ser investigadas para nos ajudar a entender o potencial para o projeto?

• Que idéias e conceitos principais o projeto deve usar para expressar as informações para os usuários?

A mágica visão interdisciplinar

Esses crês pontos de visca sempre se sobrepõem. Toda consideração da en1presa te1n iinplicações cécnicas e para o cliente (o que é verdadeiro para rodas as oucras pennutações). Portanto, obcer a 1nelhor perspecciva de planejarnento exige expor cada visão em condições iguais e ver onde estão as semelhanças e as diferenças. Algumas decisões que favoreçam uma perspectiva e1n detrimento da outra precisarão ser tomadas, n1as isso não pode ser feito por acidente. Devem ser apoiadas por uma estratégia inteligente derivada da obtenção da nlaior quantidade de valor possível de cada perspectiva .

Investindo um cempo na exploração das crês perspectivas, é possível ver as oportunidades para as decisões estratégicas inteligentes. Será possível satisfàzer algumas dessas questões ou objetivos importantes de cada urna das três perspectivas definindo urna meta de projeto onde as três perspectivas se sobrepõem. Essas são áreas que têm o maior valor potencial para a organização porque podem tracar simulraneamence dos objetivos empresarial, cecnológico e do cliente.

Quase cão i1nporcante quanto seu valor de planejamento escratégico, o uso de urn Diagrarna de Venn (corno o da Figura 3-2) pode neutralizar os vieses das perspeccivas de engenheiros e profissionais de marketing. Ele ajuda as equipes a visualizare1n os poucos de vista sobrepostos, em vez de apenas os concorrences. No início e freqüencemente durante as discussões de planejamento do projeco, esse

64 A AR·íE DO GERENCIAMENTO DE PROJE1-os

diagrama ou algurn corno ele (por exemplo, um diagrama que inclua uma !isca de objetivos porenciais de cada perspectiva) pode ser usado para esrrururar as sugesrões feiras por pessoas que rêm um viés para u1na visão do projeco. Quando as idéias são sugeridas, elas pode1n ser n1apeadas ern relação a esse diagra1na para ver como contribuem para todas as perspectivas. O GP desempenha um papel importante para que isso aconteça, usando sua natureza generalista de forma proativa para unificar as três visões en1 uma.

Empresa

Tecnologia

FIGURA 3-2. As três perspectivas

Uma maneira de fazer isso é estabelecer, logo no início, que se1npre haverá excelentes idéias tecnológicas que não beneficiam a empresa ou o cliente, assin1 como excelentes idéias que podem ajudar o cliente e que não são viáveis para a e1npresa ou possíveis com a tecnologia atual. Isso dá a rodos o poder para identificar idéias em uma dimensão e solicitar a contribuição dos outros. Além disso, gera respeito pelas perspectivas porque todos são forçados a perceber que precisam colaborar com as pessoas que têm o conhecimento que eles não possuem para que sejam ben1-sucedidos.

Mas se não for feito nenhum esforço para resolver os pontos de vista divergentes, os conflitos raramente serão enfrentados. E1n vez disso, as reuniões de planejamento de projeto se tornarão campos de baralha para ataque e defesa de opiniões baseadas nessas linhas de perspectiva (e não nos verdadeiros méritos das idéias). Freqüentemente quando era consultado por equipes de projeto, o problerna para o qual pediam minha ajuda nada tinha a ver com a habilidade de planejar um projeco. Em vez disso, havia conflitos de opiniões não-resolvidos e acé mes1no não-verbalizados, sobre por que u1n departamenco - engenharia ou n1arketing, por exen1plo, era mais importante que o outro. Suas perspectivas singulares não apenas causavain o problema co1no tan1bém tornava in1possível ver a causa dele.

Anos atrás, eu estava envolvido ern urna dessas guerras estúpidas. Eu era o gerente de prograrna de recursos de pesquisa na Web no Incernec Explorer 4.0. Duas pessoas de desenvolvimento empresarial nos foram designadas e elas estavam negociando contratos com os principais mecanismos de pesquisa da época (Excite, Yahoo!, Lycos, Alta Vista etc.). Nós discutin1os com esses especialistas em negócios sobre decisões de projeto, debatendo concinuamenre sobre o que era melhor para o cliente versus o que era melhor para a empresa. Cada um de nós acreditava que mantinha a autoridade (eu fàlava pela equipe de projeto/engenharia e eles

COMO RESOLVER o QUE FAZER 65

forneciam os argumentos e1npresariais.) Discutimos os mesmos pontos por se1nanas, sempre debatendo as decisões específicas e nunca voltando para avaliar nossas filosofias ocultas sobre o que constituía um bo1n produto. As coisas iam cão mal que trouxen1os nosso gerente de grupo para nos ajudar a elaborar um . con1pron11sso.

Estou convencido de que uma visão mais abrangente do mundo teria ajudado a todos os envolvidos. Todos nós estávamos tão investidos de nossos egos e crenças que gastan1os 1nuito tempo discutindo pontos se1n importância, em vez de trabalhar para entender rodas as perspectivas sobre o que estávamos criando. Um docu111ento de visão melhor poderia cer ajudado, mas isso era impossível porque os desafios empresariais da Internet eram muito novos para o setor (por volca de 1997). Entretanto, se tivéssemos compartilhado o conhecimento, em vez de resistir a ele, poderíamos ter tido a oportunidade de chegar a um compromisso mutuamente benéfico.

Trazer uma visão interdisciplinar para um projeto pennite fazer escolhas que perpassa1n as mesrnas fron teiras que li1nitam seus concorrentes. També1n proporciona argumentos mais forces para qualquer decisão que você come. Em vez de apenas afirmar que um projeto específico será 1nais fácil de criar, você também pode dizer por que o 1narkecing encontrará mais oportunidades para vender esse projero (desde que, claro, você não esteja apenas criando essas alegações). AJgu1nas vezes, isso exigirá que você faça sacrifícios. Quando esriver procurando as nielhores soluções, elas nern sernpre corresponderão ao que você ten1 talento para fazer, ou às idéias que pessoalmente prefere. Mas se você for capaz de fazer esses sacrifícios, ganhará a convicção e a sinceridade necessárias para obter o 1nes1no dos outros. Você pode então pedir às outras pessoas que apresentem suas idéias sobre o que é melhor para o projeto. As pessoas endossarão decisões com as quais não concordam co1npleramenre se vire1n que uma mente aberra, trabalhando nos interesses do projeto, está subjacente a essa tomada de decisões.

O equilíbrio de poder

Se você trabalha em uma grande organização, deve considerar um cerco fator político para contrabalançar a visão de um projeto. Eu chamo esse fator de proporção de poder (power ratio). Como o poder no projeto é distribuído pelas pessoas que representam essas três visões? Por exemplo, se os engenheiros excederem os analistas de negócios em 3: 1, a visão da engenharia renderá a do1ninar as decisões. A proporção de poder é si1nplesmente a proporção do núrnero de pessoas predispostas a urna detenninada visão. Para ter u1na perspectiva equilibrada, a proporção deve ser 1: 1: 1 (engenharia para negócios para cliente). A proporção de poder natural é a contagem pura de pessoas que têrn experiência em cada visão. Quanto mais desequilibrada for essa proporção, rnaior será a tendência em relação a uma derenninada perspectiva.

Mas o simples número de pessoas não define a quantidade de poder que elas tên1. O exército de Napoleão tinha milhares de soldados, 111as só havia urn Napoleão. Pode haver 1 O programadores e un1 1 profissional de marketing (10:1:0), mas este pode ter tanto poder sobre o projeto, dada a sua função ou experiência, quanto os outros combinados. Isso significa que um gerente pode

66 A AR"íE DO GERENCIAMENTO DE PROJETOS

cornpensar qualquer proporção natural concedendo poder àqueles que devem cer mais influência no projeto. E corno a natureza de um projeto se altera ao longo do rempo, diferences perspectivas deve1n ter mais poder em diferences períodos. Considere como você pode delegar decisões (consulte o Capítulo 12) para descobrir o equilíbrio certo para o projeto na hora cerra.

Fazendo as perguntas certas

A maneira rnais simples de estruturar urn trabalho de planejamento é refinar um conjunto de perguntas que o trabalho de planejamento precisa responder. Elas devem ser elaboradas a partir das três perspectivas com a intenção de combiná-las em um único plano. Inicialmente, elas podem ser exploradas de modo independente. Urna definição inicial do projeto pode permitir alterações, elas só precisam ser estruturadas. "fodos devern saber que tudo isso será, reunido em MRDs (documento de requisitos de marketing) ou docurnento de visão, o que exigirá muitas discussões que cornbinem o pensarnento dos negócios, da engenharia e do cliente em um único plano.

As perguntas (freqüentemen te denominadas perguntas de planejarnento de projeto) devem ser elaboradas a partir das crês !iscas discuridas anreriormenre, com base nas suas relevâncias para o projeto no qual você esrá trabalhando. Se esse for urn projeto novo (não urna versão 2), você precisará de perguntas básicas para definir os conceitos básicos. Se for uma pequena atualização para urn sistema existente, talvez haja algumas perguntas relativas a negócios e a cliente que devam ser consideradas. Mas independente do ripo de projeto, faça o exercício de examinar as perguntas. Esse exa1ne excluirá os assuntos e idéias que não foram reconhecidos e dará a rodos um ponto de partida para discuti-los.

Essa lista de perguntas sobre o planejamento de projeto deve ser livre da maioria dos lin1ices definidos pelas perspectivas. Em vez disso, você terá u1n ponto de vista holístico do projeto, que pode ser dividido, conforme o necessário, em considerações de engenharia, negócios ou cliente. Por exemplo, a lista a seguir mostra versões mais complexas das perguntas relacionadas anrerionnente:

• Quais são os três ou quatro agrupamentos úteis que podemos usar para discutir os diferentes tipos de clientes que ternos? (Por exemplo, para um processador de texros seriam estudantes, profissionais e usuários dornésticos. Para um banco de dados de TI, esses clientes poderiam ser vendedores, recepcionistas e executivos.) Como suas necessidades e comporramenros diferem?

• Que inforrnações demográficas podern nos ajudar a entender quern são esses clientes? (Idade, renda, ripo de e1npresa, profissão, educação, outros produtos adquiridos ou sites utilizados etc.)

• Ern que atividades cada grupo de usuário está usando nosso produto? Co1no isso corresponde à finalidade para a qual eles comprara1n o produto? Con10 isso corresponde ao modo como nós divulgan1os o produto? Que problemas eles têm ao usar o produto para satisfàzer suas necessidades?

• Quem são nossos clientes potenciais e que recursos, cenários ou tipos de produtos precisarían1os fornecer para torná-los nossos clientes? (Quais são os perfis demográficos desses novos clientes?)

COMO RESOLVER o QUE FAZER 67

• Temos tecnologia e experiência para criar algo que satisfaça essas necessidades e problemas? {Para cada necessidade identificada, respostas si1n, calvez e não, podem freqüente1nente ser suficientes ao 1nenos co1no um primeiro passo.)

• Podemos criar a tecnologia e obter a experiência para criar algo que satisfaça as necessidades e proble1nas? (Sim, talvez, não.)

• Existem oportunidades significativas em um novo produto ou linha de produtos? Ou as necessidades estão diretamente vinculadas ao produto atual ou à linha de produtos?

• Existem modelos de negócios viáveis para usar nossa experiência e tecnologia para resolver esses problemas ou necessidades identificados? (Os lucros excederão os custos em uma linha de tempo previsível?)

• Quais são as linhas de te1npo do mercado para a próxirna versão ou lançamento de produto? Que janelas de oportunidade faz mais sentido aproveirar?

• O que os concorrentes neste 1nercado estão fazendo? Quais são as estratégias que nós achamos que eles tên1 e con10 podere1nos competir co1n eles?

Respondendo às perguntas certas

Talvez leve horas ou semanas para responder a essas pergunras, dependendo da profundidade e da qualidade das respostas necess;írias, que são definid;is pelo gerente de projeto ou líder do grupo. Como regra prática, quanto mais estratégico se espera que um projeto seja, mais imporra.nte será a qualidade desse tipo de pesquisa de planejamento e definição. Para projetos cá.ricos que são direcionados para necessidades de curto prazo ou questões menores, é necessário 1nenos profundidade. Talvez você precise considerar apenas algu1nas perguntas e poderá basear suas respostas no 1nodo como respondeu a elas no iJlri1no projeto. Mas para projetos i1nporcances, essas infonnações terão valor inestimável e1n rodos os ajustes e alterações realizados durante o projeto, não apenas na fàse de planejamento.

Algumas dessas perguntas são melhor respondidas por analistas de negócios, outras são melhor respondidas por progra1nadores líderes ou engenheiros de usabilidade. Freqüencemenre, as 1nelhores respostas são provenientes de discussões entre esses especialistas e do co1npartilhan1ento de anotações, fontes e opiniões. A realizaç.'io desse trabalho pode ser uma tarefa cara e den1orada, mas essa é a natureza do planeja1nento. Comprar uma casa ou um carro, 1nudar para un1 novo país ou escrever um livro requerem significativos esforços de planejan1enro para fiizer com que o processo funcione ben1. Se você fizer da maneira correta, permitirá tomadas de decisão mais precisas e mais rápidas em todo o restante do projeto. (Falarei mais sobre isso no Capítulo 14.)

E se não houver tempo?

No pior dos casos, mesmo que não haja nenhuma pesquisa e não seja alocado tetnpo para fazer uma investigação adequada, ainda assim filça essas perguntas. O fato de fazer boas perguntas leva a duas possibilidades positivas. E1n pri1neiro lugar, suposições inteligentes sobre a pergunta certa são melhores que nada. U ma pergunta bem fonnulada concentra a energia nos problemas cercos. Mesmo que

68 A An.-rE DO GERENCIAMENTO DE PROJE1-os

você só renha cempo para conjecuras, especular sobre as quescões cercas vale mais do que especular sobre as quescões erradas. E1n segundo lugar, a ausência de pesquisa sobre quescões i1nporranres pode levanrar u1na bandeira vermelha para os líderes e a gerência. A saúde a longo prazo de uma organização depende da sua habilidade de fazer bons planos e, muito embora investimentos (contratação de pessoas ou fornecimento de fundos) possam vir n1uito tarde para ajudar neste projero, isso poderá definicivamente ajudar o próximo projeto.

Catálogo de formas erradas comuns de decidir o que fazer

.Existem sempre mais formas erradas do que certas de fazer algo e um planejamento de projeto não é uma exceçã.o. Como uma ferramenta adicional voltada para separar o certo do errado, a Tabela 3-1 mostra alguns enfoques malfeitos que vi sendo usados. Espero que ela possa ajudá-lo a reconhecer quando isso ocorrer e por que esses enfoques são problem;íticos.

TABELA 3-1 . Catálogo de formas erradas comuns de decidir o que fazer

Forma errada Exemplo Por que acontece O problema

Faremos o "A versão 3.0 será Freqüentemente não O mundo pode ter mesmo que igual à 2.0, apenas há a disposição ou os mudado desde a versão fizemos na melhor!" recursos para voltar e 2.0. Sem examinar última vez. fazer nova pesquisa como a v2.0 se saiu em

sobre as questões relação a suas metas, o empresariais, plano poderá ser um tecnológicas e dos desastre. clientes.

Faremos o que "As características Itens que foram Características esquecemos de excluídas da excluídos são bem excluídas não são terminar na última versão 2.0 serão compreendidos e essenciais. Focar uma vez. o núcleo da 3.0!" estão parcialmente versão nelas pode não

completos, tomando- ser o melhor uso de os pontos mais fáceis recursos. para começar.

Faremos o que "Nossa meta é igualar É a estratégia de Podem existir péssimas nosso competidor o Produto X marketing mais razões para um está fazendo. característica a simples. Ela satisfaz competidor fazer o que

característica." os paranóicos, os faz. inseguros e os preguiçosos. Nenhuma análise é exigida.

Desenvolveremos "A versão será Tendências são As revoluções são raras. o que for novidade baseada no Java, tendências porque são O progresso tecnológico e indicar uma preparada para fáceis e divertidas para é superestimado no tendência. dispositivos móveis seguir. As pessoas se curto prazo e

e compatível com o entusiasmam com a subestimado no longo RSS 4.0." tendência e isso pode prazo. Problemas dos

trazer motivação para clientes podem superar projetos chatos ou as tendências. mal-definidos.

COMO RESOLVER o QUE FAZER 69

TABELA 3-1. Catálogo de formas erradas comuns de decidir o que fazer (continuação)

Forma errada Exemplo Por que acontece O problema

Se nós o "O Projeto X será o Ao desviar a atenção de O mundo precisa de uma desenvolvermos melhor mecanismo todos para o ratoeira melhor? assim, os clientes de pesquisa/editor da desenvolvimento e não Os cliente virão se o que virão. Web/dispositivo/ratoeira para a razão para o for desenvolvido for útil

já desenvolvido." desenvolvimento, as para eles e não porque pessoas podem às uma equipe decidiu vezes evitar o desenvolver algo. planejamento real.

O processo de planejamento

Qualquer que seja o cempo alocado par-a a definição do projero, crie um processo simples para responder às quescões do planeja1nenro. Se possível, cada perspecüva (empresarial, cecnológica e do clience) deveria rer uma pessoa com experiência na área conduzindo a pesquisa de informações, gerando idéias e propostas e revisando suas opiniões com seus pares das oucras perspeccivas. O cruque é mancer esse grupo suficience1nence pequeno para ser producivo, mas grande o suficiente em perspectivas para ser amplo e abrangence. Um grupo de 1 O pessoas será muito 1nenos efecivo na discussão de quescões e no desenvolvimenco da "quünica" da equipe do que u1n grupo de cinco (consulce o Capfrulo 9).

Com base na minha experiência, prefiro lidar co1n os egos feridos das pessoas que não são as principais concribuintes para o planejamenco do que incluir pessoas em excesso e sofrer por um ano ou mais em un1 projeto mal­planejado e cheio de soluções conciliatórias. As pessoas maduras que você não incluir co1npreenderáo suas razões se você dedicar tempo para explicar a elas, e as imaturas terão a oportunidade para crescer ou a motivação para encontrar empregos 1nelhor ajustados aos seus egos.

Se você está usando os resul tados do planejamento como aqueles que eu descrevi sucintamente antes neste capítulo, a meta do grupo de planejamento deveria ser a criação e publicação daqueles documentos para a equipe. A fase do planejamento (consulte a Figura 3-3) termina apenas quando aqueles documentos (ou, ainda mais importante, as decisões que eles contêm) são co1npletados.

A MRD . r- ~ ~

• Visllo

• ,.... ...... .. 1 Eseecificaçõés

1 " :: ~ WBS •

FIGURA 3-3. A realimentação (feedback) entre os níveis de planejamento.

70 A AR-íE DO GERENCIAMENTO DE f>ROJE1-os

Uma versão inicial de cada documento de planejan1ento deverá ser preparada bem cedo para incorporar os comenc.ários da equipe anres que u1na versão final seja devida. Como niosrrado na Figura 3-3, pode acé exisrir u1n !oop de feedback encre os resulcados do planejarnento. Quando a versão inicial do MRD (documento de requisitos de marketing) for criada, alguém poderá ter condições de iniciar o trabalho no documento de visão, levantando novas questões para o MRD que o melhorem antes que seja finalizado. Esse padrão se repere em todo o rrabalho de planejamento. Porcanto, mesn10 se os prazos para cerminar os documentos de planejamenro foren1 curtos, alguma superposição no cempo será saudável e melhorará a qualidade do processo. Como moscrado na Figura 3-4, quando um projeco escá na fase de implementação, torna-se mais difícil, embora não impossível, que esse ripo de feedback se propague para cima na estrutura do planejamento. (De forma alternativa, a Figura 3-4 pode ser vista como representando uma equipe contratada que tem influência apenas sobre as especificações e atribuições de trabalho.)

MRD

Vis§o

WBS

FIGURA 3-4. Com o passar do tempo, torna-se mais difícil (embora não impossível) que as mudanças se propaguem para cima na estrutura do planejamento.

O trabalho diário

No que concerne ao trabalho diário, não há n1aneira mágica de realizar esses cipos de rarefas colaborarivas. Pessoas são pessoas, e é i1npossível saltar o cempo que é nonnalmente consumido para que pessoas co1n diferenres mentalidades se relinam, aprendam u1nas com as outras e discucam e assu1nam os compro1nissos necessários para levar o projero à frente. 1-laverá reuniões e discussões, e provavelmente a criação de listas de distribuição de emails ou de sites, 1nas nenhuma receita secreta para essas coisas faz uma grande diferença. Seja tão simples e direto quanto possível. O líder define o com ao iniciar as conversações, fazer as perguntas i1nporcanres e assegurar que as pessoas cercas escão na sala no momento certo. Entretanto, três coisas devem ser consideradas:

• A parte mais importante do processo são os papéis que se espera que as pessoas desempenhem. Quem tem autoridade sobre requisitos? Projeto (Design)? Se muitas pessoas está.o envolvidas, como as decisões serão tomadas? Como os vínculos serão quebrados? Com a definição desses tipos de relaciona1nenros logo no início, muitos problemas pode1n ser evitados ou, mais provavelmente,

COMO RESOLVER o QUE FAZER 71

tratados co1n a compostura e a urgência devidas. (Consulte o Capítulo 10 para obter mais informações sobre relaciona1nentos e definição de papéis.)

• Todos deverão saber quais são os pontos inrer1nediários. Quais são os marcos entre o pri1neiro dia do esforço de planejamento e o dia em que se supõe que a definição do projeto esteja completa? O cronograma dos resulrados do planejamento - como os relatórios, reuniões de revisão ou documentos de revisão - deveria ser listado logo que possível e as responsabilidades definidas para cada un1 deles. Quando exatamente o "planejamento" termina e o projeto (design) ou implen1entação começam? Devem existir respostas boas e documentadas.

• Devem ocorrer reuniões freqüentes onde cada perspectiva seja discutida. Os relatórios com novas informações ou considerações deverão ser apresentados e novas perguntas ou conclusões deverão ser levantadas. Especialistas de outras partes da organização ou da equipe deverão participar daquelas reuniões nas quais eles tê1n conhecimento específico que pode ajudar, ou se suas opiniões tiverem valor para o grupo.

O gerente de projeto é freqüentemente responsável pela consolidação de cada reunião e da discussão en1 pontos-chave, e por assegurar que as conclusões serão docu1nentadas e disponibilizadas em um local que o grupo possa acessar co1n facilidade. As perguntas ou questões levantadas deverão ser atribuídas de forma apropriada e discutidas na próxüna reunião.

Pesquisa de cliente e seus abusos

Há diferentes maneiras de utilizar indevida1nente as inforinações sobre os clientes. Declarar simplesn1ente que os clientes são importantes não significa muito. Não há trabalho nenhum em dizer "Nós nos preocupamos com os clientes" ou "A satisfação dos clientes é importante" porque raramente algué1n pergunta como essas crenças se enquadram no comporca1nenco da organização. Muito embora na última década tenha ocorrido muito progresso na melhoria dos métodos para a pesquisa e a compreensão dos clientes, a 1naior parte disso ainda não atingiu as organizações centradas no gerenciamento ou na engenharia. Ainda é incomum que as equipes de projeto tenham um especialista em pesquisa de clientes, projeto de interfaces ou usabilidade disponível para os que to1nam as decisões.

Em grande parte, o erro mais comu1n que tenho visto e1n pesquisa de cliente é a excessiv<t dependência em um único método de pesquisa como a fon te para a tomada de decisão. O problema fundamental com toda a pesquisa, científica ou não, é que um determinado estudo avalia apenas um ponto de vista sobre um assunto(discutiremos isso nova.mente no Capítulo 8). Cada método utilizado no exame é bom apenas para 1nensurar determinados atributos e rui1n para rnedir outros (consulte a Tabela 3-2). Da mes1na maneira que você nunca usaria um velocí1netro para medir seu peso, ou sua conta bancária para 1nedir sua pressão sangüínea (embora elas possam estar relacionadas), há aplicações nas quais levanta1nentos (surveys) e grupos de foco (jocus groups) são eficazes e outras nas quais eles não o são.

72 A An.·rE DO GERENCIAMENTO DE PROJETOS

TABELA 3-2. Métodos comuns de pesquisa de cliente

Método O que é? A favor Contra

Grupo de foco Um grupo de clientes Pode obter muitas As discussões são em potencial é opiniões ao mesmo difíceis de analisar e é reunido para ver tempo. Permite fácil tirar conclusões protótipos e dar sugestões adicionais erradas. Facilitadores opiniões em uma e diálogo aberto. mal-treinados podem discussão com criar dados facilitador. enganosos.ª

Levantamento Um conjunto de Forma de baixo custo Confiabilidade da perguntas é passado para obter informação é baixa.b A aos clientes em informações de preparação de potencial. grande número de levantamentos sem

pessoas. Bom para perguntas avaliar tendências tendenciosas é difícil. bem amplas. É fácil tirar

conclusões erradas.

Visitas aos locais Especialistas ou Permite observar a Os dados são mais membros da equipe real experiência do valiosos para aqueles vão aos locais de cliente. que fizeram a visita: é trabalho dos clientes Freqüentemente esta difícil transferi-los e os observam é a experiência mais para outros ou usá-los enquanto trabalham. memorável e influente quantitativamente.

para a equipe.

Estudo de Clientes Quantifica quão fácil é Pouco valor direto usabilidade selecionados usam usar algo. Proporciona para questões

um projeto (design) evidência para empresariais ou em um ambiente problemas tecnológicas. Pode controlado. São específicos. É mais representar esforço realizadas medições valioso quando feito desperdiçado se for para quantos logo no início, antes realizado mais tarde cenários eles que o projeto comece. ou se a equipe de possam completar, engenharia não em quanto tempo e observa com com quantos erros. freqüência.

Pesquisa de O mercado para o Única maneira de Não explica por que mercado produto é examinado capturar a visão os produtos têm

para verificar empresarial de um sucesso e foca nas quantos clientes mercado ou setor. tendências e nos existem, qual o custo dispêndios, em vez de dos produtos dos nas pessoas e nos concorrentes e quais seus são as projeções de comportamentos. receita.

• Grupos de foco tendem a tomar as pessoas mais colaborativas. Elas não querem desapontar seus anfitriões e freqüentemente serão mais positivas e generosas na consideração de idéias do que o fariam nomialmente.

b Considere quão diligente você foi ao responder às perguntas no último levantamento do qual participou. Se nunca participa de levantamentos, pergunte a si mesmo sobre os tipos de pessoas que provavelmente gastarão muito tempo respondendo a levantamentos.

COMO RESOLVER o QUE FAZER 73

Especialistas em pesquisa do cliente fazem duas coisas: eles escolhem o tnécodo com base nas perguntas que a equipe do projeto precisa responder e usatn vários 1nétodos para compensar as limirações e os vieses de abordagens individuais. A Tabela 3-2 apresenra alguns dos principais mérodos de pesquisa e seus pontos fortes e fracos.

Como gerente de programas na Microsoft, nas melhores equipes de projeto com as quais trabalhei, tive acesso a 1nuitas dessas fontes de informações. Freqüencen1ente tive que solicitar respostas a perguntas específicas que iam alén1 do que eu recebia de informações, 1nas havia especialisras dedicados na organização que en1 geral raziam isso para mim. Em outras equipes com n1enos suporte, eu tinha que realizar o trabalho com meus próprios recursos (normalmente com menor sucesso porque tinha outras coisas para fazer e não era tão competente para a obtenção de resul tados quanto um especialista em tempo integral o seria).

Mesmo sem recursos ou orçamento, algumas horas de trabalho dedicadas a responder àquelas perguntas de planejamento podiam às vezes fornecer resulcados úteis. A energia focada e gasta e1n pesquisas inteligentes na Web e em consultas a bibliotecas (os bibliotecários reais representam ferratnentas 1nais poderosas do que os sites) pode revelar fontes que são infinitamente mais úteis do que nada. Ao longo do rempo, as habilidades e a experiência na realização desse ripo de pesquisa aumentarão e consumirão menos tempo no fururo. Ainda mais importante, o faro de ter realizado esse ripo de trabalho o colocará etn u1na posição n1ais informada para contratar algué1n para fazer o trabalho para você, caso lhe seja oferecido o orça1nenro apropriado ou autorizada a contratação.

Com qualquer fonre de dados, o ceticismo e um saudável exame 1ninucioso ajudarão a refinar e melhorar o valor dos dados. As pren1issas deverão ser quesrionadas e os vieses conhecidos dos diferences tipos de pesquisas deveriam ser desafiados ao mesmo rempo em que a pesquisa é apresentada em uma discussão. Isso não significa que os dados deveriam ser descartados s implesmente porque não são suficientes ou porque existem questionamentos válidos a respeito deles. Em vez disso, a equipe deveria tentar ir além das falhas para descobrir as partes valiosas que poderiam ser utilizadas para influenciar as discussões e proporcionar uma perspectiva melhor sobre o que é a realidade da experiência do cliente. Nenhurna forn1a de dados é perfeita: sempre existirão vieses, avisos, margens de erro e detalhes ocultos. O gerente do projeto cem que ser capaz de ver além dos vieses e fazer uso inteligente do que está disponível para tomar decisões melhores.

Juntando tudo: requisitos

O planeja1nento cria grandes quantidades de infonnações interessantes (fàzer 1nuitas perguntas leva a isso). O desafio consiste em cotno simplificar as informações e convertê-las em uma forma úti l para a definição de u111 plano de ação. Em um nível 1nais alto, urn docurnenro de visão possibilita urna sínrese de rodas as perspecrivas, pesquisas e estrarégias. Falaremos mais sobre esses docun1entos especiais no próxirno capítulo. Mas, do nível médio para o baixo, a ferrarnenta 1nais si1nples é o uso de requisitos. Os documentos de visão freqüentemente contên1 informações sobre os requisitos, mas se forem redigidas especificações ou preparados ourros documentos mais focalizados, os requisiros deralhados poderão estar disponíveis nesses outros documentos.

74 A Al'ºíE DO GERENCIAMENTO DE PROJETOS

Muicos projecos usam os requisicos corno uma maneira de definir a direção de urn projeco. Um requisico é, por definição, algo que a equipe (e o clience) concorda que será sacisfeiro quando o projeco for cornplerado. No sencido mais sirnples, pedir urna pizza de pepperoni represenra um aro de definição de requisitos. Você está dizendo especifica1nente ao atendente o que quer. Ele pode fazer perguncas para esclarecer o requisito ("Quer um refrigerante também?"), ou ele pode negociar os detalhes do requisico ("Não temos pepperoni, pode ser de salame?"). No caso mais complexo de desenvolvimento de software, bons requisicos são difíceis de obter. Existem muicas maneiras diferences de inrerprecar idéias abscracas ("melhorar a velocidade de execução" ou "reduzir a freqüência de falhas"), e o processo de esclarecimento desses requisitos pode ser difícil.

Há mécodos estabelecidos para desenvolver e documentar requisitos, e eu recomendo que você se familiarize com eles (consulte o excelente livro Explo1·ing Requirenients: Quality Before Design, de Donald Gause e Gerald Weinberg, publicado por Dorsec House, 1989). Dependendo da autoridade que você tenha sobre o processo de elaboração dos requisitos, existirão rnaneiras diferentes de proceder para que sejarn obtidos bons resultados. Os decalhes desses métodos e sua forrna de aplicação estão fora do escopo deste livro. Entrecanto, posso oferecer urn método simples que acredico seja facil de usar e em geral be1n eficaz: o mécodo das declarações de problemas (problem statements method) .

Declarações de problemas são descrições, em urna ou duas sentenças, das questões específicas do usuário final ou do cliente. Elas devern resultar das pesquisas realizadas ou de solicicações específicas do clience. Devem ser redigidas em u1n forrnato que identifica um proble1na ou necessidade a partir da perspecciva do clience (ao concrário das perspeccivas empresarial ou da engenharia). Isso garancirá que o ponto de vista do in1pacro no cliente será mancido e não será discorcido de forma não-incencional pelas outras perspectivas. As declarações de problen1a tan1bém ajudam a evitar alguns dos erros mais comuns con1etidos pelas equipes nos requisitos (nós os abordaremos de forma sucinta no Capítulo 5).

Como um exemplo, aqui está uma lista de como poderiam se apresentar declarações de proble1nas para u1n site na intranet:

• É difícil enconcrar os itens freqüentemente necessários na página inicial.

• As páginas com infonnações deparcarnencais são muico lencas e os usuários tê1n que esperar.

• A página de consulta ao banco de dados falha quando está trabalhando com grandes rabeias e os usuários têm que reiniciar seu crabalho.

• O site não fornece acesso auto1natizado aos serviços da <Írea de Recursos Humanos, que ton1am cempo quando feicos manualmente.

• Os resultados da pesquisa são difíceis de exan1inar com o leiauce atual.

• A página de registro não avisa sobre os campos requeridos e torna fácil comecer erros.

• A página de status não inclui informações sobre email, e os usuários nã.o podem descobrir por que seu email não está funcionando.

• Não há maneira de salvar as preferências ou opções para exibição da página inicial.

COMO RESOLVER o QUE FAZER 75

Observe que esses não são relatórios de erros. Essas questões podem nunca ter sido idenrificadas co1no coisas que o site precisasse fazer. Declarações de problernas deveriam ser mais arnplas do que os erros, e rambérn diferences na perspectiva adotada, porque a idéia é capturar o que escá faltando a partir da perspectiva do cliente, em vez de apenas o que não está funcionando a partir da

. ' . perspecnva tecn1ca. Cada un1a dessas declarações em uma sentença pode ser seguida por

evidências ou exemplos que a suportem (como, cópias de rela do site ou do produto que proporcione um conrexco para a questão cracada, ou encão referências ao estudo de usabilidade ou a oucra pesquisa que tenha identificado o problema) para ajudar a contar a história e explicar por que e como o problema ocorre (ou por que a omissão de um tipo de fi1ncionalidade é significativo). Mas essa evidência de suporte não deve se misturar com a própria declaração de problema, ou com os planos da engenharia ou os objetivos empresariais. Para 1nancer a sanidade rnental, essas declarações de problernas de cliences deverão tratar apenas dos clientes e de suas necessidades.

Os problemas se tornam cenários

Como as declarações de proble1nas representam o escado acuai do mundo, um projeto precisa de algo rnais para expressar corno o mundo será quando o trabalho for con1plecado. Para esse objetivo, as declarações de problemas precisam ser convertidas no que são denon1inadas declarações de caracterísricas lfeature statements) ou cenários. Há 1nuiras 1naneiras diferences de fazer isso; casos-de-uso (use-cases) consrirue1n urn 1nérodo conhecido (consulre o livro de Alisrair Cockburn, Writing Ejfective Use Cases, Addison Wesley, 2000), mas exiscem

. muitos oucros.

Cada cenário é uma descrição curta de algo que o cliente terá condições de fazer con10 resultado do projeto, ou as rarefas que ele não terá mais de realizar porque o projeto as automatizará para ele. A idéia é descrever essas coisas a partir da perspectiva do cliente ou do usuário e evitar qualquer descrição de como esses benefícios serão atingidos - isso sení tratado mais adiante. Por agora, o importante é que a equipe cem condições de expressar e discutir quais são os cenários que produzem maior valor. As considerações sobre o valor empresarial de cada cenário ou sua viabilidade tecnológica deverão estar refletidas na forma como os cenários são priorizados.

As próprias declarações de caracterfscicas lfeature statements) deverão se constituir na maneira de representar rnais facilmente o que foi aprendido sobre os clientes e o que o projeto focará para atendê-los. Corn base na lista anterior de questões dos clientes, aqui está como algurnas declarações de caracceríscicas se . apresencarram.

Possíveis características do Projeto X:

• Os itens comumence utilizados serão fáceis de localizar na página inicial.

• Os resulcados das pesquisas serão rápidos e fáceis de ler para a maioria dos ' . usuanos.

76 A Al'ºíE DO GERENCIAMENTO DE PROJETOS

• O site proporcionará acesso fácil e auromarizado aos serviços de Recursos Hurnanos.

• A página de regisrro rornará fácil a inserç.'io de inforn1ações sern erros.

• As páginas de informações deparramentais serão pelo menos tão rápidas quanro a própria página inicial.

• A interface de consuha ao banco de dados será rão confiável quanto as outras partes do sistema.

• Os usuários terão condições de conhecer os problemas no status do servidor de emails de uma forma sirnples e conveniente.

• O sistema terá urna maneira conveniente de lembrar das preferências dos usuários.

Declarações de características nunca deverão descrever urna solução ou design específico mas, em vez disso, deverão explicar o itnpacro da solução no cliente. (Isco é mais fácil de dizer do que de fazer. A maioria dos engenheiros e pessoas criativas adora1n solucionar problen1as. Se você descrever u1n problema, eles desejarão se dedicar à soluç.'io do problema e1n vez de gastar te1npo tentando elaborar ou refinar o problen1a. É co1num requerer un1a proibição temporária de propostas de soluções durante as discussões de listas de problemas e cenários. Duranre a reunião, sÍlnplesmenre solicite que as pessoas romem noras de suas idéias e que as discutam rnais tarde. Abra exceções para idéias que eliminarn completamente problemas da lista ou que os idencifique1n como triviais.)

Ao postergar a discussão aprofundada sobre alternativas de projeto (design), a equipe poderá focar sua atenção no esclarecimento dos reais objetivos do projeto. Essas declarações de características podem ser classificadas em linhas gerais por i1nportância, ajudando a definir a forma que o projeto terá. Se isso for bern gerenciado, quando for a época de explorar e definir designs, isso ocorrerá muito mais rapidarnence porque todos estarão rrabalhando para os mesmos objetivos (em ve--1. de serem distraídos pelas tecnologias ou por suas idéias favoritas para as soluções). Como 1nuiro se espera dessas descrições sucinras, elas precisam ser redigidas cuidadosamente e levando em consideração o ternpo pelo qual serão usadas pela equipe do projeto. Freqüentemente são necessários várias passagens e revisões para acertá-las, rnas uma vez completas, elas rararnente precisa.rão ser redefinidas durante o curso de un1 projeto.

Integrando requisitos empresariais e tecnológicos

Com uma lisra de características potenciais que ernergiu da pesquisa dos usuários, poderão ser acrescentadas outras características que atendan1 às considerações empresariais ou tecnológicas. Mas uma pergunta importante deve ser respondida: qual é o objetivo dessas solicitações adicionais se elas não contribuem para ajudar os clientes? Antes de adicionar novas características, a lista existente deverá ser revisada para verificar quais delas já represenram essas considerações empresariais e tecnológicas. Isso obriga a que roda a discussão seja centrada no impacto e no benefício ao cliente, sem proibir considerações específicas empresariais ou tecnológicas.

COMO RESOLVER o QUE FAZER 77

É cocalmence possível que os requisicos ernpresariais, visando a exploração de decerminadas oporcunidades de mercado, sejam represencados por uma ou rnais caraccerísricas consrantes da !isca. Os requisicos da cecnologia ca1nbé1n deverão esrar vinculados aos benefícios que esses esforços de engenharia criarão para os clientes. Qualquer requisito empresarial ou tecnol6gico que não se conecte a benefícios para os clientes (a curto e longo prazos) deverá ser examinado cuidadosa1nente. Essas características não-cencralizadas nos clientes deverão ser criteriosamente definidas para garantir que não impactarão negativamente a experiência dos mes1nos.

E mesmo que o marketing demande uma adição que não renha vínculos com o aprimoramento da experiência do cliente, rodos saberão que esse é o caso e responderão de forma compatível. Algumas vezes, é necessário acrescentar uma característica para ajudar a vender um produto, a despeito de seu dúbio valor para o usuário final, ou para satisfuzer um cliente ou executivo exigente. Porém, ao organizar o processo de planejamento primeiro em corno da pesquisa dos clientes, das declarações de problemas e das características resultantes, todos terão que apresentar seus argurnencos dentro desse concexco. Sinais de alerta soarão se a 1naioria das caracceríscicas em uma versão não civer conexão direta co1n o cliente. Se puderem ser revisadas por sua relação com uma lista centrada no cliente, as solicitações esparsas ou que acendam a inceresses individuais se descacarão para rodos na sala e demandarão debares e discussões adicionais. Isso dá ao gerente do projeto a oportunidade de definir um conjunto básico de características que tenha111 em n1enre os melhores interesses dos clientes e da organização.

Resumo

• Projetos diferentes demandam abordagens de planejamento diferences.

• A forma como o planejamento é realizado é freqüentemente determinada por quem tem qual autoridade. Requisitos, design e orçamento são os crês tipos de autoridade de projeto que têm impacto no planejarnento.

• Há alguns resultados comuns do planejamento de projetos: documentos de requisitos de marketing (marketing require1nents docurnents, MRDs), documentos de visão/escopo, especificações e estruturas analíricas de projeto (work breakdown structures, WBS).

• A forma mais poderosa de planejar um projeto envolve o uso de três perspectivas iguais: e1npresarial, tecnol6gica e do cliente. A perspectiva do cliente é freqüentemente a 1nenos co1npreendida e a pior utilizada.

• As perguntas força111 o bo1n pensamento e direciona1n de forn1a eficaz a energia do planejamento.

• O processo de definição de requisitos é difícil mas há boas referências sobre como fazê-lo ben1.

• Declarações de problen1as e cenários são uma fonna sin1ples de definir e de con1unicar requisiros. Elas são facilmenre convertidas en1 idéias de design sem perder a clareza sobre o que é e o que não é importante.

Capítulo 4

Redigindo a visão eficiente

80 A Ai,-íE DO GERENCIAMENTO DE PROJETOS

U1n desafio para as equipes de liderança é tnanrer as pessoas concenrradas nas mesmas 1neras por períodos de re1npo prolongados. Todos os líderes re1ne1n que as decisões por eles romadas não seja1n le1nbradas. É possível que os motivos que as pessoas cinhan1 para ouvi-los já tenhan1 sido esquecidos ou seja1n ignorados amanhã. Pior ainda, os próprios gerentes pode1n se esquecer do run10 para o qual, supostamente, deveriam esrar conduzindo o projeto. Por conseguinte, o desafio do gerenciamenro de projetos é não somente dar o ponrapé inicial na direção correra, co1no também manter o ru1no.

O Capírulo 3 apresentou uma visão geral sucinta dos docu1nentos de planejamento, como o MRD, visão e especificação. Este capítulo se concentrará no documento de visão, o mais importante de todos os materiais de planejamento prévio. Explicarei por que é importante ter um legado escrito dos documentos de visão, as qualidades dos documentos eficazes e como obter continuamente o máximo proveito ao longo de um projeto. Quando utilizados adequadamente, esses documentos encerram a fuse do planeja1nento inicial de u1n projeto (consulte a Figura 4-1 ).

Visão concluída '>'=P;l;an;e1;·a;m;en;;;;to;';ín;;;;ic1;;;;·a1~

Especificação conclulda J> 1 Projeto 1 ·;1:;:;;;;p;;;~;og;~;a1;n;aç;;;;ã;;;;o~~,

1 Teste 1 FIGURA 4-1. Um documento de visão finalizado representa o final da fase de planejamento, assim como as especificações finais determinam o final da fase de projeto.

Apenas uma observação antes de co1neçar. Há várias 1naneiras diferences de dividir o terreno coberto pelos MRDs, visões e especificações. Algu1nas organizações nunca usam MRDs ou documentos de justificativa de negócio e, ern vez disso, incluem essas inforrnações no próprio docurnenro de visão. Já 1ne deparei com outras equipes que dividem o que chamo de documento de visão em quatro ou cinco docu1nenros 1nenores e atribuem a esses documentos nomes fantasia. Participei algumas vezes em projetos pequenos onde a informação do ripo visão era reduzida à própria especificação. Sendo assin1, não se preocupe co1n a quantidade de docutnencos que você precisa ter nem co1n os nomes que deve atribuir: acho que isso não tem itnportância. O aconselhamento a seguir se aplica bem a qualquer processo de planejamento que você escolher.

A importância de documentar tudo

Daniel Boorstin, autor das grandes obras, The Creators e The Discoveres, disse certa vez que a palavra escrita era a mais importante tecnologia que o homem inventou . Sem ela, dependeríamos de nossa memória cerra1nente não-confiável para. realizar atividades complexas, como fazer dinamite (hummm, quanta nirroglicerina deve

RE01GINDO A VIsAo EFICIENTE 81

ser co1nbinada a quanto carvão?) ou reatores nucleares (qual a quantidade de urânio?). Especifica1nente na arividade de projeto, docu1nentar as coisas pennite definir o trabalho de engenharia ou captar os objetivos globais de equipes inteiras, de u1na só vez, e reaplicar esse conhecimento várias vezes. Documentar os pormenores das decisões transfere de nossas mentes para o papel todo o peso da exatidão e men1orização, e tudo o que precisamos fazer é olhar para o que escrevemos. Essa liberação da 111ente nos pern1ite acelerar ao máximo a rarefa em questão, na certeza de que poden1os consultar o que escreven1os quando necessário (por exemplo, quando perdermos o foco, enfrentarmos desacordos ou nos confundirmos). Daí que quanto mais complexo e incenso for o esforço, ranro maior a probabilidade de que as anotações dos respectivos detalhes aumentarão as chances de êxito.

Quanto maior for o grupo de pessoas que trabalham em equipe, tanto mais complexo e denso será o trabalho. Um ti1ne de três pessoas pode conversar o bastante, em paralelo, para coordenar o 1nodo como seus esforços se integrarão e como 1nanterão a chama dos objetivos finais acesa em suas mentes. Contudo, u1n grupo de 20, 100 ou 1.000 pessoas não pode ter esse privilégio. Em vez disso, alguém terá que definir o plano de nível superior para todo o trabalho, antes de seu início, e deverá documentá-lo de 1nodo que todos possam usá-lo de modo fácil, como uma referência.

Documentar as erapas também serve para informar as intenções de uina equipe a tuna organização de grande porte. Se o grupo A puder representar suas idéias nlais importantes e as decisões de alto nível em um docu1nento resuinido, então os grupos B e C poderão entender as intenções do grupo A e levantar questiona1nentos ou apresentar con1entários rapida1nente. Quanto 111ais con1plexo e denso for um projeto, tanto 1nais i1nportanre será esse docun1enro sucinro, uma vez que os projetos complexos têm uma tendência maior a erros de comunicação e enganos dispendiosos. E como compensação, os novos integrantes da equipe (experientes e iniciantes, indiferentemente) poderão ler uma versão condensada dos principais conceitos do projeto e entrar no circuito mais rapidamente do que se precisassem assimilar essas idéias básicas a toque de caixa.

De quanta visão você necessita?

Eu já examinei documentos de visão de 50 páginas, cuidadosamente formatados com pesquisa, diagramas e raciocínio estratégico. Ta1nbém já me deparei com visões com apenas algumas páginas de irens com marcadores, com algumas frases descrevendo cada un1 deles . . De acordo co1n o projeto, serão necessários diferentes níveis estruturais e de planejamento. Não comera o erro de achar que os docurnencos de planeja1nenro são aspectos fixos e rígidos: são apenas documentos. Quão profundos ou exorbitantes eles devem ser dependerá da narureza do projero e da cultura da equipe. Contudo, os documentos de visão eficiente rendem a abranger os 1nes1nos tipos de questionainentos, mas o 1naterial varia em termos de deta!hainento e rigor.

Para dar un1a idéia da estrutura e invesrin1ento necessários a seu docun1ento de visão, examine as seguintes perguntas:

• Quantas pessoas diferences serão afetadas pelo projeto? A quanras organizações diferentes essas pessoas pertencen1? Con10 você vai criar expectativas junco à alta

82 A AR·íE DO GERENCIAMENTO DE f>ROJE1-os

administração, aos outros níveis e, entre estes, em cada organização, adequada1nente?

• Quantas perguntas válidas a própria equipe te1n sobre o futuro? Até que ponto as pessoas precisa1n saber sobre o que farão e por que farão?

• Que nível de detalhamenco de feedback sobre o rumo do projeto você deseja receber de outras pessoas?

• Quanta explicação das decisões você quer ter para F<1zer pessoalmente? (Uma boa visão deve estar bem-embasada ao representar o projeto para outras pessoas.)

• Quanta solidez de conhecimento e raciocínio um líder de projeto deve oferecer à organização, corno parte da tomada de decisões no nível de projeto? (Urna visão fornece a prova disso.)

• No decorrer do projeto, até que nível de detalharnento do pensamento estratégico a equipe deve ter acesso?

• Que pesquisa os executivos ou gerentes seniores esperan1 que você fàça, corno parte do planejarnento do projeto? Como você apresentará essa tarefa?

• Será necessário relembrar as meras do projeto para a equipe, posteriormente? Exjste alguma probabilidade de as pessoas questionarem mais adiante sobre itens específicos acordados recentemente?

Quanto n1ais detalhadas e fundamentadas forem as suas respostas a essas perguntas, tanto maior será a importância do documento de visão. Se poucas dessas perguntas forem aplicáveis, escolha algo rnais leve e informal. Se muitas delas se aplicarem (e você sentir náuseas ao lê-las), precisar-.í de rnaterial mais pesado.

Devo dizer que essas perguntas estão mais para questões de liderança e como um líder pretende lidar com os desafios da liderança, do que aspectos puramente relacionados com as visões. Contudo, um documento de visão é a ónica maneira que conheço de tratar várias delas simulcaneamente. Também estou convencido de que, mesrno trabalhando sozinho (super-herói solitário), elaborar urn docurnento de visão informal (como uma lista de metas) para a sernana, mês e ano está n1uito longe de encerrar esses períodos de ternpo com algo rugno de se orgulhar. Após anotar todos os aspectos, fica n1ais fácil atribuir responsabilidades às pessoas por cada um deles, rnesmo que você só esteja respondendo por si mesmo.

Metas da equipe e metas de cada membro

Para falar sobre as visões en1 detalhes, preciso definir alguns cennos. Visões, 1netas da equipe e meras são termos que freqüentemente se sobrepõem. Eis aqui um esclarecÍJnenco sobre con10 vou utilizá-los:

• Visão - Define as metas de alto nível para o projeto inteiro. Isso também pode ' incluir uma declaração da visão ou meta global. (As vezes, as metas de alto nível

definidas por uma visão são chamadas de objetivos para ajudar a diferenciá-las das metas de nível inferior.)

• Metas da equipe - O subconjunto da visão pelo qual determinada equipe é responsável, definido de modo mais detalhado do que a visão. (Por exemplo, a

REDIGINDO A VISÃO EFICIENTE 83

equipe A pode ser responsável pelo sistema de banco de dados e respectivas 1netas, e a equipe B pode responder pelo siste1na do mecanismo de pesquisa e suas 1netas, mas co1npartilhando a mesn1a visão do projeto.)

• Metas de cada me1nbro - O subconjunto de 1neras da equipe pelo qual u1n único indivíduo é responsável.

Em projetos pequenos, há pouca diferença entre metas da equipe e de cada men1bro (consulte a Figura 4-2). Un1 projeto pode ser, inclusive, tão pequeno que não há necessidade dessas distinções. Entretanto, nos projetos nlaiores, com 50 pessoas ou mais, essa ca1nada extra pode ser necessária. Trabalhando em equipes rnaiores (definida grosseira1nente como com mais de 50 pessoas) em grande parte de minha carreira, eu costumava analisar essas três camadas: um conjunto para o projeto inteiro (visão), outro para cada recurso ou área do projeto (equipe) e ourro ainda para as metas pessoais de cada e1npregado trabalhando no projeto (indivíduo). Os dois primeiros são de regisrro público para a equipe inteira; o últin10 permeia o e1npregado e seu gerente.

O que todos estão fazendo

' ,

O que alguns de nós estão fazendo

• • • • • •

O que eu estou fazendo

FIGURA 4-2. Três níveis de metas.

Por exen1plo, exa1ninemos o projeto Hydra, um site de intranet na Web:

• Visão da Hydra - O site da I-Iydra rornará as fonres de intranet mais usadas (pesquisa, contabilidade, inventário, RI-1, viagens) facilmente acessíveis a partir de um site, com uma única interface sin1ples, f.ícil de usar.

• A equipe A ficará responsável por tornar a pesquisa e a contabilidade fàcilmente acessíveis e simples de usar. A equipe B ficará encarregada do inventário, RH e viagens.

• Frederico (equipe A) vai elaborar e implementar todos os recursos necessários para a pesquisa. Mauro (equipe B) orientará o esforço do projeto global e criará rodas as especificações da interface do usuário para a Hydra. Roberto (equipe B) projetará e implementará rodos os recursos necessários para RH e viagens.

A idéia é que exisra lllna transferência hierárquica forte de ci1na para baixo: as 1neras da equipe são herdadas das 1neras do projeto e as meras de cada 1nembro são oriundas, em sua grande maioria, das 1neras da equipe da área (sendo a exceção básica as necessidades individuais de treina1nento ou crescimento que não pode1n ser atendidas no â1nbito do projeto) . Desde que esses três níveis sejam

84 A AJ,-íE DO GERENCIAMENTO DE PROJETOS

bem idealizados, todos deve1n co1nparecer todos os dias, 1notivados para realizar um trabalho que faz sentido para eles e que contribui direta1nenre para o projeto como um rodo. O rernpo necessário para 1nonrar uma esrrurura co1no essa con1pensa rodos os esforços. Essa estrutura gera urna sinergia natural de meras compartilhadas na equipe inteira e fucilica ainda mais a gestão de urn projeto (consulte a Figura 4-2).

A esses três níveis de definição devem corresponder documentos (ou no mínin10, discussões diferences). Para a visão do projeco compleca, o gerente do grupo ou líder do projeto global deve esrar liderando a criação do documento de visão de alco nível. Esse gerente deve esperar, então, que os líderes de área ou componentes recebam e interpretem as diretivas de alto nível como meras das próprias áreas, possivelmente levantando temas ou meras específicos a partir daí. Por último, os contribuintes de nível de linha devem discutir com seus gerentes e lideres de equipe suas 1neras e responsabilidades individuais, derivadas das meras da equipe.

Cinco qualidades das boas visões

U1na vez que rudo procede da visão de alro nível, o chefe da equipe deve investir mais energia nessa visão do que em qualquer ourro material de planeja1nenco prévio. As cinco características rnais imporranres são: simplificante, intencional (orientado por metas), consolidado, inspirador e memorável.

Simplificante

O aspecto mais importante a se buscar é urn efeito simplificante sobre o projeto. Uma boa visão trará respostas para as principais perguntas dos 1nembros e lhes oferecerá u1na ferran1enta para tomar decisões em seu próprio trabalho. Ainda que un1a visão provaveln1ente renha idéias que levantem novos quesriona1nentos, esses serão em inenor nún1ero do que aqueles que não precisam 1nais ser perguntados. Nas fàses iniciais de u1n projeto, deve-se consultar a visão o tempo todo - ern discussões, emails e reuniões - utilizando-a acivarnente como uma f'erramenra para ajudar a tomar decisões e, confiantemente, progredir. O gerente do projeto deve estar à espreita disso e desejoso de modificar e rever a visão para incluir perguntas inopinadas que a tornem mais útil para a equipe. A visá.o nunca deve ser um relicário religioso, enfurnado dentro de um armário de vidro. Ela deve ser 1nais parecida com urn conjunto de regras para um bom jogador de tabuleiro, fornecendo esclarecimentos para todos os participantes, especificando os li1ni~1res e dirimindo rapidarnente as disputas ou mal-entendidos. Deve ficar desgastada pelo uso e rer anotações espalhadas pelas margens. Seus efeitos devem encerrar as prelitninares rapidamente e conduzir as pessoas ao centro da ação, co1n a certeza de que o projeto pode ser utn sucesso.

Intencional (orientado por metas)

O documento de visão é a primeira fonte de metas de utn projeto. Ele define o tom das boas n1etas, a quantidade de metas de um plano e o refinan1enro

REDIGINDO A VISÃO EFICIENTE 85

necessário às rnetas antes de sua conclusão. Uma meta bem escrita delineia uma intenção clara para os rnernbros da equipe. São fornecidas infonnações suficientes na própria meta ou nas informações de apoio da 1neta, para que as pessoas saibam quando ela foi concluída. Os men1bros da equipe tambén1 precisa1n conseguir distinguir as atividades que, provavelmente, contribuirão para as metas, daquelas que não ajudarão em nada. Redigir boas .metas é difícil e muito subjetivo; são necessárias diversas revisões para se obcer uma nleta forte e be1n escrita. Quanto menor a quantidade de nletas de alto nível, tanto nlais poderoso será o docurnenro de visão. Ern geral, o documento de visão de um projeto deve conter de crês a cinco metas de alto nível (para obter exemplos, consulte o próximo catálogo de boas declarações de visão).

Um conhecido acrônimo comercial para escrever boas metas é SMART, que representa Specific (Específico), Measurable (Mensurável), Action-oriented (Orientado por ações), Realistic (Realístico) e Timely (Oportuno). A idéia é que se uma meta tiver todos esses cinco atributos, provavelmente ela escará suficiente1nente definida para ser útil (rnas pennanece o critério subjetivo de quão específica ou realística urna mera deve ser). Outra técnica que pode ajudar nas rnetas é fazer o papel do advogado do diabo: pergunte corno urn projeto ainda pode falhar se sua meta puder ser acendida conforme escrito. Depois, i1nagine se existe alguma maneira de expressar a meta de modo mais meticuloso, ou se seria necessário acrescentar um pouco mais de informação para respaldar a meta.

Consolidado

Para que urn documento de visão tenha poder, ele deve consolidar idéias de vários outros locais. Ele deve absorver o pensamento referencial da pesquisa, análise, planejamento estratégico ou outros esforços, e ser a melhor exposição dessas idéias. Qualquer visão de uma equipe fracassará se o seu entendimento exigir que o leitor realize metade do trabalho do autor.

Por esse motivo, o melhor é separar as metas e diretivas de todos os argumentos e pesquisa de apoio que respaldam o plano. Deve haver um único local onde se possa encontrar facilmen te todos os raciocínios e materiais complementares (uma simples página da Web ou site), que esrimule os diligentes (ou céticos) a ir mais fi1ndo do que o próprio documento de visão. A consolidação não significa apinhar um sortimento aleatório de referências - quer dizer que deve haver uma coerência entre elas. Elas devern usar o mesmo modelo e fonnatação ou, pelo menos, ser fàcilmente agrupadas em um só volume: não em função do processo ern si, rnas porque facilita rnuito mais a leitura, o que obriga as pessoas (de preferência, o próprio "manda-chuva") a ponderarem exatamente sobre quantas referências ou fontes são in1portantes para o seu conhecirnento. Esse número não deve ser zero, 1nas tatnbém não deve ser 15 ou 20 docu1nentos, ensaios ou relatórios.

Inspirador

A inspiração nunca vem do âmbito superficial (pensando bem, até mesn10 as pessoas superficiais necessitatn de tuna inspiração verdadeira). Para se relacionar com as

86 A ARºíE DO GERENCIAMENTO DE PROJETOS

pessoas, há que exiscir uma problemática no mundo que precise ser solucionada, e que a equipe cenha interesse ou capacidade para resolver. Acé onde um líder de equipe caris1nácico possa ser úril, ele não muda a qualidade das idéias esboçadas na visão. Concedendo ao leitor um entendi1nenro claro das oportunidades existentes, e apresentando t11n planejamento sólido a ser explorado, quem tiver alguma capacidade para se inspirar, se sentirá inspirado. Embora os programadores e engenheiros tenham uma rendência a tirar inspiração de desafios tecnológicos, é fücil derivar esses desafios da problemática do mundo real que o projeto precisa solucionar. Certifique-se de que todos entendan1 que o projeto está sendo embasado para solucionar a problemática do mundo real e não apenas o impasse tecnológico.

Memorável

Ser memor-ável implica duas coisas: primeiro, que as idéias fizeram sentido ou foram interessantes de alguma maneira; e segundo, que elas ressoam corn os leitores e os aco1npanharão durante as semanas e 1neses de urn projeto. Provaveltnente, eles não lembram 1nais do que alguns aspectos, mas isso é o suficiente para que sintatn confiança no que escão realizando rodos os dias. (Convém observar que se uma visão for muito complexa para ser enrendida, será impossível alcançar esse efeito. Raramente as pessoas se lembrain de coisas que não entende1n.)

Para ser men1orável, o melhor é ser direto e honesto. Se você puder atingir o núcleo das decisões e co1nu1licá-las de modo eficiente - mes1no que as pessoas não aprovem roral1nente essas decisões - elas pennanecerão co1n as pessoas por mais te1npo do que aquelas de uma visão cheia de conceitos nos quais acredirain piatnente, mas esravain soterradas sob u1na redação confusa e fraca. Porcanro, luce para tornar a visão clara e confiável. Transmita à equipe conceitos forres e formas de idealizar o trabalho. Evite as idéias apelativas e espalhafutosas que possan1 inspirar no curto prazo ou captar u1na tendência caprichosa ou volúvel, mas que viram fumaça depois de algun1as semanas, quando a importância da concepção se desgastou.

Principais aspectos a serem cobertos

No centro de uma visão devem estar as respostas para várias das seguintes perguntas. É comum que esses tópicos sejam os principais títulos em um docu1nento de visão ou estejam !iscados no final, como parte de uma seção de Perguntas & Respostas. (Entretanto, quando essas perguntas não são solucionadas no docu1nento principal e engloba1n u1n apêndice, você verá engenheiros saltando para as úlci1nas páginas, un1 1nau indício no que diz respeito ao alcance da redação precedente.)

Para responder a várias dessas perguntas, é necessário envolver-se co1n profissionais de marketing, pesquisa de cliente, elaboração de produtos ou outros especialistas disponíve is para opinar - e que isso não seja uma consideração tardia. Algumas das perguntas a seguir são propositalrnente sernelhantes às perguntas feitas no capítulo anterior sobre planejan1enco. A diferença é que estas perguntas estão intensamente voltadas para as prioridades e decisões, e não para o contexto e entendimento. Durante o planejamento, havia espaço para exploração, mas a visão é forçada a coroar u111a posição e ser decisiva.

REDIGINDO A VISÃO EFICIENTE 87

• Que frase definiria esra versão específica desre projeto? (Geralrnenre, essa frase é a declaração da visão ou para os cínicos da equipe, a declaração sern imaginação. Mais adianre, apresenrarernos alguns exe1nplos disso.)

• De que rnodo esre projeto conrribui para as meras da organização? Por que esre projeto é 1nais relevante do que outros que também podem contribuir para essas mesmas metas?

• Que cenários/recursos para os clientes são fundamentais para este projeto? (Prioridade 1.)

• Que cenários/recursos para os clientes são desejáveis, mas não fundamentais? (Prioridade 2 .)

• Quern são os clienres? Que problemas este projeto soluciona para eles? Que prova ou pesquisa (ao contrário de opiniões e especulações) respalda essas reivindicações? Como os clientes finalizaráo seus trabalhos sem esce projeto?

• Quem são os envolvidos (stakehofders) desce projero na organização (as pessoas corn poder sobre o projeto, rnas que náo são necessariamente clientes)? Que função essas pessoas teráo no projeto? (Discutiremos sobre os envolvidos no Capítulo 16.)

• Por que esses clientes con1praráo ou assinarão este serviço? (Frases como "porque é legal" ou "porque não rên1 escolha" não são respostas aceitáveis mas, sim, os resumos do que os usuários-alvo estão adquirindo atua11nente e como o novo projeto se encaixa em seus estilos de vida, orçamentos ou hábitos cor.idianos. É evidente que, en1 uma siruação de TI, a resposta pode ser "porque não têrn escolha".)

• Quern são os concorrentes e co1no con1parar este projeto ao deles? (As versões anteriores de projetos semelhantes devem ser incluídas como concorrência, ou possíveis alternativas não-tecnológicas, como lápis e papel. O design simples do Palm Piloc é atribuído à visão do papel como um concorrente básico, não outros dispositivos eletrônicos.)

• Que soluções para os clientes foram solicitadas ou sugeridas mas, certamente, não farão parte desce projeto?

• De que modo isso não é uma tecnologia à procura de um problerna?

• O que o projeto não realizará? (Não seja pedante: faça urna lista das coisas que as pessoas prevêem ou supõe1n que fàriain parre do projero, 1nas não furão. Arrole as perspectivas políricas, comerciais e do clienre, se elas ainda não foram cobertas.)

• Quais são as prováveis possibilidades de fracasso deste projeto e como serão evitadas ou minimizadas? (Nos primeiros rascunhos, devem ter sido levantadas apenas as avaliações de riscos, mas sem planos para administrar/evitá-los.)

• De que outras empresas ou grupos este projeto depende para ter sucesso? Que outras empresas ou grupos dependem deste projeto para obterem êxito?

• Em um alto nível, como o trabalho será dividido na equipe? Quem são os líderes de cada subárea imporranre do projeto e que nível de auroridade eles têm?

• Quais são as premissas básicas do projeto? Quais são as dependências desce projero em outros projetos, empresas ou organizações?

Para roda pergunra ou aspecto considerados críticos, deve haver u1n raciocínio extremainente sólido respaldando. O gerente do projeto deve procurar os membros mais inteligentes e mais céticos da equipe, e solicitar que aponten1 as fàlhas existentes

88 A Ai,-íE DO GERENCIAMENTO DE PROJETOS

na lógica e nos argwnenros de apoio por rrás das principais declarações. Corno esses aspecros serão a base de rudo o que vier depois, deverão ser irrefucáveis. Esse processo de feedback é gera1111enre 1nais eficiente quando realizado inforn1almenre, um a um ou en1 grupos n1uico reduzidos, com o gerente do projeto incorporando o feedback e considerando novas perspectivas depois de cada discussão.

Sobre escrever bem

Aré mesmo para aqueles denrre nós que se con1unicam naturalmente bem, as visões e os documentos da liderança trazem consigo o potencial para a pretensão. De repente, surge uma oportunidade de mostrar para a organização inteira a magnitude de nosso raciocínio - é difícil resistir à tentação do ego. Mas a escrita pretensiosa derrota o próprio objetivo; e1n vez. de transmitir idéias, ela as obscurece.

É difícil ser simples

O erro mais comum ao escrever visões é equiparar a complexidade do pensamento à cornplexidade da apresentação. Ao contrário do que muita gente pensa, dá muito mais trabalho expressar idéias sofisticadas de rnodo simples do que o oposto (escrever código e escrever ensaios cornparrilham essa relação). Dez páginas de resu1nos, isenções de responsabilidade, gráficos e diagramas pode1n fucihnente ofuscar as idéias centrais de luna visão. Sua inclusão provaria apenas as incertezas e falta de concisão por parte do autor (e1n qualquer jornal acadêmico ou filosófico você enconn-aní u1na infinidade de exe1nplos disso). Infelizmente, esse comporcainenco é fácil de copiar. Tende a iniciar no topo das organizações e vazar para baixo, gerando níveis quase furais de exageros e excessos de comunicação. Em algumas empresas, fica difícil reconhecer em que idioma o documento foi redigido.

Por esse motivo, o docun1ento de visão define e.ão somente o rumo do projeto. Ele dá o tom e a qualidade da con1unicação que as pessoas devem esperar umas das outras, ao trabalharem no projeto. É uma oportunidade para os líderes de equipes demonstrarem para todos como ir direto ao assunto e se cornunicar bem. Por outro lado, se a visão é exagerada, baseada em jargões, pomposa, altamente especulativa, inconsistente ou até mesmo delirante, não será surpresa alguma se o projeto resultante herdar as mesmas características.

Documentos de visão eficientes nunca se desviam de suas idéias centrais. Eles evitam preF.ícios, isenções de responsabilidade e introduções, e não renram se 01nirir das decisões importantes (e provavel1nenre controversas) que definirão o projeto. Por isso, são geralinence curtos e fáceis de ler. Já. tne deparei com diversos docu1nenros de visão que era1n volun1es pesados que inrin1idavam não somente pelo puro brilhantismo do pensa1nenro que expressavam, mas pelo ra1nanho físico. A inri1nidação funcionava: ninguém lia o docu1nenco.

Escrever bem, demanda um escritor principal

Alguns dos piores documentos de visão que já exa1ninei fora1n gerados por comirês. Ocasionalinence, pequenos con1irês podem acuar como bons

RE01GINDO A VIsAo EFICIENTE 89

divulgadores, 1nas ja1nais deveriam exercer a função de autoria básica ou autoridade de co1nada de decisões. A 1nenos que exisca uma excepcional quí1nica e visão comparrilhada (geralinenre u1na in1possibilidade, considerando-se a polírica dos con1irês), as probabilidades de un1a redaÇ<ío clara, concisa e ardenre são n1fni.mas. Sendo assim, o gerente ou líder de projeto precisa ter autoridade para criar a visão e nela inserir uma concepção, com plena consciência de que seu trabalho não é escrever uma reflexão sobre sua personalidade mas, en1 vez disso, englobar as melhores idéias e pensamentos disponíveis na organização. Esse autor deve ser tun forte colaborador, capaz de incorporar as 1nelhores idéias e opiniões de outras pessoas e1n um ünico documento.

Uma referência canônica para uma autoria li terária de primeira grandeza é a Declaração de Independência dos Estados Unidos. Em 1776, o Congresso Continental formou um comitê para redigir esse documento. O comitê se reuniu várias vezes, 1nas reconhecendo a importância da clareza do documento, solicirou a Tho1nas Jefferson que redigisse u1na versão preliminar da declaração. Quase como estou sugerindo a uma equipe de projeto, Jefferson redigiu alguns rascunhos e parricipou de discussões com o Congresso no decorrer de várias revisões. O grupo enrregou um docu1nento final ao Congresso algumas semanas depois. Essa função não precisa de alta visibilidade; Jefferson não fez uma seção de aurógrafos nem pediu aprovações de produros para seu rrabalho na Declaração. Ele si1nplesmenre recebeu aurorização para fazer uso de suas apridões para 1nelhor acender à sua equipe.

Volume não é qualidade

É i1nporranre entender que o raciocínio claro não exige muiras páginas. Os documentos de liderança mais eficientes do inundo nã.o eram muito extensos. A Constiruição dos Estados Unidos, inclusive o Estatuto de Direitos, tem apenas 7.000 palavras (cerca de 6 páginas). Os 1 O Mandan1entos têm 300 palavras. A Carta Magna ten1 5.000. Os pensadores bons e diretos são capazes de destilar as idéias a seus elementos principais e centrais, e eles as expressa1n de uma 1naneira mais poderosa do que o dobro de páginas o furia. Volume nunca deve ser confundido com qualidade. Infelizmente, como é mais facil produzir volume do que qualidade, às vezes caímos na tentação de "se não conseguirmos ser bons, podemos nos estender o bastante e talvez ninguém perceba" (outro hábito de autoria de líder de comitê). Mesmo levando em conra rudo isso, é jusro perguntar por que não consegui reduzir esre livro. Mea culpa.

Todos esses aspectos i1nplicam que o direito de esboçar e revisar u1na visão deve ser atribuído com caurela. Muito provavelinente, o 1nelhor comunicador na organização não é a pessoa co1n o cargo 1nais imporranre. A mais alra probabilidade de se criar u1na boa visão exige que o líder do projeto conheça os próprios poncos forces e fracos e os dos inregranres de sua equipe.

Esboçando, examinando e revisando

Cada organização ren1 un1 jeiro diferente de planejar os projetos. Não posso apresencar um plano simples, e1n cinco erapas, de con10 parcir do dia l, sem uma

90 A ARºíE DO GERENCIAMENTO DE PROJETOS

visão, para o dia 20 (ou 5 ou 50) com uma visão concluída e rocalmente aprovada. Dependendo de quanca autoridade você exerce ou não, pode levar muico cernpo para se obter rodas as aprovações necessárias e acé que rodas as discussões pavimenrem a base do projero.

Mas o que realmente importa é que o processo de definição da visão comece antes do término do projeto atualn1ente ativo de sua equipe, e deve terminar antes que a equipe parta a toda velocidade para o próximo. O casionalmence, uma pessoa pode ser remanejada de um projero nas úlcimas fases e pode dedicar 1nerade do seu re1npo ao levanramenco das principais questões mencionadas anteriormente. O líder do projeto pode, então, reservar um tempo em seu trabalho e preparar uma versão preli minar mais rapidamente que o faria se estivesse trabalhando sozinho.

Geralmente, a parte mais complexa desse processo, nas o rganizações de médio e grande porre, é crabalhar com a alta adminiscraçã.o e co1n outras equipes para coordenar as necessidades prementes (consulce o Capítulo 16). O CEO ou executivos têm planos para a empresa inteira, que afetarn o próximo projeco? É necessário consulcar engenheiros ou outros líderes que opinam? Quais são os líderes na organização (na equipe local e na empresa inceira) que têrn conhecimento profundo, ou influência política, que devernos conhecer e com os quais deve1nos criar um relacionamenro? Existem idéias básicas que supostan1ente devêssemos apresenrar ou, pelo menos, pensar em fazê-lo? Há outros projetos na en1presa que precisam de nossa contribuição para obterem êxito em seus esforços?

Nos bons momentos, os gerentes seniores apresentam respostas claras para algumas dessas perguntas e confirmam a incerteza gerada para o projeto quando essas perguntas ficam sem resposca. Nos maus momentos, o gerence do projeto recebe o pesado fardo de criar as próprias respostas e descobrir, por tentativa e erro, os verdadeiros limiares. (Como alternativa, se você estiver e1n u.1na pequena empresa e precisar responder apenas para si mesm.o ou para seus parceiros, todas essas indagações e fardos da alta administração serão naturaln1ente, para melhorar ou piorar as coisas, seus.)

Seja qual for o caso, a natureza do trabalho é a 1nesma. Diante de u1n cronograrna projetado entre o término do projeto atual e o 1nomento em que o novo projeto já deverá estar a pleno vapor, os pontos in rermediários devem ser definidos para os rascunhos, análise corn os líderes que representam a equipe inreira e para os primeiros rascunhos cornpletos de urna visão do projero. Esteja cerco de que em cada irem analisado, será gasto um tempo revisando e aprimorando a versão preliminar (e1n vez de supor que roda reunião terininará co1n a sala acenando a cabeça indicando um acordo). Comece por baixo, e aumente gradativamente o apoio ao processo e às principais concepções, aperfeiçoando-as após cada oportunidade de feedback. O cronogra1na desse processo deve ser informado (consulte a Figura 4-3) , e as pessoas no grupo pequeno não devem permanecer inacessíveis ern escricórios especiais ou em outros prédios. Elas deve1n ficar visíveis e acessíveis à equipe (embora se deva tomar cuidado para não desviá-las do projeto atual). Estimular perguntas e visibilidade se1npre ajuda a fazer transições tranqüilas para o novo trabalho.

REDIGINDO A VISÃO EFICIENTE 91

Rascunho inicial 10103

Análise com os lideres 15103

Versão preliminar pública 22103

Reunião geral 25103

Visão final 05104

FIGURA 4-3. Um cronograma básico para analisar e revisar um documento de visão.

Parte desse processo deve incluir uma apresentação das principais concepções e a versão preliminar da visão, para a equipe inteira (uma espécie de reunião geral), com antecedência suficiente para não dar a impressão de ser um completo pretexto, mas agendado tarde o bastante para ainda. aproveitar algo importante a ser dito. Mesmo que isso seja assustador para os novos líderes, se for realizada uma reunião em u1n rnornenro ern que as idéias básicas são 1-orres mas ainda restam algumas dúvidas, todos terão uma oportunidade no projeto de perceber a visão como algo vivo e acessível. Eles não a recusarão se a visão for algo que possam influenciar e sobre a qual possam questionar. Se essa visão evoluir depois de 1nuiros diálogos e oportunidades de feedback, um resulrado favorável à equipe pareceria natural para rodos os participantes.

Quando a visão estiver concluída, a fase do planejarnento terminará (consulre a Figura 4-3). A equipe deve ter as informações necessárias para desenvolver um bom trabalho estrutural, que atenda às 1neras. Se for usado um processo de análise parecido com o da Figura 4-2, a equipe terá uma vantagem na elaboração porque recebeu antecipada1nente a orientação geral.

Um catálogo de declarações de visão ruins (que devem ser evitadas)

Já li dezenas de docu1nentos de visão e1n toda a 1ninha carreira, e existem determinados padrões comuns aos docu1nentos ruins. As visões de baixa qualidade não tê1n integridade; não apresentam um plano ne1n expressam u1na opinião. Em vez disso, especulam e eviram a possibilidade de estarem erradas. Se a visão não assurnir uma posição clara sobre o que deve acontecer, os líderes da equipe nunca investirão emocionaln1ente no esforço, e o projeto estará fadado ao fracasso. No filme Fight Club, Tyler Durden diz que "Colocar penas em sua cabeça não o torna uma galinha". Redigir um docun1ento com o termo visão no título não significa que você tem u1na visão. Você pode realiz.1r todas as reuniões cerras e usar os modelos de documento adequados e não saber a função dos documentos de visão. Da Inesrna forma que ter um título de líder de projeto não transforma magicamente tudo o que você faz em um aro de liderança, atribuir a alguma coisa. o nome documento de visão não significa. que terá os efeitos descritos anteriormente.

92 A AR"IB DO GERENCl1\MENTO DE PROJETOS

A Tabela 4-1 apresen[a alguns aspec[OS comuns que percebi ern docurnen[OS de aparência irnpressionan[e, que os desqualifica1n para a liderança do proje[O.

TABELA 4-1 . Documentos de visão ruins mais comuns

Declaração de visão Exemplo Por que acontece/fracassa • ruim

O exagero Maximize a possibilidade de Genérico demais para ser nossos clientes concluírem útil. Esta é uma declaração seu trabalho. de missão de uma

organização, não uma visão de um projeto.

O disparate Desenvolver, plantar e Este é um discurso de gerenciar um conjunto comitê repleto de jargões. diversificado de ferramentas Usa uma linguagem de gerenciamento de complexa para disfarçar a conhecimento estratégico ausência de idéias sólidas. escaláveis e de desempenho Ninguém consegue saber o para atender da melhor que isso significa, de modo maneira possível a nossos que não pode ser útil. constituintes, parceiros e organizações colaboradoras, aumentando a possibilidade de satisfação geral entre nossos diversos perfis de cliente .

A falta de convicação • As vezes, podemos pensar Todos perceberão que é um em tentar fazer algo um discurso muito fraco e que pouco melhor do que o não há nada que justifique fizemos anteriormente. Pelo uma reunião da equipe. menos, é isso que supomos que deveria ser nossa visão agora. Mas não vá tão longe porque achamos que ela pode mudar de novo em breve.

O que o VP deseja A visão do vice-presidente "E tenho dito" não é um para nossa corporação é ser argumento aceito. Os VPs o maior fabricante de são obrigados a justificar as bugigangas nos mercados decisões importantes, e é de médio porte, e para isso que serve a visão. trabalharemos arduamente para atender ao padrão do VP, investindo todos os recursos disponíveis para que isso aconteça.

REDIGINDO A VIsAo EFICIENTE 93

Exemplos de visões e metas

Nesra seção, apresenro alguns exemplos de boas declarações de visão e meras de projero excraídas de minha experiência. En1bora eu renha 1nodificado os detalhes, é fácil in1aginar como seria crabalhar nesses projetos, assim como o que as 1netas nos basridores das visões poderiam conter.

Eis alguns exe1nplos de boas declarações de visão:

• SuperEdic 3.0, a ferra1nenca de edição para os edicores experiences, facilitará o uso dos cinco 1nais i1nporcances e freqüenres cenários de clienre, tornará esses cenários mais confi;íveis e mais rápidos de operar do que o SuperEdit 2.0.

• O Super\vidgecs.com será o mais imporranre site para compra de bugigangas na lnterner para agentes de compra em corporações de médio porre. Ele Í<lcilirará, agilizará e rornará seguro o processo completo de aquisição desses irens para as empresas de médio porre.

• O Helpdesk Aucomared Services Site (HASS) Versão 5.5 cracará das 10 mais i1nporcances reclamações de clientes na universidade, sem qualquer impacto negativo sobre o desempenho médio, confiabilidade ou agilidade no sisce1na inceiro.

Co1no exe1nplo de 1neras de projetos eficienres, exa1nine o que a equipe de profissionais que desenvolveu o organizador pessoal, Palm Pilor, urilizou para definir seu projeco: 1

1. Tamanho - Cabe no bolso da can1isa. Leve o suficiente para não parecer desajeicado.

2. Cusco - Mais barato que um organizador de papel de luxo (VS$ 300).

3. Simplicidade - Deve ser tão simples quanto o papel. Liga instantaneamente e usa convenções simples.

4. Sincronia com o PC - Usa o PC como u1n ponto comum de interação para o cliente.

Meras de projeto eficientes co1no essas são claras e simples, e descrevem o mundo como ele será quando o rrabalho esriver concluído. Lembre-se de que si1nplicidade é diference de dificuldade. Foi um imporrance desafio escrucural e recnológico cria um produto que arendesse a essas meras. Os exe1nplos anreriores de boas declarações de visão poden1 representar os enormes desafios desses projetos. Dependendo da "i1nportânciá', "facilidade de uso" e "principais reivindicações" definidas, esses projetos poderia1n enfrentar grandes desafios.

Apoiando as declarações de visão e metas

As reivindicações feiras em uma declaração de visão ou nas meras do projeto devem estar respaldadas ou esclarecidas em algum lugar no documento. Sendo assim, a importância dessas declarações por necessidade d~ cliente, fàcilidade de execução, con.fiabilidade e principais argurnentações dos clientes deve ser definida o baseante para permitir a co1nada de decisões abalizadas. Se esses aspectos são

94 A AR-íE DO GERENCIAMENTO DE PROJETOS

imporcances o suficience para conscar na visão, cerão relevância a ponco de recrutar a ajuda de especialiscas para dissecá-los com a n1esma precisão e decalhamenco que as mecas cecnológicas. Se fore1n feicas argumencações do àpo "fácil de usar", mas ningué1n for especialista em fucilidade de uso, a equipe não estará preparada para atingir a mera. Ao preparar a visão, os líderes devem avaliar os recursos necessários ao sucesso e de que modo a falta de recurso e aptidões serão preenchidas (as opções são treinar, conrratar, mudar a visão ou cruzar os dedos).

As visões devem ser visuais

"Urn dedo aponta para a lua, 1nas ai daquele que confondir o dedo co1n a lua."

- Ditado Zen

As visões receberam esse nome por u1n 1nocivo: suposcamence apela1n para nossa capacidade de i1naginar e visualizar um ripo específico de resultado. Quando olha1nos para u1na imagem, assiinila1nos alguns níveis de informações de uma só vez. Para muitos conceitos e idéias complexas, as in1agens proporciona1n para as pessoas um acesso 1nais rápido e n1ais clareza, en1 n1enos ten1po do que as palavras. Já participei de dezenas de discussões, en1 meu escritório, co1n programadores ou arquiceros que se esforçavatn para esclarecer aspectos de tun argumento, e terminavam quando un1 de nós finalmente ia para o quadro, esboçava rapidamente a idéia e perguntava "você queria dizer isso?". Depois, geralmente rodos nós ría1nos do tempo que desperdiçamos tentando explicar os modelos ou estruturas do objeto com nossas palavras ou nossas mãos, quando teria sido muito mais rápido usar uma caneca marcadora e um quadro. Acho que a cultura americana destaca mais as aptidões verbais e matemáticas do que o desenho e as qualidades artísticas, e os reflexos da maioria dos profissionais foram treinados nessa direção. Estou convencido de que, contra nós mesmos, esquecemos o poder das imagens ao expressar idéias.

Os melhores documentos de visão que conheci continham imagens. Eles apresentava1n rascunhos, maquetes ou protólipos de como seria o resulcado final se a visão fosse seguida. Isso era oferecido como sugestões e primeiras amostragens, oferecendo às pessoas apenas uma idéia para ajudar a solidificar as 1necas da visão nas 1nentes dos leitores. f evidente que essas 1naquetes estão longe de ser a versão final do que será criado. Muito longe. En1 vez disso, são apresentadas cão-so1nence con10 uma pri1neira tentativa de preencher as idéias na visão. Essa modalidade de especulação permite que as pessoas conversem sobre o trabalho e1n si, e não apenas abstrações do trabalho favorecidas pela visão.

As 1naqueces e procóàpos geral1nence ressoa1n mais co1n os engenheiros e programadores mais dedicados do que qualquer diagrama de modelos de objeto ou exemplo de código. Diferentemente das formas de expressão abstratas e conhecidas, o protótipo visual mostra algo que ainda não existe, mas pode existir. Os arquitetos de arranha-céus e projetistas de automóveis fazem várias maqueces e protótipos físicos para ajudá-los a conhecer as idéias com as quais estão trabalhando e para obter a opinião de outras pessoas sobre essas idéias. Os produtores de filmes usam storyboards para a mesma finalidade. Os bons documentos de visão não devem se eximir de usar técnicas semelhantes.

REDIGINDO A VIsAo EFICIENTE 95

Apresen[ar um esboço da versão final penni[e que cada indivíduo posicione o próprio [raba1ho e1n um con[exto 1nais a1nplo. Os 1ne1nbros da equipe não estão mais criando um con1ponen[e apenas. Eles já [ê1n u1na idéia do que o componente realizará quando es[iver concluído.

Visualizando coisas não-visuais

Só porque u1n projeto não possui uma in[erface do usuário nem in[erage com os clientes não significa que não pode ser visualizado. O que 1nudará no mundo quando o proje[O estiver terminado? Talvez a visão discorra sobre a eliminação de algum problema ou frustração para as pessoas (servidores lentos, bancos de dados travando etc.). lsso pode ser visualizado, apresentando as visões anterior e posterior (ou simulações) do mesmo site - ou um protótipo que comparava as seqüências de etapas que os clientes deverão executar antes e depois - expressando como as coisas serão mais si1nples quando for possível i1nplementar a nova arquitetura ou banco de dados.

Há sempre mui[as 1naneiras de expressar visualmente as idéias, a despeito de quão abs[ratas ou [écnicas elas sejain. Se o proje[O permi[irá que os clien[es gastem menos tempo em suas mesas, mostre uma cadeira vazia ao lado de uma mesa. Se o projeto agilizará o banco de dados, apresen[e dois de1nos, un1 antes e outro depois. Se o índice de falha de un1a API de siste1na integrada cairá em 1 Oo/o, apresente o teste do caso sendo usado para avaliação, antes e depois do proje[o. Dê à equipe tuna i1nage111 visual, 1nes1110 que seja maçan[e ou desagradável, para emoldurar o trabalho de cada u111.

Se não for possível visualizar esse resultado final - mesmo que seja apenas um esboço, 1naquere ou quadro - eu questionaria o fato de que a visão não está clara. Se você não conseguir vislumbrar uma representação visual do impacto do projeto no universo, provavelmente ele está direcionado para algo que o mundo não precisa, ou não está suficientemente bem definido para obter êxito.

Esse exercício de imaginar o futuro e visualizar idéias, principalmente quando os clientes participam, é a praia dos designers, ocasionalmente chamados de designers de interação, de produto ou até designers industriais. São profissionais treinados em como converter idéias em imagens e abstrair pensamentos nos detalhes do que os clientes verão. Mesmo que os engenheiros ou gerentes de projeto [enhaJU esses talen[OS, alguns os cultivarain em exercícios. Se a facilidade do uso e a satisfação do cliente fore1n metas, os serviços dos designe~-s devem ser adquiridos no início de um projeto, e a inclusão desse aspecto na visão seria apenas uma das contribuições naturais que eles ofereceriam ao projeto. Se forern trazidos com antecedência suficiente e tiverern autorização para realrnente se envolverem, eles não son1enre farão com que tun produto pareça ser born, como tainbétn contribuirão de rnodo significativo para tornar o próprio produto rnuiro bom.

A verificação da sanidade da visão: um culto cotidiano

Un1a das cópias originais da Constituição dos Estados Unidos encontra-se em um cofre-forte, por trás de painéis espessos de Plexiglas®, em um museu, em Washington, D.C. Embora esteja a salvo e seja seguro, renho certeza de que

96 A AR-íE DO GERENCIAMENTO DE PROJE1-os

poucas pessoas a leram nesse fonnaro. Quando as idéias não estão acessíveis ou expostas, elas desaparece1n (a 1nenos que sejam suficientemente importantes para obrer a própria exposi<;<'io nos 1nuseus). Até mesmo nos projetos de curro prazo, é fácil perder o fio de como as decisões cotidianas se enquadram no cenário 1naior, e a falta de visibilidade das idéias básicas propicia esse ripo de entropia. As pessoas podem estar mui.to ocupadas e se sentirem bem quanto aos módulos e peças que esrão construindo, mas sen1 os pontos de referência freqüentes e co1nuns, fica difícil saber se tudo isso ainda está seguindo na direção cerra. A visão, ou as principais idéias e meras que a compõem, deve se manrer viva nos corredores e salas das pessoas que escão realizando o trabalho.

Para manter a visão visível, algumas metas importantes devem ser expostas em cartazes, nos pontos de alto trânsito no corredor. Devem ser discutidas abertamente em reuniões semanais ou mensais, devem ser lidas bem alto para a sala inteira antes do início da reunião. As plataformas para slides ou outros 1nareriais usados pela equipe devem ter algumas dessas referências básicas no pri1neiro slide ou na pri1neira página. Na 1naior parte do te1npo, a 1naioria das pessoas na equipe deve conseguir cirar a 1naioria das nletas do projeto, pelo 1nenos aquelas em que estão contribuindo ou pelas quais são responsáveis.

Mas essa visibilidade não mancérn necessariamente a visão viva. O faro de que as pessoas podem se lembrar dela ou memorizá-la não significa que concinua1n usando e avaliando essa visão para auxiliá-las em seu trabalho. Para manter a visão viva, os líderes da equipe precisan1 ron1ar utna at itude. Precisan1 reaplicar conrinuamenre o mesmo raciocínio que levou à sua criação.

Faça as seguintes perguntas em toda reunião de status ou de liderança ao longo de um projeto:

1. A visão reflete com exat.idão nossas 1netas e intenções neste projeto?

2. A visão está ajudando os chefes e os contribuintes individuais a tomar decisões e a recusar as solicitações fora do escopo?

3. H á mudanças na visão a serem consideradas que tornariam as perguntas nll 1 e n2 2 verdadeiras?

Se os líderes de uma organização puderem tornar o documento de visão algo vivo, eles dariam poderes a todos para fuzer o mesmo. A visão e as meras continuam íntegras e pode1n ser u1na fonte contínua de 1norivação e esclareci1nento para a . . . equipe 1nre1ra.

Isso não quer dizer que a visão deve ser 1nodificada freqüente1nenre. Ao contrário, as grandes alrerações deve1n ser raras depois que o projeto estiver rodando a roda velocidade. Mas assim como aconcece em uma emenda conscirucional, é possível que algumas sicuações juscifiquem uma mudança. E essa possibilidade ajuda a 1nanrer rodos afiados e as idéias centrais da visão, na 1nence de todos.

Resumo

• Os documentos de visão destilam os ourros 1nateriais de planejamento em um único plano de alto nível.

REDIGINDO A V1SÃO EFICIENTE 97

• Redigir concribui para o aucor e para a equipe. Traz a base para a discussão e é u1n ponco de referência que não depende de nossas 1ne1nórias que falham.

• O nível de decalha1nenco em um documenco de visão varia de acordo co1n a nacureza da equipe e do projeco.

• As n1etas da equipe deve1n se originar das metas definidas na visão. As tnecas das pessoas devem proceder das meras da equipe.

• Boas visões são si1nples, orientadas por metas, consolidadas, inspiradoras e memoráveis.

• Volume não quer dizer qualidade. Demora mais ser conciso do que não ser.

• Mancenha a visão viva, questionando a utilidade dessa visão para as decisões cotidianas relacionadas ao projeto.

Capítulo 5

4'•

.~ .. •

•

De onde surgem as idéias

100 A.ARTE DO GERENC[AMENTO DE PROJETOS

A verdade {que não chega a surpreender) sobre a origem das idéias é que elas vêm das pessoas. Na hisrória da hu1nanidade, nenhuma idéia ja1nais se originou de un1a pilha de rochas, u1n n1onre de sujeira quente ou de um pacote de bastões cortantes e pontiagudos. As idéias també1n não surgiram de livros de auto-ajuda, nem de seminários de criatividade nem de sessões de brainstorming. Embora as idéias possam ser apresentadas ou consumidas nesses locais, as fontes são as pessoas que as criam. Aconrece que nos projetos, são os indivíduos - e não os processos, as merodologias ou os co1nirês - que têm idéias e descobrem maneiras de aplicá-las ao trabalho que deve ser realizado.

Portanto, não há nada de mágico nas idéias. Todos nós podemos sugeri-las {mesmo que alguns de nós façam isso melhor do que outros). Nunca se esqueça de que é da natureza fundamental dos seres humanos e de outras criaturas usar sua criatividade e poderes cognitivos para solucionar os problemas que enfrentam no mundo. A despefro do pouco conheci1nenco e experiência que cenha1nos em nossas vidas 1nodernas para aplicar de modo eficiente essas habilidades, elas ainda existe111. Nossa espécie sobrevive basicarnente porque encontramos 111aneiras de lidar co1n os desafios, e invenra111os ferratnenras e esrrarégias para nos ajudar a superá-los. (Embora devamos quesrionar se nossa possibilidade de inventar coisas, como se apresenta atualmente no século XXI, traz mais problemas do que soluções.)

Em relação aos projetos, a habilidade para encontrar boas idéias é in1porcance do pri111eiro ao úlrin10 dia. As boas idéias são necessárias para ron1ar as priineiras decisões do planeja1nenro, desenvolver projetos, escrever um código de qualidade e entregar u1n trabalho que acende às necessidades do cliente. O âmbito dessas idéias pode ser diferenre (por exemplo, algumas afetam o projero inreiro e outras, uma linha do cócügo), mas o processo de descobrir e garimpá-las é muito semelhante. Neste capítulo e no próximo, explicarei esse processo. O foco aqui estará sobre como fuzer brotar idéias e o pensa.mento criativo. O Capitulo 6 definirá como gerenciar o processo criativo e o trabalho com idéias, assin1 que você as tiver.

Usarei na maior parte do ten1po a fase de criação (design) do trabalho (consulte o Capítulo 2) para ilustrar o processo de trabalhar com idéias, que se encaixa basicamen te no intervalo de tempo após a criação de um planejamento de alto nível (por exemplo, a visão), mas antes da implementação. Se você não costuma organizar seu projeto dessa maneira, tudo be111: este capítulo ainda lhe será útil. O aconselhamento apresenrado aqui é facilmenre aplicado a qualquer ripo de situação de solução de problemas ou geração de idéias.

A lacuna entre as exigências e as soluções

Por motivos que não consigo explicar plenamente, muiras pessoas rêm dificuldade de planejar o rrabalho criarivo. Na 1naioria dos livros que li sobre desenvolvimento de so_ftware e gerenciamenro de projetos, falca uma coberrura do que acontece entre a obtenção de uma lista de requisitos para o que deve ser in1plemenrado e u1na boa elaboração. Os cronogramas sempre têm uma data estipulada para o suposto término dos requisitos, e outra data definida para a conclusão das especificações, mas há pouca orientação para o que acontece entre essas duas daras (consulte a Figura 5-1).

DE ÓNDE SuRGEM AS IDÉIAS 101

Planejando "-..T jJ E:specificando

Va' Projetando? j '> FIGURA 5·1. A criação é freqüentemente considerada um processo misterioso entre o planejamento inicial e as especificações concluídas.

Mas tudo bem se o trabalho e111 questão for muito incremental, direto e sin1ples. A arnbigiiidade desse período é aliviada pela simplicidade do trabalho criativo que precisa ser feito. Por oucro lado, a falca de definição da conduta durante a elaboração de alguma coisa leva ao fracasso da equipe. 1 Se os problemas forern complexos, a equipe precisará de tempo para avaliar as diferences abordagens e para conhecer as melhores, antes de um coral compromerimenro com a sua construção.

Assirn como un1 viajante diante de uma bifurcação na estrada, saber para onde você deseja ir ("para casa, por favor") não dá a menor indicação de corno é possível chegar lá ("os três caminhos, pelo menos a partir de onde estou, parecem iguais"). Os viajantes inceligences procura1n maneiras de reduzir ao 1nínimo as chances de entrar e1n um beco se1n saída. Talvez caminhe1n u1na discância pequena en1 cada estrada, ou encontrem oucro ponro de visão (u1n morro, uma montanha, urn satélite espião orbital, geocêntrico, controlado remotamente) que lhe dê mais informações. Quanto maior a distância percorrida em sua jornada, tanto 1naior o investimento em re1npo, necessário à exploração.

Há duas maneiras simples de preencher essa lacuna. Os requisitos de alca qualidade são uma opção, e a exploração da criação é a oucra. Como essas opções estão forternente relacionadas entre si, não é raro que essas duas atividades se sobreponham no decorrer do tempo.

Requisitos de qualidade e evitar erros

No Capítulo 3, apresentei uma explicação básica dos requisitos e suas funções no processo de planejarnenco. Grosseirrunence definidos, os requisitos da qualidade cransrnicem de 1nodo eficiente as necessidades do cliente e/ou as 1necas do projeto, com clareza suficiente para ser acionável por que1n quer que venha a realizar o trabalho. Um bo1n requisito pode não definir co1no solucionar urn problema mas, em vez disso, pode idencificar um problema com cal clareza, que quem tiver o conhecimento adequado certarnence poderá trabalhar na sua solução. A 1naioria das equipes de software e projetos que já encontrei tem pelo rnenos un1 processo informal de requisitos, possivel1nente cão sÍlnples quanto trocas de emails com !iscas de requjsicos de un1a linha, com marcadores.

Os requisitos são crít.icos. Eles acuam como un1 ponto de pru-cida para gerar idéias e possíveis soluções. Se os requisitos declarare1n "Haverá u1n celeiro, que deve ser verde", todos os participantes na fase de criação do projeto pensarão nos diversos tipos de celeiros verdes. Isso ajuda de duas maneiras. Primeiro, evica que muitas idéias sejam consideradas (quem apresentar esboços de espaçonaves azuis pode ser facilmente corrigido). Segundo, permite que os designers façam perguntas para examinar ainda mais os requisitos. Un1 designer pode fazer perguntas básicas,

102 A.ARTE D O G ERENC[AMENTO DE PROJ ETOS

corno "O verde-limão é aceitável ou sornente o verde-escuro?" ou "Qual deve ser a medida do celeiro em metros quadrados?", ou perguntas de alto nível, como "Qual será a urilização do celeiro? Você já pensou em u1n sórão? Provavelmente, é mais barato e pode acomodar melhor as suas necessidades". Dependendo de quem cem os requisitos e autoridade para elaboração (consulte o Capítulo 3), pessoas diferentes terão o poder de decidir con10 as perguntas serão respondidas. Mas todos devem ser estimulados a fazer perguntas e a testar os requisitos, o que aumenta a sua qualidade.

Por conseguinre, quanto mais arenção for dedicada aos requisiros escritos cuidadosamente, tantos maiores as chances de os designers encontrarem soluções para acendê-los. Se nenhum requisito for documentado, quem estiver nesse processo de criação estará trabalhando por seu próprio risco (ou seja, se você estiver criando sem requisitos, calvez seja interessante delinear alguns). Como uma orientação preliminar para requisitos mais eficientes, eis uma lista curta de erros comuns que devem ser evitados ao escrever requisitos (consulte a publicação Expforing l<equirements: Qutifity Before Design, de Donald Gause e Gerald Weinberg, Dorset House, 1989, para obter 1nais inforrnações).

• Apresente um plano para a negociação e iteração dos requisitos. Corno os requisitos permitem que os designers fàça1n pergunras, muito provavelmente algu1nas dessas perguntas serão suficience1nenre boas para obrigar a repensar os requisitos. Que111 quer que tenha autoridade sobre os requisitos deve se preparar para isso e iniciar as discussões con1 os designers con1 antecedência suficiente para incorporá-los, ou para providenciar modificações posteriores nesses requisitos, depois que algun1as idéias foren1 propostas. Quanto mais enfoque os requisiros dedicarem aos problemas específicos que precisan1 ser solucionados, e não aos 1nécodos específicos de solucioná-los, menos necessidade haverá de modificá-los.

• Persiga as premissas errôneas. Freqüentemente, os requisitos pressupõem que o cliente ou usuário necessita ou deseja algo que, na realidade, ele não precisa ou quer. As listas de possíveis requisitos podem começar no email ou em listas informais, e todos poden1 presumir que alguém mais as tenha verificado e examinado criteriosamente. Se você é um gerente de projetos, não faça essa pressuposição. Faça religiosamente perguntas de esclarecin1enco, como "Por que precisamos disso?", "Que problema isso solucionará?" ou "A quem pertence este requisito?", para esclarecer as prernissas. Lembre-se de que é sempre possível que alguém, inocentemenre, interprete mal alguma coisa ou transrnita urna informação incorrera, sem se dar conta disso.

• Persiga as informações ausentes. Os erros mais evidentes, ocorridos nos requisiros são os erros de 01nissão, que pode ser parcial ou coral. Parcial significa que está fulcando u1n aspecto do requisito (por exe1nplo, o formaro do campo da data não está especificado, embora exista um ca1npo de data) ou um requisito inteiro foi negligenciado (o site deve estar em grego e oferecer suporte para o Netscape 2.0). Falta de informações pode revelar duas vertentes totalmente distintas: primeiro, o cliente não se in1porta com esse aspecto do proble1na; ou segundo, o cliente não dá importância mas também não pensou sobre esse aspecto ou se esqueceu de analisá-lo. Exatamente corno acontece com as pressuposições erradas, é responsabilidade do gerente de projetos marcar as

DE ÓNDE SuRGEM AS IDÉIAS 103

infonnações ausen[es e confirmar se essa ocorrência se origina na primeira ou segunda ver[enre.

• Defina as prioridades relativas para cada requisito. Da mes1na fonna como gosraríamos de receber [udo o que es[á especificado e1n nossas lis[as de co1npras, é crítico que os requisitos impliquem, na melhor das hipóteses, no grau de importância de cada requisito em relação aos outros. Ao fazer isso de n1odo relativo, fica mais fácil ocorrere1n negociações entre as pessoas com autoridade para especificar requisitos e aquelas com autoridade para aspectos de engenharia (para obter n1ais detalhes sobre como atribuir prioridades, consulr.e o Capítulo 12).

• Aprimore ou elimine o linguajar inadvertidamente ambíguo. Palavras como rápido, grande, pequeno, bom, bonito e usável exigem 1nedidas relativas para sere1n entendidas. Convém que não dêem margem à ambigüidade, desde que todos os participantes no requisito (cliente, chefe, programador etc.) concordem em negociar as respostas mais adian[e. Caso con[rário, é do interesse de todos os envolvidos na redação dos requisitos manter a ambigüidade somente onde for intencional. Casos de limite ("O carrega1nento da nossa horne page deve ser, no mínimo, cão rápido no Firefox quanto no Ww\v.addison-wesley.co1n; de preferência, deve ser tão rápida quanto o WW\v.oreilly.com") são freqüenren1ente o modo n1aÍs si1nples de diri1nir ambigüidades. Como neste exemplo, os requisitos absolutos (deve haver) e os requisitos desejados (bo1n, nlas pode ficar sem) pode1n ser facilmente indicados.

Usando uma das declarações de problema eiradas nos Capítulos 3 e 4, eis un1a maneira de escrever um requisito de qualidade:

Os resultados da pesquisa serão rapidamente lidos pela maioria dos usuários. Prioridade 1. Nossa meta será melhorar gradativamente a usabilidade de nossa experiência em pesquisa. Recriaremos a página acuai de resultados de pesquisa para solucionar as cinco principais reclamações dos clientes e os cinco principais problemas detectados no próximo estado da usabilidade do design atual. A página recém-criada será a página de resultados exibida a partir das pesquisas inseridas em todos os campos de entrada de busca básica (barra de navegação, home page, carrinho de co1npras) e, se o cusro fo r desprezível, de rodos os campos de busca.

Cercamente, há espaço para mais detalhes, mas fo ra1n evitadas diversas armadilhas dos requisitos em apenas algumas frases. Convém observar que o requisiro é específico quanro à intenção, 1nas não quanto à recriação da página em si. Quanto mais 1ninucioso for o requisito, mais riscos existirão para que o requisito restrinja (desnecessaria1nenre) a elaboração. Isso pode ou não ser desejável, dependendo de quen1 tem que autoridade e conjunto de habilidades.

Exploração da criação

Já que concordamos (não que se tenha escolha) sobre a imporrância dos requisitos, pode1nos discutir sobre co1no explorar as idéias neles baseadas.

104 A ARTE DO GERENC[AMENTO DE PROJETOS

Assirn que os requisicos estiverem em vigor, os designers poderão examinar o território por eles emoldurado. Existe un1 grande espaço, cha1nado de espaço dos proble1nas, de possíveis alternativas para solucionar determinado problema. De acordo com os requisitos, esse espaço pode ser muito grande; por exemplo, há um nú1nero infinito de maneiras de elaborar uma casa, uma refeição, un1 sistema contábil, um site ou qualquer coisa que você esteja sendo pago para fazer. Sendo assim, até ter alguma noção das possibilidades (porque já explorou esse território em questão), não é inteligente se co1nprometer com algo que foi descoberto anteriormente. É improvável que as suas primeiras idéias captadas sejam boas: você ainda está conhecendo o espaço dos problemas e formando uma idéia das possibilidades.

A Figura 5-2 ilustra o espaço dos problemas como oriundo dos requisitos. Assim que um designer começar a examinar as idéias para atender aos requisitos, o espaço dos problemas começará a crescer. Esse espaço cresce porque cada questão ou esboço inicial expõe mais decisões e oportunidades do que era possível perceber anceriormence. Por exernplo, o requisito poderia declarar "O site deve fornecer pesquisa de texto cornpleco de todas as páginas", mas provavelrnente ele não revelará o rnecanismo de pesquisa utilizado, como ele será configurado ou corno a sua interface do usuário será integrada ao restante do site. Ern vez disso, devem-se explorar as diversas possibilidades, e há muitas. (Contudo, o espaço dos problemas, de vez em quando, se afunila. Falaremos sobre isso no próximo capículo.)

Requisitos

definidos 1>•

FIGURA 5-2. As idéias da criação aumentam a partir das definições dos problemas.

Dependendo da natureza dos requisitos, podern existir diversos tipos de limites no espaço dos problemas. Se houver apenas urna semana para pesquisar as alternativas, e a construção da estrutura finaJ precisar custar apenas US$ 1 O, o espaço dos problemas estará muito lirnitado. Um designer estará rescrito a urn conjunto lirnicado de alcernarivas. Na realidade, é totalrnente possível criar requisitos que não possam ser acendidos (por exemplo, criar uma rnáquina de movimento ininterrupto ou solucionar todos os proble1n as de energia nuclear e1n prazo polinomial). O tempo, orça1nenco, conhecin1ento e os critérios específicos do design afetam o fonnaro ou tamanho do espaço dos problen1as. Isso ocorre, ern parte, porque a definição dos requisitos ren1 um grande in1pacto sobre o processo de criação.

Isso também explica por que deve existir um loop de feedback entre a criação e os requisitos. Se for impossível acender a alguns requisitos, considerando as restrições de um espaço de problemas, deve haver alguma maneira de ajustá-los. Como alcernaciva, se um designer tiver uma idéia fantástica que acende às meras do projeto, mas que exige o ajuste de um requisito, é do interesse do cliente/ e1npresa promover essa mudança.

DE ÜNDE SURGEM AS IDÉIAS 105

Não surpreende que u1n trabalho inovador gerahnente ocorra quando uma única pessoa te1n autoridade para requisitos e criação (por exe1nplo, algué1n e1n uma empresa recém-estabelecida, um laboratório de P&D ou em um grupo que delegou a essa pessoa n1uico poder). Essa pessoa pode fazer mudanças nos . . . ... / . requisitos e na cnaçao, por conta propna.

Medo da lacuna e a idéia do andamento

Talvez muitas pessoas saltem o processo de elaboração porque reinem a exploração, principalmente quando são observadas por outras pessoas. Ao examinarmos nosso próprio t rabalho (por exemplo, tentando otimizar um algoritmo ou revisar um documento), não há ninguém para testemunhar esse processo. Temos liberdade para testar idéias constrangedoras ou estranhas porque o único julgamento que enfrentare1nos é o nosso. Mas co1n o processo de criação co1no uma atividade prevista em cronograma para uma equipe, que1n fizer a criação terá suas explorações visíveis para várias outras pessoas. Todo esboço ou protótipo criado por essa pessoa deve ser apresentado aos outros e discutido abertamente. Se não houver uma certeza de que as outras pessoas emitirão uma crítica positiva, não será surpresa alguma que esse processo seja intimidante. 2

Diferenten1ente de corrigir defeitos ou gerar docu1nentos, no trabalho de criação não se sabe como avaliar o anda1nento. En1 vez de observar u1n número aun1entando ou diminuindo, durante a f.'lse de criação, o gerente precisa confiar e1n seu conheciinento desse processo (que pode ser limitado) ou em seu julgamento subjetivo do progresso criativo (que ele pode não cer ou no qual pode não confiar) . Isso é fonnado pelo 111edo de que uma estrutura muito intensa possa restringir as pessoas criativas de realizarem seu trabalho criativo, 1nas tuna estrutura insuficiente pode empurrar um projeto diretamente para o precipício. (Fazendo uma última associação com o Capítulo 6, prometo que explicarei con10 lidar com esse desafio no próximo capítulo.)

De modo geral, acho que o trabalho criativo - quer esteja relacionado à construção de pontes, criação de espaçonaves ou de sites - sofre de vários estereótipos. Os gerentes e líderes devem ser as primeiras pessoas a se livrarem desses rótulos. Especificamente em relação à descoberta de idéias, dois dos piores estereótipos e percepções incorretas estão representados pelas seguintes frases demoníacas: "não existem más idéias" e "pense fora dos padrões". Ao examinar essas frases e as idéias erradas que transmitem, apresentarei algumas alternativas simples de pensar na criatividade, e darei alguns conselhos para encontrar boas idéias.

Existem más idéias

Não sei de onde surgiu a frase "não existe1n 1nás idéias", 111as renho certeza de que está errada. Já 111e deparei con1 essa frase em comerciais de televisão e e1n reuniões de brainstorming (e 1nuito provavelmente em comerciais de televisão sobre reuniões de brainstorming). Essa pequenina e graciosa frase geralmente é empregada em uma tentativa de ajudar a impedir que as pessoas descartem idéias

106 A ARTE DO G ERENCIAMENTO DE PROJETOS

cedo den1ais no processo criarivo - urna mera nobre, com cerreza. Mas quando aplicada a praricamenre rodas as outras siruações que envolve1n soluções de problemas ou a 1nenre criariva, a frase "não exisrem rnás idéias" não poderia ser mais frusrranren1enre falsa. Tenho provas incontestáveis de que existe urn nt'1mero infinito de idéias horríveis, horripilantes, inúteis, comicamente estúpidas e embaraçosamente ruins. Se você prestar atenção ao mundo ao seu redor, é evidente que as pessoas descobrem nlais dessas idéias o cen1po rodo.

Até mes1no com um conjunto de requisiros de primeiro nível, a 1naioria dos possíveis designs exisr.enres ou que poderia1n ser criados não solucionarão os problemas ou atenderão às meras (consulte a Figura 5-3). Na verdade, o espaço de boas soluções para um problema é muito menor do que o espaço de problemas sem soluções. A lógica básica dita o seguinte: se eu pedir a você que escale o Monte Everest, provavelmente haverá diversas rotas que levam ao topo com segurança. Mas se eu lhe pedir que não escale o Monte .Everest, você terá um número infinito de alternativas bem-sucedidas (por exernplo, cutucar o nariz, ler Dickens, escalar ourras montanhas, escalar outras montanhas enquanto cutuca o nariz e lê Dickens etc.). Há sempre mais rnaneiras de não fazer algurna coisa do que de fazê-la (uma consraração que cerramenre gera muiro regozijo enrre os cínicos e preguiçosos em rodo lugar).

• ~ À A minoria dos designs '----' ~li=:=!!!!!'" que solucionam

os problemas

FIGURA 5-3. A maioria dos possíveis desígns não obterá êxito (e aqueles que obtiverem não estarão agrupados, como o diagrama pode suscitar).

Entreranro, o problema reside na dificuldade de se prever as idéias que conduzirão às verdadeiras soluções. Ao conrrário de escalar o Monre Everesr, a maioria dos projeros cobre um território que não é bem mapeado. Você pode usar tecnologias de ponta {leia-se como não-confiáveis), ao tentar solucionar um grupo de problemas novo ou con1plexo, ou ao trabalhar co1n pessoas que não têrn o conhecimento necessário. Há 1nil rnorivos pelos quais seu projeto atual pode ser diferenre dos realizados anterionnenre, e que essa diferença significa a necessidade de urn repensar (criando) para obrer êxiro.

Bom ou mau em relação a quê?

Evidenren1ente, isso se rorna cada vez mais difícil porque nen1 sempre é fácil descobrir se a idéia à sua frenre é boa ou ruim. É possível avaliar idéias no reino

D E ÓNDE SuRGEM AS IDÉIAS 107

da abstração. Elas são boas ou 1nás so1nente ao solucionar determinado problema ou quando atingem um efeito almejado (por exetnplo, fazer alguétn sorrir, fazer coisas explodirem erc.) . Co1no 1nencionado anreriormenre, se o problema for complexo, raramente você descobrirá tuna solução co1npleta, o que significa que uma boa solução é boa apenas em relação às suas alternativas. Se você tiver apenas uma boa idéia, não há base de con1paração e nenhum 111étodo de avaliação adequado. Portanto, se você, algum dia, não tiver alternativas para serem avaliadas entre si, ou u1n problema claro para ser solucionado, será muito difícil julgar a importância de uma idéia.3

Ourra maneira de interpretar isso é que, embora a descoberta da f6rmula E=mc2 tenha sido um belo trabalho de Einstein, não é muito útil para um amigo que se esforça para calcular o saldo da sua conta bancária, ou para alguém atualmente perdido no Deserto do Saara4 (para não citar alguém perdido no deserto e tentando calcular o saldo da sua conta bancária). A fórmula E=1nc2 é u1na boa idéia? Talvez seja se você ampliar seus requisiros e o espaço de problemas, de modo a incluir a idéia geral de au1nentar seu conhecimento do universo. Talvez não seja, se sua única preocupação for o seu atnigo no Saara. As idéias parecetn boas ou ruins apenas em relação a algum ripo de conheci1nenro, e não importa quão inteligente uma idéia possa parecer no nível abstrato, pois quando se trata de projetos que efetivamente constroem algo para solucionar algu1n ripo de proble1na, a falha em não distinguir o abstrato do pragmático sen1pre gera problen1as.

Não é raro que pessoas inteligentes se desvie1n dos problemas reais exisrenres, e1n decorrência das qualidades absrraras de suas idéias. As idéias pode1n ser elegantes, inteligentes e criativas e1n relação a outras idéias que conhecemos, 1nesmo que não solucione1n proble1nas do mundo real. As vezes, uma idéia pode fazer alguém se sentir bem porque apóia uma reivindicação feira por essa pessoa, ou lhe traz u1na vantagem política. Por exe1nplo, um progra1nador poderia discorrer sobre a idéia A e não sobre a B porque a primeira é inais elegante -tendo em vista o n1odelo de objeto que ele projetou - ainda que a idéia A satisfà.ça menos às exigências do clienre. ~ possível que suas exigências pessoais não combinem com os requisitos do projeto, mas ele não percebeu a diferença. Portan to, identifique se1npre as suas verdadeiras motivações para perseguir ou defender uma idéia.

Pensar dentro ou fora dos padrões é perfeito

A segunda frase mais desacreditada e enganosa no tocante às idéias, "pense fora dos padrões", teve a sua origem e1n u1n quebra-cabeças clássico, do tipo charada. O quebra-cabeças, mostrado na Figura 5-4, solicita à sua vírima (ou seja, ao parricipanre) que ligue os nove pontos usando apenas quatro linhas retas - sem erguer a caneca do papel. Acontece que isso é impossível, a menos que a víri1na use o espaço além das fronreiras dos pontos e pense (rufem os ta111bores) fora dos padrões. A questão é que, ao supor que as restrições e fronteiras faze1n parte de u1n problema, li1nita1nos nosso raciocínio e fican1os bloqueados para achar a solução. É uma questão charmosa e quase doce, e eu lhes darei alguns instantes para saboreá-la antes que eu a destrinche.

108 A.ARTE D O G ERENCIAMENTO DE PROJETOS

• • • • :··• ···· ··:#·.· • ~~ # • •••••• • • • • • • • .. .......

• • • • • • • • • • • • • • •• •

FIGURA 5-4. O quebra-cabeças "pense fora dos padrões", com a solução.

Quebra-cabeças e charadas à parte, o mais difícil não é elin1inar os padrões - é saber que padrões deven1 ser usados e quando utilizá-los. Sempre existirão restrições: precisan1os de ar para respirar e alimento para viver. As leis da física vinculam objetos entre si. De ve1.. em quando, as restrições ajudarn a solucionar problemas; por exemplo, digam o que quiserem sobre a gravidade, mas é bom saber que ao colocar uma pedra pontiaguda no chão, ela nã.o vai levantar vôo e . . at1ng1r meu rosto.

Portanto, a verdadeira arte da solução de problemas e da mence criativa é conhecer as restrições a serem aplicadas ou ignoradas, e quando se deve fàzer isso. Já vi pessoas supercriacivas baterem à rninha porca com idéias fantásticas, três sernanas depois da última dara possível para utilizá-las. Tarnbém participei de reuniões de brainstorming para minúsculos projetos, com verbas insuficientes - já arrasados - onde as pessoas apresentavarn suas "maiores e mais radicais idéias fora dos padrões", o que só enfurecia a equipe inteira porque nenhuma dessas boas idéias surgiu sequer próxi1110 ao final do planejamento do projeto.

Alguém precisa orientar a equipe quanto à determinação das restrições/ requisitos que podem ser ignorados, desvirtuados, deturpados ou manipulados, e os que deven1 ser seguidos à risca. Para ser criativo, geralmente é necessário trabalhar dentro de uma restrição, com recursos ou tempo limitados e descobrir nlétodos espertos ou inteligentes de fazer melhor do que o previsto (veja o filn1e Apollo 13). Raramente, são necessárias grandes idéias incríveis e radicais para se obter êxito. Mais freqüentemente, bastam algumas boas idéias básicas e concretas - aplicadas corretamente.

A quescão básica é a seguinte: fàça o que você quiser com o padrão. Pense dentro dos padrões, for.idos padrões, acima dos padrões, abaixo dos padrões, rasgue tudo e toque fogo nos padrões, seja o que for, desde que o seu gerenciamento solucione os problemas identificados co1no meras do projeto. Torne os padrões irrelevantes pa!".i permitir o entendimento dos problemas, para cultivar a energia mais criativa das pessoas e para canalizar roda a energia da equipe para a rnesrna direção. Corno dizia T homas Edison, "Que inferno, não há regras aqui. Estamos tentando realizar algurna coisà'. Certifique-se de que as regras criadas por você sejam positivas para o processo e para as pessoas nele envolvidas, e não o contrário.

TI1n1bé1n é imprescindível ponderar sobre o seguinte: como fi1zer com que as pessoas reflitam sobre os mes1nos proble1nas? Co1no trazer as boas idéias até você? Você te111 alguma idéia de por onde pode começar? Este parágrafo já o está chateando? Be111, surpresa! As coisas geral1nente começam quando fazemos as perguntas cerras. (Sério? Sim. Tern certeza? Absolura. Podemos continuar, então? É claro.)

DE ÓNDE SuRGEM AS IDÉIAS 109

Boas perguntas atraem boas idéias

"Os computadores são inúteis. Eles só pode1n lhe dar respostns."

- Pablo Picasso

Para me esquivar de um monte de exigências acadêmicas indesejáveis, estudei teoria da lógica e filosofia como parte da minha licenciatura. Além das tantas coisas que aprendi e das quais me esqueci, algo que aprendi e que sempre le1nbro é coino fazer boas perguntas . . Eu tinha boas intuições para lógica, como o único aluno não-forrnado em turmas de teoria da lógica de nível de graduação, eu era geralinente (certo, se1npre) o lanterninha do grupo. Aprendi rapidamente que, se eu não fizesse perguntas cuidadosa1nenre articuladas aos parceiros ou rnesrres, eu receberia urn grande volume de inforrnações complexas que não me ajudavam em nada. Na verdade, descobri que muitos engenheiros, médicos e outros especialistas inteligentes rendem a se sentire1n imensa1nente felizes quando co1npartilhan1 o que sabe1n, independen temente de estar relacionado ao que estou perguntando. As pessoas sin1plesmente se perdem no próprio conheci1nento.

Perguntas ben1 feiras são uma n1aneira de conduzir as discussões difíceis por caminhos úteis. Por exemplo, tive esta experiência recorrente com professores de lógica que me obrigavam a prestar atenção ao modo como eu fazia as perguntas. Começou quando eu perguntava algo assim "Você poderia me explicar esta parte do teorema da imperfeição, de Godel?" . E o professor responderia, "Certamente. Con10 você pode perceber, todos os sistemas de provas podem ser reduzidos a um conjunto básico de características definidas pelas funções primitivas recursivas". Eu diria "Uuuumm n1, cerco. Legal. Mas você pode me explicar essa linha aqui?" e eu apontava para essa pequena linha na prova, circulada co1n tinta vermelha espessa e com um gigantesco ponto de interrogação ao lado dela. O profi~ssor balançaria a cabeça e diria "Ahnn, esta, é claro. <Pausa>. Bem, a história dos sistemas de provas de lógica se origina na nobre tentativa de exprirnir aspectos da existência por meio de um sistema verificável". Eu diria "Deus do céu. E esta aqui <apontando novamente>. O que ela significa? Até que ponto ela se relaciona co1n a linha anterior?". Ele responderia co1n "Certamente, certarnente. Entenda, a teoria da prova se relaciona corn a teoria da lógica por causa do le1na da intangibilidade entre conjuntos de valores não-ordinais nlas infinitos". Por úlcitno, eu desistiria e partiria para o bar mais próxin10.

Eu aprendi que sem fazer boas perguntas, eu nunca receberia boas respostas. Às vezes, era difícil obter boas respostas, até 1nes1no ao fazer boas perguntas. Mas eu realmente tentei transmitir esses ensinan1entos, e descobri mais tarde na Microsoft, e no setor técnico, que esses exercícios de perguntas-respostas eram de grande importância. Os problemas de comunicação que eu enfrentava na sala de aula eram sen1elhances aos que ocorriam com os engenheiros, advogados, executivos, profissionais de marketing, designers e clientes. Geralmente, as pessoas insistem em lhe contar coisas que não têm nada a ver co1n o que você precisa saber. Mas colocando de lado minha experiência em aula de lógica, boas perguntas, feiras com firmeza, ajudam a direcionar as discussões para caminhos úteis.

Há três tipos de perguntas a serem consideradas, específicas para a solução criativa de problemas: perguntas focadas (boas), perguntas criativas (boas também) e perguntas de retórica (diabólicas).

110 A.ÁRTE DO GERENC[AMENTO DE PROJETOS

Perguntas focadas

Uma pergunra focada cha1na a arenção de u1na pessoa ou grupo para a ausência de algo imporranre, útil ou até prin1ordial para o trabalho sendo feiro. Esses ripos de perguntas estreira1n de algun1a fonna o ân1bito da discussão e an1plifica1n a atenção dedicada a certos aspectos de tuna situação. É equivalente a "não perturbe com isso, por enquanto, olhe aqui". Presun1indo que o destinatário da pergunra preste atenção a ela, un1a pergunra bem-pensada e direcionada pode ser mais útil do que qualquer quantidade de resposras para bem menos pergunras. "Existe alguma 1naneira de usar a base do código existente para criar u1n sistema que atenda a esse requisito de desempenho?" ou "Como os usuários saberão quando devem acessar esta rela?" ou "Manteiga de amendoim vai bem com chocolate?" Em pouquíssimas palavras, as boas perguntas identificam um componente básico do problema (ou da solução) - ignorando todas as informações secundárias e não­essenciais - e abrem u1n espaço para o surgimento de uma resposta. As pessoas inteligentes sabem, instintiva1nente, quando ouve1n u1n boa pergunta ou u1n bom problema, e vão gostar de atacar, a roda velocidade, assim que reconhecido. As boas perguntas funcionam co1no ímãs, atraindo para elas pessoas inteligentes e criativas, e trazendo, ao longo do percurso, rodas as suas idéias potencialmente boas.

Os excelentes gerentes de projeto e pensadores criativos são mestres em perguntar. Eles percebem quando as coisas estão tomando outro rumo, identifica1n os componentes básicos que estão faltando e1n uma discussão ou planejan1ento, e os reinjetam con1 u1na pergunta cuidadosa1nente cronometrada e articulada. En1 equipes forces, mes1no que o gerente do projeto faça a pergunta errada, o fato de ele interromper a discussão no momento cerco fará con1 que alguém dê u1na resposta certa. "Bem, Scott, nós realmente recusamos esses requisitos. Portanto, uma pergunta mais eficiente seria 'estamos certos de que esse novo design atende à lista atualizada de requisitos?'". E depois de un1a rápida discussão, a equipe inteira já se encontra reenergizada e reenfocada em torno de un1a perspectiva aprin1orada do trabalho a ser realizado. Boas perguntas são catalisadoras: elas fazem um novo mix do conhecin1ento e da energia de uma discussão - aprin1orando, refinando e cristalizando tudo, de uma só vez - e lançam novamente essa energia para adubar u1n terreno de 1nodo mais frutífero.

Descobri, após gerar urn clima de confiança na equipe, que a pergunta mais poderosa em todo gerenciamento de projetos, pensa1nenro criativo e solução de problemas é:

Que problema você está tentando solucionar?

Desde que você tenha credibilidade suficiente, para que essa pergunta não seja considerada con10 um mero discurso da gerência - ela poderá ser usada em pl"'aticamente rodas as discussões, a qualquer momento no início ou final de um projeto, pal"'d ajudar a esclarecer dois aspectos. Primeiro, que a equipe pode identificar o que realmente est.á tentando descobrir e, segundo, que todos os presentes na sala, na ocasião, têm a mes1na resposta (não há nada pior do que cinco pessoas inteligentes t r-abalha,ndo junras mas tentando solucionar, sem saber, problemas diferentes). Isso fi1nciona magicamente bem para tudo, desde discussões de estratégias de alto nível até decisões de detalhes de alto nível da sintaxe do código, especificações de casos de teste ou questões relacionadas à produção do projeto. Foi uma frase assim poderosa e útil que emoldurei acima da minha escrivaninha. Descobri que sempre que o raciocínio

DE ÓNDE SuRGEM AS IDÉIAS 111

do projeto e a geração de idéias escão confusos ou que as pessoas escão dizendo coisas conflirantes, eu não escou sozinho - exisce1n oucras pessoas cão confusas quanco eu. Sendo assim, ao lançar a pergunca-1nescre, esrarei garancindo que codos se reabasceçarn e se recarreguem em torno do que supostainente estejamos fazendo.

Perguntas criativas

Um ripo de pergunca coralmence diference, uma pergunca criativa, funciona exatamenre ao contrário das perguntas focadas. As perguntas criativas indicam os rumos que ainda não foram considerados e que devem ser explorados. "Quantas maneiras diferentes existem para apresentar essas informações aos clientes na ho1ne page?" ou "No que mais o banco de dados do mecanismo de busca pode ser usado?" Geralmente, as discussões do projeto sã.o enriquecidas pelas trocas desses tipos de perguntas entre os colegas da equipe, corn rnuitos raciocínios, esboços e exploração das respostas apresentadas nesse ínterirn. As boas perguntas criativas normalrnente aurnentam o número de alternativas e a1nplia1n o ârnbito da discussão (se bern que não necessaria1nence o escopo do proble1na). Como examinaremos mais adiante nesce capículo, criar um grande pool de idéias é, com freqüência. a única maneira de alcançar as boas idéias. Fazer boas perguntas criacivas prepara uma pessoa criaciva para seguir na direção cerra ou, con10 geralrnente aconcece, em urna direção incorrera que ocasionalmente ajuda as pessoas a descobri rem a cerca.

Perguntas de retórica

Mas cenha cuidado com a gêmea diabólic.1. da pergunra criaciva: a pergunta de retórica. As pergunras de retórica são do ripo capcioso, feiras sem qualquer intenção de obter uma resposta literal. Como um pai ralhando com o filho ("O que você estava pensando quando comeu tuna caixa inteira de sucrilhos?" ou "Como você pôde deixar a Sandrinha passar manteiga de amendoim na cela da televisão?"), as perguntas de retórica tendem a encerrar as discussões. Elas implicam um julgamento negacivo e cheio de culpa. Elas pressupõem que quem pergunta sabe mais do que quem vai responder, e colocam injustamente o destinatário da pergunta em uma posição de poder comprometedora. As pessoas que têm autoridade e sabem usá-la de modo eficiente geralmente fazem perguntas de re tórica (por exemplo, um chefe ou professor frustrado). Ao fazer perguncas dessa 1naneira, rararnente recebem a resposta que almejam. Quando usadas criteriosamente, as perguntas de retórica podem ser divertidas ou poden1 sacudir as pessoas que precisam ser sacudidas ("Francamente, rapazes, isso é o melhor que vocês podem Í.1.zer?"). Mas até co1n essa finalidade, use-as con1 n1oderação.

Tanco as perguntas focadas quanto as criativas ajuda1n a obter a matéria­prirna necessária para o bo1n raciocínio. É preciso ser habilidoso para perceber quando usar cada cipo de pergunta e quando apenas concribuir nas discussões e con1 idéias esponrâneas. Evidentemenre, se a equipe estiver desenvolvendo urn bo1n trabalho e costuma ficar focada além de ser criativa, não há necessidade de desencavar perguntas propositalmente. Acima de tudo, o mais in1portante, no final das contas, é a qualidade das idéias, não as perguncas ou processos específicos que conduziram a elas.

112 A.ARTE DO GERENC[AMENTO DE PROJETOS

Más idéias levam a boas idéias

A primeira vez que vi um designer criando algu1na coisa foi quando eu era terceiro anista na faculdade. Para ser sincero, eu não sabia o que os designers faziam e eu pensava que, na 1naior parte do tempo, eles estilizavam as coisas: designer de jeans, designer de bolsas etc. Enfim, aquele jovem estava criando u1n novo cipo de equipamento estéreo porcácil. Ele se sentava à sua mesa no estúdio de universitários do departamento de criação, que era uma área aberta enonne, co1n várias mesas, esboços, prorótipos e planos de projeto espalhados no local.5 Ele estava esboçando idéias diferentes, cada uma era um design alterna tivo para o estéreo. Perguntei o que ele escava fazendo ou, mais exatamente, de que modo o que ele estava fazendo se encaixava no "aro de criar" qualquer coisa significativa para ele.

Ele pensou durante algum tempo, sorriu e me disse: "Na realidade, eu só me dou conta de que existem boas idéias depois de examinar as ruins". Eu acenei positivamente com a cabeça, 1nas discordei dele totalmente. Atribuí 1ninha impossibilidade de entender o que ele escava dizendo porque eu o considerava u1na pessoa diferente e criativa, e não à minha própria ignorância.

Somente depois de passar uns dois anos criando sofovare é que entendi o que ele escava dizendo. Aprendi com a experiência que as boas idéias geralmente precisam dos restos de nluitas idéias ruins. Se1n co1nerer erros e negligências e1n várias tentativas diferentes, em geral é i1npossível encontrar o caminho das idéias que leva1n ao sucesso (consulce o Capítulo 1). É provável que somente quando uma idéia não funciona e nos depara1nos com o fracasso, somos forçados a examinar nossas premissas. E só então, quando retomamos co1n mais informações, vislumbramos o caminho que não escava visível para nós,

. anrenormenre.

Por conseguinte, as melhores idéias e designs precisam de um ímpeto. Elas não surgem como resultado de uma palavra mágica ou força de vontade ("Seja brilhante agora! Quero dizer, nesre 111omento. Que tal agora mesmo?!"). Cada desenho, esboço ou protótipo, nã.o importa quão ridículo ou patético ele seja, ensina ao designer (ou ao engenheiro ou ao cientista) 1nais u1n pequeno detalhe do problema e aumenta a probabilidade de que a próxima tentativa seja melhor do que a anterior. As pessoas de mente brilhante, que buscaram a solução de problemas complexos no mundo, trabalharam rodeadas de enormes pilhas de papéis ainassados. Algumas delas mentiram a esse respeito, outras reconheceram. Enfim, essa concepção de que as más idéias conduzem a boas idéias nos deixa livres para começar a criar do jeito que escolhermos. Certa1nente, devemos esperar sujar as 1nãos e co1neter 1nuitos erros no início, porque quanto 1nais cedo os co1netermos, tanto antes 1nigrare1nos para idéias rnelhores.

Os bons designs surgem de muitas boas idéias

Solucionar um único problen1a não é a 1neta de urn projeto; há coisas mais ;írduas do que isso. A nlaioria dos projetos de software engloba a solução de dezenas de problemas, de preferência de um modo que os clientes possam facilmente usar e que possa ser construído pelo time de engenharia em pouco ten1po. O nú1nero total de poucos de integração entre peças e co1nponenres envolvidos na criação e

DE ÓNDE SURGEM AS IDÉIAS 113

engenharia de u1n auromóvel, site ou de urn prograrna de software exige que os desi.gners faça1n diversas revisões, na cerreza de que serão necessárias dezenas de renrarivas e ajusres aré acercar rudo. Revisão e aprimorarnento é o norne de jogo, e uma parte do processo.

Todas as atividades criativas, da engenharia às artes, compartilham essa verdade essencial, como afirn1am alguns conhecidos pensadores e criadores:

"As duas fe17amentas rnais irnportantes de urn arquiteto são o apagador, na sala de desenho, e a marreta no focal da construção."

- Frank Lloyd Wright

"A melhorferramenta do ftsico é a sua lixeira de papel."

- Albcrc Einsccin

"Há dias em que faço cinco, rnas deve-se considerar que e1n cada 20 desenhos, somente um será u1n sucesso."

- Vinccnc Van Gogh

"Essa coisa de fracasso não existe. A.s pessoas é que desistem cedo demais."

-Jonas Salk

"Existe urn jeito de.fozer isso melhor - descubra."

-Thomas Edison

"Erre. Erre de novo. Erre melho1:"

-Sa1nuel Becken.

"Se você quer ser bem-sucedido, ®bre sua taxa de erros."

- Tom \Varson, IBM

"Eu escrevo 99 páginas de idiotices para cada página de obra-prima."

-Ernesr Heming.vay

Mes1no que a mera não seja rransfonnar cada projero de s~ftware em uma obra­prima, rodo projero que exige criação e solução de proble1nas deve ter re1npo suficiente para explorar uma grande variedade de idéias alternativas. Também é necessário dar tempo para fuzer a integração entre conceitos e componentes. Os incrédulos e n1esquinhos podem optar por conceder bem menos recursos a essas acividades, mas o preço será sempre pago com a redução da probabilidade de eferivarnence solucionar os proble1nas dos cliences.

E rnesmo se você comprar tudo isso, e se trabalhar ern uma ernpresa que concede tempo para a criação, as coisas ainda serão difíceis. Para ter e criar idéias úteis, são necessárias aptidões diferentes daquelas que a maioria de nós aprende na escola ou que geralmente são ensinadas no ambiente de trabalho. Na realidade, eu mesmo, apesar dos anos de estudo e trabalho em criação, precisei voltar para a escola para receber uma nova aula sobre onde surgem as idéias.

114 A.ARTE DO G ERENC[AMENTO DE PROJETOS

Perspectiva e improvisação

E1n urn desafio de Ayca Yuksel e Vanessa longacre, dois ex-colaboradores na Microsoft, três de nós nos inscrevemos em urna turrna de comédia improvisada, ern urna fàculdade da cornunidade. Só depois do prin1eiro dia, aprendi que era totaln1ente infundado o meu terror na proposta de ser engraçado quando dirigido por algué1n. Percebi que a maioria das pessoas, se aprender a prestar atenção (o que a aula nos ensina a fuzer), descobrirá humor em muiras situações comuns. É só unia questão de ver as coisas que geralmente passam despercebidas, e associar u1na às outras.

Quando voltei para o trabalho e para o mundo dos projetos e designs, eu me dei conta de que acontecia o mesmo em relação à solução de problemas. Os bons solucionadores de problemas observam coisas que os outros não vêem. Eles enxergam mais detalhes, fàzem mais associações e têm uma percepção mais profunda com a qual contam para descobrir ligações entre as coisas. Em uma entrevisra à revista Wired Magazine, Steve Jobs teve sua excelente participação em um cornentário criativo:

Para elaborar algurna coisa realmente bern, é necessário alcançá-la. Você precisa eferiva1nenre groca1"' a essência dessa coisa. Isso exige um comprornerünenro de paixão para enrender profundamente alguma coisa - mastigá-la, e não apenas engoli-la rapidamente. A maioria das pessoas não pára para fazer isso. Criatividade é apenas associar coisas. Ao perguntar a urna pessoa criativa como foi que ela fez algo, é provável que ela se sinta culpada porque, na realidade, ela não fez nada, ela só enxergou. E isso pareceu óbvio para essa pessoa, depois de alguns instantes. Isso aconrece porque as pessoas criativas conseguem associar as experiências que tiveram e as sinrerizam em novas coisas. E elas conseguem fàzer isso porque tiveram mais experiências ou porque refletiram 1nais sobre suas experiências do que as outras pessoas. Infelizmente, esta é uma mercadoria rara. Muitas pessoas no nosso setor industrial não têm tido experiências muito diversificadas. Elas não têm pontos suficientes para ligar e terminam com soluções muito lineares, sen1 uma perspectiva mais an1pla do problema. Quanto mais amplo for o entendimento de alguém sobre a experiência humana, tanto melhores serão as criações que terernos.6

A única reserva que tenho em relação a ess<i citação é o fato de que implic<i a presença de algo especial nas pessoas criativas, que não pode ser obtido pelas pessoas "não-criativas''. Não acredito que as pessoas nasçam para serem colocadas ern uma ou duas pilhas exclusivas de gênios criativos e mentecaptos sem irnaginação. Se a aula de improvisação que recebi foi algurn tipo de indicação, a maioria das pessoas poderá aprender a se tornar mais observadora e a desenvolver, elas rnesrnas, seu senso de percepção do inundo, e das conexões entre as coisas, atendendo aos critérios de Jobs.

Todos na aula (visite o site W\>VW.jetciryimprov.co1n) invent<ivam maneiras de sere1n interessantes e divercidos, 1nesmo que pracicamente nenhum dos alunos -todos adultos, rodos com diferences níveis culrurais e profissionais (e alguns de outros países) - tivesse qualquer experiência prévia e1n comédia e i1nprovisação. Na minha opinião, a i1nprovisação e outros bons exercícios cri<itivos dependen1 de nossa habilidade universal de fazermos uso do que os ourros nos mostram, e nos

* N. de T.: Cornpreender plenamente.

D E ÜNDE SURGEM AS IDÉIAS 115

ajuda1n a ver 1nais clara e profundamence, prescando 1nais acenção. Acredito piamence que u1n desenvolvedor de software compecence, 1nas não excepcional, pode 1nelhorar muico mais escudando a construção de arranha-céus, pontes e aré composições musicais, do que lendo unicamente dentro de sua área.

Evadir-se u1n pouco de um campo específico (mesmo que seja apenas durante algumas horas necessárias para ler un1 livro ou ver um filme) e depois olhar para trás é, em geral, a única maneira de entender o que esse campo realmente significa. Dominar algo deve ser parecido com ficar em pé na parte n1ais alca de uma faixa de n1onranha: pern1ire que você se orgulhe do que fez, mas também fuz com que você perceba quantas outras monra.nhas existem com visões igualmente boas.

Descobri que a aula de improvisação me ajudou a me afastar do meu trabalho e de minhas relações, e crescer de um jeito que eu não conseguiria dentro do meu contexto habitual. Também ajudaram muito nesse processo as quatro regras que apliquei durante os jogos em sala para nos auxi liar a permanecer atentos e 1nanter as idéias Auindo. Descobri 1nais carde que elas se transferiam facilmente para as discussões sobre criação e reuniões de brainstorming de pequenos grupos - situações em que a 1neta era buscar novas idéias e criar urna excensa )isca de conceitos e pensamentos para serem examinados posteriormence.

Devo ad1nicir que, para os céticos e sarcásticos (como este autor), listas de regras a serem seguidas podem parecer um alegre fascis1no (tirania com um sorriso). Contudo, na maioria das vezes, que as renho experi1nenrado - inclusive com equipes fortes, silenciosas, cínicas, pedanrernente sarcásticas, excessivan1ente intelectuais e de baixa energia social - essas regras têm ajudado. Elas conduzem, de modo consisrenre, a discussões 1nelhores, 1nesmo que essas discussões tenha1n iniciado com uma equipe recusando cais regras e apresentando as próprias regras.

Regras de improvisação para a geração de idéias

Para fazer o jogo da improvisação para brainstorming (aviso: não é bom para a incrospecção em criação), você precisará do seguinte: u1n pequeno grupo de pessoas (2 a 8), uma sala confortável, um período de tempo dedicado, pelo menos uma definição de proble1na relevante ao projeto, e alguém posicionado perto de um quadro para anorar descrições curtas de cada idéia sugerida. Se as pessoas precisarem do quadro para explicar as idéias, tudo bem. Mas como a mera é o volume, o detalhe não deve ser o foco.

Para co1neçar, alguém acua como o facilitador e permanece ao lado do quadro. Deve haver uma declaração do problema que define para o quê o grupo está gerando idéias. Pode se originar das declarações de problemas ou de requisi tos, ou pode ser algo aleatório introduzido por você. Assirn que o proble1na estiver estipulado, as pessoas co1neçarão a lançar idéias, que o fàcilitador anocará.

O jogo começa quando algué1n sugere uma idéia e a discussão acontece. Há quatro regras a serem seguidas nessa discussão:

1. Siin, e ... Quando alguén1 1nais lança un1 pensa1nento, a t'rnica resposta pern1itida é "Sim, e <insira alguma coisa aqui>". Sua primeira tentativa seria continuar essa linha de raciocínio. Geralmence, você usa essa idéia ou ponto e desloca-a para frente ou redireciona-a, con10 "Poderíamos usar uma caixa de rexro aqui ... ", "Sim, e ela seria suficience1nenre inteligente para crazer o usuário

116 A.ARTE DO GERENC[AMENTO DE PROJETOS

para o lado direico quando ele digicasse algo". Ou, "Sim, e ela poderia usar o novo 1necanis1no de busca que esca1nos criando e recornar resulcados mais rapidamente". A incenção é 1nanter as coisas se movendo positiva1nente e desenvolver o hábito de ouvir os outros para ajudá-los em suas idéias, en1 vez de cão-somente esperar para contar as suas.

2. Sem meias desculpas. Não é permitido lançar urna idéia seguida por "Desculpem, sei que é brega" ou "Não sou bom ein ser criativo". Meias desculpas significam não ter compron1isso com o que está sendo dito. O que você diz não precisa ser brilhante. Tudo bem se sua idéia for ruim: ela só precisa provocar alguérn a dizer algo melhor. Se você confia na pessoa a seu lado para dizer "Sim, e ... ", talvez ela consiga fazer algo interessan te com sua idéia "torpe" que, de outra forma, nem ela nem você teriam imaginado.

3. Sem p erguntas de bloqueio. As perguntas de bloqueio colocarn na defensiva as idéias e as pessoas que as estiverern perguntando. Se você disser "Por que, diabos, você faria isso?", estará e1noldurando u1n novo contexto em torno do que a outra pessoa disse, que não é improvisado - é crítico. Pressupõe que não há um bom motivo para isso até que se prove o contrário, o que não traduz o clima certo para abrir e liberar a mente (ernbora seja a atrnosfera certa, mais adiante, em introspecções sobre criaç,'ío). En1 vez disso, teste seu próprio intelecto: co1no você pode direcionar a idéia inicial dessas pessoas para algo t'1ti!? Faça as pressuposições ou os mergulhos na fé necessários para dar sentido à declaração de alguém. Flua co1n essa declaração e continue fluindo . Perguntas curtas e esclarecedoras podem ser adequadas na ocasião, mas não as torne o foco da questão. É melhor passar para a idéia seguinte do que se li1nitar a algumas, isoladamente. Se a mera é a geração de idéias cruas, o volume de idéias por hora é inais importante do que a qualidade de cada idéia. Para a nleta global de geração de idéias, talvez seja melhor não dizer nada do que discursar sobre quão inexpressiva é uma idéia.

4. Faça alguém parecer bem. Ninguém deve pontuar ou rastrear quem disse o quê. As recompensas devem ser das pessoas que ajudam a amplificar, expressar ou extrair as melhores idéias dos outros no grupo. Corno provavelmente o que for elaborado será construído por alguém na sala, não faz sentido prerniar algué1n ou classificar as idéias co1n base no seu criador. Se o processo de criação começar com um processo co1num saudável, onde as melhores idéias surgem independentemente de suas origens, é bem provável que o restante do projeto herde o mes1no espírito.

O resultado dessa modalidade de exercício deve ser un1a lista de idéias imperfeitas e incompletas, que alguém classificará posteriormente. Ao fazer isso, essa pessoa escolherá as idéias suficiente1nente interessantes para serem perseguidas ou discutidas mais detalhadamente. Corno essas discussões de acompanharnento têm menos a ver com a geração de idéias cruas, as regras de improvisações não se aplicam canto - embora o espírito delas deva permanecer.

Outras abordagens para a geração de idéias

Se você não se sence preparado para jogos de i1nprovisação ou se prefere utn modo nlais direro de gerar idéias, eis algumas sugestões tradicionais:

D E ÓNDE SuRGEM AS IDÉIAS 117

• Escolha um livro sobre a mente criativa. Você enconcrará bons livros desse gênero. Dois dos 1neus favoricos são Thinkertoys, de Michael Michalko, e Six Thinking 1-fats, de Ed>vard De Bono. Vários oucros livros populares são muico bons ca1nbém, aproveicei n1uico esses dois.

• Preste atenção ao momento em que você se sente mais criativo. Descubra os ambiences que facilitam ao máximo sua criatividade. Quando está sozinho? Quando está acompanhado (com que pessoas)? Con1 ou sem música? Que gênero musical? Todos nós somos diferentes e você não se conectará com a sua criatividade se não passar algum ten1po detectando os ambientes que lhe trazem inspiração. Talvez seja em uma cafeteria aconchegante, meditando em um banco no parque sob as árvores ou observando o pôr-do-sol lentamente na linha do horizonte, atrás da Ponte do Brooklyn.

• Reconheça que a persistência contribui para a criatividade. As pessoas que parecem criativas necessariamente não apresenta1n idéias co1n mais fàcilidade do que você. Mas elas podem passar mais cempo exercicando essas parces de seus cérebros e mantendo-as flexíveis. A criatividade é uma apcidão como qualquer oucra, e mes1no que rodos nós não iniciemos com os mesmos dons, qualquer pessoa pode n1elhorar decenninado aspecto se investir energia suficiente.

• Co1npre o baralho de cartas de brainstorming, ThinkPak, criado por Michael Michalko. É un1 conjunto de cartas elaborado para ajudar as pessoas ou grupos a terem novas idéias para qualquer tipo de desafio. Você enconcrará outros conjuntos como esse, mas obtive mais êxito con1 esse do que com os outros. (O ThinkPak está disponível em W\vw.amazon.con1.)

A experiência do cliente dá início à criação

"Os visionários tecnológicos podem nunca perceber a diferença entre o viável e o desejável. " - Ed,vard Mendelson

Se a melhor arquitetura do inundo for escrita con1 os n1elhores modelos de objeco, com os 1nelhores algoritmos e co1n a 1nais veloz e 1nais confiável base de código jamais concebida, ainda assi1n poderá ser totalmente inútil se os clientes para os qu<ÚS esse trabalho foi desenvolvido não souberem co1no fazer o que necessicam corn ele. Seria um desperdício desses algoriunos e dessas horas-home1n de esforço de engenharia, porque ninguérn experimentaria a qualidade do trabalho concluído.

O único seguro concra isso é iniciar o processo de criação e o esforço de engenharia de ci1na para baixo - a partir do que o cliente verá na tela, descendo aos con1ponentes de alto nível e descendo mais ainda até as especificações do trabalho. Assim que os conceitos iniciais do que o usuário experimentará forem esboçados, os engenheiros e tecnólogos devem responder acé que ponto o que eles escavam pensando se encaixa nesses conceitos. Os projetos podem ser construídos? Quais são os co1npromerimenros? Quais são as restrições? O crabalho continua, com o fluir das discussões entre camadas do projeto e os diferentes especialistas na equipe, para garantir que, com o andamento do trabalho, a integridade da experiência do usuário seja mantida, sem violar o que é possível (e provável), segundo os engenheiros. O raciocínio do projeto se movimentará em duas

118 A.ARTE DO G ERENCIAMENTO DE PROJETOS

direções: a parrir da experiência altnejada do clience acé a recnologia, e a parcir da tecnologia prácica acé a experiência do clience (consulce a Figura 5-5).

Experiéincia do cliente Experiéincia do cliente

Tecnologia Tecnologia

FIGURA 5-5. O melhor processo de criação integra o design centrado no cliente com as considerações práticas para a tecnologia disponível. Se um deles for elaborado isoladamente, o outro estará sempre comprometido.

As sessões de brainstorrning deve1n esclarecer quando e onde deve ser iniciado o trabalho de criação. Muicas das primeiras idéias geradas no brainstorrning provavelmence descrevem algum 1nodo de criar o siscerna para solucionar um problema. Cada urna dessas idéias cem pelo 1nenos u1na represencação visual - em termos de como o softivare ou o site realmence pareceria para alguérn tencando usá-lo - isso pode ser esboçado e discutido sem precisar escrever uma única linha de código. (Se o projeto for un1 sisterna incorporado ou un1 kernel de sisce1na operacional - sistemas se1n qualquer interface do usuário tangível - então, deve-se dar atenção a que condições nunca são aceitas.)

Atingir essas representações, esboços, desenhos iniciais ou, e1n alguns casos, protótipos, é a pritneira erapa para encender a idéia. Se ela não pode ser desenhada nem esboçada, cerramence não poderá ser criada. Diagramas UML e Visio não são a mesma coisa que um croqui de desenho. Diagramas são abstrações. Eles nã.o mostram o que o usuário verá e, por conseguince, podem ocultar todo o tipo de problema e detalhes que precisam ser analisados.

Eis alguns exemplos de problernas que incluí no Capítulo 3: "é difícil encontrar os itens comumente usados na horne page". Vamos presu1nir que depois de u1na sessão de brainstorming, foram detectadas crês idéias decentes:

l . Priorizar dinamicarnence a página, de acordo com o que as pessoas usa1n .

2. Eliminar os itens que nunca são clicados pelas pessoas.

3. Organizar a home page e1n grupos que façatn sentido para os clientes.

Ai1ces que qualquer engenheiro possa pensar e1n como construir essas coisas, alguém deve considerar os méritos das idéias sob o prisma da experiência do cliente. Acontece que por mais maravilhosas essas idéias possam parecer em term.os abstratos, ninguém consegue construir um bom design? que as incorpore, de modo a fàcilicar o trabalho que o cliente precisa fazer. Por esse motivo, é de interesse da equipe co1neçar com a experiência do cliente: é a maneira 1nais fácil de evitar o crabalho desnecessário, esclarecer o design que será desenvolvido e por que será. criado e reduzir as probabilidades de ter que implernenrar 1nudanças

DE ÓNDE SuRGEM AS IDÉIAS 119

rnais tarde. Não é fiícil gerenciar esse processo, mas fazer de modo deficiente ainda é rnelhor do que não fazê-lo em hipótese algurna.

Um projeto é uma seqüência de diálogos

Con1 alguns esboços de possíveis interfaces do usuário, é possível iniciar o verdadeiro trabalho de criação. Uma análise informal dos esboços, co1n os engenheiros, rescadores e profissionais de marketing, pode iniciar os verdadeiros diálogos que levam ao progresso. Um engenheiro pode fazer uma recomendação de última hora para um clesigner sobre o trabalho em questão ou sugerir mudanças no design que facilitem ainda mais a construção. Várias perguntas boas serão lançadas em ambas as direções. O engenheiro também pode conscientizar o designer sobre as opções tecnicamente viáveis, que o designer não percebeu ("Oh, com o novo capacitor de fluxo que estamos construindo, você pode eliminar essa tela"). Quanto mais cedo essa discussão começar, tanto mais rapidamente o diálogo se fortalecerá, e rnais idéias poderão ser levantadas, consideradas e exatninadas.

É importanre que rodos percebatn o processo pelo que ele significa: uma série de tentativas, discussões, perguntas e introspecções que se repetem até surgiren1 proposras satisfatórias (ocasionalmente documenradas ern especificações). Se algué1n não quiser participar nesse tipo de trabalho fluido, deverá abrir mão de un1a parte de sua autoridade no processo de ton1ada de decisões para aqueles que realmente participarem. Criação não é a mesma coisa que engenharia, e ernbora a presença de engenheiros no processo de criação renda a melhorar os projetos, é melhor retirar indivíduos do núcleo do processo do que renrar e mudar um processo para atender a um indivíduo.

Se as meras do projeto forem claras e os problemas a serem solucionados forem identificados, a natureza dos diálogos do processo de criação subseqüentes tan1bém será boa. Ocorrerão discordâncias, mas se cada um tentar solucionar o mesmo problema, os conflitos hão de parar por aí. E considerando os aspectos mencionados no início deste capítulo sobre a importância da perspectiva, esses problemas podem expandir as perspectivas das pessoas. Corno as regras da improvisação sugerem, a idéia de uma pessoa pode ser o ponto de partida para que alguérn com urn nível de conhecimento ou co1n u1na opinião diference sugira algo cocalmence inesperado e rnuico melhor do que foi proposto inicialmente.

"Gosto de trabalhar corn boas pessoas porque se eu tiver urna idéia, elas terão uma idéia 1nelho1~ e depois eu terei uma idéia ainda melhor, e assim por diante:

é u111 processo de dar u1n salto à .frente, e o trabalho se torna melhor do que seria se eu só fizesse o que eu quero''.

- Terry Gillian1, direror de filmes

O ripo de colaboração descrito por Gilliarn só é possível quando os metnbros de uma equipe confiam uns nos outros. Geralmente, os gerentes e líderes se encarregam de gerar ambientes de confiança e que precisa1n estar abertos a boas idéias, independentemente de suas origens. Falaremos mais sobre isso no Capítulo 12.

120 A ARTE DO G ERENCIAMENTO DE PROJETOS

Resumo

• Muicas equipes não gerenciam adequada1nence o ce1npo enrre os requisiros e as especificações.

• As exigências da qualidade e as explorações para a criação são as n1elhores utilizações desse te1npo.

• As idéias são boas ou ruins somente e1n relação às metas e a outras idéias.

• As restrições ajudam a ter idéias, mas pensar fora dos padrões não é necessariamente a resposta. Às vezes, a melhor solução é descobrir uma maneira criativa de trabalhar dentro das limitações.

• Perguntas, perspectivas e jogos de improvisação são ferramentas para ter novas idéias.

• O 1nelhor lugar para iniciar as idéias do design é a experiência do clience.

• As idéias se desenvolvem e1n criações, através de diálogos entre pessoas diferences co1n ripos diferences de experiência.

Capítulo 6

O que fazer com as idéias quando você as tiver

122 A.ARTE DO GERENC[AMENTO DE PROJETOS

A ssim como é árduo encontrar boas idéias, é 1nais difícil ainda gerenciá-las. Mes1no que o projero esteja indo bem, o docu1nenro de visão esreja preparado e un1 forre ín1pero criativo esteja se desenvolvendo, há um outro nível de raciocínio que deve ocorrer: como os designs e as idéias serão convertidos e1n decisões? Ainda que os designs e as idéias estejam sendo investigados e as pessoas e.stejam encusias1nadas con1 o seu trabalho, o desafio de convergência para as especificações continua. Se uma 1nudança do í1npeto para decisões definitivas do design não ocorrer no 1no1nenro cerro e se não for gerenciada de modo correto, espere por desastres. Por vários motivos, o fracasso do projeto começa aqui.

Se a equipe ainda estiver lutando para romar grandes decisões no dia em que os programadores precisarem das especificações (ou das decisões nelas contidas), já estará definido o com para o restante do projeto: haverá atrasos, darão meias desculpas e as pessoas não conseguirão dar o melhor de si. O mais problemático é que mesmo que as coisas sejam concluídas em tempo hábil, se a qualidade das idéias refletidas nos designs for rui1n, a poncualidade não terá i1nportância. Dependendo das metas do projeto, a qualidade das idéias pode contar tanto quanto ou mais do que a pontualidade.

Por esses 1notivos, o rempo entre a conclusão do planejamenco inicial e a redação das especificações, em qualquer marco é sempre severo. A tensão na equipe aumenta naturalmente quando a primeira dara limite importante (por exen1plo, as especificações) acena no horizonte. Mesmo que as pessoas não conversem sobre isso, várias delas reconhecen1 que nen1 todas as idéias ainda e1n discussão sobreviverão. Não haverá te111po, verba ou pessoas suficientes para const.ruir todos os diversos aspectos em consideração. As pessoas co1neçan1 a vislu1nbrar 1naneiras de cobrir seus compro1nissos ou ro1nar atalhos. Pior ainda, algumas idéias e designs podem entrar em conflito uns com os outros. Um carro só pode ter un1 motor, uma casa, u1n telhado, e se três alternativas diferentes para esses itens ran1bém forem sugeridas, evidentemente que a maioria delas não chegará a aconcecer.

Idéias fogem ao controle

Acualmenre uma observação frusrranre é a existência de muitas idéias pairando no ar, que parecem nã.o aterrissar em lugar algum. Talvez a pior experiência de minha carreira - nessa etapa de um projeto - ocorreu durante a criação do lnrerner Explorer 4.0. (Se você não estiver interessado em outra história de guerra, sinta-se à vontade para avançar para a seção seguinte.)

Le1nbro-1ne de estar sentado e1n 1ninha sala olhando fixamente para 1neu quadro branco. Oucro GP e eu fizemos um diagra1na 1naior da equipe do projero e de rodos os recursos em que esníva1nos rrabalhando. Sempre que achávamos que escava concluído, nós nos lembráva1nos de u1n novo requisiro adicionado ou alterado. Quando renninamos, o quadro escava roral1nenre preenchido. De repente, o outro GP foi para uma reunião e eu fiquei sozinho em 1ninha sala com aquele diagrama diabólico.

Eu cinha muito trabalho a fuzer, 1nas eu n1e sentei e olhei fixan1ente para o tal diagrama. Não conseguia imaginar con10 o diagra1na rinha chegado àquele ponto. A dimensão de cada problema que renrávamos solucionar era tão grande e

O QUE FAZER COM AS IDÉIAS QuANDO Voct. AS T 1vER 123

ocorria canca sobreposição com oucros problemas, que eu não conseguia guardar cudo em minha cabeça ao 1nesrno ce1npo. Eu adorava 1ninha equipe e meu rrabalho, 1nas esse senri1nenro não me proregia concra 1neu desespero cada vez maior. Eu não conseguia vislumbrar co1no terminaríamos o que tínhamos começado. Embora fosse uma bagunça promissora, repleta de coisas inteligentes, não deixava de ser uma bagunça. Um colega da equipe espichou a cabeça para dentro da minha sala, viu a expressão no n1eu rosto e o diagra1na que eu estava olhando, e compreendeu imediatamence. Ele disse "Ei, sinta o amor!", frase que se tornou nosso clamor sarcástico revigorante pelo rescante do projeto.

Nos primeiros meses do projeto IE 4.0, enfrentamos uma completa tormenta de desenvolvimento de software. Esr;ívamos tentando mudar simultaneamente de pequenas versões (como a 2.0 e a 3.0) para uma versão importante do produto. T ínhamos a pressão do setor advinda da concorrência da Microsoft com o Nerscape, que a imprensa transformava em uma batalha ao estilo "o vencedor leva tudo". Depois ocorreram as políticas internas de um produto transfonnador, ainda que estratégico. Era difícil 1nanter o equilíbrio do barco. Co1no acontece na 1naioria dos projetos, é quando o Ílnpeto passa do planeja1nenco para a engenharia, que os egos e as opiniões afloram. As pessoas enfrentavam suas primeiras decisões difíceis e sentiam as pressões de seus compromecimencos. A medida que as incercezas e pressões se cornava1n cada vez mais evidentes, um aspecto não mudava: os prazos. A próxima dara pairava i1npacienremente no horizonte, aproximando-se a cada dia. 1

A solução, que é o foco deste capítulo, é gerenciar con1 cuidado o ca1npos dos possíveis designs. É necessário planejar e direcionar cada n1arco, desde a exploração até a especificação. A 1nenos que exista um campeão experience em design ou engenharia por perco para co1nandar esse esforço (o que, co1no mencionado no capítulo anterior, é a melhor maneira), a carga recai sobre o gerente de projetos mais próximo. Partindo do ponto onde parou o Capítulo 5. trataremos de virar a esquina da geração de idéias e avançar na redação das especificações (um tópico adequadamente discutido no próxin10 capít.ulo).

Para gerenciar idéias, é necessário pulso forte

O erro mais comum é considerar o processo da criação (design) como se fosse um enorme interruptor de luz - basta ligar e desligar à vontade. Com o passar do tempo, essa fantasia acontece assim: e1n determinado dia, você percebe que as coisas vão atrasar e que há 1nuiras idéias e designs (e decisões insuficientes), e diz para a equipe "OK, já chega de idéias. Escolha1n u1n design e va1nos começar a codificar! Ao trabalho!" Mesmo co1n a hipótese remota de existir um design prontinho para o horário nobre (o que não exiscirá), esse tipo de comporcamenco imprevisível desoriencará e confundirá a equipe inteira. Até aquele 1nomento, rodos escavam crabalhando em designs que exigiam cempo para serem concluídos. Sem uma dara estipulada, calvez eles rivesse1n pensado que rinha1n até as 11 h591nin da noite para suas especulações se tornaren1 suas grandes decisões.

E1n vez disso, o planejamento das boas idéias é decisivo 1nas previsível. Nunca deve ser uma surpresa que a natureza do projeto está mudando (a menos que haja uma crise) ou que o foco da energia está deslocando porque o projeto escá entrando em oucra fase. Deve haver lembretes fáceis e naturais

124 A ARTE DO G ERENCIAMENTO DE PROJETOS

para a equipe, quando o escopo e a ênfase mudarern . Corno um interruptor de concrole da incensidade da luz - do cipo com um bocão que concrola a mudança - deve ocorrer uma n1udança gradariva do foco. O gerenre de projeto deve gerenciar esse incerrupcor e certificar-se de controlá-lo co1n pulso forte. Haverá um momento em que alguém dirá "Atenção. Acabou o tempo. É A ou B?", mas esse momento deve ser aguardado com dias ou semanas de anrecedência. Talvez seja necessário acelerar ou desacelerar o ritmo, mas isso deve ser feiro com boas maneiras.

A rírulo de iluscração, a Figura 6-1 apresenra de modo convenienre uma visão idealizada da fase criativa de um projeto, com um momento singular em que os problemas e meras foram definidos (documento de visão e/ou requisitos) e um único momento em que as especificações estarão concluídas. Entre esses dois momentos, transcorrem as atividades de brainstorming, esboço, criação, elaboração do protótipo e todo o tipo de outras atividades divertidas, descritas no Capítulo 5 . Na primeira metade do tempo disponível, todos estão concentrados e1n ter idéias e ern au 1nen tar o espaço dos designs alcernacivos. Na segunda rnecade, a ênfase se desloca para afunilar o carnpo, aprimorando e aperfeiçoando os melhores designs. Ocasionalrnente, chega o momento ern que foram tomadas decisões de design suficientes para documentar codas elas em uma especificação.

Definição dos prob/e1nas

Espaço dos problemas (explorando alternativas) • 1

Escrevendo especificações para um único design

&-=====-'> O tempo segue nesta direção

FIGURA 6-1. O espaço dos problemas deve estar reduzido no momento decisivo.

Esta é uma boa história e um diagrama legal, e sinto orgulho com a presença deles nesce livro. Contudo, como acontece com 1nuiros diagramas legais, o único retratado aqui representa algo que nunca acontece. Linhas recas e ângulos perfeitos não existem. O gerenciarnenco de idéias, assim corno grande parte do gerencia1nenco de projetos, é sernpre um processo difuso e subjecivo (consulce os oico paradoxos do gerenciamenco de projecos, no Capículo 1), e há vários 1notivos irnporcances pelos quais esse diagrarna é inexato.

Pri1neiro, o espaço dos problernas rende a mudar conscancemence. Nunca é uma linha na cor amarelo vivo, presa no lugar. Entender os problemas a serem solucionados - e como solucioná-los - não é uma atividade estática, o espaço das possíveis alternativas está sen1pre au1nencando e diminuindo. Os requisitos serão ajustados. Há uma tendência maior para o espaço crescer do que encolher, ou encolher mais do que crescer, mas nunca é uma coisa ou outra. É mais uma linha curva difusa do que uma linha reca.

O QUE FAZER COM AS IDÉIAS QuANDO Voct. AS 1~1vER 125

Os 1norivos comuns são:

• Novas informações são disponibilizadas. O mundo não pára porque o seu projero esrá en1 andan1enro. En1presas podem sair do ran10. Urna cecnologia pode fulhar. Os orçamentos podem mudar. Un1 estudo da usabilidade ou uma entrevisra com o clience pode revelar um novo insight no problema ("as pessoas imprimem documentos muito mais do que supomos" ou "os usuários sequer conseguem executar suas tarefas básicas na página inicial de nosso protótipo").

• O plano de um engenheiro foi esclarecido, alterando as estimativas aproximadas do possível volume de trabalho. O raciocínio inicial sempre dá 1nargem a um raciocínio rnelhor, posteriorrnente. Às vezes, isso funciona a favor do projeto, outras vezes, contra o projeto. Por exernplo, é possível que um programador descubra uma nova estracégia de implementação: "se construirmos por esse novo rnécodo, não será necessário desenvolver cinco das outras especificações do processo, e haverá mais ternpo para outra atividade, ou podemos terminar ances {viva!)" ou "como não podemos construir conforme previsto inicialmente, precisamos desenvolver cinco especificações de processo adicionais, o que significa menos ternpo para outro trabalho, ou podemos arrasar o término (droga!)".

• São detectados conflitos entre duas soluções para dois proble1nas diferentes que, quando integradas, prejudicam-se inutuainente. Isso pode acontecer por 1nocivos de usabilidade, co1nerciais e de engenharia. José pode rer u1n design fantástico para un1 motor de auromóvel, e Sally pode ter um excelente design para uma transmissão, mas quando eles se juntam, percebem que os aspectos de cada design entram em conflito; por exemplo, a transn1issão não se encaixa no moror.

Mudanças causam reações em cadeia

Oucro motivo pelo qual o espaço dos problemas muda é que as decisões do design são inter-relacionadas: uma mudança pode afetar várias outras decisões. Diante dessa interdependência, é impossível prever totalmente todos os impactos. Já vi isso acontecer várias vezes.

No projeto IE 5.0, uma de nossas rnecas era melhorar a possibilidade das pessoas organizarern suas listas de sites f.-ivoritos. Exarninamos quatro designs distintos e criamos protótipos simples de interface do usuário (UI) para cada urn. Co1n esses protótipos, fize1nos escirnacivas da engenharia e obcive1nos inforrnações básicas sobre a usabilidade para serem aplicadas e1n co1nparaçóes. Co1n a iminência do arraso das especificações, opta1nos por nos concentrar no design B. Mas alguns dias depois, souben1os que, devido a urna mudança no cronogra111a de outro projeto, um co1nponence do qual o design B dependia não estaria disponível. Sendo assirn, riven1os que volrar acrás e reavaliar a nossa escolha.

Con1 isso, descobrimos que todos os outros designs também precisavam do mesmo con1ponente (ai, ai, ai!). Então, quando corramos a funcionalidade (ou seja, elin1inamos o requisito) que o componente problemático ceria oferecido, soubemos que oucros programadores esperavam que lhes oferecêssemos essa funcionalidade acravés de nosso código. Esse co1nponente era mais i1nporcante

126 A ARTE DO GERENCIAMENTO DE PROJETOS

para o projeto do que supomos inicialmente. Foi necessário reunir a equipe e avaliar se nós 1nes1nos podería1nos assumir o design e a construção daquela funcionalidade, ou se sobreviveríainos com as conseqüências de não cê-la, em hipótese alguma.

É importante observar que essa história não representa um fracasso. Sem tomar a decisão de avançar no design B, nunca reríamos eliminado as dependências e as respectivas considerações do design. Realmente acredito que equipes inteligentes se livram dos requisitos e das dependências logo no início, mas se o projeto for co1nplexo, talvez você nunca se livre delas. Não creio que o tempo investido na modelagem de sistemas complexos para captar rodas as dependências de inter-relacionamen tos compense os custos (se o ri tmo for veloz e o projeto for complexo, a manutenção desses modelos será muito dispendiosa), mas pode ser. Depende das necessidades do projeto. Preferimos apostar em um trabalho de equipe do processo de design para expurgá-las para nós, e foi feiro.

Enfim, o processo de idas e vindas e1n que entrei, onde os ca1ninhos se abria1n e se fechava1n, as premissas se provavam incorretas e novas questões erarn levantadas, traduz exatamente o que é o ato da criação. Isso é geralinenre eirado corno iteração, o que significa que os detalhes precisam evoluir corn o passar do tempo (uma vez que o problema é suficienremence complexo, as decisões não serão acercadas sem diversas evoluções).

Especiftca1nente para o design, a iteração i1nplica dar dois passos à frente e un1 passo atrás. Quanto mais difícil e con1plexo for o trabalho, tanto 1nais apertada essa proporção tenderá a ser (por exe1nplo, 1,5 passos à frente para cada passo atrás). Mas até dar esse passo à frente e tomar uma decisão ("Vamos avançar no design B!"), você não vishunbrará rodos os problemas e questões. To1nar decisões durante o design, mesmo que incorretas, é a única maneira de f.1zer os problemas e as questões aílorarem. Se você planejar corretamente, errará várias vezes no decorrer do processo de design, mas ao fazer isso, você au1nentará bastante suas chances de êxito. A maioria dos esforços de engenharia, design e científicos tem padrões semelhantes, como na citação a seguir:

'54inda há rnuita tentativa e erro... Você vai e volta entre a observação e a teoria. ltócê não sabe o que procurar sem uma teoria, e não pode testar a teoria sem examinar os jàtos ... Acho que esse inovirnento de vaivém ocorre inilhares,

até milhões de vezes ao longo de uma única investig;ação''.

- Joshua Lederbcrg, ganhador do Prên1io Nobel de 1958

O trabalho criativo tem uma motivação

O segundo problen1a apresentado na Figura 6-1 é que o únpeto criarivo de um projeto é sempre mais forre do que os líderes e gerentes sem experiência poden1 prever. O esforço necessário para reduzir o pool de idéias a u1n ú1úco design (bom) torna-se muito mais difícil e exige diferentes habilidades, do que o previsto. A Figura 6-1 implica corretamente que o te1npo necessário para encerrar o espaço dos problen1as deve den1orar tanto quanto o que levou para expandi-lo. Mas quanto 111ais inovador ou criativo for o projeto, tanto mais difícil será estimar o tempo necessário ao espaço dos problemas. Isso se deve ao ímpeto do trabalho criativo.

O QUE FAZER coM AS IDÉIAS QuANDO Voct AS T 1vER 127

A causa desse Ílnpe[O é o fa[O de que a [axa de novas ques[Ões e problemas sendo descober[OS é mais veloz do que a raxa de encerra1nen[o dos problemas ancigos. Quem parcicipa do crabalho detecca essa [endência. A[é 1nes1no quando a dara almejada para as especificações estiver se1nanas à frente, 1nuitos acreditarão que o cronograma vai mudar (pior ainda, que não há nada que possam fuzer quanto a isso porque os gerentes não percebem o que esrá acontecendo). Geralmente, esre é o prin1eiro grande ponto de deslize nos projeros. Acontece gradativamence e continua sendo subestimado, acé escar grande de1nais para ser corrigido fucilmence. (Discutirei as ações correrivas gerais dos cronogramas, nos Capírulos 14 e 15.)

Por conseguinte, no diagrama da Figura 6-2 (1nuito pior do que o da Figura 6-1, mas, infelizmente, mais realístico), a equipe está trabalhando arduamente, mas ainda está bem evidente que a dara da redação das especificações não está certa. A taxa de fechamento é boa e tende na direção certa, mas sua t rajetória não coincide com o prazo para as especificações.

Definição dos problemas

Espaço do problema (explorando alternativas)

Dados das especificações concluídas

@~====-1> O tempo segue nesta direção

FIGURA 6-2. O espaço dos problemas aumenta e diminui durante o design, em relação ao ímpeto inesperado do trabalho criativo.

Esta é geralmente a primeira vez em que um gerente de projeto tem a oportunidade de entrar em pânico. Até esse ponto, tudo era abstrato: palavras, rnetas, listas e plataformas deslizantes. Mas quando os designs ainda não estão coesos e a <laca das especificações surge ameaçadoramente, as pessoas se apavoram. Alguns procuram alcernativas para evicar essa situação, culpando os OU[ros, forçando decisões mal-[omadas ou negando vee1nentemente a existência do problema. O Capículo 7 explicará uma cécnica para lidar com o arraso das especificações; o Capículo 11 discucirá o que fazer quando as coisas derem errado. Mas neste capítulo, enfocaremos um método mais eficiente para gerenciar idéias e evitar esses proble1nas antes de tudo.

Pontos de verificação de fases do design

A melhor maneira de gerenciar idéias é começar qualquer atividade irnportante do design com pontos de verificação claros sobre a utilização do tempo. Em vez de ter apenas dois pontos de verificação, os requisitos (ou a definição dos problemas) e a redação das especificações, é necessário definir alguns pontos intermediários antes que o rrabalho criarivo esteja a rodo vapor. O gerenre do projeto é quem deve garanrir a criação desses poncos no cempo (e fazer com que rodos encendan1

128 A ARTE DO G ERENCIAMENTO DE PROJ ETOS

a sua urilidade), embora ralvez fosse 1nelhor que os designers ou engenheiros definisse1n os deralhes específicos de quando esses ponros no re1npo deverão ocorrer e os critérios para atingi-los.2 É possível fazer isso de várias 1naneiras e a melhor escolha varia de um projeto para o outro, e de uma equipe para a outra. Contudo, como regra geral, existem os pontos-chave no ten1po (ilustrados na Figura 6-3).

• • • 1 ([)

Especificações Definição dos Agrupamentos problemas de idéias

©Alternativas Designs

(D Alternativas

FIGURA 6-3. Pontos de verificação do design.

• Visão e comprovação da validade do conceito. Se o documenco de visão for liberado com um protótipo que comprove a validade do conceico, o design e o esforço criativo terão uma vantagem. Já exiscirão as idéias do design e os conceitos da engenharia a sere1n investigados e a parrir dos quais construir (ou recusar, 1nas co1n un1 entendiinento 1nais ainplo do problen1a). Não será u1na boa visão se não existir pelo menos um protóripo inicial do design para viabilizar os conceitos.

• Agrupamentos/listas de idéias. Após a primeira onda de idéias e possíveis abordagens, deve-se organizar e consolidá-las. Isso deve aconrecer em algum

. 1no1nenco, para que a equipe o espere e se prepare.

• Três alternativas. Após rneio caminho andado, a rneca é reduzir as possíveis direções do design de 3 a 5 alternativas. Quanto rnais complexo for o projeto, tanto maior o leque de alternativas. As diferenças cruciais encre as al ternativas dependerão da postura arrojada/conservadora do projeto, da confiança dos designers e dos problemas que o projeto estiver tentando solucionar.

• Duas alternativas. Investigue, pesquise, comprove e quescione até chegar confiantemente a duas alcernativas. Deverão existir duas direções claras que definirão o(s) mais i1nporcante(s) ponco(s) de decisão restante(s).

• Um {uiico design. Investigue, pesquise, comprove e questione até escolher uma direção final.

• Especificação. Documente o único design escolhido. Use o tempo restante para investigar, conhecer e tomar decisões sobre questões do design de nível inferior.

Esses pontos de verificação devem ser definidos pela equipe enquanto o docun1ento de visão é concluído. Se os cronogran1as forem aperrados, reduza o nún1ero e o âmbito dos pontos de verificação ou salte alguns pontos

O QUE FAZER COM AS IDÉIAS QuANDO Voct. AS T1vER 129

inrermediários. E se não houver recursos suficienres para invesrir em pontos de verificação e1n rodo o trabalho, priorize em corno dos mais relevantes desafios do d-esipz .

É imporrante entender que esses ponros de verificação não são usados unicamente para controlar o processo. Eles também servem para orientar a equipe, dividir o trabalho em partes gerenciáveis e oferecer ao gerente do projeto u1na nlaneira de entender o estado do projeto. Quando ocorrerem mudanças, os pontos de verificação funcionarão como um quadro de referência para discurir o que esrá acontecendo e por quê. Por exen1plo, após atingir três alternativas, podem se desenvolver novas informações ou idéias que expandam temporariamente o campo dos designs alternativos para quatro ou cinco. Isso pode indicar que o design ainda está vivo e que está sendo aplicado um novo raciocín io para aprimorá-lo. Mas também pode significar que estão sendo examinados rumos desnecessários. Os pontos de verificação obrigam a equipe a analisar cada um deles e acusar quando o espaço do design estiver crescendo mais do que deve. Os pontos de verificação geram oportunidades naturais para os gerentes de projeto e suas equipes descobrirern quão arrojados ou conservadores deverão ser nas próximas decisões, para 1nanter o projeto nos trilhos.

NOTA Esses pontos de veriflcaç.'ío pocle1n ser usados no nível do projeto ou e1n qualquer problema isolado do design, desde um recurso até um algoritmo. É uma tática para orienrar o rrabalho; é aplicável em qualquer dimensão do projeto.

E1n 1ninha experiência, os primeiros pontos de verificação são os 1nais difíceis de acertar e os mais fáceis de seren1 ignorados pelos engenheiros. Se as etapas iniciais forem ben1-gerenciadas, estará formada a base para o restante do processo criativo. As pessoas darão importância e apoiarão o processo. Sendo assim, tenha o cuidado de gerenciar esses prin1eiros poucos pontos de verificação. Com equipes particulannenre resistentes, a simplificação do processo para apenas crês pontos de verificação - definição dos problemas, as três alternativas e redação das especificações - pode ser u1n compromisso vi1ivel logo na pri1neira vez (consulce o Capítulo 1 O para obter mais informações sobre a criação e adoção do processo em equipe).

Como consolidar as idéias

Ern qualquer processo criativo, assirn que surgirem idéias suficientes, alguém deverá exarninar as possibilidades e dividi-las ern pilhas úteis. Assi1n, é possível entender as diferentes orientações viáveis do design e corneçar a perceber as suas diferenças. (E1n geral, é 1nais fácil trabalhar com 4 ou 5 pilhas do que co1n 30, 50 ou l 50 itens individuais. O rnesmo se aplica às idéias, especificações, crianças hiperativas, pequenos animais, pedaços de doce, escritores enfadonhos que cria1n listas inúteis etc.) Convén1 que algumas idéias sejan1 representadas e1n protótipos e outras en1 rabiscos, notas ou pensamentos inexplorados. O objetivo não é elüninar ou apri1norar as idéias individualmente, mas, sim, modelar e estruturá­las de alguma forma.

130 A.ARTE D O G ERENCIAMENTO DE PROJETOS

Para isso, há várias récnicas3, mas a mais simples que conheço é um diagra1na de afinidades (conhecido cotno diagrama KJ, e1n homenage1n ao anrropólogo Kawkira Jiro). Essa abordagem exige quarro irens: idéias, uma parede, recados Posr-it e a equipe (embora uma boa cerveja e uma con1ida gostosa sen1pre ajudem). E1n um diagrama de afinidades, cada idéia é representada por uma anotação, descrita em poucas palavras e colocada na parede. Essas idéias poden1 ser o resultado de sessões de brainstorrning ou uma lista apurada por um ou mais integrantes da equipe. Pode haver algo em torno de 20 a 100 idéias ou mais. O âmbito do problema que você está tentando solucionar e o nível de criatividade das pessoas pode atribuir enormes oscilações à dimensão das idéias, de um projeto para outro.

Com um diagrama de afinidades, você terá uma visão mais abrangente de todas as idéias. Esse diagrama deve ficar parecido com o da Figura 6-4. Algu1nas idéias sã.o semelhantes e convém posicioná-las em conjunto para facilitar a sua identificação. O trabalho visual pennice focar as relações e não o volume de infonnações memorizáveis. Os diagra1nas de afinidades ta1nbém oferecetn a vantagem de tornar naturais as discussões de idéias com outras pessoas. U1n pequeno grupo de pessoas pode ficar em pé juntas, perco da parede, e fazer comentários sobre as relações por elas percebidas, trocando as posições das anotações em Pose-ir, ao chegarem a novas conclusões. Os diagra1nas de afinidades usa111 anotações e1n Post-it porque esses papéis podem ser 1novimentados e1n uma parede e facilmente organizados em outras disposições.

• ••••••• •••• ••••• ··?· •• . •• _. • .......... •• FIGURA 6·4. Muitas idéias (viva!), mas é difícil gerenciá-las (essa não!).

O objetivo do diagrama de afinidades é alcançar algo parecido com a representação na Figura 6-5. A nlesma lista inicial de idéias é agora agrupada em cinco grupos que representam a maioria das idéias disponíveis. É fácil fazer isso. Alguém vai até a parede e começa a mudar as idéias de lugar. O designer chefe, o gerente do projeto ou uma equipe pequena devem ser os primeiros a dar palpites sobre a organização das idéias. Depois que alguém fizer um primeiro corre, ficará. mais fácil para os outros deslocar as idéias entre os grupos, mudar os nomes dos agrupamentos ou reconhecer que algumas idéias estão duplicadas e podem ser retiradas. A medida que os integrantes da equipe parare1n e fizere1n mudanças, o fonnaco do diagrama rnudará de V<Í rias 1naneiras interessantes. (Dica: experirnence tirar focos digita is periodicamente para preservar os diversos grupos sugeridos.) Em algum momento, o diagrama de afinidades ficará definido e surgirão agrupa1nentos que poderão ser usados nas etapas seguintes.

O QUE FAZER coM AS IDÉIAS QuANDO Voct. AS T 1vER 131

FIGURA 6-5. Agrupar idéias é uma boa idéia.

No caso de eu estar sendo abstraro demais na descrição do funcionamenro dos diagra1nas de afinidades, eis um exe1nplo explicado sob outro pris111a, na Figura 6-5. Vamos supor que u111a das metas do projeto fosse facilitar ainda mais os resultados de pesquisas no site da intraner. Nós nos reuni1nos, fizen1os brainstorming, ro1na1nos algumas cervejas e preparamos uma extensa lista de idéias. Na 1nanhã seguinte, as pessoas tinha1n outras idéias a sere1n adicionadas, que foran1 incluídas. Examinarnos essa lista, eliminarnos as repetições, rirnos muitos ao cruzarmos com idéias que ninguém sabia explicar, e essa lista básica de idéias serviu de apoio para:

• Remover opções avançadas que ningué1n nunca usa.

• Aperfeiçoar o leiaute da página de resulcados de pesquisa.

• Usar o 1necanismo superior de pesquisa HyperX.

• Reduzir o número de resultados apresentados.

• Permiár que os usuários definam preferências relacionadas à aparência da página.

• Abrir os resultados em uma nova janela.

• Corrigir erros de dese1npenho em nosso mecanismo de pesquisa.

• Fazer o mecanismo de consulta funcionar correta1nente (co1n suporte para pesquisas Booleanas).

f\pós examinar a lista e usar as anotações em Post-i t ou algum outro método de agrupar idéias, passamos meia hora organizando-as. Mudamos suas posições, experimentamos outras disposições e finalmente obtivemos uma lista que consideramos a mais útil:

• Simplificar

Remover opções avançadas que ninguém nunca usa Aperfeiçoar o leiaute da página de resulcados de pesquisa Reduzir o número de resultados apresentados

• Personalizar

Permirir que os usuários definam preferências relacionadas à aparência da ' . pagina

Abrir os resultados em u1na nova janela

132 A ARTE DO GERENCl1\MENTO DE PROJETOS

• Re1nodelar a arquicecura

Fazer o mecanismo de consulta funcionar correcainente (com suporte para pesquisas Booleanas)

Corrigir erros de desempenho em nosso mecanis1no de pesquisa

Usar o mecanismo superior de pesquisa HyperX

Neste caso, os agruparnentos são 1nui to simples e como existe apenas um total de oito idéias, funcionam bem. Contudo, se existissem 40 ou 50 idéias, uma lista não funcionaria cão bem. As listas promovem um raciocínio linear e hierárquico e ficam difíceis de gerenciar quando atingem um tamanho maior. Mais adiante, na fase de desenvolvimento, as listas são excelentes para empurrar o projeto para fre nte, mas nos estágios iniciais, os diagrarnas de afinidades são 1nais poderosos, pois ajudam as pessoas a vislu1nbrarem as idéias co1no coisas fluídas e tangíveis que pode1n ser movi1nentadas e reorganizadas facilinente. Essa fluidez cambé1n contribui para se questionar as premissas, ver novas perspeccivas e acompanhar os raciocínios das oucras pessoas. Para as equipes principiantes em raciocínio criativo (principalmente como u1n grupo), u1n diagra1na de afinidades ajuda muico. Use as !iscas para seus próprios objecivos como um gerente de projetos posteriormente, 1nas dê à equipe uma afinidade. Estou convencido de que isso ajuda a despertar outras boas idéias e envolve as pessoas no processo.

Refinar e atribuir prioridades

Não se preocupe em encontrar "o melhor" agrupamento - se for muito bom já será suficientemente bom. Há várias maneiras de agrupar, acé mesmo un1 pequeno número de idéias, e várias delas serão boas. Procure quatro ou cinco grupos que cubram diferentes áreas ou indiquem direções distintas. É possível que algumas idéias não se encaixern e1n grupo algum, mas, seja como for, trabalhe-as o melhor que você puder.

Lembre-se de que você pode retomar as suas idéias e reagrupá-las posceriormence, se necessário. Quando ficar sacisfeico com algo, vá e1n frente. Você não envia diagramas de afinidades ou !iscas de idéias para o cliente, portanto não pense demais nisso.

Um últi1no exercício a ser considerado é a atribuição infonnal de prioridades às idéias (a atribuição forn1al de prioridades será discutida no Capítulo 12). Quais são as idéias mais promissoras? Consulte novan1ente a visão do projeto e os proble1nas a seren1 solucionados, para assegurar que rodos encenda1n os critérios reais, tuna vez que é fácil se apaixonar pelas idéias por motivos que nada cê1n a ver con1 as 1necas do projeco. Algué1n deve orientar esse processo, seja um gerente de projeto ou um designer-chefe. Quanto mais informal for essa discussão, menos tempo consumirá. Não é necessário preparar unia lista completa de critérios e o procedimento de avaliação. Basta uma idéia inicial dos conceitos mais fortes antes de passar para a criação de protótipos. Se o cempo agendado for encurtado, essa orientação inicial facilitará a detenninação de onde usar o ce1npo restante.

O QUE FAZER coM AS IDÉIAS QuANDO Voct AS T 1vER 133

Os protótipos são seus amigos

No Capítulo 5, expliquei por que o design é uma exploração. Você precisa explorar o espaço dos problen1as para conhecer as alcernativas. O bon1 design depende do conhecin1ento das alternativas porque quanto nlais inforn1ações você tiver sobre os problemas e as soluções, tanto mais fácil será a tomada de boas decisões. Os protótipos são a próxima etapa natural no processo de design. Eles utilizan1 tudo o que foi assin1ilado e aplicam ao problema, sem correr os riscos da imple1nentação completa. Os protótipos satisfazem àquela máxima do carpinteiro, "medir duas vezes, mas cortar uma só vez", aprimorando o raciocínio do design para que a equipe se comprometa com um plano. Como explicarei em seguida, os protótipos não precisam ser elaborados ou dispendiosos, nem exigem muito tempo. Se você não acredita na importância dos protótipos, vá para a seção "Os protótipos apóiam os programadores".

Onde os protótipos começam?

Corn quatro ou cinco agrupamentos disponíveis, você terá a base para uma criação de protótipos eficiente. Mesmo que as pessoas com aptidões criativas mais acentuadas já tenham vislu1nbrado os rumos das alternativas com dias de antecedência, os agrupa1nentos de idéias perrnitem que as equipes visualizen1 de rnodo 1nais fácil quantas alternativas existe1n. Co1n 20 ou 30 idéias, há centenas de maneiras diferentes de combiná-las, isso sem considerar a quantidade de 1nérodos diferences de inrerpreraç,'lo de cada idéia.

Um designer experiente saberá quando chegar a hora de começar. Ele saberá classificar as idéias disponíveis e determinará que protótipo deve ser criado em pri1neiro lugar (isso sem m.encionar o que deve ser feito para criá-lo). Mas mesmo que o seu processo de design não tenha un1 designer experiente, há várias maneiras simples de escolher o protótipo a ser desenvolvido:

• Selecione a idéia 1nais promissora de cada grupo e tente combiná-la a um design.

• Crie pequenos protótipos para cada grupo para saber até onde vão. Foi possível solucionar t:odos os impasses tão-somente remodelando a arquitetura ou adicionando urna cusromização? Observe aré que ponto cada rurno conduz o design.

• Avaliação do designe1~ deixe o designer aplicar sua experiência e intuição para decidir o que usar, em u1n palpice inicial.

• Prepare uma !isca das questões do design rnais difíceis e irnporranres, e faça u1n proróripo (ou proróripos) para ajudar a respondê-las.

Como regra geral, quanto 1nais sofisticado for o protótipo, canto mais sofisticadas serão as perguntas que ele poderá responder. Um rascunho no verso de um guardanapo funciona bem para os primeiros tipos de quesrionan1entos, 1nas se você quiser saber algo específico e rer confiança na resposta, precisará de algo rnuito mais abrangente.

134 A.ARTE DO G ERENC[AMENTO DE PROJETOS

Corn os primeiros protótipos ern construção, deve ser óbvio quais idéias adicionais devern ser incluídas, sem gerar confliros ou problernas, e quais não se encaixam mais. Assim corno em um quebra-cabeças, algumas coisas se encaixarão e farão 1nais sentido do que outras, 1nas é necessário aplicar o método da tentativa e erro para descobrir. Como há tantos detalhes e perspectivas {cliente, empresa, tecnologia), é impossível prever quais caminhos funcionarão ou não. E é

• .f • • - · exatan1ente para isso que servem os protoupos e a Heraçao: cometer erros, aprender, revisar e seguir em frenre.

Criação de protótipos para projetos com interfaces do usuário

Os protótipos devem ser criados de cima para baixo. Comece com o que os usuários verá.o e a seqüência em que isso ocorrerá. Envolva seus especialistas em usabilidade e design o rnais cedo possível, para. obter alguns designs e premissas razoáveis. Não há muiro senrido em gasear dias planejando bancos de dados e esquemas XML para terminar criando algurnas poucas celas: é corno construir a esrrurura de uma casa só para rer uma noção da planta baixa. Se você fizer isso, cerrarnenre esrará desperdiçando um trabalho de qualidade da produção, algo que o esforço da criação de protócipos deve evicar. {Para obter argumencos sobre questões de programação antes de criar, consulte a publicação The lnmates Ate Running the Asylurn, de Alan Cooper, da San1s, 2004.)

Em vez disso, aguarde até surgire1n esboços ou n1aquetes prornissores da interface do usuário {que são determinadas com maior eficiência através de estudos da usabilidade ou exarninando as decisões que os usuários deverão rornar ern cada rela para fazer seus trabalhos). Os engenheiros deverão, enrão, explorar como seria exatamente essa construção. Se j<í ocorrerarn debates parecidos no início do projeto, esta deve ser uma continuação natural e fácil dessas discussões.

No tocante à construção dos protótipos, não há um segredo n1ágico. Exige experiência para saber o que simular ou encobrir, e o que requer mais raciocínio e investimento.4 A regra geral é fazer o mínin10 trabalho necessário para obc.er as informações necessárias. Qualquer ferramenta - Flash, HTML, VB ou até o papel - pode ser usada em designs de protótipos. Tem mais a ver com o talento do designer e/ou profissional de protótipos do que com a técnica ou ferramenra.

Criação de protótipos para projetos sem interfaces do usuário

Até rnesn10 nos projetos sem interfàces do usuário ou front-ends da Web, ainda é sensato criar urn prorócipo.5 No lugar das questões do design relacionadas à inrerfàce do usuário, escolha os desafios técnicos ruais cornplexos e difíceis e crie urn protótipo para eles. Confirme se os principais algoritmos estão adequados, preenche1n os casos de restes básicos ou acendem a um subconjunto de crirérios de desempenho. O objetivo da criação de protótipos é o mesmo e independe do ripo de projeto: esforce-se para entender se a(s) abordagern(ns) inicial(is) que estão sendo analisadas poden1 ser construídas no tempo alocado e se realn1ente soluciona(n1) os problemas suscitados. É uma oportunidade de lidar com o risco ances de iniciar a implen1entação, e para saber o que precisa ser feito ances de se compron1eter.

O QUE FAZER COM AS IDÉIAS QuANDO Voct. AS 1-1vER 135

Os protótipos apóiam os programadores

Quando h;í u1n designer ou u1n gerente de projetos para comandar o esforço da criação de protótipos, os progran1adores e engenheiros freqüentemente reclan1an1 que não tê1n nada para fazer.6 Também pode1n dizer que o processo é uma perda de tempo (uma reclamação geralmente feita devido a algo que não exige a criação de um código). Muito pelo contrário, acho que os programadores se beneficiam con1 a criação de proróripos 1nuito n1ais do que qualquer outro integrante da equipe. Quando desenvolvida corretamenc.e, a criação de protótipos aumenta muito a probabilidade de que os designs, cuja construçã.o coube a eles, tenham sido bem considerados e sejam de alta qualidade. Evidentemente, não é uma certeza absoluta, mas as probabilidades aumentam. Durante a criação de um protótipo, provavelmente o mais importante para o gerente de projetos é que os programadores tenhan1 um prazo para investigar as abordagens do desenvolvimento e da engenharia que precisarão usar. A qualidade do seu código de produção deve 1nelhorar se eles investirem o tempo do design de modo inteligente.

Eis u1na lista resumida das perguncas que os progra1nadores devem responder nesse estágio:

• Em um alto nível, como construire1nos o que o(s) protótipo(s) do design n1ostra(n1) ? Há un1 código ou u1na tecnologia já existente que possa/deva ser usado(a)?

• Existen1 alterações razoáveis do design que o designer deva conhecer, que reduzirão os custos da engenharia?

• Quais são os cinco ou seis componentes principais necessários, e que ripo de inter-relacionamento existe entre eles? No nível mais alto, quanto custará a construção desses con1ponentes? (Alto/médio/baixo/desconhecido é suficiente. Se a resposta for desconhecido, o prograrnador deve começar a investigar.)

• Onde se encontram os maiores riscos técnicos? Quais são os cornponentes cuja construção é mais difícil ou 1nais complexa?

• Que interfaces, entre que componentes, são as mais con1plexas ou que apresentam a mais alta probabilidade de falha? (Um testador dedicado ou um profissional de QA', se disponíveis, podem responder a essa pergunta de 1nodo mais confiável.)

Da mesma forma como não é possível para um designer responder con1 certeza absoluta às perguntas complexas do design sem um protótipo pertinente, u1n engenheiro também não pode responder com certeza às perguntas con1plexas de engenharia, sem um protótipo da engenharia (a despeito do que ele possa afinnar). Se fore1n necessários vários esforços de protótipos, eles deve1n ser desenvolvidos co1n un1a sincronização entre si. É melhor que o designer-chefe e o engenheiro-chefe passem algum tempo conversando, fuzendo perguntas e colaborando um com o outro para tomar decisões acertadas. Os dois esforços de protótipo devem percorrer um caminho que, em algun1 momento, suas concepções devan1 convergir: as idéias da engenharia e do design devem combinar.

• N. de T: Qunlity Assurnnce - Garancia de Qualidade.

136 A.ARTE DO G ERENCIAMENTO DE PROJETOS

Alternativas aumentam a probabilidade de êxito

Especificamenre para interfaces do usuário e designs para a Web, a 1naioria dos protótipos con1 os quais colaborei, ou que eu mesn10 desenvolvi, tinha muitos irn1ãos e irinãs. Com o grande pool de idéias afloradas no início do processo criativo, havia diversas alternativas que pareciam tão razoáveis quanto as demais. Para discernir quais eran1 as melhores, a única maneira era experimentar algumas delas. Os designers ou engenheiros experientes na criação de protótipos podem alrerar a interface do usuário, o leiaute ou outros detalhes para algu1na das diversas configurações (CSS e HTML são exen1plos excelentes disso, onde há camadas que podem ser modificadas isoladamente umas das outras). Um protótipo flexível pode agilizar as discussões e decisões porque as pessoas nã.o precisam imaginar e visualizar muito em suas mentes.

Aprendi com a própria experiência que, a despeito do quanto as pessoas possam estar de acordo, se todas elas não estiverem vendo a 1nesma imagem, não estarão concordando e1n hipótese alguma. Cada pessoa pode ver algo diferente através dos olhos de sua mente, e ao dizer si1n para as outras pessoas, na realidade estará concordando co1n coisas 1nuiro diferenres. Mais rarde, muito provavelmente o designer ou o gerente do projeto serão responsabilizados por esse tipo de confusão. Os protótipos são um modo confiável de evitar que isso aconteça, porque representam coisas reais que podem ser apresentadas e consultadas posteriorinente. "Entendeu até aqui? Você concordou com isso e todos na sala testemunharam que aceitou esse exaro design". Você deve destacar especifica1nente dessa fonna os aspectos dos protótipos ou das capruras de cela do design que está usando.

Questões para iteração

Con1 o pri1neiro corre em um protótipo, surgirão toneladas de idéias e perguntas novas. Isso incluirá sugestões de mudanças, melhorias e novas idéias a serem testadas. Se isso ocorrer no início de u1n protótipo, sua próxima iteração deverá focar a exploração das grandes idéias ou mudanças abrangentes. Se estiver no final do protótipo, as iterações devem ser usadas para reduzir o espaço do design e ajudar a tomar decisões. Cada iteração traz uma oportunidade para uma nova discussão sobre o andamento do design. A melhor modelagem para essas discussões é apresentar um conjunto de perguntas que ajudem a avaliar o design e que amarrem a discussão de uma forma produtiva.

Eis algu1nas perguntas para as pri1neiras iterações do protótipo:

• Que requisitos foran1 atendidos por este protótipo? É possível verificar isso? (Usabilidade, casos de uso erc.)

• O que funciona e não funciona neste design em relação ao problema que supostamenre ele soluciona? (Prós e conrras para cada usabilidade, negócio, tecnologia, considerações.)

• Quais são os dados necessários para avaliar este protótipo? (Talvez un1 esr.udo da usabilidade, um exame informal feito por u1n programador quanro à sanidade da engenharia, markering, a opinião de um especialista etc.)

O QUE FAZER coM AS IDÉIAS QuANDO Voct AS T 1vER 137

• O que aprendernos com esce design que devemos rnancer na próxima tencaciva? Eli1ninar?

• O que poden1os fazer na próxiina iceração para torná-lo 1nelhor?

• 1-lá outras idéias do agrupamento de idéias ou de outros protótipos que devemos incluir?

Eis algumas perguntas para as últimas iterações do protótipo:

• Que decisões esse protótipo nos ajuda a tomar?

• Que questões ern aberto esse protótipo nos ajudan\ a fechar?

• Este design confirrnou a existência de urn problerna que precisarnos investigar? Ele solucionou urn problema que precisávarnos resolver?

• O que podemos experirnentar na próxima iteração que permita nos aproxirnar da redação das especificações?

E co111 isso, o designer ce1n informações suficiences para criar outra versão do protótipo, possivelrnence integrando duas alcernarivas distintas ou bifurcando o design em duas novas alternativas. Não deven1 existir restrições quanto ao que é perrnitido ou não, desde que o que for feito, em algun1 momento, agilize a conclusão do trabalho do design.

A lista de pendências

Com a redução das alternativas, há un1a nova responsabilidade para o gerente de projetos: a lista de pendências. Uma pendência é algo que precisa ser decidido ou discutido mas não aconteceu ainda. É basicamente uma lista de perguntas e deve englobar tudo o que precisa ser feito, classificado pelo possível impacto sobre a engenharia. O formato dessa lista não é cão importante quanto a qualidade das questões listadas e a diligência da pessoa orientando a sua solução. Usei para isso um ponto designado em um quadro branco ou ern urna planilha eletrônica do Excel, e não posso afirrnar que a ferramenta que escolhi fez diferença, seja como for. Não acho que essas !iscas devam ser controladas ou gerenciadas como o código-fonte (ou seja, a menos que a política ou a culrura da sua organização considere irnporranre); quanto n1ais simples for a ferran1enta, tanto n1ais eficiente ela será.

Essa lista pode co1neçar com as perguntas não-respondidas ("Usare1nos o esquerna de dados A ou B?" ou "Precisamos do úlcimo design da UI feiro pela Sandra"), mas o deralhamento desse design deve ser expandido e aperfeiçoado, porque há poucos dias para começannos a redigir as especificações. Cada irem deve ter a seu lado o nome da pessoa que está orientando a solução da questão. O GP deve garantir que alguém conheça as questões atribuídas, importune-as adequadamente e supervisione-as até serem solucionadas.

Os programadores deven1 ter a carga rotai das perguntas e pesquisas de engenharia, mas se houver alguma questão que o GP possa assu mir, ele deverá fazê-lo. Geralmente, os itens que podem bloquear a engenharia, mas não são específicos de engenharia - como aprovação do marketing, considerações sobre a usabilidade, promoção da marca e design visual - devem ser rastreados

138 A.ARTE DO GERENCIAMENTO DE PROJETOS

pelo gerenre de projero, porque aferarão a especificação mais do que a i1nplemenração (discucire1nos a diferença enrre as duas no Capírulo?) .

O gerence de projecos inreligence divide a !isca de pendências em duas prioridades: icens que precisan1 ser resolvidos ances da especificação e icens que podem esperar para depois. O método mais natural é atribuir prioridades e focar as questões que podem bloquear a engenharia - e possivelmente o projeco inteiro. Tudo o que estiver na lista de pós-especificações deve ser esclarecido junco aos engenheiros porque são os únicos que podem confirmar se a decisão ou as informações podem esperar. (Co1no e por que as coisas deve1n ficar para depois das especificações será discucido no próximo capítulo.)

Portanto, é necessário incluir na lista todas as incertezas que devem ser resolvidas. Ninguém, exceto o gerente de projetos, deve ter acesso a essa lista, certamente não no início. Mas corn o passar dos dias, essa lista pode funcionar como uma ferramenta para unificar a equipe em reuniões ou nas discussões pelos corredores. O objetivo não é fazer com que as pessoas se sincarn rnal; é lembrá-las do que ainda est<Í. pendenre e ajudá-las a enxergar os problemas que os oucros mernbros da equipe precisarn resolver. Como o trabalho do gerenre de projecos afera a rodos, tornar a !isca visível permire que as pessoas colaborem na solução das questões. "Ei, isso consra na minha !isca cambém. Você deve tratar disso ou eu?" Esse é um dos mocivos pelos quais n1antinha minha lisca de pendências no quadro branco da rninha sala ou no corredor. (Urn site deve funcionar muito ben1, 1nas, pela 1ninha experiência, ningué1n examina essa lista exceto que1n a criou. Os locais não-virtuais e inforn1ais funcionam nluico nlelhor.)

Descobri que se1npre que as pessoas visitavam minha sala e me perguntava1n como as coisas escavam indo, eu deveria apontar para essa lista e dizer "É exatamente assim que as coisas escão transcorrendo. Quando essa lista estiver vazia, poderei concluir essas especificações" . En1bora isso não seja exacan1ence uma métrica de desempenho ou algo rigorosamente avaliável com o passar do tempo, o estado da lista de pendências de um gerente de projeto e o ân1bico das perguntas nela incluídas, revelarn muito sobre como as coisas estão carninhando. Se a lista for extensa, mas contiver questões rnuito específicas e reduzidas, as coisas estarão bem. Se a lista for curta, mas quesrionar coisas assuscadorarnente básicas, como "Que problema escarnos tentando solucionar?" ou "Que linguagem de programação esramos usando?", você saberá que o projeto cem um longo caminho pela frente.

Resumo

• As idéias cêm um ímpeco próprio. Levará 1nais ce1npo do que você espera para do1ninar o crabalho criarivo. As mudanças pennearão um projero . . 1nce1ro.

• Crie ponros de verificação do crabalho criacivo, para acompanhar e gerenciá-lo. Pontos de verificação comuns abrangem comprovação da validade do conceito, agrupamentos de idéias, três alternativas, duas alternativas, um único design.

O QUE FAZER COM AS IDÉIAS QuANDO Voct. AS T 1vER 139

• Use diagra1nas de afinidade para consolidar idéias.

• Os procótipos permicem confroncar quescões logo no início e aprender co1n os erros, sen1 correr grandes riscos.

• Use icerações ou o aprimoran1ento periódico de um procócipo para fazer perguntas, avaliar o anda1nenro e decidir nas erapas seguinres.

• Crie uma lisca de pendências para rastrear as quesrões que precisam ser solucionadas antes da conclusão das especificações.

·-·-.e ca J: •

C\J w l­a: <(

a...

Capítulo 7

Escrevendo boas especificações

144 A ARTE DO G ERENC[AMENTO DE PROJETOS

C erta vez, argumentei com um programador que credicava não ser necessário escrever especificações. Encrei no escricório dele com o grande modelo que 1neu chefe me pediu para usar e ele si1nplesn1ence riu do modelo (e infelizmente, de n1im tan1bé1n). Na opinião dele, se o que eu queria fazer era tão con1plicado, a ponto de exigir uma explicação de 50 páginas para os programadores, então não valeria a pena construir de jeito nenhum. Ele interpretou a necessidade de codo esse processo e papelada como uma indicação de que a comunicação e coordenação na equipe escavam em baixa, e que não confiávamos em decidir coisas por conta própria. Não deveríamos precisar canto de trabalho extra e burocracia - dizia ele - o que levava a crer que nunca se tinha dado a devida imporc~ncia ao planejamento elaborado.

Como eu já tinha ouvido esse argumento anteriormente, sorri. Perguntei se ele faria a mesma reclamação sobre os planos de engenharia para a construção do aparta1nento do espigão e1n que ele morava ou para o viaduto de crês níveis que ele atravessava com o carro para chegar ao trabalho. Mas acho que ele j<i tinha ouvido essa pergunca e riu logo depois. Disse que, e1nbora estivesse contente com o faro de que aquelas coisas tivessem sido planejadas detalhadamente, ele não achava que trabalhar com software era o mes1no que trabalhar corn as leis da física e com materiais de construção. Concordamos em dois aspectos. Primeiro que, em relação à engenharia tradicional, o sof'tWare é n1ais flexível, n1ais fácil de alterar e dificiln1ente arrisca as vidas das pessoas. Contudo, reconhecemos que, pelo faro de enfrentarmos desafios estruturais complexos, de termos urna equipe de pessoas que depende1n de nossas decisões e cennos orçamentos e prazos a cumprir, precisávamos muito mais do que nossas lembranças de bace-papo de corredor para . assegurar que as coisas cercas acontecessem.

Também chegamos à conclusão de que o que precisávamos em nosso projeto era algo adequado para o ripo de atividade que realizamos e para as pessoas que somos. Um tipo de documentação escrita seria útil se solucionasse problemas efetivos para nossa equipe, se agilizasse o processo de finalização e aumentasse a probabilidade de um resultado de qualidade (e precisava ser atualizável com o passar do tempo, mas sem perturbar ninguén1). Se pudéssemos fazer algo para alcançar essas coisas, ele ficaria feliz em utilizar essa alternativa, independentemente do nome que atribuíssemos ou da forma assumida. E com isso, ele decornpôs o processo de especificações e1n algo que, na nossa opinião, funcionaria para nossa pequena equipe. Procurei novamente meu chefe, recomei nossa conversa e alinhavei um compromisso. Aquele grande modelo de especificações ao estilo direito fiscal desapareceu.

A rnoral dessa história é que, como tudo o que as pessoas fazern, não existe algué1n destinado a escrever especificações ou documentar o trabalho. As especificações, como a maioria das coisas que as equipes são solicitadas a fazer, devem corresponder às necessidades do projeto atual e às pessoas que deverão criar e lê-las. E da 1nesrna rnaneira como os sites ou producos de sofavare precisam passar por um processo de elaboração (d.esign) para que sejam derecradas as melhores abordagens, as especificações necessitam de certa análise e iteração para serem corretamente concluídas.

Porém, várias pessoas experientes que conheço caíran1 na armadilha de acreditar que só existe um jeito de fazer especificações (ou seja qual for o nome a elas acribuído), o que tende a repetir o método aplicado na úlcin1a vez. Às vezes,

ESCREVENDO BOAS ESPECIFICAÇÓES 145

esse ciclo de repecição conduz novarnence aos primeiros projecos nos quais rrabalhara1n. Presu1ne-se que, como os projeros não foram um desasrre cocal, o modo con10 as especificações fora1n escritas conrribuiu posirivamente para esse resultado: uma argun1entação que, se1n u1na investigação, pode ou não proceder (ou seja, o projeto pode ter sido bem-sucedido, apesar de um processo de especificações desajustado). Pior ainda, se não foram feitas boas perguntas sobre como e por que as especificações são escritas, ninguém na equipe realmente conhecerá a eficiência ou ineficiência do processo de criação de especificações, ou aré que ponro esse processo conrribui ou não para o dese1npenho da equipe. (Isso nos faz lembrar que a ausência de boas perguntas sobre como escrever um código de qualidade nos impede de saber se o código é realmente bom ou ruim.)

Neste capítulo, meu objetivo é explicar o grupo de idéias apresentadas a seguir. Primeiro, as três funções das especificações em um projeto: garantir que seja feita a coisa certa, oferecer um marco de cronogra1na que conclui a fase de planejamento de u1n projeto e permitir o exame e feedback abrangentes por diversas pessoas, no decorrer do projeto. Essas três funções são 1nuito importantes e é improv;ível que um processo diferente das especificações escritas lhes forneça tudo ao mesmo tempo. Só por esse rnotivo, sou fã das especificações. Ern segundo lugar, a maioria das reclarnações das pessoas sobre as especificações é facilmente solucionada, desde que seus aurores conheçam as armadilhas comuns da escrita de especificações e reconheça1n os benefícios específicos propiciados pelo uso dessas especificações.

O que as especificações podem e não podem fazer

Assim co1no os documentos de visão, as especificações são uma forma de comunicação. Quando usadas de n1odo eficiente, elas transmitem informações importantes de maneira simples e fácil de entender. Quando utilizadas de 1nodo ineficiente, fica difícil entendê-las, sua criação é enfadonha e tornam-se frustrantes para todas as pessoas que lidan1 com elas. En1 geral, parece que as equipes que escrevem especificações ruins precisam de 1nais delas (co1no em "Se os lobos vêm em bandos, as especificações vêm em pragas"). Na maior parte do tempo, as especificações fracas ou com fàlhas nascem de um engano em relação ao que elas podem ou não podem alcançar.

Examine a seguir urna lista do que as especificações podem fàzer .

por u1n projeto:

• Descrever de modo eficiente a funcionalidade do que será construído.

• Ajudar os designers a esclarecer as decisões co1nadas, forçando-os a seren1 específicos.

• Permitir a análise, o questionamento e a discussão de planos detalhados antes de iniciar a in1plementação co1npleta.

• Transmitir informações de um para muitos.

• Criar um ponto de referência no nfvel de equipe para os planos específicos (e se delineado na fase do design, use-o como uma documentação viva do que está acontecendo 1).

• Fornecer um marco de cronograma natural para focar a equipe.

146 A ARTE DO GERENCIAMENTO DE PROJETOS

• Garancir que o(s) aucor(es) não seja(rn) acropelado(s)2 .

• Agilizar, aprirnorar e aumencar a freqüência das discussões salucares.

• Dar aos líderes urna oporcunidade de apresencar urn feedback e definir o padrão de qualidade.

• Conceder discernimento e segurança à equipe (e ao autor).

Lista do que as especificações não podem ou não devem làzer:

• Elim inar todas as discussões entre os membros da equipe.

• Provar para a equipe quão inteligente é o autor.

• Provar a irnportância de un1 recurso (ou por que ele não deve ser cortado).

• Converter pessoas e1n um ponto de vista filosófico.

• Ser un1 playground para as habilidades do autor no M icrosoft Visio ou e1n UML (Unífied Modeling Language - Linguagetn de Modelage1n Unificada).

Os líderes de equipe deve1n preparar uma !isca co1n esse nível de decalhamento para a equipe usar. Todos aqueles encarregados de ler e escrever especificações devem ser orientados a revisar a lista e dar um feedback sobre os tópicos, antes que as especificações sejam efetivamente escritas. É possível que algum dos aspectos listados não precise de uma especificação ou que exista algo ainda não listado que deva ser incluído. Isso pode ser feito em un1a discussão rápida, de meia hora no máximo. Até mesmo um rápido bate-papo pode defin ir expectativas para o ilmbito da contribuição das especificações, e propiciar à equipe uma oportunidade de dar sugestões para 1nelhorias. Se existir um modelo para as especificações definido pela equipe, ele deve ser escrito com base nesses critérios.

Decisão sobre o que especificar

Cada metodologia que conheço para o desenvolvi1nento de software ou gerenciarnenco de projetos define especificações de modo diferente. Nunca me importei 1nuito com isso. Há quatro tipos básicos de infonnações que resultam em especificações, e a maneira 1nais f-ícil de discutir sobre elas é supondo que elas hão de gerar quatro docu1nentos discíntos. Mas o 1nodo como tudo isso é dividido não é 1nuiro i1nporranre (mes1no que algumas pessoas sejam metódicas). O que realn1ente importa é que a informação cerra seja especificada pelas pessoas certas, e que essa infonnação seja produzida de 1nodo útil para as pessoas que precisare1n utilizá-la. Sendo assín1, en1 equipes menores, esses diferentes tipos de especificações são geralmente combinados. Nas equipes maiores, calvez seja necessário separá-los (mas 1nanrendo um vínculo) e até mesn10 serem criados por pessoas diferences.

• Requisitos. Para documentar os diversos aspectos previstos de um projeto, uma especificação com os requisitos delineia todas as requisições e obrigações que o trabalho deverá satisfàzer. Essa especificação consolida todo o trabalho dos outros requisitos e funciona como um ponto de referência para o projeto. N a melhor das hipóteses, trata-se de uma lista de condições para a vi tória,

ESCREVENDO BOAS ESPECIFICAÇÕES 147

descrevendo o resultado final, mas sem dar muitas explicações sobre como esse resultado será alcançado. Em rodos os casos, os requisitos deve1n ser definidos antes do início do processo de design (e1nbora seja possível aprimorar e atualizá­los posteriormente) e devem se originar no documento de visão. Eles devem ser incluídos com as especificações dos recursos para fins de esclarecimento e para ajudar na revisão (esse plano acenderá aos requisitos?).

• Recurso. Uma especificação de recursos delineia o con1portan1ento e a funcionalidade de determinado cenário ou conjunto de cenários sob a perspectiva do cliente. Un1a especificação de recursos é o resulcado principal do processo de design, que descreve a funcionalidade do sofavare através da interface do usu;)rio (se exis tir) e explica em detalhes como as coisas devem h1ncionar sob um prisma não-técnico. Essa especificação deve relatar acé onde a experiência do cliente mudará quando o trabalho estiver concluído, e deve conter uma lista si1nples dos irens de trabalho definidos pela engenharia, necessários para cumpri-lo. A diferença encre essa !isca e a !isca de requisitos é o faro de que ela define un1 design específico que acende aos requisitos, inclusive a inrerfàce do usuário ou outros elementos inco1nuns do design.

• Especificações técnicas. Uma especificação técnica apresenta un1 detaJha1nenco da abordagen1 de engenharia necessário para cun1prir a especificação dos recltrsos. Essa especificação deve fornecer pormenores suficientes para descrever os componentes 1nais co1nplexos ou reurilízados que os outros programadores poderia1n usar nova1nence, e para oferecer evidência de apoio para os irens de rrabaJho necessários a un1a especificação de recursos. Ocasionalmente, o ihnbiro ou a natureza técnica de uma especificação de recursos evita a necessidade de uma especificação técnica separada.

• Listas de itens de trabalho. Quase equivalem à estrutura analírica de projeto (WBS - Work Breakdown Structure) . Uma lista de itens de trabalho é a descrição de cada atribuição de programação necessária para atender à especificação de recursos. Essa lista deve ser decomposta a um nível de detalhamento que discrimine os itens de diferences graus de irnportância, corn estirnativas expressas em dias (deve ser definido urn limiar para o escopo dos itens de crabaJho, talvez um dia ou meio dia, mas essa tarefà fica a critério dos prograrnadores). A criação da lista de itens de trabalho fica cocalrnente por conca do programador, mas o programador-chefe e possivelinence o gerente de projetos deverão revisar e resumir essas listas. (Em termos técnicos, as !iscas de irens de trabalho não são especificações em si n1es1nas: são o plano de como a engenharia atenderá às especificações. Contudo, elas são tão in1porrantes e relacionadas co1n as especificações, que não consegui vislumbrar un1 lugar mais adequado para inseri-las.)

• Critérios de teste e critérios de saída de marco. Quando a especificação de recursos estiver preparada, os critérios de reste devem ser criados. Isso deve incluir casos de reste priorizados para a nova funcionalidade, juntamente com as 1neras para o desempenho do código nesses casos, para atender aos objetivos da qualidade para atingir o marco (urna espécie de critérios de saída; consulte o Capítulo 15).

Darei um exemplo de como esses diversos tipos de informação de especificação podem ser con1binados. Sempre que eu crabaJhava em uma equipe grande, com várias

148 A.ARTE DO GERENC[AMENTO DE PROJETOS

funções especializadas, geralrnence erarn escricas especificações de recursos e técnicas. As listas de requisitos eram extraídas da vi&'io, a equipe e o cliente exaininavam as listas de requisitos e, depois, essas )iscas eram inseridas no início da especificação dos recursos. As listas de icens de trabalho erain geradas pelo programador (geralinence em uma planilha sirnples, acessada pela equipe inteira) e copiadas ou vinculadas à especificação de recursos. No final, surgia uma especificação principal, que continha alguns tipos de informação de especificação recén1-descritos.

O modo mais fácil de analisar esses quatro tipos de especificações é na orde111 cronológica aproximada: requisitos, recursos, cécnicas e itens de crabalho. Assirn como várias outras tarefas do projeto, cada um desses quatro tipos de informação é a base para o seguinte. Quanto maior for a equipe e quanto mais complexo for o projeto, tanto mais formalizada deverá ser a divisão entre esses tipos de especificações.

Quem é responsável pelas especificações?

Em urna equipe grande, os GPs ou os designers devern ficar responsáveis pela especificação dos recursos; os prograrnadores seriam responsáveis pela especificação cécnica. É necessário redigir essas especificações de modo que quem estiver lendo os dois documentos acredite que os respectivos aurores realrnente se conhecem e trocam idéias corn freqüência. Geraln1ente, as especificações técnicas são n1ais curtas (e n1enos generosas para o leitor) porque seu público é reduzido e os progra1nadores têrn uma tendência a não se interessare1n em escrever linhas que não serão compiladas. Mesmo assirn, a especificação técnica de apoio aos designs contidos na especificação de recursos deve ser condizente.

Os analistas de empresa, clientes ou gerentes de projeto escrevem documentos de requisitos com freqüência. Isso depende de quem tem autoridade para requisitos e da natureza da equipe do projeto (pequena equipe contratada temporariamente, equipe grande efetiva). Quem estiver gerenciando a equipe de programação ficará responsável pelas listaS de itens de trabalho. Em organizações grandes, geralmente é o chefe dos programadores.

Como sernpre, em equipes pequenas, é um assunto menos esquemat:izado. Pode ser que não existam políticas rigorosas para quem fàz o quê, ou inclusive, que documentos precisam ser redigidos. O gerente do projeto ou o programador­chefe pode terminar escrevendo um iínico documento que será um emaranhado desses quatro cipos de informação, saltando encre eles para acomodar as necessidades irnediatas da equipe. Isso pode ser bom, desde que as pessoas consigarn o que necessitarn e quando necessicarn.

Especificar não é criar

Os dois capículos anceriores definirarn urn processo de design para trabalhar com idéias e desenvolvê-las em planos. A definição de um processo de design é in1portante para separar o design e o planejamento do ato de escrever uma especificação. A criação de unia especificação deve se concentrar o máximo possível em transn1itir um plano ou conjunto de decisões existentes da melhor nlaneira possível, em vez de elaborar esse plano sin1ulraneamente. Quanco menos

ESCREVENDO BOAS ESPECIFICAÇÕES 149

separação houver encre esses dois aspeccos, canco mais difícil será alcançá-los. Já é suficience1nence árduo execucar u1n desses processos isoladamence, e quanco 1nais rencannos fazer as duas coisas ao mesmo cempo, menores serão as probabilidades de reaJizar an1bas as tarefas corretamente.

Os autores de especificações devem estar atentos às estruturas mentais de elaborar e especificar. Ao escreverem a especificação, deverão, durante alguns instantes, parar de explorar e criar, e se concentrar em se expressar e explicar. Ou devem, pelo menos, pensar en1 voltar e revisar profundamente o docun1ento, de modo a refletir o discurso de u1n explicador e não de um criador. Sempre que estiver escrevendo especificações (ou qualquer outra coisa), é importante lembrar que nem sempre o modo como imaginamos ;1lgo é a melhor maneira de explicá-lo a alguém.

Descrevendo o design final em relação à sua construção

Embora seja possível combinar as especificações de recursos e técnicas em um único documento, na maioria das vezes, elas devem ser seções clara1nence separadas. Uma das piores especificações que j<í li caiu na armadilha de fazer essas duas coisas ao mesmo tempo. Com roda a sua inteligência e capacidade, o aucor renrou descrever o design e explicar simulcaneamente como ele seria construído. Assi1n que abri o docu1nento, ficou evidence quanco te1npo ele deve cer gasco para prepará-lo.3 Ele rascunhara grandes e 1neticulosos diagramas 1nostrando as relações entre os objetos e con1ponentes, e ao n1es1no tempo diagramando-os sob o prisma da ucilização por parte dos cliences. O resultado foi um belo desastre, alcamente aprimorado. A aparência da especificação era impressionance, 1nas após cinco 1ninucos de leicura e da cencaciva fruscrada de entendê-la, minha voncade era estranguJá-lo imediatamente (e acho que sua equipe teve uma reação parecida). Ele tentou várias vezes convencer as pessoas, o que, infelizmente, s6 serviu para au1nentar as reações negativas (e potencialn1ente violentas).

Pensando em ajudar, falei como redator de especificaçáo e cencei oferecer algumas sugestões . . Ele admitiu que tinha perdido o enfoque e que a especificação em si não era assim tão importante, a despeito de que acreditasse ainda que sua abordage1n era boa. Ele argumentou que, corno sabia que os prognimadores precisariam de uma referência para o comportamento esperado e os detalhes de nível superior das relações entre os objetos, compensaria combinar todos esses aspectos. Em minha opinião, mesmo que u.ma pessoa necessite de ambos os tipos de informação, não há por que pressupor que alguém precisará de tudo ao mesmo tempo ou na mesma página. Geralmente, é mais fácil escrever e ler ern um único nível de raciocínio e lidar co1n um nível da história de cada vez, do que con1binar cudo. As boas especificações, em geral, descreve1n o design em camadas: primeiro, a experiência do clience, descrica na linguagem do cliente; segundo, tuna visão geral de alco nível dos objecos básicos e da arquiterura; e rerceiro, a coberrura das quesrões co1nplexas e detalhadas do design da engenharia.

Boas especificações simplificam tudo

A coisa mais complicada para as pessoas de raciocínio técnico é realmente escolher os detalhes que deven1 ficar de fora e quando fazer isso. Após sobreviver a 1nuiras

150 A.ARTE DO G ERENC[AMENTO DE PROJETOS

aulas de lógica e macemácica rerrivelmence complexas, descobri que os rnelhores professores sabe1n quando deven1 salcar coisas não-essenciais, embora imporranres, e como volrar a elas quando o aluno {ou leicor) esriver preparado. Quando be1n-escricas, as especificações usam o mesmo ripo de habilidade. O essencial transparece. As pessoas ganham discernin1ento sobre o trabalho e podem prosseguir de modo abalizado. Os modelos mentais disponíveis para o modo como as coisas serão construídas são mais aprimorados após a leitura da especificação, e nlelhora a qualidade das pergunras feiras ao GP ou aos oucros incegranres da equipe. Busque esse efeito. Ne1n se1npre rodos estarão dispostos a participar de modo positivo, mas esforce-se por conseguir colaboradores realmente importantes para o projeto. ,

E evidente que a complexidade é inevirá.vel em um modelo de objeto complexo ou uma interfuce altan1ence detalhada. Alguns aspectos exigirão explicações e te1npo para serem assin1ilados, e esteja certo de que isso realmence acontece. Mais freqiience1nenre, a complexidade é uma desculpa para colocar panos quentes e1n uma redação inexpressiva ou e1n u1n raciocínio medíocre. O objetivo de redigir uma especificação é apresencar u1na descrição, de modo a 1ninimizar o trabalho das oucras pessoas para encendê-la. No pior caso possível, alguém levaria rnais tempo para encender a especificação do que para elaborar a coisa roda por conta própria. Assim como acontece co1n a maioria das que.~cões relacionadas 1t escrita, esses critérios são alta1nente subjetivos. Identificar o nível certo de esclarecimenco e a co1nplexidade adequada é uma questão de bon1 senso, e é melhor deixar que os líderes da equipe decidan1.

Na tentativa de apresentar uma boa descrição, eis algumas dicas para redação e coisas a seren1 evitadas nas especificações:

• Use as boas expücações contidas em outras esp ecificações {mesmo que sejam de autoria de outras pessoas). Use o hipertexto adequadamente e obtenha visões gerais úteis na Web, se necessário - o que deve ser estiinulado pelos líderes da equipe. Você não ten1 que inventar ou descrever absolutamente tudo.

• Evite jargões e termos obscuros. Não use esses recursos de linguagem, a menos que você tenha certeza de que ajudarão o leitor, o que raramente acontece. Ou, colocado de forn1a ainda menos aproveitável, reduza a provável confi.1são intencional do material teórico através da concisão atenuada de 1nacro­conceitos em transfonnações de conhecimencos inequívocas e a anulação geral de construções lingüíscicas redundantes.

• Preserve as velhas especificações. Elas são boas referências quando você ainda não sabe como apresentar u1n conceito da n1elhor 1naneira possível ou como diagramar algu1n aspecto. Quando você enconcrar uma boa especificação escrita por outra pessoa, use esse material ta1nbé111.

• Ao escrever, tenha em mente leitores específicos. Até 1nesmo en1 u1na equipe de l O incegrantes, 4 ou 5 deles dependerão muito da especificação. Adicione a esse mix uma pessoa inteligente que você conhece, que não faz parte da equipe, nem conhece a tecnologia específica que você está usando. Como você descreveria u1n conceito co1nplexo para essa pessoa?

• Não se apaixone pelo Visio ou por fl uxogramas. Mantenha relacionamentos platônicos com todas as ferramentas. Geralmente, os diagramas só são interessantes para quem os criou, e normalmente não ajudam o projeto de

ESC REVENDO BOAS ESPEC IFICAÇ ÕES 151

modo cão eficience guanco seus criadores supõem. Às vezes, um bo1n parágrafo ou llln si1nples rascunho feiro à 1não funciona 1nelhor do que utn diagrama de UML com 500 elemencos gráficos. (Só porque u1n diagra1na é a única maneira de urn aucor encender alguma coisa, isso não garante que seja a melhor rnaneira de explicar essa coisa para outra pessoa.) As ferrarnentas e diagramas podem ser recursos excelentes, basta manter a objetividade e1n relação a eles.

• Isso é uma referência ou uma especificação? Geralmente, as especificações não precisam ser referências completas à API ou descrever cada instância ou possível con1porcamento. É plenamence razoável explicar apenas 1 O ou 15 casos con1uns ou os mais importantes e preparar um documento separado que relacione todo o restante (com menos detalhes).

• Antes de colocar a mão na massa, use um pseudocódigo ou até o seu idioma para descrever algoritrnos con1plexos ern alto nível. Co1no 1nencionado ancerionnente, pense em como u1na abordagem da explicação em camadas pode ser o método de assi1nilação 1nais rápido - inclusive para as pessoas inteligentes. No mínimo, os resumos e as visões gerais eficientes pode1n concribuir baseante.

Exa111ine a seguir mais um truque que sen1pre n1e ajudou: quando algué1n não entender direito algum ite1n incluído em um rascunho de sua especificação (coisa que você só descobrirá se subornar alguém para ler previarnente), pare por 5 1ninutos e dê luna explicação a essa pessoa. Assitn que ela entender, pergunte a ela

' se o assunto poderia cer sido abordado melhor em sua especificação. As vezes, você recebe uma boa sugestão, ou eras vezes não, mas seu discernimenco sempre há de melhorar porque você estará se obrigando a ampliar sua perspectiva. Toda vez que você perguntar a outra pessoa, estará examinando um conceito específico de un1 nlodo ligeiran1ente diferente, aumentando a probabilidade de descobrir uma abordagem mais eficaz. Corno autor da especificação, lembre-se de que um comentário construtivo vem rnuito mais facilmente se você o solicitar, ern ve-l de esperar por ele.

Garanta que a coisa certa aconteça

As especificações definem u1n grupo de intenções. Elas têrn a seguinte postura: "Se as coisas acontecerern conforme esperamos, quando esse trabalho estiver concluído, obtere1nos o que escá descrico neste docurnento"; e1n outras palavras, rodo (ou uma porcencagem razoavelmente alta) o comporcamenco e a funcionalidade delineados em uma especificação de recursos devem ser rnanifestados no código operacional final, quando tudo estiver finalizado . Embora seja tocaln1enre possível que no dia seguinte ao término da especificação o n1undo possa rnudar, no dia em que foi escrita a intenção existia. Quando o inundo 1nudar, a especificação deverá ser atualizada de nlodo a refletir esse novo mundo e as novas intenções - sejam elas quais forem.

No nível de engenharia, o objetivo de uma especificação é inforn1ar essas intenções a rodos os que necessitam utilizá-las. Para os testadores e para a garantia da qualidade, isso significa rer uma exatidão suficiente do comporrarnento esperado de um projeto para redigir rascunhos de casos de cesre e estimativas.

152 A.ARTE DO GERENC[AMENTO DE PROJETOS

Especialiscas em markecing, docu1nencação e oucros especialiscas parcicipances do projeco obcerão resposcas para oucras perguncas sobre co1no será o resulcado final, ances de realizarem suas acividades. Os gerences de suporce cécnico e de concas precisarão saber co1no as coisas funcionam para serem capazes de respaldar ou preparar o suporte para o trabalho.

Uma das n1elhores perguntas para se fazer às pessoas depois de lerem uma especificação é "você tem o necessário para fazer seu 1nelhor trabalho?". Elas farão perguntas nlelhores e colocarão a especificação em prática, em suas mentes, e a seguir no mundo real.

Quem, quando e como

Assim como os documentos de visão, é muito importante que as especificações tenham um único autor. Todos aqueles que realizarão o trabalho deverão contribuir, emitindo comentários e adicionando conteúdo, 1nas uma só pessoa deve filtrar, fonnacar e fàzer com que todas as peças se encaixem. O motivo é simples. Para que u1na especificação seja lida conforme foi escrica por uma pessoa de raciocínio claro, várias pessoas diferences não deverão preparar parces diferentes do documento. Desde que um único autor entenda que seu trabalho é incorporar as boas contribuições e sugestões oferecidas, tudo funcionará bem.

Presun1indo-se a exiscência de um único aucor principal, os prováveis candidatos ao cargo seria1n o gerence do projeto, o designer ou o progra1nador chefe. Co1no as especificações represencain uma co1nada de decisões 1nulcidisciplinares, elas devem ser redigidas pela pessoa que civer mais aucoridade sobre as decisões nesse nível. A especificação de recursos e a especificação cécnica devem ser condizentes e relacionadas às listas de itens de trabalho compiladas pela equipe de programação. Se as equipes de engenharia e de design trabalharam em conjunto durante todo o processo de design, será fácil coligar todos esses aspectos. E1n compensação, trabalhar em conjunto na fase inicial muda a perspectiva sobre o processo da especificação: ela será percebida como uma colaboração feliz para o trabalho de planejamento, e não como o início de u1n processo de debates e frustrações.

Por esse e outros motivos, o trabalho da especificação deve começar na fàse de design. À medida que os protótipos forem construídos e as idéias exploradas, decisões inceligences começarão a fluir do trabalho, e os rascunhos de docu1nencos de especificações poderão ser iniciados (e devem ser marcados como versões preliminares). Esses documentos pode1n ser 1nan cidos confidenciais até existir un1a descrição suficiente para ter relevância para 1nais de u1na pessoa. Em conversas entre a diretoria do projeto, equipes de design, 1narketing e progran1ação, surgirá wna percepção lenca mas estável sobre o design certo, e a especificação deverá trilhar por essas discussões. Quando o processo de design chegar a u1n ponco e1n que só exisca1n duas alcernacivas principais, a especificação cerá um ímpeto forte para respaldá-la. Co1n apenas duas alcernacivas sobre a 1nesa, as especificações poderão, no 1nínimo, incluir rodos os elen1entos comuns e o trabalho de engenharia necessários nessas duas alternativas (por exemplo, um mecanjsn10 de pesquisa necessário para ambos os designs), assim como uma listagem de alco nível das demais decisões importantes e suas possíveis itnplicações.

ESC REVENDO BOAS ESPEC IFICAÇ ÕES 153

Escrever para um versus escrever para muitos

Para os gerentes de projeco, as especificações podem ser u1n local prácico para reunir cedas as inforn1açóes úteis. Geral1nence, há rancas perguntas ou dúvidas de pessoas diferences, que o docun1enco de especificações ern si se torna, aparentemente, o lugar mais fáci l de rastreá-las. Infelizmente, para outra pessoa exceto o gerente de projeto, esse nível de detalhamento torna-se ruidoso. Ler uma especificação não deveria ser como ler o diário profissional do autor (como muitos cientistas e engenheiros o fazem, 1nancer um diário profissional separado pode ajudar a descobrir boas idéias) . Quanto maior a equipe e mais especializadas forem as fi.1nções, canto pior será esse problema.

Contudo, uma das funções importantes da especificação é auxiliar o GP diretamente. Como o gerente de projeto precisa organizar e comandar o esforço, provavelmente o documento será. modificado e lido mais ve-Les por ele niesmo do que por qualquer outra pessoa. O diálogo ao estilo diário que emerge na especificação tern u1na fi1nç.'io relevante; o rastreamento de fragmentos específicos e decalhados de informações sobre um projeco tern a sua imporcância. O truque é fazê-lo de modo a não obscurecer a narraciva principal e as decisões que a especificação escá cencando delinear.

Sendo assim, quando você esciver criando uma especificação, cenha o cuidado de isolar os detalhes que acendem somence ao GP e aqueles imporcances para o restante da equipe. A 1naneira 1nais sin1ples de fazer isso é separar as explicações do con1portamenco ou da funcionalidade na especificação das questões ou perguntas sobre as descrições atuais. Poderia existir tuna única lista de questões pendentes no final da especificação, que é a solução mais sitnples.

Quando as especificações estarão concluídas?

Para un1 cronograma de desenvolvimento que abrange uma fase de planeja1nenro, a redação e revisão das especificações são a sua conclusão natural. En1 termos teóricos, a equipe deverá conhecer a maioria dos detalhes do que será construído e como será feito, quando as especificações estiverem finalizadas. O projeto estará pronto para voar baixo, e o equilíbrio do trabalho migrará dos planejadores e tlesigners para os programadores e testadores.

O que é suficiente?

Determinar quando uma especificação está concluída é um julga1nento de valor. Se1npre haverá questões e perguntas retardatárias ou dependência em relação a outras empresas e projetos que ainda não foram totalmen te identificados. A marca de aprovação de "especificação co1npleca" pode significar vários níveis distintos de incegridade e qualidade, dependendo do projeto e da equipe. Não há nada cerco ou errado aqui: às vezes, o risco de especificações 1nais fracas é superado pela pressão do cronogra1na ou por oucras considerações. Como qualquer outro aspecto de alto nível de um projeto (qualidade, estabilidade e desempenho do código), somente o bon1 senso dos líderes da equipe pode decerminar o nível cerco de invesri1nenco. E evidencen1ence que, quanto mais iteraciva for a escratégia

154 A.ARTE DO G ERENC[AMENTO DE PROJETOS

de engenharia geral, canco rnaior será a possível flexibilidade no modo como as especificações serão escricas.

Como uma regra universal, quanco mais force for a especificação, canco 1nais alta será a probabilidade de u1n resultado oportuno. A questão, então, é de quanta probabilidade você necessita? Compensa o tempo necessário para aperfeiçoar uma especificação e1n 50/o? Ou os programadores ou o gerente de projeto teriam detectado os detalhes no decorrer natural do trabalho? A resposta não é fácil. Ao examinar detern1inada especificação, eu reria que usar meu bo1n senso. Acho que isso exige experiência etn projetos, mais do que conhecimento de programação ou redação, para fazer esse julgamento de valor.

Entretanto, convém observar que, independentemente do nível de integridade esperado para que as especificações sejam consideradas concluídas, a única maneira de chegar a esse ponto é atrdvés do processo de revisão. Pelo futo de ser muito subjetivo e comparativo, o único modo de obter especificações com uma certa qualidade é instruir os líderes de equipes (e usuários das especificações) a revisarem e emitirem co1nentários sobre elas. (Esse processo será descrito na próxi1na seção.)

Como gerenciar as questões pendentes

Independentemente da eficiência no gerenciamento do processo de design, sempre haverá questões não resolvidas durante a redação das especificações. Se essas questões náo forem gerenciadas de modo adequado, será um desastre. Muitos desastres ocorridos no 1neio de projetos são conseqüências de questões de especificação mal-geridas ou negligenciadas. É crítico que o GP tome a iniciativa de reunir e examinar essas questões, instruindo a equipe a reconhecê-las logo no início . . Esse é um desalio cornplicado para os GPs menos experientes, uma vez que estarão tão absortos em oucras tarefas da redação de especificação, que não atribuirão um tempo adequado para administrar as questões pendentes. Geralmente, é preciso ser atropelado por u1n problema mais adiante no projeto, para se reconhecer a irnportância do acompanhamento prévio dessas questões.

O gerenciamento eficiente das questões pendentes está diret:runence relacionado ao levanrainento de dados. É necessário investigar os possíveis problemas e reservar um cen1po para anotá-los. Não há nada mágico aqui. Assim que forem anotados, poderão ser priorizados, acribuídos e solucionados; 1nas se ninguém fizer isso, evitar problemas maiores será uma questão de sorce e não de habilidade.

Pressupondo que você realn1ence rastreie os problemas de alguma 1naneira, mesmo que isso seja feito apenas em urna lista no quadro de seu escritório, examine a seguir algun1as perguntas básicas para ajudá-lo a priorizar e refiná-los:

• Quando esse problema deve ser resolvido? Quem é a melhor pessoa para tomar as decisões necess;\rias para resolvê-lo?

• O proble1na pode ser isolado de algu1na rnaneira, talvez em u1n co1nponente ou cenário específico? Ou ele afeta o recurso ou o projero inteiro?

• Quais são as possíveis soluções para o problema, que ainda estão sendo exaininadas? (Por exe1nplo, usaren1os ASP ou PHP, 1nas não JSP.) De que modo cada alrernativa afetará a especificação?

• É possível eliminar esse proble1na? De que 1nodo ele realn1ente afeta o cliente em nosso cenário do usuário da prioridade 1?

ESCREVENDO BOAS ESPECIFICAÇÔ ES 155

• É possível decornpor o problema ern problemas menores que podern (devem) ser delegados a ourras pessoas?

• Quern ou o quê esrá impedindo a solução desse problerna, e esrão sendo realizados esforços para derrubar o bloqueio? (Essa solução pode ser récnica ou política.)

Se existirem vários problemas grandes e for difíci l dividi-los, alguma coisa deu errado, e o processo de design e/ou a liderança da equipe falhou . O modo de contornar o problema está alén1 do âmbito do gerenciamento de questões pendenres. (Consulte o Capítulo 11.)

Fechando a lacuna da especificação

Se você gerenciar de modo eficiente as questões pendentes, conseguirá fechar as lacunas do cronograma, prevendo como esses problemas serão resolvidos. A Figura 7-1 ilustra a idéia básica, em geral citada cinicarnente como "um encaminhamen to paralelo" (shot-gunning). Se isso for feito corretamente, urna especificação poderá ser revisada e considerada ocasionalmente concluída, rnes1no que ainda existam questões de design em aberto. Na realidade, o shot-gunning traz um risco: você esrará esrimando a eficiência com a qual a equipe solucionará as quesrões restantes, ern vez de esperar a equipe realmente resolver rodas elas. Contudo, não é necessaria1nenre un1a opção de alto risco. Tudo depende do grau de discernimento sobre os proble1nas e da eficiência das prernissas feitas em relação a eles. Por exen1plo, considere duas equipes. A equipe A cen1 u1na lisca de problemas extensa, n1as bem dirin1ida. A equipe B tem uma lista de problemas curta, mas mal-djscernida. Em sua opinião, qual equipe cumprirá os respectivos prazos? Eu aposraria na equipe A (roque a 1núsica - o rema do A-Team). Nada 1nais a acrescenrar, o ceticismo me diz que a pequena lista de problemas da equipe B implica que os integrantes dessa equipe ainda não reconheceram todos os problemas da especificação. A equipe A investiu mrus cempo entendendo as questões pendentes e está mais bem preparada para todos os desafios que o projeto lhe reserva.

Espaço dos problemas (explorando alternativas)

Data de conclusão das especificações

@-=====-'> O tempo transcorre nessa direção

FIGURA 7-1. Fechando a lacuna entre o design e a especificação.

É imporcante observar que o fechamento da lacuna não significa abandonar o trabalho de design necessário para finalizar essas decisões. Indica que o GP tenta retroceder por uns instantes e fàzer julgamentos de valor criteriosos, para manter o cronograma.

156 A ARTE DO GERENCIAMENTO DE PROJETOS

Para ajudar a fechar a lacuna, considere esras pergunras para cada quesrão pendenre:

• Exisce1n irens de rrabalho que precisa1n ser concluídos, a despeiro da alternativa escolhida? Neste caso, eles devem ser estimados e adicionados à especificação. Se necessário, esses irens de rrabalho podem ser iniciados antes da conclusão da especificação.

• O GP ou o designer pode resolver esse problema? O encerramento dessa questão resultará em novos itens de rrabalho? (Por exemplo, talvez seja possível trabalhar si1nultaneamente con1 o programador, começando pelos itens de trabalho reconhecidos, enquanto o GP orienta a soluç,'ío do problema pendente.)

• Quas são as alternativas possíveis para solucionar o proble1na, que ainda estão sendo exa1ninadas?

• Dentre as prov<1veis alternativas, qual é a mais cara? Procure estimar os irens de trabalho com base nessa abordage1n, e tornar a especificação e a lista de irens de trabalho u1n plano de design do pior caso.

• Trara-se de u1n componente central ou do núcleo? Quando o progra1nador deverá implemenrá-lo? Isso pode ser elaborado mais carde, durante a fase de iinple1nenração? É algo do qual alguns ourros co1nponenres dependam?

• Esse problema pode ser conrido, reduzido, dividido ou eliminado? Caso conrrário, desloque-o para o início da lisra de prioridades.

Nem sempre é possível fechar a lacuna com êxito. Talvez você consiga algun1 avanço significativo e evolua em alguns aspectos, mas ainda estará muito longe. Mesmo assim, forçar um fechamento nunca é demais. As equipes experientes geralmente precisam desse ripo de pressão para obrigá.-las a confrontar todos os seus proble1nas (técnicos ou não) e os gerentes podern não conhecer totahnente a complexidade do que ainda fàlta acontecer. É possível fazer uma boa argumentação para fechar a lacuna de modo proacivo, em vez de esperar que o cronogra1na fique compromecido.

A importância de alcançar uma especificação completa

Deve haver uma data no cronograma do projero para concluir a especificação e calvez seja a dara mais i1nporrance para os GPs, como colaboradores individuais no projeto. Geral1nente, a redação da especificação é a principal ou calvez o único resultado (deliverable) literalmente importante para o projeto. Tão logo as especificações estejam concluídas, o foco dos GPs se deslocará para orientar e comandar o projeto, inclusive ajudando a rransição da equipe para o desenvolvin1ento pleno.

Após a conclusão da especificação, deverá ocorrer un1a n1udança na psicologia e ar.itude na equipe do projeto. O sencimenro deve ser aquele e1n que, para o marco atual, as preliminares cern1inaram, e que várias decisões difíceis já fora1n tomadas. A equipe enfrentou grandes desafios para descobrir os designs cercos e identificar as diversas possibilidades para acender à visão e encontrar um plano coerente. Fica por conta do GP assegurar que rodos os

ESCREVENDO BOAS ESPECIFICAÇÕES 157

parcicipances do esforço acé enciío percebam u1na parce dessa perspecciva e cenha1n o seu crabalho reconhecido.

NOTA A melh<>r maneira de elogiar o trabalho das pessoas é f.1zer isso cara a cara. Não use o email para dizer à equipe o quanto significan1. Bata de porta ein porta ou ligue para cada integrante. U1na conversa rápida cem 1nais carga emocional do que qualquer email.

Com roda a dificuldade de se realizar bons eventos que estimulam a equipe e conversas de incencivo, deve haver algum tipo de reconhecimento para a equipe inteira pelo trabalho desenvolvido até então. Geralmente, as coisas simples funcionam melhor: uma tarde de folga, um almoço mais demorado ao ar livre, ou uma semana de cervejas ou petiscos grátis na cafeteria. Alguma modalidade de intervalo positivo na rotina (por exempo, sair do local de trabalho) é a melhor forn1a de ajudar as equipes a fuzer uma transição e recarregar-se, co1no 111na preparação para as diversas pressões que enfrentarão nas semanas ou meses seguintes.

Revisões e comentários

O 1naior engano das pessoas quanto às especificações é esperar u1n processo de revisão fonnal para receber um feedback sobre o seu conceúdo. As revisões devem ser usadas para confinnar e aprin1orar, não para dar uma primeira olhada e u1na decisão final ao 1nes1no tempo. Este é outro 1notivo pelo qual um processo de design é cão importante: significa que as decisões do design tiveram muitas iterações, e os aurores tiveram muitas oportunidades de incorporar boas sugestões. Os líderes da equipe devem incentivar esses eventos, prontificando-se para as análises iniciais informais e disponibilizando as especificações prel .. iminares na intranet. Mas isso não significa que as análises e reuniões iniciais sejam uma moleza; todos devem seguir para o processo de revisão com un1a idéia muito clara do que se espera de cada um.

É possível revisar as especificações de várias maneiras, 1nas a maioria delas exige uma reunião onde o documento é lido ou discutido para a satisfação de alguém. O grau de formalidade ou informalidade dessa reunião depende muito do nível cultural da equipe, da conduta de seus líderes e da natureza do projeto. Seja como for, o objetivo é responder às mes1nas duas perguntas: "Esta especificação está suficientemente detalhada para nos orientar durante o desenvolvi1nento inteiro?" e "O resultado atenderá aos requisitos e objetivos dessa parte do projeto?". Cerra1nente, há várias perguntas 1nais específicas a serem feiras, 1nas rodas elas se originam dessas duas perguntas básicas. O processo de revisão deve ser oriencado para responder a essas perguncas com segurança.

Como revisar uma especificação

A revisão da especificação deve ser um processo em equipe. Embora o centro da atenção esceja no documenro e nas pessoas que o redigiram, o objetivo deve ser confirmar que todos os envolvidos no trabalho concordam com o conteúdo do

158 A ARTE DO GERENC[AMENTO DE PROJETOS

documento. O modo 1nais fácil e rápido de fazer isso é reunindo rodos em tuna sala, para que rodos conheça1n as resposras a rodas as pergunras feiras. Já resren1unhei revisões de especificações feiras por e1nail ou por audioconferência, e posso afinnar que não fiquei sarisfeico com os resulrados. Assi1n que un1a questão enfadonha surgia, o que eu mais queria era estar na mesma sala con1 a equipe e usar quadros brancos ou gestos com as 1nãos para explicar os deralhes em rempo real. Quanto nlais complexa é a especificação, mais você deseja a presença das pessoas na sala. (Se você é obrigado a trabalhar virrualmenre e acha que todos devem part icipar na revisão, relina pequenos grupos de três a cinco inregranres. Para tarefas mais complexas, como revisar especificações, as audioconferências e videoconferências com grupos grandes se tornarão rapidamente verdadeiras tragicomédias.)

Deve ser reservado com vários dias de antecedência um intervalo de tempo de uma ou duas horas em uma sala de conferência de tan1anho 1nédio. Se a especificação estiver preparada para revisão (conforme o autor determinar, con1 orientação a partir dos critérios definidos pelos líderes da equipe), ela deve constar co1no parre da convocação para a reunião. Se não me falha a memória, só consegui fazer isso poucas vezes. Era mais co1nu1n eu agendar u1na reunião com cerca de u1na semana de anrecedência e infonnar a rodos que o documento seria enviado por email 24 horas antes da reunião de revisão da especificação. Algumas pessoas odiavam isso, mas descobri que é o 1nelhor método para enrregar um docu1nento atualizado e fazer con1 que as pessoas o leiam. Avisando antecipada1nente, as pessoas podem reservar um tetnpo nesse período de 24 honls para ler o 1naterial.

Exaran1enre por isso, acho justo solicitar aos participantes da revisão da especificação que leian1 o docun1ento antes de virem para a reunião. Por seleção narural, as pessoas que realn1ente precisarem lê-lo encontrarão tempo para fazer isso, porque será uma das coisas mais importantes que estarão fazendo. A despeito do que possam dizer, se não conseguire1n realmente tempo para, pelo menos, verificar os problemas mais gritantes no docu1nento, o trabalho não será uma prioridade 1náxin1a para essas pessoas e elas não farão parte da sala.

Se1npre que autorizado a fazê-lo, eu exigia que a equipe inteira lesse as especificações antes da reunião. Isso me dava duas certezas. Primeiro, iria reduzir o nlimero de pessoas participantes somente àqueles que efetivamente precisavam comparecer. Não haveria a probabilidade de uma sala repleta de "pentelhos". Em segundo lugar, a reunião de revisão transcorreria 1nuico mais rapidainenre porque rodos esrariam partindo de um nível de conhecimenro se1nelhante. A rendência das pessoas que não lia1n a especificação era destacar-se pelas pergunras que faziam. Se as perguntas tossen1 pertinentes, deveriam ser consideradas, mas se estivessem a1npla1nente cobertas na especificação, seria justo pedir a essas pessoas que lessem a seção ou procurassem o autor da especificação depois da reunião.

Quem deve comparecer e como funciona?

Deve estar na sala pelo 1nenos uma pessoa de cada função i1nportante (prograinação, teste etc.), alé1n de todas as outras tl1nções de apoio relevantes (negócios, design, documentação). As revisões deven1 ser abertas à equipe inteira: se os testadores ou programadores esriverem interessados na especificação e conseguiram un1 ren1po para lê-la, a participação deles deve ser bem-vinda,

ESC REVENDO BOAS ESPEC IFICAÇÕES 159

rnesmo se não rrabalharem no recurso específico. Os líderes da equipe deve1n receber convires opcionais, e eles 1nes1nos decide1n se deverão parricipar da reunião. Se eles desenvolveram be1n o seu rrabalho, devem conhecer deralhes suficienres para participarem apenas das revisões de especificação rnais controversas. Por outro lado, se for uma equipe inexperiente, seus membros deverão participar de todas as reuniões.

A reunião em si deve ser realizada pelo GP (ou pelo autor da especificação). O processo é simples: responder perguntas. Se não existirem perguntas (ou seja, a terra da fantasia) e as pessoas certas estiverem presentes na sala, felizes co1n a especificação, a revisão estará terminada. Alguns GPs gostam de fuzer resumos do prorótipo final, o que é muito bom. Ourros preferem repassar cada seção do documento. Em minha opinião, é uma perda de tempo (se escrevi uma boa especificação e todos a leram, por que repetir a coisa toda?), mas algumas equipes gosram disso; portanto, use o que realmente funciona. O único aspecto importante é que as pessoas estejam participando de uma discus.~o saudável, fazendo perguncas interessantes e trabalhando em conjunto par<1 as identificações necess.1rias.

Para qualquer questão levantada, fica a critério das pessoas na sala discutirem a resposta para acender ao requerente ou para incluir urn novo irem na lista de questões pendentes da especificação. Quando não houver mais perguntas, o GP revisará essa lista (um quadro branco na sala de conferência funciona bem para listar os novos irens) e determinará se existe algo que rnereça outra discussão de análise. Se nada 1nais avançar, a especificação será considerada revisada, falrando investigar e solucionar as novas questões pendentes.

Após o término da revisão da especificação, o GP ter<Í u1n prazo para responder às novas perguntas ou questões levantadas na reunião. Imediatamente após a reunião, todos os convidados a participar deverão receber uma 1nensagem de email com um pequeno resumo das questões pendentes, com a dara da próxima revisão (se já estiver agendada) e con1 um prazo para a solução dessas questões. Isso é n1uito importante se uma questão pendente impedir que um integrante da equipe execute seu trabalho. N a verdade, as questões bloqueadoras devem ser identificadas durante a revisão da especificação e devem receber atenção especial.

A lista de perguntas

Existe1n algurnas perguntas que devem ser feiras em roda revisão de especificação, baseadas em aspectos comuns que as pessoas detectara1n corno erros no decorrer do ce1npo. Mesmo que fàzer perguntas cornplexas não identifique os proble1nas específicos, essas perguntas real1nente obriga1n a equipe a pensar de modo mais crítico sobre o que estão fàzendo. Lembre-se de que isso não é um exame final: tudo bem que todos já conheçam as perguntas antes de co1nparecere1n. Você cern interesse em garantir que rodos os participantes da revisão esceja1n preparados.

Como o design e a redação da especificação são processos odmiscas, as pessoas na revisão podern duvidar e con1provar coisas que pode1n ter sido negligenciadas. (Cuidado para não ser sórdido. Para ser crítico, você não precisa se desviar de seu can1inho e ser cruel ou fazer as pessoas se sencirem mal. Se u1na equipe esciver lan1encavelmente despreparada para revisões de especificação, a maior responsabilidade geralmente recai sobre os líderes da equipe

160 A ARTE DO G ERENC[AMENTO DE PROJETOS

individualmente.) Mes1no que a equipe saiba as perguntas cercas, algué1n cem que se empenhar para garandr que as respostas efetivas venha1n à tona.

Eis a minha !isca, 1nas reco1nendo que você revise essas perguntas e acrescente as suas:

• A lista de itens de trabalho do programador está condizente com a especificação? De que modo cada componente importante na especificação está relacionado com cada item de trabalho? Onde, no design, há n1ais probabilidade de detectar itens de trabalho negligenciados?

• Existe alguma probabilidade desse design ser dividido? Quais são os componentes ou interfàces mais frágeis? Por que não pode1n ser melhorados?

• Qual é o aspecto mais forte desce design? Qual é o mais fraco? O que nos transmite 1nais ou menos confiança? Nossos poncos forres e nossa confiança estão centrados nos componentes 1nais importantes?

• Ten1os o nível de qualidade certo? Essa qualidade ser;í tão confiável, atuante e utilizável quanto exige a nossa visão do projeto? As esci1nacivas dos testes são realísticas?

• Por que um design mais simples não é melhor? Realtnente necessitamos de tanta complexidade ou funcionalidade? Que provas temos ou que argumento confiável pode ser apresentado para não simplificá-lo?

• Do que este design depende? Existem tecnologias, corporações, projetos ou outras especificações que possam fracassar, de n1odo a prejudicar ou impedir este trabalho? Ternos 1ilgu1n plano de contingência?

• Que elementos do design muito provavelmente serão alterados? Por quê?

• Teste, documentação, marketing e todas as outras funções especializadas desce projeto cêrn todas as inforrnações necessárias para permitir a execução do trabalho? Quais são as principais preocupações e de que modo serão solucionadas? Ou exisce1n motivos justos para igno rá-las?

• Quais são as principais preocupações dos GPs, programadores e testadores quanto a esca especificaç.'io? E quanto a este recurso?

• Existem oportunidades para cotnparcilhar ou tomar emprestado um código com outros recursos sendo construídos para este projeto?

• Conseguin1os atender aos requisitos de acessibilidade e localização da Ul?

• Quais são os riscos de segurança desce design? Por que não fàz sentido eliminá­los? Eles estão documenrados na especificaç.'io, juncamente com as possíveis soluções (por exemplo, modelos de riscos)?

• Existern provas confiáveis de que os usuários especificados podem usar este clesign de U I para realizar com êxito o que precisam fazer?

Resumo

• As especificações deve1n atingir três objetivos: garantir a construção do produto certo, fornecer urn 1narco do cronograma que conclua a fase de planejamento de um projeto, e pennicir uma revisão minuciosa e o feedback de várias pessoas, no decorrer do projeto.

ESCREVENDO BOAS EsrECIFICAÇÓES 161

• As especificações solucionam apenas decerminados problemas. Os líderes da equipe devem ser claros quanco aos problemas que escão cencando solucionar com as especificações, e quanco aos problernas que precisam ser solucionados de . oucra n1ane1ra.

• As boas especificações simplificam. São basica1nenre uma forma de comunicação.

• Especificar é muito diferente de criar.

• Deve ser definido claramente quem deverá redigir e quem controlará a especi flcação.

• Fechar a lacuna é um método de gerenciar questões pendentes e agilizar o final do processo da especificação.

• Um processo de revisão é a forma mais simples de definir e concrolar a qualidade da especificação.

Capítulo 8

Como tomar boas decisões

164 A ARTE DO GERENCIAMENTO DE PROJETOS

Q.ando estava escrevendo este livro, enrrevisrei n1ais de u1na dúzia de gerenres de projero. Uma das perguntas que eu lhes fazia era corno romar boas decisões. Suas respostas concinharn sugestões co1no ponderar as opções, definir critérios e procurar rnécodos diferences para resolver a situação ern questão. Mas quando eu lhes perguntava quantas decisões tomavam por dia, e com que freqüência usavam as técnicas que citaram, geraln1enre percebiam que algo estava errado. Vários deles admiriam (depois de olhar ao redor para ter certeza de que ninguém mais ouviria) que era impossível seguir se1npre qualquer processo formalizado para romar decisões, devido ao rempo resrriro e à quantidade de coisas que precisavam fazer.

Em vez disso, admitiam que geralmente trabalhavam por intuição, premissa razoável e uma proteção rápida do problema imediato contra os objetivos mais imporranres do projeto. Se pudessem, eles reaplicariam a lógica usada nas decisões anteriores ou utilizariam a experiência dos projetos anteriores. Por mais razoável que essa resposta rne parecesse sempre que eu a ouvia, o gerente do projero e eu descobrimos algo frustrante. Acho que todos nós queremos acreditar que todas as decisões são rornadas com cuidado e respeito, 1nes1no sabendo que é impossível. Há urna rescrição de ternpo e um poder mental li1nitado, e nem se1npre todas as decisões podem ser tomadas de modo eficiente.

Especifica1nenre no gerenciamento de projetos, acho que os fracassos na cornada de decisões ocorrem mais freqüenre1nence não porque o co1nador de decisões era despreparado ou inexperiente, n1as apenas por ter investido sua energia de n1odo deficiente e1n rodas as diversas decisões que ele deveria co1nar. Há utn processo de mera to1nada de decisões para determinar as decisões nas quais deve-se investir tempo e energia. Esse processo exige experiência e predisposição a revisar erros e aprender com eles para se aprimorar nessa cornada de decisão de nível superior. (É possível realizar vários ripos de treinamento para desenvolver essas aptidões, 1 mas nunca vi ou ouvi falar deles com componentes centrais de qualquer currículo de ciências da computação ou gerenciamento de projetos.)

A possibilidade de tomar decisões efetivas explica como algumas pessoas poden1 gerenciar o quíntuplo do trabalho (ou de pessoas) do que ourras: elas dividem instintivamente o trabalho em partes significativas, encontram as decisões e ações de maior alavancagem e investem sua energia ao to1nar essas decisões da melhor 1naneira possível. Quanto às decisões nas quais invesriram menos tempo, deve ser mais Fácil a recuperação de quaisquer erros ou problemas por elas causados, do que dos erros que possam ter cometido em decisões importantes.

f. curioso observar que quando as "habilidades para cornada de decisões" são ensinadas nas universidades, geralmence os alunos aprendem os 1nétodos da teoria da utilidade ou a análise da árvore de decisões: processos em que as escolhas recebe1n a acribuição de valores numéricos e os cálculos são efetuados co1n base nesses valores (a análise de custo-benefício é outro método habitual1nenre ensinado). V<irios programas2 de graduação de MBA e algumas cerúficações de gerenciamenro de projeros abrange1n essa 1nodalidade de creinamenro. Conrudo, é oferecida pouca cobertura para as decisões de nível superior ou oucras considerações práticas de to1nada de decisões fora da sala de aula. Mécodos co1no a análise da árvore de decisões exige1n a quantificação de rodos os elementos, o que funciona bem para as decisões de base exclusivamente financeira, mas é algo fora do comum para as decisões de design, estrarégias ou organizacionais. Como geralmenre acontece, é necessário considerar vários fatores e perspecrivas

COMO TOMAR BOAS ÜEC ISÔES 165

diferenres para rotnar boas decisões no projeto e nenhum 1nétodo formal que conheço realtnenre incorpora rodas elas.

Não surpreende, enrão, que raros dos gerenres de projero enrrevisrados rivesse1n un1 creinamenco forn1al e1n co1nada de decisões, e desses gerences, poucos achavam que escavam ucilizando suas direcrizes com freqüência. Essa observação casual se encaixa com o que Gary Klein escreveu em seu livro, Sources of Power: How People Make Decisions (MlT Press, 1999): " ... nÍÚJ acredite nos cursos de métodos formais de tomada de decisões. São métodos de ensino que as pessoas raramente usam". Klein concinua explicando os diversos modos pelos quais piloros experientes de linhas aéreas, bombeiros e enfermeiras da unidade de crauma co1nam decisões, e como é raro que os mécodos l·ormalizados em manuais sejam aplicados para executar as atividades. Isso não significa que esses métodos sejam ineficientes, mas, sim, que os manuais raramence fornecem qualquer evidência sobre quem uciliza os mécodos e se essas pessoas são bem-sucedidas, quando comparado a outras técnicas.

Quase como os gerentes de projeco, Klein observou que esses profissionais experiences rara1nente tê1n informações ou tempo suficiente para fazer esses 1nérodos de decisões funcionaretn. E1n vez disso, esses profissionais rêtn quacro caracrerísticas: experiência, incuição, rreinamenro e rê1n um ao ourro. Para tomar boas decisões, maximizam esses recursos. Em alguns casos, como com os pilotos de avião de combace ou escudantes de medicina, o creinamenco é elaborado nessa direção. Em vez de 1ne1norizar procedimentos ou ceorias idealizados durante o treina1nenco, destaca-se o desenvolvin1ento de experiências através de simulações de problen1as e desafios comuns.

Neste capítulo, a coberrura da romada de decisões enfocará crês aspeccos: conhecer o que escá em jogo, enconrrar e ponderar as opções (se necessário) e usar as informações adequadamence.

Tomando uma decisão (o que está em jogo)

Tudo o que você faz todos os dias é u1n tipo de decisão - a hora de levantar, o que comer no café da manhã e com quem deve falar primeiro no trabalho. Nem se1npre interprer.amos essas ações como decisões porque as conseqüências são muito pequenas, mas estamos sempre comando decisões. Todos nós temos um julgamento natural sobre quais decisões em nossas vidas exigem mais atenção, e o mesmo tipo de lógica se aplica às decisões do gerenciamento de projecos. Algumas escolhas, como concracar/demirir empregados ou definir meras, cerão ra1nificações que vão durar meses ou anos. Co1no essas decisões cerão um impacco mais duradouro e profundo, compensa investir 1nais tempo examinando as opções e analisando suas diferences i1nplicações. E1n termos lógicos, as decisões menores ou . . 1nenos importantes merece1n menos energia.

Sendo assi1n, a priineira parte da ro1nada de decisões é decenninar a imporrância da decisão etn questão. Na 1naioria das vezes, faze1nos isso inscinriva1nence, reagi1nos ao problema e usa1nos nosso julgamenco pessoal. Tenho certeza de que posso to1nar un1a boa decisão no mon1ento justo ou preciso de 1nais ten1po para isso? Geralmente, são necessários apenas alguns instantes para essa identificação. Mas é exatamente aí que muitos de nós começamos a cer proble1nas. Esses instintos podem ser orientados por fatores certos ou errados. Sem dar tempo, pelo menos ocasionaln1ente, para decompor e avaliar as parres

166 A ARTE DO GERENC[AMENTO DE PROJETOS

que leva1n a esse julgamenco, realrnence não conheceremos as tendências ou pre1nissas por crás de nosso raciocínio (por exemplo, almejar uma pro1noção ou proteger um recurso favorito) .

Dito isso, eis algumas perguncas-chave para serern usadas ao aval iar uma decis,'io . . Essa lisca pode ser ucilizada para ajudar a moldar uma decisão específica ou co1no um método de reavaliação de seus critérios de alto nível para avaliar decisões.

• Qual é o problema central da decisão? Geralmente, as decisões surgem em resposta a novas informações, e o 1nodo inicial como a quescão é levantada enfoca aspectos críticos e limitados do problema. Assim, a primeira atitude a ser tomada é fazer pergunr-,is investigativas e partir para a decisão que deve ser tomada. Por exemplo, o problema pode ser definido inicialmente como "Precisamos de tempo para corrigir os 50 bugs conhecidos detectados", mas, na verdade, o verdadeiro i1npasse é "Não temos critérios de triagem de bugs". Para redefinir o problema e a decisão em uma fonna mais útil, é necessário trilhar um longo carninho no sentido da rnelhoria da qualidade da decisão. Ser paciente e cer calrna diance de um problema aparente1nence urgente geralmente ajuda. Faça perguntas como: Qual é a causa desce problema? É um problema isolado ou afetará oucras áreas? De quem é esce problema? Que objetivos na visão não incluíram esse risco? Já tínhamos tomado essa decisão na especificação ou na visão, e neste caso, há bons 1notivos para reconsiderar agora?

• Por quanto tempo esta decisão afetará o projeto? Até que ponto afetará? U1na grande decisão, corno a orientação da visão ou da cecnologia a ser usada, afetará o projeto inteiro. Uma decisão pequena, como a hora de uma reunião ou o conteúdo do cronograma, afetará um pequeno número de pessoas, en1 termos rescritos. Se for uma decisão de longo prazo, e se o in1pacco for abrangente, serão necessários paciência e rigor. Se for un1a decisão de curto prazo com impacto superficial, opte por agilidade e transparência, com base em um senso claro das decisões estratégicas tomadas na visão. Geralmente, é melhor tomar as grandes decisões na fase inicia.! ou em uma determinada fàse de um projeto, para que sejam tomadas com paciência e atenção, e não quando o prazo estiver se extinguindo. (Isso faz lembrar alguns aspectos discutidos no Capítulo 2.)

• Se você estiver errado, qual será o impacto/custo? Que outras decisões serão afetadas, como conseqüência? Se o impacto é pequeno ou desprezível, não há 1nuito a perder. Entretanto, isso não significa que você deve co1neçax a se arriscar. Para aspectos do projeto, como a usabilidade ou confiabilidade, a quaJidade recai sobre a sincronização de várias decisões pequenas encre si. A frase "morre por 1nilhares (de erros)"3 se originou dessa sicuação, onde não é u1n gr-ande erro que derruba a.lguém; 1nas vários erros rninúsculos. Porranco, você deve examinar pelo 1nenos se a escolha escá realinente isolada. Se não esciver, é melhor cencar e fazer várias escolhas de un1a só vez. Por exernplo, siga as mesmas direcrizes da elaboração da UI en1 todas as páginas, refutore todo o código que usa a 1nesma API ou elirnine de vez esses recursos. Explore o 1náximo possível cada decisão cornada.

• Qual é a janela de oportunidade? Se o prédio pegar fogo, não importa se a rota de n1ga é difícil, in1porta apenas o tempo para comar a decisão. Se você levar muito tempo para decidir, decidirão por você; as rocas se fechamo e codas as opções desaparecerão de uma hora para a oucra. Na roda-viva do universo, as grandes

' decisões não aconcecem necessariamente depois de muito tempo. As vezes, você cern

COMO TOMAR BOAS ÜEC ISÔES 167

gue comar decisões estratégicas difíceis, rapidamenre, por causa de uma janela de oportunidade limirada disponível. E1n oucras vezes, a agilidade na co1nada da decisão é mais Ílnporrante do que a qualidade da própria decisão.4

• Já to1namos esse tipo de decisão antes? Este é o ceste da arrogância. Se eu colocá-lo em uma sala de emergência com um paciente se contorcendo na mesa de cirurgia e pedir que fuça uma cirurgia de desvio cardíaco, até que ponto você esraria confiante? Não há vergonha alguma em admitir a ignorância: em geral, isso exige coragem. Se você esriver trabalhando em algo dificil ou ultramoderno, em algum rno1nento não terá a múún1a idéia de como agir. Não on1ita este fato (a n1enos que renha escolhido a velocidade e1n vez da qualidade na decisão e1n questão) nem permita que outr-<1 pessoa o oculte. Em vez disso, reconheça que você considera a equipe ou a si mesmo inexperiente nesse tipo de escolha e que pode precisar de ajuda externa ou de mais tempo para examinar o problema. Se um líder ou gerente admite a própria ignorância, ele dá margem a que todos os presentes na sala façam o mesmo. De repente, a tomada de decisão da equipe inteira será muito aprimorada porque, finalmente, as pessoas estão sendo honestas.

• Q uen1 tem a perspect iva de esp ecialista? Essa decisão deve ser realm ente tom ada por mim? 56 porque algué1n lhe pede que decida algu1na coisa, isso não significa que você é a pessoa mais indicada para tomar a decisão. Você é n1ais eficiente em alguns tipos de decisões do que etn outros, portanto não se sinta dependente de suas próprias restrições e1n cornada de decisões. Os gerentes de projeto são geralmente considerados especialiscas locais: rnarketing enrende o GP con10 u1n especialista técnico, e a engenharia vê o GP como u1n especialisra comercial. Mas na realidade, o GP está mais para quern tenta urn pouco de tudo (e consegue 1nuito de nada). Nunca tenha medo de ligar para as pessoas que sabem mais do que você sobre o assunto e1n questão. Pelo menos, solicite uma consultoria e convide essas pessoas para o debace. Experimence delegar a escolha totalmente para elas; pergunte se essa decisão deve ser tomada por elas ou por você. Se o nível do relacionarnento for bom, seria mais indicado tomar urna decisão coletiva, embora isso geralmente demande o tempo máximo para ambas as partes.

• Quem deverá aprovar? Q uem deverá opinar antes de decidirmos? Quanto maior for a organização, canto mais aires serão os custos adicionais para as decisões. Uma decisão aparentemente simples pode se tornar co1nplexa quando as políricas e os interesses dos stakeholders e das organizações parceiras entram em cena (consulte o Capírulo 16). Um bom reste de sua autoridade é observar com que freqüência as decisões simples exigern aprovações ou a formação de con1itês. Quanto nlaior a quantidade de processos e1n torno das decisões, canto 1nais você precisará usar de influência em vez de sentença. Há custos políticos nas decisões, que não rê1n nada a ver cotn as considerações sobre tecnologia, negócios ou clientes, e o irnpacto de tuna decisão engloba esses cusros.

Encontrando e ponderando as opções

No livro Sources of Pozver: How Peopl.e Make Decisíons, Klein identifica dois rnodos básicos através dos quais as pessoas toman1 decisões: avaliação singular e avaliação co1nparativa (consulre a Tabela 8-1). Na avaliação singular, a pri1neira opção é

168 A ARTE DO G ERENCIAMENTO DE PROJETOS

considerada e con1parada com algum tipo de critério (quero usar essa camisa verde hoje?). Se ela atender ao crirério, será escolhida e o ton1ador de decisões se concentrará em aspecros nlais i1nportantes. Se não atender ao critério, será examinada outra idéia ou opção, e o processo se repetir-J (que caJ essa camisa arnarela?). Um bom exemplo disso seria encontrar um local onde você possa utilizar o banheiro, quando realmente precisar, ou tentar encontr-ar algo para comer quando estiver com um apetite voraz. A primeira sala de estar ou restaurante disponível será suficiente e não haverá mais necessidade de examinar outras alternativas.

TABELA 8-1. Dois modos básicos através dos quais as pessoas tomam decisões

Abordagem da decisão Como funciona Exemplo

Avaliação singular A primeira alternativa Você realmente precisa razoável encontrada ir ao banheiro. é aceita.

Avaliação comparativa Várias alternativas são Você está decidindo que comparadas entre si, ilha tropical irá adquirir. antes de decidir.

Na ourra exrremidade do espectro de to1nada de decisões, a avaliação comparativa requer a busca de alrernativas para tomar uma decisão. U1n bon1 exemplo de u1na decisão comum de avaliação comparativa é pensar na cidade para a qual você mudará a família.

A avaliação singular fuz sentido para as situações en1 que a diferença entre u1na excelente solução e un1a solução rawável não é in1portante. Klein descreve essas situações como pertencentes à zona de indiferença porque o ton1ador de decisões é indiferente aos principais aspectos do resultado, desde que o critério básico seja atendido. Ser capaz de reconhecer quando todas as alternativas se encontram na zona de indiferença (consulte a Figura 8-1) pode economizar muito tempo no projeto, permitindo encerrar rapidamente os debates e as discussões e investir energia nas decisões complexas, que merecem mais atenção. Os bons tomadores de decisão não perdem tempo otimizando coisas que não precisam ser ocin1izadas. Como dizia Tyler Durden, "o que nã.o é i1nportante real1nente não deve merecer importância".

O que não é

FIGURA 8-1. A zona de indiferença contém os aspectos de um problema que não é importante para você; a avaliação singular implica que você tem uma zona maior de indiferença do que a avaliação comparativa.

COMO TOMAR BOAS ÜECISÓES 169

A avaliação cornparaciva é 1nais indicada para sicuações complexas que englobam diversas variáveis, cêrn conseqüências difíceis de serem rapidamence encendidas ou exigem urn resulcado de alca qualidade. As novas sicuações ou problernas de natureza esrracégica são excelentes candidatos à avaliação comparativa. Quanto mais a decisão de alguém estiver en1 risco e quanto n1ais conhecida for a natureza das opções para rodos, canto n1ais adequada será uma avaliação co1nparativa. Co1n equipes, a avaliação con1parariva é a melhor estrutura a ser utilizada se você precisar convencer ourras pessoas ou desejar a participação dessas pessoas no processo de cornada de decisão. A avaliação comparativa obriga a criar argumentos relativos e a desenvolver un1a base l6gica mais profunda para a ação, o que é úril para a discussão em grupo e a comunicação.

Na maioria das vezes, tudo é motivo para fazer comparações rápidas. Existem várias maneiras de fuzer uma avaliação comparativa, e algumas delas são mais elaboradas que outras. Por exemplo, não demora mais do que alguns minutos para listar algurnas alternativas para urna decisão em urn quadro, e fuzer alguns julgamentos rápidos sobre seu valor relativo. Mesrno trabalhando sozinho, descobri que fazer uma pequena lisra de comparações é um born método de verificar a minha sanidade. Se eu não puder apresentar rnais de uma opç.'io, então fica evidente que não entendo o problema suficientemente bem: existem alternativas.

Emoções e transparência

Poucas pessoas falarn sobre elas, mas há sen1pre questões ernocionais e psicol6gicas presentes na cornada de decisões. Richard Restak, autor de The Secret L{fe of the Brain Qoseph Henry Press, 2001), escreveu que "não existe um nlornenro sem e1noções". Nós sempre sentimos medo, desejos e motivações pessoais para fazer isso ou aquilo, quer tenhamos consciência disso ou não. Até mesmo as motivações altruístas, con10 almejar o melhor resultado para o projeto ou para os seus participantes, têm um componente emocional.

lsso significa que até o en1presário do tipo mais frio e calculista na sala tem sencimencos em relação ao que está fazendo, quer renha consciência ou não desses

' sentirnencos. As vezes, as e1noções podem ser úteis ao tomar decisões, mas, em outras ocasiões, elas nos deixam mais lentos ou nos desviam de assuntos que precisamos examinar. Além dos sentimentos pessoais, o aro da cornada de decisões em si abrange pressão e tensão, e pode gerar emoções e sentimentos, que não têm nada a ver diretamente com o assunto em questão. Ao externar o processo de cornada de decisão através da escrita ou da conversa, é possível compartilhar a carga emocional e pensar clararnente sobre as opções disponíveis. Mesmo que renhamos a responsabilidade de to1nar a decisão, abrir o processo para outras pessoas nos dá urna visão mais objetiva da melhor conduta.

A melhor maneira de comparar

A avaliação comparativa só poderá ocorrer se você tiver esclarecido o proble1na ou a questão a ser decidido. Você deverá ter uma idéia dos aspectos desejáveis do resultado (enviar mais rapidamente, melhorar a qualidade, agradar o VP etc.). Tudo deve dar inargem a usar palavras e frases contidas no documento de visão,

170 A.ARTE DO GERENC[AMENTO DE PROJETOS

nas especificações ou nas lis tas de requisitos. Esses documentos refletetn as decisões de alto nível tomadas, e você deve reutilizar seus valores o máximo possível (e é exacainenre para essa finalidade que servern esses docu1nenros). As vezes, uma conversa corn o clience ou autor dos documentos é rão eficiente (ou melhor) quanto os documentos em si.

Se você conhece os deralhes específicos da questão ou pode ir à sala con1 alguém que os conheça, levará apenas alguns minutos para apresentar un1a lista razoável de possíveis opções. Com uma lista rápida, você começará a se sentir tnelhor em relação às suas alrernarivas, e terá uma base para crazer outras pessoas para a discussão. Ocasionalmente, ficará óbvio que uma opç.'io é muito melhor do que as outras e não será mais necessária uma análise adicional. Mas, na maioria das vezes, descobrirá exatamente o contrário: o que parecia ser óbvio é mais complicado do que aquilo que pensava inicialmente. Ao anotar as opções, você cem a oportunidade de reconhecer que outras questões fugiam a seu conhecimento.

O modo 1nais si1nples de fazer isso é através daquela boa e antiga lista de prós e contras (consulte a Figura 8-2). Não tenho certeza de quando aprendi a fazer isso na vida, 1nas quase todas as pessoas às quais ensinei ou que gerenciei sabem fazer, de alguma forma, esse tipo de lista. O que eu estranho é o faro de ser tão raro ver pessoas ucílizarem essas listas em reuniões ou debates, calvez porque cemarn que ao anotar seus processos lógicos, outras pessoas pensem que não são suficience1nente inceligences para 1nemorizá-los.

Problema: Nosso programador chefe saiu.

Metas: Ntlo prorrogar o cronograma. Manter a qualidade. Maximizar a satisfaçtlo do cliente.

Prós Contras

Cortar recurso A

Cortar recurso B

Cortar recurso C

Deixar o cliente decidir

Nlio fazer nada

FIGURA 8-2. A lista de prós e contras.

Aparentemente, a lista de prós/contr.is remonta, no mínimo, ao século )('./, quando era usada. como uma ferrarnenca para ajudar a organizar debates públicos. Séculos mais tarde, Benjamin Franklin aplicou a técnica em sua própria to1nada de decisões, portanto coube a ele o crédito de cê-la popularizado nos Estados Unidos.5

Pela sirnplicidade desse tipo de lista, eis algu1nas considerações i1nportances para usá-la de 1nodo eficiente:

• Inclua sempre uma opção "não fazer nada''. Ne1n roda decisão ou problerna exige uma ação. Às vezes, a 1nelhor forma de se conduzir é não fuzer nada,

COMO ~TOMAR BOAS ÕECISÓES 171

deixar as coisas acon[ecerem e invesür energia em ou[ro lugar. Rara1nence compensa [en[ar recuperar os cuscos irreversíveis. Se1npre conceda a si mes1no essa opção, mes1no que seja somente para obrigar a equipe a encender exacamente o que está em jogo na decisão. D ependendo da polícica local, cer uma opção de "não fazer nada" na lista pode atribuir uma imporcância mais relativa a qualquer outra decisão que você venha a tomar, porque faz com que as pessoas se lembrem de que não há un1a lei universal obrigando a tomar alguma acicude em relação a u1n problema.

• Como você sabe o que acha que sabe? É uma pergunta que codos deveriam fazer. Essa pergunca permite que as pessoas verifiquem as premissas e quescionern reivindicações que, ainda que convenientes, não se baseia1n em qualquer tipo de dado, conhecimento prévio ou pesquisa. Tudo be1n em fi1zer solicitações ainda não suportadas - "Tenho certeza absoluta de que essa função será confiável" - desde que rodos saibam que o único aspecco respaldando é a opinião do solicitante (e que pode julgá-la assim). Conforme a necessidade, faça um levanta1nenco de dados e pesquise para ajudar a responder perguntas ou reivindicações imporcantes.

• Faça perguntas consistentes. Vá direco ao assunto sobre o impacco das decisões. Seja direco e honesto. Faça um grande esforço para atingir o ân1ago das opções. (Consulre a seção "Mancendo os pés no chão" no Capítulo 13.) Quanco mais rapida1nence alcançar o fundo da questão e realmente assimilar as opções, poderá passar para a decisão seguince corn a rnes1na agilidade. Seja crícico e cécico. Peça a todos que coloquem os senciinencos e as preferências pessoais de lado: não permita que as boas idéias se escondam atrás do medo de magoar os sentimentos de alguém. Apresente a lista a outros na equipe e acrescence perguncas ou con1entários significativos. Coloque todas as dúvidas ou possíveis premissas na coluna dos prós ou contras de decerminada idéia, uma pergunta sem resposta ainda pode ajudar a escla.recer o verdadeiro significado de u1na opção específica.

• Tenha uma opinião diferente. Para as decisões importantes, é crítico incluir opções impopulares 1nas aceicáveis. Certifique-se de incluir as opiniões ou escolhas que você, pessoal1nente, não aprova, rnas para as quais é possível apresentar bons argumencos. Isso preserva a sua honescidade e dá a todos aqueles que examinarem a ]isca de prós/conrras u1na oportunidade de convencê­lo a tomar uma decisão melhor do que aquela a que você chegou por conta própria. Não renha medo de perguntar a si mes1no "que escolha me faria parecer o pior mas ainda ajudaria o projeco?" ou "existen1 boas opções que me levaria1n a ad1nitir que estou errado en1 relação a algo?"

• Considere as opções lu'bridas. Algumas vezes, é possível adicionar o atributo de uma opção em outra. Con10 no design exploratório, há se111pre combinações interessantes na tomada de decisões. Contudo, saiba que isso realmente extrapola o número de opções, o que pode retardar as coisas e gerar mais complexidade do que a necessária. Esteja atenco à zona de indiferença e não perca tempo nessa zona.

• Inclua todas as perspectivas relevantes. Examine se essa decisão afeta mais do que somente a tecnologia do projeto. Existem inceresses co1nerciais que serão afetados? Usabilidade? Localização? Se esses aspectos forem metas do projeto e forem impactados pela decisão, acrescente-os ao mix. Mesmo que seja uma

172 A.ARTE DO GERENCIAMENTO DE PROJETOS

decisão exclusivamente tecnológica, há perspectivas distintas presentes: desempenho, confiabílidade, exrensibilidade e custo.

• Co1nece no papel ou quadro branco. Ao apresentar idéias/opções pela prüneira vez, você quer que o processo seja ágil e rápido. Deve ser fácil destacar irens, criar híbridos ou fazer anotações com a velocidade da luz (quase como ocorreu no início do processo de design). Não comece criando uma planilha de simulação no Excel, con1 15 colunas 1nulticoloridas habilitadas para tabelas dinâmicas; você perderá o fio da n1eada. Em algumas decisões tomadas rapidamente, basca uma lista no quadro branco. Se for preciso apresentar essa lista de prós/contras em uma reunião importante, entã.o crie uma planilha elaborada ou uma apresentação de slides, poscerionnente.

• Esgote todas as possibilidades até que os focos de interesse fiquem estáveis. Se você continuar trabalhando na lista, e1n algu1n 1no1nento, ela será reduzida a um conjunto estável. As mesmas perguntas ou opiniões básicas concinuarão surgindo, e você não ouvirá qualquer comentário novo importante das pessoas inteligentes com as quais trabalha. Quando rodas as idéias lógicas e razoáveis forem cuidadosamence examinadas, e apresentar a lista às pessoas só resulta o 1nesmo grupo de opções já ouvidas, provavelinence chegou a hora de seguir e1n frente e decidir.

NOTA Um exercício simples para o leitor é fazer inclusões na lista da Figura 8-1. Tendo en1 visra o nú1nero insuficiente de detalhes da situação fornecidos, existe pelo menos tuna dúzia de oucras opções razoáveis que poderia1n ser adicionadas. Que1n conseguir citar rodas elas receberá urn prêrnio.

Discutir e avaliar

Só será possível ro1nar decisões eferivas se existir u1na lista de opções e cerro conhecimento dessas opções quando comparadas umas às outras. Com uma lista e1n vigor, é possível examinar as opções e formar uma opinião sobre quais delas apresentam o mais alto potencial. Geralmente, somente através do debate é que as opiniões fortes podem ser desenvolvidas, e a lista de opções funciona como um facilitador natural da discussão (abordaremos a faci litaçã.o no Capítulo 9). Procuro sempre esque1natizar essas 1natrizes de decisão no quadro branco, para que quando as pessoas entrarem em minha sala e perguntarem sobre o status de uma questã.o, eu possa lhes indicar exatamente onde estou e mostrar-lhes por que estou inclinado a seguir determinada direção. Mesmo que eu nã.o tenha uma conclusão ainda, elas entenderão facilmente por que (calvez conseguindo mais tempo para tomar a decisão). Além do mais, posso pedir a essas pessoas que exa1ninem o assunto comigo, que ouça1n 1ninha lógica e 1ne dêem suas opiniões. E1n vez de tentar explicar tudo e1n qualquer lugar, a lista de prós/contras docu1nenta todos os aspectos considerados e dá credibilidade à opinião que eu tenha fonnado.

Nas equipes em que a comunicação flui bem, é natural discutir as decisões críticas e1n grupo. Cada pessoa no debate cenra encadear pre1nissas extraídas da !isca de prós/concras, e cria u1n argu1nenro para uma decisão específica. Você

COMO ~TOMAR BOAS ÕECISÓES 173

ouvirá cada pessoa dando a sua opinião nos moldes de uma história - "Se fizermos isso, então X acontecerá primeiro, mas sere1nos capazes de fazer Y" - e, em seguida, outra pessoa concordará de 1nodo harmonioso, aprimorando a história ou questionando u1na das premissas. A história é refinada e os prós e contras das opções são ajustados para se obter o raciocínio mais claro alcançado pelo grupo. Com o passar do tempo (que podem ser minutos ou dias), todos os participantes, principaln1enre quem toma a decisão, têm um conhecin1ento coral do que a decisão representa e das implicações envolvidas. Quando a lista de prós e contras se estabilizar e poucas informações novas forem acrescentadas, chegou o momento de testar e eliminar opções.

Sherlock Holmes, a Navalha de Occam e a reflexão

O personage1n Sherlock Holmes disse cerca vez: "Se você eliminar o i1npossível, o que restar, ainda que improvável, deve ser a verdade." O mes1no acontece na tomada de decisões: se você eli1ninar as piores opções, o que sobrar, ainda que ruiin, deve ser sua melhor opção. Sem dúvida alguma, é uma 1naneira cínica de decidir as coisas, mas para as decisões forres, a lógica da eli1ninação pode ser o t.'1nico jeito de driblar a pressão exercida sobre você e g-anhar í1npeco para comar a decisão final .

Se você criou lllna lista de possíveis opções e precisa Í<1zer u1na redução, procure aquelas que não atendem ao padrão 1nínin10 do projeto. É provável que você as tenha incluído na fase inicial porque acrescencava1n algo à discussão e dava1n oportunidade de descobrir opções híbridas, ou porque os requisitos estava1n sendo reconsiderados, 1nas est<Í na hora de eliminá-las. Exa1nine seus docu1nencos e suas !iscas de requisitos, consulte seu cliente ou o advogado do cliente, e risque as opções que simplesmente não serão suficientemente boas. Com sorte, você conseguirá afunilar para mais da metade e reduzir a ]isca a duas ou três opções que realmente compensam ser consideradas.

Outra ferramenta que ajuda a reduzir as possibilidades é um princípio conhecido como Navalha de Occam. Willia1n de Occa1n foi um filósofo medieval no século XII, que recebeu o crédito pelo uso da idéia de simplicidade para orientar decisões. Ele acreditava que as pessoas normalmente acrescentam complexidade às situações, embora isso não ajude a resolvê-las. Ele sugeria que o 1nelhor modo de co1npreender as coisas era encontrar a explicação mais simples e usar essa explicação em primeiro lugar porque, na maioria das vezes, era a explicação certa (ou seja, como se diz hoje e1n d ia, facilite as coisas, mané).6

A Navalha de Occam está relacionada ao processo de extirpar todos os detalhes desnecessários que surge1n pelo caminho e retornar à questão básica na raiz do problema. Implica também que a solução com a mais alta probabilidade de ser a melhor é aquela co1n a lógica mais si1nples. Pode até existir uma opção pro1nissora na !isca, que exige u1na engenharia complexa e arriscada ou que dependa novamente de pessoas ou tecnologias não-confiáveis. Aplicando a Navalha de Occa1n, a falta de simplicidade e clareza pode ser u1n critério para eli1ninar u1na opção e adota a opção simples e confiável.

Mas para aplicar a Navalha de Occam de modo eficiente, é necessário ten1po para refletir. Ao passar horas martelando sobre as nlesn1as questões, em algum momento, você perderá a perspectiva. Quando rodas as opções parecerem iguais,

174 A.ARTE DO G ERENC[AMENTO DE PROJETOS

chegou o momento de escapar. Dê urna caminhada, come um café co1n urn arnigo ou faça qualquer coisa para clarear sua 1nenre e pensar ern curro assunro. Você deve examinar as opções com a rnence fresca, para tornar u1na decisão eficiente, e não conseguirá Í.'lzer isso, se ficar bitolado nas mesmas opções o dia inteiro.

A reflexão é muito desprezada como urna ferramenta de tomada de decisões. Refletir significa retroceder e pern1itir que todas as infor1nações nas quais tem trabalhado se dissipem. Geralmente, a verdadeira compreensão só acontece quando relaxan1os e deixan1os nossos cérebros processaren1 rodas as informações que lançan1os neles. Acho que fazer algum movimento físico, como sair para uma corrida ou caminhar, é a melhor maneira de deixar minha mente relaxar. Outras vezes, fazer algo apenas por diversão dá conta do recado, como entrar em uma guerra de travesseiros, assistir a um bom filme ou brincar com meu cachorro. Também é difícil ter uma boa noite de sono (talvez precedida por un1a brincadeira descomedida entre os lençóis) para clarear as idéias. Mas rodas as pessoas são diferences e você precisa descobrir por si rnes1no o melhor rnodo de dar tempo à sua mente para digerir tudo o que anda pensando.

Quando efecivarnence voltar à sua lista de co1nparações, lembre-se rapidamente dos principais problemas. Depois, pensando em Occam, exa1nine as alcernacivas e pergunte-se que opção oferece o método mais simples para solucionar o problema em questão. A opção mais simples pode não prornecer o melhor resultado, mas devido à sua simplicidade, terá a n1aior probabilidade de resolver com êxito o problen1a en1 llln nível satisfatório.

As informações mostram o caminho

A maioria das pessoas instruídas no mundo ocidental aprende a confiar nos números. Consideramos mais fácil trabalhar com nú1neros e fazer comparações com eles do que com sentimentos ou idéias abstratos. A teoria da decisão e utilidade eirada anteriormente está atrelada a este conceito, con1 a argumentação de que tomarernos decisões melhores se pudermos converter nossos desejos e as probabilidades de opções em núrneros, e fàzer os c;ilculos baseados nesses números. A despeito da crítica que flz anteriormente sobre essas teorias, quando nos forçamos ocasionalmente a atribuir valores numéricos às coisas, isso pode nos ajudar a definir nossas reais opiniões e a ton1ar decisões nelas abalizadas.

Decisões à parte, preferimos ter evidências para reivindicações na forn1a nurnérica. Há uma diferença em tennos de utilidade e conflabilidade quando alguém aflnna que "nosso rnecanisrno de pesquisa está l 2o/o mais lento nas pesquisas corn 3 palavras" em relação à declaração de que "o sistema esní lento". Os dados nurnéricos concedem um tipo de exatidão que a linguagern humana não transrnite. Alé1n disso, os dados nurnéricos são freqüentemente exigidos pelas pessoas para respaldar suas argumenrações. A declaração de que "o siste1na está lento" leva à pergunta "Mas como você sabe disso?". A fulca de a1gurn tipo de levanta111ento ou pesquisa para a resposta torna a argumentação difícil de se acreditar, ou dependente unicarnente da opinião e julgan1ento de quem está afirn1ando. Ocasionaln1ente, um fragn1ento de infor1nação específico responde a uma pergunta importante e resolve a decisão muito mais rapidamente do que seria possível de outra fonna .

COMO TOMAR BOAS ÜECISÓES 175

Dados não tomam decisões

,

O pri1neiro conceito errado sobre a infonnação é que ela raramente roma u1na decisão para você. Um bom fragn1enro de informação funciona como u1na lanterna. Ele ajuda a iluminar um espaço e pern1ite que alguén1 pesquisando criteriosamente veja os detalhes e lin1iares que estavam invisíveis anteriormente. Se no mo1nento não existirem dados ou uma pesquisa das reivindicações importantes, investir algun1 tempo na obtenção desses dados pode agilizar o processo de tomada de decisões. A neblina começa a se dissipar e as coisas se tornam claras. Mas os resulrados retornados vão di1ninuindo com o passar do tempo. Depois que o primeiro feixe de luz se acende e os principais detalhes são revelados, nenhum volume de informações poderá mudar a natureza do que foi visto. Se você estiver encalhado no meio do Oceano Pacífico, saber a temperatura atual da água ou conhecer as subespécies de peixes do ambiente não pesará grande coisa em quaisquer das decisões que venha a to1nar (mas conhecer as correntes de água, as rotas co1nerciais e as constelações pode ajudar). Na rnaioria das decisões difíceis, o proble1na não reside na falta de pesquisa ou de dados. Decisões árduas existem no universo independenrernente do volurne de infonnações disponíveis. Penso que o fenôrneno da paralisia da análise, em que as pessoas analisam e discutem de rnodo obsessivo, é sintomático da crença desesperada de que somente se houvesse dados suficientes, a decisão se resolveria por si mesma. É triste perceber que isso não acontece assi1n . As infonnações ajuda1n, mas só até certo ponto.

E fácil interpretar os dados incorretamente

O segundo erro em relação aos dados é que rodos são criados de modo idêntico. Acontece que, ao trabalhar com números, é fácil interpretar incorretamente as informações. Con10 Darrell Huff escreveu em sua obra How to Lie with Statútics (W.W. Norton, 1993), "a linguagem secreta das estatísticas, tão atraente em uma cultura orientada por fàcos, é empregada para gerar sensações, inflar, confundir e simplificar em excesso". Huff classifica os diversos modos simples de manipular os mesmos dados para tornar os argumentos opostos, e dá conselhos que deveriam ser um treinamento padrão para quem coma decisões em rodo lugar. A maioria dos truques envolve a omissão de detalhes importantes ou a seleção exclusiva de informações que respaldam urna reivindicação almejada.

Por exemplo, suponharnos que o anúncio publicitário de uma conhecida bebida energética afirme que essa bebida é "Usada por 5 dentre 6 superestrelas". Impressionante, rnas quais superestrelas estão usando o produto? O que distingue exatarnente urna esrrela de uma superesrrela? Sejam elas quem forem, corno foram escolhidas para a pesquisa? De que modo usarn a bebida - para lavar seus carros? Receberarn seus honorários anrecipadamente ou seriam recusadas na pesquisa se já não usassem a bebida? Quem sabe. O anúncio publicirário cercamente não diria. Se você examinar cuidadosa1nente todos os ripos de dados, da pesquisa 1nédica à análise co1nercia1 e tendências tecnológicas, descobrirá todo o tipo de premissas e advertências surpreendentes inseridas nas entrelinhas, ou sequer n1encionadas. Muitas pesquisas e relarórios de pesquisa são patrocinados basicamenre por pessoas que t.ê1n 1nuito a ganhar com detern1inados resulrados. Pior ainda, em

176 A.ARTE DO GERENC[AMENTO DE PROJETOS

muitos casos, são as revistas e artigos de jornais escritos por pessoas diferences daquelas que realizam as pesquisas que são nosso ponto de contaco co1n a infonnação, e seus objerivos e noção de avaliação acadê1nica geralmente não são tão altos quanto gostaría1nos que fossem.

Pesquisa como uma munição

O úlrimo aspecto a ser vigiado é a munição se passando por pesquisa. Exisre um mundo de diferenças entre tentar entender algo e renrar respaldar uma teoria f;1vorita específica. O que mais acontece é alguém (vamos chamá-lo de João) que tem uma idéia, mas nenhum dado, e procura os dados que se encaixem em sua teoria. Assim que localizar os dados, João retornará para quem ele estiver tentando convencer, dizendo "Olha só! Isso prova que estou certo". Sen1 ter mais quaisquer motivos para duvidar dos dados, a pessoa ern questão cede e João segue ern frente. Infelizmente, a prova de sustentação de João não quer dizer nada. Uma pilha de pesquisas dizendo que a Pepsi é melhor do que a Coca-Cola não significa que não exista outra pilha de pesquisas em outro lugar que prova exacamence o contrário. Para ser usada honestamente, a pesquisa deve buscar evidências para a argurnentação em questão e evidências para contestá-la (rraca-se de uma explicação muito sirnples e parcial do que é freqüenternenre eirado co1110 rnérodo científico). Os bons pesquisadores e cientistas fuzern isso. Geralrnente, os bons anunciantes, profissionais de 1narketing e pessoas tentando vender coisas (inclusive idéias) não.

A 1nelhor defesa contra a manipulação e interpretação incorreta dos dados é a co1nunicação direca entre as pessoas. Converse com a pessoa que redigiu o relatório, en1 vez de cão-somente lê-lo. Sempre que possível, evice as infonnaçóes de segunda, terceira e quarta mãos. Conversar diretamente com o especialista geralmente revela detalhes e pormenores úteis mas inadequados para inclusão em um relatório ou uma apresentação. Em vez de se basear exclusivamente naquele fragn1ento de email enviado, ligue para o programador ou profissional de marketing e obtenha a opinião dele sobre a decisão que você está enfrentando. As pessoas sempre agregam mais valor do que as informações. O redator do relatório aprendeu mil irens que poderiarn ser incluídos mas, agora, deseja compartilhar com alguém que tenha a curiosidade de perguntar.

Além de utilizar pessoas como fontes, uma cultura de perguntar é a melhor 1naneira de entender e rninimizar os riscos da informação. Como foi discutido anteriormente nas questões do design e cornada de decisões, as perguntas conduzem a alcernativas e ajudam a rodas as pessoas a considerarem o que pode estar faltando ou pode estar pressuposto nas inforrnaçóes apresentadas. Questionar cambérn conduz à busca de dados ern diferences fontes, possivelmente de pessoas ou organizações com diferentes agendas ou tendências, o que permite que o tomador da decisão ou o grupo tenha1n uma idéia mais clara do mundo no qual estão tentando cornar decisões.

Precisão não é exatidão

Como un1a última nora a respeito de informação e dados, muitos de nós se esquecetn da diferença enrre precisão e exatidão. Precisão é quão específica uma

CoMo ~roMAR BoAs DEc1sóEs 177

rnedição é; exacidão é quão próxima à realidade uma medição escá. Só porque nos apresencain um número preciso (por exe1nplo, urna esciinaciva operacional de 5.273 dias), isso não significa que exisce un1a probabilidade rnaior de ser exaco do que um núrnero 1nais vago (4 ou 5 dias). Ten1os u1na tendência a confundir precisão com exatidão porque presumimos que, se alguém investiu tempo para calcular um número tão específico, então a análise deve aumentar a probabilidade de que a estimativa está cerca. A armadilha é que a precisão da tapeação é grácis. Se eu chucar uma estimaciva para a receica do próximo ano (US$ 5,5 milhões) e oucra pessoa calcular as despesas do próximo ano (US$ 2,35 milhões), posso combinar os dois resultados e gerar uma projeção de lucros aparenre1nenre convincente: US$ 3, 15 milhões. Preciso? Sim. Exato? Quem sabe? Sem perguntar "Como você sabe disso?" ou "Como esses dados foram gerados?", é impossível ter certeza de que aquelas casas decimais representam exatidão ou apenas precisão. Acostume-se a cortar os maus hábitos de outras pessoas que confi.1ndem os empregos da precisão.

A coragem de decidir

"Todos conhecern o carninho; poucos realmente carninham nele. "

-Boclhidharrna

Há uma grande diferença entre saber a escolha certa e fazer a escolha cerca. Na. maior parte do tempo, as pessoas podem saber qua.I é a decisã.o acertada, mas poucas querem arriscar suas reputações e a si mesmas. Encontraremos sempre mais pessoas criticando e ridicularizando-nos por nossas decisões, do que pessoas dispostas a assumir a responsabilidade e a pressão de tomarem a decisão por si rnesmas. Lembre-se sernpre disso. A to1nada de decisão é um aco de coragern. As melhores decisões do projeto são gera.lmente impopulares, aborrecerão e desapontarão algumas pessoas importantes na equipe e o tornarão um a.Ivo fácil de culpa, se algo der errado.

Esse é o preço cobrado a quem tenta entrar na atividade de liderança. A ton1ada de decisões é um dos atos 1nais centrais executados pelos líderes e gerences, e quanco mais eficiente for o líder, tanto mais coragem será exigida nas decisões comadas (consulce a seção "Confie e1n si rnesmo (autoconfiança)" no Capítulo 12).

Algumas decisões não têm uma opção vencedora

Uma das piores decisões que já con1ei con10 gerente de projetos envolvia o componence barra do Explorer do Incernet Explorer 4.0. A barra do Explorer era uma nova parte da interface do usuário que acrescentava uma faixa vertical no lado esquerdo do navegador, para ajudar os usuários a navegar pelos resultados de pesquisa, em sua lista de favoritos e em um histórico de sites visitados. Faltando algumas semanas para o lançamento da primeira versão bera (versão de reste), tivemos algumas preocupações relacionadas a um problema de design. Detecca1nos o problema durante a.lgum tempo, mas com a pressão do público cada vez maior

178 A.ARTE DO GERENCIAMENTO DE PROJETOS

da conhecida "guerra dos navegadores", começamos a cemer que esse problema calvez nos atingisse, se liberássernos o produto sern corrigi-lo.

O problema era o seguince: era impossível, em casos especiais, exibir a barra do Explorer na 1nesma janela do explorador do sisce1na de arquivos, pennicindo que o usuário criasse um navegador da Web que dividia a cela em três painéis verticais, deixando uma área pequena para a real exibição de páginas da Web. Após conscacar a pressão e o escrutínio do IE 3.0 por parte da indüstria, tememos que os usuários da beca ou os jornalistas descobrissem essa condição, fizemos uma captura de cela do proble1na e libera1nos como parce das respectivas revisões. As revisões do produto eram muito importantes, principalmente nas versões bera. Havia um consenso na equipe e uma pressão por parte da diretoria superior no sentido de que deveríamos tomar uma atitude e fazer alguma coisa.

Preparei rapidamente uma lisra de prós e contras, discuti essa lista com n1eus programadores e com outros gerentes de projeto e identifiquei três opções viáveis. Todas era1n ruins. Para corrigir o proble1na adequadamente, era1n necessários cinco dias de trabalho, coisa que não tínha1nos. Tería1nos que cortar outro recurso importante para que esse funcionasse em ternpo hábil, e isso seria devastador para a qualidade da versão.

Havia uma solução paliativa, exigindo dois dias de trabalho, que extirpava alguns dos casos que causavam essa condição, mas era u1n trabalho a ser descartado posteriormente (o trabalho era suficienre1nente bom para u1na versão beta, 1nas não para u1na versão final) . A ültin1a opção era não fuzer nada e apostar que ningué111 descobriria o proble1na. Procurei desesperada1nence outras alcernacivas, mas não encontrei. Toda idéia sugerida pelas pessoas nos fàzia voltar a essas crês opções. Lembro-n1e de ficar sentado em nlinha sala até bem carde da noite, com o olhar fixo e1n meu quadro branco e dando volcas no que eu deveria fàzer.

Todo gerente de projetos pode concar histórias de escolhas difíceis que tiveram de tomar. Se você tem responsabilidade, elas fazen1 parte de seu território. Podem abranger decisões de orçamento, contratação, demissão, negócios comerciais, tecnologia, controvérsias, negociações, design, estratégia comercial e tudo o mais. Diante de u1na decisão difícil, não há uma resposta certa isolada. Na realidade, é bem possível que algo aconteça para que nenhuma das opções disponíveis (ou todas elas) dê certo. A despei to do grau de pesquisa e exame minucioso, uma tomada de decisões é outro ato de previsão. Em algum nível, a decisão árdua rennina exigindo o bom senso e a coragem do gerente de projeto -e a coragem da equipe - ern seguida.

Nessa sicuação específica do IE4, preferi não fàzer nada. Depois de uma noite sem dormir, decidi que seria melhor gerenciar as pressões se e quando ocorressem (o que consumiria meu tempo, não o de meus programadores), c1n vez de investir em uma prevenção contra algo que ainda não tinha acontecido. Eu não estava satisfeito com isso, 1nas senti que era a n1elhor escolha para o projeto. A equipe cinha concordado previamente que eu deveria tomar a decisão, de 1nodo que seguimos e1n frcnre.7

Boas decisões podem dar maus resultados

Nossa retrospectiva dos ülcin1os acontecin1encos foi injusta para vários bons tomadores de decisão. Só porque as coisas não funcionaram de determinada

COMO ~TOMAR BOAS ÕECISÓES 179

rnaneira, isso não significa que eles não fizeram urna boa escolha diante das infonnações disponíveis. É i1npossível cobrir rodas as concingências e considerar rodas as possibilidades ao lidar co1n decisões co1nplexas ou difíceis (ernbora algumas pessoas tencem). Quanto mais ternpo você gastar tentando cobrir rodas as contingências (um hábi to comum dos microgerentes), tanto n1enos tempo terá para investir nos prováveis resultados. De pouco vale se preocupar com o faro de ser atingido por um raio, se você tem utn problen1a cardíaco, alimenta-se mal e acha que digitar rapidamente é uma n1odalidade de exercício.

Só porque uma parte de um projeto fo.lha, não quer dizer necessariamente que uma decisão ruim fo i cornada. É comum acontecerem coisas fora do , controle do gerente de projeto, da equipe ou da organização. E impossível prever muitas ocorrências ou, mesmo se previstas, é impossível responsabilizar alguén1 por elas. É injusto responsabi lizar os tomadores de decisões por ocorrências que, provavelrnente, não eram do conhecimento deles ou sequer fizerarn algo a respeito. Encrecanco, em rnuitas organizações, é exatarnente isso que acontece. Se uma equipe perde por pouco, a opinião p{1blica tende a desprezar o rrabaJho árduo e o esforço heróico dos jogadores que fizeram essa equipe perdedora chegar até aí. É necessário lidar com a culpa com cuidado, no que diz respeito à cornada de decisão. Os corajosos tomadores de decisões cendern a fracassar visivelrnenre muito rnais do que que1n sempre faz escolhas seguras e cautelosas. Para que os tomadores de decisão sejarn arrojados, deve haver algun1 tipo de apoio para que eles arrisquem alto, e para ajudá-los a se recuperarem quando fracassare1n.

Cercamente, os gerentes de projeto são responsáveis pelo destino do projeto. Não estou dizendo que eles deve1n levar palinadas por ímplodir uma equipe. Quero dizer apenas que se deve tomar cuidado para não culpar urn GP por ter tomado un1a boa decisão que terminou dando um mau resultado. Se sua lógica e seu processo n1ental eram adequados antes de tomar a decisão, então ao olhar para trás, essa lógica e processo 1nencal ainda são corretos depois de ton1ar a decisão. O estado do mundo no momento de uma decisão não muda posteriormente, só porque sabemos mais agora do que naquela época. Se existir algo que o GP e a equipe desconheciam, ou não podiam ver, apesar de todo o seu e1npenho ern tentar conhecer e ver esses detalhes, eles não devem ser ridicularizados por causa disso. Em vez disso, a equipe deve descobrir corno rodos juntos devern obter os dados e as infonnações que desconheciam, e aplicar esse conhecimento às próximas decisões a sere1n tomadas.

Prestar atenção e olhar para trás

Para melhorar as habilidades de to1nada de decisão, duas coisas precisam acontecer. Prirneíro, você precisa tomar decisões desafiadoras e que o obriguem a trabalhar arduamente. Se você nunca coma decisões que considera difíceis e se raramente está errado, est~í na hora de pedir a seu chefe rnais responsabilidade. Segundo, você deve prestar atenção aos resultados de suas decisões e avaliar, corn a colaboração dos outros participantes, se podia ter feito algo diferente para melhorar a qualidade desses resultados. A experiência só beneficia aqueles que consegue1n aprender corn o que acontece.

180 A ARTE DO G ERENC[AMENTO DE PROJETOS

No creinarnenco e nas verdadeiras missões, os pilocos de aviões de cornbace se re(1nem em sessões de debriefing para exaininar o que aconceceu. Essas sessões são conduzidas pela equipe superior e experiente. O cerna central é que a única mai1eira de desenvolver e conhecer algo tão co1nplexo quanto ser um piloto de aviões de combate é revisar as missões, discutir con1 todos os envolvidos o que aconteceu e por que aconteceu, e descobrir se existe algum outro modo de n1elhorar o resultado final. Essas reuniões geralmente abrangen1 análise de estratégias e táticas, e un1a troca de idéias e opiniões para obter alcernativas para lidar com a mesma situação.

A comunidade médica desenvolve algo semelhante, deno1ninado M&M ou sessões de morbidez e mortalidade (jocosamente citado como D&D - death and doughnuts*), mesmo que essas sessões sejam realizadas somente em casos furais ou quando ocorre algo particula.rmente novo ou complexo.

Em ambos os casos, fica a critério dos líderes da sessão evitar tornar a sessão um julgamento ou fazer com que as pessoas se sintam constrangidas por seus erros. O objetivo é fazer corn que se sintam suficiencemente seguras em relação ao que aconteceu, a ponto de desejarem investir te1npo para revisar e reavaliar o ocorrido, para aprender algurna coisa, e dar aos outros na organização uma oportunidade de se beneficiar corn os custos do que tiver acontecido.

Veja a seguir minha [isca de perguntas para examinar as decisões. Quando sou convidado a ajudar equipes a avaliarem o crabalho anterior, esca é a estrutura de to1nada de decisões co1n a qual inicio. Ela funciona melhor com uma atividade en1 grupo (porque você vai tirar proveito das diferentes perspectivas), 1nas ta1nbém funciona para examinar seu próprio raciocínio.

• A decisão solucionou o problema principal? Isso deve ser parte do próprio processo de con1ada de decisões. Mesn10 que você renha feiro a opção correra, a diferença geralmente recai sobre a eficiência co1n que a equipe executa a decisão. Duas horas, u1n dia, dois dias após uma decisão, o tomador da decisão deve verificar e assegurar-se de que a decisão não esteja emperrada e que esteja sendo executada corretamente. Exatamente nessas primeiras horas ou dias é que, muito provavelmente, surgirão os problemas imprevistos, que podem exigir u1na reconsideração da decisão. lsso ocorre naturalmente e deve ser esperado.

• Existia alguma lógica ou informação melhor que pudesse ter sido usada para fazer uma triagen1 das opções mais rapidamente? Onde se investiu te1npo ao tomar a decisão? Havia alguma infonnação ou sugestão para agilizar o processo de localização e exploração de alternativas? Quais ferramentas de pesquisa foratn usadas? Alguém foi à biblioteca? À livraria? Pesquisou na Web? Ligou para u1n consultor ou especialista? Por que essas fontes não foram usadas?

• A visão, especificação ou reqtúsicos ajudararn na tomada da decisão? As boas decisões no nível de projeto e as prioridades devem contribuir para as decisões de nível inferior muito rnais do que se in1agina. É exatamenre por isso que elas existem. Essa decisão revelou algum ponto fraco ou omissão na visão? A visão/ especificação/requisito forain atualizados depois da decisão, de modo a detectar e eliminar a omissão?

• A decisão colaborou para o avanço do projeto? Às vezes, tomar uma decisão ruim também faz o projeto avançar. Uma decisão catalisa pessoas. Ao tomar

•N. de T.: Escudos post-r11orte111 ou cadáveres e cafezinho.

CoMo ~roMAR BoAs DEc1sóEs 181

uma decisão rápida para ir para o leste, e ao mudar de perspectiva, pode ficar óbvio que a direção cerra é realinente o norce. Mas ances d e a equipe começar a se 1nover para o leste, nunca conseguirão descobrir isso. Fazendo tuna retrospectiva, esclareça por que a decisão inicial foi bem-sucedida: foi por que você fez a opção cerra ou por que você tomou a decisão na hora certa?

• As pessoas-chave participaram no processo e respaldaram a decisão? Havia alguém cujo apoio ou experiência era necessário, que não tenha se envolvido? Você renrou entrar em conraro com essas pessoas e não conseguiu ou sequer tentou? Havia algum 1nodo 1nais eficiente do que o que foi feito para trazê-las? (Você deve obter a opinião dessas pessoas sobre isso, se quiser ter uma perspectiva honesta.)

• A decisão evitou ou acarretou outros problen1as? A questão imediata podia ter sido solucionada, 1nas existia1n ourros problemas acarretados? O 1noral caiu? U1na empresa parceira ou equipe foi prejudicada com a decisão? Quais foram os efeitos colaterais negativos da decisão; eles poderiam ter sido evitados? Foram previstos ou foram uma surpresa?

• Na retrospectiva, ao tomar a decisão, você estava preocupado com as coisas certas? A pressão e a paranóia podem distorcer a perspectiva de alguén1 sobre quais problemas exige1n atenção. Ao fazer uma retrospectiva, você deve vislumbrar as coisas cuja importância foi deturpada por você ou por ourras pessoas, e questionar consigo mesmo como isso aconteceu. A opinião e influência de quem contribuíram para essa distorção? Quen1 tentou minimizá­la mas foi ignorado?

• Você tinha autoridade suficiente para fazer a escolha certa? Talvez você tivesse urna idéia digna de ser explorada, mas desistiu dela por motivos políticos. Ou talvez você passe mais tempo baralhando para ter controle de problemas que, na sua opinião, deveriam estar sob seus cuidados desde o início. Analise como o poder teve seu papel na decisão e como as mudanças na distribuição do poder podem ter alterado o rumo das coisas.

• Como é possível aplicar em outro lugar no projeto o que foi aprendido ao tomar essa decisão? Não restrinja as lições aprendidas à especificidade da decisão. Examine a próxi1na leva de decisões no projeto (próxi1na data ou carefà importante) e aplique essas lições. Use a nova perspectiva e vislumbre o futuro, não apenas o passado. Len1bre-se do que Burn1ese dizia: "O hon1em reine o últi1no t igre que o mordeu e não o próximo tigre a mordê-lo".

Resumo

• Existe uma experiência importante na rneta tomada de decisões (n1eta-decision making) ou nas decisões sobre e1n quais decisões deve-se investir tempo.

• Dimensione as decisões antes de investir 1nuito tempo nelas.

• Procure a zona de indiferença e as oportunidades de uso efetivo de uma avaliação singular.

• Use a avaliação comparativa para as decisões que exijam mais investimento.

• Todas as decisões cê1n componentes emocionais, quer reconheçamos isso ou não.

182 A ARTE DO G ERENCIAMENTO DE PROJ E:TOS

• As liscas de prós e concras são o mécodo rnais flexível para uma avaliação co1nparaciva. Elas faci1ica1n a parcicipação dos oucros e propiciam perspeccivas adicionais sobre as decisões.

• Informações e dados não cornatn decisões por você.

• Para melhorar a cornada de decisões, exan1ine as decisões anceriores e explore-as como lições e oportunidades para rácicas mais eficientes.

Capítulo 9

Comunicação e relacionamentos

184 A ARTE DO GERENC[AMENTO DE PROJETOS

U1na das primeiras histórias de engenharia do Ociden te é a da Torre de Babel, do Gênesis, e e1n seu reor há uma lição sobre con1unicação. No decorrer da hisrória, a humanidade esrava alegremenre reunida no deserro. Logo descobriram como fazer tijolos e argan1assa. Tudo estava indo 1nuico be1n e, sen1 qualquer n1otivo específico, decidiram construir unia corre muito alta até o céu. As coisas caminhavam de n1odo brilhante até que, repentinamente, os operários perderam sua habilidade de usar o mesmo idioma (você diria que foi "intervenção divina"?). Nesse momento rudo, literalmente, se desfez. As pessoas antes unidas foran1 espalhadas pelo mundo (1nais intervenção divina) e diferentes idiomas e sociedades se formaram. A história sugere que se eles continuassem se comunicando bem uns com os outros, nada reria sido impossível (o que talvez, como a história também sugere, renha motivado a intervenção divina).

A passagem bíblica é muito curta: não chega a ocupar uma página inteira. Contudo, no decorrer dos séculos, chamou a acenção de vários arriscas e escritores que usavam a história para examinar questões contemporâneas. As i1nagens vívidas da torre pinrada por BruegheJI e por outros concederam à história uma importância cada vez maior às rarefàs de engenharia e gerenciamento de projetos daquela época. As interpretações da história mudaram de uma era para a ourra, assim como as ilustrações da real aparência da rorre, mas os remas gerais são os 1nesmos. Alguns acrediram que a história é um aviso sobre a arrogância da hun1anidade e um lembrete de que algu1nas coisas são inatingíveis. Outros a inrerpretam como uma história de pessoas se esforçando para alcançar cudo o que pode1n, cruzando os li1nites do possível. Para 1ni1n, e para o be1n deste capículo, a lição 1nais imporranre da Torre de Babel é simples: se você não consegue se . ~ , co1nun1car, nao cera sucesso.

Em grande parte da história da civilização, a lenridão da comunicação causou problemas. Mesmo cão tardiamente quanto na Guerra Civil Americana (1861-1865), não havia rádios, telégrafos ou sistemas de sinais (bandeiras) de uso consagrado. Os generais enviavam mensagens por meio de cavaleiros, para coordenar as inforn1ações da batalha com os comandantes lotados nos diversos campos (o que, dependendo da distância, levava horas ou dias, presumindo-se que o mensageiro não se perdesse). Conseqüentemente, as decisões era1n tomadas freqüentemente com antecedência, sem qualquer modo efetivo de retirar ou alterar as atribuições dos ataques. Muitos desastres e interpretações incorretas da linha de frente resultaram dessas limitações. (Imagine um cornandance de campo de baralha que acabou de mandar o cornereiro dar o roque de araque, direcionando rodas as tropas para atacar, quando um mensageiro exausto tropeça dentro de sua barraca. Ainda cencando respirar, o rnensageiro diz: "Despacho do cornando .... 'Prezado co1nandance. Os reforços corn os quais contava foram enviados para algum outro lugar. Larnenramos. Boa sorte.'" Não surpreende que geralmente os mensageiros fosse1n mortos.)

Hoje en1 dia, a co1nunicação é cão irnporranre quanto em épocas passadas. Mas dois aspectos mudaram. Primeiro, a velocidade não é mais um problema básico (como ser 111ais rápido que as mensagens instantâneas?). E1n substituição, o problen1a passou a ser a qualidade e a eficácia da comunicação. Em segundo lugar, para um trabalho tão complexo e interdependente quanto o desenvolviinento de software, não basta apenas a comunicação: devem existir relações efetivas e saudáveis entre as pessoas que trabalhan1 e1n conjunto. Tantas

CO!vlUNIC AÇÁO E R ELAC IONA..'v1ENTOS 185

decisões são comparcilhadas e canto crabalho é realizado no modo colaborativo, que se1n bons relacionamencos, nenhuma co1nunicação exrra cerá irnporcância. Diferente1nente da estrurura de cornando milicar de u1na força armada, a maioria das equipes de so_ftware depende da interaç,'io ponco-a-ponto e de outros relacionamentos com uma orientação menos hierárquica. Embora, em geraJ, existam lideres claramente definidos, que ocasionaln1ente dão ordens, os projetos dependem nluito da possibilidade da equipe de fuzer uso do conhecin1enco de todos, de con1parrilhar idéias e de trabalhar em sincronia (e1n vez de contar co1n linhas esrricas de autoridade, disciplina rigorosa e a compulsão de obedecer ordens se1n questionar).

Por passarem muito tempo se comunicando com as pessoas e os grupos, os gerentes de projeto têm inevitavelmence mais responsabilidade pela comunicação efetiva do que outras pessoas na equipe. Os bons gerentes de projeto oferecem canais estáveis de boa comunicação e relações saudáveis, amplificando a eficácia de todas as pessoas com as quais entrd1n em conta.to. Se é a integridade da rede social de um tirne que o impede de se tornar outra Torre de Babel, então o gerente de projeto é quern tern a fi.rnção rnais natural ao constituir e rnanter essa rede.

Para isso, não é necess<írio ter u1na personalidade extrovertida de apresentador de concursos, nern um senso de hu1nor briU1ance ou poderes 1nágicos (se be1n que esses úlrimos possam ajudar) . Em vez disso, deve-se co1neçar por admitir que a comunicação e as relações são críticas para o sucesso e que há espaço para o aperfeiçoamento de si rnes1no e de sua equipe. Se você reconhecer que isso é irnportante, há de querer saber onde ocorre a maioria dos problernas de comunicação e aprender a lidar com eles.

Gerenciar conversando

Pode parecer estranho, n1as demorei rnuito tempo para perceber a importância de conversar co1n as pessoas no ambiente de trabalho. Eu batia papo e fazia brincadeiras, mas nunca confundia socialização no trabalho con1 a sua real execução. Minha educação e experiência na faculdade nle fizeram crer que eu deveria solucionar os problemas por conta própria em meu trabalho. Em meu prirneiro ano na Microsoft, raramente eu pedia a opinião dos outros ou procurava alguém que tivesse mais conhecimento do que eu e reutilizava as inl·ormações. Em vez disso, eu esmiuçava tudo sozinho, trabalhava arduamente e não exatamente de modo inteligente. Ao mesmo tempo, eu observava dois de meus primeiros gerentes, Ken Dye e Joe Belfiore, exibirem o curioso comporcamenco de investir 1nuito tempo conversando com as outras pessoas. Eu os encontrava sentados nas salas de várias outras pessoas, batendo longos papos. Ocupado corno eu era, não podia ajudar e ficava me perguntando corno eles podiarn dispor de tanto tempo para "o social". Por ser novaco, eu não perguntava direca1nence a eles. E1n vez disso, eu simples1nence os rotulava de "excrovertidos", o que na época, por causa de n1inha experiência, era considerado urn ripo de insulco 1nenos conscrangedor. A conduca deles 1ne inco1nodava (eles não deveriarn esrar crabalhando pelo rnenos com tanto afinco quanto eu?), e eu não dava a mínirna importância ao que faziam. Como eu escava errado.

Co1n o aumento das 1ninhas responsabilidades, lentamente entendi o que Ke11 e Joe escava1n fazendo. Na base da tentativa e erro, aprendi que maltratar, ciranizar, n1andar ou exigir não era tuna tática eficiente quando eu precisava de

186 A ARTE DO G ERENCIAMENTO DE PROJETOS

coisas das pessoas que não erarn obrigadas a rne ouvir. Constatei resultados se1nelhantes e1n progra1nadores ou testadores não-comunicativos, e a sua f.'llta de eficiência para finalizar os trabalhos relacionados a outro pessoal técnico. (Esse aspecto é destacado na Figura 9-1 . A implicação é que todos poden1 se beneficiar com melhores habilidades de comunicação e relacionamento, independentemente de quão isolado seu trabalho supostamente é.)

Como os desenvolvedores investem seu tempo

Tipo de atividade Porcentagem

Trabalhando sozinho 30%

Trabalhando com outra pessoa 50%

Trabalhando com duas ou mais pessoas 70%

Levantamento da Peopleware, DeMarco e Us/er (Dorset House, 1997), resumo do levantamento feito por Gera/d McCue (IBM, 1978)

FIGURA 9-1. Há evidências de que os programadores não são tão solitários quanto imaginamos.

Descobri que quanro rnais eu exigisse ou presumisse coisas das pessoas ("Você deve codificar isso desse modo, ok?"), menos eu obtinha o melhor de seu trabalho. Mesmo que fizesse1n o que eu pedia, algo em 1ninha abordagem matava uma parte de sua motivação ou 1ninimizava a probabilidade de que agregassem valor alén1 do que eu havia solicitado. Porém, percebi que quando eu conversava com elas ("Oi, acho que preciso fazer isso e que você é a pessoa certa para esse trabalho. O que você acha?"), e1n vez de dar ordens, eu recebia. o que precisava mais rapidamente do que quando aplicava. as outras táticas. E como recompensa, aumentavam as chances de que elas sugerissem bons aprimoramentos para minhas idéias. Aprendi que os diálogos funcionam melhor do que os monólogos.

As relações melhoram a comunicação

Apesar de quão óbvia seja a necessidade de ter-se urn relaciona1nento positivo com alguém para 1nanter um bo1n diálogo, rararnence as pessoas tira1n proveito de suas habilidades nessa iniciativa. Aqueles bate-papos e conversas infonnais nos quais Ken e Joe investiam tempo não era uma 1naneira de matar o tempo, mas, si1n, invescin1entos en1 pessoas e inforrnações, que propiciava1n a Ken e Joe un1 conhecimento e uma reflexão sobre o que estava acontecendo, que pouquíssin1as pessoas tinhan1 na organização. Especifican1ente no n1eu caso: quando Ken e Joe precisavam de um conselho, opinião ou solicitar uma tarefa, podiam conversar co1n praticamente todos na equipe, e partir de u1n ponto saudável e positivo em vez do zero. O relacionamento deles com a equipe agilizava sua habilidade ern se cornunicar com todos.

Isso fucilitava ir direto ao assunto sem ser rude ou até fuzer solicitações adicionais a pessoas que, normalmente, as recusariam. Em questões de opinião, eles tinham construído uma confiança suficiente para receber opiniões honestas das pessoas certas, de modo casual, e se fosse necessário, eles podiam incorporar as

Co1111uNrc Aç Ão E RELAC 10NAMENTos 187

sugescões e idéias ao seu raciocínio muito antes das discussões maiores. Em resumo, acravés de diálogos e relacionamentos inforrnais, Ken e Joe escava1n à frenre do restante da equipe. Eles sabiam mais sobre o que escava funcionando ou não, e tinhan1 mais influência sobre isso, porque invesria1n nas relações. Eles alicerçaram o ca1ninho para rodos os tipos de suporte e benefícios adicionais, simplesmente conversando e ouvindo as pessoas.

Na obra clássica de Tom Peters e Nancy Austin, A Passion for Excellence (Warner Business Books, 1985), esse tipo de conduca é chan1ado de MBWA (Management by Walking Around}. Esse con1porta1nento é descrito como tuna qualidade central nos gerentes bem-sucedidos que observaram (há um capítulo inteiro do livro dedicado a esse assunto). Mas não é Fácil Fazer essa perambulação com eficiência. Os aurores recomendam explicitamente escolher um pequeno número de pessoas, em diferentes níveis e fi1nções na equipe, e investir tempo construindo esse tipo de relacionamento in~ormal com essas pessoas. 2 Mais importante ainda, essa habilidade exige um conheci1nento de como funcionam a comunicação e os relacionamentos saud1íveis e um comprometimento em expandir essas habilidades. Mesmo que você não opte por usar u1na abordagem MBWA para forrnar relações, as habilidades básicas de co1nunicação e interpessoais a inda serão fundaJnenrais em tudo o que você fizer.

Um modelo básico de comunicação

Independenrernenre do quanto nos comunican1os corn as pessoas, raranlente retrocedernos e aJ1alisainos 1ninuciosatnente o que está realmente acontecendo. Como a 1naioria de nós nunca aprendeu ou foi creinada a entender o que ocorre quando as pessoas se comunica1n, não surpreende que enfrentemos problemas freqüentemente. Poucas pessoas no ambiente de trabalho têm qualquer competência real no diagnóstico de problen1as de comunicação ou relacionamentos, ou tem a necessária autoridade para identificá-los. Contudo, é fãcil aprender uma esrrun1ra simples para as meras de comunicação - sob uma perspectiva de gerenciamento de projetos - e aplicá-la às situações cotidianas. Con1 esse conheci1nenro, é possível decompor onde as coisas estão falhando e tornar-se capaz de resolver problemas, porque você entenderá melhor o que não esrá fi1ncionando.

'.11 boa cornunicação fandamenta-se na conscientização e diferenciação dos indivíduos altamente desenvolvidos. Um born comunicador reconhece os . . ,,

processos internos ern st mesmos e os processos exte1·nos nos outros.

- John Bradsha\v

Na estrucura 1nais si1nples que conheço, há cinco estados básicos (descritos sucintamente) em que qualquer aro de comunicaÇ<'lo pode estar.3 Cada um deles é progressivamente 1nais importante e mais difícil de atingir do que o estado anterior. A co1nunicação só será be1n-sucedida se alcu1çar o terceiro estado (compreensão), ou o quarco (aceicação) ou o quinco (ação). Para ajudar a iluscrar cada estado, usarei um exemplo do filn1e 2001: Uma Odisséia do Espaço. Dave, um astronauta, encontra-se

*N. de ·r.: Gerencian1enco por observação.

188 A ARTE DO G ERENC[AMENTO DE PROJETOS

ern uma pequena espaçonave e deseja retornar à nave-mãe. Hal, dentro da nave-mãe, é a única enridade capaz de abrir as porcas para deixá-lo encrar.

l . Transmitido. Ao enviar um email ou deixar urna 1nensage1n de voz, você está transmitindo um fragmento de informação para alguém. Isso não significa que a pessoa tenha lido ou ouvido, mas, sim, que a mensage1n saiu de suas n1ãos com o objetivo de chegar às mãos dela. Com o email e a Web, é muito fácil transmitir informações, mas não há garantias de que qualquer pessoa leia essas informações. Exemplo: D ave diz "Hal, abra a porta, por favor." (Dave ouve apenas o silêncio como resposta.)

2. Recebido. Quando alguém verifica seu email ou assina o cornprovante de recebimento de um envelope da FedEx, a mensagem foi recebida. Contudo, o recebimento não significa que a mensagem foi aberra ou que o destinatário cem qualquer intenção de lê-la ou tentar adivinhá-la. Ernbora os recebimentos lidos ern email realmente indiquem que a mensagem foi aberra, nada mais é confirmado. Exernplo: Hal responde, "Olá, Dave". (A transmissão é recebida.)

3. Compreendido. Digerir e interpretar correramenre a informação de uma mensagem é um grande salto en1 rennos de esforço, e1n relação ao simples recebimento de un1a nlensagem. A real atividade cognitiva deve ocorrer para que algo seja encendido ("O que isso significa?"), ao passo que recebê-la não exige essa mesma acividade ("Oi, recebi un1 emai~"). Dependendo do problema em questão, encender uma 1nensage1n pode abranger aprender um novo conceito, consultar referências ou examinar um fragmento de código complexo. Geralmente, para entender algo, o destinatário precisa fazer perguntas para esclarecer aspectos ambíguos sobre a 1nensagem original. Fazer perguntas requer uma comunicação totalmente bidirecional, o que é mais absorvence para an1bas as partes. (Isso complica a estrucura simples de cinco estágios, criando urna árvore de comunicações aninhadas simultâneas, à medida que cada pergunta e cada resposta inicia a própria seqüência de transmissão, recepção, co1npreensão etc.)

4. Aceito. Entender algo não significa que alguém o aceite. Posso entender totalmente cada aspecto de uma solicitação emitida por u1n executivo, um dia ances da liberação final, para fàzer uma porte do Linux a partir de nosso programa de edição de vídeo somence para Mac, mas isso não respalda o quanro acho essa idéia uma loucura. Alcançar uma anuência entre duas pessoas inreligenres e co111 opiniões próprias pode ser uma atividade corn plexa e den1orada, principaln1enre se as objeções não esciverem claramente declaradas. Por 1nais difícil que seja, a anuência é a base da tornada de decisões que afecam uma equipe.4 Exe111plo: "Desculpe, Dave, mas cerno que não possa fazer isso". (1-Ial encende o que Dave quer, mas não concorda nem dá explicações.)

5. Convertido em ação útil. A despeito de quanca energia será necessária para enrender algo correra1nenre e ralvez aringir um nível de aceiração, rambém será exigida muito mais energia para que alguém faça alguma coisa com isso. Mes1no que a inensagem requisite explicitamente uma ação do receptor, en1 geral, isso não é uina obrigação severa. Talvez o receptor concorde em atender à solicitaçã.o na semana ou no mês seguinte (quando você precisa da ação tomada nos l O minutos seguintes) . E calvez, na pior das hipóteses, é bem

Co1v1UNICAÇÁO E R ELACIONA..'v1ENTOS 189

possível gue u1na ação seja romada, mas seja a ação errada, ou seja u1na ação co1n a qual o re1nerenre da 1nensage1n não concorda.

Os bons comunicadores rransmirem informações para serem enrendidas. Em vez de rão-somenre enviar um email e esperar o resultado, eles questionam a té onde podem ir no modelo de cinco etapas para serem eficientes, construindo a comunicação para torná-la possível. Usan1 a linguagem e exemplos que farão sentido para o destinatário da mensagem, en1 vez de usar apenas o que lhes é convenienre. Alé1n disso, eles esclarecem na mensagem os prováveis pontos de argumentação e idenrifica1n a ação que esperam do destinatário como resposta.

Sendo assim, sempre que você recebe ou envia um email, ou dá uma parada na sala de alguém para perguntar alguma coisa, ocorre um avanço natural da comunica.ção em andamento. Use essa estrutura para ajudá-lo a diagnosticar por que o que você deseja que aconteça não está. ocorrendo. A boa comunicaçã.o se realiza guando há u1na seqüência natural e satisfatória de intercfunbios entre duas pessoas, para atravessar cada u1n desses estágios. Mesmo quando as coisas não dão certo, conhecer uma estrutura co1no esra ajuda a identificar onde a comunicação esrá sendo interrompida.

Problemas comuns da comunicação

I-Iá diversos n1otivos pelos quais a con1unicação cessa. Todo gerente de projeto deve esrar fa1niliarizado co1n esses motivos para identificá-los nos ourros e no próprio co1nporramento, e para esforçar-se em solucioná-los sempre que ocorrerem. E1n várias equipes, esses comportamentos se 1nanifestam porque o gerente do grupo os apresenta em si mesmo ou rolera-os nos outros. Até que algué1n con1 autoridade entre em cena, identifique o problema como um problen1a de comunicação, e assuma pelo menos un1a responsabilidade parcial pela sua identificação, esses maus hábitos de comunicação persistirão.

A lista curta a seguir engloba vários problemas comuns de comunicação, descreve sucintamente por que ocorre111 e oferece a lgu111as sugestões simples para evitar ou para se recuperar a partir deles.

• H ipótese. Ao entrar na sala de alguém e perguntar por que essa pessoa ainda não enviou aquele e1nail tão importante, você está presumindo que: a) a pessoa sabia que deveria enviar; b) a pessoa sabia quando deveria enviar; c) a pessoa sabia o seu conteúdo; d) a pessoa deveria informar a você, de alguma 1naneira, ao fuzê-lo. Antes de gritar con1 a pessoa (va111os cha111á-lo de Samuel) ou de culpá-lo, a boa comunicação engloba o esclarecimento dessas pressuposições. "Sa111uel, você já enviou aquele ernaiP." Sainuel responde: "Que emaiP." "Sai11uel, le1nbra-se de que ontem conversa1nos no corredor e você confinnou que poderia fazê-lo?" "Ah, sim, enviei há uns 1ninutos auás." Os bons co1nunicadores nonna11nenre esclarecem as pressuposições durance as discussões em poncos-chave, como ao finnar compron1issos e ao confirmá-los nova1nente antes do prazo li111ite.

• Falta de clareza. Não existe uma lei no universo exigindo que outras pessoas entendam o que você está dizendo, simplesmente porque você já sabe. Independentemente da sua eloqüência, se a outra pessoa não entendê-lo, você não é suficienremence eloqüente para a situação em questão (como dizia Red

190 A.ÁRTE DO GERENCIAMENTO DE PROJETOS

Auerbach, "não é o que você diz, é o que eles ouvem"). A solução natural é retroceder, di1ninuir o ritmo e separar as idéias e1n partes cada vez menores até alcançar u1n ponto de clareza, e depois re1nontar lenta1nente a partir desse ponto. Descubra un1a história ou analogia para proporcionar uma estrutura inicial que as pessoas possam aco1npanhar, e acrescente detalhes nessa estrutura até que você não precise mais da analogia.

• Não ouvir. No filme Fight Club (Clube da Luta), o personagem principal, Jack, diz (en1 relação a um dos vários grupos de apoio ao qual ele se filiara recentemente) que "eles realmente me ouve1n, en1 vez de apenas esperar pela próxi111a oportunidade de conversar". So1nos compulsiva1nente maus ouvintes e temos uma tendência a preferir o som de nossas vozes ao das outras pessoas. Pior ainda, até mesmo enquanto as pessoas estão falando conosco, geralmente só estamos calculando nossa próxima resposta - continuando a defender nossa linha original de argumentação - e1n vez de realmente ouvir a opinião delas. (A forma extrema desse problema é simplesmente não presrar atenção, como ao ler o email quando algué1n está conversando com você. A despeito das duvidosas argu1nentações sobre a proficiência em 1nulticarefus, isso ainda transmite u1na 1nensagem negativa para a pessoa que está fulando: "você não 1nerece um contato ocular".) A solução é aceitar sempre a possibilidade de que as outras pessoas sabem algo importante que você desconhece. Seu objetivo é não forçá-las a tomar u1na posição, 1nas, si1n, alcançar o melhor resultado possível para o projeto.

• Ditar. O irmão gêmeo diabólico de não ouvir é dar ordens. Em vez de dar até mesmo a impressão de ouvir, as pessoas que ditam simplesmenre dão ordens. Quaisquer objeções ou dúvidas quanto à ordem são recusadas ou respondidas com decepção ou escárnio, como se fosse totalmente óbvio por que a ordem é o que é e por que está sendo dada sen1 explicação ("O que você é, idiota?"). Isso não é um ato de comunicação porque é uma violação rotai da estrutura abordada anteriormente: nã.o houve qualquer tentativa de alcançar o entendi1nento, muito menos a concordância. Dar ordens tem o seu lugar, mas deve ser a exceção. Em substituição, procure tornar decisões em um ambiente em que as pessoas têm o direito de Fazer boas perguntas e propor desafios à sua lógica.

• Disparidade de problemas. A comunicação pode mascarar vários outros proble1nas. So1nente quando nos co1nu11icainos co1n alguém, esse alguérn cem a oportunidade de externar seus sentimentos em relação a outros problemas. A resposta a uma solicitação pode ser urna expressão de sentimentos que não cem nada a ver com a solicicaç.'io ern questão ("Oi, você pode ler esta especificação?", "Não! Nunca! Prefiro a morte!"). Pode haver u1n problen1a não resolvido relacionado a outra decisão, cujos sentimentos a pessoa ainda não revelou. Se nenhuma das partes reconhecer a existência de diversos problernas ern discussão, sob o disfurce de um único problema, a discussão será frusrranre e de diflcil solução. Alguém precisará separá-los: "Espera aí, sobre o que esta1nos realrnente conversando aqui? Como codificar este recurso ou por que você não conseguiu aquela promoção almejada?".

• Ataques pessoais/ad horninem. As situações geralmente parrem para o campo pessoal quando uma das partes desvia a discussão do problema para um indivíduo. Isso é chamado de ad hominem (contra a pessoa). Por exemplo, Fred poderia dizer que não tem tempo, ao que Samuel responderá "Esse é o seu problema. Como você nunca tem tempo de revisar os planos dos testes?". Isso é injusto para Fred porque ele tern que defender não son1ente sua opinião, como

Co1v1UNIC AÇÁO E R ELAC IONA..'v1ENTOS 191

também sua conduta pessoal. Ataques pessoais são golpes baixos e há várias formas diferentes desses golpes.5 Geral1nente, a pessoa que leva o golpe se senre vulnerável e inrerprera o araque como a única maneira de vencer a argun1enraç,'io. Uma pessoa 1nais an1adurecida (ou ralvez o próprio Fred) poderia interferir e separar as questões.

• Zombar, ridic ularizar e culpar. Quando uma pessoa rem un1a nova idéia, ela se torna vulnerável com quem quer que ela escolha para partilhar essa idéia. É necessário um sentimento de confiança para se chegar junto e ser honesto. Se a pessoa é constantemenre ridicularizada e humilhada no processo de comunicar uma inforinação importante mas desagradável, ela não fàrá mais isso. A primeira resposra a u1n problema não deve ser "Como você deixou isso acontecer?" ou "Você sabe que isso aconteceu por sua culpa, não sabe?"

Existem outros problemas na comunicação, mas essa lista básica abrange várias siruações possíveis. Ocasionalmente, as siruações vêm à rona em conversas enrre duas pessoas sozinhas e1n uma sala, e outras vezes, várias pessoas estão presenres. Quanto rnaior o nú1nero de pessoas presentes, tanto mais difícil será isolar o proble1na e ro1nar a atitude para corrigi-lo. Algu1nas vezes, as discussões em grupo não são o lugar adequado para solucionar problemas de comunicação porque há 1nuiras pessoas e conflitos envolvidos para resolver qualquer proble1na de 1nodo efetivo. Discutirei resu1nidamente a comunicação e1n grupo no Capículo 1 O, 1nas na 1naior parte desce capículo, focarei as situações mais simples.

Uma tática simples para tornar a lista eirada anteriormente executável é compartilhá-la com os integrantes de sua equipe, e pedir a essas pessoas que identifiquen1 quando uma pessoa está se con1porcando de modo proble1nárico. A equipe terá, então, u1na linguagem para os problemas que derectam, fucilitando ainda n1ais identificar e 1ninimizar essas condutas. Especificamente para os líderes da eqLtipe, deve ser firmado um compromisso para reexaminar o próprio comportamento e prestar mais atenção ao que se est<í fàzendo e dizendo. Muito provavelmente, essas pessoas perceberão rapida.mente os hábitos que precisam ser trabalhados. (Uma mudança de qualquer natureza é diflcil. Uma mudança organizacional exige que seus responsáveis tomem uma atitude. Consulte o Capítulo 16.)

Contudo, por mais que você estude ou leia sobre a psicologia e cornunicação hun1ana, essa percepção se1npre será subjetiva. Não há Luna formula rr1atemática que você possa usar ou u1n dispositivo de detecção para ser co1nprado, para ajudá­lo a reconhecer quando você está prestes a causar u1n proble1na de comunicação. O mes1no se aplica ao conscientizar outras pessoas sobre os problemas de comunicação que esrão acarrerando. f uma siruação delicada e complicada, e algumas pessoas rêm anos de experiência cultivando maus hábiros de comunicação dos quais não pretenden1 abrir 1não só porque você está fazendo essa recon1endação. Este é un1 dos vários n1otivos pelos quais gerenciar projetos é u1na função árdua: você precisa investir em relaciona1nenros com as pessoas, independentemente do quanto elas esteja1n investindo em você.

Os projetos dependem dos relacionamentos

Os gerentes de projeto são tão eficientes quanto seus relacionamentos com os integrantes da equipe. Não importa quão brilhante ou culto seja o GP, seu

192 A.ARTE DO GERENCIAMENTO DE PROJETOS

valor é dererminado pela eficiência co1n que ele consegue aplicar essas peculiaridades ao projero arravés de ourras pessoas. Por exemplo, como os programadores e resradores faze1n a 1naior parte do trabalho em si, qualquer valor agregado pelo GP deve ocorrer por 1neio dessas pessoas. Isso não quer dizer microgerenciá-las nem se tornar um expert nessas habilidades; te1n a ver com perceber a função do GP como an1plificando o valor desses outros operários de algun1a forn1a possível.

O desafio esrá e1n cotno f:1zê-lo. Setnpre que dou un1a palesrra ou um curso sobre gerencia1nento de projetos e convenço u1n grupo sobre esse aspecto, algué1n sempre levanta a mão e pergunta: "Sendo assim, como posso amplificar o valor deles? Sei que é algo que devo fàzer, mas como fazê-lo sem irri tá-los muito?". Boa pergunta. Poucas pessoas vêm para o trabalho querendo ser amplificadas ou ter alguém de quem talvez não gostem se metendo e1n suas at ividades cotidianas. A resposta está. em entender os relaciona1nentos. Não existe uma formulação única para agregar valor. Isso depende da pessoa cotn a qual você esrá lidando e das expectativas geradas para a função que essa pessoa desempenhará.

Definindo funções

'/1 causa de quase todas as dificuúlades de relacionamento está enraizada nas expectativas conflitantes ou ambíguas geradas ein torno de funções e 1netas."

-Stephen Covey, autor de The 7 Habits of Highly Ejfective f>eople

Na lista anterior de problemas de con1u11icação, u1na das questões n1ais importantes está relacionada às pressuposições e como esclarecê-las. As funções de GP, líder ou gerente são as mais ambíguas e mais propensas a pressuposições por parte das outras pessoas. Todo programador ou testador sempre carregará sua primeira experiência com um GP (boa ou má) como um modelo ao trabalhar com todos os futuros GPs. Na primeira vez em que você entrar na sala, a nova equipe o verá como uma projeção de todas as suas experiências anteriores com GPs. Os integrantes da equipe presu1nirão coisas diferentes sobre o que você fará e sobre o valor que poderá agregar à equipe. Não importa a sua opinião sobre quão be1n-definidas esreja1n as descrições dos cargos onde você rrabalha, haverá se1npre baseante espaço para as más suposições.

A solução mais fácil é esclarecer as funções junto às pessoas imporrantes de seu conheci1nenro, com as quais você estará trabalhando: programadores, testadores, profissionais de marketing, clientes ou até executivos. Sente-se diante de u1na pessoa con1 a qual trabalha e faça rrês listas no quadro branco. A primeira lisra traz as arividades pelas quais você é basicamenre responsável. A segunda lista são as arividades cuja responsabilidade é dividida pelos dois. E a rerceira lisra são as atividades de responsabilidade exclusiva das outras pessoas. Ao prepararem as listas juncos e discutirem que irens pertencem a que )isca, vocês reconhecerão rapidamente o que cada um espera do oucro (consulte a Figura 9-2). A definição de funções descarrega todas as pressuposições e a bagagen1 que as pessoas trazem sobre o que os gerentes de projeto, gerentes gerais, desenvolvedores, testadores ou quaisquer outros profissionais devem fazer.

OqueoGPfaz

- Escreve especificações - Gerencia clientes - Gerencia executivos -Acompanha o andamento - Comanda a comunicaçOO

da equipe

Co1111uNrc Aç Ão E RELAC 10NAMENTos 193

O que ambos fazemos

- Triagem dos defeitos informados

- Discutimos as implicações que afetam o custo de desenvolvimento e design

- Informamos uns aos outros os riscos ou problemas

- Ajudamos uns aos outros a solucionar problemas ou brainstorm

O que o programador faz

- Escreve código - Orienta o processo

de construção - Trabalha e/testes das

compilações - Faz verificaÇ{jes - Revisa as especifrcações

FIGURA 9-2. As discussões sobre a definição de funções ajudam cada relação (isso é apenas um exemplo - suas listas podem ser diferentes).

No mínimo, você identificará os pontos de discordância e, mesmo que você não solucione todos eles, estará consciente dos possíveis problen1as e poderá trabalhar nessas tarefas co1n mais atenção. Na maioria das vezes, as discussões úteis resultarão nu1n entendi1nento melhor das funções e darão uma idéia mais clara da interdependência dos parceiros para se obter êxito. Talvez o mais importante seja que essa discussão é uma estrutura que ambas as partes podem usar para discutir problemas de relações no futuro. O gelo foi quebrado e agora ficou mais fácil conversar sobre funções, colaboração e responsabilidade. Se ocorrer algum problema posterionnente, será mais fácil voltar às !iscas e identificar onde algo não está funcionando como previsto.

O ten1or nessas discussões está, em grande parte, relacionado com o controle. Assin1 que você escrever no quadro branco algo que você gosta de fazer e oferecê-lo con10 1naterial para revisão e debate, estará vulnerável a ter esse material arrancado de você (e então, o medo desaparece). Mas até onde seja do conhecimento do GP, na maior parte do tempo, os itens de maior interesse (tomada de decisões de alto nível, trabalho multidisciplinar, estratégia) são os últimos aspectos de natureza 1nais técnica nos quais os progra1nadores ou testadores desejam participar. Na verdade, na maioria dos casos, o pessoal da área técn ica não sabe o que u1n GP fàz o dia todo, e sem realizar algum tipo de discussão sobre funções, essas pessoas nunca descobrirão o que um GP faz (co1no os bons GPs trabalham muito para proteger os prograrnadores e testadores contra as políticas, burocracia e tolices da gerência geral, é possível que o restante d a equipe nunca tenha a oportunidade de saber o quanto o GP está auxiliando).

No pior caso, onde houver lacunas enormes nas funções percebidas ("Seja o que for que seu último GP tenha feito, não vou lavar sua roupa suja"), está na hora de conversar co1n seu chefe e possivelmente co1n o gerente da pessoa corn a qual você filou. Não há tnotivo para alarme: a estrutura usada é a mais fácil para levar a discussão aos outros e trabalhar no sentido de uma solução. Nas equipes 1naiores, iniciei essa discussão algu1nas vezes co1n o gerente da equipe de progra1nação ern pri1neiro lugar, obtive seu apoio e depois abri a discussão para os progra1nadores colaboradores en1 nível de linha. Isso compensa se você acha que o apoio dessa pessoa é necessário logo de início ou se você se entende melhor com ele sobre as funções do que com alguns dos outros progran1adores contribuintes.

194 A.ARTE DO GERENC[AMENTO DE PROJETOS

A melhor atitude profissional

Uma pressuposição silenciosa sobre o a1nbienre de rrabalho é que as pessoas esrão trabalhando arduainence e cencando dar o 1nelhor de si. Como não é possível avaliar o esforço das pessoas e1n seus crabalhos, 6 ou co1no seria seu 1nelhor trabalho, os gerentes raramente perdem tempo conversando sobre isso. Isso é un1 erro. Um gerente deve ajudar cada integrante da equipe a cultivar un1 desejo de realização. O relacionamento entre o trabalhador e o gerente deve abranger o esforço do gerenre no sentido de ajudar o trabalhador a ser o mais eficienre possível.

D eve ser algo totalmente natural e aceitável para un1 GP fazer ao testador, desenvolvedor, profissionais de marketing ou designer a seguinte pergunta: "O que posso fazer para ajudá-lo a realizar seu melhor trabalho?" Não há necessidade de preâmbulos ou de quaisquer advertências sobre o que você não gostaria de fàzer. Ao fazer essa pergunta simples, três reações positivas acontecem:

1. Você define a possibilidade de que a pessoa com a qual você está conversando seja capaz de dar o rnelhor de si no projeto atual e que talvez possa existir algo que a irnpeça de fazer isso.

2. Você insere essa pessoa ern uma estrucura que avalia o próprio desempenho e identifica atitudes que ela pode ton1ar para fazer a diferença.

3. Você viabiliza urna discussão sobre o que ambos pode1n fazer para 1nelhorar a qualidade do trabalho desenvolvido. Ao basear uma discussão e1n corno do "1nelhor", você se esquiva da possibilidade de que ela venha a se sencir cricicada ou que ela pense que seu trabalho atual não é suficientemente bom.

Essa abordagem não tem nada a ver com ser um bom garoto ou tentar fazer com que as pessoas pensem como você. Obter o melhor desempenho possível da equipe é uma responsabilidade direta do GP. Descobrir como tornar um designer ou programador mais eficiente não é apenas fazer um favor a essa pessoa, é melhorar a qualidade e a.urnentar a velocidade do trabalho desenvolvido no projeto. É evidente que, para um projeto obter êxito, não se deve esperar o melhor trabalho de todos, mas algo bem parecido. Se a busca por um padrão superior não prejudica o projeto - e isso 1nelhora claramente a motivação e o investimento pessoal na equipe - então, compensa fàzer algumas perguntas simples.

Algurnas vezes, ao perguntar às pessoas corno é possível obter o melhor de si, a resposta pode ser "Deixe-me em paz" ou "Parar de me fàzer perguntas idiotas" ou outras respostas 1nais desprezíveis. Até mesmo se essas pessoas não lhe parecere1n receptivas, pensarão na sua pergunta, quer ad1nita1n isso ou não. Conheci programadores que ignorara1n 1ninha pergunta inicial ("Não, Scott, não há nada que você possa fazer") e 1ne procurara1n u1na se1nana depois com u1na excelente sugestão que tern1inou ajudando a equipe de desenvolvimento intei ra. Alén1 disso, eles me agradeceram por respe i t~i-los o bastante para pedir

• • r suas op1n1oes.

A atitude básica resultante é que quando um programador está ficando para trás, o GP não deve culpá-lo e insisrir para que ele trabalhe com n1ais agilidade. Ern vez de agir assim, deve ajudá-lo a conhecer o problema e contribuir com tempo e energia para solucioná-lo. Pedir o 1nelhor que ele possa dar é uma maneira fácil de estabelecer uma relação de apoio com ele. Essa atitude se aplica a

CO!vlUNIC AÇÁO E R ELAC IONA..'v1ENTOS 195

qualquer pessoa ou organização que esceja colaborando co1n o projeco. Mes1no que o ce1npo do GP seja requisitado para oucras acividades, e1n geral é 1nelhor dar prioridade à assiscência aos colaboradores direcos do projeco do que a quescões políricas e burocrácicas secundárias. Os primeiros sempre afetarão direcamence o cronograma do projeto, mas os liltimos nem sempre.

Como obter o melhor das pessoas

Os melhores líderes raramence obrigam as pessoas a fazer alguma coisa. Em ve:z disso, usa1n quaisquer outras alcernativas possíveis para convencê-las. Todos têm diferentes pontos fortes e fracos no que diz respeito a motivar outras pessoas, e acontece que os melhores líderes têm uma tendência a dispor de uma variedade maior de ferramentas a serem usadas e mais controle sobre elas.

Algo que conscatei nos gerentes e líderes fracos é o excesso de confiança em u1na abordage1n ou 1nétodo para tentar obter o 1nelhor das pessoas. Se o cal 1nétodo não funcionar, eles desiste1n, argu1nentando que não há nada mais a ser feiro. Infelizmente, nada 1nais aconcece, quando o líder da equipe argumenca que não há oucras alcernacivas. Em substituição, quando paralisado, provavelinence haverá outra perspecciva sob a qual vislumbrar um funcionamento. t. possível que você consiga experimentar outra cática, 1nas ta1nbém pondere que alguém mais na equipe pode ajudar, concedendo à situação u1n talento que você não tem.

• Seguir conselhos. Ouvir sugestões é un1a coisa, e fazer algo a respeito é outra. Quando a equipe solicitar mais ten1po para determinadas carefas, dê um jeito. Se dere1n a entender que está ocorrendo um número excessivo de reuniões, aceite sugestões para diminuí-las. Leve a equipe a sério. Invista muita energia atendendo às necessidades dessa equipe. Mesmo que no final das contas não dê resultado, se você realmente assumir o desafio de atender às suas solicitações, eles perceberão. O efeito sobre a qualidade de seu trabalho será parecido com ter êxito. Contudo, precisa ser original. As pessoas podem detectar os esforços administrativos simbólicos a quilô1netros de distância (elas têm muita experiência observando essas coisas).

• Desafiar/criar exigências. O modo 1nais óbvio e estereotipado de uma pessoa com autoridade fazer com que outras pessoas trabalhem é exigindo: "40 flexões, agora mesrno!" Quanto mais inceligences, independences ou experientes forern as pessoas com as quais você crabalha, canco menor será a probabilidade de esse mécodo funcionar. Se a visão for boa, o crabalho for interessante e as pessoas progredire1n, haverá pouca necessidade de fazer qualquer exigência. A rnocivação deve acontecer nacuralmence. Quando você precisar reacender a chan1a, descubra maneiras inteligentes de fazê-lo. Faça co1npecições an1igáveis: "Se cumprirn1os esse prazo, pincarei meu cabelo de azul" ou "A equipe de programadores que corrigir codos os bu~ em primeiro lugar ganhar<Í u1na carde de churrasco no n1eu barco". 7 As exigências cêrn o seu lugar, 1nas não seja 1nedíocre, seja honesco. "Veja bem, isso precisa ser feiro. É rarde demais para discurir sobre isso e lamenco se não me ftz encender anres. Por fi1vor, passe isso para mim, cerco?"

, • Inspirar. E muiro difícil simular inspiração. Ou você acredira no que escá

fazendo, ou não. Se realmente acredica, encão descubra um jeico de expressá-lo

196 A.ARTE DO GERENC[AMENTO DE PROJETOS

de modo posicivo, para que as pessoas se alimencem disso. "Sabe, eu amo esce projero. Somos pagos para aprender novas recnologias e descobrir co1no aplicá­las. Isso é algo raro e especial, que 1ne fàz vir aqui rodos os dias." Não precisa ser algo elaborado ou eloqüenre. Se for sincero, funcionará. A narureza hu1nana rerribui as emoções posirivas e quando você river u1na grande idéia, convide os outros a seguir. Métodos mais diretos seriam perguntar às pessoas o que lhes satisfaz ao escrever un1 código, e ajudá-las a fazer ligações entre esses senrimencos e o crabalho que têm pela frenre.

• Eliminar as barreiras. Todo excelente corredor no fi.1tebol americano rinha um herói anônimo que abria o can1inho para ele. Esse herói anônimo é chamado de bloqueador (uma espécie de zagueiro). Ele dispara na frente do corredor e atropela o primeiro que tentar segurá-lo (geralmente alguém muito m;Úor que ele). Se você exa.minar qualquer sucesso estrondoso, verá que sempre existe alguém que ralou bascanre para rorná-lo possível. Os bons GPs cornarn o beiro possível. Eles procuram e eliminam os problemas que escão recardando a equipe. Pergunre às pessoas: "Existe algo bloqueando?" Se dissere1n que esrão esperando u1na decisão ou tentando buscar infonnações, você deve rentar descobrir um jeito de agilizar esse processo. As pessoas devem saber que você esrá disponível para ajudar se elas se sentirem bloqueadas.

• Le1nbrar às pessoas as respectivas fun ções. O 1nétodo n1ais freqüenre de acionar o melhor trabalho é lernbrar às pessoas suas funções na equipe. Quando um programador reclarnar que está recebendo u1n núrnero excessivo de solicitações de novos recursos, a resposra deve ser que, provavelmenre, não é o serviço dele receber as soliciraçóes: ele deve encaminhar as pessoas para você (o GP). Ele pode participar no processo se achar adequado, mas se seu cronograma estiver atrasado, deverá solicitar a intervenção do GP. Ocasionalmente, as pessoas, principalmente os programadores, estão tão concentrados no próprio trabalho, que se esquecen1 dos testadores, designers e gerentes ao redor deles, que geralmente são mais indicados do que eles para comandar certos tipos de tarefas.

• Lembrar às pessoas as metas do projeto. Como GP ou líder, você re1n uma perspecriva mais abrangente do projeto do que qualquer outra pessoa. As pessoas costurnarn se perder fàcilrnente na cornplexidade de suas áreas mais restritas de responsabilidade e se esquecem dos assuntos realmente imporrantes. Uma conversa rápida, para arualizar a percepção que rêrn sobre o que estão real1nenre fazendo e por que, pode resgarar seu foco, sua morivação e eficiência. Con10 as luzes de sinalização de aterrissagem que idenrificam a pisca de um aeroporto à noire, tàcilitando para o piloro a localização de sua rrajerória segura, os bons GPs ilu1ninarn o carninho.

• Ensinar. Se você conhecer um truque que as pessoas com as quais trabalha poderão usar, por que não se oferecer para lhes ensinar? Dar a elas uma nova habilidade ou dica para subscituir uma antiga dobra o valor desse conhecimento. Quando você ensina, permire que as pessoas rrabalhem mais rapidamen te e aurnentem suas chances de apresentar um bom trabalho, além de possivelmente melhorar a qualidade do que fàzem de melhor. Noel Tichy, autor de The Leadership Engi.ne (Harper, 2002), diz o seguinte sobre a import;\ncia de ensinar: "Converse com um inregrante de uma tropa especial da Marinha [depois que ele aprender alguma coisa) e uma das primeiras aritudes que ele

Co1v1uN1CAçÃo E RELAC IONAMENTOS 197

coma é ensinar ao colega, porque isso pode salvar a vida dele. Se eu aprendo algu1na coisa - eu 1ne apresso para ensinar às pessoas? Depois, posso fazer isso em u1na escala 1naior? Esse é o cruq ue."

• Pedir. Parece óbvio mas isso raramence aconcece. Basca pedir às pessoas que dêem o melhor de si . Não é necessário explicar por que ou sequer oferecer algo em troca. Basta dizer "Ei, adoraria ver seu n1elhor trabalho aqu i. Esse trabalho é importante e se você tiver algo mais a oferecer, gostaria que fizesse isso agora."

A motivação para ajudar os outros a oferecer o melhor de si

Quando comecei a trabalhar com a equipe do Windov.1s, lembro-me que me sencia como se estivesse investindo rodo o meu cempo para ajudar oucras pessoas a fazere1n seus trabalhos. Eu era um gerence relacivamence principiante (rendo subordinados diretos) e depois de perambular ajudando as pessoas a colocar lenha em suas fogueiras e dando conselhos, tudo o que eu q ueria era ficar sozinho. Tentei chegar à rninha sala e fechar a porca, n1as as pessoas continuavan1 me acon1panhando. A luz do 1neu correio de voz não parava de piscar e eu sequer t inha coragem de verificar 1ninhas 1nensagens de email acumuladas, enquanto perambulava pelo prédio. Lembro-me de cer me quescionado por que passei canco ce1npo nas salas de outras pessoas, e precisei de algum tempo para obcer uma resposta confiável. Mas obtive uma resposta e ela está aqui.

As conversas não eram ocorrências etéreas ou engraçadas. En1 cada conversa, eu estava fuzendo algo diretamente relacionado com os objetivos do projeto. Isso vai muito além da importância abstrata de bons relacionamenc.os. Sempre que respondia alguma pergunta na minha porca, negociava com ouc.ra organização ou argumentava sobre recursos corn a minha equipe, eu escava fazendo canto quanto qualquer desenvolvedor ou testador para tocar o projeto para frente. Eu escav11 permitindo que eles escrevessem o código, localizassem os bugs e executassem mil outras coisas mais rapidamente ou com mais faci lidade do que o fariam de alguma outra forma.

O que quero dizer é que se você examinar cuidadosamente as conversas que cem com oucras pessoas e o respectivo impacto sobre o projeto, perceberá que cada diálogo contribui para urn dos seguintes aspectos:

• Melhora a qualidade do que está sendo desenvolvido

• Aumenta as chances de ser finalizado e1n tempo hábil

• Ajuda a tornar o producolsitelsoftware 1nais úteis para as pessoas

• Aumenta as probabilidades de que o produtolsitelso_ftzvare gerem lucro ou tráfego

• Protege as pessoas contra o trabalho desnecessário, políticas idiotas ou burocracia

• Facilita ainda mais a manutenção do que está. sendo construído

• Aumenca a mocivação ou a alegria das pessoas na equipe

• Ajuda a equipe a trabalhar de modo mais inteligente e ágil, e a aplicar (e aprender) novas habilidades

• Evica ou esclarece a conduta prejudicial ao projeto ou à equipe

198 A.ARTE DO G ERENCIAMENTO DE PROJ ETOS

Por conseguinte, até mes1no quando estiver cansado de derrubar barreiras, de responder perguntas ou de consultar várias pessoas por várias razões, le1nbre-se de que o esforço invesrido nisso tudo não será desperdiçado nem de pouca i1nporrância. Desde que você possa reassociar essas discussões, bare-papos, simulações de incêndio, argu1nentações a tendências positivas no projeto (ou uma prevenção contra as negativas), elas serão fundamenrais para o seu avanço. Você está realizando um trabalho que ninguén1 nlais na organização faria com a mesma eficiência. Contudo, se não puder vincular todas essas conversas a coisas in1portanres, pare de fazê-las. Priorize seu rempo e suas relações, para que sua energia seja direcionada para as coisas que tiverem o maior impacto positivo.

Resumo

• Os projetos acontece1n somente através da comunicação. Hoje e1n dia, a velocidade não é o gargalo da comunicação mas, sim, a qualidade.

• As relações otimizam e agilizam a comunicação.

• Há várias estruturas que definem co1no as pessoas se co1nunicam umas co1n as outras. Os GPs devem conhecê-las para que possam diagnosticar e solucionar as falhas na co1nunicação.

• Há vários problemas con1uns de con1unicação, a saber: pressuposições, falta de clareza, não ouvir, dar ordens, ataques pessoais e culpar.

• A definição de funções é a maneira nlais simples de melhorar os relacionan1entos.

• Pergunte às pessoas o que elas necessitam para fazer o nlelhor trabalho. Para isso, é possível: ouvir, derrubar as barreiras, ensinar e lembrar-lhes suas 1necas.

• Os relacionamentos e a comunica.ção nã.o sã.o un1 trabalho de baixa prioridade. São fundamentais em todas as atividades das pessoas, que ocorrem ao longo de

Capítulo 10

Como não incomodar as pessoas: processo, email e reuniões

200 A.ARTE DO GERENCIAMENTO DE PROJETOS

B urocracia(s): um sisrema ad1ninisrrarívo em que a necessidade ou tendência a seguír procedí1nencos rígidos ou co1nplexos í1npede a ação efecíva.

Quanto n1aíor for a sua equípe, canro maiores serão as probabilidades de suas atividades de gerenciamento de projeto inco1nodare1n alguén1. Sen1pre que supervisionar o trabalho de alguém ou tomar decisões que afecam outras pessoas, você poderá incomodar; faz parte do território. Use a sua inteligência e procure meios de ser eficienre, sem incon1odar as pessoas com as quais rrabalha. Elas ficarão maís felízes, o projeto rranscorrerá melhor e você receberá bem tnenos olhases de desprezo das pessoas pelos corredores.

As três atívídades com as maíores probabílídades de desagradar as pessoas são o ernail, as reuníões e os processos em equipe (por exemplo, construir ou especificar procedimentos). Este capítulo discorrerá sobre os erros comuns e abordagens básicas para executar essas atividades com um f.i.tor de risco mínimo de incômodo.

Por que as pessoas se sentem incomodadas

Como não encontrei uma hiscória publicada sobre o aborrecímento, esrou confiando em n1inhas próprias observações ao resumir os morivos pelos quais as pessoas se irriran1. Tenho tuna grande experiência nessa área: tenho sido inco1nodado várías vezes, renho presenciado outras pessoas sendo subtnetidas a irritações e, ocasíonalmence, sou considerado algué1n que aborrece as outras pessoas. Embora cercamente existam outras causas de aborrecimento alétn das eiradas na lisra a seguir, essas são as tnais comuns e relevantes que conheço.

Para que estes exemplos sejam real1nente co1npreendidos, estão descriros na primeíra pessoa (talvez ajude pensar em uma determinada pessoa com a qual você te.m experiência em trabalhar em conjunto, uma pessoa que você respeita, ao ler estes exemplos).

• Supor que eu sou um idiota. Se eu fui admitido para executar derermínada atividade que sou capaz de fàzer, se1npre que alguém me tratar con10 se eu não pudesse concluir a tarefa - ou como se eu precisasse de um procedimento de 20 etapas, um manual de norrnas, um modelo, uma avaliação cotidiana, uma comíssão ou outro processo que me habilire a fazer o meu trabalho - eu ficarei aborrecído, e co1n roda a razão. Parre de mínha arívidade deve ser ajudar a definír meu trabalho, de modo a atender aos objetivos determínados pela gerêncía. Mas até que eu fracasse e prove 1nínha inco1npetêncía, devo ser trarado co1no co1npetente. Devo ter liberdade para definir, de n1odo racional, a 1nelhor fonna de finaliz.'lr o meu trabalho.

• Não confiar em nlÍm. Se, todos os dias, eu precisar fazer un1a verificação, verificar duas vezes, crês vezes e fazer um laudo das decisões que já fazem parce de mínhas responsabilidades, eu me senrírei incomodado. Se eu precisar confinnar rudo, que aurorídade eu realmente renho? Por que tudo precisa ser documentado e regísrrado, se esrou real ízando um bom trabalho? Mesmo que eu não seja merecedor de toda a confiança no início, a gerêncía é quem deve propíciar um caminho justo para que eu mereça a confiança, e me ajudar a avançar nesse can1inho.

CoMo NÃo INCOMODAR AS PESSOAS: PROCESSO, E,vvuL E REUNtôES 201

• Alugar o meu tempo. Se o 1nodo corno a equipe funciona me obriga a repetir rarefus (enfadonhas) várias vezes ou me desviar do caininho para 1ne proteger conrra as conringências e paranóias da gerência, que são comica1nenre inauspiciosas e insignificantes, eu me irritarei. Isso abrange vacilar e1n decisões importantes ou ser totalmente incoerente ao enviar mensagens, ou me con1portar sem qualquer explicação (ou pelo menos 1ne desculpar), inclusive quando solicitado.

• Gerenciar-n1e com falta de respeito. Se estão sempre me fazendo de tolo, se recebo atribuições fora da realidade ou se sou exposto ao fracasso e levo a culpa por coisas que estão além da minha esfera de responsabilidade, eu fico irado. Alguém deve me supervisionar e garantir que meus esforços estejam de acordo com as diretrizes do projeto, orientando-me para o sucesso. Portanto, minhas solicitações de ajuda devem ser consideradas com seriedade e não atrasadas em demasia ou ignoradas.

• Obrigar-me a ouvir ou ler coisas tolas. Sempre que sou solicitado a ouvir utna outra pessoa ou ler algo escrito por outra pessoa, que não têm nada a ver com o trabalho que está sendo desenvolvido, fico chateado. Temos u1n padrão de triage1n para a qualidade dos bugs: por que não instituir um para a idiotice? Só porque alguém convoca u1na reunião, escreve um docun1ento ou envia um ernail, não significa que eu devo ocupar meu tempo cotn isso. Quanto mais secundárias ou rerciárias foren1 as solicirações (ou imposições) que recebo, ranro 1nenos produrivo e feliz eu serei.

A maioria desses motivos de aborreci1nento explica por que muitas pessoas detestam a idéia de processos de trabalho. Elas temem que qualquer tentativa de sistematizar seu trabalho gere apenas burocracia ou outros tipos de sofrimento. Acho que esse n1edo é infundado. As pessoas elaboram processos, con10 tudo o mais, e se o designer for inteligente e estiver focado nos objetivos certos, os processos poderão beneficiar a todos. Processos podem ajudar as pessoas e não criar barreiras ou irritá-las.

Os efeitos do bom processo

Defino um processo con10 qualquer conjunto de ações sistematizadas que uma equipe decide executar periodicamente, para verificar se algo foi realizado de detenninada 1naneira. Os processos são conhecidos por vários nornes: normas, diretrizes, fonnulários, procedi1nentos ou restrições. (Por exemplo, o modo como um código é verificado, cesrado e consrruído é um exemplo co1nu1n de um processo de engenharia. Ourros seriain redigir e revisar especificações, rasrrear bugs, gerenciar calendários e cronogramas erc.) Um bon1 processo aumenra a probabilidade de fina lização do projero e traz benefícios que con1pensan1 seus cusros. Mas con10 rarainente se investe ternpo, levando-se em consideração o motivo pelo qual detenninados processos existem ou que problen1as solucionam (devem solucionar), várias equipes vivem soterradas en1 processos, sen1 usufruir das vanragens que eles podem propiciar.

Às vezes, o proble1na é quem esrá no poder. Qualquer idiora com auroridade suficiente pode sugerir o sistema idiota mais estarrecedor para fàzer algo e tentar

202 A ARTE DO GERENCl1\MENTO DE PROJETOS

obrigar a equipe a segui-lo. En[ão, quando a equipe decide não so1nen[e sobreviver a esse processo, co1no [a1nbé1n sugerir efetiva1nen[e algo concreto, a pessoa no poder pode até 1nes1no indicar o processo como um con[ribuinre para o sucesso (ignorando o faro de que a equipe foi bem-sucedida, apesar do processo besta). Se a pessoa tiver poder suficiente, poderá abafar quaisquer motins ou contestações por sanidade e continuar torturando a equipe, acrescentando mais procedimentos.

Outras vezes, o proble1na é a filosofia: "Isso funcionou antes, então vamos agir assim". Nessa situação, um líder de equipe, que já fez algo, de certa maneira, insiste em infligir esse 1nérodo ou processo em toda equipe nova por ele comandada (esse mau hábito administrativo é citado no Capítulo 8). Isso é ruim porque o êxito obtido anteriormente em alguma coisa só é relevante se a situação atual for semelhante às anteriores. O verdadeiro teste de aceitação de um processo deve destacar as necessidades atuais at ravés de exames das necessidades passadas.

Na maioria das vezes, o problema reside nas co1nplexidades da criação dos processos. Um processo tenta organiz.'lr o modo como as pessoas [r-abalha1n e in[eragem, dois aspec[OS de impor[ância crfrica mas muito orgânicos. As pessoas trabalham de modo diferen[e. Elas têm preferências e [Olerâncias disrincas aos controles formais. Se o criador do processo não for cuidadoso, o processo se tornará facilmente um gargalo, atrasando as pessoas e tolhendo sua (concepção de) liberdade e capacitação.

Para criar bons processos, o segredo é entender dois aspectos que se combina1n: o que faz com que os projetos e as equipes obrenha1n êxito de 1nodo geral, e o que torna o projeto e a equipe atuais diferences dos outros (consulte a Figura 10-1). Não basta saber co1no ocorre a aprovação nos testes e1n geral; é necessário considerar a cultura, personalidade e os hábitos da equipe de reste atual, com a qual você está trabalhando. Ocasionalmente, a cultura ou o projeto ex.ige uma abordagem diferente (por exemplo, restar os processos para sistemas de freio antiblocante (ABS) integrados versus testar processos e1n relação ao site da banda de punk-rock de Steve). Em ve:-L de controlar de cima para baixo, em geral funciona melhor deixar a própria equipe fàzer um autocontrole. E1n vez de reutilizar u1n rnodelo padrão, é possível perrnitir a modificação e criação de u1n rnodelo próprio. Quase como qualquer ripo de negociação (consulte o Capítulo 11), no que diz respeito ao processo, é necessário ser transparente quanto aos principais interesses e não quanto a posições específicas.

O que geralmente ton1a as equipes

eficientes.

O que toma esta equipe/projeto diferente dos

outros.

FIGURE 10-1. O bom processo exige um conhecimento de projetos em geral, assim como as características únicas do projeto atual.

CoMo NÃo INCOMODAR AS PESSOAS: PROCESSO, E1vvllL E REuNtóES 203

Para ajudá-lo a encontrar e reconhecer os bons processos, segue uma lista das respectivas características e efeitos sobre o projeto. Ucílize-a ao criar ou aperfeiçoar um processo.

• Processos agilizam o progresso. Por mais sem sentido que possam parecer, os bons procedimentos tornam as pessoas n1ais e não menos eficientes. Por exemplo, as faixas de sinalização brancas pintadas nas rodovias nos Estados Unidos resrringen1 até onde seu carro pode trafegar quando você esciver dirigindo. Mas essas fuixas aplicam a mes1na restrição a rodos, elas englobam um conjunto básico de normas que permitem que cada mocorisca dirija a uma velocidade mais alta (e controlam aqueles que dirigem muito vagarosamente). As pessoas acreditam que os outros motoristas obedecerão a essas normas. O bom processo oferece um sistema com o qual as pessoas podem contar e no qual podem basear suas decisões. E1n alguns casos, o processo define normas que as pessoas seguirão, o que facilita para uma pessoa obter co1n outra pessoa algo de que necessita (por exemplo, encontrar alguém que revise um código). Um exe1nplo comprovado são as ferra1nencas e processos de criação auco1narizados que permitem que as pessoas construa.m projetos pressionando apenas algumas teclas, desde que sigam as convenções necessárias de codificação, definidas pelo siscema de compilação.

• Processos evican1 problemas. O 1notivo 1nais comu1n para Ílnple1nentar u1n processo é evitar que algu1na idiotice aconteça (nova1nenre). O desafio é fazer isso sem dificultar, ao mesmo tempo, o progresso, ou sem incentivar outros tipos de rolices. Para isso, é necessário conhecer as causas do problema e os fatores mais imporcanres para progredir. Ajuda muito perguntar apenas "Qual é a maneira nlenos invasiva, menos desagradável e nlenos dispendiosa de garantir que isso ou aquilo nunca mais aconteça?". Ou na direção contrária, ao examinar um processo já existente, pergunte "Isso evita que aconteça que problema? Qual a gravidade ou probabilidade desse problema?" Se um processo não evita problemas nem agiliza o progresso, procure se livrar dele (consulte a próxima seção "Uma fórmula para bons processos").

• Processos tornam as ações importantes visíveis e avaliáveis. Os processos que abrem bug;s ou publicam especificações facilitam o rascreamenco da freqüência com que essas coisas acontecem. Também é possível monitorar facilmente o status, os resultados e as tendências no âmbito da equipe. Para irens i1nportances, corno bugs, especificações e testes, u1n bom processo tàcilitará descobrir o escado em que o projeto se encontra e comparar o estado atual do nlundo co1n a situação em que o projeto escava e precisa estar. Esse aspecto é importante para as estratégias incennediária e final (consulte os Capículos 14 e 15).

• Processo para 1nudar ou eliminar o processo. Como os projetos e as equipes n1udam o ternpo rodo, un1 processo que é úcil ou necessário e1n um mês pode deixar de ser úríl ou necessário no 1nês seguinte. O processo em si mesmo deve dispor de um mecanismo interno para detectar quando não é mais útil ou quando deve ser atualizado para torná-lo útil novamente. Nunca pressuponha que un1 processo pern1anecerá para sempre e evite definir funções en1 torno de processos por este motivo. Alguém que identifique esta função como "O rapaz que passa no teste co1n nora 5" provavelmente dará a própria vida para se defender desse estigma e temerá qualquer 1nudança. Isso é 1nau. Em

204 A.ARTE DO GERENCIAMENTO DE PROJETOS

substituição, faça co1n que as pessoas se responsabilizem pelos efeiros ou resultados dos processos no projeto.

• Quem estiver no â1nbito de abrangência deles ficará a favo r deles. As pessoas aprovam os processos úteis. U1n bom processo será alinejável por aqueles que dele necessitam. Se você estiver propondo um novo processo que afeta testadores ou programadores, e seu processo for importante para o projeto, não deverá haver dificuldade para esses profissionais o experimentarem. Ou resumindo a história, antes de nlais nada, as pessoas devem participar diretamente na sugestão de novos processos. Certamente, calvez seja necessário convencer (uma n1udança raramente acontece sem persuasão). Mas se o problema que você está tentando solucionar realmente acontece e os ganhos de produtividade também forem reais, a equipe terá todos os motivos para se manifestar a fàvor. Como alternativa, se as pessoas afetadas pelo processo proposto pudere1n enu1nerar vários 1nocivos pelos quais o processo é uma má idéia, provavelmente estarão cerras. (Mas se o proble1na estiver realmente acontecendo, não desista. Peça à equipe uma contraproposta.)

Uma fórmula para bons processos

Uma forma de pensar sobre o processo é analisar a importância de seus efeitos positivos em relação aos custos de in1plementação e execução. Há urna fórn1ula que pode ajudar. Não é necessário sugerir nún1eros reais para que essa fórmula seja útil. Apresento-a principalmente como um exercício para ajudá-lo a ponderar sobre as implicações resultantes ao acrescentar processos de engenharia. Se não gosta de exercícios ou fórmulas, pule para a seção seguinte, você não perden1 nada.

Primeiro, examine os custos do processo: o tempo de elaboração do processo (DT - Design Tirne), o tempo de assimilação pela equipe (LT - Learning Ti1ne), o tempo real para. realizar um trabalho com o processo, multiplicado pela freqüência de execução (AT * N) . Os custos totais de qualquer processo são DT + LT + (AT * N).

Depois, considere os benefícios do processo: os custos das falhas evitadas pelo processo (FC), multiplicados pela probabilidade de que essas falhas ocorrerão (FP) se1n o processo, dentro de determinada unidade de tempo, multiplicado pela quantidade dessas unidades de tempo já atribuídas ao projeto (T). Torai de benefícios = (FC* FP) * T.

Grosseiran1enre, o resultado é o seguinte: valor do processo = ((FC* FP) * T) - (DT + LT + (AT * N)). Concordo plenan1enre que existe rodo o tipo de supersimplificação bruta

nessa fórmula, 1nas o espírito dela está suficientemente próximo para torná-la interessante. Se o resultado for un1 número alto, a importância será maior do que se desse um valor baixo. Um ni'unero negar.ivo indica que os benefícios do processo foram superados pelo custo.

Essa fórmula implica, inicialmente, que é muito fácil criar um processo que elimine efetivamente um problema. Contudo, o preço de realizá-lo pode ser mais alto do que conviver a vida inteira com as ameaças desse p roblema específico (por exemplo, adquirir um sistema de segurança de US$ 5 mil para

COMO NÃo INCOMODAR AS P ESSOAS: PROCESSO, E1vvllL E REuNtóES 205

um poce de doces) . Se você incluir o cernpo de elaboração e aprendizagem, e reconhecer que exisce apenas urna probabilidade de falha, o cusco-benefício opinará concra a mudança do processo.

Entretanto, é necessário considerar a infinidade de benefícios: geralmente se expandem por mais de um projeto. Muito provavelmente, procedimentos mais eficientes de verificação ou de construção serão úceis para o que virá depois. Talvez ainda mais importante é a probabilidade de que a ocorrência da falha nos próxiinos projetos possa au1nencar em lOOo/o. O valor de T na fórn1ula é significativo: rnesmo que a probabilidade de uma falha (FP) seja baixa, quanco maior for o intervalo de tempo, tanto maior será a probabilidade de ocorrência da fi1lha e de que o processo evite o seu custo. (Isso nos mostra um dos maiores desafios de um líder: decidir quando pagar os custos tangíveis de curto prazo para se obter retornos menos tangíveis de longo prazo. Esse desafio está presente em toda parte: admissão, equipamentos, instalações físicas, treinamento etc. Quen1 serneia vento colhe cernpescade. Os investimentos de longo prazo são a única forma de se conseguir melhorias de longo prazo.)

Uma última observaç;1o sobre essa fórmula: o componence AT (ce1npo real para usar o procedimenco) do valor é majs irnporcance do que parece. Urn born processo deve agilizar as coisas: o AT deve ter um valor negativo quando comparado com o modo como o rrabalho foi feiro sem o procedimento, se realmente estiver economizando tempo. Isso muda a relação entre custos/ benefícios, conforme estruturada na equação. Por exemplo, se AT = 5 horas, 111as anteriormence a carefa exigia 7 horas, o valor líquido é de 2 horas. Isso significa que agora a execução da tarefa foi reduzida em 2 horas e o valor cocal do processo é 1nuico nlais alto.

Como criar e implantar processos

Quando você identificar um problema que, em sua opinião, pode ser solucionado com um processo, siga o 1nesmo procedin1enco descrito no Capítulo 11. (Mesmo que você não esteja no meio de urna crise, o procedimento básico de execução de um plano de curto prazo é semelhante.) Defina de modo claro o problerna que está tentando solucionar e o pequeno grupo de pessoas mais capazes de ajudar a resolvê-lo. Traba.lhe como um grupo pequeno gerando propostas alternativas e depois escolha a mais promissora.

Em seguida, identifique uma parte isolada de baixo risco do projeto para criar um piloto para esse novo processo. Se possível, escolha pessoas interessadas em ser receptivas à rnudança do processo e fuça com que participen1 na sua criação. Concorde com os efeitos almejados que a rnudança do processo deve propiciar e, se possível, implemente rnedidas. Depois, instrua as pessoas parcicipances a realizarem a mudança. Defina urna dara futura para avaliar a eficiência da rnudança do processo.

Quando chegar o dia da avaliação, reúna-se novamence com o pequeno grupo e com as pessoas participantes do piloto. Discuta o que aconteceu. Se o piloto foi un1 desastre, repita o processo e faça u1n segundo piloto pequeno. Ou então revise o processo con1 base no que você aprendeu, e in1plemente-o em um grupo maior (possivelmente a equipe inteira). Deve ficar claro para todos aqueles solicirados a usar o processo os proble1nas que você está

206 A.ARTE DO G ERENCIAMENTO DE PROJETOS

renrando resolver e porque escá convencido de que a solução proposca realmence ajudará (as provas e os cesce1nunhos das pessoas que parcicipara1n no piloco deve1n ajudar 1nuico).

Gerenciando o processo de baixo para cima

"Nunca subestime o poder das pessoas idiotas nos grandes grupos. "

- Todd Blanchard

Às vezes, pessoas com mais poder que você infligem processos a sua equipe, com os quais você nã.o concorda. Talvez você esteja na minoria ou sem autoridade para revisar o processo. Acontece com as melhores famílias. Conheço três alternativas para lidar com essa situação. Nem sempre funcionam, mas vale a pena tentar.

• Blindar sua equipe contra o processo. As vezes, você pode absorver o processo por sua equipe. Se for necessário preparar algum fonnulário ou docurnencaç.'ío para que algurna coisa aconceça, faça você 1nesmo. É possível que você chegue a se sencir como urna secrecária, mas lhe cuscará apenas alguns 1ninutos a cada dia ou se1nana para poupar a sua equipe, e essa croca pode co1npensar. E1n alguns casos, você pode ganhar pontos junco à equipe por protegê-los contra coisas idiotas. Cartões de ponto, relatórios de despesas, reuniões obrigatórias (1nas ridículas) ao estilo RI-1, requisições de equipamentos e outras trivialidades irritantes são exe1nplos comuns de processos facilmente blindados.

• Apostar contra o processo. Agilize sua equipe no sentido de apresentar uma contraproposta ao processo. Descubra o que o processo está tencando evitar ou garantir, e assegure aos poderosos que a sua equipe atenderá a esses objetivos sern o processo. Defina um prazo para fuzer uma avaliação. Se sua equipe fracassar vencido esse prazo, você concordará em adotar o processo. Mas se a equipe for bem-sucedida, você colocará as cartas na mesa. Para início de conversa, essa atitude direciona a discussão do processo para as questões cercas (que problema estamos tentando resolver?), de modo que mesmo que você fracasse, o processo será aprimorado. (Em raros casos, uma pesquisa de outras organizações semelhances e be1n-sucedidas que não implemenran1 seja qual for o processo, ou fazem-no de um modo diferente e rnenos burro, pode atribuir pontos e evitar u1na aposta.)

• Ignorar o processo. Tenho un1a tendência a ignorar coisas distantes, an1bíguas, burocrácicas e organizacionais que não entendo. Minha ceoria é que, ao ignorá­las, das duas, u1na: ou a pessoa responsável pelo assunco entrará e1n concaco comigo e rne perguntará por que eu não a fiz, dando-me urna oportunidade de dialogar por que eu deveria fazê-lo; ou se ninguém rne pergunr;tr por que não a fiz, é por que calvez não renha importância para ninguém (ou, pelo menos, se eu a fizer ou não, é irrelevante). Tomarei conta da miI1ha vida, serei bem­sucedido sem o item em questão, terei tuna boa justificaciva, se alguém me perguntar algum dia por que não fiz isso ("Bem, fizemos outra coisa muito bem sem ele. Talvez você possa n1e convencer corno uma outra coisa teria ajudado?"). Isso geralmente funciona melhor em urna nova organização porque

CoMo NÃo INCOMODAR AS PESSOAS: PROCESSO, E,vvuL E REUNtôES 207

você cem uma desculpa a 1nais da ignorância organizacional Esceja avisado, 1nes1no que em sua perspecciva polícica seja arriscado ignorar a burocracia.

Email não-irritante

Embora pareça uma solução, o email ainda é o sisce1na mais incôn1odo con1 o qual as pessoas e1n un1 projeto cêm que lidar. Apenas como um resultado do volume de emails que recebemos, facilmente nos sentimos pressionados a ler e responder às novas 1nensagens o mais rapidamente possível, geralmente sacrificando as boas habilidades de ler/escrever. Na maior parte do tempo, a maioria de nós simplesmente não lê nem escreve email muito bem. Ironicamente, a velocidade e praticidade do email sá.o dilapidadas quando não conseguimos entender que diacho a outra pessoa está tentando d.izer ou não conseguiinos fà.zê­la entender o que estamos tentando lhe dizer.

E talvez o 1nais i1nportante para o gerencia1nento de projetos: o email é o principal 1neio de comunicação para líderes e gerentes. Ao criar u1n novo email e ao responder ao email enviado por oucras pessoas, u1n líder influencia e controla o fluxo de informações transicando acravés de um projeto. Se um líder civer idéias claras e fizer perguncas consistentes, ele incentivará os oucros a fazere1n o mesmo. U1na resposca a uma grande discussão co1n dezenas de pessoas pode cransmicir un1a onda de esclarecin1ento através da organização. Contudo, o líder prejudicará a possibilidade de u1na equipe se comunicar be1n, se expressar idéias difi.1sas e fizer argun1encações obscuras ou ofuscadas.

Um grande desafio é o faco de que poucas pessoas ad1nicem que envia1n péssimas mensagens de email. (Sua impossibilidade de reconhecer essa ocorrência explica, em parte, por que escrevem tão mal.) Por exemplo, faça o seguinte teste: usando seu próprio discernimento, que porcentagem do email recebido em sua organização é de alta qualidade? Média qualidade? Totalmente inútil? Agora, pergunte a si mesmo que porcentage1n do email enviado por você se enquadra em cada uma dessas categorias. A título de experimentaçáo, certa vez eu fiz essa mesma pergunta a um pequeno grupo de GPs, testadores e programadores. Por um fator de quase 2 por l, todos argumentaram que as outras pessoas escreviam uma mensagem de email muito pior do que a que eles redigiam . Co1no trabalhavam em conjunto, esses dados pitorescos indicavam que rodos achava1n que o problema escava no email gerado pelos outros, não por eles mesmos. Não tenho dados 1nais sólidos para respaldar essa argu1nentação, mas 1ne parece verdadeira. De alguma maneira, quando ocorre uma falha de comunicação, a média das pessoas tende a culpar os outros (para obter mais evidência, consulte qualquer história de política internacional ocorrida na civilização ocidental).

A boa peça de email

Um hábito que assi1nilei na Microsoft foi a reco1npensa pela boa peça de email. Muitos debates importantes ocorrian1 por email, e era comum nessas discussões a inclusão de pessoas de vários níveis na hierarquia; GPs de linha, gerentes de nível médio e VPs podiam trocar nlensagens de un1 lado para o

208 A.ÁRTE DO GERENCIAMENTO DE PROJETOS

outro, tratando-se rnutuamenre com igualdade. Geralrnenre, eu rnesrno intermediava esses debates, norrnalmente porque algo de minha responsabilidade de repente ganhava i1nporrância para a Divisão.

Uma vez ou outra, nessas discussões por ernaif, eu fuzia un1a argurnenração realmente forte em resposta a algo que alguém tinha dito. Escolhia as palavras com cuidado, revisando várias vezes para que estivesse tudo certinho: simples, forte e claro. En1 seguida, eu enviava. ÀJ; vezes, meus argumentos eran1 rasgados; outras vezes, ignorados. Mas ocasionalmence, eu marcava um gol de placa. Quando isso acontecia, geralmence eu recebia uma mensage1n de ernail particular, alguns minutos depois, de urn VP ou de "outra pessoa muito mais importante do que eu", contendo apenas duas palavras: "Bom email". A discussão podia até seguir em frente, mas eu sabia que ganhara alguns pontos na argumentação. O mais importante era o seguinte: alguém usou o seu tempo para que eu soubesse que minhas argumentações eram boas, e que eu as estava expressando de modo louvável. 1

Gerentes intel igentes valorizam o bom e1nail. Eles lêem tantos emails mal redigidos todos os dias, e se eles não arranjare1n um ternpinho para elogiar aqueles que se comunicarn bem, provavelmente não verão oucras pessoas fazerern isso. Breves comentários por email com críticas posicivas dernoram cerca de 15 segundos para serem enviados, e remontando à minha história, podem significar rnuito mais para as outras pessoas e1n sua organização do que você supõe.

Elogiar os outros é mais fücil do que assumir a responsabilidade pelos próprios hábitos de 1naus ernails. Co1no mencionado anterionnente, estou convencido de que a rnaioria das pessoas acha que escreve emails melhores do que os oucros (e quanco rnais sênior você for, canco mais difícil será receber um cornenrário honesto sobre a sua eriquera ao enviar ernails). Corno os líderes e gerentes enviam mais emails do que os outros, é crítico que você identifique seus maus hábitos e invista energia para contê­los. A seguir alguns conselhos ao estilo gerenciamento de projetos sobre como é um bom email e sobre alguns .maus hábitos comuns.

• Ser conciso, simples e direto. Pascal, o matemático cujo nome foi atribuído à linguagen1, escreveu certa vez que "se eu tivesse mais tempo, escreveria urna carta mais curta". Assim como no código, a linguagem pode ser otimizada, mesmo que os objetivos sejam diferences. Em vez de otimizar para a eficiência lógica, convém fuzer isso para a eficiência da comunicação. Diferentemente do código, uma rnensagem de crês palavras grarnarical e logicarnenre correra será inútil se o desrinarário não entender o seu significado. 2 Pense em quem está lendo o email e como você explicaria ou perguntaria o que precisasse dizer, se estivesse conversando cara a cara com essa pessoa. Que detalhes seriarn necessários? 01nicidos? Que conceitos você acha que o destinatário conhece? Que rnecáforas pode usar? Para u1n email irnporrance, pare urn pouco por alguns inscances e, em seguida, releia-o, rendo em visca essas perguntas, antes de enviá-lo. Ou para urna correspondência irnportanre ou urna correspondência enviada para um grande número de pessoas, peça a uma das pessoas de sua equipe que passe os olhos e lhe dê u1n retorno.

• Oferecer uma ação e um prazo-lim ite. O melhor ripo de email tern uma intenção específica ou uma solicitação claramente declarada e, se adequado, é atrelado a um prazo-limite aceitável. Ele deve facilitar para as pessoas que o lêem entender o motivo pelo qual o estão recebendo, de que modo são afecadas

COMO NÃO INCOMODAR AS P ESSOAS: PROCESSO, E1vtAlL E REUNIÕES 209

pela ação e o que devem fazer (ances do prazo-limice). Presu1nindo que você o imponha ("As solicicações devem ser enviadas para 1nim acé sexca-feirà'), prepare-se para conscacar pessoas acencas às fucuras ações informadas por você via email, que o colocarão em u1na posição de poder.

, • Atribuir prioridades. E realmence necessário enviar esse emaiP. Quanto mais

emails você enviar, tanto mais trabalho os outros terão para priorizar as suas solicitações. Quantos dos itens n1encionados são importantes? Se você te1n l O questões a serem discutidas, divida-as e1n dois grupos e concentre-se no grupo 1nais imporcance. Pondere se alguns assuntos podem ser cratados de modo mais eficiente por telefone, na próxima reunião do grupo ou batendo de porta em porca. Se você não priorizar, os destinatários o Farão - de 1nodo a atender aos interesses deles, e não aos seus.

• Não presumir que as pessoas lêem qualquer coisa (principalmente se for importante para você). É uma arrogância pressupor que pelo faro de você ter enviado uma mensage1n, alguém cer<Í que ler. As pessoas recebe1n caneladas de emails cedos os dias, uma boa parte procedente de pessoas cão i1nportantes quanto você. Quanto rnaior for a i1nportância do assunto, mais energia deverá gasear para garantir que as pessoas efetivan1enre o exa1ninem e façam alguma coisa etn relação ao assunto. Quanto mais confiável você for para as pessoas de sua equipe, 1nais pressuposições poderá fazer sobre o rnodo como as pessoas responderão às suas mensagens.

• Evitar os comentários descritivos. É raro alguém precisar saber a seqüência de eventos que fazen1 alguma coisa acontecer. Evice escrever emails que enfoquem as ações de colaboração de diferentes participantes: "Quando Sally elaborou pela primeira vez nosso processo de compilação, ela escava interessada ... " ou uma prosa orientada por narrativas, como "A reunião começou bem, com Bob e Sreve conversando através de seus slides, com muita paixão e convicção. Isco é, até ... ". Em vez disso, enfoque o impacto: o que aconteceu, de que modo isso muda o mundo e o que faremos em relação a isso. Se você for obrigado a incluir decalhes minuciosos, liste-os abaixo dos pontos críticos. O rnesmo se aplica às referências às apresentações de slides, sites, documentos ecc. Pennita que todos dêem u1na olhada nas duas pri1neiras linhas e saibam imediacamence se é suficiencemence imporcance para concinuarem lendo.

• Remover FYis. Já escive e1n equipes que insisciam em enviar enxurradas de emails quase-inceressanres-mas-irrelevances-para-cudo. Algun1as pessoas os denominan1 FYis, ou email para-seu-conhecimenco. A curiosidade e o conheci1nenco do secar são bons hábitos, mas não lhes permicem do1ninar os fóruns de co1nunicação utilizados para o trabalho 1nais cangível. Configure um alias de ernail ou tun grupo de discussão para "tendências do setor" ou "observações técnicas", onde sua equipe possa colocar as coisas interessantes que encontrarem. Se seu clience de email oferecer suporte para esse recurso, peça a cedos que definam esses tipos de emails con1 baixa prioridade ou adicione "FYI:" no início da linha do assunto. Torne esse 1narerial fiícil de ser filtrado pelas pessoas.

• O telefone é uni amigo. Se em algum mo.mento você não entender algo em um ernail importante, não responda com urna pergunta elaborada ern cinco partes. Procure entrar em contato com o remetente do email via telefone. A comunicação interativa é sempre mais eficiente para resolver confusões e conAitos do que o email. Uma conversa ao telefone de 30 segundos geralmente equivale a uma extensa série

210 A ARTE DO G ERENCl1\MENTO DE PROJ ETOS

de trocas de emails dernorados. Se você realmente alcançar o remetente via telefone e resolver o problerna, poderá cornpartilhar seu encendirnenco esclarecido e1n urn ernail enviado para rodos: muito provavelrnence, se você escava confuso, os ourros tainbé1n estavam. Os telefones (ou esticar suas pernas no corredor) são excelentes expeditores de co1nunicaçáo por email e1n grupo.3

Exemplo de um email ruim

É fácil reconhecer o email rnal feito. Esse tipo de ernail geralinence é muito extenso, rnal-escrico, cern n1uicos anexos e é difícil de visualizar. Ele pode ser localizado de longe e normalrnence é ignorado ou adequadamente desafiado: "Fred: achei esse email muito confuso. Se os outros concordarem, você poderá revisar ou convocar u1na reunião? Caso contrário, ligarei para você. Obrigada." Por esse 1notivo, o email 1nal feito náo é o tipo n1ais perigoso.

Os emails realrnente perigosos são aqueles que parece1n urna comunicação bern escrita, mas, na realidade, estão repletos de distrações, pensamentos inco1npletos e ambiguidades. A seguir, dois exernplos do 1nes1no email: urn mal feiro e o outro bern-feico. Eis o ruim.

De: Jack Colono Para: Equipe de desenvolvimento do Striker Assunto: Resumo de discussões recentes sobre verificação

Nas quatro últin1as semanas, vários de nós questionaram quando o processo de reelaboração dos procedimentos de verificação de nosso código estaria finalmente concluído. Sei que demorou rnuito tempo e que houve diversos debates pelos corredores e ern reuniões sobre o 1nodo correto de e1npreender a decisão, quanto 1nais para entender a real estrutura do novo procedimento cambé1n. A escolha dos 1ne1nbros da comissão não foi fácil para mim e como a rnaioria de vocês sabe, levou rnais tempo do que o previsto. Larnento por . . isso, mas essas corsas aconcecern .

Sendo assim, prirneiramenre gostaria de apresentar alguns destaques de nossa nova proposta, caso alguém tenha perdido unia das discussões semanais realizadas, ou não chegou a conversar comigo sobre essa proposta nas duas últimas sen1anas:

1) As verificações são muito importantes. Elas determinam o que estamos realmente construindo.

2) Todos têm opiniões. Todos nós ouvimos Randy e Bob descreverem detalhadamente por que consideravam o sistema atual péssimo.

3) Não há respostas fáceis. A maioria das mudanças discutidas pode não atingir as expectativas. Assim, quando finalmente chegarmos a uma conclusão, haverá algun1as arestas para esn1erilhar durante a transição e, possivelmente, de forma constante.

Fora isso, gostaria de inforinar a vocês posterionnente, nesta semana, que estarei enviando a proposta revisada. Aguardem o próximo email enviado por mim. Ele virá em breve.

Obrigado, - Jack

COMO NÃO INCOMODAR AS P ESSOAS: PROCESSO, EJ\1/1/L E REUNlÓES 211

Exemplo de um bom email

Diference1nence do exemplo do 1nau email, esce não conca quaisquer hiscórias nem tenta justificar coisa algu1na: é todo atitude. É curto, claro e vai direto ao assunto . . E1n vez de falar sobre propostas, ele efetivan1ente oferece tuna. Ainda que parecido com un1 ultimaturn, atende aos propósitos de criar uma velocidade de escape para a proposta, ajudando a in1plen1entá-la.

De: Jack Colono Para: Equipe de desenvolvimento do Striker Assunto: .Novo processo de verificação

A proposta final para o novo processo de verificação está concluída e encontra-se no site: http://intman/proc/checkin/.

Por ser uma questão controversa, discuti essa proposta isolada1nente co1n a maioria dos integrantes da equipe e incorporei os co1nencários de rodos. Se seus comencários não foram incluídos e você civer opiniões forces, envie-me um ernail o mais rapidamence possível.

Mas saiba que esca é a segunda notificação pública sobre as 1nudanças vindouras. Atualmence, há poucas oporcunidades de fazer 1nudanças, e essas oportunidades estão sendo reduzidas a cada dia que passa. Tome un1a atitude agora ou prepare-se para ficar calado.

Sexta-feira - 17 h é o prazo-limite para me entregar seus comentários sobre a proposca acima. Examinarei seu material e responderei a rodas as perguntas ou con1encários levantados até lá (em conjunto com o pessoal pertinente). De outra fonna, esse assunto está encerrado e entrará em vigor na próxima se1nana.

Obrigado, -Jack

Tão clara quanto a diferença entre esses dois emails deve ser, não considere esses exemplos definitivos. Eles não devem ser modelos para coisas que nunca ou sempre devem ser feicas. Cada ernail enviado pode ter uma finalidade diference e pode, por algu1n motivo, contradizer esses exe1nplos. Desde que você pense be1n ao escrever e inclua 1notivos claros, fuça o que for necessário pan1 concluir seu serviço. Mas procure se1npre maneiras de ir direto ao assunto e use o email para fazer as coisas acontecere1n.

Como realizar uma reunião não-irritante

Eis a n1inha confissão sobre as reuniões: não gosto de reuniões agendadas periodican1ente. Estou convencido de que, a inenos que haja um motivo n1uito forte para mantê-las objetivas e organizadas, em algum momento elas se tornarão uma imensa e frustrante perda de tempo. Entretanto, se esse motivo force exiscir, as reuniões poderão ser experiências energizanres e centradas para rodos os presentes na sala. O desafio é que quem quer que organize e realize a reunião deve saber o que está fazendo .

Para os iniciantes: entendam que as reuniões são dispendiosas. Se uma reunião durar l hora e l O pessoas comparecerem, essa reunião custará l O pessoas/

212 A.ARTE DO GERENC[AMENTO DE PROJETOS

hora. Em vez de corrigir bugs ou encerrar questões - duas fonnas garancidas de progresso - a equipe inreira escará crancada em u1na sala de conferência esperando que aconceça algo que co1npense o preço de seu rempo. Pode ser que aconreça, pode ser que não. Porranto, acho que os programadores e os outros têm razão quando reclamam das reuniões; em relação à i1nportância do ten1po diante de um computador, nem sempre o tempo gasto em reuniões dá bons resultados.

Contudo, se a reunião exigir a parcicipação porque entrarão em pauta idéias ou decisões in1portantes, porque revelará informações que mudarão a conduta das pessoas depois da reunião ou cransmitirão inspiração ou discernimento sobre o que está rolando no projeto, a importância da reunião será 1nuito maior. Em vez de uma chatice, será uma maneira de absorver ou trocar in formações difíceis de serem obtidas por outros meios.

A arte da facilitação

Anos atrás, lembro-me de ter participado de u1n grande debate sobre como iríamos arquitetar u1na parte i1nportante do Windows. Eu tinha chegado cedo e observava rodos entrando na sala e se senrando, elegantemenre confianres em suas opiniões. Observava-os recostarem-se para trás em suas polrronas e desfilarem seus argumentos em suas 1nenres, antes sequer do início da reunião. E evidenren1enre, questionar foi exatamente o que fize1nos. Durante 1 O minutos, a discussão rolou à vontade co1n grandes oscilações. Diagra1nas conflitantes fora1n violenta1nente rascunhados nos quadros brancos, 1nãos se1n controle n1ovi1nentavam-se e1n discordância, e declarações sarcásricas e pergunras de rerórica sobravam para rodo o lado. Finalmenre, 1neu gerenre de grupo, Hadi Parcovi, se levanrou. Ele andou silenciosamente até o quadro branco, na parte frontal da sala.

Sem pronunciar uma só palavra, ele começou a escrever uma lista de perguntas. Quando ele chegou à terceira pergunta, a sala estava em silêncio. Todos tinhan1 parado de questionar e observavam o que ele estava fazendo. Quando terminou, ele perguntou se as questões cercas escavam no quadro. Todos assentirarn. Em seguida, ele nos repassou rodas elas, uma de cada vez. Ainda existiam argumentos, rnas quando estruturados, foram drasticamente reduzidos. Hadi não nos deu a sua opinião (embora eu soubesse que ele t inha uma). Em vez disso, ele usou sua energia para ajudar a todos a navegar pelas questões com as quais concordávamos. Esra é a arce da facilicação.

Facilitar (v): aro de tornar as coisas faceis ou mais fáceis. As boas reuniões só acontecem quando alguém na sala sabe como fàcilicar.

Algumas pessoas fazem isso instintivamente, e outras não consegue1n sequer reconhecer quando isso já ocorreu. Assirn como oucr-as habilidades interpessoais, as pessoas têm níveis diferentes de consciência sobre as mais diversas formas de interação e sobre co1no influenciá-la.

Facilicar pode ser u1na função semifonnal, realizada por u1na pessoa designada que dá o show (geralrnente, o GP), ou por que1n convocou a reunião. Algumas equipes tê1n cultura de facilitação bastante forte (o que significa que vários integrantes possuem essa habilidade), que é possível até trocar natural1nente quem está dese1npenhando esse papel, ao longo da conversação. Mas quase sempre, na maioria dos projetos, as reuniões precisan1 desesperadan1ente de aptidão para facilitação.

CoMo NÃo INCOMODAR AS PESSOAS: PROCESSO, E1vvllL E REuNtóES 213

Indicadores para facilitação

A facilicação é un1a daquelas apcidões que algumas equipes negligenciam. Acé você trabalhar con1 um grupo de pessoas que efetivamente não se co1nunica1n ou até perceber que elas não esrão real1nente se co1nunicando, é fácil não dar imporcância ao que uma pessoa com esse talento pode fazer. Existem raríssimos livros4 e cursos sobre con10 facilitar, mas a n1elhor n1aneira de conhecer as habilidades envolvidas é observar alguém que faça isso be1n, e depois cencar aplicar o que observou na próxima reunião. Contudo, existem alguns indicadores que merecem ser mencionados. A identificação desses indicadores custou-me muito tempo, e eles contribuirão muito para ajudá-lo a desenvolver suas habilidades naturais de facilitação, sejam elas quais forem .

• Estabelecer uma posição de an fitrião. Se você é o organizador da reunião, é o facilitador. Comece a reunião apresentando as pessoas, esclarecendo a pauta, e iniciando a discussão. Se você se co1nportar como um anfitrião desde o mo1nento em que as pessoas entrarern na sala, elas se comportarão como hóspedes e o tratarão corn respeito. Escolha cuidadosa1nente onde se sentará na sala: sentar-se na ponta ou no centro de uma mesa geralmente lhe concede a mais alta postura de autoridade, e sentar-se nos cancos indica o concrário.

• O uvir e pensar. A principal função do facilitador é ajudar as outras pessoas a se comunicarem. Se alguén1 disser algo incompleto (mas não total1nente inútil), ajude-o a desenvolver o tema para tuna idéia amadurecida. Se Mike esciver com dificuldades de fazer uma argumentação junto à Molly, e se você tiver um 1nétodo direto para ajudar a expressar o assunto, faça isso. Experimente o truque da reflexão, declarando novamence o que as pessoas dize1n: "Então, Mike, o que você escá dizendo é <introduza u1n modo mais eficiente para Mike expressar seu tema aqui>. Concorda?" Isso aprimora o tema de Mike e demonstra para todos como tornar a discussão colaborativa. Contudo, tenha o cuidado de isolar seu desejo de defender as próprias opiniões: é difíci l ser um bom faci litador ou um bom ouvinte, se você se deixar apanhar por sua própria pauta pessoal. Algumas organizações concraca1n facilitadores profissionais que ajuda1n nas reuniões controversas e offiites. Identifique os bons facilitadores em sua equipe e convoque-os, se você acha 1nelhor expor determinado ponco de vista e não crê que consiga facilitar corn êxito, ao 1nes1no tempo.

• Direcionar a discussão. Tendo a pauta co1no referência, apresse-se em reco1nar a discussão, quando necessário. Seja flexível e deixe as pessoas falarem, mas se a conversa esciver indo para o sul quando a pauca indica o oesce, é necessário comar uma aticude. lncerro1npa educadamence, aponce para a pauca afixada na parede, e peça às pessoas que se acenha1n à discussão acuai aré que as questões agendadas seja1n abordadas (ou ofereça-se para ajustar a pauta se essa nova questão n1erecer) . Presre atenção e1n quem está falando demais e em quen1 não escá falando o suficiente, e tome as rédeas ("Bob, espere um segundo - Sreve, você ce1n algun1a opinião sobre isso?").

• E ncerrar a conversação. Tenha um limite em mente para quando uma questão deve ser interro1npida e solucionada em outro local. Em geral, basta identificar um problema e um responsável por ele, e peça a essa pessoa para prosseguir por

214 A.ARTE DO GERENCIAMENTO DE PROJETOS

conca própria e volcar no dia seguince ou dois dias depois, sugerindo uma solução. Essa é u1na 1naneira excelence de encerrar as discussões lacerais, empreendidas ao longo da reunião: "Muico be1n, dêem um ce1npo rapazes. San1 e Bob - vocês dois podem sair e destrinchar isso, ok? Depois, volre1n e informem o que decidiram". Nunca deixe duas pessoas tomarem conta do território, quando cinco ou seis outras pessoas se aborrecem durante uma hora.

• Preparar um histórico. lnvisca tempo documentando a discussão (se possível, à nledida que acontecer). Como u1n facilitador, isso o ajuda a controlar em que ponto da pauta você está e a infonnar ao grupo. Por isso, sou totalmente apaixonado pelos quadros brancos. São a maneira 1nais facil e flexível de captar o que as pessoas estão dizendo, criar listas de itens a fazer ou identificar pontos de concordância (e discordância). Mas não importa o modo como isso é feiro. O importante é que quando a reunião termina, as etapas seguintes e os temas relevances são regiscrados e enviados por email para os participantes da reunião. Alguns dizem que ser o anotador (escriba) é uma posição de poder porque você pode influenciar o modo como as coisas são registradas e quais aspectos devem ser enfatizados. Mesmo não sendo o caso, enviar anotações realmente concede u1na conotação de obrigatoriedade para as outras pessoas esclarecere1n algo exposto indevida1nente.

Ainda que você não concorde com esses indicadores, espero que eles o tenham ajudado a reconhecer que existe uma função de liderança a ser exercida nas reuniões. Se ninguém estiver exercendo ativamente essa função, as reuniões tenderão a ser assuntos frustrantes e/ou irritantes. O refrão geral é "Reuniões sugam as pessoas e devem ser evitadas", mas o verdadeiro problema é como as reuniões são realizadas, não a idéia das reuniões en1 si.

Três tipos de reuniões

A maior armadilha para os organizadores de reuniões é negligenciar a versatilidade da idéia de uma reunião. Ne1n todas as reuniões deve1n ser realizadas da 1nesma 1naneira ou devem ter a 1nes1na estrutura. O 1notivo pelo qual muitas reuniões aborrecem 90o/o das pessoas é o conflito entre os objetivos e a estrutura e o porte da reunião. Não é possível realizar discussões altamente interativas com mais de sete ou oiro pessoas, independentemente de quem esteja facilitando. Como regra geral, há crês tipos de reuniões, co1n diferences restrições e aplicações. Pondere se1npre sobre que ripo de reunião será a mais adequada ao problema que deve ser solucionado.

• Discussão altamente interativa. Todos na reunião supostamente devem participar. A n1eca é profundidade e relacionamento. O foco é explorar ou resolver questões específicas ou buscar idéias alrernativas. Porre: pequeno a médio (2-8). Exemplos: discussão sobre design, brainstormíng, gerenciamenro de . . cnse e trtagem.

• D iscussão de informe ou moderada. Uma pessoa tem um conteüdo para cobrir e necessi ta de pessoas que respondam por ou conheçam esse conteüdo. A meta é obter um feedback de alto nível ou compartilhar conhecimento. Isso pode ser alta1nente interativo, mas só ocorre em um subconjunto do grupo. Várias

COMO NÃo INCOMODAR AS P ESSOAS: PROCESSO, E1vvllL E REuNtóES 215

pessoas diferences podem co1nar a rédea duranre a reunião, 1nudando as funções de que1n escá oriencando e quem escá respondendo. Porce: 1nédio a grande (5-15). Exemplos: revisão de especificações, revisão da arquicecura, revisão administrativa e pequena apresentação.

• Revisão de status e do projeto. O objetivo é resumir o status de u1na equipe ou de um projeto inteiro. Oferece aos líderes uma oportunidade de implementar correções acentuadas e apresentar novas diretivas da gerência ao grupo inteiro de uma só vez. Quando essas reuniões abrangen1 a atividade de cobrar o status ou obrigar codos a ouvirem o relacório do scatus, geraln1ente elas são as experiências mais irritantes do universo conhecido. Porte: médio a grande (1 O­I 00). Exemplos: revisão de status, revisão do projeto, apresentação grande e reunião geral.

As reuniões mais diabólicas ocorrem quando há uma divergência entre as mecas e o modo como estão organizadas. Se mais de 1 O pessoas estiverem presentes na sala, será 1nuito difícil acontecer uma discussão alra1nente interativa ou profunda. Não há te1npo suficiente para todos participare1n e, no final das contas, u1n pequeno grupo de personalidades do1ninantes ocupará a maior parte do tempo disponível (a 1nenos que algué1n fàcilite a reunião para evitar que isso aconteça; contudo, ne1n sempre u1n pequeno grupo de personalidades dominantes é un1a ocorrência negativa). A 1naioria dos co1nirês se organiza dessa 1naneira e obtém resulrados que vão de mal a pior, como era de se esperar.

As demoníacas reuniões periódicas

A segunda reunião 1nais diabólica é a periódica (semanal, diária, mensal), que se arrasta por semanas apesar de não ser mais necessária (era impossível marcar reuniões em alguns prédios na Microsoft porque as reuniões periódicas abandonadas congestionavam o sistema de agenda1nento das salas de conferência). A recorrência é excelente porque impõe um ritmo ao trabalho e obriga as pessoas a se reunirem na mesma sala, ao mesmo tempo. Todo o tipo de pequenos proble1nas pode ser solucionado de modo rápido e ocasional, quando as pessoas estão fisicamente juntas, e podern contar corn esse encontro pessoal, uma ou mais vezes por semana. "Oi, Sam, eu ia mesmo perguntar a você ... esta API vai mudar? Vi sua verificação e acho que pode me afetar, mas não tinha certeza". Email e ligações telefônicas não garante1n respostas, 1nas quando a pessoa está sentada ao seu lado, normalmente você pode obter o que necessita.

O problema reside na facilidade co1n que as reuniões periódicas se arrasta1n após cessar a sua importância. Quando algun1as pessoas param de comparecer ou outras usarn seu ternpo para verificar e1nails em seus laptops, algurna coisa está errada; a reunião não garante mais o ten1po. O temor dos gerentes (e de outros organizadores de reuniões) geralmente é ter que cancelar a reunião, perdendo uma das poucas oportunidades de liderar a equipe co1no um grupo. Mas ao contrário, torturar as equipes com reuniões desnecessárias é con10 os gerentes perdem a credibilidade na liderança que eles tanto procuram proteger.

Eis uma boa regra: reuniões por adesão. Mantenha a reunião periódica no cronogran1a e peça a todos que procurem em seus en1ails uma paura, cinco minutos antes do suposto início da reunião. Se a pauta for consisrenre, o

216 A ARTE DO GERENCIAMENTO DE PROJETOS

organizador a enviará e o grupo se reunirá. Se não houver pauca, você enviará um email para rodos e a reunião será cancelada (nessa semana) . Isso concede à equipe urn incervalo reservado, se necessário, mas sem obrigar as pessoas a cornparecer a reuniões de enrolação. A recorrência deve ser roralrnenre cancelada se nenhu1na reunião ocorrer por n1ais de três ou quatro semanas.

Indicadores de reunião

Esta t'iltima seção traz uma lista de rácicas geralmence negligenciadas para conduzir e participar de reuniões com êxito. Não há nada sensual ou interessante relacionado: existem apenas determinados aspectos com os quais você tem que lidar, ao trabalhar com pequenos grupos de pessoas. Uma pessoa que comandou muitas reuniões terá sua !isca fuvorita de truques ou dicas: fora isso, espero que essa lista o ajude a. refletir sobre o que já funcionou para você.

• As pessoas certas estão presentes na sala? Algumas pessoas cornparecerão, se forem convidadas. Outras pessoas não virão, a menos que você dê um soco nelas e as arraste (e/ou as suborne com docinhos) . Grande parce do trabalho dos GPs é trazer a pessoa certa para a sala, na hora cerra; portanto, não terna sair pelos corredores ou penerrar ern outras reuniões, se a pessoa esperada em sua reunião não tiver chegado. Pior ainda: se você estiver tenrando iniciar un1a reunião e não conseguir trazer a pessoa certa, interrornpa a reunião. Não perca uma hora sequer do seu rernpo apresentando urn nlaterial que você precisará repetir no dia seguinte ou dois dias depois, quando finalmente houver quorurn. Por ülritno, se as pessoas certas comparecerem, mas você derecrar a presença de outras pessoas na sala, que não deveriarn estar lá, diga isso a essas pessoas. Seja diplomárico, ofereça-se para lhes enviar anorações ou o resumo, mas livre-se delas, principalmente se elas riveren1 a intenção de atrapalhar o seu ca1ninho.

• Sentado ou em pé. Um truque para encurtar as reuniões é fazer corn que todos fiquem em pé (por exemplo, uma reunião no corredor ou ao ar livre). Teoricamente, isso obriga as pessoas a ir direto ao assunto e a levantar questões realrnente importantes para a discussão do grupo. A reunião deve durar apenas 5 ou 1 O minutos, no máximo. O processo do SCRUM5 defende urna reunião diária ern pé, para fins de status, onde são feiras somente três perguntas: O que você fez desde a última reunião? O que o está bloqueando? O que você fará até a reunião de arnanhã? Com esse ripo de cornprornisso curro e grosso com reuniões enxutas, até mesmo o engenheiro mais excêntrico de.sejará participar. As reuniões sentadas tradicionais são reservadas para os grupos 111enores que tratam de assuntos específicos. Cotnpensa pelo menos fazer un1a tentativa: no mínimo, essa reunião incenciva as pessoas a considerarern que uma reunião agendada para durar tuna hora não precisa ocupar uma hora inteira.

• Prepare-se. Freqüenren1ente, as reuniões fracassam por falra de preparação. Leve se1npre em consideração quanto tempo de preparação será necessário para que urna reunião cumpra sua finalidade. Algumas vezes, esse tempo será mínimo: uma lista de perguntas ou questões em aberto, ou enviar um e1nail com a

CoMo NÃo INCOMODAR AS PESSOAS: PROCESSO, E,vvuL E REUNtôES 217

agenda, um dia an[es. Ou[ras vezes, será [rabalhoso: uma apresentação de slides, u1n de1no, apos[ilas gra1npeadas. Se1npre que uma reunião não for [âo bem quan[o você esperava, pergunre a si mes1no o que poderia ter sido feito de 1nodo diference. Na n1aioria das vezes, a resposta englobará alguma forma de preparação negligente. Um rruque é considerar esse aspecto ao enviar uma convocação para reunião, e acrescentar tempo em seu próprio calendário, antes da reunião, para fazer uma preparação adequada.

• Laptops e PDAs. Tenho uma forte tendência contra o uso de PDAs e laptops durante as reuniões. Se as pessoas na sala considerare1n que o que está acontecendo não é suficiente1nente importante para garantir toda a sua atenção, não deveriam estar na sala (a não ser que seja uma reunião do tipo revisão de status ou de projeto, onde há uma baixa relação sinal/ruído). O tempo da presença física é precioso e deve ser usado para os assuntos cuja importância as pessoas já reconhecem e que são dignos de seu [empo, enquanto o email e o correio de voz foram projetados para esperar. Se você tem uma opinião formada sobre isso, converse com os outros da equipe e veja se consegue definir uma política para o uso adequado dos laptops nas reuniões.

• Pont ualidade. Esta é u1na conduta orientada pelos superiores na hierarquia. Se os VPs e gerentes seniores costu1nam chegar tarde, todos chegarão. Se costumam ser pontuais, rodos o serão. Você pode tentar começar no horário para ter alguma vantagem, 1nas se as pessoas importantes ainda não tiverem chegado, só lhe res[ará reperir tudo assim que elas aparecere1n: é u1na causa perdida. Conrudo, se você esriver esperando por companheiros ou subordinados, experimente as táticas das contrariedades cênicas. Meu truque favorito é ligar para o escritório de cada pessoa que está atrasada. Se a pessoa ainda estiver lá, brinque com ela suavemente ao relefone, na frente de todas as ourras pessoas: "Oi, Sam. Estaremos honrados com a sua presença na sala de conferência 5". Se a pessoa não estiver no escritório, deixe uma mensage1n no correio de voz. Ligue o viva-voz e peça a todos na sala que falem em uníssono: "Amamos você, Sam!" ou cantem Parabéns a Você. Faça isso em todas as reuniões, para todos os atrasados ou lanterninhas. Comece a reunião com algo divertido - e um estímulo a mais para chegarem ponrualinenre.

• Encerre com as etapas claras e os respectivos responsáveis. Quando u1na reunião termina, rudo o que importa é o que acontecerá depois. Uma reunião pode ter sido a 1nais repulsiva, desagradável, violenta da história da humanidade, 1nas se sai r da sala com a lista cerra de cinco coisas que precisa1n ser feitas, e os non1es das cinco pessoas que concordaran1 e1n fazê­las, você obteve êxito. Nunca permita que as pessoas saian1 da sala sem um plano claro para a próxi1na etapa. Parce de sua preparação deve se basear e1n como você supõe que alcançará esse resultado e quem são as pessoas cerras para cada tarefa.

Resumo

• Os gerentes de projero são propensos a aborrecer os ourros. U1n parte desse aborrecimento pode ser evitada.

218 A ARTE DO G ERENCIAMENTO DE PROJETOS

• As pessoas se irricam por vários 1nocivos. Geralmence, quando percebem que perderam cempo, quando são cracados co1no idiocas ou quando suposca1nence devam suportar um longo cédio e maus cracos.

• Os bons processos cêm vários efeicos posicivos, inclusive acelerar o progresso e evitar problemas. Mas sua escrutura também é difícil de elaborar.

• O ernail não-irritante é conciso e factível, e permite que os leicores saiba1n rapidamente se foram suficientemente afetados, a ponto de precisare1n ler mais do que a linha do assunto ou a primeira frase.

• As reuniões transcorrem muito bem quando alguém as facilita.

• Reuniões frustrantes acontecem quando as metas são incompatíveis com o tipo de reunião.

Capítulo 11

O que fazer quando as coisas dão errado

220 A.ARTE DO G ERENCIAMENTO DE PROJETOS

I ndependentemente do que você fizer, do quanco você crabalhar, algumas coisas ainda não darão cerco. A melhor equipe do inundo, co1n os melhores líderes, crabalhadores, escímulos e recursos ainda se deparará co1n sicuações difíceis e i1nprevistas. A t'1nica n1aneira de evitar totaln1ente essas situações é não fazer nada importante ou colocar-se de modo consistente em situações e em projetos onde você esteja protegido contra todas as formas de risco -duas coisas que raran1ente contribuen1 para o êxito dos projetos ou dos gerentes de projetos.

"Todos os projetos be1n-sucedidos são apenas u1na longa seqüência de adversidades que devem ser superadas. Enfrentar adversidades não é incornum, é normal e faz parte de nosso trabalho superá-las. O verdadeiro teste não é obtermos êxito quando não há adversários, rnas quando eles existern e triunfa1nos. "

- Willia1n A. Cohen

Por esses motivos, os bons GPs devem escar preparados para lidar co1n sicuações difíceis. É necessária u1na cerca dose de sabedoria para perceber que quando coisas ruins aconcecem, elas acontecem. Nada poderá ser feito para alterá-las depois do ocorrido. Em vez disso, o modo como a equipe reage às adversidades pode represencar um facor de maior peso para o êxico do projeco do que a possibilidade de a equipe evicar as adversidades, antes de tudo. Ambos são importantes, mas a resiliência e a possibilidade de recuperação são os atributos que permitem lidar com o imprevisto. Sem esses atributos, uma equipe perfeita e um plano perfeito podem extrapolar o controle com um si1nples empurrãozinho na direção errada.

Este capítulo apresentará três itens: um guia rudimentar ou kit de primeiros socorros do que fazer quando as coisas derem errado, análises de como as pessoas e equipes reage1n às situações difíceis, e u1na cobertura das rácicas e abordagens para gerenciar em te1npo difíceis.

Aplicar o guia rudimentar

"Vócê pode culpar as pessoas que atropela1n as coisas no escuro ou pode co1neçar a acender velas. A culpa será realmente sua, se você estiver

ciente do problema e não fizer nada. " - Paul Ha,vken

Esta seção é uma cartilha simples sobre como lidar com as situações difíceis. Mais adiante, abordaremos algu1nas situações comuns e daremos conselhos específicos, mas este guia geral deve ajudá-lo a resolver o que o fez folhear estas páginas até encontrar esce capítulo.

1. Acalme-se. Nada piora mais un1a sicuação do que basear suas atitudes e1n medo, raiva ou frustração. Se algo ruim acontecer, você sentirá essas e1noções, quer esteja consciente delas ou não. Elas ca1nbém influenciarão seu raciocínio e comporramenro, quer saiba disso ou não. (Regra geral: quanto menos

O QuE FAZER QuANDO AS Co1sAS DÃO ERRADO 221

consciência civer dos seus sencimencos, canco mais vulnerável estará à influência deles e1n sua vida.) Não se esquive ne1n renha u1n ro1npance; seja pacience, 1nancenha a respiração e fique acenco.

2 . Avalie o proble1na em relação ao projeto. Só porque alguém 1nais acha que o céu despencou, isso não significa que ele renha despencado. Traca-se realmente de um problema? De quem é o problen1a? Quanco do projeto (ou das respectivas metas) está en1 risco ou pode precisar de mudanças devido a essa situação: 5º/o, 20o/o, 90º/o? Tire uma perspectiva do que aconteceu. Alguém morrerá por causa desse erro (você não é um neurocirurgião, certo?) Alguma cidade será dernolida? Pragas será.o lançadas sobre inocentes? Ajude todos a enquadrar o proble1na na escala emocional e intelectual certa. Faça muitas perguntas e faça as pessoas pensarem em vez de reagirem. Esforce-se para eliminar as pressuposições. Cercifique-se de cer um conhecimenco tangível do problema e de seu verdadeiro impacto. Depois, priorize: emergência (agora!), grande preocupação (hoje), pouca preocupação (esta semana ou na próxirna), enrolação (nunca). Saiba quanto tempo seu fusível agüenta para responder e priorizar esse novo problema e1n relação a todo o trabalho já existente. Se for uma questão de enrolação, certifique-se de que quern quer que tenha dado o alarme aprenda novas perguntas que deve1n ser feitas antes de levantar a bandeira vermelha novamente.

3 . Acalme-se outra vez. Agora que você já tern algurn conheci1nento do problema, talvez fique irritado ("Como esses idiotas deixaram <insira a coisa incrivelmente estúpida aqui> acontecer!?") . Dê um jeito de expressar suas emoções de modo seguro: berre a céu aberto, se exercite na academia ou troque uma idéia com um amigo. Mas realn1ente procure expressá-las. 1

Descubra o que funciona para você e use esse recurso. Depois volte ao problema. Lembre-se de que você precisa não so1nence estar calmo para tornar boas decisões, como também a sua equipe precisa se acalmar. Preste atenção em quem está preocupado ou aborrecido e ajude essa pessoa a sossegar. Humor, franqueza, comidas e bebidinhas são sempre bons locais para se começar. Se você é um líder, estar calmo e ter sangue frio contribuem muito para acalmar os outros. E assumir a responsabilidade pela situação (consulte a seção posterior "Assu1nir a responsabilidade"), a despeito de quern seja a falta, costurna agilizar a recuperação de uma equipe em relação a um problema.

4. Reúna as pessoas certas. Qualquer proble1na grande não afetará sornente a você. Identifique que1n são os mais responsáveis, interessados e úteis perante a situação, e reúna-os e1n uma sala (ou convoque urna conferência) imediatarnente. Recrute-os de todas as outras reuniões e tarefas: se é urgente, acue corn urgência e interrompa ou livre-se de cudo o que bloquear o seu caminho. Acornode-os, feche a porta e aplique o que aprendeu na etapa 2 . Mantenha esse grupo o menor possível; quanto mais controversa ou complexa for a questão, tanto menor deve ser o grupo. 2

Além disso, considere que (geralinente) você pode não fazer parte desse grupo: reúna as pessoas na sala, informe o problema e, em seguida, passe a palavra. Ofereça seu apoio, mas saía da frente deles (encenda bem - saía da sala se você não for necessário) . Identifique clararnente quem está

222 A.ARTE DO GERENCIAMENTO DE PROJETOS

encarregado de oriencar a solução dessa quescão (consulte "Funções e aucoridade clara", 1nais adiance neste capículo), quer seja você mes1no ou oucra pessoa.

5. Explore as alternativas. Depois de responder a codas as perguncas e esclarecer a situação, identifique quais são suas opções (consulte o Capítulo 8). Às vezes, isso pode exigir alguma pesquisa: passe a boia. Assegure-se de que a questão seja considerada urgente, se necessário; não pressuponha que as pessoas entendem a urgência de algun1a coisa. Seja o n1ais específico possível en1 suas expecrativas em relação a quando as respostas serão necessárias.

6. Use o plano mais simples. Pondere as opções, escolha a melhor delas e crie um plano simples (ou nova1nente, se for adequado, passe a bola). A rnelhor opção disponível é a 1nelhor opção disponível, independentemente do quanto possa exigir (uma crise não é o momento para idealismos). Quanto mais urgence for a questão, canto 1nais simples e mais óbvio deve ser o plano. Quanto maior for o buraco em que você se enconcra, tanco mais objetiva e arrojada deve ser a trajetória para sair desse buraco. Divida o plano na quantidade de etapas sin1ples necessárias para assegurar que ninguérn fique confuso. Faça duas listas de pessoas: aquelas cuja aprovação do plano é necessária, e aquelas que devem ser informadas do plano a ser execucado. Dirija-se ao priineiro grupo, apresente o plano, examine os co1nencários dessas pessoas e obcenha o apoio delas. E1n seguida, crans1nica essa informação ao segundo grupo.

7. Execute. Faça acontecer (consulce o Capfrulo 13). Verifique se quem está realizando o trabalho esteve envolvido no processo renha fa1niliaridade e conheça quase de modo obsessivo o motivo pelo qual está fazendo isso. Não há espaço para premissas ou ambigüidades. Tenha checkpoints (a cada hora, diariamente, semanalmente) específicos para. garantir que o plano surta o efeito almejado e para obrigá-lo e os outros no comando a considerare1n todo o esforço extra que deve ser investido na questão. Se novos problemas realrnente surgirem, comece novamente da etapa 1.

8. Faça uma reto1nada. Após controlar o incêndio, relÍna as pessoas cercas na sala e faça uma lista das lições aprendidas. (Este grupo pode ser diferente daquele das pessoas certas da etapa 4 porque convé1n incluir as pessoas afetadas, mas não envolvidas, pelo processo de decisão.) Pergunte: o que pode1nos fazer na próxi1na vez para evitar tudo isso? Quanto n1aior for o problema, mais respostas você receberá para esca pergunta. Priorize a !isca. Pense e1n quen1 deve ficar responsável por garantir que cada u1n dos . . . pnn1e1ros itens aconteça.

Situações comuns previstas

Nos projetos, ocorre1n inevitavelmente determinadas situações ruins. Grande parte do contetído deste livro versa sobre como minimizar a probabilidade dessas situações acontecerem, assim con10 minimizar a sua gravidade, se for o caso. Mas o universo é um lugar difícil para os projetos, porque há mais chances de ocorrerem erros do que acertos. Quanto maior for o ntímero de

O QuE FAZER QuANDO AS Co1SAS DÃO ERRADO 223

projetos ern que você trabalhar, canto rnaior será a probabilidade de enfrentar as situações aqui !iscadas, rnas tendo a chance de aprender antecipadatnence como lidar com elas.

Minha prirneira situação verdadeira1nente difícil aconteceu en1 1996, quando eu estava trabalhando nos recursos de controles disponíveis aos pais, do IE 3.0, minha primeira grande área de responsabilidade. Estávamos trabalhando no suporte ao padrão W3C para os sisten1as de controle dos pais, cenrando ser o prin1eiro navegador da Web a fazer algo importante para tornar a Web "segura". Na minha opinião, o projeto escava indo bem, até a nossa primeira reunião de revisão. Foi um desastre cotai. Das l O pessoas presentes, 9 pareciam tão decepcionadas com as minhas respostas às suas perguntas, que literalmente pararam de me ouvir. Todas essas pessoas eram desenvolvedores e arquitetos experientes, e suas perguntas eram muito superiores às minhas respostas. Tudo parecia errado: as pessoas berravam e 1ninha equipe escava desmoralizada. En1 dez 1ninuros de reunião, eu sabia que era urn desastre. Vinte rninutos de reunião, minha vontade era surnir. Depois de uma hora, eu não conseguia ficar ern pé.

Às vezes, o pessoal da Microsoft charna isso de prova de fogo . A idéia é que o trabalho é árduo e não há luvas de pelica. As perguntas são ríspidas e as expectativas, altas. Lembro-me muito bem desse dia porque foi a primeira vez que entendi de vez quanto raciocínio era necessário para se fazer um bom trabalho. Eu já tinha ouvido experiências sernelhantes, mas até acontecer comigo, eu não fazia idéia. Depois disso, tudo ficou claro: rneu serviço era fazer as coisas funcionaren1 suficiencernence ben1, para que tuna reunião como aquela jan1ais voltasse a acontecer.

Em 1ninha experiência treinando outros gerentes, aprendi que é difícil para as pessoas relacionarem-se totalmente com um problema que elas mesmas não enfrentaram (outro m.otivo pelo qual devem ser usadas simulações nos treinamentos). A despeito de quão fácil seja relacionar-se com a história de outra pessoa a respeito de reajustes de cronograma ou alteração de requisi tos, tentamos acreditar de alguma maneira que estamos imunes. Ou mais exatamente, que os problernas ocorridos (ou que estão ocorrendo) era1n t'rnicos de alguma forma, que os tornava inevi tiiveis e diferentes de tudo o que as pessoas já tinham enfrentado.

Porcanco, ern urn aro de puro otimismo, darei a você, caro leitor, urna lista de situações difíceis comuns. Sendo assim, examinar essa lista pode ajudá-lo a reconsiderar as experiências que enfrentou, assim como aquelas em que se encontra atualmente.

Como saber se a sua situação é difícil

No que diz respeito aos projetos, para tnirn, uma situação é difícil quando acende a um dos seguintes critérios:

1. l-lá un1a grande lacuna entre o plano atual e a realidade. ("Supostan1ente devernos liberar para a Web etn uma hora, mas Fred inforn1a que o banco de dados de clientes inteiro está danificado, está faltando energia e a equipe de programação escá bêbada.")

224 A.ARTE DO G ERENCIAMENTO DE PROJETOS

2. As coisas estão confusas quanto à extensão da lacuna, o que a está causando, que1n é responsável por solucioná-la ou, possivelmente, se ela sequer existe. ("Que iceberf. Não vejo nenhum iceberg.")

3. Indefinição quanto ao modo co1no os recursos devem ser aplicados para solucionar a lacuna. Há temores de que tomar uma atitude ou não fazer nada possa piorar as coisas. ("Não fique af parado, fàça alguma coisa! Espere aí -não faça nada, aguarde!")

O comentário enganoso em relação a essa lista é que para alguns projetos demoníacos, essas peculiaridades devem ser aplicadas desde o primeiro dia. Muito justo. O que é status quo em urna organização pode ser uma simulação de incêndio em outra. Enquanto faz parte do gerenciamento de projetos minimizar o caos - pelo menos enquanto forem apenas problemas específicos, ern momentos específicos, e não u1na característica geral do a1nbiente de trabalho - rodos nós sabemos que, às vezes, a gerência não consegue realizar seu trabalho (insira o segundo co1nenrário enganoso aqui). Diro isso, o aconselhamento deste capítulo se aplica igualmente be1n, a despeito da freqüência com que você necessite aplicá-lo. Mas se você estiver lendo este capítulo com freqüência, calvez esteja na hora de procurar outro gerente ou local de trabalho.

A lista de situações difíceis

.É possível aplicar o guia rudin1en tar, apresentado no início desce capítulo, a todas as seguintes situações, embora os domínios e as habilidades em questão possam ser diferentes. A título de referência, incluí algumas respostas possíveis a sere1n consideradas (assunto da etapa 5, "Explore as alternativas", no guia rudi1nentar) para cada urna dessas situações:

• Omissão ou concepção. A maioria das coisas erradas ocorridas nos projetos são atos de 01nissão ou 1nenosprezo. Un1a decisão tornada há dias ou se1nanas não funcionou e agora algo não funciona também. O problema é que o cronograma e/ou o requisito permanece: para atendê-los, é necessário fazer alguma coisa nova. (Compilações diárias ajudam a concretizar essas concepções logo no início e não depois.) Respostas possíveis: n1ude os requisitos, mude o cronograma, de 1nodo a reimplementar (corte o próximo recurso de prioridade mais baixa) ou, se necessário, explore novas alternativas de design. Se você explorou o design (consulte os Capítulos 5 e 6), calvez exista um bom design alternativo de reserva, que seja bem­conhecido.

• Você (ou sua equipe) é obrigado a fazer algo idiota. Isso pode ocorrer por vários 1nocivos, e o 1nais óbvio é o resultado de uma decisão da gerência ou um cliente que se recusa a ad1nitir um aspecto do problen1a. (Embora ocasionalmente uma falta de recursos nos obrigue a tomar decisões reconhecidamente ruins.) Isso é frustrante porque você conhece muito be1n a situação, mas não tem poder suficiente para Í.'lzer alguma coisa. Respostas possíveis: saiba que você está em uma annadilha ad1ninistrativa. Se realmente se esforçar para obter êxito de algu1na fonna, apesar da decisão estúpida, você sení

O QuE FAZER QuANDO AS Co1sAS ÜÃO ERRADO 225

colocado na mesma si[uação novamen[e, no fu[uro . Se fracassar, será culpado por nunca [er acredirado. Assi1n, se este for u1n problema crônico, invista 1nais tempo gerenciando para cima (consulte o Capítulo 16). Priorize suas objeções, tenha reco1nendações específicas e use suas habilidades políticas e de negociação (consulte "Solução de conflitos e negociação", mais adiante neste capítulo) para buscar um compromisso. Você não vencerá, mas até encontrar un1a gerência mais eficiente, poderá proteger sua equipe e a si mes1no. Tente isolar a idiotice em um recurso ou n1arco, onde faça nlenos estrago (consulte a seção "Controle de danos") .

• Descomprindo o cronograma ou falta de recursos. Sempre que a probabilidade de cumprir a próxima dara ficar abaixo de 75º/o, as datas não serão mais , prováveis. E possível, mas improvável. Respostas possíveis: consulte os Capítulos 2 e 14. Trata-se dos critérios de saída e das respectivas prioridades i1nplícitas. Ou você corta recursos, amplia o prazo no cronograrna ou ignora toda a lógica conhecida, registra seu úlcimo desejo e o testamento, e tenra cumprir a próxima data de qualquer maneira. Procure realmente considerar se o risco do cronograma pode ser isolado e deslocado do ca1ninho crítico, ou se pode ser negociado e1n u1n próximo marco por algo considerado rnenos importante. A Lei de Brook3 afirrna que acrescentar pessoas por ocasião de tropeços nos cronogra1nas pode ser 1nenos valorizado do que se espera.

• Baixa qualidade. Não é possível saber se a qualidade é má, se não se conhece o nível de qualidade pertinente. Se estiver usando compilações diárias ou se algu1nas 1nétricas forem freqüenre1nenre rastreadas (conrage1n de bugs etc.), você saberá con1 antecedência. Existem vários tipos de má qualidade: código frágil, inobservância no atendimento aos requisitos, desen1penho deficiente ou instabilidade. Há também várias causas da má qualidade: engenharia (principais práticas de desenvolvin1ento), processo (check-ins e ferramentas) ou cronogran1a/planejamento. Respostas possíveis: confirme se a equipe sabe qual é a boa qualidade e defina metas cotidianas para isso (consulte o Capítulo 15). Sacrifique alguma coisa (recursos, tempo) para obter mais qualidade. Geralmente, é melhor retardar o ri rmo do progresso até que o padrão de qualidade renha sido a.lcançado e rodos saibam como atender a esse padrão, depois volte a acelerar o ritmo.

• Mudança de rumo. A gerência ou o próprio mercado pode exigir u1na 1nudança no rumo do projeto. Isso não é necessariamente ruim para o projeto (pode ser até u1na fonna de progresso) - apenas é improvável que seja divertido. Podem ser necessários cortes de orçan1ento ou novas 1netas de alto nível. Respostas possíveis: pode-se evitar a 1nudança em certos componentes? Identifique as especificações ou partes de especificações ainda viáveis, e as mantenha no pipeline do desenvolvimento (consulte o Capírulo 14), depois priorize o que deve ser alterado. Cercifique-se de que não esteja sendo ditado pelo seguince: ser instruído a "fazer X" não é o mesmo que "Ten1os que aumentar a receita em 10%". O primeiro é uma diretriz; o último é um problema a ser solucionado. Esforce-se por detectar os problemas e participe propondo soluções palatáveis (consulre "Solução de conflitos e negociação", mais adiante neste capírulo).

• Problemas na equipe ou pessoais. Uma ou mais pessoas estão aborrecidas com alguma coisa, e isso afeta negativan1ente a equipe. Pode ser no nível

226 A.ARTE DO GERENCIAMENTO DE PROJETOS

pessoal ("Não posso continuar trabalhando cotn Fred") ou no nível sistêmico ("Odeio o modo co1no fazemos as revisões de código"). Respostas possíveis: comece conversando com cada pessoa envolvida. Pergunce o que está aconcecendo e o que pode ser feico (por você ou por essas pessoas) para melhorar as coisas. Descarregue o problema e deixe as pessoas desabafarem. Procure as causas, não apenas os sintomas (consulce "Solução de conflitos e negociação", nlais adiante neste capítulo).

• Discordância e conflito. As pessoas discordam abertamente sobre o que deve ser feito (o que pode ser saudável), mas agora as discordâncias escão impedindo o progresso. Gasta-se mais tempo debatendo e reexan1inando constantetnente o que deve ser feito, ern vez de fazer. Ern casos excrernos, !·acções discintas estão trabalhando secretamente em di fe rentes direções. Respostas possíveis: consulte a seção "Solução de conflitos e negociação", rnais adiante neste capítulo.

• Falta de confiança. A equipe sirnplesmence não acredita no rumo do projeto. Os membros escão realizando o crabalho, progredindo, sem discordarem acivamence, mas acham que o navio escá indo direco para u1n iceberg. Alcernativas possíveis: verifique se eles estão certos. Se não estiverem, use sua influência (consulte o Capítulo 16) para ajudar a respaldar esse ru1no. Comece por baixo: que1n escá acreditando mais? Como você pode angariar a confiança dessa pessoa e cransmici-la ao restante da equipe? Tente definir 1netas menores para a equipe e gerar incenrivos. Bata de porca em porca e peça o apoio das pessoas: "Olhe aqui, sei que você não acredita nisso, 1nas eu acredito. Existe algo que eu possa fazer para convencê-lo a apoiar? Se não houver, você pode confiar em mim, pelo nlenos na próxin1a semana?"

• Ameaças de motim. Essa é a forma crítica e violenta de falta de confiança. A frustração da equipe chegou ao limite e seus integrantes reagem mal a todo problema novo surgido, por mais insignificante que seja. Além do mais, as pessoas reclamam mais dos meta-problemas (por exemplo, "por que a gerência/testei marketing continua fazendo isso?") do que dos problemas reais. Se não for coinada u1na atitude, os veteranos podem apoiar as reclamações, e podern despontar pequenos atos ou simbólicos de subversão (por exemplo, de repente, pode se tornar difícil corrigir determinados bugs) . Algué1n precisa tomar a frente e desar ticular esse motim. Torne pública essa quescão, faça uma !isca de codas as reclamações e solucione visivel1nente pelo menos alguns itens da lista.

Boa parte do que pode dificultar essas sicuações não é a situação e1n si, 1nas o contexto no qual ela ocorre. Quanto 1nais tardio no cronograma um proble1na acontecer, e quanco 1nais baixa estiver a 1notivação da equipe (ou do GP), canco mais difícil será lidar com a situação. No final das concas, há poucas saídas prováveis para solucionar o problema, e os riscos de fazer mudanças são muito .mais altos. Às vezes, essa ocorrência facilita encerrar um debate, indicando o cronogran1a. Na reta final, mudar vários tipos de questões torna­se proibitivamente dispendioso, e é mais fácil sugerir a possibilidade de conviver com o problema agora e corrigi-lo na próxima versã.o (ou 1narco). Convém observar que a opção de escapar de um problema não o soluciona:

O QuE FAZER QuANDO AS Co1sAS DÃO ERRADO 227

significa apenas que há um jei[o fácil de se recusar a lidar com o problema, o que pode ser a coisa cer[a ou errada para o projeco.

Também é importante perceber que as situações difíceis geralinente [ên1 os co1neços e términos imperfeicos. Nenhu1na luz vermelha acenderá em sua n1esa, significando que a motivação está baixa ou que acabou de acontecer tuna omissão. Verifique isso e mesmo que você o faça, nem sempre ficará totalmente claro o que está acontecendo. Se ocorrer um problema depois e você decidir comar tuna atitude, calvez consiga apenas aliviar e mini1nizar seu impacto; possivelmente, não será toral1nente solucionável. Isso quer dizer que, no final das contas, você deve gerenciar os pequenos problemas e sintomas causados pelos problemas durante semanas ou até meses. (Por exemplo, gerenciar dois programadores ou testadores que simplesmente não se <lã.o bem. Você pode ajudar a consertar as coisas, mas não pode corrigir totalmente o conflito existente entre eles.) Sendo assim, uma parte do que deve ser feito quando as coisas dão errado é dedicar um tempo para 1nancer os problemas crônicos e irresolutos e1n u1n nível tolerável. Quanto mais proble1nas gerenciar dessa maneira, tanto mais tempo precisará investir nessa 1nanucenção e concrole dos danos.

Tornar a prática e o treinamento difíceis

O treinan1ento para os gerentes de projeto deve abranger exercícios e jogos que simulem colocar os GPs nessas situações. Aprendi que ensinar às pessoas os casos ideais pode ser o 1nelhor método de aprender as teorias básicas, mas para melhorar a habilidade e1n gerenciamento de projetos e tornar as teorias compreensíveis, basta ensinar os casos de fracassos e desafios. Os cursos mais bem-sucedidos que ministrei estavan1 focados em situações e exercícios de desafio, e não em fórmulas e conceitos. Pelo lado cínico mais uma vez, o desafio de gerenciar projetos não é navegar em águas calmas e límpidas, a céu aberto . . Em vez disso, o desafio está em saber discernir, priorizar e reagir a rodas as ocorrências imprevistas e difíceis com as quais nos defrontamos. (Mesmo que o derradeiro exercício para os GPs seja, possivelrnente, transformar o mar revolto em mar calmo, antes da equipe começar a navegar.)

Por conseguinte, se você trabaJha com ou gerencia outros gerentes de projeto, e não há oportunidades de fazer um treinamento adequado, é crítico usar essas situações difíceis como oportunidades de aprendizagem, quando elas ocorrere111. Por mais estressantes e decepcionantes que seja1n, a experiência de enfrenr;í-las vale ouro para o pr6xi1no projeto - se você reservar um tetnpo para exa1niná-las depois. Ste\>vart Brand disse cerra vez que "com precipitação, os erros surgem aos montes. Com ponderação, os erros ensinan1."4 Até 1nes1no diante do pior desastre, os GPs ainda tê111 concrole sobre suas reações. E a menos que a situação seja liceraltnence faca) para a equipe, haverá sempre tuna oportunidade de aprender algu1na coisa depois do ocorrido.

E1n relação a outras situações difíceis: há várias maneiras diferences de decon1por os possíveis problen1as com os quais você pode se deparar. Se estiver procurando listas n1ais extensas nas quais possa aprender, a melhor fonce de consulta isolada que conheço é o Capículo 3 da obra Rapíd

228 A.ARTE DO GERENCIAMENTO DE PROJETOS

Develop11'tent, de Steve McConnell (Microsoft Press, 1996). A segunda rnelhor fonte de consulra é o catálogo de antipadrões (http://c2.co1n/cgi/ "viki?AntiPatternsCaralog) que, na verdade, é uma leirura 1nais interessante e pitoresca, mas é rnais difícil de aplicar e não esrá redigida com rnuita coerência (o que não surpreende porque é um sistema wiki) .

Assumir a responsabilidade

Assumir a responsabilidade por alguma coisa não o torna culpado: significa que você enfrentará as conseqüências e ficará responsável por resolver a situação. Muitas pessoas temem assumir a responsabilidade porque não querem ser responsabilizadas e se expor ao ridículo ou a repreensões. O bom gerente deve ter u1n posicionamento exatamente oposto: em questões envolvendo sua equipe ou seu projeto, ele deve tornar a responsabilidade para si e usá-la para ajudar a equipe e o projeto a obterern êxito. Se aliviar urn engenheiro ou testador do temor da culpa me acenar uma solução melhor ou se agilizar uma solução, ficarei feliz ern tomar partido. Se meu próprio gerente não for eficiente, assurnir a responsabilidade de um problema pode ser uma honra para mirn . Ao me responsabilizar diretamente pelo problema, eu o torno imediara1nente menos perigoso para o projeto {consulte a seção "Funções e autoridade clara"), n1ais adiante.

Essa idéia de assumir a responsabilidade pode se estender não sornente à culpa ou ao fracasso, 1nas a todas as relações com as pessoas. Corno Larry Conscantine escreveu e1n sua obra Beyond Chaos: The Expert Edge in Managing Software Development (Addison Wesley, 2001):

Em vez de questionar por que uma pessoa é tão difícil, acho rnais útil perguntar a si mesmo por que estou tendo dificuldades coi.n essa pessoa. É evidente que normalmente é nlais fácil ver a sujeira dos outros do que a sua, mas todo encontro frustrante com uma pessoa difícil é uma oportunidade de aprender mais sobre si mes1no. Com o passar do ternpo, você se deparará cada vez menos com pessoas difíceis com as quais você precisará lidar.

Isso é importante principalmente nas situações difíceis ern que outras pessoas podern ser mais sensíveis ou propensas a perder as estribeiras. Se você puder contar com a sua própria 1naruridade e sabedoria para superar os medos ou as atitudes irracionais das outras pessoas, poderá levar u1n projeto ao sucesso, apesar de todo o comportarnento decepcionante ou contraproducente dos outros.

Assumir a responsabilidade, inclusive nas situações de fracassos ou dificuldades, é sempre uma oportunidade de cresci1nento. Ao arriscar sua própria pele, você concede a si rnesmo certo poder por estar se colocando be1n no meio de uma situação, seja ela qual for. Desviar-se da culpa ou subtrair-se à responsabilidade pode ajudá-lo a evitar o problema de curto prazo de lin1par a bagunça ou responder aos gerentes superiores sobre uma questão difícil, mas também exclui a oportunidade de aprender algo ou de crescer e de1nonstrar suas possibilidades. Para desenvolver o talento de apagar incêndios, você precisa sentir vontade de se queimar.

O QuE FAZER QuANDO AS Co1SAS DÃO ERRADO 229

Em [ertnos prá[icos, use sua predisposição de assu1nir a responsabilidade para fortalecer os OU[ros duran[e a crise. Inclua a seguin[e frase e1n seu manual de instruções para trabalhar co1n outras pessoas: "Não esrou bem cerro de como isso aconteceu, n1as não i1nporra agora. Podemos descobrir n1ais tarde e quando o fizermos, ajudarei a assumir a responsabilidade pelo que aconteceu. Mas porque isso realmente ocorreu, precisamos fazer isso e aquilo, agora nlesmo. Podem me ajudar a identificar como fazer isso e aquilo?"

Como alrernariva, em algumas situações, seu aro 1nais poderoso é livrar­se de sua responsabilidade. (No Capítulo 12, discutiremos a importância da confiança e como a delegação de poderes é uma maneira de confiar, que os gerentes podem usar para o benefício do projeto.) Em tempos difíceis, reafirmar a sua confiança nas habilidades de alguém pode resultar mais um efeito positivo do que qualquer contribuição intelectual ou técnica que você pudesse dar. "Ouça-me, Sally. Confio e1n você. Sei que esse é um problema difíci l, 1nas você é tuna expert. Apoiarei tudo o que, em sua opinião, deva1nos fazer para lidar com isso. Mas saiba de u1na coisa. Pense bem no assunto. Se você ainda discordar, es[aremos com você".

Controle de danos

Se ocorrerem muitos problen1as ao 1nes1no te1npo ou se acontecer algo realmente devastador, a priineira ação deve ser o controle de danos. Ou seja, a parrir desse pri1neiro 1no1nento, sua prioridade máxi1na é restaurar o projeto a um estado aceitável. l1nagine-se co1no um pilo[O de u1n 747 que acabou de perder a força no motor. Até a força ser restaurada, tudo o mais tem menos importância. Toda a sua energia deve estar direcionada para solucionar um problema ao qual estão subordinados todos os outros problemas. Você está no nlodo de controle de danos.

Em situações de controle de danos, os pilotos e capitães são treinados a diagnosticar o problema e tentar isolar os sintomas e as causas. Geralmente, os pilotos de aeronaves e astronautas têrn um procedirnento específico para fazer isso, em cada situação relevan te ocorrida (esses procedimen tos normalmente são mantidos em um manual porque há vários deles}. A idéia é que quando a sujeira atingir realmente o ventilador, nã.o haja tempo para inventar um procedimento - e talvez não haja rempo suficiente para seguir um procedimento sequer. Portanto, quando os pilotos se deparam corn uma en1ergência, eles inicia1n a seqüência de diagnóstico e trabalham siste1naticamente no problema até encontrare1n urna solução (ou, se fracassare1n, até cair).

Como un1 gerente de projetos, e1n algun1 rnomento você estará etn u1na situação de controle de danos. Não haverá [empo para explorar alternativas, ne1n para considerar as opções. Algo muito importante se quebrou, e não estará muito claro con10 é possível solucionar a questão. Para lidar com esta situação, siga esta lista:

• Convoque unia reunião geral. Os boatos correm rapida1nente pela equipe quando algo muito iinportanre está visivelmente muito errado. Quanto

230 A.ARTE DO GERENC[AMENTO DE PROJETOS

1nais [empo você demorar para solucionar, tan[o maiores serão a divergência e o 1nedo da equipe, quando você o fizer. Enfrence a si[uação e convoque tuna reunião, ou envie um email de al[a prioridade para a equipe. Explique resun1idamente a situação e que você está trabalhando no problen1a. Se possível, explique o que estará fazendo nas próxi1nas 24 horas (consulte a seção "Aplicar o guia rudimentar", anteriormente neste capítulo), e defina quando você en1icirá u1na atualização sobre o assunto. Não se esquive dos grandes problen1as: sua equipe perceberá que algo está errado, mesmo que você seja muito bom em esconder o faro.

• Se as pessoas entrarem em discordância, encontre um ponto de concordância. Discutiremos sobre isso mais minuciosamente na próxima seção. Se você estiver em uma sala cheia de pessoas que, aparentemente, só discordam do que está acontecendo ou do que deve ser feito, assuma o controle e reinicie a discussão. Re[orne ao úlci1no momen[o em que havia uma concordância: "Todos vocês concordam que nossas metas são A, B e C, e nessa orde1n?" Assim que você tiver u1n ponto de concordância, por mais si1nples que seja, passe a trabalhar nos proble1nas que está enfrentando. Examine um problema de cada vez e não permita que a discussão avance antes deles tere1n sidos solucionados ou antes de atribuir a algué1n a tarefa de destrinchá-los, fora da reunião.

• Qual é o 1nais recente bom estado conhecido do projeto e da equipe? Se você esüver controlando u1n dano técnico, voice através das co1npilações diárias (cujo arquivo você deve n1anter) até encontrar a úlcin1a co1npilação boa. Coloque-a sobre a mesa para restaurar o projeto a esse estado. Isso pode ser 1nais rápido do que continuar o projeto a partir do estado en1 que se encontra. Os programadores podem reaplicar 1nanualmente as alterações que desapareceram, e você pode aplicar controles superiores para eliminar a causa do problema. Esta é uma atitude radical, mas garante a estabilidade e a conflabilidade à custa de tempo no cronograma.

• É possfvel isolar o problema? Pense em u1n navio pegando fogo. É possível conter o incêndio? As part:es 1nais críticas do navio podem ser protegidas contra ele? Pense e1n como isolar o proble1na e evitar que ele afete as partes críticas de seu proje[O. Isso pode exigir o sacrifício de compromissos menos importan[es ou negociar recursos de u1na parte da equipe para a ou[ra. Pode exigir a assis[ência de curto prazo de outras pessoas de outras áreas, para ajudar a isolar e conter o problema, 1nas como isso garantirá u1n estado estável do projeto, co1npensa1n as i1nplicações.

• Podem ser aplicados recursos para ajudar no que foi danificado? En1 alguns casos, você pode achar un1a solução (e1n tern1os de dinheiro e equipe) para um problen1a. ln1agine um verdadeiro desastre, con10 u1n terremoto ou u1n tornado: você pode gasear dinheiro para realocar o projeto e comprar novos equipamencos imediatamente, para ajudar a n1ancer o projeto vivo aré serem encontradas as soluções mais demoradas. Se você detectar uma grande lacuna na cobertura da garantia da qualidade, poden1 ocasionalmente terceirizar para outra equipe a cobertura dos casos de testes atualmente automatizados ou os processos de compilação . Às vezes, injetar dinheiro ou outros recursos pode funcionar se o objetivo con1pensar e se for o tipo cerco de alvo.

O QuE FAZER QuANDO AS Co1SAS DÃO ERRADO 231

Solução de conflitos e negociação

"Não deve111os nos preocupar com o número de pessoas que discordarn de nós rnas, sim, com a veracidade dos seus rnotivos. "

- Alain de Botton

Os gerenres devem esrabelecer as diferenças o rempo todo. O fato da negociação só rer aparecido nesre capítulo não implica que rer que solucionar discordâncias significa que algo deu errado. Pelo contrário, uma equipe saudável e vibrante deve rer idéias e opiniões suficientes para saber que as discordâncias ocorrem periodica1nence. Desde que as pessoas discutrun os 1nériros das diferentes concepções e se cratetn com respeito, as discordâncias são pontos de vista alternativos e realmente conduzetn ao progresso. Os aspectos i1nporcances são o modo con10 as pessoas se trata1n mucua1nence quando encra1n e1n discordância, como essas discordâncias são resolvidas e se a discordância e o debate são convertidos em ação positiva.

Dito isso, em tempos de crise, a possibilidade de resolver discordâncias e negociar é de itnportância crítica. Você deve ser capaz de firmar compromissos adequados e trabalhar as situações difíceis para obter resultados mucuamence benéficos. De longe, o melhor recurso para aprender a atitude e as habilidades cercas é o livreco Getting to Yes, de Roger Fisher (Penguin Books, 1991).5 Não conhecia esse livro até bem carde em minha carreira, e ao lê-lo, pude entender melhor o que tinha ido bem e mal, em rodas as minhas experiências de negociação anteriores. Também percebi que a negociação ocorria de várias formas diferentes. Às vezes, eu ajudava duas pessoas na equipe a solucionarem um problema. Outras vezes, eu era uma das duas pessoas que discordavam, mas sem a vantagem de uma terceira pessoa interessada e1n ajudar a solucionar o conflito, eu forçava u1na atuação de negociador. Em rodos os casos, descobri u1na abordage1n básica que funcionava para mim, e que passo a descrever aqui:

• Encon tre o ponto de unificação . Independentemente do quanto possa111 discordar, duas pessoas hão de concordar co1n alguma coisa: o n1undo é redondo, o céu é azul, o projeto precisa estar dentro do prazo. Encontre os pontos i1nporcantes de unificação e concordância, e use-os para iniciar rodas as suas discussões. Convém co1neçar uma negociação con1 o pé direito. Solucione as questões controversas que esciverem ocorrendo dentro de uma escrucura de inceresse mútuo e perspectiva compartilhada. Crie um Diagrama de Venn dos tópicos que interessan1 às partes A e B, e observe os cruzan1entos. Se não existirem cruzamentos, está faltando algun1a coisa: por que teriam alguma base de discordância, se não têm interesses em comum?

• Reconheça os conflitos de personalid ade e, en1 seguida, ignore-os. É muito fácil cair na armadilha de deixar que as características da personalidade de alguém o desviem da meca de negociação, principalmente se você for uma das partes. E1n vez de centar encontrar situações que beneficiem a todos, é fácil escorregar para uma perspectiva de que a negociação é u1na competição: você quer vencer, ou pior ainda, quer fàzer o "oponente" perder. Isso é um cotai desvio de seus objetivos. Se você acha que não gosca

232 A.ARTE DO GERENCIAMENTO DE PROJETOS

da pessoa corn a qual escá negociando ou das pessoas cujo conílico escá cencando solucionar, descubra u1n jeico de isolar esses sencirnencos da carefa em quescão (ou delegue sua função para oucra pessoa) . Concencre-se em como o projero será favorecido, se o problen1a for solucionado, e faça isso com motivação.

• Busque um interesse m(1tuo. Se você ava liar rodas as alternativas possíveis para solucionar uma situação, descobrirá algumas opções que beneficiam ambos os lados. Você só poderá encontrá-las, enquadrando a discussão en1 corno dos inreresses e não em posições adversárias. Um posicionamento é um conjunto de exigências específicas ("Comerei sornente bolo de chocolate"). Um interesse é uma meta de nível superior ("Quero uma sobremesa saborosa e satisfatória") . Os interesses podem ser atendidos de várias maneiras diferentes, mas os posicionamentos dispõem de poucas soluções. Geralmence, as pessoas ern conílico não conhecem os inceresses mútuos, e sua energia é desperdiçada brigando em posições opostas. Mesmo assim, é mais fácil entender e trabalhar com os inreresses do que com os posicionamenros. Convença as pessoas a conversarern sobre os interesses e chegue a um acordo (ou pelo rnenos a um encendimenco) nesse nível, antes de co1neçar a discutir sobre formas específicas de acender aos inceresses de rodos. Lisce os inceresses de ambas as partes e relacione-os novamence co1n o ponco de unificação: alguns inceresses se encaixarão melhor do que oucros na área unificada. Deixe bem claro para cedos os envolvidos quais são esses . 1 n ceresses.

• Seja forte, mas flexível. Se você tiver uma posição austera que deve ser mancida, busque outros posicionamentos menos importantes nos quais possa ser nlaleável. Se não conseguir postergar as datas, é possível mudar os recursos? Se não puder conceder mais tempo, é possível liberar nlais verba? Conheça os pontos onde é possível ser flexível e 1nanipular, e aqueles que são rígidos. Quanto rnelhor conhecer a pessoa com a qual está negociando, tanto mais condescendente será ao abrir horizontes que são import<tnres , para essa pessoa, e custam pouco para você. E seguro dizer que se você não fo r maleável em nada, provavelmente não conhece profundamente os seus interesses (calvez porque a gerência só lhe cenha informado as posições das pessoas e não os respecrivos inreresses) .

• Conheça as alternativas. Nunca negocie sern saber o que lhe custará a sua parricipação e a dos ourros. Getting to Yes chama isso de sua BATNA - Best Alternative To Negotiated Agreement (A Melhor Alrernativa para urn Acordo Negociado). A idéia é a de que isso deve ajudar a derern1inar seus interesses e posicionamenros. Quanro 1nelhor for a sua BATNA e1n relação à de sua concraparre, ranco rnaior será o seu poder de barganha. Por exe1nplo, vamos supor que você esteja perdido no deserco corn urna dúzia de pessoas e que renha apenas urn galão de água potável. Fred oferece US$ 5 pela água. Você poderia dizer não e provavelmente reria uma oferta melhor de uma das outras pessoas, mas son1ente Fred pode negociar com você. Fred tem poucas alternativas razoáveis, enquanto você dispõe de várias. Fred pode ser o melhor negociador do mundo, mas isso é irrelevante se você conhecer a superioridade de suas opções, em relação às deles. 6

O QuE FAZER QuANDO AS Co1sAS DÃO ERRADO 233

• Use a persuasão e argu men te. Na maioria dos casos, os interesses e os desejos de ambas as parres se baseiam e1n opiniões subjerivas sobre o valor relarivo das coisas. Isso significa que se você conseguir desenvolver um verdadeiro entendimento dos senrin1enros de uma das partes, possivel1nente poderá persuadi-la de que um aspecto da situação é mais (ou menos) desejável do que ela supõe. A persuasão é um talento: co1nbina carisma, habilidades de comunicação, lógica e psicologia - todas as coisas que podem ser aprendidas com experiência e esforço. Use a diplon1acia ao persuadir os outros, e direcione seus esforços para os pontos mais . importantes para o progresso.

Na realidade, o ato de negociar é apenas uma forma especial de discutir. Re1ína as pessoas certas na sala (consulte a seção ''.Aplicar o guia rudimentar'', anteriormente neste capítulo), defina uma pauta que inclua a discussão dos problemas e interesses, e depois procure encontrar alternativas viáveis para solucioná-los. Se as pessoas e1n conflito estivere1n na 1nes1na organização, você poderá contar co1n as 1netas do projeto para estruturar os interesses de nível mais alto para todos os envolvidos (o ponto de unificação). São apresentadas propostas e contrapropostas até ser alcançada uma resolução.

Se as pessoas e1n conflito estiverem em duas organizações distintas, as coisas serão 1nais co1nplexas: pode haver menos confiança e relações 1nais frágeis entre as pessoas envolvidas. O primeiro objetivo deve ser replicar algo se1nelhante às 1netas do projeto: por que estan1os trabalhando em conjunto? Quais são os benefícios 1nútuos para negociarn1os trabalho ou recursos? Con10 regra geral, isso deve ser feito quando esse relacionan1enro começar (os contratos são vias simples desse tipo de acordo). Isso esclarecerá os interesses de rodos e propiciará uma linha de base de referência, caso ocorra1n conflitos ou discordâncias posteriormente (além de minimizar as chances de que essas discórdias se formem antecipadamente). Mas em lugar de u111 acordo preventivo, isso pode ser feito após o ocorrido. Será n1ais difícil fazer porque a confiança e a boa vontade não estarão em alta, mas é o único caminho para se encontrar uma solução.

Funções e autoridade clara

Aprendi duas lições ao participar de esportes competitivos. Primeiro, a verdadeira confiança só é conquistada quando os desafios surgem e são superados. Só quando ocorre uma contenda ou discussão, onde algué1n está aborrecido ou assustado e a verdade aparece, é que as relações tê1n a oportunidade de crescer. E1n segundo lugar, as boas equipes eferiva1nence funcionain porque cada integrante conhece a própria função, assim como as funções de codas as pessoas na equipe. Tudo vai be1n quando cada um depende da contribuição do ourro, até o ponco e1n que possa focar-se em suas tarefas com confiança. Um guicarrisra líder e1n u1na banda de rock não poderá fazer u1na grande apresentação solo se o baixista e o barerisra não lhe proporcionarem un1a estrutura rítmica confiável na qual trabalhar. O 1nes1no acontece com os atacantes e defensores no jogo de basquete, ou con1 os quarterbacks e ele1nentos da linha ofensiva no futebol americano. E é claro que isso se aplica aos programadores, testadores e outros profissionais nas equipes técnicas.

234 A.ARTE DO G ERENCIAMENTO DE PROJETOS

A interdependência na atividade e1n grupo torna-se 1nais i1nporcance diante da tensão e da pressão. É provável que as coisas se divida1n e as pessoas cenha1n a primeira oportunidade de fracassar, sentir medo ou culpar os outros quando algo der errado. Em geral, o trabalho complexo é muito interdependente, o que significa que Fred sabe que fracassará ao concluir seu reste, se Sara não conseguir fazer seu código funcionar em tempo hábil. Ele ten1 um bom motivo para se preocupar: ele ainda não trabalhou tempo baseante con1 ela para ter tuna verdadeira confiança em sua habilidade de cumprir um compromisso em situações difíceis.

Portanto, sob pressão, é co1num ver equipes inexperientes e i1naruras se empenharem em suas funções. Os integrantes da equipe questionarão as próprias habilidades e farão tudo o que for possível para se resguardarem da possibilidade de falhas ocasionadas pelos outros (geralmente desperdiçando energia no processo). Até mesmo as pessoas experientes podem agir assim, se estiverem trabalhando em equipes formadas por pessoas que ainda não têm 1nuira confiança u1nas nas outras.

Isso significa que boa parte do que um GP deve fazer nos momentos difíceis é reforçar a escrucura funcional da equipe. Lembre a todos a interdependência que existe entre os incegrances da equipe e o que devem esperar de seus companheiros. Como líder, fica a seu critério identificar quem está ficando agitado ou nervoso, e le1nbrar a essas pessoas a confiança que você deposita na equipe. Procure conhecer quen1 se sente ignorado ou vulnerável, e esforce-se por n1udar essa percepção. Para manter uma equipe unida, não são necessários grandes discursos ou gestos. Em vez disso, basca se dirigir às pessoas e verificar se elas se sentem ligadas ao que está acontecendo e se elas têm o necessário para acreditarem que pode1n contribuir pos1C1vamenre.

Em alguns casos, as pessoas precisam de apoio e proteção para desempenhare1n suas funções. O GP deve respaldar as pessoas que estiverem desenvolvendo seu trabalho honestamente, n1as estiverem sendo questionadas de modo injusto e improdutivo pelos outros. Geraln1ente isso ocorre com u1na equipe secundária ou com as divisões de funções, como entre a programação e teste ou engenharia e 1narketing. Assim, quando você se surpreender com um comenr;írio injusro, como "Meu Deus, Bob deve ser um perfeito idiota se ainda não cenninou esse tesce", você deve dizer, se for adequado, "Sceve, Bob escá arrasado agora devido a um arraso da equipe de desenvolvimento na semana passada. Talvez você possa ajudá-lo, da mesma forma como a equipe de reste ajudou vocês anteriormente, hein?" Seja a consciência da equipe e preserve as pessoas honestas, quando necessário.

Se ocorrer u1na verdadeira incompetência e1n algu1n lugar (por exemplo, se Bob for real1nente um idiota), fica por conta do GP envolver diretamente os integrantes e gerentes, e garantir que o problema seja identificado para que1n estiver na melhor posição para fazer algo a respeito. (Baseie o foedback na função que a pessoa suposra1nenre esraria desempenhando e que parres dessa função não esrão acontecendo. Em vez de incompetência, calvez seja u1na falha de comunicação sobre as funções e compromissos.) Na 1naioria das vezes, os problemas de uma equipe sob tensão são erros de comunicação, falta de confiança e falhas funcionais, e não aros isolados de idiotice ou • A ' 1ncompetenc1a.

O QuE FAZER QuANDO AS Co1sAS ÜÃO ERRADO 235

Todos devem saber quem toma as decisões

E1n momenros difíceis, é necessário un1 horizonre claro sobre a auroridade de tomada de decisões. Se a equipe estiver trancada em uma sala e for necessário fazer un1a convocação urgenre nos próxi1nos cinco n1Ínutos, com o destino do projeto dependendo do resultado obtido, quem deve fazer isso? Em organizações milirares, existe uma cadeia de co1nando para garantir que a resposta a essa pergunta seja se1npre óbvia. Co1no as decisões serão to1nadas sob grande tensão e com prazos apertadíssimos, é necessária uma estrutura administrativa indisputável, confiável para tomar atitudes de modo efetivo, a despeito de quão confusa a situação possa estar. Boa parte do treinamento que os soldados recebem está direcionada para confiar na cadeia de comando. Nos projetos, a regra geral deve ser a seguinte: quanro mais alros forem os riscos e a pressão, canto menos dúvidas deve1n exisrir quanto a quem tem autoridade.

Nos projetos, a cadeia de comando para decisões difíceis depende da gerência -em termos 1nais específicos, do gerenciamento de projetos. Se o desafio e1n questão abrange problemas comerciais, técnicos e de requisitos, nenhum expert (1narketi.ng, engenharia) deverá ter a melhor perspectiva geral. Contudo, o GP, devido ao â1nbico de sua participação no projeto, cem o n1elhor entendimento das diferences considerações e possíveis in1pactos dessas decisões com implicações. Se várias pessoas fizere1n as rarefus do GP, cerran1ente deverá existir um processo claro de que1n decide o quê e quem está participando. As discussões sobre funções descritas no Capítulo 9 devem abranger a autoridade de tomada de decisões, e poden1 ser usadas para esclarecer outras questões relacionadas à autoridade.

Mas lembre-se de que quem toma as decisões, seja quen1 for, sempre cem o direito de delegar ou colaborar. O aspecto crítico não é o furo de Bob ou Michelle ou o Sr. VP tomar todas as decisões difíceis, mas, sim, o futo de que alguém na organização sabe a quem recorrer quando determinados tipos de decisões devem ser tornados, bem antes de urna crise. Isso agilizarJ a tornada de decisões em urna equipe, o que pode impedir que pequenas ameaças se transformem em grandes desastres.

Um kit de ferramentas emocionais: pressão, sentimentos sobre sentimentos e o complexo de herói

Esta última seção deste capítulo abordará os tópicos relacionados com as en1oções, relevantes ao trabalhar em equipes onde aconteceu algo rnuiro errado. Meu objetivo aqui não é fornecer um tratamento psicológico completo sobre o controle da tensão (estresse) mas, em vez disso, apresentar urna pesquisa rápida dos problemas que você enfrentará e os principais aspectos sobre os quais deve pensar quando estiver diante desses problemas.

Pressão

Esta é a melhor definição que conheço da palavra pressão:

Pressão (n): urna influência ou força de refreamento, irresistível.

A palavra-chave aqui é refreamento. Estar sob pressão significa que existem restrições que não podem ser movidas e com as quais se deve lidar.

236 A.ARTE DO GERENCIAMENTO DE PROJETOS

Essas res[rições podern es[ar relacionadas ao [empo, aos recursos, à d ificuldade não [ra[ada da siruação ou [udo isso jun[o. A exis[ência dessas res[rições significa que há menos escolhas disponíveis e menos rempo ainda para solucionar o problema e1n ques[ão.

Quando as pessoas usam a palavra pressão, como em "estou sob pressão", elas querem. dizer que percebem tuna ameaça de fracasso na superação da res[rição. Uma situação de pressão, con10 um debate político ou ganhar o jogo no último segundo, significa que algo in1portante está em risco e pode desaparecer facilmente (ou pelo menos, supõe-se que possa acon[ecer). Ou[ras pessoas envolvidas sofrerão se ocorrer um fracasso, au 1nentando a idéia da pressão sobre essas pessoas.

O mais importante em relação à pressão são as diversas reações das pessoas sob pressão. Cada pessoa tem sensibilidades distintas e sente mais ou menos pressão nas mais diversas situações. Alé1n disso, cada pessoa pode enfrentar ou lidar com a pressão de várias maneiras. Para algumas pessoas, o 1nelhor alívio da pressão ou tensão é a atividade física - para outras, é o humor. Infelizmente, rnuitas pessoas ainda não sabem lidar corn essas coisas.

Duran[e as si[uações difíceis, uma tarefa adicional dos líderes é garan[ir o apoio aos diversos tipos de alívio de tensão. Ao presenciar os líderes fazendo pouco caso de suas reações à tensão ("Quando chego à minha casa, trago um pacote com seis cervejas e corno o banho 1nais demorado do mundo") , a equ ipe se sentirá no direito de fazer o n1esn10. Se o programador-chefe convidar outros programadores para fazer ginástica (ou para o campo de paintball) depois do expediente, para descarregar as turbinas, as outras pessoas terão a oportunidade de saber se isso as ajudará em suas [ensões. Inclusive aquelas pessoas que não parriciparem [erão a oportunidade de refle[ir sobre a tensão sob a qual se encontram e onde pode ser o 1nelhor lugar para desca rregá-la. Ao contrário, se os líderes foren1 repressivos e negare1n suas tensões, fingindo que isso não os aflige ou que não precisam de nenhu1n t ipo de alívio (comportamento t ípico do macho idiota), eles d ificultarão a vida de rodas as outras pessoas. Nunca deixe sua equipe pensar que a necessidade de a liviar tensões é u1n si nal de fraqueza.

Fique atento à arneaça disfàrça da, "Bem, se você está se sentindo tão estressado, a pon to de precisar de um alívio, calvez não devesse estar nesta equipe". E evi[e o ridículo da negação, "Ah, yoga? Acho legal, se você precisa tan [o, pode ajudar". Esse é o t ipo de raciocínio dos gerentes que não sabem o que é bom para eles. Geralmente, o alívio de tensões é barato ou de graça, e não traz q uaisquer desvantagens. Mes1no que não ajude a aliviar a tensão, apoiar as pessoas nesse sentido (ou disponibilizar gratuitarnente para elas) rnelhora a motivação. Já vi gerentes inteligentes trazerem 1nassagiscas nos mon1entos d ifíceis, e batere1n de porca e1n porta, oferecendo a cada pessoa 1 O minu[OS de n1assagem. Fazia n1aravilhas: aré 1nes1no as pessoas que não parricipava1n falavam sobre o assunro d uranre dias.

Pressão natural e artificial

A pressão é uma força sobre a qual a gerência re1n algum controle. As ações da gerência nludam a natureza da pressão de várias 1naneiras, e para gerenciar uma

O QuE FAZER QuANDO AS Co1SAS DÃO ERJ\ADO 237

equipe nos momentos de tensão, é necessário conhecer todos os seus membros. Há quacro cípos de pressão: natural, artificial, positiva e negativa (consulce a Figura 11-1).

Natural Artificial

Positiva

Negativa

FIGURA 11· 1. Os quatro tipos de pressão.

Para mim, a pressão narural é o sencimenco de wna pessoa quando um compro1nisso pessoal irnporranre está e1n risco ("Espere aí. Eu disse ao Sam que o demo estaria funcionando até às 14 horas.") . Se a pessoa acredita no cornpromisso e está emocionalmente investida na qualidade de seu trabalho, ela fará isso sozinha, aumentará sua concentração e nível de energia en1 resposta à pressão. Esca é a chamada pressão natural porque vem diretamente do trabalho e do relaciona1nenro da pessoa con1 seu trabalho. Nessa sítuação, tudo o que os líderes precisam fazer é orientar e proteger essa energia, e apoiar os 1ne1nbros da equipe em sua busca de alcançar seus objetivos. Essa modalidade de pressão é geralmente positiva, pois a motivação pessoal e a equipe precisam estar sincronizadas. Porém, pode se tornar negativa se as pessoas se sentirem culpadas ou envergonhadas por terem fracassado no cumprimento de seus compromissos, principalmente se outras pessoas estiverem causando o problen1a que gerou essas falhas.

A pressão artificial é qualquer tática que os líderes aplicarn para tentar e ampliar a idéia de pressão da equipe. Pode ser positiva e negativa. A forma positiva é orientada para a reco1npensa, onde as pessoas são recompensadas por trabalhare1n 1nais arduamente e por au1nencarem seu dese1npenho nos momentos complicados (por exemplo, au1nentos de salários, pro1noçóes, bônus). Ou o trabalho extra pode ser voluntário, onde o líder pede (sern exigir) que a equipe trabalhe corn mais afinco (talvez com incentivos, como pagar o jantar daqueles que ficarem até mais tarde, ou deíxar n1ais pessoas trabalharen1 em casa). Às vezes, a pressão artificial pode ter a forma de uma reunião animada da equipe, onde o espírito positivo que respalda o projeto é reanirnado (calvez gerando algu1na pressão natural para alguns me1nbros da equipe), e uma nova onda de energia é cultivada.

As formas negativas da pressão artificial são xingar, acionar a culpa ou ameaçar, como maneiras de tàzer com que as pessoas trabalhem mais. Ocasionalmente, isso leva os líderes a culpar a equipe por determinados fracassos, e a pedir que trabalhem muito mais para corrigir os problemas que possivelmen te ocasionararn. Essa é a mentalidade da instrução/disciplina

238 A ARTE DO GERENCl1\MENTO DE PROJETOS

milirar esrereoripada: a equipe deve ser consranremenre disciplinada e sempre cobrada para dar o melhor de si (e assi1n vai a reoria) .

Na maioria das vezes, os gerenres usam algum ripo de combinação de forças naturais, artificiais, positivas e negativas para manter o bom desempenho de uma equipe. Mesn10 que eu prefira usar as forças positivas, às vezes son1ente o uso criterioso das forças negativas pode tornar un1a equipe coesa e concentrada novamente. E1n resumo, é um equilíbrio cuidadoso e não há un1a fónn ula para isso. Só a experiência no gerenciamento de equipes e a observação da natureza humana o aperfeiçoarão na aplicação dessas modalidades de forças. Você descobrirá que os gerentes mais experienres desenvolveram teorias sobre a aplicação da pressão. Mas geralmente essas teorias não se originam de experiências suficientemente diversificadas para justi fi car a confiança que merecem das pessoas.

Fórmula de pressão à parte, é evidente que a equipe tem limitações em relação a quanta pressão pode suporcar. A Figura 11-2 traz um diagrama adaptado do Volu1ne 1 da obra de Gerald Weinberg, Quality Software Management (Dorset House, 1996). Nesse diagra1na, há uma curva do desernpenho de equipes trabalhando sob pressão. Durante algu1n cempo, a maioria das pessoas e as equipes demonstram mais desempenho com o aumento da pressão. Co1n o passar do tempo, essa relação diminui e depois desaparece totalmente. Quando uma equipe está em seu nfvel de dese1npenho máximo (un1a espécie de limiar ou 1naxi1nização), nenhu1na pressão adicional furá con1 que a equipe trabalhe 1nais, 1nelhor ou com mais agilidade. Se a aplicação da pressão continuar, e1n algum momento a equipe (ou a pessoa) vai estourar e as coi&'ls ficarão muito piores.

Desempenho

Pressão

FIGURA 11-2. Há um limite para o valor da pressão em aumentar o desempenho.

Sendo assim, se você decidir usar a pressão para gerenciar unia equipe, esteja acento aos limiares em que você está trabalhando. Se a equipe não reagir, calvez você precise aplicar outro ripo de pressão, 1nas isso can1bé1n pode significar que a equipe escá no seu limire e nenhu1na acividade de gerenciamento furá con1 que trabalhe melhor. A experiência ajudará a distinguir entre essas duas possibilidades. Em resumo, os membros de uma equipe em seu lirnite máximo abaixarão suas cabeças pelos corredores e não sorrirão muito. Parecerão nervosos e cansados ao mesmo tempo. Murcharão quando solicitados a assumir outra tarefa ou farão uma pequenina alteração em algo já concluído. É muito mais dispendioso recuperar-se de um desgaste do que diminuir o ritmo do projeto, de modo que a última opção é a melhor. Alivie a

O QuE FAZER QuANDO AS Co1SAS DÃO ERJ\ADO 239

pressão, concedendo às pessoas uma carde livre, bacendo u1na bola, de repence, no escacionainenco ou ajuscando a carga de crabalho ou o cronogra1na para algo que mancenha a saúde mencal.

Sentimentos sobre sentimentos

Ances de saltar esca seção, supondo que é un1 material sentimental que não tem nada a ver com você, deixe-me fuzer uma pergunca. Você já se perguncou por que as pessoas se comportam de modo diference quando estão sob pressão? Se não se importa ou não vê relevância nesse assunto para o gerenciamento de projetos, sinta-se à vontade para passar adiante. Mas coitado de quem trabalha para você. (Viu só? Acionar a culpa tem o seu lugar.)

Muito bem, isso foi injusto mas fi.1ncionou. Para recompensá-lo, vou lhe contar algo precioso sobre o comportamento humano. Virgina Satir, autora de vários livros sobre psicologia e comporta1nento hu1nano, te1n un1 modelo simples para ajudar a explicar por que as pessoas podem ser cão imprevisíveis. Em tennos simples, às vezes, quando nos sencimos de determinada maneira (digamos, aborrecidos ou tnagoados), remos rapidamence um segundo senrimento sobre esse pritneiro, e é em função desse segundo sencimenro que costumamos agir. Por exemplo, vamos supor que eu lhe diga que seu cheiro é engraçado. Isso o encriscecerá. Mas talvez você sinta raiva porque eu o fiz ficar triste. Então, em va de expressar seu senti1nento de tristeza, tudo o que você consegue exprimir é o sencin1ento secundário de raiva (a Figura 11-3 1nostra un1 exemplo sitnples dessa concepção). Mais adiante, você perceberá que o sentiinenco principal foi crisceza e ficará crisce, mas por enquanto, estamos falando sobre seus sentiinentos etn relação a outros sentimentos.

O sentimento O sentimento do sentimento

FIGURA 11-3. O modelo de Satir explica que os sentimentos pelos quais agimos não são necessariamente nossos sentimentos principais.

No Volun1e 1 da obra Quality Software i\1anagement, Weinberg explica que o modelo de Sacir ten1 oucras implicações úteis. Geralmente, o que gera o segundo sentiment.o é uma crença ou h:íbiro que assimilamos, que não é uma constante para o comportamento emocional saudável. Sentir raiva de um sentimento de tr isteza não é um comporcamenco universal dos seres humanos: é aprendido. Na realidade, segundo Weinberg, nossas reações a d iversas emoções são apenas aquelas às quais estamos expostos em nosso próprio desenvolvimento emocional.

240 A.ARTE DO GERENCIAMENTO DE PROJETOS

O aspecto divertido e1n relação ao desenvolvi1nenro da infância é que todos nós reinos siste1nas e1nocionais e crenças de um legado. A 1naioria dos comportamentos que seguimos é geralmente assimilada de nossos pais, que absorveram seus comporran1entos dos respectivos pais e assin1 sucessiva1nente. Até alguém parar e examinar a importância de suas condutas e reações emocionais, independent.en1ente de onde tenham assimilado, será difícil evoluir un1a maturidade emocional - ou sequer saber quão emocionalmente amadurecidos e saudáveis nós somos. Pior ainda, possiveln1ente transferiremos tun comportamento desrrur.ivo ou confuso para outras pessoas (como nossos alunos, colaboradores, amigos e filhos) .

Algumas regras que aprendemos podem ser boas e outras más. Contudo, só porque reagimos de determinada maneira em nossas vidas, isso não significa que essas reações sejam saudáveis para nós ou úteis para nosso desenvolvin1ento.

A lição aqui para os GPs é que, às vezes, as e1noções recebidas das pessoas com as quais vocês trabalha1n não estarão direta1nente relacionadas co1n as ações que vocês romara1n. Você pode detectar u1n bug no código de alguém e essa pessoa ficar aborrecida, mesmo que você seja educado tenha descoberto algo importante.

Mais específico para este capítulo, o comportamento humano torna-se mais irregular sob tensão. Há 1nais pressões e sentin1entos envolvidos, e é 1nais difícil entender sua interação. De n1odo que, co1no gerente, que freqüentemente trabalha co1n outras pessoas, é necessária 1nuita paciência para identificar quais partes do que você está recebendo estão realmente relacionadas ao que você disse, e quais delas estão atreladas a outros senriinentos que as pessoas estão sentindo no momento.

O que você deve efetivamente iinpedir é um efeito cascata desses senti1nentos não diretamente relacionados. Imagine se, na Figura 11-3, alguém n1ais respondesse a uma expressão do sentimento B com uma declaração refletindo un1 sentin1ento C, obscurecendo mais ainda a causa de toda a situação (sentimento A). É totaln1en te possível que isso tudo termine em uma reuniã.o de cinco pessoas questionando e xingando, sem que ninguém esteja no mesmo contexto e1nocional: todas as pessoas estão se expressando e reagindo a diferentes sentimentos sobre o verdadeiro assun to em discussão (por exe1nplo, lembre-se de sua última reunião em família) .

Ourros notáveis escritores sobre a emoção hu1nana, como Leo F. Buscaglia ou John Bradshaw,7 defendem a teoria de que quanto mais saudável ou emocionalmente amadurecida uma pessoa for, canto mais consciente será de suas próprias e1noções e das en1oções dos outros, propiciando a si mesma u1n a1nplo espectro de opções de cotno reagir às emoções de outras pessoas. Isso i1nplica que, em uma situação de crise, u1n líder tem 1naior probabilidade de êxito se conseguir perceber os padrões emocionais e adrninisrrá-los de

, . . vanas maneiras.

O complexo de herói

No que diz respeito à pressão, existe um tipo especial de pessoa: aquela que tem um complexo de herói. Trata-se de uma pessoa que cria compulsiva1nente

O QuE FAZER QuANDO AS Co1sAS ÜÃO ERRADO 241

sicuações perigosas sirnplesmence para poder solucioná-las. Essa pessoa pode escar cão dependence do suspense e dos desafios das sicuações excrernamence difíceis, que não se esforçará para irnpedir que os proble1nas aconreçarn logo no início. E1n sua forn1a n1ais branda, é rão-somence alguém que gosra de crabalhar en1 situações arriscadas e superá-las. En1 sua forma mais ampla, uma pessoa com u.m complexo de herói pode estar colocando o projeto em risco, ou até mesn10 tentando sabotá-lo.

Quando as coisas derem errado em un1 projeto, as pessoas com tendências a terem complexo de herói prosperarão. Enquanto algumas pessoas ficarão desanin1adas ou se omirirão de enfrenrar o fogo, as pessoas em quesrão saltarão direramenre para o problema, como se o projeto estivesse realmente ficando interessante. Ter pessoas na equipe com a forma branda do complexo de herói é excelente porque elas procurarão os focos de incêndio e os combaterão, mas raramente elas mesmas provocarão incêndios.

Você deve estar acento aos casos de complexo cocal de herói porque esse comportarnento pode deliberadamente desestabilizar o projeto. Ou mais comu1nente, combaterão com todas as suas forças aquelas ações que irnpedern as sicuações de alco risco.

Na maioria das vezes, o complexo de herói se desenvolve nas pessoas que iniciaram suas carreiras em empresas recém-conscicuídas ou pequenas empresas (voláteis). Os esforços heróicos e sobre-humanos são geralrnente necessários para coadunar as coisas, tuna vez que essas organizações rararnente dispõen1 de recursos suficientes, correspondentes às suas ambições.8 Se as coisas fl1ncionarem bem, os sobrevivences considerarão seus esforços heróicos como urna parte significativa do sucesso. Nesse concexco original, eles escão cercos. Concudo, há n1aus hábitos por uás dessa lógica: só porque a situação A exigiu aros heróicos, isso não significa que esses mesmos atos tenham sido necessários, ou sequer benéficos, nas siruações B, C e D.

O complexo de herói cem várias crenças que o motivam, explicadas ou refutadas na lista a seguir:

• O planejamento é desnecessário: já provei isso. Como o herói é u1n craque em obter êxito sem especificações ou cronogra1nas, ele nunca dará valor a essas coisas. Essa opinião Falha devido às diferenças exisrentes entre os projetos. Um projeto de cinco pessoas e um mês te1n resuições e riscos basicamente diferences de urn esforço de 200 pessoas e 12 meses. Podem ser necessárias diferentes abordagens de gerenciamenco, planejamento e engenharia. Parte dessa concepção (imperfeira) é a idéia de que o herói já reve todo o tipo de experiência en1 desenvolvimento de sofouare. Essa arrogância irnpede que ele perceba os proble1nas específicos e1n cada projeto, que exige1n un1 equilíbrio único da esrrutura de gerencia1nento, processos e equipes para solucioná-lo. Sempre e nunca não são respostas válidas para a pergunca sobre quando urn processo é necessário: isso sernpre dependerá dos detalhes do projero.

• Eu t rabalho por conta própria. A força n1otriz mais egoísta do comportamenro do herói é o simples fato de que o herói gosra de ser herói. Ele gosta tanto disso, que não se imporra com o que está em risco ou com o que pode ser destruído, ao desernpenhar o seu papel. Os sinro1nas dessa conduta são a concorrência desleal com os parceiros ou uma total indiferença ao t rabalho das outras pessoas (ou até mesmo às metas do projeto). Essa pessoa não aceita. que seu desejo de ser herói possa ter quaisquer implicações (porque essas desvantagens existem

242 A.ARTE D O G ERENC[AMENTO DE PROJ ETOS

geralmente para as outras pessoas, não para ela) . Em alguns casos, essa pessoa sequer sabe por que seus esforços heróicos nem se1npre são recebidos do modo como espera. ("Eu não evitei que aqueles anin1ais lindos e fofinhos fosse1n queirnados quando entrei no prédio para salvá-los?" "Sirn, mas foi você que o incendiou.")

• O pseudo-herói. Já vi isso acontecer várias vezes. A idéia é que, ao fazer a gerência supor que algo é inuito pior do que realmente é, e depois, n1agicamente, torná-la 1nenos rui111 do que parecia, uma pessoa pode dar a in1pressão de que é bom em tudo o que fuz (nosso herói!). Quanto mais ignorante ou desinteressada for a gerência, tanto mais Fácil será agir assirn. Isso tende a funcionar apenas algumas vezes, até que os parceiros ou as outras pessoas percebam. Isso não é exatamente o complexo de herói porque a pessoa em questão não deseja fuzer coisas heróicas: ela quer apenas ser considerada um heroína.

• Os heróis têm "reis tolos". A rnaioria das situações que geram oportunidades heróicas são falhas da gerência. Se o projeto te1n semanas de atraso, foram cometidas omissões dos principais requisitos ou opções estratégicas ineficientes exigem mudanças estruturais significativas e tardias, so1nence a gerência é responsável por isso. Ocasionalrnente, você se deparará co1n relaciona1nencos co-dependentes entre a gerência e a engenharia, onde a gerência depende dos esforços heróicos da engenharia para cobrir (e ocultar) seus erros. Assim, en1 vez de admitir as próprias t:'llhas, eles dependem de recompensar o trabalho heróico brilhanre, possivehnenre evitável, da equipe de engenharia. Nesse ínrerirn, a engenharia adora a adrenalina desses problemas e nem espera que a gerência se recupere ao planejar ou administrar o risco, a despeito do quanto reclamam dessa gerência. É criada uma cultura de co-dependência total, que depende dos heróis e recompensa a criação dos riscos e sua resolução.

• O complexo do fracasso. É diferente do complexo de herói mas suficientemente relacionado para incluí-lo nesta lista. Algumas pessoas se sentem inseguras, exceto quando existem aspectos sobre os quais possam reclamar. Quando estão diante de um desafio, elas se sentern mais seguras encontrando desculpas para o fracasso e convencendo as outras pessoas de sua importância, em vez de investir essa energia em enfrentar o desafio e tentar obter êxito. Elas preferem se envergonhar a vencer. Essas pessoas surgem em grupos procedentes de más equipes (ou famílias), onde levar a culpa e negar era mais irnportante do que qualquer outra coisa. Elas precisam de alguém para dernonstrar a si 1nes1nas que há u1n rnodo mais saudável de continuar vivendo.

A rnelhor forma de nlini1nizar os riscos da cultura do herói é ter un1a equipe de gerencia1nento ativa. Se alguém acreditar que a diferença é importanre, ficará 1nais fácil saber se uma semana de 80 horas de rrabalho é o resulrado da resposra realinenre heróica a un1a crise ou uma correnre de inco1nperência auro-imposra. Como un1 GP, calvez você não tenha influência suficiente para conscientizar a equipe de seus hábitos voltados para o heroísmo, mas a única maneira de saber é tentando (consulte o Capítulo 16).

Son1ente quando alguém cha1na a atenção para esse comportamento é que existe uma possibilidade de mudança. No mínimo, esforce-se bastante para ter uma política de análise de atos heróicos. Sempre que um herói entrar em ação, deverá ocorrer uma discussão pública sobre o que poderia ter sido

O QuE FAZER QuANDO AS Co1SAS ÜÃO ERRADO 243

feiro para evicar o que aconteceu, em primeiro lugar. Deve-se dar um crédito ao herói, 1nas ta1nbém deve1n ser distribuídas reco1npensas para aquelas pessoas que descobrirem uma 1naneira de evitar que esse ripo de situação ocorra novamente, mais adiante.

Resumo

• A despeito do tudo o que você fizer, algumas coisas darão errado.

• Se você conseguir manter a calma e fracionar os problemas, poderá lidar com várias situações difíceis. (Lembre-se do guia rudimentar.)

• São previstas algu1nas situações comuns, que abrangem omissões, ser obrigado a 1-àzer coisas idiotas, fàlta de recursos, má qualidade, mudanças de rumos, proble1nas pessoais e atneaças de n1otins.

• Mo1nentos difíceis são oportunidades de aprendizage1n. Certifique-se de que você e sua equipe examinem o que aconteceu e co1no poderia ter sido evitado.

• Assumir a responsabilidade pelas situações, a despeito de quem as causou, sempre ajuda a resolver o problema.

• E1n situações extremas, entre no modo de controle de danos. Faça o que for necessário para restaurar o projeto a um estado conhecido e estável.

• A negociação é úr.il não somente e1n uma situação de crise, como r.ambém no gerenciamento. Os bons negociadores defendem os interesses das pessoas, não

. -as suas pos1çoes.

• Mantenha os organogra1nas be1n especificados o tempo todo. As pessoas precisam saber quem tem o poder de tomar decisões antes que uma crise aconteça.

• As pessoas reage1n à pressão de várias maneiras. Seja observador e aberro quanto ao 1nodo como você ajuda a equipe a lidar cotn as diversas modalidades de pressão.

o 1 ' e: CD E cu ·-(.) e: CD '-CD

C!J • Cf)

w b: <(

a_

Capítulo 12

Por que a liderança é baseada na confiança

248 A.ARTE DO GERENC[AMENTO DE PROJETOS

E 1n toda a minha vida, já rive 1nais de tuna dúzia de gerences. Escou cerro de que gosraria de esquecer muitos deles e alguns foram terríveis. Mas os poucos que ad1nirei ou gosraria de e1nular demoraram para ganhar a 1ninha confiança. Eles querian1 que eu fizesse 1neu nielhor trabalho e sabirun que isso seria in1possíve.l, a menos que eu pudesse contar com eles diariamente. Isso não significava que eles faria1n o que eu pedisse ou concordariam com minha opinião, habicualmente. Mas realmente significava que o comporramenro deles era previsível. Mais freqüenremente do que não, eles eram francos comigo em relação a seus compromissos, motivações e expecr.uivas. Eu sabia qual era o meu lugar, conhecia as minhas funções e as deles, e o apoio disponibilizado por eles para o que precisava fuzer.

Como um líder ou um contribuinte importante para a equipe, tudo depende das pressuposições das pessoas em relação a você. Quando você disser "isso estará pronto até amanhã" ou "conversarei com Sally e F.trei con1 que ela concorde com isso", as outras pessoas na sa.la efetuarão cálculos silenciosos, calvez no subconsciente, sobre a probabilidade de que o que você disse venha a ser verdadeiro. Com o passar do te1npo, se você acender à sua equipe corn eficiência, essas chru1ces serão rnuito altas. Elas acreditarão na sua palavra e depositarão confiança e1n você.

Mesmo que os filmes e a televisão freqüentemente retracem a liderança como uma atividade de alta carga dramática - com heróis invadindo prédios em chamas ou lutando bravarnenre sozinho contra um bando de inirnigos - a verdadeira liderança está relacionada a elen1entos n1uito simples e pníricos. Faça o que você diz e explique o que significa. Adn1ita os seus erros. Registre as opiniões e idéias dos outros em decisões que os afetam. Se você puder co1nar essas atitudes com mais freqüência, ganhará a confiança das pessoas co1n as quais trabalha. Quando chegar a hora de pedir a essas pessoas que façam algo desagradável ou com a qual não concordem, a confiança que elas depositam em você tornará a sua liderança possível.

Isso implica que para ser u1n bom líder, não é necessário ser o melhor programador, planejador, arquiteto, co1nunicador, contador de histórias, designer ou qualquer outra coisa. Basta que você torne a confiança un1 componente in1porrante a ser cultivado, e que a compartilhe com as pessoas que estão a seu redor. Portanto, para ser urn bom líder, aprenda a encontrar, construir, ganhar confiança e dar credibilidade aos outros - assim como aprenda a cultivar a confiança em si 1nes1no.

Construindo e perdendo confiança

Confiança (n): crença force na integridade, habilidade ou caráter de uma pessoa.

"A confiança é a base de todas as relações importantes. Sern a confiança, não haverá qualquer concessão, nenhum vínculo, nem se assurnirão riscos. " -Terry Mizrahi, Diretor da Ecco (Education Ccncer for Co1111ntu1icy Orga.nizaáons)

Como um experi1nenro informal, solicitei uma amostragem aleatória dos contatos confiáveis em seus locais de trabalho e o 1notivo. Todas as respostas foran1 basicamente idênticas: a confiança é adquirida pelas pessoas que fazem bem o seu trabalho, que estão comprometidas com as metas do projeto, que

POR QuE A LIDERANÇA i:. BASEADA NA CONFIANÇA 249

rrararn as ourras pessoas com jusriça e se comporram de Jnodo coerence nos 1no1nencos difíceis. Nenhurna pessoa sequer mencionou se gaseava dessas pessoas ou se desejavarn convidá-las para um jancar. Parece que a confiança (ern un1 conrexro profissional) é algo que exrirpa as ourras caracrerísricas da personalidade. Podemos confiar nas pessoas de quem não gosramos ou com as quais não desejamos passar algum tempo.

Diferencemente de oucros atributos das pessoas, a confiança tem pouco a ver con1 a preferência pessoal. Não escolhemos en1 que1n confiar baseados em elemencos superficiais. Em vez disso, há um conjunro mais abrangenre de cálculos que efetuamos en1 relação às pessoas das quais dependemos. Se eu lhe perguncasse em quem você confiaria para salvar a sua vida em uma siruação de perigo, você escolheria pessoas diferentes do que se eu lhe pergunrasse com que gostaria de ir ao cinema. Para ocorrer un1a química e uma confiabilidade pessoais, não é obrigatório qualquer vínculo mútuo.

Mas para exarninar a confiança no concexro dos projetos, precisamos deco1npor o conceito ern partes funcionais. Urna sirnples unidade de confiança é um cornpromisso. Urn comprornisso, ou promessa, é o tipo rnais sirnples de acordo enrre duas pessoas em relação a algo que arnbas concordarn ern realizar.

A confiança é construída pelo compromisso

Quando você faz um novo a1nigo e ele lhe diz que o enconrrará em algun1 lugar, você acredica que ele escará nesse local na hora e1n que ele infonnou. Mas se duas ou crês vezes seguidas, você ficar esperando por ele e renninar assisrindo a um filine ou indo a um clube sozinho, sua confiança nele diminuirá . Na realidade, ele quebrou seu compromisso com você. Se isso continuar, sua percepção a respeito dele mudará. Você não nlais o considerará confiável e questionará sua confiança nele no tocante a assuntos importantes.

De acordo co1n a obra de Humphrey, Managing the Softivare Process (Addison Wesley, 1989), urn dos principais componentes dos projetos bem­gerenciados é a possibilidade de o líder se cornprometer com seu trabalho e de se esforçar para cumprir os seus compromissos. Humphrey acredita tanro nesse aspecto, que definiu de modo exato os elementos dos compromissos efetivos. Examine a seguir a lista de Humphrey, com algumas modificações.

Elementos do verdadeiro compromisso

l. A pessoa conrrai o comprornisso esponraneamence.

2. O comprornisso não é aliviado; ou seja, o crabalho envolvido, os recursos e o cronograma são cuidadosarnence considerados.

3. Exisre um acordo enrre as parces sobre o que deve ser realizado, por quem e quando.

4. O compromisso é aberto e publicamente declarado.

5. A pessoa responsável centa cumprir o compromisso, mesmo precisando de ajuda.

250 A.ARTE D O G EREN C IAM ENTO DE PROJ ETOS

6. Ances da dara esripulada, se aconrecer algurna coisa que afete uma das parres no cocance ao cornpromisso, é e1nitida urna nocificação prévia e u1n novo compromisso é negociado.

Há dois aspectos particularmente interessantes aqui. Primeiro, os compron1issos funcionam de duas maneiras. As duas pessoas envolvidas se con1prometem mutuamen ce. Se Cornelius combinar com Rupert que andará con1 seu cachorro no período em que Ruperc estiver fora da cidade, ambas as partes escarão arreladas a interesses 1núruos. Cornelius nunca deverá cer que percorrer os 25 blocos da cidade até o aparra1nenro de Rupert, para andar com o cão no Central Park, só para encontrar Rupert dei tado no sofa, assist indo televisão ("Oh, desculpe. Eu devia ter te ligado ontem - minha viagem foi cancelada."). A confiança de cada parte é dada à outra em uma troca de confiança, e existe uma expectativa de que a confiança seja respeitada - não violada nem esquecida. Deixar alguém perder seu tempo e dinheiro é u1na violação da confiança.

Em segundo lugar, contraírnos compro1nissos o ternpo todo. Ern toda conversa em que solicitamos ou somos solicicados a fazer alguma coisa, e escipularnos um prazo para isso, escarnos concraíndo urn comprornisso. Isso engloba declarações simples, como "Oi, ligarei para você depois do almoço" ou "lerei essa minuta até amanhã". Duas pessoas podem ter idéias diterenres quanto à seriedade do comprornisso, mas rararnence haverá dúvidas de que algum ripo de comprornisso tenha sido feito. Quanto menor for a seriedade con1 que considerarn1os nossos con1prornissos com as outras pessoas, canto 1naior será a probabilidade de redução da confiança que elas depositam em nós. Há níveis diferentes de comprometimento (por exen1plo, se você se esquecer de ligar para a sua esposa e1n uma carde, ela não pensará que você escá querendo o divórcio), 1nas rodos os níveis se vincula1n e concribuem para nossas percepções da confiança dos outros.

Perda da confiança por comportamento incoerente

Voltando aos projetos, as pessoas quebram a confiança quando se comportam de modo aleatório ou imprevisível. Quando age sem respeitar seus comprornissos, uma pessoa cria ondas de preocupação que perturbam a equipe. Retira-se energia das pessoas com as quais ela precisa trabalhar (ou confrontar). Em vez de direcionar sua energia para a conclusão do trabalho, agora elas têm que gasear energia calculando se a tal pessoa realmente fará o que disse. É necessário preparar planos de contingência e sobem os níveis de tensão e dúvida ("Se Maria não terminar a verificação desse código até o fin1 do dia, estaremos ferrados."). Quanto 1nenos cuidadosa for uma pessoa corn as suas responsabilidades, canto maiores serão as ondas.

Uma hisrória inreressante (ainda que angusrianre) sobre a perda da confiança aconteceu com tun de rneus ex-gerentes. Eu era urn gerente de programas trabalhando com cinco programadores e testadores, e escáva111os indo niuito bem. Jake, o líder da equipe, era rneu gerente e tinha autoridade sobre mi1n e vários outros GPs. O proble1na era o hábito de Jake de 1nudar de idéia. Por exemplo, ele e eu discutiríamos sobre grandes decisões que eu estava tomando, que precisavan1 de seu apoio. Chegaríamos a um acordo rapida1nente quanto à melhor abordagem. Então, assim que entrásse1nos e1n uma reunião, onde forres

PoR QuE A LIDERANÇA É BASEADA NA CONFIANÇA 251

personalidades ou pessoas com rnais ou igual rernpo de casa do que Jake discordassem dele, Jake, de forma dráscica, desmoronava (isso aconcecia em urn rerço das vezes, n1as eu nunca sabia en1 que cerço). Ele pegava a pista concrária e concordava com roda decisão que fosse popular.

Lembro-me de que escava e1n pé na frente do quadro branco durante as reuniões, no nleio da explicação do meu plano A, quando ele concordava com a sugesrão de alguén1 para passar para o plano B. Eu parava e olhava para ele, escarrecido co1n o fato de que ele fizesse isso a sangue frio. Ele realmente se esquecera? Ele era assim tão puxa-saco? Ele não rinha consciência do que escava fazendo comigo? Ou esse comporramenro ao sabor dos ventos (acompanhando a aragem na sala) escava realmente fora de seu controle? Na ocasião, eu não tinha experiência para discernir sobre isso e não era "fera" o bastante para conversar com os outros sobre o comportamento que eu enfrentava, então, eu sofria. Meus exercícios físicos na academia de ginástica nunca eram suficienre1nente bons.

Ocasionalmente, eu tentava discutir essa conduta co1n ele. Eu também docu1nentava imediata1nente (o eniail funciona bem para isso) as decisões que tomáva1nos e as utilizava posrerionnente como referência. Eu ia até bem 1nais longe, chegando a prepará-lo u1n pouco antes das reuniões. Mas tudo isso resultava ern melhorias mínimas (em vez de apoiar o plano B, ele apenas saía da discussão, sem contribuir no plano A). Logo eu me deparei driblando-o. Eu dava um jeito de decidir as coisas na reunião sem a presença dele. Em termos con1parativos, dava 1nenos trabalho e era 1nais eficiente. Isso gerava outros problen1as em nossa equipe (e em 1neu relacionamento co1n Jake), mas eu conseguia ad1ninistrar 1ninhas <Íreas e obtinha resultados.

O lado trisce era o fato de Jake ser uma pessoa inteligente e divertida com a qual trabalhar. Mas como eu não podia confiar nele, isso não cinha iinportância. Ele reria sido mais útil como gerente, se fosse menos inteligente, mas angariasse o dobro da confiança. Certa1nenre teríamos criado produtos superiores e despendido menos energia controlando-o e mais energia ajudando a equipe.

Torne a confiança transparente (crie sinais verdes)

Os bons gerentes que tive tornaram explícita a confiança. Eles me diziam, sem pesramejar, que eu tinha autoridade para tomar decisões em minha esfera de responsabilidades, desde que eu tivesse o apoio da equipe. Eles (meus gerentes) identificavam aspectos específicos preocupantes e me pediam para verificar juntamente com eles. Eles me perguntavam o que eu escava querendo deles e negociava1n para ver se podia1n 1ne conceder. Se não pudessem, eles me orientavam a fazer as coisas acontecere1n, em vez de procurar a aprovação de ourra pessoa. Confiar, o verdadeiro significado da delegação, é uma atitude poderosa. Alguns esportes tê1n um jargão específico para esse ripo de delegação de autoridade - por exe1nplo, receber o "sinal verde" no jogo de basquete.

Anos anres, eu jogava basquete no curso secundário (segundo grau), no rime do técnico Rob Elkins1 no Samuel Field Y, e1n Douglaston, Nova Iorque. Ele n1e en1purrou para o lado durante um treinamento, o que geral1nenre significava que escava na hora de uma repreensão. Eu tinha feito besteira durante o treinamento, abaixando as bermudas de outros jogadores, impedindo-os de correr para a defesa. Só para prevenir, quando eu 1ne sentei, abaixei minha cabeça. Mas ele não disse nada.

252 A.ARTE D O G ERENC[AMENTO DE PROJ ETOS

Permanecen1os sentados por muito tempo, vendo o restante da equipe se esforçando na quadra. Finalmente, ele disse: "Scott, você re1n o sinal verde". Olhei para ele. "Sinal verde?" - perguntei. "Sim" ele respondeu, sorrindo, .1nas se1n olhar para rnim. "OK, técnico" - disse e corri de volra para a quadra. Mes1no que poucos tenham ouvido essas palavras, todos os jogadores saben1, de alguma forma, o que significam. Enquanto os jogadores normalmente são obrigados a lançar a bola unica.rnenre de acordo com a jogada orientada pelo técnico, o sinal verde significa isenção. Eu podia lançar a bola quando quer que eu achasse adequado; eu podia substituir qualquer jogada e exercer autoridade quando julgasse necessário.

Uma grande confiança é concedida quando se diz para um jogador algo assim, que é exatamente o motivo pelo qual a maioria dos jogadores lura em roda a sua carreira e nunca ouvem. (Eu continuei jogando basquete no curso secundário e nos times da faculdade da Divisão III, mas nunca mais ouvi essas palavras de novo e nunca as tinha ouvido antes.) Os técnicos geralmente têm horror de abrir mão de qualquer autoridade. Quase como os gerentes, eles senre1n que seu poder é tênue. Ficar na lacerai da quadra (ou sentar sozinho em u1n canto da sala) é uma posição vulnerável. Muitos gerentes e técnicos te1ne1n o que acontecerá se concederem tnais liberdade à equipe. Eles se esquecem de que sempre é possível ajustar os níveis de confiança: se eu tivesse abusado da confiança que o técnico Elkins depositou em mi1n, nada o impediria de volcar atrás (mudando o sinal verde para amarelo). Talvez ainda 1nais importante é que o grau de confiança que os gerentes ten1e1n dar geralrnente é o que sua equipe realmente precisa para seguir a liderança de seus gerentes.

Tenho certeza de que eu jogava muito 1nais para o técnico Elkins do que para qualquer outro técnico que tive. No fundo, eu sentia que naquele mon1ento eu cinha um padrão mais alto ao qual deveria acender (se bem que, em determinado jogo, eu fiz sete arremessos em u1n dos quatro tempos, e perdi rodos eles, o que cercamente foi uma espécie de recorde do clube em termos de tentativas e perdas). Também trabalhava mais intensamente para os gerentes que confiavam mais em min1 do que para aqueles que não confiavam. Não era porque eu gostava deles (embora isso ajudasse). Era porque eu tinha um espaço que me enriquecia. A transferência de confiança gera a verdadeira capacitação porque dá às pessoas espaço para se aproximarem de seu desempenho máximo.

Se o seu objetivo é o potencial máximo para o sucesso, procure maneiras de dar às pessoas sinais verdes. O gerente deve criar oportunidades para sua equipe, assim corno ajudá-la a rer a capacidade e preparação para aproveitar essas oportunidades.

Os diferentes tipos de poder

Há dois modelos de poder que usarei neste livro. A forma avançada virá depois, no Capírulo 1 G. Por enquanto, adorarei a fonna sin1ples, 1nas potente, de poder funcional.

Existern dois tipos de poderes funcionais: o concedido e o conquistado. O poder concedido ven1 através da hierarquia ou dos cargos (às vezes denon1inado poder ex ofício ou "do cargo"). Por exemplo, o técnico de um time de basquete tem o poder de decidir quais jogadores participarão da partida e quais ficarão no banco. Ou o chefe de un1 pequeno escritório comercial pode cer o poder de

POR QuE A LIDERANÇA É BASEADA NA CONFIANÇA 253

contratar e demitir que1n ele escolher. Mas esse poder não cem nada a ver com o respeito das pessoas por que1n o exerce ne1n co1n a experiência e conhecimento que as pessoas acha1n que um gerente cem. Ao concr;írio, o poder conquistado deve ser cultivado com desempenho e atitude. O poder conquistado, ou autoridade conquistada, é quando as pessoas preferem ouvir, não por causa da autoridade concedida a uma pessoa, mas porque acham que a pessoa é inteligente ou útil.

Não confie no poder concedido

"Desconfio de todos os sistematizadores e fajo deles. O desejo de construir um sistema vem da falta de integridade. "

-Nietzsche

O uso do poder concedido co1no força básica na liderança restringe os relacionamentos. Esse tipo de poder exclui a possibilidade da troca de idéias e enfoca o uso da força no lugar da inteligência. E1nbora existam situações em que o uso do poder absoluto é necessário, os bons líderes mantêm essa espada na bainha o máxi1no possível. Assim que você a en1punhar, ninguém 1nais o ouvirá -eles ouvirão a sua espada. Pior ainda, todos ao seu redor e1npunharão suas espadas en1 resposta à sua. Em vez de lhe explicarem por que esrá errado, usarão o próprio poder concedido para desafiar a sua força. Isso resulta numa competição de forças que não tem nada a ver con1 inteligência ou de un1a busca da melhor solução. O poder concedido (como o "lado negro da força") é tentador por ser mais fácil: você não precisa trabalhar tanto para conseguir o que deseja.

Uma vez, enfrentei u1na situação que me deixou na encruzilhada dos poderes concedido e conquistado. Foi durante o Internet Explorer 2.0, quando recebi minha primeira grande atribuição de gerenciamento de progra1nas. No primeiro dia, fui apresentado aos dois programadores com os quais trabalharia, Bill e Jay. Jay era amistoso, mas Bill era quieto e intimidante. Ele também era muito antigo na organização (um nível 13 no jargão da Microsoft na época, o que significava que ele escava prestes a alcançar a antigüidade máxima que um prograrnador poderia ter). Lembro-me de ter me sentado ern seu escri tório e de olhar para ele através de sua escrivaninha. Eu conversei por l O minutos e ele não disse quase nada. Ele apenas se recostava em sua poltrona e me fixava.

Tentei usar o quadro branco para ver se isso ajudava Bill a falar. Sem efeito. Ele abria a boca apenas para pronunciar coisas sarcásticas ou ambiguamente desconcertantes, como "Enrão, é isso?" e "Uau .. . interessante que você pense assim". Ele rão-so1nenre brincava co1nigo, co1no tun gare co1n u1n raro 1neio 1norto. Veja você, eu era apenas un1 rapaz arrogante, de 23 anos; eu não tinha idéia do que estava fazendo, apesar de estar convencido de que podia si1nular. Por outro lado, Bill era u1n veterano experiente que já tinha enfrentado essa rotina dezenas de vezes. Estou cerco que somente dois pensamentos passavam pela cabeça dele: "Co1no foi que eu vin1 parar com esse cara novo?" e "Ele é a primeira ou a segunda pessoa mais idiota que já conheci?" No final do encontro, eu escava balbuciando palavras ao estilo "vídeo de treinamento de RH" sobre como seria n1aravilhoso trabalhar em conjunto. (Tenho certeza de que isso confirmava para ele que eu era, na realidade, merecedor do primeiro lugar.)

254 A.ARTE DO GERENC[AMENTO DE PROJETOS

Na época, um amigo (oucro GP) me deu u1n conselho: ponhas as cartas na mesa. Eu devia dizer ao Bill que por ser eu o GP e ele, o progra1nador, ele deveria fazer o que eu dissesse quanco às decisões de alco nível. Isso se encaixa na mirologia dos GPs da Microsoft ("se você cruzar o n1eu caminho, mato você") que eu costumava ouvir, e então, reuni coragen1 para tentar e corresponder às expectativas. Mas antes de sacar a n1inha espada e empunhá-la morro acin1a, bati um papo com nleu gerente. Entre risos agradáveis, ele me disse para não fazer nada precipitado. Ele 1ne fez len1brar que Bill era inteligente e conhecedor de sua área, e que eu devia dar u1n jeito de usar isso. Ele também acrescentou que t rabalhar com Bill seria, na opinião dele, "bom para 1nim". Confiando em meu gerente, apesar de sua risada, afuscei a minha espada e vislumbrei o problema com a intenção de tirar o máximo proveito de Bill.

Trabalhar para desenvolver o poder conquistado

N as semanas seguinces, eu conquistei lentamente a confiança de Bill. No início, foi angusciante. Ao longo do processo para convencê-lo a me ajudar, tive que provar para ele a minha capacidade e acumulei de pequenas a grandes realizações. Descobri que quando eu confirmava que ele conhecia alguma coisa mais do que eu, obtinha um bon1 conselho dele 1nais facilmente. Quando eu 1ne co1npromeria e cun1pria, ele ficava 1n ais generoso. Precisei tomar boas decisões e defender 1neus pontos de vista com bons argun1entos, nlas ocasional1nenre desenvolvíamos u1n relacionamento profissional sólido. Bill 1ne concedeu autoridade para tomar decisões que lhe aferavam baseante. Ele só queria que eu demonsrrasse em primeiro lugar que 1nerecia a sua confiança.

Se tivesse exercido o poder a mim concedido nesses primeiros dias, reria perdido rodas as chances de um poder conquistado. Bill podia ter cedido naquele prin1eiro dia, mas como ele estaria respondendo somente à minha força, ficaria difícil avançar daí para n1aneiras mais colaborativas para trabalhar em conjunto. E se eu contasse continuamente com o uso do poder (que é o que normalmente acontece quando você começ<1 a usar o poder), teria se tornado menos eficiente co1n o passar do te1npo. Sempre que um gerente ou líder diz "Porque eu disse e pronto," eles estão finalizando discussões e encerrando a possibilidade de surgirem opiniões melhores. Todas as pessoas inteligentes ou dedicadas ao redor deles não estarão dando o mell1or de si e não escarão felizes co1n a lirnicação de suas funções.

Sob a perspectiva organizacional, o comporcamenro despórico afasta os excelentes pensadores. Estimula, simulraneamenre, aqueles que se senrem seguros em fazer o que lhes é mandado a continuar assim. Os tiranos criam ambientes que so1nenre as pessoas servis pode1n tolerar e vice-versa. Pior ainda, os tiranos criarn ourros riranos abaixo deles. Esses padrões de con1portai11ento (poder concedido ou nada) são rransmicidos arravés das organizações, envenenando-as e1n algu1n momenro.

Persuadir é mais forte do que ditar

Ao gerenciar outras pessoas, percebi que eu conseguia fazer con1 que as boas coisas acontecessem de nlodo mais eficiente, se eu as convencesse a fazer alguma coisa ances de obrigá-las a fazer. Qualquer idioca pode aplicar o poder tirânico e exigir

POR QuE A LIDERANÇA É BASEADA NA CONFIANÇA 255

ripos específicos de condura - isso não requer qualquer capaciração. Mas para convencer u1na pessoa (ou um grupo de pessoas) inreligence de que algo, que inicialmence ela não queria fazer, é cerro, bo1n ou acé 1nes1no de seu interesse, é n1uito mais poderoso. Quando as pessoas trabalhare1n horas a fio e começarem a questionar por que estão fazendo isso, não poderão culpá-lo. Elas poderão contar com a própria inteligência, influenciadas por seus argun1entos, para saber por que estão investindo seu cen1po fazendo isso.

En1 algum momento, as pessoas me ouvia1n porque confiavam em minha habilidade de rer bons 1notivos para as minhas opiniões. Elas faziam menos perguntas e confiavam no fato de que eu havia ponderado sobre o pedido que lhes fiz antes de fazê-lo. Elas sentiam menos receio de que eu tirasse proveito delas porque já tinham tido muitas provas de que os interesses do projeto e da equipe motivavam a minha conduta. Quanto mais as pessoas confiarem em você, mais fá.cil será. persuadi-las. Assi1n como aconteceu com o Bill, no decorrer do ten1po, eu gastava cada vez 1nenos energia convencendo as pessoas - embora tenha sido aí que iniciei meu relacionan1ento com elas - e 1nais tempo obtendo resultados.

Seja autocrático quando necessário

O poder concedido tem o seu lugar. Quando as coisas fi.1gire1n ao controle, o poder concedido pode ser a maneira 1nais rápida de restaurar a orde111. Se urna reunião está se desfazendo, compro1nissos importantes estão sendo quebrados ou estão ocorrendo outros problen1as críticos, use a espada. Se você esciver convencido de que o uso da força direta é a única possibilidade real de u1n resulrado be1n­sucedido, a despeiro das conseqüências, use-a de rodas as 1naneiras. Seja cransparence, direto e use sua autoridade de executivo par..i f..izer o projeto avançar.

Contudo, estou convencido de que quanto mais essa espada for utilizada, nlais ela camuflará problemas organizacionais básicos que precisan1 ser solucionados. Se a única maneira de avançar durante a sen1ana for gritando nas reuniões ou dando ordens a portas fechadas, isso significa que a visão do projeto, a estrutura organizacional e o cronograma devem ser reexaminados. Esses cornponentes formam a espinha dorsal do projeto e esrabelecem a sua liderança sem exigir tanto uso da força. Se eles estiverem gravemente fora de sintonia, o absolutismo só ajudará a administrar os sintomas, e não a corrigir os problemas básicos.

Confiar nos outros

Quanto mais profunda e abrangente se tornar a hierarquia de uma organização, tanto rnais normal será conrar com o poder concedido. Haverá mais ternor entre os líderes em relação a como manter as massas trabalhando em conjunto (ou calvez, corno irnpedir o início de urna revolução) e acreditarão que não há rernpo para que todos na organização participem de um tipo de discussão e cornunicação que exige a autoridade conquistada. Até rnesmo nas pequenas equipes, conheço alguns líderes que não acreditam que têm energia ou haja tempo para reunir todos os seus principais colaboradores nesse tipo de estilo de liderança. A solução para esse problema é outra forn1a de confiança, chamada de delegação: confiar nos outros para que comem as decisões.

256 A.ARTE DO GERENC[AMENTO DE PROJETOS

Autoridade e confiança freqüentemence se acumulam ern corno de diferences tarefas ou áreas de conhecirnento. Joe poderia cer autoridade m<úcima no que diz respeito a objetos da linguage1n C++, e Sally poderia ser a pessoa mais indicada para trabalhar con1 bancos de dados. Os colegas de equipes saudáveis e comunicativos confiam uns nos outros o bastante para reconhecer quando outra pessoa tem mais experiência ou uma perspectiva melhor, e pedir um aconselhamento a essa pessoa sen1 medo do constrangimento ou do ridículo. Esse é u1n medo real porque as disciplinas de engenharia têm culturas amadurecidas de comportamento passivo-agressivo e1n corno de um pedido de ajuda (por exemplo, rcfm*). Até 1nesmo nos departa1nenco de ciências da computação na faculdade, a autoconfiança é considerada uma competência básica e o fato de os alunos pedirem ajuda aos parceiros é interpretado como um sinal de Fraqueza.

Sob o prisma de um projeto, a autoridade de Sally sobre o design do banco de dados é tão eficiente quanto a sua aplicação ao projeto. Se ela ficar sozinha em seu escritório e ninguérn recrurar sua autoridade para ajudar a solucionar proble1nas, a autoridade de Sally ficará dilapidada ou, na melhor das hipóteses, restrita às tarefas desenvolvidas por Sally, por conta própria. Uma responsabilidade-chave de urn líder ou gerente de projeto é modelar a delegação e cornparcilhar o conhecimenco na equipe inteira. Se isso for realizado corretamente, ficará mais fácil para o restante da equipe seguir adiante.

Delegação de autoridade

Tradicionalinente, usa-se a delegação para descrever o aro de transferir tarefas ou responsabilidades específicas. Para 1ni1n, uma fonna mais poderosa de delegação ocorre quando as decisões, ou a possibilidade de influenciar as decisões, são distribuídas. Isso pode acontecer nas reuniões ou nas discussões em grupo. Quando pergunta-se ao líder ou gerente "Então, como esse problema está sendo solucionado?", ele cem a chance de transferir esse poder para outra pessoa. "Bem, Sally, você é a 1nelhor designer de bancos de dados. O que acha que devemos fazer nesse caso?" Desde que isso não seja feito de forma injusta (digan1os, bem no meio de uma tensa reunião de revisão com o VP, durante um demo com falhas, quando Sally não tiver idéia de que supostamente deverá responder perguntas), definirá um clima de colaboração. As pessoas têm liberdade de reconhecer o grau de experiência das outras pessoas, e elas concederão autoridade adequadamente. É claro que para o gerence de projetos, nada escará em risco. Se as sugescões de Sally não fore1n boas, a discussão prosseguirá. Mas sem esse primeiro questiona1nento, é possível que a discussão ja1nais aconteça.

É evidente que a delegação cambérn se estende a transferências explícitas de autoridade. Ao declarar publica1nente que tuna <Írea de trabalho ou recurso será gerenciada( o) por alguérn, um gerente transfere a sua autoridade para essa pessoa. É irnporcance que as delegações ocorrain corn visibilidade suficiente para que rodos que precisem conscarar a rransferência real1nence possam presenciar. Sempre que eu transferia un1a responsabilidade para alguén1 que trabalhava para min1, eu 1ne cerrificava de concarar cada progran1ador ou testador que pudesse ser afetado, para

•N. de T: Rend the F .. Afn1111nl.

PoR QuE A LIDERANÇA É BASEADA NA CONFIANÇA 257

que soubesse1n que todo poder e auroridade que eu rinha sobre aquele rrabalho seriam rransferidos para a pessoa em quescão. Evidenremente, às vezes, as pessoas não quere1n que as coisas sejain delegadas, e o líder deve usar seu poder para i111por isso.

John, u1n gerente de projetos em minha equipe, esrava preparado para assumir nlais responsabilidades. Encão, quando chegou a hora de reorganizar a distribuição do trabalho dei um jeito de passar para ele uma área pela qual eu tinha sido responsável anteriorn1ente. Depois das discussões pertinentes con1 John e Steve (o programador na área), transferi a responsabilidade para John. Un1a. sen1ana depois, Sreve entrou em meu escritório e pediu a ajuda do GP para a área. Enquanro eu ouvia, rentava descobrir por que ele estava conversando con1igo e não com John. Eu o incerro1npi: "Steve, por que você está falando comigo sobre isso?" "Bem, Scon, isso er-.i de sua alçada, não era?" "Sim, Steve, mas é do John agora. Você conversou com ele?" Ele encolheu os ombros. "Sceve, converse com o John" - disse eu. "Ele é inteligente. É bon1 no que faz. Confie nele." Steve voltou alguns dias depois e tive1nos uma versão resumida da mesma conversa. Mas depois disso, nunca mais soube do Sceve nova1nente (pelo menos não sobre isso).

Provavelmence, John nunca ficou sabendo disso e nem precisava. Sreve preferiu rrabalhar comigo por algu1n 1nocivo, e ele deseja concinuar nosso relacionamenco a despeiro da mudança de ritularidade. Mas para delegar, foi necessário me isentar das discussões. Provavelmente, eu mesmo poderia ter respondido à pergunta do Steve e eu teria gostado disso, 1nas eu estaria indo contra a minha própria decisão de delegar. Até que eu tivesse u1n motivo para nle envolver nessa área do projeto, eu teria que confiar em John e Sreve para realizar seus trabalhos, o que incluía usar a confiança do Steve em 1ni111, para convencê-lo a confiar em John.

Muicos gerentes enfrencam dificuldades para delegar. Eles passam para outro nível devido à sua capacidade de concluir rrabalhos por conra própria, e a liderança exige um equilíbrio de habilidades diferences daquela de ser um colaborador individual (consulte a seçáo "O equilíbrio no gerenciamento de projeto" no Capítulo 1). Geraln1ente, esses gerentes hesitan1 com medo de não terem controle suficiente. Evidentemente, isso é uma arn1adilha porque esse medo orienta suas decisões e nunca conseguem aprender a confiar em alguém.

Às vezes, a solução é um compromisso. Basta que o gerente discuta co1n o me1nbro de sua equipe no 1no1nento da delegação as considerações que a delegação supostamente fará . ("John, estou preocupado com Sreve. Ele se atrasa em roda escimaciva. Porcanto, presce mais acenção nisso, cerro?") Ao definir expecrativas em torno de atribuições, os líderes rransrnirem u1na parte da experiência e da orienraçáo, e provavelrnente aumentam as chances de êxito.

Confiança é um seguro contra a adversidade

Co1no discutimos no capículo ancerior, em rodos os projetos, algu1nas coisas darão errado. Os concorrenres cosrumam não fazer o que se espera deles (ou seja, o seu trabalho), tecnologias vê1n e vão e1nbora, e pessoas iinportantes 1nuda1n de idéia. Con10 gerente de projetos, esteja cerco de que aconcecerão coisas que não estava1n previstas ou projetadas. E1n n1on1entos difíceis ou de incerteza, convém que sua equipe ou seus pares possam concar com você e confiem uns nos oucros.

Se a confiança foi cultivada e amadureceu co1n o passar do tempo, e as pessoas cê1n experiência em tomar decisões enrre si (e não apesar do outro), o

258 A ARTE DO G ERENC[AMENTO DE PROJETOS

projeco cerá urn alto poder de recuperação dos problemas. Quando as pessoas acredicarn na equipe, elas podern agregar formas de confiança e paciência que não existem de ourra maneira. Assim como os soldados encrincheirados, cada pessoa pode contar corn alguérn 1nais para proteger sua retaguarda, ficando livre para se concentrar na tarefa à sua frente.

Quando existe confiança dentro de uma equipe, o tempo do gerente de projetos tan1bén1 é resgatado para se dedicar aos problemas aruais, em vez. de tentar apaziguar os corredores cheios de funcionários frustrados ou en1 pânico. Algumas vezes, o líder pode precisar pedir esse tipo de apoio explicirarnenre. Ele precisa demonstrar o respeiro que deseja receber da equipe, reconhecendo o problema e pedindo, mas não exigindo, o apoio dessa equipe. (Não funciona gritar "Quero o seu apoio agora!".) No fundo, a união das pessoas é que FJz com que elas atravessem os tempos difíceis: não seus salários, não as tecnologias nas quais trabalham, e certamente não o poder que uma pessoa tem ou não tem.

Sendo assim, o líder inteligente, como o capitão de um navio, sabe que as tormentas e os perigos irnprevistos espreitam mar adentro, e ele deve preparar a si mesmo e à sua tripulação da rnelhor maneira possível para enfrentar aquilo para o qual não exisce uma preparação. Se a incerteza é um fato, o rnelhor invesrirnento do gerente de projetos provavelrnenre é gerar uma cadeia de confiança enrre ele e rodos os colaboradores contribuindo no esforço. Em equipes maiores, é necessário investir mais re1npo formando a confiança nos relacionamentos mais críticos para o projeto ou corn maior probabilidade de fracassar sob tensão. En1bora as especificações, docun1enros de visão e outras ferran1entas realmente ajudern a vincular as pessoas, é a confiança nas pessoas por trás dessas coisas que transmite o verdadeiro poder.

Modelos, perguntas e conflitos

A regra que vale ouro - faça aos outros o que gostaria que fizessem a você - se aplica aos gerentes. Os decretos dos líderes só serão obedecidos na nlesma medida daqueles que eles 1nesn1os seguem. Os seres humanos são criaturas sociais e aprendemos um comportamento ao longo de nossas vidas, predominantemente segundo os modelos de outras pessoas. Geralmente, nossa aprendizagem é mais eficiente quando vemos alguém que respeitamos ou admiramos fazer alguma coisa, e depois tentamos, consciente ou subconscientemente, emular esse comportamento. No que diz respeito à confiança, fica a critério dos líderes dos projetos demonstrarem o comportamento que esperam ou desejam das pessoas com as quais trabalham. Michael Jordan, entre suas cantas qualidades, desenvolveu u1na reputação de urna ética profissional intensa. E1nbora ele fosse o jogador de basquete mais bern pago e mais conhecido na NBA, apenas alguns poucos trabalhavarn como ele fazia. Isso elirninava qualquer possibilidade de jogadores solicitando para ficar fora dos treinos ou passar menos tempo se exercitando. O líder define u1n rnodelo, que os outros precisrun seguir.

Érica profissional à parte, a regra de ouro para os líderes é confiar suficientemente no próprio bom senso para seguir as 1nesn1as regras de todas as outras pessoas (consulte "Confie em si n1esn10 (autoconfiança)", mais adiante neste capítulo). Fazer isso significa permitir que as outras pessoas, parceiros ou subordinados, questionem ou desafiem o julgamento ou a conduta do líder. Se alguém civer recebido a atribuição de poder, será necessário algun1 tipo de

PoR QuE A LIDERANÇA É BASEADA NA CONFIANÇA 259

feedback para desafiá-lo (por exernplo, quem pode dizer que o irnperador es(á sern roupas?). Os bons líderes confiain suficien(etnen(e nos 1ne1nbros de sua equipe para - em algum mornenco, calvez em parcicular - solicicar um Jeedback sobre seus comporcamencos e dese1npenhos. É claro que o líder não é obrig<ido a cornar urna atitude pelo feedback ou sequer cornentar sobre ele, mas é difícil imaginar a possibilidade de êxito sem uma trajetória saudável e segura para que esse tipo de informação alcance o gerence de projecos.

Os líderes definem seu processo de feedback

Descobri que, em geral, as pessoas hesita.m em dar um feedback a figuras autoritárias. Como gerente, criei um hábito de pedir às pessoas que se reportassem a mim, nas reuniões semanais individuais, se existisse alguma coisa na qual elas gostariam que eu pensasse, ern relação ao meu trabalho, meu comportamento ou meu desempenho. Era raro que dissessern alguma coisa, embora eu soubesse que isso não aconcecia porque eu era urn gerente perfeito (não existem gererues perfei(os). Percebi que a única solução era confiança e (ernpo. Eu precisava ser persistente ao criar a confiai1ça necessária para que essas pessoas se sen(issem seguras para criticar a minha conduta - sem se preocuparem com o fato de que eu pudesse ficar na defensiva ou repreendê-las por seus co1nent'ários.

Mas assirn que eu estabeleci urn feedback com elas, percebi que a perspectiva delas era rnuito n1ais útil para me tornar um gerente rnelhor, do que o Jeedback que eu recebia de meu próprio chefe. Cercamence, eu não cinha esse tipo de relacionamenco com (Odos, 1nas a maioria das pessoas, cedo ou carde, 1ne dava uma resposta úcil. U1na sugestão para realizar uma reunião de modo diference, uma pergunta sobre uma decisão que cornei ou qualquer outro comencário garantiam que a discussão seguinte ajudasse a nos sentirmos 1nelhor em relação a qualquer assunto que viesse à baila.

Sempre que eu estava em un1a discussão e fizesse ou recebesse sugestões, eu tentava expor a diferença entre criticar uma idéia e criticar a pessoa que apresentou a idéia. Só porque a pessoa A concorda ou discorda de algo que a pessoa B est.á. dizendo, isso não significa que a pessoa A esteja julgando a pessoa B. Eu queria que os membros da equipe sentissem suficiente respeito e confiança uns pelos outros, a ponto de revelarem seus pensamentos e discordarem abertamente, sem pedir desculpas, e também sem os desnecessários comentários maliciosos ou hipócritas. O senso de humor ajuda muito a viabilizar tudo isso, e geralmente começa quando o líder demonstra quando o sarcas1no ou a zornbaria são adequados, talvez usando a si mesn10 como alvo das brincadeiras. Mas o que eu queria realmente dizer é que o próprio líder deve de1nonstrar o comportamento, controlar as pessoas que forem longe demais e conquistar aquelas que se esforçam para participar.

Isso cem tudo a ver co1n os conflitos e discórdias. Toda a autoridade concedida e conquistada não ajudará ninguérn, se essa pessoa ficar sentada enquanco coisas ruins estiverem acontecendo. Existem poucas aplicações rnelhores da influência e do poder do que interrornper argun1entos idioras e puxar o tapete das pessoas que abusaram dele. Quando as diferenças de opinião partirem para ataques pessoais ou para o uso de argumentos inverídicos para justificar decisões, alguén1 precisa interron1per e elevar o padrão. Não tolerando esse comportamenco, principalmente em uma definição e1n grupo, todos recebem a

260 A.ARTE DO GERENCIAMENTO DE PROJETOS

mesma 1nensagem ao mes1no re1npo: não cence esse cipo de desculpa novarnence ~

. . . porque nao ace1ra1nos isso aqui.

Evidenremenre, isso segue a regra de ouro, segundo a qual o verdadeiro líder precisa esrar preparado para a possibilidade (ou ralvez a inevirabilidade) de que os ourros desafiem seus próprios argumentos fàlsos, se ele tentar usá-los. Os melhores líderes são aqueles que se sentem bem ao ver a equipe se comprometendo tanto com seus padrões intelectuais, que não teme questionar inclusive o comporramento do líder.

Confiar e cometer erros

É fácil confiar nas pessoas quando são bem-sucedidas; gerenciar os erros das pessoas é muito mais complicado. É para isso que os gerentes são pagos.

Aprendi por experiência própria que sempre que urna pessoa aparecia na porca de meu escritório corn um problema que ela mesma havia ocasionado, eu devia cencar (mas nem sempre conseguia) manrer rrês coisas em rnente:

1. Estou feliz porque esra pessoa veio me procurar com esce problerna. É melhor que ela me procure em vez de oculrá-lo ou renrar solucionar por conra própria e piorar as coisas. Devo dizer isso a ela imediaramenre.

2. Como posso ajudar a corrigir o problerna, seja ele qual for? Trara-se de um problerna corrigível? Quais são as opções? Aré onde posso 1ne envolver? Devo fornecer a essa pessoa o máximo de aconselha1nenco necessário, n1as se possível, devo deixar a pessoa executar o que deve ser feiro. Contudo, eu preciso ter certeza de que a pessoa não escá confusa. Mandá-la de volta para um incêndio com 99o/o de certeza de morre não é exatamente un1a boa prática de gerencia1nento.

3. Preciso me cerrificar de que, se existir uma lição a ser aprendida aqui, a pessoa deverá aprender.2 A verdadeira aprendizage1n aconrece com os erros porque quem os comete investe pessoal e emocionalmente no que aconteceu, e essa pessoa rerá uma enorme motivação para não repeti-los (principalmenre se ela sentir que a equipe confia nela).

Se você pedir a quaisquer mescres inreligen res suas grandes lições, eles lhe conrarão hisrórias sobre corno escragararn alguma coisa, provavelmente algo i1nporcance, e finalmente aprendera1n uma maneira mais eficienre de superar o que quer que fosse. Aconcece que para se cornar excelence, não é necessário apenas comecer erros de vez em quando, 1nas você precisa de alguém que lhe dê a oporcunidade de cometê-los. Os gerentes faze1n jus a seus salários quando gerenciam os proble1nas porque não somence precisam ajudar na recuperação, como ramhém liderar o processo de conversão do erro em lição para a equipe aprender.

O bon1 gerencian1ento e a boa liderança atribue1n às pessoas o máxin10 de responsabilidade e autoridade que seu nível de capacitação e experiência permiten1, 1nas, de alguma forma, nunca deixando-as senrir que estão trabalhando sozinhas, ou que só têm o seu apoio quando as coisas estão indo bem. É razoável concluir que o potencial para co1nerer erros seja exaramenre o rnesmo necessário para contribuir e obter êxito. Isso significa que é injusto pregar as pessoas nas

POR QuE J\ LIDERANÇA i:. BASEADA NA CONFIANÇA 261

paredes por seus erros de julgamenco ou por problemas decorrences das decisões que comara1n.

Em vez disso, o a1nbience ideal para criar é aquele e1n que as pessoas se sence1n seguras en1 suas a1nbições, mas admicirão e assumirão a responsabilidade por seus erros. Elas devem se sentir suficientemence conftances para desejarem aprender o m.áxin10 possível, para que isso não aconteça novamente. Se a equipe compartilhar essa cultura de modo coletivo, ela se tornará autocorrerora. Quando existe um sistema íncegro para reconhecer, responder e aprender co1n os erros, no decorrer do tempo, bem menos erros tenderão a acontecer (ou quando ocorrerem, serão solucionados rapidamente) e as pessoas cerão 1nais confiança em tomar rodos os t ipos de atitudes na maior parte de seu tempo sem erros.

Nunca repreenda durante uma crise

A pior coisa do inundo, principalmente durance uma crise, é u1n gerente ou líder repreendendo alguém enquanto o problema ainda está sem solução. Isso não resolve nada e provavelmence 1nini1nizará a probabilidade de u1na solução nipida do proble1na, porque a pessoa que mais conhece o proble1na e1n quescão (o acusado) se sentirá culpado e ficará na defensiva. l1nagine alguém que trabalhou com você entrando em sua sala e gritando "Minha sala está pegando fogo! Minha sala está pegando fogo!", e tudo o que você poderia oferecer seria "Nossa Mãe do Céu, isso foi besteira. Por que você fez isso? Estou tão decepcionado com você". As pessoas fazem isso quase o tempo rodo e é difícil não questionar a sua orige1n. Creio que algumas pessoas acreditam, provavelmence por osmose de péssimos gerentes ou pais, que o 1nodo de começar a corrigir os problemas é levantando o dedo indicador e distribuindo acusações. Evidentemente, Í<izer com que as pessoas se sintam mal e indicar quem deve se sentir pior, em nada melhora a situação (saber quem começou o incêndio geralmente não ajuda a debelá-lo) . Em vez disso, depois que o problema for solucionado, quando as cabeças esfriarem e a pressão baixar, haverá todas as oportunidades para reconstituir o problema e descobrir o que aconceceu e por que, e conhecer as lições resulcances para as pessoas e1n geral, para o líder e a equipe.

Confie em si mesmo (autoconfiança)

/to seu próprio ser seja verdadeiro, e eis que se seguirá, como a noite ao dia, . que não deveis ser falso para ninguém. "

-Shakespeare, li amlet

O úl timo itetn sobre o relacionamento entre a liderança e a confiança é para você aprender a confiar em si mes1no. Este é um tema filosófico profundo, muito além do escopo desce livro. Concudo, acredito pia1nence que podere1nos cobrir u1n

. - . assunco importante nesta seçao sucinta. Se você exarninar os currículos do curso médio e da faculdade nos Estados

Unidos, exisce uma 1nacéria que você não enconcrará: como descobrir quem você é. Isso é 1nuico escranho. Para um país que dá muita iinporcância à individualidade e à liberdade, os Escados U nidos não faze1n n1uita coisa para

262 A.ARTE DO GERENCIAMENTO DE PROJETOS

ensinar a seus cidadãos u1na aucodescoberca, muito menos autoconfiança. A aucodescoberca é o processo de conhecer que1n você é co1no indivíduo, independencemence de seus amigos, fa1niliares, empregador ou nação. A aucoconfiança é a possibilidade de aplicar sua individualidade no inundo, com base em uma escrucura de apoio emocional, físico e financeiro por si próprio. Não significa que você tenha que viver nu na floresta, vivendo da cerra, mas, sim, que você pode olhar para dentro de si mesmo e encontrar forças para fazer as escolhas nas quais acredira, mesmo que os oucros não concorden1 com essas opções.

"Náo acredite ern nada, náo irnporta onde você tenha lido isso ou quern disse essas palavras, nem se eu mes1no tiver dito, a menos que isso esteja de acordo

corn seu próprio motivo e seu próprio senso comun1. "

-Buddha

No contexto tradicional, a liderança exige que as pessoas tenham alguma noção de aucoconfiança. Você pode correr um risco ou fazer uma escolha difícil somence se civer um co1npasso interno orientando-o na direção do que acha certo. Sem a aucoconfiança, todas as suas decisões se basearão e1n grande parte nas opiniões das outras pessoas ou no seu desejo de agradá-las, sem qualquer força centralizadora para guiar essas influências. To1n Pecers, John P. Kocter e outros autores chaman1 essa força centralizadora de u1n sisce1na de valor. Eles sugere1n que um conjunto de valores pode acuar como sua essência, ou núcleo da organização, orienrando-o nas sicuações difíceis. Essa abordage1n pode funcionar, mas sugiro algo n1ais profundo e pessoal.

A aucoconfiança con1eça quando você confia nas suas opiniões - você pode acreditar que algo é verdadeiro, mesmo que os oucros não acredicen1. Opiniões diferences deven1 negar as suas somence se você as considerar e, ao pensar sobre isso por conca própria, você mudar de idéia. De oucra forma, não há motivos para desistir de sua opinião sobre um assunto (você ra1nbém pode render-se em uma decisão, abrindo mão da sua autoridade sobre ela, mas isso não o obriga a desistir de sua opinião). Suas crenças devem ser auto-suficientes. Se você tivesse que mudar de idéia só porque as outras pessoas pensan1 diferente, estaria agindo contra a sua autoconfiança. Trair a confiança em si mesmo pode ser tã.o perigoso quanto trair a confiança e1n sua equipe.

Para o bravo, a autoconfiança vai 1nuito além. Você confia não somente em suas opiniões, como ta1nbém confia suficiencemente em sua essência para pennitir que suas opiniões 1nudem, e acé 1nes1no para admicir seus erros. Sem a 1nudança e o esforço ocasional, não podemos aprender ou crescer. Mas se você real1nence confia em si mesmo, reconhecerá que você ainda é você, 1nes1no quando fracassa ou vislumbra novas idéias. Emerson escreveu: "U1na consiscência escúpida é o fancasma das mences pequenas". Ele quis dizer que n1anter as 1nesn1as idéias só para preservar as 1nes1nas idéias não faz sentido. U1na pessoa inteligente deve estar aprendendo 1nais o cempo codo, o que lhe exigirá o desenvolvi1nenro de novas idéias e opiniões, mes1no que essas idéias e opiniões vão de encontro ao que significavam anrerionnence. Se levar uma vida emocional e incelectual aciva, suas idéias crescerão com você.

Isso significa que uma pessoa autoconfiance pode ter confiança em si mesma, embora descubra maneiras de pennitir que os outros a influenciem e ajudem a definir sua visão do futuro, permitindo todo o tipo de mudanças

POR QuE A LIDERANÇA i:. BASEADA NA CONFIANÇA 263

positivas. Você pode cometer erros, ad1nici-los e 1nudar de idéia, sem violar sua própria identidade.

Sendo assi1n, se puder aprender a confiar e1n si 1nesmo dessa maneira, você, como um subproduto da função da liderança, ajudar;i os outros a aprender a confiar neles n1esmos. Nenhum ato de delegação no mundo dos projetos ou na psicologia humana é mais poderoso do que ajudar as pessoas a acreditar na possibilidade de se tornaren1 n1ais autoconfiantes.

Recon1endo o ensaio Se/f Reliance de Ralph Waldo Einerson. Está disponível na maioria das edições de seus trabalhos em coleções, ou pode ser encontrado online, em hrcp://www.emersoncentral.com/selfreliance.hrm. O melhor livro genérico sobre aurodescoberta é Chop Wóod Carry Wáter, de Rick Fields Qeremy P. Tarcher, I 984). Para os aventureiros filosóficos, experimentem ler a obra de Albert Camus, The Myth o/Sisyphus (Vintage, 1991).

"Sornente quando o horne1n abre mão de todo o apoio externo e fica sozinho, eu o considero forte e sobrepujante ... Aquele que sabe que a força é inata, que o homem é ji'ttco porque {só]

procurou o que é bom fora dele e ern outros lugares, e r1Ssirn o percebendo, lança-se sern hesitar sobre seus pensamentos, endireita-se irnediatamente, 1nantém-se firme, controla suas ações, opera miúzgres; da mesma forma que u1n homem que se apóia nos próp1ios pés é mais

farte do que un1 homem que se apóia em sua cabeça. "'* - Ralph Waldo En1erson, excraído da obra Self Reliance

Resumo

• A confiança é construída através de compromissos efetivos.

• A confiança desaparece com o comportamento inconsistente diante de assuntos . importantes.

• Use a concessão de autoridade e a confiança para que as pessoas dêem o melhor de si.

• O poder concedido se origina na hierarquia organizacional. O poder conquistado ve1n apenas das respostas das pessoas às suas ações. O poder conquistado é mais útil do que o concedido, embora ambos sejarn necessários.

• Use a delegação para construir a confiança ern sua equipe e protegê-la contra a adversidade.

• Reaja aos problemas de nlodo a preservar a confiança das pessoas. Apóie-as durante as crises para que tragam os problen1as até você em vez de ocultá-los.

• A autoconfiança é a essência da liderança. A autodescoberta é un1a 1naneira de conhecer quem você é e de desenvolver uma autoconfiança saudável.

*N. de 1~: O ·rranscendentalis1110 ajudou os ron1âncicos a se libcnarcn1 dos cânones religiosos puritanos, que opunhan1 Deus ao ho111ein. Para estes, Deus estava fora do hon1en1. Para os n-anscendentalistas, Deus escava em tudo na nacure"la, inclusive dentro do home111. Assin1, contra a idéia de que os recursos necessários para a força devessern ser buscados no racionalis1110 (na cabeça) ou no exterior, para Er11erson deveri:un ser buscados no próprio sujeito, dai a necessidade de planrar-se independenrernenre e de forrna auroconfiance sobre os próprios pés, ern vez de colocar-se h11111ildernenre e111 adoração a wna enridade externa a ele.

Capítulo 13

Como fazer as coisas acontecer

266 A ARTE DO G ERENC[AMENTO DE PROJ ETOS

S egundo um mito do gerencia1nento de projetos, decenninadas pessoas possue1n urna habilidade natural de fazer ben1 as coisas, e outras não. Se1npre que esse miro vinha à baila en1 conversas com outros gerentes de projetos, eu sempre pedia uma explicação sobre essa habilidade - co1no reconhecê-la, classific.-i-la e, se possível, desenvolvê-la nas outras pessoas. Após várias discussões e debates, o úni.co aspecto que habitualmente identificávamos - depois de examinarmos vários oucros tópicos e apcidões discutidos neste livro - é a habilidade de fazer as coisas aconrecerem. Algurnas pessoas conseguem aplicar suas apcidões e ralenros em um mix necessário para o avanço dos projetos, e outras não, 1nesrno que essas {i!ti1nas tenham aptidões pessoais idêncicas ou superiores. A habilidade de fazer as coisas acontecerem é uma combinação de saber ser um cacalisador ou motivador em uma grande variedade de situações distintas, e ter a coragem de fàzê-lo.

Essa habilidade de orientar é tão importante para alguns, que é utilizada corno u1n parâ1netro de referência (teste de litmus) na contratação de gerentes de projecos. Mesn10 que os GPs não possa1n definir co1n exacidão que habilidade é essa, sem fazer pelo 1nenos algumas referências a outras aptidões, eles realinente sabem que é possível perceber ou avaliar a sua presença e1n oucras pessoas. Por exemplo, um entrevistador precisa fazer a si rnesmo a seguinte pergunta sobre o candidato: "se as coisas não estivessem indo bem em uma parte do projeco, você teria confiança de colocar essa pessoa naquela sala, naquela discussão ou debate, e acreditaria que essa pessoa encontraria urna maneira de melhorar o projeto, fosse qual fosse o proble1na?" Se depois de un1a rodada de entrevistas, a resposta for não, o candidato será dispensado. 1 A conclusão é que, se ele não é suficientemente ágil ou flexível para adaptar suas experiências e conheci1nenco às situações e1n questão, e encontrar meios de fazer as coisas evoluírern, ele não sobreviverá, muito menos se empenhará en1 qualquer projeto. Este capítulo discorre sobre essa habilidade e sobre as aptidões e táticas pertinentes.

Prioridades fazem as coisas acontecer

Investi boa parte de meu tempo como GP preparando !iscas de prioridades. U1na lista de prioridades é apenas uma coluna de itens classificados por ordem de importância. Estou certo de que, a despeito de todo o conhecimento e todas as aptidões que supostamente eu deveria ter e usar, no final das contas, tudo o que realmente fiz foi criar listas de prioridades. Colecionava as coisas que precisavam ser feitas - requisitos, recursos, bugs, tudo o mais - e classificava-as pela ordem de importância para o projeto. Eu passava horas e dias apri1norando e revisando essas listas, integrando novas idéias e infonnações, debatendo e discutindo-as co1n os outros, garantindo sempre que estivessem sólidas co1no u1na rocha. Encão, assim que a !isca já estivesse ern vigor, eu oriencava e comandava a equipe o mais arduamente possível para seguir as coisas na seqüência definida. °As vezes, essas !iscas englobavatn o modo corno o meu próprio te1npo deveria ser aplicado em determinado dia; outras vezes, as listas abrangian1 o que equipes inceiras de profissionais furiam durante semanas ou 1neses. Mas o processo e o efeito eram os n1esmos.

Eu investia muito ten1po nessas listas porque sabia que ter prioridades claras era a base do progresso. Para que as coisas aconteçam, é necessário ter um senso claro de quais coisas são mais imporcantes do que oucras e aplicar esse senso a

COMO FAZER AS COISAS ACONTECER 267

roda inreração ocorrida na equipe. Essas prioridades devem ser refleridas e1n rodo email enviado, rodas as pergunras feiras e em roda reunião realizada. Todos os progra1nadores e resradores devem invesrir energia no que muiro provavelinenre viabilizará o êxico. Alguérn precisa se dedicar a idencificar quais são essas coisas e a orientar a equipe para liberá-las.

O que atrasa o progresso e desperdiça a maior parte do tempo nos projetos é a confusão sobre quais são as metas ou o que deve acontecer antes do quê. Muitas comunicações e etapas incorreras ocorrem porque a pessoa A pressupôs uma prioridade (agilizou algo) e a pessoa B presu1niu outra (rornou algo 1nais estável). Isso se verifica nos programadores, cescadores, profissionais de marketing e em equipes inceiras de profissionais. Se for possível evitar esses conflitos, mais tempo poderá ser efetivamente aplicado no avanço das meras do projeco.

Isso não quer dizer que os debates sobre prioridades não devem acontecer -deven1, sim. Mas devem ocorrer no início, como parte do processo de planejamento que está sendo aplicado. Se os mesmos argumentos continuarem aparecendo durante o desenvolvimento, isso significa que as pessoas não escavam efecivamente convencidas das decisões tomadas, ou que se esqueceram da lógica e precisa1n ser lembradas do que 1norivou essas decisões. Procure nutrir os debates com idéias e planos, 1nas co1nece perguntando se alguma coisa mudou, desde que os planos foram definidos, que justifique a reconsideração das prioridades. Se nada rnudou (conduta da concorrência, nova rnissão do grupo, mais/menos recursos, novos problemas significativos), n1antenha a decisão já ton1ada.

Se existir u1na !isca de prioridades afixada na parede, esclarecendo o que foi estipulado como 1nais i1nportante, esses argumentos serão rapida1nente encerrados e não voltarão mais. As listas de prioridades concedem a rodos tuna estrutura compartilhada de lógica, a partir da qual se pode to1nar decisões. Se as 1netas esciverem claras e bem compreendidas, haverá menos necessidade de interpretações e menos chances de desperdício de esforços.

Por conseguinte, se algumas coisas na equipe, em algum momento, não estivessem indo bem e as pessoas estivessem com dificuldades de se concentrarem nas coisas importantes, eu sabia que a culpa era minha: ou eu não cinha ordenado as coisas de modo adequado, não cinha informado essas prioridades de 1nodo efetivo, ou não tinha conseguido execucar e liberar na seqüência estipulada. Nesse caso, trabalhar com atribuição de prioridades e com listas de prioridades significava tudo.

Listas de prioridades comuns

Trabalhar sempre con1 urna ordem de prioridades definida facilica a implementação de ajustes e alterações. Se, por algurn milagre, mais ternpo ou recursos forem detectados no cronograina, ficasá claro o próximo itern mais i1nportante no qual se deve trabalhar. Fazendo uso da 1nes1na referência, se for necessário corcar algo no cronogra1na, rodos saberão qual é o próximo icem menos in1porcance e poderão interromper o seu crabalho nesse icern. Isso é n1uico importante porque garante que, a despeito do que acontecer, você tenha realizado o trabalho mais importante possível e consiga fazer ajustes rápidos sem muito esforço ou sen1 afetar a motivação. Alén1 disso, os erros de atribuição de prioridades con1etidos serão relat.ivos: se o ir.em de trabalho 10 tornar-se mais

268 A ARTE DO GERENC[AMENTO DE PROJETOS

imporcance do que o ice1n de crabalho 9, sem problema. Como a )isca inceira escava ordenada, você não cerá co1necido u1n erro cerrível. E alé1n do mais, se exiscirem prioridades claras e a equipe se manciver concencrada nessas prioridades, muiro provaveln1enre você rerá conseguido o rempo necessário para finalizar o iten1 de trabalho 10 antes de tudo.

Na maioria dos projetos, as crês listas de prioridades mais importantes e formais são usadas para atribuir prioridades às meras, aos recursos e itens de trabalho do projeto (consulte a Figura 13-1). Geralmente, as meras do projeto fazem parce do documenco de visão (consulte o Capítulo 4) ou são derivadas desse documenro. As listas de recursos e irens de trabalho resulram do processo de design (consulte os Capítulos 5, 6 e 7). Como cada uma dessas listas herda as prioridades da lista anterior, retrocedendo uma etapa acima até atingir um ponto de esclarecimento e depois reaplicando essas prioridades no próximo nível em questão, é possível começar a resolver quaisquer contendas. Embora isso nem se1npre resolva os debates, pelo 1nenos garantirá que toda decisão seja tomada no contexto do que é realmente importante.

Usta de metas Usta de recursos

-

-

Lista de itens de trabalho

FIGURA 13-1. As três listas de prioridades mais importantes, apresentadas em seqüência.

Outros aspectos importantes que pode1n precisar de listas de prioridades são bugs, sugestões dos clientes, bônus concedidos aos funcionários e orça1nentos das , equipes. E possível gerenciar tudo isso de modo semelhante: colocando as coisas na seqüência com maior probabilidade de trazer êxito para o projeto ou a organização. A despeito do grau de complexidade das ferramentas utilizadas (por exemplo, para o rastreamento de bugs), nunca se esqueça de que tudo o que você está fazendo é classificar coisas. Se as ferra1nentas ou os processos utilizados não ajudare1n a ordená-las e a executar nessa seqüência, procure outra ferra1nenca ou processo. Por exemplo, na realidade, a triagem de bugs, onde as pessoas encra1n e1n u1na sala e decidem quando u1n bug deverá ser corrigido (se for o caso), é apenas u1n processo e1n grupo para criar u1na lista de prioridades de bugs. É possível classificá-los por grupos e1n vez de individualinence, bug por bug, 1nas a finalidade e o efeito são os mes1nos.

Se você realmente usar as crês listas de prioridades n1ais co1nuns, cercifique­se de que elas estejam sempre mapeadas entre si. Todo item de trabalho de engenharia deve estar nlapeado para un1 recurso, e rodo recurso deve estar mapeado para un1a meta. Se for adicionado un1 novo ice1n de trabalho, ele deverá corresponder a recursos e n1ecas. Esta é uma função imposta para evitar os

COMO FAZER AS COISAS ACONTECER 269

recursos aleacórios. Se u1n VP ou programador desejar incluir algo excra, será obrigado a jusdficá-lo e1n relação ao que o projero esrá renrando aringir: "Esre é um excelenre recurso, chefe, mas que 1nera esse recurso nos ajudará a acender? Deveremos ajuscar as n1eras e lidar co1n as conseqüências, ou não deveremos investir qualquer energia aqui". Se você ensinar à equipe que é uma regra manter esses três níveis de tomada de decisões em sincronia, você focará a equipe e evitará uma perda de tempo.

Prioridade 1 versus tudo o mais

Geralmente, essas listas de prioridades têm uma linha importante dividindo-as em duas partes. A parte superior é a prioridade 1: coisas que devemos Fazer e que não obteren1os êxito sem elas. A segunda parte é tudo o mais. As prioridades 2 e 3 existem 1nas são consideradas coino de tipos totalmente diferentes das coisas da prioridade 1. É muito difícil promover itens da prioridade 2 para a prioridade 1.

Considere essa linha da prioridade l co1n 1nuica seriedade. Esforce-se por 1nanrer essa lisra o mais curca e resrri ra possível (isso se aplica a quaisquer lisras de 1neras no documento de visão rambé1n). Um ite1n da lista de prioridade l significa "1norreremos sem isso". Isso não significa irens que são bons de se rer ou que realmenre desejamos cer: identifica a maneira mais curra e enxuta de atender às n1etas do projeto. Por exemplo, se estivéssemos construindo um auton1óvel, os únicos irens da prioridade 1 seriam n1otor, pneus, trans1nissão, freios, volanre e pedais. Os irens da prioridade 2 seriam porcas, pára-brisa, ar­condicionado e rádio, porque você pode conrornar a ausência desses irens. A funcionalidade básica do auron1óvel existirá sem eles; você poderia enrregá-lo e ainda chamá-lo de carro.

Sempre foi difícil colocar essa linha em prática; havia muitos questionamentos e debates sobre as coisas sem as quais os clientes poderiam viver ou sobre aquelas n1ais importantes do que outras. Isso era bom. Queríamos que rodos os debates e questionamentos ocorressem logo no início, para depois seguir em frente. Por 1nais angustiante que fosse, quando terminássemos, teríamos uma lista que sobreviveu às opiniões e perspectivas da equipe. Poderíamos prosseguir e executar, respaldados pelas impugnações e argumentos de apoio da lista que preparamos. Após submetê-la a debates e argumentações, estávamos preparados para 90o/o das pergunras co1nuns ou desafios possivelinence suscitados mais carde pelas pessoas (por exemplo, por que esrávarnos construindo os freios e não o ar-condicionado) e podería1nos despachá-los rapidamente: já cínha1nos ouvido os argumentos e sabía1nos por que eles não foram sustentados.

O desafio de atribuir prioridades é sempre 1nais e1nocional/psicológico do que inreleccual, apesar do que as pessoas coscu1na1n dizer. Exaramence como acontece ao fazer diera para perder peso ou fàzer um orçamenro para economizar, para eliminar as coisas que deseja (mas não necessira), você deve estar disciplinado, coinpromissado co1n e focado nas meras iinporrantes. Dizer "a estabilidade é importante" é uma coisa, mas fazer uma con1paração classificando-a em relação a outros aspectos importantes é totalmente diferente. Muitos gerentes ciscan1 fora desse processo. Eles se resguardam, atrasam e negam as escolhas difíceis, e conseqüenremenre configuram seus

270 A ARTE DO G ERENCl1\MENTO DE PROJ ETOS

projetos para o fracasso . Nenhurna escolha difícil significa i1npossibilidade de progresso. Em rerrnos abstratos, a palavra importante nada significa. Sendo assi1n, as listas de prioridades e a declaração de um padrão de alca prioridade 1 obrigam os líderes e a equipe inceira a tomar decisões difíceis e a raciocinar de modo transparente.

Clareza é o modo pelo qual você faz as coisas acontecerem nos projetos. As pessoas vên1 trabalhar todos os dias com uma firme idéia do que estão fazendo, por que estão fazendo e de que 1nodo isso se relaciona com o que os outros estão fazendo. Quando a equipe quesriona por que uma coisa é mais importante do que ourra coisa, há motivos claros e l6gicos para isso . .Nlesmo quando as coisas mudam e as prioridades são ajustadas, tudo acontece dentro do mesmo sistema básico de listas de prioridades e atribuições de prioridades.

Prioridades são poderosas

Você já participou ern urna argurnentação complexa que, en1 algum rno1nento, achou que nunca rerrninaria? Talvez rnetade dos engenheiros já sentiu uma forre rendência por A, enquanto a ourra rnecade se posicionava a favor de B. Mas, em seguida, o líder da equipe encra em cena, fàz algumas perguncas, secciona a discussão de oucra 1naneira e consegue rapidamence que rodos cheguem a u1n acordo. Isso aconceceu co1nigo várias vezes. Quando era 1nais joven1, eu acribuía à genialidade: de algun1a fonna, aquele gerence ou programador chefe era simplesmence mais inteligente que as oucras pessoas presenres na sala, e via coisas que não víamos. Mas ao presrar 1nais arenção, e ocasional1nenre aré 1nesrno perguntando posreriorrnenre corno isso rinha aconrecido, percebi que era tudo uma questão de cer prioridades s6lidas como tuna rocha. Eles 1nemorizavam uma lista de prioridades e conseguiam fazer com que as outras pessoas estruturassem a discussão em torno dessa lista. Boas prioridades são poderosas. Elas elin1inam as variáveis secundárias da discussão, permitindo focar e resolver problemas.

Se você tiver prioridades e111 vigor, poderá sempre fàzer perguntas em qualquer discussão que reenquadrem o argurnento em torno de uma consideração básica mais úcil. Isso reciclará a idéia que todos fàzem sobre o que significa realmente o sucesso, dividindo visivelmente o universo em dois pilares: coisas imporranres e coisas boas, mas não irnportances. Exarnine a seguir alguns exemplos de perguntas:

• Que problerna escamos centando resolver?

• No caso de vários problemas, qual é o 1nais i1nporcance?

• De que n1odo esse problen1a esrá relacionado con1 ou afeta nossas n1eras?

• Qual é a 1naneira mais simples de corrigir isso, que nos permira acender às nossas metas?

Se não houver nada mais, você redefinirá a conversa de modo a focar as metas do projero, corn o que todos concordarão. Se foi realizado um debate durante horas, encontrar urna base comu111 é a sua melhor oportunidade de avançar a discussão para uma conclusão positiva.

COMO FAZER AS COISAS ACONTECER 271

Seja uma máquina de atribuição de prioridades

Sempre que eu conversava com os progra1nadores ou (e5(adores e ficava conhecendo seus proble111as ou desafios, percebia que 1ninha imporrância fundan1ental estava em ajudá-los a se concenrrar. Meu objetivo era elin1inar coisas secundárias ou terciárias de suas planilhas e ajudá-los a vislumbrar uma seqüência de rrabalho clara. Há n1iJ modos de implementar um design de dererminada página da Web ou un1 sisrema de banco de dados para especificações, mas apenas alguns desses modos realmente fixarão os objetivos. Sabendo disso, estimulei os progran1adores a me procurar se estivessem diante de u111a decisão na qual eles não rivessem certeza se deveriam fazer algum investimento de tempo em seguida.

Em vez de microgerenciá-los ("Faça isso. Não, faça aquilo. Não, faça isso dessa maneira. Já terminou? Que tal agora?"), eu fàzia com que eles entendessem que eu estava al i para ajudá-los a atribuir prioridades quando fosse necessário. Corno eles não tinham a perspectiva no nível do projeto, que eu tinha, a importância da minha presença estava e111 ajudá-los a ver, 111esmo que apenas por alguns instantes, de que rnodo o que eles estavam f.1zendo se encaixava no projeto inteiro. Quando eles passavam o dia inteiro depurando u111 módulo ou rodando cesces de unidades, geralrnence eram liberados de obcer esclarecimentos de nível superior, reconfirmação e confiança no que escavam realizando. Freqüencemence, baseava un1a conversa de 30 segundos para rer certeza de que rodos nós ainda

' , . estavan1os na mesn1a pagina. Sempre que chegava1n novas infor111ações para o projeto, meu serviço era

inrerpretá-las (sozinho ou e1n discussão com os ourros), e integrá-las a uma lisra de tarefas priorizadas nas quais precisávamos estar acentos e tarefas sem canta importância. Em geral, eu reria que revisar uma lista anterior, ajusrando-a para responder às novas informações. Um VP poderia mudar de idéia. Um escudo da usabilidade poderia detectar novos problemas. Um concorrente poderia fazer uma n1udança inesperada. Essas prioridades estavam vivas, respirando coisas e quaisquer alterações efetuadas em nosso rumo ou nas nleras se refletiam nelas, direta e i1nediatan1ente.

Como controlava as prioridades, eu perrniria que a equipe se concentrasse nas tarefas importantes e realmente avançasse nessas tarefas. Às vezes, eu podia reutilizar as prioridades definidas por meus superiores (documentos de visão, declarações de missões dos grupos); outras vezes, eu tinha que inventar rneu próprio esquema em respos(a a situações de ambigüidade ou irnpreviscas. Encreranro, mais do que qualquer oucra coisa, eu era uma máquina de atribuição de prioridades. Se algum dia exis tir u1na estátua em ho1nenagem aos bons gerentes de projetos, acho que a inscrição diria: "Traga1n-me sua aleatória, jusrificadarnente confusa, sarcástica e amarga 1nassa de prograrnadores sedentos de esclarecin1entos".

Algo acontece quando você diz não

Um efeito colateral de ter prioridades é a freqüência com que você é obrigado a dizer não. É uma das n1enores palavras existentes e mesmo assim, muitas pessoas sentem dificuldade em dizê-la. O problen1a é que se você não conseguir dizer não, não poderá ter prioridades. O universo é um lugar iinenso, mas a sua lista de

272 A.ARTE D O G ERENC[AMENTO DE PROJ ETOS

prioridades 1 deve ser muico pequena. Portar1co, a 1naior parte daquilo que as pessoas no inundo (ou e1n sua equipe) poderia1n supor que são grandes idéias cerminarão não correspondendo às metas do projeco. Isso não significa que suas idéias são ruins; quer dizer apenas que as idéias dessas pessoas não conrribuirão com esse projero específico. Portanto, u.ma lei básica do universo dos GPs é a seguinte: se você não conseguir dizer não, não poderá gerenciar um projeto.2

Dizer não con1eça de cima para baixo en1 un1a organização. O pessoal mais experiente em um projeto determinará se as pessoas podem realn1ente dizer não às solicicações. Não imporca o que as prioridades digam, se o chefe dos desenvolvedores ou o gerente diz sempre si111 a coisas que não estão relacionadas com as prioridades, as outras pessoas fi1rão o mesmo. Os programadores trabalharão nos recursos favoritos. Os GPs acrescentarão requisitos (ocultos). Mesmo que essas escolhas individuais sejam boas, como a equipe nã.o está mais seguindo as mesmas regras, nem trabalhando com as mesmas prioridades, ocorrerão conflitos. Algu1nas vezes, serão discórdias entre programadores, 1nas, com freqüência, o resultado apresentará designs finais desconjuntados. A estabilidade, o desempenho e a usabilidade sofrerão. Se1n o enfoque nas prioridades, é difícil fazer com que uma equipe se coordene em torno da 1nesma coisa. Os melhores líderes e gerentes de equipe sabem que é necessário dar um jeico de dizer não para o que estiver fora do escopo, estipulando um padrão para a . . . equipe 1nce1ra.

Quando você realmente diz não e faz isso valer, o projeto ganha ín1peto. Eliminar tarefas das planilhas das pessoas concede-lhes mais energia e n1otivação para focar e trabalhar arduamente no que precisan1 fazer. A quantidade de reuniões e discussões aleatórias diminuirá e a eficiência aumentará. Será formada uma força viva en1 torno de dizer não: os outros começarão a agir assim em suas esferas de influência. Na realidade, pedia aos membros da equipe que fizessem isso. Eu dizia "Se vocês acham que escão sendo solicitados a fazer algo que nã.o tem nada a ver com nossas prioridades, digan1 não. Ou digam que eu disse não, e que venha1n falar comigo. E não percam ten1po argumentando com quem quer que seja, se receberem reclamações - ensinem onde é possível me enconcrar". Eu nã.o queria que eles desperdiçassem tempo discutindo sobre as prioridades porque isso era 1neu serviço e não deles. Mesmo que eles nunca enfrentassem tais situações, eu conseguia transmitir a seriedade das prioridades e como eu gasearia de trabalhar a favor deles.

Dominar as várias maneiras de dizer não

Algumas vezes, você precisará dizer não como uma resposta direca a tuna solicitação de recurso. Outras vezes, você precisará se intrometer em uma conversa ou reunião, identificar o conflito com as prioridades que você surpreendeu e efetiva1nente dizer não ao que quer que esceja em discussão. Para se preparar para isso, é necessário conhecer todos os tipos diferences de uso da palavra não:

• Não, isso não se encaixa em nossas prioridades. Se for no início do projeto, crie u1n argumento para o motivo pelo qual as prioridades atuais são eficientes, mas ouça as pessoas sobre o nlotivo pelo qual as outras prioridades fariam nlais sentido. Talvez elas cenha111 boas idéias ou precisem de esclarecimenros sobre as

COMO FAZER AS COISAS ACONTECER 273

meras. Encrecanco, faça corn que a discussão gire em corno das prioridades do projeco, e não em corno de uma imporcância abscraca de tuna solicicaç,'io de recurso ou de correção de bug. Se aconcecer no final do projeco, você pode dizer que eles perderam o bonde. Mes1no que as prioridades absorva1n tudo, elas não mudarão com base na idéia de um único recurso. Quanto mais avançada for a fase do projeto, tanto mais drástico deverá ser o fracasso do projeto para justificar ajustes de meras.

• Não, só se tivermos tempo. Se você mantiver as prioridades enxutas, sempre haverá n1uicas idéias boas que não foram selecionadas. Expresse isso como uma decisão relativa: a idéia em questão pode ser boa, mas não suficientemente boa em relação às outras prioridades do trabalho e do projeto. Se o item estiver incluído na lista de prioridades 2, informe que é possível fàzê-lo mas que ninguém aposte alto, presumindo que isso acontecerá.

• Não, só se você fizer <inserir aqui urna coisa impossível> acontecer. Algumas vezes, é possível redirecionar uma solicicação de volta para a pessoa que a enviou. Se seu VP pedir que você inclua suporte para um novo recurso, diga a ele que você só pode fazer isso se ele cortar uma de suas outras solicitações atuais de prioridade 1. Isso afasta o ponto de contenção de você e o direciona para u1na situação tangível, e1nbora provaveln1ente inatingível. Isso ra1nbé1n pode ser feito por questões políticas ou de aprovação: "Se você puder convencer Sally de que esta é uma boa idéia, eu a levarei em consideraç,'io". Contudo, isso pode ter o efeico contrário ao desejado. (E se ele realmente convencer Sally? Ou pior, se ele perceber que você o está fazendo de tolo?)

• Não. Na próxima versão. Presumindo que você esteja trabalhando em um projeto de site ou de software, que terá mais atualizações, ofereça-se para reconsiderar a solicitação na próxima versão. É provável que isso aconteça de qualquer maneira para todos os itens de prioridade 2. Geralmente, isso se chama adiar ou jogar para frente.

• Não. Nunca. Jamais. Sério. Algumas solicitações são tão desassociadas com as metas de longo prazo, que o martelo tem que ser batido. Corte a corda agora e economize seu tempo respondendo à mesma solicitação mais adiante. Às vezes, compensa o esforço de explicar o por quê (para que escejam 1nais infonnados na próxima vez). Exe1nplo: "Não, Fred. O 1necanis1no de pesquisa do site nunca oferecerá suporce para o idiorna esperanco. Nunca. Jarnais."

Preservar a realidade

Algu111as equipes têm um senso mais apurado da realidade do que outras. Você encontrará 1nuitas histórias de equipes de projeto que liberara1n seu produto 1neses ou anos depois, ou foram injetados 1nilhões de dólares aci1na do orça1nenro (consulte a obra de Robert Glass, Sofavare Runaways, Prentice Hall, 1997). Pouco a pouco, as equipes acreditam em pequenas 1nenriras ou exposições incorreras da verdade sobre o que está acontecendo, e entram em situações perigosas e improdutivas. Em geral, quanto mais uma equipe se afastar da realidade, tanto n1ais difícil será fazer com que as coisas boas aconteçan1. Os líderes de equipes devem desempenhar a função de manter a honestidade da equipe (no sentido de que a equipe pode perder o contato com a realidade, não que seus membros

274 A ARTE DO G ERENC[AMENTO DE PROJ ETOS

deliberadamente mintatn), le1nbrando às pessoas quando elas esciverem mascarando as respostas, ignorando sicuações proble1nácicas ou se concencrando nas prioridades erradas.

Lembro-me de urna reunião em que parricipei, anos arrás, com uma pequena equipe de produros. Os membros dessa equipe escavam construindo algo que desejavam que a minha equipe utilizasse, e a apresentação estava focada nos novos recursos e recnologias de seus produtos. Senrado perto do final da sala, eu me sencia cada vez mais desconforcável com a apresentação. Nenhu1na das questões co1nplexas escava sendo solucionada ou sequer 1nencionada. Acé que eu percebi qual era o verdadeiro problema: pelo fato de não esrarern solucionando os problemas importantes, eles estavam desperdiçando o tempo de rodos.

Olhei ao redor da sala e entendi parte do problema: eu era o único líder da minha organização que estava participando. Normalmente, eu esperaria que outro GP ou programador chefe fizesse perguntas difíceis. Mas com aqueles caras na sala, eu não sabia se alguém 1nais estaria em condições de criar casos, quando necessários. Mil perguntas rne vierarn à. mente e eu levantei rapidamente a minha mão, deslanchando u1na seqüência de perguntas sirnples, uma após a outra. "Qual é o cronograrna de vocês? Quando vocês poderão trabalhar no código para nós? Quem são seus oucros clientes e de que modo vocês atribuirão prioridades às solicirações deles em relação às nossas? Corn que interesses nos tornaríamos dependentes de vocês e de sua equipe?" Os queixos deles caíram. Eles estavam totalrnente despreparados.

Estava claro que eles não tinha1n pensado naquelas perguntas antes. Pior ainda, eles não esperavam ter que respondê-las aos possíveis clientes. Expliquei educadan1ente que eles não escavam preparados para aquela reunião. Pedi desculpas se minhas expeccativas não fora1n claras quando a reunião foi marcada (achei que estavam). Disse-lhes que sem aquelas respostas, a reunião desperdiçava o cernpo de todos, inclusive o deles. Sugeri que adiássemos o restante da reunião até que tivessem respostas para aquelas perguntas simples. Eles concordaram cordialmente e a reunião terminou.

No linguajar dos GPs, o que fiz nessa história foi gritar desconfio. Trata-se de uma referência ao jogo de cartas Desconfio, onde o vencedor é aquele que se livra de rodas as cartas que tem na mão. Em cada rodada do jogo, um jogador declara que cartas ele está jogando ao colocá-las viradas para baixo em uma pilha. Ele não é obrigado a dizer a verdade. Porcanco, se, ern algurn 1no1nenco, outro jogador achar que o pri1neiro escá mentindo, poderá gricar "desconfio" e obrigar o primeiro jogador a mostrar suas cartas. Se o acusador estiver certo, o primeiro jogador levará rodas as cartas da pilha (um importante revés). Contudo, se o acusador estiver errado, ele levará a pilha.

Gritar "desconfio" faz as coisas acontecere1n. Se as pessoas esper-arn que você responda a perguntas cornplexas e não hesitam em cobrar até ter as respostas, elas se prepararão para isso antes de se reunirem com você. Elas não desperdiçarão o seu tempo ne1n o da equipe. Lernbre-se de que rodos os cipos de decepção, inclusive a decepção consigo mesrno, trabalharn contra os projetos. Quanto mais cedo a verdade vier à tona, canto mais rapidamente você poderá fazer algo relacionado. Con10 a maioria das pessoas evita conflitos e prefere fingir que tudo está bem (mesmo diante de evidências de que não está), alguém cem que extrair essa verdade. Quanto mais você puder nlanter a verdade à tona, canco mais a sua equipe poderá pertnanecer centrada, movendo-se rapida1nence.

COMO FAZER AS COISAS A CONTECER 275

O desafio ao quescionar oucras pessoas é que isso pode ir de enconcro à culcura de um indivíduo ou de uma organização. Algu1nas culcuras consideram o quesciona1nenco um insulco ou falta de confiança. Elas podem incerprecar as renracivas de 1nancer a honescidade co1no ataques pessoais, e1n vez de verdadeiras investigações da verdade. Talvez você precise abordar essas situações de modo mais formal do que fiz na história. Faça uma lista de perguntas que espera que as pessoas respondam e forneça às pessoas antes da reunião. Ou crie uma !isca de perguntas que qualquer un1 na organização pode pergunrar a qualquer un1, a qualquer momenco (inclusive VPs e GPs), e afixe-a na parede de uma sala de conferência. Se você tornar público desde o priineiro dia que, a qualquer momento, alguém poder<í gritar "desconfio" você incorporará essa investigação à cultura, sem insultar ninguém. Contudo, os líderes ainda terão o fardo de gritar "desconfio" periodicamente, demonstrando para a equipe que é possível expor rapidan1ente a verdade.

Conhecer o caminho crítico

Na cenninologia do gerenciamenco de projecos, caminho crícico é a seqüência 1nais curta de trabalho que pode finalizar o projeto. Na análise do caminho crítico, é criado un1 diagran1a ou fluxograma de rodos os irens de trabalho, rnostrando quais itens dependen1 de quais outros. Se preparado corretan1ente, esse diagrama indicará onde estarão os gargalos. Por exe1nplo, se os recursos A, B e C não puderen1 ser concluídos antes da finalização do D, então o recurso D está no ca1ninho crícico nessa parte do projeto. Isso é iinportance porque se o D estiver arrasado ou concluído de 1nodo ineficiente, ele afetará drasticamente a finalização dos irens de rrabalho A, B e C . Sendo assim, é imporranre que um gerenre de projetos planeje e priorize o caminho crítico. Ocasionalmente, un1 componente relativan1ente sem importância por si só pode ser a dependência critica que impede o término de u1n trabalho de prioridade 1. Sem fazer tuna análise do caminho crítico, é possível que você só reconheça esse aspecto quando for tarde demais.3

Sob uma perspectiva de nível superior, rodas as situações têrn um caminho crítico. Elas não precisarn ser diagramadas ou avaliadas com o mesmo nível de deralhamento, mas os processos referenciais ao avaliar v;í. rias situações do GP são semelhantes: examine o problema como uma seqüência de lig-Jções, e verifique onde estão os gargalos ou pontos críticos. Quais decisões ou ações dependem de quais outras? Em seguida, examine se elas escão recebendo atenção suficiente ou se o verdadeiro problerna não é o que está sendo arualrnence discutido. Você agilizará ba.stance urna equipe, se direcionar a atenção dessa equipe para os principais elernentos, fatores e decisões para o progresso.

Tenha sempre urna idéia do caminho crítico de:

• Trabalho de engenharia do projeto (co1no descrito anreriormenre, de 1nodo sucinto)

• Processo de co1nada de decisão de alro nível do projeto (quem está arrasando a equipe?)

• Processos da equipe para criar o código e rastrear bugs (há formulários, reuniões ou aprovações desnecessárias?)

276 A.ARTE DO GERENCIAMENTO DE PROJETOS

• Processo de produção do con[eúdo de apoio para a Web ou in[rane[

• Qualquer reunião, si[uação ou processo que afe[e as meras do projeto

Para fazer as coisas acon[ecere1n, é real1nence necessário um sólido conheciinenco dos caminhos crícicos. Se1npre que você encrar em uma sala, ler um email ou tomar partido em uma decisão, analise os caminhos críticos. Esta é a questão realmente fundamental? Esta discussão ou linha de raciocínio solucionará a questão? Convén1 focar a sua energia (ou a energia da sala) primeiramente na solução dessas considerações e na análise do que deve ser feico para garantir que esses carninhos críticos se tornem mais curtos ou tenham recursos suficientes, para evitar atrasos. Se você conseguir fixar o caminho crítico, as questões menos críticas se acomodarão mais f:1cilrnente.

Para algumas organizações, o método mais rápido de aperfeiçoar o caminho crícico (não relacionada corn a engenharia) é delegar autoridade na equipe. Em vez de exigir um consenso, deixe que as pessoas tomem as decisões e usem seu bom senso para julgar quando um consenso é necessário. Faça o mesmo em relação a aprovações, documentação, formulários ou outros possíveis fardos burocráticos (consulce o Capítulo 1 O). Em geral, a melhor forrna de aprirnorar os carninhos críticos nas organizações é recirar os processos e desviar a autoridade para uma equipe, e1n vez de criar novos processos ou hierarquias.

Seja implacável

"O inundo responde à ação e a nada niais. "

-Scott Adarns

Muitas pessoas in[eligentes podem reconhecer onde existe un1 proble1na, mas poucas estão dispostas a despender a energia necessária para encontrar uma solução e se encher de corage1n para aplicá-la. Se1npre há 1naneiras mais fáceis: desis[ir, aceitar uma solução parcial, adiar acé que o problema desapareça (dedos cruzados) ou culpar os oucros. O mécodo mais difícil é enfrencar o proble1na e resistir às conclusões que não permitem atender às metas. Os gerentes de projeco bem-sucedidos não desistem fuci lmente. Se algo for importante para o projeto, eles agirão de n1odo agressivo - usando os meios necessários - para encontrar un1a resposta ou solucionar o problema. Isso pode significar reorganizar uma equipe desajustada, conseguir que uma sala locada de pessoas concorde com as meras, encontrar resposras para perguntas ou contornar discórdias entre pessoas.

Algumas vezes, isso significa pedir às pessoas que façam coisas das quais não gostam, ou levantar perguntas às quais elas não gostam de responder. Sem alguém para forçar essas ocorrências, a maneira mais fác il renderá a ser escolhida para você. Muitos projetos consistem de pessoas com funções especializadas, que provavelmente não assumirão responsabilidade por coisas que escão além de sua esfera li1nicada (ou que esteja1n entre os craques de sua fiJnção e a de algué1n mais). Talvez o 1naior problerna resida no fato que a rnaioria de nós evita conflicos. Geralrnence, é o GP que deve ques[ionar as pessoas, desafiar pressuposições e buscar a verdade, a despeito de codo o desconforto que possa proporcionar às outras pessoas (no que pese que a rneca seja fazer isso de rnodo a

COMO FAZER AS COISAS ACONTECER 277

rorná-las o mais conforráveis possível). Os GPs precisa1n esrar disposros a fazer essas coisas, quando necessárias.

Muiras vezes, siruações que, no início, parecia1n insusrenráveis ou inrracáveis se desinregram sob o esforço psicológico de um gerente de projeto tenaz. U1na história clássica sobre essa atitude é a missão Apolo 13. Em seu livro Failure Is Not an Option (Berkeley Publishing, 2001), Gene Kranz descreve o esforço que terminou determinando o sisten1a de nlanutenção das funções virais na aeronave danificada. Foi un1 dos desafios mais difíceis de engenharia que a equipe enfrenrou, e ocorreram dúvidas arrozes enrre aqueles com conhecimento máximo de que até mesmo uma solução parcial seria impossível. Kranz defendeu a posição de que não somente dariam um jeito, como também o F.iriam no tempo restrito alocado. Ele se recusava a aceitar qualquer escape fácil e incentivou sua equipe a encontrar alternativas, resolvendo suas contendas e focando sua energia. As três versões da história, o filme Apolo 13, o livro de Kranz e Lost Moon (Pocket, 1995), de Jim Lovell (o capitão da missão) e Jeffrey Kluger, apresenta1n relacos fascinantes de urna das mais belas histórias de gerenciarnento de projetos e solução de problemas.

Os GPs eficienres examinam mais alrernativas do que as outras pessoas, antes de desistirem. Eles questionam as pressuposições que não foram desafiadas pelas outras pessoas, seja porque procedem da VP, remida pelas pessoas, ou de uma fonte de conhecimento superior que ninguém sentiu necessidade de desafiar. A pergunta "Corno você sabe o que você sabe?" é o modo rnais si1nples de esclarecer o que foi pressuposto e o que é real, 1nesmo que muitas pessoas teman1 ou se esqueç,'UTl de perguntar. Ser in1placável significa acreditar que em 99<)1ó do tempo exisce uma solução para o proble1na (inclusive, em alguns casos, mudando a definição do problema) e que se essa solução não fo r encontrada com as informações disponíveis, então será necessário fazer perguntas mais profundas e investigativas, sem levar em conta quem será desafiado. O êxito do projeto vem em primeiro lugar.

Durante anos, na divisão do Windows da .Nlicrosoft, trabalhei para Hillel Cooperman, talvez o gerente mais apaixonado e dedicado que cive. Lembro-me de que, cerca vez, entrei na sala dele com um di lema. Minha equipe estava emperrada em um problema complicado que envolvia questões políticas e de engenharia. Precis;ívamos de outra organização para F.izer um trabalho importante para nós, que não quería1nos fazer. Eu tinha feiro u1n brainstorming com todos os envolvidos, tinha pedido a opinião de ourras pessoas experienres, mas eu ainda estava paralisado. Parecia não existir uma solução razoável, ainda que fosse algo crít ico para o projeto, e eu sabia que seria inaceitável ceder. Após explicar 1ninha situação, a conversa partiu para algo assi1n: "O que vocês ainda não tentara1n?" Co1neti o erro de responder "Tencei tudo". Ele riu de mim. "Tudo? Co1no você conseguiu rencar rudo? Se você rivesse tentado tudo, teria encontrado u1na opção com a qual se senriria seguro, que aparenremence não tinha achado". Achamos essas palavras divercidas porque nós dois sabíamos exata1nente para onde a conversa se encaminhava.

Em seguida, ele perguntou se eu queria algumas sugestões. Claro que disse sim. Folheamos páginas durante alguns minutos, de um lado para o outro, e surgiu uma nova !isca de itens a serem considerados. "Para que1n você ainda não ligou? Email não é bom para esse tipo de coisa. E de todas as outras pessoas no oucro lado - aquelas que discordam de você - quen1 é n1ais receptivo? Que nível de dificuldade enfrentou para

278 A.ARTE DO GERENC[AMENTO DE PROJETOS

convencê-las do que você queria? Devo me envolver e trabalhar aciina de você? Isso ajudaria? Que cal nosso VP? Até que ponto você esti1nulou a engenharia a encontrar u1na solução? U1n pouco? Muico? O mais arduamente possível? Você se ofereceu para comprar bebidas para a equipe? Jantar? Você conversou com cada um deles ou con1 o grupo? Insista, insista, insista. Você encontrará um jeito. Confio em você e sei que solucionará isso. Insista."

Ele fez duas coisas para 1nim: ele me lembrou de que eu não somente tinha alcernacivas, con10 cambén1 de que. ainda escava dentro da minha esfera de autoridade comar a decisão. Cansado, saí da sala convencido de que existiam mais caminhos a serem explorados e que er.i. minha obrigação fuzer isso. Meu domínio do problema, que ele tinha confirmado novamente, ajudou a me motivar a ser implacável. A solução escava espreitando dentro de um dos caminhos, e eu só precisava encontrá-la. Como os vários outros problemas que eu estava gerenciando simultaneamente, en1 algu1n momento eu encontrei a solução (havia uma solução provisória da engenharia), mas só porque eu procurei: ela não viria 1ne achar.

Entre outras lições, aprendi co1n Hillel que a diligência vence batalhas. Se deixar claro que é muito sério e brigará acé o fim por determinado problerna, você esti1nulará o surgi1nento de novas possibilidades. As pessoas questionarão as respectivas pressuposições se você sustentar as suas tempo baseante. Incentive as pessoas a considerar as coisas que não examinaram, e geralmente é aí que esrá a resposta. Mesmo em discordâncias ou negociações, se você sabe que esrá cerro e persiste ardua1nente, as pessoas vão ceder. Às vezes, elas cedem só para que você se livre delas. Ser intrometido, nlas não ofensivo, pode ser u1na técnica eficaz em si mes1na.

Ser inflexível é fundamental para fazer as coisas acontecerem. Os projetos podem fracassar de cantas maneiras diferences que, exceto se houver pelo 1nenos uma força e1nocional respaldando-o - empurrando-o para frente, buscando alternativas, acreditando que há sempre uma solução para rodo proble1na e roda armadilha - muito provavelmente, o projeto não será bem-sucedido. Os bons GPs são essa força. Eles se sentem con1pelidos a continuar avançando, sen1pre en1 busca de algo que pode ser apri1norado de modo ma.is rápido ou inteligen te. Eles busca1n o caos e o convertem em esclarecimento. Da 1nesma forma co1no precisam ser céticos, os geren tes de projeto são si1nultaneamente ocirnistas no sentido de que rodos os problemas podem ser solucionados, se forem aplicadas intensidade e concentração suficientes. Por 1norivos que ne1n eles mes1nos conseguem explicar tocalmence, os GPs perseguem continuamente a ambiguidade e a dúvida, e se recusa1n a sair de campo anres de explorar rodas as alternativas possíveis. Eles acreditam que pensar posirivamence rraz vitórias e que dá rrabalho encontrar bons pensamentos.

Seja fera

Ser inflexível não significa que você renha que barer em roda porra, perseguir as pessoas pelos corredores nem ficar no trabalho até desmaiar em sua mesa. Todo o esforço pode ser nobre e bom, mas procure se1npre rrabalhar de n1odo inteligente e111 vez de apenas arduan1ente. Tenha un1a mente inflexível, mas inteligente e esperta, em ação. Só porque você se recusa a desistir, isso não significa que renha que sofrer com arividades imbecis, burras ou frustrantes (se ben1 que, às vezes, são

COMO FAZER AS COISAS ÁCONTECER 279

inevicáveis). Procure rnaneiras inceligences de contornar um problema ou mais rápidas de solucioná-los. Ucilize de modo eficience as pessoas a seu redor, em vez de achar que você re1n que fazer tudo sozinho. E o rnais imporcance, seja perceptivo ao que está rolando em corno de você, das pessoas e equipes.

Um erro básico que nluitos GPs cometem é esquecer de avaliar as pessoas con1 quem estão trabalhando e ajustar a abordagem dessas pessoas adequadamence. As Tropas Especiais da Marinha dos Estados Unidos e os rangers* do Exércico norte-americano são creinados para execucar missões em diferences ripos de terreno: desertos, brejos, floresras, tundra. Sem esse t.reinamento, sua eficácia seria limitada: eles lutariam para sobreviver em um terreno desconhecido porque suas habilidades não funcionariam (imagine um soldado com uma camuflagem verde-oliva, tentando se esconder em um campo coberto de neve). A primeira lição que aprendem é como avaliar seu meio ambiente e considerar quais tát icas e estratégias de seu conjunto de habilidades funcionamo no local em que se encontram. O mesmo acontece com os GPs. Ern vez de regiões geográficas, os GPs devem prestar atenção aos diferentes arnbientes sociais, políticos e organizacionais onde esrão, e usar as abordagens cercas nos locais ern que estiverern.

Ser fera e atenro ao meio arnbience é mais irnporrance nas seguintes situações:

• Motivar e inspirar pessoas

• Organizar equipes e preparar ações

• Estabelecer argumentos ou derrubar bloqueios

• Negociar com outras organizações ou culturas

• Criar argumentos para recursos

• Persuadir algué1n de algu1na coisa

• Gerenciar subordinados (recursos humanos)

Eis o guia rudin1entar do GP fera para avaliar un1 an1biente. As seguintes perguntas são aplicáveis a uma pessoa com a qual você está trabalhando ou a uma . . eqtupe ou grupo maior:

• Que estilos de comunicação estão sendo usados? Diretos ou indiretos? As pessoas se comunicam abertamente ou são reservadas? Existem práticas comumente aceitas para fazer cercos tipos de argu1nentações? As pessoas são geralmente eficientes ao usar o emaiP. Reuniões? As decisões são tomadas abertamente ou a porcas fechadas? Co1npare as suas abordagens com aquelas que serão eficazes corn quen1 quer que você esteja conversando.

• Con10 é o senso de h un1or do grupo? De que cernas não se pode rir ou questionar? Até que ponto os assuntos ou as decisões tratados pelos outros são delicados/difíceis/controversos?

• Os argumentos são vitoriosos com base em dados? Argu1nencação lógica através de debate? Adoção das metas do projeto? Quem fala mais alto? Quem é 1nais puxa-saco? Experimente fazer argumencos que usen1 un1 estilo, formaco ou com mais aceitável pelo seu público, quer seja um tesrador solitário andando pelo corredor ou uma sala cheia de executivos.

*N. de T.: Rnngers são soldados do Exérciro dos Estados Unidos especializados em realizar ataques de surpresa.

280 A.ARTE DO G ERENC[AMENTO DE PROJETOS

• Quem faz bem <insira aqui a tarefa que você está tentando fazer> e o que posso emular ou aprender com essa pessoa? Pres(e atenção ao que funciona. Quem são as estrelas? Que1n é mais respeirado? Como esrão se enriquecendo com o que fazem? Quen1 está fracassando aqui? Por que escão fracassando?

• Em termos de cornportamento real, quais são os valores mais importantes para essa pessoa ou grupo? Inteligência? Coragem? Velocidade? Clareza? Paciência? Obediência? Que con1portamentos são os menos valorizados ou são deplorados? Programadores e gerentes podem ter valores muito distintos. Conheça o que as OU(ras pessoas valorizam antes de cencar convencê-las de alguma coisa.

• Qual é a cultura da organização? Toda universidade, corporação ou equipe cem um conjunto de valores diferente incorporado à cultura. Se você acha que sua organização não tem urna, você já está nessa organização há muito tempo e não consegue 1nais percebê-la (ou talvez nunca a renha visto). Algumas organizações valoriza1n a lealdade e o respeito acima da in(eligência e da individualidade. Ourras são centradas na ética e no cornpro1nerirnen(o profissionais.

Dependendo das respostas dadas a essas perguntas, um GP deve ajustar seu modo de trabalhar. Sempre que você entrar na sala de outra pessoa ou em outra reunião, alguns ajustes deverão ser feitos. Corno um n1arinheiro, avalie o 1neio atnbiente e, então, defina a 1nelhor rota para atingir as metas do proje(o. Evite trilhar a es(rada mais difícil se exis(ir um modo n1ais fácil de alcançar onde você precisa chegar.

Táticas de guerrilha

Ser fera significa que você está procurando e desejando trilhar a roca mais inceligence. A )isca a seguir concém tá(icas que usei com êxico ou que funcionaran1 bem ao sere1n usadas por mim. Embora sua quilo1netragem possa variar com elas, tenho certeza de que essa lista o Í"ará pensar em outras maneiras espertas de fazer o que deve ser feito para atender às suas metas. Algumas delas trazem riscos, para os quais chamarei a atenção, e devem ser aplicadas com cuidado. Mesmo que você prefira nunca utilizá-las, se estiver atento a elas, ficará mais esperto em relação ao que está rolando ao seu redor.

• Saiba quern tern autoridade. Não perca tempo argumentando com pessoas que não rê1n controle nern influência sobre a quescão. Para ser eficiente, saiba quem (Orna decisões ou influencia cer(a questão ou situação. Descubra quem é (ne1n se1npre é a pessoa mais experiente na sala e a identidade dessa pessoa pode 1nudar de uma quescão para oucra), consiga uma horinha co1n essa pessoa, e faça a sua exposição. Ou pelo n1enos descubra as coisas concra as quais essa pessoa faz objeção. Se você não tiver acesso à pessoa n1ais influente (Sally, a VP), encontre alguém que renha o 1náxin10 de influência sobre essa pessoa (o melhor funcionário de Sally). Escale até o ponto mais alto da cadeia que puder alcançar. Aviso: não dê un1a rasteira nas pessoas. Exerça a autoridade n1as convide a perspecciva oposta, se necessário, ou revele o que você está fuzendo. "Olhe aqui, remos nossas divergências, mas sabe1nos que a decisão é de Sally. Conversarei com ela sobre isso amanhã. Gostaria que você estivesse lá." (Consulte o Capítulo 16.)

COMO FAZER AS COISAS A C ONTECER 281

• Vá até a fonte. Não perca ternpo com interpretações de segunda-rnão das pessoas sobre o que alguérn disse, e não dependa de relatórios escritos ou ernails para obrer informações complexas. Localize a pessoa em questão e converse diretamente com ela. Você não obcerá respostas para novas perguntas, lendo relatórios ou ema ils, e geralmente as pessoas lhe contarão coisas in1portantes, inadequadas à comunicação escrita. Ir até a fonte é sempre n1ais confiável e valioso do que as alternativas, e compensa o esforço necessário. Por exemplo, se dois programadores estivere1n questionando sobre o que um terceiro programador disse, coloque esse terceiro programador na sala ou ligue para ele. Sempre vá direro ao ponto e peça aos outros que f.1çam o mesmo.

• Mude os meios de comunicação. Se a comunicação não estiver funcionando, mude o meio. Em vez de email, ligue para as pessoas. Em vez de ligar, apareça na sala delas. Todos se sentem mais seguros com alguns meios do que com outros. (Geralrnence, face a face, ern frente de urn quadro branco, ganha de codos os meios. Reúna as pessoas em uma sala com um quadro branco, se o processo por email sobre alguma questão ficar fora de controle.) Não perrnita que as lirnitações de determinada tecnologia o paralisem. Às vezes, un1a rnudança de meio traz urna resposta diference, mesmo que sua solicitação seja a mesrna, porque as pessoas estarão mais receptivas a um meio do que ao outro. Para obter outros resulrados, cornpensa investir dinheiro, tempo e pegar u1n avião, ou dirigir seu carro acé o escritório de alguérn, se isso rnelhorar a dinârnica da comunicação encre você e urn colaborador irnporcance.

• Fique sozinho com alguém. Ao conversar com alguém em particular, a disposição dessa pessoa é diference do que quando você conversa com ela em um grupo maior. Em uma reunião, as pessoas importantes elaboran1 o que vão dizer, para que seja adequado a todos os ouvintes na sala. Algumas vezes, você ouvirá coisas radicalmente diferences, dependendo de quem esteja na faixa de audição. Para obter uma opinião franca e sincera, ou uma conversa mais abrangente e profunda, reúna-se corn as pessoas em particular. Alérn disso, considere as pessoas de influência: se Jim confia na opinião de Beth e você quer convencer Jim, se você puder convencer Bech primeiro, aproxime-se dela. Não arme uma cilada para ninguém, mas não evite colocar as coisas em seus lugares para que o progresso aconteça.

• Procure caçar as pessoas com voracidade. Se algurna coisa for urgente e você não estiver conseguindo o tempo de resposta necessário, fabrique tempo em seu cronograma para montar guarda ao lado da sala ou cubículo de alguém. Já fiz isso várias vezes. Se essa pessoa não estava respondendo às n1inhas ligações ou en1ails, logo estaria voltando de unia reunião e n1e encontraria sentado ao lado de sua porta. Ela era apanhada de surpresa e eu levava uma vantagem na negociação. Não tenha rnedo de caçar as pessoas, se você precisar de algurna cois,1 delas. Localize-as ern uma sala de café. Procure por elas no restaurante, durante o almoço. Pergunte à secretária ern que reuniões a pessoa pode estar e espere no lado de fora. Seja educado, mas cace e consiga o que você precisa .. (Contudo, não invada a vida particular das pessoas. Se você caça ben1 informações, não haverá necessidade de ultrapassar essa linha.)

• Desapareça. Se o seu trabalho estiver atrasado e precisar de tempo até colocá.-lo em dia, torne-se invisível. Em determinadas situações, eu encampava uma sala de conferência (em un1 prédio ao lado) e só revelava às pessoas que realmente

282 A.ARTE DO GERENC[AMENTO DE PROJETOS

poderiarn precisar de rnirn enq uan co eu esrivesse lá. Eu colocava ern dia o ernail, as especificações, as avaliações de funcionários ou qualquer coisa irnporcance que não esrivesse sendo feira, sem ser inrerrornpido. Para as organizações menores, trabalhar ern casa ou en1 uma cafr:reria pode ter o mesmo efeito (as conexões sem fio fucilitam a vida moderna) . Sen1pre incentivei meus subordinados a fazerem isso, quando sentissen1 que era necessário. Pode ser difícil para os GPs conseguir ten1po sem serem interrompidos, portanto se você não conseguir esse tempo, faça isso.

• Peça conselho. Não voe sozinho sem um mapa, a menos que seja absolutamente necessário. Em determinada situação, descubra qual dos envolvidos o tem na mais alra consideração, ou quern pode lhe dar um conselho ú til para obter o que necessita. Faça uso de qualquer conhecimento ou experiência que você possa acessar através de outras pessoas. Peça licença e faça uso. Pode ser uma pessoa, decisão, plano, qualquer coisa. "Oi, Bob, goscaria de um conselho seu sobre esce orçamento. Você reria alguns minutos?" Ou "Jane, estou tentando trabalhar com Sam nesse problerna. Você cem algurn conselho sobre a 1nelhor maneira de convencê-lo a corcar este recurso?" Para 1nuitas pessoas, só o fato de você pedir o conselho lhe conferirá alguns pontos de credibilidade: é urn aco de respeico pedir a opinião de alguém.

• Peça favores, implore, suborne. Faça uso da credibilidade ou generosidade pela qual você desenvolveu uma repucação. Se precisar que um engenheiro faça un1 crabalho excra, porque você perdeu algu1na coisa ou acabou de chegar u1na exigência tardia, peça um favor a esse engenheiro. Extrapole os limites da escrita relação profissional, e peça. Ofereça-se para lhe pagar um jantar (US$ 20 geralmente pagam bem um favor) ou diga que você lhe deve uma (e mantenha a sua palavra). A pior coisa que pode acontecer é essa pessoa dizer não. Quanto n1ais favores você tiver feito aos outros, mais cartas terá en1 sua n1anga. Além disso, tente atuar como um intermediário (como no jogo Descobridores de Catan) se você souber algu1na coisa que essa pessoa deseja, e que você pode conseguir com outra pessoa. Não é Falta de ética oferecer às pessoas coisas que as convençam a auxiliar em um trabalho que precisa ser feito.

• Jogue as pessoas umas contra as outras. Isso não ce1n que ser de1noníaco - se você river 1nuico cuidado. Se Sam lhe der urna esci1naciva de crabalho de 1 O dias, que você considera u1na enrolação, consulce o Bob. Se Bob sugerir algo inferior a 1 O dias, volte ao Sam, diante de Bob. Uma conversa revelará irnediata1nente a real esti1nativa para o crabalho. Se você fizer isso urna vez, nenhu1n engenheiro lhe apresentará estimativas falsas nova1nente {você gricou "desconfio"). Contudo, dependendo da personalidade de San1, isso pode lhe custar alguns pontos no relacionamenco com ele, portanto tenha o tnáximo de caro possível, e so1nenre quando for necessário. Os bons progra1nadores chefe devem desconfiar e verificar as estimativas por conta própria, 1nas se não fizeren1 isso, fica por sua conta.

• Prepare o baralho. Nunca encre em uma reunião iinporcance sem saber a opinião das pessoas importantes presentes na sala. Saiba sempre quem podení apoiar a sua opinião e quem poderá se opor, e tenha uma estratégia desenvolvida para a sua navegação (consulte o Capítulo 16). Se algo importante estiver em risco, movimente-se para balançar aqueles que estiverem contra você, ou para buscar o apoio dessas pessoas, antes da reunião. Não nlinta, manipule

COMO FAZER AS COISAS ACONTECER 283

ou confunda, mas prepare-se co1n seriedade e conheÇ<'l os argumentos e contra-. ~ argu1nencos que surg1rao.

• Pague café ou gulosein1as para as pessoas. Isso parece idiotice, mas descobri que as pessoas com as quais debaci durante dias, no final das conras ficam um pouco mais receprivas duranre uma bela xícara de café, em uma cafeteria local. Mude a dinâmica do relacionamento: a despeito do quanto você gosta ou não da pessoa, faça o convite e invista os 20 segundos do esforço necessário. Mesmo se a pessoa disser "Não, por que não conversamos aqui nlesmo?", você não perdeu nada com isso. Transferir a conversa para outro local, talvez menos forinal, pode ajudá-lo a vislurnbrar alternativas que ele não exa1ninaria antes. Pense biologica1nente: os hu1nanos rnelhoram o seu humor depois de uma bela refeição ou quando estão em ambientes agradáveis. Já vi GPs guardarem donuts ou biscoitos (assim como rum e scotch) em suas salas. Isso é um ato de boa­voncade? Si1n - mas há benefícios psicológicos quando você garance que as pessoas com as quais está trabalhando estão bem alimentadas e o associam a coisas boas.

Resumo

• Tudo pode ser represencado e1n uma !isca de prioridades. A 1naior parte do trabalho do gerenciamento de projeto é priorizar corretamente as coisas e orientar a equipe para a sua execução.

• As três listas de prioridades n1ais básicas são: metas do projeto (visão), lista de recursos e !isca de itens de trabalho. Essas listas devem estar sempre em sincronia. Cada item de trabalho contribui para um recurso, e cada recurso contribui para uma mera.

• Há uma linha amarelo vivo encre o trabalho de prioridade 1 e tudo o mais.

• Quando você diz não, coisas acontecem. Se você não puder dizer não, efetivamente não terá prioridades.

• O GP deve preservar a sinceridade na equipe e mantê-la próxi1na à realidade.

• Para ser eficiente, é necessário conhecer a trajetória crítica nos processos de engenharia e da equipe.

• Você deve ser i1nplacável e fera para fazer as coisas acontecer.

Capítulo 14

Estratégia de meio-jogo

286 A ARTE DO G ERENC[AMENTO DE PROJETOS

Ü cítulo desce capítulo, "Estratégia de meio-jogo", refere-se ao jogo de xadrez, que é dividido e1n rrês parres: aberrura, meio-jogo e final. Meio-jogo é quando a estratégia geral do jogador torna-se evidente e é aplicada aos seus n1ovi1nentos. A n1aioria dos n1ovi1nentos e1n un1 jogo ocorre durante o meio-jogo. Final é a conclusão do jogo, quando os recursos são reduzidos e todo movimento isolado é in1porranre. Este capítulo discorrerá sobre o meio-jogo do projeto, e o próximo capítulo discutirá o final do projeto.

"A • b das " ./'.I sorte sorri para as mentes em prepara . . - Louis Pasceur

E1n projetos, meio-jogo é o meio do cronogra1na completo. Você saberá que está no meio-jogo quando algumas coisas estão funcionando, e outras não, alguns problemas foram detectados e resolvidos, mas você sabe que ainda há outros. O meio-jogo é desafiante porque muitas coisas estão acontecendo ao 1nesn10 tempo, e é difícil n1anter a clareza sobre o que está indo bem e 1nal. O termo névoa da guerra - empregado por Clause"vitz1 em referência a quão caótica a guerra pode parecer enquanto você está dentro dela - aplica-se bem ao meio-jogo. Há un1a névoa inevitável da atividade de desenvolvi1nenco que circunda a equipe, e os inexperientes se confunde1n facihnenre. Os líderes de equipe rên1 a responsabilidade de orientar a equipe no período de incerteza do meio-jogo até a fase final, onde as coisas se tornam claras novamente.

Na perspectiva mais simples possível, as fuses de meio-jogo e final estão relacionadas à nlanutenção de alto nível:2

1. Se as coisas estivere1n indo bem no final do primeiro dia, enrão a mera do dia seguinte é continuar bem.

2. Se em algum dia, o projeto não for bem, você deverá identificar os proble1nas e co1nar uma aritude para fazer o projeto transcorrer bem novamente. Isso pode levar horas, dias ou semanas.

3. Repira até o projero estar concluído.

O desafio óbvio, 1nes1no em sua perspectiva si1nples, é o nú1nero infinito de coisas que podem acontecer para prejudicar o andamento do projeto. Pior ainda, a limitação do tem.po para identificar o que está errado e menos tempo ainda para solucionar. Isso sem mencionar o esforço necessário para evitar que as partes íntegras do projeto enfrentem problemas.

Por esses e outros motivos, os níveis de energia e tensão durante as fàses de meio-jogo e final são muito altos. A equipe está se movirnenrando cada vez mais rapidamente e as margens de erro diminuem a cada dia. Com a aproximação do final, alguém precisa encontrar o 1nodo certo não somente de aplicar os freios, co1no ra1nbé1n de recardar o moviinenro progressivamente, para que as coisas rerminem bem.

Neste capítulo e no próximo, usarei as mes1nas pressuposições inclusivas sobre a 1nerodologia desenvolvida no Capítulo 2 (essa orientação se aplica bem, independentemente da 1netodologia utilizada). Co1npensaria u1na leitura rápida da seç.'io "Balas de prata e n1etodologias" no Capítulo 2, anres de se aprofundar neste capítulo.

ESTRATÉGIA oE ME10-Joco 287

Ernbora este capírulo se concentre, em grande parte, no 1neio-jogo, e o próximo capírulo se dedique ao final, ocorre uma sobreposição ern corno e quando essas técnicas podern ser aplicadas (por exemplo, o final de u1na fase pode ser considerado parre do 1neio-jogo do projeto inteiro). Sendo assim, saiba que, algumas vezes, eu me movimentarei de u1n lado para o outro entre esses dois tópicos diferences.

NOTA A cobertura do gerencia1nenro de meio-jogo e do final, neste capítulo e no próxi1no, é alran1enre 1ninuciosa. Se você se deparar co1n perguntas ou situações não-aplicáveis devido ao ran1anho da sua equipe 011 ao escopo do seu projeto, poderá exa111inar ou ignorá-las. Não espero que rodo o conteúdo aqui d iscutido se aplique a rodo projeto isolado. Contudo, estou tentando agregar valor para você, não son1enre para seu projeto acuai, co1no cambé111 para rodos os subseqüentes. Há várias perspectivas e q11csàona1ncntos aqui que lhe serão úteis no longo prazo, n1cs1no que u1na parte não se aplique ao seu trabalho atual.

Pilotar à frente do avião

Pilotar objeros grandes e perigosos exige mais do que 1não finne. Quanro maior for o que você estiver dirigindo, e quanto n1aior for a quantidade de parricipantes, tanto 1naior será a inércia do objeto en1 questão. Como no gerenciarnenro de projetos, os novatos pilotando máquinas grandes (carros, aviões, porra-aviões etc.) subesàmarn o rernpo necessário para que as 1nudanças efetuadas no leme se reflira1n no cornportamenro do que estão pilotando. Corno mostra a Figura 14-1 , a trajetória de grandes veículos ou projetos muda bastante, em função do ímpeto e de outras forças envolvidas. A maioria das pessoas, principalmente as inexperientes, fracassa na definição correta de suas expectativas para os resultados de suas ações. Geralmente isso ocorre porque elas não conhece1n todas as forças que contribuem para a dinâmica do que está sendo trabalhado. Como alguém aprendendo a dirigir, que desli7..a na neve pela prirneir.i. vez, há muitas forças inexplicáveis interagindo para que essa pessoa continue no controle.

0 0

FIGURA 14· 1. A mesma ação pode ter resultados diferentes, dependendo da inércia já existente no projeto.

288 A.ARTE DO GERENCIAMENTO DE PROJETOS

Quando as pessoas que suposcamence deveriam concrolar perderern o controle, a reação cornum dessas pessoas é entrar em pânico. Talvez elas não adrnicam isso (as pessoas em pânico rara1nenre reconhecen1 que esrão em pânico), mas é verdade. Ern geral, a primeira reação é executar urna ação corretiva enérgica en1 resposca direca ao proble1na. Con10 elas realn1ente não conhecem todas as forças, essa ação corretiva será normalmente muito mais forte (consulte a Figura 14-2). Quando elas perceberem o que fizeram, será necessária oucra ação correciva, que elas execucarão irnediacarnence. Corno ainda esrão usando a rnesma lógica que as colocou nessa situação ridícula en1 primeiro lugar, outros problemas ocorrerão.

FIGURA 14-2. Para o desânimo daqueles que supostamente estão no controle, as ações corretivas sobre forças corretivas têm resultados imprevisíveis (e freqüentemente insanos).

Na realidade, ao se tornar insrável, um avião, automóvel ou projeto fica perigosamente difícil de se controlar - mesmo para a lguérn com muita prática e experiência. (Os projetos menores são certarnente mais ágeis, mas têm seus ímpetos também.) A instabilidade torna imprevisível o resultado da maioria das ações porque há muitas variáveis em mutação, muito rapidamente. Assim, o bom gerenciamenro de projetos está quase cocalmence associado a permanecer um ou dois passos à frente do projeto, invescindo a energia necessária para evitar cair nessas si cuações, antes de tudo.

Os pilotos de aviões de combace cê1n urna frase para o que acontece quando um piloto não pennanece à frente: voar atrás do avião. Significa que o piloco não ficou (pelo menos) um passo à frente do que escava aconcecendo com sua máquina e, enrão, cornou-se a víci1na da inceração de forças sobre sua aeronave. Assim como pilotar aviões de alca performance, os projecos exigem o gerenciamento d e várias forças interativas diferences. Ambos são siste1nas não­lineares, o que significa que a mudança de um elemento (velocidade, ângulo, cronograma, metas) pode surtir mais de um efeito ou pode afetar o sistema com mais força do que o previsco, porque essa força será amplificada através de vários fatores ou pessoas diferences. Isco é um aviso: mesmo con1 u1n projeto estável mas de alta velocidade, a natureza complexa da base do código e da equipe significa que qualquer ação de gerenciamento pode ter conseqüências inesperadas. Às vezes, essas conseqüências não serão percebidas durante dias ou até semanas. Quando tardiamente vierem à tona, será fácil presumir que algo mais recente ocasionou o problema, dificultando a sua solução efetiva.

ESTRATÉGIA DE ME10-Joco 289

Verifique sua sanidade

Para os gerenres de projeco, a rnaneira mais eficienre de pilorar à frenre do avião é verificar diariamente a sanidade. Os progra1nadores usarn o termo verificação de sanidade para garantir que certas coisas irnportantes sejam verdadeiras em seus códigos (na terminologia da linguage111 C, pense na função assert ( ) ). Esta é uma idéia muito boa porque as pressuposições são perigosas. No código, quando un1a dessas verificações de sanidade falha, todos podem ignorar a busca inütil de red herrings (proble1nas que não existe111) e fuzer a pergunta mais fundamental, ou seja, por que uma condição louca foi introduzida no sistema.

Para "pilotar à frente do avião", é necess<írio verificar constantemente se as condições revistas ainda são verdadeiras. E então, ao detectar uma falsa, você saberá imediatamente onde deve prestar atenção.

O desafio reside na existência de várias outras verificações de sanidade possíveis. E ntre rnetas, cronogramas, tecnologias, motivação, concorrência, orçamento e aspectos políticos, é irnpossível verificar tudo o tempo todo (embora isso não evite que alguns gerentes paranóicos possam tentar). É u1n erro final arrastar urna equipe inteira acravés de uma tortura di<íria de confirrnação de dezenas de premissas aleatórias. Quanro mais obrigar urna equipe a confirmar aspectos que geralmente devem ser verdadeiros, canto 1nenos essa equipe confiará em você, e tanto 1nais desperdiçará o te1npo dessa equipe. Você quer saber o estado do projeto sem perturbar o seu estado.

1-Iá três n1aneiras de fazer isso: perguncas táticas, perguntas estratégicas e avaliações transparentes do avanço da equipe. Discuciretnos as avaliações no próxin10 capírulo. Por enquanco, concenrre1no-nos nas pergunras rácicas e escrarégicas para verificar a sanidade.

O processo é simples: mantenha uma pequena lista de perguntas que ajude a colocá-lo à frente do avião, e crie um ritual de perguntá-las. Faça as perguntas táticas u1na vez por dia; faça as perguntas estratégicas uma vez por semana. Você pode fuzer isso sozinho ou escolher membros específicos da equipe para participarem nesse processo. Estimule também as pessoas da equipe, principalinente as mais experientes ou mais antigas, a fàzer u1na verificação de sanidade de alto nível semelhante por conta própria e correlacione com os seus achados o que essas pessoas detectarem.

Minha proposta é a seguinte: eu marcaria uma reunião se1nanal de meia­hora co1nigo 1nesrno (se eu não resguardar o meu re1npo, quem o fará?) no 1neu cronograma. Fecharia a porca, colocaria uma música para cocar e analisaria minha lista de perguntas. Em geral, isso só levaria alguns minutos. A partir de encão, eu poderia redefinir as prioridades do meu dia ou da minha equipe adequadan1ente. E1n algu1nas equipes, incluí esse ripo de questionamen to como parte da cultura, e criei versões n1enores dessa modalidade de perguncas e resposcas durance as

· ~ reuntoes.

Perguntas táticas (diárias) para permanecer à frente

• Quais são suas metas e compron:Ussos? Ainda tê1n precisão? Há tanto trabalho a ser feiro em determinado dia, que se torna inevitável para você e os outros

290 A.ARTE DO G ERENC[AMENTO DE PROJETOS

perderern a perspectiva das rneras. Um sirnples exame dessas meras rodos os dias restabelecerá seu foco e suas prioridades. Mais importante para a equipe, se as rnetas oficiais não corresponderem às reais (por exernplo, devido a algo sem razão aparente da VP) ou às meras da equipe (é legal fazer o que pensan1os), então as metas não são exaras. Se as meras não forem exatas, a equipe estará em conflito. Quando uma equipe estiver em conflito, os sinton1as virão à tona. Não espere o surgimento dos sintomas se você detectar conflitos óbvios que, e111 algum nlomento, os acarretarão. Pennaneça à frente, principaln1ence quanto às questões que afetam direramence as metas.

• O que estamos reali1.ando hoje contribui para as nossas metas? Exarnine os irens de trabalho nos quais seus programadores estarão trabalhando hoje, amanhã e durante a semana. Está claro como eles estão contribuindo para as meras ou acendendo aos requisitos? Se não esriver, o navio estará começando a ficar à deriva. Trabalhe juncarnenre corn o(s) prograrnador(es) adequado(s) para fazer com que rodos entendam as meras e a importância do trabalho para acender a essas mecas. Ern seguida, ajuste um destes crês aspectos: as rneras, o trabalho ou arnbos. Algumas vezes, essa tarefa é denorninada alinharnento do trabalho; como os pneus de seu carro, é necessário verificar periodicamente se rudo esrá trabalhando na mesma direção.

• Os itens de trabalho estão não somente sendo concluídos, como tambétn sendo finalizados de modo a atender aos requisitos e às situações? Há rnil maneiras de concluir urna unidade de trabalho que não acende1n ao espírito e à intenção do design. Um design ou especificação eficiente rerá definições de aspectos, como irens de trabalho que acendam às reais situações dos clientes. Contudo, as sutilezas da usabilidade, os requisitos de negócio, a integração de con1ponences e o design visual são geralmente esquecidos por programadores com 15 outros itens de trabalho para fazer. Se um designer (ou outro especialista) de interfi1ce dedicado estiver por perto, deverá estar examinando ativamente os i·heck-ins e a cornpilação diária, para ter certeza de que os itens de trabalho atendam à holística, não somente itens de linha, requisitos.

Perguntas estratégicas (semanal/mensal) para permanecer à frente

.Essas perguntas são freqüentemente assunto de reuniões de liderança. Se ocorrer uma discussão sernanaJ ou mensal sobre o status, são esses tipos de problemas que merecem a atenção dos líderes. Mas essas perguntas se aplicam até mesmo a urn GP individual trabalhando em uma pequena área.

• Qual é a nossa probabilidade an1al de atingir a data/marco/icem seguinte com o mesmo nível adequado de qualidade? Ocorreram mudanças desde que as esrirnativas de trabalho forarn projetadas. Corno as pessoas se senrem em relação ao trabalho, agora que estão dentro dele? Pergunte a si rnesrno e aos principais integrantes da equipe qual é a probabilidade de ocorrer uma reunião bem­sucedida no próximo encontro. 1 OOo/o? 90%? 50o/o? Alta? Média? Baixa? Seja sincero e peça aos outros para fazerem isso tatnbém. Seja sensível à equipe: não deixe tudo isso ser orientado por culpa ou desafio, como se você estivesse tentando provar que as escirnacivas dos integrantes estão incorreras ou que esses

ESTRATÉGIA DE ME10-Joco 291

me1nbros precisam trabalhar mais. Em vez disso, esclareça que, desse 1no1nenco em diance, você precisa de resposcas sinceras. (Por que eles cê1n pouca confiança ou quem é o culpado por isso não muda o faco de que têm dúvidas rangíveis. Convén1 conhecer e entender as dúvidas rangíveis.)

• Que ajustes são necessários para melhorar essa probabilidade? Deveria ser excraordinaria1nente raro obter 100º/o de certeza no próximo encontro, de alguém que é sincero e equilibrado. O acon1panhamenco da questão da probabilidade deve girar sempre em torno de co1no é possível aumentar essa probabilidade. Menos reuniões e interrupções? Decisões nlais ágeis? Cortar recursos? Decisões mais eficientes? Esclarecer as metas? Revisões de código mais apuradas? O que mais? Pergunte às pessoas que mais participam no trabalho di;írio da li nha de frente . Torne um item de alta prioridade para si mesmo e para a equipe fazer perguntas ativamente e investir nas respostas.

• Até que ponto fazemos ajustes cuidadosamente e de modo isolado? Primeiro, pense se1npre de modo cirúrgico. Qual é o menor volume de ação necessário para solucionar com êxito o problema e melhorar nossa probabilidade? Uma ligação telefônica? U1n emaiP. Tornar uma decisão importante visível? De1nitir alguém? Não tenha medo de executar uma grande ação se esse for o 1nenor esforço para realizar o trabalho. Se não existir uma opção cirúrgica, então pense de n1odo holístico. As metas necessitam de ajustes? O processo de check-in? Que processo do sistema ou atitude pode receber um ajuste para acabar co1n o sinto1na e a causa? (Consulte a próxima seção, "Executar u1na ação segura".)

• Quais são os 1naiores ou mais prováveis riscos de hoje, da próxima semana, do próximo mês? Quais são nossas contingências se vierem a acontecer? Basca identificar três ou mais riscos perigosos ou prováveis, e você terá dado um grande passo para evirá-los; você terá ligado o seu radar e esrará sensível aos sinais de aviso que possam indicar a ocorrência desses problemas. Mesmo que você só invista 5 ou 1 O minutos por sema.na para identificar os possíveis riscos, e suas possíveis respostas a esses riscos, você estará se colocando à frente do avião. Esse tipo de verificação do projeto norinalinente custa muito pouco: com alguns minutos por se1nana, você obtém muita proteção.

• Con10 foi que o mundo 1nudou sen1 que eu soubesse? Meu VP ou stakeholder ainda está a bordo? As metas deles 1nudaram? Os principais parceiros ern rninha equipe estão preocupados corn algo que desconheço e que afetará o projeto, caso esteja1n certos? O que nosso concorrente fez que merece uma resposta de nossa parte? Nossos parceiros ou subordinados ainda estão nos trilhos? O que escá dando errado hoje, que eu não descobrirei até a1nanhã? Algu1nas rápidas ligações telefônicas ou vagar pelos corredores geralmente responde1n a esra pergunta. Cuidado para não n1icrogerenciar, agir con1 paranóia ou ainedront.ar os oucros. Torne co1nun1 e habitual fuzer esses tipos de investigações. Alé1n disso, incentive e recompense as pessoas que obtêm para você esse cipo de informação (sobre as próprias responsabilidades e as dos outros), de 1nodo proativo.

Contudo, a despeito de sua experiência, preparo e inteligência, se1npre haverá os dias em que você terminará pilotando atrás de seu projeto. Aprenda a perceber a diferença entre ter muito trabalho para fazer e esrar atrás do avião: não significam a mesma coisa. Muito provavelmente, você perceberá que, às vezes, há mais trabalho para fazer do que tempo necessário para f.izê-lo. Mas se você criou listas

292 A.ARTE DO G ERENCIAMENTO DE PROJETOS

de prioridades para o trabalho a ser feito(consulte o Capículo 13) , saberá que há se1npre algu1na coisa esperando por seu te1npo. Quando você estiver atr<\s, vai se senür congelado, deprimido ou até apático. Acreditará que não i1nporra o quão tarde fique no escritório, não recuperará o controle do projeto.

Três últimas coisas importantes:

l. Quando você estiver atrás, saiba que está atrás. Lembre-se de que cronogramas são probabilidades. Até que ponto você tem certeza de que o que precisa ser concluído será feito esta semana? 80o/o? 50%? Se houver uma probabilidade de 50-50 (ou menos) de conclusão, você está atrás; sua margem de erro é pequena e você cometerá erros se ainda não tiver cometido.

2. Quando você encontrar pessoas atrás do avião, ofereça-lhes seu apoio. Não refure o problema: diga-lhes que você examinará e tentará ajudar. Evite deixar que alguém em sua esfera de atuação erga as mãos em protesto ou entre em pânico. Fique calmo, ajude os outros a permanecerem calmos e trabalhe em conjunto para volrar a ficar à frente do avião.

3. Não hesite em obter ajuda dos pares ou supervisores. Talvez seja a única n1aneira de se recuperar e voltar à posição à frente. Use a ajuda dessas pessoas ao atribuir prioridades ao seu te1npo e ao tempo da equipe, ao escolher alguns do seu trabalho ou apenas ouvindo o seu desabafo. Segure na mão de alguén1 se lhe for oferecida. Peça a n1ão de alguén1 se ningué1n lhe oferecer a 1não.

Para obter mais detalhes sobre corno lidar com situações de crise, consulte o Capículo 11.

Executar uma ação segura

No decorrer do meio-jogo, a maioria das ações são versões menores e mais reduzidas da atividade do GP realizada durante o planeja1nento ou design. Se um requisito desapareceu ou precisa ser incorporado, o processo para definir e documentá-lo é apenas uma versão dobrada do que foi feiro ao longo do processo dos requisitos (conhecer as necessidades, considerar as implicações, definir e atribuir prioridades). Ou se algo foi negligenciado na especificação. o processo para solucioná-lo é tuna repetição dupla ou tripla do processo de especificação. Algumas capacidades novas são empregadas no meio-jogo. Geral1nente, é apenas uma versão nlais enxuta e ágil de u1na capacidade usada anteriormente. O problema é que trabalhar em velocidade gera riscos. Executar u1na ação segura no 1neio-jogo significa tão-so1nente que a integridade do projeto não é corro1npida involunraria1nenre, como conseqüência da ação.

A ação segura é con1plexa porque a munição está viva no 1neio-jogo. As coisas já estão em n1ovimento e muitas decisões já foram tomadas, o que pode colidir com qualquer ação nova. Por exemplo, se no n1eio da construção de sua casa, você decidir mudar a planta da estrutura-A padrão para un1a redo1na geodésica, desperdiçará muito material e esforço, e possivelmente exigirá u1n novo trabalho sob pressão mais intensa. É necessário ter experiência para mudar um requisi to, cortar um recurso, ou a alteração de um design afetará a base do código . e a equipe.

ESTRATÉGIA DE ME10-Joco 293

A 1nera de qualquer GP deve ser execurar uma ação segura. Ele precisa se 1novin1enrar e se comporrar de 1nodo a manrer sÍinulraneamenre o projero nos rrilhos e1n direção ao cu1nprimenro das meras que podem mudar, alé1n de prejudicar o projeco o nlínimo possível. Algum prejuízo é inevirável e deve estar previsco. Quanto nlais eficientes forem as ações de un1 GP, tanto menos negativo será o in1pacto.

Co1no mostra a Figura 14-3, quanto mais longo for um projeto, tanto mais difícil será execurar ações seguras. Isso ocorre porque a probabilidade de que un1a ação renha conseqüências dispendiosas aumenca em fl1nção do cempo: é mais provável que o trabalho já concluído deva ser modificado ou desperd.içado. Essas despesas podem estar roralinenre garantidas, mas execurar uma ação segura pressupõe cerro conhecimento sobre os custos antes da tomada de decisões.

Tamanho do ajuste Tempo decorrido

FIGURA 14·3. É mais difícil fazer um ajuste seguro quando ele é grande e/ou se efetuado na fase final do projeto.

Ao considerar os ajustes (n1udança de recursos/metas/requisitos) durante o n1eio-. . ~

)Ogo, as c inco perguntas sao:

1. Que problerna estamos tentando solucionar? É necessário solucionar esce problema para obcer êxico? Precisamos resolver este problema durante este marco? Conseguiríamos conviver com este problema?

2. Esce problema é um sinro1na ou u1na causa? Apenas a solução dos sincomas é aceicável?

3 . Conhecemos o esrado do código ou da equipe suficienremente be1n para prever como u1na ação os aferará?

4. Os benefícios da 1nudança co1npensa1n os cusros do ajusce (inclusive o ce1npo para conhecer o esrado do código/equipe, considerar alrernarivas e obrer respaldo polícico para a decisão)? Localizar e corrigir as causas pode cuscar mais do que conviver com os sintomas, muito 1nenos que corrigi-los.

5. O benefício da mudança compensa os riscos de outros possíveis problemas?

A decisão de executar un1a ação depende das mesmas estratégias de ton1ada de decisão discutidas no Capítulo 8. Qualquer design, especificação, comunicação ou ação política necessária faz uso das rácicas abordadas nos Capftulos 6, 7, 9 e 16, respectiva1nence. A aticude e abordagem são as mes1nas, exceto pelo furo de que o cronograma e a margem de erro são muito menores. A falta de tempo pant considerar as opções significa duas coisas. Pri1neiro, conre co1n o conhecimento obcido previa1nenre durante qualquer esforço de criação de protóripos ou de design. Alguns ajus tes sendo analisados devem cer vindo à tona na ocasião, e use o

294 A.ARTE DO G ERENCIAMENTO DE PROJETOS

conhecirnenro da equipe para auxiliar na análise arual. Em segundo lugar, seja conservador. Quanro menos você souber, ranro maior a quanridade de riscos que não poderá derecrar. Quanro rnais arrasado esriver o seu cronogran1a, ranro mais elevado será o nível para execução de uma ação.

Romper compromissos

Parre inregral da ação segura é considerar os compromissos dos líderes da equipe para com a equipe. Como discurido no Capítulo 12, a confiança que os líderes conquistam na equipe é definida pelo modo como gerenciam seus compromissos. O documento de visão, os requisitos e o cronograma são formas de compron1etimento entre a gerência, os líderes da equipe, programadores e o cliente. Toda ação executada durante o meio-jogo pode invalidar os co1npromissos contraídos anteriormente.

Para manter a confiança da equipe em você, à 1nedida que ocorrerem mudanças, respeite os co1npro1nissos anceriores. Como dizia Hurnphrey, "Se ocorrer wna mudança que afere urn dos parceiros em relação ao cornpromisso, deve ser emicida uma notificação prévia e urn novo compromisso é negociado". São permitidas rnudanças, que devem seguir um processo de negociação sernelhance ao que resulrou no pri1neiro conjunto de compromissos (visão, requisitos, cronogra1na). Você não precisa rascunhar docurnentos ou ter grandes reuniões, mas é necessário infonnar às pessoas a mudança dos compron1issos, e envolvê-las no processo de decidir o modo corno essas n1udanças aconrecerão.

Ao solicirar à sua equipe que jogue fora duas semanas de rrabalho, verifique se esses cusros foram incluídos no cálculo da decisão. lnforn1e às pessoas o motivo pelo qual a nova mudança é acertada, e os fatores que contribuíram para essa opinião. Se possível, reúna os integrantes da equ ipe antes de tomar as decisões finais.

Não tenha medo de fazer n1udanças. Mudar é bom e inevitável. Mas há vários tipos diferentes de mudança, e diversos métodos pelos quais um líder pode gerenciar u1na equipe através da mudança. Se você estava indo para o oeste e o projeto precisar ir agora para o norte, sení necessário aplicar as mesmas habilidades (se bem que duas vezes mais ágil e com bem menos formalidade) usadas para que a equipe se movimentasse para o oesce, para fàzê-la se mover para o norte. Exarnine novamenre os Capítulos 3, 4, 11 e 12, para obter uma orientação sobre como liderar através da mudança.

A pipeline da codificação

Uma visão pragrnática do trabalho do rneio-jogo enfoca os programadores criando o código. A única maneira de o projero avançar é fazer com que cada linha do código escrita aproxime o projeto da conclusão (recursos favoritos, otimizações desnecessárias etc. não en1purram o projeto para frente). Todo o esforço do planejarnenro e design ocorrido antes de os programadores escreverem o código, quer seja realizado por eles ou por outras pessoas, serve para criar uma seqüência de atividades eficiente para serem desenvolvidas no decorrer do ren1po. Esse processo é denominado pipeline da codificação.

ESTRATÉGIA D E M EIO-]OGO 295

O GP deve garancir que a pipeline da codificação esceja funcionando normal1nence. Enquanco os programadores deve1n gerenciar a pipeline e decidir que1n trabalhará no quê,3 o GP cambém é respons,1vel por certificar-se de que a equipe de progran1ação renha o apoio necessário para fazê-la fi.1ncionar. Isso pode abranger tarefas de 1nenino de recados, organizar reuniões, incon1odar várias pessoas para finalizar decisões ou, em alguns casos, solucionar os problemas4 rescances do design (consulce a Figura 14-4). Talvez o GP precise antecipar alguns dias de trabalho antes do progran1ador, finalizando designs e alimentando a pipeline. Quando responsável pelo trabaU10 de vários desenvolvedores, o GP deverá priorizar seu tempo com cuidado, para assegurar que possa lidar com as demandas da concorrência de várias pipelines (outro motivo pelo qual o programador chefe deve Fazer uma parte ou mais desse trabalho).

Hoje

Programador

GP ( Design para A i

Amanhã

Implementação A

Design para B

Depois de amanhã

Implementação B

1 Design para C 1

FIGURA 14-4. Os detalhes finais de uma especificação/design podem ser verificados ou finalizados simultaneamente pelo GP ou designer. Isso contribui para a importância da pipeline da codificação.

Na obra Web Project Management: Delivering Successfttl Commercial Wéb Sites (Morgan Kaufmann , 2001), o autor Ashley Friedlein chama esse processo de instruir a equipe (fazer u1n briefing), e o detalha1nenco da próxima parte do trabalho que farão é denon1inado brief Con10 Friedlein escreve, "Para maxiinizar a eficiência e a rapidez do desenvolvimento, seus briefi devem ser elaborados de modo a estarem sempre à frente do trabalho em detenninado nlomento. Assim que uma parte do trabalho for concluída, o brief da pr6xi1na seção já estará pronto". Esses briefi são oriundos das especificações (se ainda forem relevantes), mas contê1n algo novo ou modificado, que o programador talvez precise saber. Sem instruir ativamente os programadores durante o n1eio-jogo, várias ocorrências poderão bloquear um item de trabalho e retardar a pipeline: problen1as de usabilidade, trabalho do design visual, irens de trabalho realizados por outros programadores, problemas de marketing, técnicos ou dependências externas. Por terem o mais diversificado conjunto de habilidades, os GPs são as pessoas mais indicadas para tomar a frente da pipeline da codificação, sinalizar ou solucionar problemas e normalizar as coisas antes de o programador co1neçar a crabalhar. (Isso inclui procurar incansavelmente os programadores fruscrados, que estão bloqueados, mas não o admitem ou sequer perceberam o tàro.)

296 A.ARTE DO GERENC[AMENTO DE PROJETOS

Quacro perguncas definem como fazer isso de 1nodo eficience:

• Que itens de trabalho estão sendo ativamente codificados? Exiscem proble1nas impedindo que os programadores finalizem seus irens de trabalho atualmente ativos? Neste caso, elimine-os (os problemas de bloqueio, não os itens de trabalho). Este é um estado de alerta vermelho no projeto. Se um programador estiver impedido de escrever ativa1nenre o código, o projeto estará paralisado. Nada é n1ais importante do que solucionar un1 problen1a que inrerron1pe o trabalho de un1 programador. Basca perguntar a eles "Co1no posso ajudá-lo a solucionar isso?" Eles d irão se você pode ajudar. Se o problema do bloqueio for uma dependência (por exemplo, Fred precisa final izar o item de trabalho 6 para permitir que Bob comece no item de trabalho 7), examine que outro trabalho um programador poderá fazer até o bloqueio ser removido.

• O programador sabe e conhece todos os detalhes necessários para implementar o item de trabalho atual para uma especificação? Há sempre perguntas e lacunas que só aparecem no 1no1nenro da i1nplemenração. Alguns progra1nadores são 1nais pró-ativos do que outros para resolver essas lacunas de 1nodo ponderado. O GP ou designer deve estar disponível e envolvido o suficience para ajudar a identificar e fechar essas lacunas. Ocasionalmente, é possível prevê-las - por exe1nplo, cedos os problen1as levantados na revisão das especificações desse ice1n de crabalho fora1n resolvidos?

• Qual é o próximo conjunto de itens a ser codificado? É exaca1nenre aí que inicia o gerencia1nenco da pipeline: estando um passo à frente dos progra1nadores (consulte a Figura 14-4). Se os irens de trabalho atualmence ativos estiverem em boa forma, o foco mudará para os próximos itens acima na pipeline. Esses itens costumam ser a próxin1a parte mais importante do trabalho para o projeto. Procure sempre fazer primeiro o trabalho mais crítico, mesmo que seja o mais árduo. Para ca.da item na pipeline, exa1nine as questões pendentes que pode1n atrasar ou interromper o progra1nador quando o item em questão alcançá-lo. Localize e solucione-as.

• O último item de trabalho finalizado foi realmente concluído? O resultado da pipeline da codificação é que i1nporca. Alguém deve examinar o efeito dos check-ins na co1npilação e garancir que ele realinence fàz o que suposcamence deve fazer sob o prisma do clience. A conclusão desse úlci1no irem de trabalho realmente acrescentou a funcionalidade e o co1nporca1nenro necessários? A equipe de cesce concorda com isso? Todas as unidades passaram nos cesres? Algué1n pelo n1enos abriu os bugs para rastrear o que está faltando? Cotnpilações diárias (descritas no capítulo seguinte) são tuna maneira fácil de aco1npanha1nento, porque sempre é possível experi1nentar o estado atual do projeco - e enconcrar as lacunas no que foi concluído - co1n o que é necessário. Quanto maior for o icem de trabalho, tanro mais i1nportanre será este aspecto.

Alguns programadores assumem mais responsabilidade do que outros por suas pipelines de codificação. Muitos progran1adores buscarão n1ais agressivan1ente determinados t ipos de problemas (técnicos) e tenderão a ignorar ou retardar outros (comerciais, políticos). Parte de seu relacionamento com cada programador é saber até que ponto você deve participar para assumir o gerenciamento da

ESTRATÉGIA DE ME10-Joco 297

pipeline. Não importa quem fará isso, desde que seja feito, e alguérn verifique e proteja ativa1nente a qualidade desses itens de trabalho. (Esta é u1na discussão de funções, descrita no Capítulo 9.)

Pipeline agressiva e conservadora

A pipeline de codificação geralmente só precisa estar dois ou três itens à &ente da equipe de programação (se cada icem exigir dois dias, será necessária 1nais de uma se1nana de trabalho para crês itens). Pode ser uma discussão infonnal entre GPs e programadores para estipular a próxima seqüência lógica. (Ou, se existir um caminho crítico mestre ou um gráfico de Gantc, e realmente não estiver com semanas de atraso, a pipeline poderá ser derivada dele.) Isso propicia um bujfer adequado de modo que se um problema de bloqueio não puder ser resolvido em tempo hábil, o programador e o GP tenham ce1npo suficiente para encontrar outro item de trabalho adequado e colocar na pipeline, enquanto esse problema de bloqueio é solucionado.

Uma equipe co1n u1na postura agressiva pode contar con1 a pipeline para priorizar problemas. E1n vez de criar urna escrucura analítica de projeto elaborada (Wórk Brerikdown Structure - WBS) de todos os irens do trabalho, a equipe aposta na ocorrência de mudanças e na possibilidade de o GP ou programador chefe gerenciar a pipeline. Neste caso, os riscos são mais alcos: se a pipeline for copiada em backup ou não puder pern1anecer à frente da equipe, serão to1nadas péssin1as decisões e ocorrerá u1n desperdício de tempo. Para obter n1ais inforn1ações sobre corno criar boas WBSs e aplicá-las ao cronograma do projeto, consulre Total Project Control, de Scephen Devaux (Wiley, 1999), ou qualquer outra fonte de referência do gerenciamento de projetos tradicional.

Para as equipes com uma postura mais conservadora, gerenciar a pipeline é u1n aprimoramento sutil da lista de itens de trabalho original, criada durante o planejamento. A pipeline pode ser mapeada para quatro sen1anas ou meses de trabalho, usando o plano original como a origem da pipeline de cada programador. Devem ocorrer pequenos ajustes, mas a expectativa é a de que o plano original continue viável, pelo 1nenos, através do marco. Quando iniciar o pról(imo marco, será gerada. uma nova. lista de itens de trabalho como parte do planejarnento e o processo se repetirá. Assim, dependendo de quão curro for o marco ou quão estável for um projeto, será possível elaborar um planejamento antecipado e viável da pipeline.

Contudo, o aspecto fundamental em relação às pipelines não é seu 1nodo de elaboração. Toda metodologia rem uma alternativa. O que importa é que a pipeline seja gerenciada de modo eficiente, que os irens de rrabalho cercos sejam feitos da 1naneira cerca e que se desperdice pouco tempo identificando o que deve ser imple1nencado a seguir.

A pipeline da codificação torna-se a pipeline de correção de bugs

Mais adiante em un1 projeto, após a conclusão de todos os itens de trabalho, a pipeline da codificação continuará. O que 1nuda é que, no lugar de itens de trabalho, a pipeline é preenchida con1 bugs/defeitos para serem corrigidos. No Capítulo 15, discutiremos esse assunto quando cobrirmos a triagen1 - o processo de co1nada de decisões sobre como manipular os bugs.

298 A.ARTE DO GERENCIAMENTO DE PROJETOS

Rastrear o andamento

O marcador mais simples para rasrrear o anda1nenro do meio-jogo é a lisra de irens de rrabalho: antes da conclusão de cada irem de trabalho agendado (com o nível de qualidade adequado), o n1eio-jogo não estará terminado (consulte a Figura 14-5). Toda as estratégias de meio-jogo abrangem o conhecin1ento do estado do projeto, manter a equipe na direção cerca e tomar decisões para um final bem-sucedido. A pontuação dos irens de trabalho concluídos são os dados mais importantes para fazer essas determinações.

Itens de trabalho Concluído

A Sim

B Sim

e Não

D Não

E Não

FIGURA 14-5. O meio-jogo não termina antes da conclusão de todos os itens de trabalho agendados. Somente aí começa a fase final. Tudo o que não afetar a taxa de conclusão dos itens de trabalho nunca deverá ter prioridade sobre o que afetar.

Reco1nendo o uso de uma visão de projeto muito sin1ples, como a que a Figura 14-5 apresenta, e torná-la visível o máximo possível para a equipe (em projetos maiores, indique a porcentagem dos irens de trabalho concluídos por área). Se existi r um site da equipe, deve ser exibido com destaque um resun10 do andamento dos itens de trabalho, atualizado diariamente. Pendure um grande quadro branco no corredor principal para a equipe, e um gráfico semelhante lá, també1n. Toda reunião semanal de status ou uma grande reunião da equipe deve começar com uma revisão sucinta do status da grande equipe. Como os itens de trabalho devem ser concluídos e1n um a três dias, u1n gráfico como o da Figura 14-5 indicar<i o anda1nenco pratica1nente diário. As pessoas devem ser esti1nuladas a ir até lá regularmente e descobrir o que foi verificado recenremence e o que virá brevemente.

É evidente que devem ser rastreados os dados secundários sobre o status, como os dias restantes por irem de trabalho, dias de trabalho restantes por programador etc .. Não perrnita que os dados e1nbacem a visão simples. Durante o meio-jogo, é n1uito mais in1porcante oferecer alternativas para a equipe obter uma idéia holística do anda1nento do projeto. Geralmente, as pessoas cê1n uma noção de suas áreas locais e das áreas com as quais enrram e1n conraco e1n seu trabalho coridiano.

Cercamente, há mais informações sobre como rastrear o anda1nenro de modo eficiente. Este assunto será discutido 1nais detalhadamente no próximo capítulo, onde os bugs e as tendências terão uma i1nportância crítica.

ESTRATÉGIA DE ME10-Joco 299

Atingir alvos móveis

"Ninguém nunca venceu uma batalha seguindo um plano, mas nunca alguém ganhou uma batalha sem um. "

- Dv,•ighr D. Eiscnho,ver

Uin dos argun1entos mais fortes dos curtos ciclos de desenvolvimento do XP e outros métodos é que as orientações mudan1 o tempo todo. Ao usar ciclos de desenvolvin1ento curtos, o projeto pode responder às mudanças de direção rnais importantes sem desperdiçar o equil íbrio do trabalho, e rodo esforço de planejamento ou design pode ser focado no curto prazo tangível. Tudo isso faz rnuito sentido para mim, assim corno a atitude básica de almejar vitórias de curto prazo consistentes. Mas existe urna outra verdade: planos de prazo mais extenso, mesmo que prel iminares, tenderão a facili tar ainda mais as mudanças de curro e médio prazos.

O motivo é q ue no momento en1 que ocorre urna mudança nas meras, nos requisitos ou no design, o plano original rararnence é desperdiçado en1 sua totalidade. E1n vez disso, as rnudanças (urna espécie de deltas) ocorrern ern relação a algu1na idéia de referência do que o projeto seria até a nova alteração ser efetuada. Por mais exaro que fosse o plano original, n1es1no que fosse u1na versão preli1ninar, ranro mais forre seria um ponto de referência e ranro 1nais rápidos seriarn os ajustes. Isso significa que o melhor seguro contra a volatilidade das coisas que rnudan1 é ter urn plano viável desde o início, que possa ser ajustado ao longo do processo.

"Bem, em minha opinião, uma batalha nunca se desenrola de acordo com o plano. O plano é apenas u1na base comum para rnudanças. É 1nuito importante que todos conheçam o plano, para que seja alterado facilmente - a batalha moderna é muito jluidrt e você tern que tornar decisões 1rluito l'apidamente - e, na rnaioria das vezes, discordando do plano. Mas pelo menos todos sabem de onde você partiu, e {depois]

para onde estd indo, niais ou menos. "

-General de Brigada Dan Laner, Comandanre das Forças de Defesa de Israel

Ao usar planos onde os alvos são suposra1nence 1nóveis, o truque é nunca passar períodos de re1npo prolongados se1n acualizar o plano. Se for possível identificar os intervalos certos, os alvos móveis não se rnoverão rnuito de urna só vez: eles apenas seguirão e1n certa direção, a u1na velocidade específica, e1n detenninado re1npo. Se você tiver vários rnarcos ou fàses em seu projeto (consulte o Capírulo 2), esses serão seus intervalos naturais para fazer ajustes (e se o tempo do novo design for planejado em cada u1na dessas fases, você poderá revisar o que foi concluído no primeiro marco, que precisa ser alrerado). Até rnesrno em urn rnarco de três ou seis setnanas, você pode encontrar u1na ou duas nlédias para reavaliar a t rajetória do projeto em relação a quaisquer n1etas ou requisitos que possam ter nludado. Por esse motivo, a duração dos marcos deve corresponder à volatilidade: quanto mais volácil for a direção, ranro mais curta será a duração do marco.

A Figura 14-6 craz um exemplo sin1ples de fuzer ajustes para acompanhar as metas móveis. O projero inicia em A e suposcamence termina em B. Se após duas se1nanas de projeto (talvez a conclusão de um marco curto), os líderes da equipe

300 A .ARTE DO G ERENC IAMENTO DE PROJETOS

chegarem à conclusão de que as meras de B mudaram, o projero deve ser al(er-ado par-a man(er-se síncronizado co1n B. Ou(ras duas semanas, 1naís ajusres são feíros e ocorre u1na nova correção do curso. Algum rr-abalho pode ser desperdiçado, 1nas menos crabalho será perdido ao ajusrar a direção no início do que n1aÍs rarde. Se esses movi1nentos coincidirem com o final/início de marcos, a equipe terá cempo de desenvolver algt1111 trabalho de design para compensar as modificações, adicionar itens de crabalho para alterar o trabalho anterior e fuzer os ajustes a passos largos.

Dia 1

cp 1 1 1 1 1 1 1 1

0

Dia 15

© "' 1 1 1

0

Dia 30

cp 1 1

0 FIGURA 14-6. As metas, os requisitos e as restrições mudarão, mas se a velocidade e a direção forem compreendidas, e forem executadas etapas intermediárias para rastrear as alterações, será possível gerenciar a mudança.

Inclusive se1n os ínrervalos de 1narco adequados, a pipeline da codificação pode ajudar a cornar esses ajusces ínrer1nedíáríos conrroláveís pela equipe de desenvolvimenro. Como essas 1nudanças de curso ocorre1n na saída da pipeline diante da equipe de programação, há uma 1narge1n de segurança para a ocorrência de mudanças. Quanco 1naior for o prazo na pipeline (consulce a Figura 14-7), canto maior será essa n1argen1 de segurança. Presu1nindo-se, evidentemente, que haja alguém (GP ou programador chefe) cotn rempo para gerenciar a pipeline, a equipe não precisará parar toralmenre para f:1zer mudanças de rumo. Basca existir trabalho (cerro) suficiente na pipeline.

Movimento real

00 ©

0 Areade > cobertura

Movimento possível suportado

o 00 0 1 1 1 1

----0------FIGURA 14-7. Todo plano possui uma área de cobertura para o limite máximo de variância suportado. Quanto mais abrangente ou mais detalhado (com prognóstico de possíveis mudanças) for o plano, tanto maior será essa área de cobertura.

ESTRATÉGIA DE ME10-Joco 301

Concudo, isso realmence pressupõe que as 1nudanças não escão radica!tnence longe do plano inicial: um esforço de planeja1nenco específico propicia apenas uma possibilidade limicada de 1novimencação (consulce a Figura 14-7). Se os novos requisitos ou n1etas ultrapassaren1 determinado ponto, será necessário realizar um novo trabalho e investigação importante do design, que vá além do prazo suportado pela pipeline da codificação (ou, em alguns casos, quanto tempo de design está previsto para o próximo marco). Por exemplo, se o plano inicial era criar um forno-corradeira, seria possível ajustar o projeto durante o meio-jogo para cransfonná-lo e1n um forno de tamanho médio - mas não en1 um acelerador de partículas ou um navio petroleiro.

Na Figura 14-7, um modelo rudimenrar mostra a variância de um projeto; a área representa o espaço de mudanças que o esforço do planejamento permitiu para a recuperação por parte da equipe, sem um novo trabalho significativo. Um diagrama semelhante poderia ser desenhado no nível micro, para cada item de trabalho. Dependendo da abordagem do progra1nador, o respeccivo plano terá diversos níveis de cobertura para as 1nudanças de requisitos/design nesse itetn de trabalho.

Há uma coisa cola na Figura 14-7, digna de citação. Ela representa o avanço cronológico vertical, implicando que a área de cobertura dá mais oportunidade para o rnomento no decorrer do tempo, o que não é verdade. Uma maneira mais exara de i1naginar a área de cobertura é que ela muda em função das mudanças ocorridas no projeto, au1nentando e diminuindo de acordo com o estado em que o projeto se encontra. Ern geral, o espaço de cobertura encolhe co1n o passar do re1npo, à medida que os itens de trabalho são concluídos. Mas cada movimento realizado desvia o plano efecivo, e junta111ente com ele, a possível cobertura do futuro movimento.

Lidar com o gerenciamento de mistérios

Nos projetos de bom funcionan1ento em organizações saudáveis, a maioria das mudanças de alto nível são cronon1etradas de acordo com os 111arcos do projeto (porque, mais urna vez, a duração dos marcos corresponde aproxirnadamente à volatilidade do projeto ou organização). A gerência tern paciência e 1naturidade de esperar o término da fase, para instruir a equipe a redefinir e reajustar. Mas acé mesmo nessas organizações, podem existir diretivas de gerenciamento que forçam a ocorrência de mudanças no meio do percurso, sem muito tempo de evolução, para se preparar para elas.

Na 1naioria das vezes, há mais alarmes da gerência, dos clientes e da concorrência para fazer as correções do curso do que verdadeiras decisões para 1nudar o curso. As vezes, está dentro de sua esfera de poder fazer as ligações para 1nudar as direções; outras vezes, você deve apenas aguardar a decisão de onera pessoa. E1n ambos os casos, parte de seu raciocínio deve incluir um plano preliminar do que você faria se a 1nudança a1neaçada realmence ocorresse. Ances que grandes decisões procedam da gerência ou os concorrentes dêe1n as viradas cerras, norn1al1nente podem ser encontradas algumas linhas escritas na parede, con1 dias ou sen1anas de antecedência - se você estiver aco111panhando o caso. Você depende de suas relações e habilidades políticas para obter as informações necessárias para in1pedir que o projeto seja surpreendido. Nem sempre é possível evitar, 1nas às vezes dá certo.

302 A.ARTE DO GERENCIAMENTO DE PROJETOS

Usando as infonnações obridas, faça periodica1nenre sua melhor esrimariva de qual será a 1nudança de rumo (Suporre para uma nova tecnologia? Um novo recurso? Uma nova mera?), e delineie os ajusres necessários para chegar lá. Isso pode ser feiro de n1aneira simples - por exemplo, conversar rapidamente com um programador chefe sobre o que pode estar envolvido. "Fred, o que teríamos que fazer para suportar o conjunto da API 2.0, adicionaln1ente aos que já utilizan1os?" Sua nleta não é u1n novo plano de baralha, é apenas uma noção de como será a estrada, se você e sua equipe precisarem trilhá-la. Reexamine sua lista de atribuição de prioridades para os irens de trabalho (consulce o Capítulo 13) e verifique se você j<í tinha refletido sobre o novo trabalho que teria que assumir.

Investigar o impacto da mudança

Se a probabilidade dessa n1udança se rornar alra, você poderá ajustar o rrabalho na pipeline da codificação para se preparar melhor para as mudanças. Na esrrarégia do xadrez, existem pelo menos duas maneiras diferentes de planejar um movimento:

l . Conservadora. Procure os movimentos que lhe permitam o maior número de movi1nentos futuros e que m.antenham suas opções abertas.

2. Agressiva. Compromera-se toralmente com uma linha de esrrarégia que você vê claramente e force o jogo sobre seu oponente.

Nos projeros (ou no xadrez), quando você est<Í confiante e se senre 1nais forte do que o oponente (por exemplo, gerenciamento de 1nistérios, ou a concorrência), a agressiva é a opç.,'io a seguir. Quando as coisas estão incertas ou você foi sobrepujado, a 1naneira conservadora costuma ser a melhor opção. Pedir à equipe que pense de modo conservador pode retardá-la um pouco, mas esse é o preço do seguro que você está comprando. OcasionaJ1nente, ser agressivo obriga os outros a ton1are1n decisões, e se você estiver indiferente ao resultado mas precisar de u1na decisão rápida, as decisões agressivas pode1n funcionar a seu favor, mesmo que esteja em uma posiç.,'io polírica desfavorável.

. Observe que considerar os ajustes ne1n sempre significa um re1npo de desenvolvimento extra ou redução da qualidade do código. Pode existir um algoritmo alternativo com a mesma conftabilidade, mas 1nais flexível de uma forma importante. Basca pedir ao progra1nador ou à equipe: "Rapazes, cerno que nosso cliente/VP nos obrigará a suportar outro esquen1a de banco de dados. Examinem o que vocês estão fazendo, e se houver maneiras fáceis e inteligentes de nos preparannos para essa mudança à medida que trabalharem, faça.1n isso. Mas não implementem mudanças radicais, ne1n sacrifique1n a qualidade por conta disso. E ntendera1n?".

' As vezes, isso é impossível: pode levar horas de investigação para responder a essa pergunta. Mas há casos em que isso será muito simples. Por exemplo, é possível que um programador já tenha pensado nessa direção ou tenha uma opinião razoável, com base no seu conhecimento do código. Para preparar sua equipe dessa maneira, calvez isso não custe mais do que uma conversa de cinco minutos. Mais i1nporcante, calvez:

ESTRATÉGIA oE ME10-Joco 303

quaJl[O mais você conhecer os possíveis cus[OS da mudança, tanto melhores serão seus argu1nentos para ve[ar as 1nudru1ças (ou se perrinen[e, para apoiá-las).

O alcance potencial da mudança

Convém observar também que quanto mais um projeto se aproximar do conjunto inicial (ou do úlrimo ativo) de meras, ranro mais distanre ele estará de realizar quaisquer ajustes ou mudanças de rumo. Na Figura 14-8, o projeto está oficialinente se movendo para B, mesmo que ainda existam forres rumores de mudança de rumo (indicados como uma "?" na figura) . O GP faz sua melhor estimativa sobre qual será a mudança e ajusta adequadamente. Ele prepara um plano rápido com seus programadores sobre como eles podem reagir.

Dia 15

©0 1 1 1 1 1 1 1 1

----•

0

Dia30

0 1 1

1 1 ___________ ...J

\ O alcance da mudança

0 FIGURA 14-8. Se você souber que uma mudança está para chegar mas não souber quando, ainda poderá usar sua melhor suposição de como será essa mudança.

À 1nedida que o projeto avança, a mudança niisteriosa continua sendo um rumor. O ângulo da 1nudança se desloca enquanto o projeto prossegue para B, tornando­se 1nais nítida e 1nais arriscada. A cada linha de código escrita, menos e rnenos suporte pode ser concedido a urn possível r111no alternativo. Quando o projeto estiver rnais próximo da conclusão em B, a distância para a mudança misteriosa (chamado de alcance da mudança na Figura 14-8) será maior, em relação à distância residual até B. Quanto nlais a equipe de1norar para fazer 1nudanças durante o andamento do projeto, tanto mais altos costumam ser os custos.

Se a rnudança acontecer, e seus esforços projetados não con1pensare1n, você não terá outra opção, a não ser redefinir a equipe. Se a n1uda11ça chegou se1n recursos adicionais de tempo, retorne às suas listas de atribuição de prioridades e identifique os itens que poden1 ser cortados, para ganhar o tempo necessário (consulce o Capírulo 11).

Gerenciar mudanças (controle de mudanças)

Algun1as equipes de projeto controlam e rastreiam ativamente toda mudança no design q ue exija um novo item de trabalho ou a exclusão de um já existente (isso

304 A.ARTE D O G ERENC[AMENTO DE PROJ ETOS

corneça depois da revisão oficial das especificações). Há um temor de que se as mudanças no design forern feiras sen1 urn processo envolvido, ocorrerão decisões grandes, mas demoníacas, sern que as pessoas certas renham conhecimento disso. Dependendo da cultura e das meras de sua equipe, você pode ou não precisar fuzer isso. Como destaca Friedlein, "O modo como você gerencia a mudança ao longo do projeto dependerá do tamanho e da natureza do projeto. Geralmente, quanto nlaÍor e mais con1plexo for o projeto, e quanto mais rígidas forem as especificações, tanto maior a firmeza com que você deverá gerenciar a n1udança". Se a sua equipe não se imporra corn um processo de especificação, provavelmence rambém não ligará para u1n processo de nludança - não haverá nada para marcar deltas contra.

Encret:anto, mesmo em uma equipe corn menos processos formais, quanto mais próximo um projeto estiver de sua conclusão, tanto mais sensível será em relação às mudanças. Sem um processo em vigor para informar, rastrear e gerenciar as mudanças, é difícil e frustrante fechar a porta e1n un1 projeto. Quanto mais a1nadurecida for urna equipe, tanto 1nais cedo ela tenderá a querer controlar a 1nudança. Não é necessariamente um processo de final de jogo: só que à rnedida que o final se aproxima, os riscos aumencarn, assim corno o desejo de concrolá-los.

O modo mais simples de gerenciar a mudança é acravés de uma versão superenxuta de um processo de especificação. A NASA e a Microsoft chamarn esse processo de DCR, ou Design Change Request {solicitação de rnudança do design) . Outros non1es con1uns atribuídos a esse processo são ECR (Engineering Change Request - solicitação de mudança de engenharia), ECO (Engineering Change Order - pedido de nludança de engenharia) ou a fonna mais simples, CR ( Change Request - solicitação de mudança).

Para isso, o processo n1ais simples é o seguince:

1. Alguém (GP) redige um resumo da mudança - inclusive sua relação com as metas ou requisitos do projeto - a necessidade da mudança e uma explicação do design da n1udança a ser implementada. (São concedidos pontos de bonificação para identificar os possíveis riscos do impacto da DCR sobre o projeto.) Esse resu1no raramenr.e ocupará mais do que uma página ou duas. Um bug (ou, seja qual for o método usado para rastrear problemas) deve ser criado para acompanhar a DCR e este documento deve ser anexado a ela.

2. O prograrnador, testador e quem for bastante afetado pela mudança devem contribuir para o resurno da DCR e chegar à conclusão de que essa mudança é necessária e que seja adequadamente elaborada. O programador apresenta as esrimarivas do desenvolvimento, e o resrador as estimativas dos restes {ou plano de reste prelirninar).

3. A DCR é sugerida a urn pequeno grupo de líderes da equipe (consulte a seção "Equipe bélica" no Capítulo 15), ou ao gerente do grupo, que coma urna decisão a favor ou contra a mudança. Se a mudança vier a acontecer, será considerada mais um irem de trabalho no projeto, e a DCR será difundida para a equipe (e o item de trabalho será atribuído ao programador pertinente). Os cronogramas e qualquer docun1entação do projeto deven1 ser acualizados de modo a incluir essa mudança. Se for recusada, a DCR rasrejará para o canto mais próximo da sala, soluçando descont:roladamente, até desaparecer do universo do projeto.

ESTRATÉGIA D E MEIO-}OGO 305

A última etapa pode ser ignorada se as equipes forem pequenas e a autoridade for alramenre distribuída. As pessoas relevanres apenas se reúnem, discute1n as opções e decidem sobre a 1nudança. Mas se a Inudança forçar uma derrapagem no projeto, afetar outros progran1adores ou exigir outros recursos, os líderes da equipe deverão participar.

As DCRs são sen1pre nlais caras do que o previsto em suas estimativas de programaç.'io e de teste. Elas têm efeitos colaterais in1previstos sobre o restante da equipe de engenharia e faze1n com que o GP dê menos atenção à pipeline e a ourras atividades que já são imporcanres. Como o trabalho de design para as DCRs é realizado no dobro do tempo, a probabilidade de erros e de péssimas escolhas no design é alta. É comum uma DCR gerar a necessidade de outras DCRs. Minha atitude geral em relação a elas é a seguinte: é melhor usar ciclos de desenvolvimento curtos, com fortes processos de design e permitir menos DCRs, do que planejar um cronograma que prevê várias mudanças e1n DCR. Os integranres da equipe devem ser incentivados a resolver logo no início seus proble1nas de design e evitar o processo da DCR.

Resumo

• O 1neio-jogo e o final corresponde1n às fases intennediárias e final do projeto.

• Se e1n algum dia o projeto não estiver indo bem, identifique o que esrá errado e solucione. Repira essa operação no decorrer de todo o 1neio-jogo.

• Projetos são sisce1nas não-lineares complexos, que tê1n un1a inércia significativa. Se você aguardar os problemas graves para executar uma ação, será carde demais e as coisas poderão piorar.

• Quando seu projeto estiver fora de controle, você estará pilotando atrás do aviã.o, que é um péssimo lugar para ficar. A verificação da sanidade é o modo mais facil de permanecer à frente do avião. Existem verificações de sanidade táticas e estratégicas.

• Considere como execuca.r uma ação para corrigir uma situação no modo mais seguro possível. Quanto 1naior for uma ação e quanto 1nais de1norado for o projeto, tanto 1nais perigosas serão as ações.

• A pipeline da codificação é o modo co1no os itens de trabalho são gerenciados durante a i1nplementação. Há 1naneiras agressiva e conservadora de gerenciar a pipeline.

• O planejamenro baseado em 1narcos e a pipeline da codificação oferecem oportunidades de fazer correções seguras do curso dos projetos.

• Controle de mudanças (DCRs) é o modo como se regula a taxa de mudanças de baixo e médio nível em um projeto.

Capítulo 15

Estratégia de final de jogo

308 A.ARTE DO G ERENCIAMENTO DE PROJETOS

Dando continuidade a partir da estratégia do meio-jogo do úlrimo capículo, este capírulo enfatizará o acendimento de daras e prazos, assim como as ferra1nencas a sere1n usadas para orientar a conclusão dos projetos e1n tempo hábil.

É f.ícil esquecer, mas rodos os projetos têm n1ais de um prazo. Há sempre datas e cronogramas incennediários que conduzem aos marcos ou às datas de fim do projeto. Isso significa que se sua equipe fizer um esforço extraordinário para ac.ender a u1n prazo co1n êxito, e existir outro prazo aguardando no horizonte, há riscos ocultos em forçar incensamente a equipe a acender o primeiro. Se for necessário muito esforço para atender a essa primeira dara e a equipe começar na data seguinte, exausra., estressada e frustrada, a probabilidade de atender com êxito ao prazo seguinte será reduzida. Vince Lombardi disse certa vez que a fadiga torna todos covardes. Quando estamos exaustos, nenhuma cafeína nos tornará as pessoas que somos em circunstâncias melhores.

"O inodo como você toca uma nota é tão importante quanto a própria nota. "

- Henry Kaiscr

Quando uma equipe é muito pressionada, serão necessários dias ou se1nanas para volrar ao rnesmo nível de desernpenho previsto nas esrirnativas de trabalho da equipe (consulce a Figura 15-1). Pior ainda, quanto n1ais vezes a equipe for pressionada dessa maneira, tanto n1enor será a agilidade - o esgotamento é o ponto ern que a recuperação não é 1nais possível e1n un1 cronograma útil.

Marco 1

Efeito

---Real

===-"> - - - Planejado ;f,. Tempo

CY FIGURA 15-1 . Você paga um preço por falhar no atendimento a uma data e tentar cumprir a seguinte. Forçar muito para atingir o Marco 1 obrigará o Marco 2 a começar no buraco.

No nível de projeto, é melhor pensar na produtividade da equipe como um recurso de soma 1 zero: se você exigir esforços extras para curnprir un1a data, conscientize-se de que está roubando esses esforços das partes iniciais da fase seguinte. (Contudo, se a equipe civer funções especializadas, é possível minimizar isso, deslocando responsabilidades. A fase crír.ica para os designers, planejadores, GPs, cesradores e programadores costuma ocorrer em diferences ocasiões no projeto. Se o trabalho for corretamente distribuído, a equipe inteira nunca será igualmente pressionada, com as diversas fi1nções executando mais da carga de trabalho em diferences momentos.)

Pior ainda, há uma taxa de juros a ser paga: a proporção entre o tempo de recuperação e o esforço da pressão não é de 1: 1. Ê necessário mais tempo

ESTRATÉGIA oE F1NAL oE ]oco 309

para recuperar-se do que para exercer o esforço extra incenso (por exemplo, pode levar apenas 20 segundos para correr para pegar o cre1n, mas você precisa de um minuco ou mais para ganhar fôlego ourra vez). Algu1nas vezes, o preço a pagar é o sacrifício das vidas pessoais e familiares das pessoas, o que não esrá no interesse de longo prazo do indivíduo, da equipe ou da organização (consulte a Figura 15-1).

Isso significa que o bom gerencian1enro deve evitar as grandes exigências. É i1npossível evitar alguns picos em um projeto grande, mas é interesse dos gerentes controlá-los com cuidado, trabalhar de modo preventivo para minimizá-los e conhecer os custos reais quando vierem à tona (por exemplo, não culpe a equipe duas semanas antes do próximo marco por ser preguiçosa e excêntrica) . Quanto mais longo for o projeto, tanto mais energia a equipe perderá nesses picos e tanto mais difícil se tornará o verdadeiro final do jogo de um projeto de vários n1arcos.

Grandes prazos são apenas vários prazos pequenos

Para discutir aspectos i1nportances da estratégia de meio-jogo e final, é necessário definir várias daras intennediárias que ocorre1n nos projetos. As três <lacas intermediárias 1nais básicas, em un1 cronograma si1nples, corresponden1 aos crossovers entre a regra preliminar de terceiros, descrita no Capítulo 2 (consulte a Figura 15-2). Cada ponto de crossover representa u1na 1nudança no foco da equipe, e deve cer os próprios critérios de saída.

1 Design i< Design concluído

Tempo Programação

@ i< Recurso concluído

1 Teste

Teste concluído < Design

FIGURA 15·2. Nos marcos, há datas-chave que devem ser acompanhadas, focadas e devem ter um critério de saída.

Os critérios de saída. são sua primeira lista de coisas que o marco supostamente deveria cumprir. Eles descrevem o estado em que o projeto deve estar para finalizar um marco. Quanto mais cedo os critérios de saída forem definidos, ranro maiores as probabilidade de que o marco seja concluído e1n tempo hábil.

Os três principais pontos de crossover e1n qualquer marco são:

• Design concluído/especificação concluída. A equipe escá preparada para escrever o código da produção. Todas as especificações, protótipos, briefi de design necessários para iniciar a imple1nenração esrão finalizados. (Observe que isso não exige o término de rodas as especificações, somente as necessárias para

310 A ARTE DO GERENCl1\MENTO DE PROJETOS

começar a imple1nenração. Podem ser 20o/o ou 90ºAi delas.) O rrabalho do design pode prosseguir (consulre a seção "A pipeline da codificação" no Capículo 14), e podem ocorrer iterações e revisões, mas uma porcenragem aceirável ou o ni'1cleo dele foi concluído.

• Recurso conchúdo. A equipe está preparada para focar o refinamento e a garantia da qualidade. Isso significa que toda a funcionalidade fornecida pelos irens de trabalho individuais foi finalizada, e que o comportamento e o design necessários para arender aos requisitos foram iinplemenrados. Podem existir lact111as ou problemas de qualidade, mas a liderança os avaliou ou rastreou (os bugs realmenre existem), o trabalho da construção básica pode ser considerado concluído. Todas as métricas de teste ou de qualidade definidas como parte da especificação j<í deve1n ter as avaliações. Nesse dia, todos os problemas restantes devem ser rastreados como bugr, e o banco de dados de bugr torna-se o método principal (se não for o único) de aco1npanhar a evolução restante.

• Teste ou marco concluído. O 1narco esrá finalizado. A qualidade e o refinamento alcançaram os níveis adequados. Começa o marco seguinre e/ou o projeto deslancha. Ocasionalmente, isso é chamado de marco concluído porque é a última fase no marco. Se for o (1nico ou o último 1narco, o projeto estará finalizado.

Além da qualidade das especificações, as esri1nativas de trabalho e a própria equipe, a regra geral 1nais simples para cumprir as daras é que quanto mais eficientes forem os critérios de saída, tanro maiores serão as suas chances.2 Até que os critérios seja1n atendidos, a equipe deve continuar trabalhando. Toda data importante no cronograma deve ter um conjunto de critérios de saída definido.

Definir critérios de saída

Os critérios de saída não precisam ser complexos (ernbora possam ser). Porém, devem realmente incluir os seguintes itens:

• A lista de itens de t rabalho a serem concluídos

• Uma definição do nível de qualidade em que esses irens devem ser concluídos (talvez oriundo dos casos de reste, planos de resre3 e especificações)

• A lista de irens e1n que as pessoas devem pensar deve estar pronta mas não precisa realmente estar concluída

• As coisas e1n que as pessoas nunca devem pensar devem estar prontas (verificação de sanidade)

Há várias maneiras de definir os critérios de saída e infonnar e rastreá-los junto à equipe. Os detalhes de con10 são preparados não têm tanta importância (sugira-os à equipe, receba os comentários, finalize e informe-os amplan1enre). O imporrante é prepará-los logo no início, mantê-los simples e usados publicamente para rastrear o andamento e orientar as decisões. Os critérios de saída devem ser remapeados segundo a visão e as metas, e devem ser o método mais útil para aplicar a visão e as metas às perguntas e aos desafios enfrentados nas fàses intermediárias e finais dos marcos.

EsTRATÉGlA oE F 1NAL oE JoGo 311

Crirérios de saída cornuns:

• Especificações/designs/listas de itens de trabalho concluídos. Isso é úril somente para a finalização do design. Sejam quais forem, as ferra1nentas ou processos utilizados para realizar o trabalho de design devem ter critérios de saída correspondentes para concluí-lo. Talvez 90o/o de todas as especificações revisadas ou um protótipo com um conjunco específico de fi.111ções . . operac1011a1s.

• I tens de trabalho reais concluídos. Deve ser a lisca de itens de trabalho definida. no início do marco ou fase do projeto. Quando os itens de trabalho estiverem completos para a especificação, a fase/marco estará finalizada(o).

• Contagens de bugs etn determinados níveis. Como discuriremos 1nais adiante, há várias rnaneiras diferentes de rastrear e avaliar bugs/defeitos. Geralmente, os critérios de saída abrangendo bugs especificam a quantidade permitida de bugs ativos de determinado tipo.

• Passar em casos de teste especificados. Pode existir urn conjunto de condições d e teste usadas para dererminar quando o 1narco escará concluído. Se urilizados como critérios, os casos de teste orientarão as decisões sobre quais bugs/defeitos devern ser corrigidos para que o 1narco possa tenninar. Talvez baste usar critérios de saída baseados em limiares, definidos pelos casos de reste, como "80º/o dos casos de teste para as situações da prioridade 1 devem ser aprovados."

• Métricas de desempenho ou confiabilidadc. Se a equipe estiver avaliando o desempenho de certos componentes (por exemplo, u1n banco de dados ou 1necanisrno de pesquisa), podem existir critérios de saída baseados nesses números. Se o critério de saída for uma melhoria de 10% da velocidade e1n relação à versão anterior, então o marco não estará concluído até que esse aumento de 10% seja atingido.

• Tempo ou dinheiro. Tempo é o critério de saída mais sirnples do inundo. Quando determinado período de tempo termina, o marco acaba. Final da história. Um trabalho de meses para obter belos marcos porque nunca há dúvidas sobre quando iniciara1n, termina1n ou quanto ternpo eles absorveram. (As pessoas usa1n sernanas e 1neses para acompanhar o restante de suas vidas, então por que não basear os cronogramas do projeto nesses parâmetros tainbérn?) Os recursos concluídos pela 1netade ou parcialrnence finalizados são cortados e considerados no próxi1no marco (se existir). O dinheiro também pode ser u1n critério de saída: quando o orça1nento é gasto e o poder se esvai, você fica paralisado.

Sem critérios de saída, a equipe ficará dependente de suas opiniões subjetivas sobre o que "suficientemente bom" significa para o projeto, o que é un1a grande perda de tempo. Todos terão opiniões diferentes sobre o que é suficientemente bon1. Mesmo que uma pessoa seja autorizada a tomar esta decisão, a decisão sempre sen1 controversa, a menos que alguma coisa seja anotada. Sem critérios, as equipes são obrigadas a enfrentar debates difíceis tardiamente em um projeto, quando a tensão e os riscos são altos. Evite colocar sua equipe em uma situação em que deva. se desperdiçar energia no final dos marcos, questionando sobre os

312 A.ARTE DO GERENCIAMENTO DE PROJETOS

critérios de saída. Em vez disso, planeje de 1nodo a usar roda a energia da equipe no final dos marcos para eferivan1enre acender aos critérios.

Lernbre-se de que a 1nera não é apenas cu1nprir uma dara, 1nas cumpri-la con1 o projeto em um estado específico. Quanto mais cedo a equipe determinar esse estado, tanto maiores serão as chances de que ele realmente aconteça. Se a equipe conhecer os critérios antecipadan1ente, toda decisão tomada ao longo dos marcos se refletirá nesses critérios. Mesn10 que os critérios mudem pelo percurso, a equipe estará se ajustando na mesma direção, preparando colerivamenre o projeto para u1n final de jogo mais fácil.

Um exemplo de lista de critérios de saída para u1n n1arco em um pequeno projeto de Web ficaria assim:

• Concluir os itens de trabalho 1-10, segundo as respectivas especificações

• Atender a 800/o das metas de usabilidade para as áreas de prioridade 1

• Passar em rodos os restes automatizados e manuais de prioridade 1

• Passar em 80% de rodos os restes auromarizados de prioridade 2

• Triage1n de rodos os bugs ativos

• Corrigir todos os bugs de prioridade 1 e 2

• Obter aprovaç.1o da equipe de 1narketing e de vendas

Por que cumprir as datas é como aterrissar aviões

Com marcos intermediários, a n1eta não é apenas cu1nprir uma data específica, mas preparar a equipe para o marco (ou versão) seguinte. Cumprir uma dara é mais do que uma simples cronologia: dependendo da tranqüilidade com que você atende a uma data, a estabilidade do código e o próximo marco (se existir) estarão . e1n risco.

Pense na aterrissage1n de un1 avião. Uma boa aterr issage1n posiciona o avião de modo a facilitar u1na outra decolage1n; por exemplo, se as asas ainda esrivere1n acopladas, o trem de aterrissage1n estiver funcionando e a tripulação ainda estiver atuante. Basca mais combusrível, um plano de vôo e um sanduíche para o piloto. A finalização dos marcos deve ser interpretada da mes1na nianeira. Quanto mais agudo for o ângulo para terminar um marco, n1ais altas serão as possibilidades de que o projeto não esteja e1n bom estado quando concluir o n1arco.

Ângulo de descida

, .E possível converter os cronogramas mais básicos de projetos de engenharia en1 um quadro simples, como o da Figura 15-3. Esse quadro pressupõe que a taxa de evolução seja constante, e que o projeto será finalizado exatamente denr.ro do prazo agendado, nlantendo essa raxa consranre. É evidente que se trata da rerra da fantasia. Esse quadro nunca será mapeado com a realidade porque a evolução e eflciência da equipe nunca são constantes (por vários motivos descri tos anteriormente neste livro).

EsTRATÉGlA DE F1NAL DE )oco 313

Agenda da terra da fantasia

Data de Data início

Trabalho restante

pretendida

FIGURA 15·3. Este é o cronograma de marcos mais básico do mundo, com premissas da terra da fantasia incluídas.

Ern vez disso, a rnaioria dos projetos tennina na situação ilustrada na Figura 15-4. Em algum ponto do carninho para a dara pretendida, a equipe percebe que o trabalho não apresenca a agilidade previsca. Isso pode ocorrer porque um novo crabalho foi introduzido (consulce a seção "Gerenciar 1nudanças (concrole de mudanças)" no Capículo 14) ou porque a equipe não atendeu às esrimarivas. A despeito de como isso aconteceu, a equipe deve estar diante de u1na escolha: como compensar o que falca para a data final? Existem apenas três opções:

1. Postergar a agenda. Deslocar a data final de 1nodo a reflerir a nova percepção da velocidade de descida.

2. Mudar o ângulo. Convença-se de alguma forn1a que você pode fàzer corn que a equipe crabalhe mais, mais rapidamente, para compensar a margem de tempo (por exemplo, prepare-se para uma aterrissagem forçada). Você pode rentar isso, mas há um preço a pagar. O risco de cometer erros será mais alto e a equipe estará preguiçosa e cansada ao iniciar o próximo ciclo de trabalho.

3. Atender à data com o que você tem. Identifique os recursos ou itens de crabalho com o máximo de trabalho ou risco residual. Corre esses recursos, prorrogue-os para o próximo marco (se existir) ou deprecie a qualidade e entregue-os como estão.

A fantasia se depara com a realidade Data de Data Data

inicio Realidade atual pretendida

• <:

Trabalho Fantasia restante

FIGURA 15-4. A realidade do cronograma em geral se contrapõe ao plano. A manipulação desse aspecto depende totalmente dos critérios de saída.

O n1odo con10 essa escolha é realizada depende totalmente dos crirérios de saída. Esra é exacan1ente a situação que 1nais se beneficia en1 ter um raciocínio claro sobre o que isso significa para o término do marco. Em vez de inventar critérios agora, sob a tensão de uma acerrissagem difícil, basca olhar para trás e

314 A.ARTE DO GERENCIAMENTO DE PROJETOS

ajuscar os cricérios definidos se1nanas ances. A cornada de decisões e1n sicuações difíceis de final de jogo ficará mais fácil se exiscire1n cricérios de referência que a equipe já conheça.

Por que a mudança do ângulo pode não funcionar

Usando novan1ence a analogia do avião, mudar o ângulo para encaixar o espaço restance desestabiliza a abordagem. Assiin como os aviões, os projecos não controlaJn 1nuito bem quando sua velocidade de descida está alta. Há muiras coisas que precisam ser realizadas simultaneamente para que essa velocidade se estabilize. Se você estivesse em um avião se aproximando da pista e percebesse que sua abordagem não funcionou , você mudaria de direção e faria uma nova aproximação (mover a pista, ao contrário das datas do cronograma, é impossível). Diante do 1nau te1npo, os vôos comerciais geralrnence reiniciam sua aproximação. Contudo, os projetos rara1nente podem respaldar essas ocorrências. Eles são como aviões quando escão com pouco co1nbustível: há recursos suficiences para apenas u1na aproxi1nação. Co1n u1n só ciro, os pilocos sadios faze1n aproxi1nações 1nuico cuidadosas e be1n-planejadas. Os gerentes de projecos sãos devem agir assim também. Se não for possível mudar seu compromisso ou recurso (como acontece com uma pisca), você deve começar a se preparar para arerrissar logo no início.

Por que piora

Exisce um princípio psicológico básico que respalda o 1nodo como a maioria das pessoas prioriza seu rrabalho. Com rodos os fatores consrantes, as pessoas tenderão a evitar fazer coisas que não desejam.4 Isso significa que à n1edida que o cronograma evolui, os itens de trabalho restantes ou as correções de bugs serão as tarefas indesejadas e infelizes do marco. E mesmo que o trabalho restante seja ridiculamenre divertido de se fazer, se as equipes fore1n recompensadas pelo número de bugs corrigidos e1n um dia ou semana., haverá tuna pressão natural para selecionar bugs con1 a dificuldade pertinente para atender à quota.

No final dos marcos, as pessoas estarão em condições de cansaço, frustração e tensão, que resultam em um desempenho inferior. Os bugs difíceis, situados encre áreas, tendem a circular por uma equipe de desenvolvi1nento tardiamente no cronograma (uma espécie de bataca quente de bug). U1n programador exa1nina um desses bugs, percebe que é resistente e, diante da pressão de seu outro trabalho, passa o bug para outra pessoa que possivelmente assumirá a responsabi lidade por ele. Como Weinberg escreve, "os problemas não são solucionados, eles simplesmence circulam". Até 1nesmo os melhores programadores sofrem dessas cencações naturais, de vez e1n quando.

A tendência básica de arrasar um trabalho difícil ra1nbém se aplica à detecção de bugs - 1nesmo que sua causa não seja psicológica. Os defeitos mais difíceis de sere1n detectados ou que aparece1n tardian1ente e1n u1n cronogra1na, costu.mam ser os mais complexos5 (como mostra a Figura 15-5). Para os bugs complexos n1as de baixa prioridade, esse aspecto não é muito imporcance, 1nas para os de alca prioridade, essa tendência é un1 problen1a grave. Esses bugs exigem

ESTRATÉGlA DE FINAL D E ]oco 315

não sornente mais tempo do que a média para sere1n encontrados, como també1n para sere1n corrigidos. Os dois caminhos de linha reta indicados na Figura 15-4 estão incorretos: a aproxirnação de uma data e1n um projeto é quase assintótica (curvo) nos resultados, e parece mais perto do que mostra a Figura 15-6. A equipe pode estar trabalhando canto quanto antes, rnas os resultados - em termos de avançar na direção das metas - declinarão. Quanto mais perto você estiver de u.m compromisso, tanto mais isso se verificará.

Tempo para detectar ou corrigir bugs

@ Complexidade do bug

FIGURA 15·5. Os bugs mais resistentes tendem a ser descobertos ou corrigidos posteriormente, no cronograma. Isso s ignifica que o ângulo da abordagem não é uma linha reta, mas uma curva ponderada contra o avanço (consulte a Figura 15-6).

Trabalho restante

@ Tempo

FIGURA 15-6. Um quadro de ângulo de abordagem genérico mas realístico, presumindo um nível de esforço constante por parte da equipe.

Guia rudimentar para corrigir ângulos de aproximação

O ângulo de aproximação para a conclusão de marcos ou projetos não é um 1niscério. Co1no qualquer outra tarefa relacionada ao cronograrna (consulte o Capítulo 2), determinadas considerações contribuem para a precisão de um ângulo previsto. Eis os fatores básicos a serem considerados:

• Examine o desempenho anterior da equip e e do projeto. Para planejar o ângulo, verifique a eficiência con1 que a equipe se conduziu no final do jogo nos projetos anteriores de tipo semell1ante. Em projetos de diversos marcos, observe as curvas dos marcos anteriores, planejadas versus reais (não se iluda: use o plano original e o último cronograma real). Suponha que as coisas serão mais difíceis no marco que está planejando do que nos anteriores, apesar do que você pensa. Se não tiver dados de referência para o ângulo, o que o faz pensar que não está apenas supondo? Se tiver que supor, suponha de modo conservador.

316 A.ARTE DO G ERENCIAMENTO DE PROJETOS

• Faça estimativas adequadas. O ângulo é apenas 1nais outro ripo de tarefa de esri1nariva do cronogra1na. Reúna as pessoas adequadas na sala, divida o trabalho restante em tarefas, discuta os riscos e as premissas e chegue a esri1narivas. No míni1no, isso tornará a abordagem final u1n esforço da equipe, no qual as pessoas se sentirão envolvidas no processo e definindo, juntas, o ângulo. O moral funcionará a favor e não contra o ângulo.

• Prepare-se para uma curva lenta, não para uma linha reta. Mesmo sem quaisquer dados, considere que a taxa de evolução é retardada à medida que a contagem de bugs diininui (consulte a Figura 15-6). Suponha que o t.rabalho ficará 1nais árduo, com a aproximação do prazo. Crie gráficos e quadros co1n curvas que declinem acentuadamente para o final.

• Não beba o Kool-Aid'. É fácil criar quadros. Você pode colocar a linha onde quiser, sem qualquer referência com a realidade, e pode até convencer os outros de que existe algutna lógica por t rás das linhas desenhadas. Pense no piloto desse avião: você pilotaria este avião neste ângulo, rendo em vista o que sabe? Levante a bandeira vermelha; seja o delator. Proteja a sua equipe contra uma aterrissagem forçada. Se sua abordagem for 1nuico conservadora, o pior que pode acontecer é você tenninar à frente do cronograma, enquanto se for muito agressivo, rodo o ripo de coisas diabólicas acontecerá.

• Faça unia caixa preta. No n1Ínin10, verifique se os dados de dese1npenho real foratn obtidos (consulte a próxitna seção). En1 seguida, após a aterrissage1n forçada, você terá a prova do que deu errado, e poderá fazer uma argumentação forre para a inclusão de ajustes no próximo projeto ou marco.

Elementos de avaliação

Rastrear o andamento é muito importante no meio-jogo e no final. Quanto maior for a equipe, tanto mais difícil será tornar visível o estado do projeto. Para fazer correções ou ajustes no curso (consulte o Capítulo 14), é necessário conhecer o estado do projeto para diagnosticar os sintomas e prever como o projeto responder;í aos ajustes.

As avaliações uülizadas, sejatn quais fore1n, devem estar visíveis para a equipe inteira. No Capítulo 14, sugeri que os irens de trabalho são os 1necanismos de rasrrea1nenco mais importantes para o meio-jogo. Aqui, examinaremos mais detalhadamente oucras avaliações úteis para o 1neio-jogo, mas nos concentraren1os no rastreamento do final.

Para o final do jogo, você pode usar quaisquer marcadores de pontos do projeto usados anteriormente; basta verificar se a avaliação importante recebeu o destaque adequado (elimine as avaliações que não significam mais grande coisa, como os irens de trabalho) . O 1narcador de pontos deve ficar e1n u1n corredor visível e pode ser rão simples quanto um grande quadro branco arualizado freqiienre1nenre, o u cão incrementado quanto um terminal dedicado (convenientemente localizado perto das salas de estar, cantinas ou outras áreas de tráfego incenso) que extraem os dados nlais recentes da rede.

*N. de ·r: Refresco, con1erciali:iado cm pó, no Reino Unido e c1n oucros países.

EsTRATÉGlA oE F1NAL oE JoGo 317

A compilação diária

Ao fàzer compilações do projeco rodos os dias, você força a manipulação de vários cipos de erros ocorridos até o mon1ento, em vez de prorrogá-los para frente. Qualquer un1 poderá exaininar a compilação atual e saber i1nediatan1ence o estado de evolução do projeto. Você dependerá menos de pessoas escrevendo relatórios de status ou outras atividades de trabalho desagradáveis; en1 vez disso, é sempre possível ter uma leve idéia, carregando a compilação arual e usando determinadas fi.1nções ou recursos. Talvez seja dispendioso manter uma compilação diária (e criar as ferramentas necessárias para viabilizá-(a6), mas compensa todos os custos.

Com as co1npilações diárias, os programadores (e a equipe inceira) saberão imediatamente quando um check-in danificou outros componentes, o que ajuda a manter alta a qualidade do check-in. Defina uma hora-limite todos os dias para o processamento da compilação, o que configurará uma base de código estável contra a qual será possível executar testes para verificar a qualidade da compilação. (Geralmente, esses testes diários são chamados de testes de fumaçaª: u1na referência ao reste de componentes eletrônicos, onde seriam acopladas as placas de circuito, para verificar se algurna peça realrnente esfurnaçou.) Depois dessa hora-limite, os check-ins na árvore de orige1n constarão apenas na compilação seguinte.

Para cada compilação, deve haver u1n conjunto de testes para determinar a sua qualidade. Bastarn três classificações - boa: passou em todos os testes; 111ista: passou em alguns testes; ruirn: passou em poucos ou etn nenhun1 reste. Os bugs específicos identificados co1no a causa de uma fi1lha no reste deve1n ser anunciados nas inforrnações da compilação e devem receber urn tratarnenco de alta prioridade.

Esses testes de qualidade da compilação (uma espécie de testes de verificação da compilação ou BVTs (biúld-veri:fication tests) devem constar no cam inho para os critérios de saída do marco. Na fase inicial do marco, esses restes devem ser simples em relação aos critérios de saída; por exemplo, pode-se aceitar ter apenas uma "boa" compilação por se1nana. Entretanto, à medida que a equipe se aproxirnar da conclusão do recurso, os critérios devem ser superiores. Corn compilações diárias e testes de qualidade, você terá sempre uma avaliação da qualidade e uma maneira de como controlá-la.

Gerenciamento de bugs/defeitos

Na conclusão do recurso, o trabalho restante que deve ser feito antes do térrnino deve ser desviado para o banco de dados de bugs. Esta aç,'ío fornece urn siscetna de controle e avaliação ao projeto. O sistema usado para rastrear bugs pode ser simples, mas precisa existir e todos deverão usá-lo. Se alguns programadores tiverem siste1nas preferidos para rastrear seu trabalho, e rodos esses siste1nas forem diferences, será irnpossfvel apresentar um controle ou uma avaliação no nível do projeto ao longo do andan1ento. Geraln1ente, quando a equipe faz u1na transição a partir da conclusão de un1 recurso, algué1u tem que insistir muito cotn as pessoas para que insiratu no sistema os itens que cê1u rastreado por conta própria.

*N. de T'.: 1e sce de fun1aça; ran1bém conhecido con10 cesre de regressão.

318 A.ARTE DO G ERENCIAMENTO DE PROJETOS

Adquira o hábito de perguntar "Qual é o número do bug dessa ocorrência?" se1npre que surgirem problemas. Se dissere1n que não há nenhu1n, encerre a conversa até que o bug cenha um número. Pode ser u1na coisa tirânica, mas funciona a favor do projeto. Os dois minutos necessários para criar um nún1ero de bug compensam muito sob o prisma do projeto. É bom que as pessoas façam um rastreamento por conta própria se isso não afecar a con1pilação ou a base do código; você não quer que o sistema de bugs fique atolado de bugs que são lembretes pessoais ou trivialidades do tipo listas de coisas a fazer. (Ou se você concordar, verifique a presença de um ripo de bug específico para esse 1narerial, para pennirir a sua filtração em relatórios e consultas.)

A título de referência, todos os bugs devem ter pelo menos as seguintes informações. Ignore esta seção se você já tiver um sistema para bugs satisfatório. Você pode usar vários tipos de informações diferentes no rastreamento de bug.r, mas pela minha experiência, estes são os principais atributos necessários para gerenciá-los de 1nodo eficiente:

• Prioridade - Mantenha o 1náximo de si1nplicidade possível. Prioridade 1 -Correção obrigatória. Prioridade 2 = Correção na prirneira oportunidade. Prioridade 3 = Desejável, mas improvável. Prioridade 4 = Comicamence improvável.

• Gravidade - Qual é a gravidade do i1npacto do bug? Gravidade 1 = Perda de dados, queda do sistema ou proble1na de segurança. Gravidade 2 = As principais funções não funcionan1 como previsto (especificado). Gravidade 3 = As funções menos in1porrantes não funcionam con10 previsto (especificado). A gravidade é diference da prioridade. Por exemplo, pode haver um erro de script de queda de navegador, que é grave (Gravidade 1), mas con10 ocorre apenas se você digitar "PAPAYA!" sete ve:zes, con1letras1naiúsculas, no can1po do email em un1a página de registro na Web, é de baixa prioridade (Gravidade 1, mas Prioridade 4).

• Atribuído a - Todos os bugs devem ser atribuídos a uma pessoa. É possível atribuir os novos bug.r a um alias, mas parte do objetivo da triagem (discutido mais adiante) é atribuir bug.r a uma pessoa, assim que possível. Para permitir que os bug.r sejam inseridos das versões alfa ou beta, crie um valor chamado "acivo" ou "hora da festa", ao qual os bug.r poderão ser atribuídos. Os bugs atribuídos a esse valor poderão ser submetidos a uma triagem e enca1ninhados às pessoas pertinentes, mais tarde.

• Reprodução (um ripo de repro) - A seqüência de ações que permire1n que algué1n 1nais reproduza o bug. Talvez seja o ca1npo 1nais importante para a qual idade do bug. Os casos de n1á reprodução desperdiça1n o tempo da equipe, obrigando os progran1adores a investire1n ruais energia do que a necessária só para identificar qual é o bug. Os bons bugs têm etapas de reprodução curtas e simples.7

• Área - E1n projetos 1naiores, os bugs deve1n ser classificados pelo local onde ocorre1n no projeto (a área). Isso pennice rastrear os bugs por componente, não apenas por desenvolvedor.

• Aberto por - Nome da pessoa que abriu o bug, com informações de concato.

• Status - Um bieg pode estar apenas em quatro estados: ativo, corrigido, resolvido ou encerrado. Ativo significa que o bug não foi corrigido e ainda está

EsTRATÉGlA oE F1NAL oE JoGo 319

sendo considerado. Corrigido significa que o programador acredita que ele foi corrigido. Um bug só se cerna resolvido quando a pessoa que o abriu concorda que ele foi corrigido ou concorda em prorrogá-lo. Encerrado indica que a ação do bug renninou e que a equipe de tesce confirmou o seu fim.

• Resolvido como - Um bug resolvido significa que ele não esrá mais ativo. U1n bug pode ser resolvido de várias maneiras: corrigido, prorrogado para o marco ou versão seguinte, duplicado de um bug existente ou não será corrigido.

• Tipo - Há dois tipos importantes de bugs: defi~icos e regressões. Um defeico é um bug comum, bem antigo. Uma regressão é um bug corrigido uma vez, mas que ressurgiu com um efeito colateral negativo de alguma outra mudança.

• Triagem - Este campo indica se o bug foi filtrado e quaJ foi o resultado. Periodicamence, os únicos bugs que devem ser corrigidos são os submeridos a u1na triagem e 1narcados co1no aprovados. Sendo assim, este carnpo ten1 geralrnente três estados: aprovado, recusado ou sob investigação.

• Título - Todos os bugs deve1n ter um título descritivo de u1na linha, para que outra pessoa renha tuna idéia do problen1a.

A 1naioria dos sistemas de rastrea1nento de bugs fornece u1n registro de cada bug. Isso permice saber quem fez quais 1nudanças em que bug, e quando isso ocorreu. Esse recurso é prácico se as decisões comadas em relação aos bugs específicos forem disputadas. Também previne as pessoas dos vários tipos de comportamento enganador no modo como os bugs são gerenciados.

O quadro de atividades

No nível do projeto, o uso mais eficiente dos bugs é para rastrear as tendências em sua dececção, avaliação e resolução. Ao examinar as tendências ao longo do projeto, você pode fazer t rês coisas: avaliar o andamento, ter uma idéia de qua.is problemas no nível do projeto podem existir e desenvolver um horizonte de ações correcivas desses p roblemas.

Assi1n que existir u1n banco de dados sirnples de bugs, a armadilha é a grande fàcilidade de gerar V<1rios tipos de gráficos e tendências e fazer tipos co1nplexos de an<ilise.8 Evite coisas tnuito elaboradas - os cipos mais básicos de gráficos são os ma.is importantes. Consulcas e tendências avançadas pode1n ser úteis para ajudar a responder perguntas específicas, mas freqüente1nence provocam distrações ("Atenção! Nossa taxa de correção de bugs corresponde ao índice pluviornétrico na Espanha!") . Antes de perder rernpo gerando um novo tipo elaborado de relatório, fuça a si mesn10 as seguintes perguntas:

l. Quais perguncas podern ser respondidas ao exarninar este gráfico?

2. De que modo as respostas a estas perguntas poderão nos ajudar a entregar em cernpo hábil e com qualidade? Corno as respostas nos ajudarão a acender a crirérios de saída ou a n1eras do projeto específico{as)?

3. Se o número aumentar, o que isso realmente significa? t urn fator negativo? Concinua o mesrno?

4. Ao final de cada dia/semana, isso nos ajudar-á a perceber a proximidade da conclusão?

320 A .ARTE DO GERENC[AMENTO DE PROJETOS

Manter a simplicidade

É possível acompanhar as tendências mais simples e Íinporcantes por meio de um quadro de atividades. Em cada dia do projeto, os seguintes dados estatísticos são extraídos do banco de dados de bug.r e exibidos como gráficos de linhas:

• Ativo - O número total de bug.r ativos não-corrigidos ou resolvidos.

• Recebido - O número coral de bugs abertos em determinado dia (antes da rriagem}.

• Corrigido - O número cocal de bugs corrigidos e1n determinado dia.

Na Figura 15-7, é possível ver as rendências básicas de arividades para um projero de ta1nanho médio, nos primeiros dias do final de jogo de um 1narco. I-lá um número alto de bug.r ativos e uma taxa de bugs recebidos relariva1nente alta. Indo para o 111eio do gráfico (da esquerda para a direita}, inicia-se um teste importante e a taxa de bugs recebidos au1nenra consideravelmente (assin1 con10 o nt'1mero coral de bugs}. Finalinence, após o cesce, a taxa de bugs corrigidos é 111aior que a taxa de bugs recebidos, e o número rocal de bug.r arivos começa a cair. Nesse gráfico simples, é possível ver as principais relações: entrada versus corrigidos define a principal tendência da conclusão do trabalho.

450

400

350

300

250

200

150

100

50 ~-...:.-----­-----.......... -------

~-.::=Tu=m=p=º=~=m=d=~=s=) ===-rt> FIGURA 15-7. Um quadro de atividade básica de bug.

Avaliar as tendências

--- Ativo

--- Recebido

- - - Corrigido

Todos os gráficos ou técnicas de análise revelarão um dentre dois aspectos: há mais trabalho a fazer e há menos rrabalho a ser feiro. Por exemplo, se o número cocal de bug.r ativos continuar aumentando, isso significa que a pilha de trabalho está aumentando 1nais rapidamente do que sendo esvaziada, e ainda estão sendo detectados novos problemas a u1na alra taxa. Como alternativa, se o nún1ero total de ativos tender a declinar, o trabalho estará sendo concluído mais rapidamente do que a detecção de novos problemas. Em ambos os casos, o objetivo da análise de tendências é saber, en1 relação a um atributo específico, e1n qual dos três estados o atributo se encontra:

E.sTRATÉGIA oE F1NAL oE Joco 321

• As coisas estão p iorando - Isso é cocalrnence aceicável e até desejável, nas primeiras fases de tesce de u1n projeto. Se resces imporcantes estiverem ocorrendo no 1no1nento ou se forain concluídos recenren1ente, é narural que o nt'1mero cocal de buf! aun1ence 1nais rapida1nence do que a equipe de programação pode lidar.9 Às vezes, a integração de componentes pode ocorrer depois do previsto, atrasando a detecção de buf! 111ais do que o previsto no processo. O imporcance é saber por que as coisas estão piorando, quanca piora está ocorrendo e o que deve ser feito (se for o caso) para mudar a tendência.

• As coisas continuan1 iguais - Como os velhos buf! esrão sendo corrigidos e os novos estão sendo detectados paralelamen te, é totalmente possível que u1na equipe tenha a impressão de que não está chegando a lugar algum, apesar do imenso esforço . . As taxas de bug> ativos podem se estabilizar, mesmo que os programadores estejam mandando bala. Se em algum momento urna avaliação­chave estiver pairando, examine as entradas e saídas que contribuem para a avaliação, para saber o que deve acontecer para dobrar a esquina e quando isso acontecerá, ou o que deve ser feiro para que isso aconteça. E. importante inforrnar esse aspecto à equipe. Muitos progran1adores entram e1n pânico quando estão trabalhando a todo vapor, pois não entendem por que o projeto não escá avançando (ou pior, por que ele escá se dissipando lencamence).

• As coisas estão n1elhora11do - Quando as cendências estão favoráveis, é imporcance avaliar a velocidade de aceleração e a linha da tendência até o final do 1narco. Uma tendência posiciva pode não ser suficienre1nenre posiciva para atender aos critérios de saída. Se as tendências estiverem positivas logo no início, desconfie: todos os restes foram concluídos? Algum bug está sem criagern? A qualidade de correção de bugs é alta? Descubra o que está causando exatamente a melhoria da tendência antes de achar que é tuna boa notícia.

Avaliações úteis de bugs

Existem algumas avaliações comuns, úteis para o acompanhamento do final do jogo. Compensa encontrar uma maneira de gerar automaticamente esses dados estatísticos, de modo que se forem necessários para ajudar a tornar decisões, não se perca tempo criando uma nova consulta do banco de dados.

• Taxa de correção. A taxa em que a equipe corrige bugs. Co1no nem todos os bugs são idênticos, essa taxa é o tempo necessário para se corrigir u1n bug de complexidade 1nédia. Se a caxa de correção estiver abaixo da caxa de bug> recebidos, e todos os bugs recebidos precisarem ser corrigidos, o projeto nunca conseguirá deslanchar: haverá se1npre 1naís bugs.

• Recebidos para aprovados. Qu<Ultos dos buf! novos abertos realmente necessitam ser corrigidos e não são duplicaras de ourros buf!, ou problemas de prioridades 3 e 4? (O processo dessa determinação é a triagem; n1ais detalhes sobre este assunto na próxima seção.) Saber a proporção entre buf! recebidos e submecidos à triagem ajuda a fàzer estimativas preliininares em relação aos bugs sem triagem. E1n geral, a qualidade do bug deve declinar no decorrer do tempo: após cerro ponro, a raxa de bugs bons, substanciais, das prioridades 1 e 2 se reduzirá e depois despencará. A taxa de en rrada bruta não indicará quando isso está aconrecendo.

322 A.ARTE DO GERENCIAMENTO DE PROJETOS

• Duração de bugs ativos.Tempo 1nédio de duração da acividade dos bugs. Indica a agilidade da equipe e o modo co1no a equipe está lidando co1n a sua carga de crabalho acuai. O tempo de resposta deve aumentar à medida que você se aproxi111ar das daras de compromisso porque a equipe deve escar gerenciando menos bugs e deve estar mais agressiva na triage1n e ataque dos problemas recebidos. Se o tempo de resposta for lento, as pessoas estarão ocupadas.

• Bugs por desenvolvedor - Para equilibrar a carga de uma equipe de desenvolvimento, é necessário rastrear quantos bugs ativos cada desenvolvedor esrá acualn1ence investigando ou nos quais escá trabalhando. També1n compensa observar a porcentagem de bugs ativos atualmente atribuída aos testadores, desenvolvedores ou GPs. Os bugs atribuídos a GPs ou testadores não esrão atualmente na pipeline para correção, devem ser submetidos à triagem e redistribuídos periodicamente.

• Fault Feedback Ratio - Weinberg cha1na a taxa de regressões causada por u111a correção de bug de Fault Feedback Ratio (FFR) .1º Se cada bug corrigido acarretar dois oucros bugs, a FFR será 2,0. Segundo Weinberg, urna FFR de 0,1 a 0,3 é a taxa de referência aceitável; um valor acima indica que a qualidade deve ser apri1norada (e/ou o rit1no deve ser retardado). A maioria dos bancos de dados de bugs pern1ice a vinculação de novos bu~· aos já exiscences, viabilizando o rastrean1ento da FFR. Mas eu nunca vi isso auto1nacizado - é uma avaliação 1neramente subjeciva por parce daqueles que faze1n a triagem no projeto inceiro. (Observe que, às vezes, a correção de lun bug pode fazer co1n que os bugs ancerionnence ocultos venham à cona. Isso não deve ser considerado na FFR.)

Elementos de controle

Controlar projetos é muito mais difícil do que rascreá-los. A obtenção de dados percinentes e a sua avaliação é uma questão de dedução, mas para identificar como reagir às tendências e influenciá-las, é necessário ter intuição. Os projetos adquirem um ímpeto próprio, principalmente no final do jogo, e não podem ser direcionados canto quanto influenciados. Quando a atividade está focada em trabalhar com bugs, há várias decisões individuais sendo tomadas na equipe, e isso exige comunicações e lembretes constanres para manter os to1nadores de decisões com as 1nesn1as atitudes, pre1nissas e n1etas.

O aspecto mais conveniente a ser considerado sobre os diversos elementos de controle é a freqüência co111 que são aplicados. Em algu1nas atividades de alto nível, co1no a revisão da gerência, basca executar a ação u111a vez por mês. Em outras, como a triagem, pode ser uma atividade diária ou honiria. Dependendo do grau de controle necessário ou do nível de influência que se quer ter, os intervalos de tempo de controle são suas considerações 1nais relevantes.

Reunião de revisão

Este é basicamente um mecanismo de controle de meio-jogo. Uma revisão é quando os líderes da equipe devem apresentar o estado do projeto em relação às meras, para a a lta gerência, clientes e para a equipe inteira. A reunião de revisão

EsTRATÉGlA oE F1NAL oE JoGo 323

deve funcionar como uma função obrigacória para idencificar o que escá indo bem (e1n relação às 1necas), o que não escá indo be1n e o que escá sendo feiro em relação a isso. O fonnaco da revisão pode ser simples. Se escas perguncas forem respondidas co1n sinceridade, a discussão pode demorar u1na hora ou mais. As nlelhores revisões e1n que parcicipei foram direto ao assunto. I-lavia n1aturidade suficiente na sala, as omissões ocorrian1 voluncariamente (não eram dissimuladas), as solicicações de ajuda eran1 acendidas (não eram ridicularizadas) e era dada arenção às coisas mais imporranres (não ao que fazia com que as pessoas parecesse1n bem ou se senrissem felizes).

A discussão da revisão deve obrigar a equipe a avaliar as metas, os cronogramas, as tecnologias e as funções, dentro da realidade. Nada deve ficar de fora em uma revisão. Todo problema afetando o projeto deve ser aberto à discussão. Por esse motivo, a reunião de revisão é um elemento de controle e não apenas um acompanhamento, porque propicia um fórum para líderes e altos gerentes discutirem os ajustes que deve1n ser feitos e1n qualquer aspecco do projeto.

A qualidade de u1na revisão depende muico de quern tern poder sobre o projeco. As melhores revisões englobatn discussões sinceras sobre o que escá aconcecendo, descacando o conhecimento dos problemas e desenvolvimento de soluções, em vez de direcionar e se esquivar da culpa. Por isso, as reuniões de revisão devem ser pequenas. Un1 resu1no da discussão e os slides ou 1nareriais usados na apresentação deve1n ser apresencados à equipe inteira, em um fórum separado, posceriormente. (Os líderes devem ficar à voncade con1 a responsabilidade por suas equipes, principal1nence quanto à inceração co1n a alca gerência.)

As equipes devem rer revisões agendadas em intervalos periódicos, ao longo de cada marco. A data das reuniões deve ser de conhecimento póblico, assim como uma reunião da equipe deve ocorrer em seguida. Os projetos com duração de vários meses deven1 ter uma revisão mensal. Os projetos com duração de várias semanas devem ter uma reunião semanal ou quinzenal. Quanto nlais freqüentes forem as reuniões, tanto mais informais e propícias poderão ser.

Revisões de clientes

No caso de uma equipe contratada ou com clientes internos, as reuniões de revisão podem funcionar corno uma maneira de receber um feedback direto de seus clientes. A 1naioria dos conselhos aqui descritos ainda se aplica. Um aspecto adicional é que você nunca deve depender dessas reuniões co1no fonte ónica de feedback dos clientes. Os intervalos encre as reuniões se1npre serão muito longos, e a fonnalidade das reuniões pode dificultar o aprofundan1enco ou a discussão de proble1nas con1plexos.

U1n aspecco importance do XP é o faro de incencivar um represencance do clience a parricipar direcamenre no desenvolvimenco do software (Extreme Progra1nming Expfained, pág. 83). É alra1nence recomendável solicitar ao clience que destine pelo n1enos uma pessoa para exercer essa função. A pessoa e1n questão deverá usar as compilações diárias e desenvolver relacionamentos con1 os progran1adores e seus líderes. Isso permice que você e sua equipe obtenham um feedback diário ou horário sobre os problemas, e não semanal ou mensal. Definir

324 A.ARTE DO GERENCIAMENTO DE PROJETOS

esse relacionarnenco pode ser cornplicado na primeira vez (consulce a seção "Definindo funções" no Capículo 9), mas setnpre cotnpensani para co1nar decisões de projeco 1nais inceligences e deixar os cliences mais felizes.

Triagem

Todo processo em que você usa un1a lista de problemas e acribui a esses problemas uma ordem de prioridade é um processo de criage1n. O que corna a triagem real diferente dos oucros tipos de atribuição de prioridades é o faro de você estar lidando com um fluxo de encrada conscante de novos problemas que precisam ser entendidos e priorizados em relação a outras questões. A triagem ocorre em todo o meio-jogo, sempre que houver uma data intermediá.ria de um compromisso que precisa ser cumprida, e uma métrica de qualidade dos critérios de saída. Contudo, a triage1n torna-se lllna tarelà primária para a equipe durante o final do jogo, geralmente ocupando uma porcentagem considerável do trabalho diário dos GPs e de outros profissionais.

O objecivo da triagem é gerenciar a pipeline da engenharia (descrica no Capítulo 14) de modo a 1naximizar a importância do trabalho realizado para os cricérios de saída do marco. Para fazer isso con1 êxito, são necessárias crês caref:1s:

• Sanitizar - A importância dos novos bugs surgindo se1npre variará. Alguém deve revisar os novos bugs e obter as inforn1ações neles contidas sobre o nível de qualidade, de 1nodo a acribuí-los a u1n progratnador, para que ele os investigue e corrija. Alguns bugs exigen1 investigação do programador, mas a n1aioria das fi ltragens abrange tarefas triviais: preencher campos vazios (gravidade, prioridade etc.), aprimorar os casos de reprodução, verificar se não é uma duplicata de um bug já existente etc. Geraln1ente, são tarefas menores: ligações telefônicas, en1ails e dedicar algum tempo com a compilação específica para rastrear as informações.

• Investigar - Após a sani tização dos bugs, haverá problemas mais densos q ue poden1 exigir exarne antes da tomada de decisões. É necessário corrigi-lo? Viola o espírito ou o documento de requisitos/especificações? Que componente causa esse problema e o que englobaria a sua correção? Talvez seja necessário responder a diversas perguntas, para tomar urna decisão sobre o destino de u1n bug. Algumas dessas considerações são técnicas, oucras não.

• Priorizar - Após a sanitização e invescigação, os bugs podem ser priorizados e inseridos na pipeline, no grau de i1nportância adequado.

O que dificulta a criagem é que, para realizar co1n eficiência qualquer uma dessas três tarefas, é necessário mais conheci1nento do que urna pessoa isolada possa ter. Quanto maior for o projeto, tanto menor a probabilidade de que u1na única pessoa possa efetivan1ente fazer a triagen1 sozinha. Sendo assim, para a maioria das equipes na maioria dos projecos, a rriagen1 é uma atividade de grupo. No início, seria bom que as pessoas fizessem a triagen1 de seus próprios bugs, entretanto, mais adiante no projeto, o foco se deslocará para os pequenos grupos e equipes subordinadas. Eis por que os bugs devem ser

ESTRATÉGIA OE FINAL O E )oco 325

organizados ern corno de áreas específicas do projeco (consulce a seção ancerior "Gerenciamenco de bugsldefeicos"). Facilica para os pequenos grupos de pessoas responsáveis pela área em quescão fàzeretn uma reunião e uma triagem independenten1ence do restante da equipe.

Mais adiante, perto do final do jogo, quando toda decisão de bugs for verificada, deverá ocorrer um esforço de triagem no projeto inteiro, realizado por um grupo central de líderes de equipes (consulte a Figura 15-8; discutiremos este assunto na próxima seç.'io "Equipe bélica"). Por enquanto, é i1nportante identificar os dois ripos básicos de triagem: diária e dirigida .

• • • • Triagem individual

• • Triagem de área

Tempo • Equipe bélica

FIGURA 15-8. A triagem torna-se centralizada à medida que o final do jogo se aproxima.

Triagem diária/semanal

A triagem diária é um processo de rotina para lidar com os bugs recebidos e ativos. Dependendo do cronograma, talvez seja necessário rea.lizar esse processo un1a vez por semana, uma vez por dia ou por hora. Quanto mais avançado estiver o final do jogo, maior deve ser a freqüência da triagem.

O objetivo da triagem diária é simples: manter as coisas íntegras. A equipe de progra1nação é a trajetória crítica para o final do jogo do p rojeto, e a triage1n é a única maneira de verificar se a respectiva pipeline está sendo usada com freqüência . Todo bug recebido deve ser sanitizado e comparado com o grupo de bugs existente, de preferência antes de aterrissarem na plataforma de um programador individual.

Algumas veles, é mais conveniente (em termos de eficiência da equipe) que uma pessoa tome a iniciaciva de fazer a triagern diária e1n cada área. Presumindo que os programadores e testadores estipulem os critérios, u1na pessoa pode ficar responsável por sanitizar os novos bugs, rnarcando as duplicatas e ajustando as prioridades dos bugs recebidos. Os GPs são bons candidatos para essa carefa, pressupondo-se que seja1n suficiente1nente técnicos para entender os problemas e tomar as decisões básicas relacionadas aos bugs.

De outra forma, a criagem deve ser feira em uma pequena reunião, co1n representantes do desenvolvimento, teste e o GP. Se outros especialistas na equipe forem necessários - como rnarketing, design ou usabilidade - poderão ser chamados, conforme a necessidade. As reuniões devem ser curtas. Tudo o que não puder ser resolvido em n1inutos deve ser atribuído a um progran1ador para ser investigado.

O campo de triagern deve ser ajustado para os bugs após a respectiva triagem . Isso dará ao projeto uma perspectiva adicional dos dados dos bugs, uma

326 A ARTE DO G ERENCIAMENTO DE PROJETOS

vez que você poderá posreriormenre separar a guancidade de bugs já submeridos à rriage1n (bugs bons conhecidos) do coral de bugs arivos (bugs de qualidade desconhecida).

Triagem dirigida

A criagem dirigida é um esforço focado para acender a uma 1nera específica. Essa triagem é realizada adicional1nence à rriagem diária. A criagem dirigida é um controle, no nível do projeto, para ajudar a impulsionar as coisas e aun1encar a imporcância dos gráficos de bugs e da análise de tendências. Eis alguns motivos comuns para a triagem dirigida:

• Quando a proporção entre bugs submetidos à triagem/ativos é baixa. Se existirem 500 bugs ativos e apenas 200 passaram pela triagem, será impossível saber o significado dos 300 bitgs restantes. Todos eles podem ser rrava1nencos de siste1na da prioridade 1 ou podem ser duplicaras: não se cem idéia. Uma rriagern dirigida reria o objerivo específico de eliminar rodos os bugs que ainda não passaram pela criagem até determinada hora (meio-dia de amanhã) . Se este for um problema crônico para uma equipe, deverá existir u1na n1eta de nenhum bug ativo se1n triagem ruais anrigo que um período de tempo especificado (24 horas).

• Quando os critérios d e saída mudare1n. Se os líderes da equ ipe ou a gerência decidirem que os critérios de saída deve1n ser ajustados, talvez ren1ovendo ou adicionado un1a condição, a triagen1 será a única maneira de atualizar o projeto com essas mudanças. É co1num usar novos critérios de saída co1no un1 modo de 1nudar o ângulo de descida, deixar de considerar cercas classes de bugs para au1nenrar a segurança do ângulo (mas degradando a qualidade do processo).

• As contagens não encerradas são altas. Após a sua correção, o bug deve ser definido com o status = resolvido, e deve ser reatribuído à pessoa que o abriu para verificar se realmente fo i corrigido. Uma porcentagem desses bugs calvez não renha sido corrigida corretamente. Se esses bugs permanecerem não encerrados, haverá uma bolsa de bugs, que precisam ser corrigidos, não informada no número tocai de bugs ativos. Dependendo do sistema de rastrea1nento de bugs, calvez exista1n outros locais onde os bugs possa1n se ocultar. É preciso orientar periodican1ente a equipe a descarregá-los.

Equipe bélica

A medida que o projeto se aproxin1ar de seu ténnino, a distribuição da autoridade deve ser centralizada. Oiferenten1ente do design e programação de recursos, que podem ser razoaveln1ente distribuídos pela equipe, não há espaço para erros ao se aproxin1ar do final. Todas as decisões se tornam cada vez mais importantes, com riscos rnaiores, significando que são garancidos

E.sTRATÉGIA oE F1NAL oE Joco 327

concroles 1nais eficientes. O termo da Microsoft empregado para essa centralização do controle é a chamada equipe de guerra ou bélica (to1nado emprestado, suponho, do cenno 1nilirar sala de guerra, onde os líderes se reúnem para co1nar decisões imporcances) . Un1 pequeno grupo de líderes de equipe corna-se a ramificação executiva do1ninante do poder, à medida que os prazos estão vencendo. Em pequenas equipes, talvez não seja necessária un1a n1udança formal no poder, 1nas nas equipes médias e grandes, essa mudança é fundamental. Ela eleva o padrão em toda ton1ada de decisão e fornece à equipe uma função de obrigatoriedade, no sencido de que o jogo está tenninando.

A reunião da equipe bélica real é simples. Basta uma sala de conferência, um membro superior de cada equipe (líder da programação, de teste e o GP ou outros líderes parceiros, e possivelmente o gerente sênior do grupo), e um computador acoplado a un1 grande n10nicor para que a sala inteira possa ver o bug ou problema e1n discussão. Para un1 problema ser aprovado pela equipe bélica, todos os membros seniores deverão entrar e1n acordo (algun1as equipes prefere1n uma maioria de dois terços ou passar o poder de veco para os 1nembros da equipe bélica). A agenda da equipe bélica é decidida rodas as 1nanhãs e qualquer problema pode ser inserido na agenda. Co1no um tribunal de júri, tudo o que aceitarem ou recusarem terá prioridade sobre o rescance da equipe. As reuniões da equipe bélica deve1n ser aberras à equipe, e deve1n cer prioridade as pessoas que apresencare1n DCRs específicas (consulte o capítulo anterior) ou propusere1n bugs para revisão.

A equipe bélica deve estabelecer um padrão 1nuico alto. Todos os que se apresencaren1 diante de uma equipe bélica despreparados ou sem respostas para perguntas básicas (Isso acende a quais critérios de saída? Que regressões isso acarretaria? O programador e o cesrador concordam com essa correção?) devem ser convidados a sair e voltar quando estiverem prontos. O ten1po da equipe bélica é precioso porque o tempo da equipe é precioso. Todo GP e programador deve1n ser alran1ente motivados a ter sua história avaliada e fortemente apoiada antes de pedir a aprovação da equipe bélica. Essa pressão gera um incentivo natural para a equipe inteira pensar baseante sobre os problemas por conta própria, antes de os levarem à equipe bélica. (Mas tenha cuidado: as reuniões da equipe bélica podem ser altamente carregadas e h<í muita oportunidade de acontecerem grandes tribunais de julga1nentos e un1 desperdício de tempo egocêntrico. O gerente do grupo deve interceptar esse ripo de co1nporramenro no início.)

A equipe deverá cer um aviso administrativo sobre em quê e quando a equipe bélica entrará en1 ação. Na Figura 15-9, aparece a platafonna básica do que a equipe bélica deve aprovar. O objetivo é alcançar u1na centralização gradativa da autoridade com compromissos públicos para quando essas 1nudanças ocorrere1n. A aprovação das DCRs é geralmente o pri1neiro uso da equipe bélica porque pode1n ocorrer logo no início, durante o 1neio-jogo. Mais adiante, quando for necessário rastrear firmemente o número cocal de bugs, a aprovação para colocar bugs na pipeline da programação passa para a equipe bélica (os bugs anteriormente aprovados geralmente devem ficar de fora). Por último, nas sen1anas ou dias de encerramento, a equipe bélica revisa rodos os bugs recebidos e o controle do projeto é efetivamente centralizado.

328 A ARTE DO G ERENCl1\MENTO DE PROJETOS

Trabalho restante

Todas as DCRs aprovadas pela equipe bélica

Todos os novos bugs aprovados P.ela equipe bélica

Triagem central da equipe bélica

@ Tempo

FIGURA 15-9. A autoridade da equipe bélica aumenta à medida que o final do jogo se aproxima.

As reuniões da equipe bélica podem começar semanalrnente, mas logo deverão mudar para reuniões diárias de rneia-hora ou de urna hora. A própria equipe bélica se encarregará de fazer co1n que essas reuniões iniciem e terminen1 pontualmente (alguém deve esclarecer a pauta antes do início da reunião). Se o objetivo é tomar boas decisões e1n relação aos critérios de saída e aos objetivos, é possível examinar várias DCRs e fazer a triagem de vários bugs em 60 ou até mesn10 em 30 1ninutos. O segredo é evitar um microgerenciamento do final do . jogo.

A equipe bélica não precisa conhecer os meandros de todo bug ou problema. Ao contrário, basta garantir que as decisões tomadas ocorram para o melhor interesse do projeto, que as perguntas certas tenham sido bem feitas e respondidas, e que o padrão certo seja estabelecido para a utilização do tempo restante. As equipes bélicas deixarn de ser convenientes quando os líderes não confiarn ern suas equipes. Se urn problerna for realmente rnuito ruirn, dever<Í ser isolado para uma discussão co1n um único rnembro da equipe bélica, e no dia seguinte deverá ser reapresentado de rnodo rnais eficiente.

Entre as meras do projeto, critérios de saída, decisões para definições de prioridades de bugs e comunicações da equipe, há 1nuiras oportunidades de direcionar a ton1ada de decisões para a equipe. Ocasionalmente, o processo de aprovação da equipe bélica pode ser autornatizado, con1 forrnulários da Web permitindo que os 1ne1nbros da equipe bélica aproven1 itens re1norainente, de acordo com o seu te1npo. Seja esperto. Encontre 1naneiras de evitar que a equipe bélica seja u1n gargalo desnecessário ou se1n finalidade.

Em geral, quanto menor a quantidade de problemas gerenciados pela equipe bélica, tanto mais eficiente terá sido o trabalho da alta gerência de serviços ao planejar, executar e liderar a equipe ao longo do projeto. Se as reuniões da equipe bélica forem normalmente maratonas brutais de três horas, a liderança terá falhado de alguma maneira e há lições a. serem aprendidas para o próximo projeto.

O fim do final do jogo

O período de encerramento de um projeto de engenharia é difícil e enlouquecedor. Jim McCarthy, em Dynamics ofºSoftware Devefopment (Microso~ Press, 1995), refere-se a esse processo como trabalhar com gelatina. Sempre que você corrigir urn bug, estará efetivamente tocando no grande cubo de gelatina

E.sTRATÉGIA oE F1NAL oE Joco 329

rnais urna vez, e leva algurn rempo para que ele pare de crerner. Quanco mais roques você der, canco maior será a variância ern seu modo de se agicar, e canco mais complexa será a interação encre as ondulações dessas mudanças. Um site ou produto de software é basican1ente un1 enorine conjunto de partes móveis altamente interconectadas, e sempre que você mudar uma delas, acarretará todos os tipos de novas ondas possíveis de comportamento através desse conjunto. Diferente1nente da gelatina, com o software não é fácil saber quando a agitação parou. O código não é cransparence. Somente acravés dos processos de asseguração de qualidade e do exarne manual cricerioso das compilações, você conhecerá o efeito dessa pequenina mudança.11

Isso significa que o verdadeiro fim de um projeto é, em grande parte, um jogo de espera. Horas e horas são gastas examinando novos relatórios de bugs ou problemas, e verificando se atendem ao padrão de agitação da gelatina novan1ente. Nas equipes maiores, a equipe bélica se encarrega dessa tarefa. No que pese que o restante da equipe deva continuar observando o surgirnento de novos problemas e usando as compilações mais recentes, todos podern contribuir de alguma maneira para o jogo de espera.

Quando surgir urn bug que cornpense agitar a gelacina, cudo deverá entrar na engrenagern novarnence. A equipe bélica examinará o processo de liderar a equipe (ou, mais especificamente, o progra1nador) para entender suficientemente o problerna de modo a fazer uma mudança cirúrgica. A suite de restes e condições deve ser reexecutada para verificar se tudo está exacamence con10 antes, exceto uma pequenina coisa que precise ser alterada. É um processo muito escressance. Diferentemente da carga cocal do 1neio-jogo ou da diversão e1n localizar bugs no início do final do jogo, a tensão nos úlrimos dias não pode ser aliviada, impondo uma grande carga de trabalho. Tudo é muito pequeno e a pressão não cem para onde ir.

Nesse processo, existem avaliações e mornencos significativos diferences, nlas não contribuem muito para mudar a natureza do trabalho. São apenas marcos intermediários ao longo do percurso para a liberação. No nlínimo, esses marcadores quebram a monotonia estressante do trabalho terminal do final do jogo.

• Zero Bug Bounce. Quando o número cocal de bugs ativos e aprovados (pela equipe bélica) chegar a zero, diz-se que a equipe deu o ZBB (Zero Bug Bounce -Salco de Zero Bug). Esse processo é charnado de salto porque assim que o bug seguinte é recebido, a equipe não está mais com zero bug. Exiscem algumas teorias preferidas quanto à distância entre o ZBB e a versão real , mas nenhurna delas é suficiente1nente force para ser incluída aqui.

• Zero resolvido. Os bugs resolvidos podem estar ocultando problernas que a equipe desconhece. Até ser encerrado (e verificado), não há certeza absoluta de que un1 bug foi realrnente corrigido como deveria ser. Atingir zero bug resolvido e zero ativo significa que o projeto está realrnence em u1n esrado de possível conclusão.

Os bugs recebidos e ativos justificam as avaliações deficientes nesse esnígio, porque estão abaixo dos critérios de consideração. Embora a equipe esteja investigando ativan1ente esses bitgs, até sere1n conduzidos à equipe bélica, não afetarão efetivamente o andamento do projeto.

330 A.ARTE DO GERENCIAMENTO DE PROJETOS

A candidata à versão (RC - Release Candidate)

A pritneira compilação de u1n projeco, que acendeu a rodos os cricérios de saída, é chan1ada de candidara à versão (Release Candidate) . Assim que essa co1npilação é feita, deve ser adicionado un1 novo critério de saída: que problen1as detectados nessa compilação RC garantirão a criação de uma segunda candidata à versão? Se não existiren1 critérios, presumindo-se que a compilação RC passe em todos os testes de verificação e de garantia da qualidade, a compilação será suportada para a Web ou colocada em CD e enrregue aos clientes.

Se existir um crirério de RC definido e a RC não passar nesse crirério, o processo de final do jogo se reperirá. A equipe bélica determina que investigação, design e implementação deve ser feita(o), a mudança é aprovada e efetuada, e o processo se repete.

No mundo do software, principalmente no inundo do software de prateleira, as RCs são dispendiosas. Freqüentemente, há testes e procedimentos pelos quais a compilação deve passar, para verificar a instalação, localização, branding e outros aspectos. Para a Web, tudo isso depende do modo como o projeto se integra a outros projetos. Pode haver u1na árvore co1nplexa se1nelhance de dependências que precisam ser gerenciadas.

Lançamento e operações

Quando uma compilação RC final é concluída, apenas uma parre da equipe comemora. Dependendo da natureza do projeto, u1na RC final pode acionar uma seqüência cocalmence nova de trabalho. As equipes de cesce e QA (Quality Assitrance - Garanria da Qualidade) calvez precisem avaliar as cargas do servidor ou outros tipos de proble1nas de capacidade, que s6 podem ser tesrados com uma compilação final. Certamente, esses probleo1as podem ser previstos, mas a fase de testes não pode iniciar antes de os bits estarem em vigor.

A maioria dos sites ou dos projetos baseados na Web disponibiliza suas versões através de uma seqüência de servidores de reste, onde diferentes condições e trabalho de integração recebem a cobertura dos testes finais. Quanto maior o número de plataformas ou linguagens o projeto precisar cobrir, tanto mais complicado será o processo de lançamento. É evidente que o tempo necessário para o lançamento correto deve ser previsto durante o planejamento inicial. Dependendo de sua organização, a carga do lançamento e das operações deve ser isolada em uma equipe subordinada ou dividida pela equipe inteira do projeto.

O pós-morte do projeto

A 1nedida que o cérmino de um 1narco ou de um projeto inceiro se aproxi1na, algué1n deve prepara a equipe para aprender com o que acabou de ser realizado. Geralmente, isso é chan1ado de fazer a retrospectiva ou p6s-1norce (referência ao termo médico para aprender co1n algo que terminou) de un1 projeto. A parte árdua dessa tarefa é que você precisa obter as informações enquanto estiverem fresquinhas nas mentes das pessoas, 1nas quando as pessoas esrivere1n prontas para

EsTRATÉGlA oc F1NAL oE Joco 331

a come1noração e o encerrarnenco, rara1nence querem voltar acrás e analisar codos os proble1nas co1n os quais acabaram de lidar. A maioria das pessoas quer seguir em frence e encerrar o passado.

É exaca1nenre aí que a liderança entra e1n ação. Os líderes das equipes devem se comprometer em investir no processo pós-morte. Quando as cosias se acalmarem, os líderes devem pedir às pessoas que comecen1 a refletir sobre o que deu certo e deu errado, mesmo que seja apenas na forma de listas pessoais. Deve ser preparado um plano para que os líderes das equipes cobrem essas listas e crien1 um relatório pós-morre, que deverá ser constituído de duas partes: uma análise e resumo das lições aprendidas, e u1n compromisso de tratar de um nümero bem pequeno delas no próximo projeto (se você escolher um nümero grande, não serão tratadas; priorize e enfoque).

Talvez compense contratar um profissional para fazer o trabalho pós­morte12 para você (ou atribuir essa tarefa a alguém que não pertence à sua equipe, rnas à sua organização). Esse profissional passaria urna sernana entrevistando as pessoas da equipe, e criaria um relatório baseado no que foi aprendido, filtrado pela experiência de u1n consultor. Isso traz a vantage1n de uma perspectiva objetiva, uma vez que o profissional em questão observará e falará coisas omicidas pelas oucras pessoas.13 Talvez ainda mais imporcance, esse profissional acrescentará à organização um conhecimento externo, aplicado às necessidades de um projeto e equipe específicos.

Hora da festa

Quando u1na co1npilação RC final é confirmada e inicia o processo de disponibilização para o n1undo, chegou a hora de cornemorar. Depois de várias semanas, n1eses ou até anos, seja o que for que você supostamente deveria fazer, acabou. É uma coisa rara e especial finalizar um projeto: no setor técnico, a maioria dos projetos sequer chega perco de um fim. Como GP, cercifique-se de proporcionar a rodos os participantes uma oportunidade de celebrar em conjunto. Evite os clichês corporativos ou organizacionais (é irnpossível comemorar em urna sala de conferência). Em vez disso, vá para o barzinho mais próximo, reserve uma grande mesa em seu restaurante favorito ou convide as pessoas para irem à sua casa. Beba e coma mais do que conseguiu fazer por muito tempo (e coma e beba mais ainda por conta disso). Se você não é do tipo festivo ou social, descubra quem é na equipe, e conspire co1n essa pessoa para organizar alguma coisa.

A finalização de projetos não acontece todos os dias. Criar coisas boas que outras pessoas usarão e1n suas vidas é um desafio incrível. Este 1nomento merece uma comemoração extraordinária: viva a vida!

Resumo

• Grandes prazos são uma seqüência de pequenos prazos.

• Todo marco tem três prazos menores: design concluído (especificações prontas), recurso concluído (implementação finalizada) e marco concluído (garantia da qualidade e aprimorarnento finalizados).

332 A.ARTE DO G ERENCIAMENTO DE PROJ ETOS

• Definir cricérios de saída no início dos marcos aumenca a possibilidade de a equipe cu1nprir as dacas.

• Cumprir dacas é como acerrissar aviões: você precisa de uma longa e lenca abordagern. E convém escar preparado para decolar de novo rapidan1enre, sem precisar fazer grandes reparos.

• São necessários elementos de avaliação para rastrear o projero. Elementos comuns são: compilações diárias, gerenciamento de bugs e quadro de atividades.

• São necessários elementos de controle para ajustes no nível do projeto. Elementos comuns de controle são: reuniões de revisão, triagem e equipe bélica.

• O cérmino do final do jogo é um lenro e entorpecence processo. O desafio é reduzir o escopo de mudanças aré que reste uma versão sarisfacória.

• Chegou a hora de iniciar o processo pós-morre. Conceda a si 1nesmo e à sua equipe o benefício de aprender corn o que deu cerco e o que deu errado.

• Se a forcuna brilhar para você e seu projeco fizer dinheiro lá fora, seja feliz. Muiro, muito feliz. Muiras pessoas, mesmo se1n rerem culpa, nunca chegam cão longe. Prepare urna noite ern grande estilo. Faça coisas ridiculamente divertidas e extravagantes (inclusive convidar este aucor para a festa). Reúna hiscórias para contar pelos próximos anos.

Capítulo 16

Poder e política

334 A.ARTE DO G ERENCIAMENTO DE PROJETOS

S ernpre que você tentar orgarúzar pessoas para fazer alguma coisa, seja u1na fesca ou inauguração de uma e1npresa, haverá diferences acicudes, desejos e habilidades encre os parricipanres. Isso significa que, a despeiro da inreligência ou ralento de u1n líder ao adn1inistrar u1n projeto, algun1as pessoas não receberão cudo o que deseja1n. Sendo assim, há um instinto narural para que as pessoas motivadas e ambiciosas tenten1 e obtenham o que desejan1, influenciando aquelas pessoas que tên1 poder de execução. Isso, na forma mais simples que consegui acon1odar em um parágrafo, explica por que a polícica existe. É um subproduto da natureza humana nas interações de grupo que enfrenre1nos as frustrações e os desafios das situações políticas. Aristóteles dizia que "o homem é um ser político" e isso é uma parte do que ele quis dizer.

"Todo ato administrativo é um ato político. Com isso quero dizer que todo ato administrativo de alguma maneira redistr·ibui ou reforça o poder. "

-Richard Farson, Management of the Absurd.· Paradoxes i11 Leadership

($in1on e Schusrer, I 996)

O co1nbustível da política é o poder. Definido grosseiramente, poder é a possibilidade que uma pessoa ce1n de influenciar ou controlar outras pessoas. E1nbora a nossa cendência seja exan1inar as hierarquias organizacionais para saber quen1 é poderoso e quem não é, geralmente as estruturas do poder não corresponde1n direca1nenre às hierarquias (como descrico no Capículo 12, o poder conquisrado é diferente do concedido). Quem pode persuadir a pessoa cerra na hora cerra, e aplicar seu conhecin1ento para resolver as situações para a satisfaç,'io de todos, pode ser mais poderoso en1 uma organização do que seus superiores -algumas vezes, os superiores não reconhecem isso.

Esse fato acrescenta mais urna complexidade às políticas organizacionais: os indivíduos podem renrar e cultivar o poder independenren1ente da hierarquia. Para dificultar ainda mais tudo isso, dependendo da questão ou decisão específica, o poder é distribuído de modo diferente na equipe. Pant as decisões da engenharia, Harold pode ter o poder máximo, mas para as questões comerciais, Maude é quem manda. Com tudo isso combinado, a complexidade das org-.i.nizações comuns de projetos gera oportunidades políticas, mas també1n torna a competição pelo poder e influência inevitável.

Para os gerentes de projeto, isso indica dois aspectos. Primeiro, haverá influências políticas que o afetarão, independente1nence de todo o seu poder e sua ética. Em segundo lugar, o poder e a política são uma parte inerente da liderança e do gerencirunenco. Conheça pelo n1enos o funcionrunenco dos siste1nas políticos, para diminuir seus efeitos negativos, e no 1nínimo 1nelhorar os posicivos. Este capítulo apresentará as principais lições da política de projero aplicada. Discutirei como diagnosticar a paisagem política e1n que você se encontra, as situações comuns e por que ocorren1 e con10 solucionar problen1as de políticas e poder.

O dia em que me tornei político

Minha primeira lição importante sobre política organizacional veio em 1997 de Chris Jones, que, na ocasião, era um gerente de programas de grupo para o Internet Explorer. O grupo tinha passado por alguns meses caóticos, com

PODER E POLÍTICA 335

várias reorganizações e rnudanças de rurno, e a poeira ainda não tinha assentado. 1-Iavia urna função parcicularrnente imporcance na equipe -responsável por um recurso charnado canais (parte da malfadada 1nania da "recnologia push" duranre as guerras dos navegadores) - que nunca funcionou bem. Essa função era tão crítica para nossos planos, e tão 1nal gerenciada, que a equipe inteira era prejudicada por ela. Muitos parceiros e eu ficávan1os aborrecidos, mas não sabíamos o que fazer. Com um sentimenro de impotência, a 1naioria de nós se culpava pela polícica de nossa equipe de gerenciamenro. Para piorar ainda mais as coisas, na ocasião, eu tinha a visão mais cínica da polírica organizacional. Era algo assim:

Política (n): aros comeridos por pessoas diabólicas, fracas e . . com interesses pessoais.

Eu não sabia exacamenre o que eram aquelas coisas ou como eram feitas, mas eu tinha certeza de que as pessoas diabólicas, fracas e com interesses pessoais na equipe (não importa quem erarn) escavam fazendo isso. Eu não conseguia identificá-las de modo preciso porque minha avaliação das pessoas, na época, tinha dois parâmetros: inteligenres e burras. Eu era ignorante e arrogante (é inceressance observar como essas duas caracceríscicas andam de mãos dadas). Mas a salvação da minha lavoura contra essas falhas era o faro de que a opinião que eu tinha sobre Chris escava ern alta, e tive a sorte de ter u1n escritório ao lado do dele.1 Un1 dia, frustrado e aborrecido co1n a situação da equipe, parei ao lado dele e lhe contei minhas preocupações em relaç,'io ao grupo. Ele ouviu co1n paciência e sugeriu que conversássemos durante o alrnoço.

Ele teve a acicude mais surpreendente na hora do alrnoço - ele revelou 1nais do que eu esperava ouvir. Ele esquematizou a siruação segundo a sua perspectiva, informando detalhes suficientes para eu entender os problemas básicos, sem trair a confiança dos outros membros da sua organização. Ele descreveu sua avaliação de alto nível do problema e suas três alternativas razoáveis para solucioná-lo. Percebi que ele tinha restrições: as necessidades, os desejos e as metas de seus próprios parceiros, gerentes e YPs. Havia a pressão do nosso cronograma e a concorrência estratégica (Netscape). Para mim, o mundo dele era mais livre do que o meu (ter mais poder não significa ter mais liberdade?), mas à medida que ele esquemarizava, percebi que sua situação era mais difícil do que a minha.

Então, ele fez a segunda ação mais inesperada - ele pediu a minha opinião. Ele me deu urna oporrunidade de oferecer minha própria lógica e perspecriva sobre as decisões que ele precisava tomar. Imediatamente, eu rive minha primeira revelação política: essa coisa é difícil, muito difícil. Ao perguntar o que eu achava (e ao ouvir o que eu dizia), ele desarmou roda a ani1nosidade e <trrogância que geraltnente permeava1n 1ninhas tentativas no pensamento político. Ele me fez refletir real1nence sobre os problen1as e as pessoas envolvidas. E quando eu fiz isso, fiquei congelado. Como ao ser lançado no 1neio do tráfego de uma rodovia em sua direção, eu não sabia por onde iniciar: cudo parecia aterrorizanre. Ainda me len1bro de rer ficado parado, olhando para a 1nerade comida do sanduíche, sem conseguir achar nada inteligente para dizer. A conversa mudou de ru1no, o almoço terminou e voltei para o trabalho. Desde então, aprendi nluiro sobre o funcionamento das organizações, nlas me recordava daquele dia como un1a mudança irnporranre de perspecriva:

336 A.ARTE DO GERENC[AMENTO DE PROJETOS

• Política não é uma palavra maldita. Na maioria dos dicionários, a primeira definição enconrrada da palavra política é algo assiin:

Polírica (n): a arte ou ciência de governo ou de governar, principal1nente o governo de uma entidade polftica, con10 uma nação, e a administração e o controle de seus assuntos internos e externos.

Você não enconrrará nada parecido com minha definição cínica, acé se deparar com a quarta ou quinta definição listada na 1naioria dos dicionários (no idioma , inglês). Política é a habilidade de gerenciar pessoas e organizações. E possível ser politicamente eficiente, sem recorrer a uma conduta antiética ou escusa.

• Todos os líderes têm restrições políticas e de autoridade. Gostamos de acreditar que figuras de poder - como os YPs corporativos ou o presidente dos Esrados Unidos - cêm um rremendo poder. Real1nente têm, mas grande parre é um poder através de influência. Por exemplo, o presidente dos Estados Unidos é uma das crês ra1nificações do governo (executivo) e seu poder é verificado e equilibrado pelas outras duas ramificações. Muitos de seus aros oficiais pode1n ser vetados ou recusados. A maioria dos VPs corporativos tê1n gerentes seniores subordinados, que não gosram de receber orientações, e exige1n 1nuira auroridade. E por aí vai a cadeia de comando. Porranro, ao olhar para pessoas que tê1n 1nais poder do que você, não pressuponha onipotência.

• A proporção entre poder e responsabilidade é constante. Uma 1naneira de pensar no poder é através de seu relacionamento com as restrições ou co1n os desafios que você esperava enfrentar ao usar esse poder. Suponha que eu fosse o CEO da Exan1pleCorp e lhe desse US$ 5 para me trazer um café. Sua autoridade é pequena (mas existe), assim con10 a responsabilidade. Por outro lado, se eu lhe desse US$ 2,5 1nilhões e un1a equipe de vaquinhas de presépio brilhantes, provavelmente eu lhe pediria que planejasse, construísse e gerenciasse a empresa inteira. Responsabilidade, tensão e desafios geralmente aumentam em relação ao poder que lhe é concedido. Por esse motivo, ter mais poder rara.mente facil ita as coisas, porque os desafios se avolumam como conseqüência do aumento do poder.

• Política é uma espécie de solução de problemas. Não itnporta o desafio organizacional enfrentado e a frustração decorrente, isso é ourro ripo de proble1na para ser solucionado. Os microgerentes, os casuístas e os puxa-sacos são apenas tipos diferentes de obstáculos a sere1n superados ou contornados. Por niais que as coisas esteja1n boas ou ruins, provavelrnente há um n(11nero finito de opções realísticas que alguém com poder há de escolher en1 qualquer situação, e rodas essas escolhas terão conseqüências políticas. Se você abordar os proble1nas organizacionais com a 1nesma disciplina e criatividade que usa ao lidar com um problema de design ou de engenharia, poderá enconrrar ourras opções e tomar boas decisões (ou pelo menos, a melhor decisão possível).

Com o passar do tempo, aprendi que culpar a "política" pelos problemas que enfrentava era uma maneira ingênua e conveniente de me esquivar dos aspectos desagradáveis, mas inevitáveis, de trabalhar com pessoas. O mesmo se aplica às trocas de acusações na "gerência", "engenharia" ou "marketing', falando de sua estupidez e ineficiência. Trocar acusações não torna ninguém menos estúpido ou

PODER E POLÍTICA 337

ineficaz. (Se, na realidade, esse for realmente o problema. Sempre é possível que seja1n inteligentes, 1nas simples1nente li1nicados por fatores políticos co1no você.)

O mesmo é válido para apontar dedos para qualquer progra1nador, gerente ou autor individual. Culpar simplesrnence não 1nuda coisa algun1a e sin1plesmence não o deixar ver as verdadeiras causas e possíveis soluções de un1a situação. Qualquer ação política ou administrativa que ocorrer, a despeito de quão estúpida ou den1011íaca possa parecer, é sen1pre un1a de un1 número lin1itado de possíveis escolhas dos gerentes. Talvez as alcernacivas fossem piores para o projeto do que a escolha feira. Sem conhecer as restrições, o julgamento seni sempre baseado mais em um desabafo da frustração do que na realidade da situação.

As fontes de poder

Poder (n): a possibilidade de fazer ou agir; capacidade de fazer ou realizar alguma coisa.2

Para entender a política e ter uma chance de influenciar ou obter êxito no modo como as coisas se desenrolarn, é necessário conhecer os fundamentos do poder político. A maioria das formas de poder em uma organização gira em torno das decisões que alguém pode tornar ou influenciar. Pense em co1no as decisões são tomadas e1n sua organização: se existir u1na chan1ada difícil para ser feita, quen1 fará? Que1n pode perinanecer na sala ao longo de u1n debate? As opiniões de quen1 são 1nais ouvidas? Essas são as pessoas com graus de poder. Ter autoridade cotai para tornar uma decisão é a forn1a mais básica de poder, 1nas cer acesso a esse tomador de decisão, fazer perguntas ou dar idéias é outra forma de poder. Como discutimos no Capírulo 12, o poder concedido é a forma 1nais 6bvia, se origina na hierarquia. Está implícita nos títulos dos cargos das pessoas ou em outros símbolos de superioridade. Quase sempre o poder concedido é atribuído a uma pessoa por alguém en1 posição de poder superior. O VP concede poderes a seus subordinados diretos, e esses indivíduos concedem poder a quem trabalha para eles. O VP pode dar mais poder a certos indivíduos do que a outros - se isso se incluía nos interesses de suas metas.

O poder adquirido é distribuído de modo orgânico. Como a reputação e a possibilidade são subjetivas (em relação aos cargos e à hierarquia), cada indivíduo em um projeto desempenha uma função ao determinar quem adquiriu o poder. Por exemplo, vamos supor que Tyler é um programador na equipe. Maria e Jack compartilham de suas opiniões, mas Chloe não. Se ocorrer um debate abrangendo a equipe inteira, Maria e Jack, e não Chloe, darão mais credibilidade aos argumentos de Tyler. Por urn lado, Maria e Jack tenderão a transferir u1na parte de seu poder para apoiar os argu1nentos de Tyler. Assiin, o poder adquirido geralmente é concedido a alguérn através do cornporta1nento daqueles que o apóiam. Nesse caso, o poder adquirido (ganho) pode ser distribuído nos níveis da hierarquia. Por exernplo, u1n gerente sênior em uma organização pode cer grande consideração por um funcionário iniciante, e1n outra empresa.

En1bora seja comum que algumas pessoas conquiste1n mais confiança e poder do que outras, essa é uma questão sempre subjetiva e relativa. São possíveis diferentes resultados que dependem do domínio da decisão, de quem está na sala e de que poder r.ê1n. Por un1 cerr.o ângulo, é isso que torna a política interessante:

338 A.ARTE DO GERENC[AMENTO DE PROJETOS

o poder flui conscance1nence na equipe, mudando de direção e apoiando ou crabalhando concra pessoas diferences e em momencos diferences. Como nein se1npre o poder é óbvio acé ser aplicado, é fácil incerprecar incorreca1nence quem deré111 que tipos de poder.

Para dar uma idéia mais completa, a lista a seguir oferece definições específicas dos diversos cipos de poder (essa !isca é uma interprecação distance de uma lista encontrada em Power P!ays, de Thomas Quick). Não voltarei mais a esse assunto, mas compensa considerar que111, e111 sua organização, possui esses poderes e como são aplicados:

• Poder de recomp ensar. A possibilidade de conceder às pessoas bônus, <U1mentos salariais, petiscos deliciosos ou qualquer recompensa visivelmente benéfica. Como as pessoas sabem que você tem esse poder e querem ser seus beneficiários, vão reagir e se co1nportar de modo diference para você.

• Poder de coagir. Concrolar as penalidades e a possibilidade de ameaçar com ações punitivas. Geralmente, a ameaça desse ripo de poder é suficience porque, ao contrário das reco1npensas, o poder não está no recebimento de coisas boas mas, sim, em não ter que receber coisas ruins. O poder de coerção pode ser rão siinples quanto a possibilidade de en1baraçar ou ridicularizar uma pessoa na frente de outras ("Co1no você é burra!") ou tão oficial quanto rebaixar pessoas ou reduzir suas responsabilidades ou salário.

• Poder do conhecimento. Ter experiência em uma área subjetiva ou ter informações específicas, relevantes para uma decisão, confere poder. Ao concrolar como essa experiência é aplicada ou como/quando a infonnação será disseminada, alguém pode desenvolver u111 poder. Na fonna mais simples, ser inteligente, ter conhecimentos e ser bom na solução de quaisquer problemas surgidos no que você estiver trabalhando também confere poder porque as pessoas o ouvirão e respeitarão a sua opinião. Nas formas mais complexas, ter informações sobre outras pessoas, equipes, tendências ou reuniões dá poder, uma vez que a sua visão do mundo é mais exata do que a dos outros. E se você estiver se sentindo manipulador, podení distorcer as percepções dos outros ein relação ao estado do projeto ou do mundo.

• Poder da referência. Que1n você conhece e co1110 você conhece. Se as pessoas soubere111 que cetn o apoio ou a a1nizade de oucras pessoas co111 poder, uma parce desse poder se reflecirá em você. Por exemplo, se você se apresentar co1no "Sou Steve, trabalho para Bill", dependerá do poder e da reputação de Bill para lhe conceder uma parce de seu próprio poder e repucação. O poder da referência ta1nbén1 pode proceder de pessoas que se aliaram a você ou lhe oferecen1 apoio.

• Poder da influência. Algumas pessoas podem persuadir outras, o que pode ou não estar relacionado com o conhecimento do problen1a en1 questão. U1na combinação de habilidade em comunicação, confiança, percepção das emoções e talentos de observação contribui para a habilidade de ser influente. A influência pode ser alimentada pelo respeito que as pessoas tên1 por seu conhecimento ou porque confiam em você, ou até 1nesmo apenas porque o consideram atraente, in teligente ou interessante. A influência também pode se desenvolver como conseqüência de uma dívida: alguém pode lhe dever um favor e influenciar em uma decisão é uma maneira de agradecer. Observe que

PODER E POLÍTICA 339

algu1nas pessoas terão mais influência sobre outras - é urna forma de poder alca1nence relaciva, não absoluta.

O uso indevido do poder

"Se você não sabe o que está fazendo, que importância terá para alguém e como será irnplementado, o projeto se organizará auto1natica11iente e1n fonção de

outra 1neta ou metas. Gerahnente, surge algum tipo de argumentação política. Isso garante a falta de propósitos. "

- Jarnes Bullock, extraído de Roundtabk on Project Management

f\o discutirmos sobre política como uma coisa diabólica, em geral a interpretamos, na realidade, como o uso indevido do poder. Defino um uso indevido do poder como qualquer ação que não atende ao bem maior do projeto e das pessoas a ele atreladas.3

Corno as fontes de poder são naturais e seu uso para influenciar e orientar as decisões é urn subproduto do trabalho baseado na equipe, essas coisas não podem ser de1noníacas en1 si ou a partir de si mesmas. E impossível trabalhar em urn projeto se.rn que as pessoas tentem influenciar as outras e usar o próprio poder para fazer o projeto avançar. (Na verdade, con10 constacare1nos, a discussão e o debate abertos de idéias é saudável e positivo para tomar decisões rnelhores e trabalhar corn eficiência, minimizando simulcanea1nenre a política.)

Sendo assi1n, o uso indevido do poder ocorre quando alguérn está trabalhando por interesses próprios. Por exernplo, na Figura 16-1, as metas de uma pessoa correspondem muito vagarnente às n1etas do projeto. Boa parte de sua energia será investida fazendo o que é melhor para si mesn1a, em vez do que é melhor para o projeto como u1n todo. Isso caracteriza uma falha de liderança e gerenciamento em sincronizar melhor as meras (e recornpensas) individuais e da equipe com as metas do projeto. Para ser justo com os líderes, algumas lacunas são inevitáveis. As pessoas têm vida fora dos projetos. Os indivíduos têm as próprias motivações pessoais que podem nã.o ter nada a ver com o trabalho, mas que estão tentando atender através do t rabalho. Contudo, a função do gerenciamento é procurar essas lacunas e encontrar maneiras de minimizá-las. No 1nínimo, os gerentes devem ajudar os funcionários a agir corn essas 1notivações para não prejudicar o projeto. No fi1n das contas, se existirem grandes lacunas, será gerada Luna tensão natural em relação ao rnodo como o poder seni aplicado. Ocorrerão forces tentações nas pessoas em atender a si mesmas, e não ao projeto.

O que é melhor para mim ou para minha equipe

O que é melhor para o projeto

FIGURA 16-1. As motivações pessoais devem se alinhar ao projeto. Quanto menor for a sincronização, mais destrutivo será o comportamento político.

340 A ARTE DO G ERENC [AMENTO DE PROJETOS

Também é possível que o que parece ser u1n uso egocêncrico do poder seja apenas u1na discordância sobre o que é 1nelhor para o projeto. Co1no mostra a Figura l 6-2, duas pessoas podem cer opiniões diferences sobre a melhor forma de cumprir as 111etas do projeto. Talvez seja n1uico difícil distinguir entre esses dois casos porque, em geral, o que é melhor para o projeto pode terminar sendo o que é melhor para uma pessoa e não para outra. Para discernir quando a motivação é puran1ente interesse pessoal, é necessário conhecer as pessoas em quescão, esclarecer as metas do projeto e cer un1a boa estrutura de comunicação, debates e discussão de problemas.

A opini/!io de Rupert é a melhor para o projeto

A opinião de Comeliusé a melhor para o projeto

FIGURA 16-2. Disputas pelo poder podem acontecer por motivos altruístas. Dois parceiros podem simplesmente discordar sobre o melhor uso do poder.

Quando existirem várias equipes pequenas contribuindo para o mesmo projeto, os p roblemas serão mais complexos. Como mostra a Figura 16-3, se cada equipe individual civer mocivaçóes para tàzer coisas não-relacionadas ao melhor interesse do projeto, cada equipe gaseará muita energia o que não conduzirá ao êxito global do projeto. Essa estrutura se aplica igualmente bem a pessoas e a equipes inceiras. Sempre que houver uma divergência de mecas, au1nentará a freqüência do uso indevido do poder, a menos que a pessoa que esciver gerenciando todos esses indivíduos ou equipes se esforce acivamence para convencer essas equipes a colaborare1n e chegare1n a um acordo transparente quanto ao conflico de interesses.

O que é melhor para mimou para minha

equipe

para o projeto

O que é melhor para a equipe X

O que é melhor para a equipe Y

FIGURA 16-3. Quanto maior for a divergência de interesses, mais alta será a probabilidade de que venha a ocorrer o uso indevido do poder.

PODER E POLÍTICA 341

Causas do processo para o uso indevido do poder

U1n modo mais específico de incerprecar o uso indevido do poder é dividir as causas em dois grupos: processo e morivação. As causas do processo se originam em falhas no modo con10 a equipe ou organização é esrruturada, e é u1n ripo de falha adminiscraciva ou de liderança. As causas por motivação são orientadas unicamente pelas pessoas e por suas necessidades e orientações pessoais. Na maioria das vezes, quando o poder é usado indevidamente, ocorre tuna combinação de proble1nas do processo ou de mocivação.

As causas do processo são mais perigosas do que as forças de morivação, porque não se resrringem à conduta de uma t'1nica pessoa. Em vez disso, uma causa de processo é sistêmica e incentiva rodos na equipe a abusar do poder ou aplicá-lo a causas que só atendam a seus interesses pessoais.

• Processo obscuro de tomada de decisões. Se a equipe souber que está chegando o 1nomento de uma grande decisão, se conhecer os critérios e que1n participará dessa decisão, haverá pouca necessidade de falsa política. Que1n tiver u1na opinião a dar saberá a que1n procurar ou e1n que fóru1n deverá apresencar suas propostas, assitn como os argu1nencos que serão eficientes. Haverá simplesmente menos necessidade de manipulação. Mas se o processo for omisso, de1nasiada1nence co1nplexo ou não tiver responsáveis visíveis pelas decisões, qualquer pessoa que se i1nportar con1 o resulrado estará niotivada a ser n1ais política. Portanto, todos poderão con1ar decisões que afere1n outras pessoas a esclarecerem o que será feiro, quem participará e quais serão os crirérios.

• Interpretação/comunicação incorretas. As equipes que se comunicam bem hão de garantir que as informações sejan1 não somente transmitidas, como can1bén1 compreendidas e, se possível, aceitas (consulce o Capículo 9). Quanto n1ais deficientes fore1n os hábitos de comunicação de uma equipe, canto mais freqüente será a aplicação de poder de modo a não acender aos interesses do projeto. Se as pessoas A e B interpretarem de modo diferente as meras do projeto, mas presumirem que a outra pessoa pensa da mesma maneira, estarão trabalhando uma contra a outra, sem sequer perceberem.

• Alocação obscura de recursos. Se o processo de alocação do orçamento, da equipe e dos equipamentos não for definido ou tornado público, rodos buscarão esses recursos por 1neio de quaisquer rácicas disponíveis. É obrigação de que1n te1n o poder adequado esclarecer para a equipe os critérios de distribuição dos recursos ou como e quando as propostas de aquisição devem ser feitas.

• Falta de responsabilidade. Quando as pessoas são autorizadas a falhar ou a comerer erros sem se responsabilizar por eles, a política será inevitável. Se1n a responsabilidade pelos compromissos das pessoas, a confiança entre elas será exrremamenre rescrita. Se1n confiança, as pessoas usarão o próprio poder para se protegerem da dependência nos outros ou para evitar dependerem de pessoas nas quais não confiam (consulte a seção "A confiança é construída através do compron1isso" no Capítulo 12).

• Metas fracas ou capengas. Para praticamente rodo uso indevido do poder que mencionei, alguma referência foi feita ao atendimento das metas do projeto. Quando as 1necas do projeto são fracas {ou não existem), esses usos indevidos

342 A.ARTE DO G ERENCIAMENTO DE PROJETOS

são prováveis, se não garanridos. Sem o centro de gravidade das 1neras do projeto, não haverá u1n ponto de clareza com o qual rodos possa1n concordar, o que significa que rudo pode ser debarido e inrerprerado. Mes1no se as meras forem forres, os líderes da equipe precisarão fortalecê-las ainda mais: proteger ativamente as metas, atualizar e revisar para preservar a exatidão das metas e garantir que todas as decisões sejam tomadas com o objetivo de cumpri-las.

Causas de motivação para o uso indevido do poder

A despeito de qual seja a sua fi losofia em relação à natureza humana, é justo presumir que todas as pessoas são criaturas automotivadas. Até mesmo quando agimos de modo altruísta, esta reinos servindo aos nossos próprios valores sobre o que presta e não presta no mundo. Também somos criaturas emotivas e os fàto res psicológicos orientam nosso comportamento - reinos consciência de alguns desses fatores mais do que de outros. As causas de 1notivação se baseia1n e1n elemen tos sitnples da psicologia hurnana:

• Proteger os outros. Se eu deixar essa decisão acontecer, as pessoas da rninha equipe ou meus parceiros, com os quais me preocupo, sofrerão.

• Interesse pessoal. Quero aquele au1nenro de salário, aquela promoção ou u1n senri1nenco de orgulho ao realizar algo que considero i1nportance ou ben1-feiro.

• Ego. Quero provar como sou inteligente para 1ni1n mes1no ou para rodas as outras pessoas, ou talvez garantir que seja indisputável e baseante visível como sou mais inteligente e 1nelhor do que as outras pessoas. Este projeto deve ser, no 1nínimo, tão perfeito quanto sou ou deve ajudar a dissimular a n1inha in1perfeição.

• Desgosto/vingança. Não quero trabalhar com Fred ou estou tentando fazer com que Fred reviva o que "ele fez comigo" no projeto passado.

Essas motivações não são necessariarnente diabólicas. Elas só acarretam problemas quando conduzem ao comportamento que não oferece o melhor apoio às 1neras do projeto. Se for possível gerenciar essas 1notivações de 1nodo a não prejudicarem as outras pessoas da equipe, então elas se tornarão apenas mais um tipo de combustível a ser usado para fazer o projeto avançar. Exa1nine nova1nenre a Figura 16-1: se os dois círculos se sobrepuserem em 90o/o, efetiva1nente as motivações dos indivíduos estarão alra1nenre alinhadas com as n1etas do projeto. O desafio do gerente é controlar as forças do ego e do interesse pessoal o tempo todo. O gerente deve direcionar as energias de seus subordinados e de sua equipe no sentido de ajudar o projeto e as pessoas que nele trabalha1n, e1n vez de agir conrra elas.

Evitando o uso indevido do poder

A melhor maneira de reduzir esses sintomas é contar com as meras definidas pela visão do projeto, para orientar a aplicação do poder. Se rodos consultarem as mesmas meras pri1nordiais e herdarem suas meras individuais da mesma fonte

PODER E POLÍTICA 343

(consulce o Capítulo 4), rodas as tensões polícicas que vierem à cona serão gerenciáveis. E1nbora alguns possam discordar e quescionar os 1neios, rodos esrarão lucando por objecivos sen1elhanres. Co1no reforço, a qualquer momento duranre u1n projero, qualquer pessoa pode fazer franca1nence as seguintes perguntas:

• Quais são nossas metas para esta sen1ana/mês/projeto?

• Tratam-se de metas globais ou de uma equipe secundária, que estejam enfrentando algu1n tipo de conflito? Como podemos gerenciar ou solucioná-los?

• De que modo esca decisão específica será cornada e quem a comará?

• Quais são nossos critérios para garantir que essa decisão atenda ao projeto da melhor maneira possível?

• O seu e o meu poder esrão sendo aplicados para conrribuir com nossas meras ou apoiar a equipe?

• Qual é o 1nelhor 1nodo de utilizar os recursos para nos conduzir ao sucesso? Corno fuzemos isso acontecer?

Mesmo que as respostas sejam divergentes, as pessoas estarão rendo as discordâncias certas. As verdadeiras causas dos conflitos são evidentes, e os líderes e gerentes cerão a oportunidade de esclarecer, redefinir as 1necas ou fazer novas (possivelmente difíceis) escolhas, diante das pessoas direramenre afetadas por essas decisões. Do contrário, o uso indevido do poder será garantido se as metas ficarem muito desatualizadas ou radicalmente divergentes de um indivíduo para o outro ou de uma equipe para a outra.

Ocasionalmente, os gerentes preferem preparar as equipes deliberadamente para competirem entre si, apostando que a concorrência agregada resultará em um trabalho 1nelhor. Isso pode funcionar em algumas situações, 1nas torna a organização mais volátil e política, exigindo um líder mais forte e ativo para segurar as rédeas. Não há nada único em relação a isso. Por exemplo, roda equipe desportiva ce1n os jogadores ciculares e os jogadores reserva. Em codo treino, o cécnico renca mancer a competição interna daquelas posições iniciais, mas preservando, ao mesmo tempo, um forte elo denrro da equipe inteira. Os bons líderes reforçam ativamente as atitudes e condutas cercas para 1nanter o equilíbrio dessas forças.

Entretanto, os indivíduos não-policiados, co1n interesses isolados ou concorrentes tên1 mais 1nocivação para usar o poder polícico para os próprios objecivos. Em vez de um espírico competitivo voltado para os verdadeiros concorrentes comerciais, ele está direcionado para os parceiros e subordinados, dentro da mesma equipe. Sob um prisma holístico do projeto, esse ripo de ambiente é corrupto. O poder não está sendo direcionado efetivamente para a conclusão do próprio projeto. Se1n atos forres de liderança para reforçar a equipe e nivelar as condições de concorrência, provavelmente entrarão en1 uma espiral de degradação. Cada ação corrupta ou voltada para interesses pessoais recompensada (ou ignorada pela gerência) incentivará outras pessoas a fàzere1n o mesmo. Em breve, poucas pessoas confiarão umas nas outras o suficiente para serem eficientes, uma vez que sempre questionarão os motivos secretos de seus companheiros de equipe e de seus superiores.

344 A ARTE DO G ERENC[AMENTO DE PROJETOS

Como solucionar problemas políticos

Nesta seção, estou presumindo duas coisas. Primeiro, que existem metas bem­deftnidas para o projeto. Segundo, que essas metas motivam o que quer que você esteja tentando alcançar. Se un1a ou mais dessas premissas não for verdadeira para você, esta seção ainda lhe será t'tcil, mas será mais trabalhoso, porque você terá n1enos alavancagem para fazer as coisas acontecerem.

O processo aqui descrito fàz mais sentido para grandes questões de poder e para quando você estiver em uma situação que exige rnais poder do que o que tem. Quanto maior for o problema, tanto maior a atenção necessária para aplicar urn processo elaborado corno este. Quanto rnenor for o problema, tanto menos etapas poderão ser agilizadas ou ignoradas.

Esclareça as suas necessidades

A única maneira de obter êxito ao resolver um proble1na polírico é ser transparente quanto às suas necessidades, e depois desenvolver um plano. As necessidades cornuns são:

• Recursos (dinheiro, tempo, equipe)

• Autoridade para tomar uma decisão

• Influência en1 uma decisão sob autoridade de outra pessoa

• Ajuste das rnetas de outras pessoas para respaldar ou se alinhar às suas

• Ajuste de suas próprias 1netas para se alinhar às de outras pessoas

• Conselhos, conhecimentos ou apoio

Por mais que você defina suas necessidades, prepare-se para ser flexível. Mesmo que você determine que a necessidade real recai sobre os recursos, ao buscar por esses recursos, não deixe de ouvir as sugestões de outras pessoas, que cumprem as metas mas não participarn no processo de aquisição de recursos. Ao baralhar por um orçamento rnaior ou por mais tempo, você pode forçar o surgirnenco de uma nova idéia que satisfaça às suas meras, assim corno rnais recursos tarnbém atenderiarn. Assim, não fique preso l1 necessidade en1 si: ela é apenas un1 rneio de acender às suas n1etas no projeto.

Gerir relações hierárquicas

O melhor momento para se fazer esse tipo de análise de necessidades políticas é durante a definição de suas metas. Quando reunir-se com seu gerente para estipular as suas responsabilidades para a semana ou o mês seguinte, haverá urna oportunidade de considerar se você cern a autoridade necessária para conseguir a conclusão do trabalho. Deve ser identificado todo apoio necessário do qual você não dispõe no momento, e seu gerente pode sugerir urn plano para ajudá-lo. Algumas organizações charnam essa atividade de gerir relações hierárquicas - corno se você tivesse que gerenciar hierarquia acima, ern vez de hierarquia abaixo. Esclarecer o que você precisa de sua gerência é a primeira etapa para gerir relações hierárquicas com êxito.

PODER E POLÍTICA 345

Ao gerir relações hierárquicas, as oucras ecapas abrangem, em grande parce, repecir esse processo nos incervalos necessários. Se você ficar coneccado co1n seu gerence e com o gerence de seu gerenre e1n relação ao que esrá fazendo e o que precisa deles, e garantir que tudo esteja sincronizado em torno das 1nesmas 1netas, terá alcançado grande parte do objetivo.

A maneira mais simples de gerir relações hierárquicas é iniciar uma discussão com seu gerente, propondo coisas específicas para os seguintes aspectos.

• O que eu espero que você, meu gerente, fàça por mi1n (por exemplo, dar orientações, informar detalhes que preciso saber, apoiar minhas decisões, idenciflcar áreas onde preciso melhorar).

• Os recursos necessários para acender a essas 1necas e a que1n recorrer.

• O nível e freqüência de participação que preciso de você (Nenhu1n envolvimento? Revisões cri1nestrais? Relacórios de scacus diários? Reuniões semanais com cada membro? Seja específico).

Ao tomar essa aticude logo no início, você saberá imediatamente quanto apoio poderá esperar, e onde os proble1nas provavelmente se originarão. Os alarn1es deverão disparar se o seu gerente for lerdo, vago ou se estiver na defensiva quanto a se con1promerer com qualquer un1a de suas solicitações. Isso significa que você pode 1nuito bem agir por conra própria ou se preparar para o fracasso, e que seu gerenre não esrá rrabalhando ativamente a favor de interesses 1núruos.

Quem tem poder para lhe dar o que você precisa?

Para cada tipo de poder necessário, identifique a pessoa que o pode conceder-lhe. O organogra1na ou a hier-arquia é t11n lugar fácil para se começar, n1as use isso apenas co1no um lembrete para si mesmo sobre os parceiros envolvidos (consulce a Figura 16-4). Depois, procure saber quem é o responsável mais ativo por que cipos de decisões (em pequenas equipes, deve ser óbvio, 1nas se não tiver certeza, pergunre). Use as pessoas co1npromecidas e1n apoiá-lo para ajudar a idencificar isso: seu gerente, seus parceiros ou subordinados. Deven1 ser necessárias algumas conversas para identificar as pessoas das quais você precisa. Às vi::ies, é melhor buscar esse cipo de informação indiretamente porque seu objetivo não é necessarian1ente se aproximar da(s) pessoa(s) em questão sem um plano. (Evite se comportar de modo estranho, como "Oi, Fred. Você está encarregado de determinar quem receberá novos la ?" "S" '?" "S' . "d d T h " ) ptops. 1m, por que. o cunos1 a e. c au .

Conhecendo a perspectiva de quem tem o poder

E1n relação a cada pessoa que tem o poder de que você precisa, co1nece identificando as 1netas dessa pessoa. Em uma equipe bem-adn1inistrada, isso deve ser fácil porque, na realidade, as metas dessa pessoa são as do projeto, independentemente do nível hierárquico da pessoa em questão. Considere as tendências, opiniões e métodos preferidos para lidar co1n a to1nada de decisões. Quanro melhor for o seu relaciona1nenco com essa pessoa, e quanro maior for a sua experiência trabalhando com ela, tanto 1nais fiícil será todo esse processo.

346 A ARTE DO G ERENCIAMENTO DE PROJETOS

FIGURA 16-4. A fonte relevante de poder depende da situação. A hierarquia do organograma não é necessariamente o aspecto principal. Uma pessoa de nível médio pode ter mais poder sobre certos assuntos do que seu chefe.

Raciocinando segundo a perspectiva dessa pessoa, descubra de que 1nodo suas necessidades e mecas se encaixa1n com as dela. Faça co1n que sua solicicação proceda de algun1 requisico ou objeco de nível superior do projeco que a pessoa deve respeitar. En1 vez de d izer "Preciso de oucro progran1ador", encenda que você pode dizer francamente "Para atingir as n1ecas X e Y, 1ninha equipe necessita de oucro programador. Nosso plano do projeco não previa as três solicicações que chegaram na semana passada, e conseqüencen1ence, nossas metas estão atualmente correndo grande risco". Não minta nem confunda. Disponha-se a questionar suas pr6prias solicitações de recursos se existi re1n uti lizações mais eficientes para esses recursos no projeto. (Mas se esse for o caso, você deveria estar solicitando uma mudança de 1netas e objetivos em detrimento de uma uti lização mais eficiente. "Acho que nossas metas devem mudar. A meta X é menos importante agora. Aqueles recursos devem ser deslocados para respaldar a 1neta Z." Um supervisor intel igente o recompensará por esse raciocínio voltado para o projeto.)

Quem esses poderosos respeitam e em quem confiam?

Se você identificou Fred como a pessoa com o poder do qual você necessita, procure descobrir que1n o influencia. Pode ser u1n parceiro, uma estrela em sua equipe ou o próprio superior. Pode ser você - pelo 1nenos para decer1ninados tipos de decisões. Pense em co1no usar a influência dessas pessoas para apresentar suas idéias. Se você tiver tun bon1 relacionamenco co1n essas pessoas influences, co1nparcilhe suas idéias e peça a opinião delas.

Não manipule, não minta ne1n faça nada questionável - não é necessário . Em vez disso, coloque seus argu1nen tos quase con10 o faria co1n o Fred, e peça os comentários dessas pessoas. Talvez elas saiban1 de coisas que você não sabe, calvez tenha1n perspectivas que n1elhoren1 seu raciocínio (inclusive mudando a sua opinião) ou calvez cenhan1 apenas um conselho sobre con10 vender o seu peixe. Mesmo que não renha un1 bom relacionamento com essas pessoas influentes, você també1n pode pedir suas opiniões e observar como colocam os argumentos ou propostas bem­sucedido(as) junto ao Fred.

PODER E POLÍTICA 347

A ilusão do poder de grupo

As vezes, o que você precisa parece ser controlado por um grupo de pessoas. Pode ocorrer uma reunião ou co111irê que, aparenremenre, roma cercas decisões. Nunca se concentre e111 un1 grupo de pessoas: divida se111pre os grupos em indivíduos e analise quem te1n que ripo de influência nesse grupo. A despeito do que pareçam. ser, as reuniões raran1ente decidem algun1a coisa. En1 geral, as pessoas encram nessas discussões com opiniões e aliados forres para respaldá-las, e a reunião leva a cabo uma série de 1naquinações previsíveis. Para os não-iniciados, essas reuniões podem parecer vibrantes e acivas, 1nas para aqueles com muico poder, muitos dos argumentos foram tocalmente previsíveis, quanto à sua natureza e resultado. Foram cotalmente previstos (talvez usando um processo semelhante ao que você está lendo agora), e bons contra-argumentos já estavam prontos para encerrar as discussões.

Quanto mais importante e controverso for um assunto, tanto 1naior o investin1ento que você deverá fazer nas pessoas envolvidas. Só apresente idéias cegamente para grupos, se tiver certeza de que possui as habilidades de lógica, influência e comunicação, para levar u111a sala repleta de pessoas poderosas com opiniões divergentes, na direção que, na sua opinião, atende melhor ao . projeto.

Faça uma avaliação

Co1nbinando cudo o que você aprendeu nesce livro, avalie as probabilidades de conseguir acender às suas necessidades com êxito. É coralmenre possível que, com determinada estrutura de poder, seja inviável atender a urna necessidade específica. Isso não é necessariamente fa lha de alguém, é apenas um pouco mais de restrição de engenharia ou con1ercial. Ao avaliar sua situação, perceba que as estruturas de poder têm limitações, exatan1ente con10 as oucras estruturas.

• Alguém tem o poder de que você necessita? É possível que os recursos necessários não estejam disponíveis. Todos eles podem estar comprometidos com outras tarefas (e nã.o podem ser reposicionados) ou a organização sequer possui os recursos. Se você estiver pedindo algo além do escopo da

. ~

organ1zaçao, prepare-se para apresentar argumentos extre1namente convincenres. Divida u1na solicitação grande em várias pequenas, e priorize­as. Talvez seja viável obter essas solicitações 1nenores junto a diferentes pessoas ou ao longo de um intervalo de tempo.

• Con10 você conseguiu obter esse tipo de suporte anteriormente? Analise suas próprias experiências ao obter essa modalidade de poder. O que aconteceu? O que deu cerco e o que deu errado? Se você não ce1n experiência nesse tipo de política, encontre algué1n que renha e peça u1n conselho. Se continuar assim 1nesmo, saiba que precisará enfrencar desafios: quem tiver o poder que você esrá tentando usar terá experiência em lidar com pessoas que desejam acesso a ele, colocando-o em desvantagem (mais unia vez, é possível que eles não seja1n tão brilhantes ou tão f.1miliarizados con1 o pensa1nento polícico quanto você).

348 A.ARTE DO GERENC[AMENTO DE PROJETOS

• Como alguém conseguiu obter junto a eles esse tipo de suporte? Se ninguém conseguiu convencer o gerente da equipe a 1nudar a metodologia de desenvolviinento, saiba que se você renrar fazer isso, estará conquistando u1n novo espaço. Ao contrário, se estiver tentando fazer algo que os outros já fizera1n, descubran1 como fizeram e assimile a experiência dessas pessoas.

• Até que ponto seus argumentos são fortes? Em algumas ocasiões, eu preferia apostar toda a minha reputação en1 uma solicitação. Eu tinha tanta certeza de que estava cerro, que usei o lastro de nleu comprometin1ento para ajudar a convencer as pessoas de sua importância. Oucras vezes, eu não tinha tanta certeza, e eu adaptava meus argumentos adequadan1ente. Conheça onde você está pisando e seus sencirnencos em relação ao que está pedindo. Organize detalhadamente seus argumentos e assuntos e concentre-se nos mais fortes.

• Que abordagem e estilo funcionarão melhor? Aparecer na sala de alguérn e dizer "Preciso disco" será mais eficience do que fazer uma relatório ou uma apresentação de 1 O páginas? Dependendo dos facores anteriores, da culrura da equipe e das personalidades das pessoas envolvidas, abordagens diferences serão 1nais eficazes. Nesse caso, não existe um manual de instruções rigoroso: seu melhor guia é perguntar a si n1esrno quão formal ou inforrnal você deve ser, e en1 que to1n suas solicitações deve1n ser apresentadas. Analise sucintarnenre algu1nas abordagens diferentes antes de investir e1n uma delas.

• Quem mais está competit1do para os mesmos recursos? Às vezes, é evidente quem mais está competindo pelo nlesn10 ite1n do qual você precisa. Orçament.os e equipes são sempre lin1itados, e geralinente os recursos do seu chefe são divididos entre seus parceiros. Se você tiver bons relacionamencos, calvez consiga se reunir com seus parceiros e discutir suas opiniões e argurnentos, tentando fi1zer coletivamente o que é melhor para a equipe (na realidade, esse gerente comum deve escar fazendo exatamente isso: definindo e liderando o processo para a equipe). Se os relacionamentos não foren1 forres, faça-o por conta própria. Analise seus argumentos e, com o máxin10 de objetividade possível, avalie-os dentro de seu próprio concexco. Por último, pondere sobre corno as outras pessoas perceberão sua forma de agir. Elas ficarão aborrecidas? Zangadas? Acharão que estão sendo traídas? Analise as coisas em tempo hábil. Converse com as pessoas envolvidas, se puder, ou coloque seus argumentos de modo a minimizar as reações negativas.

• Essa é a batalha certa para você entrar? Reconheça que essa necessidade específica é u1na das muitas que você rem. O uso de influências e oucras esrrarégias políticas lhe cuscará un1 re1npo e urna energia que não poderão ser investidos em outras coisas. Certifique-se de que o que você esr~í buscando é o rnelhor uso de seus recursos. Por exe1nplo, saiba se há uma solicitação mais imporcance que precisará enca1ninhar mais tarde, de modo que é melhor . . econon11zar energia para esse n1omento.

• O invisível o machuca. Reconheça sempre os níveis de política e poder que você não pode ver do lugar onde está. Quanto maior for a organização, mais vezes isso acontecerá. Dois ou três níveis acima (se existirern esses níveis), deve existir um conjunto de lutas e debates sobre questões sobre as quais você não f,iz a menor idéia. Seus parceiros, que podem ter meras diferences, esrão usando as próprias influências sobre os mesmos poderes que você. Considere o que pode

PODER E POLÍTICA 349

escar aconcecendo acirna e ern corno de você, e esteja acento às fonces de infonnações que poden1 ajud<í-lo a rnelhorar sua perspecciva.

Táticas para influenciar o poder

Após fazer uma avaliação, está na hora de agir. Há táticas con1uns para abordar as polícicas organizacionais e para co1neçar a usar o poder das oucras pessoas. As rácicas a seguir são as mais simples e mais comuns; em seguida, você encontrará referências a ourros métodos.

A solicitação direta

Na solicitação direta, faça a coisa rnais sin1ples possível: procure a pessoa que cem o poder necessário e faça um pedido a essa pessoa. Dependendo da abordagem e do estilo identificados (consulte a lista ancerior), pode ser uma conversa inforrnal, urn etnail ou uma reunião agendada exclusivamence para essa finalidade. Quanto rnais formal for a sua solicitação, maiores serão as chances de que oucra pessoa encre na discussão. Quanto menos formal, mais diretas serão a sua conversa e solicitação. Na Figura 16-5, A represenca a pessoa com o poder necessário, e B, C e D são as outras pessoas en1 sua equ ipe.

8 0

8

FIGURA 16-5. A solicitação direta.

A conversa

Esca é uma variante colaborativa para a solicitação direta. Se você e B estiverem competindo pelos mesmos recursos e discutiram o assunto juntos, peça a A para se reunir com vocês dois e resolvam a questão em grupo. As equipes com metas forces e um bom trabalho em conjunto fazem isso de modo natural e informal. Elas nutrem uma confiança mútua para trabalhar para metas compartilhadas do projeto, e concedem de boa vontade pontos válidos, até mesmo quando essas concessões reduzem o próprio poder ou a própria autoridade. Os líderes e gerentes fortes escimularn essa conduta porque rninirniza a necessidade de se envolverern: em algum mornento, a equipe aprenderá a resolver os próprios

350 A ARTE DO G ERENCIAMENTO DE PROJETOS

problemas (por exe1nplo, aprenderão a replicar as filosofias de A, mesmo sem a sua presença), e envolverão A so1nence se exiscirem decisões difíceis a ser co1nadas.

O uso da influência (abordar seu objetivo pelos flancos)

E1n vez de ficar dependente de sua própria influência para convencer A, invista no apoio de oucras pessoas na organização, que expressen1 argu1nencos e opiniões semelhances. Escolha cuidadosamente entre as pessoas de sua equipe, de acordo com o nível de influência que civerem sobre A .. Se sua influência for fraca, calvez seja necessário pedir o apoio de várias pessoas.

Na terminologia militar, isso se chama abordar seus objetivos pelos flancos . Em vez de se aproximar diretamente, aborde pelas laterais, ganhando vantagem. Em vez de lidar com seus argumentos, A também deve responder aos argurnencos de uma ou 1nais pessoas influentes. Quando esses argu1nencos surgirem de pessoas com igual poder ou superioridade que A, serão mais difíceis de rebater. (Contudo, tenha cuidado ao obter opiniões de pessoas de nível superior ao de A, sem a presença de A. Isso pode ser consid erado uma rasteira, urna tencariva de burlar a autoridade de A, e dependerá da cultura do grupo e da personalidade de A.)

Como alcernativa, isso pode ser combinado com a solicitação direra (co1no ilustra a Figura 16-6). Outras opin iões abrange1n o 1nodo co1no você usará a influência que ganhou. Talvez não seja real1nence necessária a presença de B, C e D na sala, ou até 1nesn10 sequer conversar co1n A sobre o assunto em questão. Desde que tenha a aprovação deles, você poderá falar por eles, dizendo a A ''Acho que precisamos corrar esre recurso. Falei com B, C e D, e eles 1ne apóian1 nessa decisão". Evidentemente, renha o cuidado de não expor incorreramenre o que eles disseram, e coloque-se sempre à disposição para trazer essas pessoas para a sala, para confirmar tudo (revertendo efetivamente para uma conversa).

8 L

FIGURA 16-6. Usando a influência para abordar um objetivo pelos flancos.

O uso da influência em etapas

Q uando você não puder acessar as pessoas das quais necessita, desça na cadeia de influência ou na hierarquia. Se C for a única pessoa que A ouvirá, e você não conseguir falar com e em particular, descubra quem ten1 o n1áximo de influência sobre C. Depois, aproxin1e-se dessa pessoa e venda seu peixe. A

PODER E POLÍTICA 351

parcir daí, você poderá concinuar crabalhando acé gue sua influência acinja o ponco onde deve ser aplicada. Consulce a Figura 16-7.

FIGURA 16-7. O uso da influência em etapas.

O uso indireto da influência

8 /

Ocasionahnence, a melhor 1naneira de ínfluenciar o poder é acionar as coisas, mas ficar nos bascidores. Talvez A esceja doís ou mais níveís acitna de você no organogra1na, e não reaja be1n a solicitações dírecas de pessoas no seu nível. Ou calvez A simples1nence não gosce ou esteja aborrecido co1n você por causa de curro assunto (e você não acha que essa pessoa esceja sendo objeciva quanco ao assunco).

Nessa situação, peça o apoio de outra pessoa para fazer essa solicitação. Pode ser seu gerente imediato, um parceiro en1 sua equipe ou algué1n que trabalhe para A, que possivelmence tenha ingerência sobre o assunco em quescão.

O modo mais discreto de adminiscrar isso é levar cudo na conversa. Converse com C e veja se consegue seu apoio. Se conseguir, peça que converse corn A sobre o assunro (consulte a Figura 16-8). Quando for aré A, C não deve mentir nem confundir: poderá argumentar segundo a própria perspecriva porque C concorda plenamence com você e sua solicicação. Se A pedir para conversar com você sobre o assunto, ou se perguntar a A sobre o assunto posteriorinente, seu argumento cerá sido beneficiado pela influência de e.

FIGURA 16-8. Influência indireta.

A reunião de grupo

Reuniões são sicuações políricas muico cornplexas. Que1n escá na sala pode falar e fazer perguntas, aplicando seu poder polícico à discussão de modo a dificultar

352 A ARTE DO G ERENCIAMENTO DE PROJETOS

mais as coisas. Se algo imporcance deve ser decido ou discucido, cercífique-se de ter avaliado que1n escará na sala, ances da reunião aconcecer. Consiga cempo suficienre para se preparar para usar seu poder e influência, anres da reunião (não necessariamente para influenciar a reunião, mas para ajudá-lo a prever o que provavelmente acontecerá). Contudo, as reuniões são baseante convenientes. Você pode reunir todos no mesmo local e ao mesmo tempo, e lidar com vários tipos diferentes de assuntos, simultaneamente.

Antes da reunião, pense nas perguntas que provavelmente surgirão, e que tipo de resposra cada pessoa deseja ouvir. Se conhecer be1n as pessoas, poderá fazer boas previsões sobre o que esperar e preparar-se para tudo sozinho. Caso contr;írio, faça uma pesquisa. Solicite antes da reunião os comentários de pessoas importantes que participarão da mesmo. Conheça seus interesses e grandes perguntas antecipadamente, depois faça mudanças, se for adequado, ou desenvolva sua defesa do plano atual. Se tiver acesso direto à agenda, planeje adequada1nenre.

Algu1nas vezes, 1narcar você mesmo un1a reunião pode ser a única maneira de resolver uma questão de poder. O email rara1nente funciona bem em questões cotnplexas ou delicadas. Ou talvez você cenha percebido que Sally precisa ouvir Bob e Mike ao mesmo tempo, para se convencer de que sua recomendação deve ser seguida. Realizar reuniões efetivas é um talento por si só (consulte o Capítulo 1 O), mas por enquanto, entenda que quanro 1nais preparado você esriver para as possíveis perguntas e debates, mais fácil será administrar a reunião de n1odo normal e fàvorável. (Consulte a Figura 16-9.)

80

FIGURE 16-9. A reunião de grupo pode ser uma situação política imprevisível.

Faça as pessoas pensarem que a idéia foi delas

Raros são os casos em que é possível plantar se1nentes e regá-las co1n o ego de algué1n. Acontece o seguinte: e1n sua opinião, t11na solicitação direta não será bem-sucedida. Então, em vez disso, você força uma discussão ao identificar u1n problen1a e pede ajuda para encontrar uma solução. Você mesmo não oferece as respostas, n1as, en1 subsr.iruição, faz perguntas e argumentações que genrilmente conduzem as pessoas ao resultado que deseja. Como rodas as manipulações, essa pode ter facilmente o efeito contrário e exigir uma sutileza e talentos de improvisação que poucos possuem. Mas adm iro que, às vezes, isso funciona com os gerentes seniores, que acham que estão certos o tempo rodo.

PODER E POLÍTIC A 353

Referências a outras táticas

A lista anterior cobre apenas os funda1nentos . O assunto de táticas polícicas enche várias praceleiras de bibliotecas. O melhor recurso isolado que encontrei foi a obra de Robert Greene, The 48 laws of Poiver (Penguin, 2001), mas saiba o seguinte: quase como a obra de Dale Carnegie, How to Win Friends and lnf/uence People (Pocket, 1990), você sentirá muita vontade de ro1nar banho, depois de ler. lnjluence de Robert Cialdini (Perrenial, 1998) escá mais para marketing do que para polícica administraciva, 1nas tuna parte dos princípios psicol6gicos é semelhante.

Conheça o campo de ação

As tiltimas considerações do gerenciamento de projetos abrangem o campo de ação política. As pessoas que têm o poder 1náximo definem as regras que a equipe seguirá: co1no o poder ser<i obtido, aplicado e distribuído. Quando as pessoas agem sem ética - 1nanipulando e enganando os outros - que1n estiver no controle deverá identificar e repri1nir esse comporta1nenco. Deve ser interesse dessa{s) pessoa(s) manter o ca1npo de ação relativamente justo e permitir que as pessoas cerras usem o sisre1na político para fazer o n1elhor para o projeto.

Contudo, se quen1 estiver no poder não tiver o cuidado de manter um ca1npo de ação justo, você (como um dos parceiros) deverá conhecer as regras do jogo e ajuscá-las adequada1nence. Use seu poder para cescar e mudar as regras, ou aceite-as co1no estão. Se práticas decepcionances ou injustas fore1n comuns, saiba o que isso significará para os resulrados das suas abordagens. Não pressuponha que as outras pessoas são altruístas, se não há 1uotivos para pensar assim. Não estou recomendando que use a proposta do menor denominador comun1 e copie o comportamento de outras pessoas: esca é uma escolha dentro da ética e da n10ral que só você pode fazer. Mas estou dizendo que você precisa conhecer o jogo que está jogando, e com quen1 está jogando. Acrescente essas infor1nações à sua avaliação e se beneficie da possibilidade de prever como os outros jogarão.

Criando seu próprio campo político

Não i1nporta quão frustrante a política seja, como gerente de projetos você te1n o poder de controlar seu próprio campo de ação, co1no mostra a Figura 16-1 O. Além disso, você controla como seu poder será distribuído na equipe. Você cem duas escolhas básicas: tornar seu campo de ação um local seguro e justo para pessoas inteligentes trabalhare1n, ou pennicir que os proble1nas e sintomas da equipe 1naior aferem o seu mundo. Essa úlrin1a opção é fácil: não fazer nada. A primeira opção exige liderança e o uso de várias táticas descritas neste livro.

354 A ARTE DO GERENC[AMENTO DE PROJETOS

Mundo de insensatez e arbitrariedade

Zona segura de ética orientada por metas

Mundo de insensatez e arbitrariedade

FIGURA 16-10. Você sempre tem o poder de definir seu próprio campo de ação.

Os bons gerentes sempre encontra1n um jeito de proteger sua equipe. Embora seja verdade que, para sua equipe crescer, ela precisa enfrentar situações difíceis, un1 bo1n gerente protege as pessoas o suficiente para que sejam eficientes, e ainda participem de experiências reais e de oportunidades de aprendizagem . De modo semelhante, se o seu geren te estiver fazendo u1n bom trabalho, ele o estará blindando contra determinados problemas e situações, e trabalhará ativamente a seu favor para tornar o seu mundo um lugar mais fácil para se trabalhar. Em qualquer nível da hierarquia, essa modalidade de liderança pró-ativa exige 1nais trabalho e maturidade: mas essa é a natureza do bo1n gerenciamento .

Portanto, não pre.~suponha que, porque seu gerente o trata muito mal, você deve descontar tudo isso em seus subordinados. Co1no gerente, é você quem determina o modo con10 sua equipe deve ser gerenciada. Não transmita atitudes, hábitos ou táticas que você considera destrutivas. Explique à sua equipe as diferenças no estilo ou na atitude profissional, 1nas não siga um co1nporta1nento que, em sua opinião, é contraproducente.

Grande parte do aconselha1nento contido neste capítulo e neste livro se aplica a qualquer nível da hierarquia organizacional. Se não existiren1 1netas transparentes em seu nível, é sempre possível criar objetivos claros para a sua equipe. Se não existirem práticas transparentes no seu nível e acima dele na organização para o modo de distribuição dos recursos, você pode estabelecer as suas práticas nas áreas em que comanda. O mesmo é válido para o planejarnento de projetos, para a comunicação ou para a tomada de decisões. Nem sempre você se beneficiará diretamente com esses esforços, mas certamente a sua equipe sim. Será mais fiícil para a sua equipe ser mais eficiente e concluir mais trabalho, uma vez que você esteja propiciando uma estrutura eficaz, que o restante da organização não tem.4

No final de tudo, a liderança pró-ativa em sua própria esfera de influência é a melhor maneira de expandir as próprias fontes de poder. Inicial1nente, talvez você fique e1n desvantage1n com os superiores por trabalhar de 1nodo diference do deles. Mas co1n o passar do te1npo, as pessoas aprovarão o ca1npo de ação criado por você. Elas se sentirão mais felizes e mais eficientes ao trabalharem com e para você, e não com os outros. D iferentemente do status quo do restante da organização, a qualidade do trabalho de sua equipe continuará cada vez melhor.

PODER E POLfTICA 355

Resumo

• Polícica é u1na conseqüência nacural da nacureza hu1nana. Quando as pessoas trabalharn e1n grupo, existe uma autoridade li1nitada, que deve ser distribuída para pessoas diferences, com desejos e rnotivações diferentes.

• Todos os líderes têm restrições políticas. Todo executivo, CEO ou presidente tem parceiros ou superiores que restringen1 sua possibilidade de tomar decisões. Em geral, quanto nlais poder un1a pessoa tiver, tanto mais complexas serão as restrições sob as quais deverá crabalhar.

• Há vários tipos diferentes de poder político, incluindo recompensas, coerção, conhecin1ento, referência e influência.

• O poder é usado indevidamente quando aplicado de modo a não atender às 1netas do projeto. A falta de clareza nas metas, alocação de recursos ou processos de tomada de decisão obscuros, ou 1nás interpretações pode1n contribuir para o uso indevido do poder.

• Para resolver problemas políticos, esclareça as suas necessidades. Identifique quem pode ajudá-lo e avalie como você poderia obcê-las.

• Se você estiver participando no gerenciarnento de projetos, estará definindo um campo de ação polícico ao seu redor. Você decidirá quão ins;u10 ou justo ele será.

Créditos das fotos

PREFÁCIO, Frank Lee, www.jlee.co1n, Duorno, Florença, Icália

CAPfTULO l, Frank Lee, www..flee.com, Duon10, Florença, Icália

PARTE I, Scoct Berkun, Parque de Marymoor, Redmond, WA

CAPÍTULO 2, Scott Berkun, Interestadual 84, ldaho

CAPÍTULO 3, Scott Berkun, Intercâmbio 1-5, Seatde, WA

CAPíTUlO 4, Scocc Berkun, Parque Farrel Mc\Vhircer, Redrnond, WA

CAPÍTULO 5, Scocc Berkun, Universidade de °W"lshingcon

CAPfTUlO 6, Scotc Berkun, Capilano, Vancouver, Canadá

PARTE li , Jill Scurzman, u1wiu. uiweb.corn~jillart, Redmond, WA

CAPÍTULO 7, David F. Gallagher, www.lightningfield.com, NYC

CAPÍTULO 8, Scocc Berkun, Padaria em Queens, NYC

CAPÍTULO 9. Scocc Berkun, Scott & ]ili CAPÍTULO 10, Scott Berkun, Sea-Tac Airporc

CAPÍTULO 11, Scott Berkun, Pordand (perco de Po\vells)

PARTE III, ScoCT Berkun, Loja de livros usados, Desconhecido

CAPfTULO 12, Frank Lee, wwzujlee.com, Amscerdá

CAPÍTULO 13, Scocc Berkun, auto-retraco, Parque Nacional de Yellowstone

CAPÍTULO 14, Scott Berkun, Jogo de bola com vassouras #1, Brainerd, NO

CAJ•íTUlO 15, Scotc Berkun, Jogo de bola corn vassouras #2, Brainerd, NO

CAPÍTULO 16, Scocc Berkun, Torre Eiffel, Paris

Notas

Capítulo 1 1 A 1nente dos injciantes é u1n conceit.o introdutório do Zen Budis1no. A história canônica é aquela

da xícara vazia: se você se apegar ao que já possui, nunca haverá espaço para novos conheci1nentos. Consulte a obra de Shunryu Su'i til<i, Zen Mind, Beginner's Mind (Weatherhil, 1972).

2 The CJ-IAOS Report ('fhe Srandish Group) é um docurnento habi tualmente citado sobre orçamentos, cronogramas e falhas gerais de projetos de software. Consulte http:// standishgroup. comlsample_researchl.

3 Karl Popper foi tun notável filósofo da ciência, no século XX. Consulte http://en.xvikipedia.org/ zviki/Karl_Popper.

4 De Ja1nes H .. Chile.~, Inviting Disaster: Lessons fi·o1n the Edge of Technology (HarperBusiness, 2002).

5 U1n botn resurno de organização matricial e de ourros tipos de organizações pode ser encontrado na obra de Steven A. Silbiger, 1"he Ten-Day lvJBA (William Morrow and Company, 1993), págs. 139-145. Mas pratica1nente todo livro sobre teoria do gerenciamento discute este te1na.

6 Visite http:llunv111.ton1peters.co1n/col_entries.php?note=005297d)'ear=l991.

Capítulo 2 1 Cerca vez, ao al1noçar na Pizzaria Uno en1 Pitcsburgh, rneus an1igos e eu receben1os un1a

inforn1ação de que haveria tuna 1nesa pronta cm 1 O 1ninuros. Exaran1enre 1 O niinuros depois, nleu arnigo Chad McOaniel perguntou sobre nossa n1esa. O anfitrião nos disse que a mesa estaria pronta ern 10 rninutos. Chad perguntou "São os 1nes1nos 10 1ninutos ou são outros 10 1ninutos?". Ele não gostou da piada.

2 Você encontrará urna boa discussão cornparaciva dos rnécodos tradicionais e ágeis para o dcscnvolvi1nenro de software, cm Balancing Agility anti Discipline: A Cuide for the J>erplexed, de Barry I3oehn1 e Richard Turner (Addison Wesley, 2003).

3 Consulte a obra de Humphrey, Managing the Soft1vare Process (Addison Wesley, 1989) para obter urna discussão sobre corno definir, entender e gerenciar a mudança no processo de soft1u11re,

4 "Understanding and Controlling Sofavare Costs", IEEE Transactions on Sofavare Engineering, vol. 14, nº 10, oucubro de 1988, p<ígs.1462- 77; carnbé1n na obra de Barry Boehrn, Sofavare Engineering Econornics (Prentice Hall, 1991).

5 Os cronogra1nas baseados nos itens de trabalho do progra1nador são cha1nados de cronogra1nas de baixo para cima (bottom-up) porque a equipe cria esses cronograrnas. Os cronogramas basead<>s nas necessidades da gerência são chan1ados de cronogramas de cÍina para bai.xo (top-do1un). Con10 mencionado, geralinente ocorre tuna negociação entre esses dois cronogramas, para criar aquele a ser usado no projeto.

6 Isso ocorre porque u1n cronogran1a específico para uni projeto é realmente un1 dos vários cronogramas possíveis, Dependendo das contingências (falhas no design, revolução política, a praga ecc,) incluídas e consideradas pelo cronograma, é possível criar urna progran1ação nluito diferente para o rnesn10 volwne de trabalho. Se não foi investido qualquer esforço na investigação dos possíveis pontos de fàlha que deven1 ser considerados, há pouco 1notivo para acreditar que o cronograma ofereça u1na alra probabilidade de vir a concretizar-se do 1nodo corno foi defirtido. O autor do cronogran1a não foi suficiente1nente criativo ou cético para gerar um cronogra1na provável.

7 Pracica1nence rodo o rexco de gerencian1enco de projecos descreve un1 processo para criar estruturas analíticas de projeto. Voltarei a abordar esse assunto no Capítulo 14, 1nas se quiser urna

360 NOTAS

discussão completa, comece en1 http://en. wikipedia.orgl1viki!Work_breakdo1vn_structure ou Total Project Contro4 de Sr.ephen Devaux (Wiley, 1999).

8 A obra de Kent Beck, l:.xtre1ne l'rogram1ning Explained (Addison Wesley, 1999), oferece un1 1nodelo orientado por progra1nador para distribuir o trabalho, en1 que os próprios progran1adores seleciona111 os itens de trabalho. A idéia está certa. Un1a combinação saudável de interesse do programador, gerenciamento da equipe do programador chefe (quem é bon1 no quê, quem deve aprender o quê) e aspectos do design de engenharia deven1 orientar essas decisões. Deve ser um con1pro1nisso con1 o que é 1nelhor para o projeto e o que é 1nelhor para a equipe.

9 Consulte a obra de Beck e Fov,•lcr, Planning Extre111e Program1ning (Addison Weslcy, 2002), págs. 60-62.

1 O PERT é a abreviação de Progran1 Evaluation and Revie\v Technique. A fónnula padrão é: a 1nelhor estimativa + (4 x a mais provável) + a pior estimativa/ 6. Poré1n, há zillhões de variações e teorias para como efetuar o melhor cálculo das estimativas ponderadas.

Capítulo 3 1 Para obter outra co1nparação sobre os diferentes tipos de projetos de software, consulte http://

UJWW. joelo n sofouare. com/ ar ti eles/ Five Worlds. html.

2 Andrew Stellman, un1 dos revisores técnicos deste livro, 1ne ameaçou várias vezes de violência física se eu não fornecesse referências sobre a qualidade do software - um assunto profundo que simplesn1ente está fora do escopo desce livro (li a obra de H.oberc Pirsig, Zen and the A1·t of Motorcycle Maintenttnce). Dois locais para co1neçar: o livro de W. Ed\vards Denúng, Out of the Crisis (MIT Press, 2000), e o de Philip Crosby, Quality !s Free (Signec Books, 1992).

3 Faisal Ja,vdac, urn dos revisores r.écnicos desce livro, n1e a111caçou corn forn1as exclusivas de torturas psicológicas se eu não destacasse a ironia que foi o fato de eu ter continuado a trabalhar na Microsofr.

4 Esce é u1n comentário proposital1nence provocante, elaborado para fazer com que as pessoas se conscien cizern destas notas. Mas falern sério: quando designers crian1 para si 1nes1no, cende1n a superestiinar o design, t<tlve--4 favorecido pela liberdade de não rer uni cliente para o qual trabalhar.

Capítulo 4 1 Leia o livro de Daniel Schaccer, The Seven Sins of Me1nory (Mariner Books, 2002). ()u veja o

excelente filn1e, Me111ento. An1bos devem ajudá-lo a reconhecer a lin1itação e falta de confiabilidade da memória humana.

2 Extraído de J>i/oting J>afrn: The lnside Story of Palm, Handspring and the Birth oj'the Billion Dollar Handhefd lndustry, de Andrea Buccer e David Pegue (Wiley, 2002), p. 72.

Capítulo 5 1 A~ sirenes de alerta deveriam soar se1npre que u1na equipe tivesse o encargo de realizar urn

trabalho revolucionário, mas crabalhando a partir do mesmo processo de planejamento usado para o trabalho siinples e rotineiro. É co1no esperar que unia cirurgia do cérebro seja realizada co1n um kit de prin1eiros socorros. As n1ecas e o planeja1nenco não cornbinarn, portanto prepare-se para fracassar de n1aneira desorganizada.

2 Consulte "How to give and receive criticism", http:l!tvwzv.scottberkun.co111/essayslessay35.htm.

3 Un1 exemplo disso é o rninoxidil, un1 r11edican1ento para tratar de pressão alta sangüínea. Acontece que não ajuda muito nesse caso, mas era eficaz contra tun problema totalmente diference: a queda de cabelo. Julgado en1 relação a um crirério, a fórmula do n1inoxidil foi um fracasso; em relação ao outro, foi u1n sucesso. A fónnula foi uma boa idéia ou não? Depende do contexto ern relação ao qual foi considerada.

NOTAS 361

4 Contudo, uma fónnula si1nples de co1no fazer água e uma bí1ssola a partir da areia provavelmence venceria1n co1no 1nelhor idéia do ano e1n un1a co1npetição do tipo "Escou perdido no deserto". Este é urn cxen1plo de un1 problcrna bern-definido, in1possivel1nente difícil (do Capítulo l, é simples n1as difícil). Porcanto, se as pessoas vieren1 a reclamar que os requisitos e as definições dos problen1as retira1n o desafio da solução de problen1as, elas não sabern o que estão dizendo. As definições de problemas indicam o topo da montanha que deve ser atingido, n1as elas não revelam coisa algurna sobre como solucionar rodos os desafios de subir aré lá.

5 Foi n1uiro parecido corn os locais de trabalho descri ros e1n Peop/.eWare, de Toni DeMarco e Tirnothy Liscer, ou cn1 Planning Extreme Progr11mnúng, de Kent Beck e Marcin Fovvler.

6 Edição 4.02, fevereiro de 1996.

7 Recomendações: o livro de Sreve Krug, Don't lVfake Me Think, para obter os princípios gerais do design de \veb; GUI B/Qopers, de Jeff Johnson, que descreve erros comUils ocorridos no design de UI. Verifique http:llw1vw.11passoc.orglpeop/.e_pages/consuítants_directorylindex.html para conrrarar urn consulror de usabilidade ou design ou enrre ern conraro co111 o autor, en1 www.scottberkun.com/services.

Capítulo 6 1 Urn senri1nenro rnelhor captado pela n1úsica de They Mighr Be G ianrs, "Older": "This day

\vil! soon be ac an end, and no\v ir's even sooner, and no\v ir's even sooner. And no\v it's sooner srill" . ("Mais velho": "Esre dia logo renninará, e agora é cedo den1ais, e agora é cedo d e1nais. E agora ainda é cedo de1nais" .)

2 Segundo a perspectiva do GP, geraln1enre não in1porra o que ou onde esrão os checkpoints, desde que surcan1 o efeito que o GP necessita deles. En1 geral, é rnclhor deixaJ" a equipe sugerir os checkpoints porque isso aumenca a probabilidade de que acreditem neles e os respeiren1.

3 Consulte http:llw1v1v.1m.ftlmslprojectsltoolkindslorganize.html para obcer urna boa !isca de alcernarivas.

4 Consulre "The Are of UI Prororyping": http://wunv.scottberkun.com/essayslessayl2.ht1n.

5 Observe que ernbora sua equipe não seja responsável pelos usuários, en1 algurn lugar do carninho seu algorirn10 ou banco de dados realn1enrc se enconrra co1n as pessoas reais, e as decisões que você tomar as afetará.

6 Já quesúonei esse n1es1no aspecto con1 ourros gerentes. Eles não poderian1 supor não perrniúr que a equipe codificasse a rodo vapor, o tempo rodo, independencen1ente que os progra1nadores renharn entendido para onde o projero estava indo. Se os prograrnadores escavam ociosos, o projeto deve escar inativo, certo? Errado. Há uma hipocrisia aqui: se o terupo do progra1nador é tão importante, o uso desse re1npo deve ser be1n-planejado. "O que os progran1adores farão?", eles 1ne pergunraria1n. E eu diria "Esperarão por urn plano que co1npense o ren1po deles ou ajudarão a

. á 1 ,, equipe a enconcr, - o.

Capítulo 7 1 Por esse mocivo, algurnas equipes colocarn especificações no controle de versões, co1n bloqueios de

check-inlcheck-out para apoiar a possibilidade de que várias pessoas edire1n o docun1enro se1n pisotear tunas às outras. Geralmente é u1na angúsria, 1nas cornpensa. Em norícias sen1ell1m1tes, rer urna n1aneira de indicar o que rnudou de urna versão para outra econo1ni2a ternpo. Nada é rnais frustrante do que vaguear ern un1 docun1enco, cenrando descobrir o que esrá diference en1 relação à versão anterior. Diferentes ferran1enras ou autores que registran1 alrerações no próprio docun1enro ("20/03/2004 - acrescentado um detalhe na seção 6") são dois métodos con1uns.

2 Por mais sarcástico que possa parecer, é verdade. Na realidade, o conceito da gestão do conhecimento é, em parte, baseado nessa idéia de fornecer docu1nenração de coisas que, de ourra fonna, desapareceria1n se alguém, digarnos, não cornparecesse para a versão seguinte.

362 NOTAS

3 .t. se1npre un1 sinal de aviso quando consulto especificações belas ou extre1namente longas. Isso in1plica que alguérn esrá rnais preocupado corn a especificação do que corn o que pode esrar rolando lá fora. De n1odo sen1clhanre, as especificações rnuico longas geralrnente indicar11 que não são lidas por ninguén1. Suponha que, se eu estivesse construindo arrnas nucleares ou equipamentos cirúrgicos (ou sisren1as integrados a esses irens), eu reria outros sentimencos, mas a 111aioria dos projetos de softtvare não exige níveis de deralhamenro rigorosos.

Capítulo 8 1 Treinar através da sirnulação é a melhor maneira de desenvolver habilidades de cornada de

decisões. Já vi sinnrlações que colocan1 os escudantes, ao invés do processo, no centro da experiência. Consulte Serious Games, de Clark Abt (Viking, 1970). Utilizo essas idéias en1 meus cursos.

2 l'he 1en-Day l11BA, de Steven Silbiger (Quill, 1999) contém um capítulo con1pacto e simples sobre a an;llise quantitativa e sobre a teoria básica da árvore de decisões. Acuna de tudo, o livro tàz urn bo1n trabalho ao fornecer urn resu1110 sucinto dos principais assuntos abordados na 1naioria dos progran1as irnponances da MBA.

3 A frase cornplera é "morros por 1.000 cones" - como nos corres de papel. Cararnba.

4 Geralrnence, isso ocorre en1 situações con1pecicivas. A ação rápida pode deslocar o que, no jargão militar, é chamado de farelo da incerteza. Ao comar tuna acicude antecipada, você obriga o concorrente a asstunir unia postura ágil e torça-o a responder. Para fazer isso de 1nodo cficicnce, é necess<írio conceber urna esrrarégia e criar planos coerentes no decorrer dos aconrecirnencos: unia habilidade que poucas pessoas possuen1 e nas quais deseja apostar suas forças annadas/e1npresas. Ern geral, que111 sente que está na vancage1n (recursos, talentos, terreno) ern sua estratégia torna esse tipo de iniciativa.

5 Unia história curta de lista de prós/conrras pode ser encontrada no panfleto, "Hotv to Make a Decision" (2003, Who's There, lnc.), que pode ser adquirido e1n http:lhvw1v.knockknock.biz. Ern 32 páginas divertidas, esse título abrange técnicas, como cara ou coroa, pedra-papel-tesoura, minha-111ãe-1nandou-eu-escolher-este-daqui etc.

6 O ponto fraco da Navalha de Occan1 é a sua vulnerabilidade aos máxi1nos locais. Por exe1nplo, se você estiver en1 urna n1onranha e não puder enxergar nada no horizonte 1nais alco do que você, a conclusão n1ais sin1ples é a de que você estaria no ponro n1ais alto da Terra. Pode haver informações que você não cen1, que, se tivesse, invalidaria sua sin1ples conclusão.

7 Eu escava cerro? Bem, é impossível saber. No dia posterior ao de minha decisão, nosso desenvolvedor-chefe, Chee Che\v, decidiu fazer o trabalho sozinho. Se1n contar nada a 1niin ne1n a ningué1n, ele trabalhou urn dia e u111a noite inteiros, e conseguiu concluir o trabalho, por conta própria. A esrirnariva inicial de 5 dias foi projetada por alguérn con1 nienos experiência con10 co111ponente, e ele conseguiu fa1.er as panes principais ern niet~ide desse ternpo. A propósito, fui à sala dele no dia seguinte e tive unia surpresa. Ele sorriu para niin1 e 1ne niosrrou a versão do navegador, com as n1udanças i1nple1ncnradas por ele. Eu fiquei esci rnulado e horrorizado, ao rnesrno tempo.

Capítulo 9 1 Brueghel era urn pinror fla1nengo no século X\11, tàn1oso por pintar paisagens e cenários

carnponeses. Você pode consultar seu quadro Ton·e de Babel, e sua biografia cornplera, en1 http:// en.wikipedia.orgltvíki/Pieter_Brueghel_the_Elder.

2 Como diz Pecer, "Se você não coscun1a passear (nas salas das pessoas], o início dessa ca1ninhada será, resu1nindo e1n urna única palavra, aterrorizante . .. ". De1nora construir esse ripo de entendi1nento co1n as pessoas, principalmente com aqueles que têm motivos para ce1nê-lo.

3 Não consegui encontrar referência a essa estrutura. Ouvia os co1nenc;írios das pessoas, trans1nitia niensagens, recebia n1ensagens e cornpreendia, rnas apesar de n1inha pesquisa, não consegui achar

NOTAS 363

u1na fonte de referência. Acrescentei as duas últimas por conta própria. Outra estrutura boa é o 1nodelo Satir, que Weinberg usa e1n vários de seus livros. Consulte The Satir l'vfodel: Farnihi Therapy and Beyond, de Virginia Satir ec ai. (Science and Behavior Books, 1991). Si111, este é un1 livro sobre terapia. E sim, se isso o inconioda, provavelniente ele é exatamente o cipo de livro que você precisa ler.

4 ÀJ;, vezes, uma concordância pode ser rão simples quanto determinar qual pessoa roniará tuna cerra decisão. Você não precisa rer wn apoio 11nâni1ne para algunia coisa., para discernir que uma pessoa está na 1nelhor posição para roniar a decisão. Consulte o Capítulo 8.

5 É possível encontrar tuna lista abrangente de diálogos con1 golpes baixos, adequadan1ence classificada e coni exen1plos, en1 http://www.vandruff.co111/art_conve1-se.htrnl. Atenção, por favor, não use essa !isca conio uni 1nanual a ser seguido.

6 "foda esrimaciva de trabalho cem seus problemas. Linhas de código Ílnplicani eni quantidade, não eni qualidade. l-loras i1nplicam em duração do trabalho, não e1n intensidade.

7 A coisa inteligente, 1nas secreta, a ser feita é preparar um convire para ambas as equipes, independente1nenre de que.m vencerá. Encreranco, não revele às equipes acé que a con1pecição ccnha ccrn1inado.

Capítulo 10 1 É desconcerrance, mas mantive essas pequenas anotações de agradecÍlnenco por email aqtú e ali,

provavelmente porque não houve um elogio suficienremence exteriorizado, pairando no ar, enlitido pela alta gerência. O IM e o enuiil não ofereceni equivalentes a assencir co1n a cabeça ou sorrir, o que en1ice u1n con1encário secundário durante as reuniões: talvez esses e-niails colaterais con1pensen1 isso de algunia nianeira.

2 Unia história possivelnienre forjada sobre Vicror Hugo descreve unia ucilização niuiro inteligente da coniunicação con1pacra. Quando a obra Les Misérables foi publicada, Hugo enviou u1n celegrama a seu edicor indagando qual tinha sido a reação inicial. Esse telegra1na foi o 1náxi1no conciso possível, consistindo ern um único caractere: "?". A resposta recebida ta1nbérn consistia ern u1n único caractere. "!". Aparenternente, as primeiras vendas fora1n espetaculares. Se h<í tuna lição aqui, é que duas pessoas que se conhece1n e se entende1n 1nuíto bem geralinente se con1unica1n con1 rnais eficiência do que as outras pessoas. Este tanibém é oucro niorivo da inipoi:cância de se desenvolver relacionarncntos coni os colaboradores.

3 Provavel1nente, deve haver algunia lei da coniunicação que reivindique que o modo do1ninante da comunicação (emai~ ainda depende do niodo anteriormente dominante (telefone) como sua retaguarda IM -+ Email -+ telefone -+ correio -+ sinais de fumaça -+ face a face -+ etc.

4 Dois bons locais para irúciar são The Facilitator's Fieftlbook, de Tom Justice (Arnerican Managenienc Associat.ion, 1999) e Mining Group Go/d, de Thonias A. Kayser (McGra\v-Hill, 1991 ).

5 Para obter niais inforniaçóes sobre SCRUM, consulte http:llc2.cornlcgi/u;iki?ScrurnMeetings ou http :llzvww. controlchaos. corn/.

Capítulo 11 1 U1n hábito destrutivo comum, principaltnente entre os hornens, é fingir que nada os aborrece. f a

conhecida negação . . En1 algu1n nível e1nocional, tudo nos afeta. As pessoas co1n niais consciência são cha1nadas de - prepare-se! - saudáveis. Tenha senti1nentos e investigue-os. Eles são bons para você.

2 Isso é cultural. Já fiz parte de equipes que rinham unia cultura de comunicação muito boa. Os assuntos permaneciani ínrimos, até niesmo coni sere ou oiro pessoas na sala, inclusive sobre temas conrroversos. Conrudo, a 1naioria das equipes não cul riva esse ripo de inrÍlnidade. Para cobrir terreno rapida1nenre, você ren1 que co1neçar por baixo, ro1nar fôlego e depois convidar as pessoas.

364 NOTAS

3 Em termos rudin1entares, a Lei de Brook afi.rma que acrescentar pessoas ten1 dois efeitos negativos: pri rneiro, dernora algurn ten1po para ganharern agilidade; segundo, aurnenrarn os custos indiretos necessários para que as coisas sejan1 concluídas. Sendo assirn, até n1esn10 nas rnelhores situações, acrescentar n1ais pessoas resultará un1 valor decrescente. i'v!as há exceções.

4 Isso faz parte da Lei do Ritn10 de Brand. Extraído da pergunta anual da revista Edge, que en1 2004, era "Qual é a sua lei?" Consulte http:llwwzv.edge.orglq2004!page6.htrnl#brand.

5 Consulte ta1nbé1n Bargainingfar Advantage, de G. Richard Shell (Penguin Books, 2000). Essa obra fornece outras táticas e técnicas do que Getting to .l-és, e é u1n excelente segundo livro a ser indicado.

6 É exatan1ente aí que as negociações se tornam con1plexas. Se Fred não acreditar que você deseja usar suas opções, ele consultará sua BATNA de n1odo diferente. Ele pode dizer assin1 ("Você não vai me deixar sentar aqui e morrer, vai?"). As negociações se rorna1n complexas quando as pessoas fingem, mente1n sobre seus interesses ou não confian1 na outra parte. Ern situações n1cnos rneciculosas, as coisas tendern a se norrnalizar à rnedida que as B.ATNA~ são execuradas. Se u1na e1npresa puder realn1ente conseguir urna boa negociação, ern algun1 1no1nento, seguirão eni frente. Se não for possível, entregarão os pontos.

7 Para obter un1a apresentação inforn1al à dinân1ica e1nocional bá~ica, exrunine a 1naravilhosa obra de Leo F. Buscaglia, Living, Loving & Learning (Ballantine Book~, 1985). Para uina apresencação 1nais formal, tente Bnulshau1 On: The Fnmily, de John Bradsha,v (Health Comrnunications, 1990).

8 Urna perspectiva rnais favorável de se examinar as iniciativas é que a força criativa, necess<fria para inovar só nasce e1n u1n grupo reduzidíssi1no de pessoas que trabalha1n ardua1nente. U1na "redução" de pessoas é desejável porque concede rnuita autonomia a todos. Hackers and J>ainters, de Paul Graham (O'Reilly, 2004), apresenta argurnenros interessantes sobre as recornpensas e os riscos de en1presas recérn-estabelccidas.

Capítulo 12 1 Rob e Eric, do Samuel Field Y, ern Douglaston, Ne,v York 1ne ensinaram 1nuito mais sobre treinos

e gerenci<unento do que os treinos de basquetebol no segundo grau e na f.1culdade, que tive posterionnente. Se você conhecer esses rapazes, peça-lhes para entrar en1 contato cornigo.

2 Ern várias organizações 1nilirares, son1ente as situações descritas corno incidentes ou rnissões exigern dehriefings. Sendo assin1, se algo estúpido acontecer, e ninguén1 for culpado por isso, e o irnpacto for 111ínirno, pode não haver sequer unia lição, e não con1pensa o esforço de ser 111uito considerado. Na verdade, a melhor resposta poderia ser expressar que sua aprovação não é necessária para questões menos importantes, semelhantes a esta, posteriormente.

Capítulo 13 1 O padrão não era "Essa pessoa pode fazer isso?", rnas "Essa pessoa saberá quando buscar ajuda

para as situações que estiveren1 alén1 de sua co1npetência?". Este é apenas 1nais uni tipo de situação con1 a qual lidar.

2 Para obter uma discussão adicional sobre como dizer sin1 e não, consulte o ensaio de H.ichard Brenner, "Saying No: A Short Course for J\1anage1)-" e1n http:llunvw.ayeconference.co1n/Articles/ Sayingno.htinl.

3 Vários n1anuais de gerencian1enro de projetos discutern 1ninuciosarnente a análise do carninho crítico. Existe un1 resun10 en1 http:llen.zuikipedi.a.orglwiki/Critical_path. Para obter unia discussão 111ais abrangente, consulte a obra de Stephen Devaux, Total Project Control (Wiley, 1999).

Capítulo 14 l Karl von Clause\vicz foi tun influente pensador 1nilitar prussiano do século XIX. Consulte http://

en. wik ipedia. orglwikil Clause1uitz.

NOTAS 365

2 CMi\1, o Capacity Maturity Model (Modelo de :N(aturidade da Capacidade) para o desenvolvi1nenco de sofavare realizado pelo Softtvare Engincering Insticute, definiu várias prácic.'ls consagradas para o gerencia1nento do 111eio-jogo no nível de projecos. Consulte http:ll wu1w2. ummsd.edu!SWP Ilseiltr25fltr 25.htrnl ou http:llzvwrv.sei. cnu1.ed11/anml.

3 Para isso, há métodos fonnali1.ados. Algu1nas equipes fazen1 unia reunião se1nanal, onde a pipeline de cada programador é rapidamente discutida: rodos conhecem os irens de trabalho da equipe, e para os indivíduos, os da sen1ana. O GP certifica-se de que os problernas de cronogran1a estejam inregrados à piptdine.

4 En1 projetos que usan1 inrensa111ente a interface do usuário, o gerencia111enro da pipeline da codificação nos pennilia fazer a iteração do design. Fazían1os co1n que a pipeline integrasse o iten1 de crabalho A, incluían1os no laboratório de usabilidade, aprendíamos muito con1 rodo o niarerial, aprimorávan1os o design e depois fazía1nos as partes restantes de A. Desde que 1nancivésse1nos a pipeline cheia, e não ulrrapassássen1os o orça1nento previsto para o período ele desenvolvi1nento ou do marco, os designers poderiarn desenvolver o trabalho de design da UI de baixo/inédio nível, paralelainenre à equipe de progra1nação.

Capítulo 15 1 Son1a zero é un1 tern10 de teoria de jogos que significa uni conjunto finito de recursos. Fatiar uni

bolo de chocolace en1 pedaços é uni jogo de son1a zero: se eu ganhar 111ais, sobrará 111e11os para você. Porérn, ir a urna cafeceria infinitamente be1n-estocada e solicicar fàtias de bolo é urn jogo de soma não-zero: poderemos obter o quanto quisermos. Hum!!!

2 Con10 alternativa, quanto 1nenos be1n-definidos fore1n os seus critérios de saída, 1nenores serão suas chances de curnprir seus cornprornissos. O C.'\SO lirnice é não cer crir.érios de saída, quando você dependerá da opinião e dos caprichos da gerência para saber quando você rerrninou.

3 Para obrer 1nais inforrnações sobre planos de tesre e n1ccodologia geral de QA, consulce Managing the Test f>rocess, de Rex Black (M icrosoft Press, 1999). Se você leva a sério a qualidade, ela deverá integrar o documento de visão do projeto e o processo de planejamento.

4 Da obra de \V'einberg, Qualíty Sofware Manage1nent: System Thinking (Ooreser House, 1991), págs. 272- 273.

5 lbid.

6 É possível encontrar u111 bon1 resu1110 das ferran1e11tas e processos que pode111 ser utilizados, en1 http :llwww. martinjowler. comi articlesl continuo us l ntegratio n. htrn !.

7 Consulte o ensaio de Joel Spolsky, "f>ainless Bug 7i-tzcking' en1 http:llivw1v.joeíonsofavare.co111/ articles!fog0000000029.html.

8 Dois livros que valen1 a sua lei cura, se você precisar desse cipo de rigor: a obra de To1n DeMarco, Contro!Ling Sofav1zre Projects (Prencice Hall, 1986) e a de Gerald Weinberg, Qu.ality Sofavare Management: Systems 1ninking (Oorset Housc, 1991).

9 O desenvolviinenro orientado por resres é un1a abordage1n t'.1ril paca lidar previamenre co1n a qualidade da engenharia, e evitar grandes ondas de novos bugs. Consulte http:!len.wikipedia.orgl wiki!Test_driven_deveíop111ent.

10 Da obra de Weinberg, Quality Software Management: Syste11'1s Thinking (Dorser House, 1991 ), p. 250.

11 Evidenten1ence, quanto 1nelhor for a engenharia do sofavare, canto n1ais fácil será prever o in1pacco das 1nudanças.

12 Consulce http.ilw1v1v.scottberkun.comlessaysl para obcer orienração sobre con10 realizar pós-rnorces de rnodo eficiente.

13 Os líderes de u1n projeco cerão u111 force investin1enro cn1ocional no que aconteceu e tcncarão ser objetivos. Encrcranco, uni especialista externo não tern esse tipo de investirnenro nen1 un1a história pessoal e, ponanco, terá 111ais chances de êxito ao examinar, conhecer, relatar e fazer considerações sobre o projeto.

Capítulo 16 l Nunca subestirne o valor de um espaço de trabalho be1n-posicionado. Aprendi rnuito sobre o que

escava acontecendo aci1na de 1ni1n, na gerência, a partir desse local. Eu pude ter conversas infonnais com todos os tipos de pessoas que esrava1n procurando por Chris, e pude ouvir por acaso conversas in1porcantes pelos corredores. A desvantagen1 é que o chefão estava exatamente na porta ao lado. Se fosse un1 gerente con1 problen1as de controle ou de nlicrogerenciamento, haveria proble1nas graves nesse local.

2 Exu·aído do Rant/{)rn House College Dictionr11y (1999). 3 Sei que estou 1ne esquivando do debate ético sobre que co1nporca1nento é i1noral, ou até sobre que

tipos de projetos podem ser considerados con10 detentores de n1etas dcn1oníacas. Contudo, direi que acusações sen1 dar direito à defesa, nlentiras e atos inventivos de decepção geralmente prejudican1 un1 projeto. Isso favorece ganhos de curto às custas do valor e da confiança de longo prazo da equipe.

4 O desafio de forçar 1nudanças organizacionais é significativo. Leia real1nente sobre o assunto antes de avançar por conta própria. Comece com Lea,;/ing Change, de John P. Koccer (Harvard Business School Prcss, 1996).

Bibliografia comentada

Livros e outras 1nídias constam nesta bibliografia por u1n dos dois seguintes 1notivos: ou tiveram influência máxima sobre rninhas idéias ou são de suma importância para a leitura e investigação futuras.

Filosofia e estratégia

de Botcon, Allain, The Consofations o/ Philosophy (Vintage, 2001) ISBN 0679779175 A filosofia do gerenciamento remece muito às filosofias oriental e ocidental, e este é um bom lugar para começar. Conheci e me lembrei mais da filosofia ocidental com este livrinho, do que ern vários anos de ensino filosófico na universidade. de Botton escreve ensaios curtos, que fàzern refletir, informais, divertidos, cordatos e 1ne1noráveis. Costu1no dar este livro às pessoas quando dizem que estão interessadas em filosofia mas não sabem por onde corneçar.

Russell, Bertrand, The Conquest o/ Happiness (Liveright Publishing Corporation, 1930) ISBN 0871401622

Pessoas felizes gera1n gerentes rnais eficientes. En1bora eu duvide que seja possível conquistar a felicidade, este livro o ajudará a identificar o que o faz feliz e por quê. Russell era u1n filósofo notável no século XX e apesar disso, ele escreve nluiro bem. Ele era u1n tanto desordeiro e uma pessoa de mente aberta, e isso transparece no que ele escreveu. Li pela primeira vez esse livro na estrada, em uma viagem co1n Chris McGee, de Seattle para Banff. Comecei a viagem muito insatisfeito com a vida em geral, e voltei preparado para fuzer mudanças. Este livro, Chris e a viagem em si influenciaram na minha decisão de sair da Microsoft e começar a escrever.

Tzu, Sun, Art o/ War, Pocket Edition (Shambala, 1991) ISBN 0877735379 Este foi o primeiro livro de filosofia oriental que fez algum sentido para mirn. Recornendo-o por sua sirnplicidade e por ser muito curto. Foi escrito como um livro de estratégia militar, mas cem várias aplicações práticas. Durante muitos anos, carreguei em meu casaco a edição de bolso desce livro, até sua capa rasgar e metade das páginas ficarem viradas para baixo (uma década atrás, encontrei Faisal Jawdat, que ocasionalmente viria a ser um revisor técnico desce livro, no Centro Esrudancil da CMU, e ficamos surpresos ao ver o outro puxar do bolso a mesma edição deste livro). Se você achar esse livro muito obscuro ou abstrato, experirnente a obra rnais direta e divertida Essential Crazy Wisdorn de Wes Nisker (Ten Speed Press, 2001) ISBN 1580083463.

Psicologia

Zeldin, Theodore, An lntimate History oj'Humanity (Vintage, 1998) ISBN 0749396237 A natureza humana é mais vibrante e complexa do que supomos. Esta coleção atípica de ensaios, baseada em entrevistas pessoais, analisa o que nos fàz quem somos. Achei este livro inesperadamente comovente. Não se trata de um livro cienrífico formal sobre psicologia: é mais urna coleção de ensaios escritos por um homem muito inteligente, . . cunoso e pensanvo.

368 BIBLIOGRAFIA COMEN1-ADA

High Noon. 1952. Lionsgace/Fox. 2004. DVD. Um filine clássico de t'lroesce sobre u1n xerife cencando fazer o que acha cerco. A liderança e integridade colocam inevicaveln1ence un1a pessoa em sicuações e1n que pode ficar isolada. Esce filn1e investiga a psicologia dos líderes e seguidores en1 situações difíceis. Mostra por que as pessoas são definidas tanto pelo que querem ser, canto pelo que não são. Ele é apenas um bom furoeste, com Gary Cooper.

Twelve Angry Men. 1957. MGM/UA Video. 2001. DVD. Outro filme importante sobre psicologia humana e dinâ1nica de grupo e1n situações difíceis. l-lenry Fonda desempenha o papel de um membro do júri que acredita em algo que todos os outros não crêem. Ele, então, tenra convencer uma sala repleta de pessoas frustradas de que aquilo no qual elas tanto acreditam não pode ser verdade. Como em High Noon, os questionamentos sobre o poder, a influência, integridade e convicção são temas centrais, e rodos são importantes para as pessoas que lideram ou gerenciam outras pessoas. Ta1nbém é um clássico da indústria cinen1atográfica, dirigido por Sidney Lumet (autor do perfil altamente recomendado do processo de produção de filmes, Making Movies, Vintage, 1996), e co1n Henry Fonda corno procagonisra.

História

Boorstin, Daniel J., The Creators: A History of J-!eroes of the lrnagination (Vintage, 1993) lSBN 0679743758

A série de três livros de história de Boorstin (The Discoverers, The Creators, The Seekers) vale seu peso em ouro. The Creators acompanha história ocidental, em um esforço criativo de arquitetos, p intores e escritores até engenheiros. Ele considera as anedotas e histórias que fuzem parte de suas perseguições diretarnence relevantes e inspiradoras para que1n estiver tentando realizar atualmente u1n trabalho criativo.

Kidder, Tracy, Soul of a New Machine (Back Bay Books, 2000) ISBN 0316491977 Este livro capta o espírito da primeira revolução dos compucadores, quando o foco repousava sobre a engenharia elécrica e de hardware. O ponto forte desce livro é a possibilidade de Kidder capturar a compulsiva e obsessiva unidade que os engenheiros têm que construir e criar. Apesar de a história girar e1n torno das n1<Íquinas e nlinicomputadores Data General que estavam construindo no final dos anos 70, ainda acho que esce livro resgata os desafios pessoais e da equipe do trabalho no secor técnico.

Kranz, Gene, Failure Is Not an Option (Berkeley, 2001) ISBN 0425179877 Um relato aterrorizante das experiências de Kranz no grupo de orientação de vôos da NASA. Ele cobre as primeiras missões Mercury até a Apollo 13. Há muitas lições aqui para os gerentes de projeto sobre como trabalhar com prazos, compro1netendo-se em entregar o que, na verdade, são experimentos, e como con1andar e gerenciar engenheiros sob pressão.

Gestão e políticas

Farson, Richard, Management of the Absurd (Free Press, 1997) ISBN 0684830442 Ao usar os paradoxos e irracionalidades do co1nporta1nento humano nas organizações, este livro investiga como deve ser o bom comportamento no gerenciamento. É uma leitura divertida principaln1ente porque trata de vários assuntos que os outros livros

BIBLlOGRAFlA COMENTADA 369

temem discutir. Farson argumenta que alguns problemas são compreensíveis e solucionáveis apenas com ajuda de nossa intuição, e que contar unicamente com a lógica geralmente nos causa problemas.

Fisher, Rodger, Getting to Yes (Penguin Books, 1991) ISBN O 140157352 O n1elhor livro de negociação por página de leitura que conheci. É bem escrito, sin1ples e prático. Alcan1ence recomendável.

Klein, Gary, Sources o/ Power: How People Make Decisions (MIT Press, 1999) ISBN 0262611465

Esra 1-<>i a fonte principal do Capítulo 8. Nela encontrei explicações e pesquisa que me ajudaram a entender minhas diversas convicções sobre a tomada de decisões.

Silbiger, Steven, The Ten-Day MBA (Quill, I 999) ISBN 0688137881 Já li 1nuitos livros comerciais de carácer geral, mas este é o único que consulco com maior freqüência. Ele aborda 1 O temas básicos de 1nuitos progra1nas MBA, indo direto às idéias e filosofias principais contidas e1n cada um deles. Soa 1nais con10 observações para um bo1n livro-texto: é evidence que alguns fonnaJis1nos forain evitados e, em vez disso, o autor fornece suas próprias explicações menos fonnais e 1nais fáceis de entender para dererminados conceitos.

Quick, Tho111as, Power Plays: A Cuide to Maximizing Performance and Success in Business (F. Watt, 1985) ISBN 0531095827 Escolhi este em u1na pilha de livros antigos. Tornou-se u1na das referências 1nais úteis do Capítulo 16. O livro é vagamente de auto-ajuda, no sent.ido de que renta apresentar u1na estrutura para as políticas organizacionais e conselhos sobre co1no atingir determinadas metas. Ele forneceu a maior quantidade de rácicas que encontrei, e administrou as questões éticas relativamente be1n. Quando meu livro escava sendo escrito, este estava esgotado, mas deve estar disponível através dos sebos on-line.

Ciência, engenharia e arquitetura

Brand, Stewart, 1-Iow Buildings Learn: What Happens After They're Bui!t (Penguin Books, 1995) ISBN 0140139966

Este texto acelerou n1inha convicção de que tudo o que eu aprendi sobre projetos e design no setor tecnológico podia ser aplicado e era importante, em rennos gerais, para o mundo. Este é um de 1neus livros favoritos sobre arquitetura devido à sua apresentação: muitas foros e exemplos. Brand escreve e pensa co1no um bo1n professor, tornando as coisas interessantes e, às vezes, divertidas, ao conduzir sua curiosidade por caminhos inteligentes e repletos de revelações.

Chiles, John, Inviting Disaster: Lessons from the Edge of Technology (H arper Business, 2002) ISBN 0066620821

Desde desastres aéreos até naufrágios de plataformas petrolíferas, as histórias contidas neste livro destacam a relação diret<t existente entre a complexa engenharia e seus pon tos fracos, frágeis, simples, não-lineares, que podem conduzir a desastres. Embora considerado 1nais co1no u1na série de longos ensaios sobre desastres específicos, do que como um livro com um cerna central ou conectado, achei rodas as histórias sobre desastres tecnológicos interessantes e que fazem refletir.

370 BIBLIOGRAFIA COMEN1J\DA

Cross, Hardy, Engineers and lvory Towers (Ayer, 1952) ISBN 08369 l 404X Enconcrei duas referências a esce livro no 1nes1no dia, e1n maceriais se1n quaisquer ligações, senci-me compelido a explorá-lo e enconrrei o resouro. Trara-se de uma longa argumencação feica por u1n engenheiro sobre o esrado da engenharia por volra de 1952. Ele questiona acitudes conhecidas entre engenheiros, desde a arrogância geral até a falta de ética ou de conhecimento artístico, e fornece dicas para uma visão m.elhor e detalhada do que a engenharia deveria ser. Acho que este livro é o que eu esperava da obra Existential Pleasures of Engineering, de Samuel Florman.

Petroski, Henry, To Engineer Is Human: The Role of Failure in Successfal Design (Vintage Books, 1992) ISBN 0679734163

Um clássico sobre a impossibilidade de evitar a falha e como aprender com ela é uma parte importante do avanço da engenharia. Petroski analisa vários desastres de engenharia, desde a ponte de Taco1na Narrows até o ônibus espacial Cha.llenger, e expõe as falhas teóricas e técnicas relacionadas. Be1n redigido, curto e, de algu1na forma, inspirador.

Processo de software e metodologia

Beck, Kenr, Extreme Programming Explained: Embrace Change (Addison Wesley, 1999) ISBN 0201616416

Este pequeno livro explica a incenção e a l·llosofia do XP e apresenta alguns princípios básicos sobre como fazer acontecer. É espirituoso e apaixonante, mas geralmente soa mais como um contexto espiritual, do que como um manual. Explica as iterações, velocidade, histórias e outros processos importantes do XP, enquanto expressa simulranea1nente suas vantagens. Examinei vários outros livros de programação extrema e ágil e, em minha opinião, eles geralmente termina1n se sobrepondo bastante à cobertura aqui apresencada. Planning Extrerne Prograrnming (també1n de autoria de Beck) foi o único rexco adicional sobre XP que considerei suficiencemence úcil para gerar observações a parcir dele. Traca-se ruais de um livro de procedimencos do que "a filvor de urna mudança" (embora a primeira 1necade não chegue a se sobrepor demasiada1nence).

Brooks, Fred, The Mythical Man-Month (Addison Wesley, 1995) ISBN 0201835959 Esce grande clássico, publicado pela primeira vez há mais de 20 anos, continua valendo para diversos aspectos in1porcantes. Brooks escreve be1n, usa mecáforas forces e deixa você se sencindo como se tivesse conversado com alguén1 muito mais inteligente e a1nisroso do que você. Talvez seja o livro 1nais fa1noso e respeicado sobre gerenciamento de projetos de desenvolvimento de sofo,vare.

Bullock, James e Gerald Weinberg, Roundtable on Project Managernent-. A SHAPE Forum Dialog (Dorset House, 2001) ISBN 093263348X

Uma coleção de conversas resu1nidas do grupo de discussão SHAPE, de Weinberg. Adorei este livro. Ele capta o espírito e a energia de estar em u1na conversa corn várias pessoas muito intel igentes e experientes, generosas quanto ao compartilhamento de seus conhecimencos. Elas discutem vários tópicos sobre o gerenciamento de projecos de software, desde a concepção do projeco, cronograrnas, conflitos e polícicas de gerenciamento. O livro é curro. Baseia-se em conversas, de modo que é mais sobre conversas e falácias do que u1n livro de cearia e manual de estratégia.

BIBLIOGRAFIA COMENTADA 371

Cockburn, Alisrair, Agile Software Devefopment (Addison Wesley, 2001) ISBN 0201699699 A segunda metade deste livro te1n u1na excelente cobertura da 1netodologia do desenvolviinento de software, e reflexões para os possíveis criadores de 1netodologias. Este livro é 1nuico referenciado (às vezes acé den1ais) e oscila encre um guia prácico e um livro­texto baseado em teoria de alto nível. Se gosta de um mix de ambos, ele serve para você.

DeMarco, Tom e Ti1nochy Liscer, PeopleWare (Dorsec House, 1999) ISBN 0932633439 O clássico livro de gerenciamenco sobre progra1nadores como seres humanos. Ele humaniza o processo de desenvolvimento de software, capeando a importância do ambiente profissional e social para tornar as pessoas produtivas. O enfoque sobre equipes e desempenho em relação a hierarquias e regr-as torna esse livro uma bênção para os gerentes principiantes em ambientes profissionais no setor técnico. Traz centenas de sugestões e recomendações, este é um dos melhores.

Friedlein, Ashley, \%b Project Management (Morgan Kaufmann, 2001) ISBN 1558606785 Passei 1nuito tempo procurando bons livros principal1nence sobre gerenciarnento de desenvolvirnenco para a Web. Não encontrei 1nuitos. Este foi o único a parcir do qual consegui gerar boas observações. Embora seja escrito, em grande parce, sob a perspectiva de empresas de desenvolvi1nenco para a Web e do trabalho contratado, isso não interfere no aconselhamento. Friedlein oferece uma 1necodologia simples e muicas hiscórias e escudos de casos, e capta a interação das funções (design, ceste, programação erc.) necessária para viabilizar a produção de redes de alta velocidade.

Hu1nphrey, Watts, Managing the Software Process (Addison Wesley, 1989) ISBN 0201180952

Humphrey é un1 dos grandes pioneiros no trabalho de engenharia de software. Este foi o livro mais acessível e aplicável dencre os seus, que encontrei. Ele discorre sobre o SEI CMM (Capacity Maturity Model, http://wwiv.sei.cmu. edulcm1nlcmmslc1nms.html) em detalhes. Oferece conselhos gerais sobre o gerenciamento de desenvolvimentos para diversas situações relevantes. Saiba que o texto escrito, geralmente bem-escrito, ocasionalmente pode ser seco: é um livro-texto (e com preço adequado). Os exemplos e a filosofia são mais aplicáveis às organizações de grande porte.

McCarthy, Jim, Dynarnics oj'Software Development (Microsoft Press, 1995) ISBN 1556158238

U1n dos primeiros livros que li como gerente de progra1nas na 't-.1icrosoft. McCarchy, ex­gerence de desenvolvimento do Visual C++ na Microsoft, divide o pessoal técnico do software de remessas em partes pequeníssimas, classificadas de modo rudi1nentar pela cronologia no processo de desenvolvi1nento. Este livro é u1na das minhas primeiras recomendações aos novos gerentes de programas da Microsoft: ele capta a atitude do GP da velha escola da Microsoft, o bo1n e o mau, n1uito n1elhor do que qualquer outro livro que conheço.

McConnell, Sreve, Rapid Developn1ent (Microsofr Press, 1996) ISBN 1556159005 Este livro permaneceu intacto em minha prateleira durante anos, simplesmente devido a seu enorme tamanho: lançá-lo sobre um programador pequeno poderia matá-lo. Contudo, o Capítulo 3 sobre falhas con1uns no software vale o seu preço. O livro é uma espécie de enciclopédia de conhecin1encos sobre o desenvolvin1enco acuai de software: muico abrangente e conciso. O que torna este livro um campeão é a eficiência com que

372 BIBLIOGRAFIA COMENTADA

McConnell dá conselhos e gari1npa aspectos úreis de situações ou problemas para serem discucidos.

Weinberg, Gerald, Quality Software Managernent; Volumes 1-4 (Dorser House, 2001) ISBN 0932633242

Esta é un1a obra em quatro partes de Weinberg sobre o gerenciamento de desenvolvin1enro de so.ftwa1·e. Os Volumes 1 (primeira avaliação do pedido) e 2 {lógica do sistema) fornecen1 codo o cipo de reflexões para encender o que esrá realmente acontecendo com o projeto e como gerenciar e direcioná-lo de modo previsível. Com um rnix de ciência, filosofia, observação e humor, esses livros-texto propiciam muitas reflexões imprevistas. Weinberg vai fundo neste livro: ele inspirou diversas pausas para contemplação durante a leitura.

Whitehead, Richard, Leading a Software Development Team (Addison Wesley, 2001) ISBN 0201675269

O livro rnais prático e simples que encontrei sobre co1no liderar pequenas equipes de desenvolvirnento. Escolhi este livro de brincadeira, no início da pesquisa, porque eu nunca cinha ouvido urna citação sequer sobre ele, e eu rne surpreendia pela qualidade do que eu lia. Muito pragmácico, inteligente e úcil. Esca foi uma das preciosidades que surgiram e1n toda a minha pesquisa.

A

ação segura, execucando, 292-294 quebrando co1npromissos, 294

adicionar/corcar discussões ao elaborar cronogra­n1a, 50

adversidades, superando, 220-243 assunlindo responsabilidade, 228 confiança e cerceza concra, 258 concrole de danos, 229-231 funções e autoridade clara, 233-235 kit de fcrra1nencas c1nocionais, 235-243

complexo de herói, 241-243 pressão, 236-239 sentimencos sobre sencimentos, 239-240

lidando co1n sicuações difíceis, 220-222 resolução de conflicos e negociação, 231-233 sicuações ruins comuns, 222-227

!isca de, 224 reconhecendo, 223

treina1nento e prática, 227 ajudando outras pessoas a darem o n1elhor de si,

197 ajustes en1 requisicos e designs, 57 alívio de tensão, 236 a1nbienre, avaliando, 279 a1nbigüidade

de funç.'ío de GP, 26 tolerância a, 23

ameaças de 1notin1, 227 análise da árvore de decisões, 164 análise de custo/benefício para processos, 204 análise em pesquisa do cliente, 71 andamenro

avaliando en1 projeto, 316-320 avaliações úteis de bugs, 321 avaliando tendências, 320 compilação diária, 316 gerencia1nenro de bugs, 317-319 quadro de acividades, 319-320

rasrrea1nenco e1n 111eio-jogo, 298

, lndice

aprendendo co1n os erros, 16 argumenco, usando na resolução de confliros,

233 araques pessoais, 190, 260 araques pessoais, 190, 260 atitude profissional (a n1elhor), 194 atitudes

a melhor atitude profissional, 194 de gerentes de projetos, 22-24 forçando nludança en1, 35

atividade de gerencian1enro de projetos, 20 arrasado, 291 arraso, tendência para, 34 arraso, tendência para, 34 autoconfiança, 262-262 autoridade para fazer orçan1entos e1n projetos,

57 autoridade cécnica para projecos, 56 autoridade

conquistada, 256 delegação de, 256 necessária para o planejamento de pcojecos, 56 requisitos e design, l 02 ron1ada de decisões, 235

avaliação con1paraciva, 168, 170-172 ajuscar a !isca de pr6s/contras até ficar está-

vel, 172 considerar opções híbridas, 1 71 exan1inar pressuposições ou recla1nações, 171 fazer perguntas difíceis, 171 incluir a opção "não f:1zer nada", 171 incluir perspectivas relevances, 172 iniciar no papel ou no quadro branco, 172 opiniões diferences, 171

avaliação singular, 168 avaliação, andan1ento do projeto, 316-320

avaliações úteis de bugs, 321 avaliando tendências, 320 con1pilação diária, 316 gerencia1nenro de bugs, 317-319 quadro de atividades, 319-320

374 ÍNDICE

B

baixa qualidade, 224 balas de prara, n1crodologias como, 37 baralho de cartas para brninstorming (ThinkPak),

117 best alter1111tive to negotinted ngreement (BATNA

- 1nelhor alcernativa para acordo nego­ciado), 232

bola de neve das on1issões na elaboração de cro­nogramas, 48

briefing da equipe, 295 bugs

avaliações úteis de, 321 avaliando tendências, 320 difíceis, deixar até o úlrüno, 314 fi1n do final do jogo, 328 gerencia1nenro de, 317-319 quadro de arividades, 319-320 rriage1n, 323-326

busca implacável para atender às n1etas, 276-278

e cadeia de co1nando, 235 ca1ninho crítico, 275-276 características do ego, gerentes de projeto, 22 catálogo antipadrões, 228

' . cena.nos cobertura en1 documentos de visão, 87 convertendo declarações dos problemas en1,

75 cenc1s1no

na elaboração de cronogra1nas, 50 traços do gerente de projetos, 23

checklists, confundindo com metas, 25 clareza

falta ern comunicações, 189 fazendo coisas acontecerem, 270

clientes, informações sobre (documentos de vi-são), 87

coerção (poder), 338 colocação, 60 comemorando o final do projeto, 330 compilações diárias, projeto, 316 cornplexidade, reconhecendo, 23

co1nplexo de fracasso, 242 con1plexo de herói, 241-243

morivando convicções, 241 comporta1ncnro autocrárico (quando necessá­

rio), 255 cornportamento incoerente, perdendo a confian­

ça através de, 250 con1porra1nento

forçando n1udança en1, 35 incoerente, perdendo confiança auavés do, 250

. compro1n1ssos

construindo confiança através de, 249 formalizando co1n u1n cronograma, 34 quebrando, 294

comunicação aceita, 188 cointmicação encendida, 188 comunicação recebida, 188 con1unicação cransn1irida, 188 comunicação, 20, 184-198

ajudando outras pessoas a darem o melhor de si, 197

dependência do projero en1 relacionamentos, 192-194

definindo funções, 192-194 gerencian1enro através da conversa, 185-187

rclaciona1nenros, 186 melhor atitude profissional, 194 n1odelo básico, 187-189

con1unicação acordada, 188 comunicação entendida, 188 con1unicação recebida, 188 con1unicação transmirida, 188 conversão e1n ação útil, 188

o melhor de si, obtendo, 195-197 desafiando ou exigindo, 195 eliminando obstáculos, 196 ensinando, 197 inspirando outras pessoas, 196 lembrando à equipe as respectivas funções,

196 lernbrando as 111etas do projeto, 196 pedindo o melhor de si, 197 seguir conselho, 195

problemas con1uns, 189-191 ataques pessoais, 190 disparidade de problen1as, 1 90 ditando, 190

falta de clareza, l 89 não ouvir, l 90 pressuposições, 189

relacionamentos e, 185 concorrência, cobrindo e1n documentos de vi­

são, 87 confiança, 233, 248-263

certeza contra adversidade, 258 con1etendo erros, 260-261

repreensões, 261 confiando em si mesmo, 262-263 confiando nos outros, 256-257

delegação de autoridade, 256 construindo e perdendo, 248-251

construindo pelo compron1isso, 249 perdendo pelo con1portamento incoeren-

te, 250 definição, 248 esclarecendo, 251 1nodelos, perguntas e conflitos, 258-260

líderes definindo feedback, 259 poder e, 346 quebrando con1pro1nissos, 294 tipos de poder, 252-255

poder concedido, 253, 255 poder conquistado, 254

conflito entre me1nbros da equipe, 225-226 conflitos de personalidade, 232 confusão, mini1nizando, 25 conhecimento co1no poder, 338 conhecin1ento e fltLXO de inforn1ações e1n proje­

tos, 28 consolidando idéias, 130-133 controlando projetos, 322-328

equipe bélica, 326-328 reunião de revisão, 322-323 triagem, 323-326

controle de danos, 229-231 conversão de con1unicações em ação úc.il , 188 conversas

gerenciamento através de, 185-187 comunicação nos relacionarnentos, 186

orientando co1110 facilitador da reunião, 213 sobre o poder, 349

coragem para tomar decisões, 177-179

boas decisões con1 1naus resultados, 179

ÍNDICE 375

decisões sen1 opções vencedoras, 177 traços do gerente de projetos, 23

cozinhas (restaurante), gerencia1nento de proje­tos, 17

cozinhas de restaurante, gerencian1ento de pro-jetos, 17

CR (change request- solicitação de mudança), 304 crédulo, gerente de projetos con10, 23 crises (consulte adversidades, superando) critérios de saída, 309

definindo, 310-312 critérios de resre, especificando, 147 cronogramas de baixo para ci1na, 42-43 cronogran1as de cin1a para baixo, 42-43 cronogran1as, 20 cronogran1as, 34-5 l

consrruindo, merodologias para, 36-4 l dividir para conquistar, 39-40 regra dos cerços, 37-40

estratégia de final de jogo, 308-332 estratégia de n1eio-jogo, 286-305 falhando, 224 finalidades de, 34

ferran1enta para rastrear o andamento, 35 fonnalizando co1npron1issos, 34 projetos grandes e co1nplexos, 36 vendo esforços individuais con10 parte do

todo, 35 o que as faz trabalhar, 48-51 por que elas falham, 41-49

boas esti1nativas, garantindo, 45-47 cronograma con10 probabilidade, 42-44 dificuldades de estimativa, 44 efeito bola de neve das 01nissões, 48 01nissões cornuns ao estimar, 47-48 primeiros planos especulativos, 41

tendência de pessoas ao atraso, 34 culpa (problema de comunicação), 191

D

dados estarísticos, interpretação incorreta de, 175 dados numéricos para respaldar reclamações, 17 4 daras intennediárias em projetos, 309 DCR (design change request - solicitação de

mudança de design), 304

376 fNDICE

de referência (poder), 338 declarações de recursos

converrendo declarações dos proble1nas e1n, 75

exemplos de, 75 finalidade de, 75

declarações dos proble1nas, 74 convertendo em cenários, 75 exen1plo de lisra para site en1 inrraner, 74 relatórios de bugs ver~'llS, 7 4 requisitos para a qualidade, escrevendo, 103

defeitos, 318 delegação de autoridade, 256 dependências de llln projeto, 88 desafiando otnros a darem o nlelhor de si, 195 desen1penho, pressão e, 238 desenvolvimento de sofavare

nlerodologias (consulte 1netodologias) Desenvolvi1nento orientado a recursos, 36 descnvolvin1ento para a Web, desafios de, 17 desenvolvimento parcial, 38 desenvolvimento rápido de aplicativos, 36 design change request (DCR), 304 design, 37, 55, 100-105

andamenro, avaliando, 105 autoridade sobre, 56 con10 u1na série de conversas, 119-120 decisões técnicas versus, 56 designers de produtos, 63 especificação versus, 148 experiência do cliente como ponto de parti-

da, 117-119 finali1,ando, 295 iinpacto sobre o cronograma, 50 investigação baseada em requisitos, 103-104 iteração, 126 lista de questões em aberto, 137-138 loop de feedback com requisitos, 1 04 n1ás idéias conduzindo a boas idéias, 112-113

revisão e aprin1oramento, 113 rnedo de exploração, 105 metodologias ágeis e tradicionais, 39-4 O mudanças ocasionando reações em cadeia, 125 pontos de verificação para fases, 128-129 protótipos, 133-136

alternativas, usando para aumentar o su­cesso, 136

apoio aos progra1nadores, 135 con1eçando, 133 projetos com inrerfaces do usuário, 134 projetos sem interÍ.'lces do usuário, 135

requisitos da qualidade como ponto de parti­da, 101 -1 03

revisões e ajustes, 57 trabalho criativo, ímpeto de, 127

designers (interação, de produtos ou industrial), 95

designers de interação, 95 designers de produtos, 63, 95 designers industriais, 95 Diagrama de Venn, usando para elin1inar v.iés

de perspecriv.a, 64 diagramas de afinidades, 130-132 diagra1nas KJ (Ka>vkita Jiro), 130 dilemas de gerenres de projeto, 22-24 direções, 1nudando, 225-226, 299-305

gerenciando n1udanças, 304-305 lidando con1 o gerenciamento de 1nistérios,

301-303 inv.estigando o in1pacto da 1nudança, 302 possív.el alcance da nludança, 303

discórdias enrre 1ne1nbros da equipe, 225-226 resolvendo(consulte resolução de conflitos)

discussão altamente interativa (reuniões), 214· disparidade de problen1as (na con1urricação), 190 distrações e pressões, lidando con1, 24 dirando ordens, 190

persuasão versus, 25 5 dividir o trabalho ern partes gerenciáveis, 35, 39-

40 work breakdotvn structure (WBS - estrutura

da divisão do trabalho), 44 dizendo não, 271 -273

don1inando, 272 docun1entos de visão, 58, 73, 80-97

boas declarações de visão e n1etas (exemplos), 93-94

suporte a reclamações, 93 boas, características de, 84-86

consolidação de idéias, 85 qualidade da inspiração, 86 qualidade intencional (orientada por me­

tas), 85

E

qualidade n1en1orável, 86 sin1plificando efeiros, 84

cacálogo de declaração de visão de 1ná quali­dade, 92

definição, 82 escopo de, 81-84

n1etas da equipe e individuais, 82-84 pergunras para detern1inar, 82

in1agens visuais e1n, 94-95 visualizando coisas não-visuais, 95

i1nporcância de fazer anocações, 80 1nancendo vivo, quescionando sua uti lidade,

96 principais aspeccos a seren1 discutidos, 86-88 princípios da boa redação, 88-90

n1ancendo a sünplicidade, 88 u1n escricor principal, 89 volun1e versus qualidade, 89

protótipo da verificaç.'io de conceiros, 128 rascunhando, exan1inando e revisando, 90-

91

ECO (engineering change order- pedido de n1u­danç.-i de engenharia), 304

ECR (engineering change request -solicitação de mudança de engenharia), 304

eliminando obscáculos para evocar o melhor de si, 196

email, não-irricances, 207-21 1 atribuindo prioridades, 209 evitar relaros descririvos, 209 exemplo de bom e1nail, 211 exemplo de mau ernail, 21 O limitar FYTs, 209 presumindo que os oucros o tenham lido, 209 princípios da boa redação, 208 telefonar em vez de, 209

en1ergências, lidando, 229-231 emoções, consciência de, 220 engenheiros de usabilidade, 63 engineering change order (ECO), 304 engineering change request (ECR), 304 ensinando a dar o melhor de si, 197 equilíbrio do poder e111 organizações, 65

ÍNDICE 377

equipe (grande), projecos concluídos por, 56 equipe bélica, 326-328 equipe concracada (pequena), projeco concluí­

do por, 56 equipes

confiança e experiência no crabalho e111 con-junto, 51

equipe de super-hon1en1 único, 55 problen1as entre 1nembros, 225-226 produtividade como recurso son1a zero, 308 projecos de equipes grandes, 56 projetos de pequenas equipes conrraradas, 56

erros, confiança e, 260-261 escárnio (problen1a de comunicação), 191 escopo de documentos (de visão), 58 escrever ben1, 88-90

dicas para boas especificações, 150 emails não-irritanccs, 207-211 1nanrendo a si1nplicidade, 88 um escricor principal, 89 volume versus qualidade, 89

esforço da pressão para cumprir os prazos, 308 espaço de problen1as

aumencando e diminuindo durance o design, 127

desloca1nenro de, 125 1nudanças ocasionando reações em cadeia,

125 experiência da equipe com, 50 oriundo de requisitos, 103 redução de, 124

especificação técnica, 147 especificações, 55, 144-161

decidindo o que especificar, 146 decidindo quando concluir, 153-157

fechando lacunas de cronograma, 155-156 gerenciando problemas em aberro, 1 54 importância da conclusão, 156 o quanco é suficiente, 153

desenvolvendo e documentando, 58 desi1:,rn versus, 148 dicas para redação e coisas a sere111 evitadas,

150 escrevendo para um versus escrevendo para

muicos, 153 funções de, 145 garantindo que as coisas cercas aconceçan1, 151

378 ÍNDICE

o que elas poden1 e não poden1 fazer, 145 obtendo feedback sobre, 151 que1n, quando e co1no escrever, 152-153 responsabilidade por, 148 revisões e feedback, 157-160

con10 revisar, 157 conduzindo a revisão, 159 perguncas para a revisão, 159 que1n deve parcicipar, 158

simplificando efeicos de especificações ben1 redigidas, 149-151

te1npo entre requisitos e, l O 1 esrin1ando tempo de trabalho

boas esti1nativas, garantindo, 45-47 dificuldades de, 44 on1issões con1uns ao esti1nar, 47-48

escratégia "dividir para conquiscar" en1 crono­gra1nas, 39-40

esrrarégia de final de jogo, 20, 308-332 elen1enros de avaliação, 316-320

avaliações úteis de bugs, 321 avaliando tendências, 320 con1pilação diária, 316 gerenciamento de bugs, 317-319 quadro de acividades, 319-320

ele1nenros de controle, 322-328 equipe bélica, 326-328 reunião de revisão, 322-323 triagen1, 323-326

fim do final do jogo, 328-330 con1e1norações, 330 implantação e operações, 414 pós-morre, 330 release candidate (RC - candidara à ver­

são), 329 grandes prazos como vários prazos pequenos,

309-316 corrigindo ângulos de aproximação, 315-

316 critérios de saída, 310-312 cun1prindo as datas, 312-314 por que fica pior, 314

esrrarégia de meio-jogo, 20, 286-305 executando uma ação segura, 292-294

quebrando compromissos, 294 manutenção de alto nível, 286 n1udando direções, 299-305

gerenciando mudanças, 304-305 lidando con1 o gerenciamento de mistéri­

os, 301-303 permanecendo à frenre dos evenros, 287-292

pergunras semanais/n1ensais, 290-292 questões rácicas (diárias), 290 verificações de sanidade, 289

pipeline da codificação, 294-298 agressiva e conservadora, 297 rastreando o andamento, 298 rornando-se pipeline de correç.1o de bugs,

297 ' . esrrareg1a

final do jogo, 308-332 con1en1orações, 330 ele1nentos de avaliação, 316-320 ele1nencos de conrrole, 322-328 fim do final do jogo, 328-330 grandes prazos con10 vários prazos peque­

nos, 309-316 1neio-jogo, 286-305

executando un1a ação segura, 292-294 1nanutenção de alto nível, 286 pennanecendo à frente dos eventos, 287-

292 pipeline da codificação, 294-298

escudos da usabilidade (em pesquisa de cliente), 72

exatidão, precisão versus, 177 exercícios orais (gerente de projetos), 23 exigindo rrabalho de outras pessoas, 195 experiência com o espaço de problemas, 50 experiência do cliente cotno ponto de partida

do design, 117-119 Exrrerne Prograrnming (XP), 36

iterações, 39-40 velocidade, 47

F

facilitação arre de, 212 indicadores sobre, 213-214

documentando discussões, 214 estabelecendo uma posição de anfitrião,

213

orientando a conversa, 213 ouvindo e refletindo, 213 tenninando a conversa, 214

falha de cronogra1nas, 1notivo para, 41-49 agendar con10 probabilidade, 42-44 boas estin1ativas, garantindo, 45-47 dificuldades de estimar, 44 efeito bola de neve das on1issões, 48 on1issões con1uns ao estin1ar, 47-48 pritneiros planos especulativos, 41

falha aprendendo corn, 16 possível falha do projeto, cobrindo en1 docu-

m.ento de vis.'io, 87 falta de fé (e1n un1 projeto), 225-226 falras de recursos, 224 Í.'ttor n1íniino de risco de irritaç.'ío (MARF), 200 Fault Feedback Rario (FFR), 321 fazendo anotações, a i1nporrância de, 80 fazendo coisas acontecerem, 266-283

conhecendo o carninho crírico, 275-276 dizendo não, 271-273

don1inando 1naneiras de dizer não, 272 1nanrendo a realidade, 273-275 prioridades, 266-271

listas de prioridades, 267-269 sendo fera, 279-283

táticas de guerrilha, 280-283 sendo ii11placável, 276-278

fé, falta de (em un1 projeto), 225-226 feedback, líderes definindo processo, 259 FFR (Faulr Feedback Rario), 321 fixação em processo, 37 flanquear seu objetivo, 350 fluxo de infonnações ern projetos, 28 focando perguntas, 11 O focar grupos em pesquisa de cliente, 71 função obrigatória, 35 funções, 233-235

confusão e, 25 definindo, 192-194 função do gerenciamento de projetos, 17 lembrando equipe de, para permitir o n1elhor

de si, 196 processo de planejamento, 70 reforçando estrutura de funções da equipe,

234

ÍNDICE 379

G

gerenciainenro de crises, 20 gerenciamento de projetos fera, 279-283

avaliando seu an1biente, 279 táticas de guerrilha, 280-283

gerenciamento de projetos função de, 17 história de, 14 na Microsofr, 21 salas de emergência e1n hospitais, 18

gerenciamento por observação (MBWA), 187 gerenciando os superiores, 344 gerentes de projeto, 20

níveis de participação, 26-29 criação de valor único, 28 perspectiva, vantagens de, 27

valor agregado por, 192 gerentes, 1nissão de, 26 golpes baixos (ataques pessoais), 191 GP (gerente de projetos) , 20

H

habilidades para escrever (gerente de projetos), 23

história do gerenciamento de projetos, 14 aprendendo con1 os erros, 16 principais lições aprendidas com, 15

Holn1es, Sherlock, 173

1

idéias gerenciando, 122-139

consolidando idéias, 130-133 gerencian1enro previsível, 123-128 idéias saindo do controle, 122-123 lista de questões cm aberro, 137-138 perguntas para interações de protótipo, 136 pontos de verificação para fases do t!esign,

128-129 protótipos, desenvolvendo, 133-136

origem de, 1 00-120 boas perguntas, fazendo, 109-1 l l

380 !NDICE

conrexro de boas ou 1nás idéias, l 06 design co1no un1a série de conversas, 119-

120 experiência do cliente inicia o t!esign, 117-

119 geração de idéias tradicional, 117 lacunas dos requisitos até as soluções, 100-

105 1nás idéias conduzindo a boas idéias, 112-

113 1nás idéias, 105-107 pensando de 1nodo padronizado e fora do

padrão, 107-108 perspectiva e in1provisação, 114-117

iinpaciência, gerentes de projeto, 23 iinplantação e operações, 329 iinplementação, 37

nletodologias ágeis e tradicionais, 39-40 Ílnprovisação, perspecriva e, 114-117

regras de geração de idéias, 115-1 17 influência, 339, 344

uso de, 350

reuniões, 211-217 facilitação, 212, 213-214 indicadores sobre, 216-217 recorrenres, 215 tipos de reuniões, 214

itens de trabalho atribuindo prioridades com listas de priori­

dades, 268 distribuição na equipe, 44

ir.crações, 126 protótipo, perguncas para, 136

jogos de xadrez, 286 julgamento, 259

n1edo de, 105

K

kir de fcrran1entas emocionais, 235-243 co1nplexo de herói, 241-243 pressão, 236-239

natural e artificial, 237 uso e1n várias ecapas de, 350 sentin1entos sobre sentin1enros, 239-240 uso indireco de, 351

inseguranças de gerenres, 26 inspirando outras pessoas a darern o 111elhor de L

si, 196 interfaces do usuário

criando protótipos para projetos co1n, 134 criando protótipos para projetos sem, 135

irri tar oucras pessoas, evirando, 200-218 criando e implantando processos, 205 efeitos de bons processos, 20 1-204 enutil, 207-211

atribuindo prioridades, 209 evitar relatos descritivos, 209 exen1plo de bom, 21 1 exemplo de mau, 210 limitar FY!s, 209 presu1nindo que os outros o tenhan1 lido,

209 princípios da boa redação, 208 telefonar em vez de, 209

fontes de irritação, 200-201 f(>rmula para bons processos, 204-205 gerenciando processos de baixo para cima,

206

liderança, 20 confiança co1no base de, 248-263

certeza contra adversidade, 258 confiando e1n si n1es1no, 262-263 confiando nos outros, 256-257 construindo e perdendo confiança, 248-

251 erros, 260-261 modelos, perguntas e conflitos, 258-260 tipos de poder, 252-255 tornando a confiança transparente, 251

poder e política, 334 lista de prós/contras (para decisões), l 71-172 listas de irens de trabalho, 147 listas de prioridades, 266

prioridade 1, 269 prioridades do projeto, 267-269 prioridades são poderosas, 270 sendo uma n1áquina de atribuição de priori­

dades, 271

M

n1arcos, 39-40 correspondendo à volarilidade do projeto, 48-

49 corrigindo ângulo de aproxin1ação, 315 critérios de saída, 147 duração correspondente à volatilidade, 299 intermediárias, cun1prindo as daras, 312-314 planeja1nento de projetos, 71 pontos de crossover, 309

critérios de saída, 310-312 MARF (minhnal annoyance risk factor - fator

mínimo de risco de irritação), 200 rnarketing requirements document (MRD - do­

cumento de requisitos de marketing), 57 rnarketing, funções de, 60 1nás situações (consulre adversidades, superan­

do) 1nedo, gerentes de projero e, 23 n1elhor de si, obtendo dos outros, 195-197

ajudando outras pessoas a dare111 o 1nelhor de si, 197

desafiando/gerando den1andas, 195 elin1inando obstáculos, 196 ensinando, 197 inspirando, 196 len1brando as n1etas do projeto, 196 lembrando as respectivas funções, 196 pedindo o melhor de si, 197 seguir conselho, 195

mente aberra (shoshin), 16 nience do iniciante (shoshin), 16 nietas da equipe, 83 meras individuais, 83 metas SMART (specific, rneasttrable, action-ori­

ented, realistic, and timely), 85 metas

alto nível, para um projeto (consulte docu­n1encos de visão)

atribuindo prioridades corri listas de priori-dades, 268

bem-redigidas, 85 confusão com processos, 25 confusão sobre, 267 esclarecendo com declarações de recursos, 76 exemplos de boas n1etas de projeto, 93

ÍNDICE 381

lembrando equipe de, para evocar o 111elhor de si, 196

1nantendo alra visibilidade para, 96 projeto, equipe e individual, 82-84 reuniões, 214 suporte em docun1entos de visão, 94

nletodologias de desenvolvin1ento (consu lte metodologias)

111etodologias agendando, 36-41

dividir para conquistar, 39-40 limirações de, 37 regra dos terços, 3 7-40

especificações, definições de, 146 n1étodos ágeis (desenvolvin1enro de software) , 39-

40 métodos tradicionais (desenvolvimento de soft­

ware), 39-40 1nicrogerenres, abusos por, 26 Microsoft, gerencia1nenro de progran1as e pro­

jetos, 21 modelo en1 cascata (desenvolvin1ento de softwa­

re), 36 n1odelo em espiral {desenvolvimento de softwa­

re), 36 fàses, 39-40

n1orim, a1neaças de, 227 motivações para uso indevido do poder, 342 n1otivando outras pessoas, 195 MRD (marketing require1nents document - do­

cu1nento de requisitos de rnarketing), 57 mudança, 299-305

N

gerenciando, 304-305 lidando co111 o gerenciamento de mistérios,

301-303 investigando (J in1pacto da mudança, 302 possível alcance da nludança, 303

não, dizendo, 271-273 dominando, 272

"não existem más idéias", 105 Navalha de Occam, 1 73 negociação, 231-233

conflitos de personalidade e, 232

382 ÍNDICE

o

conheça as alternativas, 232 persuasão e argumento, usando, 233 procure interesses n1útuos, 232 seja forre rnas flexível, 232

"O que precisamos Í<lzer?", respondendo, 55 objerivos, 83 obsessão corn merodologias, 37 01nissões, 224 operações, 329 organização n1atricial, 21

. ~

organ1zaçoes (consulte ra1nbé111 políücas) equilíbrio do poder, 65 impacto sobre o planeja1nento, 56 políricas, 334

orientar, habilidade de (consulte fazendo coisas acontecerem)

ouvindo

p

função e111 facilitação, 213 in1portância na comunicação, 190

paciência, gerentes de projeto, 23 paradoxos ou dilemas de gerentes de projeto, 22-

24 participação de gerentes, o tipo cerco de, 26-29 patrocinar a simplicidade, 23 pedindo aos outros que dêen1 o n1elhor de si,

197 pensamento criativo, livros sobre, 117 "pense fora do padrão", 107 perfeição, buscando, 23 perguntas criativas, 111 perguntas de retórica, 11 1 perguntas diárias para perrnanecer à frente, 290 perguntas mensais para permanecer à frente,

290-292 perguntas

chave, en1 documentos de visão, 87 conduzindo a boas idéias, 109-111

perguntas criativas, 1 1 1

pergunras de retórica e, 111 pergunras focadas, 11 O

planejamenro de projetos, 66-68 lisra de perguntas, 66 perspecrivas, incluindo, 66 respondendo às perguntas, 67 se1n te1npo para perguntas, 68

períodos de revisão en1 cronogramas, 50 perspecüva co1nercial sobre projetos, 58, 59

rnarketing, 60 perspectiva de engenharia e111 projetos, 58 perspectiva do cliente e111 projeros, 62-63

declarações dos problemas, 74 especialistas que entenden1 clientes e proje­

tan1 para eles, 63 pergunras decorrentes de, 63 solicirações e pesquisa sobre solicirações, 62

perspectiva recnológica e111 projeros, 61-62 perguntas decorrentes de, 61

perspectivas forçando 1nudança en1, 35 pessoas con1 poder, 345 sobre o planejan1ento de projetos, 58-66

equilíbrio do poder, 65 perspectiva co1nercial, 59 perspectiva do cliente, 62-63 perspectiva tecnológica, 61-62 visão interdisciplinar, 63-65

vantagens da perspectiva do GP, 27 persuasão, 339

mais force do que a detenninação, 255 usando en1 resolução de conflitos, 233

PERT (prograrn evaluation and revietu technique - técnica de avaliaç.'io e revisão de pro­gramas), 47

pesquisa de mercado, 72 pesquisa do cliente e seus abusos, 71 -73

métodos de pesquisa, 71 . pesquisa

con10 111unição para ton1ada de decisões, 176 pesquisa do cliente e seus abusos, 71-73

métodos de pesquisa, 71 solicitações de clientes, 62

pilotar à frente do avião, 287-292 questões semanais/mensais para permanecer

à frente, 290-292 questões táticas (diárias), 290

verificações de sanidade, 289 pilorar arrás de seu projec.o, 291 pipeline da codificação, 294-298

agressiva e conservadora, 297 controlando os ajustes de percurso, 300 preparando-se para a n1udança, 302 rastreando o anda1nento, 298 tornando pipeline de correção de bugs, 297

pipeline de código agressiva, 297 pipeline de código conservadora, 297 pipeline de correção de bugs, 297 planejarnento de software, 55-58

especificação, 55 i1npacco das organizações, 56 obtenção de requisitos, 5 5 produtos do planejan1ento co111u111, 57 tipos de projetos, 55

planeja111ento, 20, 54-77 catálogo de propostas ruins, 68 confundindo com 111etas, 25 cronogramas, inforn1ando à equipe, 50 desn1istificação do planejan1ento de software,

55-58 especificação, 55 impacro nas organizações, 56 obtenção de requisitos, 5 5 produtos do planejamento con1u1n, 57 tipos de projetos, 55

fazendo as perguntas certas, 66-68 incluindo três importantes perspectivas, 66 lista de perguntas, 66 respondendo às perguntas, 67 sen1 cernpo para perguntas, 68

inregrando requisitos comerciais e tecnológi­cos, 76

perspectivas sobre, 58-66 equilíbrio do poder, 65 perspectiva comercial, 59 perspectiva do cliente, 62-63 perspectiva tecnológica, 61-62 visão inc.erdisciplinar, 63-65

pesquisa do cliente e seus abusos, 71-73 métodos de pesquisa, 71

processo de, 69-71 número de pessoas participantes, 69 produtos resultantes, 69 trabalho de planejamento diário, 70

ÍNDICE 383

projetos com custos de produção alcos, 39-40

requisitos, usando, 73-76 convertendo problemas en1 cenários, 75

trabalho criativo, 100 poder concedido, 253, 337

sendo autocrático, 255 poder conquistado, 253, 254, 337 poder do grupo, ilusão de, 346 poder funcional, 252-255 poder psicológico de u111 cronogran1a, 35 poder, 334-355

conhecendo o campo de ação, 353-354 criando seu próprio cainpo de ação, 353-

354 fontes de, 337-339

definições de tipos diferentes, 338 políricas e, 334 prioridades co1no, 270 proporção para responsabilidade, 336 restrições in1postas aos líderes, 336 solucionando problen1as políticos, 344-353

avaliando o atendin1ento às suas necessi-dades, 347-348

esclarecendo as suas necessidades, 344-345 influenciando o poder, 349-353 poder para lhe dar o que você precisa, 345-

347 tipos de

poder concedido, 253, 255 poder conquistado, 254

tipos de, 252-255 uso incorreto de, 339-344

causas de nlotivação, 342 causas do processo, 340 evitando, 343

políricas, 334-355 como solução de problemas, 336 conhecendo o campo de ação, 353-354

criando seu próprio can1po de ação, 353-354

definição de, 336 fontes de poder, 337-339 no planejamento de projetos, 65 poder e, 334 restrições impostas aos líderes, 336 solucionando problemas políticos, 344-353

384 ÍNDIC E

avaliando o acendimento às suas necessi-dades, 347-348

esclarecendo as suas necessidades, 344-345 influenciando o poder, 349-353 poder para lhe dar o que você precisa, 345-

347 tornando-se polícico, 335-337 uso incorreco do poder, 339-344

causas básicas, 342 causas do processo, 340 evitando, 343

pontos de crossover e1n 1narcos, 309 critérios de saída, definindo, 310-312

pontos de verificação fases do design, 128-129 para adicionar/ corcar discussões, 50

pós-n1orce (projeto), 330 prácica e creinamento panl gerentes de projeco, 227 prazos

esforços extraordinários para atender, 308 grande, como vários pequenos prazos, 309-

316 corrigindo ângulos de aproxi1uação, 315-

316 critérios de saída, 310-312 cu1nprindo as daras, 312-314 por que fica pior, 314

precisão versus exatidão, 177 preço, 60 pressão artificial, 237 pressão natural, 237 pressão, 236-236

natural e artificial, 237 pressões e distrações, lidando corn, 24 pressuposições

esclarecendo com definições de funções, 192 ocasionando problemas de comunicação, 189 respaldando um projeto, 88

prioridades, 266-271 como poder, 270 confusão sobre, 267 dizendo não, 271-273

dominando maneiras de, 272 listas de prioridades, 267-269

prioridade 1, 269 sendo uma n1áquina de atribuição de priori­

dades, 271

problen1as pessoais, 225-226 processos

confi.1ndindo com nleras, 25 criando e iluplanrando, 205 efeiros de bons processos, 201-204

criando bons processos, 202 fixação en1, 37 fórn1ula para bons processos, 204-205 gerenciando de baixo para ciina, 206 planejamento de projetos, 69-71

nú1uero de pessoas parricipantes, 69 produros resultanres, 69 trabalho de planejamento diário, 70

repúdio a processos de trabalho, 201 uso incorreto do poder, causando, 340

produrividade (equipe), con10 recurso son1a zero, 308

produro, 60 produros resulranres (planejarnenro de projeros),

57,69 cronogran1a para, 71

program evaluation and reviezv technique (PERT), 47

programadores, pipeline da codificação, 294-298

projero Hydra (exe1nplo), meras, 83 projeros de equipes grandes, 56 projetos de pequenas equipes contratadas, 56 projecos de super-hon1e111 (único), 55 projetos de super-hon1em único, 55 prOJeCOS

pós-morte, 330 tipos de, 55

autoridade para requisiros, 56 prornoção, 60 proporção entre esforço da pressão/tempo de

recuperação, 309 propostas ruins para o planejamento de proje­

tos, catálogo de, 68 protótipos, 133-136

alternarivas, aumentando o sucesso corn, 136 apoio aos programadores, 13 5 iniciando, 133 perguntas para iterações, 136 projetos com interfaces do usuário, 134 projetos sem interfaces do usuário, J 35

pseudo-herói, 242

Q

quadros de arividades, 319-320 qualidade consolidada dos docu1nencos de vi­

são, 85 qualidade da engenharia, valor do produco e, 61 qualidade da sin1plificação, docun1encos de vi­

são, 84 qualidade do software, 61 qualidade inspiradora de docu1nenros de visão,

86 qualidade incencional (oriencada por 1necas),

docu1nencos de visão, 85 qualidade 1nemorável de docun1encos de visão,

86 qualidade

baixa, 224 da redação, voltune versus, 89 produco, 60

quando as coisas dão errado (consulte adversi­dades, superando)

"Que problen1a você está tentando resolver?", 110

quescões semanais/inensais para pern1anecer à fi·ence, 290-292

qucscões rácicas (diárias) para pennancccr à fren­ce, 290

R

rastreamento confundindo com metas, 25 cronograma como ferran1enca de rascreainen-

to, 35 realidade, mantendo o contato com, 273-275 recompensas (poder), 338 recurso soma zero, produtividade da equipe

como, 308 recursos

atribuindo prioridades corri listas de priori-dades, 268

cobertura em documentos de visão, 87 especificação, 147 requisitos comerciais e tecnológicos, 76

recursos, 344 para poder político, 353

redes sociais, in1porcância de, 28 reflexão

ÍNDICE 385

como ferra1nenca de tomada de decisões, 174 função c1n facilicação, 213

regra dos terços (cronogra1na), 37-40 desenvolvin1ento parcial, 39-40

regressões, 318 taxa causada por correção de bugs (FFR), 321

relacionamenros ajudando outras pessoas a daren1 o melhor

de si, 197 co1nunicação e, 185 dependência do projeto en1, 192-194

definindo funções, 192-194 1uelhorando a comunicação, 186

relatórios ou discussão 1noderada (reuniões), 215 release candidate (RC - candidata à versão), 329 repreensões, 261 requisicos comerciais, integrando con1

requisitos tecnológicos, 76 requisicos tecnológicos, incegrando con1 requi­

sicos comerciais, 76 requisitos, 73-76

aucoridade sobre, 56 con1erciais e recnológicos, inregrando, 76 convcrcendo ein soluções, 100-105

andrunenco ern design, 105 escrevendo requisitos para a qualidade,

101-103 investigação do design, 103-104 1nedo de invescigação, 105

documentando, 57 especificação, 146 1nécodos de declarações dos proble1nas, usan­

do, 74 exemplo para site em intranet, 74

obtendo, 20, 55 revisões e ajustes, 57

resolução de conflitos, 231-233, 260 conflitos de personalidade, 232 conheça as alternativas, 232 interesse mútuo, buscando, 232 persuasão e argumento, usando, 233 ponto de unificação, procurando, 231 seja forre mas flexível, 232

responsabilidade assurnindo em más situações, 228

386 ÍNDICE

proporção de poder e1n relação à, 336 rescrições

fu nção na solução de proble1nas e no pensa­mento criativo, 107

política e poder, 336 resultados positivos em projetos, 29 reuniões de grupo, usando poder e influência,

352 reuniões de scarus e revis.'io de projeto, 215 reuniões recorrences, 215 reuniões

não-irritantes, 211-217 facilitação, 212, 213-214 indicadores sobre reuniões, 214-217 reuniões recorrentes, 215 tipos de reuniões, 214

planejan1enco de projetos, 71 revisões

co1no controles de projeto, 322-323 requisitos e designs, 57

ridicularizar (proble1na de comunicação), 191 . nscos

s

avaliando en1 docu1nentos de visão, 87 discutindo antecipadainence no cronograina, 51

salas de emergência en1 hospitais, gerencia1nen­to de projetos, 18 .

sentunencos consciência de, 220 sobre sentimentos, 239-240

shoshin (1nente do iniciante), 16 si1nplicidade

orientando decisões (Navalha de Occam), 173 patrocinando, 23

simulações, tomada de decisões, treinando atra­vés de, 165

site em i ntranet declarações dos problernas (exemplo), 74 projeto Hydra (exemplo), metas, 83

site para este livro, xii situações difíceis (consulte adversidades, supe­

rando) solicitação (direta), de poder, 349 solicitação direta de poder, 349

solicitações, clientes, 62 solução de problemas

perspecciva e iinprovisação, 114-117 regras para geração de idéias, 115-117

políticas co1no, 336 soluções, lacuna entre requisitos e, 100-105 specific, rneasurable, action oriented, realistic, and

timely (SMART), nletas, 85 stakeholders, cobertura en1 docun1encos de visão,

87 subesciinar, 224 supercnvolvi1nento por parte dos gerentes, 26

T

caxa de correção (bugs), 321 cempo de recuperação, proporção en1 relação ao

esforço de pressão, 309 tendências, avaliando, 320 ceoria da ucilidade, 174· testando, 37

metodologias ágeis e tradicionais, 39-40 ThinkPak (baralho de cartas para brainstorming),

117 tolerando arnbigüidade, 23 to1nada de decisão, 20, 164-182

autoridade para, 235 coragen1 para decidir, 177-179

boas decisões com maus resultados, 179 decisões sem opção vencedora, 177

detern1inando o que está em risco, 165-167 aprovação ou .feedback necessários, 167 experiência con1 problerr1a, 167 impacto e duração da decisão, 166 impacto/custo de estar errado, 166 janela de oportunidade, 167 perspectiva de especialista, buscando, 167 principal problema, 166

eliminando o impossível, 173 evidência para recla1nações em formulário

numérico, 174 examinando decisões, 179-181 inforn1ações, 174-177

dados vel)"tJS decisões, 175 interpretação incorreta de dados, 175 pesquisa como munição, 176

precisão versus exatidão, 177 procurando e ponderando opções, 168-173

co1nparação, prós e concras, 170-172 discucir e avaliar, 172 e111oções e clareza, 169

reduzindo possibilidades com a Navalha de Occan1, 173

reflexão, 17 4 creinan1enco fonnal en1, 165

rrabalho criativo ín1pero de, 127

rrabalho de design iterativo, 58 trabalho

ajudando outras pessoas a daren1 o n1elhor de si, 197

o 1nelhor de si, obcendo de outras pessoas, 195-197

desafiando/gerando de1nandas, 195 eliminando obscácuJos, 196 ensinando, 197 inspirando, 196 len1brando as n1etas do projero, 196 le1nbrando as respecrivas funções, 196 pedindo o n1elhor de si, 197 seguir consell10, 195

rraços de aucocrara/ delegador, gerences de pro-jeto, 22

traços de um gerente de projetos, 22-24 craços do delegador, gerences de projeto, 22 treinan1enco para gerentes de projeto, 227 rriage1n diária/sen1anal, 325 triage111 sen1anal, 325

criagem, 323-326 diária/sen1anal, 325 dirigida, 325

V

valor

ÍNDICE 387

agregado por gerenres de projeco, 192 criado por gerenres de projeco, 28 definido co1no qualidade da engenharia, 61

velocidade (Excreme Program1ning), 47 verificação de conceito, 128 verificações de sanidade, 289 verificando sua sanidade, 289 visão incerdisciplinar no planejamenco de pro­

jeros, 63-65 visicas a site (na pesquisa do clience), 72

w WBS (consulte work breakdown structure) work breakdown structure (WBS - estrutura ana­

lícica de projeco), 44

X

desenvolvendo e docun1enrando, 58 pipeline agressiva ve1~us, 297

XP (consulte Exrren1e Programn1ing)

COLOFÃO

MarJo,ve Shaeffer foi o editor de produção e editor de A Arte do Gerenciamento de Proje­tos. Audrey Doyle foi o revisor. Jamie Peppard e Claire Cloutier fizeram o controle de qualidade. Ellen Troutn1an-Zaig redigiu o Índice. Lydia Onofrei deu assistência à produção. MENDEDESIGN, wu11v.n1endedesign.com, fe-t o design da capa deste livro. Karen Montgornery produziu o leiaute da capa no Adobe lnOesign CS usando as fontes Akzidenz Groresk e Oraror.