我的产品方法论分享：产品需求方案中要包含哪些核心要素？

关注并将「人人都是产品经理」设为 ★ 星标

每天早上更新，与你一起成长

大家做的项目是类似的，但是实际上在讲解自己的产品需求方案（原型/需求文档）的时候就有很明显的不同，这里会有这么几个情况：

而通过这么几次的评审后，我观察到情况3的人比较少，而情况1和情况2的比较多。其中情况1是最让人可惜的，因为都花了很多时间做得那么好了，但是却讲得不好，让人感觉“差一点点”就成了，这种遗憾我觉得完全是可以避免的。

所以，我想通过这篇文章来帮助大家解决以上这些问题，希望能让大家既输出好的产品方案，同时也把自己的方案讲解好，不留遗憾。

需求评审中常见的一些问题

在讲产品需求方案中需要包含什么内容模块之前，我觉得可以先和大家分享一下需求评审中常见的一些问题，这些问题既是我过往工作中发生过的，比较有典型代表性。

1. 产品方案既是看的，也是讲的

在实际的工作中，产品经理输出的产品方案一般会包含各种图、文档、原型，还有附件资料等，其中需求文档和产品原型应该是最常见，也是最花时间输出的。

有一些产品的需求文档和原型都非常详实，甚至也会有一些产品经理认为需求文档的字数越多越好，感觉文档没写到几千几万字就总是会漏掉什么一样。

而另一个极端则是文档和原型都没什么内容，很多时候可能就截个图表示一下意思，或者是直接在需求评审的会议上对着竞品的内容直接讲解，然后需求就是做成和竞品差不多的样子……

无论是第一种，还是第二种，我都见过，而且我感觉都有很多的优化空间，基于我了解的大多数的公司的研发机制和流程规范，我都会建议：

产品方案既是看的，也是讲的。也就是说，不要写得太多，因为有一些内容你是可以通过讲解去表达的；也不要写得太少，因为有些时候错过了当面评审的会议或者是时间一长，就容易遗忘一些细节内容。

在下文中，我会重点提到一个产品方案中最好要包含哪些内容，如果不知道自己应该拿捏在什么度的朋友，请记得看完后续的内容。

2. 结构化的表达是需要持续提升的能力

在产品需求评审会议上，很多产品经理可能都会遇到一个尴尬的场景：评审到后面的时候大家几乎没认真听了，玩手机的玩手机，看电脑的看电脑，甚至有一些人都在打瞌睡了。

抛开一些外界因素（团队制度规范、个人素质和专业性、团队凝聚力等），我发现评审效果不太好的很核心的一个原因是：

产品经理在表达输出自己方案的时候，很容易陷入“不自知”的一种状态。例如自己一直持续地在讲，压根没留气口给其他旁听的人提问或者思考；自己讲解的时候各种切换页面、素材，整个脉络混乱，让人跟不上节奏；还有就是缺乏图例，表格，还有一些画面感的东西讲解，基本上就是对着文字在念，让听众很乏味。

对于产品经理来说，自己可能花了很多时间去了解需求的背景，然后做了足够的调研、会议讨论、业务设计、最后整体方案设计等，这些东西对自己来说可能已经滚瓜烂熟了。

但是对于听众来说，他们可能是第一次听说这个东西，而且也没有详细的背景铺垫，没有足够的业务知识积累，就会导致每次听需求评审的时候都被临时丢了一个新的东西，都需要花很多时间和精力去专注理解和吸收。

如果此时产品经理在评审自己的方案的时候，没有一些结构化、脉络化、画面感的东西，那么必然就会导致听众没有听懂，也跟不上节奏，然后就演变成了走神、发呆、各玩各的东西了……

产品经理的结构化表达能力是需要持续锻炼的，怎么把自己熟悉的一个事情向新人讲清楚，讲明白，还要把自己的观点和方案传达清楚，这不是一件容易的事情，需要我们提前准备足够的资料，也需要我们有适当的练习，持续地去迭代和完善。

