プログラマーのチームを管理する: プログラマーのモチベーションを適切に高める方法と方法は? パート XNUMX

エピグラフ：
夫は汚れた子供たちを見ながら妻にこう言います。「さて、この子供たちを洗おうか、それとも新しい子供たちを産もうか？」

カットの下には、プログラマーのモチベーションを高めることの特殊性について、チームのリーダーであり RAS 製品開発ディレクターである Igor Marnat が語った内容が含まれています。

クールなソフトウェア製品の作成で成功する秘訣はよく知られています。クールなプログラマのチームを編成し、チームにクールなアイデアを与え、チームの作業を邪魔しないことです。 クールな開発者は稀であり、需要があります。 採用担当者の中には、市場から優秀なプログラマーを採用するよりも、優れたプログラマーを生み出す方が簡単であるという印象を持っているとさえ言う人もいます。 雇用そのものの難しさに加えて、特定の開発者の経験、既存の製品とその開発の歴史に関する知識は、多くの場合、かけがえのないものであるか、補充するのが困難で時間がかかります。 したがって、運が良く、優秀なプログラマーのチームをすでに持っている場合は、彼らのモチベーションを高めるために取り組むことが重要です。 新しい開発者を雇用してトレーニングし、その開発者でチームを編成することは、子供を産んで育てるのと同じくらい難しく、時間がかかります。

プレゼンテーションを明確にし、構造化するためにマズローのピラミッドを使用して、プログラマー (プログラマーのチーム) のモチベーションの主な要因を考えてみましょう。 マズローのピラミッドについて聞いたことがない方のために説明しておきますが、これは誰もが認めるアメリカの心理学者アブラハム・ハロルド・マズローの非常に有名で説明的な理論です。マズローは、人間の欲求の階層に基づいた個人の動機付けの理論を提案しました (下の図を参照)。

マズローは、生理的欲求から潜在的な発達と自己実現の欲求まで、個人の欲求を階層的な順序で整理しました。 マズローの理論の重要な前提は、「人は低次の欲求が満たされるまで、高次の欲求を経験できない」ということです。 たとえば、その人が XNUMX 日間寝たり食べなかったりすると、知識や美的欲求に駆られることはできません。

詳細に入る前に、明白な事実に焦点を当てましょう。チームは人々で構成され、全員が異なり、それぞれが独自のモチベーション構造を持っています。 各人が異なる興味によって動かされているという事実に加えて、各人は異なる生活環境にもいます。 キャリアのスタート地点にいて、それをどのように構築するかを考えている人、結婚しようとしている人、新しい分野を習得したいと考えている人がいます。 ある人にとって重要なことは、別の人にとってはまったく重要ではありません。そして明日にはすべてが再び変わります。 このコンテキストを正しく理解するには、簡単な解決策があります。それについて考え、それに取り組む必要があります。 最も重要なことはコミュニケーションです。
チームとは必ず仕事以外のことについて話し、非公式な関係を築きましょう。

それでは、マズローのピラミッドを見て、そのレベルをプログラマーのチームの管理に適用したものとして考えてみましょう。

I: 生理的、生物学的ニーズ:

モチベーションについて話すとき、多くの人は給与を最初に考えることがよくあります。 この場合、給与とは報酬パッケージの恒久的な部分を意味し、結果にはまったく依存しません。 これはボーナス、賞与、会社のプロモーションには適用されません。 私たちの場合、「生理的欲求」のレベルに起因すると考えられるのは給与です。 ボーナス、業績に基づくボーナス、オプション、会社の株式など、私ならこれらすべてを別のレベルに分類します。

私の意見では、それがどんなに奇妙に聞こえるかもしれないとしても、給与はむしろ やる気を失わせる 動機というよりも要因。 プログラマーと働くことの特徴は、プログラマーが全員、第一に非常に頭が良く (この職業の特徴)、第二に、深くおよび/または幅広い教育を受けていることです。 通常、プログラマーは、その職業に加えて、製品を作成する XNUMX つ以上の主題領域について深く理解しています。 さらに、優れたプログラマは、プログラミング開発の歴史、アルゴリズム、標準などに興味があり、よく知っています。 同じことが対象分野にも当てはまります。 このレベルの人々にとって、給与は通常、主な動機要因ではありません。

