Projetizando a Vida

Infelizmente não sou Vidente, e como todo  Gerente de Projetos lamento profundamente isso, mas apesar disso, posso garantir que sei duas coisas  sobre o próximo projeto que vou assumir, embora não saiba qual será ele.

 E mais ainda, sei também duas coisas de Seu projeto atual e sobre seu próximo projeto, mesmo sem saber quais são eles, e nem mesmo sem saber quem é você… (e isso depois de dizer que não sou vidente!)

 Essas duas coisas são :

 1. O Escopo vai mudar

2. Alguma coisa vai dar errado…

 Pois é,  depois que parar de rir, pare e pense em todos os projetos que você já teve conhecimento, você vai ver que o escopo mudou, e alguma coisa deu errado.

 Chamo a isso de Verdades dos projetos, essas são duas verdades incontestáveis dos projetos, o Escopo muda, e algo dá errado …

 Mas se o escopo muda, porque que é que não acerta o escopo logo no início?  E porque não planeja melhor para evitar que as coisas dêem errado?

 A resposta é simples, é porque se você fizer isso vai gastar muito mais tempo no planejamento,  vai gastar muito mais esforço se precavendo contra problemas que não vão ocorrer, seu prazo e seu orçamento ficarão infinitamente maiores, e depois de tudo isso…

 Seu Escopo vai mudar mais uma vez, e alguma outra coisa vai dar errado…

 Afinal, essas são duas Verdades absolutas em Projetos.

 Quando falamos em Projetos estamos falando , por definição,  em algo que nunca foi feito antes,  pelo menos não EXATAMENTE daquela forma, afinal, “projetos são empreendimentos temporários que visam produzir um produto ÚNICO, a um custo pré-determinado”…

 São tantas variáveis envolvidas que é impossível controlar todas, por isso, algo vai dar errado, algum imprevisto vai forçar uma mudança de escopo, sem levar em conta o famoso Jaques… (já que esta fazendo isso…)

 Quando se fala em Projetos de TI então, temos um “complicômetro” a mais, é a nossa “matéria prima”…

 Se na engenharia a matéria prima é o cimento, o tijolo, o concreto, na Informática a “Matéria Prima” são as pessoas…

 Lidar com pessoas é uma das atividades mais difíceis de se aprender, ou você tem empatia ou não tem, ou o “santo bate” ou nada feito…

 Conheci um Gerente de Projetos, um dos Bons, que me dizia que o principal instrumento que ele usava era a Planilha de Riscos, pois com ela, ele conseguia controlar tudo, sem ela ele estava perdido…

 Um dia resolvi testar, e comecei a usar os meus “E SE…”

E SE o cliente mudar o escopo?

 Lá vai o Carlão, planilha de Risco, Item 5, Mudança de Escopo por parte do Cliente, Probabilidade Alta, Impacto Alto, Estratégia de Enfrentamento Triplo(Plano de aceitação ativa, Plano Mitigação e  Plano de Contingência): Plano de aceitação ativa- Incluir 5% de margem de segurança. Plano de Mitigação: Documentar Escopo Inicial e Negociações, Demonstrar alteração de Escopo ao Cliente e Renegociar.  Contingência: Estratégia de Compressão: FastTrack.

 E SE o programador fizer corpo mole?

 La vai o Carlão, Planilha de Risco, Item 9, Baixa Produtividade da Equipe pro Desmotivação…

 E assim por diante, peguei a Planilha de Risco dele e vi que tinha 95 riscos apontados, com as devidas estratégias de enfrentamento.

 Perguntei, quanto tempo ele “perdia” criando aquela planilha para cada projeto, ele respondeu: Perder? Nem um minuto… Investir? 1 dia…

 Antes que eu trucasse, ele falou, essa Planilha me acompanha há 10 anos, a cada projeto eu apenas ajusto as probabilidades e o impacto, eventualmente entra um ou outro, mas nunca sai nenhum, afinal, sempre tem escopo flexível, sempre tem custo apertado, cronograma inviável, profissionais insatisfeitos, etc., etc.

