产品经理的日常工作，总是在梳理和输出各类文档：竞品分析报告、产品原型、需求说明书（PRD）.......
这些文档的交付质量，基本能看出一个产品经理的能力层次。
因为文档呈现了你分析业务需求的广度与深度、提出产品方案的有效性、逻辑思维的严谨性及团队协作的能力。
一份好的文档能让你与业务、研发、测试快速理解业务背景、业务流程、产品架构与功能逻辑。
但在输出产品文档过程中，我们经常被以下问题困扰：
我重点要输出哪些文档，这些文档与产品交付的关联是什么？头脑想法很多，却不知如何有序组织，无标准模板可参考文档主线模糊，逻辑混乱，看文档的人抓不住要点，解释成本高文字堆砌，找不到合适的语言描述业务与产品逻辑，可读性差接下来让我们把这些问题一网打尽！
1. 产品经理要重点输出哪些文档，这些文档与产品交付的关联是什么？
欲理解此问题，我们需深入理解软件产品的本质，此处以常见的消费信贷业务系统为例，加以阐释。
消费信贷业务系统本质
我将消费金融产品分为可见的交易层与不可见的业务逻辑层，可见层为面向终端用户提供服务的小程序或APP或网页端，只是软件产品与整体业务价值链的冰山一角。
而隐藏在可见层背后的业务逻辑、产品定义与公司战略，才是整个消费信贷业务价值链的核心。
因此，你的软件产品必须做到整体业务价值链的拉通，并让价值链上的各个参与者能高效协同合作。
通过产品文档，将不可见的业务逻辑层（战略、产品、流程）清晰可视化，进而才能定义软件产品的架构、逻辑与数据脉络，这是软件产品文档对软件产品交付最重要的价值体现。
软件交付过程需要输出哪些文档呢？
可参阅我们的上一篇推文：产品经理必备的文档技能，对标腾讯、阿里
此处我将产品交付流程与各流程节点应输出文档重新列示。
主流互联网科技公司产品交付流程与文档清单
你所在公司目前都有输出哪些文档，又缺失了哪些？产品交付面临的核心问题是什么，可在评论区留言，我们会及时回复。
以下回归此文重点：产品需求说明书（PRD）！
2. 产品需求说明书（PRD）文档价值与查看对象
为何先谈《产品需求说明书（Product Requirement Document）》？
你与业务确认产品方案、控制需求变更的依据是什么？
你的开发同事依据什么来写代码，测试同事依据什么来编写测试用例？
正是一份详细的《产品需求说明书》。
它集成了业务逻辑、产品功能逻辑、数据逻辑、产品界面及其他非功能性需求等内容，是软件交付过程中最基础的文档，也是在业务、开发、测试、设计中传递、查阅频次最高的文档。
PRD文档的核心查看对象有哪些呢？
（1）业务与需求负责人
（2）产品总监与关联产品经理
（3）研发团队
（4）测试团队
（5）设计团队
其他文档，如产品整体方案与计划、业务流程方案等，是软件产品更深层次的业务解决方案中级或高级以上产品经理必须掌握。
我们在后续逐步展开，帮助大家进行思维与技能的逐级升维！
3.1.1目录
即需求说明书的内容大纲，是文档思路与主体内容框架，在着笔具体内容前必须理清。目录还为自己与读者提供了基本的内容导航，是不可或缺的一部分。
3.1.2专业名词解释
目的是降低读者对文档内容的理解难度，降低自己与团队间的理解与沟通成本，因而省出彼此重复提问与答疑的时间。
假设你设计的是业务财务一体化的系统产品时，会涉及“会计凭证”的自动生成。很多非财务领域的同事是不知道会计凭证的，因此你需要增加此专业名词解释。
3.1.3修订与评审记录
记录需求与产品设计变更过程，使变更与评审过程可追溯并责任到人。对乙方交付项目尤其重要，当项目发生争议时，此部分内容可提供追溯依据。核心要素如下示例：
3.2主体内容
3.2.1业务概述
将业务背景、业务模式、业务场景做简要概述，帮助开发与测试同事理解基本的业务逻辑，1-2页左右交代清楚，更详细的业务方案应在《业务流程方案》文档中描述。
3.2.1.1公司业务概述
目的：帮助自己与读者理解公司背景，为后续深入业务流程做好铺垫。
技巧：两三百字概述即可。重点说明白2个问题：A.公司的目标客户是谁？ B.公司为客户提供哪些产品与服务 。
3.2.1.2业务模式
目的：用图示描述清楚公司或你所负责模块的业务运作链路，建立整体业务视图，把握关键业务。
技巧：从业务参与主体、主体间的业务交易链路，交易过程的信息流、物流和资金流进行展开。
如下示例，某生鲜公司的业务模式：
3.2.1.3业务场景
目的：业务场景是业务实际发生的场域，具象化业务过程，帮助自己与读者深入到真实业务场景中。
技巧：聚焦你所负责板块的核心业务场景。
比如你负责生鲜仓储与配送模块，那么你需要将果蔬从入仓、仓储贴标、存放、盘点、配货需求获取、配送出库、配送签收、配送损耗处理等涉及的核心业务场景罗列清楚。
3.2.2目标用户
业务与系统产品目的都是为目标用户创造价值，因此正确识别并呈现产品目标用户类别，对自己与读者理解产品方案都是非常有帮助的。
3.2.2.1业务主体
指业务交易的核心参与方，也是未来使用系统产品的组织主体或个人。
一般可用“供需连”模型进行识别。
比如某水果公司的业务链路中，共有4个核心主体。“供”即水果供应方“农户”，“需”即水果需求方“消费者”，“连”即连接供需两端的中间方“公司”与“直营门店”。
3.2.2.2产品目标用户
罗列到细分用户群体，如农户细分客群、消费者细分客群，如下示例
A. 农户细分群体：年产值XXX的规模化农户，分布在全国各地，包括水果、蔬菜和养殖户。
B. 消费者细分群体：聚焦华南区域有孩子的家庭主妇、55-65岁的带娃老人
....
3.2.2.3业务量与用户量
目的：业务量与访问量大小，对研发技术选型、实现方式、测试要求都有较大的影响。
技巧：可按平均值和最大峰值（比如促销期间）两个维度进行预测。
业务量可按“日交易订单数”与“日交易总额”预估，用户量可按“日访问量”预估。若业务量较小，可将时间周期宽到月。
3.2.3产品整体方案
3.2.3.1业务主流程
目的：将业务流转的主链路闭环描述清楚，建立系统业务逻辑与数据逻辑的主脉络。
技巧：将产品或服务从供需两端完成端到端完整交付过程中，所必须经过的核心业务节点梳理出来，然后补充流转顺序与信息交互关系，以此形成的业务闭环，构成了业务主流程。
（若是模块级产品，则可仅呈现此业务模块的业务主流程）。
某生鲜公司业务主流示例：
主流程节点说明（将每个主流程节点下的关键业务精炼出来）：
如 01门店预采购：门店基于历史销售数据分析，提前6个月提出预采购需求，由公司采购部统一汇总并备货。
02 03 04 .......逐个节点展开描述。
3.2.3.2产品架构与模块设计
目的
产品架构是基于业务主流程与产品模块化的思路，设计系统的核心模块与模块间的关系。帮助自己与业务、研发、测试建立整体的系统视图，为技术架构设计提供依据。
技巧
系统架构需要将共性与个性化的系统功能进行剥离，实现共性功能的可共享。
子系统可按目标客群进行划分，划分后将各模块下的核心业务功能罗列出来。
注：如果本次产品迭代仅是某个系统模块，在架构图中将本次迭代的子系统或模块标注颜色，并备注说明。帮助团队理解本次迭代的产品范围。
如下示例：
基于以上产品架构图，可每个子系统的核心功能模块进行梳理与呈现，帮助自己与阅读者理清系统整体框架，从宏观到微观逐级理解系统架构。
若你负责的只是某一个子系统，你可聚焦特定子系统的系统架构，比如采购管理系统，将此系统的模块与模块间的关系描述清楚亦可。
3.2.4详细功能说明
此部分内容描述具体模块的详细系统逻辑，包括功能清单、系统流程图、详细功能说明。
3.2.4.1模块与功能清单
目的：罗列本次迭代的子系统、系统模块及功能清单，帮助团队了解整体的迭代范围及功能关键要点。
技巧：模块与功能清单可用表格式呈现，并与需求清单关联，描述清晰且可读性强。
可将系统模块的全部功能清单都罗列清楚，本次新增或修改的在状态列注明。有助于你始终了解整体系统功能迭代情况。
如下示例：
子系统
模块
功能清单
对应需求编号
状态
物流与配送系统
配送管理
配送订单自动生成
XQ202107002
本次新增功能
各区配送时效分析
本次新增功能
.......
......
车辆管理
车辆返程线路规划
XQ202106030
已上线
车辆运输时效分析
已上线
.......
.......
3.2.4.2系统流程图
目的：将某一业务活动在系统中运作的业务逻辑与系统逻辑描述清楚，是开发、测试理解具体功能最核心的“图纸”。
技巧：用visio泳道图绘制，呈现岗位、业务操作、业务判断逻辑、业务执行顺序及数据流。
如下示例，以下为某生鲜公司配送发运系统流程图：
某生鲜公司配送发运系统流程图
配送发运系统流程核心业务单据清单与核心字段：
（1）发货通知单：发货人、发运公司、商品SKU、数量、发货仓.......
（2）销售出库单：商品SKU、发货仓、数量、成本价、销售价........
（3）.......
3.2.4.3详细功能说明
目的：基于系统流程图，将每一个功能清单中的具体功能界面、业务逻辑、数据逻辑、操作逻辑均在此处描述清楚。
技巧：按“功能界面、业务逻辑、数据逻辑、操作逻辑”4个维度对每个功能点展开描述。
功能界面：将原型图中的界面截图过来，把界面的操作按钮、字段逻辑逐个描述清楚；业务逻辑：描述此功能所对应的业务场景，及功能操作后对实际业务产生的影响。比如“创建发货通知单”操作：基于门店采购需求的配货规则，创建发货通知单后物流部会进行物流发运安排，仓储部会锁定库存........
数据逻辑：描述此操作数据来源、数据处理与输出输出逻辑。如“创建发货通知单”：数据来源于采购需求订单+商品库存数量，发货通知单审核通过则锁定商品库存数量，并且推送生成物流发运单。
此处可配上单据状态图，如“发货通知单”从创建到关闭的状态流转过程。
操作逻辑：描述此界面上的每一个操作的触发条件，操作后会执行的系统逻辑。比如“发货通知书审核”：审核权限控制：需在权限模块分配组织与业务操作权限的角色才可见“审核”按钮；
“审核”操作说明：将审核界面截图在此处，说明审核操作的必填项和选填项，及每一个选项的具体含义......。
你看，任何一个功能点，从4个维度出发，系统功能都能很有逻辑地呈现，帮助自己及业务、开发、测试同事充分理解产品背后的逻辑，对开发设计、测试用例编写都价值巨大。
3.2.5非功能性需求
非功能性需求将业务功能以外的，对数据安全、产品性能及兼容性等方面的技术要求。
产品经理无需写出技术方案，但要把产品要求表述清楚。
数据安全：指系统在数据采集、传输和存储过程中的安全要求。比如对于客户实名认证数据，在传输与存储过程要求脱敏与加密。在用户查询时，展示界面需要脱敏展示。
技巧：详细罗列有安全性要求的数据清单，并详细说明安全需求（脱敏、加密、权限控制）。
产品性能：性能是对系统响应时间、并发用户数、吞吐量、点击数等指标的要求。产品经理基于业务量预测，提出以上具体指标值，让开发、测试同事在交付系统过程中进行落地，对后续系统产品的稳定运行是非常重要的。
（如果产品经理不了解这些指标，可以提前跟技术同事沟通，让他协助你理解）
兼容性：指的是对系统客户端在浏览器、操作系统方面的兼容要求。比如PC端，必须兼容哪些主流浏览器，移动端支持哪些手机操作系统及浏览器。
要基于目标用户群的设备情况进行评估，并给开发和测试提出落地要求，对用户体验及系统产品的稳定运行同样是非常重要的。
你在写产品需求说明书的过程中，还被哪些问题困扰，欢迎留言提问，我们会及时为你答疑哦~
