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

01

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

02

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

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

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

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

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

为什么呢？

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

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

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

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

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

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

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

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

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

03

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

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

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

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