Le billet de blog de Jeff Atwood sur Mechanical Turk d'Amazon suggère qu'il ne devrait pas offrir de récompenses monétaires mais plutôt une motivation intrinsèque , "motivation qui est motivée par un intérêt ou un plaisir dans la tâche elle-même, et existe au sein de l'individu plutôt que de compter sur une pression extérieure".

Comment un membre de l'équipe (un manager, un lead ou un développeur) favorise-t-il la motivation intrinsèque dans une équipe logicielle?

EDIT: Veuillez fournir des réponses complètes. Partagez votre expérience personnelle avec une analyse objective.

EDIT # 2: Pour faciliter une discussion productive et sur le sujet, nous devons supposer que la compensation monétaire est satisfaisante pour le développeur.

En ne le tuant pas . Je parie que tous ceux qui travaillent plus de 5 jours ont rencontré suffisamment de tueurs de motivation pour remplir des livres. Tout le monde jure que s'ils en ont l'occasion, ils feront mieux. Mais d'une manière ou d'une autre, ces tueurs persistent, et ceux qui les mettent en œuvre continuent à penser, ils sont meilleurs, `` toujours l'un des bons '', etc.

Donc, à mon avis, la meilleure façon n'est pas d'essayer de faire le bien, mais d'éviter de faire le mal.

EDIT, modifié sur demande:

La version longue

À mon avis, la motivation intrinsèque est fortement liée à l'identification au travail / à l'entreprise.

L'identification vient de l' identification , comme dans «rendre la chose identique», donc quelqu'un qui s'identifie à son travail essaie d'avoir le moins de différences possible entre «faire le travail» et «faire ce qu'il veut».

Par conséquent, tout ce qui oblige à prendre une décision entre bénéficier à l'entreprise / l'équipe en travaillant et en profitant soi-même est un tueur de motivation potentiel, et en tant que tel, doit être évité.

Certains de ces tueurs que j'ai rencontrés sont:

Communications brisées: Il importe surtout de savoir comment et à qui on dit quelque chose plutôt que quoi. La motivation pour faire la bonne chose (ad res) est punie en tuant le messager, en riant de cassandra et en exécutant publiquement l'ioniste.

Signes: beaucoup de cc, bcc et to dans les courriels, et un écart entre les choses dites lors des réunions et les choses dites à la cafétéria.

Forme au-dessus des résultats: Il importe surtout de savoir comment le travail est effectué, pas ce qu'il produit. La motivation de produire quelque chose de valeur est tuée en n'appréciant pas la chose produite et en punissant la production. Il est beaucoup plus facile de ne rien produire en suivant le protocole.

Signes: «bloqueurs de facebook», horaires fixes, règlement de bureau. (Je pense que Jeff Atwood a écrit quelque chose à propos de 'Furniture Police')

Ennui / impasse: dans ce travail, quand on reste, on manque quelque chose, que ce soit l'occasion d'apprendre, d'accéder à un domaine d'expertise différent (par exemple du codage à la conception) ou d'obtenir un salaire qui peut subvenir aux besoins d'une famille . Et plus on reste longtemps, moins il y a d'opportunités.

Le choix est entre améliorer l'entreprise et s'améliorer.

Signes: tout le monde est connu comme «le gars X», où X est la chose qu'il a fait pour toujours.

Dans le cadre de votre cycle de vie de développement logiciel

• Attribuez les bonnes tâches aux bonnes personnes (si possible)
  • Cela implique qu'ils veulent la tâche en premier lieu
  • Sinon, considérez que cette tâche ne devrait peut-être pas être effectuée
• Attribuer des tâches difficiles
  • Les programmeurs sont des gens créatifs et préféreront avoir une tâche qui est mentalement difficile et pas seulement une refonte excessive de quelque chose qu'ils ont déjà fait.
  • Bien sûr, vous ne pouvez attribuer que les tâches que vous avez sous la main dans le cadre de vos exigences, mais essayez d'identifier comment chacune de ces exigences peut représenter un défi, et choisissez le bon développeur pour cela. Si vos exigences sont toujours les mêmes et ennuyeuses, il y a aussi quelque chose à faire ici. Il n'y a pas de motivation intrinsèque ici, mais il y a un point intrinsèque d'échec et de redondance.
