需求变更，产品经理的良心也会痛！-创新互联
引言：在项目执行过程中，产品经理与后续的合作团队，包括设计、开发、测试等相关人员最尖锐突出的矛盾，就是需求变更，这是产品经理最经常被诟病的地方。频繁的需求变更，对产品、项目进度和团队积极性都有非常大的危害。产品经理一定要不遗余力避免需求变更的情况。
本文选自《爆款是怎样炼成的：产品经理晋级宝典》。创新互联公司是一家专注于成都网站设计、网站建设与策划设计,隰县网站建设哪家好?创新互联公司做网站,专注于网站建设十年,网设计领域的专业建站公司;建站业务涵盖:隰县等地区。隰县做网站价格咨询:18980820575
作为产品经理，我们一定要理解开发团队及其他团队成员为什么视需求变更为大敌。事实上，需求变更对整个项目都非常有害。
需求有变更，就意味着设计、开发团队的工作有浪费。这首先是资源和时间的浪费。
这会导致团队成员有抵触情绪，对产品经理及需求产生了不确定感，产品经理的威信下降。严重的还会导致团队成员懈怠工作，因为谁知道什么时候这个需求还会变更？也许就不用做了呢？
打乱版本进度，除影响发版时间之外，还会打乱团队的工作节奏。原本运转得很好的团队，如果频繁发生需求变更，很容易打乱项目节奏，使人无所适从，因为原本计划的时间点已经由于需求变更不可能按计划实现。
临时发生需求变更，容易导致新的需求考虑得更加不周全，项目的风险、产品质量下降的风险都会加大，严重的还会导致产品偏离原本的产品定位或想法。
频繁的需求变更，对产品、项目进度和团队积极性都有非常大的危害。产品经理一定要不遗余力避免需求变更的情况。下面来看看需求变更产生的主要矛盾以及如何应对。
（1）对需求考虑不周全。
比如产品经理小明设计用户注册流程，方案是用户需要填写手机号才能顺利注册。这个方案已经由设计人员给出效果图和切图，且进入了开发阶段。那么，在这个过程中，小明从公司内部的其他同类产品中了解到，用户对手机号非常敏感，如果手机号是注册时的必填信息，则很容易造成在注册流程中用户的流失。于是，小明只好修改产品方案，将填写手机号一项改成选填，增加填写常用邮箱作为注册用户的唯一标识。这就是典型的在需求方案设计阶段，没有全面考量方案的例子。当然，这与小明的经验也有关系，一般新人难免在设计方案时对一些情况不够敏感，会有疏忽和考虑不全的情况。这需要产品经理高标准要求自己，从各种角度审视、考量自己的方案，尽全力考虑周全，那么就会在相当大的程度上避免需求变更，并且本人也会有所收获、提升能力。
（2）由于实现难度而修改需求。
这种情况往往发生在设计人员已经给出了设计图和切图，开发人员开始开发，在某一个地方遇到了实现难题，比如按照原本的需求方案，可能有性能问题，或者开发难度太大，工作量比预期的大很多，等等。这时候，只好用一个妥协的产品方案来替代原本的需求。于是，设计人员需要重新作图，开发人员也有部分工作需要调整。有的同学可能会说，这种情况可不能赖产品经理了吧？是开发人员实现不了导致推倒重来的。这里要特别指出，如果你想成为一名优秀的产品经理，千万不要有这种思考习惯。项目中出现的任何问题，都有产品经理的责任。那么，这种情况要如何避免呢？那就是尽早地邀请开发人员介入，在需求方案还未敲定时，甚至在需求发起和讨论时就邀请开发人员一起参与讨论，即使开发人员对产品方案不能给出建议，至少也可以了解需求的来源，并且及时指出一些技术实现的难点。这种实现风险大、成本高的地方发现和提出得越早，越能保障产品后续环节的顺畅进行。需求变更发生得越晚，新的需求方案输出得就越仓促，考虑得就越不周全，对产品和项目都有很大危害。风险提出得越早，除可以避免团队成员工作量的浪费之外，还可以让大家对需求变更考虑得更周全。所以，在这里产品经理要注意，让开发人员尽早了解和知道接下来要做什么需求，涉及哪些技术难点，这既是必需的，也是应该的。
（3）在设计图出来之后，或者开发原型出来以后，甚至在测试阶段，发现之前的需求方案不合理。
这种情况一般是不应该发生的，产品经理的水平越高，发生这种情况的概率也会越低。但是人不可能完全不犯错，或者说，在看到真正的效果之前，甚至试用原型之前，有些交互体验的细节问题确实难以发现。这也是产品经理需要修炼自身的地方，平时应该多试用各种产品，体验各种交互和页面设计，这样才能在设计产品方案时不是单纯地拍脑袋，而是在有真正的操作体验的基础上去设计。但是也要说明一点，这种情况下的需求变更，不应该是非常重大的变更，一般都是交互体验或者页面内视觉逻辑的微调整。产品流程或产品逻辑的问题，应该在视觉效果图输出之前就能够被发现，而不是到视觉效果图或者产品原型阶段才能发现。
（4）还有一种非常无奈但是常见的情况，即老板提出的需求变更，或者真的由于产品方向改变而出现的需求变更。
这种情况下，产品经理也并非完全没有责任。这时产品经理要思考，为什么老板在已经进入设计和开发的阶段才提出需求变更？是否因为老板之前并没有能够充分了解需求？这可能是因为老板太忙了，没有关注到这个项目，那么其实产品经理可以更主动积极地让老板了解产品项目的进度、整个需求的思考过程和最终方案。这样，如果老板有其他想法或不同意见，即可及早提出。
因此我们看到，避免需求变更的主要思想就是，让信息在团队内部，产品与产品之间， 团队与老板之间，进行充分的交流和沟通，避免信息不对称或不同步的情况，在信息充分同步的情况下，才能更早地暴露问题，提前修改需求方案，不浪费设计和开发等资源。
没有需求变更的团队是非常理想的，但是当理想照进现实，我们发现，事实上很少有需求不变更的情况。那么，当需求变更不可避免地发生了，该怎么处理，才能将危害降到最小呢？
其实，需求变更流程与产品的一般流程是一致的，首先是产品经理重新思考变更的需求， 全面考虑后输出新的需求方案，同时并行的是充分与设计、开发、测试等团队成员沟通，让大家了解需求为什么要变更，如何变更，以及修改后的方案会是什么样子，等等。在团队成员对变更后的需求都认可了之后，就要再次进入设计、开发、测试的阶段。在整个过程中， 产品经理同时要关注的是需求变更对整个产品版本进度的影响，一般需要设计、开发、测试人员重新评估工作量和提测时间，产品经理需要了解该变更是否会影响产品最终的发布时间， 如果确实有影响，无法通过协调其他时间来消化，那么要及时告知更大范围的团队成员。比如需求变更只涉及一个功能的开发和测试，但当这个需求变更会影响整个版本的进度时，就需要让整个产品版本涉及的所有开发、测试等人员知道版本发布计划的变更及原因。
由于需求变更一般是产品经理发起的，而这是相当不讨好的事，所以产品经理的压力其实非常大。最后再谈两点，让产品经理适当减轻一点压力，避免因此受到伤害。当然前提是产品经理要修炼自己，尽量避免发生需求变更的情况，在此基础上，可以用如下两个方法来适当地调侃、保护自己。
（1）开发人员能保证不用修改Bug，那么产品经理也可以保证不发生需求变更。
修改Bug 其实就是开发人员不能一次性将产品做到完美的真实例子，其实这个道理在任何人身上都适用，只是开发人员的Bug 并不那么容易被发现，而产品经理的“Bug”，很多情况下是可以提前避免的。所以，一定要注意这句话说出来的场合和语气（一般要用调侃的语气）。虽然道理如此，但这并不是产品经理的挡箭牌。在说这句话之前，一定要真诚地向团队成员道歉，尤其是受到需求变更影响的成员，毕竟需求变更的责任更多地在产品经理。但是也可以用这句话调侃下，让大家互相理解，都是迫不得已。
（2）是Bug还是需求变更？
善良的产品新人会说，这个问题需要去深究吗？是的，一般情况下，尤其是小团队，是不需要深究的，但是，当团队比较大，或者需求变更导致的影响比较大的时候，搞清楚问题出现的原因是Bug还是需求变更，对未来避免发生类似问题是有益的。如何搞清楚呢？这就需要查看产品需求文档。
曾经有产品新人问，写需求文档有没有意义？如果它只是为了备案和存档记录，那么对于创业阶段的小团队，由于产品方向还在不断地变化，还在快速尝试中，备案和记录好像并没有那么必要和紧急。其实需求文档的重要意义在于可以前后印证，了解这一类有利于鞭策产品经理提升自己完整考虑需求的能力及写需求文档的能力。比如开发人员说：“这个Bug不是Bug，是你的需求，如果你现在要变成这样，那么你就要说明是需求变更。”这时，你能够悠然地打开需求文档，指出某一条，上面明确写明了需求，是开发人员没有正确实现。不要以为这种情况很罕见。是Bug还是需求变更，关乎声誉甚至绩效，是一个值得去明确的问题。对于产品经理来说，如果是早就想到了的需求逻辑点，只是因为在需求文档中漏写或没有明确表达出来，导致开发人员认为需求文档里没有写明而在开发过程中也漏写了逻辑从而产生问题，这种“需求变更”确实不能算Bug，责任就在于产品经理。
所以，如果你真的在需求文档中明确表达清楚了，是开发人员没有按照需求实现，那就是Bug，不能算作需求变更，这是对产品经理声誉的保护。但如果是因为你的需求文档写得不够严谨而造成“需求变更”，那么就只有吃下黄连之后继续修炼了。
本文选自《爆款是怎样炼成的：产品经理晋级宝典》，点此链接可在博文视点官网查看此书。
想及时获得更多精彩文章，可在微信中搜索“博文视点”或者扫描下方二维码并关注。
另外有需要云服务器可以了解下创新互联scvps.cn，海内外云服务器15元起步，三天无理由+7*72小时售后在线，公司持有idc许可证，提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案，具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势，专为企业上云打造定制，能够满足用户丰富、多元化的应用场景需求。
网页标题：需求变更，产品经理的良心也会痛！-创新互联
网站路径：http://abwzjs.com/article/jpese.html
