手把手学做B端需求：绩效考核模块（上）

编辑导语：对产品而言，独立负责模块是很重要的事，但如何做得更好，是值得思考的问题。本文就将围绕需求背景和搜集信息两个方面展开，推荐对此感兴趣的朋友继续阅读，希望对你有所帮助，一起来看看吧。

还记得你头一次独立负责新模块的兴奋吗？

对于很多产品来说，独立负责模块是职业生涯中的一个小里程碑，代表着你可以成体系的为模块的产出的价值负责，可以肩负起思考它的过去、现在和未来的责任。

很多人也会认为，从0开始做一个模块，没有历史负担，不受过去牵累，是很简单的事情。

但从0开始，也是在为这个模块敲砖打地基，考虑得不够周到，大概率会为自己和开发埋坑，导致后面的需求迭代起来非常困难。所以以最近工作上的一个例子来探讨，怎么做可以更多的考虑到模块的可扩展性。

一、需求背景

我司的服务对象是有城配需求的企业，我们可以为其提供充足且服务稳定的运力资源。

其中一家企业，业务量大，业务点遍布全国，为了平衡运输质量，每个城市会找多家运力供应商承接，而我们也是其中一家。

为了有效管理和激励多家供应商，也为了平衡大家的利益，企业出台了绩效考核政策，把运输过程中的关键点拆分成指标，每项指标赋予权限，最后根据总分，对供应商进行排名。

排名更新得非常及时，每日都可以在甲方对应的系统中看到。

另外每月会得出最终排名，会根据排名的情况适当调整供应商的业务。表现差的供应商，会被削减部分业务，转而把这这部分奖励给排名靠前的供应商。

所以及时了解数据的变化情况，会有利于公司掌握现场运营情况，及时应对，做出调整。

现在总部会要求现场的管理人员，每日用邮件的形式，发送数据日报，周报以及月报。但邮件中的信息非常分散，不利于总部汇总，更没法看到分值对比和变化。

所以总部同事向技术部门提供需求：我们想在系统上汇总看到这部分数据。

接了需求以后，我们开始干活了，既然是一个新模块，于是关注延伸认知、设计可扩展性方案两件事情，并分别定下目标。

第一，全面了解绩效管理的信息，达成对该事项的初级认识。

效果评定：未来业务部门对其他项目进行绩效考核，自己能够知道是如何操作的，甚至可以给业务提出一些考核流程的意见。

第二，通过全面的了解，设计出未来可扩展的产品方案。

效果评定：了解企业内部现有所有的场景，后续如何支持其他场景可以做到心中有数，可以在现有方案上平稳迭代和支持调研到的这些场景。

二、搜集信息

要认识新的事物，搜集信息是非常重要的一步。

产品经理不可能面面俱到，事事知晓，我们需要信息来建立认知，然后内化成自己的知识、打破旧的框架、重构新的框架。这也我们也才能设计出有可扩展的方案，毕竟事物再千变变化，也还是会遵循真理，遵循事物发展的基本原则。

1. 建立认知

以绩效考核模块为例。

它是企业经营中较为常见和通用的模块，不会因为企业业务和诉求的不同有非常大的差异。并且绩效考核这件事情，已经是非常成熟的管理手段，更发展出了多个不同的理论和方法，所以我们可以先自己搜集资料，建立认知。

通过搜集信息，你可以在心里已经建造一张绩效考核的地图。后续和业务沟通时，既能明白业务开展工作的背景，确保双方可以在同一个语境下交流，也能基于了解，梳理出更完整的问题框架。

在建立认知方面，我们可以采用【黄金圈法则】，用自己的话从what why how 三个程度解释绩效考核。

（1）what

在工作中，制定需要关注的指标，观察指标并周期性地对指标评分，用以评估员工或业务的工作质量。

往往是薪酬管理的前置部分，最后的数据可能成为薪酬考核的权重。

（2）why

拆解组织目标到个人：定下自上而下的标准，落实目标，保证大家朝一个方向前进。

给到好的标准：用smart原则，量化工作中的要求，让大家有努力的方向。

（3）how

一般要经过设置指标——设置公式/参数——填写目标——生成考核结果——查看数据/加工数据

公司内部是否是这样的流程，差别在哪里，为何会有差别，也是我们后续要重点询问的。

2. 搜集产出物

建立好了认知，就可以去做需求澄清了，在这个步骤中，不光要听需求方讲述，更要拿到需求方现在会产出的文档。

为什么要重点强调产出物呢？

