职级薪酬体系：岗位序列、带宽测算与落地避坑

摘要：简介：针对岗位序列、职等职级与薪酬管理，这份Word文档提供了完整制度文本，适合人力资源从业者、部门管理者及需要了解职级体系的员工参考。内容系统梳理了管理序列（M）与专业序列（P）两大类岗位，职等以BAND1至BAND1……

简介：针对岗位序列、职等职级与薪酬管理，这份Word文档提供了完整制度文本，适合人力资源从业者、部门管理者及需要了解职级体系的员工参考。内容系统梳理了管理序列（M）与专业序列（P）两大类岗位，职等以BAND1至BAND12划分，配有职等职级图与各级别薪酬带宽表，薪酬范围覆盖实习生2K到总经理40K以上；职级部分说明除BAND1、BAND11、BAND12外，每个职等下设C、B、A三个职级，同时涵盖新员工定级、逐级晋升规则、271评选方法、晋升准入资格中的司龄与业绩排名要求，以及降级情形，可直接用于企业制定或优化职级薪酬方案。资源为单个docx文档，压缩包约35KB，便于下载后按需编辑。目前已有147人学习下载，适合需要快速对照设计职级薪酬制度或研究公司分层体系的人群。 一次内部复盘会上，业务负责人当着一屋子人的面问我：“你们搞的这套职级标准，我底下干了八年的技术骨干，凭什么只能定个中级，而隔壁组干了三年的产品经理却能定高级？以后涨薪是不是也要看你们这套东西的脸色？”当时我手里正拿着刚起草完的《岗位序列、职等职级和薪酬管理规定（征求意见稿）》，忽然意识到一个事实：制度文件写出来容易，真正让它在几百号人里落地、让各部门都觉得“公平”，才是最难的。

这也是我今天想认真聊聊的事。无论你所在的公司是刚过百人开始建体系，还是已经有了一定规模想重新梳理职级薪酬，这份管理规定背后的设计逻辑、参数测算和落地过程，都值得被拆开看一遍。我要讲的，不是那种“用即用”的模板文本，而是在搭建这套东西时真正需要想清楚的几个关键问题，以及我踩过的坑。

1. 岗位序列划分：为什么“分错序列”比“定错薪级”更致命

职级薪酬体系的第一颗扣子，不是定薪级，而是分序列。很多人上手就急着画薪酬带宽表，结果序列都没捋清楚，后面全乱。岗位序列的本质，是把公司里工作性质相近、能力要求可比较的岗位归并成类，让“涨薪”和“晋升”有可比的对象。你不可能拿一个销售总监和一个架构师去比谁更资深，他们不在一个评价坐标系里。

1.1 序列划分的三级逻辑：族群—序列—子序列

我一般建议用“族群—序列—子序列”三层结构来划分。

族群是最粗的维度，比如管理族群、专业族群、技术族群、市场族群、职能族群。这个维度不要分太细，五到八个族群就够。很多初创公司在这里容易犯一个毛病：把“研发”和“测试”拆成两个族群，看起来分得很清楚，实际上测试和研发后端的能力模型高度互通，硬拆出去只会让后期定级标准螺旋失控。

序列是第二层，也是最关键的一层。比如技术族群下面可以分“后端开发序列”“前端开发序列”“算法序列”“测试序列”“运维序列”。序列内部的人，工作性质高度相似，能力成长路径可以拉成一条线，他们的职级才有可比性。

子序列是第三层，通常是在序列内部再细分专业方向。比如后端开发序列下，可以视规模再分“业务后端”和“基础设施后端”。公司规模不到三百人，我不建议急着拆子序列——层级越多，评审成本越高，体系越僵硬。

1.2 管理序列和专业序列的边界怎么划

这里有一个实际执行中几乎必踩的坑：管理序列和专业序列的边界。

很多公司设计制度时会把“带不带人、有没有下属”作为唯一标准。但实际操作中会出现大量灰色地带：带三个人的小组长算不算管理？不带人但是牵头跨部门项目的资深专家算什么？带十几个人的部门负责人如果专业能力也非常强，该怎么走？

我的处理经验是：以“时间精力分配+组织授权”双维度来界定。

