企业官网建设流程全解析

• 文档
• 知识库

本文围绕 Teamlead Roadmap 知识库中"人员管理 → 解雇（firing）"分支文档展开，系统拆解技术团队领导在员工离职与解雇场景下的完整职责：从决策前的多维评估、绩效纠正的最后机会，到正式解雇的谈话话术、补偿方案与团队善后沟通。读完本文，你将掌握一套可直接落地的解雇决策算法与执行清单，并能与仓库中反馈、一对一、动机、试用期、行政工作等相邻分支的知识形成闭环。

解雇是什么：两种离职场景下的团队领导角色

解雇（firing）是员工与公司之间劳动关系的终止。员工可能自愿离职、双方协议解除，也可能由公司单方解除劳动合同。tlroadmap 的原文档指出，这两种场景下团队领导（Teamlead）的角色是不同的：

• 员工自愿离职：团队领导的核心任务是把离职过程对团队造成的冲击降到最低——减少相关风险、平稳交接，并启动替代人选的招聘。
• 公司解雇员工：团队领导的角色显著扩展，他不仅是决策的发起者，更是执行者。这意味着解雇不能甩给 HR 或上级，团队领导必须亲自走到台前。

这一分支在仓库中位于 tlroadmap/roles/people-manager/people-management/firing/ru.md，与它同级的 反馈（feedback）、一对一（one-on-one）、动机（motivation） 等分支共同构成"人员管理"的完整能力地图。

为什么这条分支重要

解雇不是孤立的人力事件，它同时作用于三个层面：

对下属而言：解雇是一段沉重的个人经历。员工最需要的是领导的支持，以及对决定原因的清晰解释。原文档特别强调：员工"惊讶于自己被解雇"本身就是管理失败的标志——说明此前的反馈链条已经断裂。

对团队而言：

• 每个团队都有自己的微气候（микроклимат），一个人的离开可能对整个团队产生强烈影响；
• 由于人手或特定能力减少，团队在解决工作任务时可能明显变慢，交付节奏被打乱。

对管理者而言：

• 解雇是管理员工绩效的最终工具（final instrument），是前面所有绩效管理手段失效后的兜底；
• 管理者对自己招进来的每一个人都负有完全责任，解雇正是这份责任的终点。

如果不做这条分支，会怎样

原文档给出了四个维度的代价，帮助团队领导校准"解雇时机"：

一句话概括：解雇的时机与方式是团队领导必须主动管理的关键变量，既不回避、也不滥用。

可以委派给谁

解雇这一分支的职责可以有限度地委派，但决策与执行的最终责任人仍然是团队领导：

• 下一级团队领导：可承担解雇流程的部分执行工作；
• HR：作为支持性职能参与，负责财务、法律、流程合规等事务，但不应替代团队领导完成解雇谈话本身。

原文档在"行为示例"中明确指出："团队领导自己不解雇员工，而把这件事完全推给 HR"是典型的坏行为。HR 是盟友，不是挡箭牌。

行为示例：好与坏的边界

坏行为（应坚决避免）

• 员工从未收到过负面反馈，直到被解雇那一刻才得知真相；
• 从未尝试帮助员工改进其缺点；
• 不考虑将员工调到其他团队或其他角色的可能性；
• 团队领导不做解雇，把整个流程完全甩给 HR；
• 不向团队解释解雇的原因。

好行为（应主动做到）

• 员工在工作中的缺点获得过持续的、具体的反馈；
• 为员工准备了改进目标与纠正计划（即绩效改进计划的基础形态）。

从仓库的 反馈分支文档 可以看到，反馈的两个核心属性是及时性（своевременность）与完整性（полнота）。解雇前的反馈必须同时满足两者：及时给出、完整说明，否则员工就会陷入"毫无预兆地被解雇"的境地，这正是坏行为第一条要避免的。

实战核心：解雇完整决策与执行算法

原文档坦言：解雇大多数时候是单次事件，谈不上系统性练习，因此提供的是可复用的算法。以下按决策、纠正、执行三个阶段完整展开。

阶段一：出现解雇念头时，先完成六维自评

在向任何人宣布决定之前，先把"想解雇"变成"该不该解雇"。围绕以下六个维度写下理由：

1. 员工绩效：目标完成情况如何？所承担任务的复杂度与完成质量如何？
2. 员工价值：是否拥有对业务至关重要的技能或知识？失去他会损失什么？
3. 对团队的积极贡献：对整体结果、团队内部气候、其他同事产生了什么影响？
4. 绩效提升的可能性：客观判断，他的绩效有多大概率还能回升？
5. 替代成本：解雇后重新招聘一个合适的人，要付出多高的成本？
6. 空缺成本：从员工离职到新人到岗之间的空窗期，项目要承担多大损失？

阶段二：交叉验证你的评估

单方面的判断是不可靠的。原文档要求：

• 向同事收集反馈，或对员工近期的绩效做一次系统分析，以此确认自己的评估结论；
• 检查员工的动机因素是否得到满足——可参考仓库的 动机分支文档，其中列出了金钱、认可、权力、技术挑战等典型动机因子；
• 思考员工真正感兴趣的工作是什么，公司是否有可能为他提供转岗到其他团队或角色的机会——在解雇之前，转岗是常被忽视的第三选项。

阶段三：判定影响范围，选择路径

关键的分叉问题：员工的绩效或行为，是只影响他自己那一亩三分地，还是已经波及整个团队？

• 如果影响仅局限于其个人角色 → 存在纠正空间，进入路径 A：纠正与改进计划；
• 如果影响已经扩散到团队整体 → 情况更严重，可能直接进入路径 B：正式解雇。

路径 A：最后一搏——反馈 + 改进计划

第 1 步：给出清晰反馈。用准备好的论据和事实说话，并确认员工真正听到并接受了——不是"说了就行"，而是"听懂了才行"。

第 2 步：共同制定纠正计划。这份计划必须满足四个硬性条件：

• 关联性：与触发解雇讨论的根本原因直接对应；
• 明确性：清楚描述对员工的要求与期望；
• 可验收：包含清晰的检查点（checkpoint）与验收标准；
• 现实性：在规定时限内是可完成的，而不是一张永远完不成的愿望清单。

第 3 步：明示后果。明确告知下属：如果计划未完成，他将被解雇，并再次确认他把这句话听进去了。这一步看似残酷，实则是公平——给员工一个明确的"最后一次机会"窗口。

这里与仓库的 一对一分支文档 形成天然衔接：反馈与改进计划的落地主要发生在定期的一对一会议上；而一对一文档也强调，会后应发送 follow-up 纪要、记录所有约定与期限，这些记录恰恰是将来解雇谈话中"引用过往沟通"的凭据。

路径 B：正式解雇——从准备到执行的七个动作

如果纠正路径已走完（或影响范围过大），解雇进入执行阶段：

① 规划团队的空窗期。提前想好没有这个人的团队如何运转：他的工作负荷如何重新分配、需要多久找到替代者、哪些事务需要交接给谁。原文档明确要求"提前设计好团队在没有此人的情况下如何组织工作"。

② 与 HR 对齐财务与法律问题。搞清楚公司应支付员工多少已工作天数的工资和未休假期补偿，准备好回答员工可能提出的任何财务与法律问题。这部分与仓库的 行政工作分支文档 直接相关——该分支覆盖劳动合同的签订与解除、休假与工资规则等劳动关系事务。

③ 决定是否支付额外补偿。与 HR 共同评估是否发放额外补偿金。原文档给出的常见区间是1～3 个月薪资。这笔钱的目的不是"买断"，而是：让员工能够从容地寻找下一份工作、让解雇过程更平稳、并显著缓和员工对公司的负面情绪。在 IT 这个圈子很小的行业里，这是一笔性价比极高的"声誉投资"。

④ 确定最后工作日。通常在两种方案中选择：一天内离职，或留出几天到两周的交接期。决策时考虑三个因素：

• 员工是否需要向他人交接工作；
• 员工留在岗位上是否会对团队产生负面影响；
• 团队是否会因"一天解雇"的突然性而产生负面反应。

⑤ 准备谈话脚本并预演。提前想好可能的提问与情绪反应，准备好回答口径。解雇谈话是最难的一次管理对话，值得像技术评审一样认真演练。

