Nous parlions dans un précédent article de la démarche d’amélioration continue, le kaizen. Nous poussons cette semaine plus loin dans cette direction en nous intéressant aux mudas1, différentes formes de « gaspillage » dont l’élimination est essentielle pour améliorer votre processus de production. Comme souvent, ce concept a été développé dans un contexte industriel classique (chez Toyota, en l’occurrence), mais avec un peu d’imagination nous pouvons le décliner pour la gestion d’un projet informatique.
Less is more
Plus globalement, l’objectif poursuivi par l’identification et l’élimination des mudas est en fait la mise en place d’un système de production lean, c’est-à-dire débarrassé de toutes les scories (pertes de temps, d’argent, etc.) et optimisé au maximum afin de produire le produit le plus approprié (correspondant au mieux au besoins du client) avec le minimum d’effort. Il s’agit en quelque sorte d’une vision ascétique de la gestion de projet qu’on pourrait résumer par la phrase bien connue « less is more ».
Les mudas qui ont été identifiés sont au nombre de sept, voyons ensemble comment ils se déclinent dans le contexte de la gestion d’un projet de développement informatique.
Les mudas
Attente
Il n’est pas rare qu’une décision permettant de démarrer un développement se fasse attendre, ou bien de l’autre côté que les personnes qui vont être amenées à intervenir sur le projet ne soient pas disponibles rapidement.
Dans un cas comme dans l’autre le risque est grand de créer un retard qui entraînera inévitablement une surcharge et un surcoût. Il convient donc pour le chef de projet de parvenir à limiter au maximum les délais d’attente (en fixant des jalons à l’avance pour « forcer » la prise de décision, en prévoyant en amont la mobilisation de ressources, etc.).
Transport
C’est à comprendre, dans le cas qui nous occupe, comme un transport d’information. Ainsi, dans le cas d’une gestion de projet « classique » où l’information circule systématiquement de façon pyramidale (du bas vers le haut et inversement) il n’est pas rare que des informations se perdent ou se modifient, car leur source est toujours indirecte (c’est le fameux « téléphone arabe »). Il est alors nécessaire, pour limiter ce phénomène, de bien s’assurer que la demande a été dûment formulée (spécification, ticket, document officiel, etc.) et que les échanges à son sujet seront également centralisés et notés.
Les méthodes dites « agiles » peuvent paraître immunisées à ce problème car elles tendent à rapprocher le client (le Product Owner) de l’équipe de développement … Ce n’est cependant qu’une apparence : en effet les incompréhensions peuvent alors se produire de la même façon car les deux ne parlent pas le même langage et n’ont pas la même perception des priorités (business/marketing et technique).
Il est donc nécessaire de garder un œil attentif sur ce muda, car ces échanges (quelle que soit leur nature) ont un coût réel sur le projet qui est souvent négligé : à court terme, une incompréhension peut conduire au développement de fonctionnalités non-conformes ; et sur le long terme la perte de confiance entre le client et l’équipe a un coût exponentiel.
Processus excessif
Il faut dans la mesure du possible, essayer d’adapter la méthode de suivi de projet à l’ampleur de celui-ci, ou au moins ne pas hésiter à prendre des raccourcis pour ne pas risquer de faire perdre son temps au client. Par exemple, est-il raisonnable de partir sur un cycle en V complet pour monter un projet modeste qui a été vendu trois semaines ? En somme il faut percevoir que le mode d’organisation que vous retiendrez a un coût sur le projet lui-même : essayer de l’adapter au mieux peut être une façon d’optimiser les choses … Nous y reviendrons plus loin.
Stock
De nombreux problèmes ont été remontés et stagnent dans l’outil de gestion des tickets, en attente d’une résolution. Ceux qui sont prioritaires seront probablement traités, mais de nombreuses tâches risquent de passer éternellement à la trappe car jugées (par l’équipe ou le client) comme étant non-prioritaires. Au final cela alourdit inutilement la navigation dans l’outil, et c’est prendre le risque de passer à côté :
- côté client, de besoins non-encore complètement exprimés mais néanmoins bien réels (et qui pourraient devenir soudainement urgents dans le futur) ;
- côté équipe, d’une création de dette technique si un travail de fond devrait être mené pour assainir la base de code.
Il est donc nécessaire de prendre le problème à bras le corps en amont en prévoyant régulièrement un (ou plusieurs) point(s) complet(s) sur les tickets non-prioritaires ouverts et de décider avec le client et l’équipe de la suite à donner à chacun d’entre-eux : doivent-ils être traités, et si oui quand ? Sont-ils obsolètes et doivent-ils être abandonnés car ils n’ont plus d’objet ?
Mouvement
L’esprit de ce muda est d’identifier les mouvements qui ne contribuent pas directement à l’ajout de valeur au produit fini. Métaphoriquement, dans le contexte de la gestion d’un projet informatique, on pourrait y voir la tendance à faire trop de réunions inutiles ou inefficaces … Posez-vous donc par exemple les questions suivantes :
- vos réunions sont-elles toujours bien calibrées (ordre du jour correspondant au nombre et à la qualité des interlocuteurs, une durée prévue à l’avance et respectée, etc.) ?
- donnent-elles toujours lieu à une prise de décision ?
- sont-elles trop ou trop peu fréquentes ?
Une bonne réunion peut faire avancer le débat et permettre de recadrer les choses … Mais une mauvaise fait perdre du temps à de l’énergie à tous !
Non-qualité
La non-qualité est coûteuse ; aussi bien celle du produit qui est développé, que l’organisation du projet qui vise à son développement. Le tout doit donc s’inscrire au sein de la démarche qualité, un processus mené en parallèle qui va permettre de traiter ces deux aspects (ce point précis fera l’objet d’un article ultérieur).
Surproduction
La démarche lean, que nous avons déjà abordée à travers l’exemple de Kanban, vise à produire en flux tiré (on parle de pull) : la production est ainsi toujours liée à la demande. Nous l’avons vu aujourd’hui, c’est par l’élimination des mudas que l’on parvient à rapprocher justement la demande de la mise en production en retirant les obstacles.
La surproduction, qui est en fait la résultante des six autres mudas, est exactement l’inverse de cet esprit car elle implique que la production s’effectue en flux poussé (le pull). Dans le domaine de la conduite d’un projet, on pourrait alors parler de « sur-gestion » qui nuirait à la réalisation des livrables : trop de réunions, trop de documentation, de compte-rendus, de validations, etc.
Même si elle n’a bien sûr pas les effets dramatiques d’une « sous-gestion » du projet, il faut garder à l’esprit que cette « sur-gestion » peut également avoir sur lui un impact négatif : l’idée est donc de trouver le point d’équilibre pour adapter la méthodologie aux enjeux du projet et aux besoins du client.
Avez-vous déjà été confronté à une telle « sur-gestion » ? L’identification des mudas vous semble-t-elle une approche envisageable pour essayer de faire évoluer les choses ? Laissez donc un commentaire dans le formulaire ci-dessous !