Projetos são empreendimentos únicos é  claro, mas o ser humano é sempre igual, e portanto, as empresas e o relacionamento entre elas são muito parecidos, assim como seus problemas, por isso, os riscos são sempre os mesmos, somente sua probabilidade e seu impacto é que mudam…

 E ele terminou com a frase sobre as verdades: Só sei duas coisas sobre meu próximo projeto: O Escopo vai Mudar e Alguma coisa vai dar errado. A única forma de conviver com isso é ter uma planilha de riscos muito bem montada.

 Logo depois dessa conversa montei a planilha do projeto que eu estava iniciando, apontei 22 riscos. Quando terminei o projeto ela tinha 35, Hoje ainda a carrego comigo, já tem 53.

 E Antes que alguém me peça a planilha, aviso que eu pedi a dele, e darei a mesma  resposta que ele me deu:  Mais importante que ter uma boa planilha de riscos, é construir uma planilha de riscos, construa a sua.

Voltarei a falar sobre Riscos em breve e criarei uma área de templates no Blog para deixar um modelo para quem quiser construir a sua, ok?

Alguns textos sobre riscos:

Por que ignoramos a gestão de riscos em nossos projetos? (GestaodeProjetos.net)

Analisando Riscos na Gerencia de Projetos (O Blog da Gerência de Projetos)

OBS: A Imagem acima é a capa do Livro Gerenciamento de Riscos em Projetos, da FGV, que recomendo a leitura e pdoe ser adquirido no Submarino, clicando aqui

A grande maioria dos Gerentes de Projetos de TI Experientes que conheço (eu inclusive) entraram nessa carreira acidentalmente… (Uso o termo a grande maioria para não cometer algum equívoco ao usar Todos, porque não consegui me lembrar de nenhum que não tenha sido assim, voce que me lê, conhece algum?)

A recente valorização da Certificação PMP, tende a mudar um pouco isso, mas como ela exige que se tenha pelo menos 4.500 horas de experiencia comprovada, isso ainda vai demorar muito tempo, mas o que quero questionar com esse artigo é, ser Gerente de Projetos é mesmo um acidente de percurso?

Note que falei em Gerenets de Projetos de TI, o termo Gerente e Projetos, o PMI inclusive é oriundo de projetos de Engenharia Cívil, pois é muito mais fácil numa obra de engenharia, um prédio ou uma ponte por exemplo, falamos de um produto que tem séculos de história e já se percebe a necessidade de um projeto, de fases bem definidas (fundações, alvenaria, acabamento, hidráulica, elétrica, etc) e quando uma obra de engenharia dá errado, o prédio ou a ponte cai, e morre gente, por isso desde sempre, ou desde há muiteo tempo, a legislação exige o projeto, exige e fiscalização e a sociedade cobra isso, e quem contrata o prédio ou a ponte sabe que ela precisa ser gerenciada e que isso custa…

Já quando falamos de informática, falamos de algo muito recente, poucas décadas, de algo intangível. Quando um projeto de software dá errado perde-se ” apenas” dinheiro e tempo (normalmente), quem compra um projeto de TI somente agora está percebendo que é preciso contratar um Gerenteciamento eficiente, porque isso vai garantir o produto comprado.

Mas porque os Gerentes de Projeto foram um ” acidente de percurso”?

No Brasil, há cerca e 25 anos atrás começou na área de TI o processo de terceirização, visando adequar os custos, inicialmente apenas com locação de mão de obra, rapidamente isso evoluiu para ” proposta fechada” (vulgo projeto).

Nesse momento a área comercial das ” consultorias” foram obrigadas a começar a controlar, inicialmente de forma empírica, escopo, custo e prazo, para evitarem o prejuízo, dessa forma surgiram os primeiros gerentes de projeto, que ainda não usavam esse nome.

Logo em seguida, porque precisavam vender, essa tarefa foram repassadas para analistas de sistemas, e assim, acidentalmente também, passaram a assumir a carreira de Gerentes de Projeto.

A Demanda por Gerentes de projeto é crescente, tanto no Brasil como no mundo, e não existe, e não existirá num futuro próximo, Gerentes de Projetos capacitados para atender a essa demanda,e quem diz isso nâo sou eu, e nem essa é uma realidade brasileira, como pode se perceber pelo trecho que recortei do blog PMhut(inspiração para este artigo), a SEGUIR:

“The Accidental Profession

Many corporations today will assign the management of a project to someone with superior technical and leadership abilities. The individual then “inherits” the job as project manager, often without any training. They become project managers accidentally. Unfortunately, without proper training, many project managers hit a wall in their career advancement. Proper project management training is vital.”

Só existe uma saída para isso: é necessário um curso de FORMAÇÃO DE GERENTES DE PROJETO, e não apenas cursos preparatórios para certificação.

Já ouvi muita gente colocar o Agile Software Development como uma metodologia alternativa ao PMBOK, quando vejo isso fico em dúvida se dou risada ou se choro…

