Getting Real -- 第十一章 第1节 功能定义一点用都没有

原文作者：Dave Thomas
原文链接：Chapter 11 There's Nothing Functional about a Functional Spec
译者：catlinux

功能定义一点用都没有

不要写功能定义文档

这些蓝图文档通常和成品几乎毫无关系。理由如下：

功能定义文档是虚幻的

功能定义文档不反映真实情况。一个应用只有在被构造时、被设计时，和被使用时才是真实的。功能定义文档只是纸上谈兵

功能定义文档是无关痛痒的

功能定义文档可以用来让人感受到参与的乐趣，措辞温和但是并不是那么有用。它们不关心艰难的抉择，不关心成本——而这些正是建立一个成功的应用所必须考虑的。

功能定义文档只能达成虚幻的共识

看文字并不能让人们达成共识。大家可以读到同样的文字内容，但每个人的想法却可能不同。以后将不可避免地发生这种情况：“等下，我不是那样想的。”“啊？我们可不是这么说的。”“是的，就是这样的，我们大家都同意了——你还签过字呢。”我相信，你知道该怎么做。

功能定义文档逼迫你在拥有最少资讯时作出最重要的决定

当你刚开始构建时，你知道的是最少的。而做得越多，用得越多，你才能了解得越多。这才是你应该做出决定的时候——即当你有足够多信息，而非信息少的时候。

功能定义导致功能泛滥

功能定义阶段对整个过程没有什么推动。写点东西加个标注，看上去并不需要什么代价。你可以加上他们欣赏的功能，让那些令人头疼的人高兴。然后你按照那些写下来的文字标注设计，而不是为人设计。最终你得到的将是一个拥有30个栏目的臃肿站点

功能定义让你无法变通、变化和重新评估

一个功能一旦明确下来，得到认同，即使在开发阶段你就意识到它是个坏主意，你也不得不照做。一旦你开始做某事，一切都在变化，而功能定义却不会去处理这些实际情况。

   那么，你应该做什么去替代功能定义呢？ 去写一个简明的替代文档，以此引导你去做那些真正的事。 写一页的说明去描述这个应用要做什么。 使用平实的语言并且要简短。 如果要阐述的内容超过了一页纸，就太复杂了。 这个过程不应该超过一天。

   接下来开始建立界面----界面将成为功能文档的替代物。 在纸上简单快速地画些草图。 然后把它写成html代码。 界面设计是每个人都会认同的共同基础，这不同于，大段的文字可以有不同的理解。

   人人都使用同样的屏幕界面时， 混乱不见了。在你开始担心后台代码之前，要建立一个人人都可以看得见的，使用的，点击访问的，并且可以“感受到的” 界面。 一定要尽量把自己置于客户体验之前。

   忘记那些锁定的功能定义。 它们迫使你做大，在太早的时候逼你作关键决策。 略过功能定义阶段，你将可以便于改变并且保持灵活性。

---

没用的功能定义

 “功能定义”几近无用。 我还从来没有见过一个足够全面和足够准确的功能定义文档。

   而且，我见过大量的基于功能定义（文档）的无用功。 这真是写软件的唯一最坏途径，这从它的定义就可以看出： 为了教条而写软件，而不是现实。

 —Linus Torvalds,  Linux 之父 (摘自： Linux: Linus 谈规格书)

---

和阻碍作斗争

   我发现人们常常坚持在任何设计工作开始之前，要先准备大量的需求文档， 这真是一些“阻碍”，使整个过程变慢。（这些人通常对设计没有任何的贡献和创新思维）

  我们所有的最佳工作都是这样做出来的， 我们把头脑中的一些关于站点改进的想法， 先作一个（静态）的快速原型， 再改动一点设计，然后使用真实数据建立一个活的原型。 在把原型上的一些累赘剔除以后，我们通常都会得到一个健康运转的项目，并且取得很好的成果。

—Mark Gallagher, 公司内部网研发 (摘自： 信号 vs 噪音)

---

（译注：  下划线部分是别人已经翻译好的。）

添加评论

相关文章：

  Top 100 web2.0网站 最热门的100个网站

  VC新年新展望

  怎样为你的WEB2.0创业进行营销