全面解析 | 如何做好输出「需求文档」这件「小事」？

2017-07-05 09:22来源:人人都是产品经理

原标题：全面解析 | 如何做好输出「需求文档」这件「小事」？

Anyway,「方法只是思维层级里底层的事情」。

最近一直在思考「输出需求文档」这件「小事」，发现太多产品经理连需求都没办法完全表达清楚，在需求评审会上支支吾吾，被各种挑战，或者开发阶段中多次重复确认，疲于各种沟通。相信每个产品新人都有过这种痛苦，解决的方法只有一种：「产品逻辑想得比任何人都多」。而需求文档是其中一种思维工具，利用好文档帮助自己梳理逻辑，掌握自己的节奏。

同时，需求文档能够在复杂需求流程中起到重要作用：

表达产品设计的需求，提高团队协作效率，是最重要的「协作工具」

作为可验收的「产品标准」

「输出需求文档」是每个新人很长一段时间都要做的事情，发现竟然大部分导师或者前辈都不会系统讲解的。「输出需求文档」是产品经理产品设计能力中最基本的基本功，就像UI同学用PS画图，开发哥敲代码一样，后两项技能/工具是需要花4年大学时间或者甚至更长的时间学习的，而大部分产品经理竟然都没有学习过需求文档这件事情，如果大学开产品经理专业，「输出需求文档」一定是大一就要学的课程。

我这里一直讲的是「输出需求文档」，不仅仅包括写需求文档这件事，「输出」应该是一个动作。可以看到需求的完整流程，「输出需求文档」应该分为需求前、需求中、需求后，写文档只是其中的一部分。

这次分享的是与需求文档相关的动作，需求跟进和管理又是另外一个大课题，这次框架里不包括。

一、写需求文档

推荐这种结构的需求文档，采用的是结构化导航模式（网上已经有很多模板了），这样的好处是清晰明了，开发、测试、设计不同角色可以根据自己需要看自己关注的部分，不用对着文字版需求说明书来回找。

再来，完整又简洁的需求文档应该包括：文档简介、需求分析、结构流程、原型交互、埋点说明。

沿用了这种模板和结构的不一定是好需求文档，更重要是每一部分里的思维和逻辑，模板和结构只是表面。

（1）文档说明

#版本说明

让参与人员能第一眼清楚看到这次版本或者功能包括哪些部分，能大概有预期工作量。为了清楚描述需求概况应该包括：

1. 序号：有几个功能需求点。

2. 类型：将需求分为新增、修改、删除。

3. 功能点：功能名字。

4. 需求描述：简要描述功能点，理解功能概况。

5. 优先级：功能重要性，开奖，分为P0,P1,P2(当然也可以直接分为高中低，或其他写法)，不建议超过3个优先级，意义不大。P0定义为必须完成，P1定义为无意外的话需要完成，P2可做可不做。

6. 详情：我这里只是为了方便点击跳转到相应需求说明的位置。

#修改历史

是的，很多情况下需求从开始，到结尾从来没有更新过。这样导致的问题会很严重，需求版本不同步，验收时错误或漏掉需求，反复修改。需求同步不是一件容易的事情，文档修改历史可以帮助需求同步。

1.详细描述文档改动点，包括时间、版本号、类型（增删改）、严谨的修改说明。以下是两类示例：

a. 不合格的修改说明： 修改标签库逻辑

b. 严谨的修改说明：在评论提醒中

C回复B不需要通知A的，因为A不会非常在乎B与C讨论的内容

点击通知栏的时候如果没登录是调起登录的

小红点逻辑：启动的时候拉取

列表刷新：每次都进入都刷新

定位位置，点赞定位问题

特别多人讨论确定逻辑后需要修改在文档里，详细描述。

2. 同步给所有参与人（这部分目前我是通过公司的协助工具上传文件，这样能够邮件通知，暂时还没有更好的工具）

（2）词汇说明

并不是项目组每个人都明白产品经理在需求分析、交互原型里说的名词，将名词解释明白即可。

（3）需求分析

需求文档里的需求分析，目的很简单，是说服项目组认可这个功能或需求，能将需求安排下去，常用的方式两种方式：