第三回合，开发胜出。.2

对于文案人员来说，软件必须能让文案人员编写文档。许多软件没有设计文档，代码开发完毕，让文案人员自己边学习操作边辅助测试边编写文档。文案人员不是设计人员，不是代码编写人员，不是测试人员，是对软件做陌生的人。他本身都对软件不了解，可想他自己写的帮助文档有多大的可帮助性。软件没有帮助文档，其根源就在于没有设计文档。而没有设计文档的根源，在于根本没有编写设计文档的人。谁来编写设计文档？程序员？程序员再写代码。测试人员？文案人员？实施人员？培训人员？到底谁来写这个设计文档。

我看过许多网友在讨论怎样一个软件才算一个好软件，说了很多方面。但是从现实来说，我们真的需要那么多方面吗？

往往现实一开发，什么好软件的标准都丢了，程序员单枪匹马上手。还有一些开发团队，希望能做一个好软件，于是希望把这些好软件的标准都实现了，最后周期长，在有限的人力和开发时间内无法完成，只好虎头蛇尾，最终还是个烂软件。

业界有个笑话，就是说微软的软件，从第三个版本才能使用。

这说明，一个好软件，应该具备好软件的标准，但一个好软件，不是在一个版本就把这些标准全部实现。而是有步骤有重点的实现，逐步达到一个好软件。

那么，这些好软件的标准就必然需要排个顺序。

编软件，是为了什么？

是为了卖。

怎么才能卖个好价格呢？

嗯，包装成漂亮的就能卖个好价格。巩俐穿上棉袄也就是个秋菊，村姑化完妆也是个靓女。韩国整容大家有目共睹。

就是这个思路。

所以，我并没有把软件实用放成第一位。因为新软件研发，你并没有很深刻理解客户，你假设认定这个需求很实用，到了现实使用发现无法执行下去，这就废了。而且实用不实用，每个客户的理解是不一样的。有人觉得电子邮箱很实用，有人觉得电子邮箱没有用。就这个情况。所以，我设计软件，往往只设计不超过3个实用亮点，实用亮点多了，我们开发也周期长成本高难度大客户可能还接受不了，而且过于复杂销售和实施人员无法给客户讲明白。所以有1-2个宣传亮点就OK。在不断销售不断实施过程中，客户会自然提出来需求，软件就会不断实用起来。

然后，我就会把软件包装漂亮。专业的销售方案PPT，专业的帮助文档，专业的软件界面，专业的图标，统一的操作，统一的字体，统一的专业词条，统一的对齐，专业的提示（很多软件提示居然是：“不好意思，出错啦”。真汗~）。这需要美工、文案、界面开发人员三者配合。

漂亮过后，就是稳定。稳定就需要软件具备可测试性。

这样，软件就可以出去销售第一版了。

到了软件第二版，客户签单量就上来了。实施工具就要提上开发日程，否则多个项目并行提出来的需求能把程序员的工作排到明年。

到了软件第三版，客户签单量更大，老客户也用了1-2年了。服务的压力上来了。所以软件必须可跟踪可自动升级，在持续不断增加实用功能，增强功能稳定性的基础上，这是软件第三版的重点。

到了软件第四版，软件越来越复杂，如何兼容，如何容错，如何容易阅读，如何容易修改就成了首要问题。这个版本，重点就是内部代码重构优化。

到了软件第五版，性能是个问题。过去3-4年积累的数据使系统越来越慢。优化性能成为第五版的重点。

到了软件第六版，由于这么多版本的升级，功能很是复杂了，使原本易用的软件现在变的越来越难懂了，到底是特殊处理的业务。把常用功能和非常用功能分开，把正常业务处理和异常业务处理分开，做到组合裁减，一部份不常用的功能就渐渐萎缩掉，一部份常用的功能做增强。在这一版本，重构易用性成为重点。

