Posts Tagged ‘ Qualidade

Qualidade custa mais? (caso real) 09 September 2009 as 12:44 am de Washington Souza

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.

Leia o post completo →

+ Descrição de cargos e responsabilidades Por Washington Souza 09 August 2009 as 2:13 am 1 comentário

A descrição de papéis e responsabilidades (também conhecida como descrição de cargos e responsabilidades) é uma coisa básica na industria, porém em TI ela ainda esta engatinhando.

Vamos fazer um teste, procure em sua empresa se há uma documentação definindo claramente o que você (ou alguém com o mesmo cargo) deve fazer. Bom… provavelmente em mais de 90% dos casos não haverá nada ou uma definição informal do que é.

O mesmo vale para os níveis de senioridade.

Mas, porque é tão importante ter essa descrição? Simples: organização, produtividade e escala.

Tendo os crítérios, você reduz riscos de:
Contratar um junior achando que é senior
Enviar demanda a um profissional que não esta apto a executa-la
Ter diferentes faixas salariais para o mesmo perfil
Não cumprimento de prazos
E outras

Vale lembrar que esta definição deve ser apoiada pela política organizacional e deve ter a aprovação e comprometimento da alta direção.

Agora, vamos a um exemplo simples de como deve ser uma “descrição de cargos e responsabilidades”:

Cargo: Programador Junior Java
Formação: Técnica, superior ou curso que ateste os conhecimentos

Conhecimentos:
1. UML
2. Java
3. …

Habilidades:
1. Conversação em inglês
2. Digitação rápida
3. …

Responsabilidades:
1. Entregar os produtos com a qualidade definida
2. Apontar diáriamente as horas trabalhadas nas tarefas específicas
3. …

A quem se reporta: Gerente de desenvolvimento

É muito importante você definir critérios para os elementos evitando que alguém que saiba apenas a frase “the book is on the table” seja classificado com “Conversação em Inglês – OK”

Lembrando, este é um exemplo básico, da pra evoluir bem com elementos como: “Elementos Obrigatórios e Opcionais”, “Faixa Salarial”, “Atuação secundária”,”autoridade”, etc, etc, etc

Os que estão envolvidos com OT ou GRH devem montar esta definição para cada cargo (papel ou função) de sua organização e segui-la.

Abraço a todos.
Veja o post completo →

+ Programa de qualidade MPS.BR Por Washington Souza 05 August 2009 as 12:00 pm Nenhum comentário

A partir de hoje também estaremos falando de MPS.BR aqui no Blog CMMI. Então não estranhe pois quando falarmos de uma PA, também colocaremos o processo equivalente do MPS.BR.
Aos que não conhecem, o MPS.BR é um modelo de qualidade muito parecido com o CMMI e mantido pela Softex. Ele foi baseado na ISO 12107, ISO 15504 e no próprio CMMI. Outro ponto interessante é que ele também é organizado por estágios, mas, diferente do CMMI, ele tem 7 estágios.

A – Em Otimização;
B – Gerenciado quantitativamente;
C – Definido;
D – Largamente Definido;
E – Parcialmente Definido;
F – Gerenciado;
G – Parcialmente Gerenciado.

Ele tem poucos anos, mas tem trazido excelentes resultados à comunidade de software do Brasil. Atualmente mais de 100 empresas foram avaliadas em algum nível do MPS.BR e muitas destas continuam a jornada para os níveis mais altos.
Isto é excepcional pois acredito que dentro de 3 à 5 anos teremos pelo menos 40 empresas brasileiras avaliadas em alta maturidade.

MPS.BR e CMMI

No ritimo atual, acredito que este ano a quantidade de avaliações MPS.BR já deva passar a quantidade de avaliações CMMI aqui no Brasil.

Se você se interessou procure a Softex e veja como participar e obter subsidio do governo (sim, o governo subsidia parte do processo).

Enfim, é um modelo muito (muito mesmo) simular ao CMMI. Vale a pena o investimento.
Veja o post completo →

+ Uma visão geral sobre qualidade de software Por Rodrigo Ricci 31 May 2009 as 11:26 pm Nenhum comentário

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.Qualidade de software com CMMI

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 →

+ Dúvidas frequentes sobre PPQA (FAQ PPQA) Por Washington Souza 18 May 2009 as 3:24 am Nenhum comentário

O que é PPQA?
PPQA significa Process and Product Quality Assurance (Garantia de qualidade de processo e produto) e é a área responsável no CMMI pela qualidade tanto nos projetos quanto organizacionalmente.

Como PPQA realiza seus trabalhos?
A principal ferramenta de trabalho do PPQA (vamos chamar apenas de PPQA o analista de PPQA) é o checklist de auditoria. O PPQA deve seguir o checklist e verificar se o processo esta sendo seguido conforme previsto

Qual o resultado dos trabalhos de PPQA?
Um relatório mostrando como foi a auditoria. Este relatório deve ser enviado à todos envolvidos no projeto

Como PPQA ajuda nos projetos?
O principal objetivo é mostrar à alta direção como esta o projeto (o que esta em conformidade e o que não esta)

PPQA audita apenas projetos?
Não, diversas outras atividades de suporte devem ser auditadas para garantir que o processo esta sendo seguido. O principal exemplo é OT.

A quem PPQA responde?
À alta direção da empresa (presidência ou direção)

