Pourquoi est-il si difficile d'amener les employés à mettre à jour le suivi des problèmes?

J'ai toujours eu du mal à amener les gens à mettre à jour leurs problèmes, à la fois dans mon entreprise et au travail. J'ai eu quelques cas où les gens le font de bon cœur, mais ~ 70% du temps je dois pourchasser les gens.

Étant celui qui fait généralement une forme ou une autre de gestion (je suis avant tout un développeur), la principale raison que j'essaie de donner est que je ne veux pas pourchasser les gens et interrompre pour interroger sur les progrès, mais je ne ' Je pense qu'en fin de compte, les gens se soucient de beaucoup de choses. Dans certains cas rares et extrêmes, je finis par mettre à jour leurs tickets (lorsque j'ai besoin de créer des rapports).

Alors, avez-vous rencontré ce problème?, Comment avez-vous encouragé les développeurs à mettre à jour fréquemment l'outil de suivi des problèmes?, Quel succès avez-vous obtenu?

La raison en est qu'ils ne comprennent pas pourquoi ils devraient mettre à jour le tracker de problème, à part le fait que vous le dites.

Pourquoi donc? Je suppose que la mise à jour du tracker n'affecte pas leur travail de manière significative, donc la solution est probablement de mettre en œuvre un système de suivi qui les aide réellement à mieux faire leur travail.

C'est difficile, car les employés pensent clairement que la mise à jour du suivi des problèmes n'est pas importante. Vous devez changer cela, mais il y a un hic. La communication est difficile. Une communication efficace est vraiment plus difficile que vous ne le pensez. Si difficile, cette communication échoue généralement, sauf par accident .

Montrez, ne dites pas. Par exemple. ne dites pas que vous (ou votre patron) avez besoin des données pour un rapport. Montrez du point de vue des employés comment le suivi des problèmes à jour les affecte et les aide.

Mener par l'exemple.

Je suis développeur et j'ai du mal à utiliser l'outil de suivi des problèmes que nous avons au travail. C'est dommage car je suis tout à fait pour eux de garder les choses organisées. Ma solution pour le moment est d'utiliser un outil de suivi personnel et de le référencer pour parler des progrès de nos mêlées quotidiennes.

Voici ce qui me ferait utiliser le tracker tout le temps:

• Intégration transparente avec l'IDE et le contrôle de source. Nous utilisons une webapp maladroite car des licences ont déjà été achetées pour cela. La création / mise à jour de tâches prend une éternité et certaines fonctionnalités d'interface utilisateur sont déroutantes. Malheureusement, cette utilisation est indépendante de la volonté de notre équipe.

• Simplicité. J'entends par là ne pas prendre 10 champs remplis manuellement juste pour ajouter une tâche. Estimations horaires vs heure de fin, saisie manuelle du projet / composant / etc. dans plusieurs domaines, etc., il suffit d'augmenter la durée.

• Seulement un. Je ne sais pas à quel point cela est courant, mais la gestion de projet utilise un outil, le support en utilise un autre et le développement en utilise un troisième. Si l'un n'est pas mis à jour, trois ne le sont certainement pas et la synchronisation entre eux ne sera probablement pas automatisée.

Tout d'abord: que voulez-vous dire par "les gens qui mettent à jour leurs progrès"?

Voulez-vous dire «les développeurs mettent à jour l'estimation actuelle», ou «les développeurs ne définissent pas un problème comme résolu», ou plutôt «les clients / testeurs ne clôturent pas un problème résolu», ou tous ensemble?

Du point de vue d'un développeur, c'est un mélange de mentalité et de culture.

• état d'esprit: lorsque vous définissez un problème comme résolu, cela signifie que vous avez terminé et responsable s'il est bogué
• culture: si toute l'entreprise n'est pas très désireuse d'utiliser de tels outils, mais préfère d'autres stratégies d'organisation

Mon expérience est la suivante: il faut au moins que la culture pointe dans la bonne direction. Ce qui aide ensuite, c'est de définir un DoD (définition de `` fait '') - si un développeur (qui travaille pour d'autres rôles aussi) peut dire qu'il a rempli toute la liste, il est soulageant de marquer le problème résolu et de passer à autre chose sans besoin regarder en arrière.

