初学的产品小白,你是否对产品经理的相关工作毫无概念,不知道别人常说的 PRD、需求文档是什么而苦恼?
还想要一个模版,学习和动手模仿一份,期待面试加分?
又或者你是一名已入职的初级产品经理,由于自学或培训入行,没有系统的产品知识,撰写的需求文档逻辑混乱、毫无头绪,还常常给领导各种挑剔、开发各种怒怼呢?
到底什么是产品口中的需求文档?什么样的文档才算是优秀的 PRD,构思时需要抓住哪些重点进行撰写?
作为资深的产品老油条,文档撰写 300+ 起,版本迭代更是数不胜数。写个 PRD 就和喝水那么简单,我想我可以分享一些经验给你~
更多文档撰写指南:
什么是需求文档
需求文档(Product Requirement Document)作为产品经理的必学基础技能,主要是用来承载当前版本的需求背景、产品方案、原型界面等内容的产品说明文档。
我常用的需求文档模版,一般由产品概览、产品结构、UML 相关、流程梳理、文档相关、消息推送、原型界面、功能交互、废纸篓等 9 个部分组成。
接下来,我们就对这些内容展开聊聊。
产品概览,主要包含了版本封面、版本日志、版本背景、更新内容等 4 个模块。
1. 版本封面
版本封面在需求文档的第一页,用于展示“项目名称、版本编号、版本开发时间、版本发布时间、版本相关负责人”等相关内容。
你说这封面有什么用?一般是用来装 B 的,显得文档规范高大上,提升团队成员参与感~
2. 版本日志
撰写版本日志,主要是为了让相关需求方了解版本的迭代过程,以及帮助其了解版本的更新内容。
所以版本日志的撰写需要通俗易懂,避免通过系统视角,对更新内容进行生硬的描述。
(悄悄告诉你~现在为了偷懒,都用 ChatGPT 自动生成版本日志了,还别说效果真的顶!)
版本日志还有一个作用是,你可以翻看之前的迭代内容,为数据分析提供依据。
3. 版本背景
版本背景可以说是文档的说明书,它明确告知了读者当前版本的开发目的和必要性。
版本背景的内容,一般包含“版本背景、版本目标、需求说明、相关功能”等几个部分。
什么情况可以不写?
- 你领导;
- 懒得写。
4. 更新内容
更新内容一般是给相关开发人员看的。主要指出当前版本的关联需求有哪些,让前后端知道开发范围。
你说版本迭代那么快,每次都要写更新内容,太麻烦了不写行不行?
当然可以,只要你能忍受这些:
- 开发阶段前后端同事轮番轰炸你微信,问你这次开发内容是啥;
- 当你打开尘封已久的文档,由于不清楚当时迭代了什么,又因为涉及内容太多,而要梳理相关规则时,一脸懵逼生无可恋,简直无从下手。
产品架构分为了产品结构、功能结构、页面结构等三个部分。
- 产品结构:主要呈现一个产品或系统的模块分布;
- 功能结构:以一个功能或模块为主题,展示该功能的组成;
- 页面结构:描述一个版本的相关页面及页面之间的从属关系。
说实话,由于团队版本迭代的节奏较快,我基本上文档内已经很少附上这些内容了。
除非是在进行新系统设计、年度规划、系统重构等情况时,我才会花点时间构思产品结构。
所以,你可以视实际情况,考虑删减部分。
UML 的模块包含了类图、用例、状态图、活动图、时序图,我一般用的比较多的是类图和状态图。
- 类图:主要用来呈现不同对象、对象之间关系的一种模型;
- 状态图:描述一个对象在周期内,相关状态及其变更条件的过程。例如一个电商订单从待付款到已付款的变化。
有童鞋就问了,UML 是啥东西听都没听过,是不是和技术相关阿?那技术的东西我又不是开发,学来干啥?
UML 是一门图形语言,它代表了面向对象的思想,我曾经就踩过不懂 UML 的坑,说多了那都是泪。
感兴趣可以看:《3 本进阶产品必备书籍,带你快速入门 UML 建模》。
该模块主要针对于“业务、功能、页面”等相关流程进行系统梳理。
- 业务流程:一般描述某业务涉及的各个角色、规则和环节等关系,帮助产品深入思考业务场景;
- 功能流程:研究主体为一般为某个功能,并梳理出该功能涉及的相关系统条件和流程变化等;
- 页面流程:指的是作为用户进行某些操作时,相关的页面跳转过程。
作为初级产品,入门时一般会进行功能级的设计(例如一个动态发布功能),这时候需要你掌握“功能流程图、页面流程图”的基础绘制,辅助理清设计过程中将遇到的各类问题。
当积累了不少功能设计经验后,你可能会接到一些业务优化的需求,而业务优化的前提是完全理解业务场景。
通过针对某个具体业务,绘制相关的业务流程图,便能帮你搞清楚业务难题和优化方向,从而辅助相关功能设计落地。
文档相关模块,用来存放一些概念说明、数据相关等内容。
具体有“版本排期、名词解释、角色权限、全局说明、数据实例、数据埋点”等。
- 版本排期:当一个业务需求较复杂时,我们会将功能模块拆分为多个版本,此时就要进行多版本排期,以供需求方参考;
- 名词解释:对系统、业务名词进行解释,帮助读者快速了解、掌握相关概念知识;
- 角色权限:定义不同角色在系统中的操作权限;
- 全局说明:对系统的设计规范、规则要求进行统一说明,确保相关人员理解;
- 数据实例:针对某些数据表,进行数据模拟,提升读者对相关功能的进一步理解;一般涉及数据创建的需求,也可以在该模块说明,用作部分功能的自定义配置;
- 数据埋点:如版本涉及数据跟踪和数据埋点要求,可在此进行补充。
这个模块的内容,可视具体情况酌情删减。
并非每个版本文档都需要这么细的规则说明,有些小版本仅需“全局说明”就够了。
消息推送的类型主要有:短信、邮件、APP 推送、订阅消息、模板消息等。
消息推送主要告知开发,当前版本涉及的消息内容、消息规则,及其他推送的注意事项。
有些时候对旧推送改版的时候,作为产品文档的撰写人也会回顾,以便于进行规则迭代。
试想下,如果你手上负责的系统,当前的推送规则包含了好几百条,而又没有相应的文档留存写明推送规则,这时你该提桶跑路呢还是提桶跑路呢?
所以,建议你有精力的话可以做个消息推送的总文档,以便应对上述场景发生。
原型分为高保真原型和低保真原型,如果不需要演示给客户看,我建议你为了工作效率(偷个懒不过分吧~),绘制低保真原型就可以了。
一些常用的原型界面有:异常页、结果页、对话框、原型页。
- 异常页:用于存放部分页面的异常状态,例如“搜索商品为空、订单列表为空”等;
- 结果页:当用户完成某项操作后,展示的操作结果页面,例如“订单交易完成”;
- 对话框:将当前版本的所有对话框提示,单独存放在一个“对话框”页,以便开发便捷查询;
- 原型页:指具体的版本功能涉及页面。
功能交互模块,一般撰写版本迭代中,涉及相关功能的交互规则。
例如”用户注册“的功能流程,就可以用”用户注册交互“的单独页面进行撰写。
交互一般可分为动态交互和静态交互。
动态交互,顾名思义即包含了自动化或触发式的一系列变化的交互效果。
而静态交互,是指将这种动态交互效果,通过一张张页面、组件铺开组成的交互流程图。
有些人就要问了,为什么要用静态交互呢,使用动态交互不是更酷炫吗?
沟通的本质,是减少信息差。——好夕雷
文档本质是一种沟通方式,需要方便开发查阅和理解。
如果使用动态交互,一个稍微复杂的交互效果,做的人效率低不说,查阅的开发同事,要重复点击多少次,才能完全理解其中的逻辑,换我也崩溃~
所以,使开发一目了然、快速抓住交互重点才是文档的核心,那么静态交互在这种情况,就成了最优解。
废纸篓,顾名思义就是放一些已废弃、暂时不用的文档内容。
一个版本文档内,一般涉及到新逻辑变更,我的习惯是顺手复制一份放入废纸篓,兴许变更内容不理想,还可以从废纸篓中恢复当前文档内容。
需求文档作为产品的基础能力,本质是一种沟通工具。
它主要用来承载产品方案、原型界面等内容,一般有 9 个部分:产品概览、产品架构、UML 相关、流程梳理、文档相关、消息推送、原型界面、功能交互、废纸篓等。
每个模块都有特定的作用,撰写时要注意规范性、易读性,前后端查阅时,才不至于怼你太狠~
随手点个赞,谢谢你喜欢~
复制本文链接 文章为作者独立观点不代表优设网立场,未经允许不得转载。
热评 bling~