腾讯科班产品经理分享：产品管理流程与标准规范（万字干货）

一、总体流程

1.1 产品规划及评审

与需求方对接需求，并经过评估，确定要做之后，即进行产品的规划。

产品规划，将商业模式、盈利点、产品路线演化、主业务流程、核心功能模块确定之后，进行产规划的评审，评审通过之后进行原型的绘制。

1.2 产品原型设计及评审

产品原型做线框图原型即可，因为后期有专业的视觉设计，没有必要做高保真原型，能向视觉设计传达明确的意思即可。原型设计之后，进行评审，邀请评审的相关人员，中间可能会经历几次调整。具体邀请人这部分看具体公司，一般而言除产品及业务团队，研发介入越早越好，能够对部分功能的实现进行评估，产品在做原型设计的时候，也需要对相关功能进行调研，不能凭空想象。

1.3 视觉设计及评审

原型设计评审通过，则移交资料给UI设计师，UI设计师（如果有交互设计则相互配合，如果没有，产品也需要涉及交互设计）根据原型出设计图，UI设计师在产品原型评审阶段也需要介入。UI设计师设计完成之后进行评审，评审通过，则移交资料给研发团队。

有些团队产品经理要承担项目的职责，则需要和研发人员共同制定开发进度计划。

二、产品架构

为做一款产品，我们可以依据Why-How-What黄金圈法则+用户体验要素中提到的5层结构，从内到外，从抽象到具体来拆分产品的架构问题。

为什么做？—— “我们为什么要开发这个产品？”（战略层）

我们的产品目标是什么？我们的目标用户是谁？我们为用户解决什么问题（需求）？

做什么？—— “我们要开发的是什么？”（范围层）

我们的产品定位是什么？功能型产品，还是内容型产品？相应需要拥有哪些功能和内容？

怎么做？——“我们如何达到上述抽象层面所确定的问题？”（结构层、框架层、表现层）

我们的产品具体做成什么样子？要如何呈现给用户?

用户体验要素的五层结构经典图形

产品规划一般进行到结构层的信息架构，具体产品原型绘制在结构和框架层，视觉设计处理产品的视觉表现层。

下面更进一步说明用户体验要素中的各层级要做什么，解决什么问题。

2.1 战略层

这一层我们要回答两个问题：我们（公司或项目）要通过这个产品得到什么？我们的用户要通过这个产品得到什么？

也就是企业（项目）的产品目标和用户需求。产品目标是对各类经营目标的细化分解，用户需求时对用户需求得提炼，用户需求提炼则从用户画像而来。

2.2 范围层

将产品目标和用户需求转变为产品应该提供给用户什么样的功能或内容。

范围层意义在于：为产品设立边界，让参与者更能明白做出来的产品是什么样的，也避免给产品不断加入新功能，造成产品冗余。

以功能型产品来说：做什么功能？不做什么功能？哪些功能先做？哪些功能可以放在后续版本迭代时再做？

当功能太多时，确立需求优先级，可以利用战略层的用户画像可以将虚拟人物放到一个故事中（产品故事），确定用户的使用场景。

2.3 结构层

定义好用户需求并排列好优先级之后，我们对最终产品会拥有什么特性已经有了清楚的图像。结构层就是如何将分散需求的片段组成一个整体即：确定概念结构。

这部分包括两方面：“信息架构”和“交互设计”

信息架构：考虑的是功能及内容的分类组织方式，让用户能够高效、有效地完成内容浏览，办理业务。具体的结构方式有：层级结构、矩阵结构、自然结构、线型结构等，我们可以根据自己的产品特点来进行针对性的设计。

交互设计：考虑的是跳转逻辑，即：针对用户操作，产品要怎样反应来配合用户操作。

2.4 框架层

在框架层，确定详细的界面外观、导航和信息设计。

界面设计：为用户提供“做某事”的能力，即实现确定的“具体功能”。对可交互控件选择合适的位置布局，这些控件能够让用户容易理解和接受，从而帮助他完成任务。

导航设计：为用户提供“去某个地方的能力”。简单来说，就是帮用户找到方向感，顺畅的操作路径。导航有明显的两个用途：帮助我们找到想要的任何东西，告诉我们现在身在何处。

信息设计：考虑的是如何把设计元素粘合到一起，为用户呈现出有效的信息沟通。使用线框图是对一个页面所有组成部分、以及它们如何组合到一起、最直观的描述。将线框图的交互动起来，也就是有交互的，具有交互效果，比如点击翻页，可以跳转新的页面。如果只有线框图没有交互效果，则后期的沟通成本将会加剧。

