2019-04-11需求变更的多少取决于产品团队、研发团队，甚至测试团队对需求的理解程度。理解越透彻，需求变更越少，很容易在做项目的过程中及时发现问题、解决问题，这就相当于把可能发生的变更分散到日常工作中去，使其不会有太多明显的变更，降低项目延期的可能性。
宝玉老师讲到变更流程的规范化，确实深有体会。有些产品经理不按套路出牌，遇到用户提出产品需求问题，都是一口气答应下来，不去认真分析，也不去与用户探讨，觉得为了公司利益而满足客户需求是理所应当的，不加思考原原本本的将需求扔给研发，然后搬把椅子一脸焦急的看着一脸着急的研发人员。其实，有的时候加班就是这样产生的，无组织、无纪律、乱弹琴，遭殃的是患难兄弟，埋怨的是公司不人道。
我体会过产品需求流程比较规范的公司，大家都知道什么时候该做什么，绝不跨部门或越级指挥，一切按产品需求流程办事，在搭配上比较强大的执行力，每个人工作时间的工作内容都是饱和的，到下班的时候绝不留恋工作，走慢点你就是最后一个下班的。
另外，在谈论需求变更的时候，要学会拒绝，让用户知道你拒绝得很在理，有可以理解的难处；也要学会接纳，在某些合理、无伤大雅的需求上要满足用户的存在感。这样在进行项目交付的时候，即使项目完成度不是很理想，也会因你个人处事得当而加分，很容易的拿到项目的验收报告。展开作者回复: 👍很棒的分享！
所以说项目管理是艺术，其中的平衡很难完全是一门艺术！ 1 7- 2019-04-18三句箴言：
走一步想三步
能配置不定制
不要相信产品经理的“绝对”作者回复: 👍谢谢分享
这三句绝大部分时候都适用的，我觉得也要适当结合项目情况，有些时候考虑太远、做多手准备，容易做无用功。 3 
2019-04-11老师，我参与的项目遇到了这样的情况，因为老板要求项目交付时间要提前，导致了大量的需求变更和重新设计，项目看似提前完成了，但是功能却被阉割了，后续项目的改进难度变的非常大，这种情况该怎么办啊？作者回复: 砍掉功能保进度很正常。只是不知道改进难度大的原因是什么？因为没有时间做架构设计？还是因为大的功能还没做？
还是需要具体情况具体分析，你可否再发一条留言讲一下具体难度在哪，才好给具体建议。 3
2019-05-12客户需求频繁变更，大领导迫于客户压力全盘答应，导致开发节奏被打乱，除了量化风险上报之外，还有什么好办法？作者回复: 需要和你的领导私下协商，需要在他的帮助下一起作出一些调整：
1. 要设立流程提高客户变更需求的成本，可以需求变更，但不能太过于频繁随意
2. 缩短开发周期，采用迭代模型或者敏捷开发，2-4周发布一个版本，每个版本实现当前已经确定的最重要的需求，在一个版本内不接受需求变化，变化的需求放在下一个迭代中实现 2- 2019-04-12老师今天讲的现象，实际上是软件开发部门最头痛的事情。通过三个手段来解决需求变更问题，总结得太到位了。按照软件质量的金三角理论，需求变更，就相当于范围变大，必然导致成本上升或者时间增加，否则，就是质量下降。
比如说成本问题，由于业务领导对于软件开发没有成本意识，而且不考核他们的成本，所以他们可以随意变更需求，IT部门有苦难言。为了减少这个问题，我们尝试让业务部门在业务蓝图（需求）文档上签字，但对于强势的业务部门，依旧见效甚微。后来，又在发布频次上进行考核，减少发布频次。但结果又带来了用户真实的需求变更不能及时获得满足，直接影响业务。
业务变更是必然的，IT部门必须快速响应用户需求，这是摆在IT面前的必然挑战，无法回避。
真正掌握在IT部门的办法，只能是第三种选择：
“降低响应需求变更的成本”。
因此，我们开始建立统一应用框架(比如单体应用的java框架，微服务框架等）、建立CICD环境、推进云的建设，加快环境搭建速度，引入自动化质量工具，加快系统缺陷的检出速度，减少技术债务，甚至建立一些业务中台，加大业务的下沉力度和技术的上浮力度，加大技术和业务的复用，建立更高效的项目管理体系和工具平台，减少技术和业务的沟通成本。
但是这样的基础建设长路漫漫，见效很慢。不知老师有没有这方面的经验分享，比如采取哪些措施，优先级是什么，来达到降低响应需求变更的成本的目的，这里又有哪些困难，如何克服。等等。
谢谢展开作者回复: 基础建设方面我的一点建议：
基础建设困难在于短期内会减慢开发速度，是和业务冲突的，如果业务部门不支持，会很难推进，压力很大。所以可以考虑分成短期、中期、长期三类，逐步做。
首先，在不影响业务的前提下，优先做一些跟业务相关能短期取得正面效果的事，比如工具的使用，管理平台的搭建。这样取得效果后相当于为你自己积累了声望，以后推进其他事情会更容易。
然后推进流程规范的建设，比如CICD、代码审查，这类事中期可以取得效果，但也需要投入大量精力保障制度的执行。
跟开发相关的事是短期看不到效果长期的事，低调的做，一点点做，最好有专门的小团队做，比如你说的统一框架的事。这类事情阻力很大，因为既要兼顾新业务的推进，又要还大量精力对现有业务的改造。做成了绝对大功一件，没做成是要背锅的。所以低调一点，做成后再高调表表功，万一没做好或没达到预期就总结经验，下次再战，也不会导致太大影响。
供参考！ 2 
2019-04-111.提升需求确定性：设计高保真的原型，如用axure，不仅仅是画框图，还要加各种响应事件等；
2.提高需求变更的成本：提前约定变更制度，签字画押；
3.降低响应需求变更的成本：提高技术框架水平。
以上是通过产品、流程、技术三个方面解决需求变更问题。作者回复: 👍很好的总结
2
2019-10-18老师！我的组长脑子有问题，经常干涉设计，前面确定了需求，等开发完又修改，总是说话跟放屁一样！还是巨婴！任性，说我就是要这样，很多开发和设计都好讨厌他，敢怒不敢言！请原谅我留言粗鲁不文明！供应商的人天花的是公司的钱，他没成本意识，这样一手遮天的人 怎么应对？作者回复: 首先，我觉得就你自己来说，先尝试利用软件工程的知识做好你应该做的，用科学的方法去管理这类事情，包括管理你的领导。比如我在前一条回复建议的：多确认、帮助领导意识到变更成本，提高他变更的成本。不管结果怎么样，你都可以从科学认真做事的方式中获得提高和成长。
然后，对于国内的大部分公司来说，领导发言权很大的，能治领导的就只有更大的领导了，而且除非是严重错误，否则大领导也不会轻易换人。也可以考虑收集一些事实，越级投诉。但这样做风险比较大，慎重考虑。
最后，就是用脚投票，骑驴找马，换组或者换公司。 1
2019-09-171、敏捷是美国人提出的，有一点很重要：拥抱变化。而中国需求变更的确很高，而中国人为什不拥抱变化？
2、欧美软件企业的确加班比中国企业少得多，除了需求变更多，还有什么吗？作者回复: 1. 敏捷开发确实是美国人提出的，但是其实并不必可以区分中国人美国人，因为敏捷开发是针对软件开发的，而软件开发是有很多共性的，并不分中国人项目还是美国人项目。
敏捷开发的拥抱变化，正是通过自动化提高效率，通过缩短开发周期，来优先做核心功能，来快速发布快速迭代，从而快速响应需求的变化。
2. 还有文化上的差异，比如美国人很注意家庭生活；另外还有工会的制衡等等因素。 1 1
2019-04-24宝玉老师，您这边有没有做需求调研的工具或表格之类的，能更好的把握住客户的真实需求。作者回复: 抱歉我手头没有。
人人都是产品经理网站上一个“需求调研”的Tag，里面有很多相关的文章。
比如其中这篇文章《只需8步，需求调研表的标准制作流程》http://www.woshipm.com/pmd/407048.html 推荐你可以看看。 1
2019-04-15很头疼 ,开发快完成时 ,老板突然想到了个很好玩的点子,让加需求作者回复: 告诉他点子很好，等我们这个Sprint/版本完成，马上加上 ：）
1
2019-04-12今日学习应对需求变更的三种方式：
提升需求确定性；
提高需求变更的成本；
降低响应需求变更的成本 1
2019-04-11听了今天的课程，我收获的应对需求变更的方案有3
1.用低成本的方式提前收集到变更信息，以提前预知变更
2. 提高变更需求方的变更成本
3. 对系统结构要求较高，就是研发工程师在可预知范围内，尽量可配置化需求作者回复: 👍很好的总结
1
2019-04-11把自己变成客户(深入了解客户)
，可行吗？作者回复: 我觉得就算假装自己变成客户，也得要是懂客户能说服客户才有用。
1
2019-04-11给政府部门做业务软件，也配置了变更流程，可是很多时候并没有效果，领导说不满意要改就得改，这个领导满意了，另一个领导又有意见...很多时候销售,项目经理 为了维护客户关系,研发这边就得让步,不改的也得改😂作者回复: 是的，光从流程上还不够，经常有绕过流程的情况发生。还可以结合前面讲的金三角，看是不是可以增加成本或者减少其他需求。
1
2020-01-04两年才开始考虑做cms 够慢的。。- 2020-01-041 没有代码的代码最好维护。
- 2020-01-04通过约定＞配置，减少无聊的配置管理。
- 2019-11-27深有感触，需求分析不到位，变更控制不到位，对团队是灾难！
- 2019-04-23做需求变更规范的目的是提高客户对需求的重视程度，而不是阻止客户提出变更。
需求变更规范明确变更处理流程、范围和费用。需求变更规范最好由双方领导签字确认。
人做事就会犯错，不要事事较真，灵活处理，良好的合作关系很重要。作者回复: 👍是的，需求变更规范起来，目标还是为了共同努力开发出高质量的软件，而不是为了阻止客户变更！
2019-04-18多谢老师，很受益。
自己在互联网公司，很多时候需求经常变更，是需求沟通的人或制定方案的人水平不行，觉得需求变更很方便，走一步算一步，导致来回反复。（规范需求变更流程）
另外，很多程序员对自己不自信，觉得很简单的变更，随手就改了，觉得自己时间很廉价，殊不知，改动一个点，会涉及单测，继承测试等一系列工作，如果省略这些步骤，就会造成系统bug等等（变更成本高）作者回复: 是的，变更是有成本的，其实成本不低的，需要让程序员和PM都有这个意识。