开发人员如何做好需求分析梳理（B端产品的需求管理与迭代优化）

本篇目录：

原始需求与产品需求

• 区分原始需求和产品需求
• 原始需求提报管理

产品需求的层次和价值

• 需求的三个层次
• 需求的四类价值

需求池管理

需求的优先级

• 成本价值模型
• RICE模型
• 价值范围模型
• KANO模型

需求的验证和评估

• 通过拆解指标评估业务需求收益
• 通过NPS评估用户需求收益
• 通过综合方案评估技术需求收益
• 终极衡量指标：考核使用人数

迭代中的研发资源管理

• 研发资源的人力跟踪
• 产品不同发展阶段的技术资源投入

产品上线后，需要进行持续的升级、迭代和优化，产品经理要管理需求，区分优先级，决定工作计划，选择做什么和不做什么。

这篇文章，我们进一步深入的探讨B端的需求管理和迭代优化工作，首先介绍原始需求的收集和管理；其次讨论产品需求的分类、层次和价值，接下来聊一聊需求池的管理，同时还会深入探讨需求的优先级设计问题，最后分享需求验证的一些思路，以及持续迭代中技术资源的合理分配。

原始需求与产品需求优化

原始需求和产品需求是需求分析、管理工作中最基础重要的概念，我们首先需要明确两者的定义和区别。

区分原始需求和产品需求

不论是产品经理通过访谈、问卷收集的，还是业务方、用户主动提报的需求，都是原始需求，原始需求中可能夹杂了若干混合的诉求，既可能是痛点描述，也可能是用户提出的解决方案。原始需求是终端用户/客户提给产品经理的诉求描述。

产品经理通过分析挖掘原始需求，找到痛点，形成软件产品设计方案，从而形成产品需求，产品需求是颗粒度清晰、逻辑严谨完整的产品诉求，是产品经理提给研发人员的软件设计方案。

原始需求是最原生态的需求描述，充满了不确定性；产品需求则是分析问题后的的解决方案（或初步的思路拆解），具备确定性。原始需求在处理过程有可能被拆解成多个产品需求，也可能与其他原始需求合并变成同一个产品需求，原始需求和产品需求是多对多关系，产品需求会对应多个研发任务和测试任务，逻辑关系如下图。

原始需求和产品需求的关系

例如，M公司分销平台业务中，业务运营同学提交了一个原始需求，希望支持品类券（针对特殊品类生效的优惠券），并且发券数量超过1000张需要触发审批。这个原始需求里边包含了两个需求，一个是增加新的营销工具（品类券），目的是提高客单价和收入；另一个是审核规则，目的是控制风险。

果冻分析后，将这个原始需求拆解为两个产品需求，分别是品类券需求和审批流需求，其中审批流需求合并到规划中的流程引擎项目中，构建一套完整的审批解决方案，品类券需求提交研发后，研发根据功能feature又创建了多个研发任务，包括：

• 任务一：品类券在商城前端的展现（包括购物车、订单、个人中心等位置）；
• 任务二：品类券在后台的管理配置功能（包括列表页、创建编辑页）；
• 任务三：品类券的发放提醒功能（这部分可能会调用现成消息接口）；
• 任务四：品类券在交易结算中的分摊逻辑，以及台账和财务处理规则；

实际研发任务拆的会更细致，以上仅仅是示意，而且以上拆分的颗粒度，依然是功能点级别，每一个功能点背后可能还要对应多条研发任务。

可见，原始需求并不直接等同于产品需求，产品经理需要完成原始需求到产品需求的转换设计。

我们在前面文章介绍的需求分析十三要素五步法，就是对原始需求的分析过程，而其中第五步设计产品方案，输出产物就是产品需求。

在口头交流中，为了方便，我们往往将原始需求和产品需求混在一起讨论，不会做严谨的区分；例如，当我们说“这个需求优先级不高”，这句话说的既可能是原始需求，也可能是产品需求。但在正式的需求池管理中，一定要对两者进行区分，否则会带来管理和执行上的混乱。

原始需求提报管理

不论是甲方做对内系统的产品经理，还是乙方做商业化的产品经理，都会面临一个比较苦恼的问题，业务方或者客户，总是提一些一句话的拍脑袋需求，很多时候根本没有想清楚，但也会耗费产品经理大量的时间去沟通核实。

为了避免用户不经思考随意提需求带来没必要的资源损耗，可以考虑让用户通过填写需求提报模板来提交需求，促使用户提需求前把一些关键事项想明白，提高需求质量，尤其适合甲方公司。（乙方公司面临的现实情况是需要更好的主动服务客户，如果让客户通过模板提需求估计老板也不同意啊！）

具体模板见下表，内容很容易理解，此处不再赘述，可以根据自身情况调整后使用。再次强调的是，任何需求，都应该提前想清楚需求价值，以及上线后如何衡量价值是否实现，并依据效果做持续的闭环优化跟踪。不论是谁发起的需求，都应该提前想清楚需求的预期收益和度量方式。

原始需求提报表