软件到了第七版，就几乎在打补丁了，不再投入大量人去维护了。软件进入大销售大实施大维护的收割阶段，维护本版本的开发团队在萎缩，下一代产品在酝酿。

这就是一个软件生命周期中，不同时期的不同开发重点。把握好节奏，合适的时机做合适的事情，一点都不浪费投入人力。

但是我们要注意，性能是一个结构性的问题。所以虽然在第五版才调整性能，但对于企业管理软件来说，必须在基础设计的时候就强烈关注数据库设计。因为数据库结构一旦固定就无法更改。从过去的经验来看，只要数据库没有设计缺陷，性能的瓶颈主要在代码上，只要改进代码和功能设计（有些功能设计本身就性能很低，大量的功能集成在一个界面上岂能不慢？），性能是很好解决的。

对于代码的重构和优化，如果从始到终遵循着函数封装，小函数分割（我曾经遇见过一个3000行的大流水函数，不敢下手，怕一旦修改不知会发生哪些BUG），优化和重构也是很容易做到的。

网友们讨论了许多，有实用性、稳定性、容错性、性能、可测试、可理解、可修改、可实施、可支持、灵活性、移植性、兼容性、安全性、易用性....。

但这么多要求，我们都要有目的分阶段的一步步达到。而且，往往我们不断补齐上一阶段留下的遗憾，我们此阶段的努力又会形成下一阶段的遗憾，总是无法达到一个赏心悦目可以笑看江波的软件。可能，世事轮回皆此规律。

后注：

八部众为佛经故事。八部分别为八种似人非人，似神非神，似鬼非鬼，似善非善，似恶非恶的种类组成，他们散落在佛界三十三重天，或喜或嗔或怒或思或乐，但种类之间总是互相关联互相矛盾又互相共生，层层迷障无法拈花微笑。

一个好软件，也是如此多的标准特性，也是如此共生又如此矛盾，颇为神似。

24、葵花点穴手

我的手下经常会面临这样一个问题：客户必须让咱们按他们的需求改，您看怎么办？

这种情景大家可能很熟悉，一个业务处理，可以这样处理，也可以那样处理。你的软件采用了你的处理方法，客户采用了客户自己的处理方法。两种方法平风秋色，没有优劣。但客户用惯了自己的方法，所以必须让软件改成客户自己的方法。

不改吧。没有理由，因为两种方案都差不多，但客户就是客户，客户占上风，否则就不验收不给尾款。改吧，又有什么意义？这家客户习惯了这种方法，下一家客户又不适应这家客户的方法怎么办？到一家改一家？

这都成了什么事。

我也深被这种问题困扰，至今没有好的解决方法。但我仍然力求找到一些方法去改善。我就是这样一个人，能改善一点就改善一点，量变就会发生质变（当然，做这样的管理者需要时时观察细致分析研发过程中的问题）。我这几天看丰田管理方法，丰田连一个工人的左右手空闲和手臂抬高高度和次数都做了细致分析。因为手臂抬高高度和次数决定了这个工人的有效的工作时间和工作强度，我们工作的时候如果老需要不断扭脖

子，我相信很快就会得颈椎病。

一个软件，经过多年的发展，不断的客户实施，加入了很多客户的需求。我们返回头可能会发现这样一个现象：我们走的太多，我们甚至忘了我们为什么要走。当时当景，我们觉得客户说的在理，不修改就说不过去，于是做了修改，但天长日久的修改积累，我们发现软件主要要解决的问题已经被无数的功能左延伸右扩展，已经不是一个能一句话说清楚到底干什么的软件了。所以，做企业管理软件有句笑话：ERP是个筐，什么都敢往里装。