2.5 表现层

感知呈现问题，满足用户的感官（视觉）感受，也就是视觉设计，一般而言的UI设计。

三、产品规划

产品规划将主要集中在产品的战略、范围及结构层级，并且加上产品的路线。

3.1 商业模式

此部分从整体上说明商业模式及整个系统如何运转，系统内的资金，信息，实物如何流转。如下图所示：

此系统为一个自营模式的智能无人零售柜系统，平台将设备放置到线下的场所，并将采用自主或第三方配将供应商商品配送上架货柜，消费者可以通过小程序查看附近的设备及设备里面的商品，通过使用手机及支付宝扫码支付的方式购买无人零售柜中的物品。

无人零售柜的日常巡检及维修处理由运维方负责，平台将通过进价及出售价格之间的商品差价，广告主在设备广告屏上的投放获取收益，后期将探索更多盈利模式（比如收取品牌商品的展示陈列费等）。

3.2 商业画布

快速确定一个商业项目的各方面关键要素的，具体如下：

• KA 关键业务——为了确保商业模式可行，企业必须做的作重要的事情。
• VP 价值主张——为特定客户细分创造价值的系列产品和服务。
• CR 客户关系——与特定客户细分群体建立的关系类型。
• CS 客户细分——企业想要接触和服务的不同人群和组织。
• KR 核心资源——让商业模式运转所必须的最重要因素。
• CH 渠道通路——如何沟通，接触其客户细分。
• CS 成本结构——运营一个商业模式所引发的所有成本。
• RS 收入来源——从每个客户群体获取的现金收入（需要从创收中扣除成本）获取收入的方式。

以下为智能无人零售货柜的商业画布：

3.3 用户角色分析

在确定商业模式商业画布之后，整个商业的逻辑基本已经清楚，需要进一步分析系统的所涉及的角色，具体角色及作用，他参与系统的成本（支出）及收益。

3.4 产品架构

产品架构为系统的整体架构图，需要明确系统的前端有多少入口及每个入口的核心功能，后台的核心功能，系统需要对接的第三方系统（包括内部及外部）。

当然，产品的架构不是一直不变，随着时间推移，业务的演化，架构也会调整。但是在前期规划的时候，需要考虑到业务未来可能的发展趋势，早做规划准备。不一定规划多少就要立即完成多少，可以分阶段逐步完成，但要提前分析规划，使架构在一定的时间段内保持稳定，不能轻易变更。

3.5 产品结构图

产品结构图是产品信息+功能结构图的整合，展示产品的功能框架结构，层级及信息的框架。具体如下图所示：

3.6 系统各端口核心功能

在产品结构图完成之后，可以进一步梳理系统涉及的端口核心功能描述，以智能无人零售柜的系统后台部分功能举例。

3.7 产品实施路线

产品实施路线，也可以说是产品迭代路线\计划。一个产品的成熟是需要逐步完成，目前来说，有很多项目，真的是以终为始，也即是一上马就是大平台的方式，功能齐备，生态健全。但这样的系统，往往死得很难看，最好是逐步过渡，先做MVP的小系统，尽可能的先让业务跑起来，然后逐步完善。

以智能无人零售货柜举例，下图中所示的MVP：系统后台、用户、运营（配送上货）、运维（巡检维修设备）均是必须的。但在功能上尽可能简单，前期的数据统计等尽可能通过手工完成，与供应商及各方的结算等也可以采用财务手工转账的方式实现，后期根据业务量逐步实现分析、财务结算的自动化。

就像大型商超，最开始可能就是夫妻小店，只用手工记账就可以，当店铺大一些的时候，用一张Excel表格就好了，再大一些，用一个简单的进销存软件，再大用套收银系统，软件系统是根据业务的发展而逐步壮大的。

在产品规划中，一定要防止一步到位建立一个大而全，所有时髦、高大上的概念齐备的系统，这是一种诱惑，但请抵制它。

01 写PRD的目的

产品需求文档，即Product Requirement Documen，PRD的主要使用对象有：开发、测试、项目经理、设计师、运营及其他业务人员。开发可以根据PRD获知整个产品的逻辑；测试可以根据PRD建用例；项目经理可以根据PRD拆分工作包，并分配开发人员；设计师可以通过PRD来设计交互细节。

PRD文档是将产品项目由“概念化”阶段推进到“图纸化”，将需求落实到可开发的。PRD文档在产品项目中是一个“承上启下”的作用，“向上”是对MRD内容的继承和发展，“向下”是要把MRD中的内容技术化，侧重的是对产品产品功能和性能（即“产品需求”）的说明，相对于MRD中的同样内容，要更加详细，并进行量化。

