第186讲|赵晓光:如何培养团队竞争力(上)
文章目录
你好,我是 Resideo 技术总监赵晓光,今天想跟大家聊聊团队能力培养的话题。“竞争力”常见的表达是能力的竞争,“能力”这个词在我们日常生活中太常见了,张三能力很强,李四能力一般,王五能力不足等等……但何为“能力”?我们也经常听到某人在某岗位上很有竞争力,那什么是“竞争力”呢?
我认为,首先,能力是指一个人或者一个团队保证工作成效,能正确执行工作任务的技能、知识、经验以及行为,并且这些都是可以论证且有因果关系的。我们经常讲知识就是力量,知识就是能力的一部分,而经验也可当作知识,但只有知识加上行动才是能力的体现。这也是我这样理解能力的原因。
其次,竞争力是能力的升级版或者专业版,更加注重于如何完成特定任务的能力。竞争力是指在完成具体任务时所体现的能力,如果抛开具体的任务,是无法谈竞争力的。因此,我对竞争力的理解是:在大部分场合,竞争力和能力是一回事儿,在对内的场景下一般讲能力,在对外的场景下一般讲竞争力;在合作的场景下讲的是能力,在角逐的场景下讲的是竞争力。无论能力还是竞争力,都有如下特点:
1. 需要针对特定任务,对于不同的工作任务,竞争力的要求是不一样的,进一步来讲,执行不同工作任务的能力要求也不一样,就如同 CEO 和 CTO 的能力要求不一样,软件架构师和软件工程师的技能要求不一样,销售和工程师的要求不一样,同理在研发团队内部,对于不同部门的能力要求也会不同;
2. 可重复,竞争力是保证我们所执行的工作能够完成的必要条件,并且要正确,有效率。如果只是勉强可以维持,错误百出,则不能称之为能力。就比如现在大家都在谈人工智能,如果某个公司的人脸识别算法仅仅是偶尔能够识别出一个人来,是不能称之为有人工智能能力的,同样的,如果一个团队不能在同一类任务中保持绩效的可持续及迭代提高是不能被认为有竞争力的;
3. 有显著的因果关系,竞争力是可以被显著的因果关系论证的。以 AI 团队为例,拥有多名算法专家,并且专家的技能被用于算法的设计、调优等,从而保证发布的算法都是业内领先的,那这可以称之为团队的能力和竞争力;相反,虽然团队有很多专家,但仅仅因为某次误打误撞撞到了一个看起来不错的模型,甚至都不知道为什么,我是不赞同称这个团队有竞争力的。这就是为什么竞争力不但要含有知识的部分,还要有行动的部分,能够正确的使用个人能力是团队竞争力的保障。
团队竞争力培养的关键因素
对于任何一个团队,在团队竞争力培养的这件事儿上,首先要有明确的定位,大致可以分为四个层面:
- 1. 明确团队的愿景、使命、价值观;
- 2. 明确团队当前的能力;
- 3. 制定发展战略;
- 4. 设定周期性目标以及关键结果。
明确团队的愿景、使命以及价值观
愿景、使命和价值观被称为团队核心三要素,是团队竞争力的基础。理想的团队应该有共同的价值观,为了共同目标在一起努力奋斗。
从实践角度来讲,如何确定三要素是需要集体来决定的,比如可以通过心无旁骛的 workshop 来确定,不过在开始之前最好先明确上一层组织架构的三要素,确保不与其冲突。
在团队确定三要素的过程中,团队成员可以通过德尔菲法来逐步明确价值观,也就是征求所有团队成员的意见,进行整理、归纳、统计,再匿名反馈给各个团队成员,再次征求意见,再集中,再反馈,直到最终获得一致。价值观是团队的行为准则,以及如何处理分歧的基础,是团队文化的核心,也是团队成员的考核标准之一。
而确定愿景需要回答三个问题:我们的团队是什么样的?我们将会成为什么样的团队?我们最终会是什么样的?在具体操作上可以逐步引导团队思考这些问题,可以通过公开讨论并投票的方式来确定,直至最终确定清晰明了无歧义的描述。
明确使命就是要在愿景的基础上确定职责所在,也就是要先做什么,是对团队自身以及关联团队甚至社会的承诺。因此,在实践中,一定要确保先明确核心价值观和愿景再明确使命,并且保证三者不相悖,这是团队拥有持续稳定竞争力的基础。
明确团队当前的能力
明确团队能力一般需要周期性的评估,以自我评估为主,对于关键能力的评估可以通过引入外部团队来做客观评价。举个例子,我所在的技术团队主要做两个方面的评估:管理资源回顾 (MRR) 和技术资源回顾 (TRR)。
管理资源回顾主要是评估个人能力,一般需要自上而下来操作:被评估人在当前职位的水平如何?潜在的继任者是谁,能力如何?如何调整被评估人的职位(升迁或准备升迁,还是保持)?对不合格(“能力”不够)的人采取何种措施等。
技术资源回顾主要针对团队的技术能力进行评估,自下而上,先做个人评估,再做小组评估,进而进行部门评估等。在个人评估方面,一般是自评和团队负责人评估相结合,用一个简单的表格就可以搞定,比如 Excel、Power 等。也可以对技能掌握程度定级,我的经验是采用 CDE,C 指的是 Capable, 基础级,也就是可以做这个任务;D 指的是 Developed, 专业级,是经过专门培养的,;E 指的是 Expert,专家级;为了统计上的需要,还引入了 X 表示不具备技能。同时,为了方便对技能水平进行量化,我们可以给每个等级一个分数,如 C=1,D=3,E=5,X=0。
如上图所示,在进行小组技能评估时,先要确定技能列表,这个列表一般由小组长指定的团队核心人员制定,也可以通过讨论的方式来选出相关技术技能。对于一个技术团队来讲,技能可以是核心的编程语言,可以是技术的方向如数据库、网络、算法、操作系统等,可以是重要的技术平台,也可以是核心的行业知识……
另外,针对每个人的技能评估,需要进行一对一的双向沟通,这样做的目的是:
- 1. 明确技能等级的确定方式,毕竟在不同的组织内部,对技能级别的定义会有偏差,通过双向沟通能够逐渐明晰技能的能力定义;
- 2. 查漏补缺,发现那些疏漏了的核心技能,在实践中,经常会发现有的团队成员具备一些对团队有益的技能,但没有被评估出来;
- 3. 给管理者和团队成员提供双向沟通的机会,一方面使团队成员更了解团队未来的人才需求,另一方面,管理者可以更好地了解团队中每个人的能力。因此双向沟通不能马虎。有些小组长会自以为已经很了解团队了,凭个人感觉打分,就很容易走入误区。
在逐级的汇总过程中,需要对技能进行泛化,例如我们可以把 CoAP、MQTT、AMQP 等针对应用领域泛化成 IoT 协议,把 AngularJS, VueJS, ReactJS 等针对应用场合泛化成 web 前端技术,但要对泛化的技能加上明确描述。值得注意的是,不要泛化非常核心的技能,例如,如果团队的核心技能是 Go 语言,那么在泛化的过程中,可以将其他编程语言泛化成一个技能,而 Go 始终作为核心技能,直到团队大到不再关注如此细节为止。在自下而上的过程中,每个层级的团队都要进行分析和总结工作,这个工作需要结合业务需求,并对技能进行两个维度的独立分类。一般我会用四象限的技能坐标图来分类,如下图:
横坐标是技能获得难易度,设定技能难度从 1 到 10 递增,比如技能 A 的难度为 5,然后依次对其他技能难易度打分,从易到难依次排列在横坐标上;纵坐标是技术对业务的影响力,按照同样的步骤打分,并根据影响力的大小依次从将技能排列在纵坐标上,最后根据打分情况,对技能进行总的分类:
- 第一象限的技能称为皇冠上的明珠 (Crown Jewelries):这类技能对公司业务发展很重要,属于高精尖的技能,一般需要花费很大财力、物力、人力来培养或者招聘具备该技能的人才,具有此类技能的团队,在竞争者中就会处于相对领先的地位;
- 第二象限的技能属于畅销技能 (Marketable Skills):对业务发展很重要,但相比第一象限,具备该技能的技术人才比较充裕,有明确的培养途径,在人才市场上也比较容易招聘到;
- 第三象限属于基础技能 (Commodity Skills):技术人才很多或者掌握该象限技能相对容易,对业务也不是特别重要的技能。
- 第四象限的技能属于领先技能 (也叫利基技能,Niche Skills):该象限的技术人才或者技能非常难培养,由于业务的调整或者开拓进度,目前只是满足小部分业务需求;
按照这样的方式进行分类后,就会对团队所需的技术技能定位有一个清晰的了解。这时再对之前采用技术资源回顾表收集的技术能力数据进行统计整理(一般应该采用工具生成),由个人数据变成团队数据,针对每个技能都可以得知团队当前的技术实力,同时也能更好地明确团队当前的能力缺口在什么地方。以及未来需要什么样的技术人才等,例如当前 AI 的专家有两人,但因为团队需要,一年内需要扩张到 5 人,这样就能更好的打造团队的竞争力。
受限于篇幅,今天先分享明确团队的愿景、使命、价值观和明确团队当前能力这两个层面的内容,提升团队竞争力的后两个层面,即制定发展战略以及设定周期性目标和关键结果将在本文下篇继续分享,欢迎持续关注,如果你觉得这篇文章对你有帮助的话,也欢迎把它分享给更多的朋友~
作者简介
赵晓光,TGO 鲲鹏会会员,目前在 Resideo Technologies,Inc. 担任 Fellow 及 IPA 技术总监,负责技术创新、平台以及架构方向,同时负责技术战略以及路线图,团队竞争力培养以及人员培养等工作。此前在霍尼韦尔担任 Fellow 及技术总监工作。在软件开发领域有丰富经验,获得 Leading SAFe, Exin Devops Master, CSSLP 及 PMP 认证。
文章作者 anonymous
上次更新 2024-03-26