20 如何应对让人头疼的需求变更问题？
你好，我是宝玉，我今天分享的主题是：如何应对让人头疼的需求变更问题？
我以前在国内做开发的时候，加班加点是家常便饭。这几年在美国工作，极少加班，但是产出却并没有下降，所以我一直在思索其背后的原因。这里面涉及因素很多，包括大环境、管理水平、配套设施等，但是有一个因素至关重要，那就是需求变更。
在国内很多软件公司，需求变更是常态，开发到一半，很多原始需求就发生了变化，这时候当初的设计已经不能满足要求了，很多代码需要修改，不得不加班加点来赶上进度。
反观不加班的美国公司，需求确定后很少变更。这样开发人员就可以针对需求有良好的架构设计，而不用考虑太多可能的变更，从容地在项目计划的时间内完成任务，而不需要加班加点。
在需求变更这个事情上，没有赢家，每个人都是受害者。
程序员自己辛苦的工作白费了，得不到成就感，因为频繁变更的需求，不得不在设计的时候考虑很多可能的变更，导致代码臃肿，代码质量降低，加班加点成了常态。甚至有人说：“杀一个程序员不需要用枪，改三次需求就可以了！”
产品经理也觉得很委屈：“客户要改，我有什么办法？”程序员和产品经理似乎变成了两个对立的岗位，程序员怪产品经理乱改需求，产品经理觉得是客户造成的，人人都觉得自己委屈。客户同样不满意，觉得做出来的软件不是他想要的，进度总是在延后，还想加钱？
既然大家都不满意，那么我们就需要想办法去改善，这也是软件工程这门学科存在的目的和意义。
目前也已经有很多管理需求变更的解决方案，比如这两个常见的解决方案。
方案一：增强需求变更流程，让需求变更规范起来。
这个方案简单来说，就是通过严格的流程，来避免一些没有意义的变更，从而达到管理需求变更的目的。
方案二：快速迭代，缩短版本周期。
这个方案是另一个思路，就是将大的功能拆分，每个版本周期仅实现一部分功能需求，周期较短，这样需求发生变更时，就可以快速响应。
不过，在看到这两个方案后，我还是希望你不满足于当前的答案，自己停下来思考一下这两个问题：
- 这些方案是否解决了你当前项目的问题？
- 如果换一个项目环境，当前方案是否依然适用？
之所以要思考这样的问题，是因为对于像软件工程这样偏理论知识的学习，你一定不要仅仅停留在了解有什么样的解决方案上，而是要追本溯源，研究问题背后的原因，研究理论背后的来龙去脉。
因为，就算你记住了再多的解决方案，换个项目环境可能就不适用了。所以我们要多去思考和分析逻辑，这样未来遇到类似的问题时，才可以做到对症下药，选择合适的解决方案，甚至在没有现成解决方案的情况下，能自己创造合适的解决方案。
为什么建筑工程中少有需求变更？
要解决需求变更的问题，你首先要知道，软件开发行业中的需求变更是怎么来的。
我很喜欢拿软件工程和建筑工程进行对比，你可以思考一下，同样是工程，建筑项目也是有需求变更的，但却不会像软件项目这么频繁和失控。为什么呢？
我总结一下，这里有两个主要原因：需求的确定性和需求变更的成本。
原因一：需求的确定性
建筑需求是很具象的，而软件工程的需求是抽象的。所以建筑项目里面，无论是提出需求还是变更需求，客户和施工方都明确地知道他们想要什么。
软件需求则经常是抽象、模糊、不精确的，模糊不清的需求导致在软件开发有了雏形后，才慢慢想清楚真正的需求是什么，从而导致需求变更。
举个例子，客户最开始对软件界面的颜色是没有任何要求的，当第一版本的软件给客户看的时候，客户觉得白色背景太难看了，希望换成蓝色的；第二版本换成蓝色后，客户现在已经觉得黄色更好看，希望改成黄色背景；第三版本的时候，产品经理担心客户还想换颜色，就直接做成了换皮肤功能，用户可以自己选择颜色，客户还是不满意，问能不能把背景换成图片……
是不是很熟悉？类似的事情其实经常发生在我们日常的工作场景里。
原因二：需求变更的成本
建筑项目里面的需求变更，我们都很容易和成本挂钩，因为这些东西已经是生活常识了。而与此相对的是，很多人，包括很多老板都对软件项目需求变更导致的成本增加缺少系统认识。
举个例子，装修房子的时候，如果墙面已经刷成白色了，但是客户想都刷成蓝色，那么他会很清楚，这涉及一系列成本：需要重新购买涂料、需要找人重新粉刷。
但换成一个软件项目，客户想把界面的白色背景换成蓝色的，他会觉得这是很简单也是理所当然的，甚至产品经理也会这么想，他会对程序员这么说：“不就是换个颜色吗？几行代码的事，客户让换就换了嘛！”
但是实际上，软件项目的需求变更，哪怕是换一个背景颜色，同样是要涉及成本的：需要修改所有涉及背景颜色的代码，需要更新相关测试代码，还需要对涉及的界面重新测试。
你可以说这成本是架构设计水平不到家导致的，但是如果设计时就考虑到要有支持换背景颜色的功能，那么开发的工作量从一开始就上去了，成本同样是提升了。
回到文章开始时我们提到的美国程序员不加班的问题，为什么美国的产品经理不敢随意更改需求？因为在美国很多IT公司都是工程师文化，工程师相对比较有话语权，正常情况下是不会加班加点的，所以产品经理变更需求的成本很高，在确定需求时，必须慎之又慎。
如何解决需求变更问题？
说完了原因，咱们再来看看解决方案。
首先，你需要意识到，在软件项目开发中，需求变更其实是不可避免的，一味抵制需求变更也是不可取的。你能做的就是利用软件工程的知识，理解需求变更背后深层次的原因，找到合适的方案来改善，积极拥抱合理的需求变化，减少不必要的需求变更。这是大的前提条件，也是共识的基础。
好，既然引起需求频繁变更的原因我们已经清楚了，那么，怎样有针对性地想解决方案呢？这里你也不妨停下来思考一下，你会想到哪些办法？
我的经验是从源头着手，既然需求变更的原因是需求不确定和需求变更成本太低，那么我们就针对性地提出相应的解决方案：
- 提升需求确定性，把需求分析做好，减少需求变更；
- 提高需求变更的成本，让客户或者产品经理不能太容易就变更需求，这样就可以达到减少需求变更的目的。
但在实施的时候，我们会发现一个问题，假如一味提高需求变更的成本，会让客户满意度下降，也造成了产品经理和开发人员之间的对立，不利于项目协作。
所以我们从另一个角度思考：需求变更之所以让你痛苦不堪，也是因为需求变更让项目成员付出了高昂的代价，例如返工、加班，如果我们可以低成本地响应需求变更，那么一样可以达到管理需求变更的效果。
所以解决方案上可以再加上一条：
- 降低响应需求变更的成本，可以方便快捷地响应需求变更。
接下来，我来举一个在实际项目遇到的案例，我们一起来分析一下，通过对这个需求变更场景的分析，来解决以上提到的这些问题。
案例分析
我有个大学同学叫加龙，毕业后自己开了个公司，早些年企业建站火的时候专门接企业网站的活。刚开始的时候很艰苦，也没几个人，甚至都没有专门的产品经理。
开发流程比较简单，就是先把项目谈下来，客户提一个建站的需求，然后他们去开发网站，开发好了拿给客户演示。而客户在看到网站演示后，几乎每次都会提出很多变更的需求，例如说颜色变一下、布局变一下、给留言功能加上关键字过滤功能等等。客户还喜欢直接在QQ上找负责开发的程序员，让给改一下。
创业初期，加龙同学真的是不容易，每天和几个程序员一起加班加点，就是为了应对客户这种频繁变更的需求。如果你是加龙，参考前面总结的几种解决方案，你会怎么做？
加龙作为软件工程专业毕业的学生，我觉得他当时运用软件工程知识去改善需求变更问题上是做得非常好的。他其实并没有采用一个单一的解决方案，而是分阶段逐步改进。
第一步：规范变更流程，提升客户变更成本。
加龙其实也知道，通过提升需求确定性，做好需求分析，和客户多沟通确认，是可以有效减少需求变更的。但是他当时确实人手太有限，也没有专业的产品经理，不能短时间内去提升需求分析、产品设计的水平，所以他第一步选择提升客户变更需求的成本，这样可以马上产生效果。
于是在后面的项目中，在和客户签订合同时，他会和客户约定，如果有需求变更，先统一提交到他那里，然后他甄别后再决定是否做，什么时候做，是否要重新签订新的附加合同（增加额外费用）。通过制定一系列标准，让双方合作的流程变得更规范。
这样，程序员就可以专注于开发，也不会因为频繁的需求变更影响进度，大家不用那么累，收入也在稳步上升。但是需求变更的情况还是时有发生。
第二步：用原型设计低成本响应需求变更；做好需求分析和确认，减少需求变更。
加龙在挺过最艰难的创业初期后，雇佣了一个全职的产品经理，专门去和客户确认需求。这个产品经理很专业，每次在了解完客户的需求后，不急于让程序员马上去写代码，而是自己先用Axure这样的原型设计工具，做一个简单的交互原型，给客户演示。
于是客户会针对原型的效果提出一些修改意见，他再快速地修改原型，这样反复确认，等到客户没有什么修改意见后，再让开发着手实现。
通过原型设计的方式，不仅可以方便地与客户沟通需求，还可以灵活响应需求变更。
通过提升需求确定性，加龙的公司进一步降低了需求变更的情况发生，营收又上了一个台阶，又增加了几个程序员和产品经理。
第三步：通过灵活的架构和强大的配置，低成本响应客户需求变更。
加龙公司经过两年的发展后，敏锐地发现其实大部分企业网站的功能都是很相似的，主要差别还是在界面样式上。
这些年大部分网站的开发其实都是把前一个网站复制一份，修修改改，但是这样还是效率太低，如果可以做到定制化，就可以更高效地定制网站。
于是加龙从公司抽调了几名骨干程序员，成立了一个专门的项目组，把这两年做的网站类型做了分析，做了一套建站系统，有点类似于后来流行的像WordPress这样的博客系统，可以通过换皮肤的的方式来定制界面，通过插件的方式增加功能。
由于前期积累充分，大约半年后他们就开始使用这套系统去建站，一下子就把建站的成本大大降低啦。而且当客户的需求有变化时，只要后台做简单的配置就可以马上支持需求变更。
但是这个模式也有问题，就是有些特别个性化的定制需求，还是满足不了。不过这也没关系，对于需要个性化的客户，要么增收额外的费用，要么就直接放弃掉。
如果咱们对他这三步采取的方案做一个总结，还就是我前面说的三个方案：
- 提升需求确定性；
- 提高需求变更的成本；
- 降低响应需求变更的成本。
只不过他根据公司不同阶段的特点，来灵活运用。这就是我的同学加龙在处理需求变更时分阶段采取的方案，是不是跟你想的一样？
总结
今天我通过对比建筑工程中的需求变更，和你一起分析了软件工程中需求变更产生的原因。需求频繁变更，主要是由于需求不确定和变更成本过低导致的。并由此提出了三种不同的解决方案。
- 提升需求确定性，来减少需求的变更。这种方案的优势就是对需求理解透彻，后期返工少，缺点是对产品经理的需求分析能力要求很高。
- 提高需求变更的成本，规范需求变更流程，减少需求变更。这种方案的优势就是可以马上起到效果，缺点就是过于繁琐的流程不利于项目协作。
- 降低响应需求变更的成本，积极应对需求变更。这种方案的优势在于可以快速响应需求变更，能快速试错尽快调整，缺点在于对软件架构和项目管理要求比较高。
就像我的同学加龙那样，你可以根据项目的实际情况，对比这些方案的优缺点，选择适合你的解决方案。
例如你是做企业外包项目的，客户不懂又喜欢瞎掺和，那么就可以适当提高变更成本，甚至每次变更都可以计入项目成本中；如果你是做互联网项目，需要快速推出产品，那么就可以选择降低响应变更成本，快速迭代，快速试错，尽快调整。
如果你是项目经理，希望你通过这次对需求变更的学习，能针对项目特点，制定合适的需求变更流程，选择适合项目的开发模式，管理好需求变更，从而提升整个项目的开发效率，避免重复返工导致的浪费。
如果你是产品经理，希望你通过这次学习，对需求变更导致的成本有很高的重视，努力提升专业水平，勤于和客户、开发测试人员沟通，勤总结，尽可能将需求变更的可能性降到最低。
如果你是开发或者测试，希望你在以后遇到需求变更时，不要置身事外，抱怨产品经理不专业，因为需求并不是产品经理一方的事情，项目参与者都有责任一起把需求分析做好。
在一些需求分析和变更的关键阶段，要主动参与其中，从开发和测试的角度提供一些专业的建议，去思考需求产生的背景，避免对立情绪。
课后思考
在你参与的软件项目中，需求变更多吗？你们是怎么管理需求变更的？你觉得哪些地方可以做得更好？欢迎在留言区与我分享讨论。
感谢阅读，如果你觉得这篇文章对你有一些启发，也欢迎把它分享给你的朋友。
- 易林林 👍（23） 💬（2）
需求变更的多少取决于产品团队、研发团队，甚至测试团队对需求的理解程度。理解越透彻，需求变更越少，很容易在做项目的过程中及时发现问题、解决问题，这就相当于把可能发生的变更分散到日常工作中去，使其不会有太多明显的变更，降低项目延期的可能性。 宝玉老师讲到变更流程的规范化，确实深有体会。有些产品经理不按套路出牌，遇到用户提出产品需求问题，都是一口气答应下来，不去认真分析，也不去与用户探讨，觉得为了公司利益而满足客户需求是理所应当的，不加思考原原本本的将需求扔给研发，然后搬把椅子一脸焦急的看着一脸着急的研发人员。其实，有的时候加班就是这样产生的，无组织、无纪律、乱弹琴，遭殃的是患难兄弟，埋怨的是公司不人道。 我体会过产品需求流程比较规范的公司，大家都知道什么时候该做什么，绝不跨部门或越级指挥，一切按产品需求流程办事，在搭配上比较强大的执行力，每个人工作时间的工作内容都是饱和的，到下班的时候绝不留恋工作，走慢点你就是最后一个下班的。 另外，在谈论需求变更的时候，要学会拒绝，让用户知道你拒绝得很在理，有可以理解的难处；也要学会接纳，在某些合理、无伤大雅的需求上要满足用户的存在感。这样在进行项目交付的时候，即使项目完成度不是很理想，也会因你个人处事得当而加分，很容易的拿到项目的验收报告。
2019-04-11 - 果然如此 👍（9） 💬（1）
1.提升需求确定性：设计高保真的原型，如用axure，不仅仅是画框图，还要加各种响应事件等； 2.提高需求变更的成本：提前约定变更制度，签字画押； 3.降低响应需求变更的成本：提高技术框架水平。 以上是通过产品、流程、技术三个方面解决需求变更问题。
2019-04-11 - 打工皇帝 👍（6） 💬（1）
老师！我的组长脑子有问题，经常干涉设计，前面确定了需求，等开发完又修改，总是说话跟放屁一样！还是巨婴！任性，说我就是要这样，很多开发和设计都好讨厌他，敢怒不敢言！请原谅我留言粗鲁不文明！供应商的人天花的是公司的钱，他没成本意识，这样一手遮天的人 怎么应对？
2019-10-18 - Felix 👍（6） 💬（1）
三句箴言： 走一步想三步 能配置不定制 不要相信产品经理的“绝对”
2019-04-18 - alva_xu 👍（5） 💬（1）
老师今天讲的现象，实际上是软件开发部门最头痛的事情。通过三个手段来解决需求变更问题，总结得太到位了。按照软件质量的金三角理论，需求变更，就相当于范围变大，必然导致成本上升或者时间增加，否则，就是质量下降。 比如说成本问题，由于业务领导对于软件开发没有成本意识，而且不考核他们的成本，所以他们可以随意变更需求，IT部门有苦难言。为了减少这个问题，我们尝试让业务部门在业务蓝图（需求）文档上签字，但对于强势的业务部门，依旧见效甚微。后来，又在发布频次上进行考核，减少发布频次。但结果又带来了用户真实的需求变更不能及时获得满足，直接影响业务。 业务变更是必然的，IT部门必须快速响应用户需求，这是摆在IT面前的必然挑战，无法回避。 真正掌握在IT部门的办法，只能是第三种选择： “降低响应需求变更的成本”。 因此，我们开始建立统一应用框架(比如单体应用的java框架，微服务框架等）、建立CICD环境、推进云的建设，加快环境搭建速度，引入自动化质量工具，加快系统缺陷的检出速度，减少技术债务，甚至建立一些业务中台，加大业务的下沉力度和技术的上浮力度，加大技术和业务的复用，建立更高效的项目管理体系和工具平台，减少技术和业务的沟通成本。 但是这样的基础建设长路漫漫，见效很慢。不知老师有没有这方面的经验分享，比如采取哪些措施，优先级是什么，来达到降低响应需求变更的成本的目的，这里又有哪些困难，如何克服。等等。 谢谢
2019-04-12 - 谭鹏 👍（4） 💬（1）
很头疼 ,开发快完成时 ,老板突然想到了个很好玩的点子,让加需求
2019-04-15 - OnRoad 👍（3） 💬（1）
客户需求频繁变更，大领导迫于客户压力全盘答应，导致开发节奏被打乱，除了量化风险上报之外，还有什么好办法？
2019-05-12 - sotey 👍（3） 💬（1）
老师，我参与的项目遇到了这样的情况，因为老板要求项目交付时间要提前，导致了大量的需求变更和重新设计，项目看似提前完成了，但是功能却被阉割了，后续项目的改进难度变的非常大，这种情况该怎么办啊？
2019-04-11 - 舒偌一 👍（2） 💬（1）
宝玉老师，您这边有没有做需求调研的工具或表格之类的，能更好的把握住客户的真实需求。
2019-04-24 - 小老鼠 👍（1） 💬（2）
1、敏捷是美国人提出的，有一点很重要：拥抱变化。而中国需求变更的确很高，而中国人为什不拥抱变化？ 2、欧美软件企业的确加班比中国企业少得多，除了需求变更多，还有什么吗？
2019-09-17 - 胡鹏 👍（1） 💬（1）
听了今天的课程，我收获的应对需求变更的方案有3 1.用低成本的方式提前收集到变更信息，以提前预知变更 2. 提高变更需求方的变更成本 3. 对系统结构要求较高，就是研发工程师在可预知范围内，尽量可配置化需求
2019-04-11 - youjing 👍（1） 💬（1）
把自己变成客户(深入了解客户) ，可行吗？
2019-04-11 - 空知 👍（1） 💬（1）
给政府部门做业务软件，也配置了变更流程，可是很多时候并没有效果，领导说不满意要改就得改，这个领导满意了，另一个领导又有意见...很多时候销售,项目经理 为了维护客户关系,研发这边就得让步,不改的也得改😂
2019-04-11 - 舒偌一 👍（0） 💬（1）
做需求变更规范的目的是提高客户对需求的重视程度，而不是阻止客户提出变更。 需求变更规范明确变更处理流程、范围和费用。需求变更规范最好由双方领导签字确认。 人做事就会犯错，不要事事较真，灵活处理，良好的合作关系很重要。
2019-04-23 - 小伟 👍（0） 💬（1）
多谢老师，很受益。 自己在互联网公司，很多时候需求经常变更，是需求沟通的人或制定方案的人水平不行，觉得需求变更很方便，走一步算一步，导致来回反复。（规范需求变更流程） 另外，很多程序员对自己不自信，觉得很简单的变更，随手就改了，觉得自己时间很廉价，殊不知，改动一个点，会涉及单测，继承测试等一系列工作，如果省略这些步骤，就会造成系统bug等等（变更成本高）
2019-04-18