Softwares personalizados qual sua opnião

Assuntos Gerais
#1

Qual a opnião de vcs sobre a empresa de desenvolvimento adorar como diferencial softwares diferenciados para cada cliente atendendo especificas necessidades de cada um?

minha opnião…em um número pequeno de clientes já começa a perceber a dificuldade de manter a estabilidade e manutenção de softwares especificos para diferentes clientes, o custo do sistema as vezes aumenta muito chegando a ser inviável muitas vezes por modificações infinitas sugeridas
pelo cliente que não tem o conhecimento pleno do proprio negócio, ou por erro do analista…

então aqui fica minha opnição que já vivencio esse caos…
agora queria saber a opnião de vcs da GUJ…para poder saber se foi eu q não tive sorte XD

desde ja muito obrigada pela participação,
e fiquem com DEUS

#2

Na realidade sua pergunta não seria: “o que é mais negócio: desenvolver software de prateleira ou personalizado?”

No primeiro caso, óbviamente é mais fácil, visto que você só tem uma base de código pra dar manutenção. Por outro lado, financeiramente nem tanto, pois seu software vai ter de ter um preço bem mais baixo para que se torne um diferencial.

Na outra ponta, sinceramente não vejo dificuldade alguma. Se seu cliente quer algo personalizado, cabe a você, como desenvolvedor, fazer um trabalho correto de documentação para evitar que se caia neste tipo de armadilha. Mesmo porque, ao menos pela minha experiência, 99% dos trabalhos são softwares customizados feitos para necessidades muito específicas. Nunca tive problema com isto. Como mencionei, é uma questão de organização.

Mas voltando ao primeiro caso, pode ser que mesmo sendo produzido um software de prateleira, seja necessário fazer uma customização ou outra. Nesta situação, o que rola é o seguinte: seu software de prateleira tem de ser MUITO bem especificado para que seja algo fácil de ser expandido através de plugins ou aberto para comunicação com outros sistemas.

Neste caso, a criação de “plugins” personalizados cairia na segunda opção, software customizado. E novamente, minha opinião: a probabilidade de se transformar em uma GRANDE furada vai ser diretamente proporcional à sua capacidade organizacional.

#3

Minha opinião sobre a Accenture (ou qualquer outra fábrica de sofware)?

Eles gastam bastante com marketing e pessoal de vendas, talvez isso explique.

#4

[quote=kicoloco]Na realidade sua pergunta não seria: “o que é mais negócio: desenvolver software de prateleira ou personalizado?”

No primeiro caso, óbviamente é mais fácil, visto que você só tem uma base de código pra dar manutenção. Por outro lado, financeiramente nem tanto, pois seu software vai ter de ter um preço bem mais baixo para que se torne um diferencial.

Na outra ponta, sinceramente não vejo dificuldade alguma. Se seu cliente quer algo personalizado, cabe a você, como desenvolvedor, fazer um trabalho correto de documentação para evitar que se caia neste tipo de armadilha. Mesmo porque, ao menos pela minha experiência, 99% dos trabalhos são softwares customizados feitos para necessidades muito específicas. Nunca tive problema com isto. Como mencionei, é uma questão de organização.

Mas voltando ao primeiro caso, pode ser que mesmo sendo produzido um software de prateleira, seja necessário fazer uma customização ou outra. Nesta situação, o que rola é o seguinte: seu software de prateleira tem de ser MUITO bem especificado para que seja algo fácil de ser expandido através de plugins ou aberto para comunicação com outros sistemas.

Neste caso, a criação de “plugins” personalizados cairia na segunda opção, software customizado. E novamente, minha opinião: a probabilidade de se transformar em uma GRANDE furada vai ser diretamente proporcional à sua capacidade organizacional. [/quote]

Como é que vc administra as versões dos clientes, você cria uma cópia para cada um e deixa a versão seguir em frente, é isso?

flws

#5

já tive esse tipo de problema. o pior era manter as versões dos cleinte atualizadas. pode ser resolvido com repositórios ditribuidos

uma branch para o core do sistema (padrão)
uma branch para cada cliente.

se vc faz atualizações no sistema e precisa passar para as versões dos clientes, é só fazer o merge do cleinte com o repo do padrão. se vc pode desenvolver funcionalidades para os cleintes, e essas funcionalidades podem virar padrão do software, ai vc pode fazer o contrário, fazendo o merge só do que foi alterado pra essa funcionalidade.

