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