• Utiliser des jeux d'intégration / d'inspection continue
  • Ils sont amusants et motivants
  • Ils encouragent les gens à rechercher la perfection
  • Ils ne sont pas intrinsèques en eux-mêmes, mais ils font simplement appel à la qualité interne du développeur qui veut se perfectionner, apprendre et partager, mais pourrait avoir besoin d'une poussée occasionnelle.
• Utilisez des panneaux muraux (ou radiateurs ) pour SCM, les outils d'intégration continue et d'inspection continue sont amusants et motivants (vous en avez besoin dans le cadre de votre infrastructure, soit dit en passant)
  • Ils séduisent les développeurs pour les mêmes raisons que le jeu CI
  • Même sans l'aspect compétitif, ils donnent un sentiment de fierté et de droit aux développeurs qui participent à un projet.
  • Cela leur permet de voir l'évolution d'un design plus grand s'ils font partie d'une grande équipe.
  • Cela aide également à amener vos équipes (et non vos développeurs, individuellement) à:
    • concurrence (entre projets, sur la qualité du code pour instnace - ne pas concurrencer sur les LOC ... )
    • collaborer (en voulant construire des logiciels qui appartiennent à une famille)
• Utilisez des rétrospectives
  • Ils aident à identifier les problèmes de manière collaborative
  • Ils donnent aux développeurs un sentiment d'appartenance au projet (et à ses erreurs)
  • Ils n'attribuent ni récompense ni blâme (mais donnent un sens des responsabilités )
• les revues de code doivent faire partie intégrante du processus (sinon elles les craindront au lieu de les embrasser).
  • Les développeurs apprendront naturellement à rechercher et à rechercher des éloges
  • Ils seront plus ouverts aux critiques
• Permettre (et encourager) des critiques créatives et constructives
• Permettre (et encourager) le développement personnel
  • Sous forme de projets pour animaux de compagnie
  • Sous forme de prototypes (qui peuvent être des projets pour animaux de compagnie)
  • Les développeurs sont plus heureux lorsqu'ils n'ont pas besoin de se cacher dans leur bureau
• Permettre (et encourager) le partage des connaissances
• Autoriser (et encourager) les développeurs à peaufiner leur code
  • Passer à la tâche suivante peut être passionnant, mais être forcé d' abandonner une tâche sur laquelle vous avez travaillé pendant un certain temps sans la terminer à un niveau de qualité satisfaisant est mauvais pour de nombreuses raisons. Vous perdez ces sentiments mentionnés ci-dessus (fierté du bon travail, savoir-faire, etc ...) et vous perdrez en qualité.
  • Permet aux développeurs de s'amuser tout en terminant leurs tâches, d'expérimenter avec d'autres implémentations (potentiellement bénéfique pour vous si des repères se présentent)
• Rotation des tâches ennuyeuses entre équipes / individus
  • S'assurer que plusieurs personnes possèdent les compétences nécessaires
  • Les faire partager leur fardeau et ressentir un peu plus de compassion pour ceux qui s'occupent de tâches ingrates à un moment donné (au lieu de pointer leurs pairs avec un "Ahah!"), Et de vouloir les aider

Faites tout ce que vous pouvez pour éviter le codage cow-boy ou l'effet sous-marin: vous voulez que vos développeurs soient fiers de ce qu'ils font, qu'ils apprécient ce qu'ils font, qu'ils aiment le montrer aux autres et que d'autres participent à leurs efforts.

Même pour les tâches de documentation, qui peuvent être rebarbatives pour les programmeurs, essayez ce qui suit, pour rendre la documentation plus amusante pour eux, et associez-la au sentiment de produire un produit bien fini. La documentation doit apparaître comme faisant partie intégrante du produit lui-même, et pas seulement comme un livrable formel.

