Être comptable de son temps

Je vous conseille de commencer par la lecture du billet précédent, dont celui-ci est la suite : 2 à 3 heures par jour

En voyant les ingénieurs de SSII remplir des fiches de temps heure par heure, je ne peux m’empêcher de me dire que nous sommes au mieux dans une hypocrisie partagée, plus probablement dans une simple démarche perdant-perdant.

Être comptable

En société de services informatiques on découpe généralement les projets en tâches, chacune estimée en heures. Les heures sont additionnées naïvement et huit tâches d’une heure tiennent tout à fait dans la journée d’un développeur qui travaille 40 heures par semaine.

Le développeur a pour obligation de « saisir ses temps », c’est à dire de saisir heure par heure sur quelle tâche il travaille. Je n’ai jamais vu ces imputations utilisées pour surveiller le travail ou faire du flicage mais la pression négative reste forte : Le développeur doit affecter chaque heure de travail à une tâche. Une tâche qui a reçu suffisamment d’heures de travail doit logiquement être terminée et livrée.

L’équation malsaine heure de travail = heure passée sur une tâche productive devient vite insoluble pour ceux qui sont dans la même situation que moi. On finit toujours par s’arranger, souvent en rendant les imputations en retard mais ça occupe un temps conséquent pour soi et pour le chef de projet qui relance. Ça agace, énerve et épuise tout le monde, et occupe l’esprit à faire des jeux comptables administratifs tout en donnant un sentiment flottant de culpabilité ou de tricherie.

Certains comptent en dixièmes de journée mais c’est presque pire : Comme le chef de projet sait compter, une tâche de 2h est codée 0,25 et on en a quatre dans la journée.  La différence c’est qu’il est beaucoup plus difficile de considérer avoir passé les heures qu’il faut et rentrer chez soi en se disant « tant pis, ça prendra plus de temps » (ça fonctionne dans un seul sens, si le développeur termine plus tôt, il n’a pas le droit de partir pour autant, il commence la tâche suivante). Le seul gain c’est d’ajouter un peu plus de pression sur le développeur.

Attentes réalistes, meilleurs résultats

J’ai vu les choses tout autrement après avoir travaillé à Yahoo! On s’affectait l’équivalent de 4 heures de travail par jour uniquement, et personne n’était gêné que d’entendre « je n’ai rien fait ou presque ces deux derniers jours, je n’ai pas été productif » au point de synchro du matin tant que le travail était collectivement fait à la fin du mois.

On peut facilement imaginer que ce serait la porte ouverte à des productivités mensuelles lilliputiennes voire à des abus, mais ça a probablement été la période la plus productive de ma vie de développeur.

La vérité c’est simplement qu’en attendant huit heures de travail par jour, mes autres employeurs ont en réalité diminué ma productivité mensuelle. J’ai passé une dose significative de mon énergie dans les autres entreprises à être comptable et à lutter contre le système.

À la décharge de mes employeurs, j’ai pourtant toujours été dans des situations avantageuses avec des tâches fourre-tout et des positions de force qui m’ont permis d’être peu soumis au même régime que les autres. Je n’ose penser la galère que c’est pour celui qui a un poste de développeur plus classique.

Tenter le 4 heures par jour

L’idée qu’un développeur peut faire huit ou même sept tâches d’une heure dans une journée de huit heures est totalement irréaliste. Dans la réalité ce sont la qualité ou l’épuisement des collaborateurs qui servent de variable d’ajustement, parfois les deux.

Si vous avez des développeurs responsables et motivés, vous pouvez essayer de partir sur des imputations tâche à tâche et heure à heure avec une référence explicite à quatre ou cinq heures productives par jour. Pour lisser les périodes plus ou moins actives il faudra accepter de ne regarder cette métrique qu’en agrégeant par semaine ou par quinzaine. Second point d’attention : il faut que toute la hiérarchie accepte de jouer le jeu, sinon on court à la catastrophe au premier écueil projet.