02 PRD撰写的前提条件

进行了需求收集与分析，构建了系统架构，绘制了功能结构图、信息结构图、产品结构图，2大流程图（业务、页面流程图）以及所有页面的原型稿、交互稿。完成这些部分之后，对以上部分进行有机的整合，撰写PRD文档。

03 PRD内容

3.1 文档编写记录

记录文档创建，修改的情况，文档的编写状态，编写人

示例：

3.2 文档修订记录

记录每次修改的修改内容，更详细的进行记录每次修改的情况，对修改情况做概要性的描述，使查看人能够清晰的感知修订情况

示例：

3.3 目录

根据PRD文档的章节自动生成生成，如果有变化进行更新整个目录的更新即可

示例：

3.4 概述

3.4.1 背景介绍

简要说明产品/项目需求产生的背景，要达到的目的和需要实现的功能

示例：

通过建立招商加盟平台的商户管理系统，商户（招商公司）能够在商户后台直接发布项目、文章，进行自有项目的推广。商户（招商公司）能够在商户后台支付会员、广告宣传、站外文章发布等增值服务费用。可以接待来咨询访问的用户，并进行交谈，记录用户线索，形成用户档案。

商户管理系统同时能为商户提供数据分析功能，对在该商家的访问、咨询、成交用户进行分析，对商户发布文章的宣传效果，广告投放效果进行综合分析，为商家的进一步业务开拓提供决策依据。

3.4.2 涉及范围

描述本次需求，主要涉及到公司内部的哪些平台，并简要描述各平台应该做哪些事情

示例：

3.4.3 阅读对象

描述本文档的的阅读对象有哪些，一般包含：公司业务总负责人、各平级部门经理、产品经理、UI设计师、研发工程师、测试工程师等与本项目相关的所有人员。

3.4.4 名词解释

对项目或者行业的专业词汇的解释，对于较为独特的行业，或者专有名词的，复杂的系统，一定要进行名词解释。名词解释的目的：所有成员中达成认知的一致，防止一个事物多种命名的情况产生，提高信息的传递效率，消除歧义。

3.5 结构图

产品相关结构图一般包含3种：功能结构图、信息结构图、产品结构图

3.5.1 功能结构图

定义： 功能结构图就是以功能模块为类别，介绍模块下其各功能组成的图。

作用： 产品设计时，辅助思路梳理，避免功能概念模糊、缺失。

绘制功能结构时，尽量避免信息结构要素出现的可能性，形容一个功能点时建议多采用“动词+名词”的语言描述形式 。

示例：

3.5.2 信息结构图

定义：指脱离产品的实际页面，将产品的数据抽象出来，组合分类的图表。

作用：帮助PM梳理复杂内容的信息组成，避免信息内容在展示过程中出现遗漏、混乱、重复；

作为开发工程师建立数据库的参考依据；信息结构图的绘制通常晚于功能结构图，往往是在产品设计阶段的概念化过程中，在产品功能框架已确定、功能结构已完善好的情况下才对产品信息结构进行分析设计。

示例：

3.5.3 产品结构图

定义： 产品结构图是综合展示产品信息和功能逻辑的图表 。可以理解为产品结构图是对产品原型的简化表达，产品结构图就是通过信息架构设计，将功能和信息以一种合理自然的逻辑，把功能结构图和信息结构图中的内容放入产品中的每一个页面的结果。

示例：

一般而言，直接采用产品结构图，对于概要描述，根据情况使用功能结构图，使用xmind制作产品功能结构图，并对产品功能进行简要描述。

3.5.4 产品功能概要

功能等级基本为三级+描述备注（模块、功能、子功能或者其它叫法），根据功能结构图而来，控制好级别，并进一步描述功能的内容和作用，对功能排列优先级，功能是否要进行分期开发，如果需要分期开发，则对应的开发周期需要注明，是否有另外的说明和备注，如果有则可以添加备注，尽量不要使用Excel中批注，很容易遗漏。

示例：

3.6 核心业务流程

对于本次需求中最核心的业务，采用泳道+文字描述的方式，对核心业务的阶段、步骤以及异常情况及判断进行描述。

在画业务流程之前，要深入了解核心业务，与相关业务人员进行深入的沟通，确认。确定泳道（即任务），确定产品有哪几个阶段，思考业务在各个阶段的形态，如果业务流程涉及多个部门的，需要共同进行沟通探讨，并可对部分流程进行优化。思考清楚后开始画业务流程图，在画的过程中也在头脑中进行梳理，尽可能的不遗漏任何的分支或异常情况。