• Leur permettre d'utiliser les outils, les modèles et le processus qu'ils souhaitent
  • définissez-les avant le début du projet et respectez-les pour plus de cohérence
  • mais revoyez-les entre les projets dans le cadre de votre rétrospective pour vous assurer que le processus est aussi léger et agréable que possible
  • utiliser un modèle laid (et, surtout, peu pratique) imposé par le service marketing est un inconvénient
• Permettez-leur de discuter des points de la documentation qu'ils jugent exagérés
  • ils pourraient avoir raison et vous aider à réduire la charge

Faites-les devenir des enseignants , des évangélistes ou tout ce qui les met en position d'apporter du savoir-faire ou des connaissances à d'autres, à la fois dans le cadre de votre SDLC et de votre culture d'entreprise. Quiconque a eu la chance d'enseigner connaît le sentiment qu'il procure, même lorsque vos élèves ne montrent aucun signe de gratitude ( eh bien, vous pensez peut-être que vous les aidez et en fait, vous êtes un professeur de merde et c'est tout .. .mais considérons un cas général ... ) et vous n'obtenez aucune récompense directe. De plus, c'est à la fois responsabilisant et humiliant (vous trouverez toujours quelqu'un qui vous prouvera le contraire ou vous combattra sur quelque chose).

Les sections suivantes décrivent des points qui ne sont pas vraiment intrinsèquement motivants.

Bien qu'ils ne soient pas directement liés à la question, je préfère les laisser dans la liste car ils sont, à mon avis, de bons conseils pour indirectement favoriser cette motivation intrinsèque.

Dans le cadre de votre culture d'entreprise

• mettre en place des discussions / sessions régulières pour les développeurs à partager ...
  • ... les connaissances acquises en travaillant sur le projet
  • ... la connaissance de tout ce qui les rend actifs et passionnés par quelque chose
• faites confiance à vos développeurs
• laisser les décisions techniques aux techniciens
  • les intégrer au processus décisionnel
  • écoutez-les (ou ne soyez pas surpris s'ils se taisent)
• rendre leur vie plus facile et sans frustration:
  • bons outils de développement
  • bon matériel
  • bon environnement
  • la nourriture gratuite
  • jouets stupides qui traînent
  • des lieux pour discuter des idées et des lieux pour réfléchir tranquillement

Pour les nouveaux débutants

• Décrivez les réalisations des nouveaux débutants (pensez aux stades et récompenses de style StackOverflow dont ils ont besoin pour "déverrouiller")
• Attribuez-leur des tâches dans leur niveau de compétence, mais avec suffisamment de défis

Je pense que la plupart des (co) propriétaires d'entreprise manquent un point ici.

Bien sûr, allez-y et fournissez les meilleurs outils que l'argent puisse acheter, mettez les développeurs dans leurs propres bureaux, préparez des repas gratuits / heure de la bière / voyage au Venezuela / peu importe.

Ce sont tous de très bons avantages , mais à la fin de la journée, ils ne servent qu'à un seul but - augmenter les bénéfices du propriétaire (et apparemment faire en sorte que les développeurs "s'amusent" au travail). Et c'est parfaitement bien.

Mais, pour tous ceux qui ont un travail en dehors de la journée, je dis, oui, je voudrais ces avantages s'il vous plaît, mais ils ne sont en aucun cas un substitut à ma prime / récompense / 13e salaire / peu importe - la motivation monétaire fonctionne très bien pour moi. Si cela ne semble pas fonctionner, peut-être que les responsables de l'entreprise ne distribuent pas suffisamment de liquidités à un rythme raisonnable.

Malheureusement, des études montrent ( voir cet article New Scientist , abonnement requis pour le texte intégral) que l'argent n'est pas un grand facteur de motivation pour les efforts créatifs. En fait, cela peut rendre les gens moins durs à travailler.

La meilleure façon de motiver les gens est donc de les aider à croire que le travail qu'ils font n'est pas essentiel à leur survie. Cela leur permettra de prendre des risques plus importants et donc d'être plus créatifs.

Comment devez-vous procéder?

Essentiellement, le problème survient à cause de choses comme la rémunération liée au rendement. Les gens doivent savoir que ce qu'ils font est bien, mais vous n'avez pas besoin de dépendre de la taille de leur paquet de paie.

Si vous voulez motiver les gens avec de l'argent, faites-le pour des choses triviales comme faire attention aux réunions.

La créativité est favorisée par le fait d'être dans un environnement où l'expérimentation est autorisée et non punie parce qu'elle ne rencontre pas un objectif ou un autre.

Ce que vous voulez, c'est équilibrer l'expérimentation avec la mise en œuvre de méthodes éprouvées. Vous inversez donc le problème. Par exemple, pour chaque problème client N corrigé ou pour chaque fonctionnalité de rapport insipide implémentée, vous pouvez jouer avec de nouvelles technologies ou chercher de nouvelles façons de résoudre d'anciens problèmes.

S'il y a de l'argent pour les bonus, utilisez-le à la place pour participer à des conférences (auxquelles votre équipe souhaite participer), ou affectez-le à une sorte de projet extra-commercial expérimental / intéressant (avec lequel votre équipe souhaite participer) pour acheter équipement.

En faisant confiance à leurs développeurs pour faire la bonne chose

La plupart des développeurs essaieront de développer des produits de qualité s'ils en ont les moyens. Si un développeur demande un équipement plus rapide ou de meilleurs moniteurs ou des conditions de travail silencieuses - travaillez pour les fournir.

La motivation dépend des attitudes envers les tâches à accomplir. Si nous avons une attitude pour briller ou exceller dans une tâche, nous pourrions en fait faire pire. Pensez aux jours où vous faisiez des tests à l'école ou si vous faisiez partie d'un club de sport, où vous vouliez exceller ou gagner le match. UNE état d'esprit de performance se traduit par une pression qui nous empêche souvent de très bien performer ou de trouver des solutions créatives (voir Dan Pink sur la motivation ). Par conséquent, l'utilisation de récompenses basées sur ses performances peut en fait conduire à moins de motivation intrinsèque à accomplir la tâche.

Contrairement à un état d'esprit de performance, il existe une orientation vers le travail basée sur un état d'esprit d'apprentissage . Ici, le résultat n'est pas important en soi, mais le processus de réalisation de la tâche et la compréhension du contexte d'une tâche. Dans l'analogie sportive, c'est quand vous essayez juste de vous améliorer un peu. Il n'y a aucune attente de gagner finalement, juste donner le meilleur et apprendre de l'échec. Améliorer la compréhension de l'échec éventuel, se traduit par une richesse et des connaissances personnelles et peut augmenter notre motivation intrinsèque à plus long terme. Ce type de mentalités est discuté par le Dr Steve Ritter (CMU) et Carol Dweck (Stanford).

Permettez-moi de jouer l'avocat du diable.

Les gens sont des créatures très égoïstes. Ils se préoccupent surtout d'eux-mêmes. Très difficile de changer cela. Par conséquent, vous devez explorer cette faiblesse et la mettre à votre avantage.

Lorsque les gens possèdent «un intérêt ou un plaisir pour la tâche elle-même», cela signifie qu'ils poursuivent leur intérêt personnel pour satisfaire leur curiosité ou apprendre un outil. Pourquoi apprendre un outil? Pour l'utiliser dans leur programmation personnelle (auto-orientée) ou en faire un avantage marketing (profit gourmand). Il n'y a pratiquement aucune trace d'altruisme.

Afin de "favoriser la motivation intrinsèque", vous devez mettre vos objectifs dans une douce prime que les membres de l'équipe voudraient avoir. Combinez ce qui est précieux pour l'entreprise (connaissances et expertise dans un domaine technique ou non technique) avec ce qui est précieux pour l'individu personnellement (certifications renommées, titre du poste, augmentation salariale). Pensez dans cette direction.

Et pour être honnête, oui, il y a bien sûr des individus altruistes. Sans eux, le monde serait déjà tombé. Mais alors ils ne sont pas nécessairement intéressés à rejoindre vos rangs, ils peuvent toujours trouver un autre moyen de contribuer à la société (open source, projets personnels, assistance dans les forums, etc.). Vous êtes donc de retour aux bases, comment lubrifier vos programmeurs gourmands pour les faire bouger.

Je pense que ce que M. Atwood dit, c'est que vous devriez embaucher des gens qui sont intéressés par les problèmes que vous allez résoudre . Leur motivation découle d'un intérêt préexistant, intrinsèque à la personne. Je ne pense pas que vous puissiez favoriser la motivation intrinsèque, je pense que vous ne pouvez que faire appel à elle.

La rémunération est toujours importante, mais étant donné la même rémunération, je préfère travailler dans un endroit qui a des problèmes qui m'intéresse. Je vais naturellement et involontairement travailler plus dur parce que j'ai cet intérêt.

Il est normal que les membres d'une équipe soient motivés différemment. Certaines personnes travaillent pour une motivation extrinsèque (par exemple de l'argent) et d'autres pour une motivation intrinsèque (par exemple un logiciel de qualité).

Cependant, ces membres de l'équipe doivent pouvoir travailler ensemble et partager leurs forces les uns avec les autres.

Un développeur est acceptable s'il produit un travail de qualité; cependant, s'ils n'apprécient pas vraiment leur travail, il serait difficile de les employer comme leader. Un trait de leadership important est l'enthousiasme, car il pousse les autres à profiter de la tâche à accomplir.

Une autre dynamique importante est celle d'une interaction sociale saine et régulière. Joel Spolsky a récemment blogué sur les avantages des déjeuners d'équipe : "Manger ensemble est un élément essentiel de ce que signifie être humain et de ce que signifie avoir un lieu de travail humain ..." Même si le développeur stéréotypé est introverti, la solitude est démoralisante et rend difficile la programmation.

En résumé, grâce à un leadership enthousiaste et en encourageant la camaraderie , la motivation intrinsèque qui existe chez certains et qui fait défaut à d'autres peut être transférée et partagée par l'équipe.

À mon avis, la motivation intrinsèque correspond au dernier besoin des individus dans la hiérarchie des besoins de Maslow; ce n'est pas un besoin en soi, mais qui vient de la réalisation de soi. Bien que cette hiérarchie ne soit pas applicable dans toutes les circonstances, ignorer la base de cette hiérarchie conduit souvent à un manque de motivation intrinsèque.

Alors que la plupart des organisations s'efforcent d'amener les individus à atteindre leur dernier besoin, la plupart ne le font pas car elles ne se concentrent pas sur les besoins au bas de la hiérarchie.

Mon point de vue sur l'article et la théorie sous-jacente est que c'est une tentative des propriétaires d'entreprise de dévaluer le coût de la main-d'œuvre et de faire croire aux gens que "vous n'avez pas besoin de tout cet argent pour être heureux, donc cela n'aura pas d'importance si nous ne vous accordons jamais d'augmentation ou si nous vous embauchons à un taux inférieur à celui du marché. Vous devriez être heureux d'avoir un emploi, sans parler d'un emploi aussi engageant que celui-ci, alors engagez-vous déjà! Maintenant, rappelez-vous, vous mieux vaut venir le samedi de 6h à minuit car c'est ce que fait une ouvrière-abeille "engagée". Vous aurez une belle tape dans la tête et un "bon travail!" une fois que vous avez fini de vous tuer pour le projet. "

L'étude indique que peu importe le montant que vous payez à quelqu'un, ce qui le rend "à l'aise" dans la mesure où il n'a pas à se soucier de la façon dont il va payer ses factures ou mettre de la nourriture sur la table. alors combien ça coûte? 40k USD par an? 30k?

Pour ce qui est de favoriser la motivation intrinsèque, je suis d'accord avec @keppala. La motivation intrinsèque vient de l'intérieur. Le mieux que vous puissiez faire est de ne pas l'étouffer des employés qui en ont.