首先，它是阶段性工作结果的体现，是沟通过程的中间产物，是现行的大家都认可的解决方案。产品的工作是把线下解决方案搬到线上，所以一切拆分工作都要围绕产出物上进行分解。

其次，产出物是落在纸面上的表达，口头表达信息会缺失，会有歧义，纸面上的文字可以很好的规避这些问题。往往口头沟通中没有体现到的问题，在产出物上都会得到澄清。

在绩效考核这个需求中，我们就可以要到【甲方后台截图】以及【现场管理发给总部的邮件】。

甲方考核的表和下图类似，所以我需要拆分表格，明确表格中每项数据的来源和作用。

根据表格我们能大致分为两个部分的信息。

一部分是甲方制定的绩效规则，一部分是我们的实际表现，是绩效结果。两个部分的作用不一致，对应的操作人也不一致，是需要着重考虑系统如何去支持的。

甲方制定的考核指标/规则

• 日期：与考核周期相关
• 考核类型：考核指标分类
• 考核指标：甲方认为重要的事项
• 目标值：甲方认为应该达到的目标值
• 挑战值：甲方认为应该尝试的挑战值
• 权重：甲方认为该项的重要性，是最后计算总分的参数

考核结果

• 实际值：每项考核的实际分数
• 得分： 根据实际值按照一定规则折算出来的分数
• 总分：根据权重算出来的分数
• 排名：所有供应商对比的排名

整理完表格信息，工作并没有完。记得我们还有一个【邮件】的产出物么？

打开邮件，意外发生了。可以看到邮件中不仅仅是每日的考核数据，还有一些其他数据和工作人员的总结。

这时可以进一步回来思考：我们绩效考核的范围是什么呢？业务现在搜集的信息，和绩效考核有什么关系呢？有了答案后，接着再思考这这部分多出的信息，是否要和业务做沟通，以及以什么立场和态度做沟通。

3. 需求澄清

根据已经建立的认知，以及对产出物的梳理，可以采用5w1h模版，搜集一下相关信息。

• Who：现在会考核那些人？是哪些项目上的？是哪些角色？
• what：现在会考核哪些指标？这些指标会变动么？表格上的各种规则，会变动么？会如何变动？邮件中有些信息，并非是绩效管理模块的，例如指标数据，例如员工总结，需要考虑展示么？
• where：是通过哪里呈现这些指标？
• when：这些指标什么时候会更新呢？一般考核周期是什么呢？未来大概会多久看一次数据？
• Why：考核数据会影响什么？如果数据不好，我们会采用什么措施？
• how：我们现在的填写周期是什么呢？

注意：你的询问对象，至少要涵盖流程中的各项角色。例如这个场景中，会有查数据和看数据两种角色，如果角色负责的业务，会影响到角色的行为，那么还需要询问不同业务下同一个角色的工作流程。

注意：需要特别注意询问数据变更的逻辑。是否会变，变得多与少，为何会变，变了以后会影响什么，这些都会和后期设计产品方案直接相关。

4. 跨维度搜集内部信息

对模块负责，当然要为它未来的价值负责。

所以你需要跨越当前需求方，去思考谁或者哪个部门可能还有类似的需求。模块的终局，应该是可以支持到所有角色和部门的需求的。所以了解其企业内部其他人的需要，这一步需要主动跨越的步骤，对设计的的可扩展性非常重要，但也是很容易被忽略的。

在绩效考核的例子中，我们就进一步去搜集了HR部门的绩效考核数据，从而发现了绩效规则的多样性，充实了案例库，也了解了这部分和薪酬管理的关联。

5. 搜集外部信息

以上信息，搜集的都是企业内部的信息，可能会带有强烈的企业个性化风格。

为了避免陷入定制化的困局，需要再看看外部信息，这时有两种方向是我们可以去尝试的。

一是提供类似模块的通用产品，他们的流程和业务是如何做的。比如飞书有OKR绩效，泛微有绩效考核，CRM系统有对销售的目标划定。这些产品都可以成为考察的范围，他们的通用化设计思路可以给后续工作带来一些灵感。

二是其他企业是怎么样做绩效管理的。可以从百度文库找到考核文档，可以从人人查看其他产品的设计方案。在之前的搜索这部分信息的时候，自己很明显的感受到，手头在做的绩效管理和大家的方案并不太一样。大家的绩效管理系统，更多的是体现员工自主定下绩效，进行层层审批的这一过程。所以也才萌生了写一篇文章的想法。

信息搜集到此结束，后续还有整理信息和设计方案两大步骤，请等待下篇。

等待的过程中，请收藏，点赞，多多益善～

本文由 @假装是运营 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Pixabay，基于CC0协议