实战解法：如何做好需求变更？

如何制定一份缜密的项目计划可能并不是项目中最难的事情，要应对计划之外的情况，才是最令大家头痛的地方。在项目实际推进过程中，不加控制的需求变更往往给项目带来沉重的负担和无法预料的风险。因此，设计一套合适的需求变更管理流程和规范，对项目和项目经理而言都是不可或缺的。

问题分析

首先对笔者所在项目做一个简单介绍：产品层面，我们是一个C端产品，需求主要来源于运营和策划，就产品阶段而言正处于转型期，现阶段主要以新功能探索为主；项目层面，由于功能较为复杂庞大，可切割空间不大，因此每个版本周期都较长（每个版本的产品准备周期，研发周期分别都在15～20个工作日左右），从产品设计到研发并上线的主干流程是具备的，如下：

笔者定义需求变更包含两个层面，一是在产品设计阶段：需求评审结束，PRD文档定稿后再对需求稿进行更改，定义为需求变更；二是研发排期结束，定稿开发测试上线计划，之后凡是计划外的变化都定义为需求变更。

一开始项目上并没有对需求变更的流程规范做清晰的定义，因此项目实际推进过程中会出现诸多由变更引发的问题，下面结合实际问题做逐一说明：

问题一：变更多：一开始，项目最大的问题是需求变更很多，如果只是猛的一头扎进流程中去，反而浪费时间，所以我们尝试去分析这些变更的原因，看看是否能在源头堵住变更。经过判断，发现相当一部分变更是因为需求设计不够健壮或者交互对需求的理解不到位，在后续的阶段发现，进而才开始修改或新增需求。

问题二：变更不规范：变更是在所难免的问题，大家坐下来聊一聊，如果感觉不错那就把这个变更做了吧，这是我们之前的做法。但，由于缺乏一个明确的基本流程规范，一到变更的时候，处理事情往往丢三落四，进而会出现以下问题：

变更需求提出人太多，不知道听谁的变更提出的太晚，留给项目的时间不多了变更到底做不做，什么时候做等信息，在各个角色间的信息不同步

问题三：问题带来风险：项目过多关注于讨论变更本身以及变更的意义，往往忽略了实施变更往往会冲击原有计划，缺乏完整的风险分析；在变更执行的时候，没有相对固定的套路和章法，执行过程很松散，缺乏一些有效的监控，过程风险演变不得而知。

解决方案

我们在给出解法的同时还需注意到，项目管理所依赖的流程和规范若太强则使项目运转繁琐低效；但过弱则又使项目松弛散漫。因此，设计对应办法的时候需要充分考虑各种方案，选取最简单的方式来实现规范管理。

针对问题一，我们决定优化原有的主干流程，增加一个承上启下的环节做需求确认；针对问题二和问题三，我们规范了变更如何审批，变更如何执行两个过程；建立方式监控项目对变更工作量的承受情况。

主干流程优化

项目上根据实践经验发现仅靠需求评审无法完全保证需求方清楚的澄清所有需求，以及交互方充分的理解需求方的要求，其本质原因在于PRD并不能完整的描述清楚整个场景，许多需求层面的细节和串联即便在需求评审结束后依然可能覆盖不全；只有随着交互设计师把需求完善成结构严谨的逻辑图和场景说明，往往才会发现一开始需求设计不到位的情况，在大版本的情况下，等到整个交互稿都拿出来了再去做变更，变更代价过大/感受也不好。

因此，对于较为复杂的设计，在交互评审之前会拆分一个环节出来，做一个交互主场景的评审。通过新增的环节，确保需求的健全和完善，减少流入后续阶段的需求变更数量。

这个做法适用于策划变更PRD频繁，以及功能过于复杂伴随较大的潜在变更风险两个场景。PRD频繁变更频繁并不完全因为功能逻辑设计有漏洞，还有可能是产品规划/商业分析论证等前置流程没做好，这种背景下光是增加一个主场景的评审是没用的，读者需要仔细分析。

这样一个交互主场景的评审，具体操作建议如下：

时点：这个环节安排在需求评审结束后，交互评审开始前，且建议在需求评审后尽快安排，大概2个工作日内安排；内容：交互理解策划PRD说明后，初步制作交互稿，粒度达到覆盖主要的场景及完整的逻辑流程，然后召开主场景评审会与策划/需求方进行确认，确保需求理解正确和需求的健全。参与人：需求提出方（如运营，市场等），策划，交互变更规范明确

变更流程的规范涵盖两个主要方面，一是明确变更管理的基本理念；二是明确一旦要做变更，需要依序执行的步骤。

管理变更的理念>>

变更管理的核心在于评估需求变更的价值，然后决定做不做以及是否在当前版本做，我们尝试从更多角度去思考，包括说产品的规划，需求的特点。

首先分析产品阶段特点：我们处在产品转型这样一个新旧交叉时期（简单说就是一方面要维护原有功能，另一方面更需探索设计新的功能），因此这个时期的需求变更可以划分成四个维度：原有核心功能，原有周边功能，新功能核心功能，新功能周边功能；变更也按上述维度进行分类，再考虑版本上线时间和质量，按照以下顺序去考虑需求变更（笔者假设质量是恒定的，范围和进度是变量，所以对范围和进度进行优先级排序）：新功能核心功能变更>原有核心功能变更>版本上线时间>新功能周边功能变更>原有周边功能变更。

同时，十分不建议因为紧急需求变更去延迟既定的上线时间，对于项目而言，上线时间是一个很严肃的事情，不能轻易的去改变，是大家共同守护的目标。因此，我们定义需求变更冻结时点，原则上在冻结点后不接受任何变更。关于需求冻结点如何设置，不同的项目需要根据实际情况做分析，比如我们的做法是：产品阶段的冻结时点是交互场景评审结束后两天内；研发阶段的冻结时点是提测点前两天左右（设置的原则就是做版本计划的时候，开发在估算提测时间同时确认showcase时点作为冻结点，而这个时间一般就是提测点前两天左右）。而实际上对这两个冻结点，我们会侧重于对后一个冻结点的管理。

在应对变更的整体思路上，除了以上的实践经验总结而来的基本思路，还建议有条件的项目尽量尝试固定时间研发迭代时间，周期上如果能达到两周一迭代是最理想的。我们也尝试一周一迭代，这时候在应对需求变更的时候明显更加从容，但适用场景有限，细碎的优化需求是周迭代处理的重点。

执行变更的步骤>>

编辑：未知