产品经理需求变更我太难了

　　产品经理在项目进行过程中，常常会面临一个重大考验：改需求！这也是产品经理经常被攻击的地方。为什么要改？怎么改？如何处理更改之后产生的新问题？这些都是摆在产品经理面前的一道道难题，本文作者就这些难题分享了自己的看法，供大家参考。
　　在互联网公司，产品经理改需求的梗，流传范围，可能仅次于程序员的秃头梗吧，经常会被各种表情包花式调侃。那么产品经理，真的有那么爱改需求吗？产品经理自己是怎么看待需求的修改的呢？
　　老实说，产品经理面对需求的修改，也是很痛苦的。方案调整、人员协调、资源争取、时间把控、各方同步，可能都要重新梳理，重新评估，甚至从头来过。谁喜欢麻烦呢？谁都不喜欢。但是作为产品经理必须正视和直面这样的麻烦，并且站出来牵头处理麻烦。
　　那今天我们就来仔细看下，需求更改产生的原因、影响和产品经理的处理方式。
　　一、需求更改通常会有哪些原因？
　　1。老板的要求
　　老板类型有很多种，各种老板可能都有各种修改需求的理由：体验了产品，觉得产品不够好；看了一本书，领悟了某种不得而知的天地奥妙；看了竞品，觉得这样搞也挺不错；身居高处，眼光长远，已经发现目前产品在以后可能遇到的问题。
　　产品经理可以据理力争，也可以巧妙周旋。但是话语权十分不对等的情况下，大部分最后的结果是：老板说的是，该改就得改。毕竟钱得领，饭得恰。
　　2。目前的方案遭遇瓶颈
　　这种瓶颈，有可能是技术上的，有可能是资源上的。毕竟产品评估会上，不能预见全部的问题和困难。
　　我们努力将需求的颗粒拆小，但是可能遗漏了颗粒，也可能是颗粒最后组装出现了问题，总会出现需求不改，进行不下去的情况。资源上，比如人员突然的调整和变动，有些需求可能做不完，那可能就会砍掉或者微调了。
　　3。目标的变化
　　公司内部组织结构调整或者经营方向的调整，都会影响我们的目标。目标一旦调整，产品难免也会调整。
　　4。市场的变化
　　市场千变万化，比如行业中的竞品突然出现了令人惊叹的创意，必须紧跟。网易歌单出现之后，试问有几个音乐平台没有跟进呢，有些时候打下时间战，就能分得一杯羹。
　　5。更好的处理方式
　　如果有更好的方案，给用户带来更好的体验。仔细评估之后，值得一试。
　　6。产品经理自身的问题
　　这是不可避免的，产品经理自身问题，导致需求修改；或者需求时间不够哦，没有想清楚；或者水平有限，纠结一些有的没的；或者思虑不周，没有考虑长远；或者像老板一样，看了某本书某个产品，忽然出现某个顿悟。
　　二、需求更改会产生什么样的影响？
　　1。各方人员的抗拒
　　我之前就说过，这其实是个很大的麻烦，而且是个系统性的麻烦，需求的更改，设计、产品、开发、运营、市场、销售可能都会受到或多或少的影响。
　　原本按部就班可以按时完成，而由于需求的修改，时间、资源变得不太可控，这是很多人员很抗拒的。
　　2。工期延长
　　面临着三难的选择，要么推迟上线时间，要么人员加班加点，要么增加人手。
　　上线时间不是某一个人就能决定的，推迟上线时间，面临上级责难和全方位再次协调。人员加班加点，面临同事埋怨。增加人手，资源都是一定的，不是相加就能加。
　　3。士气低落
　　有名言：一而再，再而三，三而竭。一鼓作气，士气很足，要是中间受到影响，士气低落就很难了。
　　4。重新开始
　　很可能会面临重新开始的情况，之前克服的困难会再来一次，之前的工作全部白做，可能会再做一次。
　　比如原先定好的万圣节上线，配合上线，设计师做了很多万圣节相关的物料，开发也埋了一些万圣节的彩蛋。一旦推迟，那么这些物料都会全部重新做，这些彩蛋也没有意义。
　　而产品经理之前协调过来的人员，也可能受到原来小组的召唤，不得不离开，这很可能意味着重新开始。
　　5。产品经理影响力降低
　　产品经理实际上只是个协调人员，并没有什么职权，很多时候都是靠着自己的影响力组织协调。
　　需求的更改，特别是因为产品经理自身原因的更改，某种程度上是从影响力账户取钱。当钱取完，应该也是卷铺盖走人的下场了。
　　6。对产品系统的影响
　　可能你觉得现在想到的这个方案是绝佳的方案，但是放到整个产品系统，会不会对别的地方产生影响呢？比如登录方式由原来的账号密码，修改为第三方登录和手机绑定。现有的账号系统和之后的账号系统会不会产生冲突呢？
　　三、既然影响挺大，该不该改？
　　这就涉及到对产品需求的评估了。通过上面的需求变更的原因，我们可以看到需求的变更，不能说好还是坏，是一件比较中性的事情。为了跟随市场或者提升用户体验，或者其他不得不改的理由，值得改就必须改。这些涉及到我们对更改的一个全方位评估。
　　1。更改是否合理
　　很多更改都是看似合理，其实不太合理的。自己要全方位多想想，慎重出口。没有完美无缺的方案，决策都是在不停的修补和权衡中进行的。所以如果不是特别明显的优势，还不如不改。
　　2。更改的重要和紧急程度
　　如果是合理，那么重不重要呢？紧急不紧急呢？重要且紧急，那就改。不紧急的可以放到下个版本迭代。
　　3。影响范围
　　评估下这个更改的影响范围：产品的影响范围，人员的影响范围。最好还是不要自己闷头想，可以组织会议，问问大家的意见。
　　4。影响时间
　　评估下更改会影响多少人的多少工期，会推迟多久的上线时间。
　　5。评估方案的复杂程度
　　如果方案实在复杂的话，有必要进行方案的拆解。优先做其中最有必要的一部分。
　　6。评估现有资源是否能够支撑
　　如果不能支撑的话，那需要多少的预算。这样评估下来，就知道这个方案值不值改了。
　　四、如果决定要改了，怎么处理？
　　1。心态调整
　　首先一定要慎重。无论更改需求大还是小，本质上都是给别人增添麻烦。所以对更改的地方，要慎之又慎，不得不改，就得好好把方案想清楚，想透彻。
　　其次，一定不要惧怕。既然有不得不改的理由，就要有直面的勇气，当断即断，及时快速的反应。
　　2。向领导汇报
　　如果有的调整大，涉及到人员、工期、上线日期、其他部门、其他资源的协调的话，一定先把自己的方案、调整的原因、影响的范围、希望得到的支持和预算，都和领导汇报沟通清楚，争取到领导的支持。
　　3。人员的同步
　　方案涉及到哪些人员，就得找到这些人员，先底下沟通一下，说明修改的原因和要调整的方案，了解下进度和困难，探探大家的抗拒程度，适当做一下安抚工作。
　　然后在把所有人员召集起来，大家同步下原因、方案、时间节点、里程碑。
　　4。情绪安抚
　　如果出现了一些情绪特别不好的，应该特别注意，特别的抽出时间，了解抗拒的点，帮助排解。试着用共同目标来说服和影响别人。
　　情不得已的情况下，把锅都推到老板身上，一起跟着吐槽吐槽老板吧。
　　5。文档的同步
　　这些修改，必须落实到大家共读的文档上，比如说邮件或者需求文档，写清楚修改的地方，达成文字共识。
　　口头共识，大家的理解各异。所以得保证统一的出口，文档同步是一种方式。
　　小结
　　1。老板的支持是特别重要的
　　领导老板的话语权和我们是不一样的，他们说一句，很多事情就能顺理成章的办下来。所以我们无论是产品立项还是需求的修改，首先要得到老板的支持，要先和老板沟通好。
　　不过就像我之前说到的，很多时候需求和需求的修改，其实是自上而下的，是老板自己已经决定了的；但是我们依然要做好和老板的沟通，信息要及时同步。不然后面达不到老板的期望或者完全不符合老板的期望，那就很尴尬了。
　　2。产品经理应该加强自身学习，提升自身能力
　　产品经理最重要的能力是解决问题的能力。而这种能力的培养和提升，离不开不断的学习。学习市场，观察竞品，了解变化的原因和其中的机制，而不是想当然看到表面UI和交互的皮毛。
　　解决问题的这种能力是很系统的，也就是说这样的能力需要我们掌握更加系统的知识，什么都要了解一些，有的可以更加深入一些。所以抓紧时间，多看多学多了解，和别人多交流，自己多总结，非常的有必要。
　　3。不是我的产品，而是我们的产品
　　产品经理不要张口就说我的产品怎么样怎么样，而是要学会说我们的产品。
　　产品是所有人的心血，产品经理要带头营造这样产品是我们的。这样修改的时候，不会有帮你修改这样的情绪，而是做好我们的产品的意识。
　　4。明确产品经理的角色
　　产品经理的角色，更多的时候是协调和解决问题。我们要明白最终的目的是什么，其中产生的困难都要努力的克服。
　　问题的锅被甩来甩去时，产品经理要接下锅，明确问题产生原因，去推动问题的解决，而不是干等干着急，一定要去协调去推动去解决。