Primeiro porque não existe “Agile Management”,  Agile Software Development é na verdade um conjunto de metodologias de desenvolvimento, e dentro de cada uma delas, se quisermos ter sucesso precisaremos gerenciá-las da melhor forma possível.

Em segundo lugar porque o PMBOK não é, nunca foi e nunca vai ser uma metodologia, ele é um guia das melhores práticas de Gerenciamento de Projetos.

Ele é um livro que se for usado com bom senso será ume excelente base para a criação de uma metodologia de gerenciamento que poderá sim ser ágil e adequada ao Agile Software Development.

Querem um Exemplo Prático ?

Uma das metodologias ágeis que eu mais gosto é o SCRUM.

Por curiosidade, SCRUM é aquela formação que os jogadores de Rugbi fazem onde os dois times se apóiam ombro a ombro para lançarem a bola, não sei porque e nem quando, mas a estrutura é aquela e chama-se SCRUM…

Explicando de forma hiper-super-extremamente resumida, na metodologia SCRUM, o projeto é dividido em pequenos entregáveis, de forma que o sempre tenha algum módulo entregue e aprovado na pior das hipóteses a cada quinzena, o ideal é que essa entrega seja semanal.

Diariamente a equipe se reúne, numa reunião em pé,  na frente de um quadro negro (atualmente quadro branco, com pinceis ao invés de giz), com duração de 15 minutos para responder a apenas 3 perguntas:

* O que fiz desde ontem?

* O que estou planejando fazer até amanhã?

* Existe algo me impedindo de atingir minha meta?

Terminada essa reunião cada um já sabe o que tem que fazer, e todos vão ao trabalho.

Alem disso existem algumas características adicionais nos projetos de SCRUM:

* Clientes se tornam parte da equipe de desenvolvimento (os clientes devem estar genuinamente interessados na saída);

* Entregas freqüentes e intermediárias de causam reuniões freqüentes com os stakeholders (todos os envolvidos no processo) ;

* Planos freqüentes de mitigação de riscos desenvolvidos pela equipe;

* Transparência no planejamento e desenvolvimento;

* Problemas não são ignorados e ninguém é penalizado por reconhecer ou descrever qualquer problema não visto;

Por isso deixo uma pergunta: Onde é que o SCRUM (assim como outras metodologias Ageis) está confrontando com o PMBOK?

Na minha opinião usar uma abordagem de Agile Software Development sem o Apoio do PMBOK é partir para um “Desenvolvimento Cowboy”,  ou seja,s e o bandido mexer, você  saca e atira, e torce pra ele não sacar mais rápido…

Mas voltarei a falar mais sobre SCRUM e vou convidar um amigo Nelson Abu Samra Rahal Junior, o Abu, especialista em SCRUM  e autor do Blog do Abu para fazer parte da  Equipe do Projetizando a vida, escrevendo com mais propriedade sobre o assunto.

Já trabalhei em Vários Projetos de em Empresas que tinham ou estavam implementando o CMMI e, invariavelmente, tive atritos com o “pessoal”  do CMMI.

Quem me conhece sabe que sou uma pessoa crítica, isso não quer dizer que sou “do contra”, que dizer apenas que não sou uma pessoa passiva, não aceito as coisas como elas são simplesmente por que são assim, quero saber porque são, isso faz parte do processo de aprendizado, pois somente assim podemos melhorar as coisas, e acredito que é assim que um Gerente de Projetos deve se portar, invariavelmente, entender as coisas, antes de aceitá-las ou recusá-las.

Mas voltando aos meus atritos com o “pessoal do CMMI”,  bom o primeiro atrito é com a existência de um “Pessoal do CMMI”, apesar “deles”acharem que sou contra o CMMI, sou um dos maiores entusiastas do CMMI, desde que sua implementação seja verdadeira, e para que ela seja verdadeira, ela deve ser implementada pela empresa toda e não pelo “pessoal do CMMI”, portanto sua existência já é, a meu ver, um sinal de algo errado, em segundo lugar na maioria dos locais onde vi sua implementação percebi um erro conceitual importantíssimo e por isso fui um crítico duro.

O CCMI, para quem não conhece é, a grosso modo,  um modelo que define a maturidade dos processos de desenvolvimento de software. Ele define 5 níveis de maturidade sendo que o nível 1 significa TOTALMENTE IMATURO, ou seja Caos Total, ou processos inexistentes, portanto o CMMI inicia-se no nível 2- Processos Repetitivos, passa pelo Nível 3 - Processos Definidos, Nível 4 - Gerenciado e finalmente Nível 5 - Otimizado.

