极客时间已完结课程限时免费阅读

20 | 如何应对让人头疼的需求变更问题？

20 | 如何应对让人头疼的需求变更问题？-极客时间

20 | 如何应对让人头疼的需求变更问题？

2019-04-11 宝玉 来自北京
《软件工程之美》
课程介绍

讲述：宝玉

时长16:44大小15.28M

你好，我是宝玉，我今天分享的主题是：如何应对让人头疼的需求变更问题？
我以前在国内做开发的时候，加班加点是家常便饭。这几年在美国工作，极少加班，但是产出却并没有下降，所以我一直在思索其背后的原因。这里面涉及因素很多，包括大环境、管理水平、配套设施等，但是有一个因素至关重要，那就是需求变更。
在国内很多软件公司，需求变更是常态，开发到一半，很多原始需求就发生了变化，这时候当初的设计已经不能满足要求了，很多代码需要修改，不得不加班加点来赶上进度。
反观不加班的美国公司，需求确定后很少变更。这样开发人员就可以针对需求有良好的架构设计，而不用考虑太多可能的变更，从容地在项目计划的时间内完成任务，而不需要加班加点。
在需求变更这个事情上，没有赢家，每个人都是受害者。
程序员自己辛苦的工作白费了，得不到成就感，因为频繁变更的需求，不得不在设计的时候考虑很多可能的变更，导致代码臃肿，代码质量降低，加班加点成了常态。甚至有人说：“杀一个程序员不需要用枪，改三次需求就可以了！”
产品经理也觉得很委屈：“客户要改，我有什么办法？”程序员和产品经理似乎变成了两个对立的岗位，程序员怪产品经理乱改需求，产品经理觉得是客户造成的，人人都觉得自己委屈。客户同样不满意，觉得做出来的软件不是他想要的，进度总是在延后，还想加钱？
既然大家都不满意，那么我们就需要想办法去改善，这也是软件工程这门学科存在的目的和意义。
目前也已经有很多管理需求变更的解决方案，比如这两个常见的解决方案。
方案一：增强需求变更流程，让需求变更规范起来。
这个方案简单来说，就是通过严格的流程，来避免一些没有意义的变更，从而达到管理需求变更的目的。
方案二：快速迭代，缩短版本周期。
这个方案是另一个思路，就是将大的功能拆分，每个版本周期仅实现一部分功能需求，周期较短，这样需求发生变更时，就可以快速响应。
不过，在看到这两个方案后，我还是希望你不满足于当前的答案，自己停下来思考一下这两个问题：
这些方案是否解决了你当前项目的问题？
如果换一个项目环境，当前方案是否依然适用？
之所以要思考这样的问题，是因为对于像软件工程这样偏理论知识的学习，你一定不要仅仅停留在了解有什么样的解决方案上，而是要追本溯源，研究问题背后的原因，研究理论背后的来龙去脉。
因为，就算你记住了再多的解决方案，换个项目环境可能就不适用了。所以我们要多去思考和分析逻辑，这样未来遇到类似的问题时，才可以做到对症下药，选择合适的解决方案，甚至在没有现成解决方案的情况下，能自己创造合适的解决方案。

为什么建筑工程中少有需求变更？

要解决需求变更的问题，你首先要知道，软件开发行业中的需求变更是怎么来的。
我很喜欢拿软件工程和建筑工程进行对比，你可以思考一下，同样是工程，建筑项目也是有需求变更的，但却不会像软件项目这么频繁和失控。为什么呢？
我总结一下，这里有两个主要原因：需求的确定性和需求变更的成本。

原因一：需求的确定性

建筑需求是很具象的，而软件工程的需求是抽象的。所以建筑项目里面，无论是提出需求还是变更需求，客户和施工方都明确地知道他们想要什么。
软件需求则经常是抽象、模糊、不精确的，模糊不清的需求导致在软件开发有了雏形后，才慢慢想清楚真正的需求是什么，从而导致需求变更。
举个例子，客户最开始对软件界面的颜色是没有任何要求的，当第一版本的软件给客户看的时候，客户觉得白色背景太难看了，希望换成蓝色的；第二版本换成蓝色后，客户现在已经觉得黄色更好看，希望改成黄色背景；第三版本的时候，产品经理担心客户还想换颜色，就直接做成了换皮肤功能，用户可以自己选择颜色，客户还是不满意，问能不能把背景换成图片……
是不是很熟悉？类似的事情其实经常发生在我们日常的工作场景里。

