Il semble qu'il y ait de nombreux problèmes, dont beaucoup sont liés à la communication.

Daily Standups pourrait vous aider. Ils sont un outil du monde agile. Même si vous ne suivez pas une méthodologie agile, vous pourriez toujours la trouver utile.

Tout simplement, chaque membre de l'équipe se tient ensemble au début de la journée et dit sur quoi ils ont travaillé hier, sur quoi ils ont l'intention de travailler pour la journée et tout ce qui les retient. Votre personne chargée du contrôle qualité doit s'occuper de, afin qu'elle sache ce qui se passe et peut poser des questions pour vous aider à hiérarchiser le travail.

Un outil de suivi des problèmes Jira, Trello, etc. peuvent être utilisés pour fournir un état à jour des problèmes, si vous conservez cela comme source principale d'informations, il sera moins nécessaire de le faire par e-mail. (Si vous en avez un, continuez simplement à y faire référence et refusez de répondre directement)

Le statut le plus récent du problème est dans lien vers le problème s'il vous plaît vérifiez ceci pour les mises à jour.

Une discussion franche sur la communication et le changement de contexte Ceci est plus direct que les autres approches, mais cela pourrait être très utile. Il se peut que le testeur n'ait aucune idée à quel point la commutation de contexte est perturbatrice pour un programmeur. Soutenez-le avec des preuves si vous en avez besoin. Il est clair que vous avez tous les deux le même objectif, mais il n'est pas clair si le non-programmeur sait quel est l'impact de ses interruptions.

Utilisez un chef de projet (personne) un intermédiaire pour protéger les programmeurs des interruptions peut aider. Un bon chef de projet sera en mesure d'aider la personne QA en montrant la priorité relative des différents morceaux de travail ainsi qu'en prenant et en priorisant les nouveaux problèmes sans que les programmeurs aient à changer immédiatement. (Un mauvais malheureusement ne le fera pas mais vous contactera directement, vous vous retrouverez donc avec deux fois les interruptions)

Enfin, ce serait bien si vous pouviez apprécier la rareté d'une bonne personne chargée du contrôle qualité. Bien qu'il semble qu'ils n'apprécient pas votre travail, je pense que vous ne les appréciez peut-être pas. Un bon contrôle qualité avec une connaissance approfondie et une passion pour un produit est une chose très rare. Je suis sûr qu'il y a des faux positifs lorsqu'ils identifient la mauvaise source du problème, mais je pense qu'il arrive souvent qu'ils aident en suggérant où quelque chose ne va pas. Le fait qu'ils sachent à peu près comment fonctionne le système est un énorme bonus. Je suis sûr que vous les regretteriez s'ils partaient.

Racontez-lui l'histoire du mécanicien automobile à qui on a demandé combien il facturait. Sa réponse a été: «C'est 25 $ de l'heure. Il coûte 35 $ si vous regardez, 45 $ si vous donnez des conseils et 55 $ si vous essayez d'aider. "

Je suis tombé sur cette chose même, voici ce que j'ai fait.

Remarque: ne faites cela que s'il n'y a pas d'urgence et que vous avez le temps.

Je me suis assis avec la personne et je les ai laissées me regarder corriger quelques bugs. Je leur ai fait savoir que parfois, des choses qui peuvent ressembler à des correctifs majeurs ou urgents ne le sont pas, et j'ai montré la résolution de quelque chose qui causait ce qui ressemblait à un problème majeur, mais qui a été corrigé en quelques minutes. Ensuite, j'ai montré ce qui ressemblait à une "modification mineure" qui a provoqué un recodage important en raison de l'architecture.

À défaut, j'ai également constaté que l'utilisation d'analogies et de mettre les choses en termes que la personne comprend est le meilleur moyen d'aider la personne à comprendre.

Vous pouvez utiliser une analogie automobile, si vous le souhaitez. Vous pouvez lui dire que votre mécanicien doit d'abord diagnostiquer le problème avant de savoir ce qui se passe, et que ce n'est pas parce que le voyant de votre moteur en est un, que votre voiture est sur le point de mourir. Cela pourrait signifier que votre bouchon d'essence n'est pas correct. La même chose s'applique pour corriger les bogues avec les programmes. Le fait qu'il en existe un ne signifie pas qu'il est difficile à réparer ou qu'il est urgent.

