10 erreurs à commettre pour une mauvaise gestion de recettage

Aujourd'hui nous vous donnons toutes les clés pour rater la recette d'un site web, d'une application ou d'un logiciel. Parce que la gestion du recettage d'un projet de développement web est importante, nous allons vous dire exactement toutes les erreurs à commettre pour que vous ne les reproduisiez plus jamais !

Erreur #1 : Ne pas prévoir le recettage

Le meilleur moyen de rater un projet web c'est encore d'oublier un ingrédient important : la recette.

Oublier de prévoir cette étape qui consiste à valider que le projet est conforme à ce qui est attendu ne fera pas disparaitre les bugs pour autant. Le reporting de bug se fera juste n'importe quand et n'importe comment...

Erreur #2 : Ne pas planifier la recette

C'est bien de prévoir de recetter un projet web, mais faut-il encore le planifier. Se dire dans un coin de sa tête qu'on recettera le projet la veille de livrer est le meilleur moyen de râter la livraison d'un projet abouti qui convienne au client. 

Une bonne gestion de recettage est donc une recette délimitée dans le temps afin que tous les feedbacks soient faits avant la livraison.

Erreur #3 : Impliquer tout le monde

Faire recetter un projet un trop grand nombre de personnes est le meilleur moyen d'avoir des retours en double, triple, quadruple... De plus, chaque personne recettant le projet doit en connaître les attentes initiales.

Avec un outil de gestion de recettage, il est possible de définir une équipe d'utilisateurs qui pourront recetter le projet web par exemple.

Erreur #4 : N'impliquer personne

La gestion de recettage ne se fait jamais seul. Il faut à minima impliquer un autre collaborateur que le développeur qui remarquera d'autres bugs et le client.

Erreur #5 : Tester sur 1 support, 1 navigateur, 1 version

Il faut s'assurer que le projet est compatible avec l'ensemble des supports et navigateurs utilisés par la cible. Un projet ne peut être optimisé uniquement pour Chrome et/ou Safari alors que la cible utilise l'application métier, par exemple, sur IE11.

Erreur #6 : Tester sur IE6

Alors oui il faut tester sur plusieurs versions d'un navigateur mais il faut aussi savoir faire l'impasse. La compatibilité avec de vieilles versions nécessite un développement particulier qui est bien souvent trop coûteux par rapport aux nombres d'utilisateurs touchés par cette amélioration d'expérience.

Erreur #7 : Accepter de recevoir des rapports de bugs par téléphone

Un bug rapporté par téléphone dérangera forcément le développeur qui ne passe pas sa journée à attendre que ceux-ci soient rapportés. De plus, par téléphone, il est impossible de visualiser l'erreur et la personne qui remonte l'erreur est bien souvent incapable de rapporter les détails de son environnement d'utilisation.

Il est donc préférable d'utiliser exclusivement une solution de gestion de tickets pour centraliser tous les retours et pour que chaque réception de bug report soit efficace.

Erreur #8 : Passer 20 minutes à obtenir des informations pour reproduire un bug

Si le téléphone n'est pas un bon canal pour rapporter des bugs lors d'un recettage, l'e-mail n'est pas non plus adapté. Lorsque le rapporteur n'utilise pas de solution de recettage pour remonter les erreurs, celles-ci sont incomplètes et cela entraine de nombreux allers-retours pour aller chercher les informations liées à l'environnement.

La communication est essentielle pour éviter certains problèmes généralement rencontrés en phases de recettage.

Erreur #9 : Recevoir un bug, le noter sur un post-it et l'oublier

Les bugs ne doivent pas être simplement remontés, ils doivent être corrigés et retestés. C'est pour cela qu'il est d'autant plus important d'utiliser une solution de gestion de tickets pour organiser le recettage. Grâce à une solution comme SmartHelp, il est possible de ranger les tickets dans des dossiers, étape par étape : tickets fermés, en attente, archivés...

Il est également possible de leur donner un ordre de priorité : urgent, haut, normal, bas. Le plus important est qu'il est possible d'assigner un développeur à la correction du ticket, estimer le temps d'intervention, échanger dans un fil de commentaires et notifier le rapporteur de la résolution du bug.

En bref, un bug doit être suivi !

Erreur #10 : Traiter une évolution non prévue à l'origine

Un des problèmes majeurs auxquels sont confrontés les chefs de projet est la gestion de la frontière entre correction et évolution. En effet, à l'inverse d'un flyer qu'on crée, qu'on valide, qu'on teste par un BAT et qu'on imprime définitivement, un projet web n'est pas aussi figé.

Une fois face à son projet, le client peut avoir de nouvelles idées d'amélioration et il faut être capable de catégoriser chaque ticket comme erreur ne répondant pas au cahier des charges ou comme une évolution future. Si un client envisage des améliorations, il faut le voir comme une opportunité de lui proposer une V2 de son projet et ainsi ne pas perdre du temps non facturé sur le projet en cours de recettage.

Partager sur :