一、什么是PRD
PRD：产品需求文档，全称是Product Requirement Document，是产品文档中最底层最细致的文档。文档侧重对产品功能和性能的说明，主要是把产品规划与设计中的产品流程，界面，功能等定义向研发、设计、测试等团队做清晰的描述说明。
二、为什么写PRD
1、帮助团队存档产品信息
产品实现过程中，有很多的逻辑、算法需求，没有文档的记录，容易在团队变更、交接班的时候出现较大风险。通过产品需求文档记录产品的各种需求与实现方式，能有效降低团队的风险，同时也能提高交接效率。
2、提升内部信息沟通的效率
虽然需求可以口述，但是不代表说一次全员就都能记得，会遇到开发、设计或测试记不清楚的地方，可以直接查看文档。结构明确、表达清晰的文档仍然有不可取代的作用。
3、产品工作有据可查
各方需求理解不一致，或延期产品工作的时候，通过产品需求文档都可以有效的找到问题根源。
三、PRD常见的面向对象
研发人员：由于研发人员本身专注于功能的实现与性能，所以他们相对于其他岗位比如运营，时长，设计等，表现相对不太关系，对于产品更多地了解来自于产品经理的产品宣讲。
设计人员：设计人员本身更多的会关注产品的表现形式与原型，所以对PRD的需求是相对较弱的。
还有老板、项目经理、运营、市场、客户、财务……
所以，PRD文档，根据阅读对象，可以用最平铺直叙的话，把产品描述清楚就行。
四、PRD格式
文字模式：Word。时间较为充裕的或岗位责任制分明，有文档要求规范的团队，建议选择Word撰写文档。
原型图模式：Axure。追求时间效率灵活性的团队，建议选择Axure撰写文档，原型搭配产品说明，无需切换，只用一个文件就可，方便快捷。
无论哪种方式，都是大同小异，本质上并不影响PRD文档的使用效果。
五、PRD文档结构
——文档说明
1、修订记录：版本号、修订日期、修订章节、修订内容、修订人等。
版本号说明，以1.25举例：
版本号（1.25）：重大调整升级，一般是产品结构功能等有调度。
子版本号（1.25）：在原有基础上对局部功能进行了升级或调整。
修正版本号（1.25）：局部小范围优化与Bug修复，一般是不动功能性的东西。
版本号的命名规则：
归零原则：前一个数字增加一位，后面的数字都归零。
修订记录的作用：
对修改前后进行比较
有利于维护和管理PRD
记录修订人和修订日期
方便查询，可以只看修订部分，快速查找变更之处
2、名词术语：将一些产品里面不易理解，容易混淆，或者缩写的词汇在开篇进行统一的列表说明，有利于阅读。
——全局说明
全局说明包括：权限说明、授权说明、异常情况、键盘说明等。
权限说明：对角色权限进行划分，例如登录和未登录状态下可访问的功能权限。
授权说明：手机号授权、地理位置授权、相册授权等。
异常情况：加载失败、网络异常等。
键盘说明：数字键盘、字母键盘。
......
——功能性需求
1、产品结构：包括产品功能结构图、信息结构图。
2、业务流程图：通过用户行为串联信息结构和产品结构，可以更好的理解产品经理设计的用户行为。
3、功能清单：清单包括功能模块、功能点、功能描述等。
4、功能详情：原型设计、功能说明和用例。
功能详情的表述顺序可以按照功能的逻辑来表述，或按照产品结构来表述，具体可以看个人习惯和团队要求。
用例：用例图和用例说明。用例图表述的是系统的外部参与者与系统之间的关系，是由参与者与用例组成的示意图。
注意：
撰写前要保证思考到位，产品结构本身短期内不会有重大改动。这样即便是在交付后，出现调整或需要优化的地方，也不会出现重构的情况。
文档中用词用语一致，对于同一事物的表述应该一样，避免混用。
——非功能性需求
非功能性需求是对产品非功能性需求的说明，包括性能需求、技术组件需求、安全性需求、可用性需求、质量需求等。
性能需求：系统满足多用户同时工作，保障同时在线用户五千人，并发操作一千人的使用需求。
技术组件需求：数据存储及计算使用星环大数据平台等。
安全性需求：涉及外网环境的需保证数据网络架构上保证数据的传输安全、具备良好的跨平台部署能力等。
可用性需求：系统支持IE11并向下兼容，支持Chrome等主流浏览器。
质量需求......
六、总结
上面的文档结构只是PRD的基本结构，并没有成为固定的可以供套用的东西，文章只是一种思路的分享，具体还是要根据自己公司及团队的习惯和达到你的目的为依据来进行调整，切勿生搬硬套。
对产品经理感兴趣的朋友，可以移步“行业与市场分析”，期待共同交流。
网友评论