Gardez votre calme et soyez fiers. C'est ce que nous nous efforçons de faire ici à Easy LMS. Cela semble bien, mais comment y arriver ? Nous gérons par processus et non par résultats. Nous voulons que nos processus s'améliorent afin d'obtenir de meilleurs résultats. C'est pourquoi nous utilisons des conditions cibles plutôt que des objectifs. Bien qu'ils se ressemblent, ils sont totalement différents. Nous allons vous expliquer pourquoi.
Conditions et objectifs expliqués
Commençons par un exemple concret (tiré de Toyota Kata : Managing People for Improvement, Adaptiveness and Superior Results) que vous reconnaîtrez probablement. Vous voulez vous lever le matin et être à votre bureau dans l'heure qui suit. Si c'est votre objectif personnel et que vous êtes en retard, vous devez vous dépêcher. Vous conduisez peut-être trop vite, vous sautez le petit-déjeuner ou vous ne vous brossez pas les dents. Faire des économies pour atteindre votre objectif. Si vous définissez cette condition comme un objectif, vous devez la diviser en sous-étapes que vous pouvez mesurer. Si vous n'arrivez pas au travail en une heure, ce n'est pas un problème, car vous savez quelle sous-étape vous pouvez améliorer. Décomposons donc la condition cible en plusieurs étapes :
Get up and take a shower | 10 minutes |
Get dressed | 10 minutes |
Eat breakfast | 20 minutes |
Brush your teeth | 3 minutes |
Put on your shoes and coat | 2 minutes |
Ride your bike to work | 15 minutes |
Le résultat (l'objectif) de ce processus est d'arriver au travail à l'heure, bien nourri, habillé, douché, avec des dents propres et sans être bousculé. C'est dans l'intérêt de tous ?
D'accord, mais en quoi les cibles diffèrent-elles des conditions des cibles ?
Une condition cible est une description des processus de votre travail quotidien lorsque tout se passe bien.
Retour à la théorie. Nous connaissons tous ce sentiment lorsque le travail ne se déroule pas comme prévu. Les choses prennent plus de temps que prévu ou vous rencontrez des obstacles en cours de route. Beaucoup de choses peuvent aller de travers. Une condition cible est une description des processus de votre travail quotidien lorsque tout se passe bien. Une condition cible décrit comment nous aimerions que notre processus de travail et tous ses sous-processus soient. Il s'agit de l'état futur d'un processus que vous visez. L'état cible nous donne une orientation pour nos améliorations. Comment ? Nous mesurons notre processus de travail pendant que nous travaillons. Chaque fois qu'un processus ne fonctionne pas comme défini dans l'état cible, nous devons l'examiner. C'est ce que nous appelons une "analyse des causes profondes". Nous essayons de trouver une solution simple. La mise en œuvre de cette solution nous rapproche rapidement de l'état souhaité.
Comparez cela à un objectif. Une cible doit être atteinte. Vous devez faire tout ce qui est en votre pouvoir pour atteindre l'objectif, comme dans l'exemple de routine ci-dessus. Cela semble être une chose héroïque à faire, n'est-ce pas ? C'est faux. C'est stupide, à notre avis. Les objectifs sont source de stress, d'heures supplémentaires et de déception lorsqu'ils ne sont pas atteints. Ils donnent l'occasion de rogner sur les coûts pour atteindre l'objectif. À long terme, cela nuit à la qualité et à la satisfaction des clients. ;
Si vous devez atteindre un objectif, vous n'investirez pas dans l'amélioration des processus.
En outre, si vous devez atteindre un objectif, vous n'investirez pas dans l'amélioration des processus. Les améliorations de processus ne sont rentables qu'avec le temps. Le temps consacré à l'amélioration nuira bien sûr à vos résultats à court terme. Lorsque vous atteindrez enfin votre objectif ou que vous manquerez votre échéance, vous pourrez regarder rétrospectivement ce qui ne s'est pas passé comme prévu. Mais cela se fera des jours ou des semaines plus tard, après que le "faux pas" se soit produit. Comme il s'agit d'un événement très ancien, les traces seront froides et vous n'aurez aucune idée de la manière dont vous pourrez atteindre votre objectif la prochaine fois. Vous avez manqué l'occasion d'améliorer votre processus.
En résumé, les objectifs cachent vos inefficacités et vos opportunités d'apprentissage, tandis que les conditions cibles aident à mettre en évidence les points à améliorer, vous observez et optimisez le processus au lieu de vous concentrer sur le résultat.
Si vous trouvez une petite solution que vous pouvez mettre en œuvre immédiatement, vous n'aurez probablement pas besoin de la grande solution coûteuse.
Comment utiliser les conditions cibles pour améliorer
Reprenons notre exemple de routine matinale. Le premier matin où vous commencez à mesurer, vous constatez que s'habiller prend 20 minutes. Vous devez maintenant procéder à une analyse des causes profondes. Lorsque vous vous y plongez, vous découvrez que choisir ses vêtements prend 10 minutes. Vous perdez donc 10 minutes. Vous proposez donc deux solutions: ;
Vous préparez vos vêtements la veille.
Achetez une Porsche 911 pour réduire le temps de trajet.
Ces deux solutions semblent adéquates. Elles vous permettent d'arriver à l'heure au travail. C'est vrai ? Non, c'est faux. Laissez-moi vous expliquer : ;
Si vous avez du mal à arriver à l'heure au travail, on vous a probablement conseillé de préparer vos vêtements la veille. Mais il ne s'agit pas d'une véritable amélioration du processus. Choisir ses vêtements prend toujours 10 minutes. Pourquoi ne pas se coucher 10 minutes plus tôt, se réveiller 10 minutes plus tôt et dépenser ces 10 minutes ? Une véritable solution consisterait à réduire le temps nécessaire : porter la même chemise ou le même col roulé, comme le fait Mark Zuckerberg ou Steve Jobs. Ou portez le même ensemble de vêtements tous les lundis, et si vous faites la lessive, mettez ces vêtements ensemble dans une pile. Ou réorganisez votre garde-robe pour que les vêtements assortis aillent ensemble dans vos tiroirs.
La solution d'acheter une voiture est trop grande. Vous n'avez pas le budget nécessaire. Le délai de livraison de la voiture est de quelques semaines. Si vous trouvez une petite solution que vous pouvez mettre en œuvre immédiatement, vous n'aurez probablement pas besoin de la grande solution coûteuse.
Voyons quelques exemples tirés d'Easy LMS
Chez Easy LMS, nous nous efforçons de mettre en place un flux d'éléments unique.
Chez Easy LMS, nous nous efforçons d'avoir un flux d'éléments unique. Cela signifie que nous voulons qu'une histoire d'utilisateur puisse passer en douceur à travers notre processus de développement sans attendre que d'autres éléments soient prêts. Lorsque nous avons commencé à travailler avec cette condition cible, cela n'a pas fonctionné sans heurts. Le cycle, c'est-à-dire le temps qui s'écoule entre le moment où l'on commence à travailler sur une nouvelle fonctionnalité et celui où elle est mise en ligne, était de 32 jours. Nous avons commencé à examiner les données relatives à notre processus de travail afin de déterminer les points à améliorer. Nous avons remarqué que les articles restaient bloqués dans l'attente d'une version. Notre processus de publication était la première chose que nous voulions améliorer.
Faire deux publications par semaine
Nous nous sommes fixé le défi suivant : parvenir à un flux d'articles unique en l'espace d'un an. Pour y parvenir, nous devions définir différentes conditions cibles afin de nous rapprocher de notre objectif. ;
Le premier objectif que nous nous sommes fixé était de passer d'une publication toutes les deux ou trois semaines à deux publications par semaine. Cela nous paraissait presque irréalisable : ;
Nous avons commencé à planifier deux versions par semaine, le mardi et le jeudi, et à voir ce que nous rencontrerions en cours de route. Nous nous sommes assis et avons décrit les étapes nécessaires pour réaliser la version, et qui était responsable de quoi.
La toute première version ne s'est pas déroulée comme elle était censée le faire. Le développeur qui en était responsable était malade ce jour-là. Les autres développeurs étaient affectés à un autre projet. La solution a consisté à automatiser et à planifier la publication afin qu'elle ne dépende pas d'actions manuelles. L'automatisation a permis de placer la version sur le serveur de préparation tôt le matin du mardi et du jeudi, prête pour le test d'acceptation à exécuter par Caroline (AQ/CQ).
Le goulot d'étranglement suivant que nous avons rencontré était Caroline. Elle est responsable de la finition de la version, mais ce jour-là, elle était très occupée à gérer les traducteurs, pour que tout soit traduit à partir de la version précédente. Nous avons amélioré notre processus de traduction, ce qui est une toute autre histoire, afin que Caroline ait plus de temps pour se concentrer sur les tests. Je vous entends penser : pourquoi ne pas embaucher un testeur supplémentaire ? À l'époque, nous n'avions pas le budget nécessaire pour engager un testeur supplémentaire. L'utilisation d'objectifs semble être une solution plausible au problème, mais l'embauche de personnes supplémentaires n'est pas une véritable amélioration du processus.
Après deux mois et de nombreuses petites améliorations, nous sommes parvenus à publier deux versions par semaine ;
Pour la condition cible suivante, nous avons porté notre attention sur différentes parties du processus de développement. Au fur et à mesure que nous améliorions notre processus de travail, de plus en plus d'histoires passaient par le processus de développement. Par conséquent, les versions sont devenues plus importantes. Les versions plus importantes prennent plus de temps. Parfois, nous ne pouvions pas terminer une version avant que la suivante ne soit prête. Cela nous a fait manquer la condition des deux versions par semaine. ;
Comment nous sommes passés de deux à quatre publications par semaine
Pour résoudre ce problème, il fallait réduire le nombre de versions. Nous avons décidé de fixer la prochaine condition cible à la publication d'une version lorsque quatre histoires étaient prêtes à être publiées. Cela s'est traduit par des versions plus fréquentes et plus petites. Récemment, nous avons relevé la barre et abaissé le nombre d'histoires dans une version à deux. Nous en sommes presque à un déploiement d'un seul élément ;
Passer de deux versions toutes les deux ou trois semaines à quatre versions par semaine est un progrès considérable. Pour y parvenir, nous avons apporté des tas de petites améliorations et quelques autres plus importantes, comme l'automatisation de presque tous les tests d'acceptation. ;
Durée du cycle
Grâce à ces conditions cibles, nous avons ramené la durée du cycle d'un article de 32 à 6 jours.
En cours de route, nous avons défini et amélioré la description de la condition cible, nous avons beaucoup appris et nous avons réduit le gaspillage. Grâce à ces conditions cibles, nous avons ramené la durée du cycle d'une histoire de 32 à 6 jours, avec un code de meilleure qualité, moins de distractions, presque pas de correctifs, et des gens plus heureux.
Qu'est-ce que cela signifie pour notre culture d'entreprise ?
Nous disons toujours que l'échec n'est pas une mauvaise chose, tant que l'on apprend quelque chose. Si nous disposons d'une condition cible, nous savons en fait quand nous échouons et ce que nous devons apprendre. L'échec mène donc à l'apprentissage.
Nous sommes des apprenants avides. Avons-nous rempli toutes les conditions ? Dans ce cas, nous n'avons pas suffisamment appris et nous devrions fixer une nouvelle condition cible, plus stricte et plus difficile, ce qui nous expose à nouveau à l'échec. C'est ce qui nous permet d'apprendre en permanence.
L'apprentissage est la condition la plus importante pour nous, afin de devenir une entreprise prospère et durable. Apprendre à s'améliorer est la première étape de cette courbe d'apprentissage.
Curieux de connaître notre culture d'entreprise particulière ? Explorez notre section Travailler chez Easy LMS pour en savoir plus!
Aller travailler chez Easy LMS
