あなたの後輩があなたの提案を採用しなかった場合、あなたは何をすべきですか？[閉まっている]

私は3〜4人のジュニア開発者のチームを率いています。私の仕事は、コードを書くことに加えて、後輩に監督と指導を提供することです。

しかし、私は開発者が自分の仕事で自律性をどれほど大切にしているのかを完全に理解しており、自分の考えやアルゴリズムをスプーンで提供することによって彼らの本質的な動機を破壊したくありません。私は彼らに彼ら自身の方法で問題を探求し、彼ら自身でそれについて考え、彼らが本当に乗り越えられない問題に直面しているときだけ私に来てほしい。

彼らが私に来たとき、時にはアルゴリズムが十分に堅牢ではないため、問題を解決するために完全に異なるアルゴリズムを提案する必要があります（私はシニアであり、私は彼らよりも多くを見てきました）。もちろん、私は彼らの感情を傷つけないようにこれを素敵な方法で説明し、私の解決策が彼らのものよりもはるかに優れていることを優しく概説します。

それでも、彼らは私の提案を受け入れたがらない場合があります。その理由の1つは、独自のアルゴリズムに多大な投資をしているからです。どこにも行きません。しかし、私の心の奥深くでは、私のアルゴリズムが彼らのアルゴリズムよりもはるかに優れていることをよく知っているので、採用するだけです。

彼らが私の提案を採用しなかった場合、どうすればよいですか？彼らに自分の道をたどるように頼むべきなのか、それとも彼らに何度も頭を壁に叩きつけて、彼らが私に戻ってくるのを待つべきなのか？前者を実行すると独裁者になりますが、後者を実行すると貴重な開発時間がかかり、バグ修正コストが発生します。私は本当にここでジレンマに陥っています。

提案された変更を行う理由を理解するのに役立ちます。そして、彼らが変化を起こさない正当な理由があるなら、彼らに耳を傾けてください。話し合いを行い、何をするのが最善かに基づいて合意に至ります。

このアプローチは、次の理由で重要です。

• 堅実なビジネス/技術的理由により、彼らに変化を起こしてほしい。これらが何であるかを明確にすることは重要です（あなたも間違っている可能性があることを覚えておいてください。
• あなたはあなたの提案の背後にある理由を本当に伝えたいです-その方法は、受信者が将来同様の問題を自分自身で解決することを学ぶでしょう。また、後輩があなたから良い洞察を学んでいると感じるなら、あなたはより良い関係を持つでしょう。
• あなたが年功序列を使用し、実際に正当な理由があることを実証できない場合、あなたは尊敬されません。
• あなたの上司は、あなたのために「自分のやり方でやる」だけでなく、本当の価値を生み出すものに後輩の時間を効果的に使っていると確信したいと思うでしょう。

あなたがスマートであれば、あなたはまた、彼らはただで答えに来てもらうことができます質問をします。正しくすれば、後輩は自分自身で正しい結論に達するでしょう（したがって、それを実装する意思がずっと高くなります）。質問例：

• コードは、運用データベースへのアクセスを前提としています。切断された開発環境でJUnitが正しく動作し、正しくテストできるように、どうすれば変更できますか？（潜在的な答え：ああ！依存性注入を使用すべきです...）
• 攻撃者がオンラインデータ入力フォームで巧妙に構築されたSQLを故意に送信した場合、どうなりますか？（潜在的な答え：ああ！おそらく、インターネットからの未検証テキストを連結してSQLステートメントを構築すべきではありません）

編集：あなたが行うべき正しいことはあなたの提案に従うことであるとあなたのジュニアを説得することに成功した場合、彼らはまだいくつかの追加のアドバイスがあるよりも消極的です：