Não existe uma obrigatoriedade das empresas escalarem os níveis 2, 3, 4 e 5, uma empresa pode (se for louca o suficiente, e trabalhei em uma que tentou isso) implantar direto o nível 5, normalmente as empresas iniciam na 2, escalam para a 3 e então pulam para a 5 (não conheço nenhuma  que tenha tirado o nível 4).

O grande problema quando se cria a “Turma do CMMI”  é que normalmente não existe ninguém da “Turma de Gerentes de Projeto” nesse grupo e “pequenos”  erros conceituais costumam acontecer.

O Pior deles é muito comum: O Objetivo do CMMI é PADRONIZAR PROCESSOS, e o que muitas vezes acontece é que as empresas acabam padronizando PRODUTOS. Ou seja, tornar os produtos IGUAIS.

OPS… Vamos fazer um Rewind, retomar a definição de projeto: “Projeto é um empreendimento TEMPORÁRIO que tem por objetivo produzir um PRODUTO ÚNICO, com um ORÇAMENTO previamente definido.”

Se vamos produzir PRODUTOS ÚNICOS, como é que vamos fazer PRODUTOS IGUAIS???

Podemos concluir que CMMI e Projetos são incompatíveis? Não, de forma alguma. O que podemos concluir é que precisamos envolver Gerentes de Projetos EXPERIENTES na definição dos processos de implementação do CMMI ou pelo menos permitir que os mesmos critiquem os mesmos durante a sua implementação, sem que sejam considerados anti-CMMI.

Vou Abrir uma categoria nova para os Textos do CMMI e voltarei a falar, futuramente, sem uma freqüência pré-determinada,  sobre cada um dos Processos, fazendo um paralelo sobre os Processos/Grupo de Processos do PMBOK.

Existem alguns documentos que deveriam ser tratados com mais seriedade, não apenas, mas principalmente em projetos, mas especificamente em projetos um dos documentos mais desprezados é o  Project Charter, ou o termo de Abertura do Projeto.

Quando terceirizamos um Projeto normalmente esse documento é feito, pois como praticamente todas as metodologias dizem que ele é obrigatória, ele consta no contrato, e portanto ele é feito, mas muitas vezes é feito “nas coxas” e na grande maioria das vezes (aprendi a nunca falar SEMPRE) ele é feito e depois ignorado, a menos que se tenha auditorias freqüentes (por exemplo de CMMI) quando então se lembra que ele existe, mas apenas isso…

Quando se fala num Projeto Pessoal então, ele é praticamente inexistente…

E não são apenas Gerentes iniciantes esquecem dele, querem um exemplo prático?  Esse blog não tem um Project Charter…  Ops!!! *rs

Pois é, e sua falta acabou trazendo problemas, por isso ele ficou abandonado um tempão, mas agora que resolvi retomá-lo, e com força total, começarei como deveria ter começado, farei um Project Charter (o nome em inglês parece impor mais respeito…*RS),  ele será colocado numa página a parte, em breve, ma hoje quero falar livremente sobre o que me levou a isso…

Por não ter esse plano o blog fugiu do controle, acabei seguindo o PMBOK a risca, nada contra ele, mas isso, além de deixar o blog ligeiramente chato  é desnecessário, existe o próprio PMBOK para isso, além de centenas de outras fontes,  vou finalizar a serie sobre o grupo de processos para não deixar algo inacabado,  mas tomarei outra linha daqui pra frente (que será refletida no Project Chart),  falarei sobre técnicas, metodologias e ferramentas, sobre situações práticas e meu objetivo será criar uma comunidade de Gerenciamento de Projetos, para isso abrirei o blog para outros Gerentes de Projeto que desejarem escrever, estou planejando um Forum de Discussões e mais alguns elementos para Transformar o Projetizando em uma Comunidade.

A Primeira Ação nesse sentido foi o lançamento do Domínio próprio:  PROJETIZANDO.COM.BR, este post está sendo replicado neste domínio e no domínio antigo projetizando.blgoprofissional.com.br, que a partir de agora deixa de ser o domínio principal, como ainda  tem bastante assinantes de feeds, postarei resumos periódicos, mas sempre direcionando para o novo endereço…

Enfim, esperem bastante novidades e muita informação em 2009.

Bons Projetos para todos.