ジェフ・アトウッドのAmazonの機械トルコ人のブログの記事は、それが金銭的な報酬ではなく、提供してはならないことを示唆している本質的な動機を、「タスク自体に興味や楽しさによって駆動される動機、むしろ任意の外部の圧力に頼るよりも、個々の中に存在しています。」

チームメンバー（マネージャー、リード、または開発者）は、ソフトウェアチームの本質的な動機付けをどのように促進しますか？

編集：包括的な回答を提供してください。客観的な分析であなたの個人的な経験を共有してください。

編集＃2：生産的でトピックに関する議論を促進するために、開発者にとって金銭的な補償は十分であると想定する必要があります。

それを殺さないことによって。きっと、5日以上働いている人は皆、本を書くのに十分なモチベーションキラーに会っています。皆が誓う、機会があれば彼らはもっと良くなるだろう。しかし、どういうわけか、これらの殺人者は存続し、それらを実装する人は通常、彼らはより良い、「まだ良い人の1人」などと考え続けます。

だから、私の意見では、最善の方法は良いことをしようとするのではなく、悪いことをするのを避けることです。

編集、リクエストに応じて修正：

ロングバージョン

私の意見では、本質的な動機は仕事/会社との同一性に強く関連しています。

識別はから来ている識別するために、彼の作品で彼自身を識別し、誰かが「仕事をしている」と「彼が望んでいることをやって」の間のできるだけ少し違いとして持ってしようとしたので、「STH同じをするために」のように、。

したがって、仕事をすることによって会社/チームに利益をもたらすことと、自分自身に利益をもたらすことの間の決定を強制するものはすべて、潜在的なモチベーションキラーであり、したがって、避けるべきです。

私が遭遇した殺人者のいくつかは次のとおりです。

壊れたコミュニケーション：それは、何よりも、どのように、誰に対して何かを言うかが大事です。正しいことをする動機（ad res）は、メッセンジャーを殺し、カサンドラを笑い、アトナーを公に処刑することによって罰せられます。

サイン：多くのcc、bccおよびtoメール、および会議での発言とカフェテリアでの発言の不一致。

フォームオーバー結果：それは、仕事がどのように行われるかではなく、それが生み出すものではなく、主に重要です。価値のあるものを生産する動機は、生産されたものを評価せず、生産を罰することによって殺されます。プロトコルに従うだけで何も生成しない方が簡単です。

兆候：「facebook blockers」、固定勤務時間、デスク規制。（ジェフ・アトウッドは「家具警察」に関する記事を書いたと思います）

退屈/デッドエンド：この仕事では、滞在するとき、何かを逃します。学習する機会、異なる専門分野に到達する機会（コーディングから設計など）、または家族に提供できる報酬を得る機会。そして、長く滞在するほど、機会は少なくなります。

選択肢は、会社を改善するか、自分自身を改善するかです。

サイン：誰もが「Xの男」として知られています。Xは彼が永遠にやったことです。

ソフトウェア開発ライフサイクルの一部として

• 適切なタスクを適切な人に割り当てる（可能な場合）
  • これは、彼らが最初にタスクを望んでいることを意味します
  • そうでない場合は、このタスクを実行しないでください。
• やりがいのあるタスクを割り当てる
  • プログラマーは創造的な人間であり、すでにやったことのやり直しをやり直すだけでなく、精神的に困難なタスクを好むでしょう。
  • もちろん、要件の一部として手元にあるタスクのみを割り当てることができますが、これらの各要件が課題をどのように表現できるかを特定し、それに適した開発者を選択してください。要件が常に同じで退屈な場合は、ここでやることもあります。ここには固有の動機付けはありませんが、障害と冗長性の固有のポイントがあります。
• 継続的インテグレーション/検査ゲームを使用する
  • 彼らは楽しくてやる気があります
  • 彼らは人々が完璧を目指して努力することを奨励します
  • 彼らはそれ自体に固有のものではありませんが、彼らは自分自身を完成させ、学び、共有したいが、時折プッシュを必要とするかもしれない開発者の内部品質に訴えるだけです。
