PRD修炼真经•卷一:一份标准化产品需求文档的逻辑思路

17 评论 115767 浏览 714 收藏 13 分钟

欲练此功,必先自宫。

本系列文章的宗旨是让大家从源头上理解PRD每个章节的内容,对内容的表达可以创新,但万变不离其宗。 enjoy~

写PRD时,你是否曾经做过以下的事:

  • 从公司研发规范文档中下载模版,进行内容填写;
  • 当不了解章节的内容时,直接写略或者删掉;
  • 在网上找到相似产品的PRD,对文章内容进行替换。

前几年我所在公司刚转型的时候,PRD管理比较混乱,很多产品经理常常使用上一个迭代,或者其它产品团队的PRD模版。把其中的内容进行替换,自作主张的删减,严重者只剩下“产品功能”这一部分。导致了很多需求要么没有可读性,要么又臭又长,甚至需求遗失,团队沟通成本极高,项目延期率居高不下。

这与其说是产品的偷懒行为,不如说是对PRD的理解不够,不得其法。

PRD的定位

我们知道,PRD是MRD的技术量化版,可以指导产品实现,是承上启下的重要文档。因此在产品实现过程中,PRD的重要性不言而喻。因此好的PRD文档,无论格式和内容如何演变,一体式也好,word也好,以下两个问题必定是明确的:

  • 在产品实现过程中,谁会看这个PRD;
  • PRD是否具备所有读者需要的内容。

所以,PRD的内容需要根据产品形态,项目组织形式等情况,做相应的调整。通常情况下,读者包含但不仅限于以下角色:产品总监、研发、UI、测试、相关产品团队(含硬件团队)、运营、客服。

PRD的结构

互联网敏捷团队,轻文档,重过程,对PRD形式没有特殊要求,最重要的是要合适你的团队,大公司的模版不一定适用小公司,小公司模版也不一定适合大公司。有得的队研发强,有的团队测试强,有的团队运维强,PRD要有所侧重;有得团队经过长期磨合,一个眼神,就知道你的隐性需求,PRD当然可以不写,但是你给别的团队用,可能要解释半天甚至返工。在团队磨合过程中,要形成恰当的PRD,需要对PRD的理解上有了一定的功底,才能写出最合适的PRD。

因此,本系列文章的宗旨是让大家从源头上理解PRD每个章节的内容,对内容的表达可以创新,但万变不离其宗

整体概览如下,后面会对每个章节分解说明:

基本结构

先从简单的说起,很多只重视“产品功能”的描述,对其它信息不重视,这是一种误区,特别是文档本身的基本信息。当文档涉及到跨项目,跨部门,跨公司,跨集团时,这些内容是很重要的。

封面

这部分是需求的门面,一定程度上可以展示公司和团队形象。

  • 公司信息:包含但不仅限于logo,名称,传真等,一方面提升公司形象,一方面便于联系
  • 保密级别:公开,普通,机密,绝密等,在一些游戏产品或涉及公司重大战略的产品,保密很重要。这同时也是一种免责声明。
  • 文档名称:xx项目/产品 PRD,我见到不止一次,A项目的文档写着B项目的文档名称
  • 文档编号:如果公司有要求则按公司要求,无要求则根据产品体系自行填写,文件名最好带上文档编号。
  • 文档编写人:编写人信息,包含部门, 姓名等,代表的是一种责任
  • 编写时间:一般为重要文档版本对外发布时间。

版本信息

又叫修改控制纪录,这部分就像软件的更新说明一样,表明文档与上个版本有什么区别。

  • 日期:版本的修改时间;
  • 版本:文档版本号,结构与产品版本号类似;
  • 版本描述:修订xx章节,新增xx章节,删除xx内容,让读者对文档变更内容有个大致了解;
  • 版本作者:该版本的编写人,便于沟通;
  • 审核人、批准人:根据实际项目变更委员会的组成情况,确定是否需要。

编制说明

一般情况下PRD文档都省略或合并了这个部分。我曾经参与过一个国家级的项目,当时由多个公司,n多专家共同编写,历时几个月,产品文档共有10个分册,十本纸质的加起来将近有30公分厚。编制说明用于说明文档编制的情况,互联网提倡小而美,快速落地mvp,不会有那么大的需求,所以大家会在背景或概要描述时顺便提一句。

  • 编制来源:描述因何进行编写文档。如:因什么政策,有xx公司牵头,xx公司参与,以什么为目标,展开本次工作。
  • 编制过程:描述文档编制的过程。如:x日成立工作组,x日组织了研讨,x日组织专家分析,x日正式启动编写。
  • 文档体系结构:用于描述本项目或产品涉及所有文档,如:xx综述分册,xx业务模型分册,xx需求规格分册,xx数据模型分册等。
  • 编制说明:用于描述当前文档的定位和边界,如:本文档负责是承接并叙述xx相关成果内容,起草单位:xxx。

目录和正文

目录:在修订文档后,更新域即可。一般情况下用不到目录,定位段落的时候用文档结构图比较方便。但是如果需要打印成纸质的项目,目录就必不可少了。

正文:PRD的主体。一般包含引言,概述,功能需求,非功能需求,环境。PRD的功力深浅,就在这体现了。

引言

引言即文档开头,是PRD正文部分的开始部分。

其作用是提供辅助读者深入理解整个文档所需的其它相关信息

背景

