La logique flou de l'organisation de son temps de travail

La semaine dernière Éric D écrivait un article sur la gestion de son temps de travail en montrant que sa productivité n'était pas proportionnellement liée au nombre d'heures passées à coder.

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.

Dans une situation de désordre global, c'est-à-dire qu'on ne sait pas sur quels projets travaillent les gens et à quel moment ; la volonté d'avoir une vision plus claire des événements, afin de les ordonner, est tentante. Face à cette nécessité d'organisation, on observe dans la plupart des cas la mise en place de système de remplissage de feuille temps.

Chaque jour, l'employé doit remplir le temps passé sur chaque projet, voire sur chaque tâche spécifique au projet. En théorie, tout cela semble très bénéfique pour le suivi de projet, mais en réalité un certain nombre de désagréments apparaissent :

1. La gestion du système de suivi des tâches est hasardeuse
2. Les intervenants ne remplissent pas de manière satisfaisante leur feuille de temps
3. Le système se transforme en outil de contrôle qui trouble les relations entre collègues

Quelles activités ?

Tout d'abord, pour bien organiser sa journée ou sa semaine, il est souvent essentiel de se fixer des objectifs et des types de tâches uniques. Pour ma part, à un niveau personnel, j'en identifie 3 :

1. L'activité de définition
2. L'activité de recherche et prototypage
3. L'activité de mise en œuvre

Pour la détermination de ces 3 phases, je m'inspire de cet article Mr Meyer qui évoque la pédagogie d'un professeur de mathématique.

Ventilation des activités

Quel temps attribuer aux différentes activité ? Bien entendu, cette définition est à la discrétion d'une entreprise ou d'un groupe de travail. A lui de choisir son mode d'organisation en fonction d'un type de projet ; mais essayons nous à cet exercice d'un manière un peu générale.

Si on prend Eric D, on sait qu'il travaille 10 à 12 heures sur l'activité de mise en oeuvre (le code), c'est à dire 1/3 du temps total sur une semaine. Pour ne pas trop choquer ses supérieurs disons que d'une façon raisonnable, on pourrait fixer ce temps à 3/5 de la semaine (3 jours de code).

Il nous reste ainsi 2 jours pour les deux dernières activités. On va faire simple : 1 jour pour chacune. Donc, le lundi, grande journée de discussion avec votre équipe projet et le mardi travail en petit groupe sur des prototypes.

Je suppose que pour beaucoup d'entre vous, avoir deux jours disponibles sans coder à discuter et expérimenter va bien au delà de vos rêves les plus fous. Pourtant si on faisait un examen précis des temps de travail respectif de chacun (à l'image de l'article d'Éric) ; on serait dans l'obligation d'admettre qu'il ne s'agit ni plus ni moins que d'un schéma en correspondance avec une réalité.

Application de la logique flou

Une étude américaine (toujours faire référence à une étude américaine, ça donne du crédit) a déterminé qu'il était plus bénéfique, car moins anxiogène, de donner des notions de dates de rendu floues plutôt que très précises. Dire "à rendre dans 3 jours", plutôt que "le 14 mai à 15h30 tapante". En effet, dans une liste de choses à faire, le décalage d'une seule des tâches ne permet plus de se rendre compte de la priorité réelle du reste à faire.

Si je dispose du lundi pour discuter avec mon équipe de l'organisation du projet. Pourquoi ne pas attribuer du temps pour répartir, en jours, les trois types de tâches sur la semaine à venir et en profiter par la même occasion pour analyser l'activité de la semaine précédente.

Par ce procédé, tout d'abord, on donne du temps officiel pour une période de définition du projet (1 jour), ce qui doit permettre d'éviter la mauvaise gestion du système de feuille de temps. Ensuite, comme les intervenants fixent eux-même les tâches à venir avec de commencer à travailler (ce qui semble logique), le remplissage correspondra à quelque chose de réaliste. Enfin, comme ce sont les participants au projet qui contrôlent leur planning, ils ne sont pas soumis au phénomène de contrôle.

Conclusion

Dans un métier de la connaissance, une partie de l'activité n'est pas uniquement dédiée à la mise en œuvre. D'autres activités de réflexion et d'organisation rentrent en ligne de compte.

A chacun de s'organiser comme il le souhaite, mais il semble assez pertinent d'identifier des types d'activités comme la veille ou des ateliers de conception. La réflexion en amont de projet est sensée limiter les écarts avec le besoin initial en collant au plus prêt des objectifs.

L'enjeu de ce système est de responsabiliser une équipe en la laissant libre de s'organiser comme elle le veut à condition de rendre le projet dans les temps ; en passant par un contrôle, non plus du temps passé, mais de la méthode mise en place afin de limiter les points bloquants.