Qu'est-ce qu'un KPI pour un employé et comment l'évaluer correctement Qu'est-ce qu'un KPI pour un employé et comment l'évaluer correctement. Vladimir Zavertaylov, responsable de Sibiriks : mêlée-studio

Pour écrire cette note & nbsp a été dépensé:

  • 68338 kilomètres pour les déplacements.
  • 72 heures-homme pour la correspondance postale.
  • 423 heures de travail pour des expériences avec une équipe de 30 personnes.
  • 88 heures pour préparer des rapports et prendre la parole lors de conférences.
  • 17 tasses de café pour une conversation avec des gens sages à l'after party.
  • Environ 25 heures pour taper ce texte et y corriger les bugs :).
  • Un rédacteur torturé qui a été obligé de parcourir mes brouillons, enregistrements audio et, en général, grâce à lui.

Beaucoup d'argent et de temps. Peut-être le plus coûteux (en termes de nerfs, de temps et d'argent) a été l'expérience sur ma propre équipe, dont je suis incroyablement gêné de me souvenir. Mais plus à ce sujet ci-dessous.

Tôt ou tard, tous les réalisateurs ont probablement le désir de payer équitablement. Pour le travail effectué. Et beaucoup de gens essaient maintenant de mettre en œuvre des KPI (Key Performance Indicators). Cela fonctionne comme ceci : vous, en tant que propriétaire d'entreprise, assignez des objectifs spécifiques aux employés. Ils atteignent ou n'atteignent pas leurs objectifs dans le cadre du travail. Ceux qui ont réussi reçoivent un petit pain (bonus en espèces).

La raison d'être de cette approche est de payer équitablement. Autant que j'ai gagné, j'ai autant reçu. C'est honnête, c'est logique, c'est merveilleux !

Bon, c'est logique que :

  • Les vendeurs doivent se voir attribuer un pourcentage du chiffre d'affaires. Les loups doivent avoir faim. (Oui, il existe une opinion alternative selon laquelle appliquer cette approche signifie "s'imposer une taxe supplémentaire". Mais quant à moi, tout est juste ici :-)).
  • Plancton de bureau - fixez un salaire. La stabilité est pour eux une condition très importante de leur existence.

Mais avec les unités créatives (concepteurs, programmeurs) - tout est beaucoup plus compliqué.

Nous avons récemment mené une enquête auprès des dirigeants des principales agences numériques et studios Web du pays sur le thème « comment utilisez-vous les KPI par rapport au travail des unités créatives », nous avons obtenu l'image suivante :

Certaines entreprises (15 %) utilisent des KPI pour mesurer les performances des programmeurs et des concepteurs.

Environ 25% des entreprises mettent actuellement en œuvre des KPI / rencontrent des résistances au sein de l'entreprise, ou travaillent selon un schéma simplifié.

Environ 30 % des entreprises rémunèrent leurs salariés sur la base des évaluations subjectives des managers. Au contraire, 30% l'admettent ;-)
Les 30% restants n'avouent pas.

La chose la plus intéressante est que beaucoup ont essayé de mettre en œuvre des KPI ou essaient maintenant. Et pas très bien. Cela ne signifie pas que le KPI est mauvais. Les aliments mal cuits sont impossibles à manger. Peut-être ne savons-nous tout simplement pas comment préparer ce KPI ?

Mais les statistiques montrent que l'écrasante majorité a des difficultés de mise en œuvre. Et on soupçonne que tout le monde a un problème commun. Essayons de le comprendre.

La première chose à laquelle vous devrez faire face lors de la mise en œuvre des KPI est la résistance de l'équipe

La question se pose: Quel est le plus grand fan des développeurs lors de la mise en œuvre des KPI ?

Après avoir mené plusieurs expérimentations et enquêtes auprès de collègues, nous avons identifié 6 raisons principales :

  1. Peur de la nouveauté. Tout le monde a totalement peur des innovations, pensant que ça va empirer (moins d'argent, plus de travail, etc.).
  2. Schéma opaque. En utilisant un système de compensation multi-paramètres, nous augmentons le risque que les travailleurs ne le comprennent pas. Les gens sont énervés et démotivés lorsqu'ils ne comprennent pas exactement comment obtenir les meilleurs résultats ou pourquoi ils ont soudainement reçu moins d'argent.
  3. « Pourquoi y a-t-il autant ? » Oui, cela arrive aussi. Si le schéma est construit de telle manière que le résultat de ce mois n'apparaîtra qu'après deux ou trois. «Ce mois-ci, j'ai travaillé moins bien et j'ai eu plus. Les moyens, la dernière fois, je n'ai pas été donné. La direction est idiote, ils ne comprennent rien à mon travail !"
  4. Le taux d'intervention d'urgence de l'employé. Il est presque irréaliste d'entrer dans la conscience de soi d'une personne et de lui donner un bonus "juste".
  5. Dépendance incomplète l'atteinte du critère par l'employé. Par exemple, cela ne dépend pas entièrement du designer si le dessin qu'il a dessiné sera vendu ou si 50 modifications devront être apportées.
  6. Rapports. Je ne connais personne qui aime rédiger des rapports, consigner le temps écoulé et promettre des "échéances exactes".

Si vous regardez attentivement cette liste, vous constaterez que la plupart des réclamations sont liées au choix, à la comptabilité, à la transparence et à l'adéquation des critères.

D'ACCORD. Il vous suffit donc de trouver de bons critères !

Eh bien, ceux qui comprendront tout le monde, qui ne feront planer personne, qui seront faciles à expliquer même lors d'un entretien. Et pour que tout soit juste, et j'ai envie de travailler de plus en plus.

Essayons donc de trouver de bons critères. (Au fait, "Bon" - pour qui ?). Nous avons trois principales parties prenantes concernées : le propriétaire du studio, le client et les développeurs.

Quel peut être un bon critère du point de vue du client ? Habituellement, tout se résume à de l'argent (enfin, ou à des résultats réels) :

  • ROI - grosso modo, c'est le « retour sur investissements financiers ». L'indicateur déduit par les économistes n'est pas tout à fait applicable aux développeurs : après tout, ils ne peuvent pas contrôler le rendement de leur travail et le mesurer en argent sur le pouce. Autrement dit, ils ne peuvent pas affecter directement l'indicateur.
  • Faible coût de la fonctionnalité. Il est avantageux pour le client d'avoir un faible coût de la fonctionnalité. Et pour un développeur, il s'agit d'une ventilation du modèle ("Comment est-ce : je gagne plus d'argent pour le fait que je travaille pas cher ?").
  • La satisfaction. Je ne sais pas comment le compter, mais si on prend en compte que les gens veulent du bonheur ou du moins de la vapeur moins (Dmitry Satin), alors on peut même proposer cette formule :

Or, les réalités sont désormais telles que venir offrir, par exemple, à un designer la dépendance de son salaire sur la « satisfaction » éphémère du client est une façon garantie de rester sans designer. Une crise très grave est nécessaire pour que ce sujet commence à fonctionner. Ou beaucoup de bons designers superflus.

  • Date de sortie. Tout semble logique : nous remettons le projet à temps - nous obtenons beaucoup d'argent, si nous le remettons avant la date prévue - nous obtenons encore plus d'argent. L'indicateur est bon, mais il a un problème déjà identifié : tout ne dépend pas du développeur. Le délai découle le plus souvent du côté client-gestionnaire. (D'où la foire : "Pourquoi devrais-je perdre en salaire, alors que le gérant n'a pas assommé le contenu du client ?").

