Comment rédiger le rapport quotidien des ingénieurs logiciel et des équipes de développement : dépasser le journal des tâches et transformer les écarts d'estimation et les blocages en prochaine étape

Les rapports quotidiens des ingénieurs et des équipes de développement ont tendance à devenir une liste des tâches touchées dans la journée.

Par exemple : « fonction de recherche implémentée », « retours de revue traités », « réunion ».

Garder une trace du travail est important, mais cela seul ne dit pas pourquoi quelque chose a pris plus de temps que prévu, où l'on a été bloqué ni comment l'éviter la prochaine fois.

De plus, les équipes de développement disposent déjà de nombreux endroits où les choses sont consignées.

Les tâches sont dans l'outil de gestion des tickets. Les modifications de code sont dans l'historique du contrôle de version.

Les échanges du quotidien sont dans la messagerie.

Le rapport quotidien ressemble alors facilement à une tâche consistant à recopier une fois de plus le même contenu.

Par exemple, il est rédigé à la hâte en fin de journée, après des heures de travail concentré. Et personne parmi ses lecteurs ne répond.

Si c'est le cas, celui qui écrit finit par se contenter d'une ligne du type « ça avance ».

En termes de PDCA, le rapport s'arrête au Do, la trace de ce qui s'est passé, tandis que le Check et l'Act disparaissent.

Cet article examine comment repositionner le rapport quotidien.

Passer d'une copie du journal de travail à un outil pour revenir sur les écarts d'estimation et les blocages de la journée.

Et les transformer en prochaine étape et en apprentissage pour l'équipe.

Lisez-le comme une réflexion sur le système, et non comme un reproche adressé à quiconque.

Le rapport quotidien d'un ingénieur est plus facile à tenir lorsque les rubriques se limitent à peu près à ceci.

(1) L'objectif du jour, c'est-à-dire quelle tâche on fera avancer jusqu'où.

(2) L'écart entre l'estimation et le temps réel, avec un mot sur la raison plutôt que sur l'ampleur de l'écart.

Par exemple, l'attente de la confirmation d'une spécification, un code existant inattendu ou un environnement défaillant.

(3) Ce qui bloque et ce que l'on veut demander à qui. (4) Ce que l'on a découvert ou appris en essayant.

(5) Les décisions prises en revue ou en réunion qui concernent son propre travail. (6) La première action de demain.

L'essentiel est de ne pas répéter « ce qui a été fait », déjà présent dans les tickets et l'historique des modifications.

Il est de recentrer le rapport sur l'écart et sa raison, les blocages et ce qui a été appris.

À l'inverse, il y a des observations comme « j'ai commencé à écrire sans vérifier les hypothèses de conception et j'ai dû refaire une partie ».

Il y a aussi « en demandant à une collègue plus expérimentée comment lire les journaux, l'erreur a été réglée en dix minutes ».

Elles n'apparaissent ni dans les tickets ni dans l'historique des modifications et ne peuvent être recueillies que dans le rapport quotidien.

Trop de rubriques allongent le temps de rédaction et multiplient les cases vides. Commencez avec environ cinq rubriques et ajustez-les en écoutant l'équipe.

Le format de norolu PDCA comporte cinq parties. P (l'objectif du jour), D (ce qui a réellement été fait), C (ce que l'on a remarqué).

A (ce que l'on fera ensuite) et le P du lendemain.

Voici l'exemple d'un ingénieur qui travaille sur le développement d'une fonctionnalité (un exemple fictif à titre d'illustration).

P : « Amener la fonction de filtrage de l'écran de recherche jusqu'à la revue. » D : « L'implémentation est terminée, mais l'ordre de tri ne correspondait pas à la spécification de la liste existante, et la vérification et la correction ont pris deux heures de plus que prévu. Je n'ai pas pu la soumettre à la revue. » C : « Je n'avais pas vérifié la spécification de l'ordre de tri avant de commencer à écrire. La cause : avancer sur la seule description du ticket. » A : « Pour les travaux qui touchent aux écrans, noter avant de commencer trois points sur lesquels j'aurai probablement des doutes, et les confirmer d'abord avec la personne responsable. » P du lendemain : « Soumettre à la revue dans la matinée. Ne commencer la tâche suivante qu'après avoir noté les points à confirmer. » L'astuce pour faire le lien avec le P du lendemain est d'écrire le A comme une seule chose concrète à faire.

Plutôt que « vérifier plus rigoureusement », écrivez « noter avant de commencer trois points sur lesquels j'aurai probablement des doutes ».

De cette façon, le rapport du lendemain pourra vérifier si cela a été fait. Une à trois lignes par rubrique suffisent.

Il y a les ingénieurs récemment arrivés et les membres moins expérimentés.

Pour eux, le rapport quotidien peut aussi être l'endroit où signaler tôt un blocage au lieu de le porter seul (un exemple fictif à titre d'illustration).

P : « Trouver la cause d'un bogue qui se reproduit dans l'environnement de test. » D : « J'ai cherché la cause toute la matinée sans la trouver. En consultant la responsable d'équipe l'après-midi, j'ai compris que la configuration était chargée dans le mauvais ordre. » C : « Je ne m'étais pas fixé de limite de temps pour chercher seul. Même en sachant qu'il serait plus rapide de demander, je pensais être sur le point de trouver et j'ai laissé passer le moment de parler. » A : « Si je n'ai aucune piste une heure après avoir commencé à chercher, noter ce que j'ai essayé et demander de l'aide. » Écrire sur ses blocages ne sert pas à rapporter ce que l'on ne sait pas faire, mais à permettre à l'équipe de donner un coup de main plus tôt.

Par exemple, la personne qui encadre l'équipe ou un collègue plus expérimenté reconnaît d'abord en une phrase que le membre a demandé de l'aide.