• 利用ウォールボード（またはラジエーターSCMに）をと、継続的インテグレーションと継続的検査ツールが楽しくてやる気になります（これらはインフラストラクチャの一部として必要になります）
  • CIゲームと同じ理由で開発者にアピールします
  • 競争面がなくても、彼らはプロジェクトに参加する開発者に誇りと資格を与えます。
  • 大規模なチームの一員であれば、より壮大なデザインの進化を見ることができます。
  • また、チーム（開発者ではなく）を次のようにすることができます。
    • 競合する（プロジェクト間、インスタンスのコード品質について-LOCで競合しない...）
    • 共同作業（家族に属するソフトウェアを構築したい）
• 回顧を使用する
  • 彼らは共同で問題を特定するのに役立ちます
  • 開発者にプロジェクトに所属しているという感覚を与えます（そしてその間違い）
  • 彼らは報酬も非難も割り当てません（しかし、責任感を与えます）
• コードレビューはプロセスの不可欠な部分である必要があります（または、彼らはそれらを受け入れる代わりにそれらを恐れます）。
  • 開発者は賞賛を求めて努力することを自然に学びます
  • 彼らは批判に対してよりオープンになります
• 創造的かつ建設的な批判を認める（そして奨励する）
• 個人的な開発を許可（および奨励）
  • ペットプロジェクトの形で
  • プロトタイプの形式（ペットプロジェクトの場合もある）
  • 開発者は、オフィスに隠れる必要がないので幸せです
• 知識の共有を許可（および奨励）
• 開発者がコードを洗練できるようにします（そして奨励します）
  • 次のタスクに進むことはエキサイティングなことがありますが、満足のいくレベルの品質に仕上げずにしばらくの間作業を放棄せざるを得ないのは、多くの理由で悪いことです。上記のこれらの感情（良い仕事、職人技などの誇り）を失い、品質を失います。
  • 開発者がタスクを終えながら楽しんで、代替の実装を試すことができます（ベンチマークが来れば、あなたにとって有益になる可能性があります）
• チーム/個人間で 迷惑なタスクを交代
  • 複数の人が必要なスキルを持っていることを確認する
  • 彼らに負担を分かち合い、ある時点で恩知らずな仕事をしている人たちにもう少し思いやりを感じさせるために（仲間に「アハ！」を向ける代わりに）、彼らを助けたい

カウボーイコーディングや潜水艦の影響を避けるために、できる限りのことをしてください。開発者に自分のやることを誇りに思って、自分のやることを楽しんでもらい、他の人に見せて楽しんでもらい、他の人の努力に参加してもらいたいです。

プログラマにとっては厄介なドキュメント作成タスクであっても、ドキュメント作成をより楽しくするために次のことを試してみてください。ドキュメントは、正式な成果物ではなく、製品自体の不可欠な部分として表示される必要があります。

• 必要なツール、テンプレート、プロセスを使用できるようにする
  • プロジェクトの開始前にそれらを設定し、一貫性のためにそれらに固執する
  • 振り返りの一環としてプロジェクト間でレビューし、プロセスができるだけ軽量で楽しいものになるようにします
  • マーケティング部門からあなたに押し付けられたい（そして何よりも実用的ではない）テンプレートを使用することはダウナーです
• やりすぎだと感じるドキュメントのポイントについて話し合うことができます
  • 彼らは正しいかもしれませんし、負荷を減らすのに役立ちます

それらになる作り、教師、伝道者か何かその人にノウハウや知識をもたらすの位置を入れ、それらを、両方のあなたのSDLCのとあなたの企業文化の一部として。生徒が感謝の兆しを見せない場合でも、教える機会を与えられた人なら誰でもそれが感じる気持ちを知っています（まあ、あなたは彼らを助けていると思っているかもしれず、実際はくだらない先生であり、それがすべてです。しかし、それでも、一般的なケースを考えてみましょう...）、あなたは直接的な報酬を得られません。さらに、それは同時に権限付与と謙虚さです（あなたは常にあなたが間違っていることを証明したり、何かであなたと戦うだろう誰かを見つけるでしょう）。

以下のセクションでは、本質的に動機付けにならないポイントの概要を説明します。

それらは質問に直接関係していないかもしれませんが、この内在的な動機付けを間接的に助長するための良い指針であるように、リストに残しておくことを好みます。

企業文化の一部として

• 開発者が共有するための定期的なトーク/セッションを設定...
  • ...プロジェクトでの作業中に獲得した知識
  • ...何かに積極的で情熱を注ぐものに関する知識
