最全的B端产品PRD规范(上)
不知道工作中你是否遇到过这样的问题?
- 你认为写的需求文档简单易懂,但是开发读不懂你的文档;
- 你认为写的需求文档天衣无缝,评审时漏洞百出,遭受各方挑战;
- 你认为写的需求文档行云流水,但是读者体验较差,对系统的整体架构一脸蒙圈。
规范的PRD文档可以给我们带来什么?
- 每个公司均有自己的PRD规范格式,都是在最基础的模板上进行增减,可以有效降低文档使用对象的阅读门槛。
- 规范行文格式以及行文脉络,遵循MECE的原则,可以在一定程度上对功能模块进行查漏补缺。
- 清晰给予读者系统全方位视角的流程图,架构图等等,帮助读者从宏观视角理解文档。
下面给大家展开介绍一下规范的PRD文档的书写。
首先需要明确PRD面向对象为哪些人,重点需要给哪些人进行讲解,例如:业务方、设计团队、产品团队、研发团队、运营团队及PM自己等等。
其次为版本号的命名,命名规则一般为Va.b.c(abc均为正整数),对全局功能的升级改版,改头换面需要改变a,依次加1;对流程以及部分功能的修改以及升级需要改变b,依次加1 ;对细微处的优化修改不影响主流程需要改变c,依次加1。
最后给大家呈现标准的格式如下:
XXX项目XX系统V1.1.0(需要注明项目以及涉及的系统)
一、背景描述
介绍项目产生的背景。
二、 名词解释
对文档中出现的新的名词给出定义和解释。
三、产品目标及价值
1. 调研信息和数据
提供前期调研信息和数据给出一些重要的项目数据。
2. 产品预期目标
明确本次迭代的预期目标及价值,给出有量化的目标值。
四、产品概述
1. 用户角色
哪些用户在什么场景下用到系统的某些功能,做用户角色以及故事简单描述。
2. 总体流程
- 主流程图以及主要分支流程图;
- 产品架构图。
3. 功能摘要
4. 对其他系统的影响
跟自己上下游系统之间有无影响,影响面多大,涉及到哪些功能点。
五、功能需求
1. 功能模块
1)用户场景
用户通过什么操作或途径触发该功能模块。
2)约束条件
前置条件:用户触发功能模块的前置条件。
后置条件:用户执行完该功能或操作后,关联的数据会有什么变化,页面怎么跳转。
3)输入/输出
当用户输入时,对于不同的输入该如何处理?当用户完成输入并提交时,系统该做什么校验?不同结果该返回什么值?
建议通过业务流程图 文字来描述,以确保逻辑清晰、完整。
4)异常处理
如网络错误、接口返回异常、服务器内部错误等,产品需要给出对应的解决措施或是相应反馈。
5)状态转换
列出产品的各种状态及状态转换图。
6)界面&排序规则
每个界面都可以拆分成多个元素,如表单、文本、链接、图片等。
7)数据字典
该功能涉及哪些数据,哪些可以通过数据字典进行配置,可以给到开发一些参考。
六、非功能需求
包括数据需求、性能需求、监控需求、兼容性需求、安全需求等。
1. 数据需求
如果系统需要数据统计,例如:PV、UV等,PM要提前梳理出需要埋点的事件,同步给开发进行埋点。
2. 性能需求
如果系统对性能有特殊需求,例如:最大并发数、响应时间等,可提前联系技术及运维人员准备部署方案。
3. 监控需求
如果系统需要特殊的监控,例如:当某个接口或服务出现异常时,可发送报警信息至相关人员。
4. 安全需求
如果系统对安全有特殊需求,例如:手机号需要进行加密,密码需要进行密钥管理,外网是否可以访问等等。
5. 兼容性需求
如果产品需要对兼容性提出特殊的需求,例如:需要小米11,苹果14的机型等等,需要提前联系对应的测试以及机型管理员,提前做好适配。
七、风险与运营
- 上线后需要如何运营达到相应指标;
- 上线后对历史功能的影响以及宣传是否到位;
- 上线后需要打配合的部门有哪些,需要做何种协助。
版权声明
本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!