新创公司如何建立优质的工程师到职流程

原文How to Build a Good Onboarding Process for New Hires at a Startup
本文由The Effective Engineer作者Edmond Lau授权翻译

 本文是作者于Quora上的回答 整理

「不游就淹死 (sink-or-swim)」， 这听起来不是最鼓舞的话。  Ooyala的CTO,也是前Google联合创始人， Sean也许可在我进入状况后跟我说这话， 不过这话在我一到职跨入新创世界的第一天就明白告诉我- 不会有什麽救生圈，唯一可行的是不断挣扎且最好学会如何以最快的速度生存。

从第一天我进入一个30几岁的人开创的公司 Ooyala ， 我发现自己一直在龟速处理一个程式码基底(codebase)。 这程式码搅和着技术债(technical debt)， 有一点文件说明，  没什麽单元测试(unit tests)，且用我不熟悉的以类似Java的语言ActionScript所写的， 我只有两个星期的时间建构上线一个已经承诺给影片出版者的功能， 一个能让他们可以排程影片那时候可以上线上线的功能。 为了能准时完成， 我必须学习ActionScript， 马上使用Ruby on Rails，熟悉Flash影片和图形函式库 ，除此之外还要追踪一堆杂乱的程式码，内含不明的变数如 “qqq” 以及让人问号一堆的函式名称如 “load2” 和 “load3”。 

我别无选择只能很伤脑筋地在两个星期70-80小时的限制内， 按时交付我刚到职的第一个功能。  这 「不游就淹死 (sink-or-swim)」的到职经验至今仍旧是我最紧张最吓人的工作经验。  刚到职的那几天， 我经常怀疑自己不该离开Google的舒适环境， 这样的新创世界对我是正确的选择吗? 最终在团队伙伴的帮助下， 我适应了新环境， 一直以来含意模煳的程式码也已採用更强的工程实践替代。  这两年与敬业的团队伙伴共事我学习到很多，但总觉得刚到职的日子是否可以更平顺、有更好的经验呢?  

在2010年八月之后，我加入Quora的12人团队， 到职的流程并没有更好的进展。  Charlie Cheever给我一些初始的解bug工作， 但由于没有任何付费客户， 除了自我要求的学习外并没有任何时间压力。 到职过程主要是我自主地去找团队不同的成员请他们解释一些事情，也许还有一两个特别成立的白板讨论。  我在Ooyala的到职经验以及两年在新创公司的实战经验已经让我足以应付任何事，所以在Quora的融入生产力过程相较温和很多。
我的到职经验后来激发我在Quora启动到职计画，  在2012年11月我曾详细写下 What is the onboarding process for new engineers at Quora?

真的有需要为了新员工的到职投资时间?

新创公司有成千上万的事需要完成， 且很多都在跟时间赛跑， 要在资金用尽前儘快建构产品、获取使用者和客户。  所以第一个问题为是否，与何时，挪出资源投入新员工的到职训练才合理? 很多新创公司要嘛不管,，不然就是延迟对这方面做任何投资。  他们仰赖新进工程师自己去问问题， 搞清楚要做哪些事情。

有时这是有用的，但有可能会发生一些特定案例、缺漏、错误定义的风险:

• 扫掉一些不错的人才，这些人也许给他们一点点指引就会很有生产力。 这对于已经花了很多精神与力气招募人才的公司来说真的是非常可惜。
• 无法在短时间内辨识出低产出或不良雇用的员工， 因没有足够的时机来评量他们的工作或你可能一直怀疑需要在他们变得有生产力前给予他们机会。
• 新进员工生产力的成长所需要的时间比应有的还长，因此少了预期的生产力。
  
• 新进员工有较多的压力与较少的幸福感， 尤其是从来没在新创公司待过的员工更觉如此。

当你有越多新进人员， 这些风险将越高， 尤其是如果你偏爱招募没有经验的候选人， 如大学毕业生到你公司做他们第一个全职工作的话。

当团队成长， 非正式的到职体验不会随着规模扩大。 不同的员工于不同时间为新进人员解说并没有一个标准，如此这些分散的说明很有可能漏掉掉应该包含的有用资讯。 一位工程师有可能搞不清楚关键抽象(key abstraction)，而这资讯对于工作其实很有帮助。  这有可能是因为他起初参与的项目都是周边非关紧要的功能， 从来没有机会去看核心程式的部分。 或者， 如果公司的期待目标没有被清楚地传达，一位新进人员有可能花太多时间去学习新的东西， 一个月内却毫无实际的产出。 当一家新创公司还小，东西相对比较少，容易辨识出重点。 当公司稍微大一些， 产品、程式基底(codebase)都比较多了， 需要关照的事物也增加， 对于新人来说， 在没有指引下， 将越来越难辨识出必须优先了解的课题。

