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 →

Complementando o post “A importância do PPQA“, vamos explicar um pouco como deve ser uma auditoria  de PPQA (Auditoria de Garantia da Qualidade) do seu planejamento até a conclusão dos trabalhos.

Tenha em mente que a área de PPQA deve ter autonomia e autoridade, desta forma, é importante que esta área responda aos maiores níveis da organização. Somente assim a auditoria será imparcial e terá seu foco na qualidade.

Vale lembrar que o principal objetivo da área de PPQA é fornecer visibilidade de como esta a qualidade dos produtos e o seguimento do processo á direção e gerência.

O planejamento da auditoria

Antes de tudo, a auditoria deve ser planejada. Durante a fase de planejamento o Analista de PPQA (vamos chamar apenas de PPQA) deve planejar como serão as auditorias e quando elas ocorrerão. É muito importante que sejam realizadas auditorias antes de entregas à clientes.

O Checklist de PPQA deve ser montado bom base no conjunto de processos que serão utilizados no sistema, além disso, os envolvidos no projeto devem ter conhecimento de como serão as auditorias e quais as responsabilidades de cada um.

A auditoria

Bom, chegou o dia de uma auditoria de PPQA, o que fazer?

Primeiramente, certifique-se de que os acessos as bases de produtos foram concedidos ao analista de PPQA. Na sequencia todos devem ser comunicados de que haverá a auditoria.

A principal ferramenta do PPQA é seu checklist, e com base nele ele vai auditar o projeto verificando coisas como:
- Os produtos foram desenvolvidos;
- Os produtos estão corretos;
- Os produtos seguem os padrões definidos;
- Os produtos foram desenvolvidos com base no processo;
- A qualidade dos produtos estão de acordo com o planejado;
- Entre outros.

Desta forma, ele segue verificando o checklist de PPQA (item por item) e vai classificando. Ao final ele terá um indicador de como esta a qualidade do projeto e de cada processo.

Um ponto que recomendo (mas não esta na PA PPQA) é que antes de se divulgar os resultados o PPQA apresente os resultados para o Gerente do projeto para ver se não tem algum “engano”.

Comunicação dos resultados

É muito importante que todos envolvidos no projeto recebam o resultado da auditoria. O responsável direto é o gerente do projeto, mas a equipe deve ter conhecimento de como esta o projeto e buscar resolver as pendências o quanto antes.

Tratando os desvios

Antes de tudo, o responsável pelo tratamento dos desvios ou definição de quem vai tratá-los é o gerente do projeto, o PPQA apenas apontará os desvios e verificar se os mesmos foram corrigidos. Aqui é bom lembrar que é muito importante que o PPQA estabeleça uma data para correção dos desvios.

Após esta data, os desvios que não foram corrigidos devem ser “escalados” para o superior direto do gerente do projeto, e assim consequentemente até chegar na instância mais alta.

Quais os tipos de auditoria de PPQA?

Falamos muito de projeto, mas existem diversos outros tipos de auditoria de PPQA como:
- Auditoria do ambiente de configuração
- Auditoria do processo de melhoria
- Auditoria do processo de gerenciamento
- Auditoria da área de treinamentos
- Auditoria do processo de medições
- Auditoria de qualidade de projeto
- Auditoria de qualidade de propostas e pré-venda
- Auditoria da área de PPQA (esta deve ser feita por um terceiro, preferencialmente fora da empresa)
- E algumas outras.

Bom, esta é uma visão bem simples e rápida de como é uma auditoria de PPQA. Em breve publicaremos um macro-checklist de PPQA para ajudá-los.

Atendendo a pedidos colocaremos uma descrição breve das PAs do CMMI para serviços.

Capacity and Availability Management (CAM)
Esta PA contem um conjunto de práticas que ajudam a organização a garantir que os recursos definidos para suportar os requisitos do serviço foram efetivamente utilizados.

Incident Resolution and Prevention (IRP)
Conjunto de práticas para ajudar a garantir que incidentes (casos ou problemas) possuem ações preventivas e são resolvidos em tempo hábil.

Strategic Service Management (STSM)
Práticas que ajudam a estabelecer e manter padrões de serviços em sintonia com as necessidades estratégicas e planos estratégicos.

Service Continuity (SCON)
Práticas que ajudam a estabelecer e mantar planos de contingencia para garantir a continuidade dos serviçois durante incidentes significativos

Service Delivery (SD)
Práticas que ajudam a entregar serviços que atendas os SLA’s estabelecidos junto ao cliente.
Service System Development (SSD)

Práticas que ajudam a analisar, conceber, desenvolver, integrar, verificar e validar o os serviços que devem ser entregue para atender as necessidades do cliente e SLA’s definidos.

Service System Transition (SST)
Práticas que ajudam a a implementar mudanças significativas gerenciando seus efeitos e impactos no serviço.
Veja o post completo →

A SEI esta lançando o CMMI-SVC, que é o CMMI para serviços. Segundo pesquisas, mais de 80% da demanda por TI no mundo é voltada a Outsourcing & manutenção, assim, este novo modelo vem para preencher uma lacuna que o CMMI-DEV não atendia. Várias organizações utilizavam a combinação CMMI + ITIL para atender serviços.

O que muda?
A boa notícia é que você vai poder utilizar seus processos CMMI-DEV sem problemas pois eles são os mesmos (com alguns ajustes).
Houve a adição das seguintes PAs (que explicarei mais tarde):
- Capacity and Availability Management (CAM)
- Service Continuity (SCON)
- Incident Resolution and Prevention (IRP)
- Service Delivery (SD)
- Service System Development (SSD) – Adição
- Service System Transition (ST)
- Strategic Service Management (STSM)

Outro ponto interessante é que o modelo prevê ações tanto para fornecedores quanto para clientes.

Enfim, se sua organização tem um processo CMMI em andamento e é focada em serviços, convém obter mais informações sobre o mesmo junto a consultoria que esta lhe ajudando.