可以采用的思考方法：

1. MECE——是Mutually Exclusive Collectively Exhaustive，中文意思是“相互独立，完全穷尽”。也就是对于一个重大的议题，能够做到不重叠、不遗漏的分类，而且能够藉此有效把握问题的核心，并解决问题的方法，也是找出异常流程的重要方法之一；
2. 5W1H分析——是对选定的事项、流程或操作，都要从原因（何因Why）、对象（何事What）、地点（何地Where）、时间（何时When）、人员（何人Who）、方法（何法How）等六个方面提出问题进行思考。可以寻找流程的改善方向，构思新的工作方法，以取代现行的工作流程方法；
3. 运用ECRS四原则——即取消、合并、重组和简化的原则，可以帮助人们找到更好的效能和更佳的工序方法。）。

业务流程图并不是一成不变的，在多次讨论会后中可能会有调整和变动。但每次调整或变动都需要进行明确，保证流程的清晰，不要存在核心流程的模糊死角。如果核心流程不清晰，则子流程以及后续很多工作都会导致极大的变动性，也会影响整体项目的进度，特别是在研发已经介入的情况，如果流程还存在不清晰的地方，开发工作也会反复。

3.6.1 核心业务流程

跨职能的泳道图——泳道图中需将业务数据流所涉及的所有业务平台加入到泳道中，同时需区分正常流程和异常流程。

示例：

业务流程描述：

用文字描述上述流程图中的所有流程，用以作为流程的补充说明，注意，流程中的每一步需以单独的数字序号进行描述。

示例：

优惠券发放、使用、核销流程

（1）优惠活动创建

1. 优惠活动由平台设置。
2. 平台创建优惠活动，费用由平台、设备提供方、或其它方承担，具体承担方由运营进行设置之前与各方沟通确认，并在设置的之时进行确定。
3. 此处活动的设置，主要设置基本信息，如活动的优惠类型（满减、立减、折扣类型可适当减少，比如第一期只用满减），针对什么商品类别或是单个商品，针对区域店铺或者单个店铺。

（2）优惠券发放

1. 从优惠活动中选择活动，设置优惠投放方案，如发放时间，有效期，针对门店，针对用户（新用户or老用户），自动发放还是用户手动领取
2. 设置投放方案后是否立即启用，如果启用，则在设置的投放时间向用户投放
3. 不支持正在投放的优惠券临时修改，只能停止作废，后台作废之后，用户端不管是否还在有效期内，均不能领取及使用
4. 正在使用的优惠券，优惠活动原始模板不能更改，如要改变，需单独创建。

（3）领取使用

1. 如果是系统自动发放的优惠券，用户不需要单独进行领取，优惠券自动领取，在用户端优惠券中心可以看到
2. 如果需要用户领取的，用户可在领券中心进行领取
3. 用户在领取优惠券之后，升降柜的优惠券使用可让用户自己选择，双开门柜为拿货之后自动结算，则自动选择优惠券使用，以优惠最大的券为准。

（4）核销结算

1. 用户使用优惠券购买商品之后，如果用户发生退款，则优惠券不退会，且不可再使用（即优惠券只能使用一次）
2. 如果订单中包含多个商品，均有使用优惠券，如果退款退货只退其中一部分，则优惠券也只退其中一部分，按比例进行摊薄
3. 进入清分结算的订单，有使用优惠券时，则在清分中按实际支付进行清分，并标注使用优惠券
4. 优惠券不进入清分，优惠券只进行费用承担，但使用该优惠券的订单结算完成后，该笔优惠券的费用承担状态为完成。

备注：

1. 优惠券采用创建与发放分开的形式，创建为创建优惠活动，不配置具体的发送方案
2. 用户领取优惠券后，在购买商品时，进行金额的抵扣（用户级别不一，则抵扣金额和券的类别有差异）

系统异常处理流程：

主要描述跨系统、角色间的业务流转方面的异常处理逻辑。还有其它的一些通用异常处理：

1. 获取地理位置权限失败
2. 发送通知权限获取失败
3. 网络情况

优惠券流程示例：

1. 优惠券发放错误，停止活动，则已发放的优惠券用户不能再使用，优惠券失效
2. 优惠券过期失效，不能再使用，并标记已过期失效，并给予提示
3. 退款订单中已使用的优惠券，不再恢复到可使用状态（即便未过期），直接作废
4. 其它

3.7 产品界面级功能及交互需求说明

根据产品原型上的页面结构，构建功能需求说明树。

示例：

3.7.1 功能一（界面）

粘贴产品功能界面，并对产品功能界面的功能、交互进行描述

