Marché : Comment les situations de défaillance du produit seront-elles gérées après une mise à jour du build ? - page 3
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
+1
Si c'est le concept, vous ne devriez pas brandir vos poings.
Vous avez mal compris la "singularité" de l'option. C'était le seul à l'époque où j'ai écrit à ce sujet. Maintenant, il existe déjà une version modifiée et même d'autres variantes. Le train de la "singularité" est déjà parti. :)
OK, supposons que chaque opinion est la seule au moment où elle a été écrite :) Le seul pour l'auteur de l'avis :) L'ironie, bien sûr.
Le travail se poursuit même après que le produit a été mis sur le marché. Et il ne faudra pas longtemps pour le tester sur une nouvelle construction.
Êtes-vous sûr que tout le monde écrit des programmes avec tous les modules utilisés tout le temps et immédiatement ? Et que personne ne dispose de modules qui sont branchés une fois tous les quinze jours ou une fois par mois. Avec ce type de code, les bogues ne sont pas forcément découverts "au fur et à mesure" et ce, par les clients.
OK, partons du principe que chaque opinion est la seule au moment où elle est écrite :) Le seul pour l'auteur de l'avis :) L'ironie, bien sûr.
Êtes-vous sûr que tout le monde écrit des programmes dont tous les modules sont utilisés en permanence et immédiatement ? Et que personne ne dispose de modules qui sont branchés tous les quinze jours ou tous les mois. Dans un tel code, les bogues peuvent être détectés "en cours de travail", loin de l'immédiat, et par les clients.
La décision sera prise par les développeurs du terminal commercial. Avant de le faire, ils examineront la question sous tellement d'angles que nous ne pourrions même pas en rêver. En fin de compte, tout peut rester comme c'est. :)
Avez-vous des variantes de solution à cette question ? Ou bien, parmi les options proposées, laquelle vous semble la plus proche de ce qu'elle devrait être ?
Je vous ai donné un exemple de ce qu'un acheteur lirait s'il y avait les mots AUCUNE RESPONSABILITÉ dans la phrase.
Juste au cas où, laissez-moi vous rappeler que la perception humaine est sélective. Un fait bien connu du cinéma : si le film n'intéresse pas le public dans les 20 premières minutes, alors il peut s'agir de n'importe quoi, de n'importe quelles cascades déroutantes et généralement d'une beauté paradisiaque, mais le cinéma à ce moment-là est vide, ne regarde cette beauté personne.
Il en va de même pour les ventes, la marque bien connue dans notre pays, Zhiguli, a dû être rebaptisée Lada en Italie, car elle rappelle beaucoup gigolo, eh bien, quel genre de ventes peut-il y avoir si un acheteur vient et se voit offrir une "voiture moderne très cool" avec le nom gigolo :) alors comment monter dessus ? Je peux imaginer les exclamations excitées des Italiens, regardez, regardez, un gigolo est arrivé :)
Il est simplement surprenant que la plupart d'entre eux ne voient le problème que d'un seul côté. Et de sujet en sujet. Laissez-moi vous expliquer pour un cas spécifique.
Il y avait un auteur du programme, il y avait un programme, il y avait un client. Le programme a bien fonctionné pendant un certain temps, mais un bogue dans MQ l'a fait cesser de fonctionner. Qu'est-ce qu'une conclusion impartiale ? - C'est exact, si MQ est à l'origine du problème, il en est responsable, et les questions doivent être abordées sous cet angle. Que font la plupart des gens ? - Ils commencent, d'une manière ou d'une autre, à diviser les devoirs et les intérêts de l'auteur et de l'acheteur, et proposent des variations en fonction de la relation entre l'auteur et l'acheteur. En d'autres termes, ils laissent la raison derrière eux. Pour résoudre un problème et proposer des variantes, il est nécessaire de partir de la raison d'être d'un sujet, plutôt que des conséquences de la raison d'être pour l'auteur et l'acheteur...
Clause spéciale : pas de déviation du sujet.
Yedelkin, arrêtez de mélanger la discussion sur votre personnalité et les suggestions sur le sujet dans votre message.
Je n'ai pas la liberté de supprimer votre message dans son intégralité, il a des phrases sur le sujet. Je ne peux pas non plus supprimer des phrases individuelles d'un message hors-sujet.
Un avertissement vous a déjà été adressé - ne tournez pas le sujet vers votre personnalité.
Avez-vous des solutions pour régler ce problème ? Ou quelle option vous semble la plus proche de ce qu'elle devrait être ?
A en juger par le nombre de messages, les accusations de "trollisme" ne vont pas tarder à pleuvoir :)
... La première option, comme on dit "à la volée", l'a déjà énoncé. Si vous pensez qu'une discussion constructive n'est possible que s'il y a un tas d'options diverses - maintenant je vais réfléchir. Bien que le vecteur de pensée indiqué ci-dessus.
Yedelkin, arrêtez de mélanger la discussion sur votre personnalité et les suggestions sur le sujet dans votre message.
Je n'ai pas la liberté de supprimer votre message dans son intégralité, il a des phrases sur le sujet. Je ne peux pas non plus supprimer des phrases individuelles d'un message hors-sujet.
Un avertissement vous a déjà été adressé - ne tournez pas le sujet vers votre personnalité.
OK, je supprime le message "foiré" que j'ai fait, vous supprimez le message que j'ai cité, et le message actuel. D'accord ?
Quant aux "avertissements", c'est vous qui avez déplacé le fil de discussion vers mon identité. Même si vous avez ensuite supprimé ce message vous-même. Ne jouons donc pas au jeu des avertissements.
Avez-vous des solutions pour régler ce problème ? Ou quelle option vous semble la plus proche de ce qu'elle devrait être ?
Option 2. Si l'on souhaite formaliser les relations en vertu de la loi russe, il est nécessaire d'inviter des experts de la partie 4 du Code civil de la Fédération de Russie pour résoudre le problème. Voir, par exemple, l'article 1296 du Code civil "Programmes d'ordinateurs et bases de données créés sur commande". Si je comprends bien, si l'acheteur a commencé à utiliser le programme, il n'y a rien à exiger du programmeur - toutes les réclamations sont contre MQ comme source d'un éventuel bug. La question de savoir si MQ est en mesure de rejeter une telle demande leur appartient. ...Peut-être que d'autres verront une solution différente dans le Code civil.
Option 3. L'acheteur du marché ne doit pas seulement être informé de la disponibilité d'une nouvelle construction, mais en même temps, "dans le même flux d'informations", il doit savoir que cette construction est approuvée/non approuvée par l'auteur du programme. Si le build n'est pas approuvé par l'auteur du programme - ne permettez pas que ce build soit téléchargé au niveau du terminal sur l'ordinateur de l'acheteur de la Bourse (ou ne permettez pas que le programme de la Bourse soit chargé avec le nouveau build). Cela se traduira par :
===D'une manière ou d'une autre, les détails peuvent toujours être clarifiés/ajoutés. Je vous le dis tout de suite : on m'a demandé des options - je les ai générées. J'espère que l'idée est claire. Je suggère ce que j'ai trouvé maintenant. Aux questions "comment imaginez-vous une telle mise en œuvre", je ne peux pas répondre. Je ne défendrai certainement pas les options, sur la base d'une expérience malheureuse.
(c2) si l'auteur ne s'engage pas à maintenir le produit sur le marché lorsque de nouvelles versions sont publiées
c'est le point en question.
les règles et même les méta-citations hypothétiques n'ont pas inclus une telle clause dans l'accord de marché. Cela implique que les nouvelles constructions ne peuvent pas affecter le fonctionnement du produit MQL5. Et ce n'est pas le cas dans les produits réels.
Et c'est essentiel. Puisque les performances du produit après sa sortie dépendront des développeurs, et non du programmeur mql.
il s'agit de la clause en question.
dans les règles et même hypothétiquement les méta-citations n'ont pas mis une telle clause dans l'accord de marché. Ce qui implique que les nouvelles constructions ne peuvent pas affecter le fonctionnement du produit MQL5. Et ce n'est pas le cas dans les produits réels.
Et c'est essentiel.
Je n'étais pas conscient de telles subtilités. C'est-à-dire qu'à l'heure actuelle, c'est MQ qui a assumé (volontairement ou non) l'entière responsabilité dans cette partie, n'est-ce pas ?
Quant à l'Accord, ce n'est pas une fondation en béton armé, il est perfectible :) Si ce point est si important pour les auteurs des produits - concentrez-vous sur lui aussi, afin de parvenir à une solution mutuellement acceptable.
D'ailleurs, les civilistes ont cette approche... Pour résumer : le fabricant peut donner sa garantie sur une partie de certaines obligations et le magasin peut compléter cette garantie. Vous vous souvenez de Mvideo, par exemple ? - Là-bas, ils donnent une garantie d'échange gratuit pendant 2-3 ans pour 100-200 dollars. Ainsi, le fabricant du produit n'est responsable que de la partie des obligations qu'il a prises sur lui, le magasin - du reste.
Donc, si j'étais l'auteur du programme, j'essaierais d'utiliser la première option, à savoir : dans la publicité, le produit indiquerait qu'il est responsable uniquement de "untel", "untel" et "untel" (longue liste). Mais je ne suis pas responsable de "cela" (la liste restreinte). Et si les règles du marché restent inchangées, alors la responsabilité du produit au-delà des tâches que je couvre incombera à l'administration du magasin (parce que leurs règles sont ainsi).