O que é mais importante para um gerente de projetos? Certificação, Pós Graduação ou formação?

Constantemente tenho me deparado com esse questionamento, e por isso resolvi escrever este post para dar uma resposta definitiva, direta e que não deixe dúvidas, enfim, sem enrrolação.

E a resposta é: Depende.

Existem no mercado muitos cursos (e isso não é prerrogativa do Gerenciamento de Projetos) “baratinhos”, que prometem o impossível e que tentam forçar o “candidato a  aluno”  a uma decisão tendenciosa que resulte na compra do curso oferecido. A maioria deles vem com um carimbo como “alguma coisa PMI” ou “alguma coisa PMP”.

Não gosto dessa posição por achar que ela caminha pelo limite da ética, um argumento mais forte e ela cai para o lado errado…

Por isso eu respondo Depende, e procuro ajudar quem faz a pergunta a encontrar sua própria resposta, porque o que serve para um, pode não servir para outro e assim por diante, então, vamos analisar esses três caminho:

Certificação

As certificações, e a Certificação PMP oferecida pelo  PMI não é exceção, não tem por objetivo ensinar algo, mas avaliar se o candidato já tem conhecimento suficiente para assumir a função de gerente de projetos, é um “carimbo de atestado de competência”, ou… vamos falar diferente, atesta que o canditato se deu bem na prova.

Estes certificados são reconhecidos pelo mercado, e apesar de não concordar com essa fábrica de certificados isso, é uma realidade de mercado e faz diferença na carreira profissional, porém, os cursos de certificação PMI ou qualquer outra, não tem por objetivo ensinar nada ao candidato. O Objetivo é preparar o candidato (que já CONHECE o assunto) a passar na prova e tirar sua certificação.

Portanto não é indicado para quem quer iniciar a carreira. O Público alvo é quem tem MUITO conhecimento e quer apenas comprovar isso, com um certificado reconhecido internacionalmente.  Mesmo porque, pelas regras do PMI (que muitos tentam burlar com informações falsas) é preciso ter 4.500 horas de experiência para se candidatar a prova.

Veja o post completo →

1. Você não consegue fazer um bebê em um mês usando nove mulheres
2. O mesmo trabalho será estimado de forma diferente por 10 analistas ou por um mesmo analista em 10 diferentes vezes
3. A palavra mais útil e menos usada no gerenciamento de projetos é “NÃO”
4. Você pode convencer um alguém a assumir um prazo irreal, porém, você não pode obrigá-lo a cumpri-lo
5. Quanto mais ridículo o prazo, mais caro e difícil será cumpri-lo
6. Quanto mais desesperada a situação, mais otimista ela é
7. Poucas pessoas conseguem resolver os problemas em um projeto, porém muito mais pessoas criam problemas acima da capacidade das primeiras resolverem
8. Você pode congelar os requisitos de um sistema, porém não consegue congelar as expectativas dos usuários
9. Não existe almoço grátis – se alguém te ofereceu um, você com certeza vai pagá-lo
10. Congelamento de requisitos e o abominável homem das neves são parecidos – ambos são mitos e ambos se derretem quando o calor apropriado é aplicado
11. As condições sob as quais uma promessa e feita são esquecidas, porém, a promessa será sempre lembrada
12. Um usuário somente lhe falará o que lhe for perguntado – nada mais
13. A primeira coisa para um projeto dar certo é que os stakeholders queiram que dê certo
14. Diante de varias interpretações de um comunicado, a menos conveniente é a mais correta
15. O que não está escrito, não existe ou não foi dito
16. Parkinson e Murphy estão vivos e muito bem – no seu projeto
17. Quem não sabe aonde quer ir, nunca chega
18. Para quem está perdido, qualquer caminho serve
19. Se você legou 10h para fazer 90% de uma tarefa, precisará de pelo menos outras 10h para concluir os outros 10%
20. Prazo e fidelidade de sistemas são promessas difíceis de se cumprir
21. Depois que passei a estudar mais, trabalhar mais e planejar melhor, minha sorte mudou
22. Em projetos, não confunda folga nos prazos, com prazos dos folgados
23. Se você não respeita sua equipe, porque quer que ela te respeite?
24. A logística de um projeto sempre exige àquilo que você esqueceu
25. Reunião sem pauta vira happy-hour
26. Reunião sem ata, não existiu
27. Para o usuário, o que você esqueceu sempre é o mais importante
28. Equipe muito grande em projetos é como chinês fazendo túnel, eles colocam um buzilhão de chineses de um lado da montanha e outro buzilhão do outro lado. Se tudo der certo eles fazem um túnel, se der errado eles fazem dois
29. Grupo de trabalho – quando você está dentro é equipe ou grupo de trabalho; quando você está fora é panela
30. Para tocar o seu projeto, conheça bem: o organograma, o mandograma, o orfacograma, o mafiograma, e fundamentalmente, o secretariograma