原因二：需求变更的成本

建筑项目里面的需求变更，我们都很容易和成本挂钩，因为这些东西已经是生活常识了。而与此相对的是，很多人，包括很多老板都对软件项目需求变更导致的成本增加缺少系统认识。
举个例子，装修房子的时候，如果墙面已经刷成白色了，但是客户想都刷成蓝色，那么他会很清楚，这涉及一系列成本：需要重新购买涂料、需要找人重新粉刷。
但换成一个软件项目，客户想把界面的白色背景换成蓝色的，他会觉得这是很简单也是理所当然的，甚至产品经理也会这么想，他会对程序员这么说：“不就是换个颜色吗？几行代码的事，客户让换就换了嘛！”
但是实际上，软件项目的需求变更，哪怕是换一个背景颜色，同样是要涉及成本的：需要修改所有涉及背景颜色的代码，需要更新相关测试代码，还需要对涉及的界面重新测试。
你可以说这成本是架构设计水平不到家导致的，但是如果设计时就考虑到要有支持换背景颜色的功能，那么开发的工作量从一开始就上去了，成本同样是提升了。
回到文章开始时我们提到的美国程序员不加班的问题，为什么美国的产品经理不敢随意更改需求？因为在美国很多 IT 公司都是工程师文化，工程师相对比较有话语权，正常情况下是不会加班加点的，所以产品经理变更需求的成本很高，在确定需求时，必须慎之又慎。

如何解决需求变更问题？

说完了原因，咱们再来看看解决方案。
首先，你需要意识到，在软件项目开发中，需求变更其实是不可避免的，一味抵制需求变更也是不可取的。你能做的就是利用软件工程的知识，理解需求变更背后深层次的原因，找到合适的方案来改善，积极拥抱合理的需求变化，减少不必要的需求变更。这是大的前提条件，也是共识的基础。
好，既然引起需求频繁变更的原因我们已经清楚了，那么，怎样有针对性地想解决方案呢？这里你也不妨停下来思考一下，你会想到哪些办法？
我的经验是从源头着手，既然需求变更的原因是需求不确定和需求变更成本太低，那么我们就针对性地提出相应的解决方案：
提升需求确定性，把需求分析做好，减少需求变更；
提高需求变更的成本，让客户或者产品经理不能太容易就变更需求，这样就可以达到减少需求变更的目的。
但在实施的时候，我们会发现一个问题，假如一味提高需求变更的成本，会让客户满意度下降，也造成了产品经理和开发人员之间的对立，不利于项目协作。
所以我们从另一个角度思考：需求变更之所以让你痛苦不堪，也是因为需求变更让项目成员付出了高昂的代价，例如返工、加班，如果我们可以低成本地响应需求变更，那么一样可以达到管理需求变更的效果。
所以解决方案上可以再加上一条：
降低响应需求变更的成本，可以方便快捷地响应需求变更。
接下来，我来举一个在实际项目遇到的案例，我们一起来分析一下，通过对这个需求变更场景的分析，来解决以上提到的这些问题。

案例分析

