上級プログラマーは、ジュニア開発者を引き受け、指導する必要がありますか？
緊密で協力的であることを意図したショップでは、上級開発者と後輩開発者がメンターとしてペアになる文化の一部にすべきでしょうか？または、このメンタリングは、より有機的で自発的なもの、つまり必須ではないが、人為的な励ましなしで開発することができるものでなければなりませんか？
私はそれを奨励すべきですが、必須ではないと思います。先輩は後輩やそのようなものに割り当てられるべきではありません、さもなければあなたはディルバートランドに行き着くでしょう。 「メンターとメンティー」の関係には、コアとなるある程度の友情と、相互の健全な敬意が必要です。人々に「出て行って」と言うだけではそれはわかりません。
シニア開発者がメンターとしてジュニア開発者とペアになることが文化の一部であるべきですか？
はい。
有機的で自発的、つまり必要ありませんが、人工的な励ましなしで発達することができます
それは実際に誰かを助けるほど頻繁には起こりません。
組織内に既存の関係を持つ人々は、新しい人々によって派閥またはエリート主義者として認識されます。派閥は通常壊れません。私たちは、知っている人々に固執します-それは必須人間の本性の要素です。
30年以上にわたるコンサルタント（クライアントとの100年間の契約）として、新しい人々は常に部外者であると断言できます。 「文化」や「雰囲気」の特徴ではありません。それは人々が働く方法の本質的な特徴です。確立されたスタッフは何もそれらを含める傾向がないため、コンサルタントは独自の派閥を形成します。
メンタリングを確立する唯一の方法は、クリークに新しい人々を挿入することです。
「メンター」の伝統的な意味は、割り当てに多少反します。友達を割り当ててみてください。
私の経験では、確立されたチームメンバーを最初の週、月などの質問の主要連絡先として使用するように新しいチームメンバーを割り当てることは問題ありません。
上級開発者は後輩開発者を指導する必要がありますか？
絶対違う。優れた上級開発者の中にはひどいメンターになる人もいるでしょう。メンターシップを成功させるには、個性のマッチアップが欠かせません。しかし、私は上級開発者が開発チームについて何かをより良くするために必要とされるべきだと思います。それは、側面で何かをプロトタイピングすること、プロセスまたは実践を改善すること、新しいツールを開拓すること、グループに技術資料を提示すること、チームまたは何か他のものを導くことかもしれません。言い換えれば、彼らは個々のワークシェアよりも大きな何かに対して責任を持つべきです。
または、このメンタリングは、より有機的で自発的なものでなければなりません。つまり、必須ではありませんが、人為的な励ましなしで開発することができますか？
いいえ、その見方にも同意しないでください。私は、メンタリングが「有機的で自発的」であると予想される状況をあまりにも多く見ました。組織はメンターシップに感染する機会を与える責任を負う必要があると思いますが、それを強制することはできません。それは難しいですが、価値があります。組織は次のようなことができると思います。
- 潜在的なメンターと潜在的な弟子の間の非公式の交流会
- メンターシップが組織によって正式に認識されるための提案された方法と機会（たとえば、あなたが事実上すべての請求番号を持つ場所である場合、メンターシップ会議の請求番号を作成します-これを明確にIS作業の実行可能な部分）
- メンターのトレーニングとサポート
- メンターを選択する方法と何を期待するかについての弟子へのガイダンス
- 何を期待し何を提供するかについてのメンターへのガイダンス
- 参加用のテンプレートを使用したメンターシップの推奨（または強制）パターン-たとえば、目標が毎週のミートアップでの3か月の体験であり、新しい開発者が立ち上がるのを支援することを事前に知っている場合、それを試してみる方がはるかに簡単ですと会社に行きます。それがもっと発展しないと言うのは言うまでもありません...しかし、それは人々が始めるための場所を与えます。
一部の人々はそのように配線されておらず、アイデアによって非常に無効にされるため、これを要件にすることは潜在的に逆効果になる可能性があると思います。とはいえ、メンターにふさわしいと思う人を特定し、メンターにもっと積極的な役割を果たすことを勧めます（まだそうでない場合）。この先行事例のアプローチは、より自発的なメンタリングをキャッチし、刺激することができます。
また、定期的に発生するグループアクティビティをスケジュールすることもできます。これは、チームがゼリーを作るのに役立ちます。これらは、チームランチのような完全に社交的な活動でも、毎週のプログラミングブッククラブのようなプログラミングについての学習を組み込んだ活動でもかまいません。
また、システムで定期的な「ミニ事後分析」を行うこともできます。これは、グループコードレビューのように機能します。グループ設定でレビューを行う利点の1つは、元のコードを書いた人だけでなく、全員がフィードバックから恩恵を受けることができることです。物事を始めるために自分のコードを判断してもらえるボランティアを集め、礼儀正しさを維持する必要があるかもしれません。
ジュニアプログラマーやシニアプログラマーという言葉は好きではありませんでした。たとえば、私はしばらくプログラミングをしており、いくつかの分野での経験はありますが、他の分野では非常に環境に配慮しています。たとえば、私たちはWPFに移行しています。Windowsフォームアプリケーションのエクスペリエンスはたくさんありますが、WPFはまだ新しく、私にとっては初心者です。したがって、私は「上級」プログラマーですが、「総」経験がはるかに少ない人を外で雇うことができ、おそらく現時点で私よりも優れて高速にWPFアプリケーションをプログラミングできます。
言うまでもなく、WPFアプリケーションに適用できる優れたアプリケーション設計とアーキテクチャの経験はあまりありませんが、自分の限界はわかっています。
時にはメンターになりたい人もいれば、メンティーになりたい人もいるでしょう。
チームメンバーが知識を持っているときにメンターであることを恐れず、知識が必要なときにメンティーを他のメンバーが持っている場合、実りある経験になります。
開発者が謙虚で新しいアイデアを受け入れ、必要に応じて他者を助けるような開発環境を育てることができれば、先輩と後輩の関係が自然に生まれます。
メンタリングを強制すると、おそらく開発者が互いに憤慨するかもしれないカーストシステムが作成されます。すべての開発者を同じレベルで平等に扱うことをお勧めします。
この業界は大きく異なります。 Senorityは常に良いとは限りません。
時々、先輩は後輩に指導する必要があります。
チームが構造をリードし、コードレビューにつながることがトリックを実行するはずです...
あなたには、1人以上のジュニアを担当するスタッフのシニアメンバーがいます。それは自発的な助けではなく、正式なプロセスであるべきだと私は思います。ある意味では、上級会員は新人が生み出す仕事の質に責任を持つということです。このアプローチには（少なくとも）2つの利点があります。上級管理者に管理スタイルを指導し、後輩が高品質のコードを作成できるようにします。
私は双方向で物事を行う環境にありました。
私が学校に通っていなかった最初の仕事は、メンターに割り当てられました。私はその男が好きではなかったし、確かにすべてについて彼に同意しなかった。私は彼と一緒に働くことを強いられたことに憤慨しており、雇用主が間違いを犯したと確信していますが、振り返って私は多くを学びました。
数年早送りして、今、私は開発者を一人ぼっちの態度で扱う会社にいます。開発者は厳しい期限にさらされており、他の人を自分の翼の下に連れて時間をかけてそのロープを見せるために時間を費やす開発者のための手当があったとしてもごくわずかです。残念だと思います。ジュニア開発者が私と同じことをいかに苦労しているのかがわかりますが、彼らを助けるメンターがいなければ、ずっと時間がかかります。
私は「メンター」としての評判を築きました。なぜなら、新入社員は「私が提供できる助けに感謝しているようだ」からです。私の知る限り、これは私が平凡な生産性レビューを許容して、正しいことを行うことができるという人事の言い方です。これは、ジュニア開発者が自分の仕事を効果的に行い、迅速に改善できるようにすることです。
それは私たちの後輩従業員にふさわしいことだと思います。そして、後知恵と経験のおかげで、私が最初に働いた会社と私を指導したその人は、当時思っていたよりもはるかに多くのことがわかったと思います。
これらはすべて、メンターを割り当てる必要がないことを願っていますが、作品を広めるためのおそらく唯一の公正な方法であるという長い言い方です。そうしない場合、それを行う人々に彼らの当然のことを与えるべきです。簡単な作業ではありません。対人スキルとエンジニアリングスキルの両方が必要です。そしてそれは時間がかかります。
上級開発者は、コードの大量生産を超えることを期待されるべきです。ただし、その方向性はすべての上級開発者にとって同じであってはなりません。
一部はメンタリングに適しています。それ以外の人はそうではなく、アーキテクチャの改善を計画して実装するか、新しいテクノロジーを評価するか、プロセスの改善を計画して先導するか（継続的インテグレーション、TDDなど）であろうと、他の上級レベルの目標を追求する必要があります。
基本的に、シニアは、ジュニアよりも数年以上コードをカットしている人であってはなりません。それは、チームの成功に貢献する追加の責任を引き受ける意思と能力を持つ人でなければなりません。後輩のメンタリングは重要ですが、それだけが重要なことではなく、誰もが得意とすることではありません。
人間はかなり自然に努力するので、そのようなメンタリングを義務付けることは逆効果ですagainst強制的な活動、行動、関係より良いアプローチは報酬メンタリングを上手く行う人々であり、メンターに欲しいようにします。
もちろん、これはこの文脈で「良い」を測定する問題を引き起こします。不完全ですが、簡単に実装できるソリューションは、1年後に（おそらく匿名で）新規参入者に、会社やコードベースへの統合を支援した上位3人の名前を書いてもらうことです。その後、あなたは名前が最も言及される人々に報酬を与えることができます。ただし、金銭的報酬はここでは機能しません。ある種の社会的報酬を見つける方が良いです。
すべてのものでプログラミングそれは依存します。しかし、私は間違いなく、彼らが目先の仕事のための最高のトレーニングを得るために、彼らが後輩であろうとなかろうと、新入社員をメンタリングするシニア開発者を望んでいます。
いいえ、それは上級開発者とジュニア開発者の数が常に同じであることを意味するためです。メンターになりたい上級開発者を励ますことはできますが、ペアリングを強制することは本当に悪い考えかもしれません。メンタリング関係をサポートするという考えは良いので、ここで捨てるべきではありません。
ただし、人工的な励ましは悪い考えではありません。すべてのジュニアおよびシニア開発者に、彼らがメンティーやメンターになることを、どんなに少し宗教的であっても、すぐに逆火になる可能性があることを伝えます。
メンタリングの扱い方について社内で知られているフレームワークがあればそれは素晴らしいでしょう。ただし、それが存在しない場合、キーはメンターとメンティーの間でいくつかの異なる種類の瞬間を持つようになります。
- 現在の状況-物事は今どこにありますか？メンターが解決の支援を提供できる現在の課題は何ですか？
- 将来の状態-何が求められているか：ヒント、解決策、尋ねる質問、誰に尋ねるか？
- 遡及-変更を加える際に何が機能し、何が機能しませんでしたか？
- 将来の変更-以前に行われたものよりもうまく機能する可能性のある将来的に試みられるものは何ですか？
少なくともこれらは、論理的なトップダウンアプローチを取るために私が見て理解できる状態です。他の人たちは、もっと有機的で自由形式のものが同様に機能することを望んでいるかもしれません。重要なのは、この関係でコミュニケーションを実践することで研ぎ澄まされるべきスキルを各側に持たせる方法を理解することです。フィードバックは非常に重要なので、双方が関係から何かを得て、この種の関係を築くためのいくつかの共通の基本ルールがあるはずです。
これにどれだけの時間を費やすかは、実際に何が行われているか、そしてスキルの開発と関係の構築に時間を費やすことがどの程度許容できるかを検討する必要がある公正な質問です。週に1時間はこれを通過したいペアもあれば、1日2時間でこれをカバーしたいペアもあるでしょう。正式なメンタリング関係の範囲内ではありませんが、シニアとジュニアが一緒に働く他のやり取りがあることを忘れないでください。
私はメンターシップシステムでいくつかの異なる試みを見てきました。私が一番気に入ったのは、上級開発者がジュニア開発者を支援するために実行した特定のタスクセットを備えていたものでした。これにより、メンタリングの必要がなくなりました。たとえば、最初の6か月間、割り当てられた上級開発者の1対1のコードレビュー担当者は非常に役に立ち、メンターシップにつながる可能性があります。私が嫌いなのは、余分な忙しい仕事のように感じられ、行われている仕事に直接関連していないように思われるものでした。たとえば、毎週30分、割り当てられたメンターと面会します。これは特に、メンターシップ関係の2人のメンバーが1週間の間に互いにやり取りをせず、お互いのプロジェクトとは何の関係もなかったときに、いらいらしました。それは、専門的に成長することに焦点を当てたというよりは、非常に強制的で手ごわい感じでした。あなたが望む最後のことは、メンターシップ関係がカウンセリングセッションのように感じることです。
IME、あなたはメンターシップ関係の発展を頼りにすることはできません。そのため、少なくとも、少なくとも、通常のペアのビジネス活動のセット（コードレビュー、デバッグ、ペアプログラミングなど）のシニア開発者とジュニア開発者をペアにして、潜在的なメンターを提供します。まず、素晴らしいアイデアです。理想的には、シニアメンバーはその役割に志願し、個人的な利益を認識できる必要があります。私の現在の会社では、シニア開発者がプロジェクトのリーダーであることがほとんどで、その利点は、彼らが独自のプロジェクトのチームを構築していることです。他社では、メンターが管理トラックを調査することがよくありました。
若い開発者を雇うすべての企業には、ある程度の効果的なメンタリングプログラムが必要だと思います。しかし、多くの開発者は、開発がどれほど上手くいっていても、メンタリングがひどいという単純な理由で、すべての上級開発者がそれを行うべきであるかどうか、デフォルトの位置はわかりません。残念ながら、それは領土と調和しています。私たちの一部は、あなたが好きなだけでは、素晴らしい人ではありません。
一方、それが得意な人がいる場合は、ブラックマークではなく、それを認識してもらう必要があります。実際の開発出力は、ああIDEの実装に関する簡単なローカライズされた問題を説明しているときに低下するためです。たとえば、常にNotePadとJavacを使用してきた初心者に。
これには、バランスの取れた管理が必要です。それが一般的であるかどうかはわかりません。
メンタリングが機能するためには、これが重要であることを経営陣が認識し、これに時間を割り当て、積極的にこれを奨励することが不可欠です！
割り当てが100％予約されている人にとって、メンタリングを行う時間や受け取る時間は文字通りありません。それは起こりません。
一般的に、メンターシップは、シニアからチームリーダーまたはマネージャーに移行するための良い踏み台です。メンターシップをPDP（Personal Development Plan）の昇進や、会社がこれまでに採用したメリット計画に関連付けると、より効果的です。給与の増加とキャリア開発を、少なくとも一部は知識を伝え、新しい開発者を育成する能力に結び付けることが、経営陣の変化とスタッフの離職を乗り切ることができる強力なITスタッフを構築するための鍵です。重要な目標を提供し、スタッフと協力して彼らの改善を支援することは、リーダーシップへの成長の一部です。成長の一部であるジュニアの成績とシニアの評価を結びつけるのは公平ではないと考える人にとって。ほとんどの場合、あなたは給与削減について話しているのではなく、増加の減少または進歩の鈍化について話している。その進歩の一部として見ることはあなたのリーダーシップの下でそれらを導き、教える能力ですこれは私にとって非常に自然なことのようです。
私が最初にチームに来たとき、私はオーナーとリードデベロッパーに指示を与えていました。私はそれらのどちらかを何でも尋ねることができ、彼らは両方とも答えるでしょう。けれども、私がそれをタイムリーに理解することができなかった場合を除いて、彼らを悩ませ続けないように十分に敬意を表した。
うまくいきましたが、これを機能させるには、おそらくユーモアのセンスのある素敵な人が必要でしょう。