产品需求文档是产品工作必不可少一样东西。至于什么样的产品需求文档是合适的，千人千面。一份好的PRD不仅代表个人的职业素养，更重要的是会在项目整个过程中避免很多无谓的扯皮，项目顺利开展，也十分有利于我们与团队小伙伴关系融洽。基于此，蜗牛希望花一点时间去总结、完善一份比较系统全面、通用的PRD。enjoy~
一、PRD存在的必要性
结合自己的一点点浅显经验，我个人认为，PRD有以下作用：
1）项目开发需要
a.产品经理通过编写PRD，系统梳理整个产品架构，做到查（bi）漏（mian）补（ai）缺（dui）
b.开发同事根据PRD，获知整个产品逻辑去实现
c.测试同事根据PRD编写测试用例
d.UI同事根据PRD去设计产品页面及交互（有专门交互设计师除外）
e.运营同事根据PRD去制定、完善对应方案和规则
f.其他业务同事根据PRD可以对产品有了基础认识
2）项目管理需要
这里就比较有意思了。
提到产品开发，一个永远避不开的话题就是“撕逼”。
就产品自身而言，产品与开发撕、与UI撕、与测试撕、与运营撕，与boss撕，等等。哪怕是一个新入职的新人，只要你从头到尾全程负责一个产品落地，你会和大半个公司的人相爱相杀过。
以我多年厮杀经验发现，撕逼有2个主要问题导致：
①产品需求经常变更
大部分产品经理都有一个通病：爱拍脑袋，容易变卦。当然，变更需求的不止是产品。需求文档在一定程度上可以约束产品变更。
②产品逻辑问题
太多时候，产品方案尚未确定，产品逻辑没有走通就推给研发，希望研发同事去填坑。这样不撕逼才怪。
解决这2个问题，需要从问题源头规避，即：PRD
需求文档在某种意义上是一个项目节点凭证。产品立项会应确认2件事情：
①产品需求已确认，不再变更
②项目参与方应给出一个项目排期
无规矩不成方圆。凡事立了规矩，接下来的工作才好顺利开展。
一旦项目启动，不应轻易修改甚至变更需求。尤其是在研发过程中修改变更需求，不论是对工作开展还是团队士气、凝聚力都不是一件好事情。
当然，需求变更并不是绝对的。如果市场需要或者研发需要，必须变更时，应再次召开需要变更讨论会，做到信息同步。
二、产品需求文档框架
2.1产品概览
产品概览模块的作用是让让别人可以快速知道你这是做什么的。
一般包括产品简介、需求列表、开发排期、交互自查表4部分。
1）产品简介
产品简介一般包括该产品的价值、目标用户、使用场景和当前市场的基本分析。
2）需求列表
为方便项目团队成员清晰快速知晓本次产品的任务清单，产品经理应把需求列表整理出来。
3）开发排期
产品经理某种意义上在担负着项目经理的职责，负责整个项目进度的把控，因此整个开发排期是必不可少的。
4）交互自查
这部分内容主要方便产品查漏补缺。涉及信息架构与流程、产品界面、交互设计和异常情况。
2.2产品架构
1）产品结构
用思维导图的方式将产品的各个页面都罗列出来。将产品中的数据元素列举。
2）业务流程图
为保持逻辑的完整性，便于技术方通过流程图分配工作，通常采用泳道图来表示业务流程。以美团外卖为例。
3）任务流程
涉及到具体某项功能时，清晰的任务流程会帮助团队成员更好理解业务。
2.3产品原型
敲黑板！敲黑板！重点来了。
Axure相对于传统的产品需求文档来说，优点在于可以将交互和标注清晰在原型中表达出来。
1）交互原型
如下图所示，Axure版需求文档可以在原型中清晰标注出具体功能点，并在旁边详细标注需求说明。
2）全局说明
全局说明主要包括产品适配、常用字段、全局交互、异常情况处理等。
3）控件规范
在控件规范中，将产品工作常用的颜色字体、常用图标和常用组件整理出来。既能保持风格统一，又能避免重复造轮子。
2.4其他说明
在该模块可以编写其他需求说明。比如说，埋点需求、性能需求、兼容性需求等。
哦了，絮叨了这么多，这份产品需求文档大概就是下面这个样子。
三、后记
在我刚入行的时候，一直在试着编写一份标准的产品需求文档。
2年下来，发现并没有标准完美的PRD。只要你逻辑清晰、考虑周全，学会项目管理，可以解决问题就OK了！
世上哪有那么多完美，哪有那么多标准！^_^
Goodnight！
蜗牛丨2018.11.15