Cette personne essaie seulement d'aider, ne lui tire pas dans le pied, tout ce que tu as à dire c'est:

"J'ai eu ce [nom de la personne], merci pour votre aide. Je vous ferai savoir si j'ai des questions ".

S'ils reviennent immédiatement avec plus de serviabilité , répétez-vous. N'entretenez pas de longues conversations sur le correctif, surtout si vous les avez trouvées inutiles. Cela ne fera que les encourager à continuer à parler maintenant et à l'avenir.

S'ils vous harcèlent encore, vous allez juste leur montrer qu'ils ont tort avec des faits concrets sur le problème.

[Nom de la personne], je comprends ce que vous dites à propos de «A», mais je sais que le problème est vraiment lié à «B» comme je le vois (journaux, événements, données, etc.) pour prouve le. Pour le moment, j'ai vraiment besoin de me concentrer pour rassembler tout cela et trouver une solution.

Je ne sais pas si cela aide, mais voici comment je vais gérer des situations comme la vôtre:

Situation A. Lorsque votre collègue vous soumet un problème:

1. Écoutez cette personne

Quoi que vous fassiez, écoutez d'abord. Écoutez leur problème: pas de réaction, pas de commentaire, pas de bavardage au téléphone. Restez face à face si vous le pouvez.

Cela permet à l'autre personne de se sentir respectée et vous facilitera la vie .

2. Réfléchissez un peu.

Essayez de comprendre chaque mot qu'ils prononcent. Croyez-moi, plusieurs fois j'ai pensé avoir pleinement compris une idée, mais plus tard, les choses se sont avérées différemment.

Prenez une grande respiration, donnez-vous un peu de temps pour traiter ce qu'ils disent. Passez ensuite à l'étape suivante.

3. Répétez leurs idées dans vos propres mots.

Expliquez leurs problèmes d'une manière que vous puissiez tous les deux comprendre. S'il y a trop de points, essayez de faire une note rapide et de les citer, point par point. S'il y a des informations peu claires, laissez-les clarifier. Par exemple:

• Si je comprends bien, vous voulez dire que le bouton doit être dans le coin supérieur gauche de l'écran?
• Vous voulez dire que notre programme est nettement plus lent avec une certaine entrée. Ne parlons pas encore de l'algorithme. Quel type d'entrée provoque le retard? Pouvez-vous me donner un exemple?
• Vous pensez donc que ce problème doit être résolu aujourd'hui avant la sortie. Est-ce correct?

Notez que les étapes 1 => 3 consistent à comprendre l'opinion de l'autre personne . Vous n'avez aucune contribution ici, sauf peut-être donner quelques exemples pour clarifier leurs problèmes.

Cela peut sembler beaucoup, mais l'étape 1 => 3 souvent ne prend pas plus de 2 minutes .

4. Faites un suivi avec une réponse / clarification

Maintenant que vous avez toutes les informations de leur côté, vous pouvez parfaitement former votre réponse. Exemple:

• Je pensais que le bouton avait été déplacé en haut à droite de l'écran suite à une demande de modification récente, mais je me trompe peut-être. Laissez-moi vérifier et je vous reviendrai plus tard.
• Le programme est donc nettement plus lent si l’entrée est un nombre négatif. Hum ... intéressant. Je crois que j'ai une idée de l'endroit où se situe le problème, cela ne concerne peut-être pas notre algorithme. Laissez-moi faire une vérification rapide et je vais vous mettre à jour.
• De notre dernière réunion, je me suis souvenu que cette fonctionnalité n'est pas nécessaire avant la prochaine version. J'ai confiance en cela. Si vous êtes toujours inquiet, nous pouvons revérifier la note de réunion pour en être sûr.

Situation B. Pour éviter d'être interrompu lorsque vous êtes "dans le flux".

Collègue X : Hé, je pense que vous devriez vous pencher sur ce bug T4235. Je crois que c'est dans la fonction de recherche et c'est juste une solution rapide. Pouvez-vous m'aider?

Moi : OK. Pouvez-vous attendre un peu? Je suis en train de développer les fonctions du T100 dont nous avons besoin pour livrer ce sprint. Je vous rejoindrai avant le déjeuner et nous pourrons discuter.

ou

Moi : Donnez-moi 15 minutes. Je suis au milieu du T100. J'examinerai cela après cela.

