team-onboarding-playbook

一个可重复使用的框架，用于制定入职手册，让新团队成员稳步上手，同时避免培训他们的人精疲力竭。

适用场景

• 新员工即将加入，但你还没有书面的入职计划。
• 现有入职流程较为随意且不一致。
• 团队快速扩张，入职培训成了瓶颈。
• 承包商或代理合作伙伴需要快速上手。
• 团队成员即将离职，需要记录其知识。
• 目前入职培训耗时过长，你希望缩短所需时间。

不适用场景

• 用于持续的绩效管理（这是另一个问题）。
• 用于特定技术的培训（请使用有针对性的文档和教程）。
• 用于一般性文档策略（请使用 documentation-strategy）。
• 用于职位定义或招聘（这是上游的另一个问题）。

所需输入

• 职位：此人将负责什么，以及 90 天后怎样才算成功。
• 现有材料：文档、运行手册、代码库、设计文件。
• 团队：谁负责指导，谁负责结对协作，谁回答哪类问题。
• 工具和访问权限：新成员需要哪些账户和系统。
• 时间预算：团队成员可以投入多少时间进行入职培训。

框架

良好的入职计划包含 4 个层面。四个层面都要落实。

层面 1：归属感（第 1 天至第 1 周）

第一周的重点主要是建立归属感，而非提高效率。做好这一点，其他一切都会加速推进。

• 在他们入职前发送欢迎信息。
• 在第 1 天之前准备好工作空间和账户。不要说“之后再处理”。
• 指定一位伙伴或入职搭档（不是经理）。
• 安排第 1 天日程，既不要开满 8 小时会议，也不要完全没有会议。
• 介绍他们会经常合作的同事。
• 建立第一周的节奏：每天与经理或伙伴进行沟通。

层面 2：背景信息（第 1 周至第 4 周）

下一阶段是了解背景信息。新成员需要先理解系统，才能对其进行修改。

• 产品或业务：我们做什么、服务谁、存在的意义是什么。
• 团队：各自负责什么、如何做出决策。
• 技术或运营环境：架构图、主要工具、关键文件。
• 近期情况：重要决策、近期发布、当前优先事项。
• 正在进行的项目：哪些项目正在推进，以及它们之间的关联。

阅读清单也是其中一部分。保持简短、附上注释并精心筛选。

层面 3：做出贡献（第 2 周至第 6 周）

到了第 2 周或第 3 周，新成员就应该开始做出实际贡献。不是因为他们已经完全上手，而是因为做出贡献正是逐步上手的方式。

• 第 2 周安排一项小型、范围明确且可以交付的首项任务。
• 第 3 周结对协作或跟进一项真实工作。
• 到第 4 周或第 5 周，独立负责一个小项目。
• 从一开始就参与代码审查、设计评审或同等形式的同伴反馈。

首项任务很重要。选择一项涉及主要系统、但不会影响任何重要内容的任务。完成交付后，能增强信心并提高可见度。

层面 4：精通（第 2 个月至第 3 个月）

到 90 天结束时，新成员应该成为团队的正式一员。

• 端到端负责一个项目。
• 如果团队有值班或轮值安排，则参与其中。
• 参与路线图讨论，而不只是执行讨论结果。
• 指导或支持下一位新员工。

90 天是一个检查点，而不是终点。记录哪些做法有效、哪些有所缺失，为下一位新成员做好准备。

30/60/90 天计划

每份入职计划都应明确设定第 30、60 和 90 天的里程碑。

30 天

• 工作空间、工具和访问权限全部设置完毕。
• 已与每位团队成员见过面。
• 了解产品、团队和近期背景信息。
• 已交付或参与至少一项实际工作。
• 清楚了解自己的首个重要项目或负责领域。

60 天

• 能够独立负责一个项目或领域。
• 知道去哪里寻找答案，而不是每次都要提问。
• 已与直属团队以外的同事建立良好的工作关系。
• 至少对某个流程、文档或代码库做出了一项有意义的改进。

90 天

• 能够充分胜任岗位工作。
• 参与路线图和规划讨论。
• 能够为下一位新员工讲解系统的部分内容。
• 愿意提出问题并表达不同意见。

如果有人在 30/60/90 天检查节点时明显未达到这些标准，就要直接解决问题。可能是计划不合适、支持不到位，或岗位匹配度不够。寄希望于问题自行消失是行不通的。

