Blog CMMI & MPS.BR

O caso que vou contar hoje aconteceu comigo a alguns anos atrás e faz pensarmos naquela conhecida frase: “Qualidade tem custo”.

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.

Todos nós temos conhecimento que o desenvolvimento de projetos de software é uma tarefa árdua e extremamente difícil. Um sistema mal construído pode gerar milhões de reais em prejuízos em poucas horas, dependendo do tamanho do cliente e do porte da operação suplantada. O primeiro registro de “bug” foi em 1945 quando a Oficial Naval Grace Murray Hopper, encontrou uma traça dentro de um dos computadores da marinha americana. O fato de ter encontrado um “bug” (inseto em inglês) dentro de um computador que estava com mau funcionamento por conta dessa ocorrência, permitiu com que o termo se tornasse comum na área de desenvolvimento de software e associado a falhas durante a execução.

Ao longo da história evolutiva do computador e do desenvolvimento de aplicativos, é muito comum totalmente normal encontrarmos situações na qual existiram, existem e ainda irão existir situações de problemas durante a realização de alguma tarefa em um determinado sistema. Mas em muitos desses casos, as conseqüências desses atos foram resultados de tragédias calamitosas que sacrificaram vidas humanas ou até mesmo prejudiciais ao meio ambiente. Um caso interessante, foi à explosão do ônibus espacial Columbia em 1986, quando alguns funcionários da própria NASA que haviam sido demitidos após o fracasso do projeto, declararam para a imprensa que o acidente aconteceu por conta de falhas no software na hora do lançamento, pois não tiveram testes suficientes no software. Veja o post completo →

DAR – Análise de decisão e resolução

1. Crie um guia para orientar as tomadas de decisões formais
2. Crie critérios que definam quando um processo de decisão formal deve ser realizado
3. Defina critérios para a seleção de alternativas
4. Identifique as soluções alternativas
5. Analise o que normalmente é feito em processos similares
6. Defina claramente o método que será utilizado para análise das alternativas
7. Nunca, jamais se esqueça de analisar as alternativas e documentar esta análise
8. Analise os riscos associados a escolha ou não de uma solução
9. Documente todo o processo de decisão formal
10. Mantenha os dados em gestão de conhecimento para consulta posterior

IPM – Gerenciamento integrado de projeto

11. Tenha uma base de processos
12. Mantenha uma base de melhores documentos, lições aprendidas, modelos, templates e outros
13. Mantenha um plano integrado de trabalho que contemple as atividades de outros grupos bem como previsão de alocação
14. Crie planos que definam como conflitos serão tratados
15. Defina critérios de entrada e saída para as atividades
16. Utilize os planos integrados para o gerenciamento do projeto (um plano de gerenciamento de projeto pode lhe ajudar bastante)
17. Periodicamente atualize a base de conhecimento da organização
18. Mantenha um canal para entrada de sugestões
19. Periodicamente avalie as sugestões e forneça feedback de como estão as sugestões
20. Defina o envolvimento dos stakeholders e comunique-os de suas responsabilidades
21. Identifique e gerencie as dependências e compromissos do projeto
22. Documente ações preventivas e/ou corretivas quando necessário

OPD – Definição do processo organizacional

23. Crie padrões para definição de processos
24. Documente os processos
25. Elabore uma matriz contendo os processos, produtos, atividades e responsabilidades
26. Documente o relacionamento entre os processos e produtos
27. Defina SDLC’s para os principais produtos e serviços
28. Defina critérios para tailoring dos processos quando necessário
29. Documente os processos tailoring dos projetos (quando necessário)
30. Mantenha uma base de medições
31. Periodicamente verifique se há necessidades de ajustes nos processos
32. Estabeleça padrões de infra-estrutura e ativos de processo de acordo com o papel
33. Realize revisão entre pares sempre que houver alterações nos processos
Veja o post completo →

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 →

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.