需求编号	BRD_业务部门缩略编码_yyyy-mm-dd 新需求：此部分由业务人员填写 需求变更：此部分由业务人员填写，需要写明原需求编号
需求名称
提交人			业务负责人
提交时间			期望上线时间
优先级	采用公司统一定义的项目管理优先级定义，例如高、中、低
问题描述	业务中遇到的问题，需要清晰、详尽
期望目标	期望解决哪些问题，或改善哪些指标
预期收益	预期获得的收益，尽量用客观数字描述
期望解决方案	期望的问题解决方案
期望上线日期	yyyy-mm-dd
存在风险	预计需求背后可能存在着的各类风险，包括业务风险、商业风险
相关部门	干系人1	收益/影响
	干系人2	收益/影响

产品需求的层次和价值

产品需求，从软件工程角度来讲，可以分为功能需求、非功能需求；从需求背后的业务价值和分类的角度来讲，又可以分为业务需求、用户需求、技术需求，这也体现了B端需求的三个层次。

需求的三个层次

在C端产品设计中，常常将马斯洛模型作为C端产品需求洞察的理论基础，并依此推演C端产品的用户价值，以及进一步延展出用户旅程、KANO模型等一系列构建C端产品设计的方法论。遗憾的是，这些模型和方法论并不完全适用于B端产品设计与需求管理，主要基于以下原因。

• B端产品面向企业或组织，帮助其解决某类经营管理问题，对于机构来讲，需求的本质在于业务管理，无法通过马斯洛模型来定义描述。
• B端产品的关注对象，除了机构本身，也需要关注业务用户，而业务用户的需求动机也并非马斯洛模型可以解读。
• B端产品作为复杂系统，除了承载业务目标，还需要考虑软件架构设计、体系构建等问题，因此需求分析管理中，对于软件产品本身还需要有足够的关注度。

基于以上所述，可以发现，B端产品的需求来源和场景复杂，很难像C端产品那样基于马斯洛模型从单一维度去覆盖需求洞察的工作，而需要从几个维度分开来审视B端的需求类型和层次。

实际上，我们可以将B端需求分为三大类，分别为业务需求、用户需求、技术需求，这三个类别本身由上到下具备层次关系，每一类需求处理权衡时都有不同的考量。

业务需求

业务需求，是自顶向下的需求，往往来自于中高层管理人员（或监管、政策要求），基于业务运营管理的直接诉求和要求，例如业务规则、管理制度、业务流程、组织机构，这些都属于业务需求。

业务需求的分析过程，往往采用了经典传统的软件需求分析设计思路，重点通过业务诊断分析、抽象建模（DDD设计思想）、流程再造（BPR）的方式，进行需求分析和设计工作。

业务需求，承载了B端产品的业务价值，为相关业务的运营管理助一臂之力。注意这里所说是业务价值，而非商业价值。商业价值往往要上升到企业的层面，而B端产品多数情况是为单一业务部门服务，承载的更多是业务价值。

业务需求，多数情况下难以衡量具体的收益，例如，很难衡量设计开发了某个CRM管理模块，就会对销售业绩有多少程度的提升；即便如此，产品经理也要尽量尝试量化收益和价值，关于几类需求收益价值的讨论，在本章第四节会进一步展开。

用户需求

用户需求，是自下向上的需求，来自于一线业务用户和基层管理人员，更多体现着业务人员对业务规则、流程、系统操作交互上的改进诉求。

现如今SaaS形态的B端产品都更加关注用户体验，其交互体验和操作流畅度要好于传统的管理软件。在梳理B端产品的用户需求时，可以大量借鉴C端产品的需求管理方法论，例如客户旅程地图，KANO模型等。

用户需求体现了用户价值。互联网思维下，即便是B端产品，也需要重视用户体验和用户价值，包括了功能满意度和操作效率等；尤其是工具型、基础服务类产品，解决了一线用户的痛点，就是解决了业务的痛点，产品赋能终端用户、重视体验就显得更为重要。

通过针对功能模块定期的满意度调研（NPS）可以较好的度量用户需求的满足情况。另外也可以从效率提升、时间节约的角度去衡量、评估收益。

技术需求

B端产品复杂程度高，建设到一定阶段，甚至有些时候在建设初期，就要考虑功能复用问题，以及与其他系统的架构设计与交互问题。例如，对于业务系统的权限管理模块，是复用基础服务，还是独立开发？对于消息中心和公告通知模块，是复用基础服务还是独立开发？除此以外，还有类似于软件产品功能完备性提升的诉求，例如灵活的后台配置模块，报表引擎的配置，视图编辑器的配置，这类需求，我们可以统称为技术需求。

技术需求往往不具备明显的业务价值（但可能具备用户体验价值，例如视图编辑器的能力构建），但是在软件系统结构合理性设计上，具备显著价值。除了让架构合理，还能节约重复开发的人力浪费。产品需求承担了软件的系统价值，为系统自身优化而服务，让系统自身合理并增值。

对于技术需求的收益评估，可以考核功能复用以及架构完善，对研发人力的成本节省。

业务需求、用户需求、技术需求，作为B端需求的三大类型，也体现出了层次关系。对于B端产品的核心目标，首先服务于业务，要满足业务需求；其次，要关注用户的体验和效率，满足用户需求；最后，要考虑软件结构的合理性，满足技术需求。

【资源推荐】

关于需求层次的更多分析，推荐贝恩咨询分别于2016年、2018年发表于哈佛商业评论（HBR）的两篇论文，探讨了基于马斯洛需求层次在2C领域的价值要素金字塔模型；以及借鉴马斯洛模型，尝试构建了2B业务的价值要素金字塔模型。

