本文深入探讨了产品经理在日常工作中不可或缺的一环——需求文档的编制。通过一个具体的分销系统设计案例，文章详细展示了如何从一个宏观的视角逐步深入到功能的每个细节，确保研发团队能按照既定目标高效完成任务。

产品经理日常繁琐的工作中，除了与业务、研发之间的battle，最重要的一部分就是需求文档的编制，需求文档的好坏直接影响研发同学对产品功能实现的质量，是研发代码实现的依赖，更是功能的详细说明书。好的产品文档，会赢得研发、业务对产品的专业认可。

由于“高保真”的需求原型适用于产品雏形期的萌芽阶段，现实更多的产品经理处于公司发展中的小步快跑阶段，7天一个版本，如果每个版本都要做到“高保真”，那得有多少加不完的班。本篇文章主要介绍日常繁琐工作中的“文档型”PRD编写，中小需求均适用。

对于概念的内容就不加赘述，直接通过需求实例来展示这几块内容的编写（这样写的好处是看到这篇文章的产品可以直接实战，适合新入职场的产品童鞋）

需求实例：“M公司分销系统设计”

一、文档综述

1.1 版本控制

1.2 需求干系人管控

二、项目背景及价值

2.1 项目背景

M公司是M集团下属电商公司（M集团是一家经营了十几年的成功企业，旗下拥有零售超市、生鲜电商、金融理财等多条业务线，业务发展良好，系统建设成熟）主营生鲜商品，以C端客户为主，业务稳定。三个月前尝试开展分销业务（也叫大客户，ToB业务）。

分销业务的目标客户是大型连锁餐饮集团，以及大型生鲜分销商等企业级客户（注：M公司并不会参与客户对商品的二次转卖，即下一级生鲜品后的分销过程）。

业务试点在北京、上海开展，三个月以来业务发展迅速。目前分销业务月流水50w，以每月20%增幅快速发展。但是在高速发展中，若干流程、管理风险问题突出，现急需配套的软件系统来提升业务效率，控制经营风险。

目标：在两到三个月时间内搭建一套分销业务平台，至少支持分销业务在未来两年内的高速发展，有效提升效率，控制经营风险。未来内部系统成熟后，将这套分销业务平台Saas化对外售卖。

2.2 项目价值

战略目标：扩充并尝试新销售渠道，发展高端零售的分销通路，战略目标是3年内打入主要的一二线城市的高端零售分销市场。

2.3 市场分析

M公司即将研发的分销平台，目前客户是农产品渠道商，渠道商业业务规则在万亿级别，而这些渠道商在信息化、数字化方面投入只占营业额的0.01%，测算得出针对农产品领域的分销类软件产品，年市场规模大概1亿元人民币。在农产品分销软件平台领域，市场占有率最高的3家软件供应商，总共占据了40%的市场份额（即行业集中度CR3=40%），是一个竞争充分的市场。

三、需求总览

3.1 需求场景

可以以excel方式展示有哪些业务场景，需要做什么。

3.2 功能框架图及分期实现步骤

将业务场景拆分到功能模块，并进行优先级排期，由于本次需求涉及到新系统搭建，故分期进行。

PS：如果是小的需求，就在大的功能框架图中标注变更/调整点。

四、需求详细描述

B端产品的细节方案设计，通过对整体方案中总结出的业务场景，逐个进行深入分析，包含业务数据建模、页面流转设计、界面设计、权限设计等。

B端产品进行细节设计的常见流程，首先梳理业务流程，接下来提炼背后的数据模型，然后基于流程和数据模型确定业务流转图，再着手进行每个页面的具体设计，同时提前规划好系统用户角色，最后完成权限设计。

需求详细描述模块是研发同学实现的依据，涉及到方方面面细节，故也会存在多个版本的修订补充，需要在版本控制模块做好管理。

1. 业务数据建模

业务数据建模是数据库设计中最重要部分，会影响数据库表结构设计，很多产品经理常常忽略业务数据建模，只关注功能界面设计，最终陷入混乱的逻辑中。

数据建模工作面临两种情况，第一种是已有业务流程，第二种是还没有业务流程。前者的建模工作相对简单一些，需要做好已有数据表单，实体的识别和抽象（目前互联网企业一般是前者，产品经理在日常繁琐PRD中，往往会忽略对现有表单的影响，导致以为实现很简单，研发评估后发现改造较大，而产生分歧等问题）；后者设计人员没有线下的流程和表单可供参考，需要自己从零梳理设计。

关于本次分销平台的“业务数据建模”

a. 用户、订单、商品模型

分销系统中，1个用户（or大客户）下1笔订单，N个商品，一个商品也可能存在多个订单中，每个订单中包含多个商品；一个订单对应0个或多个运单，因为订单可能没有配配送，或者被拆分成多个运单配送；同时一个运单必须有一个对应的订单。

b. 客户模型

分销平台客户诉求：目前分销客户中，有比较大型的集团客户，下设若干机构、库房和门店。调研时客户诉求如下：

• 上海、广州采用中央仓库模式，客户从M公司采购商品后，商品首先配配送到中央仓库，再由客户自己从中央仓库向地区门店发货。故需要开通采购员账号，以实现中央仓库系统中下单。
• 其他地区是门店自采模式，即门店采购员自行下单菜单，商品直接从M公司配送到门店，因此需要针对每个门店创建采购员账号。
• 还需要一个高级采购员账号，能帮助同一地区各仓库和门店代下单。

故整理出以下客户业务数据模型：

综合a、b模型，提炼出分销平台数据ER图，如下：

2. 流程与角色

流程合理、角色清晰是系统设计正确的前提和保障，流程确定后，再绘制页面流转图，最终完成页面细节设计。

系统中角色一般与公司中岗位对应，分销业务客户包含如下几个角色：卖方-销售人员、卖方-分公司运营人员、卖方-总部运营人员、客户-管理员、客户-采购员。结合上一节数据建模提炼出的数据对象，以及对角色模型分析，绘制出以下业务流转图，根据业务流转图，可以设置相应的角色岗位以及系统权限。

3. 页面流转

页面流转图描述的是，用户完成某项工作需要访问的页面及页面跳转顺序。绘制页面流转图可以帮助设计人员审视、思考系统页面设计方案，包括系统总共需要哪些页面，哪些页面可以重复使用，哪些页面需要定制化开发。根据用户角色，设计出以下分销系统界面流转概况：

4. 界面详细设计

界面详细设计，即我们熟悉的原型图，B端系统的线框原型图，一般采用表单形式。产品经理绘制出原型图，并表达清楚每个界面，每个字段及按钮的设计需求。UE/UI协助产品完善交互体验，并制作交互原型。前端工程师拿到UI切图文件，进行前端开发，包括实现交互、动效等。

以上为分销系统下单界面、报价管理、门店管理界面示例，除了图之外，产品经理还需仔细描述清楚图中每个字段及按钮的需求，这是一项庞大而繁琐的工作，但也是从细节中见真知，对细节的描述也不容忽视，这样才能保证后续系统开发工作的顺畅进行，减少双边的返工成本。

（行业内主流产品经理画图软件为：墨刀、Axure，我之前也写过一篇关于：墨刀功能的简介，有兴趣的朋友的也可以去看看）

五、灰度计划

灰度节奏一般与业务侧对齐，根据业务实体，如分销系统实体中的门店，选取中型门店，上线后，灰度期间，先完成业务流程的跑通，再逐步推向城市及全国。

六、上线后业务复盘

PS：一般上线后半个月，或一个月，对产品进行上线后数据分析，看是否达到项目目标，此模块需要业务同学协助进行。