需求系列（一）——需求处理流程

B端产品周翔 2023-07-26 15:38:25

产品经理日常的主要工作都是围绕需求展开的，每天为它抠破脑袋，只为开发哥哥们少点烦恼，用户爸爸们多点快乐。想清楚了，皆大欢喜；没想清楚，咏春叶问。

在后面的这段时间里，我将以一个系列的文章来分享一些自己对需求的认识，希望能帮助到还未能系统认识需求的同学。

作为本系列的第一篇，我们先聊聊常见的需求处理流程，后续文章将以此流程为框架，逐条展开。

需求系列（一）——需求处理流程

一、需求获取阶段

在需求获取阶段，需要做好收集和管理两件事。

这些需求既有产品经理主动挖掘的，也有从用户、运营、业务方、领导等渠道被动获取的，无论哪个渠道来的需求，都需要有一个正式的地方进行管理，也就是我们通常所说的需求池。

不过，对于多方关注的重点需求，通过需求池来向各方同步就不太合适了：

一是因为需求池内容太多、太杂，向业务方、领导汇报的时候会有很多干扰信息，难以快速抓住重点；
二是因为需求池里面可能有些需求不适合完全公开。

这时我们就需要使用《事项跟踪表》来单独跟进，形式上用Excel、PPT都可以。

而放在《事项跟踪表》里的需求，也要在需求池里记录下来，即需求池是做全量需求管理的，《事项跟踪表》是做重点需求跟进、汇报的。

二、需求分析阶段

1. 分析内容

需求分析主要从需求要素、定位、分解、优先级四个方面进行。

1）需求要素分析

需求要素分析是从需求本身出发，不考虑其他因素。

这些要素包括：内容、用户/角色、频次、价值、场景-动机、强度六个方面，这些要素的含义大家应该都比较清楚了，这里说一下分析各个要素的目的是什么：

分析需求内容，是为了弄清楚需求是什么；
分析需求用户/角色，是为了弄清楚需求为谁服务；
分析需求频次、强度，是为了弄清楚需求对用户的重要性、紧迫程度；
分析需求场景-动机，是为了弄清楚需求真伪、用户目的，更深入的理解需求；
分析需求价值，是为了弄清楚需求值不值得做。

2）定位分析

需求的定位分析是分析需求对产品当前阶段目标的意义。

分析需求的定位，有以下两个目的：

一是作为优先级排期的判断条件之一，如果需求与产品当前阶段的目标密切相关，则需要作为高优先级上线；
二是为了框定需求范围。每个需求的实现程度都有深有浅，可以很简单，也可以很复杂，了解了需求之于产品的定位，就能判断需求要做到什么程度。如果一个需求对产品很重要，那就需要做得很丰富，如果只是辅助需求，则需要适当轻量。

3）需求分解

原始需求的颗粒度往往较粗，不利于后续的分析、设计、开发等工作，所以我们需要对这些颗粒度较粗的原始需求进行分解，分解为一个个完整、独立、可实现的子需求。

4）优先级分析

优先级分析是以拆解后的子需求为单位进行的，根据各类优先级的判断方法、原则，初步评估各个子需求的上线顺序及时间。

2. 常见问题

需求分析应该是大家从入行那天就知道要做的事，但大多数同学在做需求分析时会犯以下三个比较常见的错误。

1）缺乏系统性

这是在分析中最常见的问题，即很多同学在分析需求时没有系统性的框架，导致很多方面没有分析到、考虑到，从而对需求认识不全面。

2）缺乏深度

对需求某些要素认识比较浅，不够细致深入，例如在分析需求的用户时，没有对用户分层、切片，对各个分层的用户也缺乏足够的了解，导致对用户只有一个笼统、模糊的认识，最后自然无法深入进去。

不过分析是否有深度的定义其实很难把握，也缺乏明确的判断标准，需要随着分析者思维能力的提升、信息量的提升来加强。

3）忽略顺序

在上文列举分析内容时，其实是有分析顺序的，即需要有前面环节的分析结论，才会有后面环节的分析基础。

当需求分析清楚后，我们就可以针对高优先级的需求设计产品方案了。

三、方案设计与分析

1. 方案设计

设计需求方案既可以自力更生、独自设计，也可以借鉴其他产品同类需求的方案，两者本没有好坏对错、也没有所谓的创新与抄袭之争。

产品经理最重要的职责之一，是分析清楚需求后，找出最适合这个需求的满足方案，而不是纠结这个方案出自何处。

2. 方案对比

任何一个需求的满足方案都不会只有一种，至于选择哪一个，则要考虑很多因素，所以我们需要从多维度对比这些方案的投入产出比，以此来尽可能的选出所谓最优解。

评估方案投入相对比较简单，也容易量化，主要包括时间成本、人力成本、资金成本、机会成本，但方案的产出则难评估得多，一个方案：

最终产出=价值-负面影响

结合这个公式，评估方案产出的难点主要有以下几个：

1）价值标准难选取

哪个方案带来的价值更大，取决于我们以什么标准去衡量它，但这个标准有时候并不好找。

2）部分标准难量化

在选取的评判标准中，有些是无法量化的指标，这些指标所体现的价值就无法客观判断。

3）部分标准主观影响大

对于无法量化的指标，就需要由人主观判断，这样结论就与评判人的主观想法密切相关了，有时候也会屁股决定脑袋。

4）需要逆向评估

方案大多都是有利有弊的，除了正向评估方案价值，还要逆向评估其所带来的负面影响。这个方案对某些用户可能是有价值的，对另外一部分用户可能是种打扰。

5）价值、负面影响不确定性大

相比于成本的预估，价值的预估则要困难很多，因为不确定性太大，影响因素更多，且大多没有可借鉴类比的经验，说得好听叫预测，说得不好听就是“听天由命”。

所以，所谓的最优解是一个美好的愿望，我们真正能做的是在当时条件下，基于自己有限认知做出的自认为最合理的决策。

3. 依赖分析

有些方案看起来很美好，但如果没有必要条件的支持，那也只能停留在纸面上。

所以我们需要将备选方案的内部、外部依赖条件分析清楚，以判断这些方案需要哪些支持、谁能提供、提供数据能否满足要求、提供时间、提供方式等，进而提前做好准备。

以上的对比、分析，并非全由我们独自完成，而是需要作为牵头人，找到相关方，如技术负责人、依赖方，合力解决，从而选出一个最终方案来满足我们的需求。

4. 方案初评

选择方案后，需要就下个迭代的内容与前后端的技术负责人做初步评审，解决明显的障碍和问题，节约后面正式评审的时间。

四、需求上线阶段

1. 方案评审

需求上线前，先要进行我们常说的需求评审，不过从产品经理的视角来看，这个应该叫做产品方案的评审，所谓需求评审，是从开发视角来讲的。

在方案评审时，需要做好四件事：原始需求说明、方案讲解、方案评估以及工作量评估。

原始需求说明是指向开发团队介绍经过分析后的需求要素，目的是为了让开发小哥们更好的理解需求，更有代入感，以免实现歪了；
方案讲解即介绍满足需求的方案，这是开发同学最关心的事情。有时候开发小哥们在理解了需求的情况下，可能会提出更好的方式；
方案评估是从实际开发人员角度评估方案的可行性、风险、成本，在方案设计阶段，我们虽然与前后端技术负责人做了初步评审，但粒度比较粗，且评估人不一定是一线开发人员，所以可能有些细节没有注意到，此时我们就要更深入、全面的进行评估；
工作量的评估是通过量化的方式评估迭代需求总量，有利于开发团队合理规划迭代的开发时间。