Être comp­table de son temps

Je vous conseille de commen­cer 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’em­pê­cher de me dire que nous sommes au mieux dans une hypo­cri­sie parta­gée, plus proba­ble­ment dans une simple démarche perdant-perdant.

Être comp­table

En société de services infor­ma­tiques on découpe géné­ra­le­ment les projets en tâches, chacune esti­mée en heures. Les heures sont addi­tion­nées naïve­ment et huit tâches d’une heure tiennent tout à fait dans la jour­née d’un déve­lop­peur qui travaille 40 heures par semaine.

Le déve­lop­peur a pour obli­ga­tion de « saisir ses temps », c’est à dire de saisir heure par heure sur quelle tâche il travaille. Je n’ai jamais vu ces impu­ta­tions utili­sées pour surveiller le travail ou faire du flicage mais la pres­sion néga­tive reste forte : Le déve­lop­peur doit affec­ter chaque heure de travail à une tâche. Une tâche qui a reçu suffi­sam­ment d’heures de travail doit logique­ment être termi­née et livrée.

L’équa­tion malsaine heure de travail = heure passée sur une tâche produc­tive devient vite inso­luble pour ceux qui sont dans la même situa­tion que moi. On finit toujours par s’ar­ran­ger, souvent en rendant les impu­ta­tions 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’es­prit à faire des jeux comp­tables admi­nis­tra­tifs tout en donnant un senti­ment flot­tant de culpa­bi­lité ou de triche­rie.

Certains comptent en dixièmes de jour­née mais c’est presque pire : Comme le chef de projet sait comp­ter, une tâche de 2h est codée 0,25 et on en a quatre dans la jour­née.  La diffé­rence c’est qu’il est beau­coup plus diffi­cile de consi­dé­rer avoir passé les heures qu’il faut et rentrer chez soi en se disant « tant pis, ça pren­dra plus de temps » (ça fonc­tionne dans un seul sens, si le déve­lop­peur 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’ajou­ter un peu plus de pres­sion sur le déve­lop­peur.

Attentes réalistes, meilleurs résul­tats

J’ai vu les choses tout autre­ment après avoir travaillé à Yahoo! On s’af­fec­tait l’équi­valent de 4 heures de travail par jour unique­ment, et personne n’était gêné que d’en­tendre « je n’ai rien fait ou presque ces deux derniers jours, je n’ai pas été produc­tif » au point de synchro du matin tant que le travail était collec­ti­ve­ment fait à la fin du mois.

On peut faci­le­ment imagi­ner que ce serait la porte ouverte à des produc­ti­vi­tés mensuelles lilli­pu­tiennes voire à des abus, mais ça a proba­ble­ment été la période la plus produc­tive de ma vie de déve­lop­peur.

La vérité c’est simple­ment qu’en atten­dant huit heures de travail par jour, mes autres employeurs ont en réalité dimi­nué ma produc­ti­vité mensuelle. J’ai passé une dose signi­fi­ca­tive de mon éner­gie dans les autres entre­prises à être comp­table et à lutter contre le système.

À la décharge de mes employeurs, j’ai pour­tant toujours été dans des situa­tions avan­ta­geuses avec des tâches fourre-tout et des posi­tions 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éve­lop­peur plus clas­sique.

Tenter le 4 heures par jour

L’idée qu’un déve­lop­peur peut faire huit ou même sept tâches d’une heure dans une jour­née de huit heures est tota­le­ment irréa­liste. Dans la réalité ce sont la qualité ou l’épui­se­ment des colla­bo­ra­teurs qui servent de variable d’ajus­te­ment, parfois les deux.

Si vous avez des déve­lop­peurs respon­sables et moti­vés, vous pouvez essayer de partir sur des impu­ta­tions tâche à tâche et heure à heure avec une réfé­rence expli­cite à quatre ou cinq heures produc­tives par jour. Pour lisser les périodes plus ou moins actives il faudra accep­ter de ne regar­der cette métrique qu’en agré­geant par semaine ou par quin­zaine. Second point d’at­ten­tion : il faut que toute la hiérar­chie accepte de jouer le jeu, sinon on court à la catas­trophe au premier écueil projet.

Ou lâcher prise sur les impu­ta­tions

Si la situa­tion est moins idéale que ça, si le mana­ge­ment risque de ne pas jouer le jeu jusqu’au bout, ou simple­ment si l’équipe ne pense pas fonc­tion­ner sur ce rythme d’un faible nombre d’heures produc­tives par jour, on peut imagi­ner un scéna­rio plus proche des habi­tudes :

L’im­pu­ta­tion se fait au niveau du projet et pas au niveau de la tâche, avec par blocs d’une jour­née ou demie jour­née. Parfois une demie jour­née n’aura quasi­ment pas été produc­tive, parfois elle le sera excep­tion­nel­le­ment, mais on ne fera pas de diffé­rence : la préci­sion sera globa­le­ment suffi­sante pour le repor­ting comp­table et admi­nis­tra­tif (le contrôle de gestion, la factu­ra­tion, l’éven­tuel crédits impôts-recherche).

De l’autre côté l’avan­ce­ment projet est fait en mesu­rant … (atten­tion c’est révo­lu­tion­naire) l’avan­ce­ment du projet, et pas le temps travaillé. Ça semble enfon­cer les portes ouvertes mais c’est encore assez rare comme pratique.

Quant au suivi des déve­lop­peurs eux même c’est un point RH chaque semaine. Ce qu’ap­porte un déve­lop­peur à une équipe ne pourra jamais être chif­fré en heures de travail ou en nombre de tâches affec­té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éve­lop­peurs compé­tents, respon­sa­bi­li­sés et moti­vés. Si vous montez consciem­ment des équipes avec des ouvriers déve­lop­peurs qui font du travail à la chaîne, passez votre chemin.

Enfin, chacun a son propre mode de fonc­tion­ne­ment. 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 fonc­tion­nera pour quiconque d’autre. Par contre je suis convaincu de la néces­sité de jeter ou réfor­mer et le système d’im­pu­ta­tion des SSII et l’idée qu’on peut mettre pour huit heures de travail dans une jour­né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 Scaleway, ONLINE SAS, joignable par téléphone au +33 (0)1 84 13 00 00 et joignable par courrier à l'adresse BP 438 - 75366 Paris Cedex 08.