O Projeto Fatal - 1ª parte

Bem como prometido vou descrever uma história que aconteceu com um amigo na empresa em que ele trabalhava, antes quero destacar algumas coisas, primeiro, não vou divulgar o seu nome real, usaremos a alcunha de Charlie, e nem da empresa em que ele trabalha (ele esta lá até hoje), pois se eu fizesse isso ele nunca me perdoaria, segundo, os fatos aconteceram mesmo, se o que descreverei aconteceu com você também, pode acreditar é mera coincidência. Mas vamos à história.

Eu conheci o Charlie num curso de introdução as boas práticas em gerenciamento de projetos, ele me pareceu a primeira vista, meio perdido, conforme me confidenciou depois, que nunca ouvirá falar de gerenciamento de projetos, ele me disse que o diretor da empresa leu numa revista que aquilo era o futuro, que as empresas que teriam sucesso em longo prazo teriam que adotar, então decidiu “bancar um curso” sobre o assunto.

Ele é um cara muito legal fizemos amizade muito rapidamente, pois além de morarmos perto, voltávamos junto no mesmo ônibus, faziamos parte do mesmo grupo de trabalho, fora as cervejas que tomávamos após as aulas com o pessoal do curso.

Numas dessas cervejadas pós-aulas, estávamos falando sobre a experiência de cada um em gerenciamento de projetos, uma amiga (trabalhávamos juntos em uma empresa) disse que achava gerenciamento de projetos o futuro, outra disse que era a profissão que mais oferta teria no mercado, mas a melhor foi a resposta do Charlie, ele disse: “- Cara pra mim esse negócio de projeto era coisa de arquitetura, engenharia, nem imaginava que era isso que tô aprendendo.”

As semanas passaram, o curso foi chegando ao seu final, e o Charlie continuava mais perdido que cupim em metalúrgica, mas, ele se formou, primeiramente porque era um cara esforçado e também muito esperto, pois o tal diretor havia dito que se ele não fosse aprovado no curso, não precisaria nem vir trabalhar no dia seguinte. (palavras dele)

Bem, após o curso mantivemos contato com todo o pessoal, havíamos fortalecido um networking, em que pelo menos uma vez por mês se reuníamos para a tal cervejada, agora pós-trabalho.

Nessas cervejadas o Charlie vivia reclamando que a pior coisa que havia feito na vida foi ter ido a esse curso, o diretor dele determinou que tudo fosse baseado em projetos, ele tinha até que ministrar aulas sobre as “áreas do conhecimento” para o pessoal da empresa. Isso me deixou muito preocupado, pois o Charlie não era lá muito didático, mas até ai tudo bem.

Passados alguns meses, recebi uma ligação do Charlie pedindo ajuda, pois o maior projeto da empresa estava afundando e ele seria nomeado oficialmente o capitão do barco, ou seja, ele iria afundar junto. Falei para ele ficar calmo e que nos reuniríamos para tomar conhecimento do que estava acontecendo e qual seria a melhor estratégia a usar.

Bem chamei o pessoal do curso para se reunir, e o Charlie expôs o seu projeto.

No próximo post continuarei com a história...

P.S.: Charlie desculpe...rrrsssss

O ressuscitador de Projetos - Parte 1

Vi dias atrás em um grupo do Linkedin sobre projetos (Gerenciamento de Projetos) um post que me chamou a atenção, ele era fazia a seguinte pergunta:

- “Tenho um projeto de 2 anos que ainda não tem um escopo totalmente definido, por isso pensei em usar o SCRUM e ter entregáveis a cada 3 meses. Alguém já trabalhou em algo assim? Sugestões?”

Dentre diversas respostas algumas afirmavam que o problema estava localizado no escopo mau definido. O professor Farhad Abdollahyan, descreveu com muita autoridade sobre a sequência lógica de gerenciamento de projeto para se chegar ao cronograma do projeto: Termo de Abertura => Identificação de Stakeholders => Coleta de Requisitos => Definição de Escopo e EAP => Estimativa de Recursos, Custos e Durações das Atividades => Cronograma e Orçamento => Plano de Gerenciamento de Projeto e Linha de base de desempenho (Project Performance Baseline). Ele também afirma que independente da “metodologia” sendo ela ágil ou não, pois em ambas devemos saber aonde queremos chegar (visão) em termos macro, pelo menos, pois sem isso o projeto nunca acabará.

O SCRUM são bons para “time-boxing” ou seja definir funcionalidades (feature-boxing) a serem entregues não está possível ou desejável. Um exemplo pode ser o cliente desejando resultados incrementais ao invés de uma visão toda em Big-Bang.

Então temos o seguinte, o executor do projeto e o cliente/usuário definem paralela e simultaneamente os requisitos (demanda, documentada e formalizada) e o escopo (oferta, isto é a solução em termos de entregas) em ondas sucessivas, ou seja, progressivamente.

Outro colega, Douglas Braga, PMP, deu destaque as seguintes questões:

- O que é este Projeto? 

- Por que existe este projeto? 

- Quais são os objetivos desde projeto? 

- Quais são as expectativas de todos os envolvidos? 

- Quais são os Requisitos Detalhados para atender todas as expectativas?

- Quais serão os produtos deste projeto que irão atender a estes requisitos, ou seja, qual será a solução para esta encrenca? 

As respostas vão fazer com que você chegue bem perto do escopo do projeto.

Ele dá uma saída a essa questão dizendo o seguinte: “Time-Boxing ou Feature-Boxing irão te ajudar a entregar coisas durante o Projeto, o que irá ajudar a evitar as solicitações de mudança, pois o usuário terá menos tempo para pensar em coisas que ele quer”.

 

À vista de tudo o que foi descrito por todos chegamos a conclusão que abrangem muitas discussões nos fórum e redes profissionais em GP: Qual metodologia adotar?

Bem isso independe, se for Waterfall ou Agile, o que conta realmente é um escopo bem definido. Isso está claro ?

No próximo post vou descrever um case que ocorreu na empresa de um colega de profissão. Até lá...

Abraços