4、变更与发布管理：需求与流程全解析

变更与发布管理：需求与流程全解析

1. 需求获取与衍生

在项目中，向利益相关者询问问题时，他们的回答往往会引出新的问题。例如，他们可能不清楚创建柱状图相较于简单数字的难度，也想了解十三个月与两个月的额外成本差异。为避免陷入无休止的问答循环，最佳做法是让项目团队衍生额外的详细需求。团队会对利益相关者可能的需求做出假设，并将这些假设记录为衍生需求。

不过，衍生需求时要把握好度。项目团队不会为报告指定具体的列标题、文本字体大小等细节，但会确定从数据库获取哪些数据以及数据在报告中的大致布局。原则是提供足够的细节，让利益相关者对项目最终结果不会感到意外，同时也给有能力的设计人员留出实现需求的选择空间。

2. 需求的整理与文档化

收集完需求后，需要对其进行有效整理。最好的方法是根据利益相关者的需求和期望为需求分配优先级。

需求应以文档形式呈现，虽然也可以存于电子表格、数据库或需求管理工具中，但文档更便于审查。需求是项目范围文档的一部分，此外，完整的范围文档还应包含以下元素：
- 项目的业务背景
- 项目发起人的列表
- 项目利益相关者的列表
- 最终状态的高层描述（有时称为运营概念）
- 审批页面

如果需求过多导致范围文档过于繁杂，可以将需求拆分为两份文档。业务需求仍保留在范围文档中，而更具技术性的流程、系统和组件需求可放入名为“服务需求规范”的单独文档。这样，发起人可以审批高层需求，项目团队和技术利益相关者审查低层需求，两份文档可分别审查和批准。

在项目的整个生命周期中，要维护好需求。项目变更不可避免，每次需求变更后，都要重新审视需求文档的审批，确保所有利益