Lean Principe #6 : Tâches standardisées

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.

Tâche standardisée ne signifie pas produit standardisé

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 :

• il est bref et souvent visuel, on évite d'écrire un roman ou une "spécification"
• il met l'accent sur les points clés à vérifier lorsque l'on réalise un geste, plutôt que de rentrer dans des détails techniques inutiles
• il explique les erreurs courantes à éviter, afin d'éviter les dangers.
  
  

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 :

• elle vise à expliquer le geste de production d'un plat, pour être reproduit
• elle peut être résumée sur une petite fiche
• elle met en garde contre certains dangers (coupure, brulure, etc)
• elle ne décrit pas nécessairement en détail les gestes élémentaires du cuisinier (émincer, etc)

Les problèmes courants des standards tech

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 

Problème 1 : trop de standards

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 :

• Organiser, catégoriser les standards pour les retrouver facilement
• Hiérarchiser les standards: les standards de "haut niveau" faisant des liens vers les gestes élémentaires.
• Séparer le coeur de métier qui va servir tous les jours, des standards "occasionnels" / "à la demande"

‍

Problème 2 : des standards trop complexes

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 :

• Découper le standard en plusieurs sous-standards (ex: extraire un sous-standard à partir d'une étape d'un standard plus gros)
• Remplacer du texte par des visuels, des exemples, des aperçus de bonne pièce
• Intégrer le standard dans l'outil / la matière première (= le code). Les standards tech sont souvent mal appliqués car le document n'est pas "proche" des réalité de travail.
  Exemple dans le développement informatique : ESLint permet de matérialiser des règles de bonnes pratiques de code qui sont parfois difficile à faire respecter tant elles sont nombreuses

Problème 3 : des standards trop compliqués

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 :

• Le formateur du standard doit maitriser la théorie et les raisons profondes d'un standard afin d'être capable de l'expliquer simplement à l'élève lors de la formation
• Eviter de copier tout le contenu de Wikipedia ou du site référence, cela n'apporte pas de valeur. La copie sera bien souvent moins bien que l'original, un lien suffit.
• Eviter d'utiliser des technologies non éprouvées, non documentées ou sans communauté. Les standards majeur de l'industrie disposent en général d'un éventail de contenu pédagogique très large (site officiel, forums, stack overflow, cours de formation)

Des standards imparfaits plutôt qu'inexistants

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 ! 

‍