Requirement Change

Change Control Process

Requirement Change 需求变更

1）首先定义需求，大多数指定就是内容基准（合同、原型），版本 【Version 1】，定义变更规范

2）参考原型【Version 1】，哪怕修改一个符号，图标，相当就是变更，只是需要判断是否影响成本。

a.减少需求，合同价格不变，这种是对于乙方来说是最佳；

b.未开发的需求即还没做，是不是增加工作量，还是减少了；

c.开发中、开发完成的需求变更，需求改造，需求优化这类几乎就是工作量增加，增加成本；除非a类，突然不要了，不需要追加；

d.以上都是合同范围内，不在合同范围，新增需求，提高成本，理论需要追加成本；

3）为什么研发无脑根据客户要求，而不帮忙优化，实际工作的复杂业务模式决定的。有时候你按照以往开发惯例为了 1 + 1 = 2，非常简单，但是实际清空是客户的业务要求 1 + 1 = 3，这就是为什么研发的没有法子根据所谓经验来给你优化，唯一就是审查或者开发过程发现问题可能会反馈，同时这个过程很废时间以及开发时间，越是工作经验丰富的人越是只按照原型，需求，设计来。

4）为什么研发到后期会向客户或者甲方提出工作量超标预警，前面不排除为了“讨好”甲方，在项目管理中本来就是不可取的，包含加班、赶工等等行为，实际工作量超标。

5）为什么甲方没有按照变更规范，乙方继续执行，乙方在1）规范约束，甲方没有提出异议即认可。实际执行过程，很多甲方根本不按照规范或者也没规范执行需求确认流程。

6）为什么甲方总觉得工作量不多，主要原因根据过往经验，当然不排除有些个人能力出众甲方

记录在案==举个例子==改造总体软件架构、UI样式、布局==移植异构系统==

kkview 2024（2）

kkview 2024