Processus : une série d’actions ou d’événements exécutés pour faire quelque chose ou obtenir un résultat particulier — Cambridge English Dictionary
Aujourd’hui, nous plongeons dans le grand débat sur le processus. Le processus est-il la solution au chaos dans les organisations ? Une façon d’appliquer une bonne discipline et des opérations pour faire bouger les choses ? Ou le processus lui-même est-il le problème, ajoutant des frais généraux et empêchant les gens de faire de leur mieux ?
Je soutiendrai qu’il existe un moyen de gérer un processus qui préserve ses avantages tout en éliminant la plupart de ses inconvénients. C’est probablement quelque chose que vous n’avez jamais vu auparavant. Et je décrirai comment le déployer, quelles sont les règles pour fonctionner de cette manière et certains des avantages surprenants.
Votre processus doit être open source
La première chose à réaliser à propos du processus est qu’il existe déjà, que vous le reconnaissiez ou non. Le processus est la façon dont nous travaillons ensemble.
Le processus peut être explicite et écrit. Ou cela peut être implicite, quelque chose que les gens comprennent simplement parce qu’ils ont l’habitude de travailler d’une manière particulière en équipe.
Le processus peut être quelque chose sur lequel un groupe de personnes est aligné. Ils sont tous d’accord sur la façon dont les choses fonctionnent. Ou cela peut être quelque chose sur lequel les gens ne sont pas vraiment d’accord. Ils peuvent avoir des idées différentes sur la façon dont les choses se font.
Parce que le processus fait partie du travail des humains en groupe, il est absurde de s’opposer au processus. Cela n’empêche pas les gens d’essayer ! Mais la vraie question est comment vous façonnez et définissez la façon dont nous travaillons ensemble.
Le processus peut être problématique
La plupart de l’opposition au processus vient des mauvaises expériences des gens avec lui. C’est naturel. Le processus est un peu comme le code — sans attention, le processus peut se dégrader et causer des problèmes.
Le défi avec le processus est qu’il a sa propre vie.
Par exemple, supposons qu’une équipe d’ingénierie logicielle se concentre uniquement sur de nouveaux travaux et ne travaille pas sur les bogues provenant de l’équipe de support.
En ignorant cela, vous devriez probablement chercher plus en profondeur pourquoi cela se produit, et supposons que nous allons simplement apporter une réponse de processus à ce problème. Vous pourriez:
- Demandez au responsable de l’ingénierie et au chef de produit de planifier des bogues à chaque sprint
- Décidez que l’équipe demandera à la personne de garde de faire des bogues pendant la semaine où elle est de garde
- Ajouter un SLA autour des bugs
Quoi que vous décidiez, vous voyez un problème et vous modifiez le comportement de l’équipe pour essayer de résoudre ce problème à l’avenir. C’est un travail de processus.
Donc, disons que vous décidez que le responsable de l’ingénierie et le chef de produit rencontreront leur agent de support une fois par semaine et hiérarchiseront les bogues les plus importants chaque semaine. Vous organisez la réunion et elle commence à se produire chaque semaine.
Le problème, c’est que deux ans plus tard, le problème pourrait évoluer. Et les personnes qui ont créé ce processus ne sont peut-être même pas là. Ainsi, les personnes impliquées dans cette réunion deux ans plus tard peuvent ne pas comprendre les problèmes que la réunion était censée résoudre.
Cette incertitude sur les origines du processus peut rendre les gens réticents à changer les choses. Cela est particulièrement vrai si le processus est important ou autour de quelque chose qui semble dangereux. Ainsi, Process peut prendre une vie propre, où il fonctionne comme une sorte de zombie. Et les gens le suivent parce qu’ils le doivent, même si c’est mauvais ou nuisible.
Encore une fois, c’est comme du code hérité. Cela fonctionne, mais chaque fois que vous le touchez, vous risquez de causer d’autres problèmes. Donc, la plupart du temps, les gens essaient d’éviter de le toucher.
Et si le processus était fluide et dynamique ?
À quoi ressemblerait le processus idéal ?
- Ce serait fluide et dynamique. Facile à adapter aux besoins de l’organisation.
- Cela intégrerait un bon contexte à l’intérieur. Cela faciliterait les modifications.
- Il serait clair, concis et à jour.
- Ce serait la source de la vérité, vous pourriez donc vous y fier.
Traitez votre processus comme du code
Bref, un bon processus, c’est un peu comme un bon code :
- Il peut être mis à jour facilement
- Vous avez le contrôle de version. Vous avez de bonnes informations historiques pour voir comment cela a changé au fil du temps.
- Le coût du changement est minimisé
- Vous avez un bon contexte qui vous permet de voir pourquoi le processus existe et ce qu’il essaie de faire
- Le processus est ce qui décrit comment les choses fonctionnent
Solution : Processus Open Source
Alors, comment obtenir un processus flexible qui peut s’adapter aux besoins changeants de votre organisation ?
La meilleure solution que j’ai trouvée est d’ouvrir votre processus. Notez votre processus et permettez à quiconque de suggérer des modifications. Dites à tout le monde qu’ils peuvent changer la façon dont l’entreprise fonctionne.
Bien que cela puisse représenter beaucoup de travail, cela peut aussi être extrêmement clarifiant. Et cela peut sembler stimulant de pouvoir dire : la façon dont nous travaillons ensemble est écrite. Et n’importe qui peut y apporter des modifications.
Avantages d’une culture écrite
Écrire votre processus est une pratique de base pour une organisation avec une culture écrite. Et il y a plusieurs avantages à écrire les choses :
- L’écriture est une pensée plus claire. Cela demande de la précision. Il apporte de la clarté.
- L’écriture est asynchrone et toujours disponible. L’écriture est plus évolutive car elle ne nécessite pas de réunion pour partager des informations.
- L’écriture est donc meilleure pour les équipes distribuées.
Le principal inconvénient est que la documentation nécessite des efforts pour être maintenue.
Comment ouvrir la source de votre processus : un manuel d’ingénierie
Alors, comment construire une culture écrite et créer un processus flexible et maintenable pour une organisation ?
Vous créez un manuel d’ingénierie. C’est un référentiel de la façon dont les choses fonctionnent dans votre organisation. Il représente la documentation de votre processus.
J’ai fait cela de nombreuses fois. Voici les étapes générales que je recommande.
1. Choisissez un format pour votre manuel d’ingénierie
Le premier défi que vous aurez est de déterminer où conserver la documentation de votre processus. Je n’ai jamais rien trouvé qui fonctionne parfaitement. J’ai un article séparé qui partage mes notes sur les outils à utiliser pour les manuels des employés. L’étape importante est de choisir quelque chose. Vous pourrez changer d’avis plus tard.
2. Amorcez le contenu
La prochaine chose à faire est de commencer à remplir le contenu. Chaque fois que vous rencontrez un processus, écrivez-le, même brièvement. Décrivez comment les choses fonctionnent actuellement.
Cela fonctionne particulièrement bien lorsque vous rejoignez une organisation. Vous pouvez utiliser ces descriptions pour clarifier le fonctionnement des choses. Vous pouvez même montrer vos écrits aux gens et leur demander s’ils sont corrects.
Je pourrais le faire pendant quelques mois avant de continuer à le déployer davantage. Au fur et à mesure que j’apporterai des changements organisationnels, je les documenterai et j’aurai une section avant et après. Une fois la modification effectuée, je placerai la section avant dans la partie historique du document, afin que les gens puissent voir comment notre processus évolue au fil du temps.
Souvent, vous constaterez qu’il existe des versions précédentes de documents de processus qui se trouvent quelque part. Ils peuvent être incomplets ou non entretenus. Mais ils peuvent raccourcir une grande partie de ce processus. Organisez-les et commencez à les entretenir.
Avoir suffisamment de contenu avec lequel interagir est important. Cela montre qu’il y a un élan derrière la pratique et qu’elle sera prise au sérieux. Cela permet aux gens d’y investir leur temps.
3. Choisissez un mainteneur : c’est probablement vous
Vous aurez besoin de quelqu’un qui s’assure que ces documents de processus sont pris au sérieux et qu’ils sont mis à jour et organisés. Vous pouvez demander de l’aide, mais en fin de compte, il faut que quelqu’un s’investisse en eux. Ce n’est peut-être pas quelque chose que vous pouvez facilement déléguer.
Idéalement, c’est quelque chose que toute la direction prend au sérieux, et vous pouvez le modéliser, mais demandez à un plus grand groupe de personnes de vous aider.
4. Communiquer comment tout cela fonctionne et déployer les changements
La prochaine étape consiste à le déployer. Si vous avez démarré le contenu, ce n’est peut-être pas une surprise pour toute l’organisation que vous le déployiez. Certaines personnes l’ont peut-être déjà vu.
Ce que j’ai généralement fait, c’est parler des raisons pour lesquelles nous mettons l’accent sur une culture écrite, puis partager les règles que nous suivons pour nous assurer que nos documents de processus sont à jour (plus à ce sujet dans une seconde). Et puis, j’essaie de partager comment n’importe qui peut améliorer le fonctionnement de l’organisation et de décrire comment cela fonctionne. Cela peut être une chose excitante et stimulante pour l’équipe.
Règles de processus
Alors, quelles sont les règles pour la documentation des processus ? Voici les choses que j’aime partager.
1. Répondre avec documentation
La première chose que j’aime partager est le concept de réponse avec documentation. Je le partage généralement avec toute l’équipe d’ingénierie, lors d’une réunion de tous les ingénieurs ou dans un bulletin d’information à l’organisation. Et je vais essayer de le modéliser moi-même. Qu’est-ce que « répondre avec documentation » ?
Quand quelqu’un vous pose une question; idéalement, vous voulez répondre avec une URL qui répond à cette question. Vous faites cela en allant sur le wiki, en vous assurant que la réponse n’y est pas et en l’ajoutant si ce n’est pas le cas. Ensuite, vous leur envoyez l’URL.
Cela fait plusieurs choses :
- Cela garantit que la question pourra être répondue à l’avenir sans que vous ayez à y répondre.
- Il forme la personne à demander où elle peut trouver des réponses aux questions futures.
Répondre avec de la documentation, c’est mettre une couche de cache devant toutes les questions que les gens pourraient vous poser. Cela rend votre expertise plus largement disponible.
Pour l’organisation, l’impact de la réponse avec documentation est que vous pérennisez vos réponses. Au lieu de répondre à la question un million de fois, vous vous assurez qu’elle n’a besoin d’être répondue qu’une seule fois. Vous résolvez systématiquement les problèmes plutôt que de vous contenter de faire un travail ponctuel.
2. Ce n’est pas officiel tant que ce n’est pas dans le manuel
La règle suivante est quelque chose que je répète encore et encore à l’équipe de direction. Ce n’est pas officiel tant que vous ne l’avez pas mis dans le manuel. Chaque fois qu’un responsable apporte une modification ou déploie un plan, je dis que le plan doit inclure une URL.
- L’équipe passe-t-elle à des sprints de deux semaines ? Cela devrait être dans le manuel.
- Est-ce que quelqu’un change d’équipe ? Il devrait y avoir une liste des personnes de cette équipe dans le manuel.
Cette règle est importante car…