Nas consultorias da vida eu já encontrei mais vezes do que gostaria projetos em que os desenvolvedores tem nojo do código. É sério, nojo mesmo, parece que estão olhando para algo pútrido, em decomposição. Porque será que deixamos as coisas chegarem a esse ponto? Você tem nojo do seu projeto atual? Qual a SUA responsabilidade nisso? Qual a nossa responsabilidade coletiva sobre isso? Vamos analisar.

Em um projeto tradicional o seguinte triângulo é usado com frequência:

No meio estaria a qualidade, resultado dos três extremos do triângulo. O triângulo geralmente significa que o cliente deve escolher dois pontos que ele quer fixar, e um ponto que vai ser flexível. Por exemplo, ele quer um projeto para 6 meses, e que custe 1 milhão. Para isso ele vai ter que flexibilizar o escopo. A qualidade é dada como fixa e constante.

No entanto, o que vemos no mercado é que os três pontos são fixos! O cliente do projeto quer um projeto para 6 meses, que custe 1 milhão, e que atenda um levantamento já realizado, ou seja, um escopo pré-definido. Nesses casos, tenho uma outra visão sobre o triângulo, ele não é mais um triângulo de compensações. Ele se parece mais com isso:

Isso é um triângulo impossível.

Mas estou sendo injusto. O triângulo não é impossível. Ele é possível, basta variar o quarto ponto, aquele que não aparece: a qualidade!

E é justamente isso que fazemos. Geralmente, como o escopo é fixo e os recursos também, é no prazo que temos sofremos. Estamos sempre atrasados, fazendo horas extras, dormindo pouco.

E vocês sabem o que acontece quando você pressiona um desenvolvedor por prazo? Ele diminui a qualidade! Isso é um fato! Imagino que se os inúmeros gerentes de projeto por aí tivessem essa informação eles iriam pensar duas vezes antes de se dobrarem sobre os ombros de um desenvolvedor e fazer aquela famosa pergunta: dá pra andar um pouco mais rápido? (ou outras semelhantes, como “já terminou?”, ou “dá pra entregar dia tal?”)

E sabe o que é pior? O desenvolvedor aceita essa pressão. Ele aceita cortar qualidade pra atender o prazo. Ainda pior, ele não conta que está cortando qualidade, e o coitado do gerente de projeto fica em uma situação ainda pior. Ou, mais frequentemente, o desenvolvedor sequer percebe que está cortando a qualidade.

A cada dia mais qualidade é cortada do projeto, mas atalhos são pegos. Em pouco tempo, o que acontece? Temos um código nojento, que ninguém mais quer trabalhar. O cliente, por outro lado, encontra um software nojento, resultado de um código nojento, e entende que o desenvolvedor só faz porcaria. A visão do cliente, não tenham dúvidas, é de que somos um bando de incompetentes. Já imaginou se seu médico cortasse qualidade toda vez que estivesse pressionado por um prazo? Já imaginou como seria uma cirurgia do coração? Mas não, ele não faz isso, ele é um profissional.

Pra resolver isso, há um instrumento vindo das práticas ágeis chamado “definição de pronto”. Vou falar dele semana que vem. Por enquanto, pensem sobre as consequências que sua decisão de aceitar pressão de prazo do cliente ou gerente de projeto, de forma recorrente. Pense que isso vai tornar sua vida miserável, e que você estará contribuindo para piorar a visão que se tem sobre nossa profissão.