3. 文不如表，表不如图，图不如当面沟通

我的每一节私享课，我基本上都会花很多时间去画图和做表，同时在需求文档和产品原型输出的时候，我也会一直强调一个理念：

文不如表，表不如图，图不如当面沟通。

过往我接触过很多产品经理都非常喜欢写文档，无论是简单的逻辑还复杂的逻辑，都是用文档的形式去阐述，然后用各种序号，表格，分段落等方式去阐述一些概念和方案，看似写了很多东西，但是读起来就非常的拗口。

例如说我经常吐槽金蝶的说明文档，他们就有这样的问题，大段的文字说明，但是看完了并不知道他要表达什么意思。

“所有权归属方即货主（组织结构勾选业务组织即为货主），存储地即仓库，仓库所属组织即“库存组织”（组织机构勾选业务组织，还得勾选“库存组织”职能）。

从组织机构的设置来看，业务组织一定可以作为货主，但不一定是库存组织，但库存组织一定是业务组织。

这点是与K/3WISE的最大区别，K/3WISE没有组织的概念，没有货主的概念，货主与库存组织是同一个。”

这段话就是摘自金蝶的官方社区，读起来非常拗口，如果能画两个示意图，我觉得这个概念可能一下子就能让读者明白了。

例如我需要表达一下OMS的入库单和出库单的一些操作会导致库存如何变化，那么我就可以采用表格的形式去说明，这些库存是怎么变化的：

如果说通过这个表格，还是有一些研发和测试人员不太懂，那么我可以通过图的方式再跟他们说明一下，让他们结合一个表和一个图来进行理解：

如果用表格和图片还是不能让大家理解其中的含义，那么这个时候就可以去当面沟通了，直接拉会议或者走到对方的面前，然后对着表格和图片去讲解，讲到大家懂了为止。

4. “用户满意度”才是核心的指标，而不是“规范和标准”

在产品经理群里时不时会看到一些提问，大概意思是就是“有没有需求文档模板可以参考学习的”，“有没有原型模板借鉴”，“有没有XXX模板或者规范可以抄作业的”。

无论是需求文档，产品原型，还是需求评审，规范和标准只是用来提升效率，同时规避一些已知的风险，并不意味着一定不符合“规范和标准”就不能做出好产品，或者说就会被定义为是“野路子产品经理”。

很多初中级的产品经理在这个问题上都会纠结一段时间，尤其是之前的公司团队规模比较小，然后也没有见过什么好的案例，就很容易有这种“自我怀疑”和“矫枉过正”的问题出现。

我曾经也有过一段时间的纠结，也很担心自己被定义为“野路子产品经理”。但是作为一个过来人，回过头来看的话，我希望大家能够尽早地意识到：“用户满意度”才是核心的指标，而不是“规范和标准”。

谁是你的用户呢？

如果是需求评审，那么在座的研发、测试、UI、甚至是你的产品同事都是你的用户，你应该在评审了之后去向他们获取反馈，自己是评审讲解的好还是不好，是否有什么值得改进的。

如果是需求文档或者原型，也是同样的道理，去问使用你“产品”的人，去倾听他们的反馈，而不是去“XX产品交流群”问广大群友们。

要包含的核心要素

前面分析了需求评审中常见的一些问题，实际上除了这些问题之外还有很多具有代表性的问题，但是碍于篇幅和时间的关系我就不展开去讲了，我直接分享一下我认为的一个好的产品方案（需求文档或者原型）应该要包含哪些核心要素。

这里我是以B端产品的日常工作为参考的，所以有一些内容不太适用于C端的产品或者其他领域的产品；除此之外，文中提到的是“核心要素”而不是“大而全的模板”，意味着这些是我认为特别重要的内容模块，但是并不代表说我没提到的就不重要，如果你需要“大而全的模板”，那么市面上有很多类似的文章可以参考学习。

