产品经理必修课（8）：需求管理

跟了解订单的生命周期就能勾画出电商购买流程、了解帖子的生命周期就能勾画出论坛的交流场景一样，从需求的生命周期就能勾画出整个产品设计到实现的流程。

在相对成熟、处于发展期的团队，需求管理就是产品经理的核心工作之一。就像长途驾车既要保证方向正确、目标清晰，也要保证在驾驶中的平稳、安全不出差错。

需求在不同的阶段，产品经理对这个需求要负的责任是不同的。但需求要牢牢把控在产品经理手中。产品经理对每个需求都了如指掌，非常清楚，这才称得上是“Manager”。要管理起整个产品，将产品拆分成功能，功能都从需求中来，是需求的表现形式。严格来说，需求到了开发阶段就算是功能了，但为了描述的一致性，在这里我们把此时的“实现功能”也视为“实现需求”。

我们可以把需求分为几个阶段，依次讨论在每个阶段产品经理应当如何管理和处理需求。

一、获取需求阶段

需求的来源有很多。业务越复杂，需求就越复杂。前文我们提到了一个电商平台，产品需求就可以拆分成导购、商品、营销、交易支付、售后、个人中心等。

职级越高代表着身边人提需求的可能性越大。初入行的产品专员或助理，主要是得到被安排的任务；初级产品经理，需求来源主要是用户和上级；产品负责人，需求来源还会有老板和其他相关部门；而作为老板，谁都可能提产品需求。

所以在获取到需求这一刻，就必须做一个判断并且记录。如果不做判断，等做的时候根本没办法梳理出头绪，可能大部分时间都在疲于折腾需求清单。记录当然是为了方便回溯，获取到的再小的需求也记下来，不要指望你随时能想起来每天听过的每个需求。

判断需求的方法如下：

第一，判断需求本身的重要性。

同样是页面写错了一个字，把“登录”写成“登陆”和把“奖励 15元”写成“奖励50元”，对不同问题的严重性要有一个大致的预估。

第二，考虑需求来源。

需求来源会表明一些事情，要慎重思考。比如老板提到的需求未必是目前你能理解的，但他认为特别重要，我们就暂且把这个需求当成特别重要的任务。再比如是用户提到的需求，但细想后发现他并不是目标用户，那么他的需求就可以暂时不用考虑。

第三，了解需求背景。

我在工作中有三类需求绝对不记。

没说清楚原因的需求，不记。（“你做个XX出来，别管那么多。”）

不说清逻辑的需求，不记。（“啊，这里我也没搞懂，你先看看。”）

不是实际遇到的需求，不记。（“哎，我觉得可能有人会这样用。”）

需求背景没弄清楚，完全是浪费时间。记录需求的时候，要确保格式是“问题+方案”的形式，例如“XX在用我们的XX功能时，感觉XX，我们可以尝试XX的方案”。如图8-1所示为我们平时记录需求时的常用格式。

image.png

二、讨论和设计阶段

每隔一段时间应该举办需求讨论会，整理“需求池”，也就是记录所有获取到需求的表单。会上要详细讨论每个需求的情况，确认以下几个事项。

1.需求的优先级

对于需求的优先级有两种常见的排序方法。一种是基于四象限法则，另一种则是基于KANO模型。

↘ 四象限法则

一般需求的重要程度很难量化，尤其在来源复杂的情况下。营销部门着急要我们配合做活动，不做就少赚好多钱，业务部门着急要我们配合做一套自动化结账工具，做了能节省很多成本……有时抉择会很痛苦，要权衡各种利弊，考虑最合理并且能说服别人的理由。

最常用的判断方法是 Stephen Covey提出的紧急重要四象限法则。如图8-2所示。

image.png

我们要把紧急且重要的需求排在最前，不紧急但重要的需求其次，紧急不重要的需求再次，最后是不紧急不重要的需求。

而在判断是否重要时，可以参考这样的排序（重要程度由强到弱）：

• 不做，会造成严重的问题和恶劣的影响

• 做了，会产生巨大好处和极佳效果

• 跟核心用户利益有关

• 跟大部分用户权益有关

• 跟效率或成本有关

• 跟用户体验有关

判断是否紧急，可以参考以下排序（紧急程度由强到弱）：

• 不做，错误会持续发生并造成严重影响

• 在一定时间内可控但长期会有糟糕的影响

• 做了，立刻能解决很多问题、产生正面的影响