D'ACCORD. Ces Critères Bons pour le client ne seront évidemment pas Bons pour le développeur. (Je ne me fais pas d'illusions, maintenant vous pouvez facilement trouver 200 autres critères différents qui sont importants pour les affaires. Écrivez, nous en discuterons dans les commentaires :))

Mais vous pouvez mesurer la PERFORMANCE ! C'est si simple!

Ou pas? Comment le mesurer ? Si j'ai peint la clôture, alors tout est évident. Mais il ya un hic. Il y a beaucoup de gens réfléchis, créatifs et talentueux dans notre industrie et personne ne peint de clôtures. Prenons l'exemple des programmeurs. Alors, quelles sont les bonnes références de performance qui vous viennent à l'esprit ?

  • KSLOC. Savez-vous ce que cela est? Connaissez-vous le code hindou ? Mettre en œuvre - vous le saurez. KSLOC est le nombre de milliers de lignes de code. Si vous liez cet indicateur à votre salaire, attendez-vous à mille lignes de copier-coller. Une de mes connaissances a reçu une commande terminée quelque part à Bangalore - un script php, pour seulement dix dollars, mais pour pas moins de 20 Mo. Et ça a marché !
  • La quantité de merde par heure (WTF/h). Le nombre de pages dessinées par jour, le nombre de fonctionnalités implémentées par heure, etc. Cela semble être une métrique normale - quelque chose peut en fait être calculé et utilisé pour distribuer des petits pains. Cependant, un problème similaire au point précédent se pose : une baisse de la qualité au détriment de la quantité, une augmentation de la dette technologique. Motivation, intérêt, satisfaction - tout s'effondre. En conséquence, chiffre d'affaires et faible qualification.
  • Le nombre de bogues. Moins il y a de bugs, plus nous payons. Tout est logique, n'est-ce pas ? Pas vraiment. Y a-t-il un bug tracker dans votre studio ? Si c'est le cas, oubliez ça. Vos testeurs se mettront très vite d'accord avec vos programmeurs sur le nombre de bugs à écrire et le nombre non, afin que ce ne soit pas au détriment des deux parties.
  • Recyclage."Si vous êtes en retard au travail, vous ne travaillez pas bien." N'est-ce pas aussi logique ? Nous avons du mal à recycler, par exemple, nous coupons l'électricité après 18h00. Cependant, ici, vous devez vous rappeler que la psychologie d'un développeur est fondamentalement différente de la psychologie du plancton de bureau : s'il reste assis jusqu'au soir, alors il est intéressé (et cela doit être encouragé).

Les gens travaillent dans notre domaine principalement parce qu'ils s'y intéressent.

N'interférez pas avec les règles stupides de l'entreprise.

  • Facteur de mise au point. Cette métrique nous est venue de mon Scrum bien-aimé. Montre combien la tâche aurait dû prendre, idéalement, et combien elle a fini. "Concentration" de l'équipe sur le projet. Est-il possible de payer de l'argent sur la base de ce critère ? Tout à fait, mais si vos managers ne sont pas des "techniciens", alors les programmeurs surestimeront délibérément le temps, minimisant ainsi leurs propres risques. La conséquence de cette démarche est que les délais sont tendus, le client s'indigne (ou n'achète pas chez vous). Oui, et chaque réunion se transformera en querelles et en disputes en 10 minutes.
  • Rapidité.Également de Scrum. La "productivité" proverbiale. C'est assez flou, les sciences humaines peuvent sauter un paragraphe.

Vous permet de prédire le nombre de tâches qu'une équipe sera en mesure de marquer lors de la prochaine étape, en fonction du nombre de tâches effectuées lors de la précédente. Les problèmes sont les mêmes que le facteur de mise au point, plus un autre est ajouté. Souvent un manager (surtout inexpérimenté), qui sent que la performance d'une équipe peut être "mesurée", commence à appliquer cet outil "dans l'autre sens". Mais la vitesse ne peut pas être un critère exact, car montre combien de temps la même tâche, exécutée par la même commande dans les mêmes conditions, peut prendre. Cependant, après avoir terminé la tâche, l'équipe a déjà changé : elle a acquis de l'expérience dans la façon de résoudre cette tâche particulière. Et la métrique ne fonctionnera plus.

  • Temps d'un cycle.À quelle vitesse le temps s'écoule depuis le moment où l'idée d'implémenter une fonctionnalité sur le projet est née jusqu'au moment où elle a été réalisée.

Personnellement, j'aime beaucoup cette métrique. L'un des éléments clés qui mérite d'être mesuré et optimisé. Mais les développeurs n'influencent pas directement ce facteur. C'est une métrique de trop haut niveau. Si vous commencez à payer à l'équipe un salaire basé sur le temps de cycle dont elle dispose, cela signifie que vous, en tant que leader, ne cherchez pas à résoudre les problèmes de l'équipe et à comprendre les processus, mais transmettez simplement tout à l'équipe.

Une tentative de déterminer la dépendance du salaire du développeur sur une métrique de haut niveau est la preuve de l'impuissance managériale

Alors, est-il possible de mesurer l'efficacité d'une équipe ? Oui, vous pouvez, d'autant plus que nous avons écrit une dizaine d'indicateurs pour cela. Et une autre douzaine de deux peuvent être envisagées dans les commentaires. Autre question : vaut-il la peine de faire dépendre le salaire du développeur de la performance ? Mais c'est déjà risqué.

Je commence à travailler et je fais mon travail - enfin, parce que je suis un professionnel et cela m'intéresse. Mais si je commence à répandre la pourriture avec des métriques stupides, j'optimiserai ces métriques stupides. J'écrirai 1000 lignes ou dessinerai 10 dessins de merde par jour. Et mon intérêt pour le travail va très, très vite se tarir, j'aurai bêtement envie de la pâte. C'est ce qu'on appelle une substitution de motivation interne - externe.

L'histoire d'une folie

Une fois, un "bon ami à moi", le chef du studio, a eu l'idée d'introduire un salaire très juste, où un tas de paramètres seraient pris en compte. Naturellement, la question a été abordée à grande échelle. Nous avons écrit tout un tas de critères, tels que :

