一、目的
为建立有序的职级职位体系，构建通畅的员工职业发展通道，明确各职级标准等，特制订本制度。
二、范围
本规范适用于研发团队全员，含隶属于成都研发的外地研发团队。
三、名词解释
3.1 职位序列：是指根据工作性质的不同，组合类似职位族而形成的职位序列。公司的职位序列分为M（Management，管理）、I（Innovation，创新）、T（Technology，技术）三大职位序列。
3.2 职等：是指将困难程度、责任大小、所需资格等条件都大致相同的职级，归纳为职等。
3.3 职级：是指将职位序列作出区分，以区别不同级别所需的能力标准、任职要求，如T1、T2即为两个职级。
3.4 职位族：是指将工作内容、性质等相类似职位组合而形成的职位集合。
3.5 职位：是组织中的最小结构单元，是指为了完成某一项职能或工作任务而需要具备的能力、责任、权利等的综合称呼。
3.6 晋级：是指员工能力经评估后达到下一个职级要求，则晋级到下一个职级，如从T3.1晋级到T3.2。
3.7 晋职：是指员工的职级达到下一个职级对应的职等，如从T2工程师级晋职到T3.1高级工程师级。
3.8 降级：是指员工能力经评估后无法胜任该职级要求，则降级到上一个职级，如从T3.1降级为T2。
3.9 降职：是指员工的职级降级到上一个职级对应的职等，如从T3.1高级工程师级降职为T2工程师级。
四、权责
人力资源中心为本制度管理单位，负责本制定的制定、修改及相关解释，各级员工均需遵照本制度执行。
五、职级体系
5.1 职级框架
|
职级框架 | ||||||||
|
职级 |
管理通道 |
专业通道 | ||||||
|
M序列 |
职等 |
I序列 |
T序列 |
职等 | ||||
|
M5 |
C？O级 |
I7 |
T7 |
首席/科学家 | ||||
|
I6 |
T6 |
架构师级 | ||||||
|
M4 |
M4.2 |
VP级 |
I5 |
T5 |
专家级 | |||
|
M4.1 |
I4 |
I4.3 |
T4 |
T4.3 |
资深工程师级 | |||
|
M3 |
M3.2 |
总经理级 |
I4.2 |
T4.2 | ||||
|
M3.1 |
I4.1 |
T4.1 | ||||||
|
M2 |
M2.2 |
总监级 |
I3 |
I3.3 |
T3 |
T3.3 |
高级工程师级 | |
|
M2.1 |
I3.2 |
T3.2 | ||||||
|
M1 |
M1.2 |
经理级 |
I3.1 |
T3.1 | ||||
|
M1.1 |
I2 |
T2 |
工程师级 | |||||
|
M0 |
组长/主管级 |
I1 |
T1 |
助理工程师级 | ||||
|
I0 |
T0 | |||||||
5.2 职级标准
职级标准是各职级的人才画像，集合了各职级对人的能力和综合素质的要求，员工必须达到相应标准才能被评定到该职级。研发团队的职级标准请见《研发职级标准》（附件1）。
5.3 职业发展
职业发展通道是员工可能在公司可能的发展路径。公司的职业通道分为管理通道（M序列）和专业通道（I/T序列），根据员工意愿和能力，两个通道可以转换发展。研发团队的职业发展通道如下：
|
M5 |
T7 | ||
|
M4.2 |
T6 | ||
|
M4.1 | |||
|
M3.2 |
T5 | ||
|
M3.1 | |||
|
M2.2 |
M I/T双通道 |
T4.3 | |
|
M2.1 |
T4.2 | ||
|
M1.2 |
T4.1 | ||
|
M1.1 |
T3.3 | ||
|
M0 |
I/T3.2 | ||
|
I/T3.1 | |||
|
I/T2 | |||
|
I/T1 | |||
|
I/T0 | |||
研发团队提倡以夯实专业能力为基础，在合适情况下发展管理能力。为此，在管理通道的前五个职级（具体指M0、M1.1、M1.2、M2.1、M2.2）设计了与专业通道双通道并行发展的机制，即该几个管理职级的员工同时也需要评估专业职级，除此外其它职级均为单通道发展。双通道发展的，职级对应的薪酬按“就高不就低”给予定薪。专业职级达到一定职级后方可进行管理职级晋级，具体规则为：
- 往M0晋级的，专业职级不得低于I/T3.2；
- 往M1.1晋级的，专业职级不得低于I/T3.3；
- 往M1.2晋级的，专业职级不得低于I/T4.1；
- 往M2.1晋级的，专业职级不得低于I/T4.2；
- 往M2.2晋级的，专业职级不得低于I/T4.3。
- 往M3.1及以上晋级的，不再限定专业职级要求。
5.3.1 职业发展
员工专业能力达到I/T3.2的职级及以上时，如果团队内部有职位空缺且员工有能力和意愿往管理序列方向发展，可以申请从专业序列往管理序列发展（起始职级为M0）；同样，如果员工处于管理通道上，但员工有能力和意愿往专业序列方向发展，也可申请从管理序列往专业序列发展。公司鼓励员工内部合理流动，包括异动、跨序列发展等。跨序列发展需经过职级评定委员会评定新的职级后方可。
5.3.2 晋级晋职与降级降职
员工的发展有升有降，员工的能力达到相应职级标准则匹配对应职级、职等，包括晋级晋职与降级降职。晋级/降级是晋职/降职的基础，职级升、降后则对应进行职等的调整。原则上逐级晋级和降级，特殊情况可除外。
1）、晋级：
以员工能力和工作业绩为基础，如果员工能力超出本职级标准达到下一职级标准，则可以申请进行晋级，
|
晋级要求 | ||||||
|
层级 |
晋升申报 |
基本资历 |
能力要求 |
价值观 |
绿色通道 | |
|
年限 |
绩效 | |||||
|
I/T3.3晋级I/T4.1或以上职级晋升 |
二级部门以上负责人提名，HRBP审核资格 |
在上一职级至少工作1年 |
最近半年考核不得有B或更低 |
按相关职级标准要求进行严格评定，须满足全部要求，半年内不得有重大过失。 |
结合公司/部门价值观，通常作为一票否决。 |
绩效持续优秀的员工，可适当放宽资历条件限制，须经相关委员会确认。 |
|
I/T3.2及以下职级晋升 |
员工可自己申请或由二级部门负责人提名，HRBP审核资格 |
在上一职级至少工作半年 |
最近半年绩效至少有一次B 或以上 | |||
|
I/T3.2及以上晋级M0或以上 |
往M0晋级的员工可自己申请或由二级部门负责人提名，HRBP审核资格；M0往M1.1及以上晋升的，需由直接上级提名，HRBP Head审核资格。 |
在上一职级至少工作1年 |
最近半年考核不得有B或更低 | |||
经评估通过后，晋级到下一职级。晋级要求如下：
2）、降级：
符合以下条件的可以降级：
- 员工能力不能满足本职级标准，只能匹配更低职级要求的；
- 员工在上一个绩效考核周期内有重大工作失误的；
- 员工工作态度消极、与公司价值观不匹配的；
- 一年内接受过公司重大处分的；
- 其它认定的符合降级情况的。
5.3.3 组织结构与职级职等匹配
为规范各级组织架构的人员任命及管理，匹配各级组织职责，健全人才管理体系，保障各级组织人岗匹配，特规定如下：
- 三级部门（如XX组）负责人职级需在M0 I/T3.2及以上；
- 二级部门（如XX部）负责人职级需在M1.1 I/T3.3及以上；
- 一级部门（如XX中心）负责人职级需在M2.1 I/T4.2及以上。
各级组织架构对应负责人可以高配职级，但不得低于以上职级要求；特殊情况除外。
5.3.4 其它
1）、时间窗口：以每半年（每年1月和7月）为一个窗口期评估员工能力与职级匹配情况，进行晋级晋职或降级降职工作，特殊情况除外。管理通道M1.1及以上级别的，每年1月均需参与管理述职。
2）、主导单位：由HR主导开展，各级员工参与，职级评定委员会进行评定。
3）、组织形式：由待晋级候选人进行现场述职。其中I/T3.3以下晋级由各一级部门及HRBP组织，同时需至少邀请一位其它一级部门负责人参与，组成不少于3人评审委员进行述职评审；I/T3.3及以上晋级及管理通道晋级的由人力资源部组织，候选人向职级评定委员会（每次不得少于5人）进行述职评审。
5.4 职级评定委员会
研发职级评定委员会的职责为指导建立科学的研发职级体系、进行员工的能力评定等。研发职级评定委员会的成员由研发线专家组织（TMG/PMG等）、人力资源及其他相关职能高级管理者等组成。
六、职位体系
6.1职位框架
为方便进行研发团队职位管理，对研发相关职位进行归纳梳理，倡导全栈文化，特按职位序列梳理出研发团队职位框架如下：
|
职位序列 |
M序列 |
T序列 |
I序列 | ||||||||||||
|
职位族 |
技术管理族 |
开发族 |
人工智能族 |
信息安全族 |
运维族 |
硬件开发族 |
设计族 |
产品族 |
项目族 | ||||||
|
职能 |
— |
测试 |
前端开发 |
后端开发 |
客户端开发 |
嵌入式开发 |
算法 |
信息安全 |
运维 |
硬件开发 |
UE |
UI |
产品策划 |
产品运营 |
项目管理 |
6.2 职位管理
人力资源中心负责对研发团队职位进行管理，包括职位的增加、删减等，以规范公司职位体系，清晰定义职位工作职责和任职要求，并在此基础上建立研发职位图谱及职位库。
6.2.1 职位命名
职位命名要求职位名称能够体现职位主要工作职责。研发团队所有职位采用“职能 职等”的形式作为职位命名的基础规则。如T4.1的后端开发工程师的职位名称为“高级后端开发工程师”，部分职位如“产品经理”、“项目经理”、“UI设计师”等岗位则参考市场上公认命名规则。
研发团队职位图谱如下：
|
研发团队职位图谱 | |||||||||||||||
|
职位序列 |
I序列 |
T序列 | |||||||||||||
|
职位族 |
产品族 |
项目族 |
设计族 |
开发族 |
运维族 |
信息安全族 |
硬件开发族 |
人工智能族 | |||||||
|
职能 |
产品运营 |
产品策划 |
项目管理 |
UI |
UE |
前端开发 |
后端开发 |
客户端开发 |
运维 |
信息安全 |
硬件开发 |
算法 | |||
|
职位 |
M5 |
C？O级 |
/ |
/ |
/ |
/ |
CTO |
/ |
/ | ||||||
|
M4 |
VP级 |
产品副总裁 |
/ |
/ |
研发副总裁 |
/ |
/ | ||||||||
|
M3 |
总经理级 |
产品总经理 |
项目管理总经理 |
/ |
研发总经理 |
运维总经理 |
信息安全总经理 |
硬件开发总经理 |
/ | ||||||
|
M2 |
总监级 |
产品总监 |
项目管理总监 |
设计总监 |
研发总监 |
运维总监 |
信息安全总监 |
硬件开发总监 |
算法总监 | ||||||
|
M1 |
经理级 |
产品运营经理 |
产品策划经理 |
项目管理经理 |
设计经理 |
前端开发经理 |
后端开发经理 |
客户端开发经理 |
运维经理 |
信息安全经理 |
硬件开发经理 |
算法经理 | |||
|
M0 |
主管级 |
产品运营主管 |
产品策划主管 |
项目主管 |
设计主管 |
前端开发主管 |
后端开发主管 |
客户端开发主管 |
运维主管 |
信息安全主管 |
硬件开发主管 |
算法主管 | |||
|
I/T7 |
首席/科学家 |
首席产品官 |
/ |
/ |
软件开发科学家 |
/ |
/ |
/ |
人工智能科学家 | ||||||
|
I/T6 |
专家级 |
产品专家 |
项目专家 |
设计专家 |
软件开发专家 |
/ |
/ |
/ |
算法专家 | ||||||
|
I/T5 |
架构师级 |
产品架构师 |
项目架构师 |
设计架构师 |
前端架构师 |
后端架构师 |
客户端架构师 |
运维架构师 |
信息安全架构师 |
硬件开发架构师 |
算法架构师 | ||||
|
I/T4 |
资深 |
资深产品经理 |
资深项目经理 |
资深设计师 |
资深前端开发工程师 |
资深后端开发工程师 |
资深客户端开发工程师 |
资深运维工程师 |
资深信息安全工程师 |
资深硬件开发工程师 |
资深算法工程师 | ||||
|
I/T3 |
高级 |
高级产品运营经理 |
高级产品策划经理 |
高级项目经理 |
高级UI设计师 |
高级UE设计师 |
高级前端开发工程师 |
高级后端开发工程师 |
高级客户端开发工程师 |
高级运维工程师 |
高级信息安全工程师 |
高级硬件开发工程师 |
高级算法工程师 | ||
|
I/T2 |
工程师级 |
产品运营经理 |
产品策划经理 |
项目经理 |
UI设计师 |
UE设计师 |
前端开发工程师 |
后端开发工程师 |
客户端开发工程师 |
运维工程师 |
信息安全工程师 |
硬件开发工程师 |
算法工程师 | ||
|
I/T1 |
助理级 |
助理产品运营经理 |
助理产品策划经理 |
助理项目经理 |
助理UI设计师 |
助理UE设计师 |
助理前端开发工程师 |
助理后端开发工程师 |
助理客户端开发工程师 |
助理运维工程师 |
助理信息安全工程师 |
助理硬件开发工程师 |
助理算法工程师 | ||
|
I/T0 | |||||||||||||||
6.2.2 职位变更
根据公司发展需要，HR定期修订公司职位体系。当出现新的工作职能时，新增职位；当原工作职能消失时，删减职位；当原工作职能调整时，修订职位。禁止采用职位库以外的职位名称。如需新增、删减、修订职位名称的，由职位使用部门填写《职位变更申请表》（附件2）。
6.2.3 职位编号
为便于管理，HR对研发职位进行统一编号，编号规则为“YF-职位序列-职位族代号-流水号”，如测试工程师的职位编号为“YF-T-CS-001”。研发团队职位库请见《G7研发团队职位库》（附件3）。
6.2.4 其它
当员工的职级、工作内容发生变化等情况时，应当更正员工的职位名称；
当员工兼职不同职位时，以员工主要工作内容所对应的职位名称进行称呼。
七、其它
本制度自颁布之日起执行，其它未尽之处由HR负责解释。
,
