Il est possible que vous disiez: «La matrice des compétences? Vraiment? " Il est fort probable que vous ayez déjà entendu parler de cet outil et même tiré des conclusions pour lesquelles vous ne souhaitez pas l'utiliser. Peut-être que ce n'était pas le cas auparavant, ou comment l'argument meurtrier "s'est-il passé historiquement ...".

En fait, c'est un outil complètement logique et non un nouvel outil qui peut être très utile. Et vous pouvez l'implémenter de manières complètement différentes, ce que nous allons essayer de vous prouver sur des cas pratiques de deux équipes différentes - le support technique et le développement. Sur la base de ceux-ci, vous pourrez vous-même estimer les coûts de main-d'œuvre (ils peuvent être très différents) et trouver un moyen plus approprié pour vous dans cette direction.

Et qu'est-ce que les dragons ont à voir avec ça, nous allons expliquer sous la coupe.



Cet article est basé sur le nôtre avec Konstantin Kaftan sur TeamLead Conf . Konstantin Timlid, du service d'assistance technique d'IPONWEB, et je suis le rédacteur technique de l'équipe de développement d'IPONWEB, engagée dans la gestion des connaissances.

L'histoire est construite sur des cas pratiques IPONWEB, alors apprenez d'abord à connaître un peu l'entreprise afin que vous puissiez comprendre si ce matériel est proche de vous.

Notre RH, à la demande d'une image marketing cool qui parlera de notre sphère, a donné ceci:


En effet, IPONWEB développe des plateformes pour les clients qui s'engagent dans la publicité en ligne. Nous travaillons sur le modèle du Software as a Service (ou plutôt de la Platform as a Service). Nous avons de nombreux composants: serveur HTTP, algorithme de prédiction, interface utilisateur, reporting. Logique métier pour environ 50 projets écrits en Lua.

Nous avons également le produit phare BidSwitch, qui a commencé comme une spin-off. Nous sommes plus intéressés par l'intégration des partenaires (côté demande, côté offre), nous avons donc beaucoup de journaux. C'est le même projet, sur la même pile, mais il est assez grand, il a des spécificités et une ligne de support technique dédiée, dirigée par Konstantin.

Pourquoi avons-nous choisi le nom «Dragons Live Here», qu'est-ce que cela signifie? Donc, plus tôt sur les cartes médiévales, on a désigné des endroits où l'on ne sait pas ce qui se passe - comme Terra Incognita. Il y a deux histoires à ce sujet. Le premier concerne la structure des compétences et des compétences de l'équipe, et plus l'équipe est grande, plus il y a de Terra Incognita; et parler de la seconde un peu plus tard.

Comment en sommes-nous arrivés là

Il se trouve que nous (Svetlana et Konstantin) ne nous chevauchons pas souvent dans le travail et que nous n'avons soumis des demandes sur le même sujet que sur le site Web de la conférence . Ensuite, nous avons décidé de nous unir - il nous a semblé que ce serait plus intéressant pour tout le monde.

Profils d'équipe

L'équipe de support technique de Konstantin:

• Effectif: 10-12 personnes.
• Distance Timlid: courte - tout est visible les uns aux autres.
• Un ensemble de compétences: un ensemble très diversifié d'aptitudes, de compétences, d'outils de travail - cela est dû au fait que nous avons un moyen de nous retirer de nouvelles tâches de collègues d'autres équipes et départements.
• Style de travail: voler des tâches à des collègues. Cela se fait, premièrement, afin de diluer la routine de support, donc, ce n'est pas très intéressant d'analyser le même type de demandes jour après jour. Deuxièmement, pour voir qui obtient quoi et pour définir la direction du développement.

Mon équipe de développement Lua :

