组织敏捷转型中的 HR

csm
Scrum Master 中文CSM认证-18年3月-上海 (PMI ACP & PMP PDU, CSM)
2017年12月7日
24K含金量!Scrum Alliance导师级CTC认证于2018年全面升级
2017年12月9日
作者/Gitchat分享人:Andy 王威

Human Resources,也就是人力资源。似乎每个人都不可避免地与HR打过交道,从面试,到入职,到涨工资,到离职……HR的职责是什么?HR在敏捷转型中扮演什么样的角色?HR应该在敏捷转型的什么阶段介入?在敏捷社区中,针对HR这个似乎伴随着我们在一家企业工作的全过程的角色的讨论非常少,也没有旗帜鲜明的观点。即便是在SAFe或者LeSS这样的组织级敏捷框架中也不曾讨论过这个问题。

但这是一个真实存在的问题!很多团队反应,团队级别的敏捷改进到了一定阶段后,如果包括HR在内的整个组织不能跟随团队的进程一并发生变化,那么来自于组织的天花板将完全限制团队进一步改进。

  1. 概括性讨论HR的职责、以及在不同规模的组织中HR职责的变化;
  2. 结合研发团队的关注点,深入探讨特定职责的细节、胜任的HR在这一方面能够给组织和团队带来的价值、以及不胜任的HR给组织和团队带来的危害;
  3. 站在HR的立场上,TA们是如何看待研发团队的,所谓知彼知己;
  4. 在敏捷变革中,变革推动者们,包括敏捷实践者和HR,应该如何协作。希望以本文抛砖引玉,能够激发更多的讨论。

HR是做什么的?

我曾经在一个微信群组里问敏捷社区的同志们,HR的职责是什么。有人的回答相当精辟,四个字“选用育留”。

  • 选人:企业每天都会收到成百上千封求职信,如何能够在海量简历中筛选出来高质量的候选人,这是一个需要经验与技巧的工作。有经验的HR能够向职位经理指出候选人在性格、团队协作等方面的优缺点;有的企业里HR能够一票否决候选人。
  • 用人:如何把员工放在合适的位置上,让其能够为企业带来最大价值?HR站在产品线之外,可以从整个企业的角度观察员工与岗位的匹配度。
  • 育人:员工的能力需要持续发展。无论是在组织内部的学习分享、培训(内、外部培训)、员工职业道路发展、软技能提升,都离不开HR的参与。
  • 留人:这可以说是员工最关注的部分。薪酬岗位体系设置、员工考评、涨薪、升职、移除组织障碍……

但是这也只是对HR职责的简单归纳。在实际企业运作当中,不同行业、不同规模的公司里,HR的职责和表现可以大相径庭。一般而言,在中小型企业、以及大型/巨型企业中,HR的职责有明显的不同。

国家对IT企业的规模划分是:

  • ≤10人:初创/微型企业;不需要(专职)HR
  • 10 – 100人:小型企业;不需要专职HR,或HR只起到行政、辅助、事务性质的作用
  • 100 – 300人:中型企业;HR关注员工薪酬、绩效、招聘等方面的工作
  • ≥300人:大型企业;HR开始出现分工:统筹全局的HR,以及入驻每个部门的HRBP (HR Business Partner),后者的职责更类似于中小型企业中HR的作用,而前者则更重视诸如薪酬体系、考评体系、职位岗级体系等的建设与运作
  • ≥10000人:虽然国家没有对超过万人的IT企业有所谓“超大型企业”的划分,但是超过万人的IT企业,如腾讯、阿里、京东等,已经不再是单独的企业,而是企业集团,由多个大型组织构成;HR的分工更加明确,相对于大型企业中的HR,企业集团的HR还会关注企业人才储备、企业面向未来的业务/产品形态/技能/职位/人才建设等,着眼于布局企业在下一个技术革命中的参与度和定位

我们日常打交道最多的是HRBP,因此在本文中我提到的HR,绝大多数时候默认的也是HRBP。但在大型、尤其是超大型组织中,负责薪酬体系、考评体系、职位岗级体系建设,以及人才储备、着眼未来布局的HR,在以他们的视角和理解去重新定义企业、改造企业。打造敏捷组织,需要敏捷推动者与这些HR达成一致意见,组成联盟,并形成合力以推进组织变革。如果我们彼此完全不了解、不信任、不认可,那么敏捷转型只能是一纸空谈。

