Projetizando a Vida

Aguardei  a  quarta versão com certa ansiedade, ainda não li com a seriedade e atenção que merece (isso quer dizer ler com calma, várias vezes cada capítulo), mas posso afirmar que tive uma primeira decepção…

Eu acho que uma das falhas do PMBOK na sua versão anterior  e que permanece  nessa nova é a falta de um tópico sobre Gerenciamento de  Crises.

Não sei exatamente qual o critério para a criação de uma Área de Conhecimento, mas deixo uma pergunta aos membros do PMI:  Será que não Gerência de Crises não seria uma área de Conhecimento a  ser incorporada numa versão futura do PMBOK?

Sei que muitos vão falar que projetos bem gerenciados não geram crises…

Para esses eu peço que me citem 10, ou melhor, 5, ou ainda 3, ta bom se for grande, me contento com 1 PROJETO que não tenha tido nenhuma crise…

Antes de qualquer coisa: O que é uma crise?

Crise é aquela situação onde as três variáveis (prazo, custo e escopo) são comprometidos e a qualidade nem se fala…

Algo precisa ser feito, mas ninguém chega a um consenso do que deve ser feito, normalmente troca-se o gerente,  muitas vezes troca-se a equipe e algumas vezes cancela-se o projeto, mas será que isso é mesmo necessário?

Infelizmente na maioria das vezes é,  porque o Bom Senso foi deixado de lado, é preciso mostrar que algo está sendo  feito,  e o mais visível é substituir algumas “peças”,  e torcer para as coisas darem certo…

E as vezes dão, mas na maioria das vezes se escuta do cliente: “mas o fulano tinha prometido isso e aquilo…”, e engole-se mais um aumento de escopo!!!

Nessa hora  é que faz falta o Gerenciamento de Crises…

É  hora de pisar no freio,  chamar o bom senso de volta à  mesa e ao invés de procurar encontrar os culpados, o que normalmente se faz, precisa-se procurar os erros e as causas dos erros, e trabalhar em conjunto para encontrar a melhor solução…

Quando se chega nesse momento o prejuízo já está consumado para todos, achar a solução é ais importante e mais inteligente que achar o culpado…

Infelizmente na maioria das vezes,  talvez pela  falta da Área de Conhecimento de Gerência de Crises, a crise só é resolvida pela troca do Gerente do Projeto, e mesmo assim somente se o Novo Gerente tiver o Bom Senso de ouvir todos os lados do problema de forma imparcial de forma a formar a sua própria visão do problema, e buscar uma solução que diminua o prejuízo, visto que nesse momento ele já é um fato consumado.

A inspiração para escrever esse Post veio de uma reunião que tive hoje pela manhã, quando estava assumindo um projeto com “alguns problemas” para terminá-lo da melhor forma possível. Quando fui apresentado a Gerente de Projetos do Cliente ela falou, com uma “leve” desconfiança :  “Você é o Novo Gerente de Projeto?”

Eu respondi:  Não, sou o Gerente de Crises…

Nesse momento senti que o Projeto começou a entrar nos eixos…

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.

Oi pessoal,

 Segue um post referente a um definição curta e rápida do que é Scrum.

 

Segundo Ken Schawber [Schwaber 2004], “Scrum simplesmente oferece um framework e um conjunto de práticas que guardam tudo visível. Isto permite aos praticantes do Scrum saber exatamente o que está acontecendo e fazer no local os ajustes para manter o projeto na direção dos objetivos desejados”.

A primeira experiência com o Scrum ocorreu em uma fábrica de automóveis, em que se constatou que a utilização de equipes pequenas e multidisciplinares produzia melhores resultados. Em analogia a essas equipes, associou-se a formação do Scrum a de um jogo de Rugby. A partir de 1995, Ken Schwaber formalizou a definição de Scrum e ajudou a implantá-lo em desenvolvimento de software em todo o mundo.

 

 Figura 1. Formação chamada Scrum em jogo de Rugby

 Martin Fowler, um dos maiores estudiosos em desenvolvimento de software, comenta em seu artigo A Nova Metodologia [Fowler 2008] que: “Nos últimos anos, vem crescendo rapidamente o interesse em metodologias ágeis (ou ‘leves’). Também caracterizadas como um antídoto contra a burocracia ou uma licença para ‘hackear’.

Estas metodologias despertaram os interesses em toda a extensão da indústria do software”.

Dentre as técnicas de utilização do Scrum, há a entrega de produtos em períodos de tempo pré-estabelecidos, nunca inferiores há uma semana ou superiores há trinta dias. Para estimular o contato entre empresa e cliente, os projetos são revistos em períodos regulares de tempo, a essas ações dá-se o nome de Sprint. Ao término de cada Sprint, o cliente recebe um conjunto de funcionalidades desenvolvidas e prontas para serem utilizadas. A melhor maneira de comprovar se o software atende às necessidades é fazer com que o cliente o utilize, apontando as qualidades e o que falta ser aperfeiçoado.

É importante destacar que a participação ativa do cliente no processo de desenvolvimento de software faz com que sejam atribuídas a ele algumas responsabilidades como definição das funcionalidades do produto, decisão quanto às datas de lançamento de conteúdo e ajuste de funcionalidades. Em desenvolvimento ágil a empresa não vê seu cliente como mero comprador de software, mas como um parceiro na pesquisa e no desenvolvimento do produto. E o Scrum é apenas um dos meios para alcançar esse objetivo.

 

Referências

Schwaber, Ken (2006) “Desenvolvimento Ágil utilizando SCRUM”, FAQ.

Fowler, Martin. (1991) “A Nova Metodologia”, http://simplus.com.br/artigos/a-nova-metodologia/#N2A3

Rahal, Nelson Abu Samra Junior e Santos, Marcelo dos (2008) “Você sabe o que é Scrum”, http://www.knowtec.com/index.php?m=ver&id_item=18

 

 

 

 

Obrigado Edmundo e um abraço a todos,

 

Abu

http://blogdoabu.blogspot.com/

http://www.abuzitos.com.br/

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.