Nous organisons le chaos ou comment implémenter une approche processus dans une organisation

Une fois, j'ai changé d'emploi et je suis passé d'une grande organisation bien structurée à une startup en plein essor. J'ai vraiment tout aimé à la fois: l'énergie avec laquelle les gens ont travaillé, le professionnalisme et l'âme des communications internes. Mais au moment où ils ont commencé à me transmettre les affaires PM, une surprise m'attendait:

- Dans le sens d'aucune description? Autrement dit, vous n'avez écrit nulle part, selon quelles règles fonctionnent vos équipes? Absolument, vraiment?! Même un SLA? Et comment vas-tu me donner? En termes de mémoire, que se passe-t-il si une sorte d'arrangement est oublié et non transmis? Comment puis-je comprendre cela en cours de route? Oh les mamans ...

Avez-vous déjà eu le sentiment que votre tête est ronde et que la pensée que vous essayez de penser est carrée? C’est ce que je ressentais pour moi-même, en essayant de comprendre comment je travaillerais. La startup n'était plus petite - plus de 200 personnes, des bureaux dans plusieurs pays, des clients à travers le monde. Et, d'après ce que j'ai compris, les accords sur le fonctionnement des équipes de développement, la fréquence à laquelle elles publient les versions, selon les règles qu'elles fixent les tickets, la façon dont elles signalent, où se trouvent les documents et comment elles sont mises à jour - tout a été décidé d'une manière ou d'une autre. Et c'est merveilleux - quand vous êtes peu nombreux et que vous êtes tous au même endroit. Mais lorsque votre nouvelle équipe est assise dans un nouvel endroit, tout le monde dans d'autres villes et même dans les pays, et de nouvelles personnes chaque jour de plus en plus ... Je n'étais pas à l'aise.

En conséquence, je me suis souvenu d'une pensée simple, car j'ai une formation technique:

Le système change de n'importe où dans le système

Et elle a décidé que je serais probablement ce point qui ferait passer le système d'un état de chaos à un état de structure claire.

Pour les programmeurs et pas seulement pour ceux qui pensent que la description des processus de gestion est une perte de temps: tout comme le code doit être couvert de documentation technique et utilisateur, le travail de l'entreprise doit être décrit par des instructions et des processus. Pour les mêmes raisons: plus il y a de règles et plus elles sont déroutantes, plus il est difficile de le mentionner.

En particulier, elles doivent être décrites si le nombre de nouveaux arrivants augmente constamment et que les processus ont tendance à changer constamment. À quoi cela sert-il plus tard:

• Rappeler aux gens le fonctionnement du processus (par exemple, lorsqu'il n'est pas exécuté)
• Mettez-en un nouveau dans le processus
• Apportez des modifications au processus sans rien manquer
• Réfléchissez à ce que nous faisons de mal et optimisez le processus.

Je n'ai jamais pensé que je l'écrirais, il semble que ce soit clair et vrai. Mais non, il s'avère que les startups techniques manquent généralement la complexité des processus managériaux et préfèrent penser que tout devrait se passer de lui-même.

Quoi écrire

En bref et plus simple, puis des instructions et des accords avec toutes les parties sur la façon dont le travail est organisé avec les incidents, problèmes, versions, connaissances, capacités, sécurité, etc. dans notre organisation.

Si plus, ouvrez le Talmud ITSM et lisez :)
Cet article n'est pas entièrement sur ce qu'il faut décrire, mais plutôt sur la façon de décrire et de mettre en œuvre pour que les processus vivent.

Comment écrire

La tâche de décrire pour que les gens l'utilisent n'est pas très triviale, surtout dans des conditions où les changements ne viennent pas d'en haut, de la part des dirigeants. Il devient encore plus complexe avec une pure résistance.

J'ai trouvé une source de résistance, de longues instructions d'environ 10-30 pages, écrites il y a environ 5 ans, dont tout le monde a oublié un an plus tard. C'est-à-dire que les tentatives de structuration ont échoué, et elles étaient sûres que cela ne fonctionnerait pas.

En lisant ces documents (tout à fait, raisonnables, mais longs, trop sophistiqués), je me suis fait des pseudos

Leçon 1: Décrivez les arrangements courts et animés.

Ce que vous ne pouvez pas expliquer en termes simples, un processus complexe est votre problème, pas celui qui le lit. Peut-être que vous essayez de coller plusieurs processus en un seul.

Leçon 2 Si vous ne pouvez pas utiliser le tableau - ne l'utilisez pas. N'utilisez jamais un diagramme complexe.

