B4.3-Scope 范围层

定义项目范围：确认这是一个有价值的过程+同时能产生有价值的产品

1. Process 定义过程：先做什么，后做什么

考虑潜在的冲突和粗略的问题点

确定现在能解决哪些事儿，哪些必须要迟一些才能解决

Schedule  得有一个时间表

Working Flow  有一个工作流程、各部分的合作

Milestones 得有阶段性目标和阶段性成果

2. Product  定义产品 ：要做什么，不做什么

明确了项目要完成整个的全部工作

提供了一门用于讨论这件事的共同语言

---

“当我们所有的人都在一个办公室里工作时，几下每一件事都是很麻烦的—>没有人去定义需求”

于是：

你团队中的每一个人都有各自关于产品的想法，然后通过口口相传的方式传递出去，每个人的描述都略有不同。每个人都认为别人肩负着设计和开发产品关键环节的责任，但实际上这个人并不存在。

Scope Creep 一个雪球向前每滚一英寸，都会沾上更多的雪，直至冲到山下。

每一个额外的要求看上去并没有增加太多的工作量，但是当它们汇集到一起的时候，你的整个项目就会失去控制地膨胀，结束时间遥遥无期。

---

3. Functional Specifications 

Feature  可以同时指功能/内容

文档不能解决问题，但定义可以。

程序员们不喜欢阅读长篇的功能说明，应该让撰写功能说明的过程变得快速简便，不要让它变成产品开发过程中的一个独立项目。

不需要包含产品的每个细节—>只需要包含在设计开发过程中可能混淆的功能定义。

不需要展望产品未来的理想化状态—>只需要记录在创建这个产品时已确定的决议。

4. Content Requirements

Content Management System, CMS  

不要混淆内容的格式和它的目的。

内容元素的大小（图片像素、文本字数、音频大小）对UX决策影响很大。

尽早确定负责生成/更新内容的人（"如果不是我来维护的话，它就应该有XXX"）。

有效的内容需要日常维护，如果你没有考虑这个，那么随着时间的推移，它就无法满足用户需求。

所以，你应该指定内容负责人，并定义内容更新频率。

Content Inventory

---

需求大致划分3类：

A 人们讲述的、他们想要的东西

B 人们在某个过程/产品中遭遇的困难以及衍生出的建议

C 人们不知道他们是否需要的特性（突然想起的伟大构思）

Personas 人物角色

Scenarios 需求场景

需求的详略程度常常取决于该项目的具体范围。

一些需求适用于整个产品（品牌需求、技术需求），另一些只适用于特殊的特性。

当你把所有的时间都投入到维持现有产品时，你经常会忘掉哪些是真正的限制条件，而哪些是为了简化产品而曾经做过的选择。

需求优先级

最难的不是收集潜在需求或想法。难的是，你应该选择哪些是保留到你的产品中的，以及留下来这些哪些是重点去关注的。

实现的可能性：有些特性可能会因为技术上的局限无法实现，有时候仅仅是因为时间不够或是资源不足。

很少有功能是独立存在的，这不可避免地导致了特性之间的冲突，有些特性要和其他的一起权衡，才能得到一个连贯的、统一的产品。

任何不符合当前项目的战略目标的特性建议，都要通过范围定义将其排除出去。如果需求开起来很正确就反思一下你的战略，然后确定。

---

需求表述：

Be Positive  用积极、引导的语言去陈述

Be Specific  用操作性强的概念去定义功能特性

Avoid Subjective Language  有些概念和形容词是很主观的