Décrire un worklog dans Jira sans écrire un roman

Une formule simple : action, périmètre et état

[Action réalisée] sur [partie précise du travail]. [Résultat vérifié ou point en attente, si cela apporte du contexte].

Par exemple :

Vérification des filtres de date de l’export. Cas de l’intervalle vide testé. Validation du changement de mois en attente.

La phrase situe l’activité et son état. Elle ne présente pas le ticket comme résolu et ne reprend pas ses consignes. La feuille de temps n’a pas besoin du making-of.

Il s’agit d’une proposition de rédaction de Sync4us. Les règles de l’équipe déterminent le niveau de détail nécessaire et l’endroit où enregistrer chaque activité.

Ce qui mérite de figurer dans la description

Un verbe qui raconte ce qui s’est passé

Analyser, préparer, vérifier, tester et corriger décrivent des travaux différents. « Avancement » laisse presque toute l’explication à fournir.

Si le travail s’est limité à une investigation, il faut le préciser. Une recherche sans solution reste du travail. Inutile de la déguiser en correction terminée.

La partie précise qui a été traitée

« Tests des filtres de date » apporte davantage que « tests ». Recopier le titre du ticket dans chaque entrée apporte peu si cela ne permet pas de distinguer une session d’une autre.

Le ticket explique le problème. La description du worklog explique l’activité réalisée pour cette entrée de temps.

L’état, lorsqu’il facilite la compréhension

Un défaut reproduit, une modification préparée et une validation terminée sont trois situations différentes. « En attente de revue » peut éviter plus de confusion que trois paragraphes d’historique.

La durée, la date et l’heure ont leurs propres champs. Une phrase impeccable ne corrige pas une entrée enregistrée au mauvais mardi.

Pour créer l’entrée, Atlassian indique Plus d’actions > Log work ou le champ de suivi du temps. Les libellés et les options peuvent varier selon le site. Documentation sur l’enregistrement du temps.

Avant de chercher la phrase parfaite, rassembler la journée

Le blocage commence souvent avant la rédaction : les activités, leurs durées et les tickets correspondants ne sont pas réunis.

Manuellement, la vérification peut se faire ainsi :

1. Rassembler les références disponibles : notes, relevés et calendrier. Un rendez-vous prévu ne prouve pas à lui seul le temps effectivement travaillé.
2. Séparer les activités et les interruptions. Vérifier ce qui correspond à chaque ticket et éviter les chevauchements.
3. Vérifier la date et la durée, rédiger la description et contrôler ce qui figure déjà dans Jira avant d’ajouter une entrée.

Un tableau ou une liste conviennent s’ils permettent cette vérification. En l’absence de référence fiable, il faut clarifier la durée selon les règles de l’équipe, sans présenter une estimation comme une mesure exacte.

Sync4us permet d’organiser cette journée en blocs et de vérifier les éléments préparés pour Jira avant de confirmer l’envoi. L’intérêt est de pouvoir passer en revue les activités, leur destination, leur date et leur durée en gardant le travail sous les yeux. La description se rédige avec ce contexte.

Six exemples : avant et après

Tous les textes et toutes les situations sont fictifs. Les versions proposées ne conviennent que si elles décrivent ce qui s’est réellement passé.

Une tâche, une interruption et vingt minutes qui apparaissent deux fois

Cette matinée fictive paraît facile à comptabiliser :

Cela donne 60 minutes d’analyse et 20 minutes d’assistance : 1 h 20 min. Enregistrer toute la période comme de l’analyse, puis ajouter la demande d’assistance, compterait vingt minutes deux fois.

La comptabilité vient de recruter du temps que personne n’a travaillé.

La correction manuelle consiste à séparer les durées et à vérifier la destination de chaque activité. Si l’équipe autorise le regroupement des sessions d’analyse, la description pourrait être :

Analyse du défaut d’export en deux sessions. Reproduction de l’intervalle vide et préparation du prochain cas de test.

Si des entrées séparées sont exigées, chaque session conserve la sienne. L’assistance garde ses vingt minutes et son explication.

Dans Sync4us, il est possible de préparer les blocs de cette matinée, de vérifier leurs durées et de contrôler quel ticket Jira recevra chaque entrée. Ensuite, la personne examine l’aperçu et confirme l’envoi. Elle fournit le contexte et décide de ce qui doit être enregistré.

C’est là l’intérêt : une meilleure description aide, mais elle ne remet pas à elle seule de l’ordre dans une journée dispersée.

Pour la vérification manuelle complète, consulter le guide de vérification des heures dans Jira.

Expliquer l’activité sans coller les documents de travail

« Vérification de la configuration d’accès » décrit une action. Coller des mots de passe, des jetons, des données personnelles inutiles ou des informations clients peut ajouter du contenu dont l’entrée n’a pas besoin.

Les détails restent à l’endroit autorisé. Une référence interne ne s’inclut que si elle convient aux personnes pouvant consulter le worklog. Un chemin de fichier ou le nom d’un document peuvent également révéler des informations.

Un worklog ne doit pas être présumé privé. Son accès dépend des autorisations et, lorsqu’elles existent, des restrictions de visibilité par groupe ou par rôle. Cela ne garantit pas la confidentialité et n’autorise pas n’importe quel contenu. Autorisations et visibilité des worklogs.

En cas de doute sur les destinataires ou les informations autorisées, il faut consulter la personne responsable avant d’enregistrer.

Si une description incorrecte a déjà été enregistrée

La première étape consiste à retrouver l’entrée. En créer une autre ne corrige pas la précédente et peut doubler le temps.

Atlassian distingue les autorisations de modification des worklogs personnels de celles portant sur les worklogs d’autres personnes. Pouvoir enregistrer du temps ne signifie pas pouvoir corriger toutes les entrées. Autorisations de suivi du temps.

Le guide pour modifier ou supprimer un worklog présente la démarche. Si des informations inappropriées ont été incluses, la procédure interne s’applique également : modifier le texte ne permet pas de savoir ce qu’il est advenu d’éventuelles copies antérieures.

Checklist à copier avant d’enregistrer

[ ] Les activités sont réunies et correspondent au travail réalisé.
[ ] Chaque entrée indique le bon ticket Jira, la bonne date et la bonne durée.
[ ] Les interruptions ne sont pas également comptées dans une autre activité.
[ ] La description explique l’action, le périmètre et l’état lorsque cela apporte du contexte.
[ ] Le texte évite les identifiants d’accès et les données inutiles à l’entrée.
[ ] Les références et le niveau de détail respectent les règles de l’équipe et les destinataires prévus.
[ ] Les éléments déjà présents dans Jira sont vérifiés avant d’ajouter une entrée.
[ ] Après l’enregistrement, l’entrée est contrôlée dans le journal de travail.