需求的四类价值

B端产品需求的价值可以从对内对外两个视角分为商业价值、技术价值、业务价值、用户价值四大类。

商业价值

如果是商业化售卖产品，我们首先要判断的是需求的商业价值，是否符合产品本身的定位和规划，是否遵循产品商业化售卖的战略诉求和经营要求。

例如，在M公司分销平台的SaaS化设计中，是否要实现销售型CRM模块，这就是一个涉及商业价值判定的决策，而非基于客户的业务诉求；从业务价值来看，销售管理对客户的业务是有益的，但从商业价值来看，该模块不符合产品定位，并且会泛化产品边界，扩大研发成本，稀释商业竞争力，因此我们不考虑实现它。

如果是对内使用的产品，商业价值是比业务价值层次更高的，从企业整体战略经营角度带来的价值。

例如，M公司分销平台的设计，首先是为了实现对分销业务支持赋能的业务价值，在更深的层面，则支撑了M公司期望实现多元化经营战略的商业价值的。

业务价值

B端产品除了承载商业价值，更需要帮助客户、用户在业务上取得成功，这是B端产品的业务价值。

我们在第1章讲到过，B端产品对企业来讲承担着提升收入、降低成本、提高效率、保证品质、控制风险的重任，这些都是B端产品的业务价值。

用户价值

B端产品本质上是为了解决业务问题而存在的，但设计过程中也要考虑终端用户的体验问题，包括是否能够提升一线效率和满意度，这是产品的用户价值。有些时候，赋能用户，其实也是赋能业务，提升了用户价值，也就提升了业务价值；例如针对协同办公类产品，提升整体使用体验，可以提高员工的工作效率，实际上也提升了企业整体的运作效率。尤其是针对工具型、基础服务型产品，提升了用户价值，也就提升了业务价值。

技术价值

软件产品在构建过程中，自身也存在技术层面的优化点，比如说，我们要将列表页进行支持自定义设置的改造，从而解决为不同客户三天两头硬编码修改列表页的烦人工作，这类需求是为了降低研发成本，或提升产品化能力而存在的；再比如说，为了解决企业客户重复的问题，我们需要将产品背后的应用架构进行主数据改造，这类需求是为了改善架构合理性而存在的；这些都是技术需求背后可能的价值。

以上需求的四类价值，不论是商业化软件产品，还是对内使用的产品，业务价值、用户价值、技术价值本质上都最终服务于商业价值；而需求的三个层次正好一一应对这三类价值。

产品规划建设过程中，四类价值的优先级并不是一成不变的，不同的产品阶段可能有不同的优先级策略。

例如，M公司分销平SaaS商业化的初期，要先解决客户的业务问题，需求的业务价值优先级高于技术价值。但随着客户数量的增大，一些交互层面的定制化需求越来越多，不支持，伤害用户体验；硬编码支持，又浪费研发资源。此时，技术需求的优先级可能就会提高，类似于自定义视图编辑器这种组件的设计需要被采纳执行，而这么做，是因为产品对业务的支持已经有很好的成熟度，需要加大产品化能力，强化配置能力，核心目的也是为了服务产品的商业价值。

小结

最后，我们通过一张图，来总结回顾需求的类型、层次和价值，如下图。

需求的类别和价值

对原始需求分析后，进行拆散或合并，形成产品需求。从软件工程角度来讲，产品需求可以分为功能需求和非功能需求，从业务角度来讲，又可以分为业务需求、用户需求和技术需求，这也体现了需求的层次，具有天然发的优先级属性。这三层需求也分别体现着产品的业务价值、用户价值和技术价值，最终都是为了服务于商业价值。

需求池管理

产品经理需要管理维护两个需求池，原始需求池，和产品需求池。

原始需求池记录了所有用户端提报的原始需求记录，产品需求池，是对用户需求经过初步分析拆解后形成的需求清单。

用户需求池体现的是从用户提报的角度来记录，产品需求池体现的是从产品管理的角度来记录。用户需求和产品需求应该有明确的关联，可以互相追溯，一方面方便用户从提报需求的角度理解相关工作的进展，另一方面帮助产品经理找到产品设计背后对应的原始需求轨迹。

原始需求一旦记录在案，更多的是存档保留，产品需求则可能被更新、调整。一旦产品需求形成产品方案投入研发，就会进入明确的项目管理周期。

有条件的话，需求池管理应该使用项目管理软件进行，但只要负责人用心，Excel同样可以管理好需求池。下边，我们来介绍一个产品需求池中典型的字段：

• 产品需求ID

需求唯一性主键。

• 原始需求ID

对应的原始需求编号，可以为多个。

• 产品线

描述需求所在产品线（或对应的业务线），例如CRM系统或客服系统等。

• 需求类型

需求类型应该做谨慎的设计分类，主要目的用来分析资源在不同业务方向上投入的情况。可能的需求类型包括业务需求、用户需求、技术需求，或者纯粹根据业务价值分类，包括：提升规模、降低成本、提高效率、控制风险、保障品质、体验优化等。总之，要根据自身情况设计一个合理的分类。

• 是否插队

用来专门记录需求是否在项目执行中做了插队执行的字段。

• 主题

需求的一句话概述。

• 内容

需求的具体描述。

• 来源

需求的提出人，或提出部门。这个数据可以来自于原始需求。