我有个大学同学叫加龙，毕业后自己开了个公司，早些年企业建站火的时候专门接企业网站的活。刚开始的时候很艰苦，也没几个人，甚至都没有专门的产品经理。
开发流程比较简单，就是先把项目谈下来，客户提一个建站的需求，然后他们去开发网站，开发好了拿给客户演示。而客户在看到网站演示后，几乎每次都会提出很多变更的需求，例如说颜色变一下、布局变一下、给留言功能加上关键字过滤功能等等。客户还喜欢直接在 QQ 上找负责开发的程序员，让给改一下。
创业初期，加龙同学真的是不容易，每天和几个程序员一起加班加点，就是为了应对客户这种频繁变更的需求。如果你是加龙，参考前面总结的几种解决方案，你会怎么做？
加龙作为软件工程专业毕业的学生，我觉得他当时运用软件工程知识去改善需求变更问题上是做得非常好的。他其实并没有采用一个单一的解决方案，而是分阶段逐步改进。
第一步：规范变更流程，提升客户变更成本。
加龙其实也知道，通过提升需求确定性，做好需求分析，和客户多沟通确认，是可以有效减少需求变更的。但是他当时确实人手太有限，也没有专业的产品经理，不能短时间内去提升需求分析、产品设计的水平，所以他第一步选择提升客户变更需求的成本，这样可以马上产生效果。
于是在后面的项目中，在和客户签订合同时，他会和客户约定，如果有需求变更，先统一提交到他那里，然后他甄别后再决定是否做，什么时候做，是否要重新签订新的附加合同（增加额外费用）。通过制定一系列标准，让双方合作的流程变得更规范。
这样，程序员就可以专注于开发，也不会因为频繁的需求变更影响进度，大家不用那么累，收入也在稳步上升。但是需求变更的情况还是时有发生。
第二步：用原型设计低成本响应需求变更；做好需求分析和确认，减少需求变更。
加龙在挺过最艰难的创业初期后，雇佣了一个全职的产品经理，专门去和客户确认需求。这个产品经理很专业，每次在了解完客户的需求后，不急于让程序员马上去写代码，而是自己先用 Axure 这样的原型设计工具，做一个简单的交互原型，给客户演示。
于是客户会针对原型的效果提出一些修改意见，他再快速地修改原型，这样反复确认，等到客户没有什么修改意见后，再让开发着手实现。
通过原型设计的方式，不仅可以方便地与客户沟通需求，还可以灵活响应需求变更。
通过提升需求确定性，加龙的公司进一步降低了需求变更的情况发生，营收又上了一个台阶，又增加了几个程序员和产品经理。
第三步：通过灵活的架构和强大的配置，低成本响应客户需求变更。
加龙公司经过两年的发展后，敏锐地发现其实大部分企业网站的功能都是很相似的，主要差别还是在界面样式上。
这些年大部分网站的开发其实都是把前一个网站复制一份，修修改改，但是这样还是效率太低，如果可以做到定制化，就可以更高效地定制网站。
于是加龙从公司抽调了几名骨干程序员，成立了一个专门的项目组，把这两年做的网站类型做了分析，做了一套建站系统，有点类似于后来流行的像 WordPress 这样的博客系统，可以通过换皮肤的的方式来定制界面，通过插件的方式增加功能。
由于前期积累充分，大约半年后他们就开始使用这套系统去建站，一下子就把建站的成本大大降低啦。而且当客户的需求有变化时，只要后台做简单的配置就可以马上支持需求变更。
但是这个模式也有问题，就是有些特别个性化的定制需求，还是满足不了。不过这也没关系，对于需要个性化的客户，要么增收额外的费用，要么就直接放弃掉。
如果咱们对他这三步采取的方案做一个总结，还就是我前面说的三个方案：
提升需求确定性；
提高需求变更的成本；
降低响应需求变更的成本。
只不过他根据公司不同阶段的特点，来灵活运用。这就是我的同学加龙在处理需求变更时分阶段采取的方案，是不是跟你想的一样？

总结

今天我通过对比建筑工程中的需求变更，和你一起分析了软件工程中需求变更产生的原因。需求频繁变更，主要是由于需求不确定和变更成本过低导致的。并由此提出了三种不同的解决方案。
提升需求确定性，来减少需求的变更。这种方案的优势就是对需求理解透彻，后期返工少，缺点是对产品经理的需求分析能力要求很高。
提高需求变更的成本，规范需求变更流程，减少需求变更。这种方案的优势就是可以马上起到效果，缺点就是过于繁琐的流程不利于项目协作。
降低响应需求变更的成本，积极应对需求变更。这种方案的优势在于可以快速响应需求变更，能快速试错尽快调整，缺点在于对软件架构和项目管理要求比较高。
就像我的同学加龙那样，你可以根据项目的实际情况，对比这些方案的优缺点，选择适合你的解决方案。
例如你是做企业外包项目的，客户不懂又喜欢瞎掺和，那么就可以适当提高变更成本，甚至每次变更都可以计入项目成本中；如果你是做互联网项目，需要快速推出产品，那么就可以选择降低响应变更成本，快速迭代，快速试错，尽快调整。
如果你是项目经理，希望你通过这次对需求变更的学习，能针对项目特点，制定合适的需求变更流程，选择适合项目的开发模式，管理好需求变更，从而提升整个项目的开发效率，避免重复返工导致的浪费。
如果你是产品经理，希望你通过这次学习，对需求变更导致的成本有很高的重视，努力提升专业水平，勤于和客户、开发测试人员沟通，勤总结，尽可能将需求变更的可能性降到最低。
如果你是开发或者测试，希望你在以后遇到需求变更时，不要置身事外，抱怨产品经理不专业，因为需求并不是产品经理一方的事情，项目参与者都有责任一起把需求分析做好。
在一些需求分析和变更的关键阶段，要主动参与其中，从开发和测试的角度提供一些专业的建议，去思考需求产生的背景，避免对立情绪。

