最全的B端产品PRD规范(上)

不知道工作中你是否遇到过这样的问题?

  • 你认为写的需求文档简单易懂,但是开发读不懂你的文档;
  • 你认为写的需求文档天衣无缝,评审时漏洞百出,遭受各方挑战;
  • 你认为写的需求文档行云流水,但是读者体验较差,对系统的整体架构一脸蒙圈。

规范的PRD文档可以给我们带来什么?

  • 每个公司均有自己的PRD规范格式,都是在最基础的模板上进行增减,可以有效降低文档使用对象的阅读门槛。
  • 规范行文格式以及行文脉络,遵循MECE的原则,可以在一定程度上对功能模块进行查漏补缺。
  • 清晰给予读者系统全方位视角的流程图,架构图等等,帮助读者从宏观视角理解文档。

下面给大家展开介绍一下规范的PRD文档的书写。

首先需要明确PRD面向对象为哪些人,重点需要给哪些人进行讲解,例如:业务方、设计团队、产品团队、研发团队、运营团队及PM自己等等。

其次为版本号的命名,命名规则一般为Va.b.c(abc均为正整数),对全局功能的升级改版,改头换面需要改变a,依次加1;对流程以及部分功能的修改以及升级需要改变b,依次加1 ;对细微处的优化修改不影响主流程需要改变c,依次加1。

最后给大家呈现标准的格式如下:

XXX项目XX系统V1.1.0(需要注明项目以及涉及的系统)

最全的B端产品PRD规范(上)

最全的B端产品PRD规范(上)

一、背景描述

介绍项目产生的背景。

二、 名词解释

对文档中出现的新的名词给出定义和解释。

三、产品目标及价值

1. 调研信息和数据

提供前期调研信息和数据给出一些重要的项目数据。

2. 产品预期目标

明确本次迭代的预期目标及价值,给出有量化的目标值。

四、产品概述

1. 用户角色

哪些用户在什么场景下用到系统的某些功能,做用户角色以及故事简单描述。

2. 总体流程

  1. 主流程图以及主要分支流程图;
  2. 产品架构图。

3. 功能摘要

最全的B端产品PRD规范(上)

4. 对其他系统的影响

跟自己上下游系统之间有无影响,影响面多大,涉及到哪些功能点。

五、功能需求

1. 功能模块

1)用户场景

用户通过什么操作或途径触发该功能模块。

2)约束条件

前置条件:用户触发功能模块的前置条件。

后置条件:用户执行完该功能或操作后,关联的数据会有什么变化,页面怎么跳转。

3)输入/输出

当用户输入时,对于不同的输入该如何处理?当用户完成输入并提交时,系统该做什么校验?不同结果该返回什么值?

建议通过业务流程图 文字来描述,以确保逻辑清晰、完整。

4)异常处理

如网络错误、接口返回异常、服务器内部错误等,产品需要给出对应的解决措施或是相应反馈。

5)状态转换

列出产品的各种状态及状态转换图。

6)界面&排序规则

每个界面都可以拆分成多个元素,如表单、文本、链接、图片等。

7)数据字典

该功能涉及哪些数据,哪些可以通过数据字典进行配置,可以给到开发一些参考。

六、非功能需求

包括数据需求、性能需求、监控需求、兼容性需求、安全需求等。

1. 数据需求

如果系统需要数据统计,例如:PV、UV等,PM要提前梳理出需要埋点的事件,同步给开发进行埋点。

2. 性能需求

如果系统对性能有特殊需求,例如:最大并发数、响应时间等,可提前联系技术及运维人员准备部署方案。

3. 监控需求

如果系统需要特殊的监控,例如:当某个接口或服务出现异常时,可发送报警信息至相关人员。

4. 安全需求

如果系统对安全有特殊需求,例如:手机号需要进行加密,密码需要进行密钥管理,外网是否可以访问等等。

5. 兼容性需求

如果产品需要对兼容性提出特殊的需求,例如:需要小米11,苹果14的机型等等,需要提前联系对应的测试以及机型管理员,提前做好适配。

七、风险与运营

  1. 上线后需要如何运营达到相应指标;
  2. 上线后对历史功能的影响以及宣传是否到位;
  3. 上线后需要打配合的部门有哪些,需要做何种协助。

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部