では前の記事、エンタープライズレベルの企業で製品管理の正しいスケーリングの主なアイデアをまとめました。今こそ、それぞれのアイデアを個別に検討するときです。今日は、多くのサブシステムで構成される複雑なソリューションの製品とは何かについて説明します。
製品定義の問題を理解する最も簡単な方法は、例を使用して説明することです。以下に、抽象的なサービスを提供するための一種のソリューションである一連のシステムを示します。
これは、サービスを提供するための非常に単純化された、やや典型的なソリューションです。実際には、システムのリストははるかに広く、数十に数えられていますが、一部のシステムは古くなっている可能性があり、新しいシステムと交換する必要があります。
このようなシステムの開発は、企業によって組織が異なります。一部の企業では、複数のコンポーネントを担当する開発チームを見ることができますが、逆に、複数のチームが1つのコンポーネントを開発できます。ただし、多くの場合、システムごとに1つの開発チームがあります。これは、古典的で最も一般的なコンポーネントチームのアプローチです。
, — , , , .
, . , - . : .
?
— , . . .
, ?
, . .
— . , , , . .
— . , , . , , (operational value stream).
, . (feature teams cross-component teams).
. , .
. , , , , , . , .
, , , , . :
. , . , , .
, .
, , :
, ;
, , ;
, , /
, , ;
, "" " " .
, .