把招聘要求拆成能力项,核心动作是:先把岗位描述中的每条要求改写成可观察的行为或产出,再按“知识、工具、策略、协作”四类归位,最后为每项写出一条验证方式。这样做的直接结果是,多人协作时谁负责哪项能力、交付到什么程度、如何验收都清楚,减少因理解不一致造成的返工。
招聘要求通常混着三类写法,拆解方式不同。第一类是结果型,例如“能提升网站自然搜索流量”,它描述的是目标,不是能力。第二类是动作型,例如“能完成关键词调研并输出内容规划”,它接近能力项,但仍需补充产出标准。第三类是资历型,例如“有两年以上相关经验”,它只能作为筛选条件,不能直接当能力项用。
判断方法很简单:把这条要求读给一个没做过该岗位的人听,如果对方问“那具体要做什么、做成什么样”,说明它还需要拆。拆解时不要照抄原句,而是问“做到这件事,需要会什么、用什么、和谁配合”。
以“网站排名提升培训”相关岗位为例,招聘方可能写“能通过培训帮助团队掌握排名优化方法”。这句话至少可以拆成以下能力项:
这四类不是固定模板,但能覆盖大多数招聘要求。拆完后要检查一项:每项是否对应一个可交付物。知识项对应讲解或文档,工具项对应操作记录,策略项对应方案,协作项对应任务清单。没有交付物的能力项,在多人协作中很容易变成空话。
拆解完成后,不要直接拿去分配任务,先走一遍四步验证。
假设某团队把“能做排名提升培训”拆成“能讲关键词布局”。验证时发现,执行者能讲概念,但给不出页面示例和判断标准。这说明该项还停留在知识层,需要补充工具操作和产出示例,否则培训结束后学员仍不知道怎么做。
返工通常来自三种情况:能力项边界重叠、验收标准不一致、资料交接缺失。处理办法是在拆解表里增加两列——“不包含什么”和“需要谁提供什么”。例如“关键词调研”可以不包含内容撰写,但需要内容负责人提供页面主题清单。把不包含项写清楚,比反复口头确认更省事。
另外,招聘要求中的“熟悉”“了解”“掌握”要换成可判断的表述。可以这样改写:
这些改写不涉及具体机构或证书,只描述行为和产出,适用于多数需要交付清楚的协作场景。如果招聘方给出的是论坛或未知来源的岗位信息,先核对发布方、岗位职责和任职要求是否自洽,再决定是否按上述方法拆解。
拿一份真实的招聘要求,把每条要求逐句拆进“知识、工具、策略、协作”四类,并为每项补一条验证方式。拆完后让另一位协作者只看拆解表,判断能否直接分配任务和验收。如果对方仍需追问,继续补充产出标准和边界,直到无需口头解释也能执行。