回答。
変更管理は、要求がプロジェクトの進行中にしばしば修正されるため、ビジネスアナリストの重要な任務です。変更管理（change management）には以下が含まれます:
- 変更の影響評価。 アナリストは、ビジネスと技術アーキテクチャへの新しいリクエストの結果を評価します。
- 変更の形式化。 すべての変更は、元の要件との明確な関連を持って文書に記録されます。
- 通知と合意。 変更について連絡する必要があるすべての利害関係者を特定し、彼らとの合意を得ること。
- 導入と監視。 変更を加えた後の修正の監視と改善またはリスクの分析。
主な特徴:
- 変更を追跡するために、規則（例：Change Request）を使用することが重要です。
- すべてのリクエストは、影響評価と承認の手続きを経る必要があります。
- 透明性のために、変更の履歴（version control）を記録する必要があります。
トリック質問。
変更を顧客の確認なしにチームと直接合意することはできますか？
できません。すべての変更は顧客と合意する必要があり、対立や誤解を避けるためです。
変更は常に製品を改善しますか？
いいえ。変更は、時には製品を悪化させたり、期限やコストを増加させることがあります。常に影響の詳細な評価が必要です。
すべての変更を別の文書に記録する必要がありますか？
必須ではありませんが、要求管理システム全体または個々のChange Requestに記録することが重要です。最も重要なのは、変更履歴を明確に追跡することです。
一般的なエラーとアンチパターン
- 変更を記録せず、要件のバージョン管理を行わないこと。
- 公式な合意なしに変更を実施すること。
- 変更が製品の他の部分に与える影響を無視すること。
実生活の例
ネガティブケース:
マネージャーの口頭のリクエストに基づいて影響評価なしに変更が実施されました。
- プラス: 新しい機能を迅速に導入。
— マイナス: 予期しないエラーが発生し、他のモジュールとの対立が生じました。
ポジティブケース:
各リクエストがChange Requestとして形式化され、リスク評価と合意が行われました。
- プラス: 予期しない事態の最小化、透明性。
— マイナス: 官僚的な手続きに時間がかかります。