Indicação de artigo: Você tem que escolher entre Software “no prazo” ou Software de qualidade

Eu uso um aplicativo chamado Pocket para salvar artigos, tutoriais e notícias que eu gostaria muito de ler, mas não posso fazê-lo naquele momento. E coloquei como um dos meus objetivos “zerar” a lista que lá se encontra. Tem muitos artigos de opinião sobre vários assuntos do meu interesse, dentre eles desenvolvimento de software, dicas sobre como melhorar soft skills, etc, etc. Pretendo postar aqui os artigos que foram relevantes e de fato agregaram algum conhecimento à minha pessoa.

O artigo de hoje tem o seguinte título:

You have to choose between Software Delivered on Time and Good Software

Confesso que, já no título, me apaixonei, apesar de ser extremamente clickbait.

O autor fala de sua própria experiência, mas acredito que todos os desenvolvedores com algum tempo de carreira já sabem do que ele vai falar. Existem dois cenários no mundo do desenvolvimento: você faz as coisas da maneira correta e com cuidado e ultrapassa o prazo que lhe foi estimado.

1- Você faz as coisas da maneira correta e com cuidado e ultrapassa o prazo que lhe foi estimado.

2- Você entrega no prazo, porém ou o escopo foi reduzido, ou a dívida técnica do projeto está enorme.

Mas a grande questão é: por que isso acontece? Por que é tão difícil conciliar qualidade de software e prazos (na maioria das vezes, arbitrários e enviado por algum superior)?

O autor cita três razões, e eu concordo 100% com ele.

Primeira razão: Criatividade

Desenvolvimento de software, apesar de ser uma ciência exata, é um trabalho criativo. Existem, como todo trabalho, as tarefas repetitivas e triviais (que tendem a ser automatizadas). Porém estamos sempre criando alguma coisa nova. Inclusive, quando um desenvolvedor não tem certa liberdade criativa no projeto em que está, o sentimento que fica nele é: “por que diabos eles precisam de mim, se tudo já está definido?”

O problema é: liberdade criativa demanda mais tentativas e, consequentemente, erros para alcançar a solução de um problema. O processo de desenvolver software é um constante ciclo de ajustes: você não tem a solução definida de antemão; você a aprende enquanto desenvolve, e de forma iterativa vai testando coisas novas enquanto mantém as que funcionam. Dessa forma, você refina a sua solução até que esteja satisfeito com ela.

E quanto tempo isso leva? Possivelmente bem mais do que você pensou no início. E esse é o ponto: processo criativo não casa com estimativas.

Segunda razão: Artesanato

A palavra pode parecer esquisita, eu sei, mas o conceito de artesão de software estão muito em voga: é alguém que não só constrói algo que funciona, mas também o faz da melhor maneira possível; qualidade é a palavra que te define, em vez de quantidade.

Artesanato é sobre se importar: se importar com um bom trabalho, com quem vai dar manutenção no seu código futuramente, com quem vai consumir seu software, com seus colegas… Significa que você não é um babaca.

E é difícil se concentrar e prezar pela qualidade em um mundo que tem sempre um prazo muito curto.

Terceira razão: Imprevisibilidade

Projetos de software são sistemas complexos: são feitos por humanos e afetados por interações interpessoais, motivação, problemas de comunicação e psicologia humana, em geral. E não é possível quantificar isso em uma planilha. A única certeza que se tem é a incerteza.

Em um ótimo cenário, os prazos são definidos após estimativas cuidadosas e detalhadas por parte de todos os integrantes de uma equipe ou time. Mesmo assim, projetos atrasam. Imagine em cenários em que o prazo vem de cima para baixo sem a possibilidade de negociação? Um dos dois está fadado ao fracasso: a qualidade do software ou o prazo acordado pelas pessoas “de cima”.

Há uma saída?

De acordo com o autor, uma boa estratégia para equilibrar essa equação é uma ponte entre o mundo da planilha e o mundo da IDE: um Gerente Engenheiro. Ou seja, uma pessoa que conseguiria enxergar os dois lados e ser flexível entre eles. Além disso, uma relação de confiança entre esses dois mundo também se faz extremamente necessária. Afinal de contas, todos os envolvidos em um projeto de software tem o mesmo objetivo: entregar um sistema de boa qualidade da maneira mais rápida possível.

E o recado dele para nós, desenvolvedores, que eu aqui ouso reafirmar é: se você sente que seu superior ou a organização em que você trabalha não está focada em construir softwares bons, você deveria se levantar e tentar fazer essa mudança. Se isso falhar… bem,  procure outro lugar para trabalhar assim que possível.