Seu chefe, o cliente e a qualidade

Na área de desenvolvimento, muitos desenvolvedores são abençoados em ter gerentes que já foram desenvolvedores ou compreendem os processos envolvidos na construção de um software. Mas não raro é possível encontrar chefes que não entendem o trabalho que a equipe de desenvolvimento realiza.

Um desenvolvedor já precisa lidar no dia-a-dia com a pressão do cliente. Este não tem a obrigação de entender nos detalhes como é o processo de desenvolvimento de um software, mas estará sempre de prontidão para pressionar a equipe de desenvolvimento para realizar as entregas de funcionalidade. É comum que esta pressão passe antes pelo gerente da equipe. Se o seu gerente tem consciência de como é o processo de desenvolvimento de um software com qualidade, que exige algumas tarefas "incompreensíveis", como refatoração e testes, ele defenderá a equipe e irá absorver este pressão adequadamente.

Mas se o seu chefe não entende, a equipe ganha mais uma dor-de-cabeça.

Todos sabemos como funciona: "Isto precisa entrar amanhã!", "Precisamos disto para ontem!", "Por que ainda não terminamos?", "é pouca coisa, dá para fazer rapidinho e entregar"...

O recomendado é tentar fazer com que o seu chefe e cliente entendam o trabalho de desenvolvimento. É o desenvolvedor que é o profissional que vai construir o software, e ele deveria saber mais do que ninguém como fazer isto da melhor maneira possível.

Se alguém (gerente ou cliente) pedir a entrada de uma funcionalidade Y para amanhã, converse antes para saber o motivo. Em uma conversa, muitas coisas podem ser reveladas:

• O seu chefe, ou cliente, não tem total consciência das consequências no sistema do pedido;
• Deixe claro que as atividades que estão sendo realizadas neste momento serão atrasadas; alguns clientes tem a ilusão que ao pedir mais alguma coisa para determinada data, as que já estão em desenvolvimento não terão qualquer impacto.
• Enfim, muitas coisas são urgentes quando, depois de uma boa conversa, deixam de ser;

 Se o consenso é que este pedido é importante, e que a data na qual esta funcionalidade precisa entrar não vai encaixar-se no processo adequado de desenvolvimento, deixe claro:

• A funcionalidade Y será entregue na data prometida, mas no próximo dia um dos desenvolvedores deixará de continuar a trabalhar na funcionalidade X para refatorar o código ruim, escrito às pressas, deixado pela funcionalidade Y.
• Se a conversa chegou no assunto "horas extras", seja prudente; nenhum ser humano é uma máquina que pode trabalhar por longas horas.

Agindo assim, tanto o seu chefe quanto o cliente não criarão a ilusão que podem realizar qualquer pedido para a equipe sem compartilhar as consequências negativas deste caminho. Até porque, se a equipe de desenvolvimento não corrigir o código ruim deixado, ou tomar qualquer outra ação para preservar a qualidade do software, as consequências serão muito piores para todos no futuro. É importante fazê-los entender que um código ruim hoje, fica pior ainda amanhã. Já dizia o Uncle Bob (Robert Martin):

No matter who. No matter what. No matter when. Short term. Long term. Any term. Writing good code is always faster than writing bad code.

No próximo texto vou falar do papel da empresa. Depois, podemos ir para a parte divertida: o código!