Mercado: Como serão tratadas as situações de falha do produto após uma actualização de construção ?

 

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.
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?

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 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?

 
sergeev:
...


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...

Ордерa, позиции и сделки в MetaTrader 5
Ордерa, позиции и сделки в MetaTrader 5
  • 2011.01.05
  • MetaQuotes Software Corp.
  • www.mql5.com
Надежный торговый робот не может быть создан без понимания механизмов работы торговой системы MetaTrader 5. Клиентский терминал получает от торгового сервера информацию о позициях, ордерах и сделках. Чтобы правильно обработать эти данные средствами MQL5 необходимо хорошо представлять как происходит взаимодействие mql5-программы и среды исполнения терминала.
 
sergeev:

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
Публикуйте свои интересные разработки в сервисе Маркет, и ваши программы станут доступными сразу всем трейдерам на MetaTrader 5 по всему миру. Маркет - это отличная возможность заработка с моментальным зачислением на счет и удобной статистикой для анализа покупок и скачиваний демо-версий Продуктов. Все MQL5-программы на Маркете при продаже автоматически шифруются под покупателя, допускают до трех активаций и не требуют дополнительной защиты с вашей стороны.
 
Renat:

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.

 
papaklass:
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?

 
sergeev:

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?)

 
tol64:

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 comprador utiliza o produto (e descobre o bug), o problema ocorre por culpa da MQ (dentro do tópico indicado), e o vendedor tem de assumir a culpa?
 
Yedelkin:
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?
tol64:
...

Essa é uma opção. Mais em que pensar...

Neste momento, esta é a única opção/oferta. E não é o mais conveniente/melhor.
 

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.

 
Wangelys:

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?