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

　　你是否有过因为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后消失？
　　编辑：是否可编辑？涉及到编辑时，要描述清楚编辑成功后的交互。比如保存后是否要刷新页面。
　　异常情况：出现异常时如何处理？
　　当没有网络网络异常时，显示什么？
　　当服务器忙时，显示什么？
　　当产品下架页面被删除等时，显示什么？
　　被恶意评论、恶意刷分等时，显示什么？
　　几个不同状态的综合考虑：
　　登录未登录：例如，未登录状态下不能点赞。
　　有权限无权限：例如，无权限时是否显示？交互如何？
　　版本兼容考量如果是APP，不同版本之间的兼容需要考虑，web端一般不需要考虑这块。
　　以上是PRD要考虑的核心部分，是站在开发角度的考量。
　　当然，由于例子有限，以上内容并不完整（如下方列举了一部分），所以整理一个思维导图下载链接，大家参照即可。
　　比如：APP端、小程序端、web端各有不同，各自有各自的注意点。
　　比如：流程上的注意点，如需为设计考虑，可以标注清楚这个版本涉及的更改内容，这样设计就能更快地知道自己该设计哪些地方；还应该给出可复制的文案，否则设计得自己输入对应内容等等。
　　比如：与线上功能一致的，尽量沿用线上已有的功能，这样便于开发，可降低开发成本。此时最好还说清楚线上功能所在的位置，便于开发找到对应的功能。
　　对于关联性较强的数据，开发难度往往更大，此时应更多地考虑性能。
　　如果更改频率低，写死比在后台添加更好。
　　可以把通用的功能全部收集起来放在一个文档中，这样后续用到对应功能时，可以直接给出链接，让开发看之前的文档描述即可。
　　PRD文档写作详细说明、PRD模板：
　　链接：https：pan。baidu。coms1tVhJ6A6On3TFE0lGHO3TQ
　　提取码：smu7