Auteur/autrice : Éric

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.

Quand je déve­lop­pais, je pense que ma moyenne a le plus souvent tourné autour d’une douzaine d’heures de travail produc­tif par semaine. Par « travail produc­tif » j’en­tends « travailler à la tâche qu’on m’a demandé ». Cette moyenne était même assez irré­gu­lière pour que je me demande si une moyenne mensuelle ne serait pas plus adap­tée.

À cette moyenne il faut toute­fois ajou­ter quelques périodes de surac­ti­vité dans l’an­née. Là je faisais peut-être huit à dix heures quasi conti­nues par jour, mais pas forcé­ment quand le projet en avait le plus besoin.

Le reste du temps je papillon­nais, pour partie sur des acti­vi­tés tech­niques mais non néces­saires à la réali­sa­tion de mon travail, et pour partie sur des acti­vi­tés tech­niques, person­nelles, voire récréa­tives.

Le non produc­tif essen­tiel à la produc­tion

Je ne consi­dère pas ce temps passé « à ne rien faire » comme du temps perdu. Il m’était indis­pen­sable : Un travail intel­lec­tuel néces­site de pouvoir penser à autre chose, d’avoir du recul, de lais­ser les idées et la vision mûrir dans la tête. Plus que la réflexion, il faut aussi avoir une vision large sur ce qu’on fait et de ce qui se fait hors de son projet, hors des méthodes de sa société, y compris sur d’autres logi­ciels ou sur d’autres tech­no­lo­gies. C’est ainsi qu’on peut résoudre les problèmes effi­ca­ce­ment.

Les salons de discus­sion avec les trolls ou échanges inter­mi­nables entre déve­lop­peurs, les centaines (milliers ?) d’heures passer à lire les blogs tech­niques, les autres centaines à lire les docs ou expé­ri­men­ter des choses qui n’ont rien à voir avec mon travail en cours… Tout ça s’est révélé d’une valeur inépui­sable pour mon travail. J’irai même plus loin en pensant que c’est souvent ce qui a fait la valeur de mon travail par rapport aux autres.

Ces heures ne sont pas « produc­tives », mais elles sont rentables, et pas qu’un peu. J’au­rais certes pu travailler six à sept heures par jour, mais j’au­rais été beau­coup plus lent sur ces six heures. La produc­tion aurait été un peu plus impor­tante mais la qualité aurait aussi été drama­tique­ment plus basse. Sur un travail intel­lec­tuel, la valeur produite n’est pas propor­tion­nelle au temps passé, tout simple­ment.

Pour la suite, c’est juste le lien suivant : Être comp­table de son temps.

Un rappel toute­fois : Tout ce qui précède est vrai pour des déve­lop­peurs auto­nomes, respon­sables et moti­vés. L’or­ga­ni­sa­tion du temps d’un consul­tant ou d’une direc­tion me paraît tota­le­ment diffé­rente (même si là aussi huit tâches d’une heure ne tien­dront jamais dans une jour­née de huit heures), de même pour des déve­lop­peurs qui ont besoin d’être pris par la main.