Brainstorm é uma palavra inglesa que, em uma tradução livre, significa “tempestade mental”. É uma técnica onde todas as idéias de uma equipe podem ser expostas sem um julgamento precipitado. Todas são avaliadas e levadas em consideração e servem para muitas coisas, como criar uma marca, um produto ou solucionar um problema.

Existem algumas dicas que podem ser adotadas para que o brainstorm seja feito de forma eficiente. A primeira delas é que se tenha um líder para dirigir a dinâmica e mediar os questionamentos e possíveis conflitos entre os participantes. Ele também é quem vai incentivar a discussão e fazer com que a equipe mantenha sempre o foco no objetivo proposto.

Outra dica é que as idéias sejam anotadas, sem filtro, de forma que todos possam lê-las. Pode-se usar para isso quadro branco ou flipchart, ajuda aos participantes na organização das idéias e pensamentos, facilitando os questionamentos e promovendo a melhoria contínua.

A terceira e última dica é que tenha-se um tempo determinado para a realização. Geralmente é uma dinâmica rápida, que leva pouco tempo, questão de minutos. O limite de tempo estimula os participantes a doarem-se durante aquele período e é preciso ser rígido com isso.

Ao final do brainstorm a melhor idéia é selecionada e espera-se que o objetivo tenha sido alcançado ou ao menos tenha-se chegado próximo a ele.

Quer ver como é um Brainstorm na prática? Assista qualquer episódio do seriado House, ele pratica isso muito (e é uma série excelente).

Esta técnica por muitos é considerada boa oportunidade para o surgimento dos talentos, pois é uma forma que todos conseguem expor suas idéias e isto faz com que todos vejam o potencial existente em cada um.

Veja o post completo →

Destruir a carreira de Gerente de Projetos é muito fácil, veja o que você NÃO deve fazer para arruinar a sua.

1. Adote a postura do “novo xerife na cidade”. Desconsidere os processos já existentes e faça mudanças profundas, já no primeiro dia. O legal é que todos se sentirão verdadeiros idiotas que nunca fizeram nada certo até a sua chegada. E melhor ainda: você estará tomando atitudes importantíssimas sem ter a menor idéia do que se passa no projeto.
   .
2. Preocupe-se apenas com as ferramentas: falar com alguém? Pra que? Tranque-se em sua sala e trabalhe loucamente no seu software de gerenciamento de cronogramas. Finja que os artefatos gerados por você são o que realmente importa. O que os “outros” estão fazendo é problema deles…
   .
3. Ignore seus stakeholders. Se ninguém nunca se preocupou em fazer uma análise das diversas partes interessadas, agradeça e aproveite. Isto iria complicar demais a sua vida.
   .
4. Peça muitos conselhos para as pessoas de sua equipe e faça exatamente o contrário do que lhe foi sugerido;
   .
5. Grite bem alto: “Isto está fora do escopo!” sempre que qualquer stakeholder abrir a boca;
   .
6. Mande documentos que servirão de base para discussões na reunião de status do projeto 30 segundos antes do início da reunião. E claro, faça questão de comentar: “Vocês receberam os documentos? Bom, eu os enviei”;
   .
7. Faça sessões de brainstorming mas não anote nada que você não concordar;
   .

Veja o post completo →

Um projeto exige muito esforço de muitas partes para alcançar o sucesso procurado. Tamanho esforço aplicado sempre deixa implícita uma questão: será que esse esforço todo levará o projeto ao sucesso nos resultados?

Na tentativa de estreitar o caminho que leva ao sucesso nos projetos, foram verificadas as direções mais comuns que levam ao seu inssucesso, tendo essas, portanto, que serem evitadas a todo custo. São elas:

Objetivos não definidos
Sem um escopo claro e consistente, o projeto perde em direção, dinâmica e, principalmente em fundamento, pois não vê definição final no que procura. O objetivo é o que alimentará todo o empenho da equipe, do gerente e dos stakeholders na busca pelo sucesso nos resultados.

Implementação mais lenta que o planejado
A dinâmica com que se apresentam os resultados do projeto é um termômetro de como a logística de distribuição das tarefas e o acompanhamento e controle das atividades estão em sintonia. A implementação anda na medida em que critérios como o conhecimento das potencialidades individuais e coletivas da equipe é conhecido e utilizado de forma adequada ao que propõe o planejamento do projeto.