• 需求提出日期

收到需求的日期。有些公司会要求产研团队提高需求响应速度，可能会通过上线日期和需求提出日期的时间差来进行考核评估。

• 优先级

优先级会在下一节详细介绍。

• 迭代版本

如果采用了敏捷开发模式，就需要标记需求排期开发时的迭代版本。

• 业务负责人

该需求业务口的唯一负责人

• 产品经理

该需求对应的产品经理。

• 研发负责人

研发负责人一定是研发的整体负责人，而不应该分成后端负责人、前端负责人，因为那样很可能导致两者各自负责自己的工作，但是对于技术实现的整体方案和进度没有把控，相当于没有技术负责人。

• 测试负责人

如果研发负责人全权管理研发、测试工作，则不需要单独指定测试负责人。否则，要明确安排测试负责人，对质量结果和进度负责。

• 状态

状态用来描述需求的生命周期，状态值可以包括如下选项：

待跟进、需求调研中、PRD编写中、待PRD评审、待技术评审、待排期、待开发、开发中、待测试、测试中、待验收、待上线、已上线、暂停、终止。

这些状态值较好地覆盖了从需求采集到上线的完整生命周期，仔细观察后可以发现，这些状态的设计符合我们在介绍状态机图时提出的建议，即状态应该是能持续足够时长的，不应该是很快就结束的（所以我们没有定义“需求评审中”这种状态，因为需求评审只需要开几个小时的会议就可以完成，没有必要在开会前改一下需求状态，开会后再次修改）。

• 状态变更说明

对某些状态字段的补充解释，例如如果状态被修改为“暂停”，需要选择被暂停的具体原因。

• 计划上线日期

计划上线日期是在技术评审结束后，研发负责人确定工时和资源投入后给出的目标上线日期。

• 实际上线日期

实际上线日期是系统的真正上线时间。通过对比实际上线日期和计划上线日期，可以统计项目的延期情况，并进一步分析延期原因。

• 前端开始日期/前端结束日期

前端开发工作的开始日期和结束日期。

注意，工期和工时是两个完全不同的概念，工期是指开发时长，工时是指工作量。例如，为了开发某功能，安排了2名研发人员，从9月1日开始开发，到9月5日提测，则工期是5天，工时是10人日。如果这两名研发人员并不是同时介入的，其中一名研发人员是9月1日介入的，另一名在9月3日才介入，到9月7日提测，则整体工期是7天，但工时依然是10人日。

• 前端研发工作量（人日）

即前端开发工作预计投入的总工时。在敏捷开发中，可能通过基于经验的“点数”来评估工时。

此外，后端开发及测试的开始时间、结束时间、工作量，这些字段的含义与前面所讲的类似，不再赘述。

• 发版计划

在移动端产品中，需求上线可能涉及发版，即需要发布新的客户端，因此要在表格中记录发版的版本号。

合理运用上述模板，可以帮助产品经理将需求和项目管理得井井有条。认真填写模板中的各项内容，可以帮自己较好地分析需求跟进情况、研发效率、工作量投入等。

如果某个需求涉及跨端或跨团队开发，则需要按照子项目将模板进一步细化，例如每个子项目要安排各自的研发负责人、产品负责人，有各自的工时、工期等，然后再填写具体字段。

在实践中，并不一定在产品需求池中记录管理研发状态，有可能产品需求池只管理产品层面的需求清单，具体的研发执行，会通过另一个研发任务池进行管理。总之，根据自己团队的习惯和风格，或者公司的统一要求，选定一个模式或方案，持续执行，正确记录相关字段和内容，保证可以做出11.3小节那样的整体性分析，以便持续优化产研效率，就可以了。

需求的优先级

需求优先级的判断，是产品经理工作的一个难点。决策先做什么，再做什么，决定了产品的发展路径和节奏，甚至会决定产品在市场环境中竞争的优劣。遗憾的是，优先级的判断，在实践中，很难通过一套理性的方法论作为客观的执行依据，很多时候，优先级的判定是一门艺术，融合了对战略、市场、竞争态势、业务发展、研发资源、团队情况的综合判断。

即便如此，产品经理需要了解业界经典的优先级定义的方法论，在不同的场景和情况下，给自己更多的思路和启发。

成本价值模型

成本价值模型，是优先级判定最基本的、最通用的方法论，也是其他理论的核心基础。

如果通过研发成本和需求价值这两个维度划分出四个象限，可以将需求放置在某个象限之中，根据需求所在不同象限，可以得到优先级的划分策略，这就是成本价值模型。

需求优先级的成本价值模型

• 第一象限中的需求，价值巨大，但成本投入也比较大，理性的做法，应该是规划并持续关注。
• 第二象限中的需求，价值巨大，实现成本又很低，当然要快速拿下，所以我们应该迅速投入。
• 第三象限中的需求，价值和成本都很低，这就有点像鸡肋，食之无味，弃之有肉。处理的策略可以是关注并抽空实现。
• 第四象限中的需求，价值很低，实现成本反而很大，这种需求没有做的必要哦了，我们应该忘掉他们。

综上可以给出，位于不同象限需求的优先级，即II > I > III > IV。

然而，需求的实现成本相对容易衡量，需求的价值却很难量化评估！

RICE模型

