原文作者:Dave Thomas
原文链接:Chapter 11 There's Nothing Functional about a Functional Spec
译者:catlinux
功能定义一点用都没有
不要写功能定义文档
这些蓝图文档通常和成品几乎毫无关系。理由如下:
功能定义文档是虚幻的
功能定义文档不反映真实情况。一个应用只有在被构造时、被设计时,和被使用时才是真实的。功能定义文档只是纸上谈兵
功能定义文档是无关痛痒的
功能定义文档可以用来让人感受到参与的乐趣,措辞温和但是并不是那么有用。它们不关心艰难的抉择,不关心成本——而这些正是建立一个成功的应用所必须考虑的。
功能定义文档只能达成虚幻的共识
看文字并不能让人们达成共识。大家可以读到同样的文字内容,但每个人的想法却可能不同。以后将不可避免地发生这种情况:“等下,我不是那样想的。”“啊?我们可不是这么说的。”“是的,就是这样的,我们大家都同意了——你还签过字呢。”我相信,你知道该怎么做。
功能定义文档逼迫你在拥有最少资讯时作出最重要的决定
当你刚开始构建时,你知道的是最少的。而做得越多,用得越多,你才能了解得越多。这才是你应该做出决定的时候——即当你有足够多信息,而非信息少的时候。
功能定义导致功能泛滥
功能定义阶段对整个过程没有什么推动。写点东西加个标注,看上去并不需要什么代价。你可以加上他们欣赏的功能,让那些令人头疼的人高兴。然后你按照那些写下来的文字标注设计,而不是为人设计。最终你得到的将是一个拥有30个栏目的臃肿站点
功能定义让你无法变通、变化和重新评估
一个功能一旦明确下来,得到认同,即使在开发阶段你就意识到它是个坏主意,你也不得不照做。一旦你开始做某事,一切都在变化,而功能定义却不会去处理这些实际情况。
那么,你应该做什么去替代功能定义呢? 去写一个简明的替代文档,以此引导你去做那些真正的事。 写一页的说明去描述这个应用要做什么。 使用平实的语言并且要简短。 如果要阐述的内容超过了一页纸,就太复杂了。 这个过程不应该超过一天。
接下来开始建立界面----界面将成为功能文档的替代物。 在纸上简单快速地画些草图。 然后把它写成html代码。 界面设计是每个人都会认同的共同基础,这不同于,大段的文字可以有不同的理解。
人人都使用同样的屏幕界面时, 混乱不见了。在你开始担心后台代码之前,要建立一个人人都可以看得见的,使用的,点击访问的,并且可以“感受到的” 界面。 一定要尽量把自己置于客户体验之前。
忘记那些锁定的功能定义。 它们迫使你做大,在太早的时候逼你作关键决策。 略过功能定义阶段,你将可以便于改变并且保持灵活性。
没用的功能定义
“功能定义”几近无用。 我还从来没有见过一个足够全面和足够准确的功能定义文档。
而且,我见过大量的基于功能定义(文档)的无用功。 这真是写软件的唯一最坏途径,这从它的定义就可以看出: 为了教条而写软件,而不是现实。
—Linus Torvalds, Linux 之父 (摘自: Linux: Linus 谈规格书)
和阻碍作斗争
我发现人们常常坚持在任何设计工作开始之前,要先准备大量的需求文档, 这真是一些“阻碍”,使整个过程变慢。(这些人通常对设计没有任何的贡献和创新思维)
我们所有的最佳工作都是这样做出来的, 我们把头脑中的一些关于站点改进的想法, 先作一个(静态)的快速原型, 再改动一点设计,然后使用真实数据建立一个活的原型。 在把原型上的一些累赘剔除以后,我们通常都会得到一个健康运转的项目,并且取得很好的成果。
(译注: 下划线部分是别人已经翻译好的。)
相关文章: