O documento discute os custos de qualidade no desenvolvimento de software. Em três frases: O autor argumenta que incluir processos formais de teste e garantia de qualidade no desenvolvimento de software não aumenta o custo total, mas sim reduz custos futuros de correção de defeitos, preservando a qualidade do produto final. Embora o cliente pague inicialmente por esses processos, ele acaba economizando ao evitar problemas e paralisações causados por bugs.

1.
Falando sobre CUSTO…
Por
Edwagney
Luz
Estava aguardando o início de uma de minhas aulas sobre Teste de
Software, quando chega um de meus alunos questionando sobre a aula do
dia anterior. Na ocasião, havia comentado sobre o custo da qualidade de
software. Achei interessante o questionamento, pois vem ao encontro do
conceito que a maioria das pessoas tem. Quando falamos em qualidade, logo
pensamos, é algo caro, vou ter que gastar mais, e etc.
Será mesmo? Alguém já mediu a qualidade de alguma coisa? Ou melhor,
alguém já mediu o TAMANHO do efeito colateral de alguma coisa? Quem já
fez isso, por favor, compartilhe…
Mas o questionamento dele foi o seguinte.
Atualmente construo software dentro de um processo onde não
existe teste formal e sem uma área de qualidade de software.
Quando faço a inclusão desses processos no processo de
desenvolvimento, obviamente haverá um custo. Quem paga esse
custo? Minha empresa ou o cliente? “O custo ficará mais alto”,
afirmou.
Primeira coisa que TODOS pensam quando olhamos a palavra custo é em
dinheiro. Natural. É isso que move a economia mundial. Porém quando se
trata da QUALIDADE de alguma coisa, dinheiro deveria ficar em último lugar.
Nessa minha humilde opinião, visão e vivência em TI, quando CUSTO =
DINHEIRO quem presta o serviço ou desenvolve o produto, de alguma forma
repassa o custo ao cliente. O cliente PAGA o valor. Isso é fato. Ou alguém já
viu algo diferente? Se já, novamente… Compartilhe.
Vamos analisar o questionamento. Ele afirma que constroi software dentro de
um processo onde não existe teste formal e sem uma área de qualidade de
software. E eu pergunto, porquê?
Desde que estudo a Engenharia de Software ela sempre pregou o uso de
processos de teste e garantia da qualidade. Sempre apresentou metodos
para se fazer esses controles. Pergunto novamente: Porque ATUALMENTE
as empresas desevolvedoras de software não usam esse arsenal?
Negligência? Acho difícil. Não tenho tempo para desenvolver? Perfeitamente
possível. O cliente quer antes do prazo normal. Até concordo, mas quero
induzí-los no seguinte raciocínio: Tudo bem que o cliente quer rápido, não
tenho o tempo necessário para desenvolver, se não o fizer outro vem e faz no
meu lugar. Concordo e vejo razão por ser assim atualmente… Mas isso
ATUALMENTE, HOJE. E ontem??? Já pararam para pensar que estamos
TODOS pagando por um erro cometido no passado? Digo erro porque quero
acreditar que o não uso desses processos, NÃO tenha sido uma decisão

