最近一直在思考「输出需求文档」这件「小事」，发现太多产品经理连需求都没办法完全表达清楚，在需求评审会上支支吾吾，被各种挑战，或者开发阶段中多次重复确认，疲于各种沟通。相信每个产品新人都有过这种痛苦，解决的方法只有一种：「产品逻辑想得比任何人都多」。而需求文档是其中一种思维工具，利用好文档帮助自己梳理逻辑，掌握自己的节奏。
同时，需求文档能够在复杂需求流程中起到重要作用：
我这里一直讲的是「输出需求文档」，不仅仅包括写需求文档这件事，「输出」应该是一个动作。可以看到需求的完整流程，「输出需求文档」应该分为需求前、需求中、需求后，写文档只是其中的一部分。
再来，完整又简洁的需求文档应该包括：文档简介、需求分析、结构流程、原型交互、埋点说明。
沿用了这种模板和结构的不一定是好需求文档，更重要是每一部分里的思维和逻辑，模板和结构只是表面。
（1）文档说明
版本说明
让参与人员能第一眼清楚看到这次版本或者功能包括哪些部分，能大概有预期工作量。为了清楚描述需求概况应该包括：
修改历史
是的，很多情况下需求从开始，到结尾从来没有更新过。这样导致的问题会很严重，需求版本不同步，验收时错误或漏掉需求，反复修改。需求同步不是一件容易的事情，文档修改历史可以帮助需求同步。
（2）词汇说明
并不是项目组每个人都明白产品经理在需求分析、交互原型里说的名词，将名词解释明白即可。
（3）需求分析
需求文档里的需求分析，目的很简单，是说服项目组认可这个功能或需求，能将需求安排下去，常用的方式两种方式：
2、数据型说服：通过估算这个需求带来的直接数据增长，比如用户数、收入、点击率等等
（4）原型交互
「最容易理解的需求方式是界面长得怎么样」，别让项目组其他同学对着文字版需求理解。原型交互式整个需求文档中最重要的部分，也是最需要详细描述的部分，包括客户端逻辑、服务端逻辑、交互逻辑、边缘场景（并不是每个需求都有客户端逻辑或服务端逻辑）。
客户端逻辑:
描述客户端界面元素的展示和操作逻辑，推荐图文结合的方式。
服务端逻辑:
服务端部分指为用户提供产品服务时涉及的数据逻辑等等，完整梳理应该包括后台功能和服务端数据逻辑。
1.后台功能：指后台配置功能部分，目的是给运营同学配置内容。一般包括后台前端，配置项、增删改功能，可以根据功能难易是否需要后台原型。
（简单版）
2.服务端数据逻辑：定义数据结构和数据下发逻辑，以热文库这个功能为例子解释下。
功能背景：通过挑选热点内容，覆盖头部内容，提高内容质量和点击率
数据定义:
数据下发逻辑:
交互逻辑:
指的是界面和元素之间的交互行为。即使公司里有专职的交互设计师，产品经理也不应该省略这一部，只有完整考虑流程和细节，才能和设计师、项目组任何成员流畅讨论。
与客户端逻辑不同的是，这部分更多是界面之间操作流程，辅助界面的交互说明（点击、加载、动画），几个注意点：
1、交互设计的本质是「让用户更快更便捷的使用服务或产品内容」2、始终考虑交互设计五个要素，媒介、场景、行为、目的、用户
边缘场景：
如果你完成了上面的主要逻辑场景，一般来说功能只完成了一半，甚至没有。边缘场景的梳理这部分是最容易遗漏的地方，一旦遗漏就会陷入各种沟通和反复中。总结了常见的边缘场景，写完原型说明必检查。
（5）结构流程
信息架构:
当信息项特别多而复杂的时候有必要将信息架构列出来，按照界面、界面元素、信息项逐项拆解，目的是在测试同学在写用例时更方便查找。
（6）埋点说明
埋点的作用是为了功能上线后做分析调整，也是迭代的关键辅助，一定要做到「有功能必埋点」。埋点包括三个部分：事件ID、事件名称、统计口径、事件描述。
1、事件ID事件唯一标识，一般使用英文表述意义，单词间使用下划线隔开，如click_add_bookmark_folder；2、事件名称：事件的中文名称。3、统计口径指埋点类型，分别为计数事件、内容计数事件、计时事件、状态事件。
需要关键点是：
需求文档只是整个流程中将思路文档化的过程，可见项目完整流程图，文档只是很小的一部分。本文先不讲需求跟进部分，仅仅「输出需求文档」就容易忽略前期和后期，导致需求流程不可控。
（1）需求输出前
输出前做好两件事情分析和沟通，能在需求后续流程中更顺畅。
1、需求分析：想清楚为什么要做这个需求，可以从用户场景和反馈思考，可以从数据分析，可以从竞品中参考，但是一定要比任何人都要想得更多。2、沟通：提前将想法和需求参与人员沟通，比如开发、设计。让他们提前了解需求大概和评估可行性，这样能避免将需求评审会变成需求讨论会，团队一群人开一整天讨论会效率极低。
II.需求输出后将需求文档发出去之后就完事了吗？在需求跟进过程中，需求文档是需要维护。