快速原型法案例

项目型软件的开发流程，通常会包括七个步骤：第一步：需求调研分析；第二步：概要设计；第三步：详细设计；第四步：编码；第五步：测试；第六步：软件交付准备；第七步：验收与收尾工作。

在项目型产品的开发过程中，依据软件工程思想的标准，遵循软件开发流程（Software development process）一步步的操作是最正统和最标准而且有效的做法，项目组人员的理解并落实这一点，整个项目就会朝着良性的方向发展。

狭义的项目组成员是指软件公司的人员，广义的项目组成员还应该包括客户方，对于客户来说，更关心的是结果而不是过程。由于项目组成员们的专业素养和技术水平会有差异（比如项目开发方的长处在计算机方面，而合作方在专业知识），再加上沟通不畅等因素，会给项目带来一些负面影响，比如甲乙双方对于研发成果存在争议、项目无法按期完成等等。

简单谈一下我们公司经历的一个项目情况。由于项目的专业性，摆在项目组人员的第一个问题就是理解需求其次才是后续步骤。如果严格按照软件开发的流程，必然会出现一些不可控的风险。

我方项目组果断决定采用快速原型法和敏捷开发的思想作为此次项目开发的主导，主要有以下几个措施：

1、在获取用户原始需求后迅速理解开发出一个雏形，把一个能看到的软件界面反馈给用户去探讨更进一步的需求，去更准确的把握用户需求，反复迭代。这点对甲乙双方都是有利的，当你拿着一堆文档让客户确认需求签字，从文档上看双方理解一致就签字了，然而等中期汇报做出来成果会发现简直就是南辕北辙，下次再签字肯定就会犹豫了……

2、把编码工作提到了概要设计和详细设计的前面或者并行，不等待所有的文档都完成才去进行下一步的工作。任何好的制度如果僵化，就会出现与制度目的背离的结果。

3、出现疑问和争议时抱着“友好合作协商解决”的态度去及时沟通，当然了也是个合作与斗争的过程，一味的满足用户需求做出承诺意味着“死亡”而且客户未必也会领你的“情”。及时，就是对无法获得与客户有效沟通地机会这个问题上不要给自己找太多理由，也许客户方企业组织的一个集体活动都会比项目重要。

尽管最终无可避免的也出现了争议和延期两个问题，但是我方把风险做到了最小化，项目中后期一直到汇报，客户都是和我们站在一起的，要知道我们公司的“背景”是最薄的！

当时客户方是两个软件项目同期进行的，通过几次集中汇报和私底下的交流，我们了解开发方是严格按照软件的开发流程展开工作。当客户方按流程要求所有项目进行中期汇报检查时，我们公司拿出的除了文档还有一个能满足客户40%左右工作需求的软件，而另一个项目却只有厚厚的文档；当项目第一次申请延期时，我方项目组实际已经和客户落实了90%以上的需求并完成了大部分的开发工作剩余部分为了不影响验收工作也达成了双方都可以接受的解决方案，而另一个公司的项目组的需求还在变化中；当项目验收汇报近在咫尺时，我方在科室内部汇报中获得了客户方大部分的认可并可能获得优秀外协项目的评价，而另一个公司却还得继续申请延期（这一次是按

违约处理要扣项目款）；后来项目结束我们项目组离开驻地，3月后byteh以项目经理的身份出现在客户方去交付剩余的需求并办理尾款结付手续时，该公司的项目还在进行，而且还出现了一些生疏的面孔……

前一段，在北京遇到了当时对方项目组的一位哥们，简单沟通后了解到，他已经离开了那家公司而公司的老板是国内某最著名高校的教授……

综上所述，得出结论：在项目性软件产品的开发过程中，快速原型法要得到相关人员的重视，或者说不要生搬硬套规则！