初学的产品小白，你是否对产品经理的相关工作毫无概念，不知道别人常说的 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 相关、流程梳理、文档相关、消息推送、原型界面、功能交互、废纸篓等。
每个模块都有特定的作用，撰写时要注意规范性、易读性，前后端查阅时，才不至于怼你太狠~
随手点个赞，谢谢你喜欢~
复制本文链接 文章为作者独立观点不代表优设网立场，未经允许不得转载。
好夕雷
9.7w人气 6文章
热评 bling～