Markt: Wie wird mit Produktfehlern nach einem Build-Update umgegangen?
...
Bis jetzt ist die gute Nachricht, dass das Unternehmen entwickelt, organisiert und unterstützt den Markt und den Verkauf von MQL5-Produkten. Daher wird es einen Kampf um Qualität geben, aber wer wird dafür mit seinem Ruf und seinem Geld bezahlen?
Die Fragen sind sehr relevant. Und es muss eine Lösung gefunden werden. Ich habe bereits einen Vorschlag gemacht.
Sie könnten zum Beispiel Folgendes tun. Um das nächste Update (Build) für das Handelsterminal zu installieren, entscheidet der Benutzer selbst, ob er es installieren möchte oder nicht. Mit anderen Worten: Sie müssen ihm/ihr den neuen Bau bekannt machen, aber er/sie muss selbst entscheiden können, wann er/sie ihn installieren darf. Anwendungsentwickler müssen dann über zwei Versionen des installierten Terminals verfügen. Eine Version mit dem vorherigen Build und eine zweite Version mit dem neuesten Build. Wenn bei der Verwendung des Produkts keine Fehler in der neuen Version gefunden werden, vermerkt der Anbieter im Market, dass das Produkt mit der neuesten Version kompatibel ist. Wenn das Produkt im neuesten Build Fehler aufweist, wird die Markierung nicht mehr angezeigt, und der Benutzer weiß, dass es zu früh ist, den neuen Build zu installieren.
Dies ist eine Option. Mehr zum Nachdenken...
- 2011.01.05
- MetaQuotes Software Corp.
- www.mql5.com
Diese Frage stellt sich in der Tat schon seit langem.
Was sollten die drei Parteien jetzt tun?
Zwei. Der Programmierer hat damit nichts zu tun. Der Käufer muss lediglich in der Lage sein, den neuen Markt abzurufen. Ohne E-Mails, Anfragen, Captchas, Bestätigungsmeldungen usw.
Natürlich nur auf der Hardware, auf der sie bereits vorhanden ist.
Die Produkte verfügen über eine interne Versionierungsfunktion, die Sie im Artikel https://www.mql5.com/ru/articles/385 nachlesen können .
Wenn eine neue Version veröffentlicht wird, erscheint automatisch eine Aufforderung zur Aktualisierung der Software. Dies ist gut für die Aktualisierung von kleineren Versionen wie 2.xx
Bei der Freigabe von Hauptversionen müssen Sie das neue Produkt registrieren, um es weiterverkaufen zu können, oder Sie können weiterhin neue Versionen unter der alten Registrierung mit einem automatischen kostenlosen Upgrade für bestehende Kunden freigeben.
- 2012.04.17
- MetaQuotes Software Corp.
- www.mql5.com
Die Produkte haben eine eigene Versionierung, die Sie im Artikel https://www.mql5.com/ru/articles/385 nachlesen können.
Wenn eine neue Version veröffentlicht wird, erscheint automatisch eine Aufforderung zur Aktualisierung der Software. Dies ist gut für die Aktualisierung von kleineren Versionen wie 2.xx
Bei der Veröffentlichung von Hauptversionen müssen Sie das neue Produkt registrieren, um es weiterverkaufen zu können, oder Sie können weiterhin neue Versionen unter der alten Registrierung mit einem automatischen kostenlosen Upgrade für bestehende Kunden herausgeben.
Ja, das gilt für die neuen Versionen der Produkte.
Aber das ist etwas anderes als die Frage, um die es in diesem Thread geht.
Was ist, wenn die neue Version des Terminals den normalen Betrieb der Software blockiert?
Wenn man darüber nachdenkt, kommen die Builds etwa zweimal im Monat heraus. Es stellt sich heraus, dass der Kunde durch ein Upgrade des Terminals die Möglichkeit verliert, das Produkt für ein paar Wochen zu nutzen. Das ist es, worüber wir hier reden.
Und nicht nur das: Der Programmierer sollte seinen derzeitigen Job aufgeben und sich um den Fehler kümmern. Und wenn er mehrere Produkte auf dem Markt hat?
So bekommen sie alle den Ärger.
Aber was ist die Lösung?
aber was könnte die Lösung sein?
gibt es keine Lösung.
Solange es keine neue Version mit den Korrekturen gibt, bleibt das Produkt untätig (oder verliert Geld an den Kunden, oder vielleicht sogar Gewinn - wer weiß? - dann, nachdem der Fehler im Terminal behoben ist, eine Menge von Nutzern entrüstet fordern wird, dass der Fehler wieder in das Terminal aufgenommen wird?)
Wenn bei der Verwendung des Produkts keine Fehler in der neuen Version gefunden werden, kennzeichnet der Anbieter das Produkt im Marketplace als kompatibel mit der neuesten Version. Wenn das Produkt auf dem neuesten Build zu "gluckern" beginnt, wird keine Markierung vorgenommen und der Benutzer weiß, dass es zu früh ist, den neuen Build zu installieren.
Der Hersteller ist also auch für das Auffinden von Fehlern in neuen Builds verantwortlich? Tatsächlich wird das Produkt vom Käufer benutzt (und entdeckt einen Fehler), das Problem tritt durch die Schuld von MQ auf (innerhalb des angegebenen Themas), und der Verkäufer muss die Schuld auf sich nehmen?
...
Das ist eine Möglichkeit. Mehr zum Nachdenken...
Im Idealfall ergibt sich folgende Lösung (die Frage ist, wie praktikabel sie ist):
1- Deaktivieren Sie die Option der automatischen Update-Installation im Terminal, nur die Verfügbarkeitsmeldung und die Entscheidung des Benutzers (dies wurde bereits irgendwo vorgeschlagen);
2- "rollback to build #..." Funktion im Terminal.
Im Falle einer EA-Störung, die durch einen neuen Build-Fehler verursacht wird, können dann einfach vorübergehende Maßnahmen ergriffen werden, bis der Build-Fehler behoben ist. Besonders Vorsichtige können als zusätzliche Vorsichtsmaßnahme Updates an einem freien Tag installieren und ihren EA im Tester laufen lassen. Durch die Angemessenheit oder Unzulänglichkeit der Geschichte im Vergleich zu den vorherigen Build, die endgültige Entscheidung treffen, ob zu aktualisieren-abzubrechen.
Wenn Sie einen Expert Advisor entwickeln (verkaufen), sollten Sie den Build angeben, auf dem seine Leistung getestet wurde.
Im Idealfall sehen wir folgende Lösung (die Frage ist, wie realistisch sie ist):
1- Deaktivierung der Option zur automatischen Installation von Updates im Terminal, nur noch Meldung der Verfügbarkeit und Entscheidung durch den Benutzer (dies wurde bereits irgendwo vorgeschlagen);
2- "rollback to build #..." Funktion im Terminal.
Im Falle einer EA-Störung, die durch einen neuen Build-Fehler verursacht wird, können dann einfach vorübergehende Maßnahmen ergriffen werden, bis der Build-Fehler behoben ist. Besonders Vorsichtige können als zusätzliche Vorsichtsmaßnahme Updates an einem freien Tag installieren und ihren EA im Tester laufen lassen. Durch die Angemessenheit oder Unzulänglichkeit der Geschichte im Vergleich zu den vorherigen Build, die endgültige Entscheidung treffen, ob zu aktualisieren-abzubrechen.
Wenn Sie einen Expert Advisor entwickeln (verkaufen), sollten Sie den Build angeben, auf dem seine Leistung getestet wurde.
Ja, das scheint mir auch ein vernünftiger Vorschlag zu sein (wie ein ähnlicher Vorschlag, den tol64 sofort gemacht hat).
Die Installation eines Build-on-Demand-Systems ist der logische Ausweg. Schützt den Verkäufer und den Käufer vor den Bauunternehmern. :)
Der Verkäufer kann das Produkt in aller Ruhe mit dem neuen Build testen und die Änderungen und die neue Version gegebenenfalls veröffentlichen.
Ich bitte die Entwickler der Plattform - denken Sie über dieses Thema und diesen Vorschlag im Besonderen nach.
Vielleicht hat das Unternehmen seine eigene Vorstellung von dem Problem und seiner Lösung?
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Diese Frage stellt sich eigentlich schon seit langem.
Die Situation ist wie folgt, ganz real.Der Programmierer und die Kontrolleure des Marktplatzes haben die Software getestet und sie auf den Marktplatz gestellt.
Das Schlimmste an dieser Situation ist natürlich, dass der Ruf des Programmierers mehr leiden wird als der des Unternehmens. Denn die Probleme des Baus müssen noch ermittelt und nachgewiesen werden.Nachdem der Kunde einen bestimmten Betrag dafür bezahlt hat, stellt er einige Zeit später fest, dass das Produkt in dem neuen Gebäude nicht mehr funktioniert.
GUT. Der Programmierer prüft und stellt fest, dass das Problem in der neuen Version vorhanden ist, aber es gibt keine Möglichkeit, den Fehler zu lokalisieren und zu beheben.
Was machen die drei Parteien jetzt?
Rückgabe der Gelder an den Käufer, die möglicherweise bereits in die neue Entwicklung investiert wurden?
Den Käufer zu den Entwicklern des Terminals schicken und ihm sagen, dass das Problem im Build liegt und nicht die Schuld des Programmierers ist?
Oder einen anderen Weg?
Das Produkt wird in dieser Zeit viele negative Rückmeldungen erhalten und muss möglicherweise aus dem Regal genommen werden.
Es zeigt sich also, dass MQL-Programmierer von den Plattformentwicklern abhängig sind. Und sie sind so abhängig, dass jeder Trick beim Bau ihren Ruf an den Wurzeln ruinieren oder zukünftige Aufträge oder andere Pläne durchkreuzen kann.
Welcher Ausweg aus dieser Situation ist geplant und wie kann das Unternehmen diese Situation lösen?
Bisher ist die gute Nachricht, dass das Unternehmen entwickelt und selbst den Markt und Verkauf von MQL5-Produkten organisiert und unterstützt. Daher wird es einen Kampf um Qualität geben, aber wer wird dafür mit seinem Ruf und seinem Geld bezahlen?