同時に、プログラマーにとって公正な給与が得られないことは、彼らの理解では、やる気を失い、大いにやる気を失わせます。 それなりの給料をもらうのが当たり前です。 給与は標準（市場）よりもはるかに高いですが、これも奇妙なことに、かなりやる気を失わせる要因です。 かつて同僚が、アメリカの大手アニメーション会社のプログラマーのチームについて話してくれました。そのチームは、さまざまな事情により、市場の XNUMX ～ XNUMX 倍の水準の給与を受け取っていました。 彼が言ったように、これまでの人生でこれほど退屈で怠惰でやる気を失ったプログラマーを見たことがありませんでした。 給与が上がるという事実は、短期的にはモチベーションを高めるかもしれませんが、数か月後には新しい給与が標準になり、モチベーションが失われます。 一般に、プログラマーのキャリアの初期段階では、給与要因の方が重要ですが、専門的に成長し、成長するにつれて、給与要因の重要性は低下し、他の要因が優勢になり始めると思います。

XNUMX 番目に重要な点は、チーム内の給与水準に公平なバランスが存在することです。 報酬レベルが同じでも、あるメンバーの貢献度が著しく低いとチームが感じた場合、チーム全体の意欲が減退します。 時々、管理者はお金で火に油を注ぐ誘惑に駆られることがあります。つまり、燃え尽き症候群ややる気を失った人を通常よりも給料を上げることで引き留めようとするのです。 これは通常、長期的には問題を引き起こすだけです。本人のモチベーションはあまり上がらないか、数か月間は上がるものの、チームの他のメンバーのモチベーションは低下します。 このような状況では、たとえ短期間であっても、どんな犠牲を払ってでも雇用する必要があるユニークな専門家でない限り、他のアプローチを探す価値があります。

II. 安全性、快適さ、生活条件の一貫性の必要性:

70 年前、車にストーブが装備されていることが車を選ぶ際の動機となり得ましたが、当時はそれが標準を上回り、贅沢の象徴でした。 今やエアコンがないこと自体がナンセンスであり、もちろんエアコンの有無は車を選ぶ動機にはならないだろう。 つまり、10〜15年前には、便利なオフィス、優れたハードウェア、おいしいコーヒー、フィットネス、フレックスタイムなどがありました。 それは良い動機付け要因になる可能性がありますが、今ではこれが優れたプログラマーの仕事の標準となっています。 同時に、彼らの不在は再びやる気を失わせるでしょう。

モチベーションを低下させる重要な要因は、集中力の欠如と騒々しい作業環境です。 プログラマーの仕事には、沈黙と集中力が必要です。 オフィススペースが開発者に人里離れたワークスペースを提供する機会を提供しない場合は、少なくともお互いに干渉しない同僚間の快適なコラボレーションを確保する必要があります。 精力的で騒々しい仲間を互いに団結させ、必要な人に集中する機会を与える方が良いでしょう。

現在、プログラマーの時間コストは、プログラマーが作業するハードウェアのコストよりも大幅に高くなっています。 XNUMX 台または XNUMX 台のモニター、強力なコンピューター、すべての開発者にとって快適な職場は、どの企業でも標準であるはずです。 このトピックは、Joel Spolsky の記事の XNUMX つで詳しく説明されています。Joel テスト: より良いコードを作成するための 12 ステップ。」

快適さの物理的要素は最も基本的かつ単純なもので、残りについて説明しましょう。

多くの企業では、プログラマーの標準的な勤務スケジュールは柔軟であり、服装規定はありません。 チームの仕事の詳細が許可する場合 (たとえば、顧客、政治家、銀行家との会議がない場合)、これは適切であり、正しいことです。

