成果志向

ソフトウェア開発をスポンサーする人々は、通常、ベロシティや本番環境へのデプロイ頻度などの開発指標にはあまり関心がありません。彼らは、手作業の削減、販売コンバージョンの向上、顧客満足度の向上など、ソフトウェアがもたらすビジネス上のメリット、つまりビジネス成果により関心があります。成果志向のチームは、ビジネス成果を提供するように義務付けられ、その成果を実現するために必要なすべての活動を実行する能力を持つ人々で構成されています。対照的に、活動志向のチームは、そのように義務付けられてもおらず、能力もありません。彼らは、成果を実現するために必要な複数の活動のうちの1つしか実行できません。

ビジネス成果を提供するという義務は、一定量のスコープを提供するという義務とは大きく異なります。スコープのデリバリーは、比較的簡単です。成果の実現には、問題を理解している人と、それに対するさまざまなレベルのソリューションを創出できる人との間の真の連携が必要です。ソリューションの最初の試みは、問題のより良い理解につながり、それがより良いソリューションのさらなる試みにつながります。これは、製品管理組織が開発（スコープデリバリー）組織から分離している場合は機能しません。

成果志向のチームは必然的にクロスファンクショナル（学際的）ですが、活動志向のチームは通常、モノファンクショナル（単一専門）です。最も伝統的なシナリオでは、成果は単純にプロジェクトという形で定義される場合があります。プロジェクトはビジネスケースに基づいて資金提供されるため、望ましい成果はビジネスケースで約束されていることを実現することです。ただし、プロジェクトの規模によっては、1つ以上のチームとして組織される場合があります。これらのチームが活動境界に沿って設定されると、活動志向のプロジェクト（またはプログラム）組織になります。一方、全体的な成果をサブ成果に分割し、サブ成果を提供するのに必要な人員という点で自給自足のクロスファンクショナルチームにサブ成果を割り当てることで、成果志向の組織を実現します。

Sriramの書籍では、成果志向の構造を使用して効果的なIT組織を構築する方法について詳しく説明しています。

成果志向の潜在的な問題は、同じ活動に従事する人々が互いに指導し合い、学び合う機会がないことです。これを緩和するために、メンター能力とコミュニティイベントを組織したり、書籍を購入したり、トレーニングを手配したりする予算を持つ、専門家コミュニティリーダーと共に、プラクティスコミュニティを設立してください。

成果志向のセットアップで大規模プロジェクトを実行することは、活動志向のセットアップで実行するよりも間違いなく優れています。とは言え、成果志向のアプローチは、プロジェクト中心の資金調達モデルから離れるときに真価を発揮します。成果志向のチームで実行されるプロジェクトでは、チームは、その成果がビジネスに関連する限り長く存続するわけではありません。プロジェクトの終了時に解散します。つまり、同じ分野での別のリリースが別のチームで資金提供されるまで、成果を見失ってしまいます。また、これは管理および報告構造の不安定さの問題につながります。これらは、ビジネスケイパビリティ中心の組織で克服できる、プロジェクト中心のIT実行モードの限界です。