产品经理在项目进行过程中，常常会面临一个重大考验：改需求！这也是产品经理经常被攻击的地方。为什么要改？不同阶段的问题是什么？这些都是摆在产品经理面前的一道道难题，本文作者就这些难题分享了自己的看法，供大家参考。

产品从需求出发，经过了原型设计、开发排期到测试验收、灰度后上线的过程，可以说经过了较长的一段时间。根据需求的复杂程度，产品开发时间可能需要1天、1周甚至1个月的情况。在游戏行业，产品开发周期则更长，多达几个月。

我们可以把产品经理完成的PRD原型，作为需求的集合。UI设计、开发、测试等部门的同事会根据原型所呈现的效果进行落实。

可以说，产品经理把原型做出来并在评审通过后，就成为了一份“纲领性”文件。每个人都会围绕它为中心进行工作。

一旦涉及到需求原型的变更，往往是牵一发而动全身。例如：在原型评审后，增加了一个列表排序的工作。这部分的需求变更（增加）会造成怎样的后果呢？

• 首先：UI要根据功能进行重新设计UI图；
• 技术经理要评估该功能所要开发的时间、难度、成本、可行情况；
• 测试要根据原型进行测试用例的写作和测试的准备工作；
• 如果功能联动到其他业务情况，牵扯出来的情况就更多了。

毫不夸张的是，需求变更更像是一种“原罪”。

每次产品经理在进行需求变更后，往往开发同事是一脸懵逼的，表现出“一开始，我是拒绝的”的态度，除非你能说服利益相关方。

原型的变更往往不都是产品经理背的锅。虽然需求变更可能导致开发效率的落后、产品的延期、工作气氛的负面影响、团队和谐程度下降等等，这不意味着需求变更就是错误的。

有某些情况下，需求变更意味着产品通过接受市场环境变化的不确定性，所采取的有效措施，让产品跟得上市场的变化，这是一种“利”，而不是“害”。

一、需求变更的原因

明确了这点，我们再来讨论：需求变更是什么原因导致的？

需求变更的原因，主要有几个方面：

1. 产品经理原因
2. 开发或其他部门的原因
3. 公司的原因
4. 市场/用户的原因
5. 客观原因（或者不可抗拒原因）

下面逐一解释：

1. 产品经理原因

这部分的原因往往是因为产品经理本身想不清楚需求、定义不清楚需求，导致了需求在开发过程中出现许多问题。

例如：比如，笔者所做过的一个项目中，涉及到针对某些渠道的扫码关注情况的统计，需使用一个概念把所有相关渠道进行概括。当时我会把所有的相关的渠道都一一列出来。

如果我在产品原型里，对需求的定义模糊其词，仅定义为“把涉及到这部分的相关扫码渠道都进行统计”，但并不列举是哪些渠道。开发自然会懵逼。如果开发工程师把你的表述理解为了其中一个渠道，那么造成的后果是统计有缺漏，反应的数据情况自然是不准确的。

再举个反面例子：

例如：当用户购买了某电商产品并支付完成后跳转页面，弹出了二维码。用户扫码进入该电商平台公众号-点击关注，产品经理在用户关注后并不做任何的公众号弹出的提示操作。这就是定义不清晰、想不全面。

最后的结果就是：用户关注了你的公众号，但实际上最后一步的漏斗转化就缺失了，白白流失了这部分用户的进一步转化。

2. 开发或其他部门的原因

这里更偏向于开发部门，其他部门则指客服、运营、销售、财务等部门。开发部门导致的需求变更一般会比其他部门的多，但这块也要根据公司业务重点情况，不能一概而论。

产品制定了原型并进行了评审后，进入了开发阶段。有些情况下，需求的变更不是在评审时发现的问题，而是在开发时。

例如：不断数据表之间的多层嵌套、异步特征导致数据加载延迟等情况，这些在产品体验层面是致命伤。当然也不可能进行开发落实。

例如：某个数据页面加载的时间，按照原型的不同数据方案（同步或异步读取混合），导致用户能在页面上看到的时间为15s，虽然可以进行前端的提示，实际上会吓跑用户。我们在使用各种不同app，在等待页面过程中大概10s左右就会不会有不耐烦的表现呢？15s？20s呢？

因此，开发上能实现但造成产品体验的问题，也会导致需求的变更。上述案例中，变更后的需求，对异步的数据分开统计，并加强产品提示，弱化数据入口等方式，从而减少用户等待的期待。这样的变更就是可以接受的。

