上两篇帖子，我们说明了策略需求挖掘和迭代的方法。这周我们分享怎么编写需求文档。
策略产品的需求文档和功能产品的需求文档，因为编写的初衷都是为了说明：需求是在什么情况下产生的？用什么样的产品形态，解决什么用户，在什么场景，存在的什么问题？问题解决后想达到什么结果，实现什么目标？需要哪些支持？通过什么方法和数据验证解决方案的有效性。
所以，两种需求文档在结构上是基本相同，内容依次是：项目背景、项目目标、需求概述、需求详述、统计和监控需求。
1.项目背景+项目目标
这两个是需求文档大同小异的内容了。
背景：说明需求在什么情况下产生的？谁提出的？
目标：帮助什么用户解决在什么场景下存在的什么问题。项目难点在哪，整体的应对策略是怎样的，我们想实现一个什么效果。
依据我的习惯，我习惯在背景部分说明用户场景需求情况，和现有版本存在的问题。
2.需求概述
需求概述主要是说明满足需求的解决方案包含哪些功能模块，各功能模块分别解决什么问题，想实现什么效果，功能模块之间是怎样的组成结构。
内容上其实和功能产品需求文档里的用户划分、业务逻辑、功能结构、功能清单、版本规划等内容大致相同。具体有哪些内容还要视情况而定，只要能把事情说明白就行。
3.需求详述
在《什么是策略产品经理》那篇帖子里，我们提到过，策略产品的解决方案通常是个相对发散的思路；而解决方案通常是通过“逻辑描述和效果示例”去说明产品的实现效果。
即当什么情况下，呈现什么结果。也就是策略产品四要素的后三项：输入条件（触发条件+考虑因素）、计算逻辑、呈现结果。针对迭代策略我们还会加入“问题背景（问题说明、影响面、数据表现情况、产生原因）”。
拆解下来，需求详述部分主要包含以下几个内容，相关详解如下：
触发条件：在什么条件下触发策略
考虑因素：触发策略相关的影响因素有哪些
呈现结果：向用户展示怎样的内容
问题背景：问题说明、影响面、数据表现情况、产生原因
计算逻辑
Case示例：上线效果案例
串起来逻辑就是：在什么条件下触发策略功能，然后系统通过怎样的计算逻辑，利用哪些关键因素，将怎样的结果展示给用户。
举例说明：新闻平台，个性消息推送策略
理想态：每天早8点，向用户推送1条消息，内容是他喜欢的热点新闻，促使用户打开app；
触发条件：每天早8点；
考虑因素：用户兴趣标签、内容分类标签、内容热度（公式相关变量：阅读量、点赞数、评论量）；
计算逻辑：依据用户兴趣标签，从用户喜好的类型文章中，提取用户未度过的，兴趣匹配度高的，8小时内发布的内容热度最高的前3篇新闻，推送给用户；
呈现结果：推送“最近8小时热点事件：文章标题1，文章标题2，文章标题3”，用户点击推送后打开信息瀑布流，信息流前3篇为推荐的3篇新闻。
4.统计和监控需求
策略产品统计数据的设定和功能产品的指标设定逻辑相同，通过工作经验总结，我个人理解策略会更加关注以下四类数据，前三类为通用数据。
触发率：满足条件时，策略触发的比例；
展示率：策略出发后，给到用户的比例；
点击率：给到用户后，用户点击的比例；
后置动作：这个看策略流程相关的路径长度而自行添加。
监控需求就是在数据监控系统里，添加监控指标了。PM列出数据计算公式，告诉开发在哪里埋点，多久统计一次，数据表现为什么状态时，系统自动提醒PM就可以了。
二、总结
我记得刚学产品经理那会，我会把社区里所有的需求文档都看一遍，然后整理一个标准的需求文档模板，作为自己输出文档的标准。
但工作阅历告诉我，文档格式其实并不重要。重要的是用“最精简的内容，在不丢失关键细节的情况下，将事情说清楚”。
处理一部分策略需求和学习策略课程后，我发现策略需求文档在需求概述和详述部分更是会针对不同的需求情况写出千差万别的文档。
除了触发条件，呈现结果，计算逻辑是必须写的内容外，其他内容都要视需求而定。核心就是内容能帮你把需求说清楚就可以了，千万不可照抄模板，生套内容，为了写而写，导致文档中出现大量无用内容，而必要内容还处于缺失的状态。
产品工作注重的还是逻辑的思考和表达，俞军老师不是说过：
“结论可以错，但逻辑不能错”。
本文篇内容到此结束，下一篇我在原计划的基础上添加一个“策略需求文档的编写案例”。
本来想放到这篇里的，但避免帖子字数太长，读起来太累，我们另起一篇进行详细分享吧。
策略产品经理学习笔记目录：
