Parlons procédure, méthodologie, processus, méthode… Je ferais ici référence à tout ça en utilisant le terme process (je ne parle pas ici du programme qui fait des choses dans l'ordinateur).
Il donne les pré-conditions d'application, les post-conditions de succès, les variations, les points d'attention. Un process existe toujours, qu'il soit implicite ou explicite. Un process a plusieurs niveaux imbriqués, pour produire, comprendre la production, faire évoluer le process, régler les conflits, communiquer...
On peut d'ailleurs considérer que la culture d'entreprise est un process. La culture est en effet ce qui oblige, encourage, décourage, interdit, aux gens d'avoir telle réaction dans telle circonstance. En tant que comportements, ils peuvent se lister, et se modifier (plus ou moins difficilement si on veut que le résultat soit durable).
Bref, le process est déjà énorme en soi. On ne veut pas le compliquer en y ajoutant des clauses arbitraires. Il s'agit de le factoriser, le réduire à sa plus simple expression. Si le process devient complexe, on a besoin d'un process pour interpréter le process. On n'a pas besoin de ça.
Un process peut accélérer les choses en
-
guidant les gens qui n'ont ainsi pas besoin de chercher comment faire
-
évitant de leur faire se poser toujours les mêmes questions
-
aidant à faire les choses bien du premier coup
Il peut aussi sérieusement vous compliquer la vie quand:
-
il complique inutilement ce qu'on a besoin de faire
-
il interdit de faire ce qui a légitimement besoin d'être fait, à moins d'être contourné
La qualité importante d'un process est son adaptation à la situation. Or, les situations sont variées, et elles évoluent. Un process doit donc être plastique. On en revient finalement aux mêmes considérations que pour le code: les choses les plus simples à faire évoluer sont les plus légères.
-
Quand le process est un document de 200 pages, personne ne reviendra dessus pour le modifier.
-
Quand le process demande à mettre d'accord 200 personnes pour évoluer, personne ne prendra cette peine.
-
Quand le process est implicite, personne ne peut en discuter.
Ajoutons à cela que le process doit être plus ou moins prescriptif en fonction des situations. Le modèle cynefin, le plus utile que je connaisse, nous aide à choisir une stratégie de gestion d'une situation en fonction de sa nature:
-
dans le domaine évident, où le contexte induit des conséquences facilement prévisibles, on définit et suit bêtement une liste.
-
dans le domaine compliqué, où les conséquences sont prévisibles moyennant analyse, on demande à des experts d'analyser la situation pour indiquer quoi faire.
-
dans le domaine complexe, le système a trop de relations pour prévoir ce qui va se passer, et change quand on le sollicite. On y pose des hypothèses et on les valide par l'expérience. Ce domaine est le plus fréquent dans l'activité du logiciel. Ici, on va adopter un process plus abstrait. Ce process nous donnera des indices pour concevoir les expériences, récolter les informations, vérifier qu'on n'a pas oublié de point de vue.
-
dans le domaine chaotique, c'est le feu, on essaie de sortir de là rapidement.
-
et on ajoute la falaise, de l'évident vers le chaotique, où on perd violemment nos illusions: on se croyait dans le confort de l'évident, et la concurrence nous montre que la réalité est très différente de ce qu'on pensait. La chute vers le chaos est lourde, on doit essayer d'en sortir pendant qu'on est toujours au conseil d'administration de kodak.
Le process doit tenir compte de toutes ces situations de manière pertinente. Suivre un mode d'emploi ikea dans le domaine complexe provoquera beaucoup d'erreurs. A l'inverse, expérimenter des méthodes pour monter un meuble ikea va vous faire gaspiller plus que le traditionnel week-end de chaos familial.
A noter que le lean propose un outil extrêmement utile pour gérer ça: le standard. C'est la meilleure façon que l'on connaît aujourd'hui de faire une choses. C'est le support de l'amélioration continue, parce qu'il documente notre connaissance actuelle, et qu'il évolue en permanence à partir de là. On le ressort dès qu'on rencontre un écart avec l'objectif (c'est à dire souvent) pour comprendre ce qui doit être amélioré. Il documente les pré et post conditions, les variations, les points d'attention. Tout peut être concerné par un standard, à partir du moment où le niveau d'abstraction de celui-ci correspond à la tâche à réaliser.
En bref
-
prenez le temps de comprendre cynefin. Ma compréhension actuelle m'a demandé quelques minutes d'épiphanie, et quelques années de compréhension profonde. Ça les vaut.
-
adaptez vos procédures au contexte
-
explicitez les procédures quand elles existent
-
n'ajoutez pas de procédures inutiles
