软件项目是需求驱动的典型代表，项目从立项、开发、测试到交付，需求的变化迭代是很正常的事情，这点对于大型项目尤其明显。需求迭代如果控制不好，很容易增大项目的风险，导致项目的失败。与国内的很多软件公司相似，笔者所参与的项目也存在需求迭代的问题。本文从需求迭代入手，结合项目实际，探讨需求迭代与项目风险控制的关系，希望项目需求有序迭代。
1、需求迭代，不可避免的轮回
软件项目的启动源于市场和客户的需求，通过对市场的需求调查以及典型目标客户的需求访问抽象出需求规格说明书，进而才开始原型系统的设计，经过对原型系统的评估之后启动真实系统的设计和开发。
在原型系统设计阶段，由于各种各样的因素，比如客户没有将实际需求表达清楚，或者需求分析人员对业务的理解有偏差，据此设计出来的原型系统可能与市场、客户的真实需求不是很匹配，那么随着原型系统构建的深入，必然触发需求的迭代。
在真实系统的设计和开发过程中，随着对系统的理解的深入，客户也可能对需求进行深化、扩展或者变更，研发工程师对需求的消化，这也会触发需求的迭代。
即使真实系统交付使用，随着业务的发展，客户的需求可能发生变化；而且客户在使用系统的过程中，必然会对系统提出进一步改进的要求，修改原有功能的操作方式，增加新的功能，这些也会要求需求的进一步迭代。
在这一系列的迭代过程中，如果没有很好的控制迭代的过程，评估迭代的成本，有效管理迭代的需求，那么很容易形成需求迭代无穷无尽的假象，项目团队穷于应付每一次需求迭代，项目开发高度紧张，发布日期遥遥无期，这样必然给项目带来很高的风险。
Diapers项目是一个面向北美市场的电子商务站点，已经运行三年。最近客户决定对Diapers项目进行升级改造。项目经理或者需求分析工程师负责沟通客户，分析抽象客户的真实需求，并撰写需求说明书；软件工程师根据需求说明书拟定技术方案，并着手进行编码；测试工程师根据需求说明书和测试用例对项目进行测试；项目经理引导客户确认项目的最终功能呈现，并在必要的时候启动需求迭代过程。
由于Diapers是来自北美的外包项目，双方的沟通存在时间差，项目团队也没有条件与客户面对面的沟通。在整个项目的升级改造过程中，由于业务理解的偏差以及沟通不畅，需求经过了多次迭代；需求每迭代一次，团队成员都需要面对一堆冗长的需求说明书。由于Diapers已经是正式运营的站点，客户来自市场的压力同时也转嫁到项目团队身上，项目发布的压力一直困扰着团队成员。从Diapers项目的进展来看，需求的迭代似乎就是无穷无尽的轮回。
2、主动触发需求迭代，给予足够的消化时间
导致Diapers项目的现状的主要原因是被动的进行需求迭代，迭代被动的由客户的反馈触发。每次需求迭代都可能打乱团队的开发计划，影响项目的发布，给团队带来更大的发布压力。因此，必须想方设法掌握需求迭代的主动权。
针对每次需求迭代给予充分的消化时间是一种有效的方式。从Diapers项目的情况来看，上一次需求还没有消化处理完毕，新的需求迭代又要开始了。项目发布迭代的速度根本就跟不上需求迭代的速度，新的需求一直步步进逼。在这种情况下，测试工程师压根儿就没有时间对项目进行全面的足够的测试。
找到问题的本质，Diapers项目团队开始调整发布节奏，加大人力资源投入，加快消化需求的速度；针对沟通不足的问题，项目经理集中精力与客户沟通，在双方时间交叉的部分尽量把有疑问的需求沟通清楚；发布节奏调整后，客户就有时间与项目团队同步开展测试工作，bug也能够在