[Cascavel-pm] Software comercial

[Daniel Ruoso]

Dom, 2006-10-01 às 19:56 -0300, vict0r escreveu:
> Srs.,
> desculpem-me se este assunto já foi tema de discussão nesta lista,
> porém estou em um momento de decisão e, se possível, gostaria da
> opinião de outras pessoas.
> Estou desenvolvendo um sistema e estou avaliando as possibilidades de
> no futuro distribui-lo comercialmente, e no momento analiso a questão
> de comercializar com uma licença fechada um sistema em perl. Sei que
> existe a possibilidade de compilar o código em perl e gerar um
> executável binário, porém estou tentando analisar o melhor caminho a
> seguir, quais as opções e vantagens/desvantagens, e se no caso de
> comercialização de um sistema não seria mais indicado usar uma
> linguagem como Java.
> Abraço a todos,
> Victor Dias.

Bom Victor, falo com a experiência de quem passou por essa exata
experiência, e que, por outros motivos, acabou por escolher fazer em
Java (ok, não fui eu quem escolhi. Eu fui voto vencido).

É assim, se você está pensando em fazer um software de caixinha[1], bem,
lembre-se de ver quanto você está investindo, por que você provavelmente
precisa investir muito mais que isso. Produzir software no varejo é algo
para poucas empresas que podem fazer o investimento de marketing e
publicidade necessário para tornar a operação um break-even. Neste caso
talvez faça sentido obscurecer o código usando bytecode ou par ou
simplesmente usando algum obscurecedor de código.

No entanto, se você está trabalhando com um número razoavelmente pequeno
de clientes, digamos assim que voce pretende conseguir não mais que 5
clientes por mês nos próximos 12 meses (o que, cá pra nós é uma meta
extremamente otimista, se você está começando a fazer o sistema agora)
então não vai fazer absolutamente nenhuma diferença. Por que você vai
estar trabalhando com sistemas personalizáveis, então o sistema que você
entregar para um cliente nunca vai ser exatamente igual ao que você
entregar para outro. E principalmente, o processo de implantação do
sistema normalmente vai requerer um conhecimento bastante especifico
sobre o sistema que dificilmente alguém que não esteja dentro da sua
empresa vai conseguir ter. Então, nesse caso, não se dê ao trabalho. Não
vale a pena.

Agora assim, vou dar a você um conselho que não tem nada a ver com Perl
nem é técnico de forma alguma. Não comece a desenvolver um produto.
Desenvolver um produto de software é algo extremamente caro que voce
dificilmente vai conseguir ter um retorno a não ser que voce esteja
investindo muito dinheiro para mobilizar uma equipe de desenvolvimento,
uma equipe de suporte, uma equipe de implantação e principalmente uma
boa equipe de vendas. Se você não está fazendo esse investimento em
conjunto, leia o seguinte com atenção:

Quando você faz um software como um produto e tenta vender como um
produto, o cliente não entende que aquilo tem uma quantidade de trabalho
gigantesca dentro daquilo e dificilmente vai aceitar pagar bem por
qualquer alteração e dificilmente vai aceitar que você cobre
adequadamente pelo suporte e pela manutenção. Além do fato que vender
software como produto é extremamente mais difícil (recomendo o livro
"Vendendo Software" que discute bem esse tema).

Por fim, e aqui vai realmente o meu conselho (de alguém que há 4 anos
atrás estava se fazendo as mesmas perguntas que você):

Pense que você tem um conjunto de ferramentas para tornar melhor o
negócio dos seus clientes. Você precisa convencer o seu cliente que você
e a sua equipe tem um know-how específico que pode tornar o negócio dele
mais eficiente. Para isso você vai usar as ferramentas que você julgar
necessárias e voce vai sempre mostrar todas as opções de investimento
para o cliente. Uma das opções, e normalmente a última, vai ser
desenvolver um sistema inteiro do zero. Normalmente você vai querer
integrar o maior número de ferramentas possíveis. Vou dar um exemplo:
Você conhece o GnuCash? você sabia que ele pode usar o PostgreSql como
backend? Você conhece o RT? 

A questão é que você pode prestar um serviço de muito maior valor
agregado (ou seja, você trabalha menos e ganha mais) e no fim das contas
o seu cliente vai ter provavelmente gasto menos e vai ter uma solução
mais otimizada.

Enfim... Mas como se diz, se conselho fosse bom não era de graça. :)

A propósito, se tem uma coisa que eu aprendi nesses  4 anos é que
aquelas perguntinhas que o pessoal de administração faz não deve ser
respondido de forma irresponsável. Três perguntas em especial não devem
ser respondidas com menos de uma página de redação:

1) Quem é o seu cliente? Que perfil ele tem? Quanto normalmente ele
investiria? Que valores são importantes para ele?

2) Quem são seus concorrentes? Eles trabalham com o mesmo perfil de
clientes que você? Que táticas de abordagem aos clientes eles assumem?
Que valores eles mais utilizam no processo de comercialização?

3) Quem é você? O que você tem pra oferecer ao seu cliente? Por que ele
escolheria você e não o seu concorrente? O que você tem que o seus
concorrentes não tem? O que o seu concorrente tem que você não tem? O
cliente do perfil que voce definiu acha que os seus diferenciais valem a
pena?

Enquanto você não tiver pelo menos uma página (fonte 12pt, espaçamento
simples) para cada uma dessas perguntas, não se mova, não gaste um
centavo, não tome nenhuma decisão. O único dinheiro que você deve gastar
antes de ter essas respostas é em pesquisa de mercado, nada mais.

Novamente, se conselho fosse bom, não era de graça...

mas aqui foram meus 2 centavos...

Daniel