トップページ>プロジェクト管理>仕様変更を防ぐには?
ソフトウェア開発では仕様変更は必ずどこかで発生する。
仕様変更の発生と対処そのものは、より良いものを開発するには必要な要素だが、
大半は先に検討していれば計画時に考慮できているものが多いと考える。
発生そのものを少なくする、発生時期を制御する、発生した後の影響を抑えるといった観点で、
仕様変更に対処する方法を考えていく。
仕様変更を防ぐことについて、誰がどの役割の人間に対して働きかける内容か、
実体験をもとにまとめていく。
仕様変更の発生と対処そのものは、より良いものを開発するには必要な要素だが、
大半は先に検討していれば計画時に考慮できているものが多いと考える。
発生そのものを少なくする、発生時期を制御する、発生した後の影響を抑えるといった観点で、
仕様変更に対処する方法を考えていく。
仕様変更を防ぐことについて、誰がどの役割の人間に対して働きかける内容か、
実体験をもとにまとめていく。
そもそも仕様変更を受けるべきプロジェクトかどうかを決める。
商品特性上、コストをかけずに開発したい、とにかく期間を短くしたい、などの狙いがある。
最も優先順位の高い要求事項を洗い出し、仕様変更そのものを受け付けない前提を立てることも必要。
商品特性上、コストをかけずに開発したい、とにかく期間を短くしたい、などの狙いがある。
最も優先順位の高い要求事項を洗い出し、仕様変更そのものを受け付けない前提を立てることも必要。
開発途中のリリーススケジュールを策定する。
どのリリースで何の機能が出来上がるかを明確にする。
リリース毎にステークスホルダーに確認してもらう期間を取る。
→開発プロセスの定義にも関わる。環境面(メンバー、情報共有方法、利用ツール、etc)の検討にも影響。
どのリリースで何の機能が出来上がるかを明確にする。
リリース毎にステークスホルダーに確認してもらう期間を取る。
→開発プロセスの定義にも関わる。環境面(メンバー、情報共有方法、利用ツール、etc)の検討にも影響。
仕様書の読み込み時間を確保し、不明点の洗い出しを先におこなう。
→当たり前だけど、まともま仕様書が作成されることがなかったり、
進めながら定義していくプロジェクトも多々ある。
情報の残し方、作り方を定義し、合意を得ることが大事。
ステークスホルダー間での共有内容・意識・狙いをメンバーにも浸透させる
→早期に仕様矛盾、不備、改善の発信につなげられるだけの情報を共有する。
→当たり前だけど、まともま仕様書が作成されることがなかったり、
進めながら定義していくプロジェクトも多々ある。
情報の残し方、作り方を定義し、合意を得ることが大事。
ステークスホルダー間での共有内容・意識・狙いをメンバーにも浸透させる
→早期に仕様矛盾、不備、改善の発信につなげられるだけの情報を共有する。
こちらから問いかけることで、本当に顧客目線で必要なものかどうかを見直す。
→特定のステークスホルダーの想いだけで生まれる変更もある。
それが理にかなうものなのか、精査する機会が必要。
→特定のステークスホルダーの想いだけで生まれる変更もある。
それが理にかなうものなのか、精査する機会が必要。
仕様変更と引き換えに他の何かを削る、もしくは別の制約条件をかける、などの、
天秤にかける情報を開示する。
→こちらの余力を見せることは、相手によっては逆効果にもなるので注意。
時間が空けば、本当に必要でないものでも追加したくなるケースもある。
天秤にかける情報を開示する。
→こちらの余力を見せることは、相手によっては逆効果にもなるので注意。
時間が空けば、本当に必要でないものでも追加したくなるケースもある。
コメントをかく