- plan mensuel des heures travaillées et des heures effectivement travaillées ;

- plan de vente trimestriel ;

- le nombre de pupilles et leurs salaires ;

- la quantité de communication positive de la part des clients (satisfaction) ;

- le nombre de demandes clients répétées avec de nouveaux projets ;

- récompenses lors de concours spécialisés;

- communication négative avec le client ;

- le nombre de bugs trouvés par l'AQ ;

- la croissance des comptes débiteurs ;

- le nombre de bugs trouvés par le client après le démarrage du projet ;

- lire des livres, écrire des articles.

Et 20 autres pièces (liste utile, à emporter ;-)).

Tout cela a été réuni en un seul système. Naturellement, le système devait être équilibré. Par conséquent, dans les premiers mois, il a été décidé de le calibrer sur des « emballages de bonbons » virtuels. Un grand tableau a été inventé sur lequel une liste d'employés a été établie. Divers "emballages de bonbons" ont été accrochés au tableau - immédiatement, dès que le paiement est arrivé, le projet s'est terminé, ou un événement bon (ou mauvais) s'est produit qui affecterait le salaire à l'avenir.

Littéralement en 1 heure, les visages des employés sont devenus très, très sombres. Quelques jours plus tard, les questions ont commencé : « pourquoi ai-je moins d'emballages de bonbons ? » ou "pourquoi ne m'ont-ils pas donné un emballage de bonbons - ai-je aidé Vasya?"

L'ambiance est devenue anxieuse. Au bout d'une semaine, les évaluations de projet ont commencé à prendre 4 fois plus de temps qu'auparavant, et chaque évaluation s'est transformée en une dispute sans fin entre le développeur et le chef de projet. À la fin du mois, peu de gens voulaient aider leur camarade - ils expliquaient par le fait qu'"il y a assez de leur travail". Une infinité de situations sont apparues qui n'ont pu être formalisées. De nombreux emballages de bonbons ont été distribués sur la base de sentiments subjectifs.

Peu de gens voulaient travailler sans emballage, la tension grandit. La productivité et la motivation ont chuté. Un mois plus tard, le programme a été annulé. Après quelques mois, l'anxiété a disparu.

Comme conclusion:

Différentes métriques doivent être mesurées et pensez-pensez-pensez comment les influencer. Mais ne transférez pas les métriques de haut niveau directement aux développeurs et aux concepteurs. Et plus loin.

« Le développeur a quatre composants : le corps, le cœur, l'esprit et l'âme.

1. Le corps a besoin d'argent et de sécurité.
2. Coeur - amour et reconnaissance.
3. Esprit - développement et auto-amélioration.
4. Réalisation de soi pour l'âme. "

S. Archipenkov

Respectez les autres et donnez-leur la possibilité de faire ce qu'ils aiment)).

Et la toute dernière chose. Il y a un soupçon que chaque leader doit comprendre par lui-même si son organisation est prête pour la transition vers les KPI. J'espère que cette petite sélection d'articles que nous avons réussi à rassembler vous aidera à prendre la bonne décision.

Voici comment c'était. Nous avons deux pages Facebook principales : Note de rune(ici nous publions des actualités liées à nos notes et à la concurrence des sites/applications mobiles) et Magazine CMS(le contenu principal est constitué d'articles de fond, d'études et de cas). Et puis il y a un groupe fermé CMS Magazine & Runet Rating... Il est conçu pour discuter des problèmes les plus urgents et des questions d'intérêt pour les digitalistes. Ajoutez, en passant, cela deviendra soudainement utile. Alors c'est tout. Il y a quelques semaines, l'un des membres du groupe s'est tourné vers ses collègues pour obtenir des commentaires et des documents utiles sur le sujet des KPI. Comme, le moment est venu de mettre en œuvre des KPI à la maison, mais des détails sont nécessaires.

Vladimir Zavertaylov, responsable de Sibiriks : scrum-studio

Cela fait environ 4 ans que j'ai expliqué pourquoi les KPI pour les travailleurs créatifs sont un joyau de longue durée. Et le sujet est toujours d'actualité, et peut l'être jusqu'à ce que les robots nous remplacent tous. Tous les mois littéralement (lors de conférences, de communications personnelles ou de discussions sur Facebook), non, non, et quelqu'un demandera : « Comment pouvons-nous lier le paiement des programmeurs ou des concepteurs au développement ». Ajoutez aux KPI - des objectifs d'entreprise de haut niveau (qui semblent bons et beaux, mais qui ne peuvent pas être directement influencés par un employé en particulier). Ajoutez des indicateurs au KPI, qui seront immédiatement saisis. Et pour lisser cette réalisation optionnelle de KPI (« eh bien, ils ont essayé, donnons un bonus ! »). Ce jeu est joué par des milliers de personnes.