• 探検なぜ彼らは消極的です。結果が得られれば、コードを捨てても問題ないという個人的な認識に達する必要がある可能性があります。または、期限があるために時間的なプレッシャーにさらされていると感じることもあります。あなたは知る必要があります、さもなければあなたは彼らを助けることができません.....
• リファクタリングスキルを向上させる方法として、変更を扱うことができるという点を指摘できます。リファクタリングスキルが十分であれば、かなり大きく複雑なコードベースでも比較的迅速に再利用できるはずです。
• すべてがソース管理にあるため、必要に応じて常に古いバージョンに戻すことができることを強調する必要があります。

私は前回のチームリーダーの圧倒的な態度を嫌っていましたが、優れた技術的知識を持ち、講義をせずに多くを教えてくれたという事実を尊敬します。最も重要なことは、彼が私に彼の計画を強制することは決してなかったことです。彼は私の計画で悪魔の擁護者を演じ、私の計画が完璧だったことを証明せざるを得ませんでした。彼は抜け穴を探し、抜け穴ではないか、またはより安価なソリューションである理由についての私の説明を待ちます。彼は代わりの解決策があるかどうかを私に尋ね、もし私が持っていなければいくつかのアイデアを提案します。私は彼のアイデアを評価し、彼の計画が最適ではなかったか、または私の計画が正しいか、少なくとも彼と同じリスクと報酬の比率を持っていると彼が確信した場合、彼は先送りするでしょう。私のアイデアで失敗した場合、私は彼の解決策を試さなければなりません。

自由と期限の間にはトレードオフが必要です。締め切りを延ばす贅沢はありませんし、後輩にそれを突破させることはできません。あなたは礼儀正しくなければなりませんが、彼らは彼らのアルゴリズムを試してみて、それがうまくいかなかったならば、彼らはあなたに耳を傾ける義務があることを彼らにしっかりしなければなりません。あなたが自分のものを知っていることを例で証明してください。しかし、同様に重要なことは、彼らに学ぶことであり、教えることではありません。

要件である場合は、そのことに注意してください。あなたが指摘しているように、それが提案にすぎない場合、彼らはそうでなければ自由にそれを行うべきです。私が尋ねるいくつかの質問：

• 特定のソリューションを推進する権限がありますか？
• その権限の範囲はどのくらいですか？
• 解決策は悪いのですか、それともまったく違うのですか？

もっと質問してもいいと思いますが、最初の2つはあなたの権限に焦点を当て、最後は問題が本当に推進する価値があるかどうかに焦点を当てています。

次の回答にはいくつかの素晴らしい追加点があります。ここでは、口述を単に発行するのではなく、これらの少なくともいくつかを「チーム」と連携する共同プロセスとして扱う必要があります。彼らは、「この方法でそれを行うことを考えてください」と言われるだけでなく、あなたとの問題を乗り越えて学習します。

学習は、失敗が発生した場合にのみ発生します。これは、失敗が動機付けであり、将来の想起のためのメモリキューを提供するためです。これは基本的に私たちが経験と呼んでいるものであり、職場での良い経験は失敗したことから生まれ、失敗から学んだことです。あなたのジュニアが最初にすべてを正すことができるなら、彼らは何も学んでいないか、彼らはジュニアではないでしょう。

後輩が混乱しすぎると、おそらくあなたの会社のスタッフが不正確になり、中級の開発者が多すぎて、時間の制約により経験豊富な人がリスクを最小限に抑える必要があります。同様に学ぶために。

締め切りが厳しい環境で対処できるようにするには、後輩が学び、経験を積む必要があります。チームリーダーとして、例を挙げて後輩に効率的に仕事をするよう促すのはあなたの仕事ですが、現実には、後輩に実際に何かを学ばせたい場合は、個人的なプライドの懸念や厳しいスケジュールに対する懸念を捨てなければなりません、したがって、それらが失敗することを許可する必要があります。したがって、電話をかけるのはあなたの仕事です。ジュニアに失敗する余地を与えてから、レビュープロセスを辛抱強く受けて、アイデアを改善できる場所を示す必要がある場合があります。それ以外の場合は、足を下ろす必要がありますが、そうすることは、それ自体が後輩の能力自体にあまり反映されていない真の必要性から外れていることを示すことができるようにしてください。

