听说因为随便改需求，某公司产品经理被愤怒的程序猿砍成重伤，至今昏迷不醒！
经常在网上看到，在产品研发的过程中，发生了需求变更。研发同学辛苦写的代码泡汤了，测试同学好不容易找出的 bug 得重新再找，每个人心里边都有一股怨念，产品经理作为需求的管理者，很容易承受人民群众的怒火，千夫所指，惶惶不安。一旦处理不好，很容易导致同事间的矛盾。
有人尝试着消灭需求变更的可能性，但很快会发现，需求变化很多时候根本不是产品经理自己就能控制的，甚至它就是产品发展过程中必然的经历。所以，需求变化必须纳入管理，我们称之为需求变更管理。
今天我们谈的需求变更管理方法，必须要明确两个前提：
第一，适用于产品、研发能够畅通沟通的团队。对于外包项目等需求与开发负责人不在同一团队的情况，仅供参考。
第二，适用于研发周期短，快速上线的产品迭代。对于研发周期动辄大半年的软件工程项目，需要引入更复杂的需求变更流程。同样，对于产品整体方向上的大调整，也不适用文章中提到的方法。
** 需求伊始充分沟通 **
互联网产品的研发是一次团队满足用户需求的体验之旅。既然是集体活动，事前约法三章非常重要，开始旅行之前，团队的每一位成员都需要就一些基本问题达成一致：
尊重团队的工作成果，每一次需求变更都意味着团队努力的消耗，不能接受随时随地都在发生的变化。产品经理作为需求的把控方，不能每天换个花样，今天要方的明天要圆的，提前想清楚自己要什么，拒绝拍脑袋做决策。
需求最好少变，但必须接受变化的存在。产品经理不是神，无法全知全能，团队需要对产品经理的工作保持一定的容忍度，无须谈变更就上板砖。我的习惯是和新团队合作，一定会找研发的同事们开诚布公一次，明确告知我能力有限，一定会发生需求变更，但是我会控制，不给大家瞎指挥。适当降低大家对自己工作的预期，有助于提高大家的满意度。
开始研发之前，产品经理有义务就本次研发的目标、手段和衡量方式，与整个团队达成一致。团队对需求的理解，直接影响着业绩达成。很多团队的产品和研发的关系都停留在产品经理写需求，研发团队做需求，至于为什么做，如何做，双方很少沟通，把办公室搞成了拧螺丝的流水线。
Shane 注：分享一个我常用来和团队伙伴沟通目标、手段、衡量手段的方法：BML 模型，即在什么样的背景下，作为产品经理，我依托什么逻辑设计了这样一套解决方案，上线之后我会去关注哪些节点的数据表现，什么样的数据表现会继续迭代这个方案，什么样的数据表现会考虑转型。
不要把所有问题都推到需求定义阶段。事前沟通再详尽，也会有疏漏和遗忘。过程中的沟通，有助于改善团队环境。对熟悉度很高的团队，很多事情可以靠眼神交流。如果还存有陌生感，一定要多聊，产品经理可以在午餐、晚餐及其他休息时间找研发同事听听他们对需求的理解，能够避免理解不一致带来的更改。
** 分清需求变化是如何发生的 **
再优秀的需求定义阶段，也顶不住来自时间的冲击。需求终究还是会发生变化的。那么处理的第一步，是弄清楚它是怎么发生的。常见的可能有以下几种情况：
1 自己没想清楚
这种情况对于天天都在看新东西的产品经理来说经常会发生。刚做好的设计，刚做完评审第二天就发现了新的方案。
2 老板/业务需求方变了
有的产品经理自己不会拍脑袋，但是架不住老板日理万机爱拍脑袋，胳膊拧不过大腿，只好变更。关于老板的需求处理，可以参见之前的一篇文章《报告老板，你的需求不靠谱》。
3 环境变了
产品还没上线，发现市场已经发生了变化。市场机会瞬息万变。比如之前本来稳扎稳打地做着百度云，忽然金山说我永久免费了，360也说我永久免费360G了，这时百度云也没法坚持原来的研发节奏。
4 以为变了
这种情况也经常发生，很多团队的沟通存在盲区，每个人都在瞎子摸象，对于最后的结果没有统一的目标，当发生不一致时，大家就会说这是需求变化了。
** 判断是否发起需求变更 **
需求可能有了变化，但是否有必要打断原有的研发节奏，进行需求变更，非常考验产品经理决策能力。一般情况下，我们需要做三个判断：
1 需求变化的幅度
首先确认需求变化的幅度，是实现流程的转变，还是细节上的优化。
如果是流程的变化，产品经理需要格外慎重。在考虑这样的需求变化时，我们需要分析现在的手段是否真的无法满足目标实现了。比如为了让用户能更方便查找内容，我们计划做一个内容分类导航，现在觉得不足够，想做一个搜索，这可能代表着之前的工作全都打水漂了，对团队士气有很重大的影响。一般情况下，除非是原来的计划几乎不能达成相对满意的结果，否则不要在迭代中做调整。
如果是细节上的优化，比如一些文案或者小的交互动画，对原有流程的完善，那么也可以纳入到进一步考虑的范围内。
2 价值与成本的权衡
新的需求提出是否对本次研发目标的达成有较大的促进，能够极大程度地提高对用户需求的满足程度。同时新需求提出后，研发团队修改所花费的精力大小。
效果预期很好，成本低的需求变更，积极推进
效果预期很好，成本高的需求变更，延后处理
效果未知，成本低的需求变更，审慎处理，绝不大量投入
效果未知，成本高的需求变更，坚决避免
这几项原则无论是对于来自自己、老板还是环境的需求都可以适用。重点是控制好总量，需求变更总是打断了原有工作。如果发现太多事情都需要做变更，那么我们应当首先反思自己需求定义工作的有效性。
Shane 注：权衡可以参考俞军的用户体验公式：新体验 - 旧体验 - 变更成本
3 项目排期是否接受变化
判断完需求值得变更之后，还需要考量当前项目排期情况。
如果项目排期非常紧张，并且无法变化，最好忘掉需求变更。大佬们说了，完成永远比完美更重要。
在决策需求变更的过程中，需要和需求方、团队都做好沟通，每个角色都有自己支持或者反对的理由，产品经理有义务在实施变更之前，统一所有人的认知。
** 需求变更的沟通 **
当我们确定实施需求变更后，还有一些善后工作必须做到。
1 修改需求文档
需求变更之后，很容易出现沟通不一致。需要尽快修改需求文档，重新发出，避免同事们靠一句话需求脑补或者纯口头沟通继续开发，费时费力还容易错。
Shane 注：很对团队都是用邮件来同步、保存需求，在项目管理过程中很容易出现需求文档版本混乱的问题。工欲善其事，必先利其器，产品经理都应该在团队中推动建立一套好的需求文档管理系统，例如 GIT 就非常好。
2 说明变更情况
无论是正式或者非正式的，我们有必要将需求变更的情况告知相关同事，包括需求方、研发同事。
尤其是测试的同事，很多时候在讨论需求时，开发或多或少会参与，但往往测试的同事直到发现实现和需求不一致时，才知道需求变更了。这也会带来他们的重复工作和测试质量的降低。
我们需要至少说清楚两件事：
a 阐明需求变更的原因
如果是自己的锅，请主动的背起来。如果是老板的锅，请充分沟通理解之后，也主动的背起来，不让自己变成老板的传声筒。背的时候，注重对变更价值的陈述，让相关人都能明确变更的意义。人人都希望自己做的事情是有价值的，描述清楚变更的价值，有助于后续工作的开展。
b 明确新的项目排期
对于研发的同事，项目排期是否变化决定了大家阶段性的工作压力。如果争取到了变更需求的开发时间，大家可以保持工作节奏，以相对轻松的状态应对变化。如果项目排期无法改变，需要大家加班的话，也请备好零食饮料，全程陪同。
对于需求方，原有的计划可能有一系列后续工作，如果需求变更会导致项目延误，需要告诉后续同事注意调整工作计划。同时这也是再一次告知需求方这是我们团队为需求变化买的单，未来需要更加审慎。
Shane 注：如果老板是需求方，最后评估下来需要调整当前项目，特别是影响到其他项目的排期，需要做好向上管理的工作。因为层级之间往往存在信息不对称，对于整体项目的优先级判断可能会出现不一致，要及时沟通。
** 其他的个人习惯和常见问题 **
1 担心他人差评，不敢做需求变更
很多同学害怕被同事 K 而不敢做需求变更，尤其是一些设计初期没能考虑到的细节问题，研发一旦做出来之后，产品同学发现了也不敢提出修改，放弃了对产品体验的有效把握。
这种情况，我个人有个习惯是在每次研发前跟研发的同事约定一个产品体验变更期。当产品初版出来之后，我会集中把产品从头到尾感受一遍，找出体验上的细节问题。有了事前的沟通和项目排期，大家对体验修改的容忍度也会高一些。
2 逆来顺受的做需求变更
也有的同学对其他人拍过来的需求来者不拒，全部都找研发同事改掉，而自己对于修改的原因和程度并不了解。久而久之，这样的修改程度会让研发团队疲于奔命，也把自己变成了需求方和研发团队之间的传话筒，丧失团队信任。需要回归原点，从用户需求出发，判断需求变更的价值。
3 死抠排期，漏改大问题
有时候我们会因为排期已定，担心影响上线时间，连真正的问题也放过了。事实上，对于互联网研发项目，排期更多起的是参考作用，帮助衡量项目的进展情况。即使真的有重大不能延缓的项目，像618，双十一这类大促活动，我们也需要根据上线后的影响来决定是否修改，而不是仅凭排期做事。
** 小结 **
最后，奉上不会被砍死的需求变更 32 字口诀：
目标出发，衡量价值，判断时机，做好沟通；
不怕质疑，不甘传声，灵活应对，顺理成章。
