快好知 kuaihz订阅观点

 

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

欲练此功,必先自宫。

本系列文章的宗旨是让大家从源头上理解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修炼真经•卷三:一份标准化产品需求文档的逻辑思路

本站资源来自互联网,仅供学习,如有侵权,请通知删除,敬请谅解!
搜索建议:真经  真经词条  标准化  标准化词条  修炼  修炼词条  逻辑  逻辑词条  思路  思路词条