Un employé qui sait beaucoup de choses, sait comment et est prêt à éteindre tout feu dans sa prairie, bien sûr, bravo. Mais si ce héros part en vacances ou quitte même, les temps sont durs. Il s'avère qu'il est important non seulement d'en savoir beaucoup, mais aussi de pouvoir partager ces connaissances.
Aleksey Troshin (
morroz ) est dans la profession depuis près de 20 ans, il travaille en tant que chef de projet et produit depuis 2002. Durant cette période, il a travaillé dans différentes entreprises, dirigé des équipes de 2 à 150 personnes et gère désormais le développement de la FINAM. Ici, Alex a construit un système qui permet non seulement de diffuser les connaissances, mais aussi de motiver les développeurs à se développer dans la bonne direction commerciale et d'équipe. Cependant, le système n'est pas utilisé dans toutes les équipes. Pourquoi? Nous en apprenons davantage, ainsi que les approches utilisées, sous la coupe.
L'article est basé sur un rapport d'Aleksey Troshin sur Saint TeamLead Conf, qui raconte comment les connaissances sont diffusées dans FINAM: comment la force et les compétences des Jedi grandissent, comment les Padawans sont entraînés et ce qui se passe du côté obscur de la Force (où en serait-il sans).Produits et équipe informatique FINAM
Tout d'abord, je vais parler de certains de nos produits pour déterminer le contexte de l'entreprise.
Site Web Finam.ru - site n ° 1 sur des sujets financiers, contenant de nombreuses sections différentes avec des informations financières, ainsi que des services utiles, par exemple, une boutique en ligne. Vous pouvez, par exemple, acheter une part d'Apple et la donner à quelqu'un pour un anniversaire.
La plateforme de trading FinamTrade , qui a également un taux de commission nul pour les débutants.
Comon.ru - un système de répétition automatique des transactions des traders professionnels - une solution pour les investisseurs débutants et ceux qui n'ont pas assez de temps libre pour créer leur propre portefeuille d'investissement.
Réseau social pour les commerçants et bien plus encore .
FINAM IT, c'est 150 personnes réparties en 25 équipes. Le développement est uniquement interne, nous n'attirons presque pas de sociétés tierces pour nos besoins. L'image de titre montre parfaitement comment tout est arrangé avec nous. La composition des équipes peut être différente: certaines équipes ont un Product Owner, mais il n'y a pas de testeurs, par exemple, d'autres ont des testeurs, mais il n'y a pas de Product Owner, mais il y a des analystes.
En développement, nous utilisons différentes piles technologiques:
- Frontend: React.js, VUE.js.
- Langages: C #, PHP, C ++, Java, mobile.
- Bases de données: MSSQL, PostgreSQL, Oracle.
- Plateformes: SharePoint, 1C, Diasoft, MS CRM et plus.
Lorsque j'ai rejoint l'entreprise pour la première fois, nous avons essayé de dessiner des équipes, des produits et des relations. Le résultat a été un schéma si complexe, où les cercles indiquent les produits que nous développons:
Par couleur, j'ai montré que les équipes sont organisées de différentes manières. Certains fabriquent un produit, d'autres en fabriquent plusieurs. Et il y a des produits que plusieurs équipes développent à la fois (par exemple, un back office interne).
Je vais mener mon histoire sur les exemples de deux équipes, je les appellerai conditionnellement l'équipe 1 et l'équipe 2.
Équipe 1
La première équipe a développé un système d'information interne. Au départ, cela ressemblait à ceci:
- Un employé était un expert de la version actuelle de la plateforme. Il était nécessaire de transférer cette plate-forme vers de nouveaux rails, car l'ancienne version n'était plus prise en charge.
- Nous avons pris un nouvel employé qui était un expert de la nouvelle version de la plateforme. Il a été impliqué dans le portage de toutes les fonctionnalités de cette nouvelle version.
Équipe 2
La deuxième équipe a développé plusieurs systèmes internes:
- Un employé est un expert dans un système.
- Un autre employé est un expert des autres systèmes.
- Et certains systèmes ont été développés conjointement par les deux employés.
À propos des experts
Ce n'est pas une coïncidence si le mot «expert» est mis en évidence dans le texte ci-dessus. Je tiens à préciser qui est l'expert dans le cadre de cette conversation. En tant que maître de Star Wars, cette personne a le pouvoir: une compétence profonde dans son domaine, en technologie, dans le produit. C'est généralement pratique pour une entreprise, car cela donne un point d'entrée: les experts sont invités à savoir comment le faire ou quand cela sera fait, s'il s'agit de nouvelles tâches, ou ils posent des questions si quelque chose s'est cassé ou ne fonctionne pas correctement.
J'imagine un expert comme un maître Jedi du film "Star Wars" - il peut tout faire (enfin, ou presque).
Mais l'expert Jedi a ses inconvénients:
- Il a besoin d'être "élevé" pendant longtemps pour accepter cette Force.
- Quand il part en vacances, c'est toujours: "Qu'est-ce qu'on va tous faire?"
Pour surmonter l'influence de ces inconvénients, nous avons développé un système de maintenance des matrices de compétences, dont je parlerai plus loin. Je note que nous ne l'avons pas mis en œuvre dans toutes les équipes, mais seulement là où il y avait des problèmes. Le pire de tout était dans de petites équipes.
Notre principal mal de tête était la question "Que se passe-t-il si quelque chose arrive à l'expert, comme avec Maître Yoda dans l'image ci-dessous?"
Et vous avez probablement aussi entendu parler du concept de facteur de bus.
Facteur de bus
Le facteur de bus est une mesure de la concentration des informations parmi les différents membres du projet.
Dans la définition de Wikipedia, il est écrit que ce facteur détermine le nombre de participants au projet, après la perte duquel le projet ne peut pas être achevé par les autres participants. Conventionnellement, cela signifie combien de personnes doivent déplacer le bus pour qu'une catastrophe irréparable se produise avec le projet.
Lorsque vous avez un expert, le facteur Bus est égal à un, c'est-à-dire que tous les risques du projet sont entre les mains d'une seule personne, ce qui est mauvais.
Un exemple de l'histoire: en 2010, près de Smolensk, il y a eu un accident d'avion dans lequel 96 personnes sont décédées, dont la haute direction de la Pologne. Après cet événement, une règle a été approuvée en Pologne - quatre hauts dirigeants de l'État (président, Premier ministre, président du Sénat, président du Sejm) ne devraient en aucun cas voler ensemble. Il s'agit d'un facteur de protection contre le facteur Bus.
Comme vous le savez, dans les équipes 1 et 2, les experts n'étaient pas interchangeables, ce qui a créé des problèmes potentiels. Il fallait faire quelque chose pour augmenter le facteur Bus et étendre les compétences des experts Jedi. Nous avons pris les mesures suivantes.
Étape 1. Augmentez le facteur de bus
Les Jedi ne devraient pas être seuls. Par conséquent, il est nécessaire de former et d'entraîner les Jedi, afin qu'ils soient plus nombreux.
Je préciserai que le
Jedi est un rôle, pas une compétence . Les Jedi peuvent être élevés. Le deuxième rôle (en termes de Star Wars) est
Padawan , un disciple des Jedi. Il aspire à la plénitude des connaissances du Jedi et le remplace lorsqu'il est en vacances. De plus, il peut y avoir plus d'un Padawan - si l'équipe est grande, nous pouvons cultiver plusieurs Padawans à la fois. Mais le Jedi reste toujours le principal décideur.
Lorsque nous décidons qui devient un Jedi, nous nous mettons d'accord sur les Padawans, distribuons les rôles et les visualisons dans le tableau de gestion:
Voici les produits, zones ou modules horizontaux. Par exemple, si le produit est 1C, il peut s'agir de «Salaire et personnel» ou «Comptabilité» ou d'autres modules. Les colonnes verticales indiquent les employés. À l'intersection, nous entrons dans les rôles - qui est le Jedi, qui est le Padawan. Il en résulte une répartition claire.
Nous avons convenu de certaines règles pour commencer la distribution.
Règles de distribution, partie 1:- Un produit, une zone ou un module - un Jedi . Nous nous souvenons que nous voulons conserver la commodité d'un «guichet unique», expert et responsable.
- Au moins un Padawan . C'est à peu près le facteur Bus, plus il y en a, mieux c'est.
- La distribution uniforme des Jedi . Afin de ne pas surcharger les employés, en toute équité.
Il semble que tout ait été distribué logiquement, et cela s'est avéré comme ceci:
Dans la première équipe travaillant sur un produit, une personne a travaillé sur l'ancien produit (Sunset), l'autre sur le nouveau (Sunset 2.0). Dans la version "propre" du produit, l'employé était considéré comme un Jedi, dans la version "étrangère" - Padawan, un étudiant d'un autre employé.
Dans la deuxième équipe, les employés initialement nouvellement arrivés étaient inscrits à Padawans, car ils ne savaient toujours rien à leur sujet. Et puis c'est similaire au Sudoku - nous essayons d'obtenir environ le même nombre de Jedi et de Padawans en lignes et en colonnes.
Étape 2. Contrôlez le partage des connaissances
Mais comment vérifier que le Padawan deviendra un Jedi, possédant tout le pouvoir de la connaissance?
Nous fixons les connaissances
Pour ce faire, nous fixons la connaissance de nos produits: faire une liste de toutes les connaissances et les mettre dans un tableau. Pour chacun des produits sur une page Confluence distincte, nous notons simplement la connaissance du produit et les décomposons. La décomposition des connaissances peut se faire de différentes manières, et je rappelle que ces tableaux sont dessinés sous la page avec la répartition des Jedi et des Padawans. Par exemple, pour l'équipe 1, une page pour les connaissances Sunset, une autre page pour les connaissances Sunset 2.0.
Quelques captures d'écran de notre Confluence avec des exemples de décomposition.
Par modules de produits. Par exemple, l'un des produits a des modules logiciels distincts: prêts, dépôts, contrôle des devises - nous venons de les peindre et nous avons commencé à travailler avec eux.
Par fonctionnalité. Ici, nous avons peint les unités de connaissances sur les pages et les sections du système.
Pour les connaissances techniques. Nous avons présenté certains produits simplement en fonction des connaissances techniques de l'équipe.
Vous pouvez vous décomposer de toute autre manière, l'essentiel est que vous puissiez pulvériser des connaissances sur votre produit dans un plus grand nombre d'éléments atomiques.
Ajouter de la documentation
Après avoir détaillé les listes de connaissances, nous avons ajouté la colonne «documentation» au tableau et avons commencé à la remplir progressivement - chaque ligne de connaissances a sa propre page avec une description.
Je dois dire tout de suite que ce n'est pas un processus rapide, cela nous a pris plusieurs mois, mais au fil du temps, la liste de la documentation a été remplie, et au final, dans tous les domaines de connaissance du produit, nous avons écrit une sorte de documentation.
Ajouter des notes
À droite de la colonne «Documentation», nous avons ajouté une colonne pour chaque membre de l'équipe et évalué le niveau de connaissances de chaque employé.
Je vais déchiffrer les notes:
- 1 - si vous n'avez pas vu ou touché ce domaine de connaissance.
- 2 - vu ou entendu quelque chose, sait où il se trouve. Par exemple, j'ai lu la documentation, demandé l'accès au serveur ou au référentiel.
- 3 - vu, touché, peut faire. Par exemple, j'ai décrété un bug dans cette partie du code, j'ai vérifié quelque chose avec mes mains.
- 4 - a travaillé plus d'une fois, peut en parler aux autres.
Dans la première version, nous avions cinq classes - l'école nous a appris à compter de 1 à 5. Mais il s'est avéré que le système à quatre points était suffisant, nous nous sommes arrêtés.
Lors de la notation pour un examen des connaissances, nous pouvons poser des questions de contrôle. L'une des équipes pour présenter les nouveaux arrivants au projet a une vidéo d'une heure que vous devez regarder et répondre aux questions de la liste de contrôle. Si une personne n'a pas répondu à toutes les questions, on pense qu'elle n'a rien compris, la vidéo doit être revue, car elle contient toutes les réponses.
Étape 3. Visualisez-le
À la troisième étape, la question s'est posée - comment moi, le gestionnaire, vois-je immédiatement et clairement comment se produit l'accumulation de connaissances au sein de l'équipe?
Nous avons visualisé l'état actuel en peignant les carrés Jedi et Padawans de différentes couleurs: vert - la formation est terminée, gris - dans le processus d'apprentissage, rouge - n'a pas commencé à étudier. Au tout début, généralement beaucoup de rouge, mais à la fin, tout le monde devrait «virer au vert».
Au début, nous avons joué un feu de circulation et avons pensé qu'il devrait y avoir du jaune entre le rouge et le vert, mais il s'est avéré que la couleur jaune vif nous a distraits de l'essence. Par conséquent, nous l'avons abandonné et sommes devenus gris. En fait, l'essentiel est de se débarrasser du rouge le plus rapidement possible. Image avec un exemple de feu de circulation:
Après cela, nous avons affiné nos règles.
Règles de distribution, partie 2:- Les Jedi doivent d'abord «passer au vert». Autrement dit, nous nous concentrons sur le pompage des Jedi. Le chef responsable devrait devenir compétent le plus rapidement possible. Surtout s'il s'agit d'un nouvel employé.
- Au moins un Padawan doit être vert, ayant complètement terminé la formation. Mais il n'est peut-être pas pressé de rattraper les connaissances du Jedi, l'essentiel ici n'est pas de s'arrêter.
- Les autres Padawans peuvent être en train d'apprendre. Notre tâche est de ne pas oublier de «barbouiller» les connaissances, de faire en sorte que les domaines de connaissance des employés se recoupent et que la couverture soit maximale.
Exigences différenciantes
Pour la première étape du lancement du système, au cours de laquelle la description et la numérisation des connaissances ne font que commencer, il existe une bonne pratique: séparer les exigences pour le Jedi et le Padawan.
Rappelons les estimations: Padawan obtient une marque verte pour les «trois» s’il a fait au moins quelque chose dans ce domaine, et les Jedi devraient être parfaitement orientés dans la même zone, pour les «quatre». De plus, c'est mauvais pour le Jedi (couleur rouge) si l'accès n'est pas obtenu, la documentation n'est pas écrite, etc., c'est-à-dire que son seuil inférieur est «deux». Cette approche est illustrée dans le tableau ci-dessous.
C'était suffisant pour commencer. À l'étape suivante, vous pouvez relever la barre et dire que maintenant tous les chiffres devraient être les mêmes.
Et maintenant nos assiettes sont peintes et tout est devenu plus intéressant et compréhensible:
Nous sommes allés à quelques photos vertes un an et demi. Nous nous sommes lentement réunis avec les chefs d'équipe, une fois toutes les deux semaines ou un mois, avons regardé ce qui se passait, constamment mis à jour quelque chose.
Lorsque nous avons ajouté de nouvelles fonctionnalités, des dés rouges sont apparus. Ensuite, lors de la prochaine réunion de Timlid, nous avons vérifié s'ils restaient rouges. Si c'est le cas, ils ont alors commencé à découvrir pourquoi en deux semaines la formation n'avait pas progressé. Si le rouge a disparu, les carrés gris restent, nous les vérifions périodiquement. Les résultats de la réunion d'équipe ont été enregistrés dans Confluence sur des listes de contrôle, où le statut a été noté. Par exemple: «Employé 1 - niveau 10 sur 20». Si en deux semaines ces valeurs n'ont pas changé, ils ont cherché pourquoi.
Chaque nouvel employé est toujours dans la zone rouge, il doit être formé et pompé dès que possible. Mais comment?
Étape 4. Pompage des connaissances et des compétences
Remplissage: remplir la documentation
Nous en sommes venus à comprendre que nous devons nous efforcer de faire en sorte qu'une ligne du tableau décomposé du produit corresponde à une connaissance (une page de la documentation).
La description imparfaite est juste visible dans ce tableau. Cela signifie que les domaines de connaissances dans la colonne de gauche sont trop détaillés et à droite, il y a probablement une grande feuille de documentation difficile à lire et à apprendre. Autrement dit, ils ont lu une page de la documentation et ont pompé 5 lignes de connaissances à la fois - il est illogique de l'obtenir. Il vaut mieux qu'une ligne corresponde à une page dans Confluence. Il est plus facile de cocher la case (nombre) que toutes les pages sont étudiées et apprises.
Nous utilisons deux méthodes de remplissage:
- Écriture de mémoire (méthode experte). Quiconque sait faire quelque chose, s'assoit et commence à enregistrer ses étapes, par exemple en complétant la description avec des captures d'écran.
- La deuxième méthode - la recherche - que je vois, puis j'écris. De cette façon, nous l'avons utilisé lorsque nous travaillions avec un système dont personne ne se souvenait quoi en faire. L'employé s'est assis pour comprendre et a écrit tout ce qu'il a fait par étapes: ici, vous devez demander des droits, puis écrire une lettre, etc. Ainsi, la documentation a été remplie pour la partie sur laquelle il a enquêté.
Il arrive que les intérêts des développeurs en termes d'auto-développement ne coïncident pas avec les besoins de l'entreprise. Ici, vous pouvez jouer avec les cotes. Par exemple, vous avez besoin d'un coup de pouce dans les compétences analytiques, ce qui signifie que nous mettons un coefficient de 0,5 sur l'analyse. Il devient clair que vous pouvez "virer au vert" plus rapidement. Mais là où les employés eux-mêmes sont plus intéressés, mais pas l'équipe, les chances sont plus grandes. Dans ces sections, le pompage prendra plus de temps.
En plus de travailler avec des documents, nous menons des discussions techniques. Mais la documentation est basique. Je pense que c'est la meilleure façon de contrôler tous les processus. Dans la documentation, tout est disposé sur les étagères, une image complète est visible et vous pouvez influencer la diffusion et l'accumulation des connaissances.
Nous avons donc documenté tout ce dont nous avons besoin. La prochaine étape est la mise à jour.
Actualisation
C'est très bien lorsque tous les membres de l'équipe ont le droit de modifier la documentation. Ensuite, tout employé, se familiarisant avec la documentation, lisant comment faire quelque chose, peut trébucher quelque part et la corriger immédiatement. Par exemple, le nom du serveur a changé ou autre chose, un employé peut immédiatement changer la documentation. Ainsi,
la mise à jour et la régénération automatiques des connaissances se produisent.
Si votre équipe dans votre espace Confluence est abonnée à ces modifications, elle recevra des notifications indiquant ce qui a été ajouté, modifié, amélioré, car dans Atlassian Confluence, il y a:
- Historique des changements de page - vous pouvez toujours voir ce qui a changé et quand.
- Abonnez-vous aux notifications de mise à jour de la page.
- Supprimer dans la corbeille.
Idéalement, il y a une suppression dans le panier. Si quelqu'un clique accidentellement sur "Supprimer la page", il ne sera toujours pas perdu. Vous pouvez le restaurer et comprendre pourquoi quelqu'un a tenté de déraciner cette connaissance de votre espace.
La plupart de nos équipes n'ont pas de processus distinct pour l'examen de la documentation. Donc, dans l'une des équipes, la diffusion des connaissances a été une grande douleur, le chef d'équipe a oublié de le faire. Ensuite, nous avons commencé à procéder à un examen tous les six mois. Nous avons créé une nouvelle page et recommencé à nouveau, la date de la révision a été fixée.
Le critère principal pour la qualité du partage des connaissances pour moi est le départ d'un employé en vacances. Si une personne part en vacances et que personne ne m'écrit, n'appelle pas et ne demande rien, alors je pense que tout est en ordre dans cette équipe.
Et si avant de planifier des vacances, il y a des discussions «que ferions-nous sans lui», pour moi c'est l'occasion lors d'une rencontre personnelle avec le chef d'équipe de discuter de ce qui se passe avec le transfert de connaissances dans son équipe.
Vous devez comprendre que la documentation ne consiste pas toujours à lire ou à apprendre quelque chose. Souvent, vous devez faire quelque chose: demander l'accès, installer le programme, ouvrir quelque chose dans le programme. Au cours de ces actions, une mise à jour a lieu. , , . , , , . .
Utiliser
?
. . , 4 , . , , - . , , . , , . , .
, . : « , . , ».
, — , . «», , . , : « , . ».
. , , 1, 2, 3, 4 . , , . . , , 1, 2, 3, 4. .
« »KPI, : « - KPI , - - , ». , , , , . — .
— , , .
Bus factor: , . , bus- , , , . : , . , . , , . , , . . : «, . - , ».
, , . () . , , . ( ). . , — . .
. , , . , . , . .
Conclusions
, , , .
« ! ». . !
TeamLead Conf 2020 , . , «», . , . , , , telegram- . 10 11 !