Arrêtez de poser des questions sur les progrès du codage (c'est généralement un pourcentage arbitraire arraché de toute façon) jusqu'à ce que le billet soit fermé, ne donnez aucun crédit. Si la principale chose que vous mesurez est le nombre de tickets fermés, cela s'améliorera.

Notez cependant que toutes les métriques peuvent être utilisées et que les métriques ont tendance à mieux fonctionner lorsqu'elles sont associées à des métriques complémentaires, par exemple, vous voudrez probablement également examiner les problèmes qui sont rouverts car cela implique qu'ils sont fermés prématurément.

Comme l'ont souligné d'autres réponses, la bonne question ici est probablement: pourquoi avez-vous un outil de suivi des problèmes. Une bonne réponse à cette question (non seulement du point de vue de la gestion mais aussi du point de vue du développeur) est impérative si vous voulez qu'un système de suivi des problèmes fonctionne vraiment et soit régulièrement mis à jour.

Dans de nombreuses entreprises, le système de suivi des problèmes est principalement utilisé comme outil de reporting de gestion. Faire en sorte que les programmeurs mettent à jour les problèmes pour que la direction puisse exécuter un rapport ne fonctionne pas bien. Et forcer les programmeurs à mettre à jour les problèmes ne fonctionne pas non plus - vous pouvez avoir des problèmes mis à jour mais vous devez remettre en question les données.

D'après mon expérience, la seule façon d'avoir vraiment des développeurs (et testeurs, gestion, etc.) utilise efficacement un système de suivi des problèmes est de l'intégrer dans le processus de développement. Cela signifie que la sortie d'une partie du processus devient l'entrée de la partie suivante du processus.

Pour donner l'autorité au système de suivi des bogues, je suggère ce qui suit:

• Les développeurs ne travaillent que sur les bogues / fonctionnalités enregistrés dans le suivi des problèmes et aucun travail n'est effectué en dehors de celui-ci. Toutes les idées, les projets de refactoring, les nouvelles fonctionnalités, les outils personnalisés à développer, etc. doivent également être enregistrés.
• Les problèmes sont traités par ordre de priorité. La priorité devrait en partie être déterminée par la direction, mais les développeurs devraient également avoir leur mot à dire dans la détermination des priorités. Cela est particulièrement vrai lorsqu'il s'agit de problèmes de maintenance et de refactoring.

Quant au processus, vous pouvez utiliser quelque chose comme ceci:

• l'état 'nouveau' indique qu'un problème n'a pas encore été détecté par un développeur et est toujours dans la file d'attente des problèmes prioritaires
• l'état 'assigné' indique qu'il a été attribué à un développeur. Cela pourrait être fait par le développeur ou quelqu'un d'autre comme le chef d'équipe. Je trouve que cela fonctionne bien d'avoir quelques problèmes assignés à chaque développeur, et généralement un mélange de `` gros travaux '' tels que de nouvelles fonctionnalités et des choix faciles tels que de simples bugs ou quelques travaux de maintenance simples. Cela permet aux développeurs de choisir le travail en fonction de leur humeur.
• l'état «en cours» signifie qu'un développeur travaille sur un problème. Un ou deux problèmes seulement par développeur doivent être «en cours» à tout moment.
• une fois qu'un problème a été résolu, le développeur peut changer le statut du problème en «nécessite des tests» et changer le propriétaire en testeur. Il s'agit d'une étape importante, car il s'agit également de la file d'attente de travail des testeurs.
• les testeurs peuvent changer le statut en `` tests échoués '' et redéfinir la propriété sur le développeur, ce qui signifie qu'il va en haut de la file d'attente pour le développeur, ou ils peuvent changer le statut en `` prêt pour le déploiement ''.
• les problèmes avec le statut «prêt à être déployé» peuvent ensuite être fusionnés et publiés selon le cycle de publication par la personne responsable des versions.

En bref: faites du système de suivi des problèmes un élément essentiel du processus de développement et vous n'aurez pas à vous soucier des problèmes qui ne sont pas mis à jour.

Peut-être jugent-ils trop fastidieux d'ouvrir un navigateur, de se connecter, de trouver le ticket et de le remplir. Vous pouvez peut-être essayer de les encourager avec des crochets . De nos jours, il est courant que dans le message git / hg [je suppose que vous en utilisez un], vous pouvez taper quelque chose comme aimé FIXED # 123, et le ticket changera automatiquement une fois que vous aurez poussé votre commit. De cette façon, cela ne sert presque à rien pour le développeur [s'il travaille sur chaque problème dans une branche distincte - il a déjà l'ID de ticket] et très probablement il ajoutera ces deux caractères dans le message de validation. Si cette solution n'est pas suffisante, cela signifie peut-être que la portée des tickets est trop grande et devrait être divisée en plusieurs tickets plus petits?

Cela ressemble à un problème de culture d'entreprise plus que toute autre chose. Qui a institué la nécessité d'utiliser le tracker? Si c'est quelque chose qu'une personne ou un groupe a jeté là-bas et s'attend à ce que tout le monde accepte et utilise, bonne chance. À moins que les gens comprennent ce que c'est, savent comment l'utiliser et acceptent que cela leur facilite réellement la vie (leur vie, PAS la vôtre), ils ne l'utiliseront pas à moins d'être contraint par la direction. Cela étant dit, si l'utilisation du tracker est une décision de l'entreprise, il appartient à la direction de l'appliquer. À moins que votre rôle n'inclue la responsabilité et l'autorité pour amener / faire utiliser le tracker (cela ressemble à non, car vous avez indiqué que vous êtes un développeur), vous n'irez pas très loin, quoi que vous fassiez (en réalité, à mon humble avis ).

Cela est probablement similaire à la raison pour laquelle il est si difficile d'amener les gens à entrer leur temps régulièrement. C'est un travail fastidieux ...

De nombreux trackers de problèmes s'intègrent à l'IDE. Par exemple, l'outil de suivi des éléments de travail TFS vous permet de marquer une tâche comme résolue lorsque vous effectuez un archivage. Il y a même une option pour exiger qu'un enregistrement soit associé à une tâche. L'intégration de la mise à jour d'un élément de travail au processus d'archivage simplifie les choses. L'alternative étant d'ouvrir le suivi des problèmes dans une interface distincte pour effectuer le changement.

Une autre option consiste à organiser une réunion d'état (ou lors de la réunion quotidienne) au cours de laquelle quelqu'un ouvre le tracker et met à jour les tâches à mesure que les utilisateurs fournissent le statut.

Une chose à prendre en compte est que l'interface graphique elle-même est un obstacle. Par exemple, certains obstacles peuvent inclure:

• Trop de clics
• Serveur d'applications Issue Tracker non optimisé ou sous-alimenté
• Mauvaise convivialité ou accessibilité

L'exposition d'une API permettra au traqueur de problèmes d'être mis à jour via des scripts identiques aux artefacts techniques (couverture de code, rapports de tests unitaires, état de la construction, etc.).

Les références

• Scrumwise - API

• Référence de l'API REST JIRA Cloud

• API REST Alfresco Content Services