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.
Laisser un commentaire