Comment remonter efficacement un problème à un développeur ?

Alors que vous naviguez sur le site Internet de votre entreprise pour montrer à votre prospect le nouveau formulaire mis en place, vous repérez un “problème” ! Votre premier réflexe est d’alerter immédiatement un développeur sur votre messagerie interne en le gratifiant du classique “ça ne marche pas !” Mais est-ce la manière la plus efficace de procéder ? Attention spoiler : bien évidemment que non. On vous explique dans cet article comment faire pour remonter de manière efficace aux équipes techniques les erreurs que vous relevez sur les outils que vous utilisez.

Différencier une anomalie d’une fonctionnalité

La première question que vous devez vous poser avant de remonter un “problème” est la suivante : « l’erreur que j’ai relevée correspond-elle à une anomalie ou à une nouvelle fonctionnalité ? » En plus clair, le “problème” identifié correspond-il à quelque chose qui devrait fonctionner différemment, si l’on se réfère à ce qui avait été demandé en amont du développement ? Ou ce que vous identifiez comme un “problème” relève-t-il en fait d’une nouveauté à développer qui n’a pas encore été demandée aux développeurs ? Dans le premier cas, il s’agira d’une anomalie, aussi appelée bug. Alors que dans l’autre situation, on parle de nouvelle fonctionnalité, demande d’évolution ou encore feature.

Cette distinction est loin d’être aisée à faire et nous vous conseillons de vous rapprocher systématiquement de vos Products Managers, Product Owners ou Chefs de Projet avant de remonter tout “problème”. Les consulter permettra également d’éviter des allers-retours inutiles dans le cas où l’anomalie est déjà en cours de correction ou que la nouvelle fonctionnalité est en cours de développement ou du moins déjà planifiée. Cela évitera également de déranger inutilement les développeurs.

Mais pourquoi cela est-il aussi important de différencier une anomalie d’une nouvelle fonctionnalité ? Tout simplement parce que cela ne sera pas traité de la même manière par l’équipe des développeurs. Alors qu’un bug pourra être traité dans l’heure s’il s’avère bloquant, une demande d’évolution devra, elle, être estimée et planifiée selon la méthodologie Agile entre autres.

Prendre le temps de la formalisation

Qu’il s’agisse d’une anomalie ou d’une nouvelle fonctionnalité, il sera nécessaire de passer du temps à formaliser votre retour.

Donner le plus d’informations possible

Concernant un bug, il faudra ainsi par exemple indiquer la date et heure à laquelle l’erreur a été repérée, préciser certaines informations techniques comme par exemple le numéro de version du logiciel, de l’application mobile ou du navigateur Internet, décrire l’ensemble des étapes qui ont menées à la découverte de l’anomalie ou encore réaliser des copie-écrans montrant l’erreur et l’urgence estimée de l’erreur. Un simple “ça ne marche pas” ne suffira bien évidemment pas ! Mais pourquoi donner autant d’informations ? Tout simplement pour que le développeur qui va traiter le bug puisse reproduire l’erreur, étape nécessaire pour pouvoir réaliser la correction tant attendue. N’hésitez pas à demander à l’équipe technique de vous fournir un template des informations attendues. Cela vous fera gagner beaucoup de temps.

Décrire vos besoins avec précision

Dans le cas d’une demande d’évolution, il vous faudra décrire précisément votre besoin fonctionnel : à quelle problématique souhaitez-vous répondre avec ce nouveau développement et que va-t-il apporter aux utilisateurs concernés ? Le développeur aura alors tous les éléments nécessaires pour traiter la demande et pourra parfois vous proposer des solutions auxquelles vous n’auriez pas pensées. Gardez en tête que plus vous serez précis, plus vous éviterez les allers-retours causés par des incompréhensions. Et oui, on vous le confirme, ce n’est pas un exercice facile !

N’oubliez pas dans tous les cas de respecter les process mis en place par l’équipe projet et de bien utiliser les outils dédiés. Le process de remontée peut varier selon qu’il s’agisse d’une anomalie ou d’une nouvelle fonctionnalité, renseignez-vous bien en amont !

Ne pas chercher à imposer une deadline

La dernière erreur souvent commise est de vouloir imposer une deadline. Les Product Managers, Product Owners ou Chefs de Projet sont les garants du produit et ont ainsi une vision d’ensemble. Ils sont donc les mieux placés pour prioriser auprès des développeurs les différentes anomalies ou nouvelles fonctionnalités. Vous pouvez en revanche tout à fait demander à pouvoir suivre l’avancement de votre demande. Cela pourra se faire à travers un tableau de bord sur JIRA ou Trello par exemple, ou plus simplement sur Excel.

Le fait de passer par l’équipe projet permettra aussi de mutualiser certaines demandes provenant de différentes équipes. Plutôt que de développer deux fonctionnalités, pourquoi ne pas essayer d’en développer une seule qui répondra aux deux besoins ?

La seule exception à cette règle étant si l’anomalie remontée est considérée comme bloquante, ce qui signifie qu’elle empêche les utilisateurs d’utiliser l’application ou le site Internet. Cela peut être par exemple un bug sur le paiement pour un site e-commerce. Nous vous invitons à vous rapprocher de votre équipe technique pour connaître la marche à suivre car un process à part est souvent mis en place pour les anomalies bloquantes.

Voilà vous savez tout à présent ! Il ne vous reste plus qu’à vous rapprocher des équipes techniques pour connaître les process mis en place au sein de votre entreprise. En respectant les conseils décrits dans cet article, vous contribuerez à augmenter l’efficacité des développements et donc du traitement des demandes !

Suivez Welcome to the Jungle sur Facebook pour recevoir chaque jour nos meilleurs articles dans votre timeline !

Photo by WTTJ