需求变更种类及控制策略

需求变更种类

承接上一篇文章，在项目中我们经常会讨论到需求变更。同时我们又会用到其他的术语，例如缺陷、优化、新增需求等等。能否有一个好的标准去判断，分类这些变更呢？下面，我尝试进行分析分类。
首先，我们从变更请求的定义去观察一下需求变更。

A change request is a formal proposal to modify any document, deliverable, or baseline.
变更请求是关于修改任何文件、可交付成果或基准的正式提议。

从上面的定义我们可以了解到，所谓的变更是相对于基线的。因此，需求变更也就是任何对于需求基线的变更。而由于软件开发的特殊性，我们可以从需求基线，交付成果，用户期望3个方面去对变更做分类。

需求基线Baseline/设计Design	交付Delivery/实现Implementation	用户期望Expectation	分类Category
A	A-	A	缺陷Bug/Defect
A	A	A+	优化需求Enhancement
-	-	A	新增需求New Requirement
A	A	B	需求变更Change Requirement

在实际情况中，我们可能会遇到更复杂的情况，但都可以从以上3方面去比较分类。尤其当涉及到项目范围的时候，一个明确的标准尤其重要。

需求变更控制策略

需求变更总是越少越好的，控制需求变更我们可以从那几方面入手呢？借用极客时间“软件工程之美”宝玉老师的总结，可以归纳为从以下三个方面入手。

1. 降低需求的不确定性。增加需求分析的投入。如配备专业的经验丰富的BA或产品经理。与用户有更多的沟通场合和时间。更早的发现变更，更小的需求，更短的迭代，更频繁的用户确认。
2. 提高需求变更的成本。制定需求变更流程。需求变更需要重新估算工作量。
3. 降低响应变更的成本。更好的架构，更好的工具，UAT环境。

以上三个方法根据项目具体情况灵活配合使用。