[Day7] 人才配置:合适的人、合适的运用

从资源配置的角度思考

产品经理不一定有人事决定权,但是可以从资源的角度给予建议

这个是一个特别的经历,一般产品经理很难会有IT的人事决定权,但因为管理职会看对於人的敏锐度,加上我的背景有资工,和前一份工作的表现,我很幸运能有机会可以参与面试,和人资一起进场面试,可以学到很多感知人的技巧,也学到如何旁敲侧击了解一个人的人格特质,我所待的公司,在一定硬实力下,特别看重人格特质,除了文化因素以外,重要的是新创团队,团队人数不多情况下,人员就要特别精实而且稳定。一个团队最重要的就是成员,团队的起点也是成员,合适的成员,可以让管理成本与沟通成本降到很低,对於形塑文化与冲刺目标都会打下良好基础;不合适的成员,则会需要花上许多时间为其寻找着力点,也需要花心思监督与引导,如果真无法有所改善,为了个人成长与公司发展,就必须发展到分离,对部属与主管都不好受。这里说的合适,并非讲思考模式、做事方式要公司一致才是好的,而是具备共同的核心特质,像是野心(Ambitious)、专注(Focused)等,成员还是要保持多元性,这些核心特质通常是事业体主管或是执行长层级会定义,而产品经理所要做的便是在掌握目标後,思考需要怎样的技术人员後,若公司文化允许或是和技术用人主管够有默契,则可以提出给他们参考,若就一般产品经理职权内,至少要为自己做好人力资源能力盘点,因为我们要和他们长期合作了。

从运用资源角度思考

在当下、在条件下,人才发挥其该有功效,便是最大功效

这样说或许会很市侩,然而事实是,产品经理所掌握的资源之一,就是人力资源。我们或许不会有人事权,但我们会跟工程人员紧密合作,所以了解人员状态与特质,进而促使工程人员可以一起参与、一起强化学习,是有影向力的产品经理必备能力。目前,我在和工程师互动上,尚未需要透过技术主管(有技术主管就需要尊重他用人的判断,这时候,我们也是要先和技术主管培养默契後,才会和工程师合作),所以我需要直接感知工程师的特性,目前我会以2个面向来区分,其目的只有一个,帮助工程师建立团队参与感与自信心:

  1. 能发挥能量的时间点
  2. 深思型和敏捷型

发挥能量的时间点,分为短中期战力型与长期酝酿型,前者,我会给予一些明确而且短期可以看到成效的任务,通常这类任务会是BAU,这一类型,因为Outcome显着也比较容易很快建立自信心与合作默契,但之後就是要注意慢慢配比长线任务,使其能力得以延展;比较具挑战的是後者,因为长期酝酿,所以不会有立竿见影的效果,容易让人在前期忽略他的效益,进而影响成员参与感与自信建立,目前由於我们公司采用OGSM的机制,所以我将Goal会与全体成员共识且明定,在边执行的过程里,不会忽略长期酝酿的贡献。而深思型与敏捷型,会决定我和工程师讨论的方式,深思型的人,我会提早抛明确目标与简易想法,并会预期我需要多次和他的对话,辅助他在正式要提供意见或是想法时,就能有预先的准备;反之,敏捷型的人,我一样会提早抛目标和想法,但是会在一次的讨论里面,快速抛接意见球,告一段落後,只要一有新的想法,我也会很快地回馈。因为工程师的工作属於发想创意类型,所以我会倾向先以他们习惯的方式,在有限资源下,保留一些空间,得到好的答案。

人才运用,我觉得最重要的是要先成功,成功几次,会帮助团队的凝聚,也会让成员有自信,等到时机到,人工地或自然地发生一些严苛条件,导致失败几次,我们在过程中,只要确保有新的学习、新的省思,并朝着目标前进即可。


<<:  创作App-Xcode资料库

>>:  Maven简介

DAY28 - 来试试看 line notify吧

在前一篇把 line message api 缺点和难用的地方写出来後,其实也在找其他的替代品,有...

[Day14]Fourth Point!!

上一篇介绍了Parking,题目是说在一条很长的道路上,选择任意位子停车,要输出走去各点并回到停车处...

什麽是MVC框架? 如何用UML建模?

MVC模式的架构元件被设计用来处理开发中的应用程序的不同方面。MVC设计模式的作用是将表现层与业务逻...

帮服务建置布署流程至 EC2

有了建置 Image 的流程,和前後端分离的机制,接着我们就可以设定 CICD 的流水线来进行服务自...

[Day 6] 使用 kotlinx.serialization 转换 JSON

在 Java 的世界中,有很多种 json library 任君挑选,其中最多人使用的应该是 Jac...