Gerente Também é Gente
13- Planejar É Preciso...
Quem pouco pensa, engana-se muito.
L EONARDO DA V INCI
Depois de um fim de semana totalmente em família, tentando aproveitar ao máximo o tempo que eu sabia que seria diminuído com o início do projeto, fui visitar a Telefon. Conheci o responsável pelo projeto no cliente. Seu nome era Arlindo Pena. Não devia ter mais do que 38 anos, ainda sem um mínimo de cabelo branco e extremamente energético e pragmático. Dei um palpite a mim mesmo de que ele deveria ser do tipo que praticava esporte regularmente. Se fosse para adivinhar, eu diria, futebol... e às segundas-feiras, no fim do expediente... Enfim, minha primeira impressão foi muito positiva. Apresentei-me e tentei deixá-lo ao máximo confortável em relação às perspectivas de execução. E interessante (para não dizer bizarro...) tentar confortar alguém quando você mesmo não está cem por cento confortável. Negociei com ele uma coisa muito importante também apontada no GGP e que eu já havia discutido com Petrúcio: precisaríamos de uma sala dentro das dependências da Telefon que acomodasse o meu time. Iríamos passar um ano trabalhando juntos e não fazia sentido ficarmos separados da
equipe do cliente. Segundo o GGP, essa ação era chamada de "colocação" 15. Quanto mais unidos estivessem os times, melhor. Ele me pediu uma semana para negociar internamente. Justo. Eu sabia como eram tratadas estas coisas dentro das empresas. Eu mesmo não sabia se conseguiria disponibilizar uma sala assim tão facilmente dentro da HAL, ainda mais para tantas pessoas. Salas são itens cada vez mais valorizados e escassos hoje em dia nas organizações. Todos os caminhos levam a uma reunião...
Tanto é verdade, que certa vez, em uma destas reuniões, um colega brincou:
-Quem marcou esta reunião? Foi você, Flick?
-Não.
-Foi você, Farhad?
-Não.
-Foi você, Jorge?
-Não.
-É como eu pensava... A própria reunião "se marcou"!
Tamanha a entidade que as reuniões estavam se tornando...
Eu sabia de histórias de clientes que preferiam fazer reuniões próximas do horário do almoço para garantir que ninguém agüentaria muito tempo. Ou daqueles que tinham mandado construir mesas de reuniões do tipo das que se tem em bares, sem cadeiras, para que as reuniões fossem feitas em pé e também tivessem seu fim agilizado. Enfim, o ponto de Arlindo era justificável.
Voltei para a HAL e me preparei para reunião com o meu time de 5 pessoas. Minha expectativa era de que todos já tivessem lido a documentação do projeto que eu havia enviado. Seguindo os passos do meu mestre, cheguei na sala de reunião meia hora mais cedo. Não só para garantir que seria o primeiro, pois eu era o gerente, mas também para ligar meu laptop, preparar o projetor e organizar a sala. Sentei e esperei. Confesso que ainda estava um pouco traumatizado pela primeira reunião que tinha convocado na vida e a qual ninguém tinha comparecido (só os biscoitos...). Aproveitei o tempo livre para ler mais um pouco o GGP. E o capítulo não poderia ser mais propício: planejamento. O primeiro item abordado era justamente o escopo do projeto. Li e reli atentamente as dicas que o livro passava e, principalmente, as anotações de Petrúcio. Este capítulo estava particularmente cheio delas. Não deu tempo de fixar tudo, mas foi muito bom ter feito isso porque me deu a segurança que precisava para não começar do zero com meu time. Já sabia como iria abordar a conversa. Foi quando eles começaram a chegar. Os cinco cavaleiros do apocalipse eram: Alexandre Biliani, Julia Batista, Carlos Souza, Salles Ribeiro e Eric, que inclusive já tinha trabalhado comigo anteriormente no projeto SAS501.
De todos eles, Alex foi o recurso mais difícil de conseguir. Jovem, de raciocínio rápido e muito inteligente, era conhecido por sua capacidade autodidata e sua habilidade com quase todos os produtos que a HAL oferecia. O mérito de sua vinda foi todo de Clara, que negociou diretamente com o chefe de Alex, que era seu subordinado. Todos nós nos sentimos seguros em tê-lo na equipe.
Carlos era o mais experiente do time. Já trabalhava há muitos anos na HAL, do tipo que cumprimentava todas as pessoas nos corredores. Alguns até brincavam com ele dizendo que pregada em seu corpo havia uma placa com seu número de ativo fixo da empresa. Curiosamente era o único do grupo que tinha cabelos brancos na forma predominante. Isso, por um lado me confortava, por outro me assustava um pouco. Afinal, como gerenciar alguém mais velho e com mais experiência que eu? O que eu poderia acrescentar a um profissional assim, que conhece muito mais a empresa, seus produtos e até mesmo a vida mais do que eu?
Julia era a única mulher do time. Inegavelmente bonita, corpo esguio, com traços suaves e forte personalidade. Quase nunca ia de cabelo solto, mas quando ia, lembrava em muito a atriz Catherine Zeta-Jones. Todo o time era extremamente respeitoso, mas em um ambiente somente formado por homens, são quase inevitáveis as chamadas piadinhas de mau gosto. Certa vez, até ouvi uma que dizia que Julia era uma exceção. Isso porque segundo Eric, existia um teste para entrada de novas funcionárias na HAL. O teste consistia em dar uma vassoura para a candidata. Caso ela voasse, estaria contratada... Segundo ele, Julia certamente não voou e mesmo assim passou no teste... Imagino que ela tenha sofrido um pouco com piadas do gênero... Mas nunca perdeu a pose. Sabia impor respeito e se posicionar. Todos a admirávamos por isso.
De todos eles, apenas três tinham lido a documentação do projeto. E um deles, Alexandre, já tinha até esboçado um cronograma de atividades. Foi quando comecei a aplicar o que tinha lido:
-Sejam bem-vindos. Temos um grande desafio pela frente. Agradeço a presença de todos
e estou muito orgulhoso e satisfeito de poder contar com vocês. Gostaria de começar a
discutir o projeto com um nível maior de detalhes agora, já que vamos iniciar dentro do
espaço do cliente na semana que vem.
-Chefe (ainda não estava exatamente acostumado a ser chamado assim... Fingia que
achava normal, mas sempre estranhava...), você não acha melhor que façamos uma ata desta
nossa primeira reunião interna?
Droga... Julia colocou um ponto que eu, como gerente, deveria ter lembrado. É claro que deveríamos ter uma ata. O próprio GGP fala o tempo todo que o projeto deve ser documentado...
-Perfeitamente Julia. Muito bem lembrado! Você se incomodaria de registrar nossa reunião?
Em geral quem sugere acaba sendo o responsável... A vida inteira fizeram isso comigo... Acho que foi como um tipo de revanche de minha parte... Continuei:
-Vejo que a maioria de vocês leu a documentação do projeto. Aos que não o fizeram, eu
pediria para fazê-lo o mais brevemente possível. Trata-se de um projeto extremamente
técnico que...
-Com licença, Flick, mas já participei de um projeto igual a este e tomei a liberdade de
preparar este cronograma. Posso mostrá-lo no projetor para que todos possam ver?
-Alex, eu agradeço muito sua iniciativa. Sua experiência é muito bem-vinda. Mas um
projeto, por definição, nunca é igual ao outro. Por mais que tenha elementos muito parecidos.
Antes de olharmos um cronograma, é fundamental que tenhamos total domínio do escopo
pretendido.
-Ok, mas eu já conheço o escopo.
-Tenho certeza que sim, mas é importante que todos nós estejamos no mesmo nível de entendimento. Inclusive, minha sugestão é que façamos um desenho completo de todos os produtos e subprodutos do projeto que pretendemos entregar. A partir deste desenho, poderemos construir juntos e até revalidar muito melhor o cronograma que você elaborou.
Ele não gostou muito. Arriscaria até dizer que ele achava que estaríamos perdendo tempo fazendo algo desse tipo. Mas tinha visto essa dica no GGP e pretendia segui-la. O que eu estava propondo na verdade era a criação de uma estrutura que o guia chamava de Estrutura
Analítica do Projeto16 (EAP). O objetivo deste desenho era o de justamente entender melhor o escopo e representá-lo de maneira gráfica. Era, por assim dizer, a representação do escopo em forma de uma espécie de "árvore-ao-contrário" que ia se desmembrando na medida em que íamos dividindo o projeto em seus diversos subprodutos. O ramo principal, ou a raiz desta árvore, representava o produto fundamental ou o próprio projeto em si. Comecei a desenhar com um olho no papel e outro no GGP No início, todos acharam que se tratava de um organograma. Pode ser até parecido no formato, expliquei, mas não tem absolutamente nada a ver do ponto de vista funcional. Estávamos falando dos produtos de nosso projeto. Acabei esboçando algo como o desenho a seguir, para facilitar o entendimento:
Produto Principal do Projeto
S u b p r o d u t o 1 S u b p r o d u t o 2 S u b p r o d u t o 3
S u b p r o d u t o 11 S u b p r o d u t o 2 1 S u b p r o d u t o 3 1
S u b p r o d u t o 1 2 S u b p r o d u t o 2 2 S u b p r o d u t o 3 2
S u b p r o d u t o 1 3
Em nosso caso, o primeiro retângulo representava a expansão da rede da Telefon. Deste retângulo, fomos dividindo o produto principal em três diferentes subprodutos, ou pacotes, que formavam a expansão da rede. Estes três pacotes se dividiam, cada um, em mais cinco, seis ou até dez diferentes outros e assim fomos decompondo... Chegamos a um total de mais de 50 pacotes de trabalho. Gastamos muito tempo nesta estrutura. Confesso que achava que não levaríamos tanto. Mas valeu a pena. Desenhamos a estrutura inteira juntos e discutimos bastante onde se encaixavam cada um daqueles pacotes até chegarmos a um consenso de grupo (na verdade eles discutiram mais do que eu, dado que eu não tinha exatamente todo o conhecimento técnico necessário). Paramos de decompor no ponto em que achamos que cada pacote já estava em sua unidade mínima de controle, além de ser autoexplicativo. Ao final, não só tínhamos o desenho do escopo do projeto como um todo, como também uma excelente representação que poderíamos usar depois para facilitar a confecção do cronograma e elaboração da planilha de custos. De acordo com o GGP, todos os demais itens de planejamento dependiam deste desenho ter sido bem montado. Por isso gastamos tanto tempo. Eu sabia que valeria a pena mais tarde.
Revendo depois as anotações de Petrúcio em relação à EAP, pude verificar que ele inclusive controlava mudanças, acompanhava o andamento físico-financeiro e tudo mais relativo ao projeto através desta estrutura. Ela servia até mesmo como base para relatórios executivos. E fazia sentido, dado que é muito mais fácil entender um desenho do que um texto escrito (ainda mais a nível executivo.... diretores e presidentes são como crianças... não tem paciência de ler... apenas para ver desenhos...).
Nossa primeira reunião foi praticamente inteira no desenvolvimento e detalhamento do escopo do projeto. Senti que isso decepcionou um pouco Alex, mas os demais acharam o exercício de planejamento muito interessante. Eu mesmo pude compreender muito melhor o que iríamos fazer, depois de ouvir os especialistas da equipe. Passei a ser fã da EAP. Hoje em dia não sei como seria possível planejar um projeto sem esta ferramenta. Mas ela sozinha também não era suficiente. O próprio GGP apontava que a EAP por si só não traz consigo todos os detalhes do escopo.
Na medida em que íamos montando aquela árvore, pacote a pacote, decidi que também
prepararíamos o que o guia chama de uma Declaração de Escopo17. Neste documento, estaríamos não só revisitando o conteúdo da documentaçãodo projeto, como também descrevendo em nível mais detalhado possível as características de cada pacote que desenhamos. Basicamente: o que cada pacote significava, atributos e características relativos a ele (cor, tamanho, material utilizado etc.) e, principalmente, seus critérios de aceitação. Confesso que demorei um pouco para entender o significado do termo. Isso só foi ficar bem claro meses mais tarde, quando começamos a entregar de fato os primeiros resultados do projeto. De qualquer forma, estava escrito que a importância básica da definição destes critérios era dar certeza tanto para nós, fornecedores, quanto para o cliente, de que o que se espera de cada pacote de trabalho será realmente entregue. Em outras palavras, significa uma
grande lista de itens18 a serem revistos após a entrega do serviço, para que não se tenha dúvida de que o produto foi realmente entregue conforme esperado. Na verdade, esta foi uma das partes mais difíceis do planejamento. Tínhamos a nossa própria ideia do que deveria constar como critério de aceitação em cada produto, mas não tínhamos certeza de que o cliente teria a mesma opinião. Foi quando Carlos deu uma ideia que agora me parece óbvia, mas que na hora não me ocorreu: deveríamos consultar o cliente... Não só quanto aos tais critérios, mas também em relação ao desenho e à nossa Declaração de Escopo como um todo. Nada mais justo, dado que ele é quem pagaria pelo projeto. O GGP chama esse processo de "validação".
Aceitei a ideia de Carlos de imediato. Eu mesmo iria agendar esta reunião que chamei de "revisão final do escopo" com o cliente e levaria pelo menos um deles comigo, caso houvesse alguma discussão mais técnica a respeito. Mas ainda existia um item que particularmente me chamava a atenção. Fazia parte, é claro, das anotações de Petrúcio. Ele dizia que tão importante quanto descrever em detalhes o que está no escopo era também descrever o que não fazia parte dele. Aquela frase simplesmente não me soou bem. Li e reli algumas vezes esta anotação para poder ter certeza de que não estava lendo errado. Talvez fosse um lapso do meu mestre, afinal ninguém é infalível... O que ele queria dizer com descrever o que não faz parte do escopo? Isso para mim era uma espécie de marketing negativo do próprio produto ou serviço. Além do mais é literalmente impossível dizer tudo o que o projeto não faz. Simplesmente não me parecia razoável e era o último item importante que faltava em minha lista relativa à Declaração do Escopo. Resolvi discutir o assunto com o grupo. Para minha surpresa, Salles, que tinha sido o mais tímido até agora falou:
-Chefe (eu começava a gostar da expressão...), esta lista é realmente muito importante. Posso dar o exemplo de um gerente que tive, em outro projeto, que ficou dias e dias discutindo com o cliente um determinado ponto do escopo do projeto. A discussão era se o módulo de reindexação estava ou não incluído. Não preciso dizer que, depois de muita argumentação, o cliente acabou levando a melhor. Acabamos tendo que refazer parte do projeto e isso baixou o moral de toda a equipe, que ficou revoltada com a situação.
-E baixou também o lucro do projeto, aposto!
Alex era sempre um pouco ácido em suas colocações, mas desta vez ele acertou...
Mesmo depois do depoimento de Salles, eu ainda não estava confortável em começar a fazer uma espécie de lista daquilo que meu projeto (meu querido projeto...) não iria entregar. Achava que o próprio cliente não acharia isso muito interessante. Mas acreditei nas anotações de meu "guru" e, novamente, fizemos um exercício de tentar colocar possíveis produtos, serviços ou resultados que, por experiência, imaginávamos que o cliente poderia supor que estivessem incluídos em nosso projeto, mas não estavam. Neste ponto Alex foi muito útil. Ele sabia que era o mais experiente tecnicamente e o time reconhecia isso. Fizemos a tal lista e chamamos este item de "Exclusões", dentro da nossa Declaração de Escopo. Com base no GGP, incluí um campo para minha assinatura e também para assinatura do cliente, dado que precisávamos de seu acordo para continuar o planejamento do projeto. Tudo enfim estava pronto para a reunião de "revisão final do escopo". Marquei com o cliente no dia seguinte. Eric e Julia iriam comigo. Pedi para os demais do time começarem a pensar em como nos distribuiríamos com base na EAP que desenhamos e também quantos e de que tipo de fornecedores nosso projeto iria precisar. Eu tinha estimado umas 40 pessoas ao todo, mas aquela foi uma estimativa inicial e provavelmente errada. Aliás, era incrível como a minha visão do escopo e do projeto como um todo havia mudado desde a época em que preparei o Termo de Abertura. Começava a perceber que nosso entendimento de determinada solução é progressivo em relação ao ciclo de vida do projeto. Para variar, isso também estava escrito nas anotações de Petrúcio...