研发团队眼中的HR

我询问了身边一些朋友,他们对于HR/HRBP的印象是什么。收集到的关键字集中于:管绩效的、管招聘的、管考勤的、管培训的。那么我们分别看一看,在这四个方面,HR对于敏捷团队而言意味着什么。

绩效评估

每个人都经历过很多次绩效评估(Performance Review);每个人对什么是绩效评估也有各种各样的理解。很多人认为,绩效评估就是KPI;甚至一些缺乏专业知识的HR也会这么认为。但这是错误的认知。在专业的HR看来,绩效评估大致由两部分构成:考核+评价。

考核

KPI是考核内容的一部分,如同KPI字面的意思,它是针对可预见的若干关键项的目标设定及考核;一般而言,关键项的数量不宜过多,3 – 4项就可以了。由于KPI是对可预见的关键项的评价,而在知识型工作当中,尤其是在当今风云变化的市场环境下,有很多关键的事情是涌现出来的,很难在年初(如果KPI是年度的)就预见到,因此只用KPI做考评是非常危险的做法。这导致组织只有能力处理那些确定的、可预见的、但同时可能被市场抛弃的机会,而对那些业务价值更高、更关键的机会视而不见。

此外,无论是一些一线经理,还是一部分HR,缺乏设定高质量的KPI的能力。譬如说,在一家全球知名的大外企里,我一个朋友的KPI被设定为:1)每年完成两个项目;2)每年的在岗率为93%(也就意味着,除了公司给的17天年假,一年只能休半天的病假/事假)。完成多少项目,这由项目长度、以及组织对人员的调度决定,是HR和管理者的责任,怎么可以成为一线员工的KPI!而在岗率就更加不人性化了。外企尚且如此,遑论国内一些企业,发展速度过快,HR和一线管理者的专业知识、技能储备不足,于是荒谬的KPI也就不在少数了。

除了KPI(注意:KPI也只是多种考核方式中的一种,而非唯一选项),考核内容中还有一个组成部分是面向未来的指标,那些不实现当前业绩、但对于组织和团队未来的发展、机会至关重要的事情。由于未来具有较高的不确定性,所以这部分指标不能过于具体,不适合设定定量指标。这一类指标可以着眼于团队和个人的学习能力、知识积累与沉淀。

评价

很多团队对KPI持负面看法,原因之一,KPI往往是不靠谱的、拍脑袋的;原因之二,如果只用KPI(或者再加上面向未来的指标)来做绩效评估,那么团队难以注重协作,每个人首先在意的都是自己的KPI是否能够达成。我在跟国内某知名企业的HR做访谈的时候提及,团队可以通过结对工作的方式让领域专家把知识和经验传递给新人,这位HR的第一反应是,这对领域专家有什么好处?没有好处的话为什么TA要帮新人。对自己没有好处就不做,这样的团队和组织着实令人堪忧。

因此,在考核之外,作为绩效评估的一部分,我们还需加上对个人和团队的评价。这可以是360评价、You made my day(注1)等评价方法。评价侧重于团队协作、沟通,往往是定性的,而非定量。

*注1:当某人做出额外的贡献,或是在工作中表现优异,让相关同事感到开心,那么相关同事向双方的manager和HR发出You made my day表扬邮件。

绩效=考核+评价

绩效评估是研发团队对于HR最直接的印象。绩效评估体系的设计是否合理,直接影响到团队的运作。很多时候,HR设计了绩效评估体系,由管理者为团队/个人设定绩效目标、评定绩效结果。那么HR首先要思考清楚,当前的绩效评估体系鼓励了什么、抑制了什么;它是结果导向的,还是过程导向的;它全面地评估了个体和团队的表现并着眼于组织未来的竞争力,还是片面地追求个别指标。

其次,HR要充分地协助、指导管理者为团队和个人设定恰当的绩效目标。机制再好,使用不得当,也只能给组织带来损伤。

