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

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

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

很多人也会认为,从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系统有对销售的目标划定。这些产品都可以成为考察的范围,他们的通用化设计思路可以给后续工作带来一些灵感。

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

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

等待的过程中,请收藏,点赞,多多益善~