Porque PPQA responde para a alta direção?
Para garantir independência e que não haverá conflito de interesses ou manipulação dos resultados. A alta direção deve saber a real situação dos projetos.
Veja o post completo →

+ CMMI: Ajuda ou atrapalha? Por Washington Souza 08 May 2009 as 10:43 pm 3 comentários

Olá pessoal, já a um bom tempo estou querendo escrever sobre isso, mas o texto de João Werther Filho da Desenvolva foi certeiro. Ele explica se o CMMI ajuda ou atrapalha de um jeito muito simples e fácil.

CMMI: Ajuda ou atrapalha?

De uma forma bem sucinta, o CMMI (Capability Maturity Model Integration – Modelo Integrado de Capacitação e Maturidade) é um modelo bastante aceito e de alta credibilidade no que se refere a medir a maturidade do processo de uma organização. Quanto mais madura o seu processo, maior a qualidade do produto final oriundo do processo. Pelo menos é o que pensa o SEI (Software Engineering Institute), órgão da Universidade Carnegie Mellon, patrocinado pelo Departamento de Defesa dos Estados Unidos, e responsável pela elaboração e manutenção do modelo CMMI.

yes or noO SEI acredita que a maturação do processo da organização é diretamente proporcional à qualidade do produto final obtido, mas não é só isso. O SEI acredita que o modelo CMMI também facilita para que a organização consiga elaborar o produto final do seu projeto com meios para que o custo, esforço real, e qualquer outra variável relevante ao processo, não se desvie muito do estimado e que tenha a melhor produtividade possível. E tudo isso aplicando as melhores práticas existentes dos processos. As melhores práticas de gerenciamento de projetos, por exemplo, que estão publicadas hoje no PMBoK (Project Management Body of Knowledge – Corpo de Conhecimento da Gerência de Projetos), estão, de certa forma, descritas no modelo. Em outro exemplo mais aplicável para nossa área, ou seja, no caso de processos de desenvolvimento de software, estão contidas no modelo as melhores práticas da engenharia de software.

Para muitos, um processo de desenvolvimento de software baseado no CMMI é muito burocrático e o custo do produto final termina aumentando. Afinal, segundo eles, nem todas as práticas são realmente necessárias na maioria dos casos e muito trabalho poderia ser evitado, principalmente em projetos pequenos. Frases como “O CMMI engessa o processo”, “O custo de desenvolvimento fica alto devido ao CMMI”, “O CMMI vai contra um processo ágil” são emitidas freqüentemente por profissionais que seguem essa linha de pensamento. Para eles, a qualidade gerada pelo CMMI possui um preço muito alto a se pagar e não agrega muito valor à organização.

Veja o post completo →

+ Qual o impacto que um desvio não corrigido de PPQA pode trazer? Por Washington Souza 03 May 2009 as 11:53 pm Nenhum comentário

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.

CMMI e o custo da não qualidade - quanto maior o tempo, maior o custo
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 →

+ Como é uma auditoria de PPQA? Por Washington Souza 26 April 2009 as 6:52 pm 2 comentários

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.

+ 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 →

+ Definindo objetivos de forma clara Por Washington Souza 24 February 2009 as 10:12 pm Nenhum comentário

Objetivos devem ser claros de modo que qualquer um entendaOlá, a informação é importante, mas o jeito de se divulga-la é tão importante quanto, então hoje vamos mostrar como fazer uma definição de objetivos que seja fácil entendimento e divulgação.
Vamos pegar um exemplo:

“Aumentar a qualidade”
Este texto é extremamente vago e 90% das empresas tem este objetivo. Precisamos quantifica-lo.

“Aumentar a qualidade em 50%”
Melhorou, mas se você perguntar à 5 pessoas, cada uma explicará de uma forma diferente o que significa esses 50%.

“Aumentar a qualidade da codificação em 50%”
Perfeito, agora você sabe onde deve focar e em quanto. Ainda tem bastante trabalho pois você deverá ainda:
- Medir a qualidade
- Medir o custo da não qualidade
- Identificar os fatores que influenciam na não qualidade
- Definir ações para tratar os fatores que influenciam a não qualidade

Mas, isto é assunto para outro dia. Este serve de base para a criação de um mapa de objetivos que falaremos mais adiante.

+ A importância de PPQA Por Washington Souza 26 August 2008 as 2:53 am 1 comentário

Sem PPQA não há qualidade ou CMMIA figura do PPQA é a que mais auxilia na implementação do CMMI em uma organização.
Através de suas auditorias, seus principais objetivos são garantir que o processo esta sendo seguido conforme o padrão da empresa e garantir que o produto esta atendendo a qualidade esperada.

O PPQA não deve responder ao gerente da área e sim à seu superior como área de Staff. Isto auxilia na independência das auditorias visto que seu objetivo é garantir a qualidade. Outro fator muito importante é que “obriga-se” que o processo seja seguido.

Com o tempo PPQA vai evoluindo dentro da organização e de acordo com a estabilidade dos processos, suas auditorias podem ser reduzidas à amostragens (em processos muito estáveis e organizações maduras).

Uma recomendação minha é ter pelo menos um PPQA para cada 40 pessoas. Também recomendo que sejam realizadas auditorias semanais sempre com investigações.

Mais pra frente falaremos mais sobre PPQA.