Épigraphe:
Le mari, en regardant les enfants crasseux, dit à sa femme: Eh bien, quoi, nous lavons ceux-ci ou les nouveaux?Sous la coupe de la discussion de notre chef d'équipe, ainsi que d'Igor Marnat, directeur du développement de produits RAS, sur les caractéristiques de la motivation des programmeurs.
Le secret du succès dans la création de produits logiciels sympas est bien connu - prenez une équipe de programmeurs sympas, donnez à l'équipe une idée sympa et n'interférez pas avec le travail d'équipe. Les développeurs sympas sont rares et recherchés. Certains recruteurs disent même avoir l'impression qu'il est plus facile de donner naissance à un programmeur sympa que de l'embaucher sur le marché. En plus des difficultés d'embauche, en tant que telles, l'expérience de chaque développeur spécifique, sa connaissance d'un produit existant et l'historique de son développement sont souvent irremplaçables ou se reconstituent dur et longtemps. Par conséquent, si vous avez de la chance et que vous avez déjà une équipe de programmeurs sympa, il est important de travailler sur leur motivation. Embaucher, former de nouveaux développeurs, en faire une équipe est presque aussi difficile et long que d'accoucher et d'élever des enfants.
Considérez les principaux facteurs qui motivent les programmeurs (équipes de programmeurs), en utilisant la pyramide de Maslow pour la clarté et la structuration de la présentation. Si tout à coup vous n'avez pas entendu parler de la pyramide de Maslow, ce n'est pas une théorie incontestable, mais très populaire et évidente du psychologue américain Abraham Harold Maslow, qui a proposé une théorie de la motivation de la personnalité basée sur une hiérarchie des besoins humains (voir photo ci-dessous).
Maslow a organisé les besoins de l'individu dans un ordre hiérarchique, des besoins physiologiques au besoin de débloquer le potentiel et la réalisation de soi. Une hypothèse clé dans la théorie de Maslow est: "Une personne ne peut pas ressentir les besoins d'un niveau supérieur tant que ses besoins d'un niveau inférieur ne sont pas satisfaits." Par exemple, une personne ne peut pas être motivée par le besoin de connaissances ou par des besoins esthétiques si elle n'a pas dormi ou mangé pendant trois jours.
Avant de plonger dans les détails, insistons sur le fait évident: l'équipe est composée de personnes, toutes les personnes sont différentes, chacune a sa propre structure de motivation. En plus du fait que chaque personne est motivée par des intérêts différents, chaque personne est également dans des conditions de vie différentes. Quelqu'un est au début d'une carrière et réfléchit à la façon de le construire, quelqu'un va se marier et quelqu'un veut apprendre un nouveau domaine. Ce qui est important pour l'un n'a absolument aucune importance pour l'autre, et demain tout changera à nouveau. Afin de comprendre correctement ce contexte, il existe un moyen simple - vous devez y penser et vous devez travailler avec lui. La chose la plus importante est la communication.
Assurez-vous de parler avec votre équipe d'autre chose que de travailler, de construire une relation informelle.
Passons maintenant à la pyramide de Maslow et considérons ses niveaux appliqués à la gestion d'une équipe de programmeurs.
I: Besoins physiologiques, biologiques:En parlant de motivation, beaucoup, tout d'abord, pensent souvent au salaire. Dans ce cas, j'entends par salaire la partie constante de la rémunération, qui ne dépend pas des résultats. Cela ne s'applique pas aux bonus, bonus et promotions de l'entreprise. J'attribuerais le salaire au niveau des «besoins physiologiques» dans notre cas. Bonus, primes en fonction des résultats du travail, options et actions de la société - tout cela, je me réfère à d'autres niveaux.
À mon avis, curieusement, cela peut sembler, le salaire peut être plus un facteur
démotivant que motivant. La particularité de travailler avec les programmeurs est qu'ils sont tous des gens, d'une part, très intelligents (une caractéristique de la profession), et d'autre part, profondément et / ou largement éduqués. Habituellement, les programmeurs, en plus de leur profession, sont profondément versés dans un ou plusieurs domaines pour lesquels ils créent des produits. De plus, les bons programmeurs sont intéressés et connaissent bien l'histoire de la programmation, les algorithmes, les standards, etc. Il en va de même pour leur domaine. Pour les personnes de ce niveau, le salaire n'est généralement pas le principal facteur de motivation.
Dans le même temps, le manque de salaire équitable pour les programmeurs dans leur compréhension démotive et démotive fortement. Avoir un salaire équitable est la norme. Le salaire est beaucoup plus élevé que la norme (marché) - aussi, curieusement, le facteur est plutôt démotivant. Un collègue m'a parlé une fois d'une équipe de programmeurs dans l'une des grandes sociétés américaines d'animation, qui, pour plusieurs raisons, recevaient des salaires au niveau de deux à trois fois le marché. Comme il l'a dit, il n'avait jamais vu de programmeurs plus fatigués, paresseux et démotivés de sa vie. Le fait qu'une augmentation de salaire puisse motiver à court terme, mais après quelques mois, un nouveau salaire devient la norme et cesse de motiver. En général, je dirais que pour les programmeurs au début d'une carrière, le facteur salarial est plus important, car ils grandissent professionnellement et se développent - son importance diminue, et d'autres facteurs commencent à prévaloir.
Le deuxième point important est la présence d'un juste équilibre dans le niveau des salaires dans l'équipe. Si l'équipe estime que la contribution de l'un des participants est sensiblement inférieure, mais que le niveau de rémunération n'est pas différent, cela démotivera toute l'équipe. Parfois, les gestionnaires sont tentés d'inonder le feu avec de l'argent - pour garder une personne épuisée ou démotivée, élevant son salaire au-dessus de la norme. Cela ne crée généralement des problèmes qu'à long terme - la motivation de la personne elle-même n'augmentera pas particulièrement, ou ne augmentera que de quelques mois, mais la motivation du reste de l'équipe diminuera. Dans de telles situations, il vaut la peine de chercher d'autres approches, à moins, bien sûr, qu'il s'agisse d'un spécialiste unique qui doit être maintenu à tout prix, même pour une courte période.
II. Le besoin de sécurité, de confort, de constance des conditions de vie:
Il y a 70 ans, la présence d'un poêle dans une voiture pouvait être un facteur de motivation lors du choix d'une voiture, alors c'était au dessus de la norme, c'était un signe de luxe. Maintenant, même l'absence d'un climatiseur est un non-sens, et sa présence ne sera pas un facteur de motivation lors du choix d'une voiture. Il y a donc 10 à 15 ans, un bureau pratique, du bon fer à repasser, un délicieux café, du fitness, un horaire flexible, etc. pourrait être de bons facteurs de motivation, mais maintenant c'est plutôt la norme pour un bon programmeur de travailler. Dans le même temps, leur absence, encore une fois, démotivera.
Un facteur démotivant important est le manque de capacité de concentration, un environnement de travail bruyant. Le travail d'un programmeur requiert silence et concentration. Si l'espace de bureau ne fournit pas l'occasion de fournir aux développeurs un lieu de travail isolé, il est au moins nécessaire d'assurer une collaboration confortable entre collègues qui n'interfèrent pas les uns avec les autres. Il est préférable d'unir les camarades énergiques et forts les uns aux autres, permettant à ceux qui en ont besoin de se concentrer.
Le coût du temps du programmeur est désormais sensiblement plus élevé que celui du fer à repasser sur lequel il travaille. Deux ou trois moniteurs, des ordinateurs puissants, un lieu de travail pratique pour chaque développeur - devraient être la norme dans toute entreprise. Ce sujet est bien décrit dans l’un des articles de Joel Spolsky «
Le test Joel: 12 étapes pour mieux coder».La composante physique du confort est la plus simple et la plus simple, parlons maintenant du reste.
Dans de nombreuses entreprises, la norme pour les programmeurs de travailler est un horaire de travail flexible et le manque de code vestimentaire. C'est bon et correct si les fonctionnalités de l'équipe le permettent (par exemple, il n'y a pas de réunions avec des clients, des politiciens ou des banquiers).
Un point important est la présence d'une fenêtre de temps spécifique, lorsque toute l'équipe travaille ensemble localement, afin que les gens puissent communiquer et résoudre les problèmes en personne. Le programmeur, en fait, ne quitte pas le travail même après le travail. En règle générale, les moments de travail défilent dans son esprit, quelle que soit sa présence au bureau, et les bonnes décisions viennent souvent en dehors de lui. Étant donné la nécessité d'être bon (sur lequel nous nous attardons ci-dessous), le petit contrôle est nocif. Non seulement il démotive, mais il réduit également les performances. Comme le montre la pratique, en l'absence de contrôle, une équipe motivée est susceptible de travailler plus longtemps que nécessaire. Avec le contrôle, les développeurs peuvent s'asseoir au clavier de neuf à six, mais le résultat, je pense, sera pire. Comme on dit, une personne peut amener un cheval à un abreuvoir, mais même une centaine ne le fera pas boire s'il ne le veut pas.
Dans la description de ce niveau de besoins, l'absence d'anxiété et de peur, l'absence de chaos, le besoin de structure et d'ordre sont également mentionnés. Ce sont également des points extrêmement importants qui affectent grandement l'atmosphère de l'équipe.
Premièrement, l'absence de chaos, de structure et d'ordre - l'équipe doit comprendre qui est responsable de quoi, comment les rôles sont attribués, quoi faire, qui, quand, quelles exigences sont au cœur du produit, quelles sont les attentes des patrons et du client ... être formellement décrit, tout devrait être discuté périodiquement. Sans discussion et utilisation périodique, les descriptions ne fonctionnent pas. Il est recommandé de les consulter et de les mettre à jour périodiquement après l'analyse post-mortem après la publication.
Deuxièmement, une atmosphère calme et conviviale. Nous passons tous la majeure partie de notre temps au travail et nous voulons le faire sans stress, sans conflit ni peur. L'équipe de développement travaille déjà généralement sous la pression du calendrier et des clients. Personne n'a besoin de stress supplémentaire de la part de ses collègues et supérieurs. L'ambiance dans l'équipe, en général, le fait qu'un groupe de développement puisse être appelé et être une «équipe» est la responsabilité directe et importante du manager, l'une des tâches les plus importantes à moyen et long terme. Par conséquent, il est important que le manager travaille, en particulier, avec les conflits de l'équipe, pour ne pas laisser son développement dériver. La gestion des conflits est un sujet distinct qui mérite une étude distincte.
Il y a deux façons principales d'influencer l'état émotionnel d'une équipe, le comportement des collègues (si quelqu'un ajoute dans les commentaires, ce sera parfait). Le premier est leur propre comportement. Un exemple personnel est super important pour le manager et l'équipe. Comme on dit, ce qui est pop, c'est la paroisse. Comportez-vous comme vous attendez de vos collègues. La seconde est la promotion d'un comportement correct et, pour ainsi dire, la dé-promotion du mal. Communiquez avec les gens, donnez-leur leur avis, il y a plusieurs façons de le faire. En général, la rétroaction est un sujet pour une autre discussion, c'est une partie importante et importante du travail avec la motivation.
Une autre remarque sur l'atmosphère, qui peut sembler inhabituelle, mais en pratique elle est importante. Le plus souvent, il y a moins de filles dans l'équipe de développement que d'hommes. Souvent, les équipes sont entièrement masculines. Dans de telles conditions, également sous charge, un vocabulaire parfois obscène commence à être utilisé dans l'équipe. La pratique montre que cela affecte négativement l'atmosphère, la communication devient progressivement désagréable. Vous devez éviter de l'utiliser vous-même et ne pas encourager son utilisation en équipe.
Les équipes de développement sont souvent appelées R&D (recherche et développement), et la recherche est une partie importante du travail. C'est la partie qui est généralement difficile à programmer et à planifier, sinon ce ne serait pas de la recherche. Il est important que l'équipe ait le droit de se tromper, de prendre l'initiative, d'essayer différentes options qui peuvent aboutir ou ne pas aboutir. Les erreurs sont une partie normale du travail, elles ne peuvent pas être évitées, mais vous pouvez étudier, analyser, apprendre d'eux pour l'avenir et passer à autre chose. Le principe 5 pourquoi, qui est originaire de Toyota, aide à trouver la cause profonde du problème. Punir les erreurs est un excellent moyen de créer une atmosphère de peur et d'insécurité. La seule exception est lorsque, selon les résultats de l'analyse, il s'avère que l'erreur est causée par une attitude non professionnelle à l'égard du travail, dans ce cas, il peut être nécessaire de prendre des décisions concernant le personnel.
L'atmosphère dans l'équipe est très influencée par vos attentes, l'état émotionnel avant le début de la conversation. Avant d'entamer une discussion difficile, une sorte de débriefing, ou juste une conversation émotionnelle, votre attitude, votre attitude envers la personne avec qui vous allez parler, est importante. Je pense toujours par défaut et agis en fonction de ce qu'une personne a sincèrement essayé de faire de son mieux. Si vous voyez que ce n'est pas le cas, vous devez trouver calmement et en profondeur le contexte et comprendre ce qu'il a bien fait, pourquoi il pensait que c'était bien et où nos attentes divergent. Habituellement, il s'avère qu'ils ne divergent pas vraiment, juste sa vision du contexte est plus complète ou fraîche, et vous ne saviez pas quelque chose. Ou, au contraire, il ne savait pas quelque chose. Ceci est particulièrement important dans une équipe distribuée, lorsque les gens sont moins susceptibles de communiquer en personne, d'utiliser le courrier et les messageries instantanées. Ceci est encore plus critique dans une équipe composée de programmeurs de différents pays et répartis entre différents fuseaux horaires. Ici, les différences culturelles commencent à jouer un rôle important.
Dans une situation difficile, se déplacer à la volée est simple, très simple, mais alors il est difficile de reculer et les sédiments restent longtemps. Je vais donner un exemple simple de l'expérience récente. L'un des chefs d'équipe avait un besoin urgent de commentaires sur le problème d'un client de la part d'un responsable d'une équipe adjacente d'un autre pays. Il a cinglé un collègue dans le messager, a attendu 15 minutes, a cinglé à nouveau, puis 15 minutes plus tard est entré dans une grande conversation dans laquelle il y avait d'autres gestionnaires, et a légèrement rencontré un collègue avec une formulation comme: «puisque vous ne daignez pas me répondre, peut-être , et la question n'est pas si urgente? ». En conséquence, il s'est avéré que notre messager d'entreprise était un peu ennuyeux et le collègue n'a pas du tout vu la question. J'ai dû m'excuser. En général, il vaut mieux partir du bon. Il est toujours possible de faire une erreur et de recommencer plus tard, cela ne pose aucun problème (même si vous ne devriez pas le faire). En général, pour plus de 20 ans de travail dans notre industrie, j'ai rencontré une collègue vraiment malveillante une (!) Seule fois. Heureusement, nous avons rompu assez rapidement. L'hypothèse selon laquelle les collègues veulent le meilleur, au mieux de leur vision du contexte, est correcte dans la grande majorité des cas.
Votre tâche en tant que manager est d'assurer la synchronisation des contextes, une compréhension commune des attentes, des exigences et des délais adoptés par l'équipe de normalisation. Cela peut sembler être des bagatelles, mais l'atmosphère dans l'équipe est construite précisément à partir de ces bagatelles. Du point de vue d'une équipe répartie, l'une des tâches importantes est d'assurer la communication personnelle périodique des membres de l'équipe. J'ai entendu plus d'une fois par des programmeurs qu'après, par exemple, les ingénieurs de l'équipe de support sont venus vers eux et ont travaillé ensemble en personne, ils sont restés heureux au travail pour aider personnellement dans un cas difficile à Pacha, qui les a récemment visités, bien que plus tôt Pacha n'était qu'une icône dans le messager, et personne ne s'attarderait pour le bien de l'icône.
Au fait, j'ai parlé de l'équipe de support et je me suis souvenu d'un exemple canonique pour moi. D'une manière ou d'une autre, l'un des clients en Amérique a eu un problème avec le produit, l'un des ingénieurs de l'équipe de support qui a travaillé pour lui sur la mise en œuvre (envoyé de Russie) est resté après le travail pour aider, mais le problème n'a pas été résolu et n'a pas été résolu. En général, il s'est attardé et s'est assis là presque jusqu'au matin. À ce moment-là, les gestionnaires de clientèle ont intensifié le problème, identifié sa criticité pour eux et quitté le travail le soir. Le processus d'escalade prenait de l'ampleur déjà dans un autre fuseau horaire, les responsables du support en Russie ont commencé à essayer d'aider, en raison de certaines difficultés de communication avec le bureau du client (VPN, problèmes de communication, difficultés avec les appels entre les pays, ...) ils ne savaient pas que le gars était déjà assis dans le bureau et résout le problème, et a essayé de le trouver. Trouvé uniquement le matin (américain), lorsque le problème a déjà été pratiquement résolu par lui et que le produit a été gagné. Ils ont commencé à courir dans la carrière, bon sang, le client a une telle escalade, rien ne fonctionne, où il vous porte, nous ne pouvons pas vous trouver, etc. Inutile de dire qu'à la suite d'un tel comportement, le gars était très démotivé. L'organisation d'une équipe distribuée est un grand sujet distinct, mais il y a deux choses à garder à l'esprit. Tout d'abord, la communication, l'ambiance est très importante, la réussite du travail en dépend. Deuxièmement, cela ne fonctionne pas seul, il doit être traité séparément et en profondeur.
Un autre point important lié à ce niveau de besoins est à nouveau le salaire. Pas la taille du salaire en tant que tel, mais l'existence d'un certain ordre de changement. L'entreprise devrait avoir une approche pour déterminer les exigences des postes à différents niveaux. Chaque développeur doit pouvoir discuter des attentes de son travail avec l'entreprise, comprendre comment lui et quand ses efforts peuvent affecter son salaire. Des réunions périodiques avec le gestionnaire, des certifications semestrielles ou annuelles remplissent cette fonction. Encore une fois, c'est un de ces moments dont la présence ne motive pas explicitement, mais leur absence motive fortement.
Du besoin d'ordre et de disponibilité des règles, il s'ensuit la nécessité de se conformer à ces règles, de suivre les règles adoptées par l'équipe, formelles et informelles. En général, je l'appellerais la nécessité d'être "bonne". La présence de ce besoin confirme que la microgestion n'est pas nécessaire, plutôt nuisible. Il suffit de fournir à une personne tout ce qui est nécessaire au travail, de lui faire connaître le contexte, les priorités et de lui donner la liberté d'action et de prise de décision à son niveau. , , .
, — , . . . , , . , , . — , , , . “
Google — Site Reliability Engineering ”, , , , , .
À suivre ...