BSA
製品開発プロセスの拡張 †
しっかりとした製品開発プロセスは、不要に細かいことや忙しい仕事に行き詰まってしまい、これを防ぐためにいくつかの重要な概念とプロセスを説明した開発プロセスを拡張することが役立つと分かった。
連続した凍結 †
開発の初期段階では作業成果物の管理において担当チームに対して最大限の柔軟性を与えるが、製品にコミットされた意思決定を行う時凍結しなければならなく、様々な成果物を連続的に凍結する概念が重要になる。
プロダクトマネージャーは、コンセプト段階で提案されたアイデアの市場を幅広く検討するかもしれないが、彼らは通常、事業計画の中で具体的なターゲット市場に絞り込む必要がある。
開発側では、要件、ユーザインタフェース、データベーススキーマ、サブシステム間に存在するAPI、そして最終的にはコード自体を凍結することを選択できるが、凍結は変更を防ぐという意味でなく比較的正式な変更管理プロセスを介してのみ変更できる決定を意味する。
変更管理プロトコル †
変更プロトコルは特定の結果の変更に関連付けられている手続きの度合いを指し、最も寛大な変更プロトコルは「なし」(開発者はソースコードをチェックアウトし、変更を加え、ソース管理システムにコミットするのが自由)である。
私は、多くの開発者は変更管理プロトコルによって不快になることが分かった。これは彼らが基本的な目的を誤解しており、目的は創造性を抑圧するためではなく、適切な人が変更が行われる前に知らされることを保証するためである。
いったん凍結し、ヘルプ·システム、エンドユーザのドキュメント、トレーニング資料への変更を調整する必要がある場合、変更を管理する必要がある。また、QAで作成された自動化されたユニットテストや、おそらく技術的なサポートのための更新された参考資料によって必要な変更があるかもしれない。
変更管理プロセスは、理解し承認し、かつそれを正しく処理できることを確認するために、変更によって影響を受ける利害関係者を含める必要がある。候補は技術的な出版物、QA、製品管理、技術サポート、およびリリースエンジニアリングが含まれ、製品中心の組織では変更管理会議は組織化されるべきであり、製品管理が議長を務める。他の組織では、プロジェクト全体を実行しているプロジェクトまたはプログラムマネージャが議長を務める。
ドキュメントのバランス †
すべてのマネージャーが学ばなければならない最も重要なことの一つは、特定のプロジェクトに必要な書類の適切なセットを作成するための普遍的な公式はない、ということである。私はアジャイルメソッドと最小のドキュメントを使用して、非常に成功したシステムを作ったこともあるし、重要なドキュメントが不足して失敗したプロジェクトもあった。
ここに2つの良いガイドラインがある。初期のリリースは、できるだけアジャイルプロセスを使用して作成すべきで、アジャイルプロセスは市場のフィードバックを最大化するベストの方法であることがよくある。時間が経つにつれて製品が固化し市場が成熟するとアジャイルからよりフォーマルメソッドへ移行していくが、多くの組織では深刻または致命的な課題に直面することがある。
あなたのチームが望む製品開発方法を理解することが非常に重要で、彼らが信じないアプローチを採用することを強制するのは確実な失敗の元になる。
ごみ箱 †
潜在的に有用なアイデアを捨てるのではなく、将来の使用のために保存できるごみ箱を作成することをお勧めする。与えられたアイデアは、今後のリリース、または将来のイテレーションで再浮上するかもしれない。
担当者のつぶやき †
みんなの突っ込み †
