我们做的某些事是因为其过程具有价值，就像慢跑或练习钢琴一样。而我们做的另一些事情是因为其产品具有价值，就像做一块蛋糕或修理一辆汽车。定义项目范围就包括了这两方面：一个有价值的过程导致一个有价值的产品。

???

过程(pro“ss)的价值在于，当整个事情还处在假设阶段的时候，它能迫使你去考虑潜在的冲突和产品中一些粗略的点。我们可以确定现在整个的网站建设中能解决哪些事情，而哪些必须要再迟一点才能解决。

?

?产品(product)的价值在于，它给了整个团队一个参考点，关于在这个项目中要完成的全部工作，它也提供了一门共同的语言，用于讨论这方面的事情。定义好你的要求能保证在开发过程中不会出现模棱两可的情况。

???

我曾经设计过一个似乎永远是Beta版的网页应用系统：差不多，但还是没准备好向真正的用户推出。用我们的方法去做的许多事情都是不对的——技术不稳定、我们好像根本不了解用户，同时我是整个企业中唯一一个在开发网页方面有一些经验

的人。

???

但是这些都不能解释为什么我们不能推出这个产品。最大的绊脚石是没有一个人愿意去撰写一个文档。毕竟，当我们所有的人都在同一个办公室里工作时，记下每一件事是很麻烦的。除此以外，产品经理也需要把他的精力集中在新功能的思考上。

? 这样做的结果，就产生了一个不断变化的、混合了完整产品的各个阶段功能的产品。只要有人读到的一篇新文章或一个新的想法，都会启发这个产品的负责人的灵感，然后考虑增加另一个功能特性。我们倒是有一个固定的工作流程，但是没有日程安排，

没有里程碑，项目也看不到尽头。因为根本就没有人知道这个项目的范围，又怎么能知道它应该在什么时候结束呢?

???

用文档来说明项目要求，这件事很麻烦，但是你必须要做。

这是由于以下两个主要原因：

原因一：这样你才知道正在建设什么，

这似乎很明显，但是它对于正在建设某个网页应用程序的团队却是一个惊喜。如果详细地记录下你正在建设的内容，每一个人就会知道这个项目的目标是什么，什么时候达到这个目标。最终产品不再是一个停留在产品经理头脑里的不定形的图像，它变成了一种在企业内部的每一个级别的每一个人都触手可及的东西，从高层管理人员到入门级的工程师，人人都能参与进来。

???

?如果没有文档的要求，你的项目很可能会变成一个叫做“电话”的校园游戏——在团队中的每一个人都得到一个关于产品的印象，然后通过口口相传的方式传递出去，每个人的描述都略有不同。甚至更糟的可能是，每个人都认为别人肩负着管理产品关键环节的责任，但事实上这个人并不存在。

?拥有一系列明确的要求，能让你把责任分配得更清晰，这可以大大提高协作的效率。在了解了一个详细策划的完整范围之后，你就可以看到各个相对独立、也不显著的要求之间的内在联系。在早期的讨论中，支持文档和产品规格表可能看起来像是独立的功能内容，但是把它们作为要求确定下来，会让这种有所交叠的事情更加明显，并且同一个小组的人可以把它们都负担起来。

原因二：这样你才知道不需要建设什么

??? 许多功能听上去都相当诱人，但是它们对于项目的战略目标并不是必需的。此外，所有在项目开始如火如茶地进行时，关于功能的、各种各样的可能性都会浮现出来。当这些想法出现的时候，用一个文档来记录它们，可以为你提供一个评估这些想法的架构。

了解“不需要建设什么”也就意味着知道哪些是你“不需要马上去建设”的东西。把这些杰出的想法收集起来，找到一种适宜的方式，让它们符合你的长期规划，这才是真正的价值所在。确定具体、系统的发展要求，并将任何不符合这些要求的想法作为潜在的未来功能囤积起来，只有这样才能用一种更慎重和有意识的途径来管理整个设计过程。

?

?如果你不能有意识地管理要求，那么将陷入可怕的范围蠕变(scope cre叩)中，这个词总会让我想起一个景象：一个雪球向前滚了一英寸——接着又是一英寸——每一次滚动都会捎带上更多的雪，直到它冲到山脚下。在这个过程中，雪球变得越来越大，你也越来越难以阻止它。与这个景象相同的，每一个额外的要求看上去并没有增加太多的工作量，但是当它们汇集到一起的时候，整个项目就会失去控制地膨胀，结束时间遥遥无期，而费用预算正不可避免地朝着最终的分崩离析飞奔而去。