Discuter des conflits entre les programmeurs et les clients. Une discussion sur les situations ambiguës entre le programmeur et le client, et un classement des programmeurs les plus conflictuels. - page 7
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
"Discussion sur les conflits entre les programmeurs et les clients. Une discussion sur les situations ambiguës entre un programmeur et un client, et un classement des programmeurs les plus conflictuels.
Vous ne pouvez pas proposer quelque chose d'universel qui supprime tous les conflits. Au cœur des conflits, il y a la stupidité des clients. Pourquoi exactement les clients, parce que les programmeurs sont sur le terrain depuis longtemps.
Bien sûr, après la dixième ou vingtième tâche, la stupidité disparaît. Bien sûr, tout le monde est différent, pour quelqu'un cela disparaît dès la première tâche, pour quelqu'un cela ne disparaît jamais.
Obtenir du client qu'il se plonge d'abord dans le sujet, qu'il lise l'article COMMENT ÉCRIRE UNE TK, qu'il apprenne la terminologie n'est pas possible. Le plus gros mensonge du 21e siècle - "L'accord de licence stipulait . Je suis d'accord".
Éduquer le client au lieu d'un travail spécifique sur son TK, devrait se situer dans le prix, il s'y trouve déjà. L'intégrer à nouveau dans le prix ne fonctionnera pas. Il est ridicule de se plaindre des prix bas auprès des programmateurs d'emplois, ce sont eux qui les fixent.
Dans l'ensemble, il n'y a pas de conflit mondial. Il y a un travail de routine. Il y aura toujours des tricheries ponctuelles d'un côté et de l'autre.
Parlez-vous de tous vos TDR ou décrivez-vous la journée de travail de l'entrepreneur telle que vous l'envisagez ?
"Discussion sur les conflits entre les programmeurs et les clients. Une discussion sur les situations ambiguës entre un programmeur et un client, et un classement des programmeurs les plus conflictuels.
Vous ne pouvez pas proposer quelque chose d'universel qui supprime tous les conflits. Au cœur des conflits, il y a la stupidité des clients. Pourquoi précisément les clients, parce que les programmeurs sont sur le terrain depuis longtemps.
Bien sûr, après la dixième ou vingtième tâche, la stupidité disparaît. Bien sûr, tout le monde est différent, pour quelqu'un cela disparaît dès la première tâche, pour quelqu'un cela ne disparaît jamais.
Obtenir du client qu'il se plonge d'abord dans le sujet, qu'il lise l'article COMMENT ÉCRIRE UNE TK, qu'il apprenne la terminologie n'est pas possible. Le plus gros mensonge du 21ème siècle - "L'accord de licence stipulait . Je suis d'accord".
Éduquer le client au lieu d'un travail spécifique sur son TK, devrait se situer dans le prix, il s'y trouve déjà. L'intégrer à nouveau dans le prix ne fonctionnera pas. Il est ridicule de se plaindre des prix bas auprès des programmateurs d'emplois, ce sont eux qui les fixent.
Dans l'ensemble, il n'y a pas de conflit mondial. Il y a un travail de routine. Il y aura toujours des escroqueries ponctuelles d'un côté et de l'autre.
Mais tout cela ne signifie pas que quelqu'un qui voit des cercles ne peut pas réussir sur le marché, regardez le prix des tableaux impressionnistes.
Génie
Le tableau "Scream" seul
La langue russe elle-même est très difficile à appréhender de manière logique,
Il s'agit d'une représentation hypothétique de la journée de travail de l'exécuteur.
Eh bien, tout n'est pas si triste. Oui, le travail ne prend pas une commande par jour, parfois jusqu'à 3, tous les jours pendant plusieurs semaines. Mais les bugs constants et les pépins, je pense que c'est trop.
Je ne conteste pas qu'il existe des commandes et des clients que les programmeurs ont du mal à comprendre. C'est le karma de ces ordres ou autre chose, mais cela existe.
Les praticiens confirment que certaines commandes sont problématiques et parfois même sur une surface facile. Parfois, j'ai envie de refuser l'argent et de refuser la commande qui vous fait perdre la tête et qui prend du temps.
Mais si nous prenons une exécution purement technique, alors la programmation de qualité selon le cahier des charges convenu (ne prenons pas le temps d'approuver le cahier des charges) peut prendre au maximum 4 heures. Je prends un RPT gonflé pour quelques feuilles de texte fin.
Ensuite, il y aura de très petits changements dans 1 ou 2 jours, mais c'est déjà de la poussière. Pour les réparer, il faut au maximum 30 minutes.
Si vous travaillez avec un programmeur dans le style - aujourd'hui je veux une chose, et demain ajouter une nouvelle au code inachevé, ou ajouter une fonctionnalité qui proger pend et penser à la façon de le coller dans l'algorithme TOR, bien sûr - les problèmes dans cette version sera.
Et votre RPT s'étendra sur un mois, voire six mois. En conséquence, vous vous ferez une fausse idée du codage en tant que tel.
PS.
N'oubliez pas qu'avant de commencer à travailler, vous devez toujours discuter de tous les détails de l'algorithme et de toutes les combinaisons possibles de cas de figure de son travail. Inutile pour l'exécutant, qui ne trouvera pas dans votre RPT un seul cas particulier d'échec de l'algorithme.
Il y a toujours de nouvelles choses ! Le client ne les voit pas. Mais ils doivent être vus par l'entrepreneur. Et avant le début des travaux, vous en informer et en discuter avec vous. Mais il est obligatoire avant le début du codage.
Il est préférable de passer une semaine sur le cahier des charges, puis d'écrire le code parfait en quelques heures, plutôt que de passer des mois à chercher des bogues dans le cahier des charges volatile. Ni vous, ni le codeur n'apprécierez un tel processus.
Même une phrase prononcée avec une intonation différente peut avoir un sens et un contexte différents.
C'est là où vous allez avec ça. :)
Vous pouvez donc assumer l'entière responsabilité du résultat de l'interprète et de ce qu'il vous donnera après avoir parlé avec différentes intonations sur Skype :)
Vous êtes vous-même à blâmer si, parmi tous les types de communication, vous choisissez un transfert d'informations par voie aérienne. Heureusement qu'il n'y a pas de vidéo, sinon vous pourriez vous plaindre que la même phrase, prononcée avec une position différente du pied droit et une oreille décollée, peut signifier des choses différentes :)
Pour vous, la recommandation n°2.
Communiquez avec l'interprète uniquement avec le clavier. Si vous n'êtes pas capable de former une pensée dans votre tête de manière appropriée et que vous ne pouvez pas la mettre sur papier, de quel type de compréhension parlons-nous ? C'est absurde.
C'est une très grosse erreur si vous pensez que vous pouvez transmettre le sens profond d'un mot avec l'intonation de votre voix.
Le sens du mot est déjà dans le mot et peu importe si c'est l'oncle à la voix fumée ou la grand-mère souriante dans la file d'attente pour le pain qui me dira d'aller me faire foutre.
N'oubliez pas que vous devez toujours, avant le début du travail, discuter complètement de tous les détails de l'algorithme et de toutes les combinaisons possibles de cas de figure de son travail. Inutile pour l'interprète, qui ne trouvera pas dans votre RPT un seul cas particulier d'échec de l'algorithme.
Il y a toujours de nouvelles choses ! Le client ne les voit pas. Mais ils doivent être vus par l'entrepreneur. Et avant le début des travaux, vous en informer et en discuter avec vous. Mais elle est obligatoire avant le début du codage.
Il est préférable de passer une semaine sur le cahier des charges, puis d'écrire le code parfait en quelques heures, plutôt que de passer des mois à chercher des bogues dans le cahier des charges volatile. Ni vous, ni le codeur n'apprécierez un tel processus.