PRD文档
作为PM，写PRD文档就相当于对于一个程序员来说要会编码，对于UI设计师来说会用PS进行设计，这是一项我们绕不开的技能。
也经常听到有人说，写文档有用吗？我们的程序员是不会看这些东西的，他们都是直接上原型图，PM写的PRD文档洋洋洒洒那么多字，最后没人看，还写它干嘛？
那我们PM为什么还要写PRD文档呢？
事实上不管你写不写PRD文档，当产品最终出现问题时，这个锅一定是你来背！你是产品负责人，产品出问题，不找你找谁？
所以PRD文档真的不重要吗？答案是否定的。PRD文档当然重要，开需求评审会的时候，评审内容有PRD文档吧！当然一些小型的初创团队都是PM直接说了算！自然不用什么评审会。但产品出问题了，总得找问题做备案吧！当PM离职的时候总得做交接工作吧！没有交接，那下一任PM还得重头慢慢梳理产品功能流程？
这个时候PRD文档的作用就体现出来了。
1. 产品出问题时，可以快速定位问题，做备案
2. 开需求评审会议时，整体过PRD文档，程序员可能不看你的文档，但是开会时，大家都会整体的过一遍你写的PRD文档，对产品的整个流程有个清晰的认知
3. PM离职时，交接必备物
那么如何撰写PRD文档呢？
现阶段，市面上谈论最多的也就是三种写法。第一，word ＋ 原型图，这也是绝大多数PM所推崇的做法；第二，原型图标注，直接在原型图上标注自己的注解，其实就是把word＋原型图合二为一了；第三，上次看到的有人直接用Excel写文档，需求变更、产品输出等都十分的方便。
今天这里，主要还是谈论用的人数最多的形式，因为我们写文档也主要是要把PRD文档所涵盖的内容表达清楚，逻辑理清楚。至于形式，大家在掌握了写法后，大可以都试一圈，然后找到最适合自己的，沿用下去就好。
首先，PRD文档大体涵盖以下几个部分。
第一，文档头。包含文档名称、作者或撰写人、文档编写日期、版本纪录。这是方便后期产品如果出现问题时，可以直接找到相关负责人，以及在后期迭代中，直接更新版本，加减功能即可。
PRD文档头
第二，就是目录。我们的目录包含以下5大块。
1. 产品背景、目标 、用户角色
2. 产品需求（功能介绍，增加的、删除的、改变的......）
3. 产品流程图（整个产品从头东尾运行的流程图，此处可能会有流程图、泳道图等）
4. 产品附件（这里包括测试用例、Axure高保真原型图地址等）
5. 其它需求（非功能性，比如运营、测试等）
接下来，针对以上的某几个重要的部分详述。
1. 产品背景、目标
这里背景主要是引出为什么我们要做这款产品？
目标则是，我们推出这款产品是希望它最终达到什么目的。达成这个目的的阶段性目标是什么，该怎么去实现？跟竞品相比，我们希望它有什么独特性能让它脱引而出？
2. 产品需求
落实到产品具体的地方，产品有哪些需求？增加了哪些需求？调整了什么？取消了什么？需不需要其他资源的配合？有什么影响？，把几个地方说清楚。
当涉及到有些特别重大的功能时，可以用图文的形式，有侧重点的进行梳理。
3. 产品流程图
这是整个产品的框架，因此描述清楚是非常有必要的。我们需要讲清楚产品的每个逻辑点，每个地方应该怎么走？应该做什么样的判断？如果进行到这个操作会返回给用户什么内容？用户触发之后得到什么内容？失败了会返回什么，成功了会返回什么？......
流程图样式举例（来自于网络）
如图所示，这就是我们把一款产品从头到尾的流程画出来的效果。从登陆界面，到执行完所有产品功能其中所有的逻辑。程序员不会看我们PM的整个“冗杂”的文档，他们只会看这些图例以及我们的原型图，因此把逻辑理清楚，对于我们PM来说，是无比重要的（因为针对这些逻辑的东西，程序员是会有很多发言权的）。
4. 其它需求
俗话说，PM是产品的生父，运营是产品的养父，这就是产品与运营之间的关系。
这里可能会涉及到与运营对接等需求，因此在撰写PRD文档时，我们需要实时的与运营进行沟通，他们作为一线人员，直接对市场负责，我们产品人员，可以直接从他们那获得用户的需求等
这样，大体PRD文档所涵盖的内容就都有了。最重要的一点，我们PM撰写PRD文档时，希望迭代一就尽可能完美，后期产品迭代时，我们只需要单一的修改功能即可。需求不要经常性变更，相信我，程序员是十分反感这点的。
网友评论