再者,HR要帮助不同的团队、部门把KPI对齐在一起,确保它们与组织整体的业务目标保持一致。我见过比较扯的KPI设定,2011年度部门级别的KPI是“月度活跃用户数2300万”,分解到各团队就变成“Android月活300万”、“Symbian月活1200万”……在Android手机迅猛发展的当时,300万的目标是躺着都可以实现的,而日暮西山的Symbian,1200万月活是无论如何都无法实现的,而最终这些KPI并没有真正地与部门KPI对齐在一起(思考一下,为什么说没有对齐?),那么实现部门目标也就是无根之萍了。

招聘

HR在招聘中扮演的角色和作用随着组织不同而很不一样。一般而言,HR在招聘中承担了两次筛选的作用:1)从海量简历中筛选优质候选人推荐给相关管理者;2)在面试中考察候选人的软技能和协作、融入团队的能力。能够胜任这两次筛选的HR,对组织的帮助是十分巨大的。

然而在实际招聘过程中,我在不同的组织见过各种各样的HR。某超大型快速发展的国内企业,团队抱怨HR把收集简历、筛选简历、面试候选人的任务完全丢给团队,但保留了最后考察候选人软技能的环节,并且经常地拒掉了团队花费大量时间精力才锚定的候选人。某跨国外企的HR为了能够招聘进来人才,随意地许以高额补助,但员工入职后才发现所有人的补助都采用统一的计算方式,不可能兑现当初的许诺……

考勤

我一直很好奇,为什么在很多公司要有统一考勤,而为什么考勤又是HR来负责。支持这种制度的人肯定能说出一堆的道理出来,但有一个问题是他们回答不了的:知识型工作者的责任心,到底是依靠正向的鼓励激发出来的,还是依靠负向的惩罚而实现的。

2017年11月的《哈佛商业评论》给出了答案。在《奖励和惩罚,哪种方式激励员工更有效?》的文章中,作者Tali Sharot写到,“……就行动激励(例如增加工作时长或撰写优秀的报告)而言,奖励往往比惩罚更有效。反过来,当人们尝试阻止他人去做某件事……惩罚更有效……我们的大脑已经适应了这种环境,即获得奖励的最佳方式便是采取行动……避免伤害的最佳方式(不一定总是)便是不采取任何行动。”

准时出勤是需要人们采取行动,而非不采取行动,因此在考勤这个问题上,我们思考的方向必须是“如何鼓励员工准时出勤”,而非“如何阻止员工迟到”。用同侪压力、团队回顾会议、欣赏式探询、1:1沟通等方式,激发知识型工作者内在的责任心,可以很好地鼓励员工准时出勤。相反地,用考勤制度惩罚员工的迟到行为,也会打击到其责任心。一个消极的知识型工作者给组织带来的问题,可能会远大于其带来的价值。

不同的团队有不同的运作特点,如有的团队需要与欧洲的团队频繁沟通,其出勤规律适合于晚一些上班,晚一些下班;而有的团队需要与美国的团队频繁沟通,其出勤规律适合于早一些上班,相应地早一些下班;iOS开发团队在熬夜看了苹果开发者大会,势必第二天需要晚一些上班……

一刀切的出勤制度完全是懒政;而用打卡、刷脸等方式做统一考勤,这是HR工作上的误区。HR需要认识到这一点,意识到不能用传统的体力劳动管理手段来管理知识型工作者。卓越的组织大多都有着灵活的出勤制度,也很少会做强制考勤。

培训

在超大型组织中,会设立专门的机构负责员工的培训教育;但在大多数组织中,这是HR的工作。

组织内部有优秀的领域专家,HR需要发掘、动员专家提供培训、工作坊。这在有的组织里以Brown Bag Lunch机制(注2)为依托,有的组织里则是定期的技术论坛。HR需要去了解组织中现在缺少什么技术、员工需要什么内容的培训,有的放矢地组织培训。

当组织内部缺乏领域专家时,组织要向外部寻找专家提供培训。在大多数技能、专业领域上,HR是不懂的,因而HR也不具备能力寻找合适的培训师。如果团队能够寻找到领域专家,那么应该让团队做决策,HR协助做好商务和后勤方面的工作就好。

