29 de setembro de 2006

Construir ou comprar? A pergunta mais antiga do mundo...

Meu projeto foi cancelado...

Ou melhor, foi reorientado. Basicamente, assim que entrei nesse novo emprego e me apresentaram a aplicação que deveria ser desenvolvida eu só tive uma pergunta:

- Mas, porquê estamos desenvolvendo uma coisa que pode ser comprada e que provavelmente vai ser muito mais eficiente na solução do problema???

Veja, ninguém escreve o seu próprio banco de dados. Escolhe-se Oracle, DB2, SQL Server, Sybase, MySQL, PostgreSQL, ou o que seja. Faz-se isso porque, sinceramente, escrever um banco de dados custa caro. Construir um que funcione bem custa muito mais caro. Manter um, depois de construido, e expandir com funcionalidades diversas e necessárias custa uma fortuna! Sem contar o custo de um produto que não funciona bem...

Da mesma forma, determinadas aplicações já estão chegando a um ponto onde o know-how existente e a oferta de pacotes torna o desenvolvimento de um produto in-house uma tolice inacreditável. Softwares para gestão de clientes, os famosos CRM, são a bola da vez.

Quem, em sã consciência, vai criar toda uma estrutura do zero para catalogar e gerenciar clientes? O objetivo, claro, não é catalogar - mas extrair informação útil dos dados. Extrair padrões de consumo. Extrair padrões de utilização dos serviços e produtos que a sua empresa oferece.

Com tantos pacotes de CRM no mercado, com tantos clientes que foram cobaias e que refinaram os produtos - vale realmente a pena desenvolver alguma coisa do zero? E quanto tempo vai levar pra se concluir o desenvolvimento e se alcançar o objetivo da empreitada: garimpar informação útil para a direção da empresa a partir dos dados acumulados? E quanto tempo a empresa vai ficar sem essa informação útil até que o produto esteja disponível?

Eu, sinceramente, compraria um pacote que melhor se adaptasse as necessidades da empresa e adaptaria a empresa ao pacote no que fosse necessário.

Foram sete meses de desenvolvimento para uma pré-release que causou grande impressão com relação a usabilidade e funcionalidade da interface (Swing) e uma péssima impressão no tocante a qualidade do código de acesso ao banco de dados (Hibernate 3).

A decisão?

Vamos procurar um pacote.

Antes tarde do que nunca...

Nenhum comentário: