在上一节课中，我们介绍了《问题汇总矩阵》这个文档该如何撰写，在本节课中，我们就来介绍一下基于《问题汇总矩阵》这个文档中记录的问题，接下来该用哪个文档来承接了。

我们应该知道，一切需求都是来源于消费者现实的问题，然后我们把由问题导出的需求形成一定的规格，再交付给相应的业务团队去实现，最终通过发布到市场上的产品来验证需求是否满足了消费者的期望，这样一个过程是比较漫长的，作为产品经理，就必须得用一个工具来记录这些需求在这个过程中的情况，这个工具就是我们要在本节课中要讲的《需求矩阵表》。

但是，这里大家需要注意一点的是，在战略活动中，我们只是启动《需求矩阵表》，这又是为什么呢？

因为，在这个阶段，我们用《需求矩阵表》主要是对导出的需求进行分析筛选，而后面的分配，执行，验证这些管理，在战略活动中是不做的，也就是说，基于《需求矩阵表》的和需求相关的工作是要根据需求的管理阶段来做的，也就是说，什么时候，填写《需求矩阵表》中的什么内容，这个是和需求管理工作的流程紧密相关的，大家看PPT1：

PPT1

这个流程，大家了解一下就可以，我就不展开讲了，讲的话，就又是好几节课，大家只需要注意一点就可以，产品经理的需求管理，焦点一定要放在产品管理上，而不是我们很多朋友遇到的那种，基于研发管理或项目管理的需求管理角度。

好，接下来，我就来讲讲《需求矩阵表》都包括哪些部分，以及要启动的部分该如何来写。

我们先来看整体的需求矩阵表是什么样子的，大家看PPT2：

PPT2

整张表大致可以分为两大部分，一部分是问题管理，一部分就是需求管理，这两大部分各自有相应的一些模块，在需求管理中，我们其实就是根据需求发展的阶段把这些模块完成就可以了。

接下来，我们还是基于上一节课中我最后说到的那个DD的案例来讲一下，在这个阶段，我们都该怎么来填。

在上一节课中，我提到了，现有翻译软件有个问题，就是不能根据语境来识别英文缩写和专业词汇在要翻译文章中的确切意思，比方说PM，经常就被翻译成项目经理，而不是产品经理，我就不得不手工修改，如果量大的话，会降低翻译效率，问题就是这问题，那么，如何在需求矩阵表中体现呢？

先来看问题管理部分怎么来写，在这个部分有两个模块需要填写，分别是原始信息和处理信息。

我们先来看这部分怎么来写，大家看PPT3：

PPT3

在第一个模块，也就是原始信息中，有三项需要填写，分别是：PID、问题说明、来源。

这三项都很容易理解，就不做太多介绍了，在PMM中都是自动处理的，稍微多讲一点问题说明，大家只需要记住一点就可以，这里的问题一定是基于问题汇总矩阵，由我们归纳出来的问题描述。

还有一点，这个大家可以根据实际情况来，就是问题来源，这个在PMM中是可以自定义的，你可以设定成具体的人，比方说张三，也可以设定成部门，比方说销售部，当然，设定成销售部-张三那就更具体了。

再来看第二个模块，处理信息，只有一项，PSFB就是问题、方案、特征、利益这四个单次的英文第一个字母，这个了解一下就成，关键是那个1代表什么呢？

就是问题的优先级，这是我们产品管理中的第一个优先级排序的工作，具体优先级怎么产生的，就不占用本节课的时间了，有时间了我专门讲一下。

好，接下来，我们就来看第二部分，这是本节课的关键所在，也就是需求管理部分怎么来写。

在这个部分里，分为五个模块，分别是需求信息，过程信息、执行信息、处理信息和变更信息。

我们先来看第一个模块，需求说明信息怎么来写，大家看PPT4：

PPT4

看到PPT4，大家是不是有点疑惑，怎么这里有两个需求内容啊，问题不是一个吗？

我说一下，大家要记住一点啊，一个需求一定对应一个问题，但一个问题不一定导出一个需求，这里就是导出了两个需求，咱们再看一下刚才DD中的那个问题：

缩写和专业术语不能根据要翻译文章的语境准确识别，需要手工改正，降低译者效率。

消费者的这个问题，其实包含两个诉求，一个是识别，也就是能精确翻译缩写，专业词汇等，另一个就是能够自动把一篇文章中所有的同一个词汇自动修改为正确的释义，但是，消费者在提问题的时候，是不会分的这么细的，只会把他在一个场景中出现的问题一股脑告诉你，而产品经理呢，就必须从这个一股脑的问题中抽取、归纳、分类出都包含着那些需求，这也就是为什么我在前面提到的，一定要记录问题的原始信息，因为如果让别人加工好再给你的话，说不定一些和需求有关的信息就被过滤掉了。

 当然，咱们不排除有些高级用户能够做到，按问题和需求一对一的提出来，我以前就遇到过，条理清楚，需求到位，甚至还写好了一个文档，但是，大部分的用户肯定不会这样的，别指望消费者能够和你在一个频率上交流，能给你提出问题就不错了，有时候，我们遇到的就是批评，讽刺，甚至是骂街，产品经理太难了，有首歌怎么唱的，迎着冷眼和嘲笑，生命的广阔，不历经磨难，怎能感到，就是这个意思。

