Le travail de service : vers une réorientation des développeurs de haut niveau vers le professionnalisme - page 6
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
Tenter de transférer la responsabilité à quelqu'un d'autre avec la bravade "Je me ferme délibérément la tête, je m'en remets au contractant et j'exige de lui une responsabilité à 100 % pour tout" entraîne des problèmes imminents pour l'auteur.
En tout état de cause, pour notre part, nous sensibiliserons davantage les clients aux exécutants potentiels et leur interdirons de recruter beaucoup de travail.
Tenter de transférer la responsabilité à quelqu'un d'autre avec la bravade "Je me ferme délibérément la tête, je m'en remets au contractant et j'exige de lui qu'il soit responsable de tout à 100%" entraîne des problèmes imminents pour l'auteur.
En tout état de cause, pour notre part, nous sensibiliserons davantage les clients aux exécutants potentiels et leur interdirons de recruter beaucoup de travail.
... Si le plan était de 3 jours, mais que le temps réel est de 7 jours, le client saura qu'il y a une forte probabilité d'échec.
Pourquoi cette urgence ? Qu'est-ce qui va mal se passer ? Il est certain qu'une fois le travail reçu, le client le testera pendant des mois. Quelle différence cela fait-il, alors, si c'est 3 jours ou 7 jours ?
Pourquoi cette urgence ? Qu'est-ce qui va mal se passer ? Il est certain qu'une fois le travail reçu, le client le testera pendant un mois ou plus. Quelle différence cela fait-il, alors, que ce soit 3 jours ou 7 jours ?
:-) Une déclaration inconvenante dans un environnement logiciel.... Un accord vaut plus que de l'argent.... il peut toujours y avoir deux ou plusieurs points de vue sur les délais, un compromis est un accord mutuel sur l'accord mutuel des parties, si le défaut de mise en œuvre de l'algorithme peut conduire à l'inopérabilité du programme, alors le défaut de mise en œuvre de l'accord sur les délais peut détruire la relation entre les parties contractantes..... pas toujours bien sûr.... mais ça peut...
C'est un algorithme relationnel de base.
Idéalement, les deux parties contractantes devraient être responsables à 100% des engagements pris.
J'ai réfléchi longtemps, il y a longtemps, à ce genre de mathématiques, car elles donnent un total de 200% - si deux parties se mettent d'accord et prennent toutes deux 100% de responsabilité..... et comment il peut y avoir plus de responsabilité que 100%.
Cependant, il est ainsi.... il doit y avoir quelque chose d'intangible qui interfère avec le processus des accords...
Ce n'est pas la première fois que j'entends parler de commandes en retard et de clients mécontents.
Il est vrai que le programmeur n'a aucune responsabilité - vous ne pouvez même pas laisser de commentaires négatifs pour une commande qui a été annulée (par exemple parce qu'elle est en retard).
Pour moi, la responsabilité (financière ou sous forme de notation) ne serait pas superflue. Mais le programmeur doit tenir compte de la quantité exacte de temps dont il est responsable. Et dans le statut de "vérifié par le client", laissez-le suspendre même 50 travaux.
C'est un algorithme de base des relations
Idéalement, les deux parties contractantes devraient être responsables à 100% des engagements pris.
Tout est clair avec les programmeurs - quelle que soit la façon dont on voit les choses, c'est lui qui est à blâmer pour avoir pris la commande et ne pas avoir respecté les délais et ...... et qu'il a travaillé, et comme vous le savez, ceux qui ne font rien ne sont jamais en faute.
Il reste ensuite à traiter avec les clients, en particulier les débutants - quelle est la demande du client pour l'incapacité à formuler des TOR corrects et à "se faire sauter la cervelle une douzaine de fois avec sa spontanéité enfantine". Si vous savez que la première barre est la bonne, alors le conseiller expert ouvre des transactions qui ne sont pas en accord avec les signaux de l'indicateur sur l'historique - il est fortement en retard, il a besoin de plus tôt......
? ???????
Pourquoi cette urgence ? Qu'est-ce qui va mal se passer ? Il est certain qu'une fois le travail reçu, le client le testera pendant des mois. Quelle est la différence entre 3 jours et 7 jours ?
La différence est que les "7 au lieu de 3" peuvent être plusieurs : un programmeur n'a pas pu faire face à la tâche et le contrat a été résilié, le deuxième n'a pas pu le faire à temps et le contrat a été à nouveau résilié, etc.
Et ce n'est pas l'affaire d'un entrepreneur de compter le temps (l'argent) de ses clients. Si vous dites 3, faites-le pour 3 (la clarification de la tâche et la vérification finale ne comptent pas).
Tout est clair avec les programmeurs - quelle que soit la façon dont on voit les choses, c'est lui qui est à blâmer pour avoir pris la commande et pour avoir fait foirer les délais et ...... et qu'il a travaillé, et comme chacun sait, qui ne fait rien n'est jamais en faute.
Il reste ensuite à traiter avec les clients, notamment les débutants - quelle est la demande du client pour l'incapacité à formuler un TOR correct et à "se faire sauter la cervelle une douzaine de fois avec sa spontanéité enfantine". Si la première barre est la bonne, alors le conseiller expert ouvre des transactions qui ne sont pas conformes aux signaux de l'indicateur sur l'historique - il est fortement en retard, il a besoin de plus tôt .......
Mais le client en paie le prix et ne peut rien lui prendre d'autre.
Le développeur décide d'accepter ou non la mission (et du prix à fixer). Si vous voulez le travail à n'importe quel prix - faites face à 50 pages de description absurde pour 10 $, si vous ne voulez pas - appelez cela "100 $ pour créer un algorithme" et attendez votre client.
De plus, il y a le RPT et l'arbitrage. "Gravement retardé" doit être formulé, sinon il sera rejeté.