写一份普普通通的PRD

郑重声明:本人讲课的所有资料、内容、图片、文件皆为本人亲自制作,绝对不会拿别人甚至公司的内容来直接宣讲,这是一个职业操守的问题。

先抛个话题:1、很多的产品经理给别人的印象就是开会,写文档,画个图型。2、PRD有没有必要输出,以及如何输出。还是说我们可以直接采用MVP的模式,口头定义需求和界面样式,然后让设计和研发输出。优点是速度快,执行力高,有效输出。缺点是很多事情会即兴而决定,不统一不规范,并且有熟悉的人离开后,新人补缺很难。

那么问题了:明确产品需求文档的目的产品需求文档需要具备以下三种功能: 和团队成员高效沟通,用他们能够看懂的方式清晰地表达你的想法,让他们清楚什么该做什么不该做; 记录之前的问题是如何解决的; 明确列出产品功能的短期目标、长期目标,绘制一个从短期到长期的产品蓝图。

PRD是产品最常用的工作职能之一,另外一个就是原型。那么一份PRD是要写到什么程度,写出来什么内容,写到多少才算是合适的?还一个,合适就好还是优秀好,还是普普通通的就好?

作为一个初/中级产品经理,我的建议就是普普通通的就好。首先,你并没有那么多的时间耗在PRD上,其次需求的变动会导致你的PRD跟不上你变更的频率,最后PRD只是产品最常用的工作职能之一,还有其他的原型,调研,沟通,背锅这些任务需要你去做,不用吃饭呢?不用睡觉啊,不用撩小姐姐啊~

这里说的初/中级的概念是指高级产品经理也用写PRD,但是概要的描述,更多还是做产品规划、执行、未来发展方面的工作。

PRD是功能需求文档,是讲功能内容,尽可能的使用方便理解描述,不要出现拟人词,并尽量用开发者角度去考虑。

那么我们该如何去写一份普普通通的PRD呢?常规我们写PRD有两种方式:WOR写和原型写(以微信来举例)

一、Wor写PRD

Wor写PRD其实是用Wor+截图的方式来完成。常规的产品基本都采用这种方式,至于是不是还需要截图,根据习惯来定(主要是我一般不截图,因为会比较麻烦,一次定义一个栏目,一个栏目最少最3张图,一截图Wor一页就没有了。还一个,我们的屏幕真的没那么大,你的图小了放在上面就是看个轮廓而已)。

先列目录:我一般写PRD包含简介、产品概述、产品说明这三个模块,如果要写到详细我会设定概述、产品综述、功能性需求、非功能性需求、附件五个模块(两个文档中的产品说明和功能性描述是一回事)。既然是写普普通通的PRD那我们就按照简单的来写。

1、简介:

1.1目的:目的很简单,就是告诉观看者,写这篇PRD是要说明什么。微信一个为智能终端提供即时通讯服务的免费应用程序,通过网络快速发送免费(需消耗少量网络流量)语音短信、视频、图片和文字。本文档针对微信V6.6.6版进行前台和后台(模拟)部分功能说明。

本文档清晰、有层次的说明页面各个模块的说明和相关逻辑关系。需交互、设计、前端、后台、测试人员仔细阅读,方便对微信V6.6.版进行完善开发。

1.2范围:说明范围,观看者对应的职责。对APP各页面功能布局,需设计、交互、移动端人员呈现效果,对页面中涉及到的功能点进行说明。文档中包含部分交互和后台功能要求。本文档中加粗、使用非黑色表现的模块需要重点突出,有设定说明的模块是有单独的交互和功能效果。

1.3软件角色分析:这里的角色是指使用软件的角色,不是公司内的岗位角色。

1.4名词解释:在此文档中会有一些词是通用,需要提前说明。例如我们使用C/S架构设计,这里就要说明关于客户端和服务器两部分的一些注意事项,例:客户通过数据请求与服务器,数据库管理系统与客户进行数据互通。功能实现需要后台写接口,移动端负责调用。

2、产品概述:概述我这里一般会用对该版本进行系统的说明表现,通过具体的内容让接触该文档的人能够清楚的明白涉及到的范围。

2.1UML(用例):用例的方式、方法很多,我这里简要画出来一种,大家理解一下。如果对用例很有兴趣,我可以专门拿这个来讲一次课程。

