Blog CMMI & MPS.BR

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.

Vou deixar de lado toda parte histórica e vamos para a prática.
O principio de Pareto também é muito conhecido como a regra dos 80/20. Esta é uma ferramenta muito boa tando em projetos six sigma quanto no gerenciamento de projetos pois o Pareto lhe ajuda a focar no que realmente importa.

Vamos a alguns exemplos práticos de Pareto:

• 20% do tempo despendido produz 80% dos resultados
• 80% de suas ligações telefonicas são destinadas a 20% dos seus contatos
• 20% das ruas são responsáveis por 80% do trafego (não em São Paulo)
• 80% dos pedidos em um restaurante vem de 20% do menu
• 20% de seus clientes são responsáveis por 80% do seu faturamento
• 20% das pessoas causam 80% dos problemas
• 20% dos recursos de um sistema ocupam 80% do tempo de desenvolvimento

Faça alguns destes testes e você verá que o principio de pareto é verdadeiro.

Nos níveis de alta maturidade (CMMI 4 e 5 ou MPS.BR B e A) você utilizará muito Pareto que também é uma ferramenta indispensável em projetos Six Sigma.

Você não entendeu corretamente OPP se…

… uma tabela contendo os defeitos por fase parece um excelente modelo de performance de processos (PPM – Process performance model)
…A média de linhas de código produzidas por dia por desenvolvedor parece um baseline de desempenho de processo pra você
… um gráfico de controle usado para “gerenciar” defeitos escapados parece um excelente PPM para você
… um sistema e Earned Value Management parece atender completamente o nível 4 pra você

Você não entendeu corretamente QPM se…

… monitorar os bugs ao longo do ciclo de vida do projeto parece “gerenciamento estatístico” para você
… você recalcula os limites de controle de seu baseline pelo menos duas vezes ao ano
… decisões gerenciais são utilizadas para ajustar os limites de controle
… densidade de defeitos parece um perfeito subprocesso para gerenciamento estatístico

Você não entendeu OID corretamente se…

… 42 projetos six sigma – todos voltados à inspeção – fazer uma companhia ter maturidade nível 5
… uma melhoria de 5% em um processo com variação de +-7% parece excelente e pode ser implementada imediatamente
… o resultado (e força) de uma melhoria somente pode ser mensurado pelo poder de persuasão do autor
… as propostas de melhoria são desenvolvidas de acordo com a ordem de chegada
… você não consegue ver como PPMs – Process Performance Models e PPB – Process Performance Baselines podem contribuir com OID

Você não entendeu CAR corretamente se…

… você classifica como “severidade alta” os defeitos e diz “vamos rodar uma análise de causa e ver o que esta acontecendo”
… análise de causa é utilizada apenas para encontrar as causas raiz dos defeitos
… você não vê valor em aplicar DAR para selecionar quando utilizar ou não CAR
… você não vê o valor de aplicar CAR para selecionar quando e como aplicar OID
… você não consegue ver como PPMs – Process Performance Models e PPB – Process Performance Baselines podem contribuir com CAR

Durante uma auditoria de PPQA ou Revisão entre pares (RP) diversos itens são verificados e o resultado é um conjunto de itens em conformidade e desvios. Vamos focar nos desvios

Um desvio é um problema ou algo que não esta em conformidade com o previsto.
Vamos a um cenário:

Em sua empresa após o levantamento de requisitos, gera-se um documento contendo todos os requisitos e o cliente deve aprová-los. Este documento servirá de insumo para a próxima fase onde serão desenvolvidos protótipos.

Um desvio encontrado na auditoria de PPQA foi de que os requisitos não há evidências de que os requisitos foram aprovados pelo cliente

O analista de PPQA comunica isto a gerencia e estabelece uma data para correção – lembre-se que: “PPQA deve fornecer visibilidade de como esta o projeto a direção”.

O gerente do projeto é o responsável pelo projeto e conseqüentemente corrigir os desvios. Se ele não corrigir os desvios devem ser escalados para o nível superior e assim por diante.

Imaginando que “ninguém fez nada” e deixou os desvios paradinhos lá durante um mês.

O cliente começou a validar o sistema e não esta concordando com nada do que foi definido, e para ajudar quem esta validando entrou agora no projeto.

Tudo isto não seria problema se você tivesse corrigido os desvios, mas como não fez isto, o que pode fazer agora? Bom, na melhor das hipóteses, o prejuízo será pequeno.

Este exemplo é simples, mas uma grande parte dos prejuízos em projetos vem de situações como esta. Repare que se você tivesse corrigido este desvio no momento certo, o custo seria X, agora ele será no mínimo 10 X.
Veja o post completo →