Lógico que é um pouco mais complexo que isso, mas ajuda bastante. melhor que ficar de copy paste em cada versão dos clientes quando se corrige um bug, hehehe

#6

[quote=alexborges]Qual a opnião de vcs sobre a empresa de desenvolvimento adorar como diferencial softwares diferenciados para cada cliente atendendo especificas necessidades de cada um?
[/quote]

Existem 3 tipos de sistemas:
Os que são um produto. O cliente influencia as features das próximas versões mas ele não as comanda (dá ordens).
Os que são on demand. O cliente comanda as features e todas as versões são dele.
Os que sendo produtos querem deixar o cliente comandar algumas coisas. Isto é possivel se o produto já inclui pontos de extensão que serão usados para acomodar o produto a características do cliente. Estes produtos extensiveis são melhores que os produtos padrão. Um exemplo é o pactoe office. Ele é extensivel via VBA e existe N pontos de extensão. Para este caso o produto foi constuido com o pensamento que ele será acomodado ao cliente por ele mesmo ( ou alguem a quem ele paga, que pode ser o produtor original do software mas não tem que ser). Os ERP seguem esta prespetiva tb.

Agora, vc ter um software que em tese é um produto, mas as features são ditadas pelos clientes é furada. E a furada é do departamento comercial. Como eles não fizeram um levantamento bom das features que agradariam ao mercado eles entram com medo e assim que o cliente pede alguma coisa - por muito imbecil que seja- ela é incluida. A desculpa é que “o processo do cliente é um pouco diferente” do processo modelado pelo software. Humm… cada empresa tem o seu modelo, mas um ERP se trata a todos…é porque foi pensado para isso.

Pode agradar a poucos todo o tempo (costumização) a todos algum tempo (produto extensivel) mas não a todos todo o tempo (produtos “costumizado” especificamente)

#7

[quote=fantomas][quote=kicoloco]Na realidade sua pergunta não seria: “o que é mais negócio: desenvolver software de prateleira ou personalizado?”

No primeiro caso, óbviamente é mais fácil, visto que você só tem uma base de código pra dar manutenção. Por outro lado, financeiramente nem tanto, pois seu software vai ter de ter um preço bem mais baixo para que se torne um diferencial.

Na outra ponta, sinceramente não vejo dificuldade alguma. Se seu cliente quer algo personalizado, cabe a você, como desenvolvedor, fazer um trabalho correto de documentação para evitar que se caia neste tipo de armadilha. Mesmo porque, ao menos pela minha experiência, 99% dos trabalhos são softwares customizados feitos para necessidades muito específicas. Nunca tive problema com isto. Como mencionei, é uma questão de organização.

Mas voltando ao primeiro caso, pode ser que mesmo sendo produzido um software de prateleira, seja necessário fazer uma customização ou outra. Nesta situação, o que rola é o seguinte: seu software de prateleira tem de ser MUITO bem especificado para que seja algo fácil de ser expandido através de plugins ou aberto para comunicação com outros sistemas.

Neste caso, a criação de “plugins” personalizados cairia na segunda opção, software customizado. E novamente, minha opinião: a probabilidade de se transformar em uma GRANDE furada vai ser diretamente proporcional à sua capacidade organizacional. [/quote]

Como é que vc administra as versões dos clientes, você cria uma cópia para cada um e deixa a versão seguir em frente, é isso?

flws
[/quote]

No início eu criava branches no sistema de controle de versão. Porém, posteriormente, comecei a implementar meus sistemas de tal forma que o núcleo seja expansível, ou seja, quando o cliente precisa de alguma coisa muito específica, tudo o que faço consiste em implementar algum módulo separado que se comunique com este kernel via http ou alguma outra forma de comunicação, ou seja, basicamente crio uma API básica que me possibilite a sua expansão através da implementação de clientes posteriormente.

Esta comunicação inicialmente era feita a partir de DLLs (eu trabalhava com Delphi), e posteriormente, conforme fui me aprofundando em plataformas abertas e largando o Delphi, comecei a adotar comunicação via http ou https dentro de uma arquitetura REST.

#8

[quote=kicolobo]No início eu criava branches no sistema de controle de versão. Porém, posteriormente, comecei a implementar meus sistemas de tal forma que o núcleo seja expansível, ou seja, quando o cliente precisa de alguma coisa muito específica, tudo o que faço consiste em implementar algum módulo separado que se comunique com este kernel via http ou alguma outra forma de comunicação, ou seja, basicamente crio uma API básica que me possibilite a sua expansão através da implementação de clientes posteriormente.