Ou lâcher prise sur les imputations

Si la situation est moins idéale que ça, si le management risque de ne pas jouer le jeu jusqu’au bout, ou simplement si l’équipe ne pense pas fonctionner sur ce rythme d’un faible nombre d’heures productives par jour, on peut imaginer un scénario plus proche des habitudes :

L’imputation se fait au niveau du projet et pas au niveau de la tâche, avec par blocs d’une journée ou demie journée. Parfois une demie journée n’aura quasiment pas été productive, parfois elle le sera exceptionnellement, mais on ne fera pas de différence : la précision sera globalement suffisante pour le reporting comptable et administratif (le contrôle de gestion, la facturation, l’éventuel crédits impôts-recherche).

De l’autre côté l’avancement projet est fait en mesurant … (attention c’est révolutionnaire) l’avancement du projet, et pas le temps travaillé. Ça semble enfoncer les portes ouvertes mais c’est encore assez rare comme pratique.

Quant au suivi des développeurs eux même c’est un point RH chaque semaine. Ce qu’apporte un développeur à une équipe ne pourra jamais être chiffré en heures de travail ou en nombre de tâches affectées.

Une dernière mise en garde

En plus du rappel du billet précédent, je m’adresse à ceux qui veulent créer des équipes de développeurs compétents, responsabilisés et motivés. Si vous montez consciemment des équipes avec des ouvriers développeurs qui font du travail à la chaîne, passez votre chemin.

Enfin, chacun a son propre mode de fonctionnement. Je me contente de me baser sur le mien et sur ce que j’ai vu autour de moi. Je ne prétends pas que ça fonctionnera pour quiconque d’autre. Par contre je suis convaincu de la nécessité de jeter ou réformer et le système d’imputation des SSII et l’idée qu’on peut mettre pour huit heures de travail dans une journée.

Rejoindre la conversation

