范围层

我们之所以要定义范围是因为我们保证两个价值：
1 我们做这件事的过程是有价值的
2 我们的产品是有价值的

而我们定义范围的最常见有效的方式就是文档，虽然文档很麻烦，但是没有文档很多事情会变的没有追溯和根据。

定义文档的两个原因

确定知道团队要做的是什么

在没有文档或者相关会议的团队里，很可能会出现每个人都在完成一个大家认为一样的目标，但结果最终是每个人都在完成自己认为的目标，并按照自己的能力以及认知去完成，解决。这与整个团队或者产品经理的想法可能是有很大出入的。

很多时候，个人认为自己要做的，或者他人应该做的，实际上可能没有人在做。

确定知道什么不需要做

在文档之外的，个人想象的以及并未考虑的需求都不属于当前应该考虑的，不应该因为之外的事情影响当前的主要进度。

迭代的概念

如果说范围是不够专业，那么迭代这个词大家多少都了解一些，迭代最本质的目的就是通过不断的细化每次的范围，分不同迭代去完成一个可能没有边界的项目。

在每次迭代中，我们需要在迭代开始之前，就明确这次迭代要完成的内容以及所有内容的优先级，在工作开始之后，除非特殊情况，这次迭代的相关内容和范围都不允许发生变更。

产品类型

产品分两个大类，功能型以及信息型。

产品规格

产品规格是说产品在某个具体功能时，应该能够符合的一些基本条件，能够让用户以及研发清楚，我们要做的是什么，不用多次追问。

乐观 — 描述可以做什么

通过我们的产品，我们应该定义的是通过一系列的操作我们可以做成什么，而关于一些错误的操作、异常的情况，我们要通过合适的引导和提示，到正确的流程中。

具体 — 具体到描述出5w

包括，谁，何时，何种场景，因为什么，做什么，导致了什么结果等等

客观 — 不要用主观不可具象的词汇

比如美观好看好用，交互方便，要用更实际的非主观描述、他人可以理解的一些词汇。

尽量定义一些大家都认可的规范文档，让过程中，大家有所明确的参考。

内容需求

应该尽可能的收集内容相关的素材。

1 不要拘泥于内容的格式
2 针对内容要根据特性进行分类
3 每个内容必要的设置负责人
4 维护内容的清单

确定需求优先级

1 产品规划重要度
2 用户需求重要度
3 可行性（包括技术、时间、资源）
4 冲突性需求
5 特征性需求