重要なのは、チーム全体がローカルで協力する特定の時間を確保し、人々が直接コミュニケーションをとり、問題を対面で解決できるようにすることです。 プログラマーは本来、仕事が終わっても仕事を辞めません。 通常、オフィスにいるかどうかに関係なく、仕事上の問題が頭の中で繰り返され、適切な決定はオフィスの外から得られることがよくあります。 善良である必要性を考えると（これについては後述します）、つまらないコントロールは有害です。 それはやる気を失わせるだけでなく、生産性も低下させます。 実践が示すように、コントロールができないと、やる気のあるチームは必要以上に長く働く可能性が高くなります。 コントロールがあれば、開発者はXNUMX時からXNUMX時までキーボードの前に座ることができますが、結果はさらに悪化すると思います。 よく言われるように、XNUMX人でも馬を水辺まで連れて行くことはできますが、たとえXNUMX人でも、飲みたくない場合は無理に水を飲ませることはできません。

このレベルのニーズの説明では、不安や恐怖からの自由、混乱の欠如、構造と秩序の必要性についても言及されています。 これらはチームの雰囲気を大きく左右する非常に重要なポイントでもあります。

第一に、混乱、構造、秩序の欠如 - チームは、誰が何を担当するのか、役割がどのように配分されるのか、何を行う必要があるのか​​、誰に対して、いつ、どのような要件が製品の根底にあるのか、経営陣は何を期待しているのか、そして顧客... このほとんどは正式に説明する必要があり、すべてを定期的に話し合う必要があります。 議論と定期的な使用がなければ、説明は機能しません。 定期的に議論し、リリース後の事後分析の結果に基づいて更新することをお勧めします。

XNUMXつ目は、穏やかでフレンドリーな雰囲気です。 私たちは皆、ほとんどの時間を仕事に費やしており、ストレスや葛藤、恐怖を感じることなく仕事をしたいと考えています。 開発チームは通常、スケジュールや顧客からのプレッシャーの下で働いています。 同僚や上司からさらなるストレスを受ける必要はありません。 チーム内の雰囲気、一般に開発者のグループを「チーム」と呼んでよいかどうかは、マネージャーの直接的かつ重要な責任であり、最も重要な中長期的なタスクの XNUMX つです。 したがって、マネージャーは、特にチーム内の対立に対処し、チームの成長をそのまま放置しないことが重要です。 紛争管理は別のトピックであり、個別に研究する価値があります。

チームの感情状態や同僚の行動に影響を与えるには、主に XNUMX つの方法があります (誰かがコメントを追加してくれれば、それは素晴らしいことです)。 XNUMXつ目はあなた自身の行動です。 個人的な模範はマネージャーやチームにとって非常に重要です。 彼らが言うように、司祭もそうですが、到着もそうです。 同僚に期待される行動をとります。 XNUMX つ目は、正しい行動を奨励し、いわば間違った行動を奨励しないことです。 人々とコミュニケーションをとり、フィードバックを与えるなど、その方法はたくさんあります。 一般に、フィードバックは別の議論のトピックであり、モチベーションを維持して働く上で重要かつ重要な部分です。

雰囲気についてのもう XNUMX つの注意点は、珍しいように思えるかもしれませんが、実際には重要です。 開発チームには男性よりも女性の数が少ないことがよくあります。 多くの場合、グループは全員男性です。 このような状況では、また負荷がかかっているため、チーム内で卑猥な言葉が使用され始めることがあります。 実際にやってみると、これが雰囲気に悪影響を及ぼし、コミュニケーションが徐々に失礼になってしまうことがわかっています。 自分自身での使用は避け、チーム内での使用も控えるべきです。

