Mercado: Como serão tratadas as situações de falha do produto após uma actualização de construção ?
...
Até agora, a boa notícia é que a empresa está a desenvolver, e organiza e apoia o Mercado e a venda de produtos MQL5. Portanto, haverá uma luta pela qualidade, mas quem pagará por ela com a sua reputação e dinheiro?
As perguntas são muito relevantes. E deve ser encontrada uma solução. Já tenho uma sugestão a fazer.
Por exemplo, poderia fazer o seguinte. Para instalar a próxima actualização (construir) para o terminal de comércio, o próprio utilizador decide se o instala ou não. Por outras palavras, tem de o sensibilizar para a nova construção, mas ser capaz de decidir por si próprio quando a pode instalar. Os criadores de aplicações devem então ter duas versões do terminal instalado. Uma versão com a construção anterior, e uma segunda versão com a construção mais recente. Se não forem encontrados bugs na nova construção ao utilizar o produto, então o vendedor faz uma nota no Mercado de que o produto é compatível com a última construção. Se o produto começar a ir de buggy na última construção, a marcação não será lá colocada e o utilizador saberá que é demasiado cedo para instalar a nova construção.
Esta é uma opção. Mais em que pensar...
- 2011.01.05
- MetaQuotes Software Corp.
- www.mql5.com
De facto, esta questão tem vindo a ser formulada há muito tempo.
O que é que as três partes devem fazer agora?
Dois. O programador não tem nada a ver com isto. O comprador necessita simplesmente de poder descarregar o novo mercado ex. Sem e-mails, pedidos, captchas, mensagens de confirmação, etc.
Claro, apenas no hardware, onde já está ligado.
Os produtos têm uma funcionalidade de versão interna, pode ler sobre isso no artigo https://www.mql5.com/ru/articles/385.
Quando uma nova versão é lançada, haverá uma solicitação automática para actualizar o software. Isto é bom para actualizar versões menores, tais como 2.xx
Ao lançar versões principais, terá de registar um novo produto para poder revender ou continuar a lançar novas versões sob o registo antigo com uma actualização automática gratuita para os clientes existentes.
- 2012.04.17
- MetaQuotes Software Corp.
- www.mql5.com
Os produtos têm uma versão interna, pode ler sobre isso no artigo https://www.mql5.com/ru/articles/385
Quando uma nova versão é lançada, haverá uma solicitação automática para actualizar o software. Isto é bom para actualizar versões menores, tais como 2.xx
Quando as versões principais forem lançadas, será necessário registar o novo produto para poder revender ou continuar a lançar novas versões sob o registo antigo com uma actualização automática gratuita para os clientes existentes.
Sim, isto é o que se aplica às novas versões dos produtos.
Mas isso é um pouco diferente do que se passa com a questão do fio.
E se a nova construção dos blocos de terminais for o funcionamento normal do software?
Se pensarmos nisso, as construções saem cerca de duas vezes por mês. Acontece que ao actualizar o terminal, o cliente perderá a capacidade de utilizar o produto durante algumas semanas. É disso que estamos a falar.
Não só isso, o programador deve abandonar o seu actual trabalho e ocupar-se a apanhar o insecto. E se ele tiver vários produtos no mercado?
Assim, todos eles ficam com o incómodo.
Mas qual é a solução?
mas qual poderia ser a solução?
não há solução.
Até que haja uma nova construção com as correcções, o produto permanecerá inactivo (ou perderá dinheiro para o cliente, ou talvez até lucre - quem sabe? - depois de o bug do terminal ser corrigido, uma multidão de utilizadores irá indignadamente exigir que o bug seja devolvido ao terminal?)
Se não forem encontrados bugs na nova construção durante a utilização do produto, o vendedor marcará o produto no Mercado como compatível com a última construção. Se o produto começar a "avariar" na última construção, não é feita qualquer marcação e o utilizador saberá que é demasiado cedo para instalar a nova construção.
Então o vendedor é também responsável por apanhar insectos em novas construções? De facto, o produto é utilizado pelo comprador (e detecta um bug), o problema ocorre por culpa da MQ (dentro do tópico indicado), e o vendedor tem de assumir a culpa?
...
Essa é uma opção. Mais em que pensar...
Idealmente, vemos a seguinte solução (a questão é como ela é viável):
1- Desactivar a opção de instalação de actualização automática no terminal, apenas mensagem de disponibilidade e decisão pelo utilizador (isto já foi sugerido algures antes);
2- Função "rollback to build #..." no terminal.
Depois, no caso de uma falha de EA causada por uma nova falha de construção, podem ser facilmente tomadas medidas temporárias até que a situação de construção seja resolvida. Os particularmente cautelosos podem, como precaução extra, instalar actualizações num dia de folga e executar a sua EA no testador. Pela adequação ou inadequação da história em relação à construção anterior, tomar a decisão final de cancelar ou não a actualização.
Ao desenvolver (vender) um Expert Advisor, deve especificar a construção sobre a qual o seu desempenho foi testado.
Idealmente, vemos a seguinte solução (a questão é até que ponto é realista):
1- Desactivar a opção de instalar automaticamente as actualizações no terminal, informando apenas a disponibilidade e tomando a decisão pelo utilizador (isto já foi sugerido algures antes);
2- Função "rollback to build #..." no terminal.
Depois, no caso de uma falha de EA causada por uma nova falha de construção, podem ser facilmente tomadas medidas temporárias até que a situação de construção seja resolvida. Os particularmente cautelosos podem, como precaução extra, instalar actualizações num dia de folga e executar a sua EA no testador. Pela adequação ou inadequação da história em relação à construção anterior, tomar a decisão final de cancelar ou não a actualização.
Ao desenvolver (vender) um Expert Advisor, deverá especificar a construção sobre a qual o seu desempenho foi testado.
sim, isso parece-me também uma sugestão razoável, (como uma portagem semelhante64 sugerida imediatamente).
A instalação de uma construção a pedido é a saída lógica. Irá proteger o vendedor e o comprador contra os criadores. :)
O vendedor poderá testar mais silenciosamente o produto na nova construção e expor as edições e a nova versão, se necessário.
Peço aos criadores da plataforma - pensem sobre este tópico e sobre esta proposta em particular.
Talvez a empresa tenha a sua própria visão do problema e da sua solução?
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Você concorda com a política do site e com os termos de uso
Esta tem sido, de facto, uma questão desde há muito tempo.
A situação é a seguinte, bastante real.O programador e o controlo do mercado, tendo testado o software, colocaram-no no mercado.
Evidentemente, a parte mais stressante desta situação é que a reputação do programador irá sofrer mais do que a da empresa. Porque os problemas da construção ainda precisam de ser identificados e provados.O cliente, depois de pagar uma certa quantia de dinheiro por ele, descobre algum tempo depois que o produto já não funciona na nova construção.
OK. O programador verifica e descobre que o problema está na nova construção, mas não há maneira de localizar e localizar o bug.
O que é que as três partes fazem agora?
Devolver os fundos ao comprador que possam já ter sido investidos no novo empreendimento?
Enviar o comprador aos desenvolvedores do terminal dizendo que o problema está na construção e não é culpa do programador?
Ou de outra forma?
O produto receberá muitos feedbacks negativos durante este tempo e poderá ter de ser removido da prateleira.
Assim, acontece que os programadores de MQL são dependentes dos programadores da plataforma. E são tão dependentes que qualquer truque na construção pode arruinar a sua reputação nas raízes, ou perturbar futuras encomendas ou outros planos.
Em geral, que saída está prevista para esta situação e como pode a empresa resolvê-la?
ZS. Até agora, a boa notícia é que a empresa está a desenvolver e ela própria organiza e apoia o Mercado e a venda de produtos MQL5. Portanto, haverá uma luta pela qualidade, mas quem pagará por ela com a sua reputação e dinheiro?