我们开始针对功能点清单编写我们的功能设计说明书。

我们是按照优先级来编写功能设计说明书的。我们并不会把功能设计说明书都编写完毕后才开始编码。而是，我们先把优先级为一的详细功能设计编写出来，开始开发。二级的功能编写会在开发人员进行一级功能编码的时候并行。

功能详细设计说明书由业务开发组的组长来编写，属于系统类功能或公共类的功能，都归给公共代码人员来编写，需要复杂的算法，高性能，高安全，高数据量，需求一直未确定终解决方案的未来未知变化的接口，也都由公共代码人员来编写。所以，一个开发团队，有高技术的公共代码人员，有深刻理解业务的业务开发组组长，有普通的coding人员。业务开发组的组长一般由熟悉客户业务，编码经验较多但技术能力一般、踏实细心负责适合团队管理的人担任。

功能设计说明书，根据每个功能点详细展开描述。一般一个功能点由一个EXCEL文档来详细描述。

EXCEL文档第一个sheet中是版本信息，每次修改都有变更记录。第二个sheet是页面布局。我们通常会用PPT或开发工具建立个界面草图，然后贴上去。第三个sheet是页面上面的每个字段的说明，如默认值、不可为空、输入约束、主键、输入长度、参照录入等等。第四个sheet，如果有必要，可以用VISIO画出业务流程图。第五个sheet是关于运行要求，如易用性、安全性、性能、数据量、并发性，这几个特性都分为高中低三个等级。另外，对运行的操作系统、内存都做了低要求。一个功能，必须考虑它的用户的计算机水平，否则功能很实用，但操作不习惯，客户非要改成客户习惯的方法，我们经常会面临这样的要求。与其那样让客户赶着我们，还不如我们自己提前在设计的时候要求我们自己。我们在需求调研的阶段会调研客户的信息化现状，如IT维护人员能力，信息化应用能力，客户老板对信息化认知理解，终用户信息化操作能力。

我经常看见不少客户没有IT维护人员，不知道有服务器这一说法，更不知道什么是SQLSERVER，也不知道备份。对于信息化的理解是上套软件，装个XP还不知道WINDOWS要升级（很多上网的机器连XP SP2都不装，什么防火墙放木马的都没有），知道装个瑞星杀毒，天天抱怨机器超慢。一看机器，也确实是老了，2002年的机器，128M内存。而且操作者打字和鼠标都不灵光，让他双击或鼠标右键，他根本不理解。跟他电话里说打开某个功能菜单，他很莫名其妙电脑中怎么会有菜单？如果你的软件是基于.net的，他连.net 运行时都不知道到哪里去下载。所以我们的软件需要在什么硬件上什么基础软件上运行，数据量多大仍然可以运行流畅，我们的软件要达到的易用操作程度，要达到的易用维护程度等等，我们必须在设计期考虑到。

很多做软件开发的，尤其不注重这方面，所以我在这里重点强调?嗦一下。大家不要耻笑用户，大家的工资都是他们给咱们的，而不是老板。用户不是计算机高手，他们不懂双击、滚动、鼠标右键很正常。我们的衣食父母，我们要好好对待。我们不要和我们的钱作对。

EXCEL功能设计文档到此，其实还缺一块。是数据操作流程。

我们先不编写数据操作流程。我们会先交给测试组的人员来校验这个功能点的详细设计，是否和需求流程和需求要求吻合，不符合的地方整改。

整改后的功能设计文档，算是和需求说明文档一致，设计正确。这时候才涉及到具体的实现说明。

我们会让公共代码人员出界面输入输出和业务流程图中整理出数据结构。我们为什么不让业务开发组的组长来整理表结构，是由于业务开发组的组长熟知业务却对技术并不精通。数据结构很影响未来的性能、扩展，所以应该由公共代码人员来设计表结构，并且建立视图和存储过程。

公共代码人员为了考虑性能和扩展，表结构的设计可能被打散成多个表，而不是业务开发组长自然理解的存储结构。所以公共代码人员建立了视图，保证在视图的层面上让业务代码开发组的人看到的是一个自然的业务实体数据结构，根本无须理解内部的表结构之间的关联关系。而且有存储过程来保证如何无须知道表之间的关联关系可以增删改数据。

从这种分工配合来看，我们采取的是从后到前的开发方法。先有数据层，有基础表结构、视图、存储过程，然后基于视图和存储过程进行业务流程代码开发，终由普通的业务开发人员进行界面拖控件绘制界面。所以业务开发人员既不熟悉业务，也不熟悉技术。

公共代码人员把设计完毕的数据结构交给业务开发组组长，组长来编写每个功能的数据增删改查操作文档。增加这部分文档到EXCEL中，成为第六个sheet。
我没有研究过测试驱动。我一直提倡的是全程测试，从需求到设计到代码到文档到打包，都要经过测试。只有每个环节都能保证正确，结果才会正确。如果到了代码编写完后才发现了不对，甚至是需求一开始理解的不对或有矛盾流程，这糟糕了。许多人喊需求总变，项目进度无法保证，不仅仅是没有配备需求调研人、业务开发组组长、测试人，更是研发流程方法上有问题，没有采取全程测试。

文档编写完毕一个整块（不是全部的一级功能编写完毕后），我们会交付给业务开发组去开发。具体开发人员任务安排，由业务开发组组长来决定。需要由公共开发人员来开发的，业务开发组组长都会根据自己的开发计划和公共开发人员的任务列表（我们用需求管理系统来安排每个人的开发任务），告知公共开发人员预期的实现完毕时间。

这样，公共开发和业务开发在并行，设计编写和功能开发在并行，设计和设计测试在并行，代码和代码测试在并行（我们采取的是版本管理和每日构建）。这样的情形跟流水线工作一样，颇有点像丰田的流水线生产，一旦发现某个环节出现问题，理解集中人力来解决，而不会让这个问题的这个人延期钻牛角尖，否则，所有的项目进度管理都成了一句空话。没有了实质的进度，也没有了实质的项目预算管理。那到底能不能赚钱，真成了一个鬼才知道的问题。

很多朋友在开发当中没有写过文档，一旦有想法要正规化研发管理，动辄要求全程文档，这文档，那文档，把开发人员累的，后产品质量和产品进度都没有保证。一看试验失败，全盘否定编写文档，再回归到一无所有的状况。真是走两个极端。

希望这篇文章能够给大家以平和的心态看待编写文档。我们并不是为了正规才编写文档，我们写的每一个文档都有作用。我们也在力求能少写少写，根据团队的、客户的磨合理解共识程度，哪个文档或哪个环节不需要写，我们砍掉。

我们并不在乎正规不正规，我们也并不在乎我们看上去很美，那没有用。我们只是商业开发，我们要的是可控，在有限的人力资源、合同额、合同周期内交付出客户认可的质量产品（不是高质量，是客户能接受的质量，我们从来不为没有利益回报的东西多付出）。