厳しい締め切りの問題に関しては、チーム内の相対的な長所と短所に従って作業をスケジュールし、割り当てる必要があります。最終的にバックはあなたと停止します。あなたが他の人を担当しているとき、あなたはみんなの友人がいないので、あなたは困難な状況で難しい仕事をするためにそこにいます。誰もがあなたの側にいるということは、あなたの懸念や問題を通して人々と話すことに帰着し、あなたのチームメンバーが特定の方法で何かをする必要がある理由について合理的なケースを作ります。

私自身の個人的な経験から、両方のアイデアの長所と短所について話し合うために後輩と一定の時間を確保し、次に手元にある問題を解決する最良の解決策を共同で探す必要があります。間違っていることが証明されてから前進してください。割り当てられた時間の終わりまでに両方が合意に達することができない場合、その時点で、議論を考慮し、合意に達していないことに留意する要約で会議を終了する必要があります。会議の結果に関係なく、あなたは後輩に費やした時間に感謝し、あなたの決定とともに戻ることを示しますまもなく。議論を慎重に検討した後、さらなる議論のために追加の時間を割り当てるか、会議の結果に応じて決めた計画を進めるようジュニアに指示することができます。

はい、時間は貴重な場合がありますが、後輩に就くことを選択した場合、あなたは自分の専門能力開発に投資し育成する責任を負っていることを受け入れる必要があり、その結果、しばらくの間それを受け入れる必要があります少なくとも時間はかかります。

私はあなたが実際にあなたの提案を軽desしない方法で提示しているかどうか疑問に思うでしょう。次のようなフレーズを使用している場合：

私のソリューションは彼らのソリューションよりもはるかに優れています

そして

私の心の奥深くで、私のアルゴリズムが彼らのアルゴリズムよりもはるかに優れていること、そして彼らがそれを採用するだけであることを非常によく知っています。

それは、あなたが「私のやり方は優れている」という態度で出くわす可能性があると私に思わせます。その態度を与えられることを好む人はいません。過去にそれを受け取ったとき、私は積極的に別のアルゴリズムを使用して人が間違っていることを証明しようとしていました。あなたの後輩が同じことをしている可能性があります。

より良い方法は、人と一緒に座って、彼らのアルゴリズムについて議論することです。それがうまくいかないと思う理由を指摘し、彼らがあなたに与える答えに心を開いて聞いてください。アルゴリズムが正しく機能するように変更できるかどうかを確認してください。

後輩が間違いなく機能しない場合は、なぜ機能しないのかを説明します。どの部分が間違っているか、後で書き直されるか、ビジネスモデルに適合しない。彼らがあなたの理由をよく理解していることを確認してください。次に、アルゴリズムを説明し、それが機能し、コードが失敗する部分を指摘します。

まず、あなたの後輩があなたの提案を採用しなかった本当の理由を知っていますか？

時々あなたが知っているように、新しい視点とより新しいCS教育のために、ジュニアは実際にシニアよりも良いものを書くかもしれません。上級者として、より現実の例を見るかもしれません。しかし、私の先輩が時々陥りがちな悪いトラップは、ベストプラクティスが時間とともに変化することを忘れることです。これらのようなサイトで自分自身を更新しているため、これはあなたには当てはまらないと確信しています。;）

シニアの「オーラ」がまったくない（またはほとんどない）後輩にアプローチし、彼らとレベルの面で話し、彼らが書いたコードに好奇心を示すことをお勧めします。質問をし、その回答を聞いてください。次のような非難の方法で尋ねないでください。

「あなたのコードはかなり柔軟性に欠けています。これに変更する必要があります...」

代わりに尋ねる

「私はただ、誰かが...あなたのコードがそれを処理することができたらどうなりますか？...ここで戦略パターンが役立つと思います。どう思いますか？」

