Suivi du temps des développeurs : votre relevé

Le suivi du temps peut être votre relevé personnel de développeur. Aucun plugin d’éditeur ni agent prenant des captures n’est nécessaire.

Le journal peut expliquer pourquoi une petite tâche a mangé la semaine. Il nomme mieux le travail que « trucs divers » et totalise les réunions.

À quoi sert le relevé

Il peut répondre à quatre questions pratiques :

1. Qu’ai-je réellement fait cette semaine ? Lors du bilan, c’est une liste datée, pas « travail sur la plateforme ».
2. Que coûte une tâche en temps ? Comparez estimation et heures pour repérer les éléments oubliés.
3. Où est passée la semaine ? Distinguez fonctionnalités, débogage, revue, réunions et détours techniques. Le total des réunions donne un point concret à discuter lorsque les priorités se disputent le temps. Incluez la préparation si vous voulez leur durée complète.
4. Que facturer ? Si vous facturez directement, gardez des heures avec des notes que le client reconnaît.

Gardez un relevé simple : quoi, pour qui, combien de temps.

Utilisez le suivi manuel, avec quelques particularités du développement.

L’entrée minimale

Gardez une entrée assez courte pour réellement l’écrire :

« PROJ-142 : correction de la condition de concurrence au paiement » reste compréhensible au bilan ou sur la facture. « Code » non.

Si le client ou le responsable peut lire l’entrée, nommez ce qui a été corrigé, livré ou relu dans ses mots. Gardez la bataille avec webpack dans une note privée.

Inutile de reproduire toute l’arborescence du gestionnaire de tickets.

Regroupez le travail par projet ou client, puis marquez débogage, revue et réunions pour comparer entre projets.

Pour une journée simple, une note suffit.

Une journée compréhensible le mois prochain

Voici une journée fictive :

La dernière ligne est estimée à partir des notes et de l’agenda. Un commit ultérieur identifie la tâche sans établir sa durée.

Suivre les séances, pas l’activité de l’éditeur

Un relevé d’activité de l’éditeur laisse deux manques possibles.

Un éditeur ouvert ne prouve pas le travail, et un éditeur fermé ne prouve pas le repos. Lire la documentation, dessiner un modèle de données ou regarder le plafond jusqu’à comprendre le bug font partie de la tâche. Un suivi limité à l’éditeur peut les manquer.

Ensuite, le projet ou l’objectif peut manquer. Un nom de dépôt ou de fenêtre peut identifier le projet. Une documentation commune ne dit pas forcément pour quel client vous cherchez.

Quand les catégories manquent, il faut interpréter après coup. C’est là que le suivi automatique demande votre jugement.

Un journal d’activité peut servir de filet de sécurité à classer ensuite. Utilisez-le pour combler les trous du relevé de séances.

Prenez la séance comme unité. Démarrez en vous mettant à une tâche, arrêtez lors d’un changement de tâche, de réunion ou de client, et mettez en pause aux pauses. Une courte note donne le contexte pour la revue.

Le relevé répond à vos questions. Gardez-le distinct d’une éventuelle surveillance de l’employeur. Limitez vos notes à ce que votre employeur ou votre client vous autorise à noter hors de leurs systèmes.

Retrouver vite une séance oubliée

Un commit ou une pull request rappelle ce que vous faisiez. L’agenda et les messages complètent les indices.

Utilisez-les pour estimer une séance et signalez l’estimation. Deux commits espacés d’une heure ne prouvent pas une heure de travail. Vous avez peut-être fait une pause ou changé de tâche.

Recherche et débogage ne laissent parfois aucun commit. Incluez-les si vous vous en souvenez, sans assimiler tout le travail aux changements de code.

Si aucune estimation utile n’est possible, laissez la durée inconnue. Notez la prochaine séance pendant le travail.

Revoir ses estimations avec les heures

En enregistrant toute la durée d’une tâche, vous pouvez la comparer à l’estimation.

Écrivez l’estimation sur le ticket, suivez puis comparez. Cherchez deux choses sur des tâches comparables :

• La place des étapes oubliées. Si des corrections semblables demandent régulièrement revue et tests supplémentaires, prévoyez-les la prochaine fois. Laissez davantage d’incertitude au travail inconnu.
• L’endroit du dépassement. Comparez code, débogage, intégration, environnement et revue. Si une tendance apparaît, estimez ces parties séparément.

Cela fonctionne aussi au forfait. À la fin, divisez le prix par le total des heures pour connaître le revenu horaire avant frais. Utilisez les heures pour planifier un travail similaire. Vous pourriez confronter le prochain prix aux frais et au revenu souhaité plutôt que de reproduire ce taux.

Noter débogage et reprises pour les clients

Passez cette section si vous ne travaillez pas pour des clients. Ces activités peuvent disparaître dans une entrée vague de développement.

Débogage. Notez la séance et le résultat : « Origine du webhook en double trouvée et corrigée dans le paiement » est compréhensible par le client.

Gardez les tests, le débogage et les reprises séparés si cela aide la revue. Le relevé peut inclure du temps non facturé.

Marquez clairement les reprises pour pouvoir consulter les heures qu’elles ont prises. La distinction facturable ou non aide à organiser le relevé.

Détours. Un conflit de dépendances peut prendre quatre heures malgré une courte description de tâche. Gardez la durée réelle et décrivez l’obstacle.

Si vous facturez un montant moindre, gardez les quatre heures dans le journal. Remplacer la source par « peut-être deux » détruit l’information.

Gardez aussi le travail sans client visible. Propositions, factures et apprentissage d’un framework non demandé viennent de la même semaine. Les omettre sous-estime le temps nécessaire à l’activité.

La place de TimeRetain

Votre relevé contient les systèmes utilisés, les soirées tardives, les réunions et parfois les noms et les tarifs des clients. Vous n’avez pas besoin de le téléverser pour le tenir.

TimeRetain est un chronomètre manuel qui garde ce relevé sur l’appareil. Vous voyez les heures de revue, réunions et débogage, et ce que les séances ont produit. Rien ne surveille l’éditeur.

Si vous facturez, les notes expliquent le travail livré. Gardez les reprises non facturées pour voir le temps réel du projet.

Le relevé principal reste sur votre appareil. La synchronisation facultative conserve une copie chiffrée sur les serveurs de TimeRetain.

Commencer par une semaine

Ne construisez pas tout un système. Pendant une semaine, notez seulement les séances réelles : projet ou client, début, fin et note d’une ligne avec le ticket. Utilisez git et vos notes pour estimer les oublis tant que la journée est encore fraîche dans votre mémoire. Laissez les trous impossibles à étayer.

Relisez. Comparez les réunions à votre impression de la semaine, puis une ou deux tâches à leurs estimations. Si le relevé aide à revoir le travail ou préparer une facture, et si l’effort en vaut la peine, continuez.