BSA / Product Development Processes Creating Release n.n.n

Product Development Processes Creating Release n.n.n †

ソフトウェアアーキテクチャと同様、最初のリリースにはたくさんの時間と熱意を注ぐ。

• でも現実的には、ほとんどのプロダクトはその後も続いてリリースされる。
• 「製品開発プロセス」節に書かれたプロダクト開発プロセスの主な変更は、次のようなもの。

• コンセプトとプロダクト提案は飛ばされがち。
  • プロダクト提案の価値が、プロダクトの成熟度をかなり引き下げる。
  • 与えられた市場を特定し対象とする作業があまりなく、次に対象とするセグメントや次のニッチな市場をどのように獲得するかを特定する作業が多い。
  • 厳格な企業はプロダクト提案を書き上げるのに時間をかけるだろうが、これはMRDを支持するものである。

• ビジネスプランはせいぜい、新規リリースを反映したアップデート程度のもの。
  • 初期開発正当化するビジネスプランは、新規リリースをほんの少ししか反映しない。
    • これは不備ではなく、高いレベルで、広い観点を反映させたものとなる。

• MRDはリリースの中心的な文書となる。
  • 参入した市場での基本的なフィーチャのみが書かれた最初のリリースのMRDは、続くリリースの中心的なドキュメントとなる。
  • インフルエンサーとみなせる内部と外部のステークホルダーを含めた全てのコンテキストにおけるプロダクトを考えるとわかる。
  • リリース1.0のエコシステムは、特に技術製品に関しては比較的シンプル。
  • 成功したプロダクトのエコシステムはMRDを膨らませ、リリースn.n.nに関するものになるとかなり複雑になる。
  • さらに、構成するステークホルダーのニーズは異なり、以下で挙げるような状況となる。
  • リリースn.n.nのこれらの情報を表すベストな文書はMRDで、ビジネスプランではない。

• ローンチ前とローンチのフェーズはリリースにかなり依存している。
  • リリースn.n.nのリリースに対する依存は、ローンチ前とローンチのフェーズがリリース1.0よりとても重要。
  • MSのXP、APpleのOS X、SunのSolaris2.8の販促を考えると、これらのローンチャーはかなり大きく、前回のローンチよりも重要だった。