これは、教授/講師がすべてを知っているように彼らを見下ろすようなものよりも、彼らとより健全な会話を行うのに役立つと信じています。また、彼らの推論や視点をよりよく見るのに役立ちます。

リポジトリへのプッシュアクセスを制御していますか？

オープンソースでは、プッシュアクセスは常に、品質の強化を担当するゲートキーパーによって制御されます。プッシュしているコミットを積極的に監視している場合、どこで改善できるかを鋭く認識する必要があります。

コードをハッキングしたり、コードを改善したりしますか。あなたのコードがどのように機能するかについて内部を見る機会を得た場合、彼らはあなたのスタイルにより良く適応する方法を学ぶかもしれません。心を開いて提案を受け入れずに提案を推進している場合、彼らはあなたの意見を聞く傾向が少なくなります。

正しい答えがない状況がいくつかあります（コーディングスタイルの設定など）。その場合、会社全体のポリシーを確立（または実施）して、コードのスタイルがメインのコードベースと一致するように調整する必要があることを理解してください。既に確立されたスタイルガイドライン（MicrosoftのC＃のスタイルガイドなど）を使用することが、特にチームの新しい開発者にとって最適な方法です。

コーディングテクニックに関する包括的なステートメントを作成している場合、その選択の背後にある理由を完全に理解していない可能性がかなりあります。質問の口調だけでar慢に聞こえます。若い開発者にアプローチをプッシュすることで、何を獲得/犠牲にしますか？

あなたが自問する必要がある重要な質問は、あなたの提案はコードベースの品質を維持/改善するか、あなたのピアに対するあなたの優位性/優越性を主張することに向けられていますか？前者は単純な品質管理であり、そのように正当化することができます。はしごはあなたの権利に関係なくチームのダイナミックに有害です。

いずれにせよ、あなたのソリューションを仲間にプッシュしたいなら、それが実際に優れているという具体的な証拠を持っているべきです。パフォーマンスの大幅な向上は、改善するのに十分なほど簡単である必要がありますが、それより少ないものは労力に値しません（パフォーマンスが重要なアプリケーションを除く）。自分の優位性を正当化するために他の人に仕事を強要することは、あなたが「かぎ針編みの老人」として選ばれることで終わります。

注：私が長年にわたって出会った最高で最も才能のあるプログラマーは、彼らがアプローチを始めた背景にある裏話を止めて説明したいと思っていた人たちでした。

まあ、これは興味深く、非常に自然に思えます。若いプログラマーは、自分が書いたコードに非常に興味を持っています。おとこ ！ ！）。

それにもかかわらず、ここに添付されている基本的な文字列には、集中する必要があるコードが添付されており、実行と期待される結果が名前よりも重要であることを理解させるためにかなりの努力を払う必要があると思いますこのコードをプッシュするためにソースリポジトリにエッチングされます。コードが優れている理由として線を引く必要があり、将来の作業のためにコードを維持するという点でも優れています。

いくつかの失敗が目立っていること（アタッチメントのためにいくつかのハートブレイクが必要です）を考慮に入れてください。少し時間をかけて失敗することはほとんどないと思います。彼らにそれを強制することは、いくつかのサクセスストーリーを巡って逆になり、その後、終末と反乱になるでしょう。

誰もが異なるスタイルを持っています。10人の異なる人々を見つけて、自明でない問題を提示すると、10の異なる「コーディング標準」スタイルを使用して、10の異なるアプローチを提供します。

重要なのは、重要なものを選ぶことです。正しい解決策を生まないジュニアから何かが提示された場合、それはひどく非効率的（ここでの指示ではなく1桁の大きさ）、またはセキュリティホールを作成した後、問題とその理由を説明します。「これをやった」というコメントであれば、それは素晴らしいことです。あなたは「あれ」をし、彼女は「他のこと」をしたでしょうが、問題はまだ十分に解決されています（上記のポイントを参照）。次の機能に進むか、修正してください。

