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

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

カットの下には、プログラマーのモチベーションを高めることの特殊性について、当社のチーム リーダーであり RAS 製品開発ディレクターである Igor Marnat による記事の後半が含まれています。 記事の最初の部分はここからご覧いただけます - habr.com/ru/company/Parallels/blog/452598

記事の最初の部分では、マズローのピラミッドの下位 XNUMX つのレベルである生理的欲求、安全、快適さ、恒常性の欲求について触れ、次の XNUMX 番目のレベルに進みます。

3 - 所属と愛の必要性

イタリアのマフィアのことを「コーサ・ノストラ」と呼ぶのは知っていましたが、「コーザ・ノストラ」がどのように訳されるのかを知り、とても感動しました。 「Cosa Nostra」とはイタリア語で「私たちのビジネス」を意味します。 名前の選択はモチベーションにとって非常に効果的です (職業は脇に置きましょう。この場合はモチベーションだけに興味があります)。 人は通常、チームの一員になり、大きな、一般的なビジネスを行いたいと考えます。

陸軍、海軍、およびあらゆる大規模な民兵組織では、所属と愛の欲求を満たすことが非常に重要視されています。 そして、ご覧のとおり、マフィアの中で。 これは当然のことです。なぜなら、共通点がほとんどなく、最初は志を同じくする人々のチームを形成せず、（自発的ではなく）徴兵によって集められ、教育レベルも個人的価値観も異なる人々を強制する必要があるからです。 、致命的な危険を冒して、文字通り自分の命を共通の目的に捧げるには、戦友に自分の命を託してください。

これは非常に強い動機であり、ほとんどの人にとって、自分が何か大きなものに属していると感じること、自分が家族、国、チームの一員であることを知ることが非常に重要です。 軍隊では、制服、さまざまな儀式、パレード、行進、横断幕などがこれらの目的に役立ちます。 どのチームにとってもほぼ同じ要素が重要です。 シンボル、企業ブランドやコーポレートカラー、道具や記念品も重要です。

重要なイベントには、それを関連付けることができる独自の目に見える具体例があることが重要です。 現在では、企業が独自の商品、ジャケット、T シャツなどを持っていることがむしろ普通のことになっています。 しかし、社内のチームを強調することも重要です。 リリースの結果に基づいて T シャツをリリースすることがよくあり、リリースに関わるすべての人にプレゼントされます。 チーム全体でのイベント、共同祝賀会、または活動も、モチベーションのもう XNUMX つの重要な要素です。

外部属性に加えて、他のいくつかの要因がチームへの帰属意識に影響を与えます。
まず、誰もがその重要性を理解し、評価を共有する共通の目標の存在です。 プログラマーは通常、自分たちが素晴らしいことをしていること、そしてこの素晴らしいことをチームとして一緒にやっているということを理解したいと考えています。
第二に、チームには、チーム全体が存在し、チームのみに属するコミュニケーション スペースが必要です (たとえば、メッセンジャーでのチャット、定期的なチームの同期など)。 仕事の問題に加えて、非公式なコミュニケーション、時には社外のイベントについてのディスカッション、オフトップの明かりなど、これらすべてがコミュニティとチームの感覚を生み出します。
第三に、チーム内に優れたエンジニアリング手法を導入し、社内で受け入れられている基準と比較して基準を向上させたいという願望を強調したいと思います。 業界で受け入れられている最良のアプローチを、まずチームで、次に会社全体で導入すると、チームは何らかの形で他のチームより先を行っている、先頭に立っていると感じる機会が得られ、帰属意識が生まれます。クールなチームに。

帰属意識は、チームが企画や運営に参加するかどうかによっても左右されます。 チームメンバーがプロジェクトの目標、作業計画、チームの標準およびエンジニアリングの実践について話し合ったり、新入社員と面談したりすることで、参加意識、所有権の共有、および仕事への影響力が生まれます。 人は、たとえ実質的に意見が一致していても、他人が提案した決定よりも、自分で決めて発言した決定を実行することにはるかに意欲的です。

