界面的原型图完成之后，项目成员根据自己负责的任务进行开工，大家都在用心的做好计划，根据计划做好每一件事，甚至每天还要加班到深夜，但是为什么项目总是比预期的拖延呢？是需求增加？还是需求变更？如果对于敏捷项目开发(其他文章有论述，不再说明)，这并非是最重要的，我以自己的角度理解：

1、项目的需求是否清晰，产品需要对市场不断的调研、对不同行业竞品的分析，根据用户提出的需求，吸取别人的经验，大家一起讨论之后确定目标，避免以后的需求变更。

2、界面的原型图和交互图是否完善？是否有歧义的地方？有没有根据不同的状态，做出业务逻辑阐述，配备相应的文档说明，等到项目开发中，再去理这些业务逻辑会浪费很多时间。

3、UI组是否规范化，对原型图标注和切图时，是否符合开发人员的开发习惯，例如：对于按钮来说是图片还是文字，每行是否标注行高，特殊的界面，距离上下左右的边距是否有标记等。

4、移动组，写代码时的命名规范、编码规范，功能模块的封装，是否有利用复用，加快开发进度。

5、后台组，写代码时的命名规范、编码规范，接口文档的输出，返回的字段是否有注释，是否对不同的状态进行说明，是否有根据原型图进行对比，说明哪个字段对应哪个控件显示的内容。

6、测试组，是否有规范测试流程，将测试的结果，根据Bug类型，严重程度，优先级进行设置，研发人员反馈的问题，已修复，修复中，未修复，不能完成，测试人员再进行复测，形成一个闭环。

以上不管是哪个组，最重要的是自测，要自己检查自己输出的内容是否正常，是否符合同事的要求，是否符合用户的使用，一定要过自己这关。

做项目时，最理想的方式就是0沟通，因为沟通的成本很大，如果哪一组出现了问题，项目的不确定性就会随之而来，同时也会影响其他人的研发工作，在对接时，如果问题很多的话，就会直接影响到每个人的情绪。

无规则不成方圆，形成规范化，对于一个团队的合作配合，有着至关重要的必要性。

正文：

界面原型顺利完成之后，整个团队都想立刻甩开膀子写代码！但是，进入开发结算之前必须进行过程审计。公司质量经理审计之后认为诸多事项与公司的过程规范严重不符，在完成整改之前不同意进行开发。小M一下子就郁闷了:

第一，需求规格不符合公司规范。虽然做出了界面原型，但是原始需求除了那些铅笔草图，没有任何电子文档。第二，设计严重欠缺。系统架构、数据库都没有认真设计，每个模块的输人输出、处理流程、数据库接口、异常处理、提示信息等更是没有提及。第三，没有开发规范。按公司要求编码前要确定完整的开发规范，并对所有的开发人员进行培训，现在没有一点准备。第四，工作计划不足。除了有个简单的进度计划，其他如配管管理计划、测试计划、质量保证计划等文档一概没.有.....

用质量经理的话说这就是个“三无”项目，是个负面典型！小M苦苦哀求、以“时间紧、任务重”为由希望网开一面，承诺开发完成之后一定补文档。质量经理对小M的这套说辞太熟悉了，根本不予理睬。说实话，以前审计中发现文档偷工减料是常事，如果要求严格项目组还可能会补上，一旦松动，项目结束后人就“一哄而散了”，以后质量经理找谁去?

小M也知道，文档不全最苦的是以后接手的维护人员。面对天书一样的代码绝对不敢轻举妄动。现在，公司的管理已经日趋严格，给予了质量经理非常大的权限，审计不合格就是可以暂停项目。看来这个“文档”的槛是过不去了!

质量经理离开小组之后，小M和大家一起商量对策。发哥提议做点文档应付检查，从以往的经验看，检查时对形式的关注大于内容，有一些小窍门可以保证审计过关。南拳和北腿对这种糊弄人的做法很不屑，认为糊弄人的东西再少也是浪费时间。大师兄经验多，也吃过没有文档的苦头，建议拣重要的文档好好整理一下，不重要的就糊弄糊弄。

小M比较赞同大师兄的建议，但是有个现实的问题：快速开发工具有一定的实验性质，有些实现方法只是设想，需要写代码进行验证；验证通不过的话还要尝试其他方法。也就是说，很多情况下是完成编码才能确定设计，设计文档现在想写也写不出来呀！