La vérité est que nous posons cette question lorsque nous réalisons la toxicité de la gestion des personnes. Nous voulons construire un système qui puisse pénaliser et récompenser sans notre implication directe de la direction. Nous n'avons pas peur et paresseux. Nous avons peur de venir et de donner une rétroaction négative au mauvais (mais impudent) employé (au moins jusqu'à ce que la patience déborde, puis la rétroaction arrache le couvercle de la bouilloire et tombe sur tout le monde, dans le rayon de la défaite). Nous sommes paresseux. Nous sommes trop paresseux pour procéder à une certification régulière des programmeurs (je peux donner un lien vers ce que c'est). Nous sommes paresseux et avons peur de punir nos subordonnés avec compétence, de leur enseigner, de discuter honnêtement et ouvertement de leurs problèmes et de leurs problèmes, de leur apprendre, de les faire travailler sur leurs erreurs. Nous sommes prêts à supporter un petit mal, juste pour ne pas faire face à cette chose caustique et toxique - gérer les créatifs.

Je vois comment les managers des grandes entreprises construisent généralement leurs horaires de manière sélective afin d'être le moins possible en accès de travail : sauter de conférence en exposition, de réunion en réunion, d'avion en avion, histoire de survivre tant bien que mal jusqu'au vendredi, jeter les choses , mais ne vous engagez pas dans la GESTION. Par conséquent, nous avons tellement besoin d'un système de KPI. Une telle tentation de blâmer votre incompétence managériale et votre réticence à entrer en conflit avec les gens (et c'est inévitable lorsqu'il y a une division des revenus ou que vous devez donner à un mauvais employé un méchant) sur un système de KPI magique qui réglera tout tout seul.

Nikolaï Apurin, directeur général d'ARTWELL LLC

Notre système KPI est des projets premium. Il y a un certain nombre de projets qui doivent être réalisés rapidement et hier (généralement, lorsque le client nous confie un projet dont les délais sont déjà expirés et que le projet a été noyé avec un entrepreneur « de poche », le développeur principal n'a pas passé le mathématiques et a été contraint de quitter le projet, le parquet et le compte étaient à la porte ... Et la tâche est - de le faire hier, rapidement. Dans le meilleur des cas, il y a une spécification technique, dans le pire des cas, et ce n'est pas le cas). Nous prenons de tels projets et accordons des bonus pour la réussite des étapes. Chaque projet a son propre système de bonus. Le chef d'équipe d'un projet sévère a passé avec succès les 1ère et 2ème étapes en 2 mois, son bonus total s'est avéré être de 800 000 roubles. Mais il existe également des correctifs standard% des ventes,% des ventes incitatives, un bonus fixe pour chaque bonne critique d'un client pour le RP, et d'autres.

En général, le système de motivation fonctionne. Chaque employé clé d'ARTWELL, s'il ne merde pas, peut s'acheter un appartement avec des bonus. C'est notre fort avantage et une grande motivation pour tous les nouveaux employés.

Gorevoy romain, directeur exécutif d'EUROSITE

Dans le travail de tout studio Web, il existe trois divisions mondiales d'activité - vente, développement et compte. Malgré la simplicité apparente des KPI dans le service commercial, tout s'avère pas si simple, car vous devez constamment lutter contre le désir des vendeurs de vendre plus de projets pour moins d'argent. La logique est simple - il vaut mieux vendre beaucoup, mais pour pas cher, que peu, mais à un prix élevé. Dans cette situation, l'expérience des banques et des compagnies d'assurance est utile, lorsqu'il y a un tiers - le souscripteur, qui s'accorde sur la possibilité ou l'impossibilité de conclure un accord, évalue les risques et la rentabilité possible du projet. Dans notre entreprise, la souscription est assurée par la direction. De ce fait, le plan de vente et la souscription vous permettent d'évaluer objectivement les KPI du service commercial.

Dans le développement et la conception, nous avons un KPI basé sur le retour sur investissement, mais il n'est en aucun cas lié au salaire et n'est pas divulgué aux employés ordinaires. Les développeurs et les concepteurs travaillent avec un salaire fixe, sans être distraits par la pensée de « combien d'argent vais-je recevoir ». Par souci d'objectivité, le ROI est pris pour des périodes de 6 mois ou plus. Tôt ou tard, il devient clair si l'employé reçoit suffisamment ou pas assez, ou est payé en trop, respectivement, environ tous les six mois, le salaire est ajusté.

Il ne peut pas y avoir de KPI clairs dans le compte, car tout dépend ici fortement de "l'adéquation" des clients eux-mêmes. Un gestionnaire de compte peut avoir des clients « généreux et adéquats », tandis qu'un autre peut avoir les poings serrés, et certains peuvent même avoir les clients les plus difficiles. Si vous commencez à introduire des mesures d'évaluation strictes, les clients difficiles seront soit ignorés, soit fusionnés avec de jeunes nouveaux arrivants.

Vassili Vishniakov, PDG de l'agence Internet Bquadro

L'utilisation d'un système KPI pour évaluer les performances des employés est un moment populaire mais difficile. Dans notre agence, le format KPI existe depuis longtemps. Dans un premier temps, ils ont été introduits pour le service marketing Internet, puis pour les chefs de service et le service commercial. Il faut reconnaître que tous les employés ne peuvent pas être mesurés à l'aide de mesures. Donc, nous n'avons pas de KPI dans le département technique et le département de conception.

De plus, le danger est grand de tomber dans le formalisme, où personne ne touchera le petit doigt sans bonus. Mais le succès du studio réside justement dans le travail d'équipe, dans la synergie des efforts. L'introduction d'un nombre excessif de KPI entraînera plutôt des tensions inutiles dans l'équipe. Par conséquent, il est nécessaire de trouver un équilibre entre la comptabilité des KPI et le travail d'équipe. Nous essayons juste d'équilibrer quelque part au milieu.

En résumé, je dirai que l'évaluation de l'efficacité dépend largement de la sensibilité, de la flexibilité et de l'expérience de l'évaluateur. Cette question doit être abordée différemment, car la situation peut changer et les mesures elles-mêmes peuvent et doivent parfois changer pour une personne spécifique.

Alexeï Volkov, PDG de l'agence Digital.Tools

Le schéma de motivation doit être transparent. Une personne doit comprendre ce qu'elle recevra. Il est difficile de motiver un développeur avec un pourcentage des ventes, mais il est impossible de motiver un développeur. Pour eux, des critères plus simples :

  1. livraison du projet dans les délais,
  2. avec la qualité requise.

Pour certains "travailleurs acharnés", il est possible d'introduire en plus une majoration pour les heures supplémentaires, surtout s'ils sont intéressés par le processus lui-même. Pour les managers et les vendeurs, c'est mieux en pourcentage du chiffre d'affaires. Directeurs des ventes - en pourcentage des bénéfices. Si le projet n'est pas rentable, je ne vends pas le projet. Si le projet est devenu non rentable en cours de travaux : les pertes de l'entreprise et une raison de tirer des conclusions. Le vendeur a une petite dose et % des ventes de services. Fix - pour ne pas mourir de faim, le pourcentage est bon. Ainsi, s'il ne vend rien, il sent qu'il n'a pas gagné grand-chose, et s'il vend bien, il sera recouvert de chocolat. Les responsables commerciaux ne recherchent pas de clients, ils ont à peine le temps de traiter les demandes entrantes.

Dmitri Loginov, directeur du studio de design et de l'agence Internet "Fourth Rome"

Après avoir introduit les KPI et les bonus financiers associés dans notre studio et notre agence, nous avons réalisé que chaque manager doit suivre cette voie de manière indépendante. Ce cheminement est aussi individuel que chaque entreprise est individuelle, il est donc presque impossible d'appliquer l'expérience de quelqu'un d'autre sans un grand remaniement.

Par exemple, dans le département développement et support du site web, nous avons mis en place des incitations financières liées à la rentabilité de chaque projet. Nous avons appris à regrouper tous les coûts du studio, à les diviser en départements, à prendre en compte les coûts de main-d'œuvre et à calculer le coût d'une heure, et, par conséquent, nous pouvons calculer la rentabilité et la contribution de chaque membre de l'équipe.

En même temps, nous étions confrontés au fait que c'est une chose de distribuer des bonus sur un gros projet qui a duré 6 mois, et une autre de les compter tous les mois pour 20-30 petits projets d'accompagnement. Afin de ne pas mettre KO pendant une semaine les chefs de projet et le service facturation, nous avons dû revoir le système de rémunération du service support, puisque sinon, vous devrez changer fondamentalement le système de comptabilité du travail et le logiciel de gestion de projet.

Olga Barantseva, PDG de la société Internet R52.RU

La mise en œuvre du système KPI pour les différentes divisions de l'entreprise comprend les étapes de discussion, de développement, de mise en œuvre, d'adaptation et d'administration. Et comme tout processus interne a son propre coût. Par conséquent, il est important que l'effet économique positif de l'introduction des KPI soit évident. Ce n'est pas toujours le cas dans notre industrie.

La difficulté surgit immédiatement lors de l'élaboration de « bons critères » (© V. Zavertaylov) - ils doivent être clairs, objectifs, justes et mesurables. Et c'est exactement le problème. En termes de productivité, le portraitiste Dunno est bien plus efficace que Raphael ou Velazquez.

À notre avis, il faut réfléchir à la mise en place de KPI si :

  1. la société Internet est principalement engagée dans la production en continu de solutions standard ou de modèles ;
  2. la société compte plus de 20 à 30 spécialistes du même profil, par exemple des programmeurs PHP ;
  3. en présence des agences, des bureaux distants et des équipes pour en formaliser le contrôle.

Dans d'autres cas, des choses moins coûteuses peuvent être efficaces, telles que le suivi du temps, des descriptions de poste détaillées et compréhensibles et des sanctions en cas d'échec, un système de bonus, une gradation des salaires en fonction du niveau de professionnalisme et de l'ancienneté dans l'entreprise, des incitations non matérielles ("honneur et respect")...

Dmitri Afanassiev, fondateur de DIAFAN.CMS

Je suis un adversaire conceptuel de tout type de KPI. Si où et il est possible d'appliquer avec succès les KPI, alors seulement dans les travaux primitifs mécaniques, mais pas dans les entreprises engagées dans la créativité et la création. Les chiffres peuvent stimuler et contrôler le travail des artistes ou des poètes, qui sont presque tous des développeurs informatiques. Sauf pour le salaire, bien sûr. 😉 Mais souvent beaucoup plus important est un processus intéressant et le plaisir d'un résultat grandiose, qui ne peut pas être traduit dans des tableaux et des graphiques.

Sp-force-hide (affichage : aucun ;). Sp-form (affichage : bloc ; arrière-plan : rgba (247, 247, 247, 1 ); remplissage : 25 px ; largeur : 800 px ; largeur maximale : 100 % ; bordure- radius : 0px ; -moz-border-radius : 0px ; -webkit-border-radius : 0px ; border-color : #dddddd ; border-style : solid ; border-width : 13px ; font-family : Arial, "Helvetica Neue ", sans-serif; background-repeat: no-repeat; background-position: center; background-size: auto;). sp-form input (affichage: inline-block; opacité: 1; visibilité: visible;). sp -form .sp-form-fields-wrapper (marge : 0 auto ; largeur : 750px ;). (217, 217, 217, 1); border-style: solide; border-width: 1px; font-size: 15px; padding-left: 8.75px; padding-right: 8.75px; border-radius: 0px; -moz -border-radius: 0px; -webkit-border-radius: 0px; height: 35px; width: 100%;) sp-form .sp-field label (color: # 444444; font-size: 14px; font-style : normal; font-weight: bold;). sp-form .sp-button (border-radius: 25px; -moz-bo rayon-rder : 25px ; -webkit-border-radius : 25px ; couleur d'arrière-plan : # ef002b ; couleur : #ffffff ; largeur : 100 % ; poids de police : 700 ; style de police : normal ; famille de polices : Arial, sans empattement ; box-shadow : aucun ; -moz-box-shadow : aucun ; -webkit-box-shadow : aucun ;) sp-form .sp-button-container (text-align : center ; width : auto ;)

Pour écrire cette note - il a été dépensé :

  • 68338 kilomètres pour les déplacements.
  • 72 heures-homme pour la correspondance postale.
  • 423 heures de travail pour des expériences avec une équipe de 30 personnes.
  • 88 heures pour préparer des rapports et prendre la parole lors de conférences.
  • 17 tasses de café pour une conversation avec des gens sages à l'after party.
  • Environ 25 heures pour taper ce texte et y corriger les bugs :).
  • Un rédacteur torturé qui a été obligé de parcourir mes brouillons, enregistrements audio et, en général, grâce à lui.

Beaucoup d'argent et de temps. Peut-être le plus coûteux (en termes de nerfs, de temps et d'argent) a été l'expérience sur ma propre équipe, dont je suis incroyablement gêné de me souvenir. Mais plus à ce sujet ci-dessous.

