关键词：
引言：在项目执行过程中，产品经理与后续的合作团队，包括设计、开发、测试等相关人员最尖锐突出的矛盾，就是需求变更，这是产品经理最经常被诟病的地方。频繁的需求变更，对产品、项目进度和团队积极性都有非常大的危害。产品经理一定要不遗余力避免需求变更的情况。
本文选自《爆款是怎样炼成的：产品经理晋级宝典》。
作为产品经理，我们一定要理解开发团队及其他团队成员为什么视需求变更为大敌。事实上，需求变更对整个项目都非常有害。
需求有变更，就意味着设计、开发团队的工作有浪费。这首先是资源和时间的浪费。
这会导致团队成员有抵触情绪，对产品经理及需求产生了不确定感，产品经理的威信下降。严重的还会导致团队成员懈怠工作，因为谁知道什么时候这个需求还会变更？也许就不用做了呢？
打乱版本进度，除影响发版时间之外，还会打乱团队的工作节奏。原本运转得很好的团队，如果频繁发生需求变更，很容易打乱项目节奏，使人无所适从，因为原本计划的时间点已经由于需求变更不可能按计划实现。
临时发生需求变更，容易导致新的需求考虑得更加不周全，项目的风险、产品质量下降的风险都会加大，严重的还会导致产品偏离原本的产品定位或想法。
频繁的需求变更，对产品、项目进度和团队积极性都有非常大的危害。产品经理一定要不遗余力避免需求变更的情况。下面来看看需求变更产生的主要矛盾以及如何应对。
（1）对需求考虑不周全。
比如产品经理小明设计用户注册流程，方案是用户需要填写手机号才能顺利注册。这个方案已经由设计人员给出效果图和切图，且进入了开发阶段。那么，在这个过程中，小明从公司内部的其他同类产品中了解到，用户对手机号非常敏感，如果手机号是注册时的必填信息，则很容易造成在注册流程中用户的流失。于是，小明只好修改产品方案，将填写手机号一项改成选填，增加填写常用邮箱作为注册用户的唯一标识。这就是典型的在需求方案设计阶段，没有全面考量方案的例子。当然，这与小明的经验也有关系，一般新人难免在设计方案时对一些情况不够敏感，会有疏忽和考虑不全的情况。这需要产品经理高标准要求自己，从各种角度审视、考量自己的方案，尽全力考虑周全，那么就会在相当大的程度上避免需求变更，并且本人也会有所收获、提升能力。
（2）由于实现难度而修改需求。
这种情况往往发生在设计人员已经给出了设计图和切图，开发人员开始开发，在某一个地方遇到了实现难题，比如按照原本的需求方案，可能有性能问题，或者开发难度太大，工作量比预期的大很多，等等。这时候，只好用一个妥协的产品方案来替代原本的需求。于是，设计人员需要重新作图，开发人员也有部分工作需要调整。有的同学可能会说，这种情况可不能赖产品经理了吧？是开发人员实现不了导致推倒重来的。这里要特别指出，如果你想成为一名优秀的产品经理，千万不要有这种思考习惯。项目中出现的任何问题，都有产品经理的责任。那么，这种情况要如何避免呢？那就是尽早地邀请开发人员介入，在需求方案还未敲定时，甚至在需求发起和讨论时就邀请开发人员一起参与讨论，即使开发人员对产品方案不能给出建议，至少也可以了解需求的来源，并且及时指出一些技术实现的难点。这种实现风险大、成本高的地方发现和提出得越早，越能保障产品后续环节的顺畅进行。需求变更发生得越晚，新的需求方案输出得就越仓促，考虑得就越不周全，对产品和项目都有很大危害。风险提出得越早，除可以避免团队成员工作量的浪费之外，还可以让大家对需求变更考虑得更周全。所以，在这里产品经理要注意，让开发人员尽早了解和知道接下来要做什么需求，涉及哪些技术难点，这既是必需的，也是应该的。
（3）在设计图出来之后，或者开发原型出来以后，甚至在测试阶段，发现之前的需求方案不合理。
这种情况一般是不应该发生的，产品经理的水平越高，发生这种情况的概率也会越低。但是人不可能完全不犯错，或者说，在看到真正的效果之前，甚至试用原型之前，有些交互体验的细节问题确实难以发现。这也是产品经理需要修炼自身的地方，平时应该多试用各种产品，体验各种交互和页面设计，这样才能在设计产品方案时不是单纯地拍脑袋，而是在有真正的操作体验的基础上去设计。但是也要说明一点，这种情况下的需求变更，不应该是非常重大的变更，一般都是交互体验或者页面内视觉逻辑的微调整。产品流程或产品逻辑的问题，应该在视觉效果图输出之前就能够被发现，而不是到视觉效果图或者产品原型阶段才能发现。
（4）还有一种非常无奈但是常见的情况，即老板提出的需求变更，或者真的由于产品方向改变而出现的需求变更。
这种情况下，产品经理也并非完全没有责任。这时产品经理要思考，为什么老板在已经进入设计和开发的阶段才提出需求变更？是否因为老板之前并没有能够充分了解需求？这可能是因为老板太忙了，没有关注到这个项目，那么其实产品经理可以更主动积极地让老板了解产品项目的进度、整个需求的思考过程和最终方案。这样，如果老板有其他想法或不同意见，即可及早提出。
因此我们看到，避免需求变更的主要思想就是，让信息在团队内部，产品与产品之间， 团队与老板之间，进行充分的交流和沟通，避免信息不对称或不同步的情况，在信息充分同步的情况下，才能更早地暴露问题，提前修改需求方案，不浪费设计和开发等资源。
没有需求变更的团队是非常理想的，但是当理想照进现实，我们发现，事实上很少有需求不变更的情况。那么，当需求变更不可避免地发生了，该怎么处理，才能将危害降到最小呢？
其实，需求变更流程与产品的一般流程是一致的，首先是产品经理重新思考变更的需求， 全面考虑后输出新的需求方案，同时并行的是充分与设计、开发、测试等团队成员沟通，让大家了解需求为什么要变更，如何变更，以及修改后的方案会是什么样子，等等。在团队成员对变更后的需求都认可了之后，就要再次进入设计、开发、测试的阶段。在整个过程中， 产品经理同时要关注的是需求变更对整个产品版本进度的影响，一般需要设计、开发、测试人员重新评估工作量和提测时间，产品经理需要了解该变更是否会影响产品最终的发布时间， 如果确实有影响，无法通过协调其他时间来消化，那么要及时告知更大范围的团队成员。比如需求变更只涉及一个功能的开发和测试，但当这个需求变更会影响整个版本的进度时，就需要让整个产品版本涉及的所有开发、测试等人员知道版本发布计划的变更及原因。
由于需求变更一般是产品经理发起的，而这是相当不讨好的事，所以产品经理的压力其实非常大。最后再谈两点，让产品经理适当减轻一点压力，避免因此受到伤害。当然前提是产品经理要修炼自己，尽量避免发生需求变更的情况，在此基础上，可以用如下两个方法来适当地调侃、保护自己。
（1）开发人员能保证不用修改Bug，那么产品经理也可以保证不发生需求变更。
修改Bug 其实就是开发人员不能一次性将产品做到完美的真实例子，其实这个道理在任何人身上都适用，只是开发人员的Bug 并不那么容易被发现，而产品经理的“Bug”，很多情况下是可以提前避免的。所以，一定要注意这句话说出来的场合和语气（一般要用调侃的语气）。虽然道理如此，但这并不是产品经理的挡箭牌。在说这句话之前，一定要真诚地向团队成员道歉，尤其是受到需求变更影响的成员，毕竟需求变更的责任更多地在产品经理。但是也可以用这句话调侃下，让大家互相理解，都是迫不得已。
（2）是Bug还是需求变更？
善良的产品新人会说，这个问题需要去深究吗？是的，一般情况下，尤其是小团队，是不需要深究的，但是，当团队比较大，或者需求变更导致的影响比较大的时候，搞清楚问题出现的原因是Bug还是需求变更，对未来避免发生类似问题是有益的。如何搞清楚呢？这就需要查看产品需求文档。
曾经有产品新人问，写需求文档有没有意义？如果它只是为了备案和存档记录，那么对于创业阶段的小团队，由于产品方向还在不断地变化，还在快速尝试中，备案和记录好像并没有那么必要和紧急。其实需求文档的重要意义在于可以前后印证，了解这一类有利于鞭策产品经理提升自己完整考虑需求的能力及写需求文档的能力。比如开发人员说：“这个Bug不是Bug，是你的需求，如果你现在要变成这样，那么你就要说明是需求变更。”这时，你能够悠然地打开需求文档，指出某一条，上面明确写明了需求，是开发人员没有正确实现。不要以为这种情况很罕见。是Bug还是需求变更，关乎声誉甚至绩效，是一个值得去明确的问题。对于产品经理来说，如果是早就想到了的需求逻辑点，只是因为在需求文档中漏写或没有明确表达出来，导致开发人员认为需求文档里没有写明而在开发过程中也漏写了逻辑从而产生问题，这种“需求变更”确实不能算Bug，责任就在于产品经理。
所以，如果你真的在需求文档中明确表达清楚了，是开发人员没有按照需求实现，那就是Bug，不能算作需求变更，这是对产品经理声誉的保护。但如果是因为你的需求文档写得不够严谨而造成“需求变更”，那么就只有吃下黄连之后继续修炼了。
本文选自《爆款是怎样炼成的：产品经理晋级宝典》，点此链接可在博文视点官网查看此书。
想及时获得更多精彩文章，可在微信中搜索“博文视点”或者扫描下方二维码并关注。
本文出自 “博文视点官方博客” 博客，请务必保留此出处http://bvbroadview.blog.51cto.com/3227029/1924810
产品经理如何正确告别撕逼？
...这样的疑问 ： 产品经理如何与开发掑逼？ 遇到产品需求变更，怎么与设计沟通? 客户频繁更改需求后却不满意怎么办？ 无数次改需求，开发人员当场发飚？ 产品经理每天面对跟客户，跟上司、大boss、第三方厂商，平行部... 查看详情
项目经理该如何面对频繁的需求变更?
对于软件研发项目管理，需求变更频繁是一个非常让人头痛也很无奈的问题，小到某个文档标题的改变，大到一个新的产品功能需求的提出……一旦需求发生变更，往往容易引起重估、返工，那时就不得不修改设计、重写代码、... 查看详情
怎么分析《软件需求文档》
1、需求是什么？产品的功能、业务逻辑、面向的对象是什么（用户群体）2、需求来自哪里？自研公司—产品经理—需求文档（原型图）用户—产品经理整理—需求文档（原型图）3、测试需求是什么？对需求文档中的要求进行解... 查看详情
产品经理如何让程序员放下手中的刀？
...员似乎是天生的一对死对头，在面对产品经理不断更改的需求时，脾气再好的程序员也会情绪暴走，如何巧妙地避免这种情况的发生呢？众所周知，产品经理跟程序员属于死对头岗位，程序员跟产品经理因为需求打起来 查看详情
如何培养合格的产品经理？
...负责，从创意到产品的上市并取得市场成功，所有相关的需求分析、调研、验证、产品的研发、制造、售后服务、营销方案和销售渠道等，都由产品经理掌握。产品经理是依据公司的产品战略，对某个产品担负根本责任的企业管... 查看详情
如何培养合格的产品经理？
...负责，从创意到产品的上市并取得市场成功，所有相关的需求分析、调研、验证、产品的研发、制造、售后服务、营销方案和销售渠道等，都由产品经理掌握。产品经理是依据公司的产品战略，对某个产品担负根本责任的企业管... 查看详情
产品经理如何做好需求挖掘
产品经理如何做好需求挖掘产品经理如何做好需求挖掘一、什么是需求产品是用来解决用户的问题的，那么这些问题就是需求例子：饿了么，解决用户不想出门吃饭，节省吃饭时间的需求从互联网产品角度出发，需求就是：用户... 查看详情
负责的产品经理是如何跟进需求落地的？
一个产品经理可以随时随地的知晓自己需求的进度，并且能够及时检验，是对产品负责的一个态度。 产品经理中打酱油的节点 最近负责的产品模块进入开发周期，需求评审、产品设计过一段落，是时候歇一口气的周期。往往很... 查看详情
产品经理需求池管理
1、什么是需求池？需求池是产品经理个人或产品团队为确保产品需求被及时、完整、有序地接收、描述、排序、跟进的需求管理机制。简单理解为，所有需求都汇集在一个地方，这个地方就叫需求池。2、为什么要做需求池管理... 查看详情
「产品经理」和「功能经理」的差别
作者：BMAN产品经理最主要的职责就是懂需求。看上去好像非常easy。实际上，非常多产品经理都做不到这一点。举一个样例，就拿红包这个简单的功能来讲，产品经理怎样满足用户需求呢？好的产品经理会用最简单的功能去满足... 查看详情
商业化产品经理与用户产品经理区别
...品经理来说注重的交互设计、用户体验、产品运营能力。需求来源商业化产品经理的需求大多是产品经理针对公司现状挖掘出来的变现项目，还有可能来自业务部门需求或高层建议，会有特定合作业务部门配合完成营收KPI；用户... 查看详情
产品经理
...产品的设计者、推进者、运营者设计者：调研用户、分析需求；讨论、形成方案。推进者：和开发沟通产品需求；推进开发实现产品上线。运营者：维护产品内容、提升活跃度和用户量；进行市场推广，提升用户量什么是产品？... 查看详情
初级产品经理和中级产品经理的工作内容
初级产品经理和中级产品经理的工作内容初级充分理解需求，将需求产品化对产品逻辑和流程进行梳理原型制作，文档撰写专注用户体验，关注设计细节跟进UI和研发的进度中级（需要对行业有一定的认知）市场分析和竞品分析... 查看详情
顶级产品经理是如何写产品需求文档（prd）的
产品需求文档（PRD）对每个产品经理来说都不陌生，它是产品项目由"概念化"阶段进入到"图纸化"的转折和体现，作用是"对市场需求文档（MRD）中的内容进行指标化和技术化"，PRD质量的好坏直接影响到研发部门是否能够明确产品... 查看详情
产品经理之产品评审会
...板下载五、参考文章 一、什么是产品评审会 需求评审通常是由产品经理主持，通过讲解产品需求文档，让相关人员了解具体需求，并提出疑问，进行沟通的过程。统一大家对产品需求的理解，为后续“如何做&rdqu... 查看详情
高效的产品经理，都是这样制定工作流程的
一、需求整理分析1.接收需求在需求整理时，大致分为两个阶段：需求接收/idea的产生、需求分析&需求确认。产品工作的第一步就是接收需求。需求的来源大致有以下几种：1.老板提出的需求；2.产品经理市场调研得到的... 查看详情
2016第51周五产品经理的十大错误
错误1：将用户需求混淆为产品需求 大部分产品经理的工作流程是：收集完用户需求，开始编写产品需求文档，然后交给技术人员开发，接下来跟踪项目进度，协调资源，验收成果，最后发布产品。 整个流程没有错，容... 查看详情
工作那些事（二十五）项目经理与产品经理
...品设计和开发两个重要的角色。一般来说，产品经理负责需求部分，完整的输出有脑图、需求矩阵、需求说明书、原型、效果图。脑图清晰的展现出整个产品的几大模块或子系统。需求矩阵则进一步描述各部分的功能列表。原型... 查看详情