对于SaaS软件，判断需求的价值时，还可以将受影响客户数量考虑进来，这就需要参考来自硅谷的RICE模型。

RICE是四个单词的缩写，分别代表：

• R：Reach，需求功能触达的客户数量；
• I：Impact，需求的价值打分，例如可以定义1到10分；
• C：Confidence，产品经理对需求的信心程度，是一个基于主观判断的修正参数；
• E：Effort，需求需要投入的研发人天；

通过这四个变量，对需求进行打分，可以得到优先级RICE得分，计算公式如下：

RICE Score = Reach * Impact * Confidence / Effort

例如，下表是两个需求通过RICE模型计算后的得分，根据分数，认为需求1优先级高于需求2。

通过RICE模型对需求优先级进行打分

需求	Reach	Impact	Confidence	Effort（人天）	RICE Score
需求1	100	3	80%	30	8.0
需求2	500	1	60%	35	6.7

RICE模型很好地纳入了受影响客户数量这个因素，但也有其局限性。

首先，关于Impact产品价值，本身就是很难量化的一个引子，所以RICE模型并不能解决成本价值模型中面临的困境，如何定义需求的价值？

其次，在商业运作中，并不能简单的认为，在其他变量相同的情况下，需求影响的客户数量多，优先级就高。有些需求，可能只服务于某个头部客户，但却具有标杆效应和示范效应，本身就有很高的商业价值。

因此，关于RICE模型的应用，要想清楚场景和目的。

价值范围模型

价值范围模型，是一个专门分析、衡量需求价值的模型，是我根据工作实践总结而成的，在和不同的企业交流中，我发现很多团队有着类似的思考和实践。

我们可以将一个软件产品所能提供的价值（即本书中多次提到的B端产品的五个典型价值，规模、成本、效率、风险、品质，再加一个产品本身的用户体验）列在纵轴，把业务相关的利益方都列在横轴，就得到一个多象限矩阵，有了这个矩阵，我们可以根据当前阶段业务的计划和商业的诉求，制定一个优先级打分表。

和业务方达成一致认知，设计好这张表格，后续所有的需求，都可以找到表格中的位置，以及对应的优先级。

例如，下图是M公司分销平台的范围价值模型打分表，表格中纵轴是分销平台对业务本身的价值，横轴是涉及到的利益方，单元格中直接定义了优先级。

M公司领导本身也代表了业务，所以提升收入的相关需求都可以纳入M公司领导和提升收入这两个坐标定位的单元格，我们认为分销平台核心目的是提升收入，所以这类需求优先级最高。

而针对M公司领导个人的降本增效、产品体验类需求，优先级都比较低，因为领导本身也不常用系统，不用为了领导一个人的使用体验而投入资源进行优化。

我们再来看看客户采购人员，对于他们来讲，不存在提升收入的业务价值，所以单元格用横线填充；而操作效率、交互体验，防错控制更重要一些，所以产品体验和控制风险两个单元格的优先级定义为Medium。

以此类推，基于对业务的判断和理解，梳理了角色和产品本身具备的业务价值，进一步设计了完整的优先级打分表。

价值范围模型打分表

价值范围模型比较适合用于企业对内产品研发中的需求优先级打分，在实际应用中会有很多变化和调整，例如作为一个中台产品，可以将横轴替换为中台产品服务的各个事业部业务线，提前规划好对不同业务线的支持力度，作为优先级判断的决策依据。

设计一张得到所有人认可、意见统一的价值范围模型打分表，还能避免未来和业务方扯皮的问题。任何需求都能在提前定义的表格中找到优先级的位置，不用再根据谁的嗓门大来做决策。

ANO模型

KANO模型，常常用来分析单一用户视角下需求的接受度，由东京理工大学教授狩野纪昭（Noriaki Kano）发明。严格来讲，KANO模型研究的是产品功能点和用户满意度之间的关系，但结论可以作为优先级的排序依据。

KANO模型虽然并不是为互联网产品发明，但却是互联网圈最网红的方法论。简单来讲，KANO模型将产品的功能点对用户进行问卷调研，通过正反两问来获取用户的感知，类似于这样：

正向提问：如果提交订单后马上提示开发票，你的感受是：

A.我很喜欢 B.理应如此 C.无所谓 Ｄ.勉强接受 E.我不喜欢

反向提问问：如果提交订单后并不提示开发票，你的感受是：

A.我很喜欢 B.理应如此 C.无所谓 Ｄ.勉强接受 E.我不喜欢

接下来，对用户的反馈进行统计，获得不同答案结果的占比，并统计到下表。

KANO模型统计表

		不提供此功能
		我很喜欢	理应如此	无所谓	勉强接受	我不喜欢
提 供 此 功 能	我很喜欢	Q	A	A	A	O
	理应如此	R	I	I	I	M
	无所谓	R	I	I	I	M
	勉强接受	R	I	I	I	M
	我不喜欢	R	R	R	R	Q

拿到统计数据后，经过一系列计算，可以分析出功能点的属性特征，具体有以下五种：

• A，魅力属性：提供功能用户会很喜欢，但不提供也无所谓；
• O，期望属性：提供功能用户很喜欢，不提供则不喜欢，用户对功能有强烈期待；
• M，必备属性：提供功能用户觉得感受一般，但不提供则用户强烈不喜欢，说明是必备功能；
• I，无差异属性：不论是否提供功能，用户感受都趋于平和；
• R，反向属性：提供功能用户不开心，不提供功能用户反而开心；
• Q：可疑结果：结论逻辑相悖，属于脏数据；

