Blog CMMI & MPS.BR

Para este mês estaremos montando um conjunto de dicas de coisas que devem ser feitas em cada um dos níveis do CMMI. Por ser muita coisa, estamos dividindo em blocos de aproximadamente 50 dicas. Ao todo esperamos postar mais de 300 dicas. Comentem!

Dicas gerais

1. Obtenha o patrocínio da alta direção – Esta é uma das coisas mais importantes!
2. Estruture o EPG logo no início
3. Estruture o Grupo de PPQA logo no início
4. Coloque como analista de PPQA pessoas muito experientes – normalmente seniores
5. Experiência de gerencia pode formar um excelente analista de PPQA
6. Implemente uma boa ferramenta de gerenciamento de configuração
7. Crie políticas para as PA’s coerentes com os objetivos de negócio
8. Garanta recursos e fundos para as atividades
9. Estabeleça processos padrão de desenvolvimento
10. Defina a estrutura da fábrica
11. Defina ciclos de vida de projetos
12. Estruture um framework de processos
13. Crie critérios para customização dos processos de desenvolvimento de projeto
14. Defina responsabilidades e forneça autoridade aos envolvidos
15. Treine todo mundo
16. Obtenha aprovação formal dos produtos
17. Obtenha o envolvimento e comprometimento de todos na organização
18. Leia o modelo – leia mesmo, de verdade. Se não entendeu algo, leia de novo e procure informações até entender o valor – lembre-se que tudo no CMMI tem valor, se você não esta vendo o valor é porque ainda não entendeu a PA
19. Se sua empresa compra muito serviços e projetos, avalie a implementação do CMMI para serviços (CMMI SVC)

Dicas de CM – Gestão de configuração

20. Planeje quais produtos serão mantidos em controle de configuração
21. Planeje as datas que os produtos passarão por baseline
22. Em configuração crie um ambiente de trabalho e um de baseline
23. Garanta segurança e integridade em ambos os ambientes
24. Faça auditorias independentes no ambiente de configuração para garantir que o processo esta sendo seguido
25. Documente todas as alterações nos produtos em baseline

Dicas de MA – Medição e análise

26. Especifique mecanismos para medições
27. Defina métricas alinhadas com os objetivos de negócio
28. Defina objetivos para os projetos
29. Defina objetivos organizacionais
30. Estabeleça um bom mecanismo de coleta e armazenamento de medições
31. Analise periodicamente os resultados das medições
32. Divulgue os resultados de medições
Veja o post completo →

Pesquisas apontam que pelo menos metade dos fracassos em projetos de TI vem da falta de gerenciamento de escopo.

Simplificando, o escopo do projeto, nada mais é do que o que foi combinado fazer.

Vamos à uma analogia: Preciso trocar os pneus do meu carro. Faço um levantamento dos produtos e serviços necessários e verifico que precisarei de:
- Quatro pneus [Produto]
- Troca dos mesmos [Serviço]
- Alinhamento [Serviço]
- Balanceamento [Serviço]

Bom, este é o escopo deste meu projeto “Trocar Pneu” e devo fazer uma gestão efetiva deste escopo, para não gastar mais que o previsto.

Vou na loja, faço o pedido e aguardo. Após meia hora o vendedor (que obviamente quer vender) me fala que seria bom eu trocar os amortecedores também porque estão ruins. Vamos parar um pouco neste ponto.

Trocar os amortecedores tem custo e o vendedor vai cobrar com certeza. Esta troca esta fora do meu escopo inicial e devo decidir se mudarei o escopo ou não.

Reparem que quem decide sou eu, só que esta decisão traz impacto (aumento do custo). Será que vai adiantar alguma coisa se eu chegar ao vendedor e “espernear” falando que isto estava “sub-entendido” na troca e por isso não vou pagar? Com certeza não. Eu ficaria muito feliz se ele fizesse isto de graça, mas isto não vai acontecer pois tem custo pra ele.

Voltando, decido por não trocar pois esta fora do meu escopo inicial e isto ultrapassará o valor que eu tinha previsto.

Se coloquem agora no lugar do vendedor (que é o nosso!) e simulem a mesma situação. Vocês dariam os amortecedores ao cliente?

É isto que não se pode fazer (dar algo não combinado), temos sim é que cumprir o escopo previsto em nossos projetos e sempre posicionar o cliente de possíveis necessidades de mudanças.
Mas lembrando, o escopo não muda, a não ser que alguém permita.
O Gerente do projeto deve sempre ser firme e demonstrar os impactos (esforço, custo, prazo, etc) e nunca permitir o aumento sem que o cliente concorde com os impactos (formalmente). Comunicação é primordial.

Você deve tratar os custos (estimativas em geral) dos projetos como se este dinheiro fosse sair do seu próprio bolso.

Em tempo: Alguns pontos ajudam muito a “definir o escopo” como:
- Uma proposta comercial bem elaborada;
- Deixar claro o que será feito e o que será entregue (tudo);
- Deixar claro o que não será feito;
- Deixar claro suas responsabilidades e as do seu cliente;
- Estimar com uma técnica segura sempre que possível – recomendo APF (melhora significativamente a acertividade);
- Fazer um bom planejamento e gerenciar de verdade o projeto;

Fazendo isto sempre em seus projetos, além de reduzir considerávelmente suas dores de cabeça com o projeto você também estará atendendo boa parte da parte de engenharia do CMMI

Veja o post completo →

A Imagem abaixo demonstra muito do que acontece atualmente em grande parte das organizações.

Alguns dos principais pontos relacionados à requisitos são:

1. Os requisitos devem ser documentados
2. Os requisitos devem ser aprovados
3. Os trabalhos devem ser aprovador
4. Eles devem estar sob gerência de configuração
5. Os requisitos somente podem sofrer alterações mediante análise de impacto, aprovação e replanejamento

Um ponto chave para reduzir problemas com comunicação é a formalização da mesma. Assim consegue-se mais envolvimento e comprometimento entre os envolvidos.