Tôt ou tard, tous les réalisateurs ont probablement le désir de payer équitablement. Pour le travail effectué. Et beaucoup de gens essaient maintenant de mettre en œuvre des KPI (Key Performance Indicators). Cela fonctionne comme ceci : vous, en tant que propriétaire d'entreprise, assignez des objectifs spécifiques aux employés. Ils atteignent ou n'atteignent pas leurs objectifs dans le cadre du travail. Ceux qui ont réussi reçoivent un petit pain (bonus en espèces).

La raison d'être de cette approche est de payer équitablement. Autant que j'ai gagné, j'ai autant reçu. C'est honnête, c'est logique, c'est merveilleux !

Bon, c'est logique que :

  • Vendeurs - attribuez un pourcentage du chiffre d'affaires. Les loups doivent avoir faim. (Oui, il existe une opinion alternative selon laquelle appliquer cette approche signifie "s'imposer une taxe supplémentaire". Mais quant à moi, tout est juste ici :-)).
  • Plancton de bureau - fixez un salaire. La stabilité est pour eux une condition très importante de leur existence.

Mais avec les unités créatives (concepteurs, programmeurs) - tout est beaucoup plus compliqué.

Nous avons récemment mené une enquête auprès des dirigeants des principales agences numériques et studios Web du pays sur le thème « comment utilisez-vous les KPI par rapport au travail des unités créatives », nous avons obtenu l'image suivante :

Certaines entreprises (15 %) utilisent des KPI pour mesurer les performances des programmeurs et des concepteurs.

Environ 25% des entreprises mettent actuellement en œuvre des KPI / rencontrent des résistances au sein de l'entreprise, ou travaillent selon un schéma simplifié.

Environ 30 % des entreprises rémunèrent leurs salariés sur la base des évaluations subjectives des managers. Au contraire, 30% l'admettent ;-)
Les 30% restants n'avouent pas.

La chose la plus intéressante est que beaucoup ont essayé de mettre en œuvre des KPI ou essaient maintenant. Et pas très bien. Cela ne signifie pas que le KPI est mauvais. Les aliments mal cuits sont impossibles à manger. Peut-être ne savons-nous tout simplement pas comment préparer ce KPI ?

Mais les statistiques montrent que l'écrasante majorité a des difficultés de mise en œuvre. Et on soupçonne que tout le monde a un problème commun. Essayons de le comprendre.

