这可能是最好的PRD文档写作详细说明

产品和开发之间的矛盾人尽皆知,其中一个核心问题就是——PRD写得不够好,于是开发过程非常不顺,导致产品和开发不断撕逼。

当时刚做产品经理时,也为此颇为烦恼。虽然大学时学过C++和Java,但对技术的理解有限,当时还难以写出合格的PRD。

紧接着,我就和很多产品新人一样——到网上到处搜PRD该如何写,搜了一堆模板、一堆文章。

但紧接着我们会发现——并没有人给出一个足够实用的PRD详细说明,让我们能直接在工作中应用,并能保证开发过程顺畅。

到了现在,我终于能给出一份比较实用的PRD详细说明了。果然打是亲,骂是爱,感谢那些曾经怼过自己的开发们。

有了这份PRD文档写作详细说明后,有什么效果?

一位开发评价:按照你上次的PRD文档,以后就不是开发怼你,而是你怼开发了

一位测试评价:我感觉PRD文档写成这样,以后就不用需求讲解了("需求讲解"特指开发之前的讲解,便于开发熟悉需求)

一位面试官评价:你是我面试过的产品经理中,一个难得的合格的产品经理,你要感谢那些怼过你的开发们

确实如此。只要每次都按照这份详细说明来写PRD,开发过程就很顺畅。而如果有不顺畅的地方,往往是忽略了详细说明中的部分内容。

那么这份详细说明是怎么来的?

很简单:不断地被开发怼

在被开发怼了将近1年后,在接触了6个开发团队后,我收集了足够多的开发怼我的注意点,以及过程中的不断完善,梳理出了这份详细说明。从此之后,一切就变得很顺畅。

下面就来具体讲解。

1.基本注意点

1)不同团队需要不同的PRD

PRD是给开发、测试看的,本质上也是一个产品,产品的用户就是开发和测试。

因此,一个最基本的原则是:根据不同团队的具体需求,给出不同的PRD

是的,PRD也不是一招鲜吃遍天。当你接触的团队足够多,你会发现不同团队对PRD的要求有很大差异:

有的团队需要非常详细的说明——一般是比较成熟稳定的开发团队

有的团队只需要原型图足够准确,需求描述部分很少——这就需要在开发过程中不断沟通

有的团队注重你对需求的深入理解,而不是PRD本身的描述是否足够详细——一般是创业团队

所以,PRD到底要写到什么程度,最基本的原则就是看团队的具体需求。

2)一些注意点

另外,还有一些注意点:

这份PRD详细说明主要针对业务类产品——因为这份说明来自实际工作经验,笔者没做过AI、大数据、区块链等高新技术产品,更多的是业务类产品

这份PRD详细说明非常详细,但不代表你的PRD就要这么详细——如上面所说,不同团队需要不同的PRD。但你的PRD可以比较简略,但对功能的思考上要考虑到这份详细说明中的内容,以避免开发过程的不顺畅。

这份PRD详细说明只针对功能的技术可行性,不针对需求的合理性——这是PRD的核心目的,需求的合理性可在其他阶段考虑

2.PRD文档写作详细说明

先说明一下:一些基本的PRD模块我们就不说了,比如「历史版本修改记录」、「需求背景说明」这些人尽皆知的部分。我们只讲PRD最核心的部分——对各个功能应该如何描述才足够准确、详细

至于其他模块,我们在文末放一个链接,大家自行下载即可,看一眼就懂了。

1)取值规则

取值规则即产品前端/客户端的字段取的是对应的什么字段。

我们以「人人都是产品经理」APP首页为例。

比如下图的banner部分,取值规则就是这些banner的图和标题取自哪里?

一般来说,banner部分的图和标题都在后台配置,因此你就可以写成:

banner图片:取值后台字段XX

banner标题:取值后台字段YY

PS:建议写出后台的具体字段,否则时间长了,字段就乱了,下次你想知道前后端的对应关系时,还得找开发查半天。

当然 ,取值的来源可以不是后台某字段,比如:

前端用户操作的数据——比如用户点赞次数

某几个字段综合计算后的结果