• 如果一个人50%以上的精力在做团队管理，且拥有人事建议权、绩效分配权、审批权中的至少两项，他应该走管理序列。
• 如果一个人不带下属，但是通过专业判断直接决定技术选型、方案架构或业务策略，他应该走专业序列。
• 如果两者都占，那就明确“主序列”归属，同时允许跨序列的薪酬取齐。简单说就是：管理M序列的人，薪资可以拿到P序列高两级的水平；P序列的人也可以拿到M序列同级以上的薪资，但都不改变他所在序列的晋升评审逻辑。

这里分享一个我后来一直在用的判断标准：看这个角色在关键决策中行使的是“组织权力”还是“专业权威”。组织权力体现在人员任免、预算分配和绩效档评定上；专业权威体现在方案拍板、技术路线选型和业务策略制定上。前者走管理序列，后者走专业序列，两条腿都占的，以公司现阶段最需要他贡献的维度来定。

2. 职等职级设计：带宽、中位值、级差背后的计算逻辑

序列分完之后，真正的重头戏才开始：给每个序列设计一套职等职级标准，并把薪酬带宽架上去。

很多HR新手一上来就问：“我们该设几个职等？序列间要不要对齐？”我的建议永远先反问：“你们公司现在最资深的人，距离一个能独立定方向、扛结果的人还差几步？”职等是给成长留的台阶，不是给老板的面子工程。台阶设少了，人才升不上去，只能跳槽；台阶设多了，晋升评审会沦为走过场，含金量迅速贬值。

2.1 先定职等总数，再定级差系数

一套比较稳妥的做法是“总职等×序列系数”模式。

比如我们把全公司职等统一设为P1到P9（部分公司还有P10、P11），其中P1-P3是执行层，P4-P5是骨干层，P6-P7是专家/管理层，P8以上是资深专家/高管层。管理序列可以用M1-M7单独编号，但每个M职级会映射到对应的P职级上，方便做薪酬带宽的横向对齐。

接下来是级差系数。级差指的是相邻两个职等的薪酬中位值差距，通常以百分比表示。

我经手过的几套体系里，级差设置在20%-35%之间比较常见。具体取多少，取决于三个变量：

• 公司的晋升节奏。如果公司希望员工两年左右升一级，级差可以取25%-30%；如果晋升偏慢，级差就要更大，否则员工会觉得“升不升都差不多”。
• 外部对标数据的区间分布。如果对标市场P50分位的数据显示相邻职级差距在30%左右，那你的级差尽量贴近市场，否则招人时会出现“外部候选人比内部同级别员工贵一截”的倒挂。
• 公司的薪酬预算杠杆。级差越大，晋升一次的成本越高。你要算一笔账：假设100个员工里有30%的人年均晋升一级，级差是30%，那么光因为晋升带来的薪酬增量就占整体薪酬成本的9%，这还没算普调和绩效调薪。这块不提前预估，年底就会被动。

2.2 中位值和带宽怎么设，才不至于“晋升一次调不到位”

每个职等的薪酬带宽，我习惯用三个关键值来表达：最小值、中位值、最大值。中位值是锚点，带宽是区间。

带宽的确定逻辑要分两类看：

• 底层职等（P1-P3），带宽可以收窄到40%-50%。因为这个层级技能差异小，能力提升快，太宽的带宽会造成大量内部不公平——同岗同职等，新人老人薪资差距过大，新人根本留不住。
• 高层职等（P6以上），带宽放宽到60%-80%。高层级的绩效波动大、稀缺性高，同一个职等的人能力和贡献可能差异悬殊，带宽不拉宽，业务部门根本没法用高薪留住核心人才。

这里有一个非常关键的实操技巧：中位值不是拍脑袋定的。建议从两个方向交叉验证——外部看市场薪酬数据中对应职级的P50分位，内部看现有存量员工薪资落在哪个区间。两者差距大的话，就取一个折中值，不要一次性抹平差距，否则会带来薪资倒挂风险，老员工也会造反。

2.3 重叠度设计：为什么相邻职等必须有一部分区间重叠

这是很多制度设了一道“暗门”的地方。

相邻职等的带宽之间要有一定的重叠度，一般是10%-30%左右。比如P5的带宽是25k-50k，P6的带宽是35k-70k，两档之间在35k-50k这段就发生了重叠。这意味着什么？意味着一个绩效优秀的P5员工，他的薪资可以比一个刚晋升或绩效一般的P6员工更高。

有人看到重叠会问：那这不就乱了吗？职级高反而薪资低？

这里必须讲清楚：职级是对能力和责任的认定，而薪酬是对当期贡献和稀缺性的定价。一个资深的P5带过多个重要项目、绩效持续优秀，他的身价就是可能超过一个刚上来还没证明自己的P6。如果你不允许重叠，那么每次晋升都要“保证涨薪”，这会让晋升变成单纯的加薪工具，失去筛选的意义。

从我实操的经验看，重叠度设计还能解决一个非常现实的问题——晋升预算不足。

当公司年度晋升预算只覆盖2%的薪酬总成本时，不可能让每个晋升的人都跳到下一级中位值。有了带宽重叠，你可以在晋升时只给员工调一个较小的档差，比如10%，让他的薪资落在新职等带宽的下半区，依然保持了“晋升有加薪”的感知，同时把成本控制在预算内。这套逻辑在制度文本里要写明白：“晋升后薪资原则上不低于原薪资的105%，但进入新职等带宽的具体位置，由绩效表现和市场对标决定。”这句话给执行留了口子，又不失公平感。

3. 薪酬套档测算：制度写得再漂亮，落地时都要过数据这一关

职级体系画好了，带宽表也填上了，接下来就是最见真章的环节——套档测算。这一步的本质，是把公司现有所有人的薪资放进新的职级体系里“对号入座”，看会产生多少差额、多少倒挂、多少需要额外花钱才能摆平的问题。

3.1 套档前先做存量人员模拟，别直接全员公布

我见过最糟糕的操作是：制度刚评审通过，HR就把新的职等薪资表全员公布，让每个人自己对号入座，然后引发大面积不满。正确的姿势是先做模拟。

具体操作分三步：

• 按新的序列划分标准，把组织架构里所有岗位重新归类到对应的序列和职等。这里不要只按岗位名称，要看实际工作内容。同一个“运营专员”在不同部门，可能有的偏用户运营、有的偏内容运营，归到同一个序列没问题，但职等可能不同。
• 把每个员工的现薪数据匹配到新职等带宽里，计算“带宽内位置”。我习惯算两个指标：Compa-Ratio（CR，即实际薪资与中位值的比值）和“低于带宽最小值的人数”。
• 生成三类清单：高于带宽最大值的红名单、低于带宽最小值的蓝名单、落在带宽内但位置畸高或畸低的黄名单。红名单是冻结薪酬晋升直到带宽跟上；蓝名单需要加薪或特殊补贴；黄名单需要逐人分析。

这里记住一条铁律：套档测算阶段的数据永远不要直接发到业务部门负责人手里，先由HR数据分析团队和核心管理层过一遍，反复调整序列映射和职等判定规则，直到红蓝名单的比例分布合理（我一般控制在总人数的10%以内），再进入下一步沟通。

3.2 外部对标分位数怎么选，内部公平如何平衡

套档模拟结束后，你一定会收到业务部门的大量质疑：“为什么我们部门的高级工程师比市场部的高级专员带宽还低？”这就是序列间薪酬对标没做好的典型症状。

每个序列的薪酬带宽不是完全相同的，因为外部人才市场的供需价格不同。我的做法是每个序列单独选取外部对标分位数，再套进公司统一的职等框架里：

• 核心技术人员（如算法、架构、研发），对标P65-P75分位；这类岗位人才稀缺，不给到高分位根本招不到、留不住。
• 通用职能岗位（如行政、财务、HR），对标P50-P60分位；这类岗位市场供给充足，给高了浪费成本。
• 业务拓展类岗位（如销售、商务），可以适当降低固定薪酬对标分位，增加浮动薪酬比例，但固定部分不能低于市场P40，否则连人都约不来。

内部公平和外部竞争经常打架，我的经验是：先保外部竞争，再修内部公平。原因很简单——外部不公平导致人招不进来，内部不公平导致人留不住，前者是急性病，后者是慢性病，急性病不治，公司根本活不到慢性病发作的那一天。但内部公平也不能完全不管，需要通过序列间带宽的“允许交叉值”来缓解矛盾，而不是强行拉齐。

3.3 套档测算中的常见数据问题

套档过程中杂事很多，这里提三个一定会遇到的坑：