再来看第二个模块，过程信息怎么来写，大家看PPT5：

PPT5

这个过程信息就是要对每个需求进行分析，并最终形成需求的优先级，这个我们都知道，但是，难点在哪里呢，就是如何制定分析标准，那怎么来定呢，这就需要首先定好根本原则，根本原则又是什么呢，其实说出来很简单，就是“成本-收益”原则，为什么这么定，大家应该能知道吧，这其实是商业的最根本逻辑，我们要从这个点来定原则。

基于这样的原则，就有了两个维度，一个就是成本维度，一个就是收益维度，基于每个维度，我们可以设定具体的评估点，我这里是每个维度各设定了四个，这个只是给大家做个参考，大家可以根据实际情况来定。

然后通过百分制对每个评估点进行打分，就能形成一个这样的图表，大家看PPT6：

PPT6

这样，需求的优先级就一目了然了，你最终交付出去的需求说明有这一张图表就可以了。

我知道，到这里，肯定有朋友想问，怎么绘制这张图表，不用你绘制啊，咱们的PMM里同样也把需求管理的全部流程做好功能，大家只需要打打分就可以了。

另一个问题可能又会有朋友去问，就是产品经理打这个分是不是有些主观啊，谁说让你一个人打分的，这是需要你和相关的业务团队一起来完成的，这里要借鉴的是德尔菲法，也就是专家法的核心逻辑，什么逻辑呢，就是：一群人错总比一个人错要强，一群人背锅总比一个人背锅要强。

再来看第三个模块，执行说明，大家看PPT7：

PPT7

这个模块就简单了，就填三个信息，执行人，开始时间，结束时间，为什么只填这三个呢，大家要记住，你是产品经理，不是项目经理，你只需要关注谁在做这个需求，什么时候开始做的，什么时候能做完，就行了，用个测试中的术语，这个过程就是黑盒的，只需要关注输入和输出就成了，至于具体的实现过程，相关体系有人家自己的一套的，咱们别参与太多，因为你还有其他重要的工作要去做。

当然，还有一种情况，就是产品经理兼着项目经理，那也好办，这里是呈现产品管理的，项目管理的，你用项目管理的专业工具，比方说project管理好实现过程就可以了。

接下来看第四个模块，处理信息，大家看PPT8：

PPT8

这个模块呢，其实就是记录需求结果的，分为四个要填写的项，分别是PRDID，优先级，是否实现和未实现原因。

PRDID，这个好理解，就是在PRD中的编号，关于这个，我多说两句，到这个模块，大家应该体会到了，从问题到需求，从需求再到具体的PRD中呈现的产品规格，是不是我们就用有联系的编号串起来了，比方说DD这案例，问题的编号是P1，导出了两个市场需求，编号分别是MR1和MR2，而需求在PRD中以产品规格呈现的编号分别是PRDI和PRD2，这样，我们就形成了一个编号链，无论是顺序的工作，还是回顾或复盘，都能够用编号作为唯一的线索，这样就算你这个产品做了很长时间，那么，只需要查询编号，就可以了解到这个产品最原始的市场问题是什么，追根溯源，就是这个意思。

其它三项呢，主要说说优先级吧，大家各自的公司可能有各自对功能规格优先级的定义，我这里只简单介绍一下我常用的，大家看PPT9：

PPT9

具体是怎么回事，大家可以去听千聊里第一期直播，我就不重复录制了，我用的多的是P1-P4四级优先级。

最后我们看第五个模块，变更信息，大家看PPT10：

PPT10

变更信息这个模块呢，就是一个可选模块了，如果有变更，那就写进去，如果没有，那当然好了，这个模块只记录三个内容就可以了，一个是是否出现了变更，一个是变更基线是哪级，最后一个就是变更的需求和变更记录单的联系。

这里面有一个需要注意的地方，就是变更基线，什么是变更基线呢，通俗的说，就是说如果一个需求需要变更，那么，控制这个变更的角色和权限是谁。

比方说，我以前公司的变更基线分四级，分别是委员会级（I级），总监级（II级），产品经理级（III级）和执行人员级（基础级），案例中DD就出现了变更，变更了什么呢，就是研发要求降低AI算法的精确度，如果不降低，可能就要延期很长时间，那这种变更，就不是产品经理能控制的，能拍板的了，得到I级，也就是委员会来决定了，而像修改个按钮大小，调整一下色值什么的，那产品经理同样不用过问，直接让UI改就行了。

变更管理听起来不难，但其实制作规范的时候非常费脑经，因为你得把产品出现的各种各样可能出现的变更情况想的非常全面，也就是要做到有据可依，要不一旦乱变起来，我们就没法控制了。

好，关于《需求矩阵表》咱们就讲这么多，其实在前期，也就是战略活动中，主要是填写问题管理部分和需求管理部分的第一和第二个模块，后面的模块会随着需求工作的发展才填写的，我这里只是给大家演示一下这个工具完成后是什么样子的。