作为一个初级产品经理，经常会遇到需求变更的情况，新手这个时候往往就会很崩溃。本文作者基于自己的工作经验，提出了一点思考，希望对你有帮助。

01

项目开发，简单来说，包含3个步骤：设计、执行、验收。

围绕这3个步骤，我们一般会有2个朴素的愿望：

设计时，要考虑周全，安排妥帖。执行时，要按照要求开发，按时按质按量落实。验收时，要遍历用例，把好关。

设计完成了，需求确认无误了，不会再改了，再提交执行。执行完成了，按照要求全部落实了，自测没有问题了，再提交验收。

但是，愿望仅仅只是愿望，现实往往是另外一回事。

比如说，“敏捷开发”，大家说得很多了。它的思想，大家也都基本认同。

但是，现实中，能真正按照“敏捷开发”的要求去实施的团队，却非常少见。

不同的项目开发理论，虽然内容大不相同，但都包含了一种“分割”的思想。

“设计”确认无误了，再执行。开始“执行”了，就不能再随意修改设计了。

然而，在小厂的实践中，情况往往不是这样。

比较常见的情况是，“设计”环节不受限制地往后延伸。

“执行”时，还在完善“设计”。甚至“验收”时，都还在修改“设计”。

在需求还是暧昧不清的时候，产品经理可能就需要设计方案，然后不得不着急着开始执行。

在执行过程中，需求的内容可能才开始明朗。

甚至要到项目上线时，需求才算是“暂时”明确了。

这就导致，一个项目，在开发过程中，产品经理可能需要再补3、4个需求单，再发5、6个工作邮件，频繁地进行方案调整。

02

有时候，技术同事会非常崩溃地对我说：“你们这次可得确定好啊！这次改完，咱们能不能别再改了？”

对此，我也只能表示无能为力。因为这不是产品经理所能控制的。

为什么我们不能将“设计”和“执行”进行分割，合理地安排项目开发？

相关的分析和吐槽，已经很多了，我就不再赘述。

这里我想强调的是，某种意义上讲，这和初级产品经理没有什么关系。

为什么呢？

能够合理安排项目开发节奏的，只有少数有实力的大厂。大部分公司，或多或少都有些混乱。

如果公司想要改善这种情况，肯定需要领导来统筹。初级产品经理没有能力，也没有权力，去处理这样的问题。

哪怕之后情况会逐步改善，也不可能说，我们先停下来，等情况变好了再开始推进项目。

如果有得选，那肯定是优先选择那些协作机制更合理的公司，没必要给自己添堵。

但是，如果没得选，那我建议，还是尽快“接受现实”为好。

我们当下，就是需要在这么一种混乱、不合理的机制下，开展我们的工作。

这是一个客观存在的现实。

网上有很多相关的讨论。比如说，国外先进的开发理念是怎样的，如何重新打造公司的协作机制，要怎么进行组织变革，等等。

我觉得，至少对于初级产品经理来说，这些都是空谈，没有多少价值。

03

作为一名初级产品经理，我们可能会经常碰到需求变更的情况。

我认为，不管变更的原因是什么，作为一线的“执行者”，初级产品经理在接到变更需求时，首先要关心的是“如何将之尽快落实”。

那么，面对需求变更，初级产品经理应该如何处理呢？

这里谈谈我个人的一些看法。

1. 过去的事情就让它过去，不要扯皮，不要推诿

需求要变更，某种程度上讲，意味着之前的做法存在“错误”。

出于自卫心理，我们本能地会想要把锅推出去：“之前是谁谁谁这么说的，怎么又要改了？”

我认为，这是没有意义的，而且会显得自己很没有担当。

当前最重要的是，明确需求是否确定要改，以及具体要怎么改。

任何一句推诿，都是在浪费时间。

哪怕之后有人需要为错误负责，哪怕那个人就是我自己，那也是之后的事情。

2. 快速回忆起，原来这么设计，是基于什么样的场景、出于什么样的原因

我们策划时，虽不敢说“算无遗策”，但大部分的情况，都还是有考虑到的。

备选项被舍弃，是出于什么原因？

