一份详细的产品需求文档撰写指南,结合实例,分析细致。在产品经
产品需求文档撰写教程
一份详细的产品需求文档撰写指南,结合实例,分析细致。
在产品经理的日常工作中,经常需要借助各类文档来和技术、设计等团队成员打交道。从需求收集到功能落地,一份合格的产品文档能够减少很多沟通成本,避免返工,帮助产品经理更好地推动项目进程。因此,写好产品文档是决定工作效率与质量的关键因素之一。
毋庸置疑,产品文档的撰写是产品经理的必备基础技能;虽说是基本功,但是能写出一份清晰简洁的文档,却非易事。想要写好产品文档,首先要进行反复的深入的思考,写文档不是目的,目的是将产品的思维和逻辑通过文档的形式表达出来。因此我们可以说,要想写好一份产品文档,就要进行一次有序而全面的思考。
一、 产品文档分类与差异
一般我们说的产品文档更多指的是PRD,其他常用的产品文档有BRD和MRD。那么这几个名
字相似的文档究竟有何差别,又分别会用在什么场景下呢?为了进行初步的了解,以下为常见文档的差异对比:
二、 PRD简述
PRD是产品文档中出现频率最高的一种。一般在需求收集完成,产品经理完成需求相关的业务逻辑、流程梳理后,开始撰写PRD;通过PRD将需求相关的业务流程、数据流向、页面交互等信息清晰地展现出来,作为技术开发评审需求和进行功能开发的依据。根据不同的产品类型,PRD包含内容和侧重点各不相同。但是核心在于,完整表达产品经理对于该产品的功能的逻辑、页面以及所有需求的有效表述,有效表述的标准是,技术人员能理解并借助PRD完成开发。
PRD对于产品经理而言最大的作用是沉淀信息,同时也是在产品迭代过程中的需求记录;对于技术而言是开发的依据,是一份“书面化”的任务工单。一般PRD都是word文档形式居多,但是也可以用AXURE等工具来展现。
既然PRD是产品经理与技术之间沟通的桥梁,那么这座桥梁就应该是双方共同搭建。技术将
自己的理解与开发习惯同步至产品经理,产品经理根据技术的理解、习惯形成针对性的PRD,减少沟通成本,增强PRD 的可读性与价值。
三、 PRD内容详解
对于入门的产品新手而言,“模仿是最好的学习方式之一”。需求文档虽说没有标准化的模板,但是在表述清晰简洁的基础上,一般可将需求文档的结构分解下:
文档信息一般包含文档与撰写人的相关信息,包含但不仅限于文档名称、文档版本、撰写人信息(手机、邮箱、部门等)、文档修改记录等信息。文档名称与版本可帮助产品经理更好地管理和使用文档,撰写人信息可供文档阅读者有问题时及时反馈至撰写人,文档修改记录尤其重要,一方面可帮助技术人员快速分辨出最新版本文档的修改点,减少无效阅读时间;另一方面可帮助产品经理在版本迭代过程中进行文档管理。
需求总览一般可用需求表格形式展现,内容包含但不限于需求分类、需求简单说明、优先级、技术对于需求的分解、排期等。需求列表不但可以对整个文档的需求做一个完整的统计与整理,在需求范围未确认前,还可作为需求初评的依据。若是单个需求如活动需求,可将活动流程作为需求总览进行展现。
具体的需求说明需要根据需求的类型进行定制化的说明,一般可能包含页面说明、交互说明、数据来源说明等方面。页面说明主要阐述页面包含的元素和模块,以及各模块分别满足的需求。交互一方面要说清页面的业务流程与逻辑,另一方面要结合设计图与交互稿对页面的反馈、焦点等交互逻辑进行说明。数据来源主要说明该功能的接口逻辑,数据流程以及后台相对应的编辑功能等。
页面设计说明四、PRD的迭代
每个产品经理都应该有自己的PRD管理库。一方面是针对同一个产品在不断的迭代过程中的各项功能、页面的优化、升级情况有一个全面的统计和沉淀;另一方面,当一个产品经理同时负责多个产品或者多个模块时,PRD管理库能够帮助产品经理更好更快地形成自己的文档撰写风格,发展处一套属于自己的PRD撰写方法论。
五、PRD实例说明
经过以上对PRD 的介绍说明,我们已经能对PRD有一个初步的了解和认知。那么在何种场景下我们会用到PRD?PRD在现实的产品工作中应该如何撰写?让我们以某抽奖活动的需求为例,来讨论下实战中的PRD。
版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198,我们将在24小时内删除。
发表评论