get这份PRD文档写作说明,让你有底气怼开发

17 评论 24612 浏览 248 收藏 13 分钟

你是否有过因为PRD文档写得不够好,而被开发怼的经历呢?这里一份详细的PRD文档写作说明,get这份说明,你的开发过程将会很顺利。接下来,就让笔者为我们讲述如何写好一份PRD文档吧。

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

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

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

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

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

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

  • 一位开发评价:按照你上次的PRD文档,以后就不是开发怼你,而是你怼开发了。
  • 一位测试评价:我感觉PRD文档写成这样,以后就不用需求讲解了(“需求讲解”特指开发之前的讲解,便于开发熟悉需求)。
  • 一位面试官评价:你是我面试过的产品经理中,一个难得的合格的产品经理,你要感谢那些怼过你的开发们。

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

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

很简单:不断地被开发怼。

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

下面就来具体讲解:

一、基本注意点

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

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

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

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

  • 有的团队需要非常详细的说明——一般是比较成熟稳定的开发团队。
  • 有的团队只需要原型图足够准确,需求描述部分很少——这就需要在开发过程中不断沟通。
  • 有的团队注重你对需求的深入理解,而不是PRD本身的描述是否足够详细——一般是创业团队。

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

2. 一些注意点

另外,还有一些注意点:

  • 这份PRD详细说明主要针对业务类产品。因为这份说明来自实际工作经验,笔者没做过AI、大数据、区块链等高新技术产品,更多的是业务类产品。
  • 这份PRD详细说明非常详细,但不代表你的PRD就要这么详细。如上面所说,不同团队需要不同的PRD。但你的PRD可以比较简略,所以,对功能的思考上要考虑到这份详细说明中的内容,以避免开发过程的不顺畅。
  • 这份PRD详细说明只针对功能的技术可行性,不针对需求的合理性——这是PRD的核心目的,需求的合理性可在其他阶段考虑。

二、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后消失?
  • 编辑:是否可编辑?涉及到编辑时,要描述清楚编辑成功后的交互。比如保存后是否要刷新页面。
  • ……

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

  1. 当没有网络/网络异常时,显示什么?
  2. 当服务器忙时,显示什么?
  3. 当产品下架/页面被删除等时,显示什么?
  4. 被恶意评论、恶意刷分等时,显示什么?

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

  • 登录/未登录:例如,未登录状态下不能点赞。
  • 有权限/无权限:例如,无权限时是否显示?交互如何?
  • ……

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

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

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

  • 比如:APP端、小程序端、web端各有不同,各自有各自的注意点。
  • 比如:流程上的注意点,如需为设计考虑,可以标注清楚这个版本涉及的更改内容,这样设计就能更快地知道自己该设计哪些地方;还应该给出可复制的文案,否则设计得自己输入对应内容等等。
  • 比如:与线上功能一致的,尽量沿用线上已有的功能,这样便于开发,可降低开发成本。此时最好还说清楚线上功能所在的位置,便于开发找到对应的功能。
  • 对于关联性较强的数据,开发难度往往更大,此时应更多地考虑性能。
  • 如果更改频率低,写死比在后台添加更好。
  • 可以把通用的功能全部收集起来放在一个文档中,这样后续用到对应功能时,可以直接给出链接,让开发看之前的文档描述即可。
  • ……

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

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

提取码:smu7

#专栏作家#

万能的船长,公众号:PMWang,人人都是产品经理专栏作家。一个做产品的人。

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

题图来自Unsplash, 基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 怎么过期了呀

    来自北京 回复
  2. 打开后都是空白,如果没猜错,笔者应该是技术出身

    来自浙江 回复
    1. axure文档是空白是吗?这个故意的话,我觉得形式不太重要

      另外,我就是产品出身,没做过开发

      来自浙江 回复
  3. PRD文档写作说明,这份文件打开是空白的。

    来自福建 回复
  4. 感谢分享,不过axure9下的分享文件很多看不到- -, 思维导图666

    来自广西 回复
    1. 原型里面没列啥,就是个目录
      核心思路都在文章和思维导图中了,这是关键

      来自安徽 回复
  5. 分享模版看不到了!

    回复
    1. 我看还是有的呀

      来自浙江 回复
  6. 受益匪浅 谢谢

    回复
  7. 提取码错误呀

    来自江苏 回复
    1. 试了一下,还是OK的,你再看看

      来自浙江 回复
  8. 写的太棒了,思路非常清晰

    来自上海 回复
    1. 血与泪的总结都是

      回复
  9. PRD模板的rp文件,里面为什么没有内容呢

    来自北京 回复
    1. 侧边有一点点,就是PRD常用模块的说明。
      核心还是那个思维导图,按照思维导图中的内容思考,写在「详细功能说明」中就行。

      回复
    2. 很感谢您

      来自北京 回复
    3. 血与泪的总结,工作中多用啊

      回复