需求迭代与项目风险控制[2]

由于Diapers是来自北美的外包项目，双方的沟通存在时间差，项目团队也没有条件与客户面对面的沟通。在整个项目的升级改造过程中，由于业务理解的偏差以及沟通不畅，需求经过了多次迭代；需求每迭代一次，团队成员都需要面对一堆冗长的需求说明书。由于Diapers已经是正式运营的站点，客户来自市场的压力同时也转嫁到项目团队身上，项目发布的压力一直困扰着团队成员。从Diapers项目的进展来看，需求的迭代似乎就是无穷无尽的轮回。

    主动触发需求迭代，给予足够的消化时间

    导致Diapers项目的现状的主要原因是被动的进行需求迭代，迭代被动的由客户的反馈触发。每次需求迭代都可能打乱团队的开发计划，影响项目的发布，给团队带来更大的发布压力。因此，必须想方设法掌握需求迭代的主动权。

    针对每次需求迭代给予充分的消化时间是一种有效的方式。从Diapers项目的情况来看，上一次需求还没有消化处理完毕，新的需求迭代又要开始了。项目发布迭代的速度根本就跟不上需求迭代的速度，新的需求一直步步进逼。在这种情况下，测试工程师压根儿就没有时间对项目进行全面的足够的测试。

    找到问题的本质,Diapers项目团队开始调整发布节奏，加大人力资源投入，加快消化需求的速度；针对沟通不足的问题，项目经理集中精力与客户沟通，在双方时间交叉的部分尽量把有疑问的需求沟通清楚；发布节奏调整后，客户就有时间与项目团队同步开展测试工作，bug也能够在第一时间处理。调整后，项目团队有足够的时间来消化每次迭代的需求，也有足够的时间对项目进行测试。

    尽早发布原型系统是主动触发需求迭代的另一种有效方式。原型系统通常快速构建，着重在界面的呈现和功能的模拟，通过虚拟数据模拟真实系统的运行情况。其能够在很大程度上模拟未来真实系统的呈现，在短时间内将抽象的客户需求表现出来，作为和客户进行沟通的有效媒介。相对于一堆抽象的文档，使用原型系统，客户更容易尽早发现真实系统与他们的需求之间的差距，减少未来需求迭代的次数。

    因此，在需求抽象过程中，应该通过原型系统作为双方沟通的桥梁和媒介，双方应该先就原型系统的呈现展开讨论。另外，原型系统的发布时间也是比较重要的，在项目启动后应该尽早发布原型系统。

    Claim项目则是一个商业意外险理赔平台，为北美客户提供商业意外险的在线申报、理赔服务。在项目启动的初期，项目团队在理解抽象需求的基础上，第一时间发布了原型系统，使用虚拟数据模拟真实系统的界面呈现。这个项目比较有利的是，客户自己聘请了需求分析人员，能够最大程度的理解业务需求，正确的表述客户的需求，并绘制详细的原型界面；这点在双方的沟通和系统开发过程中发挥了比较显著的作用。由于Claim项目的需求迭代节奏一直在项目团队的可接受范围，所以项目一直有条不紊的推进，虽然需求也经过了多次迭代，但终归还在可控的范围内。

原文转自：http://www.ltesting.net