HR不愿意把培训的决策权放给团队的理由之一是预算。很多组织里,培训的预算是在年初的时候制定的,并且是面向整个组织/部门的。HR担心团队会不理智地安排培训,迅速把全年的培训预算都消耗掉。但HR应该反思的是年度预算的方式是否可以改进,而不是控制团队的培训诉求。只要回报大于投入,那么就值得做培训。

*注2:对brown bag lunch的介绍可参见这里 http://language.chinadaily.com.cn/trans/2012-08/06/content_15647044.htm

小结

本节将敏捷转型放在一边,先讨论了在一般的IT研发团队中,HR对组织和团队的价值、HR需要修正/秉持的观念、以及糟糕的HR会带来的危害。下一节我们将探讨从HR的角度来看研发团队,有一些什么有趣的想法和认知差异。最后我们将讨论在敏捷转型过程中,HR和研发团队应该如何合作,以推动组织变革更快、更顺利地进行。

HR眼中的研发团队

最近我有幸跟一位HR高管做深度访谈,从她的视角来看待组织变革、研发团队,是与敏捷教练、团队管理者完全不同的,非常有意思。由于撰写本文的时间仓促,我未能与很多HR做广泛的深度对话,不敢说了解HR普遍是如何看待研发团队的,所以且将与这位HR高管的对话做一个简单的整理,供各位参考。

这位HR高管来自于10万+员工的某国内超大型IT企业。在这么大体量的企业里,在她这么高的位置上,她所着眼的并不是具体的事务,而是思考如何构建组织级别的宏观战略部署。例如,她思考并与很多专家探讨什么是未来技术变革的关键因素,以及组织如何才能在未来技术变革中占据领导地位。在她看来,ABC (AI, Big data, Cloud)中关键的技术在于AI和Big data,因此组织从现在就要开始招聘、储备相关的人才,并支持他们投入相关领域的研究。

在组织变革方面,她也一针见血地指出,组织变革需要变革推动者Change agent。部分敏捷教练具备成为change agent的能力,但另外一部分教练只是教练;除了敏捷教练,change agent还来自于许多其它领域,尤其是HR。

在这位HR高管看来,现有的研发团队,尤其是架构师,更着迷于把某个应用或服务做得更加完美;可是站在她的角度,她认为架构师应该具备这样的能力,即将多个应用或服务组装/配置在一起,灵活地形成各种解决方案;在未来,应用和服务的模块化会越来越标准,研发团队无需为实现功能发愁,但怎样把业务问题抽象出来、制定解决方案、并通过配置现有应用/服务的方式实现,这种所谓“解决方案架构师”的重要性很高。

这位HR高管的观点对错与否且不论,她看问题的角度是与研发团队不一样的。敏捷实践者推动组织变革的方式往往是在部分团队中尝试变化,获得变革的经验,并在取得成果后向更大范围推广。而在HR的角度,往往一开始就是站在全局思考的;固然她也会在局部做试验,但是试验更多的是为了验证她的设想,而不是摸索一个尚无答案的问题。研发团队关注于关键技术,而HR更关注于关键能力。

敏捷转型中的HR

讨论了研发团队眼中的HR,以及HR眼中的研发团队,我得出这样的一个结论:作为对HR缺乏深度了解的一名敏捷教练,其实我很难给出具体的方案,在敏捷转型过程中的组织里HR应该怎么做。在很不了解对方的工作的情况下,任何建议都是不负责任的。那么,作为组织中的变革推动者,我们除了需要开始与其他推动者更深入地彼此了解,还可以做的一些事情是:

胜任的HR

在上述的讨论中我们看到,如果HR是胜任的,那么TA能够给组织带来的价值、给团队带来的帮助是巨大的。但如果HR是不胜任的,就会出现各种怪异的、荒诞的现象,从而给组织、团队和个人带来的灾难也是巨大的。我们要去了解HR,看看TA们是否存在能力和知识上的短板,帮助TA们更好地胜任HR职位。必要时,作为change agent的我们,要去学习HR相关的知识,以便我们可以更好地了解、帮助HR。

