Mercato: come saranno gestite le situazioni di fallimento del prodotto dopo un aggiornamento della build?
...
Finora, la buona notizia è che l'azienda sta sviluppando, e organizza e supporta il mercato e la vendita di prodotti MQL5. Quindi, ci sarà una lotta per la qualità, ma chi pagherà con la sua reputazione e il suo denaro?
Le domande sono molto pertinenti. E bisogna trovare una soluzione. Ho già un suggerimento.
Per esempio, potete fare quanto segue. Per installare il prossimo aggiornamento (build) per il terminale di trading, l'utente stesso decide se installarlo o meno. In altre parole, dovete metterlo al corrente della nuova costruzione ma essere in grado di decidere da solo quando può installarla. Gli sviluppatori di applicazioni devono quindi avere due versioni del terminale installato. Una versione con la build precedente e una seconda versione con l'ultima build. Se non si trovano bug nella nuova build quando si usa il prodotto, il venditore fa una nota nel Market che il prodotto è compatibile con l'ultima build. Se il prodotto comincia ad essere buggato nell'ultima build, il marchio non sarà messo lì e l'utente saprà che è troppo presto per installare la nuova build.
Questa è un'opzione. Altro a cui pensare...
- 2011.01.05
- MetaQuotes Software Corp.
- www.mql5.com
In effetti, questa domanda è stata ventilata per molto tempo.
Cosa dovrebbero fare ora i tre partiti?
Due. Il programmatore non c'entra niente. L'acquirente deve solo essere in grado di scaricare il nuovo mercato ex. Senza email, richieste, captchas, messaggi di conferma, ecc.
Naturalmente, solo sull'hardware, dove è già attivo.
I prodotti hanno una funzione di versioning interno, potete leggerlo nell'articolo https://www.mql5.com/ru/articles/385.
Quando viene rilasciata una nuova versione ci sarà una richiesta automatica di aggiornare il software. Questo è buono per aggiornare le versioni minori come la 2.xx
Quando si rilasciano versioni maggiori, è necessario registrare un nuovo prodotto per essere in grado di rivendere o continuare a rilasciare nuove versioni sotto la vecchia registrazione con un aggiornamento automatico gratuito per i clienti esistenti.
- 2012.04.17
- MetaQuotes Software Corp.
- www.mql5.com
I prodotti hanno un versioning interno, potete leggerlo nell'articolo https://www.mql5.com/ru/articles/385
Quando viene rilasciata una nuova versione, ci sarà una richiesta automatica di aggiornare il software. Questo è buono per aggiornare le versioni minori come la 2.xx
Quando vengono rilasciate le versioni maggiori, è necessario registrare il nuovo prodotto per essere in grado di rivendere o continuare a rilasciare nuove versioni sotto la vecchia registrazione con un aggiornamento automatico gratuito per i clienti esistenti.
Sì, questo è quello che si applica alle nuove versioni dei prodotti.
Ma questo è un po' diverso da quello che riguarda la domanda nel thread.
E se la nuova build del terminale blocca il normale funzionamento del software?
Se ci pensate, le build escono circa due volte al mese. Si scopre che aggiornando il terminale, il cliente perde la possibilità di usare il prodotto per un paio di settimane. È di questo che stiamo parlando.
Non solo, il programmatore dovrebbe lasciare il suo attuale lavoro e darsi da fare per catturare il bug. E se ha diversi prodotti sul mercato?
Così tutti si beccano la scocciatura.
Ma qual è la soluzione?
ma quale potrebbe essere la soluzione?
non c'è soluzione.
Finché non ci sarà una nuova build con le correzioni, il prodotto rimarrà inattivo (o perderà denaro per il cliente, o forse anche profitto - chi lo sa? - poi, dopo che il bug del terminale è stato risolto, una folla di utenti chiederà indignata che il bug sia riportato al terminale)?
Se non si trovano bug nella nuova build mentre si usa il prodotto, il venditore segnerà il prodotto nel Marketplace come compatibile con l'ultima build. Se il prodotto inizia a "glitchare" sull'ultima build, non viene fatta alcuna marcatura e l'utente saprà che è troppo presto per installare la nuova build.
Quindi il venditore è anche responsabile della cattura dei bug nelle nuove build? Infatti, il prodotto viene usato dall'acquirente (e rileva un bug), il problema si verifica per colpa di MQ (all'interno dell'argomento dichiarato), e il venditore deve prendersi la colpa?
...
Questa è un'opzione. Altro a cui pensare...
Idealmente, vediamo la seguente soluzione (la domanda è quanto sia fattibile):
1- Disabilitare l'opzione di installazione automatica degli aggiornamenti nel terminale, solo il messaggio di disponibilità e la decisione dell'utente (questo è stato suggerito da qualche parte prima);
2- funzione "rollback alla build #..." nel terminale.
Quindi, nel caso di un glitch EA causato da un glitch di una nuova build, si possono facilmente prendere misure temporanee fino a quando la situazione della build non sarà risolta. Quelli particolarmente prudenti possono, come ulteriore precauzione, installare gli aggiornamenti in un giorno libero ed eseguire il loro EA nel tester. In base all'adeguatezza o all'inadeguatezza della storia rispetto alla build precedente, prendere la decisione finale se aggiornare-cancellare.
Quando sviluppate (vendete) un Expert Advisor, dovreste specificare la build su cui sono state testate le sue prestazioni.
Idealmente, vediamo la seguente soluzione (la domanda è quanto sia realistica):
1- Disabilitare l'opzione di installare automaticamente gli aggiornamenti nel terminale, segnalando solo la disponibilità e facendo decidere l'utente (questo è stato suggerito da qualche parte prima);
2- funzione "rollback alla build #..." nel terminale.
Quindi, nel caso di un glitch EA causato da un glitch di una nuova build, si possono facilmente prendere misure temporanee fino a quando la situazione della build non sarà risolta. Quelli particolarmente prudenti possono, come ulteriore precauzione, installare gli aggiornamenti in un giorno libero ed eseguire il loro EA nel tester. In base all'adeguatezza o all'inadeguatezza della storia rispetto alla build precedente, prendere la decisione finale se aggiornare-cancellare.
Quando sviluppate (vendete) un Expert Advisor, dovreste specificare la build su cui sono state testate le sue prestazioni.
sì, anche a me sembra un suggerimento ragionevole, (come un altro simile suggerito immediatamente da tol64).
Installare una build on demand è la via d'uscita più logica. Proteggerà il venditore e l'acquirente dagli sviluppatori. :)
Il venditore potrà testare più tranquillamente il prodotto sulla nuova build ed esporre le modifiche e la nuova versione, se necessario.
Chiedo agli sviluppatori della piattaforma di pensare a questo argomento e a questa proposta in particolare.
Forse l'azienda ha una propria visione del problema e della sua soluzione?
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Accetti la politica del sito e le condizioni d’uso
Questa è stata in realtà una domanda per molto tempo.
La situazione è la seguente, abbastanza reale.Il programmatore e il controllo del mercato, dopo aver testato il software, lo mettono sul mercato.
Naturalmente, la parte più stressante di questa situazione è che la reputazione del programmatore soffrirà più di quella dell'azienda. Perché i problemi della costruzione devono ancora essere identificati e provati.Il cliente, dopo aver pagato una certa somma di denaro, scopre qualche tempo dopo che il prodotto non funziona più nella nuova costruzione.
OK. Il programmatore controlla e trova che il problema è nella nuova build, ma non c'è modo di trovare e localizzare il bug.
Cosa fanno ora i tre partiti?
Restituire all'acquirente i fondi che potrebbero essere già stati investiti nel nuovo sviluppo?
Mandare l'acquirente agli sviluppatori del terminale dicendo che il problema è nella build e non è colpa del programmatore?
O in un altro modo?
Il prodotto riceverà molti feedback negativi durante questo periodo e potrebbe dover essere rimosso dallo scaffale.
Così si scopre che i programmatori MQL dipendono dagli sviluppatori della piattaforma. E sono così dipendenti che qualsiasi trucco nella costruzione può rovinare la loro reputazione alle radici, o interrompere gli ordini futuri o altri piani.
In generale, quale via d'uscita da questa situazione è prevista e come può l'azienda risolverla?
ZS. Finora la buona notizia è che la società sta sviluppando e si organizza e supporta il mercato e la vendita di prodotti MQL5. Quindi, ci sarà una lotta per la qualità, ma chi pagherà con la sua reputazione e il suo denaro?