開発チームを構成する方法

私は、会社のWebサイト/ Webアプリケーションの世話をする11人のソフトウェア開発者のチームのマネージャーであり、最大4つの同時プロジェクトに加えて、毎日のサポートをいつでも実行しています。11人の開発者には、技術的なスキル、役職、経験が混在していますが、チーム構造はフラットで、11人の開発者全員が私に直接報告しています。

単一のマネージャーを持つチーム全体が、あまりうまくスケールしないことが証明され始めています。私はあまりにも薄く広がり始めているので、直接報告の数を減らしたいです。これを行うために私が考えることができるすべての方法には、重大な欠点があります：

• ジュニア開発者にシニア開発者に報告してもらいます。これにより、最高の技術者が開発に費やす時間を削減できます。
• チームをソフトウェア製品で分割します。たとえば、開発者1〜6はイントラネットで作業し、7〜11は外部サイトで作業します。各セクションには新しいチームリーダーがいます。 ）。これにより、人工的なサイロが追加され、「イントラネット開発者」が外部のWebサイトで作業するのが困難になる場合があります。
• 構造を平らに保ち、プロジェクトマネージャー/チーム管理者の形をした管理サポートを追加して、プレッシャーを取り除きます。チームはこのように永遠に成長することができないため、これは問題を解決しません。

この問題を解決する標準的な方法はありますか？

そうでない場合、他の人はこの問題をどのように解決しましたか？

簡単な考え：

• サブチームは良いアイデアです：構造のない11の直接レポートは、実行可能なチームには大きすぎます（直接コーチングするための十分な時間がないため、多くの人々とのチームミーティングは非生産的になりがちです）。
• 運用を開発から切り離すことを検討してください。スキルセットが少し異なるため、運用上の問題によって1日中中断されると、プロジェクトの開発生産性が大幅に低下する可能性があります。
• 最初の2つのポイントの結果として、おそらく3つのサブチーム（イントラネット、外部サイト、運用）が必要だと思います。2人の開発チームがビジネスに新しいプロジェクト/価値を提供することに焦点を合わせている間、運用担当者はすべての日々の問題/保守修正などに対処します。
• 定期的にチーム間で人を循環させます。これは、プロジェクトのために、または恒久的に（たとえば、他のサブチームでコードのレビューを行うように）行うことができます。ただし、ビジネス上のニーズがある場合は常にチームの役割が変わることを理解してください。特定の役割を永久に「所有」する人はいません。
• マネージャー/管理者を追加しないでください-これは、チームの全体的な効率/生産性を低下させる確実な方法です。各サブチームで最も経験のある人に、チームリーダー/コーチの役割を演じてもらいます。彼らがここで自分の役割をコーチングし、チーム全体を成功させることを確認し、「タスクマネージャー」として行動するのではなく、このように振る舞う能力を備えていることを確認してください。
• あなたの役割は、外部の利害関係者の管理、グループ内のリソース/タスクの優先順位付け、および「ヘッドコーチ」として行動することに焦点を合わせるべきです。サブチームから時折エスカレートされる問題に対処する必要がありますが、一般的には、サブチームに来ずに自分で問題を解決するよう奨励する必要があります。
• あなた自身が非常に技術的であれば、アーキテクト/設計保証の役割を果たすこともできます。そうでない場合は、チーム内または他の場所でできる人を見つけてください。

また、アジャイルマニフェスト、特に12の原則を読み、（再）読む価値は常にあります。

その構造は主に depend on project specifications

理想的には、チームの上級開発者ごとに3人のジュニアがいるはずです。その結果、ティーチリードごとに2〜3人の上級開発者がいます。

したがって、技術リードのみがプロジェクトの進捗状況をPMに報告します。説明された構造では、技術的でない問題（休暇、休暇、紛争など）については誰でもPMにアクセスできると想定しています。

私が参加した比較的成功したソフトウェア開発チームの 1つは、プロジェクトごとに次のようになりました。

ソフトウェア開発マネージャー/シニア開発者/メンター。誰もが直接報告しました。

• スケジュールを守り、要件と受け入れ交渉を促進し、コミュニケーションを行ったプロジェクトマネージャー。誰もが点線でこの人に報告しました。ドキュメンテーション担当者（ときどきPMでもありましたが、専門知識が認められた場合のみ）。
• プロジェクトのニーズに応じて、1〜3人の開発者または上級開発者が混在します。
• 可能な場合はジュニア開発者。
• QAプールから割り当てられた人。
• インフラストラクチャーの人（マネージャーがSA能力もしっかり持っているため、マネージャーが果たす役割が多い）。

それは完璧に機能し、その組織が大好きでした。一方、私はソフトウェア開発マネージャーであり、チームの組織構造は進化していました。

機能スタッフ組織パターンに従うことを検討してください。これは、ソフトウェア製品別にチームを分割する2番目のオプションに向かって話します。

あなたの文脈で記事を引用するには：

機能組織の最大の強みは、社会構造をビジネス価値の提供に結び付けることです。私の考えでは、ソフトウェアプロジェクトは、サポートするアクティビティの有効性を向上させるほど成功し、ビジネス価値を生み出します。同じ方法でチームを編成することにより、ビジネスユーザーの満足度を重視したチームができます。

実際の管理/ HR構造は、それ以上のものではありません。

この問題を解決する標準的な方法はありますか？

あんまり。それはあなたのチーム、あなた、何をする必要があるか、そして会社があなたに利用可能にするリソースに依存します。

個人的には、最高の種類の切り替えは、技術管理を管理管理から分離することです。人々が両方に優れていることはまれであり、相互作用することはめったにありません。

1人が技術的な側面を処理します。何をする必要があるのか​​、誰がそれを行うのか、物事をどのように並べるのか。もう1つは管理面を処理します。レビュー、予算会議、製品計画など。その後、彼らは協力して、一方から他方への洞察を伝え、統一された戦線を提供します。

これがどのように分割されるかは、いくつかの異なる方法になります。最も一般的なのは、エンジニアリングマネージャーを管理側にし、アチテクトを技術側にすることです。彼らは仲間であり、ディレクター/ VPに報告します。

私が見たもう1つの仕事は、エンジニアリングマネージャーを管理者にし、チームリーダーが技術者として行動することです。これには注意が必要であり、報告が階層的であっても、適切な人々が（ほとんど）ピアとして行動する必要があります。

特定のシナリオでは、2〜3チームで技術的な側面を担当し、管理者に専念することをお勧めします。はい、実際にコードを書いているリードから時間を削減しますが、彼らは（良い仕事をしているなら）より若い開発者をより効率的/生産的にすることでその時間を取り戻すべきです。それにより、実際の昇進でもより多くのモチベーションと達成感が得られます。そして最も現実的には、新しいポジションを開くよりも経営陣に売りやすいです。