小M拿不定主意了，只好找到S总商量对策。S总也觉得问题有点棘手，于是带着小M一起找主管质量的公司高层领导商量。第一次见高层领导小M还真有点紧张，越想注意遣词造句就越是前言不搭后语。S总听着着急，直接三言两语就把问题说清楚了。

听完两位的解释，高层领导又问了一些问题，然后说:“刚刚进行的审计过程确实有一些偏差。 根据你的描述质量经理是按照“瀑布模型”的过程规范审计你们的项目的，但我初步听下来你们更像是按“原型法”的过程进行开发。这两种方法的流程和文档要求差别很大。这样吧，我安排一个有经验的过程改进的大拿帮你们梳理一下过程和文档吧。”

听说自己的问题有解，小M立刻请那位过程改进的大拿到项目组现场解决问题。大拿先是了解了需求范围和前期工作内容，然后问小M怎么选择的开发模型。

小M听得一头雾水:选择开发模型？公司的规范不就是那一大本书，哪里有什么好处的？大拿说，就在那一大本里有专门介绍如何选择开发模型的章节啊。这下小M有点不好意思了，说实话大家一看到那一本大书过程规范就头痛，很少有人认真地看过一遍，自己真不清楚里面还有这些内容。

在大拿的指点下，小M才发现过程规范里有好几种开发模型，大家常用瀑布模型，所以原型法、增量法什么的都没有注意看。  通过进一步沟通大拿觉得小M他们的开发过程更接近原型法，也就是先构造一个功能简单的小系统，然后不断扩充、逐步完善，直到形成一个满足用户需求的真实系统。如果用原型法，大拿建议大致过程如下:

第一步，做出界面原型演示工作原理和交互的过程，这一 步小M他们已经完成。  

第二步，通过编码验证关键功能的实现方法，然后分别开发各模块。这时系统可以先不连接起来，而是通过一些临时的驱动程序模拟模块的输人和输出，以降低验证的复杂度。

第三步，把各模块连接起来，用真实数据串接整个流程，把原型系统演化成为真实系统。

听到这里小M觉得真是遇到救星了，跟自己以前设想的路径几乎一样！但是，其他人似乎更关心能省哪些文档。结合项目的实际情况，大拿对文档进行了裁减并确定了几个必需的文档。

1)需求规格:那些铅笔画的草图可以作为临时的需求规格，只是在项目完成之后必须整理成规范的文档。需求规格不能省略，即使有了界面原型，但如果根据界面原型反向推测原始需求得费多大的精力!

2)接口定义:快速开发工具结构简单，性能要求不高，不需要进行架构设计。但是接口设计还是必要的，必须说明模块相互之间的调用关系和接口标准。

3)设计文件:数据库一定要完成设计，这部分不能省。简单的程序有过程的文字说明一编码前怎么也要 先有个思路嘛;逻辑复杂的程序必须画出流程图，否则以后的维护人员得“看者零件猜它是怎么加工出来的”。 

 4)开发规范:这部分公司有现成的模板和样例，其实不需要写很多东西，  只要根据项目实际情况选用脑行。命名规范、编码规范、异常处理和提示信息  等应该形成统一-的标准，而且应该全员培训。  特别容易忽略的是异常处理和提  示信息规范，如果出错了都只写行“XXXX出现错误”，测试时怎么定位  错误?用户怎么知道该如何应对?

还有，进度计划也需要项目组自已根据实际情况细化。但是其余的管理文档大拿答应安排一个质量经理帮助整理。

听完大拿的指教小M心情豁然开朗，不仅对这位大拿的专业精神赞不绝口，对那一大本过程规范也突然有了几分好感。后来小M才知道，那位大拿以前可是位开发高手，为了确保过程规范不脱离实践公司才“忍痛”将他从开发部门调出来的。

随后的几天时间里， 项目组紧张地完成了系统设计、文档整理和规范培训工作。其实，磨刀不误砍柴工，虽然多花了这点时间，但大家对整个开发过程和实现步骤清晰多了，对整体架构、调用关系和接口也都确认了，特别是大家觉得开发规范培训对提高后续的开发效率和质量帮助非常大。

正如大拿所说，规范是从实践中产生的，凝结了很多人的智慧和经验，遵守它可以少走很多弯路;同时，规范又是为实践服务的，实践变化了规范也要不断改进，两者只有相辅相成、有机结合才能达成目标。