无痛功能规格 第二篇:规格是什么?

作者:周思博(Joel Spolsky)
译:Paul May 梅普华
编辑:Jeff Wang 王家麒
October 3, 2000
A part of Joel on Software, http://www.joelonsoftware.com

(你看过第一篇吗?如果还没有可以到[这里](/wiki/The_Joel_on_Software_Translation_Project:%E7%84%A1%E7%97%9B%E5%8A%9F%E8%83%BD%E8%A6 %8F%E6%A0%BC(%E4%B8%80) “The Joel on Software Translation Project:无痛功能规格(一)")看。)

这一系统的文章是在探讨_功能规格_ 而非_技术_ 规格(译注:也称为工程规格)。人们常会把这两者搅混。我不知道是否有其他标准术语,不过_我个人_ 的用法如下:

1. _功能规格_ 纯粹由使用者的角度来描述产品如何运作。它不管东西是怎么做出来的。功能规格会述及功能,还会详述画面、功能表、对话框等等。
2. _技术规格_ 则是描述程式内部的实作。它会说明资料结构、关连式资料库模型、程式语言及工具的选用、演算法等等。

当你从头设计一个产品时,最重要的一点就是要确定使用者的体验。要显示什么样的画面,运作的逻辑为何,要达成什么功能。再来还要考虑如何达成。如果产品本身要 做什么 都还没决定,争论要用哪种程式语言是完全没有意义的。我在这个系列中只会讨论_功能规格_ 。

我写了一篇简短的规格范例,应该能让你大致了解一份良好功能规格的重点。在我们继续之前请先读这份规格范例

读完了吗?

一定还没有。现在就去读完再回来,这样我们才能讨论一份良好规格所应具备或不应包含的东西。我会在这里等你。谢谢。

(耐心地等待…)

San_Juan_Old_City.jpg

噢,很好。你回来了。

下面列出一些我在每份规格上都会放的项目。

一段声明。 纯粹自卫用。如果你写一段文字说「这份规格还没完成」,别人就不会冲进你办公室把你的头咬掉。等时间流逝规格开始完整时,你可以改写成「就我所知这份规格已经够完整了,不过有什么漏掉了,请告诉我」这提醒我每份规格都需要:

一位作者。 有些公司认为规格应该要由_整组人_ 来写的。如果你尝试过团体写作,就知道那是最可怕的酷刑。团体写作就留给拥有大批新出厂哈佛毕业生的管理顾问公司吧,他们需要做大量的虚工才能收取巨额费用。你的规格应该由 _一个人_ 负责并撰写。产品规模很大时就切成几区,让不同人写各区的规格。其他公司认为把个人名字放在规格上会让他「独占功劳」,会太过自我本位,不是良好的「团队合作」模式。 _胡说。_ 人们对被指派的工作应该要同时有_责任_ 和_所有权_ 。如果规格有问题,在规格上印上大名的规格负责人应该要负责解决。

脚本。 当你在设计产品时,一定要想出某些真实存正的状况以及人们使用的方法。否则最后就会设计出一个完全没有真实用途的产品(就像Cue?Cat)。替你的产品选好客户群,针对每种客户想像一个完全虚构而又完全 典型 的使用者,用很典型的方式使用产品。我的UI设计书(可以在线上免费取得)中的[第9章](http://chinesetrad.joelonsoftware.com /uibook/chapters/9.html)讨论虚构使用者和情境的建立。这些使用者或情境就是用在这里的。状况定得愈清楚愈真实,针对真实或虚构使用者的设计就愈好。这也正是我会放入这么多虚构细节的缘故。

非目标。 当你和整组人一起建立产品时,通常每个人都会各有所好,因而产生各式各样真正或虚构的必备心爱功能,如果要将这些功能全部都做出来,恐怕永远做不完而且要花很多很多的钱。所以你必须马上开始删功能,而删功能的最佳方法就是利用规格的「非目标」章节,列出我们 不打算做 的东西。非目标可能是个不会具备的功能(「没有精神感应式介面!」),也可能是较一般性的定义(「我们不在意这个版本的效能。这个产品跑得多慢都没关系。如果第二版时间够,我们会把效率最佳化。」)这些非目标很容易引起争议,不过尽早把它们曝露出来却是非常重要的。就像老乔治布希说的:「绝对不会做!」

概要。 这就像是规格书的目录。它可以是张简单的流程图,也可以是段广泛的架构讨论。大家会先读这部份知道大致轮廓,再来看细节才有意义。

细节、细节、细节。 最后会进到细节。除非必须了解特定的细节,否则大多数人都会略过这一部份。当你在设计一个网路服务时,有个好方法就是把所有可能的画面都取个正式的名称,再对每个画面用一整章巨细糜遗地详述细节。

细节 是功能规格中最重要的部份。由范例规格中,你可以注意到我对登入页面各种错误状况有极为详细的说明。当邮件地址错误时要怎么做?密码错误时要怎么做?这所有的错误状况,都会对应到将要撰写的真实程式码,不过更重要的是这些状况都会对应到某人必须做的 决策 。某个人必须决定遗忘密码时的处理方式。由于不决定就无法写程式,所以规格就必须把决定写下来。

未定义项目。 第一版的规格有未定义项目是正常的。我在写初版草稿时总是有很多未定义项目,不过我都会标示出来(加上特殊格式便于寻找),如果可以的话还会讨论各种可选用的方案。等程式人员开始作业时,所有未定义项目都必须处理干净。(你可能认为,先让程式员从简单的项目做起,你稍后再把未定义项目定清楚。这是个坏主意。光是处理程式人员实作程式时出现的 问题就够了,根本不会记得还有些旧问题有待处理。另外解决重大项目时所用的方法也可能会严重影响到程式的写法。)

旁注。 在写规格时要记住你会有各种不同的读者:程式员、测试人员、行销人员、技术作者等等。当你在撰写时可能会想到一些只对某类读者有用的小资料。举例来说,我会把写给程式员看的讯息(通常描述某些技术实作细节)标成「技术注解」。行销人员直接跳过而程式人员就会细读。通常我的规格里满满都是「测试注解」,「行销注解」和「文件编写注解」

规格必须是活的。 某些程式团队会有一种「瀑布」心态:我们会一次就把整个程式设计好,所以把规格写好印出来丢给程式员就可以收工回家了。对这种想法我只能说:「哈哈哈哈哈哈哈哈!」

这种作法正是规格如此不受欢迎的原因。很多人都对我说:「规格根本没用,因为没有人会照着做。规格总是过时而且从来无法反映产品。」

El_Yunque_Waterfall.jpg

原谅我。你的 规格可能总是过时又不能反映产品。不过_我的_ 规格可是时常更新的。只要产品还在开发而又出现新的决策,就会持续进行更新。规格总会反映我们对产品运作的最佳认知。只要在程式完成时(也就是所有功能完备但尚未测试除错)规格才会冻结不变。

为了让大家好过一点,我不会每天重新发行规格。通常我会在伺服器上放一份最新版供大家参考。遇到特别的里程碑时,我会印一份出来,里面加上修订标记让大家不必重读整份文件(他们可以快速地发现修订标记以便找出变更所在)。

谁该写规格?[请看第三篇](/wiki/The_Joel_on_Software_Translation_Project:%E7%84%A1%E7%97%9B%E5%8A%9F%E8%83%BD%E8%A6%8F%E6%A0%BC\ (%E4%B8%89) “The Joel on Software Translation Project:无痛功能规格(三)")。

这些网页的内容为表达个人意见。
All contents Copyright 1999-2002 by Joel Spolsky。All Rights Reserved。