工作总结
发表时间：2026-03-27人力资源执行副总裁年度工作总结。
这一年，我试着把干运维那套逻辑搬到了人力资源上。干过运维的都知道，系统出问题，第一反应不是追责，是看监控、拉日志、定位故障点。搞人力资源也一样，团队出状况，别急着开会喊口号，先把数据摆出来，看看是哪个环节在报错。
一、招聘这块，我把它当“故障响应系统”来修
上半年最头疼的是招聘周期太长，核心岗位从需求出来到人入职，平均45天。这个数字在运维里意味着什么？意味着你的监控系统发出告警，你花了一个半月才把备机上线，业务早崩了。
我干的第一件事，是拉数据。把过去两年的招聘流程拆成六段：需求确认、职位发布、简历筛选、面试安排、offer审批、入职准备。结果发现两个堵点：需求确认平均7天，offer审批平均12天。
需求确认卡在哪儿？用人部门提需求的时候，写的是“要一个能扛事的技术负责人”。什么叫“能扛事”？谁说了算？我拉着CTO，把每个技术岗位的职级能力做成清单，像故障工单一样，必须填写技术栈、项目经验、薪酬带宽，缺一项退回重填。offer审批更离谱，VP们出差多，纸质审批单在桌上躺一周是常事。我让IT把审批流搬到OA系统，设置24小时超时自动升级到上一级。
这两个改动，说起来简单，推起来费劲。第一次在会上提，业务VP直接怼我：“你们HR就知道搞流程，我们前线打仗哪有时间填表。”我没反驳，会后把过去一年因为审批延迟流失的候选人数据拉出来，发给CEO。CEO看完，在管理会上拍板：流程不改，流失的人算各部门流失率。
三个月后，核心岗位招聘周期压到27天，Q4进一步缩到22天。入职后试用期通过率从68%提到89%。说白了，招聘慢，八成是流程有bug，修流程比催HR打电话管用多了。
二、人才盘点，就是给团队做“健康巡检”
干运维的有个习惯，每季度对核心设备做健康度检查。人才也一样，不能等人走了才复盘。
年中，我拉着CTO，把P7以上的技术骨干过了一遍筛子。定了三个硬指标：技术贡献度（代码量、故障处理数）、业务影响力（交付质量、项目贡献）、可替代性（文档完整度、知识传承）。结果一出来，我们俩都沉默了——30%的核心骨干，关键系统的架构、脚本、配置全在自己脑子里，没有任何文档沉淀。
其中一位数据库负责人，所有核心表的DDL、备份脚本都在他个人笔记本上，连他上级都不知道。那感觉就像你发现整个系统的root密码只有一个人知道，而他明天可能提离职。
我要求所有P7及以上人员，必须建立个人知识库，纳入月度绩效考核。同时启动“双人复核”机制，每个核心系统至少两人完全了解架构。推进时阻力不小，有位架构师直接说：“代码就是最好的文档，写文档就是浪费时间。”
我没跟他吵。让他的上级把他的月度绩效权重从“代码量70%”改成“代码量40%+文档完整度30%+代码量30%”。第一个月他绩效扣了15%，第二个月主动来找我要文档模板。
三个月下来，核心岗位的知识覆盖率从45%提到78%。这个覆盖率怎么算的？我们定了标准：每个核心系统，至少有两名工程师能独立完成故障定位和恢复。达不到的，算系统级缺陷，挂在技术部门KPI里。
三、处理“人员故障”，得像隔离故障节点一样果断
8月的一个周一，我刚到工位，运维总监冲进来：某核心业务线负责人，连续两周代码提交量为零，团队里三个骨干同时提了转岗申请。
我没急着找HRBP要绩效记录。先让数据分析师调了他过去半年的数据：代码提交量从平均每周40次降到5次，故障工单处理时长从2小时拉到12小时，code review参与率从80%掉到10%。数据曲线在Q2末断崖式下跌。
我没有直接找他谈话。先花了两天，分别和他上级、他团队两个骨干、他老婆（对，我动用了私交）通了电话。确认了两件事：第一，不是团队内部矛盾；第二，他家里确实出了状况，老人住院，孩子升学，他自己也查出了轻度焦虑。
第三天，我约他在楼下咖啡馆谈。没谈态度，直接摆数据。“你过去两个月，code review参与率从80%降到10%，三个核心模块的故障你都在压着不处理。你遇到什么问题了？”
他沉默了很久，眼眶红了。承认自己扛不住了，白天开会、晚上陪床、凌晨改代码，两头都顾不上。
我当场做了两个决定：第一，他转为高级技术专家岗，卸任管理职责，直接汇报给CTO；第二，从隔壁团队调一名资深组长，临时接管该业务线的日常管理，为期三个月。
这个决定，我没跟任何人商量，但我知道自己权限边界在哪里。转岗需要CTO同意，我在咖啡馆当场给他打了电话，CTO听完只说了一句：“按你说的办。”临时接管需要那位组长同意，我提前跟他谈过，他愿意顶三个月。
三个月后，那条业务线的交付质量回到正常水平。那位同事在技术专家岗上重新找到了节奏，今年还带出了两个徒弟。
记得有一次，我们连续三个通宵处理一个核心交易系统的性能瓶颈。凌晨三点，机房空调坏了，温度飙到40度，所有人光着膀子在机柜前抓包分析。最后定位到是某个中间件版本的内存泄漏。我拍板做热补丁。补丁打上去，TPS从1200恢复到了4500。
那一刻我突然想，干运维和干人力资源，其实是一回事：都是在不确定的环境里，靠数据做决策，靠标准保底线，靠预案防风险。不同的是，机器宕了可以重启，人崩了，得有人兜底。
-
迷你日记网（W286.coM）职场老鸟私藏:
- 副总裁工作总结 | 人力资源部年度工作总结 | 人力资源专业副总监工作总结 | 子公司人力资源工作总结 | 人力资源执行副总裁工作总结 | 人力资源执行副总裁工作总结
四、招聘和晋升，我按“质量验收”的标准来卡
以前我们招人，面试官凭感觉打分，新人入职后才发现能力不匹配。晋升也一样，答辩会变成演讲比赛，能说的上，干得好的反而吃亏。
我干了两件事。第一，招聘面试强制加入“代码实操”和“故障场景模拟”。后端岗考SQL优化，前端岗考页面性能调优，运维岗直接给一个线上故障日志，限时定位。面试官必须按《技术岗位能力矩阵》逐项打分，低于85分的一票否决。
第二，晋升答辩取消PPT，直接调过去一年的工单系统记录、代码提交记录、故障报告，作为主要依据。第一次执行的时候，有位候选人答辩时当场发飙：“我干了三年，你们就看我代码量？”我回他：“你是运维，你处理的故障、你写的脚本、你留的文档，就是你的业绩。”
效果很直接。新入职员工试用期通过率从82%提到95%，晋升后绩效不合格率从15%降到4%。之前有个技术骨干，答辩时嘴笨，讲得磕磕巴巴，但调出数据一看，过去一年处理了43起P0级故障，写了12份复盘报告。最后全票通过晋升。
五、没干好的地方，得认
这一年，也有没干好的。干部储备机制，今年暴露出了问题：三个总监级岗位空缺时，内部居然找不出一个完全胜任的接替者。
我复盘了一下，问题出在轮岗机制上。我们一直强调“专业深度”，但忽略了“管理宽度”。技术总监候选人，对业务了如指掌，但对财务、对跨部门协作完全没概念。
明年我打算搞“干部梯队建设”，像做多机房容灾一样，每个关键管理岗至少储备两个后备人选，定期轮岗、定期演练。轮岗不是走过场，是实打实去别的部门干三个月，带着KPI去，带着成果回来。
干运维出身的人，最怕系统跑得好好的，突然崩了。干人力资源也一样，最怕团队表面一团和气，一查全是单点风险。
未来一年，没别的，继续修bug，继续建标准，继续把每个流程的“可用性”提到99.99%。这活儿，干得踏实。
-
想了解更多工作总结的资讯，请访问：工作总结
