需求变动，产品经理的良心也会痛！

引言：在项目执行过程当中，产品经理与后续的合做团队，包括设计、开发、测试等相关人员最尖锐突出的矛盾，就是需求变动，这是产品经理最常常被诟病的地方。频繁的需求变动，对产品、项目进度和团队积极性都有很是大的危害。产品经理必定要竭尽全力避免需求变动的状况。
本文选自《爆款是怎样炼成的：产品经理晋级宝典》。

　　做为产品经理，咱们必定要理解开发团队及其余团队成员为何视需求变动为大敌。事实上，需求变动对整个项目都很是有害。

1. 需求有变动，就意味着设计、开发团队的工做有浪费。这首先是资源和时间的浪费。

2. 这会致使团队成员有抵触情绪，对产品经理及需求产生了不肯定感，产品经理的威信降低。严重的还会致使团队成员懈怠工做，由于谁知道何时这个需求还会变动？也许就不用作了呢？

3. 打乱版本进度，除影响发版时间以外，还会打乱团队的工做节奏。本来运转得很好的团队，若是频繁发生需求变动，很容易打乱项目节奏，令人无所适从，由于本来计划的时间点已经因为需求变动不可能按计划实现。

4. 临时发生需求变动，容易致使新的需求考虑得更加不周全，项目的风险、产品质量降低的风险都会加大，严重的还会致使产品偏离本来的产品定位或想法。

频繁的需求变动，对产品、项目进度和团队积极性都有很是大的危害。产品经理必定要竭尽全力避免需求变动的状况。下面来看看需求变动产生的主要矛盾以及如何应对。

（1）对需求考虑不周全。

　　好比产品经理小明设计用户注册流程，方案是用户须要填写手机号才能顺利注册。这个方案已经由设计人员给出效果图和切图，且进入了开发阶段。那么，在这个过程当中，小明从公司内部的其余同类产品中了解到，用户对手机号很是敏感，若是手机号是注册时的必填信息，则很容易形成在注册流程中用户的流失。因而，小明只好修改产品方案，将填写手机号一项改为选填，增长填写经常使用邮箱做为注册用户的惟一标识。这就是典型的在需求方案设计阶段，没有全面考量方案的例子。固然，这与小明的经验也有关系，通常新人不免在设计方案时对一些状况不够敏感，会有疏忽和考虑不全的状况。这须要产品经理高标准要求本身，从各类角度审视、考量本身的方案，尽全力考虑周全，那么就会在至关大的程度上避免需求变动，而且本人也会有所收获、提高能力。

（2）因为实现难度而修改需求。

　　这种状况每每发生在设计人员已经给出了设计图和切图，开发人员开始开发，在某一个地方遇到了实现难题，好比按照本来的需求方案，可能有性能问题，或者开发难度太大，工做量比预期的大不少，等等。这时候，只好用一个妥协的产品方案来替代本来的需求。因而，设计人员须要从新做图，开发人员也有部分工做须要调整。有的同窗可能会说，这种状况可不能赖产品经理了吧？是开发人员实现不了致使推倒重来的。这里要特别指出，若是你想成为一名优秀的产品经理，千万不要有这种思考习惯。项目中出现的任何问题，都有产品经理的责任。那么，这种状况要如何避免呢？那就是尽早地邀请开发人员介入，在需求方案还未敲定时，甚至在需求发起和讨论时就邀请开发人员一块儿参与讨论，即便开发人员对产品方案不能给出建议，至少也能够了解需求的来源，而且及时指出一些技术实现的难点。这种实现风险大、成本高的地方发现和提出得越早，越能保障产品后续环节的顺畅进行。需求变动发生得越晚，新的需求方案输出得就越仓促，考虑得就越不周全，对产品和项目都有很大危害。风险提出得越早，除能够避免团队成员工做量的浪费以外，还可让你们对需求变动考虑得更周全。因此，在这里产品经理要注意，让开发人员尽早了解和知道接下来要作什么需求，涉及哪些技术难点，这既是必需的，也是应该的。

（3）在设计图出来以后，或者开发原型出来之后，甚至在测试阶段，发现以前的需求方案不合理。

　　这种状况通常是不该该发生的，产品经理的水平越高，发生这种状况的几率也会越低。可是人不可能彻底不犯错，或者说，在看到真正的效果以前，甚至试用原型以前，有些交互体验的细节问题确实难以发现。这也是产品经理须要修炼自身的地方，平时应该多试用各类产品，体验各类交互和页面设计，这样才能在设计产品方案时不是单纯地拍脑壳，而是在有真正的操做体验的基础上去设计。可是也要说明一点，这种状况下的需求变动，不该该是很是重大的变动，通常都是交互体验或者页面内视觉逻辑的微调整。产品流程或产品逻辑的问题，应该在视觉效果图输出以前就可以被发现，而不是到视觉效果图或者产品原型阶段才能发现。

（4）还有一种很是无奈可是常见的状况，即老板提出的需求变动，或者真的因为产品方向改变而出现的需求变动。

