你好，我是宝玉，我今天分享的主题是：如何应对让人头疼的需求变更问题？
我以前在国内做开发的时候，加班加点是家常便饭。这几年在美国工作，极少加班，但是产出却并没有下降，所以我一直在思索其背后的原因。这里面涉及因素很多，包括大环境、管理水平、配套设施等，但是有一个因素至关重要，那就是需求变更。
在国内很多软件公司，需求变更是常态，开发到一半，很多原始需求就发生了变化，这时候当初的设计已经不能满足要求了，很多代码需要修改，不得不加班加点来赶上进度。
反观不加班的美国公司，需求确定后很少变更。这样开发人员就可以针对需求有良好的架构设计，而不用考虑太多可能的变更，从容地在项目计划的时间内完成任务，而不需要加班加点。
在需求变更这个事情上，没有赢家，每个人都是受害者。
程序员自己辛苦的工作白费了，得不到成就感，因为频繁变更的需求，不得不在设计的时候考虑很多可能的变更，导致代码臃肿，代码质量降低，加班加点成了常态。甚至有人说：“杀一个程序员不需要用枪，改三次需求就可以了！”
产品经理也觉得很委屈：“客户要改，我有什么办法？”程序员和产品经理似乎变成了两个对立的岗位，程序员怪产品经理乱改需求，产品经理觉得是客户造成的，人人都觉得自己委屈。客户同样不满意，觉得做出来的软件不是他想要的，进度总是在延后，还想加钱？
既然大家都不满意，那么我们就需要想办法去改善，这也是软件工程这门学科存在的目的和意义。
目前也已经有很多管理需求变更的解决方案，比如这两个常见的解决方案。
方案一：增强需求变更流程，让需求变更规范起来。
这个方案简单来说，就是通过严格的流程，来避免一些没有意义的变更，从而达到管理需求变更的目的。
方案二：快速迭代，缩短版本周期。
这个方案是另一个思路，就是将大的功能拆分，每个版本周期仅实现一部分功能需求，周期较短，这样需求发生变更时，就可以快速响应。
不过，在看到这两个方案后，我还是希望你不满足于当前的答案，自己停下来思考一下这两个问题：
之所以要思考这样的问题，是因为对于像软件工程这样偏理论知识的学习，你一定不要仅仅停留在了解有什么样的解决方案上，而是要追本溯源，研究问题背后的原因，研究理论背后的来龙去脉。
因为，就算你记住了再多的解决方案，换个项目环境可能就不适用了。所以我们要多去思考和分析逻辑，这样未来遇到类似的问题时，才可以做到对症下药，选择合适的解决方案，甚至在没有现成解决方案的情况下，能自己创造合适的解决方案。
要解决需求变更的问题，你首先要知道，软件开发行业中的需求变更是怎么来的。
我很喜欢拿软件工程和建筑工程进行对比，你可以思考一下，同样是工程，建筑项目也是有需求变更的，但却不会像软件项目这么频繁和失控。为什么呢？
我总结一下，这里有两个主要原因：需求的确定性和需求变更的成本。
建筑需求是很具象的，而软件工程的需求是抽象的。所以建筑项目里面，无论是提出需求还是变更需求，客户和施工方都明确地知道他们想要什么。
软件需求则经常是抽象、模糊、不精确的，模糊不清的需求导致在软件开发有了雏形后，才慢慢想清楚真正的需求是什么，从而导致需求变更。
举个例子，客户最开始对软件界面的颜色是没有任何要求的，当第一版本的软件给客户看的时候，客户觉得白色背景太难看了，希望换成蓝色的；第二版本换成蓝色后，客户现在已经觉得黄色更好看，希望改成黄色背景；第三版本的时候，产品经理担心客户还想换颜色，就直接做成了换皮肤功能，用户可以自己选择颜色，客户还是不满意，问能不能把背景换成图片……
是不是很熟悉？类似的事情其实经常发生在我们日常的工作场景里。
建筑项目里面的需求变更，我们都很容易和成本挂钩，因为这些东西已经是生活常识了。而与此相对的是，很多人，包括很多老板都对软件项目需求变更导致的成本增加缺少系统认识。
举个例子，装修房子的时候，如果墙面已经刷成白色了，但是客户想都刷成蓝色，那么他会很清楚，这涉及一系列成本：需要重新购买涂料、需要找人重新粉刷。
但换成一个软件项目，客户想把界面的白色背景换成蓝色的，他会觉得这是很简单也是理所当然的，甚至产品经理也会这么想，他会对程序员这么说：“不就是换个颜色吗？几行代码的事，客户让换就换了嘛！”
但是实际上，软件项目的需求变更，哪怕是换一个背景颜色，同样是要涉及成本的：需要修改所有涉及背景颜色的代码，需要更新相关测试代码，还需要对涉及的界面重新测试。
你可以说这成本是架构设计水平不到家导致的，但是如果设计时就考虑到要有支持换背景颜色的功能，那么开发的工作量从一开始就上去了，成本同样是提升了。
回到文章开始时我们提到的美国程序员不加班的问题，为什么美国的产品经理不敢随意更改需求？因为在美国很多IT公司都是工程师文化，工程师相对比较有话语权，正常情况下是不会加班加点的，所以产品经理变更需求的成本很高，在确定需求时，必须慎之又慎。
说完了原因，咱们再来看看解决方案。
首先，你需要意识到，在软件项目开发中，需求变更其实是不可避免的，一味抵制需求变更也是不可取的。你能做的就是利用软件工程的知识，理解需求变更背后深层次的原因，找到合适的方案来改善，积极拥抱合理的需求变化，减少不必要的需求变更。这是大的前提条件，也是共识的基础。
好，既然引起需求频繁变更的原因我们已经清楚了，那么，怎样有针对性地想解决方案呢？这里你也不妨停下来思考一下，你会想到哪些办法？
我的经验是从源头着手，既然需求变更的原因是需求不确定和需求变更成本太低，那么我们就针对性地提出相应的解决方案：
但在实施的时候，我们会发现一个问题，假如一味提高需求变更的成本，会让客户满意度下降，也造成了产品经理和开发人员之间的对立，不利于项目协作。
所以我们从另一个角度思考：需求变更之所以让你痛苦不堪，也是因为需求变更让项目成员付出了高昂的代价，例如返工、加班，如果我们可以低成本地响应需求变更，那么一样可以达到管理需求变更的效果。
所以解决方案上可以再加上一条：
接下来，我来举一个在实际项目遇到的案例，我们一起来分析一下，通过对这个需求变更场景的分析，来解决以上提到的这些问题。
我有个大学同学叫加龙，毕业后自己开了个公司，早些年企业建站火的时候专门接企业网站的活。刚开始的时候很艰苦，也没几个人，甚至都没有专门的产品经理。
开发流程比较简单，就是先把项目谈下来，客户提一个建站的需求，然后他们去开发网站，开发好了拿给客户演示。而客户在看到网站演示后，几乎每次都会提出很多变更的需求，例如说颜色变一下、布局变一下、给留言功能加上关键字过滤功能等等。客户还喜欢直接在QQ上找负责开发的程序员，让给改一下。
创业初期，加龙同学真的是不容易，每天和几个程序员一起加班加点，就是为了应对客户这种频繁变更的需求。如果你是加龙，参考前面总结的几种解决方案，你会怎么做？
加龙作为软件工程专业毕业的学生，我觉得他当时运用软件工程知识去改善需求变更问题上是做得非常好的。他其实并没有采用一个单一的解决方案，而是分阶段逐步改进。
第一步：规范变更流程，提升客户变更成本。
加龙其实也知道，通过提升需求确定性，做好需求分析，和客户多沟通确认，是可以有效减少需求变更的。但是他当时确实人手太有限，也没有专业的产品经理，不能短时间内去提升需求分析、产品设计的水平，所以他第一步选择提升客户变更需求的成本，这样可以马上产生效果。
于是在后面的项目中，在和客户签订合同时，他会和客户约定，如果有需求变更，先统一提交到他那里，然后他甄别后再决定是否做，什么时候做，是否要重新签订新的附加合同（增加额外费用）。通过制定一系列标准，让双方合作的流程变得更规范。
这样，程序员就可以专注于开发，也不会因为频繁的需求变更影响进度，大家不用那么累，收入也在稳步上升。但是需求变更的情况还是时有发生。
第二步：用原型设计低成本响应需求变更；做好需求分析和确认，减少需求变更。
加龙在挺过最艰难的创业初期后，雇佣了一个全职的产品经理，专门去和客户确认需求。这个产品经理很专业，每次在了解完客户的需求后，不急于让程序员马上去写代码，而是自己先用Axure这样的原型设计工具，做一个简单的交互原型，给客户演示。
于是客户会针对原型的效果提出一些修改意见，他再快速地修改原型，这样反复确认，等到客户没有什么修改意见后，再让开发着手实现。
通过原型设计的方式，不仅可以方便地与客户沟通需求，还可以灵活响应需求变更。
通过提升需求确定性，加龙的公司进一步降低了需求变更的情况发生，营收又上了一个台阶，又增加了几个程序员和产品经理。
第三步：通过灵活的架构和强大的配置，低成本响应客户需求变更。
加龙公司经过两年的发展后，敏锐地发现其实大部分企业网站的功能都是很相似的，主要差别还是在界面样式上。
这些年大部分网站的开发其实都是把前一个网站复制一份，修修改改，但是这样还是效率太低，如果可以做到定制化，就可以更高效地定制网站。
于是加龙从公司抽调了几名骨干程序员，成立了一个专门的项目组，把这两年做的网站类型做了分析，做了一套建站系统，有点类似于后来流行的像WordPress这样的博客系统，可以通过换皮肤的的方式来定制界面，通过插件的方式增加功能。
由于前期积累充分，大约半年后他们就开始使用这套系统去建站，一下子就把建站的成本大大降低啦。而且当客户的需求有变化时，只要后台做简单的配置就可以马上支持需求变更。
但是这个模式也有问题，就是有些特别个性化的定制需求，还是满足不了。不过这也没关系，对于需要个性化的客户，要么增收额外的费用，要么就直接放弃掉。
如果咱们对他这三步采取的方案做一个总结，还就是我前面说的三个方案：
只不过他根据公司不同阶段的特点，来灵活运用。这就是我的同学加龙在处理需求变更时分阶段采取的方案，是不是跟你想的一样？
今天我通过对比建筑工程中的需求变更，和你一起分析了软件工程中需求变更产生的原因。需求频繁变更，主要是由于需求不确定和变更成本过低导致的。并由此提出了三种不同的解决方案。
提升需求确定性，来减少需求的变更。这种方案的优势就是对需求理解透彻，后期返工少，缺点是对产品经理的需求分析能力要求很高。
提高需求变更的成本，规范需求变更流程，减少需求变更。这种方案的优势就是可以马上起到效果，缺点就是过于繁琐的流程不利于项目协作。
降低响应需求变更的成本，积极应对需求变更。这种方案的优势在于可以快速响应需求变更，能快速试错尽快调整，缺点在于对软件架构和项目管理要求比较高。
就像我的同学加龙那样，你可以根据项目的实际情况，对比这些方案的优缺点，选择适合你的解决方案。
例如你是做企业外包项目的，客户不懂又喜欢瞎掺和，那么就可以适当提高变更成本，甚至每次变更都可以计入项目成本中；如果你是做互联网项目，需要快速推出产品，那么就可以选择降低响应变更成本，快速迭代，快速试错，尽快调整。
如果你是项目经理，希望你通过这次对需求变更的学习，能针对项目特点，制定合适的需求变更流程，选择适合项目的开发模式，管理好需求变更，从而提升整个项目的开发效率，避免重复返工导致的浪费。
如果你是产品经理，希望你通过这次学习，对需求变更导致的成本有很高的重视，努力提升专业水平，勤于和客户、开发测试人员沟通，勤总结，尽可能将需求变更的可能性降到最低。
如果你是开发或者测试，希望你在以后遇到需求变更时，不要置身事外，抱怨产品经理不专业，因为需求并不是产品经理一方的事情，项目参与者都有责任一起把需求分析做好。
在一些需求分析和变更的关键阶段，要主动参与其中，从开发和测试的角度提供一些专业的建议，去思考需求产生的背景，避免对立情绪。
在你参与的软件项目中，需求变更多吗？你们是怎么管理需求变更的？你觉得哪些地方可以做得更好？欢迎在留言区与我分享讨论。
感谢阅读，如果你觉得这篇文章对你有一些启发，也欢迎把它分享给你的朋友。
评论