Human Resources，也就是人力资源。似乎每个人都不可避免地与HR打过交道，从面试，到入职，到涨工资，到离职……HR的职责是什么？HR在敏捷转型中扮演什么样的角色？HR应该在敏捷转型的什么阶段介入？在敏捷社区中，针对HR这个似乎伴随着我们在一家企业工作的全过程的角色的讨论非常少，也没有旗帜鲜明的观点。即便是在SAFe或者LeSS这样的组织级敏捷框架中也不曾讨论过这个问题。
但这是一个真实存在的问题！很多团队反应，团队级别的敏捷改进到了一定阶段后，如果包括HR在内的整个组织不能跟随团队的进程一并发生变化，那么来自于组织的天花板将完全限制团队进一步改进。
- 概括性讨论HR的职责、以及在不同规模的组织中HR职责的变化；
- 结合研发团队的关注点，深入探讨特定职责的细节、胜任的HR在这一方面能够给组织和团队带来的价值、以及不胜任的HR给组织和团队带来的危害；
- 站在HR的立场上，TA们是如何看待研发团队的，所谓知彼知己；
- 在敏捷变革中，变革推动者们，包括敏捷实践者和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
