Temps de lecture moyen : 4 mn
Chez Captive, nous avons décidé de partager avec vous chaque semaine les enseignements que nous tirons du Lean dans notre activité quotidienne d'agence de développement.
La semaine dernière, nous avions abordé le cinquième principe du lean : Automatisation avec une touche humaine (Jidoka). Cette semaine, nous allons abordé le sixème principe du Lean : Tâches standardisées.
Taiichi Ohno, le père fondateur du lean chez Toyota a dit « sans standard, il ne peut y avoir d’amélioration ».
Autant vous spoiler tout de suite, je pense qu'il a raison!
Mais on ne va pas s'arrêter là! Je vous propose dans cet article d'essayer de comprendre ce qui se cache derrière cette affirmation et quel est le principe de la standardisation.
Intuitivement, si on demande à quelqu'un de standardiser sa production, cette personne va tout de suite penser à réduire sa gamme de produit pour avoir moins de variantes et donc des processus identiques.
Du côté des employés, la standardisation renvoie souvent l'image d'un travail monotone, peu enrichissant.
Dans la philosophie du Toyota Production System, il en est pourtant tout autre...On va au contraire chercher à personnaliser le produit, l'expérience du client pour le satisfaire au mieux.
Mais dans ce cas, comment standardiser la production ?
La standardisation au sens Lean vise à établir "une meilleure manière de faire un geste de production". Ce standard peut prendre différentes formes: document numérique, document papier, vidéo, etc.
Il a pour but de formaliser, informer et former la personne désirant réaliser ce geste.
Le standard est très intéressant pour les raisons suivantes :
Un facteur primordial pour permettre l'adoption et l'évolution du standard est la capacité des personnes à pouvoir expliquer les raisons théoriques et pratiques des points clés du standard.
Une des meilleures analogie avec pour comprendre un standard serait la recette de cuisine :
En tant que manager/team leader pratiquant le Lean, on comprend rapidement que l'on doit faire émerger des standards afin d'harmoniser les gestes de production et capturer les erreurs communes. On peut alors facilement passer à l'action : des documents courts sur un Drive/Dropbox/Notion peuvent suffire.
On va néanmoins rapidement rencontrer les problèmes suivants
Le nombre de standards qu'un développeur doit connaitre peut devenir énorme, surtout si on favorise les postes de type Fullstack . Les contre-mesures possibles sont :
Certains standards sont ou deviennent avec le temps trop complexes. La liste des points clés représente une charge mentale trop importante le rendant impossible à appliquer correctement. Les contre-mesures possibles sont :
Certains standards requièrent une connaissance théorique plus pointue que d'habitude pour pouvoir être appliqués. Formulé autrement, pour qu'une personne puisse appliquer un standard il faut s'assurer que celle-ci ait facilement à disposition la connaissance associée. Les contre-mesures possibles sont :
Commencer la standardisation de la production d'une équipe tech est relativement facile comparé à d'autres secteurs d'activité. En revanche, le défi majeur réside dans la capacité à gérer le nombre élevé de standards qu'il faut maitriser pour un développeur.
La problématique sous-jacente est donc de parvenir à définir un bon processus de production des standards et la formation des personnes au sein de son entreprise.
Il faut prendre conscience d'une chose : écrire un bon standard est une compétence qui s'acquière par la pratique. Je m'en rend compte régulièrement car lorsque je parcours d'anciens standards écrits par moi-même je me dis souvent : "Autant sur le fond que sur la forme c'est vraiment à revoir... et pourtant j'étais fier de ce que j'avais produit à ce moment!".
Afin de conduire l'amélioration, il ne faut pas hésiter à créer des standards imparfaits au départ : incomplets, moches, etc. (s'inspirer de la méthode SDCA par exemple). Par sa simple existence, le standard permet de donner un premier point de repère sur lequel itérer.
Ainsi, même s'il est sous-optimal pour un geste, "un standard tout de suite est mieux que pas de standard du tout". La clé est de donner aux équipes l'autonomie et l'agilité pour adapter/ faire évoluer le standard par la suite.
C'est en ce sens que Taiichi a totalement raison : on ne peut pas améliorer quelque chose que l'on ne qualifie pas. Merci sensei Ohno pour cet enseignement !
Captive est une agence de développement informatique qui pratique le Lean. Vous avez un projet ? N'hésitez pas à nous contacter !