说不清楚一个软件到底是干什么的，是个很大的问题。销售给客户说不明白，老员工给新员工说不明白（甚至新员工不知道这个软件有什么价值，没什么存在的意义），渐渐的，整个员工群体都在糊里糊涂的工作，反正有这个产品在，就打电话销售跟单呗，客户问什么都说软件都有都能满足。研发呢，客户有需求就修改。实施呢，签了单子就去实施，有什么软件功能就教用户怎么使，然后尽量让他使起来，管他需要不需要，管他急需不急需，管他合适不合适。支持呢，有问题就回答。大家都在做一天和尚撞一天钟。

我想到了曾经看过的微软的一种方法：

对于什么目标市场的客户（一定要精确描述好你的目标市场，千万别用什么中小型企业之类的词语）而言，你的什么产品或服务（针对这类目标客户，你提供了相应的什么产品或服务，这个产品或服务一定要与你的目标客户匹配），提供了什么主要价值（要精确，千万不要说提高了管理水平。管理这个东西很模糊，就类似这个企业管理水平低，到底指的是什么），因为你的这个产品或服务提供了什么独到之处（一定要独到，否则人家为什么买你们，而不是买别人的）。

这是微软的一个产品定位方法。

还有一种我自己总结的方法：干什么，用什么。

例如，杀毒，用瑞星。聊天，用QQ。看新闻，上新浪。写文章，用WORD。就这么定位清楚。我们知道，QQ有很多功能，不仅仅是聊天，新浪也不仅仅是新闻。但我们能把我们的企业管理软件也讲的这么清楚就非常好了。记帐，用XX软件。记录进销存，用XX软件。但偏偏这个世界发明了几个很高的词，还云里雾里解释了很多，越解释让客户听的越摸不着头脑。如：SCM、ERP、CRM、Web2.0、SOA。而做企业管理软件，却又往往要

遇到这几个词。落实下的产品到底是不是SCM、ERP、CRM、Web2.0、SOA，自己和客户谁都不明白，只能是客户目前有什么需求（这个需求可能根本不属于这些范畴）就做什么需求。

为了防止软件成为大杂烩（想起了猫扑，我一直不知道这个网是干什么的，只好把它定位于搞怪集中地，但好像也不对。年轻人的门户，好像也不对。），我经常用微软的方法和我自己的那个简单方法来校验产品，定期给大家传达，让大家渐渐模糊的产品印象又清晰重点起来。

我们也会经常一起讨论，我们的产品最适合什么样的客户，第二适合的客户是什么样的客户，第三适合的客户是什么样的客户。由此不断校正我们的目标客户群，调整我们的营销策略、销售策略、定价策略、服务策略、需求定制策略。

我们在描述最适合什么样的客户的时候，为了描述精确，用的方法是拟人法。

我们不会泛泛而谈，我们会从现在的客户群中找出最适合的已经购买使用了我们产品的客户。一一描述他们的组织结构、企业文化、老板性格、老板管理风格、中间干部的管理流程、考核方法。不过，往往我们无法找出一个完美客户，能把我们的软件各个功能都是用的很好的客户，于是我们就拼凑，把各个功能使用优秀的客户分别挑出来，然后都按照组织结构、企业文化、老板性格...等等这些方面来描述，然后把他们综合在一起，一个“完美”的最佳客户就出来了。

我们在讨论期间，为了深刻的体会，往往都把这些客户的公司名称，城市（中国真是差异很大，东北人，浙江人，广东人，截然不同），用户姓名，部门，年龄，性别，婚姻状况，从业经历，性格，如何思考问题，他讨厌什么，他喜欢什么，他关注什么，家乡，什么学校毕业，计算机水平，工作环境，每天大部分基本在干什么事都描述下来。如，我们老说：XX公司的XX，老喜欢反对别人的意见，不管别人是对是错，总要说出自己的意见，显得自己很独特。还老爱用手那样捋一下头发。唉，他也是三十五六岁的人了，但还是个小头

儿，老觉得自己满腹经纶老板不赏识。

