Il y a 15 personnes dans mon studio, dont la moitié sont des programmeurs. Le studio est spécialisé dans le développement de boutiques en ligne, les programmeurs sont donc notre principale ressource.
Trois choses sont toujours exigées des programmeurs
- Remise des projets plus rapide.
- Restez dans votre propre évaluation des coûts de main-d'œuvre.
- Grandir et se développer
Mais pour diverses raisons, ils ne sont pas toujours prêts pour cela. Comment nous avons motivé les programmeurs à s'améliorer dans les trois domaines, quelles difficultés ils ont rencontrées et quelles en sont les conséquences, je le dirai dans l'article.
Comment commencer Ă soumettre des projets plus rapidement
Nous expliquerons immédiatement pourquoi cela est important: si un programmeur soumet un projet plus rapidement, l'entreprise gagne plus rapidement au démarrage et, finalement, le programmeur gagne également plus rapidement. Puisqu'il passe rapidement au projet suivant, et le précédent va au support et à la promotion. Il semblerait que tout soit évident, néanmoins nous avons vu que les programmeurs n'effectuent pas les tâches et livrent les projets aussi vite qu'ils le pouvaient, et avons décidé de les aider à accélérer
Quelle motivation
Première étape
La première option consistait à faire du salaire du programmeur la moitié du salaire et la moitié des primes du projet. En conséquence, l'entreprise et le développeur seront «dans le même bateau», et le succès de l'un affectera directement le succès du second. Il semblerait que tout soit logique, il ne reste plus qu'à accélérer.
De quoi a-t-on besoin pour terminer un projet plus rapidement?
De toute évidence, vous devez programmer plus rapidement. Comment faire Moins de distractions et tout est bon à faire immédiatement, pour que vous n'ayez pas à le refaire.
Mais ici, nous avons rencontré un autre problème: les programmeurs ne sont pas toujours distraits par leur propre faute ou à volonté. Par exemple, un gestionnaire peut transférer un programmeur pour résoudre des problèmes de support de ses projets antérieurs.
De plus, entre le développement et la livraison du projet, il y a un processus d'intégration long et problématique. Le programmeur a donc reçu des bonus pour le développement d'un projet non encore livré. Cela ne semblait pas très logique, nous avons donc continué à chercher des options.
Deuxième étape
La deuxième décision a été de verser des primes à la livraison du projet et non à la fin du projet.
Maintenant, les programmeurs sont devenus encore pires: non seulement les tâches connexes ont influencé leur réception de bonus, mais, par exemple, la vitesse de fourniture d'accès client pour s'intégrer avec le paiement et la livraison (et parfois c'est plusieurs mois), et la vitesse de ses spécialistes 1C (pour l'intégration avec 1C )
Aussi, au stade de la programmation, toutes les erreurs des étapes précédentes sont révélées: planification, conception, conception. Et le programmeur doit les corriger virtuellement pour un simple salaire (et il était très petit dans le cadre de ce système).
Il s'avère que le programmeur reste sans bonus (et ils sont importants) sans aucune faute de leur part.
Cet alignement était inacceptable et l'expérience des primes pour les projets a dû être interrompue.
Ici, il est temps de présenter des excuses à l'équipe de développement pour de telles expériences. Je suis toujours étonné de voir comment ils ne se sont pas tous enfuis alors.
Le résultat de l'expérience a été de comprendre que les programmeurs sont assez motivés pour faire la tâche rapidement et bien, s'ils n'interfèrent pas. Et ils n'ont pas besoin d'incitations supplémentaires.
La motivation matérielle est-elle donc nécessaire dans ce cas?
J'en ai besoin. Un petit bonus à la fin du projet motive le programmeur à ne pas «mieux travailler» (pour cela, selon notre expérience, il n'a pas besoin d'incitation), mais à se plonger dans des domaines connexes. Par exemple, un programmeur, en collaboration avec un chef de projet, étudie les dispositions de conception avant de les montrer à un client, à la recherche d'incohérences et de problèmes. En conséquence, les projets sont beaucoup plus faciles à programmer et à livrer au client.
Le ratio de salaire et bonus Ă la fois au niveau de 80/20%.
Nous nous motivons pour nous adapter à votre évaluation des coûts de main-d'œuvre
S'il est impossible de livrer des projets plus rapidement en raison de la motivation matérielle des développeurs, alors peut-être qu'il vaut la peine de motiver les programmeurs à s'adapter à leurs propres estimations des délais pour les tâches?
De quoi s'agit-il: sur la base d'estimations de la complexité des tâches, il est prévu que les programmeurs travaillent - les tâches sont définies à court terme (semaine) et à long terme (1-2 mois). Par conséquent, si le programmeur ne respecte pas le délai, alors tout le calendrier de travail tombera, les délais se déplaceront sur les projets qui dépendent de lui, etc.
Comment aider le programmeur à respecter le délai prévu?
Il est possible de récompenser si vous avez atteint la marque. Vous pouvez être privé, sinon rencontré.
Cependant, les première et deuxième décisions suggèrent qu'il ne s'agit ici que de motivation et non de raisons externes. Nous avons déjà découvert que les programmeurs, s'ils ne sont pas dérangés, fonctionnent aussi bien que possible.
Nous avons commencé à mener des rétrospectives pour découvrir pourquoi une tâche particulière a pris plus de temps que prévu afin de trouver des «goulots d'étranglement» soit dans la tâche elle-même, soit dans le contexte de son exécution, soit dans la connaissance du programmeur.
Cela a aidé, les tâches ont commencé à être effectuées plus souvent dans le temps imparti. Il est devenu évident que vous devez vous renseigner sur les tâches prolongées avant qu'elles ne tombent hors du délai.
Pour cela, nous avons imaginé des «rétrospectives préliminaires». Lorsque plus de la moitié du temps alloué à la tâche s'est écoulée et que la tâche n'est pas encore proche de la moitié, le programmeur en informe le gestionnaire et ensemble, ils recherchent des raisons.
Donc, à cause de ce que vous ne pouvez pas respecter la date limite pour la tâche
La tâche a été initialement incorrectement évaluée.
Soit la complexité n'a pas été correctement évaluée, soit la solution choisie lors de l'évaluation ne s'est finalement pas adaptée. Cela signifie que le programmeur a un manque de connaissances dans un domaine particulier. Important! Ces informations sont utilisées pour la formation, pas pour punir le programmeur.
La tâche a envahi les détails en cours de route.
Si les détails venaient du client et au début ils n'étaient pas évidents, alors le programmeur corrige l'évaluation, et le gestionnaire vend les heures manquantes et décale la date limite.
Si les détails étaient évidents, mais le manager les a manqués
Cela parle déjà des lacunes dans les connaissances du gestionnaire. Nous comprenons que le gestionnaire doit étudier afin que des problèmes similaires ne se posent plus.
Mais avez-vous besoin d'une motivation financière ici
J'en ai besoin. Nous considérons le prix pour le nombre d'heures vendues au client et élaborées par le programmeur. L'objectif reste le même: étant motivé pour donner une évaluation précise, le programmeur approfondit la tâche, la dirigeant parfois vers la clarification, proposant parfois ses propres versions.
Formation des programmeurs et motivation pour le développement
Au stade rétrospectif, nous constatons des lacunes dans les connaissances des programmeurs, mais comment les amener à étudier et à combler ces lacunes?
Nous sommes situés à Krasnodar, et ici, en général, il y a un studio de commerce électronique (en fait, nous). Cela signifie qu'il n'y a nulle part où prendre du personnel prêt à l'emploi. Et tout le monde doit soit grandir à partir de zéro, soit "grandir" à partir du niveau qu'il avait dans d'autres studios.
Ce qu'un programmeur doit savoir
- Frontend
- Backend
- Moteur
- Intégration (1C et ainsi de suite)
- Linux, Nginx, Apache
Ainsi, nous avons 5 domaines de compétence. Chacun d'eux possède un certain ensemble de compétences à partir desquelles une carte de compétences du programmeur est formée. Il détermine la répartition des développeurs en niveaux (Stagiaire, Junior, Moyen, Senior).
Ă€ mesure que le niveau augmente, le salaire augmente.
Comment nous avons élevé les développeurs
Hypothèse 1
La première idée était de donner aux développeurs une carte des compétences et des supports méthodologiques et de nous proposer de les développer.
Chez Bitrix24, nous avons commencé des tâches automatiques dans lesquelles tout le monde devait rendre compte des progrès de la formation.
Et puis je suis tombé sur le premier problème. Pour une raison quelconque, les programmeurs ne voulaient pas étudier et ne voulaient pas évoluer sur la carte des compétences.
Après quelques mois de vaines tentatives, j'ai deviné leur demander: qu'est-ce qui ne va pas?
Il s'est avéré qu'il y a trop de différence de compétences entre les différents niveaux. Et elle ne motive pas à étudier.
Hypothèse 2
J'ai alors décidé de décomposer les niveaux en plusieurs niveaux (en pourcentage de la carte des compétences étudiée). Et pour chaque niveau, donner une petite augmentation de salaire.
Ça s'est un peu amélioré. Les programmeurs ont cherché à étudier et à passer des examens. Mais encore trop lent.
Le problème suivant est devenu clair: il n'y a pas de temps ni d'énergie pour étudier le matériel à la maison et au travail, les programmeurs sont occupés par des tâches. Ainsi, ceux qui ont une demi-journée d'auto-éducation gratuite ont avancé sur la carte des compétences, et ceux qui ne sont pas restés au même niveau, ce qui les a démotivés froidement.
Hypothèse 3
Donnez du temps libre. Entre les tâches, les programmeurs ont commencé à laisser plusieurs heures par semaine pour la formation.
Et donc ça a marché. Les programmeurs ont commencé à s'épanouir, à passer des tests et à augmenter les salaires.
Ceux qui ne sont pas prêts à apprendre, sous réserve du temps imparti et des perspectives de croissance, devraient simplement être laissés seuls. Il y a des gens qui sont à l'aise à leur niveau et s'ils peuvent clore certaines tâches, alors pourquoi pas?
Conclusions
D'après notre expérience, les programmeurs ont suffisamment de motivation interne, et s'ils ne sont pas dérangés, ils fonctionnent le mieux possible.
Les récompenses servent de motivation supplémentaire non pas tant pour la qualité du travail que pour l'immersion dans le travail de spécialistes connexes (recherche de domaines problématiques dans la conception et les savoirs traditionnels avant qu'il ne soit finalement convenu).
Tous les outils d'apprentissage n'ont de sens que s'il y a deux choses importantes. Sentiments de progrès (y compris les récompenses réalisables) et le temps alloué pour cela. Croyez-moi, quand un programmeur, ayant à peine réussi à clore la tâche en une journée, arrive chez lui après une heure de travail, puis après il n'est absolument pas à la hauteur de votre «plan de développement». Et je pense que "vous apprendrez maintenant et vous aurez du temps libre" ne provoquera qu'une seule réaction silencieuse: "je ne crois pas".