Plusieurs aspects : process et outils.
D’un point de vue outillage, il y a tout une série de fonctionnalités dans JIRA au point qu’il y a un produit à part (JIRA Helpdesk). Autrement des outils de gestion de support sont nombreux. Mais globalement ce sont des outils de “issue tracking”.
Concernant les process, il faut savoir si c’est plutôt du “time boxing” (Scrum) ou une autre organisation.
Dans le cadre du “time boxing”, il faut réserver un temps donné (ex : rotation d’un membre par semaine) à cette activité. Pour le côté “fun”, on peut attribuer un “sceptre” à la personne qui le fait (ballon anti-stress, t-shirt, fond d’écran, etc.).
Dans le cadre d’une approche plus orienté flux (Kanban), il faut adopter une organisation similaire aux urgences hospitalières. Pour schématiser, cela consiste à un système en couche qui “dispatch” les demandes (évaluer, prioriser).
Le support est généralement lié à des engagements contractuels type SLA (lien entre criticité, réactivité et action). Si action il doit avoir, tout comme les hôpitaux, il faut gérer les priorités de réaction. (1) Mettre hors de danger, (2) Stabiliser et (3) Guérir. Il est important de garder à l’esprit ces différents niveaux de réponses car dans le temps, les différents palier peuvent être très éloignés.
Par exemple, un utilisateur tombe sur une donné vérolée. Premièrement, on corrige CETTE donnée. Ensuite, on lancera un batch pour détecter/corriger d’autres cas identiques, puis sur des cas similaires. Enfin on analysera la cause du problème et on apportera les modifications nécessaires.
Ce principe permet de prendre en compte les demandes de support rapidement, le reste étant de nouvelles actions de la backlog. Actions et backlog qui sont ensuite discutées lors des revues.
Je reviens un peu aux outils car je pense que c’est tout de même un point important dans le sens où : les mails ne sont partagés qu’avec ceux qui sont dans la boucle et il n’y a pas vraiment de trace (difficile voir impossible de faire une recherche sur l’ensemble des demandes de support ou de faire un suivi des statuts des demandes). Il est impossible de faire des statistiques sur l’origine, la cause, la nature ou toutes autres caractéristiques des demandes (y compris sur la réactivité : temps avant prise en charge, avant clôture, etc.).
Là ou je bosse actuellement, on utilise le même JIRA que pour les issues mais on utilise le type “Spike”. Cela permet de justifier pas mal le volume d’activité que cela représente. Et quand on montre cela au client, curieusement les semaines qui suivent on observe une diminution des demandes d’analyse de situation ou d’explication. Les gens (AMO ou key user) deviennent alors enfin autonome.
Là ou je bossais avant on avait une application dédiée. On se contentait de débloquer les situations, le reste étant soit ajouter dans la liste des bugs à corriger, soit transmis à l’AMO comme potentielle “feature”.