Veja o post completo →

No começo de minha carreira em TI eu trabalhava em uma grande empresa de Campinas onde o ambiente principal era mainframe (COBOL). Naquela época uma das coisas que eu e o resto da equipe menos gostava era que toda vez que tínhamos que entregar um programa, a gente tinha que entregar algumas confirmações de que fizemos os testes solicitados pelo analista.

Isso era muito estressante pois terminávamos o programa, testávamos, e quando íamos fazer o teste com os dados que o analista passou… dava erro. Logo, tínhamos que rever todo o programa, encontrar o que não estava certo e resolver até tudo estar ok e de acordo com os dados do analista. Para ajudar, o analista somente recebia o programa com as telas (evidências de testes) confirmando que havíamos passado por todos os testes que ele solicitou.

Naquela época (meados de 90) ninguém lá (nós programadores) gostava disso, mas, com o passar do tempo acabamos percebendo o quanto aquilo era importante e contribuía para a qualidade.

Estas confirmações, ou, vamos chamar de evidências de testes, ajudavam muito na qualidade pois, ninguém entregava programas com erros (na verdade até entregava). Os analistas solicitavam evidências de teste das regras mais críticas e criavam cenários que faziam com que passasse por cada “IF”.

Imagine uma função de bonificação onde você entra com dois valores e retorna o bónus do vendedor. Eles passavam algo assim:
Bonus (100.000,30.000) retorna 5.700
Bonus (50.000,4.000) retorna 0
Bonus (60.000,10.000) retorna 0

Criavam-se cenários que verificassem as principais regras de negócio. Nossos programas tinham que dar o resultado definido pelo analista, se desse algo diferente, provavelmente o programa estaria errado (e em 99% das vezes estava), e, para garantir que tínhamos feito estes testes, os programas só eram aceitos com um print da tela com o resultado.

Claro que ainda assim apareciam alguns erros, mas eram poucos. O fator psicológico ajudava bastante.

Veja o post completo →

Olá, tenho recebido muitas mensagens perguntando como avaliar fornecedores que “usam CMMI”. Recebi e-mails com perguntas como:

“… Selecionamos três fornecedores que possuem certificação CMMI… Gostaria de algumas dicas do que podemos fazer para garantir que eles usam o CMMI…”
“… Como posso verificar que meu fornecedor segue o CMMI?”
“… o que meus fornecedores precisam fazer para estarem aderentes ao CMMI…”

Foram várias mensagens, mas a pergunta é praticamente a mesma: “Como avalio meus fornecedores CMMI/MPS.Br?”

Antes de mais nada, temos que lembrar que modelos como CMMI e MPS.Br nada mais são do que um conjunto de boas práticas e recomendações em gestão e engenharia de software. Um nível é atribuído quando uma empresa mostra (de forma independente e oficial) que executa determinadas práticas.

Atendendo aos diversos pedidos, montamos uma lista com 10 coisas que você (como cliente) pode analisar e verificar em seus fornecedores.