• 数据口径不统一。有人拿总年薪比、有人拿月薪比、有人把年终奖也折算进来。我统一用固定年薪（月薪×12＋固定补贴×12）来定档，绩效奖金和浮动奖金一律单列，不进带宽表。
• 特殊补贴成了历史遗留问题。很多公司给特定员工发过年费、通讯补贴、学历补贴之类，套档后这些补贴是否保留，要提前定好规则。我的建议是：套档时把“合理性补贴”折算进新薪酬，把“历史性补贴”冻结发放、新进员工不再适用，避免制度外项目越滚越多。
• 倒挂问题。新招的员工薪资比同职等老员工高，是数据模拟里最刺眼的现象。处理倒挂没有一招鲜的办法，但有一点值得做：给倒挂岗位的老员工做一个12个月的“追平计划”，在下次绩效调薪时优先倾斜，同时明确跟老员工沟通公司已经看到这个问题，否则老员工会用离职投票。

4. 管理规定成文：哪些条款必须写死，哪些要留活口

制度和章程的撰写，是一门关于确定性和灵活性怎么平衡的手艺。写得太死，执行时束手束脚；留口子太多，制度沦为空文。我想结合实践，谈谈哪些地方必须写死，哪些地方建议留活口。

4.1 必须写死的部分：晋升周期、调薪窗口、审批权限

先说晋升周期。每个职等的晋升最短间隔要明确写死。比如P3到P4原则上需要在本职等满一年，P5到P6建议满两年，M序列中层以上要满两年且期间绩效至少有一个A。不写死这个，业务部门会每个月都来追问“能不能给他提前晋升”，你会有开不完的特批会。

调薪窗口也要写死。我建议一年只设一到两个调薪窗口，比如每年4月和10月各一次。4月主要承接上年绩效结果，10月主要解决晋升、倒挂和特殊留人问题。窗口之外一律不处理例行调薪，只处理极少数特批。这样做的好处是让业务部门养成提前规划的习惯，而不是随时提需求、随时让HR被动响应。

审批权限是另一个必须明确的点。举个例子：晋升提名和绩效调薪，各部门负责人有提名权，但校准会（calibration meeting）负责评审，分管VP有否决权，薪酬委员会或CEO拥有最终审批权。每个权限的边界必须在制度中写得清清楚楚，防止“谁官大谁说了算”的现象蔓延。

4.2 建议留活口的部分：破格晋升、特殊情况加薪、异地调动

完全不留活口的制度，在现实面前一定执行不下去。以下几个场景我建议制度里写明“经薪酬委员会审议批准后可以破格/特殊处理”：

• 关键人才保留加薪。当一个业务线的核心骨干收到外部offer，你需要在短时间内决策是否加薪留人。如果制度里没有这条口子，就会错过留人的窗口期。
• 破格晋升。针对表现远超同级的员工，可以设置“提前晋升”通道，但必须附加条件——比如连续两年绩效A、有完成的重大项目证明、业务负责人亲笔提名等。我在制度里写的破格晋升上限是提前30%的时间，超过这个幅度就不再是“破格”而是“异常”，异常情况需要薪酬委员会全体通过。
• 异地调动和跨序列变动。员工从一线城市调到二线，薪酬按当地水平下调很容易导致人心浮动。我在制度里写：因公司原因调动导致薪酬下降的，保留原薪12个月，12个月后再按当地薪酬带宽调整。个人申请调动的，则按新标准从次月起执行。

这些口子虽然带有人情味，但一定都要走“薪酬委员会审议”这个流程。这样既保留了灵活性，又防止了口子被滥用。

4.3 制度文本的结构安排与表达方式

最后聊一聊怎么把制度文本写得既严谨又好读。

我建议严格采用“总则—序列与职等—薪酬结构—定薪与调薪—晋升与降级—特殊情形—附则”的结构。每章里面，先给定义，再给规则，最后给流程，三者不能混在一起。

特别注意“定义先行”这件事。比如“晋升”和“晋级”一定要区分——晋升指职等上调，晋级指在同一个职等内的薪资档位上调，这两个词在制度里混用会造成大量执行争议。

再就是表格和公式尽量前置。带宽表、级差表、绩效调薪矩阵，全部用附录表格呈现，正文只放引用链接。这样既方便员工查阅，也方便后续版本更新时不改动正文。