開発チームは R&D (研究開発) と呼ばれることが多く、研究が作業の重要な部分を占めます。 これは通常、プログラムや計画が難しい部分です。そうでなければ研究とは言えません。 チームには、間違いを犯したり、主導権を握ったり、成功するかどうかわからないさまざまなオプションを試す権利があることが重要です。 間違いは仕事ではつきものであり、避けることはできませんが、将来のために勉強し、分析し、そこから学んで先に進むことはできます。 トヨタで生まれた「なぜ 5 つの原則」は、問題の根本原因を突き止める良い方法です。 間違いを罰することは、恐怖と不安の雰囲気を作り出す優れた方法です。 唯一の例外は、分析の結果に基づいて、そのエラーが業務に対する非専門的な態度によって引き起こされたことが判明した場合であり、この場合、人事上の決定を下す必要がある場合があります。

チーム内の雰囲気は、会話が始まる前の期待や感情状態に大きく影響されます。 難しい議論、ある種の報告会、または単なる感情的な会話を始める前に、話す相手に対するあなたの気分と態度が重要です。 私は常に、その人が心から最善を尽くしようとしたことをデフォルトで信じ、それに基づいて行動します。 あなたの立場から見てそうではないと思われる場合は、冷静かつ詳細に状況を把握し、彼の行動が正しかったこと、それが正しいと考えた理由、そして私たちの期待がどこで異なるのかを理解する必要があります。 たいていの場合、それらは実際には乖離しているわけではなく、単に彼の文脈に対するビジョンがより完全であるか新鮮であり、あなたが知らなかったことがあるだけであることがわかります。 あるいは逆に、彼は何も知らなかったのです。 これは、人々が直接コミュニケーションをとることが少なくなり、電子メールやインスタント メッセンジャーを使用する分散チームでは特に重要です。 これは、さまざまな国のプログラマで構成され、さまざまなタイムゾーンに分散しているチームではさらに重要です。 ここで文化の違いが大きな役割を果たし始めます。

困難な状況では、移動中の運転は簡単で非常に簡単ですが、戻って運転するのは難しく、堆積物は長い間残ります。 最近の経験から簡単な例をあげましょう。 チーム マネージャーの 15 人は、顧客に関する何らかの問題について、別の国の関連チームのマネージャーからのコメントを緊急に必要としていました。 彼はメッセンジャーで同僚に ping を送り、15 分待って再度 ping を送り、20 分後に他のマネージャーもいる大規模なチャットに行き、その同僚を次のような言葉で軽く攻撃しました。答えていただけますか？その質問はそれほど緊急ではありませんか？」 結局、私たちの会社のメッセンジャーは少し鈍くて、同僚は質問をま​​ったく理解していなかったことが判明しました。 謝らなければなりませんでした。 一般に、良いことから始める方が良いでしょう。 ひどい間違いを犯して後で問題に遭遇する可能性は常にありますが、それは問題ありません (ただし、そうすべきではありません)。 一般的に、この業界で XNUMX 年以上働いていますが、本当に悪意のある同僚に出会ったのは XNUMX 度だけです (!)。 幸いなことに、私たちはすぐに別れました。 ほとんどの場合、同僚は状況を理解して最善を尽くしたいと考えるのが正しいことがわかります。

マネージャーとしてのあなたの仕事は、コンテキストの同期、チーム内で受け入れられている期待、要件、期限、基準についての共通理解を確保することです。 小さなことかもしれませんが、チームの雰囲気はそんな小さなことから成り立っています。 分散チームの観点から見ると、重要なタスクの XNUMX つは、チーム メンバーが定期的に対面でコミュニケーションできるようにすることです。 私はプログラマーから、例えば、サポートチームのエンジニアが彼らのところに来て、直接一緒に働いた後、喜んで職場に残って、最近彼らのところに来たパシャに個人的に難しいケースを手伝ってくれたという話を何度も聞きました。とはいえ、以前のパシャはメッセンジャーの単なるアイコンであり、アイコンのために立ち止まる人はいなかったでしょう。

