以下内容，来源于我产品工作中的思考，可能和你在别处看到的不太一样，希望你能赏脸一读！

01

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

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

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

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

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

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

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

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

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

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

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

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

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

在执行过程中，需求的内容可能才开始明朗。cpa之家app推广

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

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

02

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

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

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

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

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

为什么呢？

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

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

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

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

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

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

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

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

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

03

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

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

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

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

一、过去的事情就让它过去，不要扯皮，不要推诿。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

这些，都需要通盘考虑。

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

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

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

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

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

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

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

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

四、做好需求管理，安排好开发节奏。

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

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

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

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

其实不然。

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

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

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

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

五、制定解决方案时，需要与技术团队共同协商。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

八、后续的全部沟通，尽量在大群里面进行。

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

我觉得这样不对。

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

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

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

04

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

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

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