• Empresas CMMI 2 praticam os 7 primeiros itens
• Empresas CMMI 3 praticam os 9 primeiros itens
• Empresas CMMI 4 ou 5 praticam todos os itens

10 dicas do que verificar em seus fornecedores sobre CMMI e MPS.Br

1. Você recebe a equipe “que paga”?

Segundo os modelos, cada profissional deve estar apto para executar suas atividades. Entende-se por “apto” que ele possui todo conhecimento e capacitação necessários (obvio, não?). Porém, em muitas empresas isso não acontece.

Você tem certeza de que aqueles cinco programadores java “plenos” são mesmo plenos (e Java)?

Outra coisa que atrapalha muito nos projetos é a rotatividade, pois é certo que seu fornecedor não vai ter alguém na “prateleira” com o mesmo perfil e capacitação que a pessoa que saiu. Se seu projeto troca de analista toda hora, seguramente você terá problemas em breve. Isto atrapalha tanto você quanto seu fornecedor, mas, normalmente ele não vê isso como problema.

A regra é simples, se você pagou por x plenos, y seniores e z juniores, o fornecedor deve te disponibilizar estes profissionais.

Veja o post completo →

Sejamos sinceros! Fazer registros de reuniões e distribuí-los entre os participantes é uma tarefa nada empolgante. Para muitos é mera formalidade e não possui utilidade alguma. Não são em todas reuniões que faço registros como sugerido no Efetividade, em algumas apenas anoto as pendência e já saio me dedicando a elas, entretanto tem sido cada maior o número de reuniões que venho registrando. Principalmente porque encontrei uma forma bastante ágil de fazê-lo e que para mim tem sido muito útil.

Nas reuniões que conduzo, gosto muito de utilizar o quadro para fazer anotações das idéias e pontos importantes que surgem durante a reunião. É uma forma de garantir que não sejam esquecidos e também permite que todos presentes acompanhem visualmente a evolução da reunião. O que traz uma série de vantagens:

• Quando registro alguma idéia no quadro, os participantes validam na hora se minha percepção é fiel a idéia apresentada;
• No quadro é possível fazer desenhos, setas e rabiscos em diferentes cores, o que além de trazer uma melhor organização, dá uma certa dinâmica a reunião;
• Este dias ouvi uma piada em que Moisés alertava a Deus que se os 10 mandamentos fossem representados com diagramas e não leis textuais, talvez a humanidade tivesse os compreendido. Certas coisas são difícieis de transmitir em um texto, rabiscos e desenhos no quadro são muito representativos e podem transmitir algumas coisas com mais facilidade.

Porém muitas das informações representadas no quadro são perdidas nas atas formais. Talvez sejam necessário 3 parágrafos para detalhar uma idéia rabisca às pressa em uma lousa…

Hoje, graças ao advento das câmeras digitais é possível tirar fotos e em poucos minutos anexá-las em um documento e repassar aos participantes. Mesmo com celulares já é possível tirar fotos boas que permitam a releitura do quadro construído durante a reunão. Acreditem, voltar os olhos para uma foto do esquema original, criado para organizar as idéias, pode resgatar muitas informações que uma ata textual talvez não conseguiria! Fazendo uso deste recurso otimizei bastante meus registros.

Atualmente registro os participantes, local, objetivo e tópicos os mais importantes. Faço isso de uma forma bem branda, pois anexo as foto na ata. Dessa forma não há necessidade de digitar todos detalhes, uma vez que durante a reunião os tópicos importantes vão para o quadro e a foto traz um resumo bastante significativo sobre cada um.

Exemplo: Cópia tirada uma aula

Veja o post completo →

O Scrum é compatível com o CMMI? Sim e não. A formalização requerida pelo modelo CMMI contrasta teóricamente com a agilidade no tempo de desenvolvimento de software.