• 開発者を信頼する
• 技術的な決定は技術者に任せる
  • それらを決定プロセスの一部にする
  • それらに耳を傾けます（または、彼らが黙っていても驚かないでください）
• 生活を楽にし、欲求不満をなくします。
  • 優れた開発ツール
  • 良いハードウェア
  • 良い環境
  • 無料の食事
  • バカおもちゃ
  • アイデアについて話し合う場所、静かに反省する場所

新規スターター向け

• 新規スターターの成果の概要（StackOverflowスタイルのステージと、「ロック解除」に必要な賞を考えてください）
• スキルレベル内でタスクを割り当てますが、十分な課題があります

ほとんどのビジネス（共同）所有者はここでポイントを逃していると思います。

確かに、お金を買うことができる最高のツールを提供し、開発者を自分のオフィスに入れ、無料の食事/ビールの時間/ベネズエラへの旅行などを提供します。

これらはすべて本当に素晴らしい特典ですが、結局のところ、彼らは1つの目的にしか役立ちません-所有者の利益を増やします（そして、明らかに、開発者を仕事で「楽しく」する）。そしてそれはまったく問題ありません。

しかし、日中の仕事以外の生活をしている私たち全員にとって、はい、私はそれらの特典をお願いします、しかし彼らは私のボーナス/報酬/ 13番目の給料/何でも代用ではありません-お金の動機は非常にうまくいきます私のために。うまくいかないようであれば、会社を管理している人たちが合理的なペースで十分な現金を払っていないのかもしれません。

残念ながら、研究は、お金が創造的な努力の大きな動機付けではないことを示しています（この新しい科学者の記事、全文に購読が必要です）。実際、それは人々の仕事を難しくしません。

したがって、人々をやる気にさせる最良の方法は、彼らがしている仕事が彼らの生存にとって重要でないと彼らが信じるのを助けることです。これにより、彼らはより大きなリスクを取ることができ、したがってより創造的になります。

これについてどうすればいいですか？

基本的に、パフォーマンス関連の給与などの問題が原因で問題が発生します。人々は自分たちがしていることは正しいことを知る必要がありますが、有料パケットのサイズをそれに依存させる必要はありません。

お金で人々をやる気にしたい場合は、会議で注意を払うなどのささいなことのためにそれを行います。

創造性は、実験が許可されており、何らかの目標を満たしていないために処罰されない環境にいることによって促進されます。

必要なのは、実験と試行済みのテスト済みメソッドの実装とのバランスを取ることです。したがって、問題を逆にします。たとえば、N個の顧客の問題が修正されるたびに、または当たり障りのないレポート機能が実装されるたびに、新しいテクノロジーを試すか、古い問題を解決する新しい方法を検討します。

ボーナスにお金がある場合は、代わりにそれを使用して会議に参加するか（チームが参加したい）、または何らかの実験的/興味深いエクストラビジネスプロジェクト（チームが参加したい）に購入します装置。

開発者が正しいことをすることを信頼することにより

ほとんどの開発者は、そのための機能が与えられれば、高品質の製品を開発しようとします。開発者がより高速な機器、より良いモニター、または静かな労働条件を求めている場合は、それらを提供するために働きます。

動機は、実行する必要があるタスクに対する態度に依存します。私たちが仕事に輝いたり卓越したりする態度を持っているなら、私たちは実際に悪化しているかもしれません。学校でテストをしたり、ゲームに勝ったり、勝ったりしたいスポーツクラブの一員であった時代を思い出してください。パフォーマンスの考え方が多い（参照本当によく実行するか、創造的な解決策を見つけるために私たちを妨げていることの圧力に結果動機にダンピンク）。したがって、自分のパフォーマンスに基づいて報酬を使用すると、実際にはタスクを実行する固有の動機が少なくなります。

パフォーマンスの考え方とは対照的に、学習の考え方に基づいた仕事へのオリエンテーションがあります。ここでは、結果自体は重要ではありませんが、タスクを実行し、タスクのコンテキストを理解するプロセスです。スポーツの例えでは、これはあなたがほんの少し改善しようとするときです。最終的に勝つことへの期待はなく、最善を尽くして失敗から学ぶだけです。最終的な失敗の理解を改善することは、個人の富と知識につながり、長期的には私たちの本質的な動機を高めることができます。この種の考え方は、スティーブリッター博士（CMU）とキャロルドウェック（スタンフォード）によって議論されています。

