公司经过2年多所研发的产品，终于正式试用了，中间经历过了无数次调整，产品研发过程是不断迭代的过程，发生需求变更、设计变更的情况非常多，为不影响创新和开拓思路，研发处在开放状态，当前阶段是时候该形成稳定版本，需要系统性的管理变更了。
　　晚上，业务专家、业务支持人员、产品设计者、开发负责人、管理人员等等，开会审查产品，会上提出了比较尖锐的问题：
　　一是菜单上功能名称表达不合理的情况；
　　二是软件功能与业务连贯性匹配的情况，也是创新产品与传统操作流程的冲突问题；
　　三是互联网化产品吸引人眼球的配色、布局，与传统工业化生产的规范化冲突问题。
　　…
　　这些，从项目管理角度来说，其中很大一部分原因是需求管理出现问题，没有按需求跟踪管理。也就是业务专家的需求在转化为产品设计、软件实现过程中，业务场景没有合理的诠释。如果按UML来说，加上用例图就会更好，例如下图所示：　　
　　对这样的需求，需要在产品上线时，不仅在功能上体现，而且需要在功能菜单、界面上，对业务场景适应性能很好的体现。

1 产品变更管理方案

1.1 产品变更的原则

变更管理的原则是产品基准化、变更管理过程规范化，妥善保存变更所产生的相关文档，确保其完整、及时、准确、清晰、系统，并与管理工具配合（例如SVN）。

1.2 变更管理的组织机构

按项目管理体系，由项目控制委员会（CCB），或相关职能的类似组织等所有者权益的代表，负责裁定。对于产品研发，可以由产品管理委员会负责裁定，重大决定由董事会裁定。

如果产品已经上线给用户使用，试制阶段，需要顾及用户的感受，征询意见；或者，也有用户提出的建议或者需求，需要用户参与。

1.3 需求管理流程

2 需求管理过程

创建和维护《需求跟踪矩阵表》，详见下表包括：用户（专家）需求、变更控制、软件需求、系统设计、软件实现、集成测试、系统测试等内容。
　　产品/项目经理在需求基线发布后，根据发布的《用户需求说明书》或《需求获取分析表》和《软件需求说明书》创建《需求跟踪矩阵》，并将《用户需求说明书》或其他形式的需求和《软件需求说明书中内容对应填入《需求跟踪矩阵》中，同时确定需求的优先级。在以下时点产品/项目经理需要更新《需求跟踪矩阵》：
　　设计阶段，产品/项目经理更新《需求跟踪矩阵》，将设计与需求进行关联。
　　实现阶段，产品/项目经理更新《需求跟踪矩阵》，将代码与需求进行关联。
　　测试阶段，产品/项目经理更新《需求跟踪矩阵》，将测试用例与需求进行关联。
　　发生变更时，产品/项目经理更新《需求跟踪矩阵》，标定变更需求状态，并将与该需求关联的设计、代码、测试用例进行关联。

3 需求跟踪管理

产品/项目经理通过《需求跟踪矩阵》实现对需求的完整性，以及需求双向跟踪。
　　横向跟踪，产品/项目经理正向检查需求文档中的每个需求是否都能在后续工作成果中找到对应点和逆向检查设计文档、代码、测试用例等工作成果是否都能在需求文档找到出处。
　　垂直跟踪，分析需求变化是否影响其它的需求变化。
产品/项目经理在检查过程中发现的不一致问题，记录到《需求跟踪矩阵（需求不一致问题报告）》，并通知相关的项目成员。
　　相关项目成员给出消除“不一致”的措施，并将措施记录到《需求跟踪矩阵（需求不一致问题报告）》。
　　相关项目成员消除“不一致”之后，产品/项目经理更新《需求跟踪矩阵（需求不一致问题报告）》。
　　产品/项目经理根据《需求跟踪矩阵》统计需求状态，并记录到《需求跟踪矩阵（需求状态统计表）》中。

3.1 变更受理

产品研发业务专家/客户代表提出需求变更申请，填写《变更控制跟踪表（变更申请表）》，产品/项目经理根据《需求跟踪矩阵（需求跟踪矩阵表）》，识别需求变更项，填写《变更控制跟踪表（变更控制跟踪表）》。

3.2 变更影响分析

产品/项目经理组织项目成员对变更进行分析，分析变更的影响。更新《变更控制跟踪表（变更影响分析报告）》。
　　如果是重大需求变更，产品/项目经理需要组织相关干系人变更评审，特别强调的是产品投资人——老板参加评审，评审结束后，产品/项目经理需填写《技术评审报告（评审记录表）》，同时根据评审记录的缺陷（如果有），对其进行修订，更新《变更控制跟踪表（变更影响分析报告）》。

3.3 变更审批与确认

产品/项目经理对《变更控制跟踪表（变更影响分析报告）》进行审批确认，并填写审批意见。
　　说明：
　　1、 如果需求变更对其他部分影响较大，需要老板审批后即可执行；
　　2、 如果需求变更对其他部分影响较小，只要产品/项目经理审批就可执行。

3.4 进度计划及任务变更

1、变更审批通过后，产品/项目经理指导变更负责人（项目成员），并将《变更控制跟踪表》提交给产品CM，申请从基线库中提取待变更的配置项。

2、产品/项目经理跟新进度计划，如果涉及到关键路径，变更负责人（项目成员）根据变更的要求完成工作产品的变更工作。

3、工作包/任务估算

用PERT法， 估算活动的工期=（乐观估算+4×最可能估算+悲观估算）/6

$$\begin{gathered} \overline{N}\pm \sigma =68.26\% \\ \overline{N}\pm 2\sigma =95.46\% \\ \overline{N}\pm 3\sigma =99.73\% \end{gathered}$$

例如：项目中某工作包工期估算，持续时间悲观估计为36天，最大可能估计为21天，乐观估计为6天。老板期望在16到26天之间完成的概率有多大？
（1）根据Pert方法估算，工作包的持续时间平均值tE为21天，标准差σ为5天。
tE=（36+4×21+6）/6 = 21
σ =（36-6） / 6 = 5

（2）16到26天刚好是tE±σ的区间。根据随机序列的正态分布，如上图所示所以A项目在16到26天之间完成的概率为68.26%。

3.5 变更效果评价

（1）评估依据是项目/产品的基准；
　　（2）变更所要求的目的是否已经达成；
　　（3）评估变更方案中的技术论证、经济论证内容和实施过程的差距及解决情况。

4 软件产品发布与回退方案

1、对于软件产品来说，变更需要做相应的版本发布，并制定好相应的应急回退方案。为此，确保发布成功，在版本发布前应对每次版本做好配置管理管理，建立好基线和分支。

2、为了确保发布成功，需要做好发布版本发布计划，以及相应的风险评估，建立Check list做严格检查评审。

3、对于引起回退的原因做深入分析，总结经验教训。

配置版本号：
1）处于“草稿”状态的配置项的版本号格式为0.XY，XY为01~99范围的数字；
2）处于“正式”状态的配置项的版本号格式为X.Y，X为主版本号，取值范围为1~9，Y为次版本号，取值范围为0至9；第一次为”正式“文件时，版本号为1.0；
3）处于“修改“状态的配置项的版本号格式为X.YZ，修改时，一般只增大Z值。

参考：
[1].《油田采油生产业务建模之业务用例实践（EA使用入门）》 CSDN博客 肖永威 2017.11
[2].《谈谈需求分析规范化》
CSDN博客 肖永威 2017.01
[3].《软件项目量化管理（CMMI高成熟度）实践经验谈——之项目管理过程策划篇》 CSDN博客 肖永威 2014.05