采用这个设计，是基于什么考虑？

这些，我们需要快速回忆起来。

一方面，如果领导问到了，我们能有个交代。

“我之前这样设计，是有一定考量的，不是乱搞的。”

不该背的锅，我们不要随便乱背。

另一方面，这也有利于我们重新对需求进行评估。

原来是基于这样的考虑做出的设计，现在要进行变更。

那么，是原来的逻辑有问题？还是现在的情况变了？

这些，都需要通盘考虑。

3. 确保自己理解新的需求内容，最好再三确认

需求方在说明新的需求内容时，要确保自己确实理解了对方的意思。

如果没听明白，直接表示不明白，让对方复述一遍。

切忌囫囵吞枣、一知半解。

同时，要结合原先的需求设计，以及当前的开发情况，对有问题的地方一一确认。

最后，自己把需求复述一遍，确保没有理解错误。

如果有需要另外确认的事项，一一列举出来，标出相应的负责人，要落实到具体的个人。

需求变更，是一个很容易造成混乱的事情。我们要非常谨慎，不能慌乱。

4. 做好需求管理，安排好开发节奏

需求变更，有时候可能同时会有好几个变更点。

这时候，需要产品经理结合需求的优先级，以及当前的开发情况，合理安排。

比如说，需求方希望替换支付方式。而当前的情况是，正在使用的这个支付方式存在一点问题，正在处理。

表面上看，正好！原来的支付方式都不用改了，直接上新支付方式就行了。

其实不然。

如果直接上新支付方式，那就得等新的支付方式完全弄好了，才能重新上线。等待的时间比较长。

如果我们先把原来的支付方式快速改好，恢复上线。那么在开发新支付方式的时候，就能暂时先用着原来的支付，不至于长时间下架。

需要注意的是，改完一个需求点，要改下一个需求点时，最好重新与需求方确认。

因为很有可能，这个时候，情况又有了新变化。

5. 制定解决方案时，需要与技术团队共同协商

因为项目已经开发了一半，有些东西可能已经做了，不好改了。

这个时候，要满足新需求，哪些方案能做，哪些方案调整起来成本低一些，只有负责的程序员才清楚。

所以，需求变更的时候，产品经理尤其需要听取技术团队的声音。制定解决方案时，需要与技术团队共同协商。

6. 需求变更所需要的时间成本，需要与需求方和领导说明清楚

改需求，其实没什么，毕竟大家就是来上班干活的嘛。

怕的是，既要改需求，又不能多给点时间，这就有些强人所难了。

产品经理向需求方和领导说明解决方案时，需要清楚说明该方案所需要的时间成本。

让领导知悉，可能需要花费比预想中更多的时间，或者可能会占用其他项目的开发资源。

至于领导能不能多给点时间，那就是领导的事情了。

7. 每个需求点的紧急程度，需要清楚告知给团队各成员

产品经理需要清楚告知团队各成员，需求方和领导的意思是如何。

这个项目里面，哪些需求点是必须在某个时间节点内完成的，哪些可以适当延后。

如果某处碰到困难，无法解决，要及时切换到Plan B。

当前有几个项目，如果撞在一起，先做哪个，后做哪个。

简单说“需求很紧急”，是没有意义的。

因为每个项目都是紧急的。

8. 后续的全部沟通，尽量在大群里面进行

有些人喜欢建小群，有问题在小群里面私下沟通解决。

我觉得这样不对。

我觉得，建群，就要建大群，把相关领导都拉进来的那种。当然，涉及的所有人员，都要在里面。

所有沟通，都在大群里面进行。

这样才能确保，所有人都能知悉当前的所有情况，降低沟通成本，避免遗漏。

04

我觉得，某种意义上讲，“需求变更”，尤其是“紧急的需求变更”，是对初级产品经理的一次突击考试。

因为它需要初级产品经理，在非常短的时候内，在非常混乱的情况下，快速把握现状，迅速制定方案，并马上落实推进。

它是一场综合性的考试，需要严肃对待。

作者：简明产品论，个人公众号：简明产品论（ID：JianMingPM）

本文由 @简明产品论 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议