课后思考

在你参与的软件项目中，需求变更多吗？你们是怎么管理需求变更的？你觉得哪些地方可以做得更好？欢迎在留言区与我分享讨论。
感谢阅读，如果你觉得这篇文章对你有一些启发，也欢迎把它分享给你的朋友。
分享给需要的人，Ta购买本课程，你将得18元
生成海报并分享

赞 2

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
19 | 作为程序员，你应该有产品意识
下一篇
“一问一答”第2期 | 30个软件开发常见问题解决策略
 写留言

精选留言(23)

  • 易林林
    2019-04-11
    需求变更的多少取决于产品团队、研发团队，甚至测试团队对需求的理解程度。理解越透彻，需求变更越少，很容易在做项目的过程中及时发现问题、解决问题，这就相当于把可能发生的变更分散到日常工作中去，使其不会有太多明显的变更，降低项目延期的可能性。 宝玉老师讲到变更流程的规范化，确实深有体会。有些产品经理不按套路出牌，遇到用户提出产品需求问题，都是一口气答应下来，不去认真分析，也不去与用户探讨，觉得为了公司利益而满足客户需求是理所应当的，不加思考原原本本的将需求扔给研发，然后搬把椅子一脸焦急的看着一脸着急的研发人员。其实，有的时候加班就是这样产生的，无组织、无纪律、乱弹琴，遭殃的是患难兄弟，埋怨的是公司不人道。 我体会过产品需求流程比较规范的公司，大家都知道什么时候该做什么，绝不跨部门或越级指挥，一切按产品需求流程办事，在搭配上比较强大的执行力，每个人工作时间的工作内容都是饱和的，到下班的时候绝不留恋工作，走慢点你就是最后一个下班的。 另外，在谈论需求变更的时候，要学会拒绝，让用户知道你拒绝得很在理，有可以理解的难处；也要学会接纳，在某些合理、无伤大雅的需求上要满足用户的存在感。这样在进行项目交付的时候，即使项目完成度不是很理想，也会因你个人处事得当而加分，很容易的拿到项目的验收报告。
    展开

    作者回复: 👍很棒的分享！ 所以说项目管理是艺术，其中的平衡很难完全是一门艺术！

    共 2 条评论
    17
  • 果然如此
    2019-04-11
    1.提升需求确定性：设计高保真的原型，如用axure，不仅仅是画框图，还要加各种响应事件等； 2.提高需求变更的成本：提前约定变更制度，签字画押； 3.降低响应需求变更的成本：提高技术框架水平。 以上是通过产品、流程、技术三个方面解决需求变更问题。
    展开

    作者回复: 👍很好的总结

    9
  • Felix
    2019-04-18
    三句箴言： 走一步想三步 能配置不定制 不要相信产品经理的“绝对”

    作者回复: 👍谢谢分享 这三句绝大部分时候都适用的，我觉得也要适当结合项目情况，有些时候考虑太远、做多手准备，容易做无用功。

    6
  • 打工皇帝
    2019-10-18
    老师！我的组长脑子有问题，经常干涉设计，前面确定了需求，等开发完又修改，总是说话跟放屁一样！还是巨婴！任性，说我就是要这样，很多开发和设计都好讨厌他，敢怒不敢言！请原谅我留言粗鲁不文明！供应商的人天花的是公司的钱，他没成本意识，这样一手遮天的人 怎么应对？

    作者回复: 首先，我觉得就你自己来说，先尝试利用软件工程的知识做好你应该做的，用科学的方法去管理这类事情，包括管理你的领导。比如我在前一条回复建议的：多确认、帮助领导意识到变更成本，提高他变更的成本。不管结果怎么样，你都可以从科学认真做事的方式中获得提高和成长。 然后，对于国内的大部分公司来说，领导发言权很大的，能治领导的就只有更大的领导了，而且除非是严重错误，否则大领导也不会轻易换人。也可以考虑收集一些事实，越级投诉。但这样做风险比较大，慎重考虑。 最后，就是用脚投票，骑驴找马，换组或者换公司。

    5
  • alva_xu
    2019-04-12
    老师今天讲的现象，实际上是软件开发部门最头痛的事情。通过三个手段来解决需求变更问题，总结得太到位了。按照软件质量的金三角理论，需求变更，就相当于范围变大，必然导致成本上升或者时间增加，否则，就是质量下降。 比如说成本问题，由于业务领导对于软件开发没有成本意识，而且不考核他们的成本，所以他们可以随意变更需求，IT部门有苦难言。为了减少这个问题，我们尝试让业务部门在业务蓝图（需求）文档上签字，但对于强势的业务部门，依旧见效甚微。后来，又在发布频次上进行考核，减少发布频次。但结果又带来了用户真实的需求变更不能及时获得满足，直接影响业务。 业务变更是必然的，IT部门必须快速响应用户需求，这是摆在IT面前的必然挑战，无法回避。 真正掌握在IT部门的办法，只能是第三种选择： “降低响应需求变更的成本”。 因此，我们开始建立统一应用框架(比如单体应用的java框架，微服务框架等）、建立CICD环境、推进云的建设，加快环境搭建速度，引入自动化质量工具，加快系统缺陷的检出速度，减少技术债务，甚至建立一些业务中台，加大业务的下沉力度和技术的上浮力度，加大技术和业务的复用，建立更高效的项目管理体系和工具平台，减少技术和业务的沟通成本。 但是这样的基础建设长路漫漫，见效很慢。不知老师有没有这方面的经验分享，比如采取哪些措施，优先级是什么，来达到降低响应需求变更的成本的目的，这里又有哪些困难，如何克服。等等。 谢谢
    展开

    作者回复: 基础建设方面我的一点建议： 基础建设困难在于短期内会减慢开发速度，是和业务冲突的，如果业务部门不支持，会很难推进，压力很大。所以可以考虑分成短期、中期、长期三类，逐步做。 首先，在不影响业务的前提下，优先做一些跟业务相关能短期取得正面效果的事，比如工具的使用，管理平台的搭建。这样取得效果后相当于为你自己积累了声望，以后推进其他事情会更容易。 然后推进流程规范的建设，比如CICD、代码审查，这类事中期可以取得效果，但也需要投入大量精力保障制度的执行。 跟开发相关的事是短期看不到效果长期的事，低调的做，一点点做，最好有专门的小团队做，比如你说的统一框架的事。这类事情阻力很大，因为既要兼顾新业务的推进，又要还大量精力对现有业务的改造。做成了绝对大功一件，没做成是要背锅的。所以低调一点，做成后再高调表表功，万一没做好或没达到预期就总结经验，下次再战，也不会导致太大影响。 供参考！

    4
  • OnRoad
    2019-05-12
    客户需求频繁变更，大领导迫于客户压力全盘答应，导致开发节奏被打乱，除了量化风险上报之外，还有什么好办法？

    作者回复: 需要和你的领导私下协商，需要在他的帮助下一起作出一些调整： 1. 要设立流程提高客户变更需求的成本，可以需求变更，但不能太过于频繁随意 2. 缩短开发周期，采用迭代模型或者敏捷开发，2-4周发布一个版本，每个版本实现当前已经确定的最重要的需求，在一个版本内不接受需求变化，变化的需求放在下一个迭代中实现

    3
  • 谭鹏
    2019-04-15
    很头疼 ,开发快完成时 ,老板突然想到了个很好玩的点子,让加需求

    作者回复: 告诉他点子很好，等我们这个Sprint/版本完成，马上加上 ：）

    3
  • sotey
    2019-04-11
    老师，我参与的项目遇到了这样的情况，因为老板要求项目交付时间要提前，导致了大量的需求变更和重新设计，项目看似提前完成了，但是功能却被阉割了，后续项目的改进难度变的非常大，这种情况该怎么办啊？

    作者回复: 砍掉功能保进度很正常。只是不知道改进难度大的原因是什么？因为没有时间做架构设计？还是因为大的功能还没做？ 还是需要具体情况具体分析，你可否再发一条留言讲一下具体难度在哪，才好给具体建议。

    3
  • 舒偌一
    2019-04-24
    宝玉老师，您这边有没有做需求调研的工具或表格之类的，能更好的把握住客户的真实需求。

    作者回复: 抱歉我手头没有。 人人都是产品经理网站上一个“需求调研”的Tag，里面有很多相关的文章。 比如其中这篇文章《只需8步，需求调研表的标准制作流程》http://www.woshipm.com/pmd/407048.html 推荐你可以看看。

    2
  • 小老鼠
    2019-09-17
    1、敏捷是美国人提出的，有一点很重要：拥抱变化。而中国需求变更的确很高，而中国人为什不拥抱变化？ 2、欧美软件企业的确加班比中国企业少得多，除了需求变更多，还有什么吗？

    作者回复: 1. 敏捷开发确实是美国人提出的，但是其实并不必可以区分中国人美国人，因为敏捷开发是针对软件开发的，而软件开发是有很多共性的，并不分中国人项目还是美国人项目。 敏捷开发的拥抱变化，正是通过自动化提高效率，通过缩短开发周期，来优先做核心功能，来快速发布快速迭代，从而快速响应需求的变化。 2. 还有文化上的差异，比如美国人很注意家庭生活；另外还有工会的制衡等等因素。

    共 2 条评论
    1
  • MJ
    2019-04-12
    今日学习应对需求变更的三种方式： 提升需求确定性； 提高需求变更的成本； 降低响应需求变更的成本
    1
  • 胡鹏
    2019-04-11
    听了今天的课程，我收获的应对需求变更的方案有3 1.用低成本的方式提前收集到变更信息，以提前预知变更 2. 提高变更需求方的变更成本 3. 对系统结构要求较高，就是研发工程师在可预知范围内，尽量可配置化需求

    作者回复: 👍很好的总结

    1
  • youjing
    2019-04-11
    把自己变成客户(深入了解客户) ，可行吗？

    作者回复: 我觉得就算假装自己变成客户，也得要是懂客户能说服客户才有用。

    1
  • 空知
    2019-04-11
    给政府部门做业务软件，也配置了变更流程，可是很多时候并没有效果，领导说不满意要改就得改，这个领导满意了，另一个领导又有意见...很多时候销售,项目经理 为了维护客户关系,研发这边就得让步,不改的也得改😂

    作者回复: 是的，光从流程上还不够，经常有绕过流程的情况发生。还可以结合前面讲的金三角，看是不是可以增加成本或者减少其他需求。

    1
  • ifelse
    2022-06-27
    提升需求确定性； 提高需求变更的成本； 降低响应需求变更的成本。--记下来
  • 丁丁历险记
    2020-01-04
    两年才开始考虑做cms 够慢的。。
  • 丁丁历险记
    2020-01-04
    1 没有代码的代码最好维护。
  • 丁丁历险记
    2020-01-04
    通过约定＞配置，减少无聊的配置管理。
  • calvins
    2019-11-27
    深有感触，需求分析不到位，变更控制不到位，对团队是灾难！
  • 舒偌一
    2019-04-23
    做需求变更规范的目的是提高客户对需求的重视程度，而不是阻止客户提出变更。 需求变更规范明确变更处理流程、范围和费用。需求变更规范最好由双方领导签字确认。 人做事就会犯错，不要事事较真，灵活处理，良好的合作关系很重要。

    作者回复: 👍是的，需求变更规范起来，目标还是为了共同努力开发出高质量的软件，而不是为了阻止客户变更！