slideshare quotation-marks triangle book file-text2 file-picture file-music file-play file-video location calendar search wrench cogs stats-dots hammer2 menu download2 question cross enter google-plus facebook instagram twitter medium linkedin drupal GitHub quotes-close

Création d'un ticket approprié

Si vous avez un contrat d'assistance avec Code Enigma, vous pouvez poser à notre équipe pluridisciplinaire toute question relative à nos services par le biais de notre système de tickets sécurisé, Redmine.

Vous pouvez également accéder à Redmine par l'intermédiaire du client dashboard.

L'objet

Le but de l'objet est de nous dire quel est le problème. Si, par exemple, vous avez un module qui attribue des points aux utilisateurs en fonction de leur activité sur le site, qui renvoie des résultats incorrects ou une erreur fatale, un bon sujet de ticket serait : Le module personnalisé de points d'utilisateurs renvoie une erreur fatale.

Cette description est suffisante pour que le support puisse comprendre le problème. Signaler le problème avec le sujet "Bug" ou "Erreur fatale" sont des sujets médiocres car ils ne sont pas descriptifs.

La description

Veuillez inclure tous les détails possibles sur le problème. Les captures d'écran des erreurs et les entrées du journal des erreurs aident l'équipe d'assistance à comprendre ce qu'elle doit rechercher lorsqu'elle tente de reproduire le problème.

Incluez les URL où les erreurs se produisent, ou expliquez de manière aussi détaillée que possible ce que vous faisiez au moment où vous avez reçu les erreurs. Le fait de fournir la date et l'heure auxquelles une erreur s'est produite peut également aider l'équipe d'assistance à localiser les informations relatives à l'erreur dans les logs du serveur.

Il serait également utile d'inclure des informations sur l'environnement dans lequel le problème se produit (si vous avez une configuration de type dev/stage/prod).

Détaillez les étapes que vous avez entreprises pour tenter de résoudre le problème, afin d'éviter que l'équipe d'assistance ne répète les mêmes étapes et n'obtienne les mêmes résultats. Vous devez inclure les étapes permettant de reproduire le problème, car cela aidera l'équipe d'assistance à le déceler.

Choisir le bon tracker

Deux traqueurs sont disponibles, Task (Systems) et Task (Dev Support). Si votre ticket est lié à l'application elle-même, par exemple Drupal, WordPress, sélectionnez Task (Dev Support), sinon, sélectionnez Task (Systems).

Si vous n'êtes pas sûr de savoir quel tracker choisir, laissez le tracker par défaut, et l'équipe de support le changera si nécessaire. 

Attribution du ticket

Lors de la création du ticket, une notification sera envoyée à l'équipe de support, l'avertissant qu'un nouveau ticket a été créé. Nous recommandons, dans la plupart des cas, de ne pas assigner les tickets afin qu'ils puissent être attribués au prochain membre disponible de l'équipe. Si vous souhaitez ajouter un destinataire au ticket, veuillez NE PAS l'attribuer directement à une personne. Dans ce cas, vous pouvez utiliser les groupes 'ce' (ceSysadmins, ceSupport).

Vous pouvez ajouter des observateurs "Watchers" à un ticket en cochant les cases correspondantes. Chaque Watcher que vous sélectionnez recevra une notification par courriel pour l'informer qu'il a été ajouté comme observateur à un ticket. Il n'est pas conseillé de sélectionner tout le monde, car certains membres du personnel ne seront pas au courant de votre projet.

Si vous considérez que le problème est urgent, il est conseillé d'ajouter plusieurs observateurs, afin qu'ils soient informés de la création du ticket. Cependant, un problème que vous considérez comme urgent peut ne pas entrer dans notre catégorie "Urgent". Tous les tickets relatifs à Drupal seront traités dans les 24 heures. Si vous ne disposez pas d'un pack de serveurs couverts par un accord de niveau de service (SLA), les paramètres de priorité auront été convenus au préalable avec vous, ainsi que leurs délais de réponse respectifs (nous y reviendrons dans la section suivante). Les tickets qui relèvent de ce SLA sont des problèmes liés au serveur.

Status

