前言
有幸参与和负责过国内百强企业的Saas产品项目，一直想找个时间把项目全历程总结并分享出来。产品经理是如何从0到1接触并完成整个产品项目的，中间会经过什么环节、什么流程，需要具备什么技能，输出什么内容，取得什么成果……这一切的一切，我都将呈现于笔下。
如有雷同，不甚荣幸。
文档框架
PRD产品需求文档是产品经理必修课，一份好的产品需求文档可以大大减少项目周期和研发成本。目前市场上的产品需求文档格式五花八门，缺少统一和标准化，在此博主的文档格式仅作为参考使用。
首先，我们先定好文档的结构，一个清晰的需求文档结构可以让阅读者（开发、测试）更加专注于功能业务的实现，减少沟通成本。
产品需求文档可以使用Word文档、Excel表格，或者一些协同软件进行书写，但内容和结构大体相似，不同企业可以根据管理方式不同进行规定。
文档结构大体分为封面、前提概要、需求描述、功能说明、系统说明等。
零、封面
封面部分相当于整个需求的定义，主要包括需求名称、版权归属两大部分，当前企业的内部文档可以加上页眉和页脚等。
需求名称
一句话概述整个需求的定义，最好不好超过15个字，名称必须具有辨识度。示例：配货单据-新增售罄率排序优先级。
版权归属
这算是版权归属的概念，该份需求文档出自于哪个公司，哪个部门，具有一定的版权归属。示例：XX科技有限公司广州分公司-产品部。
一、前提概要
前提概要的内容主要围绕着本份需求文档本身的一些常规信息，目的是在读者阅读前告知重要的文档信息，主要内容可以包括基本信息、版本修订记录等。
基本信息
涵盖需求文档的基本信息，属于文档本身的信息而非需求信息的内容，包含内容有：文档版本号、文档编号、归属部门、编写人、保密级别、最近更新时间、审核人、审核时间。
版本修订
产品需求文档的修订记录列表，主要告知阅读者，特别是二次阅读者该文档修订了多少次，每一次修订了什么内容，类似需求变更记录。包含内容有：序号、版本号、修订日期、修订内容、修订原因、修订人等。
二、需求描述
需求描述是对整个需求的来源、分析过程、产品解决方案、产品目标或价值进行总结的部分，将读者带入体验整个需求从0到1的全过程，即为什么会有这个需求、这个需求将使用什么产品功能实现，完成这个产品功能对于用户和公司的价值在哪里。
很多时候，产品经理总是被质疑不了解业务，不了解用户真正想要什么，那么不妨把这些内容写下来，然后制定解决方案。
需求描述是给读者一个理念，即我为什么这么做这个方案，有理有据，接下来的产品功能规划才能让大家一起往一个方向而努力。
需求描述部分包括：业务背景、需求分析、产品方案、使用场景、产品价值等。
业务背景
主要描述客户在什么样的业务场景中，因为什么原因，需要使用到什么，用来做什么的过程。
示例：商品人员在实际出单过程中，需要根据单个门店的售罄率判断是否进行加量或者减量，若在近7天售罄率大于90%，则需要在原来基础上加量10%，若低于70%，则需要减量5%…….
需求分析
围绕着客户的业务场景，分析用户的痛点，提炼出用户需求。
在这里产品经理很容易出现一个问题，即用户描述得越清楚，产品经理越容易把它作为一个需求功能。
可能用户已经告诉产品经理需要什么功能，具体功能怎么计算都告知产品经理了，那此时产品经理可能就按照客户要求的做了。
但记住一点，客户需求是在变化的，因为业务在随时变化，而等到功能正式上线时，可能原有得痛点就不存在了，这就导致了无效功能的开发。
产品要让客户用起来，才有价值。
需求分析应该从业务场景出发，挖掘客户背后的用意，多问一些为什么。
示例：简单的加字段，为什么需要这个字段，用来做什么，在这个场景中一定需要这个字段吗？业务上为什么需要参考这个字段？这个字段背后涵盖的业务是什么？只有这一步需要这个字段吗？不同的商品人员如何看待这个数据，这个数据代表了什么？……
在分析的时候多思考一点，后面在做方案的时候就可以少错一点。
产品方案
分析完客户的业务场景，得到了真实的需求后，下一步是写产品方案的概述。
如果你不能用一段话描述你的产品方案，那么这个产品方案就不是最优的。
和数学一样，解决一个问题的答案一定是优美的，是简洁的，是清晰的，是最优的。产品经理之所以为产品经理，其最大的作用是提供最优的行业解决方案。
解决用户需求的方案可能有很多种，产品经理需要在众多的解决方案中寻找出对于客户、产品、开发、测试 、公司等都最优的解决方案。
这个方案也许对于客户方不是最好的，但对于整个产品的未来规划、产品设计语言、企业产品发展方向，客户使用体验是目前最好的方案。
那么，这个就是你的产品方案。
使用场景
当前功能上线后，会在哪些业务场景中使用。
产品价值
没有价值的产品或者功能，就不应该流转到开发，这是一个产品经理的态度。
曾经一个领导和我说过，产品开发出来是没有价值的，产品交付给用户也是没有价值的，只有用户真正用起来，产生数据了，产品才有价值。
产品用起来了，才会产生数据，有了数据就可以讲故事，有了故事才能吸引更多人使用。
因此在这一部分要描述整份文档中，该这个需求点对于用户能够产生什么价值。示例：减少人工操作的时间，提高效率。
三、功能描述
功能描述是整个PRD产品需求文档的核心。
除了整份需求文档需要遵循一定的文档结构外，每一个章节也需要按照一定的结构进行书写，当读者读到每一个章节的时候，除了能知道这一部分的主要内容，也能清楚知道这部分内容是如何书写的。
对于功能描述这部分，主要内容涵盖：功能基础信息、交互描述、逻辑描述等。
以上为PRD产品需求文档功能描述的示例，此为个人独立制作作品，不属于企业保密级别内容，请放心阅读。
功能基础信息
对于B端而言，更多的是用于描述和定位用的，设计到产品哪一块功能内容，路径在哪里，这一部分功能的定位是什么。
主要内容包括：页面名称、页面入口、页面功能、页面逻辑内容及其交互详细说明。
交互描述
交互描述主要是描述前端需要实现的交互及其信息的描述信息。
在当前哪一个页面，需要用到哪些元素，每个元素的类型、要求、交互特性，都在这部分描述清楚。
示例：用户名：输入框，必填，placeholder为请输入用户名，输入类型不限，输入时自动去掉所有空格，输入范围为1～20字。在登录时账号做非空校验…….
逻辑说明
逻辑说明主要是描述前后端交互、数据维度计算公式、特定规则等的描述信息。
在B端产品设计过程中，产品经理更多需要考虑数据从哪里来，如何计算，如何取值，算法公式的呈现方式，数据模拟等逻辑层面的思考，而不仅仅停留在页面如何美观，交互如何人性（当然这是基本功，有手就会）。
逻辑计算大体上可以分为3部分内容：功能实现、参数计算、数据模拟。
功能实现
以单点登录功能实现为例：
在主系统中有一个入口，只要使用账号密码登录主系统（示例：后台管理系统），就可以在主系统中看到其他系统的入口，点击A系统，就可以直接登录该系统，而无需验证用户信息，这是因为系统间实现了单点登录。
那么在单点登录的功能中，主系统是如何对接其他子系统的呢？
- 首先所有的子系统会有自己的域名信息，子系统的域名会给到主系统进行拼接成给SSO可认证的地址；
- 在主系统点击子系统入口进行登录时，主系统会向SSO发送一个请求，由SSO认证该用户的合法性；
- SSO认证通过后会生成一个token给到子系统，子系统读取token中的信息；
- 子系统读取token中的信息后匹配自己系统的用户，匹配上后即可给该用户进行登录。
以上就是PRD产品需求文档的逻辑说明的一部分，当前逻辑说明的内容还需要把其中涉及到的内容展示出来，写一个示例出来。
参数计算
如果在产品设计时涉及到一些业务指标的计算，那么产品经理在逻辑说明部分也需要描述清楚每一个指标的计算公式。
| 序号 | 指标 | 指标说明 |
|---|---|---|
| 1 | 售罄率 | 标准零售金额/（标准零售金额+标准库存金额） |
| 2 | 适销率 | 零售数量/(零售数量+库存数量) |
| 3 | 动销率 | 总销售货号数/总库存货号数 |
| 4 | 零售折率 | 零售销售额/吊牌金额*100% |
| 5 | 断码率 | 总断码货号数/总库存货号数 |
如果是涉及更多维度，像时间维度、空间维度指标的计算，那么除了提供数学计算公式外，还需要提供数据模拟的内容，方便开发人员、测试人员进行理解和规划，减少整个项目组的项目周期。
数据模拟
当产品规划中，存在由多个参数计算组合而成的算法时，产品经理在逻辑说明部分除了描述参数指标的计算公式外，还需要提供业务数据模拟信息，一块业务如何承接下一块业务，数据流向是如何的？最终的结果是如何一步步计算出来的，这便是数据模拟的作用。
示例：按销补货中
补货建议量=本期销量*下期补货天数。
| 门店 | 商品 | 补货方式 | 本期天数（14号） | 本期销量（14号） | 下期天数（15号） | 补货建议（15号） |
|---|---|---|---|---|---|---|
| 广州1号店 | 保温杯 | 按销补货 | 1 | 1 | 1 | 1 |
以上是一个简单业务算法的示例。
回归到整个逻辑说明部分，该部分可能是很多产品经理的写作难点，毕竟一份PRD产品需求文档要让研发的同事看得懂，最好的方式就是以他们看得懂的方式进行书写，哪一块不明白，就针对于哪一块做补充。
当然一份文档不可能满足所有人，产品经理要做的就是把能考虑到的问题都写进入，做到【我就差个开发就可以把产品完成】的水平。
四、系统说明
系统说明主要描述Saas产品的其他配置信息。
主要内容涵盖：权限说明、角色描述、名词解释、功能需求、项目排期、版本说明。
- 权限说明：描述本文档涉及到的需求在Saas系统中，每个模块页面的操作权限和数据权限；
- 角色描述：有关此需求涉及到的用户角色，及其在本需求中所承接的工作事项；
- 名称解释：对需求中所涉及到的专有名词、业务用语进行解释说明；
- 功能需求：提炼出的核心功能点，描述其功能点的范围及优先级规划；
- 项目排期：整个需求的预计排期时间，涉及到的各个环节的负责人等；
- 版本说明：该需求预计上线的系统版本及其说明；
小结
PRD产品需求文档是产品经理的必修课，也是考核产品经理能力的核心指标之一。
需求文档的格式、内容都可以依据企业的业务、管理方式不同而做出调整，但目标是一致的，需求文档需要以结构化的思维，将用户的需求转化为产品需求，再以开发的角度编写，推动项目的开发落地。
当然，其中免不了和开发、测试等同事一起评估和修订。
每完善一点，就离目标近了一点。
未完待续
经过这一次的PRD产品需求文档的编写事项，我以为事情应该告一段路了。
我没想到，身为产品经理的我也需要写产品操作说明书。
未完待续……
如果本专栏对你有帮助，不妨点赞、评论、关注～