La première chose à laquelle vous devrez faire face lors de la mise en œuvre des KPI est la résistance de l'équipe

La question se pose: Quelle est la plus grande préoccupation des développeurs lors de la mise en œuvre des KPI ?

Après avoir mené plusieurs expérimentations et enquêtes auprès de collègues, nous avons identifié 6 raisons principales :

  1. Peur de la nouveauté. Tout le monde a totalement peur des innovations, pensant que ça va empirer (moins d'argent, plus de travail, etc.).
  2. Schéma opaque. En utilisant un système de compensation multi-paramètres, nous augmentons le risque que les travailleurs ne le comprennent pas. Les gens sont énervés et démotivés lorsqu'ils ne comprennent pas exactement comment obtenir les meilleurs résultats ou pourquoi ils ont soudainement reçu moins d'argent.
  3. « Pourquoi y a-t-il autant ? » Oui, cela arrive aussi. Si le schéma est construit de telle manière que le résultat de ce mois n'apparaîtra qu'après deux ou trois. «Ce mois-ci, j'ai travaillé moins bien et j'ai eu plus. Les moyens, la dernière fois, je n'ai pas été donné. La direction est idiote, ils ne comprennent rien à mon travail !"
  4. Le taux d'intervention d'urgence de l'employé. Il est presque irréaliste d'entrer dans la conscience de soi d'une personne et de lui donner un bonus "juste".
  5. Dépendance incomplète l'atteinte du critère par l'employé. Par exemple, cela ne dépend pas entièrement du designer si le dessin qu'il a dessiné sera vendu ou si 50 modifications devront être apportées.
  6. Rapports. Je ne connais personne qui aime rédiger des rapports, consigner le temps écoulé et promettre des "échéances exactes".

Si vous regardez attentivement cette liste, vous constaterez que la plupart des réclamations sont liées au choix, à la comptabilité, à la transparence et à l'adéquation des critères.

D'ACCORD. Il vous suffit donc de trouver de bons critères !

Eh bien, ceux qui comprendront tout le monde, qui ne feront planer personne, qui seront faciles à expliquer même lors d'un entretien. Et pour que tout soit juste, et j'ai envie de travailler de plus en plus.

Essayons donc de trouver de bons critères. (Au fait, "Bon" - pour qui ?). Nous avons trois principales parties prenantes concernées : le propriétaire du studio, le client et les développeurs.

Quel peut être un bon critère du point de vue du client ? Habituellement, tout se résume à de l'argent (enfin, ou à des résultats réels) :

  • ROI - grosso modo, c'est le « retour sur investissements financiers ». L'indicateur déduit par les économistes n'est pas tout à fait applicable aux développeurs : après tout, ils ne peuvent pas contrôler le rendement de leur travail et le mesurer en argent sur le pouce. Autrement dit, ils ne peuvent pas affecter directement l'indicateur.
  • Faible coût de la fonctionnalité. Il est avantageux pour le client d'avoir un faible coût de la fonctionnalité. Et pour un développeur, c'est une rupture dans le schéma ("Comment ça : je gagne plus d'argent pour le fait que je travaille pas cher ?").
  • La satisfaction. Je ne sais pas comment le compter, mais si on prend en compte que les gens veulent le bonheur, ou du moins prennent moins de vapeur (© Dmitry Satin), alors on peut même proposer cette formule :

Or, les réalités sont désormais telles que pour venir proposer, par exemple, un designer, la dépendance de son salaire à l'éphémère « satisfaction » du client est une façon garantie de rester sans designer. Une crise très grave est nécessaire pour que ce sujet commence à fonctionner. Ou beaucoup de bons designers superflus.

  • Date de sortie. Tout semble logique : nous remettons le projet à temps - nous obtenons beaucoup d'argent, si nous le remettons avant la date prévue - nous obtenons encore plus d'argent. L'indicateur est bon, mais il a un problème déjà identifié : tout ne dépend pas du développeur. Le délai découle le plus souvent du côté client-gestionnaire. (D'où la foire : "Pourquoi devrais-je perdre en salaire, alors que le gérant n'a pas assommé le contenu du client ?").

D'ACCORD. Ces Critères Bons pour le client ne seront évidemment pas Bons pour le développeur. (Je ne me fais pas d'illusions, maintenant vous pouvez facilement trouver 200 autres critères différents qui sont importants pour les affaires. Écrivez, nous en discuterons dans les commentaires :))

Mais vous pouvez mesurer la PERFORMANCE ! C'est si simple!

Ou pas? Comment le mesurer ? Si j'ai peint la clôture, alors tout est évident. Mais il ya un hic. Il y a beaucoup de gens réfléchis, créatifs et talentueux dans notre industrie et personne ne peint de clôtures. Prenons l'exemple des programmeurs. Alors, quelles sont les bonnes références de performance qui vous viennent à l'esprit ?

  • KSLOC. Savez-vous ce que cela est? Connaissez-vous le code hindou ? Mettre en œuvre - vous le saurez. KSLOC est le nombre de milliers de lignes de code. Si vous liez cet indicateur à votre salaire, attendez-vous à mille lignes de copier-coller. Une de mes connaissances a reçu une commande terminée quelque part à Bangalore - un script php, pour seulement dix dollars, mais pour pas moins de 20 Mo. Et ça a marché !
  • La quantité de merde par heure (WTF/h). Le nombre de pages dessinées par jour, le nombre de fonctionnalités implémentées par heure, etc. Cela semble être une métrique normale - quelque chose peut en fait être calculé et utilisé pour distribuer des petits pains. Cependant, un problème similaire au point précédent se pose : une baisse de la qualité au détriment de la quantité, une augmentation de la dette technologique. Motivation, intérêt, satisfaction - tout s'effondre. Conséquence : turn-over et faible qualification.
  • Le nombre de bogues. Moins il y a de bugs, plus nous payons. Tout est logique, n'est-ce pas ? Pas vraiment. Y a-t-il un bug tracker dans votre studio ? Si c'est le cas, oubliez ça. Vos testeurs se mettront très vite d'accord avec vos programmeurs sur le nombre de bugs à écrire et le nombre non, afin que ce ne soit pas au détriment des deux parties.
  • Recyclage."Si vous êtes en retard au travail, vous ne travaillez pas bien." N'est-ce pas aussi logique ? Nous avons du mal à recycler, par exemple, nous coupons l'électricité après 18h00. Cependant, ici, vous devez vous rappeler que la psychologie d'un développeur est fondamentalement différente de la psychologie du plancton de bureau : s'il reste assis jusqu'au soir, alors il est intéressé (et cela doit être encouragé).

Les gens travaillent dans notre domaine principalement parce qu'ils s'y intéressent.