Esta comunicação inicialmente era feita a partir de DLLs (eu trabalhava com Delphi), e posteriormente, conforme fui me aprofundando em plataformas abertas e largando o Delphi, comecei a adotar comunicação via http ou https dentro de uma arquitetura REST. [/quote]

Obrigado pela resposta!

Idéia interessante esta que vc descreveu, tenho estudado OSGi na intenção de criar algo nesta direção; ainda não estou bem certo se é uma boa saida. Vou considerar esta idéia que vc aplicou.

#9

[quote=fantomas][quote=kicolobo]No início eu criava branches no sistema de controle de versão. Porém, posteriormente, comecei a implementar meus sistemas de tal forma que o núcleo seja expansível, ou seja, quando o cliente precisa de alguma coisa muito específica, tudo o que faço consiste em implementar algum módulo separado que se comunique com este kernel via http ou alguma outra forma de comunicação, ou seja, basicamente crio uma API básica que me possibilite a sua expansão através da implementação de clientes posteriormente.

Esta comunicação inicialmente era feita a partir de DLLs (eu trabalhava com Delphi), e posteriormente, conforme fui me aprofundando em plataformas abertas e largando o Delphi, comecei a adotar comunicação via http ou https dentro de uma arquitetura REST. [/quote]

Obrigado pela resposta!

Idéia interessante esta que vc descreveu, tenho estudado OSGi na intenção de criar algo nesta direção; ainda não estou bem certo se é uma boa saida. Vou considerar esta idéia que vc aplicou.[/quote]

Sabe, na minha opinião quanto mais “http(s)” melhor, porque assim você não fica preso a uma linguagem ou plataforma específica na hora de criar seus componentes.
Digo isto porque muitas vezes tanto para você, quanto para o seu cliente, é mais interessante permitir que outros desenvolvedores (além de você) implementem estas novas funcionalidades, e nestes casos nem sempre o sujeito sabe Java :\

#10

Voces estao falando em novas features, ok neste caso com plugins e addons resolve, mas o problema é o cliente pedindo um “campinho” a mais numa tela aqui, um botão noutra tela la e por ai vai, ai vira uma zorra total.

A não ser que todas as telas sejam plugaveis, e neste caso cada cliente pode ter sua propria tela de venda por exemplo.

O problema é se voce fala não para o cliente ele vai e procura o concorrente que faz o que ele quer.

Enquanto não tenho meu sistema plugavel, o que faço para minimizar é adicionar a feature para todo mundo, usa quem quer, não é obrigatorio usar, mas esta lá.

#11

[quote=fredferrao]Voces estao falando em novas features, ok neste caso com plugins e addons resolve, mas o problema é o cliente pedindo um “campinho” a mais numa tela aqui, um botão noutra tela la e por ai vai, ai vira uma zorra total.

A não ser que todas as telas sejam plugaveis, e neste caso cada cliente pode ter sua propria tela de venda por exemplo.

O problema é se voce fala não para o cliente ele vai e procura o concorrente que faz o que ele quer.

Enquanto não tenho meu sistema plugavel, o que faço para minimizar é adicionar a feature para todo mundo, usa quem quer, não é obrigatorio usar, mas esta lá. [/quote]

Concordo…isto é realmente um problema, há casos que o cliente não quer ver campos que não estão sendo utilizados.

Se alguem tiver uma idéia diz ai.

flws

#12

ai é fácil. só dizer não

#13

[quote=fredferrao]Voces estao falando em novas features, ok neste caso com plugins e addons resolve, mas o problema é o cliente pedindo um “campinho” a mais numa tela aqui, um botão noutra tela la e por ai vai, ai vira uma zorra total.

A não ser que todas as telas sejam plugaveis, e neste caso cada cliente pode ter sua propria tela de venda por exemplo.

O problema é se voce fala não para o cliente ele vai e procura o concorrente que faz o que ele quer.

Enquanto não tenho meu sistema plugavel, o que faço para minimizar é adicionar a feature para todo mundo, usa quem quer, não é obrigatorio usar, mas esta lá.[/quote]

Voce esta usando Java para uma simples arquitetura CRUD? Pode ser este o problema.

#14