到职流程是一个机会和新进人员沟通哪些是团队最重视的， 指引新进人员学习与行动的方向。 设计一个好的到职流程将提升到职后的工作效率。 而且， 一开始就投资时间建立一个好的到职流程将持续效应， 随着更多的人员僱用而加倍获益。

设计到职流程

我在Quora的那段期间领导新进工程师的到职计画开发， 负责定义工程方面师徒制(mentorship)的角色、组织与筹画到职讲习、协调製作教育训练资料、主持导师(mentor)训练工作坊。 从2011年的12月我开始这到职计画，那时Charlie和我发觉我们将有10位新任全职工程师， 以及夏天即将报到的实习生。  当时我们的团队约30人， 其中仅14位是工程师， 所以我们预知如果没有好的到职流程， 到时将非常溷乱。

起初成立Quora的到职计画，我很明白要让此流程比我曾经历过的平顺而且少些压力。  在决定要做哪些素材、讲习、辅导等事之前我必需先定义好一整组达到优质到职过程的目标。 设定好后然后去实现这些目标。 团队成员分享他们过去的到职经验中哪些是喜欢而哪些是不喜欢。 我也向外谘询其他公司的工程师(包含我前公司Ooyala的朋友， 他们那时也开始建立他们的到职计画)了解他们的到职经验也探索哪些做法会有效用。

到职计画的目标也许因不同新创公司而异。 以下将列出一些我认为新创公司新员工的到职过程应该达到的目标， 并告诉您针对每个目标我们在Quora做了哪些再造工程。

1. 加速提升新进员工生产力

新创公司大多急需人力资源，投入时间帮助新员工加速提升产能对于那些设计到职流程的人来说就是一个增加团队生产力的短期打击。  一位新进员工越早提升自己的生产力， 就可越快贡献有用的产出。 长远来看这将让新创公司变得更好， 因为整体将完成更多， 对于新进员工来说也很有好处， 因为他/她也想证明自己对团队是有生产力的。

在Quora我们用一种方法强调加速提升新进员工生产力的重要性， 我们指派一位导师(mentor)给每位新进工程师， 对新进人员的成败负责。  我们建立彼此都了解的底线， 事实上， 强烈地鼓励导师和其他团队的伙伴从例行工作抽出时间训练新进员工。  如此我们预期导师为了这加速提高生产力的训练，在新进员工刚进来的头几个礼拜会失去25%或更多自己的生产力。  导师要做的工作范围包含审查徒弟一开始写好的程式码， 挑选出日益广泛和难度的项目， 概述徒弟应该赶上的技术以让自己变得更有效率， 结对编程(pair programming)以便指导技巧与诀窍， 教导优先顺序的策略， 或帮助找出与不同团队成员工作的最好方法。

我在Quora时辅导不少人，而且我在第一天就跟我的徒弟明白点出让他们快速有生产力的重要程度比完成我自己的工作还高。  这帮助我们之间有共同的目标-加速提升他们的生产力， 且让他们能毫不犹豫地跟我问问题。

2. 传递新创公司的文化与价值观

每一间新创公司的文化都不一样。 也许新员工可以由招募、行销资料以及和团队成员的面试会议略知一二， 但到职流程将是确保新进员工瞭解团队共识的价值观很棒的机会。 这价值观有可能是着重将事情完成的效能、资讯导向、团队合作、高品质的产品与服务， 或是其他。  能有效在到职流程中传达价值观的先决条件当然是新创公司内部对于自己的文化、使命和价值观已清楚的定义并达成共识。

例如在Quora， 产品本身很自然地营造学习的文化。 但事实上造成新加入者太过趋于学习， 尤其那些社会新鲜人， 以致不够快速进入状况完成任务。 为了确保新进工程师了解公司的步伐， 我们试着让每位新进工程师在第一天透过推一个交付(push a commit)将自己加入团队的页面(译注: 作者并没有交代push a commit的内容)， 并于第一週内要解决一个Bug并部署、完成一个小的新功能或做一个新的实验。