用语上尽量中性客观，避免出现“表现不好”“能力不足”这类主观评价词，替换成可验证的客观标准描述。比如“连续两个考核周期绩效为C”而不是“长期表现不佳”，这样可以减少劳动争议和内部申诉。

5. 制度发布后的真实情况：执行半年才会暴露的问题

制度发布只是开始，真正的大考在后面。等制度落地跑上小半年，会有很多在纸面上想象不到的问题冒出来。

5.1 全员反对的“薪酬保密条款”

几乎每家公司都会在制度里写“禁止员工互相讨论薪资”，但现实是：这条规定从来没有被真正执行过，也无法被真正执行。员工对薪资的好奇心是天然的，你越强调保密，私下讨论越火热。

我的策略是：

• 形式上保留保密条款，但弱化惩罚表述——从“解除劳动合同”改成“视情节给予纪律处分”。
• 行动上不主动追查薪资讨论，转向加强序列和职等本身的透明化建设。公开每个职等的能力要求和晋升条件，让员工把关注的焦点从“别人拿多少钱”转移到“我怎么升到下一级”。

5.2 序列转换与跨序列晋升的通道难题

制度跑半年后，业务部门会频繁提出序列转换的需求。最常见的有两种：

• 管理序列转回专业序列。有的干部干了一年被发现不适合带团队，硬留在M序列对组织和个人都是伤害。我建议在制度里用“过渡期”处理：保留原职级12个月，过渡期内安排专业序列对应职级的认证评审，评审通过的按新序列职级执行，评审不通过的再降一级。
• 专业序列里跨序列转岗，比如后端转算法、市场转产品。这类转换我建议一律降一级起步，先进入目标序列的低一档职等，半年后可以发起快速认证，通过后再回到原职等。这个规则的底层逻辑是：不同序列的能力体系不是完全互通的，你过去这些年积累的经验在未来序列里不一定直接适用。

5.3 预算封顶下的绩效调薪怎么不变成走过场

最后聊一个大家在实际中都会遇到的财务问题：年度调薪预算只有3%-5%，但绩效分布不能太难看，怎么办。

绩效调薪矩阵是个不错的工具。横向是员工在带宽内的CR位置（低于中位值、在中位值附近、高于中位值），纵向是绩效档（A/B/C），交叉形成不同的调薪比例。比如：

• 绩效A且CR低于80%的，调薪12%-15%，目标是快速拉回到带宽内合理位置；
• 绩效A且CR在80%-120%的，调薪8%-10%，保持领先但不越界；
• 绩效B且CR低于80%的，调薪6%-8%，给那些“能力可以但还没到A”的人一个追赶机会；
• 绩效B且CR高于120%的，调薪3%左右，甚至可以不调，因为他的薪资已经领先带宽位置很多。
• 绩效C的，原则上一律不调。

这套矩阵的好处是把预算用在刀刃上——同样是5%的预算，它可以做到让最需要保留的人拿到最多的涨幅，同时避免“高绩效但已经高薪的人再拿更多”的资源浪费。在执行中你会发现，最难说服的不是员工，而是那些给高绩效高CR员工只调3%的部门负责人——他们觉得下属绩效好就该多涨。这时你就把带宽内位置的数据摆出来，告诉他这个人已经高出中位值25%了，再按10%调上去，明年他涨薪空间就没了，而且内部公平会被打破。数据面前，多数负责人是能讲通道理的。

我在实际管理工作中越来越觉得，职级薪酬体系不是一套静态的表格，而是一个需要持续调优的动态治理系统。每年至少要做一次带宽回顾，看看外部对标分位数是否还成立、内部晋升节奏是否和原设计一致、红黄蓝名单的比例有没有失控。制度文件和带宽表只是这套系统的表层，更深层的东西，是公司对“什么样的人更值钱、什么样的成长更值得被奖励”这组问题的真实回答。每家公司给出的答案都不一样，这也决定了同一套方法论在不同组织里落地之后，会长成完全不同的模样。

三、设计要点

• 序列 → 管理/专业双通道，别一刀切。
• 带宽 → 中位值±浮动，控重叠与倒挂。
• 落地 → 透明规则+节奏，防通胀。

薪酬体系最怕”拍脑袋普调”：职级不清、带宽重叠，越调越乱。先立序列与带宽规则，透明落地，调薪才不引发内部公平焦虑。