需求变更的烦恼
开始是需求不明确，客户都不知道要做成什么样，只有一个大概的粗略的描述。等到大楼盖好了，给客户，却发现大楼应该是这样那样的。。。客户方和开发方在一起( WorkShop) 还好，如果分开在两地就更糟糕。。。
永远不变的就是变化，这个大家都知道，但关键是如何合理的控制需求变更？
我以前做的上百人一年多一个的大项目，完全按照CMMI Level3规范来控制需求变更的。起初有双方签字的经过评审的需求基线，以后需求变更的时候有需求变更委员会（CCB）或专门负责的角色（通常由客户方需求人员来收集和评估最初需求并提交给QA，QA牵头需求变更流程）来处理需求变更，具体做法是：
1. 先是客户或项目组成员提出的需求申请，填写《变更申请单》并提交给项目经理。
2. 项目经理组织项目相关人员对需求变更进行评估和调研，然后组织 需求变更评审。
3. 如果同意变更则由CCB授权配置管理员检出配置项由项目组成员对相关的文档（用户需求说明书、需求规格说明书）进行修改，修改后评审（同时 填写《变更管理记录表》）通过后由高层经理审批，然后提交用户确认，最后纳入配置库，更新《需求追踪矩阵》，确保需求和工作产品的一致性；
4. 如果不同意变 更，则项目经理、部门经理与客户共同协商，协商后同意变更，则对相关的文档进行修改。协商后依然不统一，则需求变更结束。
5. 所有的需求变更都需要总经理理进 行审批。需求变更的影响：利用《需求跟踪矩阵》对变更影响进行评估；估计对项目参数的影响—规模、工作量、进度影响；超出阀值（整个项目进度的10%- 15%，里程碑30%）的，应提交高层评审/批准。
6. 妥善保存变更产生的相关文档。
现在公司做的项目规范较小，完全按照CMMI的规范来有点多余，所以我们基本上类似于敏捷开发的模式。敏捷编程是拥抱变化，持续重构和改进，迭代开发，频繁交付。在需求变更管理上我们还没有一套完整的合适的流程，具体做法是：
1. 客户提出新需求;
2. 开发人员或项目经理评估后答应了;
3. 继续开发，时间表按照重新评估后的进行;
4. 基本上很少拒绝客户；一方面是为了维护客户关系，另一方面对自己team的开发能力很自信; 结果是上头答应了客户，下头的只能加班加点赶工。
另外还有一些控制需求的做法：
1. 项目前期会首先快速开发一个产品原型(Prototype)给客户，有界面的先用visio画个界面，以验证业务规则、业务流程和大概GUI等。另外，产品原型也有助于进一步挖掘用户的需求。
2. 会粗略的列出大体的需求并签字
3. 频繁交付给客户，短周期的交付可工作的产品，以印证需求与实现是否一致，同时兼做客户教育工作。
问题是如果需求变更无休止，则需求变更几乎就不可控，项目开发也无休止。所以我觉得我们公司在需求管理上还缺乏：
1. 需求基线管理，经过评审的双方确认签字的需求基线。以后如果要超出或修改需求基线，则必须有专门的人员对此提出异议，由CCB审核后方可修改；
2. 专门的需求控制负责人。现在基本上是技术人员或是项目经理收到客户需求变更，然后自己评估下就答应了。缺乏专门的需求控制负责人，因而没有需求评审，没有一套专门的严格可控的需求变更流程。
3. 需求功能点列表的书面确认。现在签的只是非常粗略的大体需求，定性而没有定量，以后扯皮发生的可能性非常大；
4. 适当时候应该拒绝客户的要求。虽然用户有众多的理由，比如他认为改动不大，竞争对手已经拥有该功能，或是新的业务需要，但如果评估后的结果是没有必要，或不合理，或优先级不高，或风险大于必要，则坚定的拒绝。另外一种变通的方法是，根据优先级重要性有条件的答应，比如放在下一次版本之后。
另外在需求变更管理中，和客户有效的沟通、协调和教育非常重要。说的好点，就是“要讲究沟通的艺术”，“多引导客户”；说得俗点，就是“摆平客户”。如果能够对客户进行很好的客户教育，很多时候客户是可以理解开发过程中的困难，从而达到妥协或折中。比如客户理解了项目后期进度紧张，技术架构难以大改，就会在资源、进度、功能上做一些折中的选择，比如把功能分主要功能先实现，次要功能后实现；核心业务保稳定，次要业务不能牺牲核心业务的稳定性等等。反之，如果没有和客户有效的沟通、协调和教育，则会双方各执一词，搞业务的只讲业务、流程和功能，不考虑技术可行性，不考虑资源和时间表；搞技术的只讲技术，没有倾听客户的正当的商业需求，不能满足客户利益的最大化，这样双方就很难达成双赢的结果。所以，有效的沟通是软件项目成功的关键。