09 | 需求变更：三个锦囊，让需求变更不再是洪水猛兽
该思维导图由 AI 生成，仅供参考
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文介绍了如何应对需求变更的方法，包括常见的需求变更流程和三个实战经验。作者首先分享了达成最小共识的重要性，通过深度复盘建立团队共识。其次，强调在需求源头把关，通过早期深度参与和需求检查来避免需求问题流到下游。最后，提到了在需求变更发生后的应对方法，通过请程序员吃炸鸡来缓解需求变更的压力。另外，文章还分享了源头治理的案例，以及快试错、巧应对的建议。总的来说，文章强调了从达成共识、源头治理和快试错三个方面应对需求变更的方法，以及如何更好地应对来自老板或客户的需求变更。文章内容丰富，建议读者从中学习如何更好地应对需求变更，提高团队的应变能力。
《雷蓓蓓的项目管理实战课》，新⼈⾸单¥59
全部留言(35)
- 最新
- 精选
酷飞不会飞需求变更在一个项目里是不可或缺的一部分，也是项目趋于完善的自我矫正器，正确看待需求变更应该是项目经理必备的职业素能。一般会遇到两种需求变更，一种是项目进行中自我发现需求变更会更好的完善产品；另一种是外界压力下做出的需求变更。 第一种可能更好的被接受，抵触情绪也会少很多。第二种来自甲方的压力或者老板的压力，要知道甲方、老板和项目经理看待问题的角度是不一样的，甲方更看重的是贴合自身利益，他不会考虑产品后续的扩展性，老板也许会考虑产品方面的诉求，但更多考虑的是公司战略层面的规划，因此，如何衡量这两者与产品之间的平衡性，其实非常难把握。 堵不如疏，如果一直抵触无论对项目团队还是自身发展都是利大于弊的，一般情况下，如果需求变更不大，或者代价很小，可以快速试错，就算恢复相对也会容易很多；而如果变更比较大则需要深度挖掘内在需求，要知道除了产品经理和项目经理，外部其他人很难站在全局看待，也许我们可以提供更好的实现方案，尽可能将产品各方面考虑进去。 另外，项目经理忌讳直接应需求的变更，再大的需求变更下，我们需要与团队更深入的沟通，这样才会将大家抵触情绪降到最低。作者回复: 你补充的特别好！
2019-11-17647
小文同学看完这一篇，我感觉到项目管理真的是比技术难得多。道理我们都懂，但是要做好还是不容易。 我自己对于需求变更都是比较宽容的，认为要一个策划或产品在构思一份文档中直接构思到位，这和要求一个技术一口气写完一大段代码而不允许有bug是一样的。我作为技术一般要求自己做到这两样： 1、花时间和出需求的同学沟通，通过双向沟通确保自己完全明白需求的意思。同时根据自己业务上的经验，对需求可能发生变更的点直接质疑，反问，确保出需求的同学也知道明确自己的思路。(有时候出需求的同学蒙圈，自己想要的东西也不清楚，这样的需求基本上一定会改) 2、通过合理的设计模式和代码结构，让代码具备一定的可修改空间。这是我对技术同学的要求，如果对需求变更过于抵触，可能是技术同学代码本身就写得不好。 最后还是要讲究团队间的默契，加班是所有人都一起留下来的，遇到上线的时候是所有人都不得离开的，这也算是变更的一种成本。作者回复: 换位思考，做到这两点不容易，为你点赞👍
2019-12-02421
Tux Hu首先说下我的读后感：老师的针对需求变更的方法论（以疏治堵，源头治理，顺势而为，闭环优化，数据说话）很棒，也具有一定的普世性。从实例中也看到了老师落地的能力很强：在以完成项目目标和提效的共同愿景下，借力打力，团结一切可以团结的人，充分发挥团队的智慧，运筹帷幄，团队氛围和正能量不断提升。佩服老师的领导力和智慧。 就需求变更的管理，考虑到需求变更频繁/种类不一/对系统影响层面不同/变更时间不同对工作量影响不同等等因素以及对历史变更数据分析，我们会对需求变更做分类建模和应对方案方向及建议审批链（宽泛的/方向性的/易懂/不断优化的），并提前和各个业务线产品UED技术开会沟通达成第一步共识（算打预防针，也算是让不同工种互通有无），为后面需求变更的快速沟通处理做个铺垫。针对这类建模思想在项目管理中的应用，老师是如何思考的？作者回复: 谢谢你总结的25字箴言！建模的思路也特别好，建模方法与项目管理的结合，需要有大量的数据作为积累，目前我们正在通过自研的项目管理平台，做到全面的在线化和精细化，未来一定会走到精细化的差别流程管理，甚至是智能化决策。
2019-11-21311
朋克是夏天的冰镇雪碧谢谢老师的点拨，我打算在部门年度总结的时候好好说一说这件事。我现在还遇到一个让我两难的事情，客户提出了一个需求，我认为是可以做的、合理的需求，而且我 demo 都已经写出来了，但是我的领导嫌麻烦，让我就跟客户说没法做。可是这个问题不解决，客户就不给我后面所需的资料，现在严重拖慢了项目的进度，请问老师这种情况我应该怎么做呢？作者回复: 先弄清楚你的领导嫌麻烦的原因是什么，有哪些隐性成本是你尚且没能考虑到的，跟你的领导对齐认知，包括你认为对于客户及整体进度的影响，你的老板是否有共同的认识。 其实反过来看，这也是一个机会，去深入了解你们之间认知差异的部分，先找把信息对齐，再对齐思路，你会对这个项目有不同的理解。
2019-12-047
亢（知行合一的路上）积极面对需求变更，好的建议，及时采纳；不确定的，小范围试错，用数据说话。 架构设计时，要尽可能有扩展性、层次性，需求变动要控制在很小的范围内，不能牵一发动全身。但又不能一开始就过度设计，需求的变化也就促成了框架的更加强大。 沟通很重要，面对不合理的需求时，要委婉、有理有据，实在不行就以退为进，让数据说话。要给自己留有余地，自己的认识也可能是错的。作者回复: 赞！认识到最后一点不容易，产品和研发的思维方式有很大差异。
2020-02-152
阿昕「变堵为疏」的确是一个很好的思路，颇有大禹治水的架势，蓓格格讲得好。作者回复: 哈哈，偷学，被你看出来了
2019-12-021- 朋克是夏天的冰镇雪碧老师，我所在的是一家 OA 软件公司，在给客户部署 OA 平台的过程中，需求变更可以说是家常便饭，有的时候可能一天就有十多条改动的事项。 在我这里，改动所需要的代价往往不是很大，但是时间长了以后，某个地方改动过很多次，在测试的时候可能甚至都记不清这里究竟应该是什么样子了，和方案对不上的时候，我们都说不上来到底是我们配置错了还是后来客户提了要求。 虽然改动的时候我们都有记录下来，但是好几个人你记一点我记一点，老实说真要查看记录文档的时候很难找到对应的那条记录，请问这种情况应该怎么办呢？
作者回复: 你好，你所描述的这种变更频率，可以考虑用文档管理的工具来跟踪，我们用的是confluence，你也可以用石墨文档，历史记录的各个版本，谁改了什么非常清晰。
2019-11-211 
霸波儿奔这几个锦囊不错作者回复: 嗯……
2019-11-161
zw_learn_2我们团队现在有四条业务线同时进行，每天也会收到来自关键用户和大领导的一些任性需求（这些需求特点是必须做、抓紧做），不走规定的需求变更流程，这样搞得团队成员节奏很乱、怨声载道！ 针对需求变更，老师给出了锦囊妙计，下一步在团队内部实行一下看看能否改善我们的现状？ 真心希望有一位像您这样的领导😊作者回复: 谢谢，疏胜于堵，一步步来，你会找到好办法！
2019-11-161- Geek_7824a7我对需求变更的态度一致都是严防死守，听了蓓蓓老师的课换个角度来思考变更的问题，突然觉得和业务部门没有那么争锋相对了
作者回复: 有时，要解决复杂问题，通常需要换个思维方式。需求变更不是我们的敌人，去看变更背后的诉求。
2020-04-19