• 做了，在一段时间后可以有良好的效果

↘ KANO模型

另外一种很常用的方法是东京理工大学教授狩野纪昭（Noriaki Kano）提出的KANO模型。我个人比较习惯用简化版的KANO模型法，如图8-3所示。

image.png

作为一个需求对应的功能，“行”描述的是“如果有的话”，用户会“开心”、“无所谓”还是“不开心”；“列”描述的是“如果没有的话”的情况。具体分析如下。

矛盾：如果用户觉得功能存在和不存在都很开心，或者都不开心，显然是有问题的，这种矛盾的情况是存在逻辑问题的，不予考虑。

错误：如果功能不存在让用户很开心，或者功能存在让用户不开心，那么这个功能显然是错误的功能，不予考虑。

无关：如果功能存在和不存在，用户都觉得无所谓，那功能也就无关紧要了，同样不予考虑。

最重要的就是以下三类需求：

必要：如果功能存在，用户并没有特别的感觉，但功能不存在，用户会不开心。这说明这个功能是要满足基本需求的，也就是大家常说的“痛点”。

期待：如果功能存在用户很开心，功能不存在用户很不开心，这就是满足用户最直接、最明显的需求了，因为在用户内心已经有所期待。

惊喜：如果功能不存在的时候用户并没有感觉，说明对这个功能，用户之前没有预期，但功能存在用户很开心，也就是说达到了惊喜的效果。这就是我们在第2章所说的能够超预期满足用户。

任何需求对应的功能都可以分为“惊喜型”、“期待型”和“必要型”。考虑需求的价值，就要基于这三种类型来做判断。很多公司和产品利用的产品运营手法就是在满足后两种类型需求的同时，不断用第一种类型需求激活用户的热情，促使用户传播。

基于四象限法则或者KANO模型，可以完成优先级的标注。通常我们会用P1、P2、P3、P4来标注不同优先级的需求，P1优先级最高，P4优先级最低。

2.方案的草稿

需求有不同的解决办法，要讨论清楚到底用哪种方法解决。比如在讨论O2O产品的需求时，我们发现有要解决刷单问题的需求。解决方案可以有几种：事前提醒，告知用户目前地理位置或订单信息有刷单嫌疑；事中限制，以必须到达指定地点、拍摄当地照片等操作来限制用户；事后惩戒，提供给客服或者业务部门疑似刷单的名单和证据，罚款或者封号。这几项到底做哪个？还是做其中哪几个？优劣在哪里？需要好好讨论。

讨论出大概的方向，以及粗略的方案，再跟相关业务部门或者需求方确认。要确保大家共同认可了某个方向后，再继续推进。

3.指定负责人

通常存在两种产品经理的需求分配制度。一种是每个人负责的需求范围要有清晰的边界，需求对应哪个模块直接分配即可；另一种是团队作战，每次指定或者认领，谁都有可能接手任意需求。前一种的好处在于模块清晰，负责人可以对自己负责的部分足够熟悉，但缺点是工作量很可能不平衡，有的同事一直在忙，有的同事可能就比较闲，因为需求不是平均按模块分布的。

建议的方法是，在需求分配时大致还是按照模块分配，但在出现工作量不平衡的情况时，可以酌情调整一下，让活少的同事予以配合。但不管怎么样一定要指定负责人，他需要对需求负责，一直到产品上线后，出了问题他也要承担责任。要保证运营良好的工作责任制，需求管理才能健康运作。

4.划定时间节点

许多产品经理会疏漏这点，总觉得有了需求就尽快去做。但这样的结果往往是需求总也做不完。

时间节点主要是指方案完成的截止时间（Deadline）。就是当前需求能够完整提交给开发人员的时间。如果没有这个时间，对需求的管理就没有意义了。另外，如果是要跟相关部门再确认、需要对用户调研及要统计各种数据再作判断，那么还要有调研或讨论完成的时间（Deadline）。

时间节点的划定主要还是按照方案的复杂程度，依照经验做粗略判断，在多次需求迭代后会越来越准。建议最长的时间周期不要超过一周，保证需求的推动进度。对于有严格上线时间的需求（比如很苛刻的老板需求、投资人需求、政策需求等），要倒推出最合理又富有余地的时间节点。

讨论完刚刚入池的一批需求，要再整理和讨论处于其他状态的（比如需要确认方案的）需求。会议结束，每条需求都会得到更新。

这里还有个建议。我们在这个时刻，一般会让负责的产品经理及时更新需求状态给需求来源方。当然，需求方十有八九会对进度不满意，这很正常，但除非需求方有确凿的理由外，我们不会轻易调整优先级和时间节点。

三、待开发阶段

有了确切方案后，要尽快跟研发的同事做可行性评审，这一步必不可少。如果缺少可行性评审，将会出现很多产品设计方案可行性差、需求频繁更改、产品功能不切实际的情况。

在可行性评审上完成的是对需求的大致评估，要做的有以下几件事情：

1.方案本身的可行性

在技术方案上是不是能够完成？这是技术部门的同事要评估的问题。对于可行性评审里的方案未必是很精确的，所以要引导他们提出对方案实现细节的问题，一起弄清楚可行性。

2.有没有更好的方案

要跟技术部门灌输清晰的需求背景，让他们也基于当前的方案去思考是否有更多可行的方案。方案未必能很快想得完整、周全，但他们提供的思路一般是可行性较高的。

3.涉及的产品和技术环节有哪些

同样，要配合技术部门的同事判断会影响到哪些环节。尤其是很多公司产品线比较多，有可能存在牵一发动全身的情况，如果相关的产品同事和技术同事不知情，必然会延期，然后会扯皮、造成麻烦。再小的产品一般也会分前后端，所以要让技术的同事来判断有哪些人需要知情和参与评估。

4.方案的成本如何

看方案需要多少人、多少资源、多少时间来完成，也要看方案在技术层面耗费的不太明显的成本，比如服务器成本、带宽成本给用户造成的流量成本等。

这些讨论结束，会议就能够输出相对比较严谨的可执行方案（或草稿）了。注意，如果会上遇到各种问题需要改日再评，也要确认解决问题的时间节点。

四、开发阶段

开发需求的次序，未必完全按照需求池里的需求优先级进行。前文提到，在可行性评审会上，我们会核算大致的需求成本。接下来就是拿成本结合需求的优先级得出该需求的性价比。

以在做上门美甲的产品为例，作为产品经理可能同时要面对很多需求，如下所述。

来自老板的：

• 实时记录美甲师的GPS（要解决刷单的问题）

• 首页有点杂乱，不够简洁（纯粹视觉上的问题）

来自运营的：

• 要统计用户对每个Banner的点击率（看活动结束后的效果）

• 秒杀功能（下周就要做活动，通知发出去了，必须做）

• 需要提供给用户在线改单的功能（比如换样式，补差价）

• 提供私人订制的功能（包括用户上传图片、美甲师提供参考价、双方确认等步骤）

来自产品的：

• 用户下单时，支付失败后需要重新下单，不能继续支付，应做优化

• 下单步骤要跳转太多页面，应该集中在一页输入信息

• 根据关键词筛选样式的功能

这些需求结合我们在之前评估的重要紧急程度，设定的优先级如下（P1、P2、P3优先级由高到低）：

• 记录GPS：P1（记录GPS是为了防刷单，不然公司损失巨大）

• 首页简洁：P3（相对来说并不重要）

• banner点击率：P2（对运营安排活动有重要作用）

• 秒杀功能：P1（通知已经给用户了，必须做）

• 在线改单：P2（现在是人工后台改单，运营人员特别不方便，消耗大量人力成本）

• 私人订制：P3（订制用户较少，不着急）

• 可继续支付：P1（体验差，无法忍受）

• 简化下单步骤：P2（大大提升体验，但目前可以接受）

• 筛选：P3（目前的分类功能比较完善，筛选是补充）

总结完需求，按照优先级分类，如图8-4所示。

image.png

再根据之前在可行性评审会后跟开发的同事们讨论出的实现成本，我们也有个大致的排序（D1、D2、D3按照实现成本由低到高排序）：

• 记录GPS：D1（定时记录GPS，并不复杂）

• 首页简洁：D3（排班布局会耗费大量时间）

• banner点击率：D1（注入log，很简单）

• 秒杀功能：D1/D3（可以分简单和复杂两个版本上线，难度不同）

• 在线改单：D2（功能交互比较复杂）

• 私人订制：D3（同样是功能交互复杂）

• 可继续支付：D1（页面改动少，主要是调试接口）

• 简化下单步骤：D2（还是功能交互比较复杂）

• 筛选：D3（后台逻辑需要做大的改动，数据处理也很麻烦）

整理后，按照需求成本分类，如图8-5所示。

image.png

然后，可以把P序列和D序列做成矩阵图，如图8-6所示。

image.png

而有了矩阵图我们就可以从性价比由高到低的顺序，依次完成需求了。如图8-7所示，可以参考按照从1到9的顺序。

image.png

按照工作量确认了本次迭代的需求，提交开发之后，要关闭本次迭代的需求。也就是说，原则上本次迭代不再加入新的需求。

在开发中，“扯皮”的问题归纳起来有三种：需求太多，没按时做完；需求有改动，导致了额外工作量，引起开发人员的不满；有新的紧急需求，导致发布延期。

导致出现这三种问题的原因如下。

1.产品方案不完整

方案不完整往往是没有考虑全面。这个跟需求管理本身没关系，就是在出方案的过程中看能不能把事情想全。

经常出现这样的情况，在实际开发的时候技术人员才发现某个逻辑没想通。再喊产品经理来一起讨论的时候，大家才发现需要加一些功能才能完善逻辑。最终结果就是周六加了个班，大家都很不开心。

这种事情也不好追责，毕竟参与者众多，流程拖得很长。

对于这种情况，各个流程中的环节都要做一些调整，才能确保最终产品方案的完整。

分析需求时，先梳理逻辑再出方案。能画流程图的画流程图，能画逻辑图的画逻辑图，能画脑图的画脑图，穷举整体的逻辑。

讨论方案时，所有产品经理参与小组讨论，一起提出疑惑，发现问题。

在做可行性评审时，技术人员要尽可能从逻辑角度提出质疑，多发现问题。

之后再出问题，会回溯原因。如果是前两个环节出的问题，那就是产品经理的责任；如果问题出在产品经理并不熟悉的技术逻辑，那就是在可行性评审中技术同事的责任。

2.需求方的主观改动

这种情况基本上是需求方或者产品经理的问题，他们在提交方案前没有完全想清楚。有时候都开始开发了，业务部门来人说：“我们发现这个问题好像不存在了，大家不要做了”。他们觉得无所谓，还减轻了开发人员的负担。但对技术部门的同事来说就好像是被耍了一样，过去的工作一下没有意义了，造成的影响是恶劣的。

产品经理在对接业务方或者其他同事的需求时要做判断，他们是不是完全想清楚了：是灵机一动的小点子，还是不得不解决的问题。

有一种情况是需求方跟产品经理对接时出了问题。表述有误并且方案没有跟他们核对清楚，结果产品功能上线后，才发现并没有解决问题。

另外，还有一点建议之前也提到过：要在需求（比如具体方案、时间点）发生变化时，跟需求方同步。让他们知道我们的情况，也获取他们的意见和建议。图8-8是一种需求同步流程的示例。

image.png

3.无法预测的客观原因

无法预测的情况导致需求的变动引起一些问题，是客观上唯一能够接受的原因，不需要有谁承担责任。比如，本来要做一个功能狙击对手，结果做到一半时竞争对手倒闭了，那么这个功能就没有意义了，此时功能确实要废除。还有一些业务上的确无法预测的原因导致原本存在的问题不存在了。

在这种情况下，作为产品经理最重要的是安抚技术的同事，尤其是跟他们解释清楚背景和详细的原因，不要让他们误以为是产品和其他部门的同事办事不力造成的。

五、复盘阶段

需求从获取到上线走完生命周期之后，还要有一个很重要的复盘阶段，尤其是在需求管理出过故障和问题的时候。

负责任的团队都会有复盘的机制，主要是防止问题再次发生。解决问题很简单，完全规避下次再出问题则很难。要清楚之前出现问题的所有逻辑和流程，再去看在哪些环节可以做些什么，以防止问题再次出现。

成长建议Ⅷ

从文档撰写到需求管理，一般都不是新手产品经理感兴趣的，毕竟看起来远不如创造一个点子、发明一个产品、设计一个界面更有趣味。

可是能够把产品做好成为称职的产品经理，文档撰写和需求管理反而是更加重要的。在实际工作中，如果真的有巨大的工作量，那么好的文档格式、好的需求管理方法能够减轻很多负担，让产品经理可以有精力来更关注产品设计。

要点反思

• 每个需求为什么在目前的位置和状态，产品经理应当了如指掌。

• 需求的各种变化、调整和意外，应该同步到整个团队。