示例：

使用流程：

以任务流方式，描述用户在完成该功能时的步骤、业务逻辑。

示例（登录）：

页面交互：

各页面间的交互，互动链接关系，以一个功能所涉及的相关页面为

示例

异常处理：

描述业务发起过程中的异常处理流程。

1. 手机号做位数及类型限制，位数只能11位，只能是数字。
2. 密码由字母+数字构成，字母区分大小写，密码的组合方式为“大写字母or小写字母+数字”，如果用户输入字符与此规则不匹配，则进行提醒用户按规范输入
3. 如果用户未输入账号密码点击登录，手机账号：提示“手机账号未填写”；密码：提示“密码未填写”；账号与密码不匹配时，
4. 输入的账号未进行注册，提交检测在后台无记录，提示：用户账号不存在
5. 用户输入的账号与密码不匹配，则提示：用户名或密码输入错误

3.8 安全需求

描述项目需要遵循的安全标准及需要进行安全验证等。验证包括手机短信、身份信息、银行信息，信用信息（芝麻信用）所有这些均有第三方接口进行验证，支付费用即可进行验证。

3.9 数据监测分析

数据监测

采用数据埋点、数据采集等方法统计用户行为数据。

第一种方式：自己开发——优点是保密性高，所有数据都在自己的平台中，但是很费时间，要想做的好，对技术也有一定要求

第二种方式：使用第三方接口——比如友盟、神策、growio、百度等均提供接口，能快速的解决问题，另外growio，百度都有无埋点方式，就是不需要一个个数据点进行单独的埋点，而是监测所有有数据传输，操作行为的点，接入sdk之后，可以自主选择数据点进行分析。这种方式，不会存在遗漏，灵活度也非常高。

数据分析

第一种方式也是完全自主开发，在早期的时候，数据量不大的时候，可以直接将数据导出进行Excel表的分析，

第二种方式是接入第三方接口，比如finebi、powerbi、DataFocus、tableau等，在选择第三方的时候要注意，是否满足企业要求（当下及后期），是否可以进行私有化部署，后期扩展的灵活性，是否简单易用，费用。

3.10 系统日志需求

对系统处理业务的操作记录或者逻辑记录在日志中，便于后期查找、追溯。

3.11 验收标准

说明需求验收上线的评价指标及参与验收的人员，可以制作验收单，产品是最终负责人。

3.12 其它产品需求

3.12.1 性能需求

明确产品的性能，知道产品性能上限，随着业务的发展，清楚改善节点。在早期考虑综合成本的情况并满足业务需求的情况下，可以对性能做一定的妥协。

• 并发量：简单的可以说，同一秒的登录量，同时在线，订单并发量最高可以允许多少。比如客服系统，允许同时对话200，也就是允许同时存在200对话通道。
• 图片加载：图片加载的时间，页面跳转切换的时间，在不同网速下，允许的时长（不同网络情况下，信号有强弱，可能根本4G、5G信号，或者用户的卡是3G）

3.12.2 兼容性、适配需求

PC——兼容目前主流的浏览器，比如IE8、及Firefox3.5、safari、chrome等主流浏览器的主流版本，将相关版本进行罗列，同时考虑H5的跨设备适用性问题（比如官网在pc和手机的查看，看到过有些系统将功能复杂的后台没有做适配要在手机查看使用一团糟的情况，功能复杂的后台基本是不太适合在手机上操作的）。

机型——通过各种渠道（talkingdata，友盟）查目前的主流机型，市场占比，根据公司情况，选择占比靠前的测试机型，或者采用第三方测试平台（testin，testbird）

3.13 相关文档

A、原型地址

XX平台商户后台墨刀地址（密码XXX）：

XX平台系统后台墨刀地址（密码XXX）：

B、消息通知模板

C、其它

商标，软著，域名、服务器、支付平台、消息接口、其它需要准备各类平台账号及及截止时间节点，部分事项可以并行，部分事项有严格的先后顺序，在进行计划安排时，需要作出区分，尽可能缩短时间，不要出现绝大部分人等一个人的情况出现。

04 产品向各方需求文档内容

4.1 给设计师文档

思维导图、流程图、功能清单、原型图（含交互）。

4.2 给研发文档

思维导图、功能清单、流程图、原型图、UI设计图、PRD文档、数据埋点文档

4.3 给运营文档

思维导图、流程图、功能清单、PRD文档、产品使用说明书，上线资料准备清单（上线前需要准备的比如需要录入的商家信息）。

以上是PRD文档相关内容，下一篇文章将是——版本命名、验收规范、发版管理；