N'interférez pas avec les règles stupides de l'entreprise.

  • Facteur de mise au point. Cette métrique nous est venue de mon Scrum bien-aimé. Montre combien la tâche aurait dû prendre, idéalement, et combien elle a fini. "Concentration" de l'équipe sur le projet. Est-il possible de payer de l'argent sur la base de ce critère ? Tout à fait, mais si vos managers ne sont pas des "techniciens", alors les programmeurs surestimeront délibérément le temps, minimisant ainsi leurs propres risques. La conséquence de cette démarche est que les délais sont tendus, le client s'indigne (ou n'achète pas chez vous). Oui, et chaque réunion se transformera en querelles et en disputes en 10 minutes.
  • Rapidité.Également de Scrum. La "productivité" proverbiale. C'est assez flou, les sciences humaines peuvent sauter un paragraphe.

Vous permet de prédire le nombre de tâches qu'une équipe sera en mesure de marquer lors de la prochaine étape, en fonction du nombre de tâches effectuées lors de la précédente. Les problèmes sont les mêmes que ceux du Focus Factor, plus un autre est ajouté. Souvent un manager (surtout inexpérimenté), qui sent que la performance d'une équipe peut être "mesurée", commence à appliquer cet outil "dans l'autre sens". Mais la vitesse ne peut pas être un critère exact, car montre combien de temps la même tâche, exécutée par la même commande dans les mêmes conditions, peut prendre. Cependant, après avoir terminé la tâche, l'équipe a déjà changé : elle a acquis de l'expérience sur la manière exacte de résoudre cette tâche particulière. Et la métrique ne fonctionnera plus.

  • Temps d'un cycle.À quelle vitesse le temps s'écoule depuis le moment où l'idée d'implémenter une fonctionnalité sur le projet est née jusqu'au moment où elle a été réalisée.

Personnellement, j'aime beaucoup cette métrique. L'un des éléments clés qui mérite d'être mesuré et optimisé. Mais les développeurs n'influencent pas directement ce facteur. C'est une métrique de trop haut niveau. Si vous commencez à payer à l'équipe un salaire basé sur le temps de cycle dont elle dispose, cela signifie que vous, en tant que leader, ne cherchez pas à résoudre les problèmes de l'équipe et à comprendre les processus, mais transmettez simplement tout à l'équipe.

Une tentative de déterminer la dépendance du salaire du développeur sur une métrique de haut niveau est la preuve de l'impuissance managériale

Alors, est-il possible de mesurer l'efficacité d'une équipe ? Oui, vous pouvez, d'autant plus que nous avons écrit une dizaine d'indicateurs pour cela. Et une autre douzaine de deux peuvent être envisagées dans les commentaires. Autre question : vaut-il la peine de faire dépendre le salaire du développeur de la performance ? Mais c'est déjà risqué.


Je commence à travailler et je fais mon travail - enfin, parce que je suis un professionnel et cela m'intéresse. Mais si je commence à répandre la pourriture avec des métriques stupides, j'optimiserai ces métriques stupides. J'écrirai 1000 lignes ou dessinerai 10 dessins de merde par jour. Et mon intérêt pour le travail va très, très vite se tarir, j'aurai bêtement envie de la pâte. C'est ce qu'on appelle une substitution de motivation interne - externe.

L'histoire d'une folie

Une fois, un "bon ami à moi", le chef du studio, a eu l'idée d'introduire un salaire très juste, où un tas de paramètres seraient pris en compte. Naturellement, la question a été abordée à grande échelle. Nous avons écrit tout un tas de critères, tels que :

- plan mensuel des heures travaillées et des heures effectivement travaillées ;

- plan de vente trimestriel ;

- le nombre de pupilles et leurs salaires ;

- la quantité de communication positive de la part des clients (satisfaction) ;

- le nombre de demandes clients répétées avec de nouveaux projets ;

- récompenses lors de concours spécialisés;

- communication négative avec le client ;

- le nombre de bugs trouvés par l'AQ ;

- la croissance des comptes débiteurs ;

- le nombre de bugs trouvés par le client après le démarrage du projet ;

- lire des livres, écrire des articles.

Et 20 autres pièces (liste utile, à emporter ;-).

Tout cela a été réuni en un seul système. Naturellement, le système devait être équilibré. Par conséquent, dans les premiers mois, il a été décidé de le calibrer sur des « emballages de bonbons » virtuels. Un grand tableau a été inventé sur lequel une liste d'employés a été établie. Divers "emballages de bonbons" ont été accrochés au tableau - immédiatement, dès que le paiement est arrivé, le projet s'est terminé, ou un événement bon (ou mauvais) s'est produit qui affecterait le salaire à l'avenir.

Le KPI est généralement une bonne chose, mais dès qu'il s'agit de sa mise en œuvre dans les équipes créatives, des questions et des doutes surgissent immédiatement. En effet, est-il possible d'évaluer objectivement une œuvre lorsque son résultat est intrinsèquement abstrait, lorsqu'il s'agit simplement d'une sorte de concept créatif ? C'est possible, selon le studio d'art et de production ART4you, et comme preuve ils parlent de la façon dont ils ont mis en œuvre des KPI pour les designers dans leur travail.

Le système KPI pour évaluer le travail des concepteurs dans ART4you est apparu il n'y a pas si longtemps - cette année. Il y avait suffisamment de raisons à son développement : c'était à la fois la volonté d'introduire un système de rémunération absolument transparent, et la nécessité de motiver et de stimuler en plus les employés, et simplement une augmentation des effectifs due à l'augmentation des volumes de production. En général, toutes ces raisons étaient subordonnées à une idée - créer une atmosphère confortable dans l'équipe.

Les exigences des KPI étaient les suivantes : transparence maximale pour les employés et la direction, capacité d'affiner le système et d'y apporter rapidement des modifications, participation non seulement des patrons, mais aussi des artistes interprètes ou exécutants à l'évaluation du travail.

Au début, le studio a envisagé des solutions toutes faites, mais les a néanmoins refusées, car ces options étaient trop universelles et ne reflétaient pas toutes les nuances du travail du studio. "Il y a beaucoup d'aspects spécifiques dans le design", explique le directeur artistique du studio Andrey Kokeev. - Prenez, par exemple, la conception graphique et la conception de produits. Ils sont très différents les uns des autres, en fait, ils ne sont unis que par le mot "design". Nous avons une spécialisation étroite, et il s'est avéré difficile pour nous de trouver quelque chose de tout fait, ou du moins de trouver un consultant qui serait au courant des spécificités de notre travail. »

Le fait est que le studio d'art et de production ART4you fait des récompenses, des prix et des souvenirs exclusifs. Toute la production est expérimentale, un design unique est développé pour chaque produit, et le vol de l'imagination du design n'est limité que par les capacités techniques du studio, et sa base de production est l'une des meilleures de la capitale.

