開発チームを構成する方法
私は、会社のWebサイト/ Webアプリケーションの世話をする11名のソフトウェア開発者のチームのマネージャーであり、最大4つの同時プロジェクトと日々のサポートをいつでも実行しています。 11人の開発者の中には、技術的なスキル、役職、経験が混在していますが、チーム構造はフラットで、11人の開発者全員が私に直接報告しています。
チーム全体で1人のマネージャーがいるため、十分に拡張できないことが証明され始めています。あまりにも薄く広がり始めているので、直属部下の数を減らしたい。これを行うと私が考えることができるすべての方法には、重大な欠点があります。
- ジュニア開発者にシニア開発者に報告してもらいます。これにより、最高の技術者が開発に費やす時間を削減できます。
- チームをソフトウェア製品ごとに分割します。開発者1〜6はイントラネットで作業し、7〜11は外部サイトで作業します。各セクションには新しいチームリーダー（おそらく、現在の上級開発者よりも多くの管理/メンタリング/コーチング責任を持つ新しい職務記述）がいます。これは人工的なサイロを追加し、「イントラネット開発者」が外部Webサイトで作業することを困難にする場合があります。
- 構造をフラットに保ち、プロジェクトマネージャ/チーム管理者の形で管理サポートを追加して、プレッシャーを取り除くだけです。チームがこのように永遠に成長し続けることができないので、これは問題を解決しません。
私が見逃しているこの問題を解決する標準的な方法はありますか？
そうでない場合、他のどのようにしてこの問題を解決しましたか？
いくつかの簡単な考え：
- サブチームは良い考えです：構造のない11の直属の部下は、実行可能なチームには大きすぎます（直接のコーチングに十分な時間がないため、その多くの人々とのチームミーティングは非生産的な傾向があります）。
- 運用を開発から切り離すことを検討してください。これは少し異なるスキルセットであり、運用上の問題によって1日中中断されると、プロジェクトの開発生産性に深刻な悪影響を与える可能性があります。
- 最初の2つのポイントの結果として、イントラネット、外部サイト、運用の3つのサブチームが必要になると思います。 2人の開発チームが新しいプロジェクト/価値をビジネスに提供することに集中している間、運用担当者はすべての日常的な問題/メンテナンス修正などに対処します。
- チーム間で定期的に人を切り替えます。これは、プロジェクトに対して、または恒久的に、不定期に（たとえば、別のサブチームでコードのレビューを行わせるなど）することができます。ただし、ビジネスニーズがある場合は常にチームの役割が変わることを理解してください。特定の役割を永久に「所有」する人は誰もいません。
- これ以上マネージャー/管理者を追加しないでください-これは、チームの全体的な有効性/生産性を低下させる確実な方法です。各サブチームで最も経験豊富な人にチームリード/コーチの役割を果たしてもらいます。彼らがここで彼らの役割を指導し、チーム全体を成功させるように見ていることを確認し、彼らが「タスクマネージャー」として行動するのではなく、このように行動するように備えられていることを確認してください。
- あなたの役割は、外部の利害関係者の管理、グループ内のリソース/タスクの優先順位付け、および「ヘッドコーチ」としての役割を果たすことに焦点を当てる必要があります。サブチームから時々エスカレートされる問題を処理する必要がありますが、一般的には、彼らに出向かずに自分で問題を解決するように彼らに奨励する必要があります。
- あなた自身が非常に技術的である場合、建築家/設計保証の役割を果たすことを選択することもできます。そうでない場合は、チーム内または他の場所でできる人を見つけてください。
また、 Agile Manifesto 、特に 12の原則 を常に読んで（再）読む価値があります。
その構造は主にdepend on project specifications
理想的には、チームの上級開発者ごとに3人のジュニアがいる必要があります。その結果、ティーチリーダーあたり2〜3人の上級開発者がいます。
したがって、プロジェクトの進捗状況についてPM=）に報告するのは技術リードのみです。説明されている構造では、技術以外の問題（休暇、休暇、競合など）について、全員がPMにアクセスできます。
比較的成功したソフトウェア開発チームの1つは、プロジェクトごとに、次のようなものの一部になりました：
他の誰もが直接報告したソフトウェア開発マネージャー/シニア開発者/メンター。
- スケジュールを守り、要件と受け入れ交渉を促進し、コミュニケーションを行ったプロジェクトマネージャー。誰もがこの人に点線で報告しました。文書化担当者（時々はPMでもありましたが、専門知識が許可された場合のみ）。
- プロジェクトのニーズに応じて、1〜3人の開発者または上級開発者の組み合わせ。
- 可能な場合はジュニア開発者。
- QAプールから割り当てられた誰か。
- インフラストラクチャ担当者（マネージャーは確かにSAコンピテンシーも持っていたため、マネージャーが果たす役割）。
それは完璧に機能し、私はその組織を愛していました。一方、私はソフトウェア開発マネージャーであり、チームの組織構造は進化していました。
Functional Staff Organizationパターン に従うことを検討してください。これは、ソフトウェア製品ごとにチームを分割するという2番目のオプションについて話します。
あなたの文脈で記事を引用するには：
機能的組織の最大の強みは、社会的構造をビジネス価値の提供に結びつけることです。私の見解では、ソフトウェアプロジェクトは、サポートする活動の有効性を改善するだけで成功し、ビジネス価値を生み出します。チームを同じように編成することで、ビジネスユーザーの満足を重視するチームが生まれます。
実際の管理/人事構造は、それ以外には関係ありません。
私が見逃しているこの問題を解決する標準的な方法はありますか？
あんまり。それはあなたのチーム、あなた、あなたが何を成し遂げる必要があるか、そしてあなたが会社があなたに提供するどんなリソースに依存するでしょう。
個人的には、最良の種類の切り替えは、技術管理と管理管理を分割することです。両方が得意であることはまれであり、交流する傾向はほとんどありません。
1人が技術的な側面を処理します。何をする必要があるか、誰が行うか、どのように整列する必要があるか。もう1つは管理面を扱います。レビュー、予算会議、製品計画など。次に、協力して、一方から他方に洞察を伝え、統一されたフロントを提供します。
これがどのように分割されるかは、いくつかの異なる方法で実行できます。最も一般的なのは、エンジニアリングマネージャーを管理者側に、アーキテクチャーを技術者側にすることです。彼らは仲間であり、ディレクター/ VPに報告します。
私が見たもう1つの仕事は、エンジニアリングマネージャーを管理者にして、チームリーダーが技術者として行動することです。これはトリッキーであり、レポートが階層的である場合でも、適切な人々が（ほとんど）ピアとして行動する必要があります。
特定のシナリオでは、2〜3つのチームを用意し、テクニカルリードに技術的な側面を任せて、管理に集中することをお勧めします。はい、実際にコードを作成しているリードから時間を短縮しますが、（良い仕事をしている場合は）より若い開発者をより効率的/生産的にすることで、その時間を取り戻す必要があります。また、実際のプロモーションでも、彼らのモチベーションと達成感を提供します。そして最も実際的には、それは新しいポジションを開くよりも経営陣への販売が容易です。