悪魔の擁護者を演じさせてください。

人々は非常に利己的な生き物です。彼らはほとんど自分自身に関心があります。それを変えるのは非常に難しい。したがって、この弱点を調査し、それをあなたの利点に変える必要があります。

人々が「タスク自体に興味や楽しみを持っている」ということは、好奇心を満たすため、またはツールを学ぶために個人的な興味を追求していることを意味します。なぜいくつかのツールを学ぶのですか？パーソナルプログラミングで使用する（自己志向）か、マーケティングアドバンテージに変換する（貪欲な利益）。利他主義の痕跡はほとんどありません。

「内発的な動機付けを促進する」ためには、チームメンバーが望むであろう甘い恵みの中に目標を置く必要があります。会社にとって価値のあるもの（技術分野または非技術分野の知識と専門知識）と個人にとって価値のあるもの（有名な資格、肩書き、給与の上昇）を組み合わせます。この方向に考えてください。

そして正直に言うと、もちろん、利他的な個人もいます。それらがなければ、世界はすでに落ちていただろう。しかし、彼らは必ずしもあなたのランクに参加することに興味があるわけではなく、彼らは常に社会に貢献する別の方法を見つけることができます（オープンソース、個人プロジェクト、フォーラムでの支援の提供など）。それで、あなたは基本に戻り、貪欲なプログラマを動かして彼らを動かす方法に戻ります。

アトウッド氏が言っていることは、あなたが解決しようとしている問題に興味のある人を雇うべきだと思います。彼らの動機は既存の関心から派生し、それはその人に固有のものです。内在的な動機を育てることができるとは思わない。それに訴えることができるだけだと思う​​。

報酬は依然として重要ですが、同じ報酬を与えられれば、私が興味を持っている問題がある場所で働きたいと思います。

チームのメンバーのモチベーションが異なるのは当然のことです。外在的動機付けのために働く人（お金など）と内在的な動機付けのために働く人（品質の高いソフトウェアなど）。

ただし、これらのチームメンバーは協力して、お互いに強みを共有できる必要があります。

開発者は、質の高い作品を作成できれば受け入れられます。しかし、彼らが本当に自分の仕事を楽しんでいないなら、彼らをリーダーとして雇うことは難しいでしょう。重要なリーダーシップの特徴は熱意です。というのも、それは目の前の課題を楽しんで他の人を励ますからです。

別の重要なダイナミクスは、健康で定期的な社会的相互作用です。ジョエル・スポルスキは最近、ブログチームのランチの利点について：「一緒に食べると、それは人間とそれは人道的な職場を持っていることの意味をあることを意味するものの重要な部分です...」、ステレオタイプの開発者が内向されていても寂しさをがっかりされ、プログラミングを楽しむのが難しくなります。

要約すると、熱心なリーダーシップと同志を奨励することにより、一部の人が持っていて他の人に欠けている本質的な動機をチームに移して共有することができます。

私の意見では、内発的動機付けは、マズローのニーズの階層における個人の最後のニーズに対応しています。それ自体は必要ではなく、自己実現から生まれるものです。この階層はすべての状況に適用できるわけではありませんが、この階層の基礎を無視すると、多くの場合、本質的な動機付けが不足します。

ほとんどの組織は、個人が最後のニーズを達成するよう努めていますが、ほとんどの組織は、階層の最下部のニーズに焦点を合わせていません。

記事とその背後にある理論に対する私の見解は、それが労働者のコストを切り下げ、「あなたが幸せになるためにこのお金すべてを必要としないので、それが重要ではない」と人々に信じさせる試みであるということです昇給を決してしない場合、または市場価格より低いレートで雇用する場合は、このような魅力的な仕事は言うまでもなく、仕事に就いていることに満足しているはずです。土曜日の午前6時から深夜までは、「従事している」働きバチがやっているからです。頭を軽く叩いて、「良い仕事を！」プロジェクトのために自分を殺すことが終わったら。」

この調査では、請求額を支払うか、テーブルに食べ物を置くかを心配する必要がないという点で、「快適」な金額を誰かに支払うことは重要ではないと述べています。 。それはいくらですか？年額4万ドル？30k？

内発的な動機付けを促進する方法に関しては、@ keppalaに同意します。本質的な動機は内から来る。あなたができる最善のことは、それを持っている従業員からそれを嗅ぎ取らないことです。