A quoi devrait ressembler le rapport journalier d’un développeur freelance ?

A quoi devrait ressembler le rapport journalier d’un développeur freelance ?

Oui tout le monde le sait, les développeurs n’aiment pas écrire… S’ils aiment faire un travail méticuleux, ils ont horreur de prouver ce qu’ils valent… Il m’est souvent arrivé de voir un collègue développeur qui commence à remballer ses affaires avec le visage satisfait de quelqu’un qui a bien fait son travail ; sauf que son travail est encore en local car il/elle a juste oublié de le pousser sur Github !

Quand on travaille à distance, ça devient encore plus important, il ne suffit plus de seulement pousser son travail, il faut aussi informer de ce qui a été fait.

Les développeurs travaillent dur, ils ont besoin de concentration et peuvent parfois oublier des « détails » comme la communication. Pourtant, la communication est vitale pour le reste de l’équipe.

Une (1) bonne habitude

Pour ce faire, il suffit d’une bonne habitude qui renforce le lien de confiance entre vous et vos collaborateurs: Le rapport journalier.
Le rapport journalier d’un développeur freelance se veut concis mais complet, il permet de dire où on en est, et ce sur quoi on va travailler ensuite.

Pour cela votre compte rendu devrait être :

  • Informatif (Informations générales sans rentrer dans le détail)
  • Visuel (Autant que possible)
  • Régulier (Ne jamais oublier un jour)
  • Structuré (Toujours fournir le même niveau d’information)

Exemple d’un mauvais rapport :

Mauvais rapport journalier

Voici une bonne structure :

Bon rapport journalier pour développeur freelance

Dans le deuxième exemple, on peut voir ce qui a été fait, les difficultés rencontrées et on imagine déjà ce qui va être fait demain.

Attention à l’aspect visuel, il est très important. Spécialement pour les personnes qui ne sont pas techniques… Je sais ce que vous allez me dire : en montrant un travail en cours, on a parfois des retours négatifs : « Est-ce qu’on va être dans les temps, les deadlines approchent? » , « C’est encore moche » etc. Pourtant c’est comme ça que vous allez créer une relation de confiance et démontrer la progression du projet.

Il y a toujours moyen de fournir un visuel, même une impression d’écran du terminal si le projet est encore en phase initiale. Ce qui est important encore une fois c’est de rassurer et de montrer l’évolution.

Une fois que le lien de confiance est créé, vos collègues ou clients vous poseront moins de questions, c’est aussi simple que cela. Fournir un rapport de manière proactive sans qu’il soit demandé est une excellente manière pour que vos collègues / clients vous fassent de plus en plus confiance.

Mais allons plus loin :

Et si vos rapports devenaient la documentation du projet ?

L’idée est simple : l’habitude de faire des rapports journaliers, créé naturellement un historique du projet. Pendant le développement, les objectifs sont clairs, les difficultés et l’idée initiale sont en mémoire. Mais une fois le projet livré, qu’en est-il ?

Ce projet rencontrera (peut-être) quelques bugs, la sécurité pourrait avoir besoin d’évoluer, et le marché et les utilisateurs imposeront des modifications. Ces modifications pourront être effectuées par vous, vos collègues ou un nouvel acteur ; mais dans tous les cas, les commentaires dans votre code pourraient ne pas être suffisants. Et fournir les échanges, les questions, les risques détectés et l’ordre dans lequel le développement a été fait ne pourra que faciliter l’évolution du projet dans le temps.

C’est vous et vous seul qui pouvez savoir de quoi vos successeurs auront besoin. La base de connaissance créée par ces rapports s’ajoutera donc la documentation du projet.

En pratique:

Rapport journalier d'un développeur freelance

La prochaine fois que vous vous apprêtez à faire un rapport journalier, voici quelques questions à vous poser :

« Comment démontrer à l’écrit la progression de mon travail ? Comment le faire visualiser à mon/mes interlocuteur(s) ? Est-ce que mon rapport est aussi informatif, imagé et bien écrit que mon rapport précédent ? »

Si vous êtes l’initiateur de ces rapports, de cette documentation, vous deviendrez alors un exemple, celui/celle qui met la barre plus haute. Vous créerez une relation de confiance dans laquelle les difficultés se partagent et deviennent un challenge de groupe, dans laquelle les défis se relèvent a plusieurs. Vous serez moins sollicité par vos collègues car ils sauront qu’ils peuvent vous faire confiance.

C’est ce genre de détails qui fait les grands développeurs.

1 réponses
  1. Bonjour Boris, merci pour votre réponse, effectivement c’est intéressant de lister les questions en suspens. Dans un environnement Scrum ça permettra au product owner de répondre lors du prochain stand-up meeting.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *


id quis, id justo Lorem dolor ultricies leo Donec