• Effectif: 40 personnes, mais le nombre change constamment;
• Distance avec chef d'équipe: assez longue en raison des spécificités de la structure de gestion de l'entreprise (c'est la matrice). Autrement dit, le chef d'équipe ne voit pas tous les développeurs quotidiennement et ne sait pas exactement quelles sont ses tâches quotidiennes.
• Ensemble de compétences: plus ou moins uniforme. Les développeurs écrivent la logique métier dans Lua, mais en même temps, ils entrent tous dans l'unité commerciale, c'est-à-dire dans une union de projets, par exemple, s'ils vendent des espaces publicitaires ou achètent des publicités en tant qu'annonceur.
• Style de travail: tâches spécifiques, facteur de bus. Souvent, les connaissances sont concentrées dans la tête des individus, et non toute l'équipe est interchangeable.

Des descriptions de commandes sont nécessaires pour montrer clairement en quoi nos implémentations matricielles diffèrent. Nous allons essayer de décrire comment différentes équipes ont procédé, ce qui s'est passé en conséquence, car les structures, le message, les objectifs, les déclencheurs et les résultats finaux de l'équipe étaient quelque peu différents.

Objectifs et déclencheurs

Dans l'équipe de support technique:

• Qui fait quoi? Il fallait savoir quand tout devenait trop, et cesser de rentrer dans ma tête, qui faisait quoi, qui et quoi était capable et à quel niveau.
• Quels spécialistes manquent? En conséquence, qui manque pour accomplir les tâches, qui doit être formé.
• Quelles compétences sont communes et nécessaires à tous? L'essentiel est de comprendre au stade de la sélection ce qui est commun et obligatoire, ce qui doit être écrit pour les RH dans le profil du candidat idéal.

Dans l'équipe de développement, les objectifs et les déclencheurs étaient légèrement différents. L'incitation initiale était précisément la gestion des connaissances, car, comme déjà mentionné, nous avons une entreprise très spécifique - Ad Tech. La probabilité qu'une personne vienne avec des connaissances prêtes à l'emploi est assez faible et, en même temps, pour un développeur, la connaissance des spécificités de l'entreprise est très importante.

Dans Dev Team, il fallait:

• Accélérez l'intégration des débutants . L'inclusion à long terme des développeurs dans le projet est une grande douleur. L'intégration a pris environ six mois, soit plus qu'une période d'essai, ce qui signifie que nous formerons le développeur à nos frais.
• Comprendre la structure des connaissances, évaluer les lacunes dans les connaissances , trouver des points blancs, définir un plan de formation, définir des voies de croissance individuelles.
• En raison de la structure matricielle, il est nécessaire de répartir plus uniformément les développeurs entre les unités commerciales et les tâches, et de ne choquer personne. Autrement dit, n'envoyez pas tous les aînés dans une seule unité commerciale.

Il y avait également un objectif secondaire - rendre le processus d'examen des performances plus transparent et compréhensible, afin de formuler des objectifs dans un système de coordonnées unique.

Examen des performances

L'évaluation des performances est la norme de notre entreprise. Une fois tous les N mois, une revue de performance est réalisée avec chaque collaborateur en présence du collaborateur, de son chef d'équipe, en utilisant un RH ou un notaire comme arbitre. Lors de l'évaluation des performances, nous examinons ce que l'employé a fait des tâches qui ont été définies, ce qu'il n'a pas réussi, s'il n'a pas réussi, pourquoi, quoi d'autre nous aimerions réaliser, ce que nous pouvons offrir. Après cela, de nouveaux buts et objectifs sont fixés, la prochaine échéance est fixée.

Dans l'équipe de support, cette période est assez courte, car il n'y a pas de grands projets étalés dans le temps - c'est 3, maximum 4 mois. L'équipe de développement a des cycles d'examen semestriels. Auparavant, les délais étaient plus longs, simplement parce que les développeurs peuvent mieux définir une feuille de route. Dans certaines autres équipes de développement, par exemple, l'évaluation des performances frontale a également lieu tous les 3-4 mois. Peut-être que l'intervalle n'a rien à voir avec le développement ou le soutien de l'équipe, mais c'est arrivé avec nous.

Pourquoi avez-vous besoin d'une matrice de compétences

Il y a un an, notre entreprise a traversé une période de croissance intensive, il y avait plus de personnes, plus d'outils, plus de tâches, plus. À un moment donné, il est devenu clair que sans les bons documents, il est difficile de comprendre ce qui se passait. Et nous avons trouvé une solution pour systématiser les informations: sur les tâches; outils et compétences; employés.

Pourquoi avez-vous besoin de tout cela? Vous découvrirez nos cas pratiques, mais vous pouvez avoir une question raisonnable - comment comprendre que j'en ai besoin?

Si vous avez des problèmes similaires à ceux que nous avons indiqués ci-dessus, c'est-à-dire que vous ne comprenez pas l'ensemble des tâches de vos développeurs, introduisez trop longtemps de nouveaux employés et d'autres problèmes qui ont déjà été mentionnés, alors vous en avez probablement besoin.

Par où commencer

Par où commencer, nous dirons par notre exemple.

Dans l'équipe de support technique, nous avons: identifié les tâches dans lesquelles nous sommes engagés; tâches décomposées en manipulations distinctes; a découvert les outils qu'un employé devrait connaître pour travailler dans un secteur particulier.

Voici un exemple légèrement simplifié.


L'équipe a des employés Batman, Joker, Flash et Ivanov, et des tâches standard:

• diagnostics généraux du trafic;
• diagnostics du trafic des transactions;
• surveillance du déploiement;
• tester l'intégration de nouveaux partenaires, DSP et SSP, acheteurs et vendeurs.

Parmi les outils dont nous disposons:

• uSIicer vous permet d'obtenir des numéros de trading très détaillés;
• Le graphite fournit des données d'état du système en temps réel;
• Google BigQuery (BQ) - nos journaux y vivent;
• Grafana, qui vous permet d'agréger des métriques à partir du graphite, il est pratique de mettre des alertes dessus si nécessaire;
• Ul-ajustements dans l'interface d'administration, qui vous permettent de modifier les paramètres de trafic pour un partenaire particulier, une paire de trading, un centre de données, etc.

Ensuite, nous avons découvert qui sait quoi et dans quelle mesure.


2 - un expert qui peut enseigner; 1 - signifie qu'une personne en sait plus ou moins; vider les cellules à la place, afin de ne choquer personne.

Nous résumons dans un tableau:


Les outils qui ne sont pas requis dans une tâche donnée sont surlignés en gris. Par exemple, pour un diagnostic général, nous n'avons pas besoin de connaître le BQ et Grafana. Le résultat a été une image plutôt intéressante.

Nezhdanchiki (soutien)

Plusieurs personnes inattendues sont apparues qui ont aidé à comprendre:

• Parmi les collègues, quelles compétences devraient être développées pour les attirer vers de nouvelles tâches? (Indiquez la direction du développement);
• Où des problèmes peuvent-ils survenir en cas de perte d'employé?
• Dans quelle mesure le salaire de l'employé correspond-il à son groupe de tâches?
• Dans quelle mesure l'équipe est-elle dotée et formée?

Nous nous attarderons sur chacun des points plus loin.

Revenons à la table.



Officiellement, Batman est occupé par des diagnostics généraux. Le tableau montre que le Joker, si nécessaire, le remplacera bien, étant donné qu'il est toujours un expert en interface utilisateur - pourquoi pas? Autrement dit, Batman est remplaçable ici.

Le joker est généralement bien fait - il est averti presque partout, sauf peut-être déployer une surveillance, mais cela peut être enseigné.



Il est bien connu que le Joker passe son temps libre de façon quelque peu excentrique et peut tomber du travail à tout moment. Que se passera-t-il alors? Ensuite, tout sera triste avec le diagnostic du trafic de transactions.

Non seulement cela, nous n'avons pas d'expert BQ! Autrement dit, il est urgent de tirer quelqu'un vers le haut, de s'entraîner. Par exemple, vous pouvez enseigner Batman BQ et Ivanov - Graphite.



Même avec un tel système d'évaluation simplifié, vous pouvez obtenir un certain montant pour chacun des employés afin de comprendre à quel point il est compétent et bien versé. Ces estimations en ont jeté un autre inattendu.

Deux autres choses intéressantes sont le montant total de l'équipe et son score moyen. À proprement parler, ces chiffres seuls ne sont pas particulièrement intéressants - la dynamique de leurs changements d'un mois à l'autre est intéressante. Si, pour une raison quelconque, le total a commencé à baisser, il est fort probable que quelqu'un soit parti et qu'un employé faible soit venu - un problème avec la configuration, vous devez contacter les RH. Si la moyenne a commencé à baisser, cela signifie que quelque chose ne va pas avec la formation - le chef d'équipe et le seul chef d'équipe sont à blâmer.

Il est important que dans ce cas, il s'agit d'un outil de chef d'équipe qui ne soit pas présenté aux employés, car les évaluations sont subjectives.

Équipe de développement

Tout est un peu plus démocratique dans Dev Team, ou peut-être avons-nous simplement compliqué notre tâche. La liste des compétences de l'équipe de développement est plus longue, bien que l'uniformité des tâches soit probablement plus élevée.

Nous avons recueilli les conseils de 4 développeurs expérimentés (dont un chef d'équipe et un spécialiste de la gestion des connaissances), réfléchi et analysé les tâches et les compétences. Nous avons simplement marché pas à pas et sur nos sentiments personnels, mais plusieurs personnes ont analysé les tâches, les ont présentées sur les compétences, ont dressé une liste.

Au début, c'était une liste, puis elle a été structurée en compétences plus universelles, qui incluent le codage et séparément des compétences en affaires, car pour nos développeurs, c'est une partie importante. Et à partir de cette liste de compétences déjà constituée la matrice.

La première itération de la matrice ne comprenait pas les soi-disant compétences non techniques, c'est-à-dire ce que l'on ne peut pas appeler des compétences techniques. C'est quelque chose lié au travail quotidien, et qui fait même partie des compétences essentielles, notamment: la planification; communication avec l'équipe; la capacité de gérer le processus de développement en mini-groupes ou par soi-même; capacité à formuler des exigences, par exemple, lors d'une révision de code.

Nous n'avons pas immédiatement inclus toutes ces compétences, car nous ne comprenions pas comment les évaluer avec précision.

Dans la deuxième itération, ils sont entrés dans le système d'évaluation:

• décomposition des tâches et de tout ce qui s'y rapporte;
• Documentation et code d'auto-documentation
• la capacité de communiquer avec le chef de projet, c'est-à-dire de comprendre ce qu'il dit et de poser successivement les questions nécessaires;
• la possibilité de formuler correctement des commentaires sur les revues de code, etc.

Soit dit en passant, sur les compétences non techniques à l'appui. Le fait est que les compétences générales de l'équipe de développement nécessitent une évaluation distincte. Cependant, des qualités personnelles qui ne sont souhaitables que pour le développeur pour l'équipe de support sont requises . Si une personne a été embauchée, elle l'a déjà par défaut.

Dans le développement, nous avons abandonné le concept même de «compétences non techniques» et l'avons appelé compétences universelles. Ils n'incluent pas, par exemple, la connaissance de la langue anglaise ou le fait que vous ne fâchez pas votre équipe - ce n'est pas, car il est juste plus proche des compétences générales, décrit le caractère d'une personne. Nous évaluons les compétences quelque part au bord du gouffre, et nous avons donc trouvé un tel nom - compétences universelles .

Lorsque la liste des compétences était prête, nous les avons évaluées à l'aide d'une enquête continue. Nous avons effectué un véritable examen dans lequel certaines des questions suggéraient une réponse définitive, et certaines discutaient des situations de travail: "Que dois-je faire si quelqu'un retarde ou ne fait rien?", "Comment implémenteriez-vous telle ou telle fonctionnalité dans le projet?" . Cela nous a beaucoup aidés, car cette partie des questions m'a permis de parler avec un grand nombre de développeurs.

Ensuite, nous avons classé les développeurs sur une échelle de 1 à 3 pour chaque compétence.

Ces compétences que nous n'avons pas pu évaluer avec l'aide de l'enquête initiale, nous les avons évaluées avec l'aide de pairs (pairs), c'est-à-dire qu'ils ont demandé à évaluer des collègues. A cette époque, nous n'avions pas de chefs de groupe, sinon ils auraient pu le faire.

Cette matrice ressemble à ceci.



Bien sûr, il n'a pas été possible de tout intégrer dans l'image, donc certaines choses, par exemple, les corrélations et le profil des développeurs ne sont pas claires ici. Mais même ainsi, vous pouvez évaluer approximativement ce qui se passe et voir à quel point cela est clair et ce que vous pouvez mesurer.

Les couleurs sont cohérentes avec le grade. Les mêmes paramètres ont été déduits que dans l'équipe de support - total et moyenne moyenne des compétences.

Faisons attention à Dev8. Il ressort du tableau que c'est comme si le premier candidat au licenciement. Mais, premièrement, il a des connaissances spécifiques dans l'un des postes, nous avons donc besoin de lui. Mais plus important encore, cette table n'est pas un outil de tir . Je vais aussi vous en parler, nous n'avons pas tout commencé pour le plaisir.

Compétences moyennes - c'est le travail, dont les résultats devraient être formés un plan sur la façon de resserrer les compétences. Autrement dit, si les développeurs ne savent pas quelque chose, ce n'est pas leur problème. Cela signifie que nous ne leur avons pas donné suffisamment d'informations, et en général, la connaissance de certaines compétences n'est généralement pas suffisante dans l'entreprise. Vous devez soit rédiger de la documentation, soit créer une sorte de terrain de jeu pour qu'ils puissent pratiquer, ou acheter une sorte de cours externe pour qu'ils puissent apprendre, mener une session de partage des connaissances, les envoyer apprendre les uns des autres, travailler ensemble pendant un certain temps, inclure la personne dans un autre projet. Il peut y avoir différentes options pour le partage des connaissances. L'essentiel est que vous devez d'abord organiser un événement, et ensuite seulement parler de la dynamique.

Il est important de noter que puisque notre entreprise a une structure matricielle, tous les développeurs n'ont pas besoin de certaines compétences. Ils les recevront lorsqu'ils auront terminé la tâche associée à cette compétence. Sinon, cela n'a aucun sens, surtout si la compétence n'est pas incluse dans la liste critique. Par exemple, dans une partie des projets, il n'y a pas d'uPredict, ce n'est pas une compétence critique. En général, cette approche nous a aidés à formuler quelles compétences sont essentielles et lesquelles ne le sont pas, et ce qu'un spécialiste peut rattraper lorsqu'il a une telle tâche pratique.

Un autre point important sur le classement. Nous avons d'abord fait une erreur, qui a provoqué plus que la résistance de l'équipe - nous n'avons pas verbalisé la valeur des notes 1, 2 et 3. Elles étaient dans nos têtes au niveau de l'intuition, mais nous ne pouvions pas répondre pourquoi un développeur en avait 1, et le second - 2. Les développeurs ont partagé les résultats de la propagation entre eux et cela a provoqué des conflits. Contrairement au groupe de soutien, nous avons signalé des évaluations personnelles sur demande, mais pas des étrangers.

Vous devez clairement définir et transmettre cela à tout le monde, par exemple, dans la connaissance de Lua, le score est:

• 1 - signifie que le développeur connaît tous les opérateurs de base, sait travailler avec les structures de données et écrire les classes de fonctions;
• 2 - sait organiser le code en bibliothèques, travaille de manière cohérente avec elles tout au long du projet et sait ce que sont les métatables;
• 3 - connaît les spécificités de l'entreprise et des projets, par exemple, quelles sont les coroutines (les spécificités de la façon dont notre serveur fonctionne avec Lua), comment le code C ++ fonctionne avec le code Lua, quelles restrictions il impose, comment il est interprété, le code compilé, comment fonctionne notre compilateur JIT.

Vous pouvez donc décomposer chaque compétence, car quelque part au niveau de l'intuition, vous l'avez déjà.

Remarque à soi-même:

• Verbalisez le système de notation, même si vous ne montrez personne.
• Dès les premières étapes, essayez d'inclure des développeurs expérimentés. Vous savez qui peut avoir la plus grande résistance, incluez-les immédiatement dans le travail. Retirez toutes les objections à l'avance, comme cela se fait dans les ventes.

Comment mettre en œuvre

Lorsque la matrice principale était prête, dans l'équipe de développement, nous y avons attaché des mesures . Fondamentalement, c'était le pourcentage de notes de compétence maximales, qui vous permet de donner une note au développeur.

En plus des évaluations des compétences individuelles, nous devions évaluer les développeurs. Nous avions les grades A, B et C - quelque chose comme junior, middle, senior. Chez IT junior, middle, senior, il est déjà trop chargé de sens, dans lequel, entre autres, l'expérience de travail est investie. , . A, B C — . « » .

— .

, . , , , , .

, - , , . , , . , - — , , , .

, . , , . , . .

performance review . , 1 2, ( ) .

— performance review , .

(Dev Team)

. , , . , , , . . 5-6 2-3. . -, , . ( ) .

, , . . , , , . , , . , , playground, .

, , . , , , , . . . -, .

. , - : « ? ?».

, , , — , , , . .

, . - , , .



, CI, . , . , 8.



, , , , , -. .

, — -. .


:

• 4 , .. ;
• 1 , ;
• 0,5 HR-, , , .

Et c'est tout! 30 . , , , , , , .

Dev Team

. : ( ) 3-4 . , :

• , — 3-4 ( 4 ) — , .
• , , , , — 6 .
• . . , senior'. 2 knowledge- 2 .
• — ( 3-4 ). , 100 , .
• — 2 . , .

, - , - . .

, .

— , .

, - , . , , , , . : , , ..


Support - easy medium, Dev Team — medium.

, , . , . , , , .

.

• , , .

, , . ( ), . performance review, .

, , — . .

• . , , , , .
• , - — . . , , .

, HR, , -, , -, , , -, HR - . HR , , .

• , .

-. . , , . , . — - , — . .

• Don't try this at home — - , :)

, .

, , KnowledgeConf 2019 26 .

, ( , , , , ) ( ).

. , , , . .