KANO模型的具体详细说明，网络上资料很多，本书不再赘述。此处需要强调的是，KANO模型并不完全适用于B端，因为B端背后面临着多角色和多利益方，而不同利益方之间可能具有利益互反的特点。

例如，钉钉的已读未读功能，对老板来讲，可能是期望属性，而对员工来讲，可能是反向属性。

再例如，销售型CRM的拜访录入功能，对老板来讲，可能是必备属性，而对一线销售来讲，可能是反向属性。

因此，对KANO模型的使用，一定要明确场景，切勿盲目应用。

需求的验证和评估

我们已经多次强调，作为一名产品经理，分析需求时一定要提前考虑好，上线后如何持续跟踪，判断功能是否达到了预期的业务效果。但是客观的讲，B端产品的功能，很多时候，难以量化收益，或者说很难衡量需求或项目的效果。因为B端产品最终要解决业务问题，而业务上的效果和效益，除了软件产品本身的影响以外，往往还取决于业务政策，以及业务人员的能力和态度等多方面的因素。

举个例子，针对给销售人员使用的OCRM系统，做了若干需求预期提高销售的转化率，但实际上影响转化率的因素太多了，客户质量，佣金政策，销售能力，都是影响因素，这些因素互相掺杂在一起，导致项目组很难衡量转化率指标的变化，究竟有多少是因为产品功能影响改善的。

即便B端产品很多时候收益和效果难以量化，在我们的日常工作中，团队管理和要求中，依然要保持数据评估工作的持续性和严谨性，思考项目收益如何衡量的过程，本身也是对需求和项目更深层次的分析论证的过程。如果你不能度量一件事情，那么你一定要谨慎思考到底该不该去做。

根据B端需求的三个层次具有天然的区别，我们可以针对三类需求分别思考如何衡量其收益。

通过拆解指标评估业务需求收益

评估业务需求的价值，可以先找到其对企业的价值大类（无外乎规模、成本、效率、品质、风险），然后尽量将价值大类的一级业务指标拆细，尝试找到和业务需求最相关的二级指标或三级指标，作为评估度量的核心指标。

不论是规模、成本，还是效率、品质，在业务运作中，都可以首先找到对应的一级指标，例如：

• 针对销售部门，规模的一级指标可能是“签单交易额”；
• 针对客服部门，成本的一级指标可能是“每千人客户的客服人力成本”；
• 针对配送部门，效率的一级指标可能是“配送及时率”；
• 针对采购部门，品质的一级指标可能是“采购质量合格率”；

各个业务线或业务单元，都会有核心一级指标作为北极星指标存在，指引业务的方向和目标。通过将一级指标层层拆解，尽量找到贴合需求价值的二级或三级指标。

例如，某在线教育的OCRM产品经理在设计实现了销售打单辅助工具，在试听课结束后生成小孩在试听课中的精彩片段，由销售人员发给家长，作为销售打单工具。该产品功能，核心目标是提高转化率，但是转化率作为二级指标，颗粒度依然很粗，影响因素太多。此时，我们尝试将转化率漏斗进行层层拆解：

转化率 = 试听课邀约率 * 试听课出席率 * 出席完课率 * 完课支付转化率

此时，转化率二级指标被拆解成了更细的四个三级指标。而上述案例中提到的产品功能，显然目的不是提高试听课约课率，也不是试听课出席率，更不是出席完课率，而是在小孩上完试听课之后，帮助销售完成临门一脚的拍单工作，显然，该产品功能最能影响的三级指标，是完课支付转化率。

因此，我们可以确定，针对该项目，考核指标选取完课支付转化率，观察项目上线前后指标的变化来评估项目收益。

但是，这个评估方法依然是不完美的，即使到了很细节的三级指标，在业务上的影响因素依然非常多，以完课支付率为例，该指标依然受到潜在客户的质量，以及销售个人能力的外部因素影响。为了更加客观的分析，需要采用AB测试的办法，选取两批特征完全相同的销售线索，一组作为实验组，提供精彩视频功能，一组作为对照组，不提供精彩视频功能，从而观察两者在完课支付转化率上的对比，来评估项目收益。

然而，B端功能很多时候难以采用AB测试，例如流程类的调整，上线就是全量，是没有办法新旧并存局部上线的。这可能正是B端产品业务收益难以衡量的一个致命问题，B端产品的AB测试以及小流量实验，实施成本太高，甚至无法实施，这就导致很难准确的比对、测量项目收益。而我们只能尽量选取精准的相关的三级指标来尝试衡量收益。

以上提到的逐层拆解指标来衡量项目收益的思路，实际上也是B端业务分析拆解的思路。在业务分析过程中，通过对数据指标的逐步拆解，发现问题，针对某个关键指标设计改进方案，落地实施。

通过NPS评估用户需求收益

用户需求来自终端用户，可能包括业务诉求，但更多的是体验优化。如果是业务类诉求，评估方式见上一节，如果是体验优化类诉求，一方面可以衡量操作效率的提升，另一方面还可以通过净推荐值NPS（Net Promoter Score）来考核用户对功能优化的满意度变化情况。

