事由
北京程序员王XX遭遇车祸成植物人，医生说活下来的希望只有万分之一，唤醒更为渺茫。可他的Lead和亲人没有放弃，他们根据王XX工作如命的作风，每天都在他身边念：“XX，需求又改了，该干活了，你快来呀！”，奇迹终于发生了，王XX醒来了，第一句话：“需求又改了？”。
讨论
此故事说明了什么？程序员遭遇需求变更（CR）是非常常见的事情，如果哪位程序员还没遇见过需求变更的话，那堪称神人啊。 尤其是当下念头瀑布开发模式以及逐渐被敏捷开发(XP/SCRUM)所代替，在需求每天随时都可以变化的今天，开发人员们如何来应对呢？大家可以来讨论一下。
其实关于需求变更，和客户合作一般有2种方式，一种是签署框架协议，按headcount来算钱的，也就是按照多少人花费多少月时间来算钱，这种情况比较爽，因为大部分的实施都是按照ODC的形式来做的，有时候客户方也有技术人员，所以如果一个很大的需求变更出来的话，客户自己也会衡量一下有没有必要，另外就算有必要，也要看所花费的时间和优先级，因为这牵涉到钱，和项目的Delivery时间，不过这种形式一般不会牵涉到需求变更的签字啥的，但是偶尔有的项目也会有的（不信任的情况下），目前我们就是按照这种模式来做。
另外一种形式，往往是Project base的，或者是和国内一些国企干活的时候要这样，尤其是一个项目在客户那边有多个领导的这种情况，非常难搞，因为在签署项目的时候我们都会有非常明确的来定义需求变更的处理流程，要求双方必须按照确定的流程来操作，都是要约定变更需求的优先级，Delivery的时间点是否有变化，金额是否增减等事项，否则就要按照合同来办事了哦。
不知道大家在日常工作中是如何处理CR这种事情的？
以下是我们对待国内企业进行CR所需要的步骤：
同时最终的CR记录应该是和如下表格差不多的：
