产品需求说明书怎么写（手把手教你写产品需求文案）

要活学活用，之前说的产品设计的内容，不要用一套自我主义思维打天下，强调下产品结构的几种特点：矩阵结构【一个页面阐述大量的内容，并不是有大量的分层，多个维度来统计能功能】，线性结构【某个骨干流程按照某个线的方式，某个场景往下串】，层级结构【按照用户自行选择，需要干的事情，做的层级，1.足够偏，功能足够的多。2.层级足够的深，每次选择的足够少，统一认为第二种的用户体验比较好】。不要小看产品的结构设计，这是产品经理的基础。结构设计是思考一个功能第一想的问题，不先想界面长什么样子，先想是什么层级，什么结构的产品，然后在想有几个界面有几个判断。开始今天的内容，画原型和写PRD，主要是PRD和原型的对应关系，核心是说说PRD。

（一）回顾下上篇文章

• ① 交互所在层级

主要说了界面交互，低保真原型的设计。

• ② 交互设计三步走

（二）产品原型及需求文档的撰写

• ① 开发人员最讨厌的PRD

PRD里面讲的逻辑限制开发了代码，这块就去查某个表，做某个参数，定义的变量都写出来了，觉得很崩溃，照这样写出了问题算谁的，明明理解了业务，有别的方式不这么做，用更好的处理方法，出了bug算谁的？PRD到底写成什么样的，描述业务好不好。

• ② 产品设计阶段

早期的PRD不叫PRD，叫开发规格，真的很限制人的，PRD是产品设计的第三个环节，根据原型设计进行讨论，修正原型的正确性，也可以跟研发进行评判，对整个系统的开发工作量进行估值，需求文档往往是后置的，一般来需求文档就是需求评审之后，代码就开工了。在原型设计之后研发就会做一些开发的准备。PRD也不能当饭吃，一堆人在写PRD，写了这些也不能产生价值，写这些文档干什么用呢。

• ③ 为什么要写需求文档

1. 需求文档给谁看？

交互设计、视觉设计【需要了解场景进行设计】、项目经理【PRD认领，符合PRD管理规范的】、开发【开发的基本，开发需要PRD中将业务逻辑讲清楚】、测试【依据PRD出测试用例的，怎么进行测试，测试用例的变更和新增】、其他产品经理【讲述可能有遗漏不如直接看PRD】、其他需要了解业务逻辑的人。

2.需求文档的作用是什么？

准确、直观、完整传达产品需求，保证各角色沟通有依据，保证产品质量控制有标准，存档。

• ④ 需求文档覆盖的范围

• ⑤ 需求文档主要结构

• ⑥ 需求背景及目标
  1.需求背景

让项目参与者明白为什么启动该项目，如果来此竞品分析，分析下竞品，竞品实现的功能是什么样子的。

2.项目目标

让项目参与者共识目标，找到价值感。目标尽量量化。上线后验证目标达到情况的依据。

3.编写人

修订日期、修订人、修订说明、修订原因、修订文档版本号。

• ⑦ 功能列表

拆分成最小的功能点功能点之间相互独立方便参与者理解需求，评估工作量

• ⑧ 功能点拆分

拆分：一定要拆出来一个功能的组合。一定有个优先级最高的就是产品的灵魂，需求点。P0级的功能.P0是灵魂，没有它就不是这个产品。P1和P2是对用户体验有绝对性意义的东西。P3是对产品的存活有决定性作用的东西，拉新留存。P4是锦上添花的作用。功能拆分的时候不光光的讲有几个按钮，几个值，首先优先级。是不是拆分出来的每一个功能列表。

• ⑨ 逻辑展示

为什么需要逻辑展示？弥补与程序员的种族差异，帮助自己梳理思路。不免需求遗漏，考虑不周。

多角色流程图（泳道图，跨职能流程图：多角色，多系统，多模块流程）

单角色流程图（基本流程图：单角色，单系统，单模块流程）

流程图：基本元素

基本结构：顺序结构

选择结构

循环结构

页面流程，这是UED和前端最喜欢看的流程图

• ⑩ 详细描述

想不到那么多情况怎么办？善用工具，帮助整理思路，表达清晰。向测试学习，多看测试用例，善于总结。

• ⑪ 数据需求

数据需求的采集标准

1. 理论上所有用户端新增功能都需要采集。
2. 改动、优化需要进行前后数据对比
3. 版本的核心数据指标

数据采集的类型基础数据，交互数据，用户路径

业务数据，服务端存库，用户行为数据，前端埋点。

• ⑫数据需求

如果没有BI支持，需要茶品经理自己定义埋点事件，不同的数据统计工具，不同的埋点的规范

• ⑬风控说明

可能出现的风险点和策略

PS：PRD是一个文件，文件是写给人看的，文件什么样不取决于产品经理想写成什么样，取决于读者。大家认为好才好，为别人写的不是为自己。文档是核心：以表达为目的，让查看的人清晰易懂，文档完整性很重要，文档表达方式灵活：axure、word、wiki、脑图、表格，逻辑严密，表达清晰。产品经理技能宏观至战略，又能微观至一个文本框的各种边界和异常