“满足用户需求”是所有产品经理，乃至所以企业奉为圭臬的一句Slogan。围绕用户需求，产品经理需要从获取开始，历经识别、分析、分类整理和跟进等步骤，才能将需求在产品中落地。本文即围绕需求管理的全流程，对该项工作进行的全面总结。
需求管理在产品设计中，是非常重要的一个管理环节。每个公司、每位产品人都有自己特有的管理思路，它会随着每个人的工作年限、项目经历逐渐进行演化改进，没有固定的范式，故将本文命名为“V1.0版本”，以示对“需求管理”这项工作的探索永不止步。
01、需求获取
本章重点介绍了需求的获取方法，及通常情况下的需求来源。
1.1 需求的获取
本节介绍的是获取需求的方法，结合笔者工作经历和相关阅读学习，总结了以下五种获取方式：
（1）用户访谈
用户访谈主要有两种形式：面对面访谈（开放式）、用户观察（实验室观察、自然观察）。
（2）问卷调查
问卷调查即采用一问一答的形式，对用户偏好和诉求进行汇集。
（3）业务提炼
由业务专家牵头，从真实（或理想化）的业务场景出发，提炼出需求细节。
（4）逻辑推演
结合产品设计规律和特点，从产品逻辑上推演出可能出现需求点。
（5）竞品分析
对直接竞品（产品功能和用户群体大范围重合）、间接竞品（部分产品功能和用户群体重合）进行市场和产品方面的调研分析。
1.2 需求来源
除了上述介绍的用户访谈、问卷调查、业务提炼、逻辑推演和竞品分析五种需求来源，还可以对需求来源进行如下分类：
- 按照角色：一线用户、业务专家、产品经理、市场或销售
- 按照场景：线下真实业务场景、理想化的业务场景、借助计算机软件能够规范化/高效率处理的场景、用于提高产品商业价值的场景
02、识别“伪需求”
所谓“伪需求”，即不能够或不可以在软件开发中实现的需求。任何一种来源的需求都有其内在的局限性，或不符合产品设计逻辑、或不具备开发条件、或不能被所有角色认可，或不符合市场发展规律。
一名资深产品经理最了不起的能力就是能够快速识别伪需求，这背后依靠的是项目经验积累、业务理解层次，以及对市场的准确理解力等。但如果辩证地看，这也是部分资深产品经理容易陷入惯性思维和创新桎梏的原因所在。
如何来识别“伪需求”呢？下文提供了一份不完全清单对照说明：
（1）用户侧：
- 是否满足用户需求？
- 是否有真实的场景还原？
- 用户对需求的看法？
- 新需求对用户的影响？
（2）产品侧：
- 新需求与现有产品的关系？
- 新需求涉及哪些功能模块？
- 新需求是否改变产品现有逻辑关系？
- 新需求会否对产品性能产生影响？
（3）市场侧：
- 新需求能否引起市场的注意？
- 新需求的市场认可/欢迎程度？
- 市场对新需求的预期效果？
- 新需求会否对产品带来显著价值提升？
（4）技术侧：
- 新需求是否涉及系统架构变更？
- 新需求是否用到企业当前未涉猎的前沿技术？
（5）企业侧：
- 新需求对企业人力、财力、物力的要求？
- 新需求对企业组织架构的要求？
03、需求分析
第二章通过一份清单，列出了产品经理在接到需求时要考虑的一系列问题，相当于需求分析的简化版。本章着重介绍需求分析的流程和具体分析项。
3.1 需求分析的流程
简而言之，需求分析即是，借助UML图例（流程图、思维导图等）、原型等可视化表达方式，将需求进行拆解与重组设计，以此来明确该项需求是否满足开发条件，同时，通过多方参与的沟通和讨论，明确需求细节的定义和需求开发的边界。
（1）过程层次建模
过程层次建模即是对需求的拆解。因为从外部获取到的需求大多是模糊的、宽泛和抽象的，需要产品经理对需求进行拆解、细化，UML用例图是较好的一种表达方式。但在需求分析的初级阶段，一般不需要对需求进行特别细致的拆解，借助思维导图来体现需求及其分支的层次关系即可。
（2）业务流程建模
业务流程建模即是对用例的流程化重组。对需求进行拆解后的用例或功能点必定是散乱的，需要产品经理对这些用例进行编组和建立逻辑关系，UML活动图是较好的表达方式。通过业务流程建模，不仅可以理清当下需求的业务逻辑，还可以将其放置在系统整体的业务结构中，从而判断该项需求是否与原系统存在冲突，需要与之交互的功能模块有哪些。
（3）分角色（泳道）建模
分角色建模最好的表达方式是泳道图，也即对上述两项分析的综合。通过泳道建模，来体现新需求涉及到的用户角色、模块间交互和需求内在的逻辑关系。
笔者在第二章提到，优秀产品经理最厉害的能力就是能够快速判断”伪需求“；换句话说，他可以快速对需求进行分析和判别。这种能力依托的就是上述三种建模思路——过程层次建模（拆解）、业务流程建模（逻辑组合）、分角色泳道建模（复杂度评估）。这也是产品岗位重视逻辑思维能力的重要原因，即无需借助手工建模和画图即可在脑海中演化出需求最终的样子。
下文是从「需求之外的角度」进行的分析——当产品经理把需求的逻辑跑通，并确定了复杂度后，需要界定出需求的边界：该不该做，该做哪些，不该做哪些？
（4）产品商业规划：系统需求的确定
需求从功用性方面进行分类，可分为系统需求、功能需求和非功能需求。
所谓系统需求，即是否满足公司对产品的商业规划。如果不满足，主要有五种情况：
- 超出公司业务范围；
- 公司没有把该类需求纳入近期开发计划；
- 开发难度大，或不在合同范围内；
- 与已有产品存在重叠或矛盾情况；
- 需求风险过大。
这几种类型的需求并不代表不可以做（流程跑不通的需求才不能做）！换句话说，假如你的需求正好属于以上几种类型，你可能需要付出多倍的努力，才能把这项任务提上开发议程。
（5）头脑风暴：功能性需求和非功能需求的确定
业务与开发永远是一对不可调解的冤家，业务永远觉得开发很简单，开发永远觉得业务提需求不过脑子，更何况有时还会夹杂一些两边都不求甚解的人。但正是因为各类干系人关注的侧重点不同，才使得需求讨论变得有意义。
我们可以通过头脑风暴或类似的多方会谈来决定对需求的准确定义：属于功能性需求，还是非功能性需求。分别由业务人员和开发人员充当会议的主要发言人。如果主持得当的话，还能顺便得出开发难度、投入和周期等信息。
（6）原型输出
原型输出一般是需求分析的最后一个环节。即当需求的原貌被各类流程图、思维导图、界面草图、会议文档充分还原后，再开始着手准备，与之伴随的往往还有PRD需求文档。理由是，若先画原型，必定会面临无数次的推倒重来。
到此为止，需求分析的流程已经基本介绍完毕。诚如文章开头所言，每个人都有自己的工作方法，在实际操作中，一般不会严格按照这个顺序或这几项内容进行分析，往往都是同步进行。但宗旨只有一个：判断需求的可行性、复杂度及商业价值。
3.2 需求的具体分析项
本节与第二章<识别“伪需求”>有部分重合，但也说明，识别“伪需求”也属于需求分析的一部分。
（1）可行性
单纯从需求实现、满足用户所需、产品兼容性方面考虑，该项需求是否具备可执行性。即通过上述的过程层次建模和业务流程建模实现。
（2）复杂度
从涉及外部的用户场景、角色类型，以及系统内部的数据库表结构、功能交互、模块交互等方面，确定实现该项需求需要投入的人力、财力、物力。
（3）商业价值
商业价值从小范围来讲，要知道该项需求是否在合同或项目需求范围内，也就是说，是否已经有人为实现此类需求而买单；从大的方面来说，该项需求是否符合产品开发计划、上线后多久能够收回开发成本，对已有产品的帮助有多大。
这里需要引入财务领域的一个“损益试算”概念，也叫“预计损益”；它原本是为了揭示企业在未来某一期间的损益情况，由销售预算（收）、费用预算（支）、成本与毛利核算等编制依据组成的一张财务统计表格。财务人员除了会借助这张表计算企业的损益情况，有时也会深入到项目，对项目甚至项目节点进行损益预估和评价。
笔者认为，产品经理虽然无需掌握如此精细的财务核算方法，但需要有类似的工作理念，即填补财务人员不懂业务的缺漏，把成本核算精确至每一个需求点的确定。顺便提一句，这就是理想状态下的业财融合。之所以不容易实现这个“理想”，最大的障碍就在于财务不懂业务，产品经理不懂财务。
综上，本节的重点在于评估需求的商业价值，具体的实现方式是进行损益试算，具体包含成本预估和营收预估。借助财务相关的解释，是不是一下子清晰很多？至少把分析的骨架给搭出来了。
04、需求池（需求管理）
前文介绍均属于需求分析部分，偏抽象；真正的需求管理通常都是从需求池开始的，因为它是具象化的，能够转化成一套标准的工作流程。本章主要介绍三个部分：需求池的创建、需求池的进出标准、需求的分类与标记。
4.1 需求池的创建
大部分产品经理在平时工作中都有“需求池”的概念，区别在于工具使用的不同：有的借助ONES Project等专业的协同管理工具，有的用ToDo工作法，有的用Excel手工统计。无论哪种方式，其目的都是用来协助自己高效管理来源丰富、类型多样、状态复杂的需求项。
从这些工具的使用中，其实可以抽象出一套标准化的工作流程，即：获取需求、需求分类与标记（包括优先级判断）、需求审批、需求分配、需求跟进、版本规划等。因此，在创建需求池时，要能够适应这些活动的执行。
具体该创建一个怎样科学规范的需求池，笔者建议直接照搬ONES Project这类专业化的协同管理工具，因为既然能够把需求管理的这些过程在系统中实现，就一定具备可执行性。（这里是为了偷个懒，少写点早就研究透的内容）
4.2 需求池的进出标准
创建完标准化的需求池模板，下一步要做的就是制定一个进出标准，从而决定什么样的需求该进来，需求进行到何种程度意味着结束。这就又是一个偏抽象的经验活了，普遍采用的原则是：有进有出、宽进严出。这个原则不是我发明的，是从前辈那里听到的，很有普适性。
简单点说，把产品经理所能收集到的需求全部纳入需求池中，然后严格审核，确定最终决定实现的那一个。这样做的目的是为了避免因主客观因素误导，忽视不起眼但有价值的需求；同时也是为了避免有漏网之鱼，不合时宜地闯入近期开发计划中。产品经理也可以借助需求池，来逐一思考每个需求的可行性，避免遗漏。
4.3 需求的分类与标记
分类与标记是对需求进行科学化、精细化管理的基础。能否准确分类和标记，直接决定了该项需求的命运。
（1）需求编号
确保需求的唯一性。
（2）归属产品
需求属于哪个产品线、业务线。
（3）涉及功能模块
涉及产品额哪个模块、哪个功能。
（4）需求类型
- 系统需求、功能需求、非功能需求
- 新增需求、优化需求
（5）需求来源
- 客户、企业内部
- 一线用户、业务专家、实施、产品、开发……
（6）需求质量
需求质量评估，采用权重系数计算法。
（7）紧急程度
紧急程度评估。
（8）优先级
根据需求质量、紧急程度进行优先级评估，从而确定需求开发计划或产品版本规划。
05、需求跟进
需求被各方干系人认可后，即进入需求跟进阶段。在跟进需求前，仍有两步涉及沟通的工作要做：需求审批和需求分配；另外是在需求跟进过程中，还要根据需求的排期确定产品迭代规划（也可以是根据产品迭代规划确定需求排期）。
5.1 需求审批
需求审批是赋予该项需求“合法性”的依据。无论在头脑风暴、需求讨论会上，各方干系人做出多么一致的决定，最终都必须由客户或项目经理来签字确认，这也是需要产品经理撰写尽可能详细的PRD文档的原因之一。原因有二：
- 开发人员不可能面对业务方无休止地需求变更，产品经理需要靠签字确认来确保自己和开发人员处于“受保护”的状态；谁来“破坏”这种平衡状态，谁就要承担相应的风险，例如进度延期、增加人工成本等等。
- 业务人员需要依据签字审批通过的需求文档，来对开发成果进行检验，避免因开发和测试人员工作疏忽导致的需求依赖。
换句话说，严格的需求审批意味着界定各个部门对需求的责任范围，使之更好地完成需求落地。
5.2 需求分配
需求分配的含义类似于由项目经理牵头组建团队。有哪些开发、测试或产品人员处于“闲置”状态，他们分别可以在什么时候参与需求开发，分别负责哪些功能模块。
具体如何分配，一般由研发人力资源安排表来决定。研发负责人会统计每位研发人员近期的计划安排，通过计划安排表和他对每个部下的了解程度，来确定每个新需求任务分别由谁来参与。
5.3 需求跟进
（1）甘特图
（2）ToDo工作法
（3）每日站会/周会
（4）友好的日常交流
（5）多部门协作
5.4 版本规划
版本规划通常与需求排期的关联比较紧密。可能是先出需求排期，再出版本规划；也可能是先出版本规划，再出需求排期。总之，二者需要结合需求开发计划进行适时匹配，以便应对客户的诉求。
关于版本规划，需要关注以下六个要素：
- 版本号
- 版本包含的需求点
- 版本上线日期
- 发版负责人
- 紧急召回（回滚）计划
- 验收方负责人
