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

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

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

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

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

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

下图来自网上，说明了各方理解的“需求” 和成果的差异：

需求理解的差异

2、把编码工作提到了概要设计和详细设计的前面或者并行，不等待所有的文档都完成才去进行下一步的工作。任何好的制度如果僵化，就会出现与制度目的背离的结果，请参考byteh的另一篇博文央视2.4秒门对管理的启示 。

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

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

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

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

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

 

为了网友们阅读，特搜集些“”知识，如下文。

【原型法

　　原型法（Prototyping）是20世纪80年代随着计算机软件技术的发展，特别是在关系数据库系统（Relational Data Base System，RDBS）、第四代程序生成语言（4th Generation Language，4GL）和各种系统开发生成环境产生的基础上，提出的一种从设计思想、工具、手段都全新的系统开发方法。它摒弃了那种一步步周密细致地调查分析，然后逐步整理出文字档案，最后才能让用户看到结果的繁琐作法。

快速原型法

通常简称为原型法，其核心是，用交互的，快速建立起来的原型取代了形式的、僵硬的（不允许更改的）大部头的规格说明，用户通过在计算机上实际运行和试用原型系统而向开发者提供真实的、具体的反馈意见。

原型法的工作步骤

　　利用原型法进行信息系统的设计过程中，分四步进行：首先快速分析，弄清用户/设计者的基本信息需求；然后构造原型，开发初始原型系统；之后，用户和系统开发人员使用并评价原型；最后系统开发人员修改和完善原型系统。

原型法的优缺点

　　（1）优点：符合人们认识事物的规律，系统开发循序渐进，反复修改，确保较好的用户满意度；开发周期短，费用相对少；由于有用户的直接参与，系统更加贴近实际；易学易用，减少用户的培训时间；应变能力强。

（2）缺点：不适合大规模系统的开发；开发过程管理要求高，整个开发过程要经过“修改—评价—再修改”的多次反复；用户过早看到系统原型，误认为系统就是这个模样，易使用户失去信心；开发人员易将原型取代系统分析；缺乏规范化的文档资料。】

既然了解缺点，就要去改正去克服，“明知故犯”罪加一等！

 

 

 

博主推荐阅读：
    笨的方法往往最有效---写在被评为推荐博客

 丢了东西，哪个互联网大佬来帮我找
    互动与零距离:得民心者得天下
    管理的最高目标:1加1等于1  
    创业靠激情守业靠制度
    如何制定好的方案之一:方案与纸上谈兵