以下内容，来源于我产品工作中的思考，可能和你在别处看到的不太一样，希望你能赏脸一读！
01
项目开发，简单来说，包含3个步骤：设计、执行、验收。
围绕这3个步骤，我们一般会有2个朴素的愿望。
1、设计时，要考虑周全，安排妥帖。执行时，要按照要求开发，按时按质按量落实。验收时，要遍历用例，把好关。
2、设计完成了，需求确认无误了，不会再改了，再提交执行。执行完成了，按照要求全部落实了，自测没有问题了，再提交验收。
但是，愿望仅仅只是愿望，现实往往是另外一回事。
比如说，“敏捷开发”，大家说得很多了。它的思想，大家也都基本认同。
但是，现实中，能真正按照“敏捷开发”的要求去实施的团队，却非常少见。
不同的项目开发理论，虽然内容大不相同，但都包含了一种“分割”的思想。
“设计”确认无误了，再执行。开始“执行”了，就不能再随意修改设计了。
然而，在小厂的实践中，情况往往不是这样。
比较常见的情况是，“设计”环节不受限制地往后延伸。
“执行”时，还在完善“设计”。甚至“验收”时，都还在修改“设计”。
在需求还是暧昧不清的时候，产品经理可能就需要设计方案，然后不得不着急着开始执行。
在执行过程中，需求的内容可能才开始明朗。
甚至要到项目上线时，需求才算是“暂时”明确了。
这就导致，一个项目，在开发过程中，产品经理可能需要再补3、4个需求单，再发5、6个工作邮件，频繁地进行方案调整。
02
有时候，技术同事会非常崩溃地对我说：“你们这次可得确定好啊！这次改完，咱们能不能别再改了？”
对此，我也只能表示无能为力。因为这不是产品经理所能控制的。
为什么我们不能将“设计”和“执行”进行分割，合理地安排项目开发？
相关的分析和吐槽，已经很多了，我就不再赘述。
这里我想强调的是，某种意义上讲，这和初级产品经理没有什么关系。
为什么呢？
1、能够合理安排项目开发节奏的，只有少数有实力的大厂。大部分公司，或多或少都有些混乱。
2、如果公司想要改善这种情况，肯定需要领导来统筹。初级产品经理没有能力，也没有权力，去处理这样的问题。
3、哪怕之后情况会逐步改善，也不可能说，我们先停下来，等情况变好了再开始推进项目。
如果有得选，那肯定是优先选择那些协作机制更合理的公司，没必要给自己添堵。
但是，如果没得选，那我建议，还是尽快“接受现实”为好。
我们当下，就是需要在这么一种混乱、不合理的机制下，开展我们的工作。
这是一个客观存在的现实。
网上有很多相关的讨论。比如说，国外先进的开发理念是怎样的，如何重新打造公司的协作机制，要怎么进行组织变革，等等。
我觉得，至少对于初级产品经理来说，这些都是空谈，没有多少价值。
03
作为一名初级产品经理，我们可能会经常碰到需求变更的情况。
我认为，不管变更的原因是什么，作为一线的“执行者”，初级产品经理在接到变更需求时，首先要关心的是“如何将之尽快落实”。
那么，面对需求变更，初级产品经理应该如何处理呢？
这里谈谈我个人的一些看法。
一、过去的事情就让它过去，不要扯皮，不要推诿。
需求要变更，某种程度上讲，意味着之前的做法存在“错误”。
出于自卫心理，我们本能地会想要把锅推出去：“之前是谁谁谁这么说的，怎么又要改了！？”
我认为，这是没有意义的，而且会显得自己很没有担当。
当前最重要的是，明确需求是否确定要改，以及具体要怎么改。
任何一句推诿，都是在浪费时间。
哪怕之后有人需要为错误负责，哪怕那个人就是我自己，那也是之后的事情。
二、快速回忆起，原来这么设计，是基于什么样的场景、出于什么样的原因。
我们策划时，虽不敢说“算无遗策”，但大部分的情况，都还是有考虑到的。
备选项被舍弃，是出于什么原因？
采用这个设计，是基于什么考虑？
这些，我们需要快速回忆起来。
一方面，如果领导问到了，我们能有个交代。
“我之前这样设计，是有一定考量的，不是乱搞的。”
不该背的锅，我们不要随便乱背。
另一方面，这也有利于我们重新对需求进行评估。
原来是基于这样的考虑做出的设计，现在要进行变更。
那么，是原来的逻辑有问题？还是现在的情况变了？
这些，都需要通盘考虑。
三、确保自己理解新的需求内容，最好再三确认。
需求方在说明新的需求内容时，要确保自己确实理解了对方的意思。
如果没听明白，直接表示不明白，让对方复述一遍。
切忌囫囵吞枣、一知半解。
同时，要结合原先的需求设计，以及当前的开发情况，对有问题的地方一一确认。
最后，自己把需求复述一遍，确保没有理解错误。
如果有需要另外确认的事项，一一列举出来，标出相应的负责人，要落实到具体的个人。
需求变更，是一个很容易造成混乱的事情。我们要非常谨慎，不能慌乱。
四、做好需求管理，安排好开发节奏。
需求变更，有时候可能同时会有好几个变更点。
这时候，需要产品经理结合需求的优先级，以及当前的开发情况，合理安排。
比如说，需求方希望替换支付方式。而当前的情况是，正在使用的这个支付方式存在一点问题，正在处理。
表面上看，正好！原来的支付方式都不用改了，直接上新支付方式就行了。
其实不然。
如果直接上新支付方式，那就得等新的支付方式完全弄好了，才能重新上线。等待的时间比较长。
如果我们先把原来的支付方式快速改好，恢复上线。那么在开发新支付方式的时候，就能暂时先用着原来的支付，不至于长时间下架。
需要注意的是，改完一个需求点，要改下一个需求点时，最好重新与需求方确认。
因为很有可能，这个时候，情况又有了新变化。
五、制定解决方案时，需要与技术团队共同协商。
因为项目已经开发了一半，有些东西可能已经做了，不好改了。
这个时候，要满足新需求，哪些方案能做，哪些方案调整起来成本低一些，只有负责的程序员才清楚。
所以，需求变更的时候，产品经理尤其需要听取技术团队的声音。制定解决方案时，需要与技术团队共同协商。
六、需求变更所需要的时间成本，需要与需求方和领导说明清楚。
改需求，其实没什么。毕竟大家就是来上班干活的嘛。
怕的是，既要改需求，又不能多给点时间。这就有些强人所难了。
产品经理向需求方和领导说明解决方案时，需要清楚说明该方案所需要的时间成本。
让领导知悉，可能需要花费比预想中更多的时间，或者可能会占用其他项目的开发资源。
至于领导能不能多给点时间，那就是领导的事情了。
七、每个需求点的紧急程度，需要清楚告知给团队各成员。
产品经理需要清楚告知团队各成员，需求方和领导的意思是如何。
这个项目里面，哪些需求点是必须在某个时间节点内完成的，哪些可以适当延后。
如果某处碰到困难，无法解决，要及时切换到Plan B。
当前有几个项目，如果撞在一起，先做哪个，后做哪个。
简单说“需求很紧急”，是没有意义的。
因为每个项目都是紧急的。
八、后续的全部沟通，尽量在大群里面进行。
有些人喜欢建小群，有问题在小群里面私下沟通解决。
我觉得这样不对。
我觉得，建群，就要建大群，把相关领导都拉进来的那种。当然，涉及的所有人员，都要在里面。
所有沟通，都在大群里面进行。
这样才能确保，所有人都能知悉当前的所有情况，降低沟通成本，避免遗漏。
04
我觉得，某种意义上讲，“需求变更”，尤其是“紧急的需求变更”，是对初级产品经理的一次突击考试。
因为它需要初级产品经理，在非常短的时候内，在非常混乱的情况下，快速把握现状，迅速制定方案，并马上落实推进。
它是一场综合性的考试，需要严肃对待。
