产品|征服开发测试的B端PRD文档是怎样写成的( 二 )_体系|积分|用户|产品|老用户

3. 方案概述写完业务场景就要写方案概述，主要就是用产品语言概述上面的问题是怎样解决的，这个需求涉及到哪些业务模块、涉及到哪些核心逻辑。
这样宣讲需求时开发凭此就可判断是否与自己有关系了，就不会出现“某开发参加需求评审个把小时却发现自己不需要做啥，然后耽误了敲代码的时间搞的晚上又要加班”。而且开发主管也可以根据这个方案概述就能判断出来需要给什么样的开发资源、开发周期。
4. 业务流程写完方案概述开发测试只知道要干什么，但是具体怎样做是不知道的，这时就要开始写业务流程，最好用泳道图写清楚各种判断逻辑、涉及的用户角色、业务模块等。后端开发看这个的时候，脑子里就会想数据流向、需要哪些接口、用哪张表。
业务流程就好像是开车时使用的地图导航、就好像是打仗时制定的路线图，对于B端产品经理来说“无论多么复杂的业务都可以用流程图表达出来”是基本的能力，这里我就不放按案例图片了。对于开发来说非常反感的一种B端产品经理就是“一个需求竟然画不清楚、说不清楚流程”。
5. 前端交互只有业务流程来表达一件事情的解决过程还是有些抽象，所以此时要用原型页面来形象表达，这块UI和前端会重点看需要做哪些增删改查页面、哪些交互，后端也会思考需要封装哪些接口给前端调用。
注意这里不是简单用原型工具画几个页面把链接抛给开发就行，而是要按一定的格式（条件、动作、页面、结果）写出每一个交互、每一个字段，具体可看下面案例。
有一种产品经理是非常让开发测试反感的，就是“需求的输出方式就是一个原型文件，点开后发现就基本的列表页、新增编辑页、详情页，其它逻辑靠猜”。
以我这样的方式写前端交互有个弊端就是比较花时间，最大的优势就是可以不漏掉每一个交互逻辑、每一个字段，下面我只是举了2个非常简单的例子。
1）列表页中的每一个字段名称、排序要写出来，以免遗漏

文章插图
2）新增、编辑页中的每一个交互，用“条件、动作、页面、结果”这一格式表达
6. 表结构这块目前市面上90%以上的B端产品经理都不会写，因为笼统地觉得这是开发的事情。如果产品经理能把这个需求需要设计哪些表、需要哪些字段、以及每个字段的相关信息都写出来，那么开发设计表结构的时候就可以借鉴、确认，这样开发真的会非常佩服你。
这块的基础就是产品经理要懂sql的基本查询语句，如果懂了真的是如虎添翼，写需求的时候能更加从开发的角度考虑问题了。以下案例中的每一列名称的使用，需要有一定数据库功底的产品经理才能掌握。

文章插图
7. 数据流向从哪个表取数据插入或更新到哪个表，用什么样的入参去请求哪个接口返回出什么样的值，这个开发是非常关心的。
开发敲的代码操纵的就是表，也就是说在开发眼中功能的本质就是数据的流向，而数据流向的载体是表和接口，数据流向是业务流程的技术理解。这块需要有一定数据库和接口功底的B端产品经理才写得出来。

文章插图
8. 评审问题在产品宣讲或开发过程中，开发提的一些重要问题的答案这里要记录下来，这样就方便其它开发看，也更能明确需求。特别是产品文档中没写的逻辑，在评审时开发发现了然后经过讨论后定下来了，就更加要写到这上面来了。
这块其实是对需求文档的一个查漏补缺，如果不记录那么也许过一段时间又会忘记这些重要逻辑，记录采取这样的格式就行“提出人、提出时间、问题、答案”。