这样，一个活灵活现的形象就出来了。我们大家的讨论就有了基础。省得老有人提：不可能有这样的事情，谁傻蛋了这么想。但一说到现实具体例子，大家就都明白了，确实是林子大了，什么鸟都能飞出来。（可能也有鸟人）

我们以后去做销售、实施的时候，就把当前这个客户和我们设计的这个最佳客户进行对比，很快就能分析出这个客户最适合使用哪部分，它的优点在哪里，它的缺点在哪里，它的差距多大，从什么方面去提升。所以做销售，总是很快能把握住客户的兴奋点，做实施的时候也很快能根据客户的关注重点来突破和提升。其实这种方法，在业界有个很标准的名字，叫“标杆法”。

我们描述完最佳客户，我们就要去列举这个最佳客户的需求。我们到底要解决这个最佳客户的什么问题？

一个企业的经营，都有一本难念的经。每个阶段都有烦恼，小有小的压力，大有大的臃肿，中不溜还上不上下不下难受。各个方面都会有问题，从老板的管理风格，到企业财务核算，到企业财务报销，到企业考核，到招聘培训，到销售到服务，涉及到各个层次各个角度。真要数落问题，每个公司数完后都觉得这个公司没救了，但事实上这样的公司还活的好好的。所以，看事情要平和，你眼睛老盯着灰暗，你会觉得真个世界都太黑暗了，你活着太痛苦了，这就不对了。这真是自己跟自己过不去（有句笑话：饿你两天，你啥也不黑暗

了，能吃个窝头也感动的痛哭流涕）。

所以，如果我们真要去解决企业这么多问题，我们也不是万能公司，也没有能力解决。我们只能解决我们擅长解决的问题。但是我们擅长解决的问题，真的是企业现在急需的吗？这又是一个问题。解决了也不疼不痒，那企业怎会买单？

所以，我们把企业急需，而且我们擅长的，而且我们的解决方法是我们的目标客户能够执行的（别想出一个解决方法，但要人要钱要时间，哪里有这么充分的条件？这样的解决方法说明就不可行），而且解决后能有明显效果（很多东西是长期才能看出效果，这类问题的解决就比较痛苦，我们不希望这么做，这样会使观望的客户的投资购买延迟），而且客户愿意为这样的解决方法买单，而且买单的金额符合我们的盈利目标（我们也不是雷锋）。

经过这样一筛选，确实剩不下几个急需解决的问题点了。有时候大家讨论偏了，还会讨论到什么点都不剩了，于是停下来，重新过，不要讨论的那么极端。然后大家在这些问题点上统一认同。我们做营销，就是针对这些问题点提出我们的解决方案。我们的软件发展导向，也是趋向解决这几个重点问题点。这样，我们的营销和产品就是统一的。就不会出现我们老看到的一些现象：营销说的是一个东西，拿到手是另一个东西。

全公司同一个思路，同一个目标，这是最厉害的。（这让我想起了，有人曾经想UML把客户、设计、开发、测试都串在一起）。在软件公司中，把营销、销售、开发、实施、服务想串在一起也是非常困难的，大家对客户的体验是不一样的，关注的重点也是不一样的。所以，用这种方法来描述客户，描述客户问题，全公司的认识就统一了（当然，那些技术至上者除外，他们可能只想借公司资源把自己练成高高手，我直到现在也不明白练成高高手而不能解决客户问题到底是为了什么要练。我过去深入学习组件技术，搭建业务平台架构，学习数据库技术，皆为解决客户手头急需的问题。客户其实只想解决问题而已，什么技术都无所谓，只要能解决了，最好是越简单越好的解决方法）。

25、文档知多少

去年，我们要让软件开发团队管理上台阶。

我们由于处于企业管理软件开发领域，而对日外包大部分接的单子都是管理软件之类的单子，但是人家的项目管理、进度、质量都比我们好，如果他们再配合管理咨询公司作为合作伙伴，再加上大规模的服务呼叫中心，像我们之类岂有出路？