10 commentaires

  1. J’approuve. En passant l’année dernière resp du pole web, tout en gardant des activités de production par ailleurs sur d’autres projets, j’ai assez vite considéré que grosso modo, je pouvais aller au max 3 jours à mes activités de production. Les 2 autres jours étaient dédié aux suivi de l’équipe, réunions, reporting, etc.

    Ainsi, j’étais beaucoup moins frustré et plus en phase avec mes activités. Le tout est d’avoir le courage et l’honnêteté de l’admettre plutot que de croire que l’on peut faire ses 5 jours de prod – qqs heures de réunions.

  2. Passé free récemment, je me suis mis à compter mes heures productives sur chaque projet, tout en notant les à côté (veille, recherches, projets persos, etc). Globalement je travaille de 5 à 9h par jour, avec de 3 à 5h réellement productives (ie. qui font gagner de l’argent). Sans me forcer à rien, c’est venu naturellement comme cela.

    Parfois cependant ce temps non productif est utilisé pour de la recherche ou de l’expérimentation, ou en prévision sur le projet lui-même, transformant ces à côtés en heures productives :)

  3. Intéressant… mais je pense que vous n’allez pas assez loin.

    Je pense que le fait de vouloir planifier de façon aussi précise un projet informatique, c’est juste n’importe quoi. Ou en tout cas ça ne sert pas à ce à quoi c’est censé servir.

  4. Je ne fais pas de développement, mais je suis indépendante. Indépendante du genre qui ne facture pas à l’heure, mais plutôt « en bloc ». 1 journée de formation, une séance de consulting, être la rédac’-chef de votre blog, etc.

    L’an dernier j’ai commencer à compter un peu mes heures, pour moi, pour savoir combien de temps je passais sur un projet spécifique, et pour apprendre à mieux me gérer.

    Je me souviens d’une semaine où j’ai bossé d’arrache-pied, finissant mes journées crevées, bossant même après souper (ce que je ne fais normalement jamais). J’étais très déprimée en regardant le total de mes heures: misérablement, même pas 35 heures.

    C’est là qu’une amie m’a rappelé qu’une personne n’est normalement pas productive plus de 5-6h par jour de travail normal, et que j’avais compté uniquement mes heures effectives.

    Quand j’ai des phases de creux, il m’arrive d’utiliser la stratégie suivante: je ne travaille que le matin, de 9h à midi. L’après-midi je prends congé. Souvent, je fais plus durant ces 3 heures le matin (où je me concentre un peu) que sur une journée entière un peu molle.

  5. Ayant fait les deux, je ne pense pas que l’on puisse comparer le travail d’un indépendant à celui d’un développeur.
    Si vous pratiquez les méthodes agiles, en tant que développeur au sein d’une équipe il y a normalement une personne censée éliminer tout ce qui pourrait perturber votre travail.
    En tant que dev. et avec pomodoro je dépassais rarement 14 itérations de 25min par jour, le reste de mon temps temps était employé pour faire des recherches, répondre aux mails…
    En tant qu’indépendant la nature des tâches étant beaucoup plus variée, c’est difficile de se concentrer une journée entière sur la même chose : on papillone beaucoup plus. Dans mon cas une semaine type est : 35h de « production », 35 de veille et formation, et jusqu’à 20h de gestion et administratif.
    En alternant les 3 « types » de tâche, je pense qu’on peut maintenir ce rythme plus longtemps. L’idée n’est pas de faire 2 taches d’une heure puis… mais plutot de faire 2h de production (et toutes les tâches qu’on peut dans cette timebox) puis 2 h de veille… quitte à interrompre une tache en cours.
    La raison est que notre cerveau s’habitue à un type d’activité à un moment de la journée, le tout étant de s’adapter le plus possible à son rythme naturel. par ex. lecture après manger à cause de la digestion… Si je peux émettre un autre conseil c’est d’être attentif à son alimentation (notamment la consommation de sucres) et au sommeil. in hope it helps

  6. Merci pour ce billet :)

    Je suis complètement d’accord avec le billet et les commentaires. Mais je reste sur sur une problématique : combien vaut mon travail ? Si je dois évaluer un temps pour une mission, par exemple 3 jours de code temps plein, raisonnablement et d’après tes évaluations je devrais vendre 6 jours minimum ?

    Sur 3 jours c’est encore jouable, mais sur 3 semaines ?

    1. Comme je disais, le compte du temps pour un indépendant est forcément différent. Je serai mal placé pour répondre.

      1. La problématique est la même dans une petite entreprise ou pour un indé. « Combien de temps pour ce boulot ? » Le dev va répondre, convaincu (et n’ayant pas lu ton billet), 15 jours pleins. La réalité, et tu en parle très bien, c’est que le mac va passer 2 mois sur le projet. Entre coup de blues et irritations du client le projet s’enfonce, les relations se tendent.

        La difficulté est de savoir combien vaut réellement son travail. « T’as besoin de 30 jours ? Je vends 30 jours » la qualité a ce prix … douce utopie …

        Mais je pense que dans une plus grosse boîte le problème n’est pas le même, les coûts/pertes/gains sont mutualisés.
        C’est sans doute plus aux décideurs de ces boîtes que ton billet est destiné j’imagine.

Laisser un commentaire

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

À propos de ce site, du contenu, de l'auteur
Je poste parfois ici des humeurs ou des pensées. Parfois je change, parfois je me trompe, parfois j'apprends, et souvent le contexte lui-même évolue avec le temps. Les contenus ne sont représentatifs que de l'instant où ils ont été écrits. J'efface peu les contenus de ce site, merci de prendre du recul quand les textes sont anciens. Merci

À toutes fins utiles, ce site est hébergé par OVH SAS, joignable par téléphone au +33 (0)9 72 10 10 07 et dont le siège social est au 2 rue Kellermann, 59100 Roubaix, France.