技能地图：量化你的团队和组织能力

摘要：团队的能力是组织的根基，在现代技术和商业日新月异的时代，只有不断学习、各方面能力持续提升的组织才能在竞争对手面前具有顽强的生命力。

绝大多数的企业没有建立组织和团队能力度量以及提升机制，发现能力不够就加快招聘的速度，而没有从培养团队的学习和成长着手，员工能力的提升是个随意的行为，即：将员工分配到项目中，让大家在项目中自己锻炼。其实，团队的能力是组织的根基，在现代技术和商业日新月异的时代，只有不断学习、各方面能力持续提升的组织才能在竞争对手面前具有顽强的生命力。

发展组织能力

案例：

笔者多年前曾经在一家芬兰企业工作，该公司有一个非常好的组织能力发展实践：每半年做一次组织级的能力评估。他们在华设立软件研发中心，采用的能力框架有五个维度：软件管理、软件开发、软件集成、产品集成&测试和软件维护。每一个维度具体细分出很多评估项，比如软件管理具体的子评估项如图：

能力评估子项

图来源：《敏捷转型：打造VUCA时代的高效能组织》

从组织的最高领导者到每一个工程师用这个评估系统自评打分。分值定义如下：

0：None –不具备该项能力
1：Basic –具备基本能力
2：Competent –完全具备能力
3：Professional –专家级，可以指导其他人

每个员工自评后，数据保存到公司的数据库里，做以下用途：

分配员工进项目

当有新项目立项的时候，管理层从数据库里调取具备相应能力的员工进入新项目，从而保证人员的能力和项目需求匹配，避免人员不能胜任或过于胜任的情况。

年度发展计划

该企业每半年有一次员工能力发展计划。部门经理针对每个员工的能力自评，与员工一对一谈话，询问员工的兴趣和职业发展目标，帮助员工规划成长路线，通过寻找匹配能力发展的项目机会以及制定培训计划等方式帮助员工达成个人成长目标。

组织级能力发展计划

经理层将整个部门的能力数据做汇总统计，从而形成组织级能力评估，通过这个评估可以宏观地判断出整个组织的能力短板，从而找准组织级能力提升的方向。此外，HR部门会将整个企业的能力数据做汇总统计，从而规划企业级的能力发展计划。

常见误区：笔者发现，类似这样的技能地图，在国内的一些公司也存在，但是遗憾的是，组织只是单纯收集了员工的技能数据，但是没有充分利用，只是纯粹做为分配人员进入项目的工具，没有和员工开展能力发展的讨论，也没有进一步利用这个技能地图开展组织级能力发展的规划。

发展团队能力

不止在组织级可以通过管理体系和流程来驱动组织的学习和成长，还可以尝试以敏捷团队为单位发展团队的能力。最好的敏捷团队是T型团队，即：每个人都有自己的专长，但也是个通才，在别人需要帮助的时候，他虽然也可以提供帮助。

图：T型团队

案例：
陈硕是某通信企业一个Scrum团队的Scrum Master。在敏捷转型之初，团队强烈地感受到了技能壁垒的痛苦。由于每个工程师只能做自己熟悉的一个模块，其他模块都不熟悉，因此，在Sprint计划中，每个工程师都只能领取自己熟悉的模块工作。结果，在每个Sprint执行中，团队无法以价值优先的原则为Backlog排序，因为高价值的工作只有1个人有能力做，而他的工作量已经饱和。此外，每个同事孤立工作，互相没有讨论和协作，因为大家对彼此的模块不熟悉，互相帮不上忙。于是，经常出现当有同事遇到困难时，无法在Sprint结束的时候交付，而其他人只能望洋兴叹。更糟糕的是，每个Sprint会有不止一名同事遇到这样的困难，因此，陈硕的团队连续5个Sprint失败。在连续失败下，团队终于决定不能继续这样下去了，需要打破技能壁垒。但是光说打破容易，该怎么操作呢？

在这种情况下可以用技能地图作为工具，如图所示。

团队技能地图示例

来源：《敏捷转型：打造VUCA时代的高效能组织》

像上图的技能地图是如何构建的呢？有以下四个步骤：

第一步：团队将产品需要的技能逐一列出。

第二步：自评。

每个人对自己在每一项技能水平打分：
0-9分，从完全不懂到极其精通。
每个档是相对比较，不需要有明确的定义。

第三步：集体评估。

每个人自己评估打分后，Scrum Master召集团队全员一起复评，团队就每个人的自评讨论校正。
之所以需要校正这一步，是因为每个人的能力是相对的，不是绝对的评估。
比如：
一个很谦虚的同事往往会给自己的打分偏低，而一个自信的同事给自己的打分会偏高。

第四步:能力基线化。

大家将评估结果作为团队的能力基线，团队基于现实能力水平和产品的业务需要制定能力提升计划：
每个人的哪一项能力，需要花多长时间提升到一个层级，尤其关注的是那些从0到1的提升。

计划定好后，团队结对工作。

例如：
一个用户故事需要PON协议开发技能，而同事Jenny这块能力为0，她正计划学习这块知识，Tony这块能力很强，评估分为7，于是这两个人结对开发这个用户故事。
这样结对开发在短期内团队的用户故事效率会有所下降，但是在长期范围内是非常受益的。拿案例中张硕的这个团队来说，过了三个月后，团队的技能壁垒打破了很多，交付速率迅速上升，Sprint的成功率极大提高。

当然，团队制定能力计划不能只从自己的兴趣着手，还要有业务需要作为输入。产品负责人给团队提供Backlog里优先级最高的那些需求以及产品的路线图作为技能地图的重要输入，团队依据接下来的几个月内要做的业务内容，分析需要什么能力，再结合每个人的兴趣来制定能力提升计划。

初次制作技能地图后，团队需要定期更新。比如，每隔2—3个月一次，团队更新自己技能评估，并制定下一步的提升计划。