Limiter le travail en cours pour accélérer la mise en œuvre
Un programme de test qui progresse lentement souffre rarement d'un manque d'idées ou de compétence : il souffre le plus souvent d'un trop grand nombre de projets ouverts en même temps. Une entreprise a mis 30 minutes à déployer un outil de test A/B, une autre six mois pour le même outil, un écart de 8760 fois. Ce n'est presque jamais une question de talent.
Unités de travail, ressources et la variation qui bloque tout
Toute activité peut se décrire comme l'interaction de trois éléments : des unités de travail (un projet, une page, un test), des ressources qui leur ajoutent de la valeur (une personne, un processus), et la valeur elle-même, toute action qui rapproche l'unité de travail de son achèvement. Quand les étapes d'un processus n'avancent pas au même rythme (une page rapide à rédiger mais longue à concevoir visuellement, par exemple), le travail s'accumule devant l'étape la plus lente. Cette variation de rythme, pas le manque de compétence individuelle, reste la cause la plus fréquente de blocage.
Deux façons opposées de gérer cette variation
Deux logiques s'opposent face à cette variation, chacune illustrée par une image. Dans un aéroport, ce sont les passagers (les unités de travail) qui attendent, pendant que chaque agent (chaque ressource) reste occupé sans interruption : l'efficacité du personnel prime, au prix de l'attente des voyageurs. Dans le cas d'un roi qui se casse le bras et doit être opéré d'urgence, c'est l'inverse : l'équipe médicale (les ressources) attend, prête, tandis que le roi (l'unité de travail) est traité en priorité absolue. La plupart des entreprises pensent, par intuition, qu'il vaut mieux garder les ressources (souvent les plus coûteuses) occupées en permanence, laissant les projets attendre leur tour.
Le choix contre-intuitif des entreprises les plus focalisées
Les entreprises les plus efficaces font le choix inverse : elles optimisent pour l'achèvement des projets plutôt que pour l'occupation des ressources, quitte à accepter que certaines ressources restent parfois inoccupées. Un projet qui attend ne se plaint jamais explicitement, contrairement à une chaîne de production à l'arrêt, ce qui rend son coût invisible alors qu'il continue de s'accumuler silencieusement.
Cinq coûts cachés d'un projet à l'arrêt
Un travail secondaire, sans valeur directe pour le client mais coûteux en temps et en attention, apparaît dès qu'un projet reste bloqué : le stockage du travail en attente (listes de tâches, systèmes de suivi de plus en plus complexes) ; la dégradation de sa pertinence avec le temps (une offre devenue obsolète, une page qui référence une promotion expirée) ; la disparition de l'opportunité elle-même pendant l'attente (un contributeur clé qui part, un client qui change d'avis) ; le coût de redémarrage après une interruption (retrouver où on en était prend parfois plus de temps que le travail initial) ; et un projet achevé mais sous-exploité, faute d'avoir été relancé pour son déploiement complet.
La règle qui en découle
Garder le travail en cours au niveau le plus bas possible, en terminant ce qui est déjà commencé avant d'en entamer un nouveau. Cette discipline porte, dans certaines traditions du management industriel, le nom de Genchi Genbutsu à un autre niveau : aller observer soi-même sur le terrain plutôt que de gérer à distance une pile de projets abstraits, une pratique également documentée dans la méthodologie de recherche du corpus sous le nom de Method Marketing.
Application pratique
Face à un programme de test qui n'avance pas malgré une équipe compétente et occupée, la question à poser n'est pas combien de projets sont en cours, mais combien pourraient être mis en pause pour qu'un seul avance jusqu'à son terme. Choisir le projet le plus prioritaire, lui donner toutes les ressources nécessaires sans le faire attendre derrière d'autres priorités, et le mener jusqu'au bout avant d'ouvrir le suivant, produit généralement plus de résultats achevés qu'un même effort réparti sur plusieurs fronts. La question complémentaire, combien de changements regrouper dans un même test une fois celui-ci lancé, est développée dans Arbitrer entre isoler un changement et grouper plusieurs changements dans un test.