Le meilleur cas est: ÿvous pouvez définir une fenêtre de temps fixe pour la communication . Cela peut être avant l'heure du déjeuner, à la fin de la journée ou juste après une réunion hebdomadaire. Si des personnes viennent vous voir avec un problème non urgent, demandez-leur de rassembler toutes leurs questions et de revenir sur votre fenêtre de temps. À long terme, ce sera un gain de temps pour vous deux: vous pouvez continuer votre flux et ils obtiennent le meilleur soutien lorsque vous êtes le plus préparé à le faire.

(trop long pour un commentaire ...)

@JeremyFrench fait une bonne suggestion sur un chef de projet, mais je ne pense pas qu'il va assez loin.

Dans la plupart des environnements - c'est-à-dire quelle que soit la méthodologie de développement logiciel utilisée - ce n'est pas au contrôle qualité de déterminer si un problème est urgent ou non. (Ce n'est pas non plus aux développeurs.) Cette responsabilité incombe au chef de projet, au chef de produit, etc. (après tout, nous parlons d'ajouter du travail au calendrier.) Et le chef de projet / chef de produit devrait avoir des difficultés (coût) en compte lors de la priorisation des éléments de travail.

Cela étant dit, dans des environnements où les rôles, l'autorité et la responsabilité ne sont pas aussi bien définis qu'ils devraient l'être, d'après mon expérience, ce n'est pas rare pour le CQ / AQ le personnel pour hiérarchiser les corrections de bogues (même si elles ne sont pas nouvelles), inventer de nouvelles exigences, réécrire celles existantes, etc. - que vous utilisiez ou non un outil de suivi des problèmes.

Par conséquent, ma suggestion serait, à mesure que chacun de ces bogues est découvert:

• Dites à votre collègue que vous allez l'examiner et proposez-lui de signaler le problème au chef de projet / propriétaire du produit lorsque vous aurez terminé votre recherche . (Autrement dit, proposez de travailler avec eux plutôt que de prendre une position défensive.)

• Effectuez des recherches minimales sur le coût potentiel. Par «minimal», je veux dire documenter le problème dans la mesure où vous le pouvez sans compromettre vos engagements planifiés existants (je suggère pas plus de 15 minutes). Incluez dans le coût le nombre de fonctionnalités qui devront être retestées.

• Selon que vous pouvez facilement déterminer le coût, vous pouvez dire l'une des choses suivantes lorsque vous approche de la gestion de projet / produit (ou lorsqu'ils vous approchent):

• "Le contrôle qualité a trouvé ce bogue; ma meilleure supposition est qu'il faudra environ une semaine pour le corriger, et nous ' Vous devrez ensuite tester à nouveau tous les rapports. "

• "Le contrôle qualité a trouvé ce bogue; j'ai passé quelques minutes à l'examiner et je n'ai vraiment pas une bonne idée de ce qui le cause, il me faudrait au moins un jour ou deux pour le rechercher."