协作以推动变革

我们需要意识到,我们并非是组织中唯一的change agent。对于包括HR在内的其他change agent,我们要与之形成联盟,形成合力以推动变革进行下去。我们提倡研发团队内部和团队之间、业务线之间要协作,我们作为change agent又何尝不是如此。

在主动去了解HR之外,我们也要主动地向HR宣传敏捷思想。敏捷不仅仅是针对软件开发的,它对大多数需要协作的知识型工作都适用,HR也不例外。思考如何用HR能够听得懂的说法,将敏捷理念和实践当中适用于HR的部分传递给他们。一旦HR理解并接受了敏捷理念,他们也将从他们的角度思考如何帮助敏捷转型进行下去。

一些现在就可以预见到的改变

有一些与HR相关的改变,是在敏捷社区中讨论已久、并且有不少组织已经尝试过并取得很好效果的。虽然我们仍然要与HR达成共识,才会在组织中推行这些改变,但大体方向已经是很明确的。例如:

自组织团队的招聘

在自组织团队中,团队参与甚至决策新团队成员人选。HR会担心招聘会耗费团队过多的精力,或担心团队不具备能力找到合适的新成员。这种担心其实是不必要的。HR可以和团队一起设计招聘策略,从而只将优秀候选者暴露在团队视野中(例如,有的HR会预先筛选候选者简历,从超过30位候选者筛选到5位左右)。

总部位于荷兰的ING银行集团在敏捷变革过程中的做法是,团队参与面试并向主管推荐入选人,主管不能决定录用谁,唯一的权力是否决团队的推荐(而在ING上千个职位的招聘中,否决团队推荐的情况基本上没有发生过)。

从技术角度,团队更清楚他们缺乏什么样的技能,也更容易识别出哪位候选人在急需的技能方面具备足够的实力。HR需要帮助团队的,是在技术之外增加候选者之于团队的多样性,如教育、年龄、性别、文化背景等。

建设学习型组织

最近一年在辅导两个国内大型企业的过程中,我时常感叹:分明是业绩不错的互联网企业,怎么还采用机械性组织(注3)的结构和运作模式,以至于产生了巨量的浪费。在总体经济发展的时候尚不觉得怎样,一旦经济出现萎缩,体量如此巨大、浪费如此巨大的企业,怕是最先死掉的。固然组织规模很大的时候,机械性组织具有易于管理的好处,但在市场环境变化莫测、所有企业都注重加快上市速度的今天,在机械性组织中只见任务计划排期、不见业务价值流动,其蹒跚程度是难以接受的。

当前多数互联网企业都采用有机性组织结构(注4)。有机性组织中较为常见的一种结构是矩阵式结构(Matrix Structure),简单来说就是人同时受到职能线经理和产品/项目经理的领导,具有双重汇报关系。

而更进一步地,从长期来讲,敏捷组织应该是学习型组织(注5)。所有的变革推动者,无论是敏捷实践者还是HR,都应该深入了解学习型组织的原则、特点,并思考如何推动所在组织向学习型组织发展。特别地,学习型组织的胜任管理体系(以及与之相关的绩效评估体系)是与其它类型组织截然不同的,这需要HR推翻既有胜任管理体系,重新建立符合学习型组织的一整套体系。

还有更多的改变吗?也许是的。但是我倾向于在于HR互相了解的过程中与对方达成共识,而不是单方面地站在研发团队的角度对其发号施令。因此,本文完。多谢各位不嫌弃我文笔之差、思想之贫瘠,阅读到最后。

*注3:机械性组织介绍参见http://wiki.mbalib.com/wiki/%E6%9C%BA%E6%A2%B0%E5%BC%8F%E7%BB%84%E7%BB%87

*注4:有机性组织又名适应性组织,介绍参见http://wiki.mbalib.com/wiki/%E6%9C%89%E6%9C%BA%E5%BC%8F%E7%BB%84%E7%BB%87

*注5:学习型组织介绍参见http://wiki.mbalib.com/wiki/%E5%AD%A6%E4%B9%A0%E5%9E%8B%E7%BB%84%E7%BB%87

评论关闭了。