手把手学做B端需求：绩效考核模块
还记得你头一次独立负责新模块的兴奋吗？
对于很多产品来说，独立负责模块是职业生涯中的一个小里程碑，代表着你可以成体系的为模块的产出的价值负责，可以肩负起思考它的过去、现在和未来的责任。
很多人也会认为，从0开始做一个模块，没有历史负担，不受过去牵累，是很简单的事情。
但从0开始，也是在为这个模块做打地基的工作，考虑得不够周到，大概率会为自己和开发埋坑，导致未来迭代难度增加。问题再严重一点，甚至有可能演绎无法迭代、需要重构的悲剧。
希望以这次的需求为例子，一起探讨：
- 如何尽可能全面地搜集信息，在下笔前做到胸有丘壑。2套方法，帮助捕捉业务描述不出来的需求细节，以及帮助产品短时间成为负责模块的半个专家。
- 如何在拿到需求后进行全面的分析。这里提供一个在B端业务中非常好用的框架。
- 如何进行功能分析和设计实战。这里话不多说，直接放上成果，供做这块的童鞋参考，当然由于保密原因省略了一些细节，如果有需要，咱们可以私信沟通～
一、搜集信息
1. 确立目标
搜集信息是设计模块的首要工作。
在绩效考核这个具体需求的场景里，搜集信息的目的有二：
第一，全面了解绩效管理的信息，达成对该事项的初步认识。
效果评定：未来业务部门对其他项目进行绩效考核，自己能够知道是如何操作的，甚至可以给业务提出一些考核流程的意见。
第二，通过全面的了解，设计出未来可扩展的产品方案。
效果评定：了解企业内部现有所有的场景，后续如何支持其他场景可以做到心中有数，可以在现有方案上平稳迭代和支持调研到的这些场景。
2. 5个搜集信息的渠道
通常而言，我们拿到需求，更常见的是直接向业务发起人询问，但可能你会发现这样的情况：
- 天马行空地提出他的解决方案，言之这是他的经验之谈，你没有足够的知识和阅历，听之任之，结果上线后三天两头的修改，甚至发现管理逻辑上都走不通。
- 功能上线后马上发现之前没有聊到细节和特殊情况，没能满足上线目标，只有反复修改，每天疲于打补丁，搞得整个团队都像热锅上的蚂蚁。
- 功能上线后一切平稳，但过了段时间，遇到了类似的场景，之前大家没有考虑到兼容性，导致需求迭代缓慢。
所以下文提供五个搜集信息的渠道，希望在信息搜集的阶段能把基础打牢，也更有和业务沟通的底气，不至于一开始就被带偏。
1）从通用资料中搜集
产品经理不可能面面俱到，事事知晓，我们需要信息来建立认知，并以此为基础设计出有可扩展的方案。无论未来这个模块产生什么样的需求，都脱离不出现实的诉求，脱离不开企业和组织目的和发展规律，这些很难改变的东西，也就是所谓的【元认知】。
有句话说，这世界变化太快，是的，每天的新闻都在以爆炸的速度去增长，我们不眠不休的学习也是无法穷尽的，总得有点不变的东西作为心里的底气去应对这些表现的变化。
以绩效考核模块为例。
它的元认知是是什么？不会改变和很难改变的是什么呢？容易改变的又是什么呢？
结合【WYH框架】我们可以得到如下信息。
不太会改变的
一般集中在事物的本质以及事务为何会存在。正常来说，来说差别不大，可以用于和业务达成共识。
绩效考核是什么（what）
一种评估工作工作表现的方法。
在工作中，制定需要关注的指标，观察指标并周期性地对指标评分，用以评估员工或业务的工作质量。
在组织中，这项工作往往是薪酬管理的前置部分，得出的数据可能成为薪酬考核的计算参数。
绩效考核为什么会存在（why）
首先可以可以拆解组织目标到个人，在过程中可以自上而下地拆分目标，落实目标，保证大家朝一个方向前进。同时也会有甲方考核内部的情况，这种是用于甲方更好的管理多家供应商，用绩效约束供应商进行更好的服务。
其次可以把好的标注明确地给到考核人。绩效是以一条一条的形式来呈现，每个条目有对应的目标和分值，应用smart原则来量化工作中的要求，让员工有可以努力和改善的方向。
改变较小的
一般公司在做法和流程上会有所差别，但也是在大的方法论和原则上进行优化，总的来说，不会差异非常大，是需要和业务整体沟通的部分。
如何实现绩效考核（how）
公司内部的绩效管理步骤：经过设置指标——设置公式/参数——填写目标——生成考核结果——查看数据/加工数据。
甲方给公司内部的绩效管理步骤：告知关注指标和标准——系统或者人工对接指标考核数据——查看考核数据并采取新的行动。
这部分需要向公司确认内部是否是这样的流程，差别在哪里，为何会有差别。
容易改变的
一般公司在实际的执行上会差距非常大，而且隔行如隔山，各个行业可能有更具体通用的方法论，甚至对于不同职能部门也会不同。这是需要和业务重点确认的部分。
某个岗位或者业务，如果需要绩效考核应该这么做（how的细节）
不同岗位，不同公司设置的指标，对应的公示/参数，考核周期等等流程必然不同
这部分需要具体向需求方确认，明确需求范围和特殊做法
梳理完成以上内容有没有觉得自己更加自信，对于这项工作在组织中的意义，以及工作如何开展都有了基础的认识呢？
既然成为了这个模块的负责人，是有必要自主驱动，纵深地往模块的基础知识看看的。以上权当一个例子，你可以更加深入的去学习。
只要做到这一点，以下令人头大场景你几乎都能搞定。
- 业务不愿意说——你能通过一些专业的问题，在沟通中和业务建立起“你很懂哦”的心领神会，让业务高看一眼，愿意倾吐。
- 业务经常跑偏，用一些你似懂非懂的词汇有意无意岔开话题——你能及时在业务跑偏的时候提出问题，及时纠偏。
- 业务陈述信息颠倒矛盾，该说的不说，不该说的说一堆——用你的专业知识和框架思维结合在一起，一针见血的问出你要的问题，避免遗漏。
2）从需求发起人口中搜集信息
可以采用5w1h模版，搜集一下相关信息。
- Who：现在会考核那些人？是哪些项目上的？是哪些角色？
- what：现在会考核哪些指标？这些指标会变动么？表格上的各种规则，会变动么？会如何变动？邮件中有些信息，并非是绩效管理模块的，例如指标数据，例如员工总结，需要考虑展示么？
- where：是通过哪里呈现这些指标？
- when：这些指标什么时候会更新呢？一般考核周期是什么呢？未来大概会多久看一次数据？
- Why：考核数据会影响什么？如果数据不好，我们会采用什么措施？
- how：我们现在的填写周期是什么呢？
注意：你的询问对象，至少要涵盖流程中的各项角色。例如这个场景中，会有查数据和看数据两种角色，如果角色负责的业务，会影响到角色的行为，那么还需要询问不同业务下同一个角色的工作流程。
注意：需要特别注意询问数据变更的逻辑。是否会变，变得多与少，为何会变，变了以后会影响什么，这些都会和后期设计产品方案直接相关。
3） 从执行过程中的产出物中搜集信息
建立好了认知，就可以去做需求澄清了，在这个步骤中，不光要听需求方讲述，更要拿到需求方现在会产出的文档。
为什么要重点强调产出物呢？
首先，它是阶段性工作结果的体现，是沟通过程的中间产物，是现行的大家都认可的解决方案。产品的工作是把线下解决方案搬到线上，所以一切拆分工作都要围绕产出物上进行分解。
其次，产出物是落在纸面上的表达，口头表达信息会缺失，会有歧义，纸面上的文字可以很好的规避这些问题。往往口头沟通中没有体现到的问题，在产出物上都会得到澄清。
在绩效考核这个需求中，我们就可以要到【绩效要求表格】以及现在的替代法案【邮件】。
甲方考核的表和下图类似，所以我需要拆分表格，明确表格中每项数据的来源和作用。
根据表格我们能大致分为两个部分的信息。
一部分是甲方制定的绩效规则，一部分是我们的实际表现，是绩效结果。两个部分的作用不一致，对应的操作人也不一致，是需要着重考虑系统如何去支持的。
考核指标/规则
- 日期：与考核周期相关
- 考核类型：考核指标分类
- 考核指标：甲方认为重要的事项
- 目标值：甲方认为应该达到的目标值
- 挑战值：甲方认为应该尝试的挑战值
- 权重：甲方认为该项的重要性，是最后计算总分的参数
考核结果
- 实际值：每项考核的实际分数
- 得分： 根据实际值按照一定规则折算出来的分数
- 总分：根据权重算出来的分数
- 排名：所有供应商对比的排名
整理完表格信息，工作并没有完。记得我们还有一个【邮件】的产出物么？
打开邮件，意外发生了。可以看到邮件中不仅仅是每日的考核数据，还有一些其他数据和工作人员的总结。
这时可以进一步回来思考：我们绩效考核的范围是什么呢？业务现在搜集的信息，和绩效考核有什么关系呢？有了答案后，接着再思考这这部分多出的信息，是否要和业务做沟通，以及以什么立场和态度做沟通。
4）从组织内部其他业务线搜集信息
对模块负责，当然要为它未来的价值负责。
所以你需要跨越当前需求方，去思考谁或者哪个部门可能还有类似的需求。模块的终局，应该是可以支持到所有角色和部门的需求的。所以了解其企业内部其他人的需要，这一步需要主动跨越的步骤，对设计的的可扩展性非常重要，但也是很容易被忽略的。
在绩效考核的例子中，我们就进一步去搜集了HR部门的绩效考核数据，从而发现了绩效规则的多样性，充实了案例库，也了解了这部分和薪酬管理的关联。
5）从外部搜集信息
以上信息，搜集的都是企业内部的信息，可能会带有强烈的企业个性化风格。
为了避免陷入定制化的困局，需要再看看外部信息，这时有两种方向是我们可以去尝试的。
一是提供类似模块的通用产品，他们的流程和业务是如何做的。比如飞书有OKR绩效，泛微有绩效考核，CRM系统有对销售的目标划定。这些产品都可以成为考察的范围，他们的通用化设计思路可以给后续工作带来一些灵感。
二是其他企业是怎么样做绩效管理的。可以从百度文库找到考核文档，可以从人人查看其他产品的设计方案。在之前的搜索这部分信息的时候，自己很明显的感受到，手头在做的绩效管理和大家的方案并不太一样。大家的绩效管理系统，更多的是体现员工自主定下绩效，进行层层审批的这一过程。所以也才萌生了写一篇文章的想法。
二、整理信息
以设计需求为目的，来整理搜集到的信息。
这一步可以着重对比：常规管理办法VS自己公司的异同，这样可以进一步追踪造成不同的原因，也是为了可扩展性做进一步的思考。
推荐【人 时 物 权】框架进行分析。
- 人——有几个角色会参与到这项工作中，每个角色会承担的责任和义务是什么；
- 时——该项工作和时间的关系；
- 物——绩效管理的信息共分为哪些类型，那些是不变的，哪些是可变的，哪些是可配置的；
- 权——不同角色在系统中的权限是怎么样的。
按照这个框架，本需求整理出的结果如图。
可以看到，在人/物方面，我司和常规做法存在着大量不同。
进一步把人单拎出来，单独分析。
常规绩效考核的四步包括：
- 企业设定绩效规则，包括要考核哪些指标，以及计算结果（完成率或加权总分）；
- 员工/管理者设置期望达到的目标；
- 员工设置目标值后逐级审批；
- 领导周期性检查绩效达成情况。
而我司现状要求的步骤不同，由三步构成：
- 设定考核。项目考核主要由甲方驱动和设置，内部有针对岗位和业务部的考核。
- 绩效填写。无法从甲方取数时，绩效结果依赖于考核人自己填写。
- 领导周期性检查绩效达成情况&员工上报的绩效分析。
除了最后查看的步骤大体一致，绩效模版生成到产生数据的逻辑都不太一样，所以基本判定为我们现在要求的是一种比较特殊的流程。
再进一步把事（绩效）拎出来。
首先穷举不同绩效模版的模式，然后归纳总结成一张绩效考核的字段全表。接着对表格的各个部分进行分类，明白每个类别的作用，进而考虑到每个类别在配置页面中是否需要体现。
关于绩效管理的信息分析，到此为止告一段落。
到现在你应该了解了绩效管理对于企业经营的意义，线下实施绩效管理的一般方案，以及我们服务的企业和常规方案的不同在哪里。
三、设计方案
信息的整理完成后，接下来我们需要进入方案设计了。
1. 功能分期
先不要着急画UE，我们还有更重要的事情，即需要就现有资源，设计整个模块的产品演化路径。这样能给到业务部门清晰的规划，我们计划分多少期完成什么样的需求，未来计划可以支持的类型有哪些。
从本次的案例来说，我们可以用四分法拆分现有需要支持的所有绩效考核事项。
分期以后，指向的工作进一步清晰了。
首先会支持客户制定绩效，客户处查看绩效的模块，未来这类需求都用定制模版的方法来实施，即业务说明需要统计哪些内容，以及对应的目标值等数据是多少，开发针对该种情况单独定制一个模版。
未来会扩展支持通过后台字段组合，配置生成对应的考核模版，这样意味着我们对于模版后期还要做更多的投入，且要建立对应的模版指标库，才能实现系统自动生成考核结果数据。
2. 功能设计
就一期功能而言，操作SOP如下：
1）线下确认好对应模板
- 模版需要填写哪些内容；
- 哪些内容是已经填写好数值的；
- 哪些内容是需要被考核人填写的。
2） 配置好考核模板后，模版展示在列表中
- 有查看/编辑权限的人，可见该考核模版；
- 如果指标等数据有修改，产研团队人工协助修改。
3）可以通过编辑功能，调整相关信息
4）对应用户，可进入查看/编辑数据
所有人可查看的数据范围受数据权限约束。
对应SOP设计完成后，记得尽量和业务同事核对一次。避免偏差。
四、尾声
这个需求的最后呈现，说真的并不大复杂。考虑到业务对绩效模块的价值认可度比较有限，时间又紧张，设计了简单的但未来可扩展的方案。
但是由于经过了大量的信息搜集和分析，至少能从几个方面得到收益。
第一，基本已经对这个模块未来会如何发展了然于胸，脑中已经至少有了一二三期规划。业务再提类似的需求，都能做到胸有丘壑心里不慌。
第二，通过搜集数据，也能发现这个模块和薪酬模块，BI模块有着千丝万缕的关系，那未来这些模块需要开发和迭代的时候，可以成为当仁不让的人选。
第三，可以把自己对这个模块的未来规划，在一开始就和开发沟通好，尽量结构化一些数据，虽然界面上还没有支持自定义配置，但未来是需要往这个方向扩展的。产品是产研团队的上游，不能只敢眼前的活儿，不然整个产研团队也会经常被突入其来的事情困在眼前。
以上就是关于这个模块的设计心得。下次再见～
本文作者 @假装是运营
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
