Conceitos: Qualidade do Produto
Tópicos
Alguém que esteja determinado a produzir um excelente produto enfrenta dois problemas. Como saber quando o produto é bom o suficiente? Se o produto ainda não for bom o suficiente, como garantir que os envolvidos saibam disso? A resposta à primeira pergunta permite liberar o release do produto. A resposta à segunda pergunta ajuda a evitar o release de um produto insatisfatório.
Você pode estar pensando: "Não quero simplesmente lançar um produto bom o suficiente, quero lançar um excelente produto". Vamos explorar esse raciocínio. O que acontece quando você diz aos seus colegas de trabalho, à gerência ou aos investidores que seus padrões de qualidade são altos e que pretende lançar um excelente produto? Se o ciclo do projeto estiver no início, eles provavelmente aprovarão de bom grado. Todo mundo gosta de qualidade. Contudo, se o ciclo do projeto já estiver adiantado, você estará sofrendo muita pressão para concluir o projeto. A criação de um produto excelente pode exigir que você se dedique a um teste abrangente, corrija muitos problemas (ainda que pequenos), adicione recursos ou até mesmo se desfaça e reescreva boa parte do código. Você também terá de resolver controvérsias a respeito de diferentes visões sobre boa qualidade. A excelência exige trabalho árduo. Atingir a perfeição é ainda mais difícil. As pessoas que controlam o projeto acabarão dizendo a você algo como "Perfeição seria ótimo, mas precisamos ser práticos. Estamos administrando um negócio. A qualidade é o ideal, mas não a qualquer custo. Como você sabe, todos os softwares contêm erros".
A excelência pode ser uma meta estimulante. Ela instiga o orgulho que você tem do seu trabalho. Contudo, há problemas em usar o argumento de que "se qualidade é bom, mais qualidade deve ser melhor" para justificar a busca pela excelência. Por um lado, esse argumento pode fazê-lo parecer um fanático por qualidade, e não uma pessoa que age com racionalidade. Por outro lado, tal argumento ignora o fator custo. O BMW é um carro bonito, mas custa muito mais que um Saturn. Um Saturn pode não ser muito agradável de dirigir, mas é mais conveniente em termos financeiros. Ao deixar o custo de lado, o argumento Quanto Mais Melhor também ignora a redução dos retornos. Quanto melhor o produto, mais difícil é justificar futuras melhorias. Para "banhar a ouro" um aspecto do produto, você deve necessariamente ignorar outros aspectos desse produto ou possíveis oportunidades apresentadas por outro projeto. Em um negócio, é necessário fazer opções todos os dias sobre a melhor utilização dos recursos. Há outros fatores além da qualidade que devem ser considerados.
Paradoxalmente, o conceito Qualidade Boa o Suficiente (GEQ) é um argumento mais eficiente que Quanto Mais Melhor, pois fornece um objetivo que pode ou não ser alcançado. Nesse caso, torna-se um argumento de fato para cancelar ou reestruturar o projeto.
A maioria dos negócios pratica alguma forma de raciocínio do tipo bom o suficiente em relação a seus produtos. Os únicos que não fazem isso são aqueles que acreditam terem atingido a perfeição, pois não conseguem ver como seus produtos podem ser melhorados.
Aqui estão alguns modelos do tipo bom o suficiente que já foram experimentados. Alguns deles são mais eficientes que outros, dependendo da situação:
Não Tão Ruim ("ainda não estamos liquidados")
Nossa qualidade só precisa ser boa o suficiente para que possamos permanecer no negócio. Fazê-lo bom o suficiente para não acabarmos sendo processados.
Infalibilidade Positiva ("tudo que fazemos é bom")
Nossa empresa é a melhor do mundo. Como somos bons, tudo que fazemos é automaticamente bom. Pense apenas no sucesso. Não pense no fracasso, porque o pensamento "negativo" atrai má qualidade.
Exaustão Justificada ("perfeição ou fiasco")
Nenhum produto é bom o suficiente; o esforço é que conta. E apenas a exaustão completa representará um nível de esforço bom o suficiente. Não temos de nos preocupar com as questões comerciais. Faremos todo o possível para tornar o produto perfeito. Como nunca vamos deixar de tentar melhorá-lo, alguém terá de vir até nós e implorar por ele, se o quiser. Assim, a responsabilidade por qualquer problema de qualidade será deles, e não nossa.
O Cliente está Sempre Certo ("parece que os clientes gostaram do produto")
Se gostaram, é porque deve ser bom o suficiente. É claro que você não pode agradar a todo mundo ao mesmo tempo. E se um cliente atual ou em potencial não gostar do produto, cabe a eles nos informar. Não podemos ler suas mentes.
Processo Definido ("nós seguimos um Processo Eficiente")
A qualidade é o resultado do processo que usamos para criar o produto. Definimos nosso processo e entendemos que é ele é eficiente. Portanto, se o seguirmos, o resultado inevitavelmente será um produto bom o suficiente.
Requisitos Estáticos ("nós satisfazemos aos Requisitos")
Definimos qualidade em termos de metas objetivas, quantificáveis e que não sejam polêmicas. Se atingirmos essas metas e tivermos um produto bom o suficiente, qualquer outra meta subjetiva, não-quantificável ou polêmica poderá ser sugerida.
Compromisso ("nós cumprimos nossas promessas")
A qualidade é definida por contrato. Prometemos realizar determinadas ações e atingir certas metas. Se cumprirmos nosso contrato, ela será boa o suficiente.
Defesa ("nós nos esforçamos ao máximo")
Defendemos a excelência. Durante todo o projeto, procuramos maneiras de evitar problemas, além de localizar e corrigir aqueles que não podemos evitar. Se trabalharmos com afinco rumo à excelência, isso será bom o suficiente.
Compensação Dinâmica("pesamos vários fatores")
Com relação à nossa missão e à situação em questão, um produto é bom o suficiente quando não tem problemas críticos, quando tem vantagens suficientes e elas compensam esses problemas, e quando é mais prejudicial que benéfico continuar a melhorá-lo.
Dependendo de vários fatores (como processo, habilidade, tecnologia, ferramentas, ambiente e cultura), você pode conseguir produzir um produto de muito melhor qualidade pelo mesmo custo do que seria possível de outro modo. Um produto com maior capacidade de teste e manutenção custará menos para ser melhorado; outros custos são especificamente associados à má qualidade, como custos de suporte e custos para o cliente.
O custo da qualidade é uma questão complexa, o que torna difícil fazer generalizações amplas. Contudo, sempre é possível gastar mais tempo realizando testes muito mais abrangentes, efetuando um tratamento de erros mais adequado e corrigindo ou reescrevendo cada parte do produto. Por mais eficiente que você seja, isso terá um preço. E se você não consegue pensar em mais melhorias, é provável que tenha atingido o limite de sua imaginação, e não de qualidade.
Na indústria de software, a GEQ inspira-se mais em uma resposta a um custo específico do que em qualquer outro: o custo de não liberar o release do produto cedo o bastante. O espectro da abertura do mercado (ou o prazo final externo) nos impõe penalidades quando não conseguimos cumprir o desafio. É por isso que o final dos projetos costuma ser caracterizado por uma triagem frenética. Se você deseja saber o que uma organização acredita ser bom o suficiente e o quanto ela está bem preparada para isso, presencie os três últimos dias de qualquer projeto de software com duração de seis meses. Veja o que acontece quando um novo problema é relatado no último dia.
Pode ser tentador reduzir a qualidade a um número e depois definir um limite numérico que represente uma qualidade boa o suficiente. O problema é que apenas fatores relacionados à qualidade podem ser medidos. Não é possível medir a qualidade em si. Isso ocorre em parte porque a palavra "qualidade" é apenas um rótulo para a relação entre uma pessoa e uma coisa. "Este produto é de boa qualidade" é apenas outra forma de dizer "Alguém valoriza este produto". É uma declaração sobre o produto, mas também uma declaração sobre as pessoas e o contexto a seu redor. Mesmo que o produto permaneça o mesmo, as pessoas e as situações mudam. Por isso é impossível haver uma medida verdadeira, única e estática da qualidade.
Há várias medidas que podem ser usadas para obter o senso de qualidade, mesmo que você não possa medi-la de forma completa e objetiva. Mesmo assim, a questão do que é uma qualidade boa o suficiente requer um julgamento sofisticado. Você não pode escapar do fato de que, no final, as pessoas precisam avaliar e fazer um julgamento. Para um produto simples, esse julgamento pode ser fácil. Para um produto complexo com grandes limitações, é muito difícil.
Para ajudar a avaliar a qualidade do produto, o Rational Unified Process (RUP) contém os seguintes tipos de informação disponíveis para a maioria dos artefatos:
- Diretrizes e Pontos de Verificação de Artefatos: informações sobre como desenvolver, avaliar e usar o artefato.
- Templates: "modelos" ou protótipos do artefato que fornecem estrutura e orientação para o conteúdo.
Consulte também Conceitos: Medição da Qualidade, Conceitos-chave: Pontos de Verificação e Diretrizes de Artefatos para obter informações adicionais.
Copyright
(c) 1987 - 2001 Rational Software Corporation
| 
