Peopleware – Parte 4

Chapter 4: Quality – If time permits

O caráter humano é dominado por um pequeno número de instintos básicos: sobrevivência, auto-estima, reprodução, território, entre outros. Estes são fixados diretamente nos “firmwares” de nossos cérebros. Nós podemos considerar estes instintos friamente, sem nenhuma paixão (como estamos fazendo agora), mas quando você os sente, sempre há paixão envolvida. Apenas um pequeno desafio a um desses valores pode ser perturbador.
Qualquer emoção forte em nós despertada é um sinal de que um dos instintos do cérebro foi ameaçado. Um gerente novato pode acreditar que trabalho pode ser realizado sem que as emoções das pessoas sejam envolvidas, mas se você possui alguma experiência como gerente você aprendeu o oposto. Nosso trabalho nos dá plena oportunidade de exercitar as emoções.


Você pode pensar em incidente como o incendeio das emoções de uma pessoa pelo resultado direto de algo relacionado ao trabalho. Considere um incidente agora e pergunte-se (provavelmente pela enésima vez), de onde vêm todas as emoções?
Sem conhecimento algum sobre seu específico incidente, estamos dispostos a apostar que a ameaça a sua auto-estima foi um dos fatores. Pode haver muitas e variadas causas da reação emocional na vida pessoal de alguém, mas no local de trabalho, o maior despertador de emoções é a ameaça à auto-estima.
Nós tendemos a amarrar fortemente nossa auto-estima com a qualidade do produto que produzimos – não a quantidade do produto, mas a qualidade.
Qualquer passo que possa ameaçar a qualidade do produto é como colocar as emoções do seu pessoal diretamente contra você.

The Flight from Excellence

Gerentes arriscam a qualidade do produto definindo prazos de entrega inatingíveis. Mas eles não pensam na sua ação desta forma. Acreditam que estão passando desafios interessantes para seus desenvolvedores, algo para ajudá-los a se esforçarem para obter excelência.
Desenvolvedores experientes entendem outra coisa… Eles sabem que sobre a mira de uma arma, seu conforto será restrito. Não haverá liberdade para abrir mão de recursos para fazer a entrega possível. Eles não terão a opção de ter mais pessoas ou diminuição de funções. A única coisa possível de se abrir mão será a “qualidade”. Desenvolvedores sob extrema pressão começarão a sacrificar a qualidade. Eles irão empurrar os problemas para debaixo do tapete para ser tratado posteriormente ou simplesmente será imposto ao produto. Eles entregarão produtos instáveis e incompletos. Eles odiarão o que estão fazendo, mas que outra opção eles têm?
Guiados pela experiência prática, parte dos gerentes do “mundo real” têm uma resposta para tudo isto: “Alguns dos meus desenvolvedores adorariam mexer para sempre com uma tarefa/funcionalidade, em nome da qualidade. Mas o mercado não dá a mínima para muita qualidade – O mercado está gritando pela entrega do produto para ontem e aceitarão o produto mesmo que esteja em um estado rápido-e-sujo”. Em muitos casos, você estará certo sobre o mercado, mas a decisão de pressionar as pessoas para entregar um produto cujas métricas de qualidade não atingem o seu padrão é quase sempre um erro.
Nós gerentes tendemos a pensar em qualidade apenas como outro atributo do produto, algo que pode ser fornecido em vários degraus de acordo com as necessidades do mercado. É como calda de chocolate no sundae: mais para pessoas que querem mais e menos para pessoas que querem menos.
A visão de qualidade dos desenvolvedores, por outro lado, é muito diferente. Desde que sua auto-estima é fortemente ligada com a qualidade do produto, eles tendem a impor padrões de qualidade para si próprios. O mínimo que os satisfará é mais ou menos o melhor nível de qualidade que obtiveram no passado. Isto é invariavelmente um padrão maior do que o mercado requer e está disposto a pagar.
“O mercado não dá a mínima para muita qualidade” Leia essas palavras e chore, porque elas são quase sempre verdadeiras.
Pessoas podem falar em termos brilhantes sobre qualidade ou se queixar amargamente sobre sua ausência, mas quando chega na hora de pagar pela qualidade, seus verdadeiros valores se tornam visíveis. Em um projeto de software, por exemplo, você pode estar apto a fazer o seguinte tipo de apresentação para seus usuários: “Nós podemos dizer, a partir de evidências, que o tempo médio entre falhas para este produto é de aproximadamente 72 minutos. Então se entregarmos o produto hoje, no prazo, ele terá uma estabilidade muito baixa. Se colocarmos mais 3 semanas de trabalho podemos aumentar o tempo entre falhas para aproximadamente 2000 horas, um resultado respeitável.” Os usuários explicarão que são conscientes sobre qualidade, mas 3 semanas significa dinheiro.
Falando de software, esta indústria tem habituado seus clientes a aceitar aplicações desenvolvidas com uma densidade de 1-3 defeitos por cem linhas de código. Que sublime ironia, a culpa deste recorde desastroso é frequentemente colocado na má qualidade consciente dos desenvolvedores. Isto é, as mesmas pessoas que passariam a eternidade em um programa em nome da qualidade também são culpadas pela falta de qualidade.
Vamos colocar a culpa onde ela pertence. Quem que paga o flautista pede o tom (ou seja, quem paga manda). Colocando o processo de desenvolvimento sob pressão regularmente e aceitando produtos de baixa qualidade, a comunidade de usuários de software tem mostrado o verdadeiro padrão de qualidade.
Tudo isso pode suar como uma conversa filosófica contra os usuários de software e contra os padrões do mercado em geral, mas isto não precisa ser tratado desta maneira.
Nós temos que assumir que as pessoas que pagam pelo nosso trabalho estão conscientes para fazer a sensível escolha entre qualidade e custo. O ponto aqui é que a necessidade por qualidade percebida nos clientes é muito frequentemente menor do que a dos desenvolvedores. Há um conflito natural.
Permitir que o padrão de qualidade seja definido pelo comprador assim como pelo desenvolvedor é o que chamamos de “vôo de excelência”.
Um padrão de qualidade derivado do mercado só faz sentido enquanto você ignorar o efeito nas atitudes e eficácia dos desenvolvedores.
Em longo prazo, a qualidade baseada no mercado custa mais. A lição aqui é:

Qualidade, muito além daquela exigida pelo usuário final, significa aumentar a produtividade.

Se você duvida, imagine o seguinte: Pergunte a 100 pessoas pelas ruas que organização ou cultura ou nação é famosa pela alta qualidade. Mais da metade das pessoas hoje em dia deverá responder “Japão”. Agora pergunta a outras 100 pessoas que organização ou cultura ou nação é famosa pela alta produtividade. Novamente, a maioria responderá “Japão”. A nação que é conhecida por ser líder de qualidade é também conhecida por sua alta produtividade.
Espere um minuto. Como é possível que alta qualidade coexista com alta produtividade?
Para um indício da resposta, leia as palavras de Tajima and Matsubara, dois dos mais respeitados comentaristas do fenômeno japonês:

A escolha entre preço e qualidade no Japão não existe. Logo, a idéia de que alta qualidade traz redução de custo é amplamente aceita.

Quality is free, but…

Philip Crosby apresentou este mesmo conceito no seu livro “Quality is free” publicado em 1979. Neste trabalho, Crosby deu inúmeros exemplos de que deixar o desenvolvedor definir o nível de qualidade satisfatório dele mesmo resultará em um ganho de produtividade suficiente para cobrir o custo do aumento de qualidade.
Nós temos uma ruim percepção de que o livro de Crosby foi mais prejudicial do que bom a indústria. O problema é que a grande maioria dos gerentes não leu o livro, mas todos leram o título. O título se tornou toda a mensagem. Gerentes de todo o lugar estavam entusiasmados sobre qualidade: “O céu é o limite para a qualidade, nós vamos ter o máximo de qualidade que pudermos”. Mas esta atitude é justamente o oposto do que Crosby defendia.
A verdadeira mensagem que ligava qualidade e produtividade necessita ser apresentada em termos ligeiramente diferentes:

Qualidade é grátis, mas apenas para aqueles que estão dispostos a pagar bem por isto.

A política de “Qualidade – Se o tempo permitir” sempre garantirá que a falta de qualidade esteja implícita no produto.
A HP (Hewlett-Packard) é um exemplo de organização que recebe os benefícios do aumento de produtividade devido ao alto padrão de qualidade definido pelos desenvolvedores. A companhia cria uma cultura de qualidade. Neste ambiente, o argumento que mais tempo ou dinheiro é necessário para produzir um produto de alta qualidade não é ouvido. O resultado é que os desenvolvedores sabem que fazem parte de uma cultura que entrega qualidade além do que o mercado requer. A identificação com a qualidade funciona aumentando a satisfação com o trabalho e como resultado diminui-se a perda de pessoas.

Power of Veto

Em algumas companhias japonesas, entre elas Hitachi Software e parte da Fujitsu, o time de projeto tem o efetivo poder de veto sobre a entrega do que eles acreditam ser um produto “ainda não acabado”. Não importa que o cliente esteja disposto a aceitar o produto, o time pode insistir que a entrega seja adiada até que seja atingido o nível de qualidade base. Claro, gerentes de projeto estão sob a mesma pressão daqueles que estão aqui: Eles são pressionados para entregar alguma coisa, qualquer coisa, pra ontem. Mas a cultura da qualidade suficiente tem sido construída porque os gerentes japoneses sabem que isso é melhor do que intimidar seus desenvolvedores a aceitar baixa qualidade.
Você poderia dar a seus desenvolvedores o poder de vetar uma entrega? Claro que isso iria te deixar com os nervos a flor da pele, pelo menos da primeira vez. Sua preocupação principal deve ser que a lei de Parkinson possa trabalhar contra você. É um assunto importante o suficiente para garantir um capítulo para si próprio (Capítulo 5).