　　这种状况下，产品经理也并不是彻底没有责任。这时产品经理要思考，为何老板在已经进入设计和开发的阶段才提出需求变动？是否由于老板以前并无可以充分了解需求？这多是由于老板太忙了，没有关注到这个项目，那么其实产品经理能够更主动积极地让老板了解产品项目的进度、整个需求的思考过程和最终方案。这样，若是老板有其余想法或不一样意见，便可及早提出。
　　所以咱们看到，避免需求变动的主要思想就是，让信息在团队内部，产品与产品之间， 团队与老板之间，进行充分的交流和沟通，避免信息不对称或不一样步的状况，在信息充分同步的状况下，才能更早地暴露问题，提早修改需求方案，不浪费设计和开发等资源。
　　没有需求变动的团队是很是理想的，可是当理想照进现实，咱们发现，事实上不多有需求不变动的状况。那么，当需求变动不可避免地发生了，该怎么处理，才能将危害降到最小呢？ 
　　其实，需求变动流程与产品的通常流程是一致的，首先是产品经理从新思考变动的需求， 全面考虑后输出新的需求方案，同时并行的是充分与设计、开发、测试等团队成员沟通，让你们了解需求为何要变动，如何变动，以及修改后的方案会是什么样子，等等。在团队成员对变动后的需求都承认了以后，就要再次进入设计、开发、测试的阶段。在整个过程当中， 产品经理同时要关注的是需求变动对整个产品版本进度的影响，通常须要设计、开发、测试人员从新评估工做量和提测时间，产品经理须要了解该变动是否会影响产品最终的发布时间， 若是确实有影响，没法经过协调其余时间来消化，那么要及时告知更大范围的团队成员。好比需求变动只涉及一个功能的开发和测试，但当这个需求变动会影响整个版本的进度时，就须要让整个产品版本涉及的全部开发、测试等人员知道版本发布计划的变动及缘由。
　　因为需求变动通常是产品经理发起的，而这是至关不讨好的事，因此产品经理的压力其实很是大。最后再谈两点，让产品经理适当减轻一点压力，避免所以受到伤害。固然前提是产品经理要修炼本身，尽可能避免发生需求变动的状况，在此基础上，能够用以下两个方法来适当地调侃、保护本身。

（1）开发人员能保证不用修改Bug，那么产品经理也能够保证不发生需求变动。

　　修改Bug 其实就是开发人员不能一次性将产品作到完美的真实例子，其实这个道理在任何人身上都适用，只是开发人员的Bug 并不那么容易被发现，而产品经理的“Bug”，不少状况下是能够提早避免的。因此，必定要注意这句话说出来的场合和语气（通常要用调侃的语气）。虽然道理如此，但这并非产品经理的挡箭牌。在说这句话以前，必定要真诚地向团队成员道歉，尤为是受到需求变动影响的成员，毕竟需求变动的责任更多地在产品经理。可是也能够用这句话调侃下，让你们互相理解，都是无可奈何。

（2）是Bug仍是需求变动？

　　善良的产品新人会说，这个问题须要去深究吗？是的，通常状况下，尤为是小团队，是不须要深究的，可是，当团队比较大，或者需求变动致使的影响比较大的时候，搞清楚问题出现的缘由是Bug仍是需求变动，对将来避免发生相似问题是有益的。如何搞清楚呢？这就须要查看产品需求文档。
　　曾经有产品新人问，写需求文档有没有意义？若是它只是为了备案和存档记录，那么对于创业阶段的小团队，因为产品方向还在不断地变化，还在快速尝试中，备案和记录好像并无那么必要和紧急。其实需求文档的重要意义在于能够先后印证，了解这一类有利于鞭策产品经理提高本身完整考虑需求的能力及写需求文档的能力。好比开发人员说：“这个Bug不是Bug，是你的需求，若是你如今要变成这样，那么你就要说明是需求变动。”这时，你可以悠然地打开需求文档，指出某一条，上面明确写明了需求，是开发人员没有正确实现。不要觉得这种状况很罕见。是Bug仍是需求变动，关乎声誉甚至绩效，是一个值得去明确的问题。对于产品经理来讲，若是是早就想到了的需求逻辑点，只是由于在需求文档中漏写或没有明确表达出来，致使开发人员认为需求文档里没有写明而在开发过程当中也漏写了逻辑从而产生问题，这种“需求变动”确实不能算Bug，责任就在于产品经理。
　　因此，若是你真的在需求文档中明确表达清楚了，是开发人员没有按照需求实现，那就是Bug，不能算做需求变动，这是对产品经理声誉的保护。但若是是由于你的需求文档写得不够严谨而形成“需求变动”，那么就只有吃下黄连以后继续修炼了。
　　本文选自《爆款是怎样炼成的：产品经理晋级宝典》，点此连接可在博文视点官网查看此书。
　　　　　　　　　　　　　　　　　　　　
　　想及时得到更多精彩文章，可在微信中搜索“博文视点”或者扫描下方二维码并关注。