ジュニア開発者で一杯のチームをリードする方法は？
現在、私は4人の開発者のチームを率いています。彼ら全員が5〜6か月前にキャリアを始めました。私たちはグリーンフィールドプロジェクトに割り当てられているので、自分自身は幸運であると考えることができます。ビジネス目標を達成するかどうかは、完全に私たち次第です。会社自体は非常に小規模で、レガシーアプリケーションの保守に長い歴史があり、最新の状態にはほど遠いものです。これらの状況により、社内ではある程度の孤立が生じました。最初はやる気がありましたが、数か月後には焦げてしまいました。私の立場は非常にトリッキーです。プロジェクトに特別に割り当てられた管理チームやビジネスチームがいないため、私はたった5人しかいないので、主に私が対処します。アーキテクチャの設計（およびその大部分の記述）、コードレビューの保持、バックログの整理、すべてを推進すること、および管理に向けた進捗状況の伝達。先ほど触れたように、焦げて欲求不満になり始めました。私は本当に助けを得ることができず、誰かとの技術的な議論すらできず、後輩が私の決定に挑戦することを現実的に期待することはできません。
とにかく、私の本当の質問は次のとおりです。これらすべてにどのように対処しますか？進行状況を維持しながらコードベースをできる限りクリーンに保つようにしているので、プロジェクトはシャットダウンされませんが、進行のために、そうでなければ解決できないであろう解決策を受け入れるように感じる場合があります。これらはばかげた質問に聞こえるかもしれませんが、一部の人は以前にそれを経験したことがあると思います：プルリクエストを拒否するのは何回ですか？保持する必要のあるトレーニングはいくつありますか、または自分の作業の何パーセントがドキュメントを作成する必要があるので、私は単一障害点ではありませんか？私は明らかに誰もがこれに明確に答えることを期待していませんが、むしろ意見を聞きたいです。
あなたの質問はすべて関連しており、あなたが言ったようにあなたのチームはかなり若いです。一緒に部屋にいたら、彼らの知識のギャップを埋めるために何をしたかについて質問します。私が見るいくつかの赤い旗があります：
- あなたは孤立して成長しています-つまり、会社の誰もあなたがしていることに専念していないということです
- あなたは進歩のほとんどをやっています、そしてそれはイライラさせられます。
- あなたは本当に負荷を取り除くのを助ける人々の階層を持っていません
答えは、飲み込むのが難しい薬です：
あなたはコードでいくつかの乱雑さを受け入れるにする必要があります。
あなたのチームはあなたのプロジェクトと同じくらい環境に優しいかもしれませんが、あなたは手付かずのコードを過度に強調している場所にいるかもしれません。人々は無菌環境で学ぶことはできません。彼らは物事を台無しにするのを恐れすぎます。あなたのチームがそれを台無しにするのを恐れているなら、あなたが彼らの後ろにやって来てとにかくそれをやり直すと知って、それは彼らをやる気にさせます。
プルリクエストを拒否しても問題ありませんか。
グリブの答えはそれが取るだけの回数です。しかし、実際の生活は異なります。
- アーキテクチャ上の問題や危険性のために、プルリクエストが失敗していることを確認してください
- プルリクエストに失敗した場合は、トレーニングの瞬間にしてください
- 脆弱性が何であるか、またはコードがどのように傷ついているかをチームメンバーに知らせる
- そもそもその問題を回避する方法を理解するのを助ける
- 彼らに変更を行わせる。あなたがスプーンで何をすべきかを彼らにスプーンで与えても、彼らは何も学びません
保持する必要のあるトレーニングはいくつありますか、または自分の作業の何パーセントがドキュメントを作成する必要があるので、私は単一障害点ではありませんか？
答えるのは難しいです。誰かを訓練するときに、焦点を合わせるためにトップスを1つまたは2つ選ぶ必要があることがわかりました。正と負の両方のフィードバックのバランスを取る必要があります。誰かが正しいことをしている場合は、伝えてください。それは良い行動を強化するのに役立ちます。
チームに設計上の決定を含めます。彼らはおそらく白紙からデザインを思いつくのに十分なスキルはありませんが、デザインをあなたので機能するように調整するのを助けることができますチームのスキルではなく、それらに対して。
Why The Face？！（WTF）の瞬間のドキュメントを保存します。つまり、意外な要件や設計標準からの逸脱がある場合は、それを文書化します。また、概念設計とは何かを文書化します。チームと通信するのに十分です。
チームが自分の作業の所有権を取得することを奨励すればするほど、彼らは挑戦に立ち向かうでしょう。そして、誰かがそうしないなら、あなたはそのチームメンバーの変更について経営陣に話しかけることを見ることができます。
私があなたにアドバイスを提供したいのと同じくらい、私はあなたにできることはほとんどないと信じています。この問題を経営陣に伝え、経営陣が手助けをしたくない（またはできない）場合、成功する可能性は最小限です。
このような問題は、多くの場合、チームレベルまたは技術レベルでは解決策がないと思います。このような問題を真に解決できるのは経営者だけです。おそらく、後輩の指導と指導に役立つ、より人間中心のスキルを持つ人々を追加することによって。あるいは、価値の提供に対するプレッシャーを軽減し、後輩が失敗することを可能にし、すでに行われているが不十分な仕事を学び、やり直すことによって可能性があります。
また、経営陣がこれらの条件を受け入れるようにすることは、しばしば政治に関わるものであり、政治に関与することを明らかに望まない、できない、または意欲がないことは明らかです。
グリーンフィールドプロジェクトは素晴らしいものですが、ジュニア開発者のチームにとっては、挑戦的でストレスの多いものになる可能性があります。これは非常に難しい状況のように聞こえます。
良い議論のポイントとなる2つの質問があります。
プルリクエストを拒否しても問題ありませんか。
チームは品質プロセスを所有し、それに取り組む必要があります。品質についてのコンセンサスを構築するようにしてください-誰もが高品質のデザインとコードを持つことの価値を見ていますか？そうでなければ、率直に言って、あなたは毎日戦い、岩を押し上げるでしょう、そしてそれは価値がありません。
（a）品質が重要である理由、および（b）どのレベルの品質が期待または要求されるのかについて共通の理解を得ることははるかに優れています。期待が明確で、人々が彼らの目標を理解している場合、あなたはその目標に向かってより簡単に指導することができます。
（あたかも存在するかのように）完全なコードを期待するのは不合理ですが、いくつかの標準を設けることは完全に合理的です。チームと会って、それらの基準に同意します。それはあなたの標準ではなく、チームの標準である必要があります。チームの他のメンバーがこれらの標準の実施を支援していることを確認してください。 PRの問題が繰り返し発生する場合の解決策をチームが立てるのを助けます。 （a）問題を解決するための「集中治療」のためのペアプログラミングセッション、（b）グループ学習のための暴徒/グループプログラミングセッション、または（c）チームの品質への期待に関する議論など.
これらのことを試し、定期的に「検査および調整」してください。これは、チームの品質の理解、取り組み、経験が向上するにつれて変化する進化するプロセスになります。
保持する必要のあるトレーニングはいくつありますか、または自分の作業の何パーセントがドキュメントを作成する必要があるので、私は単一障害点ではありませんか？
他の人の速度を上げるために100％利用できる必要があります。主な責任は、単一障害点（またはボトルネック）から抜け出すことです。
ドキュメントを書くことは役立つかもしれませんが、notは役立つかもしれないことに注意してください。チームには何が必要で、何を望んでいますか？彼らはグループ指導、またはマンツーマンのコーチングを望んでいますか？ペアリングやモビングのようなアプローチは役に立ちますか？
できる限り委任し、他の人に間違いを犯させたいが、フィードバックとコース修正はできるだけ早く提供する（つまり、頻繁なレビュー）。それは人々の機知とこれらのことを学ぶ能力を奨励するために重要です。