09 | 需求变更：三个锦囊，让需求变更不再是洪水猛兽

Aug 23, 2021

09 | 需求变更：三个锦囊，让需求变更不再是洪水猛兽-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

09 | 需求变更：三个锦囊，让需求变更不再是洪水猛兽

2021-08-23 雷蓓蓓来自北京

《雷蓓蓓的项目管理实战课》

课程介绍



讲述：雷蓓蓓

时长12:03大小11.03M



你好，我是雷蓓蓓。今天，我们来聊一聊如何应对需求变更这个话题。
需求变更一直都是一个热门话题，特别是在奉行唯快不破的互联网公司，需求变更可以说是程序员的头号噩梦，也是“996”的直接元凶。
阿里有句非常有名的口号，叫作拥抱变化。既然需求变更无法被消灭，那么我们就要通过学习，掌握更好地应对需求变更的方法。我们先来看看常见的需求变更流程。
首先要发起变更申请，由变更委员会来综合评估，评估的内容包括变更范围、风险、对现有计划的影响程度等，以此来判断是否接受变更。变更委员会一般是由产品 leader、技术 leader、测试 leader 及项目经理组成，如果接受变更，那么就需要判断项目计划是否需要进行相应的调整，最后公告处理结果。
讲到这里，我注意到艾文脸上的表情明显有些困惑，就邀请她来说说，艾文一开口就颇为直接：“老师，这个流程其实本身很简单，书上都这么写，我也知道要这么做，但现实是……除了我之外，团队没人愿意这么干！人微言轻，实在是做不到啊！”
我对艾文的直言不讳表示赞许，“不错，坦诚直面问题是第一步。说说都容易，关键在于能否有效执行。”
那么在这一讲，我会给你介绍几种实战下来亲测有用的方式，你可以把它们作为自己的“防身锦囊”。
锦囊 1：达成最小共识：变更是有代价的想当年，我跟你一样，是个初出茅庐的小姑娘。刚到 A 团队的时候，交互妹子就可怜兮兮地拉着我说：“2 个月过去了，我们的第一个版本还在打磨，80% 的交互稿都已经改得大不一样了，越是临近上线越是不断地改。如果你去跟策划们争辩，对方就甩过来一句‘老大要加的’，你说怎么办呢？”这个“老大”也就是 A 业务的负责人。他是产品经理出身，又是完美主义，加说一不二的性格，于是，产品策划在团队中有绝对的话语权。
在耐心地观察了一番之后，我终于等到了时机。在版本结束的复盘会之前，我跟负责人建议说：“你看，我们项目组是全新的团队，成立两个多月了，这么长时间运行下来，还是有不少问题的。我们需要一次深度复盘，这次复盘非常重要，你一定要来参加！”
复盘会的当天，大家匿名写纸条，分别列出各个环节做得好与不好的地方，贴到白板上。看着满墙花花绿绿的便签，写满了各个角色对需求变更的各种吐槽，这位负责人沉默了好久。
接着，我把事先准备的表格拿出来，表格中记录着历次变更给团队带来的各项成本增加及引发的返工（如下表）。
在复盘会接近尾声的时候，业务负责人当场发话：“从今天开始，团队里的需求变更要严格控制，从我自己做起！”在这之后，产品策划的随意变更行为显然收敛了很多。而我也趁势在下一次的全员会上，跟所有团队成员约法三章，把复盘会上的共识，细化成了具体流程：
所有需求及所有变更必须建单，无单需求开发有权不接；
需求变更必须经过变更委员会评估成本，变更成本较大的，要提交项目经理更新时间计划，并告知全员；
对于确认通过的变更，产品人员要发送邮件，让全项目组人员都知道。
这样一来，大家对于需求变更这件事，就从上到下达成了一个基本共识，需求变更的压力也瞬间得到了缓解。所以，要想改变现状，首先就是找到合适的时机，树立对变更的最小共识。之所以说最小共识，是指这个共识不需要一步到位，如果你的环境下确实比较困难，可以只是前进很小的一步，比如你可以从所有变更都需要记录，并公告周知开始。
达成这个最小共识，是要让团队开始慢慢认识到，需求变更是有代价的。但是，毕竟产品仍然在探索期，变更总是在所难免的。
怎么办呢？策划们开始想各种办法，好让技术能够顺利地接受变更。实验下来最有用的一招，莫过于请程序员们吃炸鸡了。当时坊间流传着一个段子：“没有一桶炸鸡解决不了的变更，如果不行，那就两桶！”在整体项目时间有要求的情况下，请程序员吃炸鸡，也确实成了项目快速推进的有效选择。作为项目管理，你要谨记，我们追求的是达成项目目标，而不是零变更。
上面讲的这些，其实是变更发生之后的应对方法。那么，回到变更的源头，我们可以做些什么呢？
首先，就是把关需求的质量，避免需求问题流到下游，我在第 6 讲中介绍的 Bug Bash，就是一个好方法。建议你在一些大版本上，需求设计稿完成时，发动团队的力量去做一轮全面的需求检查，调动各个角色的早期深度参与，对需求变更的防治很有效。
锦囊 2：源头治理，一次把事情做对艾文听到这里，忍不住拍手称赞：“锦囊 1 好棒！原来需求变更的流程，是这样一步一步共识建立起来的，我终于明白了。”“嗯……不过，我们团队的需求质量实在是很着急，上线时间又都是定死的，我担心只有这些，事后应对还不够，到头来一改再改，压缩的还是开发时间，有没有办法可以从源头杜绝隐患呢？”
说得对，要想真正把关需求的质量，还是得从源头开始治理。
接下来，我来跟你分享一个几年前，我在某事业群启动中台建设项目的真实案例。这个事业群当时已经有三四年的历史了，伴随着多条业务线的高速发展，公共平台的架构频频遭遇掣肘。这个事业群的老大几经思索，下定决心花大力气快速进行中台整治。情急之下，他找到我，让我来负责这个超级复杂的项目。
在四个月内，我们重整了这个平台积累了四年的整个业务和技术架构。当时时间非常紧张，四五条业务线的产品和设计人员都会参与其中。作为新的中台架构，如果在后续执行中发生变更，往往会产生灾难性的影响。怎么办呢？
我急中生智：“小黑屋集中开发呀！”不同的是，这次被关进小黑屋的，不再是苦哈哈的程序员，而是产品和设计。他们以前哪经历过这个啊？纷纷念叨着：“What？项目还没怎么着，先把产品和设计的 deadline 定了？！”于是，我找来那位老大站台，召集全员，开了次隆重的启动会。会议的第二天，十几位产品和设计人员就搬进来了。
为了减少后期的变更，尽可能一次把事情做对，我们在小黑屋搞起了上墙文化，产品和设计的 Deadline 排期图、产品模块设计图、页面逻辑跳转图……还有各种设计草图，全都被搬上了墙。
没过几天，这里居然成为了程序员午饭后驻足观赏的胜地。见到如此盛况，我们开始给游客们准备各色小标签，让他们在游览的同时随时发表各种评论。大家的参与热情空前高涨，很多需求和设计的漏洞就在这里被提前发现、及时讨论并修改掉了，有效地保障了早期需求和设计的质量。
其实，这个项目中每个业务线都有自己的策划，如果采用传统方式，这些需求各自成稿，再加上不同业务线策划之间、策划与设计之间、设计与开发之间、反复沟通的成本，不知道要拖到猴年马月才能真正确认，又不知道会埋下多少坑。
不得不说，这个锦囊是个大招，使用起来有一定难度。但从变更的源头开始治理，从源头开始公开透明，一次把事情最对，实际上是最有效率的方式。小黑屋 + Deadline 的实践效果奇佳，在一些上线时间有严格要求的复杂项目上，你绝对可以考虑下！
锦囊 3：快试错，不可抗力巧应对学会了前面两个锦囊妙计，来自产品经理的变更就不在话下了。不过，现实情况是，很多变更来自大老板或大客户，这些不可抗力，我们又该如何应对呢？
我的建议是，不要直接顶回去，要去剖析、把握和满足老板或客户的真正诉求。你可能会说，说起来容易，那如果老板或客户还是一定要改怎么办呢？
我的一个团队在被大老板的各种任性变更摧残了半年以后，终于痛定思痛：“我们一直想着法儿地对抗变更，大家都身心俱疲。反过来想想，其实老板也是人，老板也很痛苦，我们要给老板试错的机会，不是吗？”
后来，我们不再一味地抗拒，不过也并没有放弃努力。相反，我们尽可能想办法降低试错成本，为了隔离老板的需求对整个团队进度的干扰，我们在常规团队之外，组建了一个老板需求响应小分队，由团队轮流值班，协同提高响应速度，让老板可以试得快，试得爽！同时，对于那些我们并不太认同的老板需求，就快速尝试，小范围灰度发布，用对比数据说话。当这一系列机制运转顺畅之后，我们慢慢发现，老板提需求时不会每次都火急火燎了。
很多同学把这类来自老板的变更视为不可抗力，实际上，这背后还是有一定的改进空间的。你可以从建立快速有效的响应机制开始，同时多去总结和剖析这些需求背后的原因，毕竟老板要的是效果，那你就得用数据说话，更好地应对这些需求变更。
总结这一讲，我给你分享了 3 条锦囊妙计，建议你从达成一个最小共识开始入手，让团队意识到变更是有代价的。然后再往前一步，从源头开始深入，集中保障需求质量，争取第一次就把事情做对。另外，关于来自老板或客户的需求变更，你要快试错，巧妙应对。
最后，借用留言区一位同学，对本节需求变更方法论的 25 字箴言来总结：“以疏治堵，源头治理，顺势而为，闭环优化，数据说话。”
如果你把需求变更当作洪水猛兽，各种严防死守，那么最后你很有可能身心俱疲。但如果你换一个视角，从失败中汲取教训，变堵为疏，那么需求变更就不再是你的敌人。你会看到一个产品不断追求完美的底层动力，从而找到更多的锦囊，帮助这个产品走向更大的成功！
畅所欲言听了这么多锦囊，希望你聊一聊你和需求变更的“战斗”史，分享一下你在实战中最有效的方法！
欢迎你畅所欲言，我在留言区等你，也欢迎你把文章分享给你的朋友。

