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

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á

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!!!