この記事では、大規模なチームにおける責任の分布を分析します。 あなたが2からN個の開発スレッドに従属するリーダーであるが、この開発はすべて1つの大きなアプリケーションまたは1つの大きなシステムであり、各スレッドが独自のモジュールまたはモジュールの独自の部分に関与している状況を想像してください。 開発フローは機能的にほとんど重複しないことが重要ですが、近隣のコードを使用できます。
したがって、私たちのタスクは、リーダーとして成功する可能性が最大になるような組織構造を作成することです。 明らかに、プロジェクトの成功は組織構造だけではありません。 同時に、正しい組織。 構造は、この成功のコンポーネントの1つです。
「誰が、誰が、何を、いつ」提供し、報告し、コミュニケーションの流れがどのように組織されるかを検討する前に、多数のプロジェクトで見られる非常に頻繁な責任分野の配分と割り当てである「ジャンルの古典」を検討してください。 通常、次の図のようになります（JavaとOracleが例として取り上げられていますが、代わりに他の技術が絶対にあります）。
もちろん、役職は異なる場合があります。
次のような非常に独特な組み合わせがある場合があります。
私はあなたの多くがそのような構造に出会ったと確信しており、おそらくあなたは現在これらの1つで働いています。 それらのすべてが良いですか？ 彼らは彼らの機能を果たし、マネージャーとして、可能な限り低いリソースコストで、より速く、より効率的にプロジェクトの成功を達成するのに役立ちますか？ あなたがまだリーダーではないが、そのリーダーになることを計画している場合は、おそらくそのような構造が効果的でなく、エラーが正確にどこにあるのか疑問に思うでしょう。
上記の例を検討してください。
プロジェクト、プログラム、部門マネージャーの目的は何ですか？ お金を稼ぐことに加えて（ポジションのレベルに応じて）、目標はただ一つです-割り当てられた予算内で、合意された量と機能と品質のレベルで製品を時間通りに作ることです。
上の図を見てください。 彼らは、例えばリリースを、時間通りに、適切な量の機能で、そして合意されたレベルの品質でさえ、作ることができるでしょうか？ 私はそれを非常に疑います。 なぜ疑問があるのですか？ いくつかの理由があります。
まず、責任の不明瞭な領域が疑念を引き起こしています。 上の図で、リリース/プロジェクト/製品のタイミング、範囲、品質を担当しているのは誰ですか？ その結果、トップにいる人がすべてに責任を負います。 そしてこれは本当です。 そして、より低い場合は？ チームリーダーはリリースに責任を負いますか？ そして、少なくともJIRA（または他のタスク追跡システム）の1つのチケットに対しては？ 上記の2つのパターンを見てください-いいえ、間違いなく応答していません。
疑いの点で2番目のポイントは、チームリード間のボールの投げ方です。 たとえば、アナリストは要件を完了し、それらを開発に移しました（アナリストリード->開発リード）。 開発者は明確な質問を持っていて、改訂のためにアナリストに要件を返しました（Dev Lead-> Analyst Lead）。 それらが完成し、再び開発者に渡されました（アナリストリード->開発リード）。 そして再び質問が発生しました（Dev Lead-> Analyst Lead）。 これは長期間続く可能性があります。 しかし、しばらくしてから開発が開始されたと仮定します（Java Lead <-> Oracle Leadなど、開発者の異なる部門間で転送されるボールを排除することにより、意図的にスキームを単純化します）。 開発の開始と並行して、テスターはテストケースの作成を開始しました。 開発の最後に、テストのためにコードが転送されます（開発リーダー-> QAリーダー）。 バグが検出されました（QAリード->開発リード）。 バグが修復され、コードがテスターに再度渡されます（開発者-> QAリーダー）。 そして円で。
この無限の円のある時点で、マネージャーがリリース状況、たとえば準備の割合を知りたい場合、リリース（コード）の90％の準備ができていることがわかります。 そして、なぜ期限が破られようとしているのかという質問には、誰も責任を負わないので、答えの論理的な欠如が続きます。 テスターは本当に正直にテストします。 そして、開発者は見つかったすべてのバグを正直に修正します。 誰もが本当に良い製品を実現したいと考えています。 しかし、開発者とテスターの間で絶え間なくボールが投げられており、終わりはありません。 他のユニット（アナリスト-開発者、開発者-開発者）の間でも状況はまったく同じです。
そして最も重要なこと-誰も最高のリーダー以外には何の責任も負わず、あるグループと別のグループの間でアービターまたはコーディネーターとして行動します。 そして、彼は非常に単純な理由で仲裁人として行動することはできません-非常に多くの開発フローとタスクに遅れないようにすることは不可能です。 可能であれば、構造はまったく異なり、チームリーダーはまったく必要ありません。メインマネージャーが1人、通常のアナリスト+開発者+テスターが残ります。 しかし、人生はそれがさらに悪いことを教えてくれます。 したがって、問題を解決する必要があります。 重要な問題は責任の領域にあります。 そして、それは我々がさらに議論するものです。
そのため、チームリーダーを本当にチームリーダーにする必要があります（これがまさにこの投稿の名前の翻訳方法です）。 実際、上記の例では、彼は誰でもありましたが、彼がそうあるべきではありませんでした。 彼は開発リード、QAリード、アナリストリード、Javaリードなどでした。 そして、バグ修正を伴うテストに成功した後、仕様の開発から開発、配信段階までのタスクのライフサイクル全体を担当していませんでしたが、このSDLC（ソフトウェア開発ライフサイクル）ライフサイクル全体の一部のみを担当していました。 私たちの仕事は、 チームリーダーがその仕事のSDLC全体を担当することです-その場合にのみ、適切な量の機能と適切なレベルの品質で、この仕事を時間通りに確実に配信することが可能になります。 チームリードレベルのコストは、WU（作業単位= 1人日）などの任意の単位または同様の単位を除き、通常は考慮されません。
人が何かに責任を持つためには、1つの重要な要素-権限が必要であることを忘れないでください。 つまり 責任と権限は分離できない2つの要素です。 権限はあるが責任はない場合、それはプロジェクトにとって惨事です。多くの国で、これがどのように進み、どのように終わるかを私たち全員が見ています。 責任はあるが権限がない場合、それはさらに面倒ですが、あなただけのためです。 あなたは失敗が倒れるスケープゴートにすぎません。 そして、あなたは何も影響を与えることができないので、間違いなく間違いがあります。 あなたが権限も責任も持たない場合の選択肢は、この場合あなたはまったくリードではないので、私も考慮しません。 そして、あなたが権威と責任を持っている場合にのみ、あなたは状況に影響を与え、それに対する責任を負い、成功への報酬を受け取ることができます。
以下は、権限と責任の関係を示す図です。
チームリーダーが負うことができる責任を決定しましょう（発生）。 ここにあります：
1. JIRAチケットの責任者
2.リソースの所有者（彼の部下）
3.特定のチーム/チケット/リリース内に特定の責任のリストがある（たとえば、レポートは特別な方法で行われます）
4.品質に対する責任
5.知識の所有者
6.コンピテンス内でいくつかの責任を負っています（たとえば、彼はOracleのシニア開発者であり、開発に時間を割く必要があります）
これらの6つのポイントは、非常に便利な2つの大きなセクションに分かれています。
タスクセクション
1. JIRAチケットの責任者
2.リソースの所有者（彼の部下）
3.特定のチーム/チケット/リリース内に特定の責任のリストがある（たとえば、レポートは特別な方法で行われます）
品質と知識のセクション
1.品質の責任
2.知識の所有者
3.コンピテンス内でいくつかの責任を負っています（たとえば、オラクルのシニア開発者であり、開発に時間の一部を費やす必要があります）
タスクセクションを開発リーダーに割り当てるのは理にかなっています。 また、品質と知識のセクションでは、新しい用語を考案する必要があります。 そして、そのような用語があります-コンピテンスリード（コンピテンシーのリーダー）。 したがって、明確で測定可能な実質的な事柄に焦点を当てた責任の重複しない領域を取得します。
「タスクゾーン」のすべての責任により、タスクを予定通りに完了させ、タスクに必要なリソースを提供し、このセクションの所有者に目標を達成するために必要な権限を与えます。 「品質セクション」のタスクは、特定のタスクの実装に影響を与えることなく、スキルと従業員の能力開発を高品質で監視します。 一緒に、彼らは私たちがプロジェクト管理でとても必要とする利得と成功を与えます。
これらの6つの責任を2つのグループに分け、なぜ各グループを異なる人々に割り当てるのですか？ 現時点でチームリーダーの役割（または同様の役割）を使用している場合、または過去にそれを使用したことがある場合、2つのグループのそれぞれが完全に異なる焦点を持っていることがわかります。 したがって、こうしたリードは、これらの両方の職務グループを成功させるために、異なる品質を持つ必要があります。 特に、彼が最近チームリーダー（TL）になった場合、この性質の組み合わせが常に1人ですぐに見つかるとは限りません。 はい、必要なすべてのスキルを開発することができ、開発する必要があります。時間がかかります。 多くの場合、実際には、実際のプロジェクトでは、両方のグループではなく、1つまたは別の職務グループのみに関心を持つ多くの人々に会うことができます。 したがって、純粋に統計的には、リーダーとして、これらの責任を正確にそのようなグループに分割し、さまざまな責任のある責任者、および第1または第2の職務の遂行に最適な担当者を割り当てることにより、著しく収益性が高く、迅速かつ容易になることがわかります。
組織図での表示方法：
図3では、QAスペシャリストのグループが破線で囲まれており、このグループ内に「コンピテンスリードQA」というポジションの人がいることがわかります。 このコンピテンスリードのQAグループには、プロジェクトで利用可能なすべてのテスターが含まれています。 同様に、アナリスト、ジャビスト、オラクル主義者、プロジェクトに参加しているすべての人をメンタルサークルに入れることができます。 プロジェクトが大きく、グループが大きすぎる場合は、ルール7 + -2（グループごとに5〜9人）に従って、それらをいくつかに分割します。 したがって、コンピテンシー、人材開発、コード品質チェック、コーチング、トレーニング、クロスレビュー、知識の共有、人々のバックアップ、および戦闘プロジェクトに十分な時間がないことが多いその他の多くの作業上の問題の問題を完全に解決します。
チームリーダー（ TL ）およびコンピテンスリーダー（ CL ）の責任リストはどのように見えるか。
責任TL ：
1.特定のJIRAチケットの配信
2.関連リリースのブランチ
3. *休暇の提出
4. *残業の提出
5.部下の病気または遅延に関する情報
6.スタンドアップの実施
7. ** L0、L1チケットの評価
8.チーム内のタスクの分散：
-リソースの負荷分散
-タスクマネージャーの配布
注：
* 3、4段落では、正確に意味するのはピッチであり、「アップラン」ではありません
**条項7- CLの参加が義務付けられています（少なくとも大規模および中規模のチケットの場合）
責任CL ：
1.タスクの技術面および品質面に対する責任：
- 使用技術
- 標準の使用
- 建築上の問題
- アプローチ、テストの概念。 テスト計画。 ケーススタディレビュー
- 品質仕様。 仕様レビュー
- 要件と仕様への準拠
- コード品質。 コードレビュー
2.積極的なポジション：
- コーチングインターン、新しいカメラ（だけでなく）
- 技術改善の提案
関連するCLは以下にも関与する必要があります。
1.タイミングシフト
2.開発、テストなどの分野における内訳とその変化...
3.人材開発計画、教育、トレーニング（ TLおよびPPMとともに）
あなたが取ることができる次のステップ：
プロジェクトの組織構造を更新したらすぐに、チームリーダーとコンピテンスリードを選択し、彼らの将来の責任を報告および調整し、適切な権限を与え、チームの新しい構造とゲームの新しいルールを表明します。それははるかに単純で簡単になります。 もちろん、他の多くのさまざまな困難や落とし穴に遭遇しますが（簡単で簡単だとは誰も約束しませんでした）、少なくともあなたの責任問題は明確に解決されます。
この記事を友達と共有してください。
ありがとう、そして幸運を！