绩效|手把手学做B端需求：绩效考核模块（上）( 二 ) 珍爱网|世纪佳缘|主良缘|江苏

2. 搜集产出物建立好了认知，就可以去做需求澄清了，在这个步骤中，不光要听需求方讲述，更要拿到需求方现在会产出的文档。
为什么要重点强调产出物呢？
首先，它是阶段性工作结果的体现，是沟通过程的中间产物，是现行的大家都认可的解决方案。产品的工作是把线下解决方案搬到线上，所以一切拆分工作都要围绕产出物上进行分解。
其次，产出物是落在纸面上的表达，口头表达信息会缺失，会有歧义，纸面上的文字可以很好的规避这些问题。往往口头沟通中没有体现到的问题，在产出物上都会得到澄清。
在绩效考核这个需求中，我们就可以要到【甲方后台截图】以及【现场管理发给总部的邮件】。
甲方考核的表和下图类似，所以我需要拆分表格，明确表格中每项数据的来源和作用。
根据表格我们能大致分为两个部分的信息。
一部分是甲方制定的绩效规则，一部分是我们的实际表现，是绩效结果。两个部分的作用不一致，对应的操作人也不一致，是需要着重考虑系统如何去支持的。
甲方制定的考核指标/规则

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

考核结果

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

整理完表格信息，工作并没有完。记得我们还有一个【邮件】的产出物么？
打开邮件，意外发生了。可以看到邮件中不仅仅是每日的考核数据，还有一些其他数据和工作人员的总结。
这时可以进一步回来思考：我们绩效考核的范围是什么呢？业务现在搜集的信息，和绩效考核有什么关系呢？有了答案后，接着再思考这这部分多出的信息，是否要和业务做沟通，以及以什么立场和态度做沟通。
3. 需求澄清根据已经建立的认知，以及对产出物的梳理，可以采用5w1h模版，搜集一下相关信息。

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

注意：你的询问对象，至少要涵盖流程中的各项角色。例如这个场景中，会有查数据和看数据两种角色，如果角色负责的业务，会影响到角色的行为，那么还需要询问不同业务下同一个角色的工作流程。
注意：需要特别注意询问数据变更的逻辑。是否会变，变得多与少，为何会变，变了以后会影响什么，这些都会和后期设计产品方案直接相关。
4. 跨维度搜集内部信息对模块负责，当然要为它未来的价值负责。
所以你需要跨越当前需求方，去思考谁或者哪个部门可能还有类似的需求。模块的终局，应该是可以支持到所有角色和部门的需求的。所以了解其企业内部其他人的需要，这一步需要主动跨越的步骤，对设计的的可扩展性非常重要，但也是很容易被忽略的。
在绩效考核的例子中，我们就进一步去搜集了HR部门的绩效考核数据，从而发现了绩效规则的多样性，充实了案例库，也了解了这部分和薪酬管理的关联。
5. 搜集外部信息以上信息，搜集的都是企业内部的信息，可能会带有强烈的企业个性化风格。
为了避免陷入定制化的困局，需要再看看外部信息，这时有两种方向是我们可以去尝试的。
一是提供类似模块的通用产品，他们的流程和业务是如何做的。比如飞书有OKR绩效，泛微有绩效考核，CRM系统有对销售的目标划定。这些产品都可以成为考察的范围，他们的通用化设计思路可以给后续工作带来一些灵感。
二是其他企业是怎么样做绩效管理的。可以从百度文库找到考核文档，可以从人人查看其他产品的设计方案。在之前的搜索这部分信息的时候，自己很明显的感受到，手头在做的绩效管理和大家的方案并不太一样。大家的绩效管理系统，更多的是体现员工自主定下绩效，进行层层审批的这一过程。所以也才萌生了写一篇文章的想法。