Dans les deux cas, vous autorisez la direction à prendre la décision concernant la priorité. (Si votre collègue insiste sur le fait qu'il s'agit d'un élément hautement prioritaire et que vous n'êtes pas d'accord, vous pouvez l'inclure dans votre déclaration à la direction: "X semble penser que cela doit être corrigé immédiatement. Je ne suis pas sûr d'être d'accord, car telle ou telle solution de contournement existe, et l'effort impliqué va probablement repousser la prochaine version ".

Si votre collègue a des suggestions quant à la cause du problème:

• S'ils font des suggestions avant que vous ayez eu l'occasion de l'examiner, dites que vous n'avez pas la possibilité d'enquêter mais que vous prendrez leur suggestion en délibéré. ​​
• S'ils font des suggestions après vous avez eu l'occasion de l'examiner, dites que vous êtes confiant dans votre évaluation du problème.

Si votre collègue fait des suggestions sur la façon de résoudre le problème :

• Si vous n'avez pas eu l'occasion d'enquêter, dites que la nature précise du problème n'a pas été déterminée.

• Si vous avez enquêté, dites que vous êtes con fident dans votre solution proposée.

Soyez poli mais ferme.

Mise à jour / clarification:
Si nouveau le code ne répond pas aux exigences, c'est presque toujours un problème hautement prioritaire. Je suppose que ces bogues ne sont pas de cette variété, mais plutôt:

• bogues existants;

• scénarios (éventuellement cas de bord) dont la conception du nouveau code ne tient pas compte;

• etc.

Je suis ne pas dire que ces types de problèmes sont automatiquement de faible priorité - seulement que les décisions concernant leur priorité ne devraient pas être prises par les développeurs et / ou les testeurs.

Réponse courte : vous devez trouver une expression telle que "[Nom,] Je comprends ce problème. J'apprécie votre idée concernant [hypothèse]. Vous me l'avez expliqué. Maintenant, c'est à mon tour de reprendre cette tâche. "

Réponse longue : à la lecture de votre question, il est vraiment difficile de savoir à quoi ressemble la personne avec laquelle vous travaillez. Je rencontre régulièrement des gens qui ne savent tout simplement pas comment travailler avec des programmeurs; et beaucoup de réponses dans ce fil ne comprennent pas non plus votre problème.

Il semble que vous travaillez avec un type de personnalité qui ne comprend pas quand arrêter de proposer des idées et vous permet de suivre votre rôle particulier. Ces personnes manquent souvent les signaux de conversation polis pour arrêter, et répéteront la même idée plusieurs fois, même s'il n'est pas approprié de le faire.

D'après mon expérience, ce genre de choses se produit lorsque la direction est immature ou absente . Dans un tel cas, votre responsable devrait être en mesure de vous aider; même s'il ne s'agit que de vous accompagner sur votre collègue. En réalité, votre manager doit expliquer à votre collègue qu'il doit vous faire confiance dans votre rôle. Votre responsable doit expliquer qu'il doit faire valoir son point une fois, puis revenir à son rôle dans l'équipe.

Si votre responsable ne peut pas ou ne veut pas vous aider, je vous conseille de consacrer 20 à 30 minutes en tête-à-tête avec votre collègue. Expliquez que vous êtes un ingénieur logiciel professionnel et que vous appréciez leur contribution. Ensuite, déclarez fermement qu'ils doivent faire valoir leur point une fois et avoir confiance que vous pouvez assumer votre rôle. Expliquez que votre rôle est de diagnostiquer et de résoudre ces problèmes.

Peut-être donner un exemple où votre collègue a continué à développer une idée ou une hypothèse. Expliquez quand il serait approprié pour votre collègue de mettre fin à ses réflexions et de vous laisser assumer vos responsabilités.

La prochaine fois que votre collègue continuera à insister sur une idée, dites quelque chose de similaire à la phrase suggérée ci-dessus. Si cela ne fonctionne pas, impliquez à nouveau la direction. Si votre responsable direct ne vous aide pas, il est temps de passer au-dessus de votre responsable.

Il est important de savoir que ce sont des situations qui mènent à des hausses de voix et à une perte de sang.

[Modifier ] Il est également important de comprendre que ce type de personnalité a souvent blessé des sentiments lorsqu'ils ne sont pas autorisés à continuer à répéter leurs idées. Ce n'est pas votre problème. Ils doivent acquérir la maturité nécessaire pour collaborer et faire confiance, et cela implique notamment de savoir quand faire valoir leur point de vue et passer à autre chose. Il n'est pas raisonnable pour eux de se faire insulter personnellement dans ce genre de situation.

Il semble que la plupart des problèmes pour vous proviennent de l'interruption de votre flux de travail. Il semble également que votre collègue s'attend à plus de communication que vous n'en donnez actuellement. Dans cette optique, vous pouvez trouver un moyen de faire appel à votre collègue pour vous aider à trouver une solution.

Workflow

Trouvez un workflow qui fonctionne pour vous et demandez-leur de le respecter . Établissez des directives et demandez-leur de vous aider à être productif au maximum. Exprimez cela comme un problème que vous avez, pour lequel ils peuvent vous aider, afin qu'ils puissent obtenir ce dont ils ont besoin.

Cette approche évite le blâme ou l'offense, et donne à votre collègue le contrôle pour vous aider à répondre à son / ses besoins --- ce qu'ils veulent vraiment, après tout.

Par exemple, vous pouvez mettre en place des directives sur la façon de signaler un bogue et à quelle fréquence vérifier les progrès. (Remarque: si vous pouviez donner une estimation pour un correctif donné de manière proactive --- avant que votre collègue envoie un rappel --- vous n'aurez peut-être même pas à demander explicitement à votre collègue de changer.)

Peut-être vous pouvez remplacer les e-mails de "mise à jour de l'état" par une réunion de 10 minutes une fois par jour.

Communication

Votre équipe dispose-t-elle d'un bon produit de suivi des problèmes (par exemple, quelque chose comme Jira ou Microsoft Planner)? Si vous pouvez facilement publier (1) ce sur quoi vous travaillez actuellement et (2) la façon dont vous avez hiérarchisé les choses, cela pourrait aider beaucoup. ¹ Il faut 3 à 5 minutes pour mettre à jour un demande de bogue, et se produit lorsque vous êtes prêt à changer de tâche.

Il semble que votre collègue essaie de remplacer un tel outil par un système de sondage par e-mail. Comme je l'ai mentionné, si vous ne pouvez pas utiliser un outil, vous pourriez au moins être en mesure d'avoir une réunion de 5 à 10 minutes de temps en temps (même une fois par jour), pour vous synchroniser sur les priorités.

¹ Mieux encore, demandez-leur ce qu'il est important pour eux de savoir. Même si vous avez déjà une idée, cela encourage un sentiment mutuel de partenariat et de travail d'équipe.

À propos de la priorité

Il est important de comprendre que l'attribution de priorités est une activité commerciale, pas une activité technique, même si les détails peuvent tous être techniques. Par conséquent, un utilisateur technique et un utilisateur non technique devraient être en mesure de s'entendre sur les priorités, à condition qu'ils soient tous les deux conscients des besoins de l'entreprise et soient capables de communiquer efficacement en fonction de ces besoins.

De plus , tout désaccord sur les priorités revient à un malentendu ou à une mauvaise communication sur la manière dont les objectifs commerciaux sont altérés (en cas de bogue), et n'a rien à voir avec le codage. ²

Pour éviter les malentendus, assurez-vous de discuter des priorités en termes de fonctionnalité métier affectée, plutôt qu'en termes techniques. Cela met votre collègue et vous-même sur un pied d'égalité et leur donne un soulagement des parties techniques.

De plus, cela fournit un mécanisme pour faire appel à un tiers, chaque fois que vous ne pouvez pas être d'accord. Si vous définissez le problème en termes de priorités commerciales concurrentes, vous pouvez désigner la véritable partie prenante --- ou peut-être votre chef de projet ou votre patron --- et dire: "Si vous voulez donner la priorité à X (fonction commerciale) plutôt qu'à Y ( fonction commerciale), veuillez en parler à untel. "

² Cela suppose que vous et votre collègue êtes réellement conscients des priorités commerciales et que vous êtes compétent dans vos jobs.

Essayer de faire votre travail / Tenez votre main

Je vous recommanderais de choisir le problème le plus important à résoudre. Si votre collègue essaie d'expliquer ce qu'il faut faire, mais pas d'une manière qui affecte votre flux de travail, je dirais, vivez avec, du moins pour le moment. Cela peut signifier que votre réunion de 10 minutes prend à la place 20 minutes, mais si vous pouvez dire: "D'accord, mais parlez-moi pendant la réunion, s'il vous plaît", cela limite au moins les dommages à votre efficacité.

Pousser back pourrait quelque peu contrarier votre collègue et vous empêcher de "l'enrôler" pour résoudre les problèmes les plus importants.

Je suppose que le problème du flux de travail est plus important pour vous, même s'il est (peut-être) un peu moins important. Je n'ai pas non plus de conseils solides sur cette partie.

J'ai tendance à être un peu intense dans certaines conversations concernant des opinions divergentes sur des choses; un exemple pour moi était les commentaires. Bien que je me connecte assez bien avec la plupart des gens, je rencontre des personnes avec un trait de personnalité similaire mais l'opinion contraire.

Lorsque cela se produit, j'essaie d'abord de pivoter dans la personne après avoir eu la friction; en augmentant l'interaction et en leur apportant plus choses pour essayer de trouver comment mieux travailler avec eux. Souvent, cela ne fonctionne pas.

Ce que je fais alors est de minimiser passivement les désaccords et de ne soulever que les problèmes ou besoins critiques avec eux. Cela réduit «l'inflammation» si vous voulez y penser de cette façon; ce qui signifie que les flambées sont moins probables. Cela aide aussi parce que lorsque je veux leur parler d'un problème, c'est parce que j'ai vraiment besoin de leur opinion; et être authentique est toujours bon.

Je vois que cela peut sembler ne pas être une réponse; mais en gros, je dis " arrête de lui dire des choses qu'il n'a pas besoin de savoir " ou " arrête d'essayer de discuter ou de résoudre des problèmes avec lui à moins que tu ne penses qu'il sera utile . "

Tout cela dit, j'ai tendance à être quelqu'un qui utilise les gens comme caisse de résonance et recherche des idées non informées ou non conventionnelles parce que cela me donne une approche différente du problème; il se peut donc que vous souhaitiez simplement commencer à l'écouter lorsqu'il a une idée peu conventionnelle ou improbable.

D'autres ont abordé les interruptions et le changement de contexte, et il y a quelques bonnes réponses à ce sujet. Je vais m'adresser au testeur qui essaie de corriger le code.

Il semble que votre testeur aimerait apprendre à programmer, aime résoudre des énigmes et recherche des commentaires ( et l'apprentissage), sans avoir la moindre idée de ce que c'est que de programmer professionnellement. Alors montrez-leur.

En guise d'avertissement, chaque fois que je faisais cela, ce n'était pas la journée la plus productive en termes de correction de bugs, mais cela a toujours porté ses fruits à long terme.

Ce que vous voulez, c'est prendre l'un des bogues (de préférence un sur lequel le testeur s'est trompé) et montrer au testeur ce que vous devez faire pour résoudre le problème. Cela fonctionne mieux si vous pouvez faire des choses que le testeur ne peut pas faire, comme utiliser le débogueur ou consulter la base de données.

Invitez la personne à venir à votre bureau et parlez du problème. Ensuite, expliquez ce que vous faites lorsque vous commencez à résoudre ce problème.

Disons que j'ai un système à trois niveaux. Navigateur, serveur, base de données. Disons que j'ai un bogue qui implique de remplir un formulaire, de le publier, puis de le relire, et les données n'apparaissent pas lors de la relecture.

La première chose que je ferais est de dupliquer le problème. La deuxième chose que je ferais est de voir à quoi ressemble la base de données. À ce stade, je sais si le problème est d'écrire dans la base de données ou de lire à partir de celle-ci. La troisième chose que je ferais est de sauter au milieu du serveur avec un débogueur, pour voir à quoi ressemblent les données. Ensuite, je regarderais les données telles qu'elles sont envoyées à la base de données ou au navigateur. Et ainsi de suite. Je me limite au point où les données ont été corrompues.

Le point est le suivant. Ce que je ne fais pas , c’est d’abord spéculer sur "quel" le problème, car cela peut me tromper. J'utilise d'abord mes outils pour découvrir "où" le problème est survenu, généralement en examinant les données à mi-chemin entre l'état bon et mauvais connu (et à un endroit où je peux l'examiner efficacement), et en répétant jusqu'à ce que j'aie réduit le problème à un petit morceau de code. Une fois que je sais "où" , je peux mettre des points d'arrêt dans la zone et parcourir et découvrir "quoi" . En faisant cela, je peux même trouver d'autres bogues potentiels dans ce morceau de code que je peux corriger en même temps, ainsi que découvrir ce qui doit être retesté.

Si vous lancez des fléchettes sur une cible dans l'obscurité, il est plus facile d'allumer les lumières que de deviner où se trouve la cible et d'espérer que vous avez atteint la cible.

Ensuite, encouragez votre testeur à parler à son responsable de devenir programmeur. Nous avons besoin de plus de bons programmeurs dans ce monde.

Si vous êtes en mesure de le faire, essayez cette expérience (et mettez-la par écrit pour avoir une trace de courrier):

Chaque fois qu'ils insistent, vous laissez tomber tout ce que vous faites et faites ce qu'ils voulez que vous fassiez, faites exactement cela et comparez les résultats dans une semaine ou deux avec votre schéma de travail normal. Ensuite, asseyez-vous avec eux et discutez des avantages et des inconvénients des deux approches, avec des statistiques réelles sur la quantité de travail que vous pouvez faire et sur la satisfaction de la direction avec les résultats de chaque approche.

Il y a toujours une chance que cela en résulte Ce n'est peut-être pas si grave, mais au cas où cela se passerait comme prévu, vous les ferez probablement arrêter de vous déranger aussi souvent que maintenant.

L'interface directe avec le contrôle qualité doit être à votre discrétion, et non l'inverse. Vous ne pouvez pas vous permettre des interruptions. Cela doit être clairement indiqué au QA par le responsable du projet en supposant qu'il correspond à la culture de votre entreprise. Sinon, vous devrez peut-être essayer de changer la culture d'entreprise.

Isolez-vous avec un meilleur flux de travail. Je recommanderais de consulter de bonnes bases de données de suivi des bogues si vous n'en avez pas déjà une. Parlez au chef de projet et expliquez en quoi ces interruptions ralentissent considérablement votre progression et causent du stress. Si possible, séparez le contrôle qualité dans une autre zone du bâtiment.

D'après mon expérience en contrôle qualité pour une société de jeux vidéo, mon travail consistait à trouver, répliquer, détailler et classer les bogues dans le bug tracker. Le rôle des programmeurs était de résoudre ces problèmes. Le chef de projet (producteur, dans ce cas) a poussé les programmeurs quand ils avaient des bogues critiques laissés ouverts. En tant que QA, je pouvais contacter le chef de projet si je pensais que quelque chose était urgent. Je ne dérangerais pas directement les programmeurs, mais ils venaient souvent me parler.

Vous êtes dans la même équipe. Comme certaines des autres réponses l'ont noté, un excellent contrôle qualité rend votre travail beaucoup plus facile. J'irais jusqu'à suggérer de faire un point pour aller plus loin et leur parler à votre convenance pour voir à quoi ressemble l'ambiance car tout ne ressort pas clairement dans le texte.

Ma réponse va être différente de la plupart des réponses ici.

La plupart des autres réponses se concentrent sur ce que votre collègue devrait ou ne devrait pas être

Je vais plutôt suggérer ce que vous pouvez faire.

Tout d'abord, regardez les points positifs. C'est un collègue compétent qui souhaite véritablement collaborer et vous aider à faire votre travail. Vous ne mentionnez rien pour suggérer qu'ils essaient délibérément de vous gêner. Ils ne le font que parce qu'ils ne comprennent pas comment être le plus efficace pour vous aider.

C'est là que vous intervenez. Il est temps d'avoir une conversation honnête, franche et objective avec eux à ce sujet . Facile, non?

En fait, ce n'est pas le cas. C'est pourquoi il existe de nombreuses ressources pour vous aider à atteindre cet objectif. En voici quelques exemples:

1. Conversations cruciales (livre)

J'ai lu ce livre et je trouve son cadre utile pour avoir des discussions productives avec les membres de l'équipe: https://www.goodreads.com/book/show/15014.Crucial_Conversations

2. Langage propre (technique)

J'en sais moins à ce sujet et je ne peux donc pas fournir de ressources concrètes. C'était un sujet populaire lors d'une récente conférence à laquelle j'ai assisté: https://en.wikipedia.org/wiki/Clean_Language

TLDR: Collaboration est difficile. Heureusement, vous n'êtes pas la première personne à relever ce défi. Il existe des ressources pour vous aider. Essayez également de googler les «techniques de conflit productif» ou les «cadres de résolution de conflit». Évitez simplement les articles superficiels et trouvez quelque chose de substantiel (comme un cours ou un livre) qui vous donne des outils concrets.

J'espère que cela vous aidera!

Tu ne peux pas essayer d'en faire une blague?

"J'ai entendu un testeur dire qu'une fois à un développeur, ils l'ont trouvé des années plus tard alors que la 4ème bosse sur l'autoroute"

"vous devez vraiment aimer mon bas salaire si vous êtes essayant toujours de faire mon travail "

" whoa là, nous n'avons même pas encore atteint ce niveau "

faites des commentaires amusants pendant que vous prenez un café dites quelque chose comme" est-ce que vous prends du sucre "puis" non attends je demanderai à Tony il te dira comment tu veux ton café "

Je sais que ce n'est peut-être pas ton style d'être" ma marque incroyable de drôles " , et ce n'est pas drôle à moins que vous ne rigoliez tous les deux en le disant ... mais faites-le rire et ça ne le dérangera pas, je vous assure. .. si vous ne savez pas comment dire ça

"J'aurais aimé connaître une blague alors je vous le dirais pour que je n'ai pas à vous frapper dans les couilles"

il est probablement conducteur de siège arrière dans d'autres parties de sa vie. la plupart des gens se moqueront de trucs comme ça s'ils savent au fond que vous les aimez