于是我们就想到了引入对日外包的开发过程管理。

大家一想起对日外包，就想到了大量的文档和大量的代码工人，想到了详细设计说明书甚至到函数级、伪代码级。

要不要引入的时候，我们内部也做了争论。觉得对日外包，人家接的单子额比国内客户大，所以也能招聘大规模的员工，而且对日外包，日本人是很理性的看待项目周期的（国内客户要求一个月开发完上线），而且日本人都做了半年到一年的调研和设计分析（国内调研几乎只是一个上午，坐在一起瞎聊，根本不成方法）。所以对日外包不适合咱们。咱们没有钱招聘一定数量的人（即使我们只需要普通员工，而不是人才，我们也没多余的钱），当然我们也无法分离那么多专职的项目管理、开发、测试、文档、配置管理岗位。我们的客户对于软件的认知决定了我们无法在调研、设计上下太多功夫（单子额就那么大，客户认为软件就值那么多钱，当然无须对软件生产各个环节进行重视）。

不过，我还是坚持进行引入。是骡子是马，咱们拉出来遛遛。还没遛，就说不行。这不是小时候的小马过河了么？

引了进来，合作伙伴给我们派了一位质量控制部的人员。

一入手，发现有个很关键的问题，方法的源头。

因为对日外包，都是接单生产，主要是编码、测试，保证生产进度和质量要求。但编码之前的所有环节，对日外包公司并不清楚。他们只知道拿人家给的设计书开始coding，设计书怎么来的，前面环节产生过哪些文档，不清楚。

幸亏我们过去有系统的调研方法，从调研描述现状、然后分析优化的组织结构、工作流程、考核报表、岗位职责四大块来描述需求。客户优化后的流程、工具中包含手工纸张信息、EXCEL信息、软件信息。

把这些转变为软件中的功能、权限、报表也一气呵成。组织结构和岗位职责决定了功能点和功能权限、工作流程决定了软件流程、工作流程中使用的纸张信息、EXCEL信息、软件信息就是数据输入，报表就是数据输出。这就是一个企业管理软件的四大块：组织权限、输入、处理流程、输出。

所以说，企业管理软件的开发是有方法和规律的，比较容易，就连最难的调研和需求管理也有方法。所以企业管理软件的开发，现在主要集中在大规模开发团队的组织、任务调度、人员培训（大规模的开发，必然需要的是一般素质的人员，而非高级人才，否则不可能有那么多资金来实现大规模开发）、大规模开发团队的质量和进度（人多了，各个层次各个水平的人都有，理解都不同，如何保证质量和进度是很关键的，否则很容易项目预算失控。一般素质的人多了，对于管理的要求是很高的，很容易成为乌合之众，只消耗不产出）。我特羡慕KFC，不管我们在大江南北哪里，迟到的KFC是一样的口味和品质，享受的服务和环境也差不多，这很难。那么多店，而且都是授权店而非自主经营店，那么多一般员工，而且员工流失和临时员工也非常多，居然能保证一样，管理水平实在了得。所以我经常学习KFC和丰田，如何使一般员工大规模配合工作。

对于企业管理软件开发过程中的文档，我们一般有需求分析说明书，其编写格式和思路，和我们的需求调研方法一致，也就是说，我们的需求调研的结果，落实到纸面，就有需求分析说明书，另外还有一份需求调研报告，是偏向于项目过程叙述的。

需求分析说明书回来，研发部内部会进行大家一起学习理解，然后讨论。

讨论主要由：需求调研人、业务组组长、测试组组长来参加。一个个的过流程。因为在需求调研期间，去的只是调研人，可能有想不全的地方。如果这样就直接进行开发，无疑会有很多漏洞。这样给开发、测试，都带来了返工修改，给项目管理也带来了项目进度、任务分配的调整，计划的打乱也间接影响了质量管理。

