2019-11-17需求变更在一个项目里是不可或缺的一部分，也是项目趋于完善的自我矫正器，正确看待需求变更应该是项目经理必备的职业素能。一般会遇到两种需求变更，一种是项目进行中自我发现需求变更会更好的完善产品；另一种是外界压力下做出的需求变更。
第一种可能更好的被接受，抵触情绪也会少很多。第二种来自甲方的压力或者老板的压力，要知道甲方、老板和项目经理看待问题的角度是不一样的，甲方更看重的是贴合自身利益，他不会考虑产品后续的扩展性，老板也许会考虑产品方面的诉求，但更多考虑的是公司战略层面的规划，因此，如何衡量这两者与产品之间的平衡性，其实非常难把握。
堵不如疏，如果一直抵触无论对项目团队还是自身发展都是利大于弊的，一般情况下，如果需求变更不大，或者代价很小，可以快速试错，就算恢复相对也会容易很多；而如果变更比较大则需要深度挖掘内在需求，要知道除了产品经理和项目经理，外部其他人很难站在全局看待，也许我们可以提供更好的实现方案，尽可能将产品各方面考虑进去。
另外，项目经理忌讳直接应需求的变更，再大的需求变更下，我们需要与团队更深入的沟通，这样才会将大家抵触情绪降到最低。展开作者回复: 你补充的特别好！
8
2019-11-16如果团队还是组件团队或者后端团队，估计先要解决需求描述的问题，而这样的需求不清也会导致大量痛苦的变更。 2
2019-12-23雷老师的两条方法“老板需求响应小分队”和“给老板试错的机会”洞察了老板的需求，从更积极的视角去看待，对待变更，让PM和团队成员不在纠结做与不做，有没有价值。
但回头想想，没有新需求，没有需求变更就真是我们期望的吗？试想没有需求变更的项目得多么“可怜”？项目管理的关键还是在于达成最终的目标，至于“路况”如何，so what？
摘抄同学一条本节课的经典总结：需求变更的方法论（以疏治堵，源头治理，顺势而为，闭环优化，数据说话）展开 1
2019-11-16这几个锦囊不错作者回复: 嗯……
1- 2019-11-16我们团队现在有四条业务线同时进行，每天也会收到来自关键用户和大领导的一些任性需求（这些需求特点是必须做、抓紧做），不走规定的需求变更流程，这样搞得团队成员节奏很乱、怨声载道！
针对需求变更，老师给出了锦囊妙计，下一步在团队内部实行一下看看能否改善我们的现状？
真心希望有一位像您这样的领导😊作者回复: 谢谢，疏胜于堵，一步步来，你会找到好办法！
1 
2019-12-04谢谢老师的点拨，我打算在部门年度总结的时候好好说一说这件事。我现在还遇到一个让我两难的事情，客户提出了一个需求，我认为是可以做的、合理的需求，而且我 demo 都已经写出来了，但是我的领导嫌麻烦，让我就跟客户说没法做。可是这个问题不解决，客户就不给我后面所需的资料，现在严重拖慢了项目的进度，请问老师这种情况我应该怎么做呢？作者回复: 先弄清楚你的领导嫌麻烦的原因是什么，有哪些隐性成本是你尚且没能考虑到的，跟你的领导对齐认知，包括你认为对于客户及整体进度的影响，你的老板是否有共同的认识。
其实反过来看，这也是一个机会，去深入了解你们之间认知差异的部分，先找把信息对齐，再对齐思路，你会对这个项目有不同的理解。
2019-12-04老板开会，经典台词，数据有吗作者回复: 哈哈
2019-12-03老师你好，我想问问关于锦囊2中的上墙文化是什么形式？上墙的内容是那些（排期、设计图、交互图）？驻足观望的程序员能根据墙上的内容就能理解整个产品或者某个模块的设计并能提出修改意见？作者回复: 当时是全站的重构，策划设计们在里面，从最初每个功能的承载页面开始梳理，抽取出公共功能重新设计，包括页面跳转逻辑图，打印出来贴在墙上，便于他们讨论。
而这些中间过程的产物，也让其他角色更早地介入进来，提了很多意见，比如测试觉得这里有坑，这么设计的话，以前的某某客户的需求就无法满足了，提早就改掉了 1
2019-12-02看完这一篇，我感觉到项目管理真的是比技术难得多。道理我们都懂，但是要做好还是不容易。
我自己对于需求变更都是比较宽容的，认为要一个策划或产品在构思一份文档中直接构思到位，这和要求一个技术一口气写完一大段代码而不允许有bug是一样的。我作为技术一般要求自己做到这两样：
1、花时间和出需求的同学沟通，通过双向沟通确保自己完全明白需求的意思。同时根据自己业务上的经验，对需求可能发生变更的点直接质疑，反问，确保出需求的同学也知道明确自己的思路。(有时候出需求的同学蒙圈，自己想要的东西也不清楚，这样的需求基本上一定会改)
2、通过合理的设计模式和代码结构，让代码具备一定的可修改空间。这是我对技术同学的要求，如果对需求变更过于抵触，可能是技术同学代码本身就写得不好。
最后还是要讲究团队间的默契，加班是所有人都一起留下来的，遇到上线的时候是所有人都不得离开的，这也算是变更的一种成本。展开作者回复: 换位思考，做到这两点不容易，为你点赞👍
2019-12-02「变堵为疏」的确是一个很好的思路，颇有大禹治水的架势，蓓格格讲得好。作者回复: 哈哈，偷学，被你看出来了
- 2019-11-21老师，我所在的是一家 OA 软件公司，在给客户部署 OA 平台的过程中，需求变更可以说是家常便饭，有的时候可能一天就有十多条改动的事项。
在我这里，改动所需要的代价往往不是很大，但是时间长了以后，某个地方改动过很多次，在测试的时候可能甚至都记不清这里究竟应该是什么样子了，和方案对不上的时候，我们都说不上来到底是我们配置错了还是后来客户提了要求。
虽然改动的时候我们都有记录下来，但是好几个人你记一点我记一点，老实说真要查看记录文档的时候很难找到对应的那条记录，请问这种情况应该怎么办呢？展开作者回复: 你好，你所描述的这种变更频率，可以考虑用文档管理的工具来跟踪，我们用的是confluence，你也可以用石墨文档，历史记录的各个版本，谁改了什么非常清晰。
2019-11-21首先说下我的读后感：老师的针对需求变更的方法论（以疏治堵，源头治理，顺势而为，闭环优化，数据说话）很棒，也具有一定的普世性。从实例中也看到了老师落地的能力很强：在以完成项目目标和提效的共同愿景下，借力打力，团结一切可以团结的人，充分发挥团队的智慧，运筹帷幄，团队氛围和正能量不断提升。佩服老师的领导力和智慧。
就需求变更的管理，考虑到需求变更频繁/种类不一/对系统影响层面不同/变更时间不同对工作量影响不同等等因素以及对历史变更数据分析，我们会对需求变更做分类建模和应对方案方向及建议审批链（宽泛的/方向性的/易懂/不断优化的），并提前和各个业务线产品UED技术开会沟通达成第一步共识（算打预防针，也算是让不同工种互通有无），为后面需求变更的快速沟通处理做个铺垫。针对这类建模思想在项目管理中的应用，老师是如何思考的？展开作者回复: 谢谢你总结的25字箴言！建模的思路也特别好，建模方法与项目管理的结合，需要有大量的数据作为积累，目前我们正在通过自研的项目管理平台，做到全面的在线化和精细化，未来一定会走到精细化的差别流程管理，甚至是智能化决策。
2019-11-18我们老板直接介入开发小组，对着开发的面说这个变更我明天就要。。。
2019-11-17看大家团队人那么多真羡慕，需求变更我只帮他分析可行性及需要的时间，老板觉得可以咱就弄，都你的钟，可你开心就好
2019-11-17后两条太有用了！！！领导经常有各种想法，这下通过灰度实现数据说话。第二天产品和业务目前职能型组织架构，小PM扛不住，略有难度，可以找leader出面试试。作者回复: 很开心能帮到你！有难度的变化，是需要做一层一层做铺垫的，找到早期支持者很重要，你可以关注下第13讲，我会讲如何引入变化。
2019-11-16锦囊 3 对我帮助很大。我就是我们团队的老板需求响应小分队。😊作者回复: 厉害了👍