Abordagens ágeis são criticadas devido ao fato de apresentarem muito pouco design de arquitetura e pouca documentação e quase nenhuma formalização. Abordagens rigorosas são criticadas por serem burocráticas e serem de difícil adaptação à mudança.

O modelo CMMI descreve “o que fazer”, enquanto a metodologia ágil, como o Scrum, descreve “o como fazer”. Isso não quer dizer que seja impossível adotá-las em conjunto. As práticas estabelecidas pelo CMMI não interferem em como devemos executá-las (conforme proposto por métodos ágeis).

O importante é entender o que o CMMI pode adaptar métodos ágeis a essa realidade sem perder o controle do CAOS, pois o CMMI é aberto a várias formas de interpretação e o modelo não desceve “o como fazer”.

Lembrando que você pode utilizar o Scrum com outras metodologias ágeis como o XP e FDD por exemplo. Abaixo pode ser vista uma tabela que mostra todas as áreas de processo do CMMI e quais são satisfeitas por cada uma dessas metodologias.

Artigo original em Inovatividade

1. Não suponha. Pergunte
2. Não acredite cegamente… Verifique
3. Analise os fatos sobre dados de fonte conhecida (e confiável). Conheça o histórico
4. Utilizar cases como forma de decidir melhor
5. Lembre-se que não dá para fazer um omelete sem quebrar os ovos
6. Não prometa além de sua competência
7. Use de referências. Crie paradigmas
8. Não jogue com 100%
9. Tenha sempre um plano B (para usa-lo quando necessário)
10. Separe o crítico do importante. Inicie rápido pelo crítico
11. Analise sempre os custos antes de tomar uma decisão
12. Utilize indicadores históricos e de tendências
13. Analise os impactos de mudanças
14. Acredite mais do que os números te dizem do que o que as pessoas te dizem
15. Faça isto rápido e decida. Acompanhe a decisão e corrija rotas

Veja o post completo →

No post Tutorial mini projeto – o nascimento da idéia iniciamos um mini tutorial de um projeto.
Apenas relembrando, no final geramos a seguinte tela:

A tela foi aprovada e seu cliente (que é seu amigo) indaga:  ”Legal, é isso mesmo que eu quero. Quando você me entrega e quanto isso vai me custar?”

Você poderia responder essa pergunta de dois jeitos: Um, chutando, outro, fazendo uma estimativa de custo, prazo e esforço. Obviamente você opta pela segunda (certo?).

Bom… com a tela em mãos, vamos usar uma técnica de estimativa, existem várias, mas, vamos escolher APF – Análise de pontos por função.

Para efeito didático, vamos usar uma visão simplista do APF, mas é bom lembrar que a técnica é muito interessante e assertiva. Eu particularmente sempre recomendo o uso de APF.

Primeiramente existem 5 elementos* que podem ser contados em APF:

• Entradas externas (EE)
• Consultas externas (CE)
• Saídas externas (SE)
• Arquivos lógicos internos (ALI)
• Arquivos lógicos externos (ALE)

* Vou deixar para vocês irem atrás do que é cada um

Existe uma tabela de pesos de cada elemento de APF por complexidade. Pra definir se algo é simples, médio ou complexo existem critérios, mas por ora, vamos definir que tudo é de complexidade média, assim facilitaremos nossa contagem. Veja o post completo →

1. Busque a harmonia e o equilíbrio no ambiente e no seu dia
2. Seja transparente, justo e coerente
3. Não prometa além de sua competência
4. Você é gestor, não um líder sindical
5. Use de as referências e paradigmas em vigor
6. Não suponha. Pergunte!
7. Não jogue com 100%.
8. Separe o crítico do importante. Inicie pelo crítico
9. Nas negociações, lembre-se que existe inteligência do outro lado
10. Particione as tarefas. É mais fácil gerenciar partes menores.
11. Tenha controles. Trabalhe com indicadores. Acompanhe-os e proponha acões de melhoria
12. Persiga metas desafiadoras e aceite mudanças
13. Respeite as regras e orientações. Exija o mesmo da sua equipe
14. Termine, conclua o que começou. Seja “acabativo”
15. O sucesso de ontem não garante o sucesso de amanhã
16. Tenha disciplina – dê exemplo – “Faça o que digo e faço”
17. Delega-se atividades e tarefas mas não responsabilidades
18. Seja um líder ao invés de um chefe
19. Fale menos e faça mais – mostre resultados
20. Gerencie como se o negócio fosse seu
    