2. consciente de alguém ou de uma empresa.
Todos aqui conhecem o ditado “Errar é humano, mas persistir no erro é
insano.” (Mudei a última palavra por conta própria… hehehe)
Sabendo disso pergunto: “Se GOSTAMOS e EXIGIMOS qualidade em tudo o
que queremos e fazemos, PORQUE é que até HOJE estamos insistindo em
não usar processos formais de qualidade e teste?”
Uma família acabou de ganhar uma quantia em dinheiro como
herança e com ela decidiram fazer uma reforma em casa. Após
análise de um engenheiro a reforma levaria o prazo de 60 dias para
sua conclusão. O casal decidiu pedir uma redução de 30% no prazo
e orçamento. Após nova revisão foram informados de que era
possível, porém teriam que alterar o escopo do projeto. O casal não
aceitou alegando que necessitavam urgentemente da casa
reformada.
Qualquer semelhança com nossa vida na TI é mera coincidência não é
verdade? Querem mais semelhanças?
1.Algo para ser URGENTE precisa estar funcionando e ter parado
abruptamente de funcionar. Não era o caso da casa. Ela estava lá e
eles íam reformá-la, então, porque a urgência?
2.Considerando que ganharam uma herança, sabemos que isso não é
planejado e portanto a decisão de reformar a casa também não teve
um tempo para o planejamento. Porque a urgência se isso NÃO
estava momentaneamente nos planos?
3.Se sempre viveram na casa e agora vão MELHORÁ-LA para terem mais
conforto, então qual o motivo de quererem isso de forma tão rápida?
Porque não podem aguardar o prazo correto?
Simples, é que sempre, meus amigos, exigimos de nós mesmos prazos para
determinadas coisas e não confiamos nos profissionais e jogamos a
responsabilidade para cima deles. Queremos porque queremos. Não vamos
conhecer primeiro para depois decidir. “Quero minha casa pronta antes da
Copa do Mundo. Vou convidar meus amigos para assistir aos jogos lá. Mas a
Copa não começa em junho? Porque a decisão de construir a casa só veio
em Maio? Ahhh, eu decido, eu tenho o dinheiro, eu estpou pagando… Quem
aceitou em fazer que se vire e me entregue a casa pronta.” SEN-SA-CIO-
NAL, acabo de assinar meu atestado de INSANIDADE. Terei minha casa
antes da Copa. (sabe-se lá como… rs)
Ahh… O custo da qualidade? É verdade, ia me esquecendo. Então,
pergunte ao casal lá de cima quanto mesmo que eles gastaram no projeto e
PRINCIPALMENTE DEPOIS da reforma, com intúito de eliminar os
(D)EFEITOS COLATERAIS da decisão de se executar um projeto dessa
forma.
Lembrando sempre que DEFEITO é algo que ocorre devido à má

3. implementação de um requisito. É o que NÃO está em CONFORMIDADE
com o requisito. E a MUDANÇA na implementação de um requisito que foi
mal elaborado NÃO É um DEFEITO do produto, portando o custo deve ser
contabilizado de forma diferente. A análise que faço aqui é referente ao
defeito encontrado NO produto considerando a CORRETA elaboração do
requisito.
Nosso exercício ou DESAFIO de agora em diante, é explicar aos nossos
clientes que a diferença entre o custo de um projeto realizado no passado e
um realizado hoje, está na inclusão de processos que foram por algum motivo
excluídos no passado e continuaram esquecido até hoje. E NÃO considero
aumento de custo, pois não estamos aumentando nada. Estamos apenas
fazendo tudo como SEMPRE deveria ter sido feito. Antes o cliente pagava e
levava a falsa impressão de que ia receber algo com qualidade. Depois
acabava pagando muito mais para corrigir problemas que deveriam ter sido
eliminados em fase de projeto, mas aí já era tarde demais. Mas não façam
isso apenas copiando e colando informações aleatórias. Pesquise, coletem
dados, analisem e criem informações que sustentem a explicação. O cliente
precisa conhecer, tomar ciência do projeto para que possa se sentir
convencido de que REALMENTE essa é a forma correta de se executar um
projeto de software. Somente com o apoio dele conseguiremos mudar os
rumos dessa história.
Ahh… Faltou a resposta ao meu aluno.
Ninguém PAGA, TODOS ganham. PROVE isso mostrando para seu cliente o
valor que um defeito provoca se for encontrado após o início do uso do
software e o mesmo paralizar o negócio por alguns minutos que seja; PROVE
isso mostrando a ele que a espera de 30% dos dias, pode fazê-lo deixar de
perder(tempo e dinheiro) com a movimentação de dezenas de pessoas na
solução do problema; PROVE isso mostrando que a espera de 30% dos dias,
pode se tornar ainda maior caso o software seja entregue antes do prazo e
com defeitos. Além do custo de correção, incidirá custos de correção da
reação provocada pelo defeito nos dados e no negócio; PROVE isso
mostrando para ele o valor do impacto de um defeito na imagem da
organização perante seus clientes. Com todos esses números em mãos,
particularmente duvido que alguém em sã consciência tomará uma decisão
contrária a executar um projeto de forma correta. Mas se ocorrer de tomarem
outra decisão, que me desculpem os puristas de plantão, mas estarão
tomando em prol de interesses próprios ou em conjunto com outrem, alheios
os interesses da organização na qual representa(m).
Abraços e até a próxima!!!