Qual é o seu produto de software?

Para muitas empresas, um produto de software é visto como o resultado de um projeto de software, restrito a escopo, prazo e custo predefinidos.

Pensa-se em produto de software como o conjunto de arquivos a serem instalados nos computadores (servidores, desktops, dispositivos, etc) em que o software será utilizado pelo cliente.

Uma vez que tal conjunto de arquivos satisfaça aos requisitos contratados pelo cliente, considera-se que o produto de software apresenta a qualidade esperada.

Okay, mas onde está o problema nisso?

Requisitos de software, e principalmente requisitos informados pelos clientes, nem sempre especificam critérios de qualidade interna, e quando o fazem, fazem de maneira bem superficial, deixando a interpretação a cargo de quem for desenvolver e avaliar o cumprimento de tais requisitos.

À medida que o produto de software vai sendo utilizado, solicitações de mudança começam a surgir, regras são alteradas, novas funcionalidades são incluídas, e uma nova versão do produto de software é distribuída a cada conjunto de alterações negociadas.

Novamente, uma vez que os requisitos apresentados são satisfeitos, a nova versão é aceita e a vida segue.

Eventualmente, algo para de funcionar. "Quem mexeu nisso?", "Isso funcionava na última vez que usei.", "E quando foi isso?", "Não me lembro, mas funcionava."

E ai começa o inferno para o programador. Gerentes cobrando resultados e o desaparecimento dos bugs, prazos apertados ou inexistentes, cliente reclamando, correções feitas sem a devida atenção, novos defeitos sendo introduzidos. Você já deve ter entendido do que estou falando.

Mas o que uma coisa tem a ver com a outra? Atender aos requisitos do cliente e ter o software aprovado com base no cumprimento de tais requisitos é o que causa esse tipo de problema? Não. Mas atender aos requisitos do cliente não deve ser o único objetivo. E ver o produto de software como um conjunto de arquivos executáveis que satisfaça a esses requisitos também não é o mais adequado. Para se evitar esse tipo de "problema inesperado", é necessário investir na qualidade interna do produto, ou seja, naquilo que o cliente não vê, não avalia, não aprova, e que deve ser considerado o verdadeiro produto de software a ser produzido e mantido: o seu código fonte.

A única forma de se evitar que erros sejam introduzidos no software sempre que funcionalidades forem alteradas ou introduzidas é garantir que o código fonte seja mantido em um alto nível de qualidade, seguindo boas práticas de desenvolvimento, utilizando técnicas e disciplinas desenvolvidas especificamente para tal finalidade.

Falta de qualidade interna normalmente não prejudica as primeiras versões do software, não prejudica a sua aprovação, não bloqueia seu pagamento. E com isso investimentos em qualidade interna acabam sendo ignorados, vistos como algo desnecessário, dispensável.

Entregar o software dentro do escopo, prazo e custo é importante, mas manter a saúde do software ao longo de sua vida também é. Lembre-se, o seu verdadeiro produto de software não são os binários entregues, isso se consegue gerar novamente com uma compilação. O seu verdadeiro produto de software são os seus códigos fonte. Invista na qualidade deles, e o resto virá naturalmente.