⑥ 开展解雇谈话。原文档给出了非常具体的执行细节：

• 开门见山：第一句话就说明"我已决定解雇你，这是最终决定，不是又一次纠正尝试"——不给虚假希望，避免谈话变成讨价还价；
• 引用历史：引用此前的沟通记录、改进计划（如有）、你本人与同事给出的反馈，证明决定有据可依；
• 承认贡献：单独说明员工对公司的贡献与他的优势，并解释为什么这些不足以抵消问题——这是对员工尊严的基本尊重；
• 留出消化时间：给员工时间思考，询问是否有问题；如果没有，再转入补偿话题；
• 坦诚边界：对回答不了的问题，坦诚请求时间弄清后再答复；
• 温和收场：尽量避免争吵与冲突，IT 圈子很小，能够和平分手就一定要争取；
• 主动提供推荐：提出自己可以作为员工在下一家公司面试时的推荐联系人，并明确表示会诚实——既讲优点也讲不足；
• 商定后续步骤：明确最后工作日、交接安排、补偿发放时间等具体事项。

⑦ 与团队沟通。谈话时机视情况在员工离开前或离开后进行：

• 向团队解释发生了什么，强调决定并非突然（这一点依赖于此前反馈链条的完整性），并说明员工的职责与任务将如何分配；
• 必要时与团队成员进行一对一的补充沟通，提供更多细节——这里再次复用一对一机制。

理论参考：原文档推荐的延伸阅读方向

原文档（firing 分支的"Теория"小节）为读者梳理了一批解雇主题的权威资料，此处以文字形式转述其要点（原文中的外部链接此处不再列出）：

• 员工视角的解雇故事：一篇引发数百条评论的社区讨论，汇集了大量"被解雇"的真实经历，有助于团队领导理解员工在被解雇时的真实感受；
• HBR《The Right Way to Fire Someone》：解雇算法与基本原则的经典论述；
• Quora 上的多人经验帖：汇集了不同背景管理者"如何正确解雇不达标的员工"的实操建议；
• Monster 的离职谈话指南：给出了解雇谈话的详细话术搭建方法；
• "有尊严地让员工离开"（《纽约时报》专栏）：关于分手姿态与尊重原则的补充阅读；
• HBR《Should You Fire a "Good Enough" Employee?》：讨论"差不多合格"的员工是否值得解雇的边界问题；
• Performance Improvement Plan（PIP）的制定与使用指南：与本文"路径 A"的纠正计划直接对应，可作为落地参考。

与 tlroadmap 其他分支的协同：解雇不是孤岛

从仓库的整体结构看，解雇分支是"人员管理"能力地图的末端节点，它与前后相邻分支构成一条完整的链路：

• 试用期（test-period）：原文档称试用期是"筛除不合适候选人的最后防线"，在此期间可以相对无痛地终止关系——管理得当的试用期能大幅降低后续正式解雇的发生率；
• 反馈（feedback）：解雇前的所有纠正动作都以及时、完整的反馈为前提；
• 一对一（one-on-one）：反馈、改进计划、解雇谈话、团队善后沟通都在一对一的场景中发生；
• 动机（motivation）：评估阶段需要判断员工的动机因素是否被满足，也解释了为什么补偿金能缓和情绪；
• 行政工作（admin）：劳动合同的解除、补偿计算、休假结算等法律与财务细节由该分支兜底；
• 职业发展（promo/career）：解雇前的"转岗"选项，本质上依赖公司是否有一套清晰的职级与岗位体系来承接。

综合来看，tlroadmap 对解雇的定义是一套**"先评估、再纠正、后执行、终善后"**的完整方法论：它把一次容易被情绪与慌乱主导的管理动作，拆解成有据可依、有步骤可循的专业流程。对于任何需要亲自做出并执行解雇决策的团队领导而言，这份分支文档与其相邻分支一起，构成了可以在真实管理场景中直接对照使用的操作手册。

（本文内容基于 tlroadmap 仓库 中 解雇分支文档 及其相邻分支整理而成，文中"补偿 1～3 个月薪资""最后工作日交接期"等数值均来自原文档给出的行业常见经验值，实际执行请以公司政策与当地劳动法规为准。）

• 文档
• 知识库