1700423308
用户体验要素：以用户为中心的产品设计（原书第2版） [:1700422472]
1700423309
用户体验要素：以用户为中心的产品设计（原书第2版） 范围层定义
1700423310
1700423311
我们做的某些事是因为其过程具有价值，就像慢跑或练习钢琴一样。而我们做的另一些事情是因为其产品具有价值，就像做一块蛋糕或修理一辆汽车。定义项目范围则同时在做这两件事：这是一个有价值的过程，同时能产生有价值的产品。
1700423312
1700423313
过程（process）的价值在于，当整个事情还处在假设阶段的时候，它能迫使你去考虑潜在的冲突和产品中一些粗略的点。我们能确定现在能解决哪些事情，而哪些必须要再迟一点才能解决。
1700423314
1700423315
产品（product）的价值在于，被定义的这个产品给了整个团队一个参考点，明确了这个项目中要完成的的全部工作，它也提供了一门用于讨论这件事情的共同的语言。定义好你的要求能保证在设计过程中不会出现模棱两可的情况。
1700423316
1700423317
我曾经设计过一个似乎永远是Beta版的Web应用系统：差不多，但还是没准备好向真正的用户推出。用我们的方法去做的许多事情都是不对的—技术不稳定、我们好像根本不了解用户、同时我是整个企业中唯一一个在Web开发方面有一些经验的人。
1700423318
1700423319
但是这些都不是导致我们不能推出这个产品的真正原因。这个项目最大的绊脚石是没有一个人愿意去定义需求。毕竟，当我们所有的人都在同一个办公室里工作时，记下每一件事是很麻烦的。除此以外，产品经理也需要把他的精力集中在新功能的思考上。
1700423320
1700423321
这样做的结果，就产生了一个不断变化的、混合了完整产品的各个阶段功能的产品。只要有人读到的一篇新文章或一个新的想法，都会启发这个产品负责人的灵感，然后考虑增加另一个功能特性。我们倒是有一个固定的工作流程（working flow），但是没有日程安排（schedule），没有里程碑（milestones），项目也看不到尽头。因为根本就没有人知道这个项目的范围，又怎么能知道它应该在什么时候结束呢？
1700423322
1700423323
用文档来定义产品需求，这件事很麻烦，但是你必须要做。这是由以下两个主要原因：
1700423324
1700423325
用户体验要素：以用户为中心的产品设计（原书第2版） [:1700422473]
1700423326
原因#1：这样你才知道你正在建设什么
1700423327
1700423328
这似乎很明显，但是它对于正在开发某个产品应用程序的团队却一个惊喜。如果详细地记录下你正在建设的内容，每一个人就会知道这个项目的目标是什么，什么时候将达到这个目标。最终产品不再是一个只停留在产品经理头脑里的不定形的图像，它变成了一个在企业内部的每一个级别的每一个人都触手可及的东西，从高层管理人员到入门级的工程师，人人都能参与进来。
1700423329
1700423330
如果没有文档的要求，你的项目很可能会变成一个叫作“电话”的校园游戏—在团队中的每一个人都有各自关于产品的想法，然后通过口口相传的方式传递出去，每个人的描述都略有不同。甚至更糟的可能是，每个人都认为别人肩负着设计和开发产品关键环节的责任，但事实上这个人并不存在。
1700423331
1700423332
拥有一系列明确的要求，能让你把责任分配得更清晰，这可以大大提高协作的效率。在了解了一个详细策划的完整范围之后，你就可以看到各个相对独立、也不显著的要求之间的内在联系。举个例子来讲，在早期的讨论中，支持文档和产品规格表可能看起来像是独立的功能内容，但是把它们作为要求确定下来，会让这种有所交叠的事情更加明显，并且同一个小组的人可以把它们都负担起来。
1700423333
1700423334
1700423335
1700423336
1700423337
用户体验要素：以用户为中心的产品设计（原书第2版） [:1700422474]
1700423338
用户体验要素：以用户为中心的产品设计（原书第2版） 原因#2：这样你才知道你不需要建设什么
1700423339
1700423340
许多功能听上去都相当地诱人，但是它们对于项目的战略目标并不是必需的。此外，所有在项目开始如火如荼地进行时，关于功能的、各种各样的可能性都会浮现出来。当这些想法出现的时候，用一个文档来记录它们，可以为你提供一个评估这些想法的架构，帮助你了解他们是如何（或是否）满足你当初所承诺要做的那些事。
1700423341
1700423342
了解你“不需要做什么”也就意味着知道哪些是你“不需要马上去做”的东西。把这些杰出的想法收集起来，找到一种适宜的方式，让它们符合你的长期规划，这才是真正的价值所在。确定具体、系统的发展要求，并将任何不符合这些要求的想法作为潜在的未来功能囤积起来，只有通过这种更慎重的途径，你才能真正管理整个设计过程。
1700423343
1700423344
1700423345
1700423346
1700423347
当前难以满足的需求，可以成为启动下一个版本的基础，这样就能形成一个不断循环的开发过程。
1700423348
1700423349
如果你不能有意识地管理你的要求，你将陷入可怕的“范围蠕变（scope creep）”中，这个词总会让我想起一个景象：一个雪球向前滚了一英寸（接着又是一英寸）每一次滚动都会捎带上更多的雪，直到它冲到山脚下。在这个过程中，雪球变得越来越大，你越来越难以阻止它。与这个景象相同的，每一个额外的要求看上并没有增加太多的工作量，但是当它们汇集到一起的时候，你的整个项目就会失去控制地膨胀，结束时间遥遥无期，而费用预算正不可避免地朝着最终的分崩离析飞奔而去。
1700423350
1700423351
1700423352
1700423353
1700423354
用户体验要素：以用户为中心的产品设计（原书第2版） [:1700422475]
1700423355
用户体验要素：以用户为中心的产品设计（原书第2版） 功能和内容
1700423356
1700423357
在范围层，我们从讨论战略层面的抽象问题—“我们为什么要开发这个产品？”—转而面对一个新的问题：“我们要开发的是什么？”