【猎云网（微信号：ilieyun
）】11月25日报道 （编译：堆堆）
上周，我们采访了LendingHome的首席技术官Adil Ajmal，这是一家员工人数达到300人、变革贷款行业的出色创企。在采访中，他分享了自己是如何为团队挑选最优秀的工程师的。
在建立和管理实力雄厚工程团队的问题上，Ajmal给出了很多高明的建议，这着实让我们感到震惊。Ajmal的经历可以说是非常传奇。他是我们认识的人中唯一一位在7家公司成功将小型工程团队打造成大型团队的人。他在TenMarks任职首席技术官和工程部高级副总裁一职，后来公司被亚马逊收购了。他还在Posterous（后被Twitter收购）以及Homestead（后加入Intuit）等公司任职过。如今，他任职于LendingHome。除工程以外，他还负责产品、设计、数据科学。
为了便于更多创业者从Ajmal的经验中加以学习，我们邀请他参加了“问我任何事”（AMA）这种新型问答方式。他给出的建议高质且明确，因此我们想要和更多在创业的人进行分享。我们列出了Ajmal在AMA中回答的问题以及他对于12个难题的回复——这12个问题是我们常年听很多创始人和技术型领导者提到的。
1.如何衡量工程师的绩效？
2.工程团队的角色和责任是什么？
3.如何确定产品优先级的顺序？
4.何时将设计融入开发？
5.关于工程团队组织架构的常见错误观念有哪些？
6.工程师面试流程？
7.何时要招募一个产品高级副总裁？
8.如何管理技术债务？
9.什么值得全部重写？
10.如何和非技术型部门共事？
11.如何在面试中采用编程测试？
12.如何招募到更有经验的工程师？
1.你如何去衡量软件工程师个人的绩效表现？又该如何从团队层面去衡量绩效？
虽然工程师的职责与设计、营销、产品等职能部门里同事的工作大相径庭，但是绩效管理的基本原理却是相同的。不管职能部门是什么，团队绩效表现的衡量原理也是一样的。尽管管理绩效有很多框架方式，但在我看来，这归根到底就是两点：
1）他/她有无完成他们答应要做的事情或是负责人期待他们要完成的事情？（目标）
2）他们会怎样去做这件事？（方式）
任何绩效评估的关键前提在于，双方对于该员工表现的期待值应当达成一致看法。这既包括显性层面，也包括隐性层面。显性层面包括基于某一些特定要求，要在一个特定的时间内上线项目。而隐性层面则包括不管项目如何，该员工在其工作角色中预期要做到什么。
举个例子，对于工程师来说，这可能是要求他写出高质量、能够通过测试的代码。当你进一步深入了解项目的细节内容时，你就无需再去提醒他们代码必须要保证质量。这一部分就是隐性层面的期待值。当有人开始着手工作、岗位发生变动或是进行绩效检查时，你应当就显性和隐性期待值，向员工传达清楚这些内容，双方达成一致看法。
期待值的部分，合理是关键。举个例子，如果你期待经验相差较大的人完成同样的工作量，那这就是不合理的。你可以期待一个有经验的工程师负责好一个大项目、独立设计以及建立一个复杂、可拓展的系统等等。与此同时，你不应当期待一个初级工程师去负责同类型大规模或复杂的项目。
因此，如果一个有经验的工程师没能很好地完成一个大型复杂项目，那么他们也许是表现不佳。另一方面，如果一个初级工程师完成了高级工程师预期要完成的任务，那么初级工程师的表现就属于超出预期。我发现很多人都会忘记这一点，这就错失了帮助员工成长的机会。当你和员工对工作期待值达成一致看法时，就“对象”和“方式”来衡量绩效就变得很容易了。
但如果他们正在开发一个功能，那么“对象”就应当包括以下这些内容：
1）这一功能在产品中是否运行顺利？
2）该功能的开发是抱着投机的目的吗？
3）它是否按时上线了？
4）它的规模是否合适？
“方式”的问题应当包括：
1）这名员工是否能和团队其他成员合作密切？
2）他们是否采取捷径、设计了一个无法维护的系统？
3）他们是否按照正确的步骤、开发可扩展且长久的产品？
4）他们能够一直打败别人的系统吗？
5）他们是否会在完成自己工作的同时教导其他人？
6）他们一直以来有没有学到点新知识？
7）他们是否是以一种新颖的方式创造性地解决了问题？
8）他们是否强行使用之前的方案来解决一个新的但却性质不同的问题？
很多评估绩效的经理关注的内容仅仅是“对象”——其实“方式”也同样重要。如果一位工程师上线的产品很出色，但他却是浪费了很多人力或资源才做到这一点的话，那么我是不会给他很高的评价（从个人层面来说）。
你可以用类似的方式衡量一个团队的绩效。尤其是，你可以询问这些问题：
1）他们是否完成了预期要实现的目标？
2）他们做事的方式是否会让你想和他们在类似的任务上继续合作？
2.工程团队的角色和责任是什么？你的团队拥有指定的软件架构师吗？技术负责人呢？
坦白说，我对于在团队中设置一个指定架构师的角色或是一个明确的架构师头衔并不感兴趣。我相信，系统架构的设计是所有打造以及维护这个系统的工程师的责任，这并非是某一个人的责任或一个团队的责任（后者指的是那些只会告诉别人去做什么、但自己根本不参与系统构建的人）。
我知道这句话也许会冒犯一些我的架构师朋友。我在大公司任职的经历让我了解了架构师问题的两个极端。举个例子，Intuit拥有一个非常强大的架构师社区，公司还为架构师制定了成熟的职业生涯规划，我也认识一些很厉害的架构师——其中一位是公司的首席架构师。另一方面，亚马逊则完全没有设置架构师的岗位。作为工程师，你也许会选择集成电路或工程管理发展路线，但是不管是哪个方向，你都要负责设计大型复杂的系统。
我建立或管理的每一个团队都选择的是后者。但请不要将其理解为是什么委员会式的架构——我个人是抵制这种的。有人需要担起领导架构的责任，但是我希望这个人能够是工程团队里可以做出实际编程贡献的人。
关于技术负责人：“技术负责人”应当是一个人所具备的功能或肩负的责任，而不是特定的职位级别。
对我来说，这就意味着在技术决策以及团队成员协调工作的问题上，技术负责人需要领导项目里其他的工程师。
我不认为你必须到达某一个层级才能成为项目的技术负责人。举个例子，就算是第一年工作的工程师也可以领导一个项目，只要他们有能力就行。我的团队里也有一些非常有经验的工程师，他们都是思想领袖或是一些问题上的专家，但他们不愿意领导别人。所以，尽管资历高的人更可能会成为技术负责人，但这本质上并不是一种职务级别。
在LendingHome，我们明确了公司内不同的职务级别以及每个级别对应的角色和责任。我们多方努力，试图保证公司与大行业保持一致，这样其他优秀的科技公司也能轻松理解我们的职务级别和头衔。我们的工程团队也分为两种成长途径：一种是集成电路，一种是工程管理。在公司里，你不必成为经理才能获得晋升。
我们的工程师层级是工程师、高级工程师、主管工程师、首席工程师、高级首席工程师、杰出工程师以及高级杰出工程师。从主管工程师级别往后，这就相当于是经理、高级经理、总监、副总裁以及高级副总裁。你也许是上述职务层级中任何一个级别，这样你就可以担任架构负责人或技术负责人的角色。事实上，我期待的是技术负责人能够负责项目的架构。就组织结构来说——这不同于职务级别以及角色——我们的工程和产品团队将被细分为三个高级别聚焦领域：获取和消费者体验、起源平台、投资者管理。
上述三个领域都是由大团队组成，每个领域都有自己的子团队。我们之前也尝试过不同的变体，比如说基于公司所处的不同发展阶段，依据业务线或是完全按照大方案进行安排等。我认为我们现有的组织结构是非常高效的，短期时间内它也不会变成公司发展的阻碍。这实际上意味着，我根本不知道什么完美的组织结构。不管你如何定义它，这些结构都会存在各自的优缺点。
当你在规划组织结构时，你需要明确自己要解决的问题以及如何应对一些不可避免的负面因素。
3. 你是如何确定产品优先级的顺序的？
每年，我们只会设定几个关键的公司目标。这几个大目标之下是每个业务线为自己设定的为期六个月的目标。之后，我们会按照这些目标创建每季度的路线规划图。这些路线图会推动我们平时的做事进程。在这种方式下，所有事情都是基于公司一整年需要完成的目标细分出来的。
创建我们的路线规划图通常开始于产品经理列出目标优先级，这是他们想和跨职能合作伙伴一同实现的目标。我们将这一切同业务线整合在一起，按序创建出下一个季度我们想要完成的目标。这通常还会包括上一个季度就一直在做的事情。
一旦我们对优先级顺序达成一致意见，产品经理就会和工程部进行合作，对于优先级最高的项目进行“T恤尺寸”的估计（即小、中等、大或超大码的估计）。工程部也会为每个季度提供清晰的生产能力数据。利用这两样工具，团队就可以具体讨论平衡利弊的有效方法并且为本季度设定最终的产品优先级。这并非是一个项目计划，而是要列出我们想要实现的目标。
我们会从这份列表中挑选目标来完成，整个季度都会持续这样做。我们会做好尽职调查，这样我们就不会在季度中期过多修改这份列表。但如果必须要进行调整的话，那么我们就会迫使自己在列表中进行权衡，而不是仅仅往里面添加更多的项目。这一点说起来容易做起来难，但这却是非常重要的一环。记住，交易从来都不是公平的。
4. 如何将设计完美融入到产品开发流程呢？如何在不浪费时间的情况下将设计尽早融入到项目里呢？
理想状态下，设计团队里应当安排设计负责人来负责系统和业务的不同部分。这些负责人应当在早期就参与到项目中，这样他们才能够从团队中按需调动资源。
过去我们面临的挑战是设计团队里没有足够的人可以担任领导人/协调人的角色。我们的目标是建立起这样的组织结构，这样设计团队才能发展。设计应当尽早融入项目——但是这一时间取决于项目的本质。举个例子，我们的部分工程项目如果是专注于后端服务和基础设施的话，我们在任何阶段都不会想将设计融入其中。另一方面，如果项目是面向顾客的话——尤其是关系到品牌、营销、应用流程等，我们就应在项目开始之初就融入设计。通常，设计团队里会有很多人在早期就参与到这类型的项目中。
如果你将参与人数减小到最低，那你就不用担心会浪费设计团队的时间了。
最糟糕的情况是，设计团队的人员不会很认真得对待项目的一些重要信息。有一点必须要指出，我从不认为设计单单指的就是视觉方面，也不认为在其他事情都弄明白之后才需要将设计融入项目。在我看来，设计是整体性的，它包含很多方面：交互、研究、视觉等。不浪费设计团队时间的最好方式就是要在合适的阶段让合适的人参与进来，而不是让所有人参与到每一个阶段中。举个例子，当需求还不确定的时候，我就不会想让视觉设计团队参与其中。但是我会尽可能早得将交互设计纳入其中，因为他们对早期确定需求和解决方案会产生很大影响。
5.建立工程团队有哪些常见的错误认知？
我确信有很多错误的认知，但以下三种是我脑海中立即浮现出来的：
1）招募最聪明的人，将他们聚集在一起，你就能组建一支高绩效的团队。
你应当致力于招募那些比你聪明的人。但是仅仅将一群聪明的人聚集在一起还不足以组建成一支高绩效的团队。组建这种团队需要的是一群聪慧的人真心诚意想要和团队里其他人合作并且比在意自身还要多得关心团队能否取得成功。
后者要比找到聪慧的人困难得多，但这正是团队成功的关键。因此，你可以这么说，聪慧仅仅只是一种筹码。就第二部分来说，你可以在面试中采用STAR方法（情境、人物、行动和结果）——这种方法的前提在于，过去的行为是最能准确预测未来行为的工具。如果有人之前就不适合团队协作或是有自私的表现，那么他/她很有可能还会出现这种情况。
2）招募所有和团队相像的人。
我曾经多次希望自己可以克隆出团队里一些出色的成员。不过幸好还不存在这样的可能。
如果我仅仅是克隆出团队里最出色的人才，那么最终团队里大家的思维就不会存在任何不同，也就不会迸发出任何创意。经验和思维的差异性才会催生新的、有创造性的解决方案。从长远角度来说，一个有差异性的团队才会成为一个出色且强大的团队。
3）将一群聪慧的人聚集在一起，他们最终会解决任何问题。
每次说这句话我都心怀愧疚。在一定程度上，这句话其实是很正确的。聪慧的人喜欢解决具有挑战性的问题，他们通常可以想出一个很好的解决方案。但这不是团队强大的原因。关键在于，你召集的人不仅要聪明，还要对团队试图解决的问题怀揣热忱。没有真正的兴趣和激情作为支撑，你也许能在早期阶段完成一些工作。但从长远角度来说，员工最终会变得闲散，团队效率也很低。
6. 工程部面试流程是什么？为什么这些步骤很重要？
在LendingHome，我们的流程简单明了。第一步，招聘人员会有选择性得决定是否要对求职者进行电话面试。这取决于我们招募的人是否是一个被动型求职者或者说该求职者是否是积极申请的。
面试流程从一个手机屏幕开始，这有两层目的：
1）向求职者介绍关于公司和岗位的相关信息。
2）评估求职者解决问题以及编程的能力。（我们会让他们在CoderPad或者Collabedit上进行测试、写出解决方案。）
通过手机屏幕测试的求职者会被邀请参加最终的现场面试。面试持续一整天时间，面试官有6位——三位工程师、两个工程经理（我们会从总监、经理、副总裁以及首席技术官中挑选出两位）以及一位产品经理（或是从设计、营销等跨职能部门找到的一个合作伙伴）。我总是希望有一个非工程师角色的人加入工程师招聘小组中，从而提供一个与众不同的视角，这也可以让求职者有机会见见未来将会一同工作的、来自其他部门的人。
现场面试中，我们会尝试考察工作能力、领导力以及行为技巧。技术方面包括架构、系统设计、解决问题以及编程能力。我非常热衷于使用STAR方法来评估非技术性的技能。我是这么考虑的，过去的行为是最能准确预测未来行为的工具。
小组内每一位面试官都会在求职者追踪系统Greenhouse里录入他们详细的反馈。在输入自己的意见之前，他们看不到其他人的反馈情况。之后，每位求职者会在现场面试当天被提问30分钟时间，我们会决定是否要为其发放工作offer。
如果我们在询问过程中决定提前接受求职者，那么我们很快就会为其发放offer。有些时候，offer的发放会取决于背景调查，但这多是为高级岗位准备的。
7. 何时应雇佣产品高级副总裁？你应当关注哪方面？
这一问题主要取决于公司所处的发展阶段以及你想通过引进一位产品高级副总裁来解决什么问题。公司规模以及技术部门不同，那么高级副总裁的角色也会包含不同的内容：
1）在一个较大的部门内，高级副总裁只需要负责某一个职能部门或业务线的产品。
2）在较小的公司或部门内，产品高级副总裁就需要引领整个公司的愿景和运营——未来成为首席产品官。
回答这个问题确实依赖于这些细节，但如果有公司想要通过引进第一位产品高级副总裁，从而让其管理公司所有的产品部门，那么我可以就这个问题提供另一种答案。
很早之前，首席执行官通常会担任公司首位产品经理的职责。之后，随着公司发展壮大，其他人也偶尔会肩负起产品经理的职责。工程团队通常是第一个发展起来的团队，它和首席执行官联系密切。如果公司不存在技术型联合创始人的话，那么公司第一位要雇佣的高管就是工程高级副总裁。之后，首席执行官会引进一位全职产品经理来完成战术方面的工作，比如说设定规格、协调工程师等等——这仍然要基于首席执行官的产品愿景。这并不是一个管理者的角色。有一些产品经理无法很好地融入团队，团队依旧要向首席执行官汇报工作。
此时，首席执行官应当感觉到公司内还有其他地方需要他们去负责管理。这时候，他们将意识到自己需要一个产品高级副总裁。
通常，许多首席执行官是被迫做出这样的决定，因为他们通常认为自己会永远负责管理产品。
如果你是一位需要负责管理产品的首席执行官，你应当问问自己这样一个关键的问题：未来的产品高级副总裁在执行首席执行官命令的同时，是否只需要负责运营产品部门并且管理产品经理呢？还是说他们也可以有自己的产品愿景、设定产品开发方向呢？
这实际上是一个非常困难的问题，答案将会决定你需要为这个岗位引进何种类型的人才。这不应当是你单方面的决策，从董事会、投资者、团队信任的成员那里征求意见。你可以期待他们来明确产品高级副总裁的职责，从而使其最大程度有益于公司目标的实现。
8. 管理技术债务，你通常使用的是什么框架？
这方面是我们仍然要改进的地方。有很长一段时间，我们发展速度非常快，资源受限，以至于累积了大量技术债务。自此，我们重构了系统内会受到以下属性影响的部分：
1）系统扩大规模随之带来的问题数量
2）维护系统的复杂性
3）将这一系统拆分为独立、更易管理的服务或系统的需求
4）由于相互之间太过依赖，以至于无法快速发展某一部分系统
5）现有系统无法满足日趋复杂的业务
不过，之后也带来了一系列的问题：
1）你该如何平衡业务发展带来的新功能开发需求与不会立即带来商业利益的现有系统重构需求？
2）你会给这两者分别投资多少比例的资源？
3）你会在开发时逐渐优化系统还是会重写代码、然后全部替换掉旧系统？
一段时间之后，我们变得善于评估这些问题，但还没有一个一直有效的方式。举个例子，我们手头上目前就有一个大型的重写项目，我想让团队开发一个新系统来替换掉之前的——因为现有系统的逐步优化会花费太长时间、令人痛苦不已。与此同时，我们手头上还有一些其他技术性的优化项目，它们可以改进现有的系统。
9. 你是如何决定有些事情太过费力、还不如重写的呢？
我要重申一遍，这没有什么通用的办法，但是通过评估以下两个因素，这可以帮助你做出决定：
1）逐渐做一件事情的成本VS重新开发的成本。我通常会将这里的成本理解为时间和辛苦程度，你也可以添加其他的因素。
2） 这项业务能够担负起你在一段时间内停止其他新项目开发带来的影响吗？
对大型重写项目来说，当你在开发一个新的系统时，你同时去给旧的系统添加新功能，后者是毫无意义的——你需要停止或者减缓新功能开发的进程。否则，这不仅会花费两倍的资源，还会不断延迟你迁移到新系统的步伐。目前，你的业务能够承担这一成本吗？
不要让非技术型的人来决定第二个因素，因为他们的认知非常有限，他们是无法做出一个合理的决策的。而你作为工程负责人或团队成员，必须要确保业务的合作伙伴充分了解其中的成本和利益平衡。
举个例子，如果你只是要求他们在开发新功能或重写项目之间进行抉择，那么他们的默认答案就是进行新功能开发，我也不会为此指责他们。毕竟在他们看来，这个答案是显而易见的。
但是，如果你能真正让他们了解不重写项目会带来的风险和成本损耗时——即系统会在未来几个月时间内出现大规模崩溃、安全性会受到严重影响、可能导致公司关门大吉、工程师不愿再留下来因为他们憎恨这个系统、你无法快速为新员工进行入职介绍、功能开发的速度开始减慢、产品支持需求不断增加等等——他们在了解更多情况之后才会做出有依据的决策。
10. 你的技术部门是如何与公司内其他运营部门合作的？
全公司内，我们让技术部门和其他不同的职能部门达成了密切的合作关系，包括运营部门，比如说贷款运营、销售、资本市场等等。我们首先是安排了一个产品经理，他/她会负责同每个部门进行合作并且针对该职能部门设定产品路线规划图。
举个例子，我们会单独安排产品经理专注于顾客获取、贷款管理（这个内容细分下还有很多子职能部门，会由多个产品经理负责）、服务、投资管理等等。这些产品经理会和团队密切合作、跟着他们学习技能、认同并且接受他们的需求和痛点，然后利用这一切来明确合适的产品功能和优先级顺序。
我们每周还会和公司内不同职能部门进行会面，参会人包括产品经理、工程经理和总监、跨职能部门的合作伙伴，有时候还包括业务线的总经理。会议是要了解产品开发的最新情况、刚上线的内容等等。但是其主要目的还是要明确该职能部门的需求、确定解决方案和项目的优先级顺序。
一些情况下，当我们推出大量内部工具时，产品团队就会为公司的运营团队提供培训。我们还会采用一个正式的流程来接收运营人员的运行支持需求。如果最终发现问题是技术方面的，那么负责此问题的工程师就会和有疑问的运营团队成员直接联系。
当我们在开发新功能时，产品经理和工程师正与运营团队成员合作确定合适的解决方案，这时也会出现相同的情况。对于小型团队来说，我们会提供Slack渠道让其和工程师、产品经理以及团队成员进行沟通。这种渠道在一段时间内是有效的，但是当你发展成为大规模团队时，Slack协作工具是无法扩展的（比如说我们的贷款运营和销售团队）。最终，我们需要推出一个更加正式的沟通流程。
尽管说了这么多，但实际上技术团队和运营团队之间的合作关系并非一直是这样和和美美的，有些时候情况也会基于不同的非技术型团队发生改变。这很大程度上取决于非技术型团队是否会认为技术团队是为他们服务的部门——他们可以直接下达指令，抑或是他们是否认为自己是技术团队的合作伙伴，双方可以共同解决问题。我们的目标通常是后者，现阶段我们已经很接近这种状态了。人们曾尝试过前者，结果通常不太顺利，且成本花费极高。
11. 你有没有在面试过程中采用编程测试？如果有，你是采用什么方式？又是为何如此呢？
我们确实会在面试中采用编程测试。我们是语言不可知论者，求职者可以按照自己选择的编程语言编写代码。我们试图评估的是他们能否：
1）写出运行顺利的代码
2）考虑到极端情况
3）正确解决手头上的问题
4）编写出色的代码测试
5）在代码出错时接受反馈意见
编程测试本身不会非常复杂。在此之前，我们会让其解决一个问题，从而用此来评判求职者能否高效解决问题。一旦他们通过了问题解决能力这一关，我们就会要求他们写出自己刚刚解决的问题的代码。
12. 就工程经理雇佣比自己经验更丰富的人这件事上，你能否分享一些建议呢？
理想情况下，你雇佣的所有人都应当至少在一个方面比你出色。在我看来，这句话同样适用于招募那些比你经验更丰富的人。关键你要弄明白你可以如何为他们带来更多价值、你又可以如何从他们的经验中受益？
一个好的开始意味着你需要坦诚相待、确定合适的期待值。了解这个人在什么地方会给团队带来价值以及他们从你的帮助中又能获得什么益处。举个例子，也许有一个比你出色很多的工程师，在设计和开发复杂系统方面他不需要你的任何帮助。但是他们也许不像你那么了解公司的业务、顾客、传统系统等。你可以帮助他们熟悉这方面内容来为其带来价值，这样他们就可以更好地完成自己的工作。与之类似，你可以帮助他们了解公司架构，从而让他们更快速地与其他团队达成合作。
除了接受工作后需要考虑到的因素，你在招聘过程中也还需要留意几点。当人们的需求和兴趣得到认可之后，他们就会被说服并且从中得到一定慰藉。
雇佣比自己经验更丰富的人，最神奇的一点其实在于你可以向他们学习。
对此别心怀芥蒂，在他们拓宽你知识面的时候记得表示感激。相信我，当你向他们进行学习时，你其实仍在为他们带来价值，所以别担心这一点。从我职业生涯早期开始，我一直负责领导团队。这么多年来，我时常需要雇佣一些比我经验更为丰富的人。我非常喜欢从他们身上学习到新知识，如果不是他们教会我那么多事，我可能现在也不会取得成功。
