为什么进行需求控制？需求如何控制？这两个问题伴随着最近的CRM开发一直引发我的思考。
在上一篇《需求到底是什么？——由CRM开发想到（一）》我似乎一直在表明需求的清晰和明确（其中包含需求提供方的明确，服务群体的明确，需求内容的清晰等内容）对整个项目开发的重要性，但是一直忽略了对需求进行有效及时的控制，是不是有了明确的需求就能做好一个项目，我的答案是否定的。原因主要有以下几点：
- 需求的明确只是在前期项目分析阶段和设计阶段的一种相对明确。在后期需求变动过程中也表现出特定的相对性。
- 需求的清晰只能作为项目开发过程中的必要前提条件，而不是充分条件。
- 需求内容越多意味着需求可能更明确和更清晰，却一定意味着开发工作量和难度的增加，而且这种增加在一定程度上成几何倍增加。
- 需求之间存在相互依存关系，往往在前期项目分析、设计阶段无法体现的一些依存关系在开发过程中突显。
- 从实施角度看，需求和最终的项目一定存在着差距，这种差距可能造成项目失败，一定会造成项目需求变动。
- 需求变动在一定程度上是随着开发和部署、实施并行的。
在这种情况下，提出需求控制，既是对客户的负责也是对开发人员的负责，那么需求为什么要控制？
下面是我最近总结的问题，通过这些问题可以看出需求不加以控制造成的项目危机：
- 销售过程中以提高客户认可度达到销售成果并扩大销售业绩为目的，过分夸大能够提供的功能及特性，造成在开发过程中过度被动和项目周期的无法控制。
- 需求分析和设计阶段由于需求经过客户描述、记录和分析、设计和拆分……过程造成需求“变形”。
- 开发过程中由于实现销售中许诺的功能及特性与开发时间的冲突。
- 部署和实施过程中由于客户原始需求和现有产品的差距造成客户认可度和信任度的减低。
- 调和客户认可度和信任度过程中被动的需求变动。
- Bug和需求变动一起提交造成时间冲突加剧。
- 项目并发引起的项目周期可控性变差。
- 相关人员的责任推卸过程造成内耗。
- 需求经过变动后项目不确定性增加。
- 其他问题。
简单的说，需求控制的目的是防止项目危机，增加项目可控程度，高效利用和分配现有资源，提高客户认可和满意度，增加项目收入。
有了需求控制的目的，那么就解决了第一个问题——为什么进行需求控制。
如前面所述，需求控制既是对客户的负责也是对开发人员的负责。对于这种控制，应该由销售人员和系统分析、设计、开发、部署人员一同进行。
随着项目的进行，需求应该由推动型向拉动型的转化，从销售人员为主导向客户为主导转化，在转化的过成中避免过激、过度也是需求控制的责任，即防止项目危机。
关于这个方面的论述，将在下一篇中进行描述。
————————————————————————————————长长的分割线————————————————————————
呵呵，深夜写东西，好的一点是安静、无人打搅思路，不好的就是困意袭人，没有办法，在需求控制后面加个“（）”写个“上”就此打住，要去睡觉了。