针对不同岗位的补充计划

上述框架适用于所有岗位。具体内容则因岗位而异。

工程

• 第 1 天：搭建好开发环境，完成首次提交（修正文档或做一项微小改动）。
• 第 1 周：阅读架构文档，了解主要服务的代码路径。
• 第 2 周：交付一项小型 Bug 修复或重构。
• 第 4 周：负责一项功能或一个组件。
• 第 2 个月：先跟班学习值班工作，然后开始值班。

设计

• 第 1 天：配置好设计工具，开通设计系统访问权限，阅读品牌指南。
• 第 1 周：参加工作室评议和设计评审。
• 第 2 周：负责一个小范围的设计（例如设置页面或空状态）。
• 第 4 周：主持一项正在开发中的功能的设计评审。
• 第 2 个月：端到端负责一项功能的设计。

产品

• 第 1 天：阅读战略文档、路线图和最新的 3 份 PRD。
• 第 1 周：旁听客户电话会议、参加支持团队同步会，并加入所有相关团队的站会。
• 第 2 周：撰写一份需求探索文档或竞品分析。
• 第 4 周：负责一份功能规格说明。
• 第 2 个月：负责一个路线图领域。

营销或内容

• 第 1 天：阅读品牌语调文档、近期营销活动资料和表现最佳的内容。
• 第 1 周：阅读客户研究资料和用户画像文档。
• 第 2 周：发布一篇小型内容（例如社交媒体帖子或博客修改）。
• 第 4 周：端到端负责一篇内容。
• 第 2 个月：负责一场营销活动或一个渠道。

根据你的岗位和技术栈进行调整。整体框架保持不变。

工作流程

1. 在新员工到岗前开始准备入职手册。不要等到第 1 天才写。
2. 提前准备好账号、硬件和访问权限。这是第 1 天最常见的故障点。
3. 指定一位伙伴，并告知对方需要做什么。
4. 在新员工入职前发送欢迎信息和第 1 天的日程安排。
5. 第 1 周重点关注归属感和背景信息，而不是产出。
6. 第 1 周每天沟通一次，第 1 个月每周沟通一次。
7. 在第 30/60/90 天进行正式检查，并明确列出里程碑。
8. 90 天后进行回顾：哪些做得好，哪些有所欠缺。
9. 根据回顾更新入职手册。入职文档需要持续更新。

常见问题

• 没有计划。 第 1 天没有日程安排、没有笔记本电脑、没有账号。这样的开局会定下基调。
• 信息过载。 第 1 天安排 8 小时会议。员工什么也记不住。
• 长期没有实际工作。 连续三周“阅读文档”会让人沮丧。尽早交付一些小成果。
• 只有伙伴，没有经理。 伙伴很有帮助，但无法进行评估或为员工争取支持。经理仍须承担责任。
• 把部落知识当作门槛。 “有问题就问 Sara”在 Sara 休假时就行不通了。把 Sara 一直在解答的问题记录下来。
• 没有 30/60/90 天里程碑。 当某人看起来忙起来时，入职流程就算“结束”了。这不算里程碑。
• 所有岗位都用同一份计划。 工程和营销在第一周的需求不同。使用针对不同岗位的补充计划。
• 没有回顾。 没人更新入职手册，导致每位新员工都会遇到同样的问题。
• 伙伴没有时间。 指定一位已经忙得不可开交的伙伴，必然会导致入职效果不佳和倦怠。要保障他们的时间。
• 跳过客户或产品背景介绍。 不了解客户是谁的工程师会做出错误的东西。不了解产品运作方式的营销人员会写出内容单薄的文案。

输出格式

交付物：

1. 入职前检查清单：账户、硬件、访问权限、伙伴分配、欢迎消息。
2. 第一天安排：会议列表、自我介绍、首项交付物。
3. 第一周阅读清单：5-10 份精选并附有说明的文档。
4. 30/60/90 天里程碑：该职位的明确检查点。
5. 伙伴指南：入职伙伴应承担的职责。
6. 经理沟通频率：安排好的 1:1 和里程碑评审。
7. 回顾模板：在 90 天时填写，以便改进下一次入职流程。

参考文件

• references/onboarding-checklist.md：涵盖前 30 天、按天和按周安排的检查清单，包含特定职位的变体以及 30/60/90 天评审模板。