【2】PRD文档介绍
首先,我想说,题主是一个不严肃的人(严肃脸),所以每次干个啥事之前我都喜欢唠唠嗑,说说废话,沟通沟通感情,曾经以为自己将会成为一个幻想中的产品经理那般大展身手,作为非计算机专业出身的应届生,后来才发现自己一直了解的都是业务产品经理牛逼的一面,并没有全面的看透产品经理这一职位。
但事实却是,产品经理,这个岗位在行业内没有明确的定义,所以其工作内容也是非常的广泛,SO,小白们,作为过来人告诉你(认真脸),不要以为你以为的产品经理就是你以为的那样(哈哈哈,绕口令来一发)
回归主题,题主就这么懵逼的成为了研发产品经理(好东西不会啊,55555····专业术语看不懂啊,5555···),不过我们始终要积极的相信,每一段经历都有它存在的价值,也必定会在未来的某一个时刻发挥其作用,所以,咱们还是脚踏实地的一步一步学习吧
![](https://img2018.cnblogs.com/blog/48590/201905/48590-20190516160355447-319157590.jpg)
在第一节中提到了研发产品经理最常接触的文档——PRD和原型,今天这篇文章就着重分享一些关于PRD文档的总结
一、PRD文档的三大核心作用
1、传达产品开发需求
2、保证各部门沟通有理有据
3、产品质量控制有具体标准
二、PRD文档的必备要素
1、命名、编号和时间戳
PRD的命名和编号很关键,因为每个产品都是经过若干迭代才完成,有时还会经过多人合作,所以命名和编号可以帮助我们知道该文档是哪个版本,到了哪个阶段
时间戳有助于文档修改时,多次传递中,我们区分文档是否是最新
示例:XX产品V1.0PRD_20160623_2006,意为在2016年6月23日20:06分修改的XX产品1.0版
2、PRD文档结构
2.1修订记录
PRD文档从创建到最终定稿,需要经过研发的评审,以及业务方的确定,所以在这个过程中经常会有一些改动,所以我们需要明确的记录下每一次的改动,以便清晰的了解整个需求的管理过程。
示例:
![](https://img2018.cnblogs.com/blog/48590/201905/48590-20190516160411562-720722222.jpg)
其中,版本号命名说明:V1.0.0
完整的版本号定义分三项<主版本号><次版本号><修订版本号>
主版本号——功能模块有大变动,比如增加多个模块或整体架构发生改变
次版本号——局部的变动
修订版本号——小部分的改动,或者BUG修复
2.2目录
目录用来了解文档结构,直接在文档中生成即可
2.3概要
需求背景:了解需求的起因,重要程度,面临的问题是什么。
需求范围:简要说明需求包括哪些部分,涉及关联系统、关联产品或者接口。
需求风险:完成需求可能遇到的风险和约束,包括产品风险,业务风险,运营风险以及技术风险。
需求来源:说明需求的来源,来源的负责人或者团队,业务方是谁,以便以后查看联系。
2.4功能需求
功能简要说明:介绍功能的用途
场景描述:说明该功能在哪些场景下会使用
业务规则:比如在京东的结算页京券和东券不可同时使用,这些业务规则可以说明,有助于测试、研发了解需求规则
界面原型:涉及页面交互过程,页面原型有助于研发,测试,设计理解
异常情况:网络异常,数据异常,功能异常以及产品的边界值等异常情况说明
2.5数据需求
我们做了什么功能,最终有什么效果,可以通过数据来体现,数据有助于更好的做出产品决策。
2.6性能
页面加载时间、数据缓存时间,功能响应速度等说明,便于研发对性能的优化。
以上是对PRD文档的分享,第三课会介绍原型的相关知识,感谢支持!
作者:芒果有点忙
链接:https://www.jianshu.com/p/405c338db868
來源:简书
简书著作权归作者所有,任何形式的转载都请联系作者获得授权并注明出处。