Recursos insuficientes
Muitas vezes, a escassez de recursos é vista de forma tão forte como um problema que se esquece de vê-la como um desafio a vencer. Os recursos surgem sempre para a melhor utilização possível dentro do planejamento do projeto, no momento e métrica suficientes, para obtenção dos resultados ideais que justifiquem seu uso.

Surgimento de problemas não previstos
A prática faz crer que é improvável para um projeto caminhar sempre nos trilhos. Assim, o gerente precisa ficar atento para desvios inesperados, sempre com uma capacidade de gerar soluções na medida das necessidades e respeitando fatores preponderantes como prioridades, tempo de resposta, bem como riscos e consequências das soluções sugeridas. Quando um projeto é bem planejado e estruturado, fica menos sujeito a instabilidades causadas por imprevistos, mas, nem por isso, há garantias de que algo fora do esperado não possa acontecer.

Coordenação ineficaz de atividades
Uma equipe mau orientada pode ser classificada injustamente como limitada ou algo semelhante, quando, na verdade, a fonte de seu fracasso está em quem direciona seus passos, define suas ações e acompanha seus resultados. Da mesma forma, um projeto mau planejado, um risco mau avaliado, um prazo mau medido podem determinar um caminho mais curto e indesejado a projetos. A coordenação do projeto como um todo se descreve como sua coluna vertebral, de onde saem análises, pontos de vista, indicações, expertise e de onde as fraquezas gerenciais devem ser anuladas e ampliadas a todo tempo.

Veja o post completo →

Tempos atrás, nossa leitora Ana Carla me passou um link de um site bem legal, no qual se divertiu muito. Selecionei um dos artigos deles e vale a pena conferir.

eXtreme Go Horse (XGH)

1. Pensou, não é XGH.
   XGH não pensa, faz a primeira coisa que vem à cabeça. Não existe segunda opção, a única opção é a mais rápida.
2. Existem 3 formas de se resolver um problema, a correta, a errada e a XGH, que é igual à errada, só que mais rápida.
   XGH é mais rápido que qualquer metodologia de desenvolvimento de software que você conhece.
3. Quanto mais XGH você faz, mais precisará fazer.
   Para cada problema resolvido usando XGH, outros 7 são criados. Mas todos eles serão resolvidos com XGH, e isto tende ao infinito.
4. XGH é totalmente reativo.
   Os erros só existem quando aparecem.
5. Em XGH vale tudo, só não vale dar …
   Resolveu o problema? Compilou? Commit e já era.
6. Commit sempre antes de update.
   Se der errado, a sua parte estará sempre correta, e seus colegas que se danem.
7. XGH não tem prazo.
   Os prazos passados pelo seu cliente são meros detalhes. Você SEMPRE conseguirá implementar tudo no tempo necessário (nem que isso implique em acessar o BD por um script malaco).
8. Esteja preparado para pular fora quando o barco começar a afundar… ou coloque a culpa em alguém ou alguma coisa.
   Pra quem usa XGH, um dia o barco afunda. Quanto mais o tempo passa, mais o sistema vira um monstro. O dia que a casa cair, é melhor seu curriculum estar cadastrado na APInfo, ou ter alguém ou alguma coisa pra colocar a culpa.
9. Seja autêntico, XGH não respeita padrões.
   Escreva o código como você bem entender, se resolver o problema, commit e já era.
10. Não existe refactoring, apenas rework.
    Se der errado, refaça um XGH rápido que solucione o problema. O dia que o rework implicar em reescrever a aplicação toda, pule fora, o barco irá afundar.
11. XGH é totalmente anárquico.
    A figura de um gerente de projeto é totalmente descartável. Não tem dono, cada um faz o que quiser na hora que os problemas e requisitos vão surgindo.
12. Se iluda sempre com promessas de melhorias.
    Colocar todo no código como uma promessa de melhoria ajuda o desenvolvedor XGH a não sentir remorso ou culpa pela porcaria que fez. É claro que o refactoring nunca será feito. 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 →

O resultado de nossa primeira enquete foi dentro do esperado (pelo menos do que eu esperava). Quase metade respondeu que o que mais irrita e a má qualidade. O segundo colocado foi uma surpresa, pois com 27% dos votos, a Baixa experiência da equipe realmente irrita nossos leitores – Os fornecedores de serviços de TI devem prestar bastante atenção nesses dois fatores que abocanharam quase 75% dos votos.

Obrigado por participarem da enquete!

O título do artigo pode parecer debochado demais, porém infelizmente tenho visto esse tipo de situação que me assusta.