2.2流程图:流程图一般用的也比较多,这块说明一个整体闭环的对应内容。一般可以用两种方式来保险:业务流程图:

泳道图:

两种图都各自有优点和缺点,还和你的习惯有关系,更和你的领导习惯有关系,转变一下思路而已,并没有什么太难的。我更倾向于业务流程图而已。

2.3功能总览:说明本次PRD都有哪些模块/功能点,分别要做点什么,并且给一个优先级,我在这里还会习惯加一个备注。优先级我一般按照1234来定义,也有按照高中低来划分的这些都没什么太大的关系,看你习惯就好。重要的必须的就是1,重要不紧急的为2,紧急不重要为3,一般的为4。备注这里为特殊说明,就以修改密码为例:功能概述是管理员可在后台修改用户密码,备注是有权限的管理员才可以操作。这里我不单说出了功能,还对功能上赋予了权限内容。

3、产品说明:重中之重的内容来了,一个PRD写的好不好就在此处,甚至说前面都可以没有,只要此模块写好,一切就都很漂亮。以下我们以微信的收藏功能点来举例。

3.1需求名称:收藏功能。写出当前模块/功能点的名字。这里要把模块和功能点做区分,我一般都是按照模块来区分,如果模块下分多个功能,那这里还需要在拆分为二级目录。

3.2需求优先级:4.按照重要的是1,重要不紧急的为2,紧急不重要为3,一般的为4进行划分。

3.3使用渠道:在什么情况下使用。比如微信的收藏功能:别人/其它公众号/朋友圈发布的文字、图片、音视频等内容,用户需要收集在自己的名下。

3.4前置流程:已登录,当前内容允许被操作(收藏别人的内容被删除,该收藏不可见)。在操作这件事情前对应的条件,比如必须要登录(不登录微信也没办法用,这句虽然是废话,但你不写,研发小哥哥真的就不给你做判断)后才可以操作。

3.5业务主要流程:

3.5.1文字、图片:

A、文字和图片已经加载完成后,用户长按弹出提示框,用户点击收藏,页面下方弹出提示框“已收藏”和“添加标签”。已收藏不可点击,只是提醒用户用户该操作已执行完成。点击“添加标签”跳转到编辑标签页面。

C、长按弹出对话框:C.1转发:点击后跳转到聊天选择界面,可搜索/多选/单选给对应人,点击对方弹出发送提示框,可直接发送/取消,发送时可以留言。后退返回收藏页面,同时对话框取消。C.2编辑标签:C.3删除:C.4更多

D、标签(在这里要注意如果标签要单独写的话,这里到跳转就截止了,如果标签是在收藏下面的,那对应的标签内容也应该写出来。)

E、文字、图片被发布者删除后,收藏内也可查看。

3.5.2音视频:音视频在未播放的情况下也可收藏,操作同上。

3.5.3公众号文章:操作同上。

3.5.4朋友圈文章:操作同上。

3.6业务分支流程:业务分支流程是指主要流程以外的关联性内容。收藏的分支可以把上面的标签放在这里。在拿优惠券来举例,分支的流程还要退款、开票方面的内容。

3.7业务规则:只允许当前用户操作自己账号的内容(当前用户指登录后任意角色在手机上的的操作)。

3.8后置流程:收藏的内容在有网络/本地有缓存的情况下可直接查看。后置流程一般是指对应当前操作之后的事情。在比如我们是一个优惠券的模块,那么后置的流程我们还需要有对应前台生成页面。这里的前置和后置不一定是匹配,只是分别对应。

3.9备注:更换机器登录后,收藏内容会保持同步更新。移动端和PC端收藏保持同步。其它:适当的我们还可以在补充一些术语和缩写、参考资料等范围方面的内容,这些具体看自己的需求。

二、原型写PRD原型写PRD其实是用原型+标注的方式来完成。(因为懒,所以借用了产品大牛的模板,这是一个很好的网站,上面有很多别人做好的文件,可以观看有些还提供下载。)

原型写PRD的好处就是你在做好了原型,旁边就说明对应栏目及功能说明内容。

原型-标注

原型-触发效果后

原型-触发效果前

后台原型+备注整体效果

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180605G21WC100?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码关注腾讯云开发者

领取腾讯云代金券