根据大家讨论补充后的需求分析说明书，就比较容易得到我们下面环节的文档。

首先我们会出功能点文档。

我们会把需求分析说明书中的业务功能都列出来清单，属于组织结构建立、组织角色、权限分配、登陆验证、基础数据维护之类的都归类到系统功能中。系统管理，各个企业管理软件差不多，我们又有公共的系统管理模块，就不需要重新发明轮子了。所以，我们主要重点是分析业务功能。

根据需求分析说明书中的每个流程，都先提出来成为一个功能点。然后针对现在整理出来的功能点，再一个个对照流程，如果这个流程复杂，就拆分，把这个功能点拆成几个复杂性和预估工作量差不多的功能点。经过这样的拆分，就形成了最终的功能点文档。

而功能点之间，根据上述方法的拆分，就形成了功能群。

功能点就成为功能权限控制的最小单位。功能群就成了软件菜单中的一项。几个相关联的功能群就成为了一个业务子系统。

就这样的方法，使子系统-功能菜单-功能点（可能是某个功能窗口上的功能按钮）三级分开，与组织结构-员工-角色-用户-权限结合。一个软件，未来会成为什么样子，大框架就出来了。

做功能点清单，就类似于跑马圈地，这个项目到底多大，我先把项目边界框起来，而不要让这个项目无边无界，那自然也不会有可落实的项目进度和项目管理。知道了项目最大做到多大，就能决定是亏是赚，是做还是不做，能不能做了，有可用的时间和人力来做否。

然后，我们会根据功能点清单，为每一个功能进行优先级的标示。我们通常会把优先级分为三级。这就意味着一个项目，大致分为三个阶段。一级是必须要做的，即使延期也要做，必须调度多加人手多加班也要完成。一级做完后，如果有时间，就把二级完成。如果时间超期，有适度的尽量去完成二级，可以延期，但也要根据预算和时间。如果适当延期也无法完成，我们会给客户去上线实施，变实施边并行开发，使实施团队和开发团队进行并行工作。所以，二级也是重要的功能。三级就是如果时间用完，三级的功能就要舍弃掉不开发。

一般是，按功能的重要性来划分优先级，我们在之前已经讲过，我们调研需求的时候，就把常用业务和异常业务分开，把每天做的业务，和每周、每月、每季、每年做的业务分开。几个结合特别紧密的，互相关联的，我们也会把他们划分在同一个优先级，需要单独开发的基础数据维护界面，我们也会放在同一个优先级。这样，只要我们项目到期，或者我们迫于竞争突变，我们会随时推出一个可以完整使用的系统。虽然这个系统可能功能简陋，但可以完整处理整个常用业务流程，而不会造成中断，无法处理下去。

很多开发团队，开发的方法是先字典功能，然后是业务功能，然后是报表。这种开发方法就导致了很多业务系统，客户上线使用了，光输入数据，没有输出，业务系统成了一个闷葫芦，用户得不到使用价值，可能只是减轻了工作量，加快了工作效率，提高了部门间的自动配合。更有甚者，业务功能开发了一半，到处都是断路，走不下去，无法成为一个完整的系统，就是个半成品，上不上下不下，无法适应竞争变化。

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

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

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

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

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

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

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

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

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

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

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

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

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

公共代码人员把设计完毕的数据结构交给业务开发组组长，组长来编写每个功能的数据增删改查操作文档。增加这部分文档到EXCEL中，成为第六个sheet。

我没有研究过测试驱动。我一直提倡的是全程测试，从需求到设计到代码到文档到打包，都要经过测试。只有每个环节都能保证正确，结果才会正确。如果到了代码编写完后才发现了不对，甚至是需求一开始就理解的不对或有矛盾流程，这就糟糕了。许多人喊需求总变，项目进度无法保证，不仅仅是没有配备需求调研人、业务开发组组长、测试人，更是研发流程方法上有问题，没有采取全程测试。

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

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

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

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

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

