Comment gérer les collègues qui ne souhaitent pas rédiger un rapport de bogue?

gnasher729

2018-08-14 13:14:14 UTC

view on stackexchange narkive permalink

Dites-lui comme c'est le cas: elle n'a pas signalé le bogue, donc le bogue n'existe pas. Elle vient de perdre dix minutes de son temps et de votre temps à vous plaindre du virus. Et demain, vous lui envoyez un e-mail de rappel. Que vous pensez qu'elle a eu des problèmes, mais qu'il n'y a pas de rapport de bogue dans le système de billetterie, elle doit donc ajouter ceci. Envoyez-lui les rappels par e-mail pendant au moins une semaine.

Dites-lui aussi qu'il est totalement inacceptable de se plaindre des bugs. Il y aura toujours des bugs, c'est une réalité de la vie où le logiciel est développé, et faire une diatribe à ce sujet ne peut que déranger les gens (cela ne me dérangerait pas, car je l'interpréterais comme étant stupide, pas comme un mauvais se passe qui ne devrait pas être là).

Et la prochaine fois qu'elle commence à se déchaîner sur le problème suivant, vous l'avez interrompue au bout de cinq secondes. Vous lui dites que son travail est de mettre la description du bogue dans le système de billetterie, que vous n'accepterez aucun rapport de bogue dans la conversation et que vous n'acceptez certainement pas ses élucubrations. Ensuite, vous vous éloignez, ou si c'est votre bureau, vous lui dites de partir.

Bien que ce soit généralement un bon conseil, vous voulez donner le ton sans les faire passer pour des enfants ou avoir un manoir condescendant.Vous voulez qu'ils travaillent avec vous et jouent à votre jeu, alors agissez en conséquence.

D'accord avec lix.Ce sont des collègues, pas des subordonnés.En fait, l'une des personnes à problèmes est le patron du PO.Prendre ce ton avec votre patron serait un GRAND non-non.

Je voudrais ajouter une perspective différente.À l'hôpital où je travaille en tant que médecin, nous avons été convoqués pour tester un nouveau système de dossier électronique des patients.Cela n'a pas très bien fonctionné.Les développeurs nous ont demandé de nous adapter à leurs besoins, au lieu de l'inverse (nous sentions que nous leur rendions service, alors qu'ils nous faisaient sentir que nous devrions être heureux de les aider).Cela a provoqué de la rancune envers les développeurs.Si vous voulez vraiment que le bogue soit classé, facilitez-le ou faites-le vous-même si cela vous fait gagner du temps.

Cela ne m'a pas fait voter: "Envoyez-lui les rappels par e-mail pendant au moins une semaine".Je suggère "envoyer un rappel après quelques jours".Vous n'êtes pas son maître.Vous avez la preuve que vous avez essayé.c'est sa responsabilité maintenant.Ceci est en accord avec li x et David K

Cela ressemble à une recette pour établir une mauvaise relation de travail et à un moyen de s'assurer que cet utilisateur évite d'utiliser votre application autant que possible.

Ce sont des conseils assez désastreux.Cela entraînera du ressentiment et les collègues utiliseront une telle attitude comme un exemple des raisons pour lesquelles il est difficile de travailler avec des développeurs.

Gardez à l'esprit avec ce conseil qu'OP a indiqué que son * patron * faisait partie de ces personnes.Traiter son patron de cette façon est un excellent moyen de se faire virer.

Une partie de cette réponse concerne la formation de vos collègues à utiliser les systèmes en place spécifiquement pour la tâche de gestion des bogues.S'ils ne l'utilisent pas, c'est un gaspillage d'argent de l'entreprise, en plus, c'est une autre perte d'argent et de temps d'avoir à écouter une diatribe de 10 minutes qui pourrait être une lecture de 3 minutes, et sans la politique personnelle ni blessersentiments.Les bogues sont une réalité de la vie, et à moins qu'ils ne soient extrêmement critiques, ils doivent être des adresses comme un autre fait, des adresses plus tard, lorsque le temps et le budget le permettent.

Personne ne devrait crier après quelqu'un d'autre dans une situation comme celle-ci.Ranting va perdre du temps et causer beaucoup de rancune.Quand j'étais submergé de travail et qu'on ne me donnait pas de priorités, les gens qui étaient gentils avec moi avaient la priorité, et les problèmes pour lesquels je me plaignais étaient laissés pour plus tard.

"Prendre ce ton avec votre patron serait un GRAND non-non" plaisantez-vous.Moi connu pour faire ça et pire.Recherchez Dan Pena pour une attitude plus alpha / performante.

* «Elle n'a pas signalé le bogue, donc le bogue n'existe pas.» * Le bogue existait.Ne laissez pas les processus entraver l’amélioration du logiciel. * «Ensuite, vous vous éloignez, ou si c'est votre bureau, vous lui dites de vous en aller.» * Ne mettez pas d'obstacles sur le chemin des personnes qui communiquent avec vous.Un système de suivi des bogues est là pour aider l'équipe à hiérarchiser et suivre le travail.Ce n'est pas un outil de communication.

@Martijn _ "c'est sa responsabilité maintenant" _ Bien que je vois ce que vous voulez en venir et que je sois d'accord dans une certaine mesure, le fait est que ce projet relève de la responsabilité du PO, donc ce n'est pas vraiment clair.L'OP doit encore résoudre le problème;ils ne peuvent pas simplement prétendre qu'il n'existe pas parce qu'il n'a pas été signalé de manière souhaitable.

