清楚；发布节奏调整后，客户就有时间与项目团队同步开展测试工作，bug也能够在第一时间处理。调整后，项目团队有足够的时间来消化每次迭代的需求，也有足够的时间对项目进行测试。
尽早发布原型系统是主动触发需求迭代的另一种有效方式。原型系统通常快速构建，着重在界面的呈现和功能的模拟，通过虚拟数据模拟真实系统的运行情况。其能够在很大程度上模拟未来真实系统的呈现，在短时间内将抽象的客户需求表现出来，作为和客户进行沟通的有效媒介。相对于一堆抽象的文档，使用原型系统，客户更容易尽早发现真实系统与他们的需求之间的差距，减少未来需求迭代的次数。
因此，在需求抽象过程中，应该通过原型系统作为双方沟通的桥梁和媒介，双方应该先就原型系统的呈现展开讨论。另外，原型系统的发布时间也是比较重要的，在项目启动后应该尽早发布原型系统。
Claim项目则是一个商业意外险理赔平台，为北美客户提供商业意外险的在线申报、理赔服务。在项目启动的初期，项目团队在理解抽象需求的基础上，第一时间发布了原型系统，使用虚拟数据模拟真实系统的界面呈现。这个项目比较有利的是，客户自己聘请了需求分析人员，能够最大程度的理解业务需求，正确的表述客户的需求，并绘制详细的原型界面；这点在双方的沟通和系统开发过程中发挥了比较显著的作用。由于Claim项目的需求迭代节奏一直在项目团队的可接受范围，所以项目一直有条不紊的推进，虽然需求也经过了多次迭代，但终归还在可控的范围内。
3、评估每一次迭代的成本和风险
能够预见到的是，需求的每次迭代都会不同程度的对项目产生影响，对此需要评估由此所带来的成本。不只是项目经理和需求分析工程师，软件工程师和测试工程师也应该参与这个过程，评估此次迭代是否会影响现有的技术架构，哪些功能点可能受到影响，哪些系统模块需要修改，测试用例是否应该重新编写，团队需要为此次迭代额外付出多少时间成本，是否会造成项目的延期等等。
评估之后，如果需求迭代对项目的进度可能造成比较明显的影响，项目经理应该和客户有效沟通，告知需求迭代的成本，尤其是时间成本。
另外，需求的每次迭代也必然给项目带来一定的风险，包括技术风险和发布风险。迭代后的需求可能影响原有的技术方案，尤其是核心业务逻辑的变更。团队要重新对技术方案进行梳理，检查该技术方案是否仍然可以达到既定的目的。需求迭代之后，软件工程师需要一定的时间调整开发进度，测试工程师也需要根据新的需求对系统重新测试，这必然影响项目的发布周期；作为项目经理，应该预见到这一点。
GS项目是某公司重点研发的一个以政府机关行政审批业务为服务目标的产品，在其进行产品升级改造的同时，其竞争对手也在着手准备同类产品的新版本发布，市场的压力要求产品尽快完成版本的升级。但是在新产品即将进入集成测试阶段的时候，公司突然决定对产品的界面进行比较重大的调整。这一次调整导致代码和测试的返工，使该产品的发布时间推迟了两个月，错过了销售的黄金期，市场和客户对于新产品的期待已经逐渐降低，结果产品的销售量远远不如预期。如果公司之前对界面需求迭代有比较清晰的成本和风险评估，那么应该不会这么仓促的触发迭代。
Diapers项目团队意识到Diapers项目的需求迭代的周期是比较短的，因此对于每次迭代的需求，软件工程师和测试工程师都会协同项目经理进行评估，判断消化所有需求并测试所需要投入的工作量，以及由此所可能带来的时间成本和技术风险，团队成员已经彻底摆脱了害怕需求迭代的心态。
4、明确项目发布