1. 业务流程图

B端产品往往会涉及到多个组织，多个部门，多个角色（用户），多种场景和业务，所以当接受到了某个需求之后，肯定是要先对业务进行梳理和分析，然后要输出对应的业务流程图。

在讲解产品方案的时候，先铺垫需求的背景和价值，然后接下来大概就要讲解相关的业务流程图了，一般来说如果涉及到多部门、多系统等场景，建议使用泳道图来表达。

业务流程图重点是表达清楚相关的业务逻辑即可，其中有一些细节或者描述可能不太符合流程图的规范也没关系，重点是传达清楚意思即可。

2. 系统流程图

上面提到了“业务流程图”，那么什么是“系统流程图”呢？其实系统流程图就是指多系统之间的流程交互，通俗意义上可以理解为在多个系统之间的单据/模块的流程交互。

系统流程图可以简单地用单据来表示之间的流转关系，也可以在单据的基础上增加单据的状态及其相关的详细说明，让这个图更加丰富，能承载和表达更多的信息。

业务流程图和系统流程图在一些不太复杂的业务场景下，基本上可以合并为一个，我一般都称之为“业务流程图”多一些。

如果是更复杂一些的业务场景，需要业务设计和应用设计解耦的时候，那么业务流程图就要和系统流程图拆分开。

业务流程图只是表达业务之间的关系，此时还不知道有什么系统，有什么模块，所以就梳理的时候就不要带入“技术思维”。

完成了业务流程图的设计之后，接下来就是应用设计的内容，那么就梳理的就是系统流程图了，而系统流程图就需要用到“技术思维”，需要考虑有什么系统，有什么模块，有什么单据，甚至是有什么具体的单据状态等，因为定义清楚了这些才知道具体的系统功能模块有哪些，产品方案是怎么样的……

3. ER图（实体关系图）

在完成了系统流程图的梳理之后，作为产品经理，也就是作为方案的设计者，我们知道该需求的满足会涉及到多少系统，多少模块，多少页面等，但是为了让研发和测试更好地了解其中的逻辑关系，我们需要输出实体关系图，也就是ER图，来帮助他们完成相关的业务建模和数据库表设计。

实体关系图也被称为 ERD、ER 图、实体联系模型、实体联系模式图或 ER 模型，是一种用于数据库设计的结构图。

一幅 ERD 包含不同的符号和连接符，用于显示两个重要的信息：系统范围内的主要实体以及这些实体之间的相互关系。

当我们谈论 ERD 中的实体时，我们经常提到诸如人员/角色（例如学生），有形商业对象（例如产品），无形商业对象（例如日志）等业务对象。“关系”则是这些实体在系统内的相互关联。

ER图听起来好像很专业，是一个很技术性质的名词，但是理解了其含义之后其实并没有想象中的那么复杂，也没有必要恐惧它而不去使用。

产品经理输出ER图的时候，只需要表达出2个核心点即可：

我们只需要通过输出简单的实体关系图就能让开发明白不同单据之间的关系是什么，是怎么流转的，如下图所示。

采购业务中的实体关系图

上面的实体关系图虽然简单，但是清晰易懂，不需要过多的文字描述就可以让阅读者Get以下这些信息：

4. 状态机说明（状态流转图）

完成了ER图的输出之后，我们会发现一条业务会串联多个单据，例如采购计划单，采购单，收货单，上架单等，这些单据一般来说都是“执行类+结果类”的综合单据，也就是意味着这些单据一般来说会有多个状态。

例如说采购计划单可能会有以下几个状态：

而采购单可能又有另外的状态，例如：

产品的方案中必然要对这些状态进行说明和定义，所以就需要输出对应的状态机说明，我一般称之为“状态流转图”，具体如下。

海外仓OMS的入库单状态流转图

如果是涉及到一些单据有比较紧密的联系时，可以采用“多单据状态流转图”的方式，也就是结合版，如下所示。