描述所说明的软件的应用,尽可能精确地描述所有相关的利益干系人。

  • 软件/产品名称:待开发软件/产品名称;
  • 提出者、开发者、用户:明确产品干系人;
  • 例子:xx产品,是由xxx与xxx合作项目,由xxx提出,由xxx承担开发人物,目前用户为xx项目的车主。

参考资料

列出有关资料的名称、文件编号、发表日期、出版单位、作者等,并说明参考文件的来源。

包含但不仅限于:

  • 经过核准的任务计划书
  • 上级机关批文
  • 项目相关的合同
  • 本项目其它已发表的文件,如:MRD、原型
  • 文中引用的其它文件、研发规范等

术语

列出本文件中用到的专业术语的定义和缩略语对照,便于理解,适用于接触新业务领域的团队。

概述

如果说引言是帮助读者理解文档,那么概述则是帮助读者理解项目和产品本身。

项目/产品描述

叙述该项软件/产品应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。

  • 应用目标:可以理解为产品要解决什么问题,如:针对xx状态下,无法进行xxx的情况,使xx产品可以通过xxx完成对xxx的工作开展。
  • 范围:明确产品边界,说明产品将干什么,不干什么。
  • 开发背景:为何要开发这个产品,一般情况下根据团队理解程度,节选BRD、MRD相关调研背景资料。

建议平时多与团队沟通探讨,不要把评审当做一种宣贯

系统模型

用于帮助读者理解系统整体结构,常用于向上汇报,帮助理解系统整体运作

(1)系统总体结构图

产品涉及的系统整体所处环境分解关系、各层次作用以及数据传递关系,便于理解各系统之间如何配合工作,各自边界是什么。

(2)网络拓扑结构图

系统所处的网络环境,用于理解各系统部署情况。帮助读者理解集群,负载,网络安全等相关信息,便于产品设计和相关决策。

这部分要求产品需要具备一定的技术能力。

假设和约束

指的是产品在实现过程中,必须满足的假设条件和所受的限制。这部分是被大家删减最多的部分。

(1)约束

这个比较好理解,就是影响产品的一些限制,比如:

  • 必须兼容的相关系统或硬件
  • 必须使用的语言,技术,或者通信协议,如java,dubbo,nginx,灰度,xmpp
  • 必须控制的成本,安全要求,保密要求。
  • 必须满足的完成时间,比如xx节日之前。

(2)假设

总有一些因素,不是产品的约束,但它们的改变可能影响到需求,比如:

  • 最终获取的经费预算满足xx条件
  • 某某技术的成熟度满足xx条件
  • 公司xx资源满足xx条件
  • 市场部或运营部具有xx能力

常见的运营需求也算是一种对运营的假设行为,此部分一方面有助于理解产品所需的资源,便于推进相关任务的进行,另一方面便于研发人员思考相关约束,减少后期返工和修改。

相关阅读

PRD修炼真经•卷一:一份标准化产品需求文档的逻辑思路

PRD修炼真经•卷二:一份标准化产品需求文档的逻辑思路

PRD修炼真经•卷三:一份标准化产品需求文档的逻辑思路

 

作者:小星星,8年互联网工作经验,5年技术,3年产品。

本文由 @小星星 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自 Unsplash,基于 CC0 协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 结合公司的信息化现状,看了此文受益匪浅,感谢大神~

    来自广东 回复
  2. 写得什么玩意~

    来自重庆 回复
  3. 我觉得挺好的,一个全面的产品经理需要知道一些技术层面的知识,因为涉及使用文档的角色比较多,感谢分享,学习了

    来自四川 回复
  4. 写的很不错,条理也很清晰,很受用。但是对于很多的公司都不太实用,写一份这样的文档对产品经理的功底是一个考验,其中涵盖的运营、技术、测试、商业等多个跨岗位的要求。产品写的PRD文档可以往这个方向靠拢,但不建议产品新人直接使用大的框架。

    来自广东 回复
    1. 确实是…新人刚开始把产品本身逻辑梳理清楚就不错了

      来自四川 回复
  5. 写的很详细,有学到东西。但是让我遗憾的是大部分程序员懒得去看篇幅很大的PRD

    来自上海 回复
  6. 对我来说很有用,谢谢。另外,系统总体结构图你是用什么软件画的,我找了几个软件画的没有你的简洁

    来自广东 回复
    1. 用word里的插入形状就可以完成

      来自日本 回复
  7. 感觉这是对外的文档吧

    来自福建 回复
  8. 太扯了吧

    来自福建 回复
  9. 求更

    回复
  10. 其实讲理论的类似文件 书籍 培训课程都很多 然后真正的讲解实际案例的确很少 希望业界的大牛们 在不方便讲解自己公司内容的情况下 可以讲解下其它公司的产品案例 这样对于我们这些初级的来说会更容易吸收

    来自北京 回复
  11. “先从简单的说起,很多只重视“产品功能”的描述,对其它信息不重视,这是一种误区,特别是文档本身的基本信息。当文档涉及到跨项目,跨部门,跨公司,跨集团时,这些内容是很重要的。”
    我没看出来你的文章哪里还包含了其他和市场、需求、行业、竞品有关的信息,都是搭建环境、技术规范、功能流程的内容,不愧是技术出身

    来自北京 回复
    1. 感谢关注,因为还没讲到你说的这部分,这部分会在(第二卷:功能需求)中的业务需求中展开讲述。

      回复
    2. 这个不是prd么,给研发人员看得。没做过产品的路过

      回复
    3. 有的时候MRD和PRD会合并为1个文档

      来自广东 回复
    4. 你可真扯

      来自重庆 回复