ところで、サポート チームについて話し始めて、標準的な例を思い出しました。 かつてアメリカの顧客のXNUMX人が製品に問題を抱え、その実装に携わったサポートチームのエンジニアのXNUMX人（ロシアから出向）が仕事後に残って手伝ってくれたが、問題は解決せず解決には至らなかった。 一般に、彼はほとんど朝までそこに残り、座っていました。 この時点で、顧客のマネージャーは問題をエスカレーションし、問題が彼らにとって重要であることを特定し、夕方に仕事を辞めました。 エスカレーション プロセスは別のタイム ゾーンですでに勢いを増していました。顧客のオフィスとの通信に特定の困難 (VPN、接続の問題、国家間の通話の問題など) があったため、ロシアのサポート マネージャーが支援を試み始めました。その男がすでにオフィスで刑務所にいて問題を解決していることを知らず、彼を見つけようとしました。 彼らがそれを発見したのは、問題がすでに実質的に解決され、製品が動作していた朝 (アメリカ人) でした。 すぐに彼らは、「何だ、顧客がこんなにエスカレーションしている、何もうまくいかない、どこにいるのか、見つからない」などと言い始めました。 言うまでもなく、そのような行動の結果、その男はひどくやる気を失いました。 分散チームの作業を組織することは別の大きなトピックですが、XNUMX つのことを覚えておくことが重要です。 まず、コミュニケーションと雰囲気が非常に重要であり、仕事の成功はそれにかかっています。 第二に、これは単独で機能するものではなく、個別に詳細に対処する必要があります。

このレベルのニーズに関連するもう XNUMX つの重要な点は、やはり給与です。 給与の大きさそのものではなく、給与を変更するための一定の手続きの有無です。 企業は、さまざまなレベルのポジションの要件を決定するアプローチを持っている必要があります。 各開発者は、自分の仕事に対する期待について会社と話し合い、自分の努力が給与にいつどのように影響するかを理解できる必要があります。 マネージャーとの定期的なミーティング、半年または年に一度の業績評価がこの目的に役立ちます。 これもまた、彼らの存在が明確な動機を与えるわけではないが、彼らの不在が非常にやる気を失わせる瞬間の XNUMX つです。

秩序の必要性とルールの存在から、これらのルールを遵守し、公式および非公式の両方でチーム内で受け入れられている規範に従う必要性が生じます。 一般的に言って、私はそれを「善良でありたい」という欲求と呼んでいます。 このニーズの存在は、マイクロマネジメントが必要ではなく、むしろ有害であることを裏付けています。 仕事に必要なものをすべて提供し、状況や優先順位についての知識を与え、その人のレベルでの行動と意思決定の自由を与えるだけで十分です。 そのような状況では、彼は信頼を感じ、自分で決定を下し、それらに責任を負い、自分の可能性を明らかにする機会を得るでしょう。

秩序の必要性と混乱の欠如に起因するもう XNUMX つの重要な点は、タスクに集中する能力、つまり頻繁なコンテキストの切り替えがないことです。 プログラマーになるには時間と集中力が必要です。 プログラマーは、あるタスクをすぐに放棄して別のタスクに切り替えることを好みません。 プログラマーの仕事に必要な部分は通常、コードの実際の開発だけでなく、バ​​グ修正や顧客からのリクエストの処理支援も含まれます。 プログラマーが別のタスクに切り替える前に、あるタスクの作業を落ち着いて完全に完了できるように、事前にそのようなことを計画する価値があります。 最善の選択肢は、自分で仕事を計画する機会を与え、優先順位と今後のタスクを事前に特定し、XNUMX つの種類のタスクに取り組むために長期間の時間を割り当てることです。 このトピックについては、次の本に詳しく説明されています。Google - サイト信頼性エンジニアリング」では、大規模で負荷の高いフォールトトレラントなシステムの運用と開発を保証するチームや、ソフトウェア開発とそのサポートを職業とするエンジニアの作業を計画するアプローチについて詳しく説明しています。

継続するには...

出所： habr.com