誕生日、記念日、同僚の人生における重要なイベント、共同のピザ、チームからのささやかな贈り物は、温かい関与と感謝の気持ちを与えます。 一部の企業では、勤続5年、10年、15年に対して小さな記念サインを贈るのが慣例となっています。 一方で、これが私に新たな成果へのモチベーションをそれほど与えるとは思えません。 しかし、明らかに、ほとんどの人は彼のことを忘れていないことに満足するでしょう。 これは、事実の存在がやる気を引き出すのではなく、事実の欠如がやる気を失わせるケースの 10 つです。 同意します。朝、LinkedIn が職場でリマインドして XNUMX 周年を祝福してくれたのに、会社の同僚が XNUMX 人もあなたを祝福してくれなかったり、あなたのことを覚えていてくれなかったら、それは非常に残念なことかもしれません。

もちろん、大きなポイントはチーム構成の変更だ。 チームからの誰かの到着または出発が事前に（たとえば、会社やチームのニュースレター、またはチーム会議で）発表されたとしても、それが特に誰かを新たな成果に向けて動機付けるわけではないことは明らかです。 しかし、ある晴れた日に隣に新しい人が現れたり、古い人が見えなかったりすると、それは驚くべきことであり、その場を離れるとまったく不快な気持ちになるでしょう。 人は静かに消えてはいけません。 特に分散チームではそうです。 特に、あなたの仕事が突然現れて消えた別のオフィスの同僚に依存している場合は特にそうです。 そのような瞬間は、必ず事前にチームに個別に通知する価値があります。

英語ではこう呼ばれる重要な要素 所有権 （「所有」の直訳はその意味を完全には反映していません）。 これは所有感ではなく、自分のプロジェクトに対する責任感であり、感情的に自分自身を製品と結びつけ、製品と自分を結びつけるときの感情です。 これは映画『フルメタル・ジャケット』の海兵隊員の祈りにほぼ対応します。これは私のライフルです。 このようなライフルはたくさんありますが、これは私のものです。 私のライフルは私の親友です。 彼女は私の人生です。 自分の人生を所有するのと同じように、それを所有することを学ばなければなりません。 私がいないと私のライフルは役に立ちません。 ライフルがないと駄目だよ。 ライフルをまっすぐに撃たなければなりません。 私を殺そうとしている敵よりも正確に撃たなければなりません。 彼が私を撃つ前に、私は彼を撃たなければなりません。 そうしましょう…」。

人が長い間製品に取り組み、その創造と開発に全責任を負い、「何もない」状態から機能するものがどのように生まれ、人々がそれをどのように使用するかを知る機会があると、この強い感情が生まれます。 XNUMX つのプロジェクトに長期間にわたって協力する製品チームは、通常、短期間で編成され、製品全体に完全な責任を持たずに、あるプロジェクトから別のプロジェクトに切り替えながら組立ライン モードで作業するチームよりも、より意欲的で団結力があります。 、 初めから最後まで。

IV. 承認の必要性

優しい言葉は猫にとっても嬉しいものです。 誰もが自分の行った仕事の重要性を認識し、それが肯定的に評価されることでモチベーションを高めます。 プログラマーと話し、定期的にフィードバックを与え、仕事がうまくいったことを祝いましょう。 大規模で分散したチームがある場合は、定期的なミーティング (いわゆる XNUMX 対 XNUMX) がこれに最適です。チームが非常に小さく、ローカルで協力している場合は、通常、カレンダーに特別なミーティングはなくても、この機会が提供されます (ただし、定期的なミーティングは必要です)。 XNUMX つにするだけで十分です。それでも必要ですが、頻度を減らすだけで済みます)。 このトピックは、manager-tools.com のマネージャー向けのポッドキャストで詳しく取り上げられています。

ただし、文化の違いを念頭に置く価値があります。 アメリカ人の同僚に馴染みのあるアプローチの中には、ロシア人の同僚には必ずしもうまくいくとは限らない。 西側諸国のチームの日常コミュニケーションで受け入れられている礼儀正しさのレベルは、ロシア出身のプログラマーにとっては最初は過剰に見えます。 ロシア人の同僚に特徴的な率直さは、他の国の同僚には無礼に受け取られる可能性があります。 これは、民族間チームのコミュニケーションにおいて非常に重要です。このテーマについては多くの著作があり、そのようなチームのマネージャーはこれを覚えておく必要があります。