26、狮面人

好多人都说：你这个方法根本就不是三五个人十来条枪的方法，项目经理，公共代码开发员，测试员，文档员，那得多少人的公司才能配得齐这样的团队。

嗯。其实，我们的团队也不怎么大，我们本身也是一个很典型的中小企业。

一般，都是一个产品或一个项目，由一名业务开发组长、一名主程、一名辅程组成。如果项目简单，基本就是一名业务开发组长和一名主程构成。如果业务开发组长的开发实力也能和主程相当，而且刻苦努力，不仅协调做的好，需求设计做的好，代码开发也做的好，那么比较中型的项目也是这两个人组成。有几个产品，就会有几个这样配对的开发团队。

研发部其他的人就剩下项目经理、公共代码开发、测试员、文档员这些角色了。

一般，研发部会有一到两名项目经理。我们老承接一些大的合作开发集成项目，老需要有人去客户现场去和其他合作伙伴一起开会，讨论，方案提交、工作量报告、工作进度报告。总需要有人去跑这些项目协调会。另外，销售打单的时候，客户总会提出一些技术性的问题或某个需求能不能做的问题，销售也模棱两可，不知道能做还是不能做，于是总会拉上一名项目经理。关于产品的、技术的、开发周期、工作量估算、项目团队组成的PPT和方案由研发部的项目经理来做，关于价格和商务条件上的由销售来做。在打单过程中需要讲解产品或回答客户产品疑问，都让这名项目经理来兼任售前支持。对于项目型的，项目经理有时还担任需求调研经理，使用需求调研方法产出需求说明书。不过，需求调研，有时也是业务开发组长来做。主要看业务开发组长在客户面前的沟通力。因为业务开发组长是开发人员出身，但技术一般，业务知识很熟，管理能力差不多够管理个1-2人，工作年限长一些工作经验也多一些，但有些人比较内向，不适合和客户调研沟通，就不做需求调研。所以谁来做，看具体人。不过按职责来，项目经理和业务开发组长都要能做需求调研。

然后就是公共代码开发人员，一般就一个人。对于企业管理软件的开发，框架的开发和维护，公共代码的开发，高难度的问题跟踪，需要高性能的设计，需要高扩展性的设计，需要高稳定的代码，需要高安全的代码，需要高并发的操作，需要复杂代码重构。需要性能优化，不知道的技术API，都可以寻求这位公共代码开发人员的帮助。他还负责新技术跟踪、新技术介绍、新技术试验。但这个新技术必须是为了改进公司现有产品和现有客户。新技术的跟踪必须上报给技术总监，以防不符合公司目标乱跟踪或跟踪方法和思路不对。对于有利于现有开发的新技术，可以筹备好培训课，由研发部经理安排时间，让公共代码人员给研发部全体人员讲解。如果大家认可这种方法，就需要选择适当的时机在产品中引入。

研发部的测试人员，一般也兼任服务部门技术支持人员。如果有服务部门解决不了的技术问题，可以转给他。而且测试人员还兼任配置人员，在产品打包、产品安装测试、产品发布、版本分支管理、源代码备份、历史版本归档方面都由他来管理。兼职是有好多好处的。如果他不兼任技术支持，他就不了解客户是怎么使用的，他测试也是瞎测试。如果他不管理产品打包发布，程序员就会自己私自发布版本。可能版本还有问题，为了修补问题，就赶快修改完再打包一个，但版本号却不改变，引起了一个版本号代码不同错误不同，让服务支持起来很莫名其妙。由测试人员控制产品版本发布，能不能发布，就是测试员说了算。测试员感觉质量没有达到，就有权不发布。很多软件作坊，程序员权力很大，一个老哥从头到尾负责整个项目，项目质量如何，全看这位老哥自己的素质和责任心了。为了不让项目质量和特定人密切相关，使公司研发保持连贯性水准，必须做到分工专业，互相配合互相牵制。

