引子
这篇入门指引适合与不是特别了解PRD文档写作规范和写作要求的初级（或中级？）产品经理以及其他需要写PRD文档的人员。
鉴于目前写PRD文档的文章实在是过多，看着实在是太累，所以，这篇文章尽可能会将写文档这件事情描述的更加简单和易读一点。所以，小桃红，给诸位斟茶~
唉，原本还想写的严肃一点，看起来三句话就容易跑偏，又要被人骂废话过多了，咳咳~
那就话不多说，进入正题。
为什么写这篇文章
最近发现，我居然没有教我司小朋友们如何写一个比较完善的PRD文档，我仔细的想了想，好像真的是忘记了哎……虽然他们都已经写的挺好的了，但是感觉还是有必要系统的讲解一下。
原本还想偷个懒，网上找点好东西震一震他们，让他们也看清楚，产品想写好文档也是需要花费大功夫的。但也真是尴尬，翻了翻网上所有些PRD文章的，要么写的过多，实在是看不下去。要么是随便写两个关键点，然后没了的。。。要么是不知所云的。。。要么是有框架，没细节的。。。要么是专讲某个细节的。。。请原谅我读书少，我是真的没太看得上大多数文章。（我艹，会不会太拉仇恨……）
不过也看到了一些写的很棒的文章，规范一套一套的，还有各种模板，我就尝试着下载了一下，看着80页的长度，我默默地关闭了文档……
原来我所期望的，和别人给的，终究还是不一样的，然后就不得不自己挖个坑，自己来填了……也是挺佩服自己，当年自己是怎么搞懂的这么一整套PRD文档的逻辑……
当然，作为一个小产品，水平也有限的很，就按照自己的思路和认知写一写吧。也不一定好，但是如果能给你们带来一丝丝更多的认知，也算是物有所值。（内心独白：不用太感动，反正也不是为了你而写的~）
当然，大公司一般都有自己的规范，按照规范写就对了。创业公司等的话，如果又没有人手把手教你的话，那我觉得开卷有益吧，反正也不耽搁你太长时间，哈哈哈哈哈~
PRD是什么
PRD，Product Requirements Document，产品需求文档，作为一个产品，别人问起PRD是什么的时候，还是要能解释一下的，好多人只知PRD是文档，到底是什么文档，却有些懵逼，所以，适当时候记一下英文名字，比较适合于不经意间装X……
PRD主要用来解释和定义一个产品（或者一件事情，一个模块，一个功能），当然，对于产品来说，你设计和策划了一个系统、结构、功能，总还是需要详细描述一下前前后后的逻辑、流程、功能等信息。这些描述的文件，现在都被称之为PRD了~
写PRD文档的目的
其实本质上就是详细的描述方案的全部信息。当然，要做到清晰明确，面面俱到。你要理解的是，你是在定义一个事物，这个事物的边边角角都需要有明确的定义。
当然我们也可以包装的好一些，定义一个产品的战略，包括产品定位、目标市场、目标用户等，和一个产品的战术，包括产品的结构、逻辑、核心业务流程、具体功能和内容描述等。
其实说多了都是扯淡，主要就是给技术GGJJ们看懂就好~
当然了，写出一些详细的文档，也有助于技术GGJJ更好的理解系统，如果不小心要撕逼，拿出文档的描述，一句话就能奠定胜局……（各位请自动脑补删除该句话，我和和我司各位技术GGJJ关系还是很好的，撕逼那是绝对不可能的~）
详细的文档也有助于未来的查询，好多细节性问题，如果不在文档中很详细的描述出来，那么基本上过上两周，你自己就忘记当时自己是怎么定义的了……（不用为自己记忆力感到担忧，其实每个产品都差不多~哈哈哈哈）
当然，以一个详细的文档，也有助于测试去建立自己的详细测试用例，设计或者交互去做完善的动作交互等等。
然后，其实交接的时候嘛，你懂得，文档甩过去就行了……（咳咳咳，我什么都没说，我做人做事，还是很有职业道德的。）
PRD文档的困境
不知道各位有没有碰到一些很尴尬的情况，就是你辛辛苦苦的写的大几十页甚至上百页的文档，其实技术GGJJ都不会怎么看，只是偶尔不知道定义的时候，CTRL+F搜索一下，然后找一下逻辑或者定义……
这真是一个尴尬的事情，你辛辛苦苦写嗨了的一些内容，比如用户群体啊，解决的问题啊，其实别人都是扫一眼就过去了的。完全没有任何作用。
so，写PRD文档的时候，一定要注意，你这个东西是要写给谁看的。不过对于大多数公司，都是写个技术GGJJ看的。那么这时候，就别搞那些有的没的，直接写关键点，把关键点描述清楚，其他的都不重要。请注意，关键点、关键点、关键点。
如果你们老板或者老大也要看的话……嗯，你放心，你们老板和老大没什么兴趣看你大几十页的文档。。。（我估计你你自己都不想看……）
PRD文档的两种写作方式
其实业界一直有两种写文档的方式吧。一种是传统的文档，比如word、pages、wiki等。一种是直接写在原型中。我无意去介绍哪种文档更好，把自己的一些想法提出来，诸位自定。
对于传统文档，在不停的版本迭代中，比较容易查找和修改。这算是优势，而劣势呢，更多的时候，技术GGJJ一般都对着原型开发，估计还是比较难一边看着原型，一般看着文档的。（所以，同志们啊，一个稍微高保真一点的原型是多么重要啊~ 额，跑题了……）
对于写在原型中的文档，看起来比较方便，但是过一段时间后，再回头查找某个逻辑或者定义的时候，会很麻烦。因为你要先找到原型，再CTRL+F全局搜某个关键字，或者到对应的页面去找文档。而且随着版本迭代次数的增多，你也不可能永远在一个源文件中不停的修改。随着时间的推移，你想回头找一些或者查一些东西的时候，就会越来越难。
所以，基本上也就是这些优势和劣势。具体如何选择全看自己。毕竟这块，大部分公司都没那么深刻的要求吧。
一般情况下，如果涉及web的话，比如中台、后台等，我会按照文档来写。如果是app或者小程序、h5的话，我会写在原型中。供各位参考。
PRD文档的基本结构
结构的东西，其实很多地方都一样，找个写的详细的PRD文档看看他们的目录基本上就知道了。
不过这里还是略写一下。
1.标题
一般也可包括副标题、文档产出人、文档产出时间等信息。如果对内，这东西都不用写，如果是对外的，那格式还是需要包装下的。至少不能太掉价，对吧~
2.修订记录
一般用来记录版本号、修订模块、修订内容、修订人、修订时间。主要是为了规避在开发过程中，对某些模块做了修改，需要周知技术GGJJ知晓，并且最好能在文档中使用不同颜色标示出调整的内容。
3.目录
这个东西，基本上在文档写的差不多的时候，才需要去生成。便于快速的去到某个模块查看相应信息。
4.产品概述
主要是描述一些这个产品的目的，产品解决的问题，影响的用户描述（用户群体），涉及到的功能范围，权限说明，以及一些你自行定义的名词的解释。
5.产品逻辑图
主要用脑图的截图来展示，主要用来描述某些核心逻辑。在文档的细节中，不同的地方也需要描述具体详细的逻辑，但若将所有关键逻辑整理起来，先给予大家一个整体的观感，效果会更好。
当然，由于逻辑图一般过大，所以，做好能提供脑图的源文件。
6.产品流程图
这个就不用多说了，一个产品的流程是什么样的，需要展示出来。
当然，这里不仅仅是要展示流程图，还要将流程的详细信息描述出来，包括流程的状态变化等。一般流程图足以说明，若流程图中有多角色参与，则可以采用泳道图。
7.产品功能机构图
这个就是这个产品的有啥功能，分别归属于哪个模块的结构图了。一般在设计某个大的架构的时候才会用上。
8.产品信息结构图
主要描述信息结构相关。比如某列表有一批筛选条件，这些筛选条件包括哪些。再比如，某个列表，列表中包含哪些字段信息。
9.产品详细功能描述
详细功能描述，自然就包括各个部分的细节描述了。这里仅描述每个细节模块的具体信息，顺序请依照自己的文档顺序进行删除。
菜单
比如你要做一个后台，你在定义的时候，一定要很明确的定义菜单的具体名称是什么，一级菜单是什么，二级菜单是什么，每个菜单分别对应什么页面。
列表
列表一般包含两部分信息，筛选条件信息和列表内容信息。
筛选条件需要定义以下内容：
列表内容需要定义以下内容：
详情
详情一般展示内容比较多，且会分模块展示，因此在详情页面描述时，需要进行再拆分，每个模块分别独立描述。
描述每个模块是什么模块，这个模块展示什么哪些信息，信息的展示方式是否有特殊要求。该模块是否有什么功能等。
功能
一个功能需要定义以下内容：
权限
主要用来定义有哪些权限，分别控制哪些功能？哪些角色应该有哪些权限等等。一般一个表格便足以说明。必要时需要加上文字描述。
表单
一般任何一个产品都少不了表单页面。表单页面虽然比较常见，也很简单，但是在大多数时候，很容易忽略一些必要的说明。一般用下表可避免该问题。
一般的表单也会有一些默认的填写提示，比如请输入你的姓名等。也会出现一些提示，比如某个字段没有填写即进行提交等。
弹窗
弹窗一般分为强制性弹窗或者弱性弹窗，该部分我也曾在其他一些短文里描述过。附一个链接吧。关于弹窗的设计「日常随笔」
异常提示
这个是在大多数场景下容易忽略的一个事情。当出现异常时，如何给予用户提示，让用户知道发生了什么。一般处理异常提示的时候，要注意描述两点。
数据统计
数据统计的文档的话，一般首先要确定统计和分析的维度，如城市维度，时间维度等。
确定完维度后，去确定每个具体的元素要按照哪些维度去统计和分析。
数据清洗
数据清洗的文档相对比较好写一些，只需要明确定义哪种类型的数据，需要洗成哪种类型的数据，给出明确的清洗规则即可。
比如原本系统中未记录客户的生日，但是现在有新的需求需要记录客户生日，且需要给客户发送生日祝福，且你的客户数据中客户都实名认证过，那么就可以从身份证号码中提炼出生日年月，完成数据的清洗。
好了，写完后看了看，好像也不怎么滴。。。伤心~
就这样吧，小桃红，看茶，送客~
若有诉求，可加contsun微信交流。