100次浏览 发布时间：2024-11-28 09:11:28
互联网产品逻辑复杂，为了保证从到开发到上线过程中，实施的没有偏差，大家协作时需要达成一致并且形成规范，我们经常听到1个词“需求”，这个功能没有按照“需求”开发，这个“需求”的标准就是PRD文档，本文总结了以下几点，供大家学习和参考：
PRD（Product Requirement Document），中文意思是：产品需求文档。它是对需求的具体描述，阐述产品具体要做成什么样子，要按照什么标准或规范来做而形成的文档。
在互联网开发团队中有这么几个角色：UI/UE、前端、后端、测试。产品经理设计完后，就需要刚提到的几个角色来具体实施落地了，首先大家要知道需求是什么？比如说做一个电商系统，公司为什么要做这个系统？这个系统具体要做成什么样子的？这些问题都要统一落实到文档，有依据，所以PRD文档的最重要作用就是——作为开发团队协作的依据！
不管前端还是后端都按照文档开发，要确保大家按同样的标准和需求来开发，开发同学如果理解上有歧义，有偏差时要依据文档，有疑问时，要第一时间跟产品经理沟通确认，这样才能顺利的进行后续的开发工作，同样，测试工程师写测试用例也要依据产品需求文档，因为bug的定义是“实际结果与期望结果不符”，期望结果是谁给出的？是产品经理，所以源头都是产品需求文档。
版本记录的目的是为了清晰的记录每次变更的内容是什么？什么时间发生的变更？以及提出变更的人是谁。因为随着产品设计及开发，需求会有微调或者改动，而需求变更次数太多的话，大家的信息获取有可能产生偏差，有人按照1.0做的，有人按照2.0做的，这时就要有“依据”，到底哪一版是最新的，最终定版是哪一版，否则会浪费开发资源。
任何实施团队在做的时候，都务必要明确大家在做的是什么产品/功能，为什么要做这个产品/功能，这个产品/功能解决什么问题，产品经理切勿把开发当工具人，只有让开发知道为什么要做，从内心认同这个产品时，才能保证后续的质量。
1）业务场景
产品是有很多功能/子功能构成，比如说“导入商品”，这就是一个功能，每个功能都是在特定的场景下来解决用户的特定的需求，比如导入商品，当用户首次使用系统，并想要批量新增商品时，就产生了这个诉求，“导入商品”这个功能就是在这个场景下解决用户的诉求的，它属于降本增效类的功能。写“业务场景”时，重点写在什么场景下，哪一部分用户产生了什么诉求或遇到了什么问题，系统功能是如何解决这个问题的。
2）需求说明
这部分是整个PRD文档中最最重要的，因为具体落地实施就是依据这部分，如果说前面的产品背景有些“虚”，那么这部分就是最最实际，开发最关心的，然后前后端和测试关注的点不一样，所以这部分务必要写的清晰明确全面，从这一部分能看出产品的基本功是否深厚，下面我们来具体说一下这里面要写什么。
（1）流程图
流程图有很多种，有数据流、有业务流程图、有交互流程图，有泳道图，这里根据公司的需要而定。注意，这里的流程图不是产品整体的流程图（因为整体流程图很复杂，且冗长），这里的流程是具体某个功能的流程图，重点是要把每个节点、判断条件、后置结果写清楚，没有逻辑错误，要闭环。
（2）E-R图
E-R图即是数据对象之间的关系，1对1、多对1、多对多。写这个的目的是为了让后端建表和字段的时候有依据，比如一笔订单多次出库，那么订单表的1条数据就可能对应出库表里面的多条数据。
（3）名词解释（定义）
产品在设计需求时，经常会自己定义一些概念，这些概念需要有明确的定义，比如“审核中”状态的具体定义，再比如“过账”的含义，这些名词第一次出现在开发同学眼里时，他们是不知道的，只有产品自己知道，所以需要明确的写出来，避免开发产生歧义。
（4）交互说明
写“交互说明”主要是给前端同学看的，比如一个下拉框，它默认选中什么，有哪些枚举值，字数最多显示多少，超出显示不下怎么处理，有没有禁用状态，鼠标悬停和点击分别是什么效果等等。
（5）各种情况枚举
这部分比较考验产品经理的全面思维和经验，很多产品同学设计完产品后可能会有遗漏，不是漏了这就是漏了那，这样开发会不断地追问，主要就是没有穷尽各种情况，而这部分也是测试关心的，因为测试要把99%的场景/情况都测到，才能保证上线后没有bug，比如商品下架在前端怎么展示，商品删除了在前端怎么展示，商品没有库存在前端怎么展示等等。
下面作者以一个简单的商品列表为实例，简单展示下需求说明怎么写
（6）实例：商品列表
需要文档模板的可以留言。
4、非功能需求
非功能需求主要包括了性能需求、安全性需求、其他合规性需求等等。