|
整个软件开发过程是一个相当复杂的流程，并不是简单的靠几个设计工程师自己在那边写软件就完，而是要有从头到尾，包括很多人，不同专家，不同的专业，不同的知识放在一起，最后才造成一个完善的软件产品。从决定开始，到计划、设计，最后到写程序、执行，然后还有测试、纠错、保证稳定、发行、部署、调试，整个过程是一个相当长的过程，并不是一个简单的程序。要为了保证软件的质量，能够达到客户满足和满足市场的要求，很要紧的工作，早期工作做的越是完善、仔细，避免后面的工作，由于前面不完善造成的返工，造成的浪费，起到关键性的作用。大家可能在 上读到在美国软件项目管理的权威，写过很多关于软件管理方面的书，很有名一个理论就是说他做过很多研究和调查，发现早期的工作要是没有做好，而造成后面工作的返工，带来的浪费是巨大的。有类似这样的图表，他做出的结论，如果在设计阶段出现了问题，在设计阶段如果你没有及时找到和纠正的话，到执行阶段才发现，你会看到三条不同的曲线，越是早期的错没有发现，最后由于要返工而造成的代价费用越来越高，如果前面没有问题，到最后只是发现半个纠错，花费的代价相当低，因为你是纠错，然后重新测试就完了。可是如果执行的时候，程序编程编错了，后来重新编，重新测试，这个费用相对来说就要高。如果是设计的时候出现错误，由于对需求管理没有管理好，客户和市场的要求都错了，开发出来的东西完全到后面重新执行、重新纠错的话，会看到这个曲线，几乎是几何形上升的，成倍的费用的增加。能够保证控制产品开发过程中间的费用增加，早期工作完善，做设计的时候，越早做的越完善，对控制后面的消耗起的作用是非常大的。
从这个方面讲，我早上举的例子造房子一样，造房子的蓝图，对盖一个房子的重要性，对早期设计的完善作用也是一样的。
什么是设计规范书。大家听过很多不同的名称，叫法也不一样，到底是什么东西。首先它是总结一个软件功能和性能、使用方案的总结书，是描述一个产品，到底该为客户提供什么服务，起到什么样的作用，到底可以完成什么任务，从这个角度对软件产品做一个总结,是提供软件功能和性能以及使用方案的总结。也就是说，他应该包括的内容是向开发人员很详细的描写清楚，这个软件到底应该怎么工作，他使用方案的总结，他的功能性的总结，而不应该包括产品具体的设计的构架，到底怎么执行，怎么设计，这方面内容其实是有不的文档或者文件去总结的。早上也提到，作为开发团队人员，当设计经理、项目经理把软件功能定完以后，真正产品怎么开发，是应该由设计团队人员去做。在微软有的比较大型的团队，我们有所谓的设计师，具体开发也开发团队的领队和开发人员，他们每个人根据功能的描写总结出来具体设计的执行方案，这个其实是不应该写在设计规范书里的，所以要理解清楚，设计规范书是描写产品对客户怎么用，而不是描写这个产品具体开发逻辑怎么执行，这个是和开发有关系的。作为设计规范书是项目经理的工作，就是要把这个产品的功能描写清楚。它该包含的内容和不该包含的内容不要搞混乱。
影响设计规范书的因素很多，首先最重要的是功能需求，客户对使用软件有它一定的要求，这个软件应该提供什么样的服务，该完成什么样的任务，这方面就叫做功能需求。其实是有不同的好几个因素来影响整个功能需求的，对市场竞争的分析，我们竞争的对手他的产品有什么样的功能，从而得出我们产品应该也有什么样的功能，甚至功能比他更好，这是对功能需求的起影响因素的。还有客户之间的回馈，他说我这个产品为我的行业做工作，这个和明显是客户具体的要求。还有就是用户解决问题的要求，比如说他说我不在乎你这个产品怎么开发，不管你以前的产品，或者你开发的产品以前有什么功能，由于要解决新的问题，必须加进这样的功能。还有用户所谓的使用方案，他真正解决问题，使用的方案流程是怎样的，由于他商业之间运行有直接关系，如果客户商业流程决定是这样的运作的顺序，你软件设备也应该要配合客户使用方案设计。所有这些是最关键的因素影响功能需求，功能需求也是第一个最要紧的影响到设计规范书该描述清楚的，解决的什么样的问题。
除此之外是性能需求，光描写说我这个软件按一个键可以写一个数字还不够，如果是客户要求我按一个数字，在0.3秒之内写出来，或者是我按键以后印出五百万字来，他显示数据的速度怎么样，他的要求也是影响到设计规范书的。他包括整个系统的要求，如果大型的软件，运行的系统，什么样的硬件，什么样的内存存什么样的 络，所有这些对性能的需求都起到影响。他的运行的环境，到底是有没有兼容不同的操作平台，不同的操作平台之间不同。对软件的功能也是起到影响的，还有安装部署，特别是大型的系统，因为我在搞工业控制很多年也知道，安装部署的要求，软件在实验室完成跑到真正大型的工厂里，完全是另外一回事。环境的安装部署要求，在很脏的环境里，边上有各种干扰的因素，在这样的运行这样的软件，性能是不是有保证，保证不会死机，数据不会出现什么错误，或者出现错误有什么样的反应，这些都会影响到开发软件的要求。还有是质量要求，有一部分是能解决的，还有一部分是不能解决的，中间的质量要求是碰到什么情况能够对付，碰到什么情况怎么应付，这些不同的用户都会有详细的要求，这些都是规范设计书应该总结的内容。
除了这些以外，还有非功能的要求，但是在设计的时候非得考虑到，包括地区、行业，甚至国家在某一个行业里的标准。象在欧美市场上，每个行业都有自己的标准。如果你是设计软件，为某一个行业设计，里面软件设计接口标准，可能使用数据规范，对于很多标准，如果你是对那些不熟悉，或者是不了解，甚至是用错的话，开发出来不符合那些客户要求就要改。这些和真正产品的功能毫无关系，可是要为了保证在以后产品开发出去避免这样的错误，由于这样的错误重新返归，就要把这些要求了解清楚。技术还有技术开发的局限，你想这样开发，你想提供这样的功能，但是首先得了解，目前客户所用的设备的硬件，或者他的运作的操作系统环境，有没有某些局限，你想开发性能的时候他没有办法达到，把这些事情弄很清楚的话，避免和客户讲不清楚的争论。在描写功能的时候，这个功能有什么样的能力，没有什么样的能力，描写的很清楚。
还有对时间的依赖，对外在因素的依赖，这里面是需要时间的。项目管理上所谓三角形的定理，有这么多时间，你有这么多资源只能开发出这么多功能。如果把你的时间砍掉一半，其他因素不变的情况下，绝对不能按时间、质量研发出来。这些都会影响到你设计规范书的撰写，你要写得很清楚，软件开发哪些能力我是可以完成的，哪些是不可以完成的。还有可用性的需求，软件为了要赢得客户的心，赢得市场的心，很要紧的一点，不光是把软件开发出来大家可以用，客户用了不会觉得很混乱，还是很闹心，还是用起来很顺手，这里面的可用性，这些东西也是很重要。什么因素决定可用性，用户的特点，不同的用户，不同的使用者，也会决定软件开发应该按照适合他们的要求。开发出来的软件是给一些专门的设计人员用的，那些人受过高等教育，都是很熟悉的，和你开发出来给爷爷奶奶用，这里边不同的客户，都有专门的特性，所以在微软把不同的使用者，分成不同类型的组群，这里的要求怎么回事。所有这些都是影响到可用性需求。整个设计规范书在描写完善的软件过程，这些都要考虑到。你不考虑的，不在乎的就去写软件，等你开发出来这些搞错的话，一定影响软件最后的质量。
在写规范书通常要经过什么样的步骤，做什么事情可以达到最后的结果你正在写之前，首先需要确定你要解决的问题，最要紧的是从市场需求来了解，我这个软件到底该做什么，这个软件是为什么样人服务的，做什么样的事情。定出你所要的功能之前，首先先要了解使用方案，三步法，知道客户的使用方案，从那个得出你的需求到底是怎样的。然后根据体的需求总结，定出你要设计的功能到底是哪些。由这些需求、总结定出这些功能，最后根据三步法设计功能。这样你设计的功能都是为了解决客户具体的使用方案，而不是设计的功能是毫无作用的。你不按照这样的方法做，常常让开发工程师自己随意开发出一些功能，功能开发出来看起来很不错，我们叫做很酷，可是不在客户的使用方案里起到具体的作用，可以在某一个软件的菜单上按一下可以做一些什么事情，可是客户根本用不着这个，这种开发出来是一个很大的浪费。让功能的建立设计在了解使用方案的基础上，由此得出的需求上就能避免浪费。这样每个开发出来的功能都是有目的的。
提纲的内容，通常在微软一般包括先写一个前沿，或者梗概，用非常简单的一小段解释这是给领导看或者是给客户看。你对产品开发高层次的理解是不是很清楚，总结你所开发的产品软件到底怎么做，有什么功能。你对一个产品的功能理解，是不是能够精简到几句话，不光你作为一个项目经理可以说出来，让你开发团队所有成员都能够明确无误的说出来，这是非常要紧的。特别是客户要求，你这个文件给他读的时候，可以很清楚的知道，对客户要求的理解是不是很清楚。等规范不完的时候，最后回去做对照。看一下我原来定的总结是要完成这些任务，最后设计完以后，回去对照是不是跟原来的计划一样的。从高层次帮你指导整个开发方向应该是怎样的。
这个项目重要成员，项目总结，包括开发团队的成员，开发团队或者测试团队联系方法。发现问题不知道该找谁，特别是团队的领队都要写在前面，联系方法。还有时间表的总结，你总的产品开发，大的里程碑，几月几 完成怎么样。还有对外部团队的依赖因素，很多开发可能都要靠好几个团队向你提供一部分功能，最后整合起来。在你产品做的时候，9月3 要完成的东西，但是8月30 我要让别的团队向我提供这些东西我9月3 就能完成，如果不能提供我9月3 就完不成。全都写清楚了，你才能知道。
在很多情况下可能要写一个开发的理由，为什么要开发这个软件别是作为一个公司开发很多不同的软件下，作为别的团队或者领导，或者是市场营业经理，可能先要了解你这个软件是干什么的，在整个企业的战略情况下，整个战略方向为企业起什么作用。很多产品在开发，技术可能是相互交错的，要讲清楚为什么这个团队花这么多钱、这么多精力，开发这个技术，为什么不用别的团队已经有的技术，或者类似的技术，他们要按照什么样的建议开发，所有的东西都要写出来。一般的内容，我们做如下的解释，开发的理由，如果我不开发这个，或者我用别人的，或者我的功能不开发，对公司长期企业的效果起什么影响，对我们市场竞争能力带来什么影响。如果我们不开发，我们的竞争对手六个月之后开发出来，我们的市场可能从第一位降到第五、第六，领导看了以后就会感觉不一样，你要用具体的数字帮你们证明，为什么要开发这样的功能。还有所需要的资源、消费，和不开发带来费用比较也是很要紧的。我要开发什么东西，我要花这么多、精力、人和资源的消费，可是我如果不开发，我市场损失是什么，这就帮助领导或者客户做决定，什么情况下多少钱、多少功能你该做的。对成功企业的影响，对整个市场的影响，要开发不开发，或者现在开发几个月后开发，这个时间是不同的。在描写具体功能之前，先要讲为什么要开发这些东西。要很清楚你开发的目标，我们叫做远景目标。开发的目的是干什么，到底是开发什么样的。为什么要开发，你要讲清楚开发什么样的软件。这是总结和列出来你要开发的远景目标，归根到底要完成什么任务，达成什么目标。
撰写内容，首先对公司企业战略上的影响，市场上的影响，技术上、功能上，所有的东西从这些层次来描写，我们该完成什么样的任务。你在开发前把目标定义清楚，后来帮助你做解决，什么情况下开发时用什么技术，如果符合我的目标就做，如果不符合我的目标，到那时候做决定，有全面目标做了到那时候起到很大的作用。
如果是为单个客户开发产品相对来说容易的多，一般情况下你的产品是成千成万人用。这时候就要考虑到，要照顾到不同的用户，他们使用的产品能力不是一样的。对于不同层次的人使用者，对他们要达到的目标是什么，都要写清楚。你对这些做了总结，帮助你在后来做设计的时候，比较容易做出决定，你这个设计功能该怎么样设计。往往这些功能写和不写没有太大区别，最后软件不起到什么关键影响，可是由于做了这些工作，你作为设计人员，项目经理，逼迫你去思考这些问题，如果事先这些问题都没有想过，希望后来设计的软件都能达到前面的功能是不可能的。如果你事先做了，做了思考，跟开发团队商量了，做的这些都是有目的的。
前面讲的是比较高层次的总结，在你描写真正开发的功能之前，就会讲到很要紧的总结使用方案。客户是如何用你的软件解决他的问题的，谁来用，是什么样的人，他们怎么用法，他们使用软件顺序是怎么样的，描写清楚。通常我们是用讲故事的方法，长三来上班，大概机器灌入一个数字，存了文档，交给李四，李四存了文档，这样用讲故事的方式来描写。还有很要紧的一点，你这样的描写，对测试团队起到一个巨大的帮助。他测试的时候，内部测试团队人员可以把自己想象成一个客户，可以按照你所描写的使用方案，测试团队来测试这个软件。按照你所描写的使用方案，按照顺序进行测试。这个是对测试团队设计他们的测试的方案起到很大的作用。
从客户使用软件具体的使用方案总结出你的功能需求，他是这样用的，因为张三打开机器要先按这个键，应该有一个输出、输入栏，灌数据，按了以后生成文档，正因为有这样的使用流程，你的需求功能非得有这个键，有数个数据栏、有功能生成文档。前面描写的故事怎么使用的，后来设计总结这些需求功能是符合你这个故事的，保证你设计出来的功能是能够满足客户按照这个步骤执行他的方案。我们在微软内部按照三步法开发软件，其实是有他的道理的，他要避免你开发出来的功能是和前面使用方案毫无关系的，开发的时候造成浪费。满足具体的使用方案，从使用方案总结出来，因为长三按这个键关入数字是这样的工作，做功能描述的时候才描述细节，但首先要有这个键、数据栏。对可有可无的功能要把它的优先顺序写持续。我们所有的功能都有P1、P2、P3，定出来哪些东西是对客户来说是赢得市场最要紧的，非要开发，哪些是可有可无，哪些是可以放到下一代产品再开发。开发之前把这个事情都做好。
有了这些以后，你才描述具体的功能。这里描写如何使用，前面先讲为什么要开发，如何开发，讲了这个软件为什么用，最后来讲这个软件是如何被客户使用的。这部分对所有的功能，所有的界面设计做一个详细的叙述。对这部分内容可以按照使用方案，从头到尾把你使用的功能用图象画出来，可以用文章总结。使用大量的图象很要紧，因为你图象化以后，帮助测试人员怎么样测试，帮助开发人员开发出来的功能是要符合你设计的图象。你画出图象，可以让可用性的工程师，根据这个造样品，然后找客户做使用性的调查。这些东西帮助管理整个使用功能控制操作和质量。
除此以外，还有很要紧的一点，在设计过程中间，常常有很多还没有解决的问题，在设计功能中间，并不是说什么东西解决了就可以开发了，产品已经在开发了，可是还有很多东西没有解决。某些技术性的问题，我等别的团队告诉我，或者有些技术性问题我等着调查，或者有些技术问题不知道，我买了硬件以后，做了平台以后做调试才知道，所谓这样都不能遗漏，为了防止这些问题都忘记，把这些问题也写到规范书里，有一个表格全部列到里面，有这样的方法就知道，整个开发过程中，让你可以随时回去看，这些没有解决的问题是不是已经被解决了，几月几 该被解决，哪些还要被调查，哪些还要被进一步决定。把没有解决的问题列出来，做个总结，谁对这个问题负责，比如某个技术调查问题是开发团队来做的，把这些该负责的人名字写在里面。目前他的状态到底有没有解决，有的已经解决或者是已经正在调查，在一个表里列出来，分成三档。有这样一个总结很明显的帮助你追踪没有解决的问题，在开发过程中状态是怎样的。如果项目过大的话，甚至可以把这个内容拿出来，专门再写一个额外的文件，一个专门的文档专门来总结这样的东西，给别的团队的人看，不见得一定在设计规范里，但是这些内容帮助你把该解决的问题记下来，帮助事后追踪管理这个过程。
增进版本的设计规范书，有时候我写一个规范书，并不是一个新的版本，我们公司已经有这个产品了，已经在市场上。我们现在这个公司正在做一个增订型的，做下一个版本，这个时候在以前已有的产品基础说我要做什么样的改变。要解决以前没有解决的问题，为什么现在开发，要解决以前没有解决的问题，我用什么样的设计，改变上一代的设计没有解决的问题。如果写崭新的产品就不会有这个问题，但是很多情况下我们的产品已经有了，我们只是要不停的增进，这种情况下要写这个内容。还有一点，设计界面的操作行为，不光是有一个图画，有一个键、数据栏、图象，还要很清楚的描述这个键我按了以后会发生什么情况，数字灌进去会发生什么情况，有时候用鼠标控制的，鼠标到底是左键按下去发生什么情况，右键按下去发生什么情况，这些都要列在里面。你盖一栋房子，描写的很清楚，用什么样的砖、瓦盖这个房子，用什么样的门窗、玻璃描写很清楚，盖出的房子一定是你所需要的，如果你画的是很大的很粗糙的草图，你盖的房子可能不是你所需要的。还有不要忘记一些基本的文章的结构不要忘记，包括标题、日记、版本数，还有页数，前面的目录、章节，不同的章节用什么标记表明的。别人读两三百页厚的设计版本会不会头脑发昏，怎么样让读者理解你的东西，都要写在里面。还有公司项目内部名称，如果公司项目很多的话，有时候项目有代 ，代 太多可能读者搞不清楚，对项目内容做一个解释。很多情况下文档是内部使用，作为公司保密的，不能流传出去。你作为项目经理要写的很清楚，告诉团队成员，这个产品开发不能把这个文档公开给别人。在写一个完整的设计文档的时候，这些规范书里都要写在里面。
|
