Outro dia acompanhei em uma lista de discussão uma thread sobre o que devemos dar foco no desenvolvimento de software. A questão se baseava entre: “Qualidade ou Entrega”?

Foi muito interessante essa discussão, que perdurou por dias, com várias colocações muito boas e outras que de certa forma me fizeram até rir. Programadores dizendo que o gerente não sabe nada porque já programou em VB e o assunto meio que se desviou de rumo. Mas fiquei então com a pergunta, vamos dar foco na qualidade ou na entrega?

Desenvolvimento para o mundo real

Desenvolver software não é simplesmente sentar na frente de um computador e começar a escrever muitos códigos. São necessárias horas de conhecimento a ser adquirido sobre aquilo que será feito no mundo computacional, que reflete o mundo real, além de se saber até onde do mundo real será espelhado no computacional.

Muitas visões são geradas no processo de conhecimento de um domínio e o resultado deste conhecimento será o produto a ser entregue ao nosso cliente. Precisamos definir a linguagem, a arquitetura e a plataforma em que o software será desenvolvido, entre outras questões. E isso não é uma tarefa fácil, mas é necessária.

Falhas de comunicação x Prazos

Além de tudo o que precisamos levantar junto ao cliente e entre nós desenvolvedores, ainda temos um grande vilão que acompanha todo o projeto de software, o prazo. Esse fator é crítico, pois mensurar tempo para um software ficar pronto é bem complexo, e a grande maioria não consegue cumprir os prazos.

O que vejo muito no ramo de desenvolvimento são clientes se apresentando como alguém que precisa de algo simples (o que na verdade não costuma ser tão simples assim) e os desenvolvedores topando dar a solução.

Aí que mora o perigo: o cliente muitas vezes não sabe a dimensão do problema dele e, uma vez que ele não sabe disso, muito menos nós saberemos até que um dia no meio do desenvolvimento começam a aparecer surpresas e mais surpresas.

O cliente precisa de uma solução para seu negócio, muitas vezes em prazo curto e buscando o menor custo. A questão é: qual é a qualidade que o cliente deseja? É código? Requisitos? Ou produto? Quanto mais controles de qualidade, maior é o custo e tempo – e o cliente precisa estar disposto a pagar por isso.

E aí o que fazer?

• Fazer tudo na correria e entregar no prazo para honrar o acordo – vulgo bancar o herói?
• Desenvolver o software e ir informando o cliente do seu andamento, mais muitas das vezes não receber por isso (Visto que valores são discutidos antes do inicio do projeto)?

Acredito que uma forma legal é ter o cliente vendo o produto nascer. Não que ele esteja o tempo inteiro vendo o desenvolvimento, mais sim estar próximo o bastante para poder participar das decisões de projeto – onde a qualidade em quesitos tecnológicos pode ficar abaixo do esperado. 

Conclusão

Talvez buscando a qualidade em quesitos funcionais (retirada de requisitos do escopo do projeto), ou até mesmo influenciando em alterações de prazo.
Só não tem como focar em qualidade deixando a entrega em déficit porque, entenda, a entrega também faz parte da qualidade. E na minha visão qualidade é fazer tudo o que foi definido com o cliente. Em todos os aspectos.