除了开发部门之外，诸如运营部在准备活动、临时通知、运营功能临时增加等情况下，就会造成需求变更。

测试部的变更情况，在笔者的实践看来，更多的是从测试难易程度的角度给出的产品优化建议。注意：测试本身是懂技术的，这部分的变更实际上如果测试能提供较好的方案，产品的需求变更也在考虑的范围了。

3. 财务部门的原因

这个笔者也跟财务打过交道，财务部门所提出的优化建议往往涉及到有效的对资金进行处理的效率，这部分也需要进行特别的考虑和评估。有时候你所做的优化往往是财务比价迫切的，对需求进行变更，其实带来的是财务、财务对客户等方面更高的效率。

由于财务并非专业于产品的设计，在开发成本和需求之间，产品经理仍然要做好需求的把控。

当然，还有其他情况，例如客服部门、新媒体部门等，这些都有可能会给产品提出一些优化建议，导致需求变更的情况。

4. 公司的原因

这可能是公司策略的改变，所以需要对产品进行修正、甚至重构的过程，也可能是上级领导根据其意愿所安排的需求变更。

总而言之，这往往意味着命令的特性。我们需要对此进行充分的了解和沟通。

5. 市场/用户的原因

例如：产品经理要针对某个社区功能进行排行榜的设计，用户要增加积分功能、要发放奖品、要每日的打卡行为特征…要知道，排行榜所能承载的功能非常多，不可能把所有的功能都进行设计。

而用户的建议则是根据其本身需求进行的判断，更有诱惑性。人是需求的集合体，而我们所做的产品是为了满足用户的需要一旦用户提出了这个需求，我们恨不得马上帮他们解决，满足了这部分用户的需求，就能满足了用户，提升满意度。这里也是产生需求变更的地方。

其他的：竞品、市场动态、政策趋势等方面，都有可能造成需求变更

6. 客观原因（或者不可抗拒原因）

这里往往是因为底层技术的限制、服务器、开发成本、资源限制等方面的原因导致需求变更（比如砍需求、对需求进行成本分析，找成本少的先实现）

以上列举的6个方面产品需求变更的原因，但是秉持这“ 先内因后外因”的处理角度，笔者建议在需求变更的原因产生时，要经常从内因、从自我本身的角度，对产生需求变更进行反思和分析。

二、产生需求变更的时间阶段

我们进行对需求变更的原因的分析，其实还可以从需求的不同时间阶段角度进行分析。

我把产生需求变更的时间阶段分为以下几个：

1. 产品规划阶段
2. 原型阶段
3. 评审阶段
4. 开发前阶段
5. 开发阶段（初期）
6. 开发阶段（中期）
7. 开发阶段（后期）
8. 测试阶段
9. 灰度阶段
10. 上线后

前2个时间阶段是由产品经理定夺，算不上需求的变更，但涉及到其他角色的参与，也算在内。

根据不同阶段所产生的需求变更，其应对的行动自然也会不同。产品经理要推动需求变更后的落实，往往由于开发、测试、UI或者利益相关方的反对而失败。

也就是说，如果需求变更是科学的、合理的，产品经理以解决问题为己任，因此，推动变更成为了产品经理所必须背负的一个“锅”。

如果需求变更后，产品经理如何进行推动和落实呢？这里有一份笔者总结的“需求变更落实难度”的模型，仅供参考。

需求变更落实难度模型

从图中可以看出，星级越少，则变更后的需求的落实难度越小，而星级越少的大部分是在产品还没有开始开发之前。

因此，产品经理如何把需求变更的可控范围缩小到开发前，自然会减少了需求的落实压力。

三、建议

事情往往不是我们所想象的那么顺畅。无论是在哪里阶段进行的需求变更，笔者有以下的一些建议：

1. 提升产品能力。要把产品想清楚，逻辑、产品设计、需求定义等能力；
2. 提升项目把控能力。把产品当做项目，那么，就需要你对项目进行有效的把控；
3. 提高眼界。充分吸收外界优秀的需求管理思想，提升对需求的处理能力、提高自己对产品的构造力，站得高才能看得远。在良好的产品架构下，会减少很多的无用功。

注意，我们要做的不是避免变更，而是科学的变更；把“原罪”减低到最小，充分理解并践行需求变更后的优势，提高需求变更后的落地能力。

需求变更是无止境的，但只有充分保存自我的”定力“，才能在工作中游刃有余，立于不败之地。

本文由 @阿艺师傅 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自 Unsplash，基于CC0协议。