Arquivos de April, 2009

Como é uma auditoria de PPQA? 26 April 2009 as 6:52 pm de Washington Souza

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.

+ O que é EVM – Earned Value Management Por Washington Souza 20 April 2009 as 1:50 am 5 comentários

Um bom método para monitoramento do desempenho de projetos é a técnica de Valor Agregado (EVM – Earned Value Management). Apesar de muito utilizada em países como os EUA, aqui no Brasil esta técnica ainda é pouco utilizada e um de seus maiores disseminadores é o PMI. Aliás, tenha em mente que além de gerenciar melhor seus projetos, você estará atendendo várias práticas do CMMI e algumas necessidades do Six Sigma.

Com EVM podemos ver coisas como:
- Como o projeto esta?
- Como ele deveria estar?
- Os gastos do projeto estão adequados ao trabalho realizado?
- O projeto será entregue dentro do prazo e custo?
- Qual a previsão de desvio de prazo e custo?

Exemplo simples de EVM

Entendendo as características básicas
Você faz o planejamento de um projeto que tem 10 dias e custo de 100.000.
A primeira coisa que você terá que fazer aqui é calcular o custo diário de seu projeto. Lembre-se que para isto você deverá ter um WBS bem detalhado e que reflita a situação real de seu projeto.
Você monta o WBS e obtém um planejamento como esse:Grafico com o custo planejado

Sempre recomendo transformar os números em gráficos pois fica mais fácil de se entender e reduz sensivelmente interpretações erradas.

Seu projeto esta em andamento e você coleta o custo do projeto todo dia. Seu projeto esta no sexto dia e quando você olha para o gráfico você acredita que o projeto esta ruim, pois o planejado para o dia é 40.000 e você já gastou 50.000.

Você apresenta este gráfico na reunião de acompanhamento semanal de projetos.
Grafico com o custo planejado de um projeto e o realizado
Veja o post completo →

+ Entendendo o gerenciamento de mudanças Por Washington Souza 14 April 2009 as 3:37 pm 9 comentários

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 →

+ Six Sigma + CMMI = Mais Qualidade Por Washington Souza 05 April 2009 as 5:36 pm 5 comentários

Visão rápida do Six Sigma

O Six Sigma e o CMMI são um casamento perfeito. Aos que não conhecem, vou explicar resumidamente o que é Six Sigma e como ele pode ajudar no CMMI.

O Six Sigma (ou seis sigma) é um modelo que foi criado inicialmente pela Motorola para melhoria de processos e redução de defeitos. Define-se como um defeito, uma anomalia em um produto ou serviço contra suas especificações iniciais. O Six sigma é altamente utilizado no planejamento estratégico para prover mudanças significativas nas organizações. Ele é aplicado tanto na redução de defeitos quanto na busca de oportunidades de melhoria.

DMAIC
Método DMAIC

O six sigma trabalha com dados reais dos processos e possui um conjunto de práticas que orienta os projetos de melhoria de forma sistemática e clara, para isso, utiliza-se um conjunto de ferramentas estatisticas que auxilizam no aumento de qualidade através de dados e fatos.

O six sigma conta com uma cultura de processos enxutos (lean) e otimizados para:
- Qualidade
- Satistação do cliente
- Redução de custos

Os projetos são normalmente desenvolvidos utilizando a metodologia DMAIC que possui um conjunto de práticas organizadas de modo a analisar de fato as causas dos problemas e propor soluções efetivas para os mesmos
Veja o post completo →

+ Descrição rápida das PAs do CMMI-SVC Por Washington Souza 02 April 2009 as 11:07 pm Nenhum comentário

O CMMI-SVC pode ajudar muito tanto fornecedor quanto clienteAtendendo 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 →

+ Plano de gerenciamento de projeto Por Washington Souza 01 April 2009 as 11:35 pm 1 comentário

Constantemente quando falamos sobre o Plano de Gerenciamento de Projetos (PGP) as pessoas indagam com: “Mas não é a mesma coisa que o plano de projeto”. Bom… a resposta é não. Vamos analisar o PGP em um cenário prático.

O plano de gerenciamento do projeto ajuda a ter ações pró-ativasO PGP tem por principal objetivo definir as ações que serão tomadas de acordo com o desempenho de diversos fatores do projeto, como:

Você esta fazendo um projeto onde o prazo é o ponto crítico. Este projeto é dividido em 3 fases com 10 dias cada e você enfrenta os seguintes problemas em cada fase:
Fase 1: Projeto atrasado em 3 dias, pois metade da equipe é formada de estagiários.
Fase 2: Projeto atrasado em 3 dias por indisponibilidade do cliente em validar os produtos.
Fase 3: Projeto atrasado em 3 dias por que o ambiente de validação não esta pronto.

Na maioria das empresas isto é encarado como causas normais de um projeto e acaba-se assumindo estes custos.

Com um PGP você deve prever os tipos de problemas e definir quais ações você tomará quando gatilhos forem acionados (Gerenciamento preventivo – CMMI3), imaginando que você montou o PGP deste projeto teríamos o seguinte cenário.

Fase 1: Seu projeto esta atrasado em 3 dias (você esta no 6º), mas isto não é problema, pois seu PGP diz que se isto acontecer você deve substituir os estagiários por planos e seu projeto terminará no prazo.
Fase 2: Falta um dia para acabar a fase e seu cliente nem começou a validar você pega o PGP e nele esta definido que se isto acontecer quem validará é o Sponsor ou haverá repasse de custos (e seu cliente já aprovou isto).
Fase 3: Você esta no 7º dia e o cliente informa que precisará de mais 3 dias para deixar o ambiente pronto. O seu PGP diz que se houver indisponibilidade do ambiente a validação será realizada com no seu ambiente de desenvolvimento (o cliente aprovou).

Enfim, note que antes do inicio do projeto houve uma análise minuciosa de possíveis problemas e ações que deveriam ser tomadas. Para apoio você também buscou as aprovações formais de cada uma destas ações. Ou seja, você foi pró-ativo (CMMI 3).

Os casos apresentados aqui são muito simples visto que seu objetivo é apenas de apresentar os benefícios do PGP, em um projeto real, seu PGP deve ser bem estruturado e você deve ter ações para os problemas mais comuns ou mais prováveis.

O PGP é um instrumento que ajuda muito no gerenciamento de projetos, considere sua implementação se você esta buscando o nível 3 de maturidade do CMMI.

Veja o post completo →