分享给需要的人，Ta购买本课程，你将得18元

生成海报并分享

赞 27

提建议

08 | 收尾：持续改进，从真正有效的复盘开始

10 | 风险管理：冰山下的风险，如何系统化应对？

 写留言

精选留言(34)

酷飞不会飞
2019-11-17
需求变更在一个项目里是不可或缺的一部分，也是项目趋于完善的自我矫正器，正确看待需求变更应该是项目经理必备的职业素能。一般会遇到两种需求变更，一种是项目进行中自我发现需求变更会更好的完善产品；另一种是外界压力下做出的需求变更。第一种可能更好的被接受，抵触情绪也会少很多。第二种来自甲方的压力或者老板的压力，要知道甲方、老板和项目经理看待问题的角度是不一样的，甲方更看重的是贴合自身利益，他不会考虑产品后续的扩展性，老板也许会考虑产品方面的诉求，但更多考虑的是公司战略层面的规划，因此，如何衡量这两者与产品之间的平衡性，其实非常难把握。堵不如疏，如果一直抵触无论对项目团队还是自身发展都是利大于弊的，一般情况下，如果需求变更不大，或者代价很小，可以快速试错，就算恢复相对也会容易很多；而如果变更比较大则需要深度挖掘内在需求，要知道除了产品经理和项目经理，外部其他人很难站在全局看待，也许我们可以提供更好的实现方案，尽可能将产品各方面考虑进去。另外，项目经理忌讳直接应需求的变更，再大的需求变更下，我们需要与团队更深入的沟通，这样才会将大家抵触情绪降到最低。
展开
作者回复: 你补充的特别好！
共 6 条评论
45
小文同学
2019-12-02
看完这一篇，我感觉到项目管理真的是比技术难得多。道理我们都懂，但是要做好还是不容易。我自己对于需求变更都是比较宽容的，认为要一个策划或产品在构思一份文档中直接构思到位，这和要求一个技术一口气写完一大段代码而不允许有bug是一样的。我作为技术一般要求自己做到这两样： 1、花时间和出需求的同学沟通，通过双向沟通确保自己完全明白需求的意思。同时根据自己业务上的经验，对需求可能发生变更的点直接质疑，反问，确保出需求的同学也知道明确自己的思路。(有时候出需求的同学蒙圈，自己想要的东西也不清楚，这样的需求基本上一定会改) 2、通过合理的设计模式和代码结构，让代码具备一定的可修改空间。这是我对技术同学的要求，如果对需求变更过于抵触，可能是技术同学代码本身就写得不好。最后还是要讲究团队间的默契，加班是所有人都一起留下来的，遇到上线的时候是所有人都不得离开的，这也算是变更的一种成本。
展开
作者回复: 换位思考，做到这两点不容易，为你点赞👍
共 4 条评论
20
Raymond吕
2019-12-23
雷老师的两条方法“老板需求响应小分队”和“给老板试错的机会”洞察了老板的需求，从更积极的视角去看待，对待变更，让PM和团队成员不在纠结做与不做，有没有价值。但回头想想，没有新需求，没有需求变更就真是我们期望的吗？试想没有需求变更的项目得多么“可怜”？项目管理的关键还是在于达成最终的目标，至于“路况”如何，so what？摘抄同学一条本节课的经典总结：需求变更的方法论（以疏治堵，源头治理，顺势而为，闭环优化，数据说话）
展开
14
MaxHu
2019-11-21
首先说下我的读后感：老师的针对需求变更的方法论（以疏治堵，源头治理，顺势而为，闭环优化，数据说话）很棒，也具有一定的普世性。从实例中也看到了老师落地的能力很强：在以完成项目目标和提效的共同愿景下，借力打力，团结一切可以团结的人，充分发挥团队的智慧，运筹帷幄，团队氛围和正能量不断提升。佩服老师的领导力和智慧。就需求变更的管理，考虑到需求变更频繁/种类不一/对系统影响层面不同/变更时间不同对工作量影响不同等等因素以及对历史变更数据分析，我们会对需求变更做分类建模和应对方案方向及建议审批链（宽泛的/方向性的/易懂/不断优化的），并提前和各个业务线产品UED技术开会沟通达成第一步共识（算打预防针，也算是让不同工种互通有无），为后面需求变更的快速沟通处理做个铺垫。针对这类建模思想在项目管理中的应用，老师是如何思考的？
展开
作者回复: 谢谢你总结的25字箴言！建模的思路也特别好，建模方法与项目管理的结合，需要有大量的数据作为积累，目前我们正在通过自研的项目管理平台，做到全面的在线化和精细化，未来一定会走到精细化的差别流程管理，甚至是智能化决策。
共 3 条评论
10
朋克是夏天的冰镇雪碧
2019-12-04
谢谢老师的点拨，我打算在部门年度总结的时候好好说一说这件事。我现在还遇到一个让我两难的事情，客户提出了一个需求，我认为是可以做的、合理的需求，而且我 demo 都已经写出来了，但是我的领导嫌麻烦，让我就跟客户说没法做。可是这个问题不解决，客户就不给我后面所需的资料，现在严重拖慢了项目的进度，请问老师这种情况我应该怎么做呢？
作者回复: 先弄清楚你的领导嫌麻烦的原因是什么，有哪些隐性成本是你尚且没能考虑到的，跟你的领导对齐认知，包括你认为对于客户及整体进度的影响，你的老板是否有共同的认识。其实反过来看，这也是一个机会，去深入了解你们之间认知差异的部分，先找把信息对齐，再对齐思路，你会对这个项目有不同的理解。
6
王鲁俊
2020-06-15
锦囊1适用大部分项目；精囊2适用大型的、复杂的项目；锦囊3适用来自老板和大客户需求变更频繁的项目；还学到一点，对齐认知，减少冲突的良药
5
桃子-夏勇杰
2019-11-16
如果团队还是组件团队或者后端团队，估计先要解决需求描述的问题，而这样的需求不清也会导致大量痛苦的变更。
3
亢（知行合一的路上）
2020-02-15
积极面对需求变更，好的建议，及时采纳；不确定的，小范围试错，用数据说话。架构设计时，要尽可能有扩展性、层次性，需求变动要控制在很小的范围内，不能牵一发动全身。但又不能一开始就过度设计，需求的变化也就促成了框架的更加强大。沟通很重要，面对不合理的需求时，要委婉、有理有据，实在不行就以退为进，让数据说话。要给自己留有余地，自己的认识也可能是错的。
作者回复: 赞！认识到最后一点不容易，产品和研发的思维方式有很大差异。
2
孙小梦
2021-09-27
作为开发来说，想要避免需求变更，那么在需求沟通阶段一定要进行深度的需求分析与沟通，确保理解需求的背景和需求内容，开发人员也需要具备一定的产品思维，了解产品的规则和头部竞品的产品设计，来进行自己所做的产品的需求分析和产品打磨。
1
Stephen
2021-05-15
怕就怕没有变更体系，没有啥成本，没有留下记录，改完又改回来。
1
牺牲
2020-04-13
如果不想需求变更，就使用“锦囊2”从源头解决它，需求产生过程就群策群力，达到一次做好。如果需求变更频繁，我们就使用“锦囊1”总结变更成本，达成最小共识，让变更更慎重，频次降低。如果需求无法拒绝，我们就使用“锦囊3”接受它，让它快速实现，用数据来制约变更。个人人为，1是最有效且最常用的方法，2是需要调整流程，动员团队实现。 3是最难的，对于本就快速紧张的迭代来说，还要抽出部分人力来应对“快速试错”。现在遇到的问题，大部分也在老板空降紧急需求上。毕竟也拒绝不了，“锦囊3”快速实现不失为一个好法子。
展开
1
阿昕
2019-12-02
「变堵为疏」的确是一个很好的思路，颇有大禹治水的架势，蓓格格讲得好。
作者回复: 哈哈，偷学，被你看出来了
1
朋克是夏天的冰镇雪碧
2019-11-21
老师，我所在的是一家 OA 软件公司，在给客户部署 OA 平台的过程中，需求变更可以说是家常便饭，有的时候可能一天就有十多条改动的事项。在我这里，改动所需要的代价往往不是很大，但是时间长了以后，某个地方改动过很多次，在测试的时候可能甚至都记不清这里究竟应该是什么样子了，和方案对不上的时候，我们都说不上来到底是我们配置错了还是后来客户提了要求。虽然改动的时候我们都有记录下来，但是好几个人你记一点我记一点，老实说真要查看记录文档的时候很难找到对应的那条记录，请问这种情况应该怎么办呢？
展开
作者回复: 你好，你所描述的这种变更频率，可以考虑用文档管理的工具来跟踪，我们用的是confluence，你也可以用石墨文档，历史记录的各个版本，谁改了什么非常清晰。
1
霸波儿奔
2019-11-16
这几个锦囊不错
作者回复: 嗯……
1
zw_learn_2
2019-11-16
我们团队现在有四条业务线同时进行，每天也会收到来自关键用户和大领导的一些任性需求（这些需求特点是必须做、抓紧做），不走规定的需求变更流程，这样搞得团队成员节奏很乱、怨声载道！针对需求变更，老师给出了锦囊妙计，下一步在团队内部实行一下看看能否改善我们的现状？真心希望有一位像您这样的领导😊
展开
作者回复: 谢谢，疏胜于堵，一步步来，你会找到好办法！
1
信怀义
2022-11-28 来自北京
变更无法避免，这个是前提；接受变更需要团队达成一致。
热血战士
2022-04-25
需求变更流程很简单，但是实际中为了敏捷，为了快速上线，很多小项目是研发，需求，设计，运维等一体化，这样就单独一个人直接面对客户的需求，客户很强势，变更有影响重来不考虑，这种情况该怎么破？
在路上
2021-11-07
最近再找项目管理方面的工作，重温老师的需求管理很有感触，经手的都是小项目，需求的管理很不完善，变更也是领导一言而绝。 Ps:箴言是20个
zhengxm_16
2021-07-24
中层管理者最重要的作用之一就是起到这种应对变更的润滑剂作用。
磉盘
2021-07-08
需求变更，是规避不了的。我们能做的就是事前考虑周全，改变开发模式，敏捷开发就是为频繁需求变更还存在的。