符合特定条件的某字段——比如取值后台字段 [状态] 的值为"显示"的字段XX

……

这些在实际工作中会有变化,核心是得想清楚前端/客户端的字段,其取值的对应字段是什么。

2)显示规则

显示规则即与显示相关的规则

以下图banner部分为例,显示规则要考虑:

取值数据为空时如何处理——例如banner的图片对应的后台字段为空,此时如何显示?

显示数量——banner的图片要显示几张?超出数量限制时如何处理?banner的标题要显示多少字?超出数量限制时如何处理?

显示格式——比如标题是靠左还是居中还是靠右?如果是数字,比如时间,是要显示成12小时制还是24小时制?

排序规则——banner的图片显示的先后顺序如何排序?是按照后台的某个字段排序?还是按照其他规则排序?

3)交互规则

交互规则为将对应的交互设计描述出来

比如下图的banner部分,至少要考虑:

自动轮播的时间间隔

左右滑动时的交互效果

点击后的交互效果——比如点击后进入XX页面

4)默认规则

对一些默认情况的说明。

默认的取值规则:默认取值xx,当xx为空则取值yy

默认的显示规则:默认显示xx,当....则显示yy

默认的交互规则:导航栏,默认选中某个标签——比如上图的首页部分,底部TAB默认选中的是「阅读」,顶部导航栏默认选中的是「文章」。

其他的默认情况说明

5)边界情况

对各种边界情况的考量,防止出现异常

比如:

取值规则:被取值字段为空时如何取值?

显示规则:

 当没有内容时如何处理——当前页面没有任何内容时显示什么页面?当前字段没有任何内容时显示什么内容?

当数量巨大时如何处理——列表显示数量过大时可能影响性能,要与开发协商处理措施。

时间显示格式——如显示时间区间格式:若开始时间和结束时间为同一天,那么是否只显示一个时间即可?

交互规则:

操作次数限制——是否要限制?如要限制,限制多少次?达到上限后如何提醒?比如输入密码错误达到上限后,就要冻结一段时间。

输入内容限制——是否要限制?如要限制,限制多少次?达到上限后如何提醒?比如输入手机号码限制11位数字,超过后如何处理?

返回按钮——若上一个页面为空,则返回哪里?

提示——提示多久消失?比如toast提示,是否3s后消失?

编辑——是否可编辑?涉及到编辑时,要描述清楚编辑成功后的交互。比如保存后是否要刷新页面。

……

异常情况:出现异常时如何处理?

没有网络/网络异常——此时显示什么?

服务器忙——此时显示什么?

产品下架/页面被删除等——此时显示什么?

比如恶意评论、恶意刷分等——此时显示什么?

几个不同状态的综合考虑:

登录/未登录——例如未登录状态下不能点赞

有权限/无权限——例如无权限时是否显示?交互如何?

……

版本兼容考量——如果是APP,不同版本之间的兼容需要考虑,web端一般不需要考虑这块

以上是PRD要考虑的核心部分,是站在开发角度的考量。

当然,由于例子有限,以上内容并不完整(如下方列举了一部分),所以整理一个思维导图下载链接,大家参照即可。

比如APP端、小程序端、web端各有不同,各自有各自的注意点

比如流程上的注意点,如需为设计考虑,可以标注清楚这个版本涉及的更改内容,这样设计就能更快地知道自己该设计哪些地方;还应该给出可复制的文案,否则设计得自己输入对应内容等等

比如与线上功能一致的,尽量沿用线上已有的功能,这样便于开发,可降低开发成本,此时最好还说清楚线上功能所在的位置,便于开发找到对应的功能

对于关联性较强的数据,开发难度往往更大,此时应更多地考虑性能

如果更改频率低,写死比在后台添加更好

可以把通用的功能全部收集起来放在一个文档中,这样后续用到对应功能时,可以直接给出链接,让开发看之前的文档描述即可

……

PRD文档写作详细说明、PRD模板:

链接:https://pan.baidu.com/s/1tVhJ6A6On3TFE0lGHO3-TQ

提取码:smu7

推荐阅读更多精彩内容