手把手学做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. 企业设定绩效规则,包括要考核哪些指标,以及计算结果(完成率或加权总分);
  2. 员工/管理者设置期望达到的目标;
  3. 员工设置目标值后逐级审批;
  4. 领导周期性检查绩效达成情况。

而我司现状要求的步骤不同,由三步构成:

  1. 设定考核。项目考核主要由甲方驱动和设置,内部有针对岗位和业务部的考核。
  2. 绩效填写。无法从甲方取数时,绩效结果依赖于考核人自己填写。
  3. 领导周期性检查绩效达成情况&员工上报的绩效分析。

除了最后查看的步骤大体一致,绩效模版生成到产生数据的逻辑都不太一样,所以基本判定为我们现在要求的是一种比较特殊的流程。

产品经理,产品经理网站

再进一步把事(绩效)拎出来。

首先穷举不同绩效模版的模式,然后归纳总结成一张绩效考核的字段全表。接着对表格的各个部分进行分类,明白每个类别的作用,进而考虑到每个类别在配置页面中是否需要体现。

产品经理,产品经理网站

关于绩效管理的信息分析,到此为止告一段落。

到现在你应该了解了绩效管理对于企业经营的意义,线下实施绩效管理的一般方案,以及我们服务的企业和常规方案的不同在哪里。

三、设计方案

信息的整理完成后,接下来我们需要进入方案设计了。

1. 功能分期

先不要着急画UE,我们还有更重要的事情,即需要就现有资源,设计整个模块的产品演化路径。这样能给到业务部门清晰的规划,我们计划分多少期完成什么样的需求,未来计划可以支持的类型有哪些。

从本次的案例来说,我们可以用四分法拆分现有需要支持的所有绩效考核事项。

分期以后,指向的工作进一步清晰了。

首先会支持客户制定绩效,客户处查看绩效的模块,未来这类需求都用定制模版的方法来实施,即业务说明需要统计哪些内容,以及对应的目标值等数据是多少,开发针对该种情况单独定制一个模版。

未来会扩展支持通过后台字段组合,配置生成对应的考核模版,这样意味着我们对于模版后期还要做更多的投入,且要建立对应的模版指标库,才能实现系统自动生成考核结果数据。

产品经理,产品经理网站

2. 功能设计

就一期功能而言,操作SOP如下:

1)线下确认好对应模板

  • 模版需要填写哪些内容;
  • 哪些内容是已经填写好数值的;
  • 哪些内容是需要被考核人填写的。

2) 配置好考核模板后,模版展示在列表中

  • 有查看/编辑权限的人,可见该考核模版;
  • 如果指标等数据有修改,产研团队人工协助修改。

产品经理,产品经理网站

3)可以通过编辑功能,调整相关信息

产品经理,产品经理网站

4)对应用户,可进入查看/编辑数据

所有人可查看的数据范围受数据权限约束。

产品经理,产品经理网站

对应SOP设计完成后,记得尽量和业务同事核对一次。避免偏差。

四、尾声

这个需求的最后呈现,说真的并不大复杂。考虑到业务对绩效模块的价值认可度比较有限,时间又紧张,设计了简单的但未来可扩展的方案。

但是由于经过了大量的信息搜集和分析,至少能从几个方面得到收益。

第一,基本已经对这个模块未来会如何发展了然于胸,脑中已经至少有了一二三期规划。业务再提类似的需求,都能做到胸有丘壑心里不慌。

第二,通过搜集数据,也能发现这个模块和薪酬模块,BI模块有着千丝万缕的关系,那未来这些模块需要开发和迭代的时候,可以成为当仁不让的人选。

第三,可以把自己对这个模块的未来规划,在一开始就和开发沟通好,尽量结构化一些数据,虽然界面上还没有支持自定义配置,但未来是需要往这个方向扩展的。产品是产研团队的上游,不能只敢眼前的活儿,不然整个产研团队也会经常被突入其来的事情困在眼前。

以上就是关于这个模块的设计心得。下次再见~

 

本文作者 @假装是运营

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部