後輩があなたの提案を採用しなかった場合、あなたは何をすべきですか？
私は3〜4人のジュニア開発者のチームを率いています。コードを書く以外に、私の仕事は後輩に監督と指導を提供することです。
しかし、私は開発者が自分たちの仕事の中で自律性を大事にしていることを完全に理解しており、自分の考えやアルゴリズムを彼らにスプーンで与えることによって彼らの本質的な動機を破壊したくありません。私は彼らに彼ら自身の方法で問題を探究させて、それについて彼ら自身で考えて、彼らが本当に乗り越えられない問題に直面しているときだけ私に来て欲しいです。
彼らが私のところに来たとき、アルゴリズムが十分に堅牢ではないため、問題を解決するために完全に異なるアルゴリズムを提案する必要がある場合があります（覚えておいてください、私は上級者であり、私はそれらよりも多く見たことがあります）。もちろん、私は彼らの気持ちを傷つけないように素敵な方法でこれを説明し、私の解決策が彼らのそれよりもはるかに優れていることを優しく概説します。
しかしそれでも、彼らは私の提案を受け入れるのをためらうことがあります。これは、彼らが独自のアルゴリズムに多大な投資を行ったため、または新しい方法を使用すると、より多くの学習時間が必要になり、経営陣に彼らがまるで経営者のように見えるようになる恐れがあるためです。どこにも行きません。しかし、私の心の奥深くでは、私のアルゴリズムが彼らのアルゴリズムよりもはるかに優れていることをよく知っています。
彼らが私の提案を採用しなかった場合はどうすればよいですか？私に彼らに私の道をたどるように頼むべきですか、それとも彼らに頭を壁に何度も叩いてもらい、彼らが私に戻るのを待つだけですか？前者を実行すると独裁者になりますが、後者を実行すると貴重な開発時間がかかり、バグ修正のコストが発生します。ここで私は本当にジレンマに陥っています。
提案された変更を行う必要がある理由を理解してもらいます理由。そして、彼らが変更を行わない正当な理由があるなら、彼らに耳を傾けなさい。話し合いを行い、何をするのが最善であるかに基づいて合意に達します。
このアプローチは、次の理由で重要です。
- 確かなビジネス上/技術上の理由から、彼らに変化を起こしてもらいたいのです。これらが何であるかを明確にすることが重要です（あなたも間違っている可能性があるので、控えめにしてください...）。
- あなたは本当にあなたの提案の背後にある推論を伝えたいと思っています-そのようにして、受信者は将来同様の問題を自分で解決することを学びます。後輩があなたからいくつかの良い洞察を学んでいると感じれば、あなたはより良い関係を築くでしょう。
- あなたがあなたの年功序列を使用し、あなたが実際に正当な理由があることを証明できない場合、あなたは尊敬されません。
- あなたの上司はおそらく、「自分のやり方で」だけでなく、実際の価値を生み出すことに後輩の時間を効果的に使用していると確信したいと思うでしょうそれのために。
賢い人なら、質問するだけで答えを見つけることもできます。正しく行われると、後輩が正しい結論に到達します（したがって、それをはるかに進んで実装します）。質問の例：
- コードは、本番データベースへのアクセスを前提としています。それを変更して、JUnitが切断された開発環境で正しく動作し、テストできるようにするにはどうすればよいでしょうか。 （潜在的な答え：ああ！依存性注入を使用する必要があります...）
- 攻撃者が巧妙に構築されたSQLをオンラインデータ入力フォームで意図的に送信した場合はどうなりますか？ （潜在的な回答：ああ！おそらく、インターネットからの未検証のテキストを連結してSQLステートメントを構築するべきではありません）
[〜＃〜] edit [〜＃〜]：後輩に、正しいことはあなたの提案に従うことだと説得することに成功したが、彼らは stillここよりも気が進まないいくつかの追加のアドバイスがあります：
- 探求する理由彼らは消極的です。結果が得られれば、コードを捨ててもかまわないという個人的な認識に至る必要があるかもしれません。あるいは、締め切りのせいで時間的にプレッシャーを感じているのかもしれません。あなたは知る必要があります、そうでなければあなたは彼らを助けることができません.....
- あなたは彼らが彼らのリファクタリングスキルを改善する方法として変更を扱うことができるという点を作ることができます。リファクタリングのスキルが十分であれば、かなり大きく複雑なコードベースでも比較的迅速に再利用できるはずです。
- すべてがソース管理に含まれることを強調する必要があります。そうすることで、必要に応じて常に古いバージョンに戻すことができます。
私は最後のチームリーダーの圧倒的な態度を嫌っていましたが、彼は優れた技術知識を持っているという事実を尊重し、私に講義することなく多くのことを教えてくれました。最も重要なことは、彼は私に彼の計画を強制することを決してしなかった。彼は私の計画で悪魔の擁護者を演じ、私の計画が完璧であることを証明するように私に強いました。彼は抜け穴を探し、それが抜け穴ではない、またはより安価な解決策ではない理由についての私の説明を待ちます。他の解決策があるかどうか尋ねられて、私が持っていない場合はいくつかのアイデアを提案します。私は彼のアイデアを評価する必要があり、彼の計画は最適ではなかった、または彼が私の計画が正しいか、または少なくとも彼と同じリスク/報酬比率を持っていると確信した場合、彼は成功を収めるでしょう。私が自分の考えで失敗した場合、私は彼の解決策を試さなければならないでしょう。
自由と期限の間にはトレードオフが必要です。期限を延ばすという贅沢はなく、後輩にそれを破ることはできません。あなたは彼らが彼らのアルゴリズムを試し、それを動かさなかったならば、彼らはあなたに耳を傾ける義務があることを彼らに丁寧であるがしっかりしている必要があります。あなたがあなたのものを知っていることを例によって証明してください。しかし、同様に重要なことは、彼らに学びを与え、教えさせないことです。
要件である場合は、そのことをメモしてください。ご指摘のように、それが提案にすぎない場合は、それ以外の場合は自由に行うことができます。私が尋ねるいくつかの質問：
- 特定のソリューションを推進する権限がありますか？
- その権限の範囲はどれくらいですか？
- 解決策は悪いですか、それとも違うだけですか？
もっと質問してもいいと思いますが、最初の2つはあなたの権限に焦点を当て、最後は問題が本当に推進に値するかどうかに焦点を当てています。
次の回答にはいくつかの優れた追加ポイントがあります。ディクテーションを発行するだけでなく、「チーム」でこれらの少なくともいくつかを処理する共同プロセスとしてそれをもっと扱う必要があることをここに付け加えます。彼らはあなたに問題を解決するにつれて、単に「このようにすることを検討してください」と言われるだけでなく、学習します。
あなたが実際にあなたの提案を侮辱的ではない方法で提示しているかどうか私は質問します。次のようなフレーズを使用している場合：
私の解決策は彼らの解決策よりもはるかに優れています
そして
私の心の奥深くでは、私のアルゴリズムが彼らのアルゴリズムよりもはるかに優れていることをよく知っています。
「わたしのほうが優れている」という態度で出くわすと思います。そのような態度を与えられることを好む人はいません。過去にそれを受け取ったとき、私は積極的に自分のやり方を変えて、別のアルゴリズムを使用して人を間違っていることを証明しました。後輩も同じことをしているのかもしれません。
より良い方法は、その人と一緒に座って、彼らのアルゴリズムについて話し合うことです。それがうまくいくと思わない理由を指摘し、彼らがオープンマインドであなたに与える答えを聞いてください。それらのアルゴリズムが正しく機能するように変更できるかどうかを確認します。
ジュニアが持っているものが間違いなく機能しない場合は、なぜ機能しないのか説明してください。どの部分が正しくないか、または後で書き換えが必要になるか、またはビジネスモデルに適合しない部分。彼らがあなたの理由をよく理解していることを確認してください。次に、アルゴリズムを説明し、アルゴリズムが機能する部分とコードが失敗する部分を指摘します。
失敗は動機であり、将来の想起のための記憶の手がかりを提供するため、学習は実際には失敗が発生した場所でのみ発生します。これは本質的に私たちが経験と呼ぶものであり、職場での良い経験は失敗したことと失敗から学んだことから生まれます。後輩が最初からすべてを正しく理解できるとしたら、彼らは何も学んでいないか、後輩ではありません。
あまりにも多くのジュニアが混乱している場合、おそらくあなたの会社は不適切に人材を配置しており、リスクを最小限に抑えるために時間の制約により経験豊富な人々が必要とするジュニアグレードの開発者が多すぎますが、それでもシニアデベロッパーがミスをすると、問題や遅延が発生する可能性がありますから学ぶことも。
締め切りが厳しい環境で対応できるようにするには、後輩が学び、経験を積む必要があります。チームリーダーとして、模範を示し、後輩に効率的に働くように促すのはあなたの仕事ですが、実際には、後輩に実際に何かを学ばせたい場合は、個人のプライドの懸念と厳しいスケジュールの懸念を脇に置かなければなりません。 、したがって、それらが失敗することを許可する必要があります。したがって、電話をかけるのはあなたの仕事です。時には、ジュニアに失敗する余地を与え、彼らが彼らのアイデアを改善できる場所を示すためにレビュープロセスを辛抱強く受け取らせる必要がある場合があります。他の場合では、足を下に置く必要がありますが、それは、それがジュニアの能力そのものにあまり反映されていない真の必要性から外れていることを示すことができる方法で行います。ただし、この方法を使用する場合は、ある程度の手持ちを期待する必要があるため、時間に対する余分な負担がそれだけの価値があるかどうか、またはそのままにしておく方がよいかどうかを判断するのはあなた次第です。失敗して学ぶジュニア。
厳しい締め切りの問題については、ここでチーム内の相対的な長所と短所に応じて作業をスケジュールして割り当てる必要があります。結局、お金はあなたと共に止まります。あなたが他の人を担当しているとき、あなたはみんなの友達になるためにそこにいるのではなく、困難な状況下で困難な仕事を成し遂げるためにそこにいます。誰もがあなたの側にいる方法は、懸念や問題を通して人々に話しかけることに帰着し、チームメンバーが特定の方法で何かをする必要がある理由を合理的に主張します。
私自身の個人的な経験から、両方のアイデアの長所と短所について話し合うために、ジュニアと一定の時間を予約してから、共同で、目前の問題を解決する最善の解決策を探す必要があります。間違っていることが証明されてから、次に進みます。割り当てられた時間の終わりまでに両方がコンセンサスに到達できない場合、その時点で、議論された懸念を考慮に入れ、コンセンサスに到達していないことを記した要約でミーティングを終了する必要があります。会議の結果に関係なく、費やした時間を後輩に感謝し、間もなくあなたの決定で戻ることを示します。ディスカッションを注意深く検討した後、追加のディスカッションのために追加の時間を割り当てるか、ミーティングの結果に従って決定した計画を先に進めるようにジュニアに指示するオプションがあります。
はい、時は時々貴重です、しかし、あなたがジュニアを引き受けることを選ぶとき、あなたはあなたが彼らの専門能力開発に投資して育てる責任を負っていることを受け入れる必要があり、そして結果としてそれはしばらくの間それを受け入れる必要があります少なくとも時間はかかります。
まず、あなたの後輩があなたの提案を採用しなかった本当の理由を知っていますか？
ときどきご存知のように、新しい視点と最新のCS教育のために、ジュニアは実際にはシニアよりも優れたものを書くことがあります。先輩として、あなたはもっと現実世界の例を見たかもしれませんが。しかし、高齢者が陥りがちな場合によく見られる悪い落とし穴は、ベストプラクティスが時間とともに変化することを忘れていることです。あなたがこれらのようなサイトであなた自身を更新してきたので、これはあなたには当てはまらないと確信しています。 ;）
先輩の「オーラ」がまったくない（またはほとんどない）ジュニアにアプローチし、彼らと平等に話し合い、彼らが書いたコードに好奇心を示すことをお勧めします。質問して、回答を聞いてください。次のような非難的な方法で尋ねないでください。
「あなたのコードはかなり柔軟性がありません、あなたはそれをこれに変更する必要があります...」
代わりに尋ねる
「誰かがどうしたら...コードがそれをなんとかして管理できるとしたらどうだろう...私は戦略パターンがここで役立つと思います。どう思いますか？」
これは、教授/講師がそれらをすべて知っているように見下ろすようなものよりも、彼らとのより健全な会話に従事するのに役立つと信じています。また、彼らの推論と見方をよりよく理解するのにも役立ちます。
他の人が指摘しているように、あなたが本当にジュニア開発者に提案を証明しているだけであり、彼らがそのように語られている場合、彼らが従うことができないので、彼らがそれに従わなければ、あなたは本当に彼らに悩まされる理由はあまりありませんそうする理由はあまりわかりません。同様に、あなたが実際に彼らが特定の方法で物事を行うための方向性ではないので、あなたは本当にあなたがあなたの提案に従わないために彼らを怒らせることはできません。
ジュニア開発者にあなたがやりたいことをしてもらいたいということに関して：
- suggestionを作成することはrecommendationを作成することと同じではありませんdirectionを提供することとは明確に異なります。それに応じて用語を使用して、あなたのポイントを理解させ、何かを行う方がより良い方法であると思われる場合は、そうすることをお勧めします。同様に、物事が所定の方法で行われることが絶対的に重要である（つまり、時間遅延に耐えられない）場合は、率直に言って、どのように行うべきか指示を与えます。
- ジュニア開発者は、あなたがどのように物事を言っているかに関係なく、依然として学習プロセスを行っています。具体的にできない理由がない限り、あなたが彼らに伝えていることの背後には常に何らかの理由を提供してください。その場合でも、「こうやってやらなきゃいけない、自分では気にしないけど、もう決まってる」という言葉をかければ、ほとんどの人はわかるだろう。彼らはかなり合理的である傾向があります。
- それが本当に提案にすぎない場合は、アイデアが実際にどのようにしたかよりも優れていることを確認してください。そうでないと思われる場合は、開発者と一緒に座って、コードとコンセプトのレビューを行って、ソリューションを正当化できるようにします。彼らが誰かにそれを説明し始めたら-そしてあなたが正しい質問をすると-彼らはより良い方法を見て自分で物事を書き直したいと思うでしょう。
- ソリューションが最初に提案したものと類似している場合は、詳細をいじくり回さないでください。彼らがあなたに伝えたことを考慮に入れ、わずかに異なることをしたか、提案に基づいて元のコンセプトを変更した可能性があります。
これは単体テストの完全な紹介です。ジュニア開発者がソリューションを持っている場合は、テスト可能でなければなりません。コードを強調するためのユニットテストを作成してもらいます。 次に単体テストを確認します。テストに穴が開いている場合は、テストを再実行して、プレッシャーのもとでソリューションが壊れることを簡単に確認できます。
これにより、ソリューションが優れている理由を示すことができ、コードが変更されたときに再利用できる単体テストが提供され、ジュニア開発者は貴重な学習体験を得ることができます。そして、誰が知っているか、あなたは彼らの解決策が素晴らしいことを知るかもしれません。
ある時点であなたが責任を負う必要があります。あなたは彼らに彼らの意見を表明させる努力をしているように聞こえます。あなたの提案は完全ではないかもしれません。他の開発者はあなたに理解/同意しないかもしれません。彼らはおそらくお互いに同意しません。あなたが担当している場合、それは民主主義ではありません。彼らはいつ就職したかを知っていました。
彼らがあなたに従う必要がある状況がない場合、あなたは彼らの上司としてふさわしく、何の役にも立ちません。チームでの役割を、リソースを使用する予定がない場合は、権限ではなくリソースに変更します。ある時点で、利用可能な時間の制約の下でできる限り最高のコードを出荷する必要があり、時間の終わりまでコードのすべての行について討論、調査、および討論することはできません。
命令を与える。結果とともに生きる。経験から学ぶ。リスペクトは双方向の通りです。あなたはそれを実証していますが、彼らはそうではありません。
リポジトリへのプッシュアクセスを制御していますか？
オープンソースでは、プッシュアクセスは常に、品質の実施を担当するゲートキーパーによって制御されます。コミットしているコミットを積極的に監視している場合は、それらが改善できる場所を鋭敏に認識する必要があります。
彼らはあなたのコードをハックしたり改善したりしますか？彼らがあなたのコードがどのように機能するかについて内部を見る機会を得れば、彼らはあなたのスタイルにより良く適応する方法を学ぶかもしれません。あなたが心を開いて提案を受け入れることなくあなたの提案を押しているなら、彼らはあなたの意見に耳を傾ける傾向が少なくなります。
正しい答えが得られない状況もあります（コーディングスタイルの設定など）。その場合は、会社全体のポリシーを確立（または施行）して、コードのスタイルがメインのコードベースと整合するように調整する必要があることを理解してもらいます。既に確立されているスタイルガイドライン（C＃のMicrosoftスタイルガイドなど）を使用することが、特にチームの新しい開発者にとって最良の方法です。
あなたが彼らのコーディング技術について包括的に述べているなら、あなたが彼らの選択の背後にある理由を完全に理解していないかなりの可能性があります。質問の調子だけで傲慢に聞こえます。若い開発者にアプローチをプッシュすることで、何を得る/犠牲にしますか？
あなたが自問する必要のある重要な質問は次のとおりですコードベースの品質を維持/改善するため、またはピアに対する優位性/優位性を主張するための提案ですか？前者は単純な品質管理であり、そのように正当化されると、はしごは、あなたの権利の有無にかかわらず、チームのダイナミックに有害です。
どちらの方法でも、ソリューションを同僚にプッシュしたい場合は、それが実際に優れていることを具体的に証明する必要があります。パフォーマンスの大幅な向上は、改善するのに十分なほど簡単である必要があり、それより少ないものは努力に値しません（パフォーマンスが重要なアプリケーションを除く）。自分の仕事を他人に強要して、自分の優越感を正当化することは、あなたが「かぎ針編みの老人」として選ばれることで終わります。
注：私が長年にわたって遭遇した最も優れた最も才能のあるプログラマーは、アプローチを開始した背後の裏話を止めて説明しようとするプログラマーであるように思われました。
まあ、これは興味深いもので、非常に自然なように思えます。若いプログラマーが、自分が書いたコードに非常に執着しているからです。かなりの時間を費やして、同じ場所に到着したり、優れたサイトから選んだりしている可能性があります（実際、Hey Jonスキートがこれを書いています。おとこ ！ ！）。
それでも、ここに添付されている基本的な文字列は、コードの添付ファイルであり、ここに集中する必要があります。実行と期待される結果は、名前よりも重要であることを理解させるために、かなりの努力を払う必要があると思います。このコードをプッシュするためにソースリポジトリにエッチングされます。なぜコードがより優れているか、そしてmaintainingの点でも優れているため、将来の作業のために線を引く必要があります。
いくつかの失敗が顕著であることを考慮に入れてください（アタッチメントにはいくつかの心の休憩が必要です）。しかし、徐々に努力していくと、それらが発生し、あなたの努力をより正しく評価できると思います。少しの時間といくつかの失敗はあなたが必要だと思うものです。彼らにそれを強制することは、いくつかのサクセスストーリーを巡る別の方法であり、それから終末と反乱です。
誰もが異なるスタイルを持っています。 10人の異なる人を見つけて、それらに重要な問題を提示すると、10種類の「コーディング標準」スタイルを使用して10種類のアプローチが提供されます。
重要なのは、重要なものを選ぶことです。後輩が正しい解決策を提示していないものを提示した場合、それは著しく非効率的（+1桁、ここの指示ではありません）であるか、セキュリティホールを作成してから、問題とその理由を説明します。それが「私はこれをやっただろう」というコメントであれば、それは素晴らしいことです。あなたは「それ」をやり、彼女は「何か他のこと」をしましたが、問題はまだ十分に解決されています（上記のポイントを参照）。次の機能または修正に進みます。
優れたリーダーになるための学習の一部は、本当に重要なことと実際にそうでないことを認識することを学ぶことです。さらに、あなたがすべてを精査する必要がある場合、グループのパフォーマンスへの潜在的なボトルネックとして自分自身を排除します。
編集：あなたの提案が本物であり、覆い隠された要件ではないことを確認してください。提案はそれだけです-自由にフォローできるかどうかにかかわらず、提案です。要件である場合は、その旨を明記してください。