Puis il répond avec un seul indice pour la prochaine recherche. Lorsque c'est le cas, les membres se sentent en confiance pour écrire là où ils bloquent.

Évitez les réponses qui reprochent à quelqu'un d'avoir écrit sur ses difficultés.

Les équipes de développement disposent déjà de registres établis.

Il y a les tickets qui suivent l'avancement des tâches, l'historique des modifications de code et les traces de revue.

Il y a aussi les registres de traitement des incidents et des bogues, et les relevés de présence.

Chacun est tenu à sa place, selon les règles de l'entreprise et les procédures fixées. Le rapport quotidien ne les remplace pas.

Considérez que décrire le déroulement d'un incident dans un rapport quotidien n'en fait pas un registre officiel de l'incident.

Le partage de base est le suivant.

Les faits relatifs à chaque tâche ou bogue vont dans les registres établis, comme les tickets, selon les procédures fixées.

Le rapport quotidien, lui, rassemble les actions, les observations et les prochaines étapes de l'équipe elle-même.

Lorsque le rapport quotidien mentionne ces registres, le numéro du ticket ou une courte mention comme « consigné dans le registre d'incidents » suffit.

Tracer cette limite dès le départ réduit la charge d'écrire deux fois la même chose.

Cela préserve aussi le rapport quotidien comme un espace de réflexion plutôt qu'un rapport d'avancement en double.

Pour savoir quels registres tenir et où, suivez les règles de votre entreprise et le jugement de la personne responsable.

Dans la rubrique C apparaissent parfois des notes comme « l'environnement de production semblait plus lent que d'habitude ».

Il y a aussi des notes comme « j'ai trouvé des informations d'authentification écrites en clair dans un fichier de configuration ».

Ne les laissez pas s'arrêter au rapport quotidien ; reliez-les aux procédures de réponse fixées par l'entreprise ou l'équipe.

Lorsque vous remarquez un incident possible ou quoi que ce soit lié à la sécurité, n'attendez pas de rédiger le rapport quotidien.

Lorsque c'est le cas, prévenez sur-le-champ la personne qui encadre l'équipe ou la personne responsable.

Suivez aussi les procédures de votre entreprise et le jugement de cette personne.

Il importe aussi de ne pas trancher la cause ni l'étendue de l'impact dans le rapport quotidien.

Il est rassurant, en outre, de tenir hors du rapport quotidien les mots de passe, les clés et les informations d'accès.

Il en est de même pour les données personnelles des utilisateurs ou les données confiées par des partenaires commerciaux.

Le rapport quotidien est le point où l'on remarque quelque chose ; ce n'est pas la réponse elle-même.

Une courte ligne comme « signalé à la responsable d'équipe » permet au lecteur de vérifier que cela a bien rejoint la réponse officielle.

La personne qui encadre l'équipe lit chaque jour les rapports des membres. Vouloir tous les lire en détail n'est pas tenable.

Commencez par le A (ce que l'on fera ensuite).

Puis regardez le C (ce que l'on a remarqué) et les blocages pour repérer ce sur quoi vous devez aider ou ce qui demande une décision aujourd'hui.

Les commentaires sont plus faciles à tenir lorsqu'ils reconnaissent un fait et ajoutent une seule question ou une seule prochaine étape.

Par exemple : « Bonne idée de noter avant de commencer les points qui pourraient poser question. Dis-moi combien il y en a eu sur la tâche de demain. » Dans les équipes qui travaillent beaucoup à distance, traiter le rapport quotidien comme un outil pour repérer tôt les blocages, et non pour surveiller les heures de travail, est la condition pour que chacun écrive sincèrement.

Une fois par semaine, mettez côte à côte les rapports de la semaine et revenez dessus.

En discuter au format KPT (Keep, Problem, Try) transforme l'observation d'une personne en amélioration de la façon de travailler de l'équipe.

C'est pour voir si le même type de reprise ou d'écart d'estimation se répète et ce qu'ont donné les idées essayées.

Avec la synthèse hebdomadaire de norolu PDCA, vous pouvez aussi revoir d'un coup une semaine d'observations.

Même si un rapport manque un jour, commencez par en demander la raison plutôt que de reprocher.

Vérifiez aussi si les rubriques et le moment de rédaction conviennent à la façon dont l'équipe développe.

Dans norolu PDCA, l'IA est une assistante qui aide à rédiger des brouillons de rapports, à poser des questions qui invitent à la réflexion et à produire des synthèses hebdomadaires.

Cette limite ne change pas dans une équipe de développement. L'IA peut mettre en forme les notes brèves d'un membre.

Elle peut aussi repérer les blocages et les reprises qui reviennent sur une semaine de rapports.

Mais il y a des décisions, comme modifier les priorités des tâches, réviser les estimations ou confier tel travail à telle personne.

Elles sont prises par la personne qui encadre l'équipe ou la personne responsable.

Il est rassurant de tenir hors du rapport quotidien les informations qui ne doivent pas sortir de l'entreprise.

Par exemple, les mots de passe, les clés et les informations sur les utilisateurs ou les partenaires commerciaux.

De plus, norolu PDCA est conçu pour que les données des rapports quotidiens soient enregistrées dans le propre Google Drive (feuille de calcul).

C'est le Drive de l'entreprise qui l'utilise, c'est-à-dire la vôtre.

C'est selon une approche de conservation minimale des données qui n'accumule pas d'informations de notre côté.

Le séparer des enregistrements établis, utiliser un format court et continuer à écrire des rapports qui reçoivent une réponse.

Nous pensons que cette habitude régulière est la base pour transformer les petits blocages et apprentissages de chaque jour en prochaine étape.

Nous pensons qu'elle est aussi la base pour les transformer en une meilleure façon de développer en équipe.