Lorsqu'une tâche est créée, elle suit le flux de travail suivant:

  • New - Un problème créé mais pas encore traité
  • In progress - Les travaux ont commencé
  • Blocked - Progression bloquée pour une raison donnée
  • Approved, waiting to go live - La solution a passé l'épreuve de l'UAT et est maintenant en attente de publication.
  • Resolved - En live, le ticket en attente est fermé (généralement par le client).
  • Closed - La question est close
  • Closed (due to inactivity) - Après 7 jours écoulés sur un ticket en état résolu, le ticket sera fermé automatiquement.

Les "Icebox"

Il est important de noter ici que chaque client dispose d'une glacière, "icebox", et qu'il est très important de l'utiliser. Nous voulons traiter le plus grand nombre de tickets possible, mais chacun d'entre eux prend du temps. Si un ticket ne se trouve pas dans l'Icebox, nous partons du principe que vous souhaitez que nous y consacrions du temps. Si cela devait épuiser le temps restant de votre contrat de support mensuel ou introduire des frais de paiement, vous le verriez dans votre aperçu (sous "Heures restantes"). Donc, si vous préférez donner la priorité à autre chose, ou garder ce temps pour une urgence, vous devez déplacer la demande dans votre "icebox". Pour ce faire, vous pouvez mettre à jour la question, en changeant le projet de Support à Icebox.

Priorités

Redmine propose quatre priorités au choix : Faible, Normal, Haut et Urgent. La priorité du ticket est généralement utilisée pour juger uniquement de l'ordre dans lequel les tickets doivent être examinés. Par exemple, si vous avez trois tickets de priorité normale, deux tickets de haute priorité et un ticket de basse priorité, les deux tickets de haute priorité seront examinés en premier, puis, s'il reste du temps de support, les tickets de priorité normale seront examinés. S'il reste du temps d'assistance après l'examen de tous les autres tickets, les tickets de faible priorité seront examinés et traités.

Urgent – Une défaillance critique, entraînant une interruption des services destinés aux clients.

Des informations complètes sur les délais de réponse sont disponibles dans notre SLA (accord de niveau de service)

High – Un problème grave, entraînant des désagréments pour les utilisateurs, par exemple:

  • Le serveur de recherche Solr cesse de fonctionner
  • Certains styles d'images ne sont pas générés
  • Les services externes (par exemple, un dépôt SFTP ou une API) ne peuvent pas fonctionner correctement en raison d'une défaillance du serveur
  • Un rédacteur ne peut pas créer de contenu et doit respecter un délai critique.

Normal – Un problème mineur, par exemple:

  • Un problème avec un service qui n'affecte pas l'expérience du client.
  • Une tâche cron doit être créée
  • Une assistance est nécessaire pour gérer un composant du serveur
  • Un éditeur ne peut pas créer de contenu

Low – Une tâche de maintenance ou un travail planifié, par exemple:

  • Le lancement d'un nouveau site
  • Le lancement d'un nouveau service ou d'une nouvelle fonctionnalité
  • La création d'un nouveau compte utilisateur pour un serveur/une application
  • Une mise à jour d'un paquet
  • Une nouvelle tâche d'intégration continue.

La première réponse sera donnée dans les délais convenus, en fonction de la priorité.

Mauvais exemples

Nous avons reçu des tickets dont l'objet était "Bug", "Ticket urgent" ou "Aide". 

Les descriptions qui ne contiennent pas assez d'informations, comme le fait de ne pas fournir les URL où les erreurs ont été trouvées ou de ne pas fournir les étapes nécessaires pour reproduire la ou les erreurs, ne sont que deux mauvais exemples de description de ticket.

De tels tickets prennent plus de temps à traiter car nous devons demander au client plus d'informations pour pouvoir déceler le problème.

Mise en page du texte

Vous pouvez formater le texte dans le champ de description. Vous pouvez mettre le texte en gras, souligné, en italique, créer des listes ordonnées et non ordonnées, des titres et des tableaux, parmi beaucoup d'autres choses. Vous pouvez utiliser ce guide pour vous aider à formater le texte dans Redmine.

Un regard plus approfondi sur Redmine

Maintenant que vous connaissez les bases, nous vous invitons à consulter notre article de blog sur Redmine pour les clients actuels de l'assistance technique, où vous pourrez découvrir comment gérer au mieux vos projets avec nous.