Discussion de l'article "Comment commander un robot de trading dans MQL5 et MQL4" - page 5
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
papaklass a raison - intégrez le coût des algorithmes formulés sur la balle dans le coût de votre travail.
Ou, dans les cas les plus compliqués, stipuler le coût de la formalisation de la tâche. Mais ils sont rarement d'accord.
Et puis, avec l'expérience, n'importe quel ensemble de caractères que vous estimez d'un seul coup, et de manière assez précise. Par l'écriture, par le surnom, par le vocabulaire.....
papaklass a raison - intégrez le coût des algorithmes formulés sur la balle dans le coût de votre travail.
Ou, dans les cas les plus compliqués, stipuler le coût de la formalisation de la tâche. Bien qu'ils soient rarement d'accord.
Et puis, avec l'expérience, n'importe quel jeu de caractères que vous estimez d'un seul coup, et de manière assez précise. Par l'écriture, par le surnom, par le vocabulaire ....
komposter, permettez-moi de ne pas être d'accord avec vous... Bien que chacun ait sa propre vérité. Dans le sens où comment considérer un client potentiel - consciencieux ou non ?
Si vous mettez dans le coût de votre travail le coût des algorithmes formulés sur la balle, alors par définition le client n'est pas considéré de bonne foi, puisqu'il paie pour le "risque de ne pas commander". C'est ce que font les détaillants, par exemple, en termes de vol. Chacun d'entre nous surpaye les marchandises exactement autant que le magasin nous a volés....
Disposant d'un mécanisme de construction d'une relation entre le client et l'entrepreneur par le biais du site MQ, il est possible de la construire plus ou moins équitablement... ou d'essayer de le faire....
Tout à fait d'accord avec abolk:
Par exemple, imaginez que vous êtes un artiste-interprète. Vous discutez et formez un TOR correct pour le client pendant environ 3-4 jours... Et maintenant, comme le suggère papaklass, regardons le manager.... Communiquera-t-il avec un acheteur potentiel pendant au moins plus d'une heure ?
Les experts-rédacteurs s'assoient parfois, calculent le temps nécessaire pour effectuer le travail sur des missions normales et sur des ballons, et le comparent avec le ratio des revenus provenant des missions normales et des ballons. Le résultat sera de l'ordre de 30/70 et 70/30. Pourquoi les clients normaux devraient-ils payer pour les aérostiers ? Le coût du travail doit inclure le coût de la discussion sur le travail, mais dans une mesure raisonnable (lecture et 2 ou 3 cercles avec questions et réponses), les clients normaux ne devraient pas payer pour les aérostiers.
... Maintenant, comme le suggère papaklass, examinons le vendeur.... Communiquera-t-il avec un acheteur potentiel pendant au moins plus d'une heure ?
Experts-rédacteurs, asseyez-vous, calculez le temps qu'il vous faut pour travailler sur des missions normales et sur des ballons, comparez avec le ratio des revenus provenant des missions normales et des ballons. Vous obtiendrez quelque chose comme 30/70 et 70/30.
C'est ainsi que les choses se passent. Moins le client est prêt à payer, plus la tâche est souvent incompréhensible, plus il y a d'arrogance et de prétention.
Il faut comprendre que les prix du marché comprennent déjà le prix du travail du programmeur sur les exigences du client.
Si un programmeur ne comprend pas cela, il est condamné à réduire sa compétitivité.
Il est utopique de vouloir séparer et facturer au client le prix de la spécification des besoins et le prix du travail sur le code lui-même.
Essayer de comprendre comment séparer et facturer au client le prix du cahier des charges et le prix du travail sur le code lui-même relève de l'utopie.
Il est possible de fixer un prix fixe pour l'analyse et l'approbation des termes de référence. Quant à savoir si la commande sera honorée ou non, c'est une autre affaire. :)
c'est à peu près la même chose que chez un horloger - inspection et détection des défauts 500r. le coût de la réparation - en fonction de la complexité de la réparation et du coût des pièces de rechange.
Il faut comprendre que les prix du marché comprennent déjà le prix du travail du programmeur sur les exigences du client.
Si un programmeur ne comprend pas cela, il est condamné à réduire sa compétitivité.
Les tentatives visant à trouver un moyen de séparer et de facturer au client le prix de la spécification des exigences et le prix du travail sur le code lui-même relèvent de l'utopie
Il ne s'agit pas de rationner le travail d'un programmeur, ni d'établir une politique de prix, ni de savoir quel type de clients sont des balourds et quel type de programmeurs sont constamment choyés, mais de constater que le service de travail présente des lacunes graves et fondamentales dans la procédure de passation des commandes, à savoir :
1) l'exécutant devrait pouvoir refuser le travail
2) l'exécutant devrait pouvoir réduire le coût du travail
3) le client devrait pouvoir augmenter le coût du travail.
Il est possible de fixer un montant forfaitaire pour l'analyse et l'approbation des termes de référence. Quant à savoir si la commande sera honorée ou non, c'est une autre affaire. :)
C'est à peu près la même chose qu'un horloger - inspection et détection des défauts 500r. Le coût de la réparation - en fonction de la complexité de la réparation et du coût des pièces de rechange.
En ce qui concerne le développement de TOR et les problèmes de paiement - dans le service "Work", tout est normalement prévu. Le client joint les TdR, appuie sur le 2e bouton - et le programmeur voit son argent. En d'autres termes, avant que le programmeur ne commence à travailler sur les TdR, il s'assure que le client est solvable. Ensuite, la tâche peut être modifiée et remplacée plusieurs fois.
J'ai eu affaire à un étranger qui marchandait, demandait une remise, et l'hypothèse de sa solvabilité semblait si plausible que j'ai entrepris de l'aider avec le TOR, mais dès qu'il s'est agi du deuxième bouton, il est devenu sourd-muet.
La conclusion de tout cela est qu'un programmeur, qui suit les règles, ne commence à travailler avec le RPT que lorsque le client appuie sur le deuxième bouton. La seule chose qui permet de juger de la solvabilité du client est le fait qu'il confirme la deuxième étape (TOR). Il n'y a rien d'autre (de nombreux internautes, tant russophones qu'anglophones, ont atteint la perfection dans l'art de la suggestion et du faux-semblant).
Quant à la correction du coût du travail en cas de modification du cahier des charges, honnêtement, je ne sais pas comment elle devrait être mise en œuvre. Mais il est quelque peu illogique qu'un programmeur réduise le coût du travail, tout comme il est illogique qu'un client l'augmente. Qui utilisera une possibilité aussi étrange ?