Veja o post completo →

Prólogo

O objetivo deste mini-tutorial é mostrar como se inicia um projeto.
Para facilitar o entendimento (e disseminar conhecimento) ele é focado na simplicidade, facilitando assim o entendimento.

A estimativa de tamanho em APF toma por base que todos os elementos são de complexidade média, todavia é importante vocês terem em mente que isto é apenas o início. Em se interessando procurem ler mais sobre estimativa, planejamento, desenvolvimento de requisitos e controle de mudanças – aos que estão iniciando com MPS.BR ou CMMI, este tutorial vai ajudar bastante nos primeiros níveis.

Tutorial Mini Projeto – O nascimento da idéia

Um amigo te liga e pede para você fazer uma visita pois ele precisa de um projeto, ele te fala que é bem simples e precisa apenas de um aplicativo para gerenciar seus contatos.

Chegando em seu escritório, a conversa começa e ele fala que tem mais de 1.000 contatos em uma agenda (papel mesmo) e que quer (e precisa) automatizar isso. Na sua cabeça você já percebe que terá uma tela (até agora).

Conversa vai, conversa vem, ele comenta que um grande problema que ele tem é que ele não consegue dizer de onde são os contatos. Ele comenta que se ele pudesse agrupar-los, isso o ajudaria muito.

Ele também comenta que gostaria que tudo ficasse em uma única tela, ele não gosta de ficar passeando de uma tela pra outra.

Veja o post completo →

Hoje, gostaria de conversar sobre um assunto muito sério: A importância do Sponsor em um programa de melhoria de processos.

Este assunto passa despercebido em diversas implementações, mas ter um sponsor comprometido com o programa de melhoria é fundamental.

Nos últimos 3 meses fiquei sabendo de pelo menos 3 casos de implementações que afundaram.

No pior caso, o Sponsor já havia implementado CMMI em empresas anteriores e conseguiu em 3 anos os níveis 2 e 3. Ele saiu da empresa e o novo Sponsor conseguiu destruir o EPG em apenas 2 meses (!!). Resultado, hoje os projetos desta empresa não tem sequer um plano de projeto “em papel de pão”, a área de PPQA foi desfeita, assim como o EPG. O resultado da avaliação esta publicado no site da SEI, mas a empresa não vai conseguir renovar no ano que vem, pois não há mais nada. Jogou-se tudo fora, inclusive o dinheiro dos acionistas.

Em outro caso que aconteceu no mês passado, trocou-se o sponsor e o novo chamou uma consultoria CMMI e perguntou o absurdo: ”Quanto que eu tenho que pagar para comprar (!!) o CMMI 2?”.

E no ultimo, que aconteceu no início do ano, o novo sponsor, a três meses de um SCAMPI decidiu parar o projeto e alocar a equipe em projetos por causa da crise. Resultado, o projeto parou, a maior parte da equipe saiu e agora a empresa terá que investir tudo novamente.

O investimento em um programa de melhoria de processos é alto e é necessário que o Sponsor compreenda os benefícios e apóie o programa.

Parece óbvio, mas casos como estes acima acontecem muito. E repare que tanto o CMMI quanto o MPS.BR falam muito disso.

Então, procure sempre conscientizar o sponsor dos benefícios, retorno e obter com ele o comprometimento e compromisso com o programa, garantindo isso você já terá dado um grande passo.
Veja o post completo →