Conseiller rapidement (1-5 heures) pour 10 $.Un script pour 5 $. - page 9
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
La pratique a montré que l'autopromotion a tué plus d'un de ces fils. Je ne peux que conseiller une procédure raisonnable pour trouver un programmeur. IMHO.
1. Lire l'article "Conseiller expert sur commande. Instructions pour le négociant" écrit par le légendaire komposteur. Il s'agit d'un guide pratique pour préparer le RPT.
2. Cherchez sur le forum des programmeurs (et non des annonces de commandes), lisez les discussions, voyez comment les gens se comportent.
3. Faites une liste des candidats qui vous plaisent (ceux qui sont sympathiques, s'expriment correctement et avec précision, ont une longue expérience sur le forum avec une grande liste de scripts/articles sérieux publiés).
4. Rédiger le cahier des charges et contacter les candidats, après accord préliminaire, envoyer le cahier des charges pour une estimation des coûts.
5. Choisissez-en un et remerciez les autres.
D'après mon expérience, les autorités incontestées sont komposter et Integer (mes excuses aux autres professionnels, je ne les ai pas rencontrés).
L'algorithme est bon, mais une chose est sûre : plus l'auteur est "inconditionnel", plus ses services sont chers :) C'est essayer de trouver un compromis raisonnable.
Bien qu'il y ait probablement une part de vérité dans le fait que l'avare paie plusieurs fois...
Plusieurs fois, avec ma modeste expérience de la programmation, j'ai accepté d'exécuter des commandes pour des conceptions simples et élémentaires.
L'impression est sans équivoque. En règle générale, les clients ont une très mauvaise idée de ce qu'ils veulent obtenir au final.
Et pour leur faire interpréter les termes de référence - cela prend parfois plus de temps que la rédaction proprement dite du conseil ! Les termes de référence (sans ironie) sont parfois presque impossibles à saisir !
En général, le client lui-même ne sait pas du tout ce qu'il veut...
D'un "ToR" : Quand l'horaire de la ligne A est juste en dessous de celui de la ligne B...
Autre communication dans la voix :
Moi : un peu, c'est combien et dans quoi ?
Zach : Tu es un idiot, tu ne sais pas ce qu'est un peu?
L'algorithme est bon, mais il y a un problème : plus un auto-item est "inconditionnel", plus ses services sont chers :) Vous essayez donc de trouver un compromis raisonnable.
Bien qu'il y ait probablement une part de vérité dans le fait qu'un avare paie plusieurs fois plus...
Un algorithme qui a été testé depuis des générations. Même dans ce fil de discussion, il est clair que la "communication désordonnée" entraîne des pertes d'argent et de nerfs plus importantes.
Et l'épargne doit être réalisée avec compétence : des choses simples à faire soi-même, des choses facultatives à commander pour une somme modique, mais les graals potentiels à donner aux diplômés.
Ils vous montreront intelligemment, raisonnablement et correctement que vous vous trompez à nouveau et vous vous souviendrez très bien de la leçon car elle a coûté cher.
Ne serait-il pas plus simple de vous faire connaître le montant que vous êtes prêt à payer, ainsi que le cahier des charges ?
pour le travail d'un programmeur.
En règle générale, le client lui-même ne comprend pas complètement ce qu'il veut...
Extrait d'un "ToR" : Quand l'horaire de la ligne A est juste un peu plus court que celui de la ligne B...
Autre communication par la voix :
Moi : un peu, c'est combien et dans quoi ?
Zach : Tu es un idiot, tu ne sais pas ce qu'est un peu?
non ciblé, mais tout de même un conseil - si vous voyez que le client lui-même ne sait pas ce qu'il veut, soyez plus tolérant : proposez un choix de plusieurs options. laissez-le choisir parmi elles !
pas ciblé, mais tout de même un conseil - si vous voyez que le client ne sait pas ce qu'il veut, soyez plus tolérant : proposez plusieurs options parmi lesquelles choisir. laissez-le choisir parmi elles !
C'est comme ça que les codeurs font... 2-3 variantes, puis le client décide.
Il y a peut-être ceux qui ne veulent pas s'embêter avec les "pinces qui tirent les TK".
non ciblé, mais tout de même un conseil - si vous voyez dans votre communication que le client lui-même ne sait pas ce qu'il veut, soyez plus tolérant : proposez plusieurs options à la fois. laissez-le choisir parmi elles !
Définitivement - tu ne devrais pas faire ça !
"Car" à tout résultat de "chasse d'eau" (et il n'y en aura pas d'autre) le coupable sera toujours le programmeur.
Avec toutes les conséquences...
Définitivement - tu ne devrais pas faire ça !
"Car" en cas de résultat "raté" (et il n'y en aura pas d'autre), le programmeur sera toujours à blâmer.
Avec toutes les conséquences...
vous ne comprenez pas ! ;-) si le client ne peut pas formuler la condition lui-même, vous pouvez simplement lui donner un choix de plusieurs options (basées sur votre expérience de développement, de formalisation). et il peut vous dire si cela correspond à sa "description confuse" ou non. s'il dit qu'une option correspond, alors laissez-le ! Mais si vous commencez à écrire sans formaliser la tâche (en termes de conformité avec la "description verbeuse du client"), alors - oui, je suis tout à fait d'accord avec vous - peu importe comment vous écrivez le programmeur, il sera toujours mauvais, vous devrez le refaire 2-3-4-5 fois.
Eh, c'est difficile d'être un codeur après tout. Il est également difficile pour un client de communiquer avec un codeur si ce dernier est "tellement idiot qu'il ne sait pas ce que signifie "un petit peu"". Et ce qui est amusant, c'est que pour formuler correctement le RPT, l'esprit du client doit être tourné de la même manière que celui de ce codeur idiot.