盘点单和盘点任务单的状态流转图

5. 不同状态下的操作说明（列表展示）

完成了状态流转图的梳理之后，我们知道了某个单据有多少状态，状态的流转条件是什么，甚至也可以知道多单据之间状态的流转关系，接下来要做的就是整理不同状态的对应的操作说明，一般来说会用列表的方式来展示。

海运头程计划单的状态说明

海运头程计划单的状态说明

6. 核心业务逻辑说明（数据推演，逻辑计算，条件判断）

前面的几个核心要素基本上都是图或者表，而且是按从大到小的结构化思路去输出和讲解的，但是一个具体的产品方案中肯定是少不了核心的业务逻辑说明，还有一些相关的条件判断等。

关于这一块的内容，每个产品经理都有自己的输出和表达风格，不用刻意去追求所谓的“标准和规范”，只需要能表达清楚，同时效率也不会受到影响即可。

例如我就很喜欢用画图、画表的形式来表达其中的业务逻辑，然后将这一块的内容贴在文档或者原型即可。

操作费的业务公式分析

WMS不同维度的库存查询逻辑说明

上面也提到过一个口诀“文不如表，表不如图，图不如当面沟通”，所以切记不要长篇大论地去用文字表达相关的逻辑，看起来动辄几万字的PRD实在是让人看的头痛，而且自己输出的效率也不会很高。

上面分别讲解了6个我个人认为B端产品方案中很核心的要素，几乎可以理解为是“必做项”，但是实际的产品工作中需求的多元化的，解决方案也是多元化的，所以可能最后要输出的内容远不止于这6个要素，可能会更多，也可能会更少。

读者朋友们需要自己去甄别，以“用户满意度”为核心指标，去审视自己输出的产品方案还有哪些遗漏的点，还有哪些可以改进的点，而不是盲目地抄模板。

怎么讲解好自己的需求？

最前面开篇的时候讲到，在组织需求评审的时候，有些朋友可能方案很详细，但是却讲解的不好，其中最大的问题就是“缺少结构化”，也可以理解为“缺少清晰的脉络”。

其实上面提到的6个核心要素，既是我们输出产品需求方案的顺序，也是我们讲解产品需求方案的顺序，它遵循的是“从大到小，从宏观到微观”的逻辑。

在讲解产品需求方案的时候，我们会先铺垫业务背景，告诉在座的各位为什么要做这个需求，它解决了谁的问题，带来了什么价值，谁会使用它，会涉及到哪些部门，哪些业务流程等。

——这些既是产品的需求背景，也是业务流程图的一部分，通过讲解业务流程图让大家先从宏观层面了解该需求的背景。

对于大多数的产研团队来说，他们不太关注这些“上价值”的东西，而是更加关注自己的“体感”，也就是：我是什么岗位？有哪些是我的活？我做的模块要怎么搞？

所以第二个部分我们就可以开始讲系统流程图了，告诉大家涉及到了哪些系统，哪些模块，哪些功能，和谁有关系，谁需要干活等。

系统流程图的讲解可以结合业务流程图来讲，也可以结合ER图来讲，但是我个人会建议还是先铺垫业务的部分，然后再去讲解系统的部分会更好。

讲完了前面的三块内容之后，接下来的状态流转图，状态说明列表，核心业务逻辑等就可以按具体的业务线和具体的模块划分去讲解了，只需要遵循从大到小的逻辑即可。

例如WMS的入库业务，前面铺垫完了业务背景，业务流程，系统流程，ER图等之后，接下来就可以分别去讲解预到货通知单、质检单、上架单的状态流转图，各个状态的说明，各个单据下的核心业务逻辑等。

如果是一些比较复杂的需求，产品方案的内容也比较多的情况，最后还是需要把各个模块的内容再串一下，做到首尾呼应，让大家能更好地理解和消化这一大块的内容。