Qualidade é de graça

Pergunte a qualquer pessoa o que é qualidade, as chances são altíssimas de que ela diga que isso é muito subjetivo ou depende. Mas nós não podemos simplesmente ficar discutindo uma coisa que nós nem sabemos direito o que é, então vamos definir o que é qualidade para nós nesse momento, tomemos então a definição de DeMarco em [i]Slack[/i] como base:

…Real quality is far more a matter of what it does for you and how it changes you than whether it is perfectly free of flaws. So that browser, even though it crashes maddeningly often, should be considered a quality product. That is why you use it so much. Its quality is most of all a function of its usefulness.

Pela definição de DeMarco, a qualidade de um produto se mede pelo que ele faz por você e o quanto isso é importante para facilitar ou melhorar o seu trabalho. A qualidade não é simplesmente a falta de defeitos (ou bugs, como nós os chamamos carinhosamente) como a maioria das pessoas pensa, não ter defeitos não dá qualidade a um sistema, até porque um sistema que não tem defeitos ou não é usado por ninguém ou é apenas mais uma daquelas lendas que todo mundo comenta, mas que ninguém viu pessoalmente.

Quanto menos bugs…

Quando você tem uma política de qualidade que tem como foco apenas evitar que bugs apareçam no sistema, você está enviando todos os esforços para resolver um problema que pode não ser o que realmente vai fazer diferença para o seu usuário final. Pior, quando você começa a associar o surgimento de bugs a produtos de má qualidade, pode criar na sua equipe de desenvolvimento um medo perigosíssimo nessa área do trabalho, o medo de mudar.

Alterar código que funciona é sempre algo traumático, especialmente quando você não tem testes automatizados que garantem se o código está funcionando corretamente ou não depois da alteração. Quando você se prende demais a ausência de bugs como única medida da qualidade de um software, a sua equipe pode simplesmente evitar fazer mudanças drásticas no sistema, como grandes refatorações, mesmo que elas sejam necessárias, por medo de que surjam novos problemas e eles sejam culpados pelo que está acontecendo.

Além de evitar a alteração do código que já está escrito, também seria menos provável que a equipe procure adicionar novidades que ainda não tenham se comprovado no mercado, preferindo manter-se no tradicionalismo a correr riscos com uma coisa nova que possa vir a não dar certo. Toda essa pressão contra as mudanças só engessa mais a equipe de desenvolvimento e diminui a capacidade deles de responder a mudanças, já que além das responsabilidades que eles tinham antes, tem que também responder pela quantidade de bugs que os sistemas apresentam.

Temos tempo pra isso?

Não temos tudo, mas pelo menos temos alguma coisa, que é buscar remover os bugs, mas remover os bugs custa tempo. Nós temos tempo pra isso? Dificilmente. Mais uma vez citando DeMarco em Slack:

Quality takes time. Even quality in the defects only sense takes time. So you might assume that a Quality Program for a development effort would, as it is most important task, assume the quality of the Schedule. I always assumed that. But so far, I have never come across a corporate Quality Program or a Quality Assurance organization that made any pretense of judging reasonabliness of the time allocated for the work.

Quando você tem um processo de qualidade e não avalia o preço que esse processo vai causar no seu desenvolvimento, ou você atrasa o processo de desenvolvimento por inteiro sempre, ou não vai haver garantia de qualidade nenhuma e a julgar pela fama das estimativas de entrega dos projetos de software, os atrasos iriam parar na estratosfera.

Você não pode esperar que o código que você escreveu funcione a contento simplesmente porque você acha que está correto, você tem que gastar um pouco do seu tempo escrevendo testes que garantam que o contrato que você diz implementar estão realmente implementados, isso garante que, pelo menos, o seu código está fazendo o que você queria que ele fizesse. Mas partamos para um nível mais alto, para saber o que o seu cliente realmente espera do sistema, você deve fazer o possível para estar em constante contato com ele, não pode simplesmente implementar a primeira idéia que saiu da boca dele e que você acha que entendeu, garantir que as informações estão corretas também custa tempo, o tempo que você não tem.

Cada um desses passos é mais um no aumento daquele prazo que simplesmente ignorou a existência de processos de garantia de qualidade, mais um projeto de software que não vai ter a mínima chance de ser entregue no prazo.

Pagando o preço

Em Peopleware, DeMarco e Lister afirmam:

Quality is free, but only to those who are willing to pay heavilly for it.

A idéia de que a qualidade de um produto é gratuita vem do livro Quality is free de Philip Crosby, onde ele afirma, através de vários exemplos, de que deixar a decisão da quantidade de qualidade de um produto nas mãos de quem o produz é a melhor saída para garantir um alto nível de produtividade.

A satisfação perante a qualidade do que é produzido é um dos maiores incentivadores que a maioria das pessoas que fazem trabalho intelectual podem ter. Quando eles sentem que o produto que eles estão produzindo atinge ou até mesmo ultrapassa os seus próprios níveis de qualidade, eles sentem-se motivados a continuar produzindo e produzindo cada vez mais. O ápice da qualidade de hoje é sempre além da qualidade que eles conseguiram ontem e isso faz com que eles estejam sempre em busca de novas maneiras mais simples e mais eficientes de resolver os problemas encontrados, para que possam aumentar ainda mais a qualidade do que é produzido. Uma pessoa motivada a fazer o seu trabalho vale mais do que dez pessoas que não estão nem aí pra o que está sendo produzido.

O grande problema é que esse nível de qualidade é sempre muito acima da qualidade real que os clientes precisam e para gerentes que não tem uma visão além do espaço daquele projeto é um investimento em vão. Se os clientes não querem aquilo tão bem arrumado, porque é que eu vou cobrar deles isso?

Forçar uma equipe a diminuir a qualidade ou lançar um produto que não atende aos seus próprios requisitos vai mexer com um dos princípios básicos das pessoas, a sua auto-estima, especialmente quando começarem a surgir problemas que eles sabiam que poderiam ter sido evitados se a pressão para lançar um produto que ainda não estava pronto no ar não tivesse existido.

Gratuito?

A qualidade que você tem é exatamente igual a tudo o que você investiu nela. Se você não investiu nem um tostão, já sabe que o provável nível de qualidade é exatamente esse, nenhum. A gratuidade da qualidade vem no retorno que você tem do investimento que fez, tanto em produtos que se destacam frente aos outros em suas funcionalidades e penetração de mercado como também nas suas equipes energizadas por estarem produzindo algo que está nos seus patamares de qualidade e que está deixando os clientes felizes.

Uma das grandes provas de que qualidade não é sinônimo de lentidão nem de baixa produtividade é a indústria japonesa. Tida por muitos como um dos sinônimos de qualidade, com os seus processos lean, eles atingem altos níveis de qualidade e também de produção, casando dois fatores que, na maioria das vezes parecem ser antagônicos.

Então, a qualidade não é tão gratuita quando diz o título, mas o investimento que você faz nela, se for feito realmente em áreas que vão aumentar a qualidade real do produto (e não apenas diminuir a sua quantidade de bugs) com certeza vão pagar e ultrapassar o seu investimento.

Referências

Slack: Getting past burnout, busywork and the myth of total efficiency. DeMarco, Tom. Broadway Books, New York. 2001.

Peopleware: Productive projects and teams, 2nd Edition. DeMarco, Tom; Lister, Timothy. Dorset House Publishing Co. New York. 1999.