产品需求文档是产品工作必不可少一样东西。至于什么样的产品需求文档是合适的，千人千面。一份好的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其他说明
在该模块可以编写其他需求说明。比如说，埋点需求、性能需求、兼容性需求等。
哦了，絮叨了这么多，这份产品需求文档大概就是下面这个样子。
PRD总览
三、后记
在我刚入行的时候，一直在试着编写一份标准的产品需求文档。
2年下来，发现并没有标准完美的PRD。只要你逻辑清晰、考虑周全，学会项目管理，可以解决问题就OK了！
世上哪有那么多完美，哪有那么多标准！^_^
Goodnight！
蜗牛丨2018.11.15
网友评论