Les employés se sont donc mis à créer leur propre système de KPI. La chose la plus importante était de formuler des critères pour analyser la composante créative du travail de conception.

« Le design est à bien des égards subjectif, et il n'est pas toujours possible de le mesurer ou de l'évaluer à l'aide de schémas standard. En même temps, il est impossible d'écarter la composante créative lors de l'évaluation du travail, car c'est la créativité qui est notre avantage concurrentiel. Les clients viennent chez nous parce que nous avons un design intéressant, et un design intéressant - cela ne peut pas être calculé », a expliqué Andrey Kokeev. Cependant, dès que les critères ont été formulés, il a été possible de prendre en compte l'avis de tous les concepteurs.

Quelques mois plus tard, ils ont commencé à mettre le système en pratique. Nous avons commencé avec quatre critères d'évaluation et avons commencé à augmenter progressivement leur nombre.

Maintenant, le travail des concepteurs est évalué en fonction des paramètres suivants:

  • volume et complexité du travail : monotâche simple, multitâche simple, moyen (standard), difficile, très difficile (cas particulier) ;
  • constructibilité / fabricabilité du travail : dans quelle mesure le projet est technologiquement et constructivement intéressant, original et facile à mettre en œuvre ;
  • créativité du travail présenté;
  • innovations : utilisation de nouveaux matériaux, composants, technologies ;
  • urgence du travail;
  • la survenance de difficultés lors de la mise en œuvre du projet proposé ;
  • transformation en raison des besoins de la production, à l'exception des situations survenues par la faute du concepteur.

Il n'y a pas eu de difficultés particulières dans la mise en œuvre, car tout le monde le voulait, tout le monde était intéressé. Tous les problèmes qui se sont posés ont été résolus immédiatement, et nécessairement collectivement.

« Lorsque les KPI ont été développés et mis en œuvre, nous avons immédiatement convenu qu'il ne s'agissait pas d'une constitution ou d'une vache sacrée, mais d'un système ouvert à une modernisation constante. Nous avons retiré quelque chose de la liste des critères, ajouté quelque chose, le travail était constant et nous sommes finalement arrivés à une version harmonieuse et objective », explique Andrey Kokeev.

En général, cette collégialité est devenue une particularité du système KPI qui a été créé. Cela a permis non seulement de rendre le système le plus transparent possible, mais aussi d'abandonner le programme informatique, ce qui est un avantage incontestable, car cela permet d'économiser de l'argent et du temps. Chaque mois, les concepteurs et la direction se réunissent pour évaluer le travail effectué. Il y a beaucoup de designers dans le studio, beaucoup de travail, les réunions durent deux à trois heures. Pendant longtemps, mais tout le monde est content, car tout le monde peut parler de son travail et de celui des autres : les tâches de conception sont précisées dans CRM Bitrix et sont accessibles à tous les utilisateurs.

"Aujourd'hui, nous avons un système de KPI très efficace pour les concepteurs de notre studio", résume Andrey Kokeev. - Il est aussi transparent et discuté que possible. Les employés ne voient pas seulement l'évaluation de leur travail, ils l'évaluent eux-mêmes. L'équipe de conception est heureuse et facile à gérer."

Conseils d'ART4you :

  1. N'ayez pas peur d'entreprendre le développement et la mise en œuvre de KPI avec peu ou pas de budget. Le manque de fonds n'est pas une raison pour le reporter. D'après notre propre expérience, le studio était convaincu que vous pouvez vous en tirer avec des coûts minimes.
  2. Impliquez ceux dont le travail sera évalué à l'aide de ce système dans l'élaboration d'indicateurs de performance clés. Ces personnes, comme personne d'autre, sont intéressées par une évaluation juste et transparente et savent très bien quels facteurs affectent la qualité et la rapidité de leur travail. De plus, travailler ensemble sur les KPI montrera que vous appréciez vos employés et respectez leurs opinions.
  3. N'hésitez pas à refuser les KPI tout faits, si la situation l'exige. Vous n'avez peut-être pas les fonds en ce moment pour acheter un système prêt à l'emploi ; il est possible que les systèmes prêts à l'emploi ne correspondent pas aux spécificités de votre travail - les raisons de l'échec peuvent être très différentes. Évaluez la situation avec sobriété. Il se peut bien que le refus et le travail indépendant sur les KPI soient la seule bonne option pour votre entreprise.
  4. Étudiez l'expérience de quelqu'un d'autre. Cela vous aidera à savoir où poser vos pailles.
  5. Partagez vos meilleures pratiques. Tout d'abord, c'est tout simplement juste : l'expérience d'autres entreprises vous a permis d'éviter les erreurs lors de la création de votre propre système de KPI, alors aidez aussi quelqu'un. Deuxièmement, votre travail peut très bien être rentable. Au moins une réputation. Le poids de la communauté professionnelle n'a encore dérangé personne.

Lorsque nous venions de démarrer l'entreprise et que je ne pouvais pas proposer d'indicateurs de performance clés pour les développeurs, je suis allé consulter mon ami, le constructeur Viktor Nevara, fondateur du Modular Construction Center. Je lui ai demandé : « Victor, tu as probablement tout selon les formules ? Plâtré un mètre de mur - obtenir de l'argent? " Il a répondu : « Si nous travaillions comme ça, nous ferions immédiatement faillite.

Bien sûr, il a aussi un KPI, mais il accepte le travail de contremaître. Il va casser le mur avec son ongle, voir que le mastic tombe et dire: "Refaites-le et je déduirai de votre salaire l'argent pour le matériau!" Et l'ouvrier sait que le contremaître ne peut pas être dupe, alors il fait tout immédiatement avec une haute qualité. Dans le même temps, le contremaître couvre son propre personnel devant ses supérieurs, distribue équitablement les prix et aidera, le cas échéant.

C'est la même chose avec le travail de bureau. Le travail de routine devient de moins en moins et créatif, dans lequel il existe des critères de qualité non formalisés - plus. Compte tenu de cet état de fait, les KPI ne sont que le pouls de l'entreprise. Le respect des paramètres formels indique que les choses avancent. Et exactement comment il se déplace est évalué par la tête. En général, la meilleure option est de donner une partie du bonus aux employés sur la base des KPI et une partie - sur la base de l'avis du manager. Nous utilisons cette méthode d'évaluation et l'appelons « pro-esclave ».

Soit dit en passant, une attitude formelle envers les KPI entraîne non seulement une perte de qualité, mais également des pertes. Nous avons récemment parlé avec les responsables du studio web AIC, et ils ont parlé de leur cas. Chacun des participants au projet - concepteur, programmeur, etc. - a rempli ses KPI et a reçu une récompense, et le projet dans son ensemble s'est avéré non rentable pour le studio.

Chargement ...Chargement ...