开发者入职通常是按入职培训花了几天来衡量的，而那是问题的另一头。真正重要的数字是另一个：一个新来的工程师要过多久，才能改动某个东西，并且有把握自己没有弄坏别的地方。在大多数团队里，这个数字是以月计的，而不是以天计的。

延迟很少出在人身上。它出在系统里有多少部分只存在于别人的脑子里，以及前两周里有多大一部分时间，是靠一次次打断别人，一点一点把这些东西挖出来的。

唯一值得追踪的指标：从入职到他们的第一次改动进入生产环境，需要多久。 不是第一次提交，提交可以只是改一个错别字，而是一次有意义并且真正上线的改动。如果这个时间超过一周，障碍几乎从来都不是能力。而是一份最近没有人从零走过一遍的环境搭建流程，或者一份没有人带路就找不到入口的代码库。

开发者入职在和什么争夺资源

一共有三笔成本，其中只有一笔是新人自己的时间。

他们的时间，这是看得见的一笔，也是所有人都在优化的一笔。团队的时间，因为每一个问题都会打断某个正在做别的事的人，而这一笔比第一笔更大。还有那些始终没被问出口的问题的成本：新工程师宁愿自己猜，也不想在一个上午里第五次去打扰别人，而这一猜错得很隐蔽，两个月后才浮出水面。

好的入职流程真正消除的，正是第三笔。写文档之所以值得，不是因为读比问更快，而是因为它让人可以在晚上十一点自己查清楚，不必先掂量再问一次的人情成本。而问不出口的那一类问题，恰恰最容易埋下隐患，因为它们从来不会出现在任何一次站会上。

先把环境修好

决定第一周成色的最大单一因素，是这个项目能不能在一台干净的机器上、不靠任何人帮忙就跑起来。

团队总是低估这一点，因为每个人都已经有一套能用的环境，而且两年来没人重建过。与此同时，那份搭建文档指向的版本早就往前走了，漏掉了去年春天某人加进来的环境变量，还默认新人拥有某个服务的访问权限，而那个权限从来没有给过他。数据库的初始数据一个字也没写，写文档的人自己也想不起来为什么只有他本机上有。

补救办法并不体面。让下一个入职的人严格照着文档走，一个字都不改，把每一处失败都记下来。那张清单才是你真正的搭建流程。更好的做法是把它压缩成一条命令，一条命令就产出一个带着可用测试数据、已经跑起来的系统，因为每一个手工步骤都是一个迟早会走样的步骤。清单上的每一条最好变成仓库里的一次提交，而不是又一页写在维基上、下一个人同样读不到的说明。

权限也是环境的一部分。一个人拿到了代码，却没有仓库权限、没有预发布环境的凭据、没有任务跟踪工具，他就还没有准备好开工。请在入职日之前把账号准备好，而不是在第一个早上才发现窟窿。一次权限申请卡在忙碌的审批人那里、整整一天就没了，这种事一点都不少见。

立刻给一件真正的任务

想让新人先躲开真实工作两周，这份好意会起反效果。没有目的地读代码库，学到的东西非常有限，因为读到的内容没有可以挂靠的地方。

相反，在第二天或第三天交给他一个小的、真实的、可以发布的改动，就等于把整条交付路径教了一遍：代码在哪里，测试怎么跑，评审怎么走，部署怎么发生，以及该通知谁。新工程师最需要的正是这条路径，而最不可能被写在任何地方的也正是这条路径。

要挑一件真的有用户在等的事，不要编一个练习题。人是分得出来的，而这个差别决定了他们会不会认真对待反馈。第一次评审要尽快给出，让第一个改动挂上两天，等于在教一条你并不想教的、关于团队优先级的道理。

然后陪着他一起做。在懂这套系统的人旁边坐一个小时，传递的东西比读一整天还多，而陪着的那个人通常也会重新发现一些关于自家代码库的事。结对时让新人握着键盘、讲解的人只动嘴，这样学到的是操作，而不是旁观。

什么该写下来，什么不该

文档会腐坏，所以只写那些能一直成立、并且值回维护成本的内容。

值得写： 怎么搭建和启动系统，怎么部署，架构是什么形状以及为什么是这个形状，那些不写下来就会被反复重新争论的决定，还有谁负责什么。我们关于技术文档的指南更详细地讨论了维护这个问题。

不值得写： 代码已经说清楚的一切，对每个月都在变的界面做的一步步走查，以及手工维护的完整API参考。这类内容过期得最快，误导性也最强。

在多数团队里，价值最高的一份文档是一页简短的架构概览，说明大的组件有哪些、为什么被拆开。它花掉一个下午，很少需要改，却回答了每个新工程师用第一周自己拼凑出来的那个问题。配一张图会更好，而当那张图开始不准时，通常说明是设计本身动了。把重要决定连同当时的取舍记成一小段决策记录，也比事后再解释便宜得多。

入职是一场对团队的考试

新人卡住的每一件事，都是团队一直在无声吸收的东西。

如果搭建环境要花三天，这笔成本一直都在，只是被每一个重装过机器的人以小额分摊掉了。如果没有人说得清某个组件为什么存在，这份含糊早就在悄悄消耗决策质量。如果部署流程离不开某个特定的人，这份依赖本来就是风险，而它也正是在技术尽职调查和任何一份像样的恢复计划里会浮出来的同一个风险。

所以把最初几周当成一次免费审计。请新人把所有让他困惑的地方记成一张单子，并且把这张单子当作待办事项来读，而不是当作对他能力的评价。那是任何人能写出的、关于你这套系统最诚实的描述，因为再过两个月，他也会不再注意到这些了。这张单子最好在第一个月结束前收走，再晚就只剩下已经被习惯盖住的那一部分了。

Mecanik 会作为软件开发工作的一部分，经常加入已有的代码库，也就是说我们是靠着替别人的系统做这场考试为生的。上手快的团队并不是文档最好的团队，而是最近有人重建过自己的环境、并且把过程中弄坏的地方修好了的团队。

常见问题

开发者入职应该花多长时间？ 要衡量的是第一次有意义的改动进入生产环境所需的时间，而不是入职培训的长度。如果超过一周，障碍很少是能力。通常是一份最近没有人从零走过一遍的环境搭建流程，或者一份没有人带路就找不到入口的代码库。

新开发者头几天应该做什么？ 做一个小的、真实的、可以发布的改动，而且真的有用户在等它。没有目的地读代码库学不到什么，因为没有可以挂靠的地方；而一次真实的改动会教会他代码在哪里、测试怎么跑、评审怎么走、部署怎么发生，以及该通知谁。

为什么搭建开发环境要花这么久？ 因为每个人都已经有一套能用的，而且很多年没人从零建过，文档就这样慢慢走样了。补救办法是让下一个入职的人严格照着走、一个字都不改，并把每一次失败都记下来。那张清单才是真正的流程，把它压缩成一条命令就不会再走样。

为了入职，哪些文档值得维护？ 怎么搭建和启动系统、怎么部署、架构是什么形状以及为什么，那些不写下来就会被重新争论的决定，还有谁负责什么。代码已经说清楚的内容、每月都在变的界面走查、手写的API参考，都可以跳过。

入职缓慢说明团队存在什么问题？ 说明团队一直无声吸收的那些成本是真实存在的。三天的环境搭建，一直由每个重装过机器的人小额分摊。没有人能为其辩护的组件，早就在消耗决策质量。只有一个人能执行的部署，在新人到来之前就已经是风险。