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

产品小白专属,10周线上特训,测、练、实战,22位导师全程带班,11项求职服务,保障就业!了解详情

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

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

不用自宫,也能成功。

功能需求

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

概要功能需求

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

业务需求

帮助理解产品的业务需求和内容

产品描述:总整体上解释和描述产品定位,产品目标。如,该产品是一款专注于xxx的平台,A业务解决用户xxx的问题,B业务解决运营xxx的问题。

个人认为,PRD中业务需求粒度不宜过细,毕竟PRD是偏向于可量化指标,以指导设计为主。但有的时候,产品MRD、PRD会合并成同一个文档。这种情况下,可以在产品描述中,展开MRD相关内容,如市场分析,用户分析,竞品分析,可行性结论等。

概要功能列表:列出文档涉及的功能列表清单

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

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

  1. 产品可用性的需求
  2. 产品用户体验性需求
  3. 产品扩展性需求
  4. 产品生态需求

产品结构图

帮助了解产品功能和总体形态的概貌。

全局功能结构:表达这个产品整体的功能层次和逻辑关系,通常用脑图来表达。

页面结构图:以页面为基准,描述产品各页面的层次结构,常用于移动端产品,可用结构图表达。

利用墨刀等原型工具,可以通过创建页面工作流快速完成。

业务流程

帮助理解产品的业务关系和流程。

产品用例图:以不同的用户或角色为基点,通过用例,表达用户会使用的功能边界,常见于后台系统。

示例来源于网络

整体流程图:用于描述某个整体任务时,各模块之间的配合关系,常见于后台系统。

示例来源于网络

全局数据流:用于描述纪录或表单等信息的流转关系或层次结构,常用于后台系统。

示例来源于网络

根据产品类型,选择需要的表达模型去构建PRD

详细功能需求

这部分大家应该都不陌生,是PRD核心中的核心,用于描述功能的量化指标,是研发部门关注的重点。

对于详细功能,我把它分为两种类型,一种是业务功能,一种是报表功能。根据不同的类型,结构有所不同。

业务功能

功能名称

一般直接使用功能名称作为标题项,便于生成目录和在文档结构图中快速定位。一个story一个小节

概述:

包含功能的一般性描述,包含以下几点内容

需求描述:推荐一个一句话描述需求的模版给大家“xxx(角色)在xxx的情况下,通过xxx的方式,达到xxx的目的”。

业务场景:描述用户的使用场景,可以用拟人化的语言去表达,如:“小王到达A写字楼后,停车场管理员告知车位已满,小王扫扫描车位二维码,寻找附近的空闲停车场。”

参与者:表述此功能具体使用人有哪些,如某功能是管理员使用还是员工使用。

业务流程

详细描述次业务涉及的主要事件流程,可通过流程图辅助说明

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

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

相关功能

与本功能相关,但较复杂,难以一起表达时,拆分到细分场景后所关联的功能。可以描述出它们直接的输入输出关系。

界面原型

原型截图或者链接至原型文档。

另外,有必要时,需要说明界面中数据项的详细描述

业务规则

针对此功能或某个数据相的业务规则描述,如果在业务流程中描述过,不需要重复描述。

例如:钱包余额不足时,可转为刷银行卡支付。

设计约束

描述需要设计、开发特别注意的事项。如:没有说明的抽象框架设计;可兼容某些特性;不可用状态时的显示要求。

如果是公共性的约束,可以通过全局说明,来阐述通用约束。如:对话框样式,加载样式等

验收标准

描述产品验收时要满足的内容,是测试人员重点关注事项。

原则上优先保证正常流下的业务结果正确,异常边界不报错,提示明确即可。

如:能够注册成功,失败原因提示正确。

报表功能

功能名称

一般直接使用报表名称作为标题项,便于生成目录和在文档结构图中快速定位。如:某某报表,编写时一个报表一个小节。

概述

因报表一般情况下的用户是管理者,因此报表类功能概述主要便于理解业务场景和管理者意图和目的

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

报表内容

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

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

界面原型

报表展示原型。个人建议报表原型最好模拟一些真实数据和用户确认最终效果。

报表框架

描述报表模块的通用框架需求,如:打印,打印预览,导出,总计,排序,默认纬度,筛选条件,分页,是否支持动态报表模版等

设计约束、验收标准

与业务功能相同,这里不再重复说明。

数据字典

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

【未完待续】

相关阅读

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

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

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

 

作者:小星星,8年互联网工作经验,5年技术,3年产品。

本文由 @小星星 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自 Unsplash,基于 CC0 协议

给作者打赏,鼓励TA抓紧创作!
7人打赏
评论
欢迎留言讨论~!
  1. 说实话,内容太多研发,交互都不乐意看

    回复
    1. 如果是外包出去做,有些是必要的,所以还是得看你的团队情况,输出自己的模板,不要生搬硬套

      回复
  2. 觉得非常好,楼主有没有示范的PRD文档范本?

    回复
  3. 不错,就是产品工作量巨大….有一些可写可不写的太多

    应该分类模板来规约,大概可以这么定义:
    1.手机APP、小程序,H5适用,最简化模板

    2.后台、PC客户端适用,中等模板

    3.大型产品适用,完整版模板

    回复
  4. 大佬,能加加我吗?我想求教一下

    回复
    1. :oops: 可以加我微信hjxdxcool

      回复
    2. 大神可以加微信交流下吗

      回复
  5. 收藏+赞,表示刚接触prd一脸懵逼,不过自己实际写完之后在来看这个还是很有启发的

    回复