@BenMz Il y a un équilibre difficile à trouver lorsque les gens communiquent avec vous non seulement de manière inappropriée, mais aussi de manière inefficace.Je ne sais pas où se trouve le juste milieu, mais il y en a certainement un, et trouver un moyen (avertissement: je n'ai aucune idée de ce que ce serait dans cette situation!) Pour permettre au collègue de communiquer sans se plier à son besoin apparent dele faire de la «mauvaise» manière serait approprié D'après mon expérience, ce type de politique et d'ingénierie sociale peut, malheureusement, être parfois la moitié du travail d'un développeur de logiciel :(

@JoeStrazzere, oui, la boutade "... donc ça n'existe pas" est ce qui rend les gens furieux et vindicatifs envers les développeurs.

@BenMz: "" Elle n'a pas signalé le bogue, donc le bogue n'existe pas. "Le bogue existait. "- Je suis d'accord que ça va un peu trop loin."Elle n'a pas signalé le bogue, donc le bogue n'a jamais été entré dans la file d'attente des choses sur lesquelles travailler. Par conséquent, on ne peut pas s'attendre à ce qu'il soit corrigé."est plus précis à mon humble avis.(Notez que cela ne signifie pas que le développeur ne pouvait pas simplement déposer le rapport de bogue en son nom, sur la base de la diatribe.) Cependant, je ne suis pas d'accord avec votre affirmation selon laquelle "Un système de suivi des bogues [n'est] pas un outil de communication. "- oui, c'est exactement ce que c'est.Quoi d'autre cela pourrait-il être?

Les systèmes de suivi des bogues @O.R.Mapper sont des outils de suivi du travail.La plupart des fonctionnalités sont à cet effet.Vous pouvez les utiliser comme pour communiquer, mais le rapport signal sur bruit est terrible.

@BenMz: "travail de suivi" * est * la communication.Transmettre aux développeurs (par exemple) ce qui doit être fait.Renvoyer (par exemple) aux chefs de produit ce qui a déjà été fait.Indiquant un certain contexte de manière partiellement normalisée.Etc.Tout cela fait partie du processus de communication.

Elmy

2018-08-14 13:53:41 UTC

view on stackexchange narkive permalink

En plus de "leur dire que vous ne pouvez pas corriger les bogues qui ne sont pas signalés" (comme indiqué dans les réponses récentes), vous devez faire signaler un bogue aussi facilement que possible . La plupart des non-informaticiens se sentent intimidés par la perspective de devoir utiliser le système de tickets et pensent que c'est beaucoup trop compliqué pour quelque chose qu'ils peuvent simplement dire à quelqu'un .

Si un collègue se met à déclamer , montrez-leur le système de tickets (où le trouver) et classez le bogue ensemble pour leur montrer comment le faire. Si possible, créez un modèle avec les informations les plus importantes dont vous avez besoin:

Nom de l'application (vous ne croirez pas combien de personnes l'oublient)
Qu'ont-ils veulent faire
Sur quoi / où ont-ils cliqué
Que s'est-il passé au lieu du comportement souhaité (le bug réel)
Ajoutez une capture d'écran si possible
Nom du rapporteur de bogue à rappeler

De plus, encouragez vos collègues à signaler les bogues fort>. Expliquez-leur clairement que signaler un bogue est une bonne chose, est utile et a un résultat positif. Certains pourraient avoir envie de vous trahir en révélant les «erreurs» que vous avez faites.

La femme qui m'insultait utilise quotidiennement le système de billetterie.

@user1261710 Alors elle n'a vraiment aucune raison de se plaindre ... Toutes les autres réponses s'appliquent toujours

@user1261710 Ce n'est pas parce que quelqu'un utilise quelque chose qu'il aime l'utiliser.En tant que développeur de plus de 20 ans, je déteste toujours les bogues de journalisation.La plupart des systèmes de billetterie sont peu maniables, n'utilisent pas de champs par défaut qui devraient avoir des valeurs par défaut évidentes, ont beaucoup trop de champs obligatoires et finissent par nécessiter 4x plus de temps pour signaler un bogue que de le faire en personne.Je le fais toujours, car je comprends le besoin, mais je comprends aussi parfaitement pourquoi les non-développeurs ne le voudraient pas.Alors concentrez-vous sur les parties de cette réponse qui vous encouragent à vous faciliter la tâche et à en communiquer les avantages.

J'avais l'habitude de travailler dans une entreprise où notre système avait de fréquents bogues tels que j'en rencontrais de nouveaux plusieurs fois par semaine, parfois plusieurs fois par jour.Je comprends l'importance de les signaler, alors je le ferais.Cependant, le format de rapport était si long qu'il m'a fallu environ 15 minutes pour le remplir.Je perdrais 1 à 3 heures par semaine à remplir des rapports de bogues.YElm a tout à fait raison de dire que signaler le bogue doit être aussi simple que possible, sinon c'est juste une douleur.

@user1261710 Ils utilisent quotidiennement le système de tickets pour traiter les tickets ou les classer?

Notre système est plutôt bon.Pas de bugs.C'est un studio visuel en ligne.Il y a quelques champs à remplir mais cela ne prend pas 15 minutes.Peut-être 5 ou moins.

@user1261710 Vous n'avez pas besoin de justifier votre système de rapport de bogue.Il est bon d'entendre que votre système n'est pas trop compliqué et que vos collègues l'utilisent quotidiennement, mais cela peut ne pas être le cas pour d'autres personnes qui tombent sur votre question et pourraient trouver des informations utiles dans cette réponse.

@Nicholas: _ "Ce n'est pas parce que quelqu'un utilise quelque chose qu'il aime l'utiliser." _ Quoi qu'il en soit, cela montre que non seulement elle est capable de l'utiliser, mais qu'elle l'utilise réellement, il faut donc se demander pourquoi elle n'est _pas_en l'utilisant pour _ce_ projet particulier.Quelque chose ne va pas ici.

@LightnessRacesinOrbit Je vois votre point de vue, mais la raison pour laquelle ils l'utilisent pour d'autres tâches pourrait être parce qu'il n'y a pas de solution de contournement plus simple (comme ce qu'ils font dans ce cas), ou que ne pas l'utiliser pour ces tâches causera trop de problèmesrépercussions pour eux, ou un certain nombre d’autres raisons.Je ne dis pas que ce sont des raisons valables.Mais si la majorité des utilisateurs contournent ce processus, je pense que la résolution devient plus importante que le blâme, même si ces utilisateurs sont vraiment en faute.

@Nicholas: Exactement, donc si l'OP cesse d'être le chemin de la moindre résistance, les résultats s'amélioreront;) Mais oui, la résolution de toute cause fondamentale sous-jacente serait une solution plus large.

@user1261710 Différents rôles utilisent des systèmes de billetterie à des fins différentes.Les analystes métier définissent les exigences, les chefs de projet génèrent des rapports, les ingénieurs QA se concentrent sur les bugs et les cas de test, etc. L'utilisation d'un système n'implique pas la maîtrise ni même la maîtrise de tous ses aspects.

Si les gens savent comment utiliser un fb, ils savent également comment signaler un bogue.Être paresseux ou penser que vous avez le droit de revoir les procédures est quelque chose de différent.

knallfrosch

2018-08-14 18:52:00 UTC

view on stackexchange narkive permalink

Tiré de Joel Spolsky, co-fondateur et PDG de Stack Overflow; qui a écrit sur son blog:

Par exemple, supposons que personne dans votre équipe ne puisse être persuadé d'utiliser une base de données de bogues. Ne laissez pas cela vous déranger. Gardez le vôtre. Entrez les bogues que vous trouvez dans votre propre code. Si vous trouvez un bogue que quelqu'un d'autre devrait vraiment corriger, attribuez-lui le bogue en utilisant la base de données de bogues. Si vous avez un bon logiciel de suivi des bogues, cela leur enverra un e-mail. Mais maintenant, vous pouvez continuer à leur envoyer des e-mails s'ils ne résolvent pas le bogue. Finalement, ils verront la valeur du suivi des bogues et commenceront à utiliser le système comme prévu. Si l'équipe d'assurance qualité refuse de saisir les bogues dans le système de suivi des bogues, refusez simplement d'écouter les rapports de bogues via un autre canal . À peu près la trois mille fois que vous dites aux gens: «Écoutez, j'aimerais résoudre ce problème, mais je vais oublier. Pouvez-vous entrer un bogue dans le système? » ils commenceront à utiliser la base de données.

_{[Je souligne]}

Notez le message `écoutez, j'adorerais résoudre ce problème, mais je vais oublier.Pouvez-vous entrer un bogue dans le système? »- la politesse est l'élément clé de cette réponse.

D'accord.En tant que développeur, si ce n'est pas dans le système de suivi des bogues, je n'en sais rien.Donc, ça n'aidera personne si on me crie dessus pour quelque chose que je ne sais pas.Répondre en nature à quelqu'un comment crier ne va généralement pas les calmer, donc la politesse est généralement le bon traitement."Ok, je vois que c'est un problème. Pourquoi ne pas me guider à travers les étapes pour reproduire le problème et nous commencerons un ticket ..." Après 1 ou 2 fois, j'espère qu'ils auront l'idée de simplementcommencez un ticket et évitez vos 1000 questions "pour plus d'informations à mettre dans le ticket".: ->

La propre société de Spolsky a reconnu que demander aux gens de saisir des bogues dans le logiciel FogBUGZ qu’ils vendent est si onéreux qu’un système a été développé qui permet aux gens d’envoyer simplement un e-mail et qu’un bogue sera automatiquement créé.

Eh bien, si garder le temps en ayant le bogue dans le logiciel approprié est si crucial, quelqu'un devra utiliser ce système onéreux.Si OP commence à le faire lui-même, le problème ne disparaîtra pas.Mieux vaut ne pas récompenser les comportements indésirables comme se plaindre bruyamment au bureau des développeurs.

Le fait est que le PO ne parle pas du «département QA».Le PO parle de quelque chose de plus proche, dans le jargon de M. Spolsky, de "tests d'utilisabilité dans les couloirs".Est-il raisonnable de s'attendre à ce que des personnes non-QA remplissent des rapports de bogues turgides?Probablement pas à moins que cela ne fasse spécifiquement partie de leur travail.

C'est ce que je suis resté à faire à mon dernier poste permanent.J'ai installé Mantis sur un serveur interne et j'allais l'utiliser jusqu'à ce que tout le monde le fasse.Mais j'ai fini par quitter l'entreprise en premier.

@teego1967, pour citer [un autre article de Joel Spolsky] (https://www.joelonsoftware.com/2000/11/08/painless-bug-tracking/) avec mon gras ajouté: «Évitez la tentation d'ajouter de nouveaux champs à la base de données de bogues. ... Il est très important de ne pas céder à ces idées. Si vous le faites, votre nouvel écran de saisie de bogue se retrouvera avec un millier de champs que vous devrez renseigner, et personne ne voudra plus saisir de rapports de bogue. **Pour que la base de données de bogues fonctionne, tout le monde doit l'utiliser, ** et si entrer des bogues «formellement» est trop de travail, les gens vont * contourner * la base de données de bogues. "

@Wildcard, oui, c'est _exactement_ ce qui se passe dans de nombreux endroits.Avant que vous ne le sachiez, le formulaire devient un gâchis complètement inutilisable pour tout le monde sauf la personne qui l'a créé.

Joel peut donner ce conseil parce qu'il est le patron.Un seul développeur militant imposant son propre processus préféré à l'organisation ne se terminera pas bien.

Bien que ce ne soit pas un "suivi des bogues" en soi, nous avons un système de billetterie chez $ {EMPLOYER} dans lequel je dis aux gens d'entrer une demande, de documenter cette demande avant de pouvoir l'implémenter dans l'une des applications où je suis administrateur.C'est uniquement pour couvrir mes fesses, donc personne ne m'accuse d'être le Lone Ranger.Quelqu'un m'a littéralement demandé "pourquoi as-tu fait ça?"seulement pour moi de produire le numéro de billet où la même personne a demandé le changement.Imaginez être jeté sous le bus sans que quelque chose comme ça prouve que c'était la faute de l'accusateur depuis le début.

teego1967

2018-08-14 15:23:01 UTC

view on stackexchange narkive permalink

Les systèmes de suivi de bogues qui sont strictement interfacés pour les besoins des développeurs sont une chose à laquelle de nombreux non-développeurs ont une aversion. Ces outils de suivi de bogues utilisent généralement une forme unique massive "taille unique" avec beaucoup trop de listes déroulantes / champs / boutons radio non applicables ou non intelligibles. Ces choses sont décourageantes à remplir, et de plus, elles sont souvent sans réponse ou simplement fermées d'une manière qui semble capricieuse.

Si vous voulez résoudre le problème sans simplement forcer vos collègues à simplement se conformer, envisagez des moyens de rationaliser le système de rapport de bogue et de le rendre plus réactif. Cela peut être aussi simple que d'écrire une courte phrase à la personne qui a signalé le bogue (au lieu de simplement sélectionner un statut dans une liste déroulante). Collectez-vous automatiquement des éléments tels que le numéro de version ou faites-vous en sorte que les utilisateurs le trouvent? Les utilisateurs savent-ils comment prendre une capture d'écran sur leur téléphone (et l'obtenir sur le tracker)? Vous seriez surpris de voir combien de personnes ne le peuvent pas. Cela semble être des obstacles insignifiants, mais s'il faut des recherches pour «comprendre» comment remplir le rapport de bogue, BEAUCOUP de gens ne le feront tout simplement pas.

Vous pouvez également essayer de travailler avec un (des) utilisateur (s) «alpha» qui est prêt à être un intermédiaire pour le reste des utilisateurs. Demandez à cette personne de remplir les rapports de bogue au nom des autres. De cette façon, vous obtenez vos billets et les utilisateurs peuvent parler à un humain et les problèmes sont remarqués et résolus.

Et si vous êtes d'accord pour forcer vos collègues à se conformer?: P

@PoloHoleSet, beaucoup de gens sont d'accord avec ça.Cependant, cela utilise de la bonne volonté pour forcer les gens à faire des choses.N'attendez pas de faveurs ou de considération en retour si vous forcez trop les gens.Il sera préférable de trouver la cause racine et de résoudre ce problème plutôt que de prétendre que c'est tout leur problème et de rejeter les rapports de bogues qui ne sont pas dans le traqueur.

Blague à part, de la part de la personne blasée qui doit faire du support et corriger les bugs du côté des choses.

A voté pour le troisième paragraphe.Nous avons un tel utilisateur "alpha", et c'est merveilleux.

Peter

2018-08-14 17:58:56 UTC

view on stackexchange narkive permalink

Saisissez vous-même le rapport de bogue. Si vous pouvez extraire suffisamment d'informations de la conversation ou de l'e-mail pour que le bogue soit reproductible, tant mieux. Si ce n'est pas le cas, vous aurez au moins le bogue mal défini à lier avec d'autres occurrences à l'avenir.

Pourquoi est-ce que je dis cela? Votre tâche consiste à produire un logiciel avec le moins de bogues possible. Cela signifie que les rapports de bogues sont quelque chose que vous devriez désirer beaucoup. Si vous rendez le processus trop lourd, les seules personnes qui rapporteront des bogues seront celles dont le travail principal est de le faire, et votre produit en souffrira.

Votre opinion sur la difficulté d'utiliser le bogue tracker n'est pas pertinent: vous avez apparemment plus d'un utilisateur qui n'aime pas l'utiliser. Alors, acceptez gracieusement leur entrée, créez un bogue dans le tracker, et faites-en l'initiateur si possible. Si vous ne pouvez pas, notez que cela a été signalé par untel et continuez votre travail. Ou demandez à votre responsable QA d'appeler le journaliste et de saisir un bogue s'il est réel.

Le problème de votre collègue qui ne suit pas le processus n'est pas votre problème. C'est le problème du manager de votre collègue. Et puisque vous avez dit que même votre responsable ne suit pas toujours ce processus, concentrez-vous sur les moyens de faire votre travail.

Et si les gens font un problème au sujet de bogues auto-saisis, vous pouvez remplir un formulaire papier pendant qu'ils se déchaînent et leur demander de le signer une fois qu'ils ont fini de déclamer et de l'utiliser comme preuve du rapport.S'ils refusent de signer, dites-leur que vous ne pouvez pas corriger le bogue autrement.

Si OP entre dans le bogue pour ce collègue, cela l'encouragera, ainsi que tous les collègues, à toujours venir se plaindre plutôt que d'entrer dans le bogue eux-mêmes (ce qui est la façon officielle de faire les choses).

Ce n'est pas ainsi que cela fonctionne.Produire des logiciels avec peu de bugs n'est qu'UNE partie du travail d'un développeur.Avec votre raisonnement, "Je ne devrais pas prendre la peine de commenter le code ou de saisir de bons commentaires de commit. Tant que mon code n'a pas de bogues, tout est juste."Chacun a un rôle différent et il existe des procédures.Faire le travail des autres simplement parce qu'ils refusent de suivre les procédures est un moyen sûr de s'emmêler dans un autre désordre plus tard.Surtout quand vous n'avez pas bien compris le bogue et que demain la même personne reviendra en déclamant encore plus fort.

Je n'ai pas dit que vous ne devriez pas faire votre travail.J'ai dit qu'il ne fallait pas s'inquiéter de savoir si l'autre personne faisait son travail.Ce qui n'est pas votre travail est de gérer votre collègue ou d'appliquer les procédures de l'entreprise à vos pairs.

@Dragonel: Pas nécessairement.Un résultat très possible est que d'une part, le développeur finit par travailler plus efficacement, car les rapports de bogue auto-rédigés par le développeur disent "après avoir cliqué sur X dans le module Y, le message d'erreur Z apparaît", alors que le bogue rapporte le même problèmepar des collègues peu disposés à lire "la fonction X échoue".Et d'un autre côté, les collègues qui estiment que les rapports de bogue que le développeur écrit eux-mêmes manquent de précision (par exemple parce que le développeur manque de connaissances du domaine sur des cas d'utilisation représentatifs) ont soudainement une réelle motivation à écrire les rapports eux-mêmes.

@O.R.Mapper - Je suis d'accord que si le développeur et le collègue parlent rationnellement et se combinent pour entrer dans le bogue, cela peut être beaucoup plus facile à corriger - mais les encourager à venir et à déclamer chaque fois qu'ils trouvent un bogue peut gravement affecter la productivité des OP et peutne produisent pas d’informations utiles s’ils «décrient» au lieu de les «discuter».Les faire entrer dans un bogue, puis OP discuter de tout ce qui n'est pas clair est une pratique plus courante car cela économise du temps de discussion sur les bogues que OP connaît déjà ou peut comprendre instantanément.

Oui, et marquez le rapporteur / déposant de bogue comme eux.

Kilisi

2018-08-14 13:58:16 UTC

view on stackexchange narkive permalink

Envoyez-leur simplement un e-mail avec une demande polie pour signaler le bogue dans le système de billetterie et cochez votre manager. Si cela n'apparaît pas, faites un suivi avec votre responsable.

C'est le rôle du manager de s'assurer que le personnel utilise correctement les outils, c'est aussi son rôle de s'assurer que vous n'êtes pas personnellement confronté et déclamé par des personnes extérieures à leur équipe. Vous n'avez pas le pouvoir de l'appliquer et ce n'est pas votre travail d'essayer.

Je suis fondamentalement d'accord avec vous, mais OP a dit que même le gestionnaire ne veut parfois pas écrire un rapport de bogue, donc cela n'aidera probablement pas à long terme: /

Lorsque la direction elle-même ne suit pas les règles et aggrave l'environnement toxique, il est temps soit d'augmenter ou de peaufiner le CV.Probablement les deux.@dontbyteme

@dontbyteme: "le gestionnaire refuse parfois d'écrire un rapport de bogue" - aussi étrange que cela puisse paraître, une réticence totale à déposer des rapports de bogue par lui-même et un engagement total à appliquer un "ne modifiez pas le code à moins que vous ne disposiez d'un élément de suivi des problèmes"la politique peut très bien coexister dans la vie réelle.

mhoran_psprep

2018-08-14 15:47:37 UTC

view on stackexchange narkive permalink

Mon projet principal est une application mobile. J'ai la plupart de mes collègues sur le canal de test alpha et les clients n'ont pas accès à ce canal.

Jusqu'ici tout va bien.

Le problème est que quelques-uns de mes collègues et mon patron ne sont pas disposés à utiliser le système de billetterie pour signaler des bogues.

Peut-être pas aussi bon qu'il y paraissait.

La semaine dernière, ma collègue pensait avoir vu un bogue et m'énervait pendant 5 minutes et je lui ai dit d'écrire le bogue dans le système de tickets. Elle ne le ferait pas. Certains de mes collègues deviennent extrêmement émotifs lorsqu'ils voient un bogue et préfèrent se plaindre du bogue au lieu de le signaler.

En regardant maintenant la première citation, une question qui me vient à l'esprit est qui mettent vos collègues dans le canal de test alpha. Le but de leurs tests est de générer les rapports de bogue. Maintenant, il y aura des personnes qui ne pourront pas consacrer autant de temps qu'elles le pensaient aux tests, ou utiliseront si peu les fonctionnalités du produit qu'elles testeront à peine le programme, mais vous devez faire effectuer les tests par des personnes qui termineront le cycle. .

Les bogues doivent être signalés pour que je puisse mettre l'heure dans ma feuille de temps.

Non, ils ne le font pas. Les bogues doivent être signalés pour que la qualité du produit s'améliore. La feuille de temps est la façon dont vous enregistrez vos heures. Le système de rapport de bogues permet aux développeurs de savoir ce qui doit être corrigé. L'objectif des tests alpha est de s'assurer que la plupart des bogues ne parviennent pas aux clients.

L'entreprise doit s'assurer que les personnes affectées au test alpha, ou celles qui se portent volontaires, savent ce que c'est attendus d’eux. Ils doivent connaître les délais, les processus, le temps nécessaire et les types de rapports qu'ils doivent produire. Ils ont besoin de savoir s’ils sont censés tester tout ou partie de l’application, ils doivent savoir quoi faire s’ils testent la partie x et qu’ils n’ont aucun bogue à signaler.

Que faire si les procédures de feuille de temps de l'entreprise exigent que le ou les identifiants de bogue soient répertoriés?"J'ai passé 15 minutes à corriger le bogue 641. J'ai passé 30 minutes à corriger le bogue 832" et ainsi de suite.Similaire à la façon dont la plupart des feuilles de temps (programmeur) exigent que le nom ou le code du projet soit répertorié lorsqu'ils effectuent un travail de développement régulier.

s'il est important d'être payé, si le test alpha ne produit pas de rapports, comment le produit va-t-il s'améliorer?c'est pourquoi les participants doivent comprendre les attentes.

@mhoram_psprep: Être payé est important.Pour l'entreprise, faire les tests est plus important, mais pour l'individu, être payé est plus important.Les participants ont non seulement besoin de comprendre le processus, ils ont besoin d'une raison pour l'accepter.

C'est pourquoi j'ai inclus le dernier paragraphe.Le but des tests Alpha est d'améliorer le produit.S'ils ne comprennent pas qu'ils ne devraient pas participer ou qu'ils ont besoin de formation.

@alroc Si la feuille de temps attend des identifiants de bogue, alors rien ne l'empêche de créer un identifiant de ticket comme nécessaire pour le rapport, même si aucune discussion n'a lieu dans le ticket.

Bien que cela ne soit pas indiqué, les validations de code source peuvent également nécessiter un bogue #.Le dernier endroit où j'ai travaillé était comme ça, chaque commit devait inclure le numéro du projet ou du bogue contre lequel il était commis.Au début, cela semblait un peu draconien, mais cela a aidé à suivre les choses.Il se peut donc qu'il ne soit pas en mesure de corriger un bogue sans un rapport de bogue.

"Les bogues doivent être signalés pour que je puisse mettre le temps dans ma feuille de temps." "Non, ils ne le font pas." OP dit que c'est nécessaire, donc c'est nécessaire.

@industry7, Je pense que vous avez manqué le point.Les feuilles de temps ne sont pas la * raison * pour laquelle les bogues doivent être signalés.

@Wildcard "Les bogues doivent être signalés pour que la qualité du produit s'améliore."Afin d'améliorer le produit, le QA peut simplement se rendre au bureau du développeur et expliquer le problème en personne.Vous n'avez absolument PAS à faire de bogues dans un système de suivi pour les corriger.Vous dites essentiellement à OP de dire au patron d'OP: "La correction des bogues n'améliore pas notre produit. Le signalement des bogues dans le système de suivi améliore notre produit."

@industry7: Je ne comprends pas d'où vous tirez l'hypothèse que les bogues non notés seront corrigés plutôt qu'oubliés.

@o-r-mapper - Je ne sais pas d'où vient votre confusion.Pour être clair, tous les emplois ont des responsabilités, et si vous êtes incapable de vous souvenir de vos responsabilités professionnelles, vous serez probablement congédié.

enderland

2018-08-15 17:23:00 UTC

view on stackexchange narkive permalink

Le problème est que quelques-uns de mes collègues et mon patron ne sont pas disposés à utiliser le système de billetterie pour signaler des bogues.

Aucun de ceux-ci ne s'adresse à votre patron ne veut pas non plus faire cela.

Je recommanderais trois choses.

Premièrement, parlez à votre patron et comprenez pourquoi votre patron refuse d'utiliser la billetterie système. En fin de compte, quelque chose cloche ici. Vous devez remplir une feuille de temps avec précision, mais votre patron travaille activement contre votre capacité à le faire - votre patron le sait-il même?

Si vos collègues sont littéralement comme vous le dites "déclamant" pendant cinq ans minutes et votre patron s'en fiche, votre patron est nul. Personnellement, je soupçonne qu'il y a beaucoup plus dans cette histoire que ce que vous avez présenté ici, mais quoi qu'il en soit, vous devez en parler avec votre patron.

Même des questions comme: "Bob ne veut pas soumettre de rapports de bogue, comment voulez-vous que je surveille ce travail? " est significatif.

Deuxièmement, réfléchissez sérieusement au processus que vos collègues doivent suivre lorsqu'ils signalent un bogue. Il y a des équipes avec lesquelles je travaille et pour lesquelles j'ai renoncé à rédiger des rapports de bogue en raison de la frustration de ce processus.

J'ai plus ou moins délégué le "est-ce un bogue?" question à eux car j'ai eu beaucoup trop d'expériences négatives en travaillant avec eux - que ce soit en fermant le ticket comme "ne le fera pas" ou en changeant un rapport de bogue en une demande de fonctionnalité ou en me disputant si c'est un bogue, je n'ai que patience pour tant de choses avant que j'arrête de m'en soucier. Je leur signale la fonctionnalité via le chat et les laisse décider s'il s'agit d'un bug. J'ai perdu beaucoup trop de temps à essayer de leur «prouver» des choses et, en fin de compte, il n'est pas de ma responsabilité d'améliorer leur produit.

Enfin, si la situation correspond réellement à ce que vous décrivez ici, votre lieu de travail sonne vraiment merdique. Mais - il y a probablement deux côtés à l'histoire et ce qui nous manque tous (y compris vous semble-t-il), c'est l'autre histoire.

L'empathie est importante. Plusieurs collègues, y compris votre patron, "déclamant et délirant" plutôt que de signaler correctement un bogue suggèrent qu'il y a un manque majeur d'empathie quelque part dans les interactions.

L'OP pourrait insister pour que tout le monde utilise le système de billetterie et n'insère des bogues que pour son patron.

Le patron est au cœur du problème.Personne d'autre ne le fera s'il voit que le patron du PO ne dérange pas.C'est un patron qui mine son propre problème de personnel.

Twyxz

2018-08-14 12:47:58 UTC

view on stackexchange narkive permalink

Mentionnez-le, dites à vos collègues que

Si vous n'utilisez pas le système de billetterie, je ne peux pas le réparer car il ne figure pas dans mes feuilles de temps.

De cette façon, ils vont classer les bogues sinon il semblera que les bogues ne sont pas "trouvés" et ce sont eux qui sont en faute, pas vous. Donc, ils notent les bogues ou laissent les bogues entrer dans une application en direct. Cela met la balle dans votre camp.

Ils peuvent alors aller voir votre manager et dire que vous ne corrigez pas les bugs, mais vous pouvez alors simplement les raisonner là-bas et il est probable que votre manager prendra de votre côté et demandez-leur d'utiliser le système de billetterie.

Cependant, pour éviter toute agitation, dites-le simplement à votre responsable.

Les gens trouvent des bogues et je les corrige mais ils refusent de le connecter au système de billetterie afin que Je peux le marquer sur ma feuille de temps, donc mes feuilles de temps ne sont pas exactes.

davidbak

2018-08-15 03:15:20 UTC

view on stackexchange narkive permalink

En tant que développeur de longue date, je déteste signaler des bogues dans un système de rapport de bogues. Ils nécessitent tous la saisie de plusieurs champs dont je ne connais pas la réponse ou dont je ne me soucie pas. Et ils sont lents aussi. De plus, lorsque j'ai terminé, le développeur le ferme toujours "de toute façon ne peut pas faire de repro".

En utilisant votre application, j'apprécierais grandement un bouton juste là dans l'application qui signalerait le bogue dans votre application . Il faudrait une capture d'écran, connaître son propre numéro de build, sérialiser l'enregistrement des 100 dernières interactions d'interface utilisateur ou tout ce qui pourrait vous aider à reproduire le problème, et également ajouter d'autres éléments d'intérêt pour le développeur qu'il a juste là dans la RAM pour le moment, et permettez-moi peut-être de éventuellement entrer un commentaire.

Alors nous serions tous heureux.

Nous utilisons JIRA.Tout ce que vous avez à faire est de saisir les étapes pour reproduire le bogue, et peut-être de joindre une capture d'écran.Mais les gens ne le font toujours pas.Ils collent une capture d'écran sur un e-mail et disent "J'ai trouvé ce problème".S'ils ont même le plus petit "titre" comme "leader" (un leader n'est même pas un manager), ils ajouteront également des commentaires avisés sur le système.Grâce à ces personnes, l'entreprise a embauché une personne dont le travail consistait à prendre ces e-mails et à les saisir dans JIRA.

En tant que développeur de longue date, j'adore rapporter les bogues dans un système de rapport de bogues.:RÉ

@hjf et c'est probablement la bonne chose à faire - fait gagner du temps aux utilisateurs et donc économise de l'argent sur eux et fournit ainsi suffisamment d'argent pour le nouvel employé.

@Mark la personne a été mise à pied, a payé une pleine indemnité et a été réembauchée 3 mois plus tard.Les clients (nos clients sont des opérateurs télécoms de plusieurs milliards de dollars) ont menacé de résilier notre contrat si cette position n'était pas rétablie.

@hjf semble que votre entreprise a appris la leçon importante qu'aucun système ne peut remplacer un bon administrateur humain :-)

andtodd

2018-08-14 16:34:45 UTC

view on stackexchange narkive permalink

J'ai travaillé pour une grande entreprise informatique dans le passé et de nombreux employés d'une équipe particulière ont refusé d'utiliser le système de billetterie. Ils ont finalement perdu leur emploi en raison de licenciements.

Aucun enregistrement du travail qui doit être effectué dans le système, alors la planification des effectifs n'a aucun enregistrement sur lequel baser leurs estimations futures.

Les systèmes sont là pour une raison qui n'est pas pour s'amuser et les gens ne pensent pas toujours à la situation dans son ensemble et voient cela comme un autre obstacle à franchir pour faire leur travail. Insistez sur l'importance du travail de journalisation afin qu'ils puissent rendre compte de leur temps.

C'est vrai.L'ensemble du processus d'utilisation de Rally ou JIRA ou autre pour suivre le travail est un PITA - et ceux-ci sont parmi les meilleurs.(Ne me lancez pas sur ServiceNow.) Cela semble être un travail chargé et ennuyeux ... jusqu'au jour où votre vice-président de département vous dit tout, il le suit de près et utilise tous les chiffres récapitulatifs pour aller au conseil d'administration pour obtenir son budget pour la prochainean ...

Simon

2018-08-14 16:39:47 UTC

view on stackexchange narkive permalink

Bien que je sois d'accord en général avec les autres réponses, je souhaite en outre ajouter un autre point de vue.

Bien sûr, vous et votre responsable pouvez forcer vos collègues à rédiger des rapports de bogue, mais si ces collègues ne le sont pas développeurs ou familiers avec les systèmes de tickets, vous pourriez vous retrouver avec beaucoup de tickets inutiles à la "fonctionnalité stupide X ne fonctionne pas". Vous pouvez alors leur renvoyer le ticket avec "pas clair", mais cela conduit facilement à un cycle infini inutile, qui ne vous aide en rien.

Une autre approche serait de s'asseoir avec eux pour reproduire le bogue et vous créez ensuite un rapport de bogue significatif. Cela peut prendre plus de temps, mais présente plusieurs avantages:

vos collègues sentent que leurs problèmes sont résolus
vos collègues apprennent à quoi informations dont vous avez besoin pour corriger les bogues
vous obtenez un rapport de bogue significatif avec toutes les informations nécessaires
vous passez moins de temps à trier les tickets incomplets

Dans à la fin, cela pourrait être une approche plus rapide et plus satisfaisante.

La question de savoir si le développeur s'assoit avec l'utilisateur pour voir le bogue démontré n'est pas liée à l'existence ou non d'un système de tickets.Je ne résoudrais jamais une affaire parce qu'elle n'était pas claire.Je pose des questions plus spécifiques et peut-être rendre visite à l'utilisateur, et c'est avec un bon système de rapport de bogues.Je ne pense pas que cela réponde à la question.

Andrew Ebling

2018-08-15 15:55:59 UTC

view on stackexchange narkive permalink

Autre point de vue - soyez reconnaissant que vous ayez des collègues suffisamment engagés pour vous fournir une contribution directe sur le produit.

Oui, ils devraient rédiger de bons rapports de bogues, mais tout le monde ne le fait pas. Et il y a de fortes chances que, en tant que développeur, vous rédigiez vous-même un meilleur rapport de bogue.

Je recommanderais donc l'approche suivante à l'avenir:

Précisez que vous êtes reconnaissant pour la contribution de vos collègues. Ou pour le dire autrement, indiquez clairement que vous ne les considérez pas comme un problème qui doit disparaître. Cela pourrait être la réaction perçue si vous dites "signaler un bogue".
Expliquez que ce sera la meilleure utilisation du temps de tout le monde si vous vous asseyez et rédigez le rapport de bogue ensemble , ici et là.
Travaillez sur votre propre modèle / liste de contrôle de rapport de bogue.
Capturez absolument tout ce que vous pouvez sur le bogue, pendant que vous avez la personne attention et capacité à le reproduire devant vous, alors que le problème est frais dans l'esprit du journaliste. Ceci est particulièrement important pour les applications mobiles, où vous n'avez peut-être pas accès à un appareil de test qui reproduit le problème, ou il peut s'agir d'un problème qui ne peut être reproduit que sur une instance d'installation spécifique de l'application.
Assurez-vous que le journaliste est abonné aux mises à jour du bogue par e-mail, afin qu'il puisse le voir progresser dans le système.
Remerciez votre collègue pour sa contribution et dites à quel point vous appréciez les "tests d'utilisabilité des couloirs" ( comme le dit Joel) et qu'ils se soucient suffisamment pour signaler les bogues. Supposons que vous souhaitiez que plus de personnes dans l'entreprise fassent cela.

En adoptant cette approche, vous serez perçu comme étant ouvert et réceptif aux rapports, vous expliquerez au journaliste ce qu'est un bon rapport de bogue ressemble à et vous aurez tous les deux l'impression d'avoir accompli quelque chose en équipe.

Les relations produit et travail bénéficieront toutes deux de l'adoption d'une telle approche.

Il devrait être reconnaissant que les gens viennent à lui (n'importe quel développeur aléatoire) et RANT à propos d'un bogue?Je suis désolé, travaillez-vous même pour une entreprise?Il semble que vous ne soyez pas conscient de la toxicité de certaines personnes, en particulier celles qui ont des «titres d'emploi» plus élevés que le vôtre.

En tant que développeur, obtenir une brève description d'un bogue, * avec une démonstration *, est parfois bien mieux que d'essayer d'interpréter la description typique d'un non-développeur dans un rapport de bogue "formel", surtout si elles incluent une "capture d'écran" qui nene montre pas vraiment le bogue.Demander à l'utilisateur d'essayer d'enregistrer son écran utilisera probablement beaucoup plus de * son * temps également.Dans une * organisation *, utiliser le temps supplémentaire du «budget» des autres est en fait globalement moins efficace.

Chris

2018-08-14 19:00:12 UTC

view on stackexchange narkive permalink

Mon premier emploi avait un problème similaire. Mon groupe a créé un logiciel que certains de nos ingénieurs ont utilisé et ils se sont assis juste devant notre salle. Ils avaient tous l'habitude de simplement revenir et de nous dire quand nous avions un problème qui faisait oublier certaines choses.

Nous avons lancé un système de tickets pour lutter contre cela, aider à garder une trace des choses et supprimer les interruptions. Cela a pris un certain temps, mais nous avons finalement amené les gens à utiliser le système en disant toujours "Avez-vous mis un ticket dans le système?" et ne pas travailler sur aucun problème jusqu'à ce qu'il soit entré. Nous leur rappelons également que ce n'est pas seulement pour notre bénéfice, mais aussi pour que leurs problèmes ne soient pas oubliés. S'il était enregistré, cela finirait par être fait.

cornelb

2018-08-14 16:29:57 UTC

view on stackexchange narkive permalink

Les collègues sont-ils des développeurs impliqués? Si oui, il devrait être facile d'expliquer en quoi consiste le processus et pourquoi il est utile de tout organiser, sinon il se peut qu'ils ne soient pas familiers avec les systèmes de suivi des bogues et ne comprennent pas pourquoi ils sont utiles.

On leur a demandé d'aider à tester l'application, ce qui signifie qu'ils voient cela très différent d'un testeur, par exemple. Un testeur connaît le processus et suit les étapes.Un collègue invité à tester l'application supposera que chaque bogue est un gros problème et supposera qu'il peut simplement vous en parler et expliquer personnellement pourquoi c'est un gros problème, au lieu de l'ajouter. à un outil de suivi.

Trouvez ce avec quoi ils sont à l'aise

S'ils se sentent mieux pour ajouter la description à un document, donnez-leur tous accès à un nouveau google doc pour cela. Ensuite, passez en revue les problèmes et ajoutez-les vous-même au système de suivi des bogues, si ce sont vraiment des bogues, cela ne devrait pas prendre trop de temps. Cela pourrait être mieux que de leur demander de fournir des détails insuffisants dans un outil de suivi des bogues.

Le but est d'amener les gens à envoyer des commentaires précieux, et non de les amener à utiliser les outils auxquels vous êtes habitués

Zibbobz

2018-08-15 18:41:24 UTC

view on stackexchange narkive permalink

Si les meilleures réponses ne permettent toujours pas à vos collègues d'écrire leurs bogues et de vous les envoyer dans le système de tickets, voici un moyen infaillible de vous assurer que votre temps de travail est alloué au système de tickets.

Tout d'abord, notez tout ce que votre collègue vous dit sur le bogue. Si possible, demandez-leur de vous envoyer un e-mail à ce sujet afin que vous ayez quelque chose à lire.

Ensuite, écrivez le bogue vous-même.

Enfin, corrigez le bogue - si vous en avez connaissance et que vous êtes censé le corriger, corrigez-le.

Cela fait deux ou trois choses pour vous - cela met le bogue dans le système de tickets pour montrer que vous lui avez alloué du temps de codage, et cela met votre temps à écrire le bogue dans le système également - essentiellement, le temps que votre collègue a «perdu» vous en parler en personne devient du temps facturable pour vous .

Vous devriez continuer à encourager vos collègues à rédiger leurs propres rapports de bogues car c'est ce qu'ils devraient faire, et vous ne devriez pas le décourager. Mais au lieu de cela, si votre véritable objectif ici est de l'avoir dans le système afin que vous puissiez enregistrer le temps passé à y travailler, écrivez-le vous-même et récoltez le mérite à la fois pour l'écriture et la prise en charge du bogue.

Inclure le fait que le collègue refuse d'écrire des bogues est un moyen de mettre cette personne contre vous.La direction est plus susceptible de vous rallier si vous NE corrigez PAS un bogue non signalé, que si vous «snitch» sur un collègue.Ils s'inquiètent plus du fait que les gens «ne se battent pas» plutôt que d'obtenir un produit de qualité.

@hjf Cela ressemble à une gestion horrible ... mais je pense aussi que vous avez peut-être raison.Je modifierai ma réponse.Je suis toujours catégorique sur le fait qu'ils devraient simplement écrire le bogue eux-mêmes, mais en supprimant la partie où ils mouchardent devrait aider.

@hjf Je ne penserais pas à cela comme du "mouchard".Vous pouvez simplement entrer le bogue comme "Joe Smith a signalé qu'un clic deux fois provoque un plantage du système".Juste les faits.Il est important de savoir qui a trouvé le bogue à l'origine au cas où vous auriez besoin de plus de détails.Je ne pense pas que quiconque puisse reprocher à la personne entrant dans le rapport d'avoir inclus le nom de la personne qui a effectivement trouvé le bogue.

Alex R

2018-08-14 22:04:38 UTC

view on stackexchange narkive permalink

Il est possible que vos collègues préfèrent simplement l'interaction humaine à la saisie de données dans un outil.

Alors faites-les glisser dans une réunion récurrente. Si votre entreprise n'est pas propice aux réunions (peut-être que vous n'avez pas de bonnes salles de conférence avec de grands moniteurs?), Allez au bureau de chaque personne et faites-le sur une base 1: 1:

Pendant cette réunion, vous ouvrez l'outil de suivi des bogues sur votre propre ordinateur portable et demandez-leur de vous dicter la description du bogue afin que vous puissiez l'entrer dans l'outil. Profitez-en pour leur demander de vous montrer le bogue ou de clarifier les étapes nécessaires pour le reproduire.

N'oubliez pas d'inclure dans vos feuilles de temps le temps que vous avez passé à documenter chaque bogue, c'est juste un partie intégrante de la correction du bogue.

Pratiquez l'art de garder un visage impassible tout en écoutant leurs diatribes (à condition qu'elles ne soient pas abusives). Il s'agit d'une compétence importante et l'interaction supplémentaire avec ces personnes peut vous sembler une perte de temps maintenant, mais elle vous aidera plus tard dans votre carrière lorsque vous déciderez finalement que vous voulez un meilleur emploi.

Quand vous corrigez un bogue qui a été signalé avec beaucoup d'émotion, allez vers cette personne et faites-lui savoir que cela a été corrigé, et s'il vous plaît vérifier et confirmer que cela fonctionne à sa satisfaction afin que vous puissiez fermer le ticket.

Faites-les participer à une réunion de triage des bogues et forcez-les à regarder les rapports de bogues de tous les autres avoir la priorité sur les leurs, car le leur n'est pas dans l'outil!

Cela suppose que la personne peut décider quoi faire de son temps.Qu'ils aient du temps pour les réunions, que les autres personnes accepteront d'être entraînées dans une réunion.Étant donné que le message original indiquait que le BOSS refusait d'entrer des billets, nous savons comment les choses se passent dans cette entreprise: le patron donne des ordres verbaux et ensuite, lorsque les choses tournent mal, ils vous jettent sous le bus.Et ils sont toujours plongés dans l'eau jusqu'au cou.Oui, cela ne se produira pas dans le type de PO du lieu de travail décrit.

Tout cela sent l'agressivité passive.Permettre à chaque personne de faire ce qui est suggéré, * lorsqu'elle vient à vous pour signaler le bogue *, c'est mieux utiliser globalement votre temps et son temps: o)

arp

2018-08-17 07:09:03 UTC

view on stackexchange narkive permalink

Une solution orthogonale:

Ajoutez un bouton "rapport de bogue" à la version alpha-test du logiciel qui collecte automatiquement les données importantes et enregistre le rapport de bogue.

Ajoutez quelques champs de texte simples: "Qu'essayiez-vous de faire?" "Qu'attendiez-vous qu'il se passe?" "Qu'est-ce qui n'a pas fonctionné?"

(Ce ne sera pas aide, bien sûr, si le problème est que l'application se bloque ou se bloque.)

Laissez les utilisateurs expérimentés affiner le rapport et laissez les diatribes frapper simplement "soumettre".

blankip

2018-08-19 10:32:14 UTC

view on stackexchange narkive permalink

Je m'occupe de cela depuis 20 ans et fondamentalement la même réponse les 19 derniers.

Vous leur dites: "Regardez si ce bogue est important pour vous, je le ferais entrer dans le système de billetterie aussi rapidement que possible. Mon équipe et ma direction allouent la priorité et le temps pendant qu'ils examinent le système pour les bogues. Si votre bogue n'est pas là au mieux, il est prioritaire dans le prochain cycle. Je ne peux pas vraiment travailler sur la correction des choses sans un Correct OK. De plus, toute l’équipe doit comprendre l’impact total, car cela pourrait avoir un impact sur d’autres choses - ce qui signifie que tout ce que vous venez de me dire, tout le monde doit pouvoir voir ce qui peut accélérer la résolution du problème. "

kraligor

2018-08-16 21:35:39 UTC

view on stackexchange narkive permalink

Les systèmes de billetterie et les utilisateurs finaux sont incompatibles. Les gens les détestent (pour de nombreuses bonnes et moins bonnes raisons). Si vous avez un problème, vous voulez être écouté, activement.

Peut-être devriez-vous en quelque sorte souligner que vos collègues sont une partie active du développement, et pas de simples utilisateurs. Envoyez des statistiques de bogues et de développement tous les vendredis, mentionnez les personnes qui ont aidé à trouver des bogues critiques, peut-être même faites un petit classement (ne le laissez pas devenir trop compétitif).

Vous aussi peut-être en mesure d'améliorer l'interface utilisateur du système de billetterie? Coupez tous les détails techniques, une zone de texte et (très) peu de catégories au choix suffisent. Faites en sorte qu'il soit aussi simple que possible de signaler un bug de la bonne manière.

"Si vous avez un problème, vous voulez être écouté, activement."- ironiquement, la diatribe de la personne au comptoir sera oubliée à son départ, alors qu'un ticket stocké en permanence sur le bugtracker recevra une attention individuelle et active à un moment donné.

djsmiley2kStaysInside

2018-08-14 16:22:50 UTC

view on stackexchange narkive permalink

GAMEIFIEZ-LE!

Tout le monde aime les points, car les points signifient des prix **!

Il suffit d'avoir un tableau de résultats des bogues les plus trouvés (valides) cette semaine * 'ainsi que des mentions spéciales pour les bogues particulièrement étranges / intéressants pour défier tout le monde.

* Seuls les bogues signalés correctement peuvent être comptés!

** Les prix ne peuvent être que des compliments

Les gens qui aiment se plaindre des bugs ne seront pas ravis de voir que "le développeur" incompétent "essaie de faire de son travail un jeu au lieu de réparer son logiciel".J'ai travaillé dans un bureau où ils ont essayé quelque chose de similaire, la situation n'a fait qu'empirer.

Si les personnes qui découvrent les bogues ne comprennent pas le rôle d'un développeur, elles ne devraient probablement pas non plus occuper un poste dans l'équipe de test - idéalement, vous auriez une équipe de test dédiée qui sait exactement ce qu'elle fait et pourquoi.Vous ne pouvez pas réparer les lieux de travail cassés ...

Ce n'est pas ainsi que cela fonctionne.Vous attendez-vous également à ce qu'OP fournisse ses propres prix?Souviens-toi qu'il n'est pas le manager

Ok ok, les prix peuvent être théoriques et simplement des compliments.

@djsmiley2k l'entreprise compte 50 employés.Je pourrais très bien être que les testeurs ne sont que des consultants qui expliquent le fonctionnement de l'application aux clients, ou peut-être même aux vendeurs.(oui cela arrive!) Une équipe de test dédiée n'est pas toujours possible, même si votre produit principal est un logiciel, dans une petite entreprise.

Lorsque vous modifiez un système comme celui-ci, les gens trouveront des moyens de l'exploiter à leur avantage.Qui décide de ce qu'est un bogue «valide»?Comment gérez-vous une personne signalant 4 "bugs" qui sont le même problème?

Terrible idée.Si les gens obtiennent quelque chose de plus, ils trouveront des bogues (qui n'existent peut-être même pas) afin de «jouer» le système.

Dilbert pertinent: http://dilbert.com/strip/1995-11-13.

J'ai travaillé dans un endroit qui, pendant un certain temps, a donné littéralement 5 £ à quiconque dans l'entreprise qui a trouvé un bogue dans un logiciel phare, tant qu'ils étaient en dehors de l'équipe de développement (NB nous n'avions pas de QA dédié; allez comprendre pourquoi nousnécessaire pour soudoyer des gens pour qu'ils testent pour nous!).En fin de compte, nous n'avons toujours pas eu beaucoup de preneurs et les développeurs se sont sentis assez vexés.Parce que pourquoi les autres devraient-ils obtenir un bonus pour cela?Je trouvais des bugs tous les jours mais je n'avais pas d'argent supplémentaire pour cela.Remarquez, je suppose que je les ai également créés, alors ...