《产品经理学习资料---一位产品老手对PRD的再思考.docx》由会员分享，可在线阅读，更多相关《产品经理学习资料---一位产品老手对PRD的再思考.docx（12页珍藏版）》请在金锄头文库上搜索。
1、一位产品老手对PRD的再思考当需求分析确定好之后，我们又该如何将自己的产品思路、产品逻辑, 整理编写成一份内容完整，思维清晰的PRD文档呢？这篇文章包含编写PRD最重要的两个局部：写PRD的基本步骤&PRD文档 的组成局部。不管是产品小白还是产品老狗，都能在里面重新梳理出新的产 品思路，让我们一起来学习下！2015年，我写了一篇梳理PRD的文章，获得3. 5万次阅读。至今已过去 5年，在这5年里，我一直从事产品相关的工作，也经历过一次完整的创业， 对PRD又有了一些新的思考。本文弥补了之前文章的缺乏，对怎么写PRD,描述得更具体、更全面， 是我思考的沉淀，也希望对大家有帮助。01你是否遇到过这
2、样的问题PRD里关键需求描述不准确，研发过程中不断修改，导致工程延期；产品总监、工程经理、研发、测试总是不断挑刺，信誉度降低，自信心 受打击；到新公司负责新工程，前任产品经理留下的文档晦涩难懂，不知所云。如果遇到以上一个或多个问题，那么你可能需要反思，自己写PRD的思 路是不是有问题？写PRD是产品经理非常重要的基本功，写好PRD,可以提 高团队效率，减少无效的沟通。02什么是PRD?PRD是Product Requirement Document的简称，其中文翻译为：产品需 求文档。该文档是产品工程由“概念化”阶段进入到“图纸化”阶段的最重 要的一个文档。例如:开始输入手机号是A否制？输入验
3、证码点击登录是单格式校仁是否通文否A册？是否已注自动注册文字版:是登录成功步骤用户系统侧1增入手机号1、文本框.必填，最多可输入10位数字。2、必须以0开头。3、错误提示：“手机号格式有误，请重新输入”2获取验证码3判断是否触发限制1、按钮，点击后开始倒计时。2、同一 IP或同一手机号.五分钟内最多 可获取5次,1天最多能发20次。3、超限提示：“获取次数超限，请稍后再 试“4输入验证码1、文本框.必填。只能输入4位数字2、正确的验证码。3、5 硼4、验证码错误提示：“验证码有误请重新输入5、验证码过期提小：”验证码已失效 请 重新获取验证码”5点壬登录是否已注册？1、根据手机号判断是否将注册
4、2、如果已注册，直接登录异常和分支流程异常流程如网络错误、接口返回异常、服务器内部错误等;以登录为例，分支流程包括找回密码、密码登录等，分支流程非必须,简单的分支流程可以直接通过主流程表达,具体可以视情况按照一定颗粒度进行拆分。数据字典这个用例涉及哪些数据，可以通过数据字典描述，这一步非必须，最终 表结构也不一定就是这样，只是给开发一个参考。有技术背景的产品，也可 以做得更细。以注册功能涉及的用户表为例：字段名称频必填默认值用户桀号varchar20Y手机号varchar20Y密码varchar64Y创立时间datetimeY时间datetimeYtokenvarcharY状态int产品经理一
5、定要懂基本的数据库知识，程序二数据结构+算法。用户使用 产品时，本质上是在和数据进行交互，只是在用户和数据之间，加了一些列 算法。7、非功能需求数据需求。常见的就是数据埋点，产品经理需要梳理出埋点事件表，告 知开发，让开发在编码过程中进行埋点。监控需求。需要监控某个接口或某些服务，当出现异常时，可以发送报 警信息至相关人员。性能需求。需要支撑多大的并发，运维人员可以提前准备部署方案。最后，一定要用正确的思路去写PRD,更要想清楚PRD所呈现方案的价值。方向不对，努力白费。记住，找准问题比解决方案更重要。PRD的主要使用对象有：研发、测试、交互设计师及其他业务人员。研发可以根据PRD获知整个产品
6、的逻辑，作为编码的依据；测试可以根据PRD编写测试用例，为正式测试做准备；交互设计师可以根据PRD设计交互细节；业务人员可以通过PRD提前了解产品，为运营和推广做准备；PRD是工程启动之前，必须经过评审达成共识的最重要文档。产品经理的PRD,就像建筑设计师的设计图纸，是设计和思考的文档化 呈现。用户体验要素作者在书中有一句很经典的话：“文档不能解决问题， 但定义可以，PRD就是要定义需求。03动手之前，先思考这几个问题1、解决什么问题？解决用户什么问题？发现问题比解决方案更重要。给公司能否带来收益? 相关干系人的需求是什么？是不是老板说这样做的？是不是“他们”说这 样做的？他们是谁？真正的问题
7、是他们说的那样吗？产品经理正确的设计思路如下：这叫RTPA设计框架，是一种逆向思维假设分析，我们要使用这样一种 思考技巧：假设初始需求都是错误的，即问题并不存在，你需要重新发现问 题。不要需求方一提需求，就开始着手设计，多问几个为什么并着手调查,以了解真正的问题。下面是一次完整的设计思路例如:线设：明确的退款规那么 有利于褥升效率假设：威少财务人工审 核可提升效率提升受理效率不同的干系人，通过什么指标去衡量问题是否已解决？有没有埋点？有 没有业务数据？谁来运营？3、需要多少资源？为了实现这个解决方案，需要多少资源、多少人？能大致评估吗？4、会不会太复杂？这个解决方案会不会太复杂？复杂是产品的坟
8、墓。有没有性价比更高的 解决方案？会不会影响现有的业务？会不会影响历史数据？5、有风险吗？这个方案会有风险吗？有没有违法？相关政策是什么？尤其是金融、游 戏领域，国家监管比拟严，有可能上不了应用市场，有可能三方服务商不会 提供服务。6、有创新吗？有更创新的解决方案吗？竞品怎么做的，有没有调研3个以上的竞品方 案。7、用户怎么说？需求真的是提交人说的那样吗？有亲身体验过场景吗？有跟用户面对面交流吗？熟悉相关领域的基本知识吗？有看不懂的名词吗？动手写文档或做设计方案之前，一定要问问自己以上几个问题，想清楚 了在动手，任何一个问题没想清楚，都不要进行下一步。04写PRD的基本步骤 搭框架、定流程、扣
9、细节，这是从一名产品前辈那了解到的产品设计流程，写PRD,也可以按照这个思路。1、搭框架首先遍历出所有用户角色，再针对每个角色，提供相应的系统/功能， 然后按照某种维度进行结构划分。这个步骤完成后，就可以输出产品的系统 架构图及系统的功能结构图。电商平台产品架构渠道中心分销商管理分销商品管理分销订单管理分销联盟CMS系统运营中心一行而索疏会员系统服务系统公告管理活动管理广告管理邮件管理短信管理微信管理注册管理登录管理会员中心呼叫中心售后管理帮助中心内容管理订阅管理服务管理CRM交易中心仓储中心导购中心! ! 产品中心采购中心分仓系统频道系统出入库系统 ：专题系统品类系统常规售卖系统商品系统拍卖
10、系统分拣系统： 搜索系统 ：:定价系统预管系统订单中心基础系统盘点系统商品展小系统库存系统购物车系统金融中心熊耕心 西神心 j 瓦隹不心账务系统网关系统风险政策管理系统管理权限系统日志系统清结算系统充值系统风险监控管理基础数据短信通道电子协议发票系统： 提现系统风险事件处置图片服务产品架构图产品由一个个功能组成，功能是逻辑结构，一个完整的功能具备输入、 处理、输出三大特性。从大到小的划分是：系统功能模块功能，用户+功 能组成了用例，用例是PRD文档里描述占比70%以上的内容，所以合理的功 能结构，是写好PRD的前提。2、定流程每个产品都有一个核心业务流程，这个核心业务流程涉及多个角色，这 个步
11、骤就是把各个角色和功能联系起来。通过核心业务流程，阅读者可以了 解产品全貌，对产品有个宏观的认识。此外，每个系统也有各自的核心业务流程，全业务流程+子系统业务流程，可以概括产品的业务逻辑。这个步骤输出产品核心业务流程图，子系统核心业务流程图，活动图, 状态机图，与外部系统交互可能还有时序图。3、抠细节这一步的核心是画原型和功能设计，通过原型表达产品的界面和交互。 功能设计主要是从输入处理输出三个方面去考虑，用户执行输入指令后，系 统会进行逻辑处理，然后输出结果。此外，还要考虑功能涉及到哪些数据, 表结构怎样设计，这些会涉及大量细节，PRD大局部内容，都是在描述这些 细节。步骤1和步骤2没有严格
12、的顺序，也可以先梳理业务流程，再根据流程 中的具体场景梳理出实际功能或系统结构。05文档的组成局部1、修订记录记录每次文档更新的时间、作者、修订内容，便于追溯历史变动；2、全局说明包括名词解释、统一异常处理、列表默认数据规那么等。名词解释：每个行业都有专业术语，可以提前将晦涩难懂的术语提前做 好解释，便于达成共识，更好沟通；统一异常处理：网络异常、后台服务异常的交互逻辑；列表默认数据规那么：默认列表的排序方式，默认显示条数，超过多少条 翻页，缺省值展现方式；所有涉及全局的描述，都可以罗列在这里。3、工程背景每个产品，都有一套价值模型。以信贷产品为例，针对用户的价值指标 有放款额、审批时长、是否
13、上征信等；针对后台业务人员，有审批时效、通过率、放款率、坏账率等指标；针对老板，有投资回报比、员工本钱、净利 润等价值指标，每一个需求，应该都是围绕某个价值指标展开。背景从现状、方案、目标3方面描述。现状：描述当前需求方遇到的问题，最好能跟价值模型关联；方案：针对这个问题，所提供的解决方案概述；目标：期望获得多少价值指标提升；通过工程背景的描述，可以让工程参与者感受到自己的工作价值。4、工程范围工程范围对应搭框架局部，将功能结构图在此处罗列；5、业务流程业务流程对应定流程局部，将核心业务流程、子系统业务流程在此处罗 列；6、功能需求这个局部在PRD中占比最大，搭框架局部，已经将产品功能点全部梳
14、理 出来了，这局部就是对功能点进行逐一描述。功能是从系统的角度来看，我 们还要考虑用户角度，所有我们采用用户+功能的方式来描述需求，这就是 用例。完整用例名称一定是动宾结构，如添加文章、删除文章、修改文章、 查看文章列表。一个完整的用例包含：描述（非必须）前置条件后置条件界面交互业务流程异常和分支流程数据字典（非必须）描述功能的简要描述。前置条件要操作此功能，需要具备什么角色、权限或状态。后置条件执行完这个用例后，关联的数据会有什么变化，页面怎么跳转。界面每个界面都可以拆分成多个元素，如表单、文本、链接、图片等；表单的每个元素要描述是否可为空、是否有初始内容、是否默认选中、 是否有字数限制等，还有对应的错误提示；文本要考虑最大显示长度，超过怎么处理；链接一定要指定点击后跳转到哪个页面；图片要考虑显示的比例，如果未加载出来该显示什么；还要考虑界面的内容是写死还是通过后台配置；登录界面元素:元表手机号获取验证码验证码输入框短信密码登录+84请输入验证码获取险证码 59S点击。登录二即代表您已同意软件注册协议尸 除私协议侧1、文本框，必填.最