A cerca de quatro ou 5 anos, eu trabalhava como Gerente de Projeto em um grande banco.
Uma colega certo dia me perguntou se eu tinha algum livro de MS-Project. Levei alguns livros e perguntei o porquê do interesse.

Tomei um grande susto! A resposta não poderia ser mais peculiar. Oras!!! Quero aprender a usar o MS-Project pra virar gerente de projetos!!

Como diz o Galvão Bueno…. Bem amigos…. Qual o resultado?? A referida colega entrou num curso preparatório de certificação, “rachou” de estudar e tirou a certificação.? Preparou um belo curriculum enfeitado e voilá… Eis que foi admitida como Gerente de Projetos numa grande empresa de Telecom. E o melhor, com um salário que é aproximadamente um quarto do que ganha um Gerente de Projetos.

Percebe-se nitidamente um movimento no mercado corporativo onde pessoas das mais variadas formações desejam ser “Gerentes de Projeto”.

“Ora, tem status, cartão de visita com o cargo. É muito bom!!”. Parece brincadeira mas ouvi isso em vários cursos que ministrei sobre Gerenciamento de Projetos.

O que percebo é um totalmente desconhecimento acerca do Gerenciamento de Projetos no mercado. ?É comum vermos anúncios de vagas para Gerente onde se pede na verdade um Líder Técnico ou um Analista com conhecimentos de Gerenciamento.

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 →

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 →

Por volta de 2003 gerenciei um projeto de um portal interno para uma grande multinacional. O esforço estimado com APF foi de aproximadamente 7.000h e estava bem justo.

Este era nosso primeiro projeto neste cliente e o mesmo estava muito apreensivo com a qualidade pois o projeto envolvia mais de 10 áreas da empresa (marketing, RH, Engenharia, Presidência, etc).

A equipe prevista era de dois analistas e seis programadores. Então decidi mudar um pouco e trocar um destes programadores por um tester. No começo várias pessoas falaram que não daria certo e que o projeto atrasaria porque “faltaria braço”.

A tester que coloquei no projeto (Fabiana Custódio) era uma pessoa muito integra e que realmente se preocupava com a imagem da empresa. Para fortalecer este processo, no lançamento do projeto divulguei a todos seu papel e que nada sairia da empresa sem o aval dela. Em apoio ao processo implementamos também a bonificação por produtividade.

O projeto foi andando e começaram a aparecer os bugs (internos sempre), a Fabiana realizava os testes, encontrava os bugs e passava para os programadores corrigirem. Em um determinado momento começou um “movimento” para tira-la do projeto pois segundo alguns “os problemas estavam aparecendo e isto não era bom”.

Tentaram de diversas formas me convencer de que ela atrapalhava o andamento do projeto, mas sempre fui firme. Do ponto de vista gerencial os resultados estavam excelentes pois o cliente não encontrava erros em nossas entregas. Comercialmente o cliente também estava muito satisfeito.

Veja o post completo →

Uma das principais responsabilidades de um gerente de projetos é zelar pelo custo do projeto e usar este dinheiro da melhor forma possível (Leia o PMI para mais detalhes).

Apesar disto ser (vamos dizer) óbvio, não são muitos os gerentes que fazem uma boa gestão do custo, e, durante o planejamento do projeto o gerente do projeto deve analisar tudo o que deve ser feito e fazer uma análise de custo x benefício .

Se você tem 10.000 para fazer uma determinada coisa, e existe um “componente” que faz exatamente o que você quer por menos da metade do preço, porque não adquiri-lo? Bom, é muito provável que você já deva ter presenciado uma situação assim, e é mais provável ainda que a decisão tenha sido de “fazer” o requisito, perdendo assim uma excelente oportunidade para economizar.

Outro caso é: Em um sistema onde você o usuário se cadastra e escolhe seu estado a pergunta é: Será desenvolvido uma tela de manutenção de estados?

Cenário 1: Sim, o cliente precisa atualizar a lista de estados sempre que precisar – Custo: R$ 1.000,00 (referente à 20 horas de trabalho)

Cenário 2: Não, é uma tabela que raramente muda, o custo não justifica o benefício – Custo: R$ 0,00

É um caso simples, mas neste caso simples você já economizou um montante do seu custo. Claro que existirão casos onde estes desenvolvimentos serão necessários, todavia serão minoria e mesmo nestas minorias, provavelmente a contratação de um serviço (como o de CEP dos correios) saia mais em conta.

Uma dica: Pratique esta análise durante o planejamento. Provavelmente você terá boas surpresas.