组织敏捷转型中的 HR

本文来自作者 Andy 王威 在 GitChat 上分享 「组织敏捷转型中的 HR」，「阅读原文」查看交流实录。

「文末高能」

编辑 | 哈比

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 对于敏捷团队而言意味着什么。

1. 绩效评估

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

2. 考核

KPI 是考核内容的一部分，如同 KPI 字面的意思，它是针对可预见的若干关键项的目标设定及考核；一般而言，关键项的数量不宜过多，3 - 4 项就可以了。

由于 KPI 是对可预见的关键项的评价，而在知识型工作当中，尤其是在当今风云变化的市场环境下，有很多关键的事情是涌现出来的，很难在年初（如果 KPI 是年度的）就预见到，因此只用 KPI 做考评是非常危险的做法。

这导致组织只有能力处理那些确定的、可预见的、但同时可能被市场抛弃的机会，而对那些业务价值更高、更关键的机会视而不见。

此外，无论是一些一线经理，还是一部分 HR，缺乏设定高质量的 KPI 的能力。

譬如说，在一家全球知名的大外企里，我一个朋友的 KPI 被设定为：1）每年完成两个项目；2）每年的在岗率为 93%（也就意味着，除了公司给的 17 天年假，一年只能休半天的病假 / 事假）。

完成多少项目，这由项目长度、以及组织对人员的调度决定，是 HR 和管理者的责任，怎么可以成为一线员工的 KPI！而在岗率就更加不人性化了。外企尚且如此，遑论国内一些企业，发展速度过快，HR 和一线管理者的专业知识、技能储备不足，于是荒谬的 KPI 也就不在少数了。

除了 KPI（注意：KPI 也只是多种考核方式中的一种，而非唯一选项），考核内容中还有一个组成部分是面向未来的指标，那些不实现当前业绩、但对于组织和团队未来的发展、机会至关重要的事情。

由于未来具有较高的不确定性，所以这部分指标不能过于具体，不适合设定定量指标。这一类指标可以着眼于团队和个人的学习能力、知识积累与沉淀。

3. 评价

很多团队对 KPI 持负面看法，原因之一，KPI 往往是不靠谱的、拍脑袋的；原因之二，如果只用 KPI（或者再加上面向未来的指标）来做绩效评估，那么团队难以注重协作，每个人首先在意的都是自己的 KPI 是否能够达成。

我在跟国内某知名企业的 HR 做访谈的时候提及，团队可以通过结对工作的方式让领域专家把知识和经验传递给新人，这位 HR 的第一反应是，这对领域专家有什么好处？没有好处的话为什么 TA 要帮新人。对自己没有好处就不做，这样的团队和组织着实令人堪忧。

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

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

4. 绩效 = 考核 + 评价

绩效评估是研发团队对于 HR 最直接的印象。绩效评估体系的设计是否合理，直接影响到团队的运作。很多时候，HR 设计了绩效评估体系，由管理者为团队 / 个人设定绩效目标、评定绩效结果。

那么 HR 首先要思考清楚，当前的绩效评估体系鼓励了什么、抑制了什么；它是结果导向的，还是过程导向的；它全面地评估了个体和团队的表现并着眼于组织未来的竞争力，还是片面地追求个别指标。

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

再者，HR 要帮助不同的团队、部门把 KPI 对齐在一起，确保它们与组织整体的业务目标保持一致。我见过比较扯的 KPI 设定，2011 年度部门级别的 KPI 是 “月度活跃用户数 2300 万”，分解到各团队就变成 “Android 月活 300 万”、“Symbian 月活 1200 万”……

在 Android 手机迅猛发展的当时，300 万的目标是躺着都可以实现的，而日暮西山的 Symbian，1200 万月活是无论如何都无法实现的，而最终这些 KPI 并没有真正地与部门 KPI 对齐在一起（思考一下，为什么说没有对齐？），那么实现部门目标也就是无根之萍了。

5. 招聘

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

然而在实际招聘过程中，我在不同的组织见过各种各样的 HR。某超大型快速发展的国内企业，团队抱怨 HR 把收集简历、筛选简历、面试候选人的任务完全丢给团队，但保留了最后考察候选人软技能的环节，并且经常地拒掉了团队花费大量时间精力才锚定的候选人。

某跨国外企的 HR 为了能够招聘进来人才，随意地许以高额补助，但员工入职后才发现所有人的补助都采用统一的计算方式，不可能兑现当初的许诺……

6. 考勤

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

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

准时出勤是需要人们采取行动，而非不采取行动，因此在考勤这个问题上，我们思考的方向必须是 “如何鼓励员工准时出勤”，而非 “如何阻止员工迟到”。

用同侪压力、团队回顾会议、欣赏式探询、1：1 沟通等方式，激发知识型工作者内在的责任心，可以很好地鼓励员工准时出勤。

相反地，用考勤制度惩罚员工的迟到行为，也会打击到其责任心。一个消极的知识型工作者给组织带来的问题，可能会远大于其带来的价值。

不同的团队有不同的运作特点，如有的团队需要与欧洲的团队频繁沟通，其出勤规律适合于晚一些上班，晚一些下班；

而有的团队需要与美国的团队频繁沟通，其出勤规律适合于早一些上班，相应地早一些下班；iOS 开发团队在熬夜看了苹果开发者大会，势必第二天需要晚一些上班……

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

7. 培训

在超大型组织中，会设立专门的机构负责员工的培训教育；但在大多数组织中，这是 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

8. 小结

本节将敏捷转型放在一边，先讨论了在一般的 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 达成共识，才会在组织中推行这些改变，但大体方向已经是很明确的。例如：

1. 自组织团队的招聘

在自组织团队中，团队参与甚至决策新团队成员人选。HR 会担心招聘会耗费团队过多的精力，或担心团队不具备能力找到合适的新成员。

这种担心其实是不必要的。HR 可以和团队一起设计招聘策略，从而只将优秀候选者暴露在团队视野中（例如，有的 HR 会预先筛选候选者简历，从超过 30 位候选者筛选到 5 位左右）。

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

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

2. 建设学习型组织

最近一年在辅导两个国内大型企业的过程中，我时常感叹：分明是业绩不错的互联网企业，怎么还采用 机械性组织（注 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

近期热文

《300万粉丝，全国最大的线上抽奖平台，深度解析》

《高可用、高性能？ 接口设计的 16 个原则》

《【钓鱼】与【反钓鱼】的技术剖析》

《快速了解 Java 9 平台模块系统》

《机器人的「语料」，如何获取？》

成为一个机智的敏捷教练

「阅读原文」看交流实录，你想知道的都在这里