De l'extérieur, il semble que le contraire soit que la lecture d'une jetée soit plus difficile que la lecture d'une carte. Je le pensais aussi. Cependant, je détiens maintenant deux documents décrivant comment nous publierons les fonctionnalités, le texte et le diagramme. Le graphique n'est pas mis à jour (difficile ou une fois), le texte est constamment (ce n'est pas seulement moi qui le fais depuis longtemps).

Leçon 3: Deux documents courts valent mieux qu'un long.

Personne ne lit plus de longs textes, il suffit de le supporter.

Leçon 4: Si vous ne pouvez pas écrire vous-même, n'écrivez pas.

Il est plus facile pour les gens d'utiliser ce qu'ils proposent et de se structurer. Convaincre quelqu'un de l'importance de créer un accord est plus correct que de vous écrire. Bien sûr, ce n'est pas plus facile.

Leçon 5: Si vous vous écrivez toujours, demandez à vérifier

Très souvent, un document apparaît après la question "Comment cela se passe-t-il avec nous?" Eh bien, si vous avez envoyé un document de vérification à quelqu'un qui a reçu les informations, avec les mots "veuillez vérifier, est-ce vrai?"

Leçon 6: En plus des entrées, sorties et interprètes et des responsables, chaque document doit avoir un public cible

Comme en marketing: pour qu'un article soit lu, il doit vous intéresser personnellement. Si vous mettez des informations pour tout le monde dans un seul document, ce sera long, et nous nous souvenons que de longs textes effraient les gens modernes. Par exemple, il existe une règle générale pour tout le monde sur la manière dont nous travaillons conformément au RGPD. En pratique, ce sont trois documents:

• pour tous les employés - une description de la règle elle-même, ce qui peut être fait et ce qui ne peut pas être fait avec des informations.
• Où et comment contacter dans une situation exceptionnelle - pour les développeurs et les services d'assistance
• Comment et où la technique décrite est exécutée - pour les développeurs

Que faire pour qu'il soit non seulement décrit, mais fonctionne également?

Déclarez que vous et votre équipe êtes gérés comme écrit.

Si quelque chose ne va pas, j'ouvre les documents, j'y mets un doigt et je dis que nous avons accepté de le faire. Que faut-il corriger? Si quelqu'un du manuel, par exemple, n'est pas satisfait des délais de travail sur le ticket, j'ouvre le processus où il est dit

• comment prenons-nous des billets pour travailler,
• par quelles étapes peuvent-ils passer
• quelle est la raison de l'arrêt du travail sur le ticket et
• quel est le temps moyen dans chacune des étapes.

et poser une question, allons-nous changer le processus, les priorités des tickets ou autre chose?
Cela atténue à peu près l'insatisfaction, facilite la communication et, surtout, augmente votre prévisibilité et la transparence de votre travail. Et là où il y a de la transparence, il y a de la confiance. Et sur la confiance, vous pouvez en construire beaucoup plus.

De plus, il vous donne la possibilité de défendre votre équipe si la faute n'est pas en public mais en confusion dans la gestion (80% des cas en fait).

Montrez aux gens comment cela fonctionne

Une partie du processus de gestion des versions est née de trois conversations avec les responsables des versions ... Sur la base de cela, j'ai expliqué à la direction pourquoi la version prenait autant de temps, et le responsable des versions a appelé à cette discussion. Maintenant, dans cet endroit, il y a plusieurs documents sur comment, pourquoi et ce qui devrait être publié ici. Écrit, bien sûr, pas par moi, mais par les responsables des versions. Habituer les gens au fait que c'est pratique, ce qui vous libère des explications inutiles et permet d'être transparent à la fois et pour tout le monde. Par exemple.

Devenez une source de connaissances

Je n'oublie pas de temps en temps de faire une petite conférence que les accords écrits sur le format de travail sont bien meilleurs que ceux non écrits. Je suis intéressé à en parler, donc tout le monde doit écouter plusieurs fois. Ce n'est pas la première fois, graduellement, la plupart des accords que nous avons rampés jusqu'à la confluence. L'eau aiguise une pierre.

Pourquoi en avez-vous besoin

Au minimum, le chaos dans la tête et sur le lieu de travail diminuera.

Au maximum, vous avez de la chance et vous serez remarqué dans cette organisation comme un gestionnaire intelligent qui sait travailler avec les processus. :)

Réflexions assez controversées.

J'ai une croyance assez sérieuse que quelqu'un ne peut pas écrire et mettre en œuvre des processus de l'extérieur. Il peut décrire l'état actuel, mais personne ne soutiendra le processus. Et si vous avez besoin de changements rapides, ils se produiront et le processus attendra que son créateur effectue les changements.

Les processus de gestion sont l'affaire de ceux qui les utilisent.

Et pourtant, il devrait arriver que l'approche processus ne soit pas une règle imposée de l'extérieur, mais mon accord avec le monde extérieur sur les règles de travail avec moi. Ensuite, l'approche processus ne sera pas un frein au développement de l'organisation (je l'ai déjà vu), mais un catalyseur de croissance.