文/PM十二
编辑/12
Hi各位周末愉快，正式进入的最后一个月了，而我还没去成环球影城，或许去环球影城看哈利波特的flag要顺延到年了??。
Anyway，本月思考如期而至，如果你对这个系列感兴趣的话，欢迎观看：
十月工作思考｜UED是个会画图的产品经理
9月工作思考｜像开饭馆一样经营自己
8月工作思考｜如何提高自己的执行力
7月工作思考｜截然不同的两个决策的背后
6月工作思考｜努力做一个靠谱的产品
5月工作思考｜产品经理不是个拉群机器
4月思考总结｜扫除一切不确定性
废话说完了，以下是正文～
1.需求变更一定是产品的锅嘛
这个月在跟进的项目陆陆续续都要进入验收阶段了，过程中又识别到了一些新的问题，于是不得不在需求进入开发后半程的时候提了几个需求变更，这一提变更不要紧，把我们开发大大给气坏了。（#程序员都讨厌需求变更系列）
从开发的视角，确实也能理解为什么他们这么讨厌需求变更。
1）需求变更意味着可能之前做的一部分工作被浪费，甚至整体设计的技术框架都得修改
2）变更无疑会带来工时的增加，为了项目如期上线，可能还得加班
人都讨厌不确定性，自此产品和开发信任崩塌，一边做需求一边担心现在做的后面还要被修改，只能绕着产品走，祈祷他/她不再提变更。
（自从提过一次变更后，开发大大belike??）
当时去提变更的时候开发大大挺生气的，我觉得确实是我不对，不应该这个时候提变更，都是我的错，自己没有及时识别到风险导致他们需要拥抱需求上的变化，特别内疚。
（这里写自己情绪日记的时候意识到一个问题就是，为什么别人一生气我就容易觉得是自己的错，这个话题后续在分析情绪的的时候再展开）
但是需求变更不得不提，既然已经识别到问题，不能不补救和解决。面对对方的情绪，只好一直道歉。但是回来的时候自己心里也有点委屈。
委屈的是，回来路上慢慢细品这件事的时候，觉得我也是为了这个项目能有更好的结果，为什么大家都认为是我的错呢？
是的，我又一次感受到了“委屈”。虽然之前已经分析过一次“在工作中受委屈怎么办”，自己洋洋洒洒写了一下午，觉得已经梳理得很明白了，还拿这个理论去安慰我们校招生妹妹，结果自己再次陷入受委屈困境。
看来，从理解到践行也还有很长的路要走。
冷静下来思考，提需求变更真的是产品的锅吗？
严谨来说，有一部分变更确实是，比如产品在需求初期没有充分调研，或者没有及时内部拉通识别风险，一些该前置的风险没有前置导致开发返工，这个确实是产品的问题，这种也没必要委屈，有错认错，是你的错大家有些情绪也是正常的。
而另外一部分变更是因为外部信息发生变化导致的，在写需求和串讲需求时这个信息变化谁也没办法提前预料到。
比如你是个笔记软件，准备联合在线教育app做个联合发布的活动，结果一夜之间，在线教育凉了，所以我们不得不调整所有的方案。这个就是不可抗力，方案该改就改，谁也没办法。
所以，结论是，需求变更不一定是产品的锅。但这个结论似乎根本不解决问题，因为开发都觉得是你的锅，你咋办？
（我们开发说，他已经有一抽屉产品写的保证书了，已经不信了??♀）
如果开发哥哥只是有点小情绪，并没有因此拒绝你的需求变更，那就凉拌。
首先从理智上我们能清楚的知道这到底是不是自己的问题。如果不是自己的问题，先不要急着委屈，要看的更长远一点，我们的核心目的是把事情做成和把事情做好，把需求推上线，带大家拿到结果。
发挥产品的共情能力，去理解一下开发gg们。
人家有点小情绪也可以理解，如果你的需求写完都串讲完了，突然被大老板提了个意见然后一大半都要重新来过，已经拉通的部分也都白拉通了，你不生气么？但是生完气理智下来，意识到人家的意见或者建议确实有道理的话，该改还是得改。
从我们的视角我们能理解变更分成两种，一种和我们有关，一种和我们无关，我们能做的只是尽量把能识别的识别清楚，但是我们没办法要求别人绝对理智，也能像你自己理解自己一样理解你的个中难处，毕竟别人的职责也不是分析你的工作内容和理解你。
有可能对于开发gg而言，本身已经为这个项目付出了很多心力了，结果这个节骨眼又被提了一个变更，又得加班加点，情绪一上来，根本听不进解释。
开发觉得是你的锅，其他道理他们也不肯认不肯听，那就当作是你的锅好了。
都那么多锅了不差这一口，如果一句“对对对，这个考虑不周确实是我的问题，后续一定多注意，尽量不在这个时候变更”就能解决问题，干嘛要battle那么久呢，多出来的时间多写俩需求不香吗～
对错真的没那么重要，作为产品要有的基本觉悟就是背锅侠，没人背的锅你来背，全世界只要你老板没误解你，为了项目如期进展背几口锅害得其他人有点误解，问题都不大。
但是如果他们情绪激烈，不肯在这个时候接受变更的话，就得想办法说服他们共同拥抱这变化了。
关于如何说服一个人，在上篇推送中其实介绍的很清楚了，可以参考运用之前提到的技巧。
提前预感到某位开发可能会有比较大的意见的话，先提前跟人家单独沟通，需求变更的时候和正式的需求评审一样，也要讲清楚变更的背景，为什么在这个时间节点提出这个变更内容，必要性和重要性有多大。
为了留足他们的缓冲时间，尽可能提前吹风，由于外部变化导致方案修改，可能会带来变更工作量的时候，提前找机会放出风去。
碰见他们的时候，先说一声，“我们这边内部识别到一个小风险，某一块的逻辑要进行微调，可能会提个小变更，先知会一声，具体改动项确认了我同步你”，这样人家心里有个准备，面对变更也不会那么突然和难以接受。
2.为什么给产品提需求不用排期
给开发哥哥们带来了工作量的增加我非常内疚的同时，不禁想到一个问题，其实我也算是变化的受害方呀，外部的信息发生变化，导致我的方案得连夜改正，然后第二天还要跪开发大大们，给他们提需求变更。
那我呢，谁来给我提变更呢，我的新增工作量谁能看见，有谁关心么？
于是开始YY，如果给产品提需求也要排期的话会是一个什么样的场景。
参与这次产品需求评审的有老板A，用户B和运营同学C。老板说，我们要优化流程提高登录注册的转化率，用户B说，我想要一个字更大的页面，需要一个字体设置的功能，运营同学说，我们近期要做运营活动，需要在主页的页面都制作几个入口。需求收集完毕之后，由产品leader整体收敛需求，评估产品这边的人力和优先级，然后砍掉部分需求。这个过程中，如果发现外部信息变化，比如在线教育突然凉了，那么和在线教育联合发布的活动需要暂停临时修改为和另一个读书app联合发布，老板通知你方案需要变更，你说“改方案可以，需要提变更，之前这个需求的调研?写prd只预估了4人天，现在需要+2人天，所以项目整体都会delay”这样yy一下貌似很爽，“变更可以，提需求，加人”，感觉自己也可以站在道德制高点选择做或者不做，但其实背后隐含很多问题。1??剥夺了产品经理的主动性在目前的整个流程中，产品经理本来是需求的发起方，研发测试是需求的执行方。大家围绕需求开展合作。在发起方前面再加一个发起方相当于剥夺了产品的主动性，人家不说就是没有需求。如果需要其他人给产品提需求产品才会开始调研和写需求的话，产品作为整个流程中最主动的人也变成了一个被动方，等待其他人来提需求。老板和运营好歹是内部人员，能接触到产品经理能给产品提需求，但是外部用户没办法直接参与需求评审和串讲，也不会手写字prd来告诉产品自己想要什么，那么产品经理本人就错失了很多识别真正有效的用户需求的机会。2??.失去了锻炼决策的机会如果由产品leader收集外部需求，然后统一评估需求合理性以及优先级再分发给各个产品同学的话，产品经理就从思考机器变成了执行机器。本身通过自己收集并调研各方需求，用同理心代入用户视角去思考用户在特定场景下遇到的问题和需要的解决方案的过程，变成了全部由产品leader思考好之后下发给个人。产品leader的工作量增大了，产品经理这个岗位本身的决策机会也被回收了。普通员工和管理层的差距被进一步拉大，leader需要同时处理和调研大量需求，普通员工没有做决策的机会，决策能力无法被锻炼。（whichmeans永远也没办法成为管理层，毕竟没有锻炼和试错机会）3??没有人为需求真正负责虽然用户或者运营或者任何一个人可以提需求，但是他们提需求大概率不是为了产品越做越好，而是为了自己用的更爽。所以提需求的人提来的需求未必合理。产品可能会评估需求的合理性决定接不接，就算接了，最后也不一定能上线，毕竟后面还有好几环。老板说做个登录注册流程，产品经理把方案出了然后去串讲，开发说目前人力紧张暂时做不了。于是产品经理告诉老板，我的活儿干完了，方案也出了，没人做，你自己想办法吧，老板，卒。用户说我需要一个锤子，你回复用户邮件说锤子的说明书已经写好了，但是我们现在没人做，你去催催我们开发吧。用户，卒。从提需求的人，老板、用户、运营，到写需求的人——产品，做需求的人——开发，保障需求质量的人——测试，大家都只