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. 我个人的几个实操心得做技能梳理这件事，前后折腾了两年多，有几个心得是踩了坑才明白的。第一，不要追求大而全。我一开始总想把所有技能都列进去，结果清单越来越长，最后没人看。后来想明白了，技能清单是决策工具，不是百科全书。只列和当前目标相关的，其他的等需要的时候再加。第二，等级标准要写下来。不写下来，十个人有十种理解。写下来之后，大家对着同一套标准评，结果才有可比性。而且写标准的过程本身，就是一次很好的对齐。第三，定期更新比一次做完美更重要。我见过太多人花大力气做了一版完美的清单，然后放在那里落灰。反而是那些做得粗糙但每季度更新的人，真正从中受益了。持续比完美重要。第四，用起来才算数。技能清单最大的价值在于用——用来分工、用来排任务、用来定成长计划、用来指导招聘。如果做完就放在那里，那还不如不做。我现在的习惯是，每次排任务之前先看一眼矩阵，看看谁适合做什么、谁需要锻炼什么。这样清单就活了。最后再分享一个小技巧：如果你觉得从零开始做太难，可以先从一个能力域入手。比如先把“数据分析”这一块的技能列出来，评一遍，用起来。跑通一个域之后，再扩展到其他域。这样起步门槛低，容易坚持，也容易看到效果。
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. 我个人的几个实操心得做技能梳理这件事，前后折腾了两年多，有几个心得是踩了坑才明白的。第一，不要追求大而全。我一开始总想把所有技能都列进去，结果清单越来越长，最后没人看。后来想明白了，技能清单是决策工具，不是百科全书。只列和当前目标相关的，其他的等需要的时候再加。第二，等级标准要写下来。不写下来，十个人有十种理解。写下来之后，大家对着同一套标准评，结果才有可比性。而且写标准的过程本身，就是一次很好的对齐。第三，定期更新比一次做完美更重要。我见过太多人花大力气做了一版完美的清单，然后放在那里落灰。反而是那些做得粗糙但每季度更新的人，真正从中受益了。持续比完美重要。第四，用起来才算数。技能清单最大的价值在于用——用来分工、用来排任务、用来定成长计划、用来指导招聘。如果做完就放在那里，那还不如不做。我现在的习惯是，每次排任务之前先看一眼矩阵，看看谁适合做什么、谁需要锻炼什么。这样清单就活了。最后再分享一个小技巧：如果你觉得从零开始做太难，可以先从一个能力域入手。比如先把“数据分析”这一块的技能列出来，评一遍，用起来。跑通一个域之后，再扩展到其他域。这样起步门槛低，容易坚持，也容易看到效果。