PRD应该怎么写

入坑以来，对于PRD文档从满脑全是问号到现在已经写过无数份。但是一直未深度的思考，PRD文档到底应该怎么写。今天，趁着工作不忙，把自己的思考做一个记录，顺便奉上一份今日思考后的模板。

图片来自互联网

一、思考

1、文档的使用者是谁

2、文档要达到的目的是什么

文档的使用者是咋们的研发大佬，要达到的效果就是能够清晰明了的把我们要做的事情描述清楚，谨防因为沟通造成各自理解误差。

二、PRD文档内容

1.名称

名称=系统名称+版本

一个系统，从立项到发版看到会经历多次迭代，这时候带上迭代版本，对于后续一些小迭代也容易追述。

版本的命名规范：<主版本号>.<次版本号>.<修订版本号>，如 1.0.0

●　主版本号：当功能模块有较大的变动，比如增加多个模块或者整体架构发生变化。

●　子版本号：当功能有一定的增加或变化，比如增加了对权限控制、增加自定义视图等功能。

●　修订版本号：一般是Bug修复或是一些小的变动，要经常发布修订版，时间间隔不限，修复一个严重的bug即可发布一个修订版。根据打包的情况，修订版本号逐渐增加。

有时也可把日期列入版本号中

2.修订记录

记录对文档的操作，对于以往的情况，一般在评审会和实际研发中会遇到一些漏掉的逻辑或最初思考有误的地方，有对应的文档编辑记录，对于相应的需求变更有据可查。

3.功能结构图

基于对应的需求，整理出系统需要做的功能点

4.信息结构图

整理出系统中系统中所需的字段，程序员在建表时可以以这个为参考，避免漏掉一些字段，便于在后续功能模块的设计中复用相应的字段

5.整体流程图

这个流程图可以帮助研发清晰的了解系统主要的使用流程，便于后续做单功能时有个整体的概念，防止因为只看到点而做出一个思路都对，但是无法接入到整体流程的功能

6.产品结构图

产品结构图是结合功能结构图和信息结构图梳理出来的，是系统的雏形，后续的原型就急于产品结构图绘制

7.功能性需求分析

7.1系统概要

描述系统的背景、产品的定位、要做的事情等

7.2模块名称

7.2.1场景描述

基于实际场景的描述，让研发明白咋们做的事情运用的地方，让他们知道功能点设计的初心.....

7.2.2界面

7.2.3功能描述

包含规则、交互、字段的具体的介绍

....未完待续...