PRD修炼真经•卷二:一份标准化产品需求文档的逻辑思路

最近比较忙,水逆没有动力更新,接上一篇《PRD修炼真经•卷一》。

特别声明: 此文目的是解构标准化PRD中各章节的逻辑,并不是PRD的模版。
不用自宫,也能成功。

功能需求

功能需求是PRD核心内容,前面说引言是帮助理解文档本身,概述帮助理解项目和产品本身,那么功能需求部分就是 帮助理解业务和功能 。下面对功能需求的各部分内容进行详细说明。
超级产品经理

概要功能需求

概要功能需求是用于描述提供给用户的产品特性和功能。通常使用框图、表、文字结合的方式说明,便于快速理解。

业务需求

帮助理解产品的业务需求和内容
产品描述: 总整体上解释和描述产品定位,产品目标。如,该产品是一款专注于xxx的平台,A业务解决用户xxx的问题,B业务解决运营xxx的问题。
个人认为,PRD中 业务需求粒度不宜过细 ,毕竟PRD是偏向于可量化指标,以指导设计为主。但有的时候,产品 MRD、PRD会合并成同一个文档 。这种情况下,可以在产品描述中,展开MRD相关内容,如市场分析,用户分析,竞品分析,可行性结论等。
概要功能列表: 列出文档涉及的功能列表清单
超级产品经理

  • 需求编号常见于大型后台系统,便于查找。
  • 需求分析可以描述该需求内因,外因,kano等级,紧急程度等,便于快速了解。
  • 优先级指导先后顺序,可用与火车头发布模式。

我见过很多需求文档中,优先级设定没有规则。我个人 优先级顺序原则是:

  • 产品可用性的需求
  • 产品用户体验性需求
  • 产品扩展性需求
  • 产品生态需求

产品结构图

帮助了解产品功能和总体形态的概貌。
全局功能结构 :表达这个产品整体的功能层次和逻辑关系,通常用脑图来表达。
超级产品经理
页面结构图: 以页面为基准,描述产品各页面的层次结构,常用于移动端产品,可用结构图表达。
超级产品经理
利用墨刀等原型工具,可以通过创建页面工作流快速完成。

业务流程

帮助理解产品的业务关系和流程。
产品用例图: 以不同的用户或角色为基点,通过用例,表达用户会使用的 功能边界 ,常见于后台系统。
超级产品经理
示例来源于网络
整体流程图: 用于描述某个 整体任务 时,各模块之间的配合关系,常见于后台系统。
超级产品经理
示例来源于网络
全局数据流: 用于描述纪录或表单等 信息的流转关系 或层次结构,常用于后台系统。
超级产品经理
示例来源于网络
根据产品类型,选择 需要的表达模型去构建PRD 。

详细功能需求

这部分大家应该都不陌生,是PRD核心中的核心,用于描述功能的量化指标,是研发部门关注的重点。
对于详细功能,我把它分为两种类型, 一种是业务功能,一种是报表功能 。根据不同的类型,结构有所不同。

业务功能

功能名称
一般直接使用功能名称作为标题项,便于生成目录和在文档结构图中快速定位。 一个story一个小节
概述:
包含功能的一般性描述,包含以下几点内容
需求描述: 推荐一个 一句话描述需求 的模版给大家“xxx(角色)在xxx的情况下,通过xxx的方式,达到xxx的目的”。
业务场景: 描述用户的使用场景,可以用 拟人化 的语言去表达,如:“小王到达A写字楼后,停车场管理员告知车位已满,小王扫扫描车位二维码,寻找附近的空闲停车场。”
参与者: 表述此功能 具体使用人 有哪些,如某功能是管理员使用还是员工使用。
业务流程
详细描述次业务涉及的主要事件流程,可通过流程图辅助说明

  • 前置条件: 在开始前,系统可检测的有意义的条件。如:意见反馈查询功能中,用户已提交意见反馈
  • 触发事件: 触发次系统功能的事件。如:用户点击、收到通知
  • 基本事件流: 常规,正常情况下的预期事件流。如:1、点击xxx进入页面,2、输入xxx,3、选择xxx,4、点击确定保存xxx。可以通过流程图辅助说明。

超级产品经理

  • 扩展事件流: 备选,可选事件流。如:1、可通过点击{导出},进入导出流程。
  • 异常事件流: 异常情况下事件流。如:空状态下,服务异常时的事件流。
  • 后置条件: 在结束后,系统可检测的有意义的条件。如:1、保存后,界面数据更新。

相关功能
与本功能相关,但较复杂,难以一起表达时, 拆分到细分场景 后所关联的功能。可以描述出它们直接的输入输出关系。
界面原型
原型截图或者链接至原型文档。
超级产品经理
另外,有必要时,需要说明界面中 数据项的详细描述
超级产品经理
业务规则
针对此功能或某个数据相的业务规则描述,如果在业务流程中描述过,不需要重复描述。
例如:钱包余额不足时,可转为刷银行卡支付。
设计约束
描述需要设计、开发特别注意的事项。如:没有说明的抽象框架设计;可兼容某些特性;不可用状态时的显示要求。
如果是公共性的约束,可以通过全局说明,来阐述通用约束。如:对话框样式,加载样式等
验收标准
描述产品验收时要满足的内容,是测试人员重点关注事项。
原则上优先保证正常流下的 业务结果正确,异常边界不报错,提示明确 即可。
如:能够注册成功,失败原因提示正确。

报表功能

功能名称
一般直接使用报表名称作为标题项,便于生成目录和在文档结构图中快速定位。如:某某报表,编写时一个报表一个小节。
概述
因报表一般情况下的用户是管理者,因此报表类功能概述主要便于理解业务场景和 管理者意图 和目的

  • 目的: 管理者因为什么需要查看此报表
  • 使用部门/职位: 用于理解使用者的职责,包括地理级别,如:xx财务经理岗位,省级/市级。
  • 相关场景与评率 :大概多久查一次,纬度有多大。

报表内容
详细描述报表各项数据的 来源和计算规则 。

  • 数据来源: 该数据项的基于哪些数据生成。如:消费金额统计,来源于xx订单纪录
  • 计算规则: 该数据的统计公式。如:消费金额统计,xx订单中“实收”的累加总额。

界面原型
报表展示原型。个人建议报表原型最好模拟一些 真实数据 和用户确认最终效果。
报表框架
描述报表模块的 通用框架需求 ,如:打印,打印预览,导出,总计,排序,默认纬度,筛选条件,分页,是否支持动态报表模版等
设计约束、验收标准
与业务功能相同,这里不再重复说明。

数据字典

列出有关功能的数据元素,或信息结构。若原型部分已经描述过,可以省略。
【未完待续】

相关阅读

PRD修炼真经•卷一:一份标准化产品需求文档的逻辑思路
 
作者:小星星,8年互联网工作经验,4年技术,4年产品。

关键字:产品经理, 需求文档, 描述, prd

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场,不承担相关法律责任。如若转载,请注明出处。 如若内容造成侵权/违法违规/事实不符,请点击下方“内容举报”进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部