技术学习笔记-需求优先级的确认方法
技术学习笔记-需求优先级的确认方法
在产品开发过程中，如何确定需求的优先级是一个关键问题。本文将从大客户定制项目、0-1打造阶段的产品以及1-N阶段的B端商业产品三个方面，详细介绍需求优先级确认的方法，包括权力/收益矩阵、KANO模型和效益评估等工具。
对于大客户定制项目：关键角色满意度
在需求收集的过程中，产品经理需要甄别出这个需求对产品最终成功指标的影响度。对于大客户项目，让大客户满意的是最关键的点。当我们分析需求优先级的时候，可以根据权力/收益矩阵来确认优先级。
通常我们会重点关注A、B区域的利益相关者，他们通常是购买方的采购负责人和公司老板。对于C、D我们不需要投入过多关注，但是也不能疏忽，他们可能对这个项目购买存在间接影响力。
- A区：采购负责人，权力高利益低需要让其满意(多沟通，明确对方的想法）
- B区：企业老板或CEO，培训负责人 ，权力高利益高需要重点关注（定时汇报）
- C区：一线基础员工，如销售，客服等人员，权力低利益低努力最小
- D区：部门管理人（组长或主管），权力低利益高多共同保证信息获取
案例：培训企业购买师资机构的在线企业培训系统
0-1打造阶段的产品：MVP版本的交付和反馈
优先级定性分析方法KANO
KANO模型可以识别用户对功能的感受度。在KANO模型中，根据不同类型的需求与用户满意度之间的关系，可将影响用户满意度的因素分为五类：基本型需求、期望型需求、兴奋型需求、无差异需求、反向型需求。
- 我们要尽量避免无差异型需求，反向型需求，至少做好基本型需求，期望型需求，再挖掘兴奋型需求。
1）兴奋型需求
所谓暗处若不提供此需求，用户满意度不会降低；若提供此需求，用户满意度会有很大的提升。当用户对一些产品或服务没有表达出明确的需求时，企业提供给顾客一些完全出乎意料的产品属性或服务行为，使用户产生惊喜，用户就会表现出非常满意，从而提高用户忠诚度。这类需求往往是代表顾客的潜在需求，企业的做法就是去寻找发掘这样的需求，领先对手。
2）期望型需求
所谓痒处。当提供此需求，用户满意度会提升；当不提供此需求，用户满意度会降低。它是处于成长期的需求，客户、竞争对手和企业自身都关注的需求，也是体现竞争能力的需求。对于这类需求，企业的做法应该是注重提高这方面的质量，力争超过竞争对手。
3）基本型需求
所谓痛点，对于用户而言，这些需求是必须满足的，理所当然的。当不提供此需求，用户满意度会大幅降低，但优化此需求，用户满意度不会得到显著提升。对于这类需求，是核心需求，也是产品必做功能，企业的做法应该是注重不要在这方面减分，需要企业不断地调查和了解用户需求，并通过合适的方法在产品中体现这些要求。
4）无差异需求
用户根本不在意的需求，对用户体验毫无影响。无论提供或不提供此需求，用户满意度都不会有改变。对于这类需求，企业的做法应该是尽量避免。
5）反向型需求
用户根本都没有此需求，提供后用户满意度反而下降。总而言之，我们做产品设计时，需要尽量避免无差异型需求、反向型需求，至少做好基本型需求、期望型需求，如果可以的话再努力挖掘兴奋型需求。
定量分析各需求层级：调查问卷
KANO模型就可以帮助我们很好地贴合业务需求，从具备程度和满意程度这两个维度出发，将新增功能进行区分和排序，从而知道：哪些功能是一定要有，否则会直接影响用户体验的（基础属性、期望属性）；哪些功能是没有时不会造成负向影响，拥有时会给用户带来惊喜的（兴奋属性）；哪些功能是可有可无，具备与否对用户都不会有大影响的（无差异因素），哪些功能是不能有的，有了会造成客户反感的（反向因素）。我们需要在功能设计之前利用KANO模型进行分析。
示例：对任意一个需求，我们都要从有和没有两面出发收集用户的反馈。
此问卷调查表划分维度有两个：提供时的满意程度、不提供时的满意程度。
样例：
满意程度被划分为5级（非常满意、满意、一般、不满意、很不满意），因为人的满意程度往往是渐变的，而不是突变的。
对于一个需求的两个问题的答案分布可以判断出对于这个答题者，这是什么层次的需求。
- 类型：
- A：兴奋型；
- O：期望型；
- M：必备型；
- I：无差异型；
- R：反向型；
- Q：可疑结果。
对于一批发放出去的问卷，我们选择统计结果的众数选项作为该需求最终的定位。
1-N阶段的B端商业产品：经济效益
重要性/紧急矩阵
同时，我们也可以用效益去衡量重要性：
效益是短期和长期经济收益的综合评估。
- 短期收益来源：承诺某些功能就可以和处在售前阶段的客户谈下合约。
- 长期收益来源：估计某个功能能够解决的场景价值。通过大概估测，没有这个功能时，客户想达到业务目的需要投入多少人、多长时间，这些人需要的薪资是多少，这个事每年做几次，最后大概能评估一个年度货币成本数量级即可。
通常来看，处于售前关键时刻（即将签约）的大金额客户经济效益是最高的，其次是涉及客户多，业务价值高的普适需求。
除此之外，我们还需要综合需要考虑开发成本和开发难度。
- 可能有些小需求经济效益不高，但成本极低，此时考虑到市场响应和客户满意度，也可以将这些小需求排入靠前的开发迭代。
- 对于经济效益高但难度大、成本高的需求，不能因为难就一直拖延着不做，我们需要勇于啃硬骨头，在具体推进时可以把这类需求穿插在多个迭代中推进。
本文原文来自CSDN