这意味着要让第一天的活动够简化，如此新进工程师能在第一天就有足够的时间建置他/她的开发环境、做个简单的程式码变更、跑测试与交付变更。  同时也意味着导师(mentor)必须事先准备新进工程师可在到职一星期内完成或解决的Bug、功能或实验。  由于我们自己的项目进度预估和新进工程师真实花多久时间赶上进度很容易有不少的落差， 我一般提议导师挑选他/她认为自己有办法于一天内完成的初阶项目， 如果项目完成时间无法如他的预期， 还是有很高的机率在一週内完成。

3. 让新进员工广泛接触成功所需的基础

随着新创公司成长，产品、团队与程式码基底也跟着成长， 也就是说新进工程师需要更费力地扫描出须知事物的资讯面积越来越大了。  在我的职业生涯中， 我也注意到那些对基础工具与抽象(abstractions)清楚的工程师–不管是他们比较善于釐清应该了解的工作重点或曾有导师或初阶专案鼓舞他们学到重点概念，经过数月后往往比其他人更有效率， 因为他们知道有哪些资源可用以及应用时机。 好的到职流程的重点在于保证每位新进工程师的起步一致且给予他们坚实的基础， 如此每位新进工程师在初阶项目或是导师指定的功课上所学到的东西不会有太大的差距。

在Quora我们运用两种方法完成这样的工程:

• 建置一系列新进工程师于到职两週或三週内需参加的讲习会~约10 个。  这些讲习将介绍程式基底(codebase)、解释git上的资料模型、告知所有的测试期望(testing expectations)、展示解bug (debugging) 与效能分析 (profiling) 工具， 并包含各种其他我们认为新进工程师应该于到职两或三週内了解的重要事物。  对于最重要的事物， 如程式基底的介绍， 我会为每一次进来的新近工程师作安排， 即使那次只有一位新进人员， 其他较不重要者， 就可能等比较多人进来后一起讲习。
• 编写codelabs说明公司内产品的抽象层(abstractions)和辅助工具(tools)。 Codelabs 是我从Google学来的概念。 一个codelab为一份文件说明为何一个核心抽象层(abstractions)如何被设计出来， 展示要如何使用它， 演练程式基底(codebase)相关的部分， 并提供一套练习以确定学徒是否了解。 我先花三天的时间写出第一份好的codelab做为后续发展的模型， 然后徵召团队伙伴写其他的codelabs， 这些codelab是每位工程师都应该知道与使用的核心抽象层(core abstractions)与辅助工具(tools)。

这些投资主要是参与的前期、一次性建立能重复使用资源的成本， 后续只需要将过时的资料更新， 以及对新进工程师举办实际的讲习。

4. 运用社交让新进人员融入团队

比起其他地方，在新创公司你很有可能大多时间都和工作伙伴在一起。  这有助于鼓励新进工程师融入团队， 尤其是那些害羞比较安静的人。

在早期的Quora， 我们主要仰赖导师(mentor)带着新人介绍给工作伙伴。  后来有的团队伙伴开始组织小组午餐， 让新进工程师更有机会认识团队其他伙伴。  此外，将新进人员集合分批于同一天到职， 也可帮助他们更有同志情感。

以上这些目标只是一些范例。 让你思考有可能想在你的新创公司设计什麽样的到职流程。  当公司成长， 到职训练所想达到的目标也将随着改变。  譬如， 根据和Facebook(同意! 如果你说她已经不是新创公司）负责集训(Bootcamp)到职流程的工程师透露，  “让新进工程师选择他们想要加入的团队"很重要。  在组织还没有真正做好工程团队的定义前，这不会是到职训练的目标。

很重要的是我们要明白-建立到职流程，可以也应该是个互动的过程。   有可能你开始只是简单地写一份文件， 说明如何建立开发环境以便让新进工程师在第一天就可以做程式码的修改。  晚点你有可能发现并非所有的起始项目都能有同样的加速提升新人生产力的效果， 需要更进一步给予清楚的指导原则， 说明如何挑出好的起始项目。  也许你注意到你一次又一次地演练同样的程式码基底(codebase)或同样的架构， 那麽是否要为这主题准备个讲习， 会更加有效率和效果呢?

每当你在设计到职流程时， 就想想你自身的经验并询问其他团队或公司的人看看哪些有用、可以如何改善。  想想看新进工程师有可能在哪裡遇到困难， 你可给予什麽帮助让他们很快地瞭解状况赶上进度。  想想哪些重要的概念、工具与价值观你真希望在刚进公司的时候就知道了。  只要有一些想法， 把最有价值的实现， 然后问问新进工程师和他们的导师伙伴， 看看这样的改变是否有帮助。  一再重复这个流程， 希望这样的到职计画不会再给你的新进人员经历和我在Ooyala一样的紧张经验。