1. 从“skills”这个词说起为什么它突然成了高频搜索词最近后台收到不少私信问的都是同一类问题“skills到底该怎么整理”“简历里的技能栏怎么写才不虚”“团队里每个人的技能怎么盘清楚”。说实话这个词看着简单但真正动手做的时候绝大多数人都卡在同一个地方——不知道从哪下手也不知道做成什么样才算合格。我自己第一次系统性地梳理技能是在带一个跨职能小组的时候。当时组里六个人背景横跨设计、前端、数据和运营结果一开会就乱有人觉得某件事该前端做前端觉得那是设计的活设计又觉得这属于运营范畴。吵了两次之后我意识到问题不在人在于我们从来没有把“谁会什么、会到什么程度、缺什么”这件事写下来过。后来花了一个周末做了一版技能清单第三次开会效率直接翻倍。所以这篇内容想聊的就是技能梳理这件事本身——它是什么、能解决什么问题、适合谁来参考。不管你是要写简历、搭团队、做个人成长规划还是单纯想搞清楚自己到底会些什么这套思路都能直接用。我不会给你一个空泛的模板而是把每一步为什么这么做、参数怎么定、坑在哪里全部拆开讲清楚。核心关键词就一个skills。但围绕它展开的东西很多——技能分级、技能矩阵、能力盘点、成长路径、团队技能地图。这些词你可能在不同的场合见过本质上都是同一件事的不同切面。2. 技能梳理的整体设计思路先想清楚“给谁看”2.1 三种典型场景决定了完全不同的做法很多人一上来就问“有没有模板”这个问题本身就问错了。技能梳理的做法取决于受众是谁受众不同颗粒度、维度、呈现方式全都不一样。我把它分成三类场景受众核心目的颗粒度呈现形式个人简历招聘方快速匹配岗位粗只留强相关列表等级团队盘点管理者/协作者分工与补位细覆盖全流程矩阵表个人成长自己找差距定计划中可追踪清单时间轴你看同样是“skills”简历上你可能只写八条团队矩阵里可能要列八十条。这不是谁对谁错是目的不同。我见过一个典型的错误有人把团队盘点的详细矩阵直接压缩成简历结果简历上密密麻麻列了四十多项技能招聘方看一眼就关了。反过来有人拿简历那种粗颗粒度去做团队分工结果发现“会设计”这三个字根本没法指导谁来做具体的交互稿。提示动手之前先花五分钟回答一个问题——“这份东西做出来第一个看它的人是谁他看完要做什么决定”答案会告诉你一切。2.2 为什么我推荐“能力域等级”的双层结构技能梳理最怕的就是变成一张没有结构的大清单。我的做法是先分能力域再在每个域里定等级。能力域就是技能的归类。比如做互联网产品的通常可以分成技术实现、产品设计、数据分析、沟通协作、项目管理这几大块。每块下面再列具体技能。这样做的好处是你一眼就能看出一个人或一个团队在哪块强、哪块弱而不是陷在几十个零散条目里。等级这块我用的是五级制但和常见的“了解/熟悉/精通”不太一样。那套说法太模糊了“熟悉”到底是什么水平十个人有十种理解。我改成行为描述式的分级L1 知道能说出这个概念是干什么的但没动手做过。L2 能跟着做有现成方案或人带的情况下能完成。L3 能独立做不给方案也能自己搞定遇到常规问题能自己排查。L4 能教别人能把自己的做法讲清楚别人照着能学会。L5 能定标准能判断什么做法是好的能设计流程和规范。这套分级的关键在于可验证。你说自己L3那就意味着给你一个中等难度的任务不给参考方案你能独立交付。这个标准一摆出来虚报的空间就小了很多。2.3 方案选型的取舍为什么不用现成的技能测评工具市面上有不少在线技能测评工具做完给你一个雷达图。我试过几个结论是可以作为参考但不能作为梳理的主体。原因有三。第一测评工具的维度是它定的不一定贴合你的实际场景。第二测评结果往往是“你在人群中排前百分之多少”这个信息对个人成长有用但对团队分工没什么指导意义——我需要知道的是“你能不能做这件事”而不是“你比多少人强”。第三测评是一次性的而技能梳理是持续更新的工具很难跟着你的实际项目走。所以我更推荐自建清单定期校准的方式。工具可以用但只作为辅助输入核心还是自己动手把技能条目和等级定义写清楚。3. 核心细节拆解技能条目的写法和分级标准3.1 技能条目怎么写才不空泛这是最容易翻车的地方。我见过太多清单上写着“沟通能力”“学习能力”“团队协作”这种词看完等于没看。问题出在这些词描述的是特质不是技能。技能应该是可观察、可练习、可交付的。我教你一个改写方法把每个条目套进这个句式——“能在什么场景下独立完成什么产出”。举几个对比例子空泛写法改写后的写法沟通能力能主持需求评审会并输出会议纪要数据分析能用SQL独立完成漏斗分析并给出结论设计能力能根据业务目标独立完成页面交互稿项目管理能拆解季度目标并跟踪到周级别你看改写之后每一条都能对应到一个具体动作和产出。这样写的好处是评估的时候有据可依——做过就是做过没做过就是没做过不用猜。注意改写的时候不要贪多。一个能力域下面核心技能条目控制在五到八条就够了。列太多会导致两个问题一是维护成本高二是重点不突出。我一般会问自己“如果只能保留三条哪三条最关键”剩下的要么合并要么降级为子项。3.2 等级判定的实操方法用“最近一次”来校准分级最怕的是凭感觉。我自己的做法是判定任何一条技能的等级时都问一个具体问题“最近一次独立做这件事是什么时候做的什么结果怎么样”如果答不上来说明这条技能的等级要往下调。如果最近一次做的时候还需要别人给方案那就是L2。如果做完之后还能给别人讲明白那就是L4。这个方法我用了两年多最大的好处是防止自我感觉良好。人很容易把“见过别人做”当成“自己会做”把“做过一次”当成“熟练”。用“最近一次”来卡水分一下就挤出来了。还有一个技巧是交叉验证。团队盘点的时候我会让每个人先自评然后让经常合作的同事复评一次。两次结果差异超过一级的条目就拿出来单独聊。聊的过程往往能发现很多有意思的东西——有人低估了自己有人高估了也有人对某条技能的理解和别人完全不一样。3.3 技能矩阵的排布行和列怎么定团队技能矩阵是梳理成果的集中体现。它的结构很简单行是人列是技能格子里是等级。但排布的时候有几个细节要注意。第一技能列要按能力域分组组内按重要性排序。不要把所有技能混在一起排那样看的时候眼睛会花。第二如果团队人数超过十人建议拆成多张表按能力域分。一张表超过十列就会很挤打印出来也看不清。第三格子里除了等级还可以加一个标记表示“是否当前项目需要”。我通常用加粗表示核心需要普通表示次要需要灰色表示暂时不需要。这样一眼就能看出当前的能力缺口在哪里。下面是一个简化示例方便你理解结构成员需求分析交互设计前端实现数据埋点项目跟进A同学L3L2L1L2L3B同学L2L4L2L1L2C同学L1L2L4L3L2看这张表你马上能发现需求分析这块只有A同学能独立做是个单点风险数据埋点整体偏弱需要补。这就是矩阵的价值——把隐性的能力分布变成显性的决策依据。4. 完整实操流程从零做出一份可用的技能清单4.1 第一步确定范围和目的动手之前先写一句话“这份清单是给谁看的用来做什么决定。”写不出来就先别动手。如果是个人简历范围就是目标岗位的JD里提到的技能加上你实际做过且能拿出手的。如果是团队盘点范围就是当前项目全流程涉及的技能一个都不能漏。我一般会拿一张白纸先把所有能想到的技能条目全部倒出来不做任何筛选和归类。这个阶段追求的是全不是准。倒完之后再合并同类项、删掉重复的、补上遗漏的。4.2 第二步定义等级标准并写下来这一步很多人会跳过觉得“我心里有数就行”。但实际做的时候如果不把等级标准写下来不同人的理解一定会跑偏。我的做法是针对每个能力域写一段简短的等级描述。比如“前端实现”这个域L1能看懂代码能改简单的样式。L2能在框架内完成常规页面开发。L3能独立完成中等复杂度模块能排查常见问题。L4能设计组件结构能指导他人开发。L5能制定前端规范和工程化方案。这段描述不用很长但要具体到能做什么。写完之后团队里所有人对着同一套标准评结果才有可比性。4.3 第三步自评与校准自评的时候我建议逐条过不要跳。每条都问那个“最近一次”的问题。评完之后找两到三个经常合作的人做交叉校准。校准的时候有个原则对事不对人。不要说“我觉得你达不到L3”而是说“上次那个任务你当时是怎么做的卡在哪了”。用具体的事来对齐理解比争论等级本身有效得多。校准完之后把最终结果填进矩阵表。这时候你会发现有些条目大家的理解差异很大有些条目则高度一致。差异大的条目要么是定义不够清晰要么是实际水平确实参差不齐两种情况都值得关注。4.4 第四步识别缺口并制定计划矩阵表填完之后缺口自然就浮现出来了。我通常从三个角度看单点风险某条关键技能只有一个人达到L3以上这个人一旦忙不过来或离开事情就卡住了。整体短板某个能力域所有人都在L2以下说明这块需要系统性补强。成长停滞某人某条技能连续两个季度没有变化可能需要新的挑战或培训。针对每个缺口制定具体的行动计划。注意计划要落到具体动作上不要写“提升数据分析能力”这种空话。写成“下季度独立完成两次漏斗分析并输出结论”这样才有可执行性。4.5 第五步定期更新技能清单不是做一次就完了。我的习惯是每季度更新一次每次花半小时左右。更新的内容包括新增的技能条目、等级变化、缺口变化、计划完成情况。更新的时候有个小技巧只改变化的部分不要每次重做。重做成本太高坚持不下去。只改变化的部分五分钟就能搞定反而容易形成习惯。5. 常见问题与排查技巧实录5.1 技能条目太多或太少怎么办太多的情况通常是归类没做好。我的经验是一个能力域下面超过十条就说明该拆域了。比如“技术实现”下面如果列了十五条可以拆成“前端实现”“后端实现”“数据存储”三个域。太少的情况通常是写得太粗。比如整个清单只有“技术”“设计”“运营”三条那基本没有指导意义。这时候要往下拆一层把每个域里的关键动作列出来。一个参考标准个人清单控制在二十到三十条团队矩阵控制在四十到六十条。这个量级既能覆盖主要方面又不至于维护不动。5.2 等级评不准怎么办评不准通常有两个原因。一是标准太模糊二是缺少具体事例。标准模糊的问题回到4.2节重新写等级描述确保每条都能对应到具体行为。缺少事例的问题用“最近一次”来卡答不上来就降级。还有一个情况是跨领域评不准。比如让做设计的人去评前端实现的等级他可能完全没概念。这时候要么找该领域的专家来评要么用产出物来间接判断——看代码仓库、看设计稿、看分析报告用实际产出说话。5.3 团队里有人不愿意配合怎么办这个问题我遇到过。原因通常有三种一是觉得这事没用二是怕暴露短板三是觉得浪费时间。对第一种我的做法是先做一个小范围试点拿一个具体的分工场景来演示。比如下次排任务的时候直接拿矩阵表来分分完之后大家发现确实更顺了抵触自然就少了。对第二种要强调这是用来补位的不是用来考核的。如果团队氛围确实比较紧张可以先做匿名版只统计整体分布不显示个人明细。对第三种控制时间。第一次做控制在两小时以内之后每季度更新控制在半小时以内。时间成本低大家才愿意持续做。5.4 常见问题速查表问题现象可能原因排查动作解决方向清单条目超过五十条归类过细或范围过大检查能力域划分合并同类项拆大域等级普遍偏高标准模糊或自评宽松用“最近一次”复核重写等级描述交叉校准更新坚持不下去流程太重检查更新耗时只改变化部分控制半小时内矩阵表没人看和实际决策脱节检查是否用于分工下次排任务直接用矩阵跨领域评不准缺少该领域专家检查评估人背景找专家评或用产出物判断5.5 几个我踩过的坑第一个坑是一开始就追求完美。我第一次做的时候花了整整一周把每个条目都写得特别细结果做完之后没人看因为太复杂了。后来简化到一页纸反而用起来了。所以我的建议是先做一版能用的再慢慢迭代。第二个坑是只做个人不做团队。个人清单做得很漂亮但团队协作的时候还是各干各的。后来加上团队矩阵才发现很多问题其实是信息不对称造成的——你不知道我会什么我不知道你会什么结果就是重复劳动和互相等待。第三个坑是评完就不管了。技能清单最大的价值在于持续跟踪。评一次放在那里三个月后就跟实际脱节了。我现在是设了日历提醒每季度最后一周固定花半小时更新形成习惯之后就不觉得是负担了。6. 技能梳理的延伸用法从清单到成长路径6.1 用技能清单做个人成长规划技能清单不只是盘点现状还能用来规划未来。我的做法是在现有等级旁边加一列目标等级再写一个达成时间。这样就变成了一张成长路线图。比如技能当前目标时间关键动作需求分析L2L3三个月独立完成两次需求拆解数据埋点L1L2两个月跟着做一次完整埋点项目跟进L3L4六个月带一次完整项目并复盘这张表的好处是目标具体、动作明确、时间可控。比“我要提升自己”这种空话强太多了。6.2 用技能矩阵做团队补位方案团队矩阵的延伸用法是补位方案。当某个关键技能只有一个人达到L3以上时就要考虑备份。具体做法是让L3的人带一个L2的人通过实际任务来提升。这样既补了单点风险又给了L2的人成长机会。我通常会在矩阵表下面加一行备份人标明每条关键技能的备选人。这样排任务的时候如果主责人忙不过来马上知道找谁。6.3 技能梳理和招聘的联动如果你在带团队技能矩阵还能直接指导招聘。矩阵上整体偏弱的域就是招聘时要重点考察的方向。面试的时候针对这些域设计具体的问题和实操环节比泛泛地聊“你擅长什么”有效得多。我自己的做法是把矩阵上L2以下的条目整理成一个面试考察清单每轮面试重点考察两到三条。这样招进来的人能直接补上团队的短板而不是招进来之后才发现技能重叠了。6.4 一个容易被忽略的点软技能的量化很多人觉得沟通、协作这类软技能没法量化。其实可以。我的做法是把软技能也拆成可观察的行为。比如“沟通协作”可以拆成能主持跨职能会议并输出结论能在分歧时提出折中方案能主动同步进度和风险能在复盘时给出建设性反馈每条都可以用五级制来评。评的时候同样问“最近一次”的问题。这样软技能就不再是模糊的印象分而是有据可依的具体能力。7. 我个人的几个实操心得做技能梳理这件事前后折腾了两年多有几个心得是踩了坑才明白的。第一不要追求大而全。我一开始总想把所有技能都列进去结果清单越来越长最后没人看。后来想明白了技能清单是决策工具不是百科全书。只列和当前目标相关的其他的等需要的时候再加。第二等级标准要写下来。不写下来十个人有十种理解。写下来之后大家对着同一套标准评结果才有可比性。而且写标准的过程本身就是一次很好的对齐。第三定期更新比一次做完美更重要。我见过太多人花大力气做了一版完美的清单然后放在那里落灰。反而是那些做得粗糙但每季度更新的人真正从中受益了。持续比完美重要。第四用起来才算数。技能清单最大的价值在于用——用来分工、用来排任务、用来定成长计划、用来指导招聘。如果做完就放在那里那还不如不做。我现在的习惯是每次排任务之前先看一眼矩阵看看谁适合做什么、谁需要锻炼什么。这样清单就活了。最后再分享一个小技巧如果你觉得从零开始做太难可以先从一个能力域入手。比如先把“数据分析”这一块的技能列出来评一遍用起来。跑通一个域之后再扩展到其他域。这样起步门槛低容易坚持也容易看到效果。