良いリーダーになることを学ぶことの一部は、本当に重要なこととそうでないことを認識することを学ぶことです。さらに、あなたがすべてを精査する必要がある場合、グループのパフォーマンスの潜在的なボトルネックとして自分自身を削除します。

編集：あなたの提案が本物であり、隠された要件ではないことを確認してください。提案は、それだけです-従うかどうかは自由です。要件である場合は、その旨を明記してください。

他の一部が指摘しているように、あなたが本当にジュニア開発者に提案を提示しているだけで、彼らがそのように表現されている場合、彼らはそれに従うかもしれないので、彼らにイライラする理由はあまりありませんそうする理由はあまりありません。同様に、彼らはあなたの提案に従わないことで彼らを非難することはできません。なぜなら彼らは物事を特定の方法で行うための実際の方向ではないからです。

ジュニア開発者にあなたがやりたいことをやらせるようにすることに関して：

• 用語を制御します。提案を行うことは、指示を提供することと明確に異なる推奨を行うこととは異なります。それに応じて用語を使用して、ポイントを理解し、何かを行う方法がそれを行うより良い方法であると思われる場合は、そうすることが推奨されることを伝えます。同様に、物事が所定の方法で行われることが絶対に重要な場合（つまり、時間の遅れに耐えられない場合）は、鈍くなり、その方法を指示します。
• 後輩の開発者は、あなたが物事をどのように表現しているかに関係なく、まだ学習プロセスを行っています。具体的な理由がない限り、常にあなたが彼らに言っていることの背後にある種の推論を提供します。その場合でも、「この方法でやらなければならない、私は自分でそれを気にしませんが、決定はすでに下されています」という線に沿って何かを言うと、ほとんどの人は理解します。彼らはかなり合理的である傾向があります。
• それが本当に単なる提案である場合、あなたのアイデアが実際にそれがどのようにしたよりも優れていることを確認してください。そうだと思わない場合は、開発者と一緒に座ってコードとコンセプトのレビューを行い、ソリューションを正当化できるようにします。他の誰かに説明を始めたら-そしてあなたが正しい質問をしたら-彼らはより良い方法を見て、自分で物事を書き直したいと思うかもしれません。
• 解決策が最初に提案したものと似ている場合は、詳細について口論しないでください。あなたが言ったことを考慮に入れて、やや異なることをしたか、提案に基づいて元の概念を変更した可能性があります。

これは、単体テストの完全な入門書です。あなたのジュニア開発者が解決策を持っている場合、それはテスト可能であるべきです。コードにストレスをかけるための単体テストを作成してもらいます。次に、単体テストを確認します。テストに穴を開けることができれば、テストを再実行して、圧力の下でソリューションが壊れるのを見るのは簡単です。

これにより、ソリューションが優れている理由を示すことができ、コードが変更されたときに再利用できる単体テストを提供し、ジュニア開発者に貴重な学習体験を提供します。そして誰が知っているか、あなたは彼らの解決策がうまくいくとわかるかもしれません。

ある時点で、あなたが担当しなければなりません。あなたは彼らが彼らの意見を表明できるように努力しているように聞こえます。あなたの提案は完璧ではないかもしれません。他の開発者はあなたに理解/同意しないかもしれません。彼らはおそらく互いに同意しません。あなたが担当している場合、それは民主主義ではありません。彼らは仕事に就いたときにそれを知っていました。

彼らがあなたを追わなければならない状況がない場合、あなたは彼らのボスとしてふさわしくなく、役に立たない。チームでの役割を、使用する予定がない場合は、権限ではなくリソースになるように変更します。ある時点で、利用可能な時間制約の下でできる限り最高のコードを出荷する必要があり、時間の終わりまでコードのすべての行を再度議論、調査、議論することはできません。

注文してください。結果とともに生きる。経験から学ぶ。敬意は双方向の通りです。あなたはそれを示していますが、そうではありません。