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