变更类型
| 阶段 | 商务 | 产品设计 | 技术 | 客户 |
|---|---|---|---|---|
| 签单阶段 | <a href="#1.1.1"> 1.1.1 客户对产品的预算及评估不足导致分期</a> | <a href="#1.3.1"> 1.3.1 不能满足某些功能开发 </a> | 1.4.1 对项目交付方式、交付时间等要求存在风险 | |
| 设计阶段 | 2.2.1 产品设计在需求确认时，发现与需求概要相悖 | 2.3.1 客户因设计图的出现提出: <ul><li>A 改动部分需求 </li> <li>新增需求</li><li>删减需求</li> | ||
| 研发阶段 | 3.3.1 开发过程中遇到未考虑到并且未言明的逻辑 | 3.4.1 因某某些原因提出暂停或中止 | ||
| 交付阶段 | 4.2.1 对交付文档的要求超出合同约定 | 4.3.1 提出非需求文档内的要求：<ul><li>A 功能增加 </li><li>B 内容完善</li><li>功能删减</li></ul> | ||
| 售后阶段 | 5.3.1 因第三方服务变更而必须做出修改 | 5.4.1 功能删减二次开发 |
处理流程
1.1.1
graph TB
A(商务提出建议)
B{客户判断}
C(分期评估)
D((取消合同))
E(签定合同)
F((知会产品为分期开发))
G((知会技术为分期开发))
A-->B
B--同意-->C
B-->D
C-->E
E-->F
E-->G
1.3.1
graph LR
A(评估方案)
B(自学)
C(招聘)
D(外包)
E(替换方案)
A--在时间及人力承受范围内-->B
A--确定此类技术将会在更多项目中有需求-->C
A--外包成本低 单次项目 -->D
A--有其他成熟方案可实现客户需求-->E
避免情况
第一： 范围蔓延
合同签订后，客户不断加功能，乙方不断退让，导致项目的功能越来越多，十分繁复
第二：“四不像”
甲方不断修改需求，修改界面，乙方不断退让，最后导致整个项目烂尾楼。
第三：项目镀金
乙方为了迎合甲方，主动添加一些项目计划外的功能。或者对软件做一些无关痛痒的美化。
第四：“东拼西凑”
乙方为了缩短工期，满足甲方表面需求，强行植入其他成型系统，导致系统出现更多不可预见风险，为排查问题付出高昂成本