一般，研发部也就配1-2名测试人员，根据同时并行的项目和产品开发和开发的强度来定。我们并不生产向国际上的产品那样的质量。我们做行业企业管理软件开发，是在客户质量要求、客户签单额、竞争对手质量水准这三者平衡上做到一个质量的认可。我们无法做到微软那样一比一的开发测试人员比例。研发部所有的产品和项目，都由这1-2名测试人员负责所有的测试工作，包括编写测试案例，编写测试结果，参与项目的需求测试、设计测试。

对于研发部的文档方面，如文档的正规化，都由文案来负责。项目经理经常要提交给客户一些文档，而项目经理往往是技术出身，文档工作水平不行，于是文档的正规化、美化、文字校对、空格段落措辞标点符号，都由文案制作。帮助文档，也由文案负责。帮助方面，有版本更新说明帮助、安全配置帮助、系统维护管理帮助、基础数据配置与维护帮助、业务功能操作帮助、软件操作演示视频、产品简介PPT、产品演示版，都由文案来做。为了防止文案不懂产品而写产品帮助，在需求说明书、设计说明书这些文档性的工作上，如果有什么文档体力活之类的工作，也由文案人员来做。文案人员还兼任产品辅助测试，主要是作为一个普通的操作者来测试，在制作演示版的过程中模拟客户流程客户数据来进行操作录入，测试出普通使用中的BUG。一般，一个专业的测试，经常呆在软件的环境中，思维就有一种定势，但实际的用户并不那样操作，但测试人员自身感不到。而文案人员就能充当普通用户来测试。我们招聘文案人员也没有强调会什么软件，文案写的好就OK。他们确实是最普通的用户，他们的困惑和操作手法代表了大量的普通用户。而一个研发部，文案人员也往往是1-2名，随并行的项目数量和规模来定。

所以说，一个研发部，一名研发部经理，1-2名开发人员，一名项目经理，一名公共代码开发人员，一名测试，一名文案，也就是5-6人完全符合一个软件作坊的人员数量。有时候团队小了，研发部经理就是项目经理，公共代码开发人员就是主程，这样，一个开发团队也就是3-4人就OK了。但方法照样能用起来。因为我所讲的方法也就是适应于这四套马车的组织架构的。每个人都身兼数职，而且都对自身的提高非常有好处，而不是给他身上堆砌毫不关联的工作内容。每一项职责都是能互相互补的，整体提高他的岗位专业性。

作为业务开发组组长，他很大的一个职责就是开发项目的进度和质量管理。手下也就1-2个人，开发人员的素质也就这么高，我们也会经常遇到突然来了个项目的事情或者突然有个过去的项目问题必须开发人员跟踪，所以开发人员也总是会被左抽右调。对于还能保证开发进度正常，业务开发组长确实每天都在监控进度异常，监控每个开发人员目前身上背着的开发任务和开发进展。每天下午5点的时候都要询问一下自己手下这两个人的开发进展。因为有的人不喜欢主动说自己遇到的什么问题，总喜欢自己去到处找答案，弄的延误了正常的开发计划。所以，开发组长必须每天下午5点主动问遇到了什么问题，是不是很棘手，能不能保证进度。如果不能保证，业务开发组长就会想办法，是全小组一起诊断出谋划策呢，还是寻求公共代码开发员呢，还是寻求研发部经理呢。为什么是下午5点？主要因为5：30-6：00就下班了。如果快下班了你才去问，大家早就心思不在这里了，谁都想赶快下班回家，问题就被隔了一夜，留了个不清楚的尾巴。如果在5点钟询问，有了问题，如果此问题业务开发组长有经历，他会很快决定该怎么解决。如果详细听完了此问题的来龙去脉，业务开发组长也无法决定，他已经清楚了问题，他会在晚上思考，第二天一上班来就有了决定。这就一叫一点都不耽误。