Les mails sont toujours noyés dans la masse d’autres mails, surtout si la demande n’est pas urgentissime. Ils sont difficiles à retrouver après une semaine, et pour peu qu'il y ait eu plusieurs échanges avec des informations complémentaires, il devient complexe de pouvoir suivre la demande.
De la même façon, les demandes par téléphone sont à proscrire : ça ne laisse carrément aucune trace ! La seule mémoire ne suffira jamais pour se souvenir de tout ce qui doit être fait. De plus, il est bien plus facile de s’embrouiller dans des explications orales.
De fait, un système d’échange par tickets doit être mis en place sur chaque projet, et les retours clients doivent se faire par son biais.
Un ticket doit correspondre à un ensemble cohérent d’actions à réaliser. Par exemple, s’il y a des retouches à faire sur quelques pages, ne pas les préciser dans le même ticket qu’une demande de feature.
Si un ensemble de retours correspondent au même type de (petites) tâches, les regrouper dans un même ticket. Par exemple, un ticket listant les retouches de la page Home et un ticket pour celles de la page About, plutôt qu’un ticket par retouche.
Ne jamais assumer que votre interlocutaire comprend instinctivement de quoi vous parlez.
Pas bien :
Utilisez la maquette pour savoir comment faire
Bien :
Utilisez le PSD
Homepage-deploy_DEV00.psdpour savoir comment faire
C’est bête et méchant, mais ça évite à la personne qui exécutera la tâche du ticket de perdre du temps à fouiller les fichiers pour trouver le bon. Pour peu que le projet soit tout nouveau, que la personne rejoigne le projet en cours de route, que le retour survienne longtemps après la réalisation du projet, ou tout simplement qu’on soit lundi matin (ou vendredi soir), ça permet de gagner beaucoup de temps.
Quelques autres exemples :
- Penser à préciser les liens, et les textes qui vont avec lesdits liens.
- Lorsqu’on fait référence à un point d’une spec, citer directement le point en question : c’est beaucoup plus rapide que de fouiller ladite spec à la recherche de la bonne ligne (surtout si elle est très dense).
- En cas de changement dans le texte, donner l’intégralité du nouveau texte plutôt que des changements à divers endroits : ça limite fortement le risque d’oublis et de ratés.
Une bonne team (et un bon gestionnaire de tickets) doit mettre à disposition un ensemble de labels à appliquer sur les différents tickets ; servez-vous en intelligemment ! Mettre un label urgent sur 31 tickets retire tout le principe de l’urgence. En tant qu’équipe, définissez des tickets cohérents. En tant que client, étudiez-bien la liste des labels disponibles avec l’équipe.