NPS由贝恩咨询发明，本身是企业用来衡量消费者对产品和服务的忠诚度与口碑，在消费互联网领域也有广泛的应用，是一种非常容易使用的用户忠诚度、满意程度评估工具。

NPS的使用非常简单，设置一道问卷题目，然后将选择9、10分的百分比，减去选择0到6分的百分比，就得到了NPS分数，如下图。

NPS的使用和计算

不同领域、地区、企业规模的NPS均值并不相同；对产品功能调研NPS，得分的绝对值参考性有限，更好的使用方法，可以持续观察NPS的变化趋势。例如，可以针对产品的不同模块定期调研NPS得分，判断用户体验是否持续改善。

下图是来自咨询公司Retently的分析报告，展示了全球B2B业务不同领域的NPS得分情况（数据样本来自于该公司的客户资源库），其中软件行业的2022年NPS均值大概在40%，供大家参考。

Retently发布的2022全球B2B业务不同领域NPS平均分

通过综合方案评估技术需求收益

技术需求又可以细分为四类，分别是基础能力建设、中台建设、纯技术建设优化，这四类方向区别比较大，如何评估收益，需要分别探讨。

对于基础能力建设项目，考核交付质量和时间

B端产品，作为复杂系统，一整套体系的运转，必须是多种类型的软件功能组合而成，例如，要有基本的权限管理，消息提醒管理，数据字典配置管理等功能，当发展到一定阶段，还需要流程引擎、报表引擎、表单引擎、视图编辑器这些组件能力。

这类对业务没有明显价值和收益，但对于软件系统又非常需要的功能，属于基础建设功能。对于此类项目，只需要正常考核交付质量、交付时间就可以，没必要为了评估而非要生搬硬套某些业务价值，造成没必要的麻烦。

对于中台建设项目，考核系统接入量以及人力节约

中台的目的是抽象建设可以复用的软件系统或模块，例如将各个业务系统都需要使用的消息中心、短信中心抽象成基础服务，供多个系统使用。对于中台产品或项目，我们可以考核其接入的客户端数量，来衡量其被复用能力的强弱，以及推广落地的结果。

此外，中台产品很重要的一个目标，是所谓避免重复造轮子问题，那么则可以通过其接入的客户端数量，来估算研发人力成本的节省。

通过考核中台产品客户端的接入数量，可以很好地倒逼中台产品经理像一个推销员一样去推销自己负责的中台产品。因为多数情况下，大型企业的多部门产品线，并不在意甚至并不愿意主动接入中台产品。虽然我们说中台建设需要自上而下的意志，但是更多时候也需要自下而上的倒逼推进。

对于纯技术项目，考核系统稳定性、安全性、时效性

对于纯技术优化需求和项目，例如微服务化、代码重构等，都是为了保证系统能够运行的更加稳定、高效，架构更加合理，灵活性更强，可以考虑衡量系统的稳定性、安全性等非功能性指标。当然这些工作更多属于技术团队决策，产品经理了解即可。

终极衡量指标：考核使用人数

我们已经讲了这么多评估的方法，但是很多时候，我们依然很难衡量某些B端产品功能对核心指标的影响程度，但两者在逻辑上却又有着明显的相关性。

例如，某销售人员使用的OCRM系统，产品经理对客户详情页做了全面的升级，提供了丰富的视图，可以让销售人员了解潜在客户的所有重要信息，通过对其进行画像标记，剖析其潜在需求和兴趣点，帮助销售人员更好的了解客户，从而成功转化。那么，如何衡量这套全新的“客户详情页”的价值和收益呢？

再例如，某客服系统，上线了若干针对一线主管使用的报表，帮助其更好的监控、管理下属团队的服务过程和服务水平。那么，如何衡量这些报表对客服业务服务质量和服务水平的改善作用呢？

如果你不能明确你的产品对业务产生的收益是什么，那么至少你可以评估有没有人使用这些功能。这是非常具备实操性的一种评估方法，如果你设计了新的功能，那么，保留老功能的入口，让用户用脚投票，看看到底哪一套更受欢迎。当然，有些新功能的推广是需要培育的过程，让用户慢慢适应接受。但是，如果没有明确的策略要求，完全可以让新老功能并存，看看到底哪套功能做的好。如果上线的功能没有人用，那么一定是哪里出了问题！

前边提到的详情页以及报表的案例，都可以考核用户使用的UV、PV，来衡量产品的价值，以及是否成功。

收益难以量化评估，是B端产品共同的难点。但作为B端产品经理，依然要尽最大努力评估、分析需求，否则就没有继续优化迭代决策的依据，也是对公司宝贵RD资源最大的浪费。

本节给出了不同类型产品需求的评估思路，只是供大家参考，希望给大家启发；实际业务中情况要更加复杂，必须做出灵活调整和设计，而不要生搬硬套。

迭代中的研发资源管理

企业级软件产品在技术上具有高度复杂性，研发人员不可能把所有精力都只投入在功能开发上，而应该分配一定的资源在技术优化和重构上。本节，我们来探讨研发资源的有效利用，以及产品不同发展阶段的技术资源投入问题。

研发资源的人力跟踪

在迭代优化过程中，产品经理要充分调动并利用研发资源，通过对人员的合理调配，保障不同项目之间无缝衔接，避免因为时间窗口不匹配导致研发资源闲置。