プログラマーがスプリント中に開発された機能を示す機能のデモンストレーションは、このニーズを実現するための良い方法です。 これは、チーム間のコミュニケーション チャネルを明確にし、プロダクト マネージャーやテスターに​​新機能を紹介する絶好の機会であるという事実に加えて、開発者にとっても自分の作業の結果を示し、自分の作成者を示す良い機会でもあります。 もちろん、人前で話すスキルを磨きましょう。もちろん、それは決して有害ではありません。

チームの合同懇親会で、特に著名な同僚の多大な貢献を賞状や記念サイン（少なくとも優しい言葉）で祝うのは良い考えでしょう。 人々は通常、そのような証明書や記念の看板を非常に高く評価し、引っ越しの際にも持ち歩き、あらゆる方法でそれらの世話をするのが一般的です。

チームの仕事、経験と専門知識の蓄積に対する、より重要かつ長期的な貢献を示すために、等級制度がよく使用されます (ここでも、軍隊の階級制度と類似することができます。従属性を確保することもこの目的に役立ちます）。 多くの場合、若い開発者は、新たなスターを肩代わりするために XNUMX 倍の努力をします (つまり、ジュニア開発者からフルタイム開発者に移行するなど)。

従業員の期待を知ることは非常に重要です。 高い等級、たとえば建築家と呼ばれる機会によって動機づけられる可能性が高い人もいれば、逆に等級や肩書には無関心で、給与の増加は会社からの評価の表れであると考える人もいます。 。 人々とコミュニケーションをとり、彼らが何を望んでいるのか、何を期待しているのかを理解しましょう。

新しい仕事分野への行動や関与の自由を増やすことで、チームの側での認識、つまりより高いレベルの信頼を示すことができます。 たとえば、プログラマは、一定の経験を積み、一定の結果を達成した後、仕様に従って機能を実装することに加えて、新しいもののアーキテクチャに取り組むことができます。 あるいは、テストの自動化、ベストエンジニアリングプラクティスの実装、リリース管理の支援、カンファレンスでの講演など、開発に直接関係しない可能性のある新しい分野に参加することもできます。

V. 認知と自己実現の必要性。

多くのプログラマーは、人生のさまざまな段階でさまざまな種類のプログラミング活動に集中しています。 機械学習をしたり、新しいデータ モデルを開発したり、仕事のために科学文献をたくさん読んだり、新しいものをゼロから作成したりするのが好きな人もいます。 もう XNUMX つは、既存のアプリケーションのデバッグとサポートに近いもので、既存のコードを深く掘り下げ、ログ、スタック トレース、ネットワーク キャプチャを何日も何週間も調査する必要があり、新しいコードはほとんど記述しません。

どちらのプロセスも多大な知的努力を必要としますが、実際の成果は異なります。 プログラマーは既存のソリューションをサポートすることに消極的であり、むしろ新しいソリューションを開発することに意欲を持っていると考えられています。 これには一粒の知恵があります。 一方、私がこれまで一緒に働いた中で最も意欲的で団結したチームは、既存の製品のサポートに専念し、サポート チームからの連絡後にバグを見つけて修正していました。 彼らは文字通りこの仕事のために生きており、土日には出かける準備ができていました。 私たちはかつて、31月1日の夜かXNUMX月XNUMX日の午後に、別の緊急かつ複雑な問題に熱心に取り組んだことがあります。

この高いモチベーションにはいくつかの要因が影響しました。 まず、それは業界で有名な会社であり、チームはその会社と提携していました (「所属の必要性」を参照)。 第二に、彼らは最後のフロンティアであり、彼らの後ろには誰もおらず、当時は製品チームもありませんでした。 彼らと顧客の間には XNUMX つのレベルのサポートがありましたが、問題が顧客に達した場合は、逃げ場はなく、誰も彼らの背後にはいませんでした。会社全体 (XNUMX 人の若いプログラマー) が彼らをサポートしていました。 第三に、この大企業は非常に大規模な顧客 (各国政府、自動車および航空関連企業など) を抱えており、いくつかの国で非常に大規模な設備を設置していました。 その結果、常に複雑で興味深い問題も、単純な問題も、前のレベルのサポートによって解決されました。 第 XNUMX に、チームのモチベーションは、やり取りするサポート チームの専門レベルに大きく影響され (非常に経験豊富で技術的に有能なエンジニアがいました)、私たちは彼らが準備したデータの品質、彼らが実行した分析に常に自信を持っていました。 、など。 XNUMX 番目に、これが最も重要な点だと思います。チームは非常に若く、全員がキャリアの初期段階にありました。 彼らは、大規模で複雑な製品を研究し、新しい環境で初めての深刻な問題を解決することに興味を持ち、周囲のチーム、問題、顧客のレベルを専門的に一致させることに努めました。 このプロジェクトは素晴らしい学校であることが判明し、その後全員が社内で良いキャリアを積み、技術リーダーや上級マネージャーになりました。そのうちの XNUMX 人は現在アマゾン ウェブ サービスの技術マネージャーになり、もう XNUMX 人は最終的に Google に転職しました。彼らの中には今でもこのプロジェクトを温かく覚えています。

このチームが 15 ～ 20 年の経験を持つプログラマーで構成されていた場合、モチベーションは異なるでしょう。 もちろん、年齢と経験が 100% の決定要因ではなく、すべてはモチベーションの構造に依存します。 この特別なケースでは、若いプログラマーの知識と成長への欲求が素晴らしい結果をもたらしました。

一般に、すでに何度か述べたように、プログラマーの期待を知り、どのプログラマーが自分の活動分野を拡大または変更したいと考えているかを理解し、これらの期待を考慮に入れる必要があります。

マズローのピラミッドを超えて: 結果の可視性、ゲーミフィケーションと競争、でたらめではありません

プログラマーのモチベーションに関しては、必ず言及する必要がある重要な点がさらに XNUMX つありますが、それらをマズローのニーズ モデルに引き込むのはあまりにも人工的すぎます。

XNUMX つ目は、結果の可視性と近さです。

ソフトウェア開発は通常、マラソンのようなものです。 研究開発の取り組みの結果は、数か月、場合によっては数年後に現れます。 地平線の彼方にある目標に向かうのは難しい、仕事の量は恐ろしい、目標は遠く、明確ではなく見えない、「夜は暗くて恐怖に満ちている」。 そこへの道をいくつかの部分に分割し、目に見えて到達でき、輪郭が明確で、私たちから遠くない最も近い木への道を作り、この近い目標に向かう方が良いでしょう。 数日または数週間かけて取り組み、結果を取得して評価し、次に進みたいと考えています。 したがって、作業を小さな部分に分割する価値があります (アジャイルのスプリントはこの目的に適しています)。 私たちは仕事の一部を完了しました - それを記録し、吐き出し、議論し、罪を犯した人を罰し、無実の人に報酬を与えました - 私たちは次のサイクルを始めることができます。

このモチベーションは、コンピュータ ゲームを完了するときにプレイヤーが経験するものとある程度似ています。プレイヤーは各レベルを完了すると定期的にメダル、ポイント、ボーナスを受け取ります。これは「ドーパミン モチベーション」と呼ぶことができます。

同時に、結果の可視性も文字通り重要です。 リスト内の閉じられたフィーチャは緑色に変わります。 コードが書かれ、テストされ、リリースされたにもかかわらず、プログラマに見える視覚的な状態に変化がない場合、プログラマは不完全であると感じ、完了の感覚はありません。 私たちのバージョン管理システムのチームの XNUMX つでは、各パッチは XNUMX つの連続した段階を経ました。つまり、ビルドがアセンブルされてテストに合格し、パッチがコード レビューに合格し、パッチがマージされました。 各段階には、緑色のチェックマークまたは赤色の×印が付いています。 開発者の一人が、コードレビューに時間がかかりすぎる、同僚がスピードアップする必要がある、パッチが数日間ハングアップしていると不満を述べたことがありました。 私は、これが彼にとって実際に何を変えるのかと尋ねました。 結局のところ、コードが書かれ、ビルドがアセンブルされ、テストに合格したとき、コメントがなければ、送信されたパッチに注意を払う必要はありません。 同僚自身がレビューを行い、それを汚します（やはりコメントがない場合）。 彼は「イーゴリ、できるだけ早く緑のチェックを XNUMX つ手に入れたいのです。」と答えました。

XNUMX番目のポイントは、ゲーミフィケーションと競争です。

製品の 3 つを開発するとき、私たちのエンジニアリング チームは、オープン ソース製品の XNUMX つでコミュニティ内で重要な地位を占め、トップ XNUMX に入るという目標を掲げていました。 当時、コミュニティ内での誰かの知名度を評価する客観的な方法はありませんでした。参加している大企業のそれぞれが、自分がナンバーワンの貢献者であると主張することはできました (定期的に主張することもできました) が、参加者の貢献を比較する実際の方法はありませんでした。それらの間で、そのダイナミクスを時間の経過とともに評価します。 したがって、一部のオウムで測定できるようなチームの目標を設定したり、その達成度を評価したりする方法はありませんでした。 この問題を解決するために、私たちのチームは企業と個人の貢献者の貢献を測定し、視覚化するツールを開発しました。 www.stackalytics.com。 モチベーションの観点から見ると、それは単なる爆弾であることが判明しました。 自分たちの進捗状況や同僚や競合他社の進捗状況を常に監視しているのは、エンジニアやチームだけではありませんでした。 当社およびすべての主要な競合他社のトップマネジメントも、スタカリティクスから一日を始めました。 すべてが非常に透明かつ視覚的になり、誰もが自分の進捗状況を注意深く監視したり、同僚と比較したりできるようになりました。 エンジニア、マネージャー、チームにとって、目標を設定するのが便利かつ簡単になりました。

定量的指標のシステムを実装するときに生じる重要な点は、定量的指標を実装するとすぐに、システムは自動的に定性的指標を犠牲にして、これらの定量的指標の達成を優先しようとすることです。 たとえば、完了したコードレビューの数が指標の 1 つとして使用されます。 明らかに、コード レビューはさまざまな方法で行うことができます。テストのチェック、ベンチでの実行、ドキュメントのチェックなど、複雑なパッチの徹底的なレビューとチェックに数時間を費やして、カルマにプラス 1 のレビューを得ることができます。数分で数十個のパッチを盲目的にクリックし、それぞれに +XNUMX を与えると、カルマが XNUMX 増加します。 エンジニアがパッチをクリックするのが早すぎて、CI システムからの自動パッチに +XNUMX を与えてしまうというコミカルなケースもありました。 後で私たちは「行け、行け、ジェンキンス」と冗談を言いました。 コミットの場合、コード整形ツールを使用してコードを調べ、コメントを編集し、ピリオドをカンマに変更して、カルマを高めた人もたくさんいました。 これに対処するのは非常に簡単です。私たちは常識を利用し、定量的な指標に加えて、重要な定性的な指標も使用します。 チームの作業結果の利用度、外部貢献者の数、テストカバレッジのレベル、モジュールと製品全体の安定性、規模とパフォーマンスのテストの結果、コアレビュアーの肩を受け取ったエンジニアの数ストラップ、プロジェクトがコア プロジェクト コミュニティに受け入れられたという事実、エンジニアリング プロセスのさまざまな段階の基準への準拠 - これらすべておよび他の多くの要素を、単純な定量的指標とともに評価する必要があります。

そして最後に、XNUMX 番目のポイント - でたらめではありません。

開発者は非常に賢い人々であり、業務において非常に論理的です。 彼らは 8 日に 10 ～ XNUMX 時間を費やして長く複雑な論理チェーンを構築するため、その場で脆弱性を発見します。 何かをするとき、彼らは他のみんなと同じように、なぜそれをするのか、何が良い方向に変わるのかを理解したいと考えます。 チームに設定する目標が正直かつ現実的であることが非常に重要です。 悪いアイデアをプログラミング チームに売り込もうとするのは悪い考えです。 自分自身がそれを信じていない場合、または極端な場合、同意せずにコミットするという内部状態を持たない場合、そのアイデアはダメです (同意しませんが、実行します)。 私たちはかつて、ある企業にモチベーション システムを導入しました。その要素の XNUMX つは、フィードバックを提供するための電子システムでした。 彼らは多額の資金を投資し、訓練のために人々をアメリカに連れて行きました。一般的に、彼らは最大限に投資しました。 かつて、研修後の会話の中で、マネージャーの一人が部下にこう言いました。 私自身は電子フィードバックを提供しませんが、あなたはそれを従業員に提供し、従業員に要求します。」 それだけです。これ以上実装することはできません。 もちろん、このアイデアは無駄に終わりました。

出所： habr.com