Utilisez un manuel d’ingénierie, ouvrez-le à tous et voyez votre processus s’épanouir
“Processus : une série d’actions ou d’événements exécutés pour créer 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 avancer 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, les règles de fonctionnement de cette façon et quelques avantages surprenants.
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 des humains travaillant en groupe, il est absurde de s’opposer au processus. Cela n’empêche pas les gens d’essayer ! Mais la vraie question est de savoir comment vous façonnez et définissez comment nous travaillons ensemble.
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 Process 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 à l’ingénierie et aux chefs 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.
- Ajoutez un SLA autour des bogues.
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 de dangereux. Ainsi, Process peut prendre sa propre vie, fonctionnant 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. Ainsi, la plupart des gens essaient d’éviter de le toucher.
À 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.
Bref, un bon Process 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.
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 la source de 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 dire : la façon dont nous travaillons ensemble est écrite. Et n’importe qui peut y apporter des modifications.
É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.
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.
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.
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 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. Après avoir effectué la modification, je placerai la section avant dans la partie historique de la doc, 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 l’élan derrière la pratique et qu’elle sera prise au sérieux. Cela permet aux gens d’y investir leur temps.
Vous aurez besoin de quelqu’un qui s’assure que ces documents de processus sont pris au sérieux, 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.
La prochaine étape consiste à le déployer. Si vous avez amorcé le contenu, cela ne surprendra peut-être pas toute l’organisation que vous le déployiez. Certaines personnes l’ont peut-être déjà vu.
J’ai généralement expliqué pourquoi nous mettons l’accent sur une culture écrite, puis partagé 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 travail de l’organisation et de décrire comment cela fonctionne. Cela peut être une chose excitante et stimulante pour l’équipe.
Alors, quelles sont les règles pour la documentation des processus ? Voici les choses que j’aime partager.
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 All Engineering ou d’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” ?
Lorsque 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 à répondre.
- Il forme la personne à demander où elle peut trouver des réponses aux questions futures.
Répondre avec de la documentation place une couche de mise en cache avant toutes les questions que les gens pourraient vous poser. Cela rend votre expertise plus largement disponible.
Pour l’organisation, l’impact de répondre avec de la 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.
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 sinon, le manuel n’est pas la source de la vérité. Les gens ne peuvent pas s’y fier pour être précis. Cela dégrade la confiance dans le manuel et en fait une source d’information moins utile. Mais l’ajout de cette contrainte fait de ce qui est dans le manuel la vérité. C’est une règle tout à fait nécessaire si vous vous souciez de maintenir à jour vos documents de processus.
Une troisième règle que je partage est que vous ne pouvez pas obliger les gens à faire quelque chose simplement en éditant un document. Ce n’est pas comme ça que les humains fonctionnent. Mais vous avez besoin de cette règle. Sinon, beaucoup de gens tenteront.
Vous aurez besoin d’une page décrivant le fonctionnement des modifications. Je l’appelle généralement quelque chose comme “Comment changer notre façon de travailler”. Il decrit:
- Qui est le mainteneur du manuel.
- Que n’importe qui peut faire des changements.
- Que vous ne pouvez pas dicter comment les choses fonctionnent simplement en éditant des choses dans le wiki. Vous devez communiquer et obtenir l’adhésion des personnes appropriées. Mais ces améliorations sont encouragées et le processus doit être fluide.
- Que la hiérarchie du pouvoir existe toujours. N’importe qui peut apporter des améliorations, mais en fin de compte, le vice-président de l’ingénierie délègue ces décisions à l’ensemble de l’organisation.
Vous devrez également décrire les règles d’approbation et de modification. J’ai fait des choses à travers un processus d’approbation complet, et j’ai fait des choses dans un wiki, où n’importe qui peut apporter des modifications. Lorsque vous faites des choses dans le wiki, il peut être bon de surveiller les changements périodiquement pour vous assurer que des changements inappropriés ne sont pas introduits. Je générais également périodiquement des notes de version afin que les gens sachent ce qui avait changé dans la façon dont nous fonctionnions au fil du temps.
Vous voudrez probablement une sorte de modèle pour vos pages de processus, qui comprend explicitement une section pour le contexte et l’historique. Cela peut sembler être un surcoût supplémentaire. Mais c’est utile. Vous pouvez signaler explicitement la situation qui a justifié le processus que vous mettez en œuvre. Et vous pouvez même parfois mentionner quand cela ne sera plus utile ou quand vous voudrez peut-être repenser cette façon de faire.
L’ajout d’un historique peut aider les utilisateurs à comprendre les modifications apportées au fil du temps. Et le contexte peut aider les gens à comprendre comment façonner les changements futurs.
Si vous avez déployé votre manuel d’ingénierie et que cela a été un succès, vous pourriez envisager de le faire passer au niveau supérieur et de l’ouvrir au monde entier.
Il s’agit d’une étape radicale et probablement pas adaptée à de nombreuses entreprises. Et il peut être difficile de faire participer les gens à l’idée. Mais il a quelques avantages :
- Vous commercialisez votre organisation dans le reste du monde. Cela peut attirer des candidats, qui voient à quel point votre organisation est bien gérée et les principes selon lesquels vous êtes organisé.
- Avoir une audience publique se traduira automatiquement par une meilleure qualité de processus. Ne feriez-vous pas une meilleure rédaction du processus de votre équipe si le monde entier pouvait le voir ?
- Avoir votre processus au grand jour aidera également les autres à apprendre de vous.
La société la plus connue pour cela est Gitlab. Le manuel Gitlab est le manuel d’utilisation de l’entreprise, et il est plutôt bien fait.
Bjorn Freeman-Benson a eu l’idée et la pratique de mettre le processus New Relic dans Github.
Rebecca Campbell a été ma partenaire dans le crime pendant quelques années avec les docs du processus New Relic. J’ai beaucoup appris de notre temps à maintenir les documents de processus là-bas.
Alex Kroman m’a demandé d’écrire le manuel d’ingénierie New Relic, qui était essentiellement notre livre sur la façon dont nous avons fait le développement de produits. Il comprenait nos pratiques, nos rôles et nos normes.
Gabriel Ricard m’a initié à l’idée de Répondre avec Documentation.