如何准确管理研发人力呢？有一种很简单实用的办法，也是传统项目管理中常用的办法，即制作一张研发人力资源安排图，通过这张图可以清晰地看出每个研发人员在不同需求、项目上的时间投入规划，并据此安排后续的工作。

在工作中，研发人员、产品经理、业务人员之间总会有这样的争执：为什么没有排期？你们在做什么？人力都铺在哪儿了？如果有这样一张图来清楚地呈现研发人员的工作安排，就可以避免这些争执。因此，维护好这张研发人力资源安排图，也是对研发人员的一种保护，避免他们“蒙受”工作不饱和的怀疑和指责。

研发人力资源安排图

产品不同发展阶段的技术资源投入

软件的代码需要不断地优化。如果软件升级迭代过程中只做产品功能需求，而不做技术优化，随着功能的积累，软件系统会变得越来越脆弱，运行速度会越来越慢，甚至频繁宕机。因此，在日常的迭代升级中，必须给技术优化预留足够的资源。

应该投入多少资源做技术优化？这个问题在产品经理和研发负责人之间似乎很难达成一致。研发负责人想多投入一些资源优化系统，而产品经理则认为应该首先解决业务需求。如何平衡业务需求和技术优化之间的资源分配问题呢？

从大的方面来说，这和系统所处的阶段有很大关系，不同阶段资源分配的思路完全不同。结合业务发展周期，我们将系统建设归纳为四个阶段，分别是初创阶段、瓶颈阶段、重构阶段、稳定阶段。

初创阶段

在初创阶段，业务还处于探索试错期，业务本身不一定能成功。在这个阶段，系统从无到有地构建起来，研发团队要开足马力支持业务，本阶段的重点在于“活下去”。构建的系统是一套全新的干净系统，没有任何历史包袱，因此，可以铆足劲儿开发业务功能，而不用太在意代码、架构的合理性，此时可以只预留10%的资源做技术优化，甚至不做技术优化。只要研发团队的水平靠得住，一套全新的系统在全力运转的状态下对业务支持一年的时间，应该是绰绰有余的，而一年正好是验证业务是否能够存活下去的关键时间点。

瓶颈阶段

经过一年的探索，证明了方向是正确的，业务取得了初步成果，并继续保持高速发展。业务对新功能的渴望持续且强劲，产品研发团队依然开足马力，但此时系统已经显现出疲态，“技术债”问题出现：曾经的设计缺陷、硬编码、架构不合理等问题逐渐凸显出来，系统三天两头出问题，Bug繁出，稳定性差，与此同时，业务需求继续井喷！

对于产品研发来说，一半的资源被修复Bug和迫在眉睫的技术优化占用，另一半资源被难以维护的老代码拖住。产品研发团队既不能痛快地满足业务需求，也不能爽快地一次性解决系统结构问题。此阶段可能会持续1年到1.5年的时间，可谓整个产品研发团队的“噩梦时期”。

重构阶段

业务继续发展且相对稳定，业务需求依然络绎不绝，但系统已濒临崩溃的边缘。所有人都明白，偿还技术债的终极时刻来临了：公司层面决定，业务需求给技术重构让路，留给研发团队充足的时间重构系统，一次性解决历史问题。此阶段可能会安排80%的资源做技术优化重构工作，包括代码解耦、拆库拆表、中间件升级、接口化、服务化等。

对于瓶颈阶段和重构阶段分别持续多久、在什么时候发生，这个问题很难准确回答，取决于业务情况、系统状况、技术团队的话语权等因素。

此外，也有“边开飞机边换引擎”的成功案例，即在不影响业务的情况下，持续升级系统，开发新功能的同时完成系统重构，但难度相对较大。需要结合具体的系统架构和实际情况来判断采取什么方案。

稳定阶段

该阶段业务发展稳定，系统运行平稳，Bug 少，不宕机。业务需求依然不停地提出，但此时研发工作显得井井有条。即便如此，依然需要预留10%到20%的研发资源持续做技术优化，这是保证系统持续稳定的秘诀。

综上所述，业务需求和技术优化的研发资源分配，要根据业务发展和系统建设的阶段来合理安排。不同阶段对两者投入的资源比例可参考下表。

不同系统发展阶段下技术优化资源投入比例建议

系统阶段	时间周期	特点	业务需求资源占比	技术优化资源占比
初创	0~1年	系统从无到有构建，业务飞速运行、试错	90%	10%
瓶颈	1~2.5年	业务继续发展，系统问题不断	50%	50%
重构	2.5~3年	业务逐渐稳定，系统问题严重	20%	80%
稳定	3年以上	业务持续稳定，系统稳定	80%	20%

商业化产品的发展阶段

以上分析和节奏适用于企业自研系统、支撑业务快速开展试错的情况；商业化软件产品的节奏不太一样，虽然商业化产品一开始也不能太复杂，而应该首先快速验证市场，但相对于自研系统，对产品和技术架构的合理性、规范性要求更高一些，因为毕竟是企业的主营售卖产品，而非某个业务的辅助支持工具，所以一开始的设计、投入需要更严谨，更充分，因此商业化产品本身的瓶颈期和重构期的出现时间可能会更晚一些，但发展过程同样也会经历以上四个阶段，在技术资源的投入分配上原则是类似的。

作者：杨堃《决胜B端》作者，聊聊产品、职场。

,