[转]资深CTO:关于技术团队打造与管理的10问10答

 1、你如何衡量软件工程师我的的工做表现?如何衡量整个工程师团队的工做表现?面试

  主要从两方面:编程

  1. 这个员工作的工做是否是他赞成作的或者应该作的?(What)
  2. 他们是如何完成本身的工做的?(How)

  任何绩效管理的最重要的前提就是针对这我的的合理指望达成共识,这里既包括显性指望和隐性指望。显性指望是指,要求对方在知足特定要求的状况下在规定时间内完成一个特定项目的交付。隐性指望是指,无论他们作什么项目,你对他们的表现所拥有的期待。后端

  若是员工在负责开发一个功能,那么这里的“What”应该包括如下几个方面的内容:架构

  1. 这个功能在产品中是否表现良好?
  2. 这个功能是否是按照规范开发出来的?
  3. 这个功能有没有按时发布?
  4. 这个功能是否能知足往后规模化扩张的需求?

  这里的“How”应该包括如下几个方面:框架

  1. 他们是否与团队中的其余成员进行了很好地合做?
  2. 他们有没有由于走捷径而开发了一个很难维护的系统?
  3. 他们是否遵循了全部正确的步骤并开发了可扩展的耐用产品?
  4. 他们是否在工做过程当中破坏了其余人的系统?
  5. 他们在作本身的工做时有没有指导别人?
  6. 他们在这个过程当中是否学到了一些新的东西?
  7. 他们是否具备创新意识,并能以一种创新的方式解决问题?
  8. 他们是否强制将以前的解决方案应用于新的、彻底不一样的问题上?

  你可使用相似的方法来评估整个团队的表现。在评估团队的表现时,你能够问下面这两个问题:编程语言

  1. 这支团队是否交付了他们应该交付的工做成果?
  2. 你从此是否愿意再让他们从此以相同的工做方式完成相似的工做?

2、你的工程团队成员的角色和职责分工是怎样的?你有指定专门的软件架构师或技术主管吗?学习

  我首先须要说明的是,我不喜欢在团队中拥有指定的架构师角色或明确的架构师头衔。我认为,设计一个系统是全部工程师的责任,全部工程师都必须负责开发和维护这个系统,而不是让某一个我的或团队来专门负责并让他们在那光指挥别人作事而不本身亲自开发这个系统。测试

  我知道这么说可能会得罪不少架构师领域的朋友,可是我仍是要说。我以前在大公司里有过亲身体会。举个例子,Intuit 拥有一个很是强大的架构师团队,也拥有很是成熟的架构师职业发展通道,我知道这群人中有一些很是出色的人才,包括 Intuit 如今的首席架构师。然而,Amazon 是没有架构师这个职位头衔的,做为一个工程师,你能够走 IC 这个职业发展通道,或者技术管理的职业发展通道,无论你选择哪种,你都须要可以负责设计很是庞大和复杂的系统。ui

  我打造和运营的每一家公司和每个团队采用的都是第二种方式。固然,任什么时候候都须要有人来负责架构方面的责任,但我但愿这我的是工程团队的一名能本身亲自写代码的成员。编码

  如今再说说技术主管。在我看来,“技术主管”应该是人们所应承担的一个职责,而不该该是一个具体的职位等级。

  对于我本身而言,技术主管意味着须要在一个项目上领导其余工程师(而不是单纯的人员管理工做),既要在技术决策上发挥领导做用,也要在不一样成员之间的分工协做上发挥领导做用。

  我不认为必需要达到必定的职位级别才能成为一个项目的技术主管。例如,只要有能力,即便是一名只有一年工做经验的工程师也能够领导一个由一个或多个工程师/实习生参与的项目。个人团队中也有一些经验很是丰富的优秀工程师,他们是思想领袖和专业领域的专家,可是却不喜欢去领导其余人。所以,尽管技术主管中更多的是那些更资深的人员,但技术主管自己并非一个职位等级。

  在 LendingHome,咱们在公司内肯定了不一样的职位级别,并定义了每一个级别所要承担的角色和职责。在这方面,咱们一直努力与行业的一般作法保持一致,这样咱们公司的职位级别和头衔也能适用于其它优秀的科技公司。咱们公司提供了两条职业发展路径:一种是 IC 职业发展通道,另外一种是技术管理职业发展通道。这样你能够在不用作管理人员的状况下也能继续在公司获得成长和晋升。

  若是走技术路线,咱们公司的工程师等级分为工程师、资深工程师、高级工程师、首席工程师、高级首席工程师、杰出工程师、高级杰出工程师。在级别上,他们与经理、高级经理、总监、副总裁和高级副总裁是平行的。你在任何一个级别上均可以扮演一个首席架构师或技术主管的角色。实际上,我但愿每个技术主管都能负责他们手里项目的架构工做。

  3、你用来肯定产品优先级的流程是怎样的?

  每年,咱们在公司层面只设定少数几个关键目标。而后根据公司的宏观目标,每一个业务线为本身制定将来 6 个月的阶段性目标。而后,咱们再制定符合半年目标的季度目标路线图。这些路线图就是咱们按期冲刺的参照标准。就这样,公司全年的宏观目标被分解成一个个短时间的目标。

  制定路线图老是从每一个产品经理开始,产品经理负责制定一个须要与跨职能合做伙伴一块儿协做完成的优先任务清单。咱们将全部这些优先任务清单整合到一块儿,并建立一个咱们但愿在下个季度完成的总体优先任务清单。这个任务清单列表也包括咱们上个季度延续下来的任务。

  一旦咱们就这些优先任务清单达成一致以后,产品经理与工程技术部门合做,对各个项目作大概的评估。工程技术部门也须要提供一个本季度的明确的工做目标。利用这种方法,团队能够进行有效的权衡,并制定该季度最终的产品工做优先级清单。这不是一个项目计划,而是一个咱们想要完成的任务清单。

  咱们就从这个优先任务列表中选择任务分别进行冲刺,并在整个季度持续执行。咱们努力在这里作足前期调研工做,这样咱们就不须要在季度中途改变这个优先任务清单。可是,若是出现了须要修改的东西,那么咱们就强迫本身对优先任务列表中的任务进行权衡取舍,而不是直接在列表中添加更多的任务条目。这提及来容易作起来难,但倒是相当重要的。

  4、如何让设计师完美地适应产品开发流程?若是能在项目早期就让设计师参与其中、同时又不会浪费设计师的时间?

  在理想状态下,在公司业务的各项不一样的产品工做中都应该有设计主管或指定的设计人员参与其中。这个设计主管应该在项目早期阶段就参与其中,这样他们就能够在整个项目进行的过程当中从设计团队中为该项目获取所需的其它资源。

  咱们过去遇到的挑战是咱们的设计团队中没有足够多的人员来肩负起这样的角色。咱们的目标是创建起这样一种架构,让设计团队能尽早参与到全部项目中去。可是这也要看项目的性质,例如,咱们不但愿让设计师参与到一些专一于纯粹的后端服务和基础设施的项目中。可是另外一方面,对于那些直接面向客户的项目,尤为是那些与品牌、营销和应用流程直接相关的项目,咱们应该在项目刚开始的时候就让设计师参与其中,并且一般状况下都会有多个设计人员同时参与其中。

  若是你已经将项目人员数量降到了最低,你就不该该担忧浪费设计师的时间。

  这里须要着重强调的一点是,我不认为设计是纯粹的外观和视觉设计。若是是纯粹的外观和视觉设计,彻底能够等到项目后期阶段、在全部其它重要工做都完成以后再作设计方面的工做。对我而言,设计是一项很是宏观的工做,它涉及到几个方面的工做:交互、调研、视觉等等。要想不浪费设计师的时间,最好的方式就是在每个阶段让合适的人员加入进来,而不是在每个阶段让全部人都参与进来。例如,当需求尚未肯定的时候,我是不会让视觉设计师参与进来的。可是,我会尽早地让交互设计师参与进来,由于他们能够在早期定义需求和解决方案的时候发挥很大的做用。

  5、在打造工程技术团队的过程当中,有哪些常见的错误想法?

  常见的错误想法有不少,我这里主要强调如下三个常见的错误想法:

  一、招聘最聪明的人,把他们放在一块儿,你就能组建一支高效的团队。

  你应该始终努力招聘比你本身更聪明的人加入团队。可是,把一群聪明人放在一块儿不必定就能组成一支高效牛逼的团队。要想打造一支真正高效的团队,你须要一群真的愿意在一个团队中共事合做的聪明人,并且这些人须要关心团队的成功赛过本身的成功。

  解决后面这个问题比招到聪明人要困可贵多,而这也是决定你的团队可否成功的关键因素。所以光招聘一群聪明人是不够的。为了确保加入团队中的人都是具备团队合做意识的人,你能够在面试中使用 STAR 法则(Situation-情形、Task-任务、Action-行动、Result-结果),由于你能够经过根据应聘者过去的行为表现来预测他将来的表现。若是一个应聘者在以前的工做中并无表现出可以和团队成员很好协做的一面,或者没有表现出团队的利益和成功是高于我的的利益和成功的,这时,若是你招他进来,他在将来的工做中颇有可能会有相似的表现。

  二、只招聘那些与你本身或团队中其余人员很像的人员。

  我曾经很是但愿可以多克隆几个我团队中的一些很是出色的人员。幸运的是,对于我来讲这个选项是不存在的。

  由于,若是我真的克隆了不少团队中最出色的人,让团队中的全部人都差很少,这只会让团队丧失想法的多样性,最终丧失了全部的创新能力。经验和思想的多样性是激发新的、创造性的解决方案的源动力。从长远来看,一个多元化的团队将会变成一个更好、更强大的团队。

  三、将一群聪明人放在一块儿,他们就能解决任何问题。

  很抱歉又强调了一遍这个问题,可是在某种程度上,这确实是事实。聪明的人喜欢解决富有挑战性的问题,他们每每会可以想出一个很是不错的解决方案。但这并非打造一个强大团队的基础。其中的关键不只仅在于找到一群聪明的人,同时要确保这些人是真正有激情去解决你要解决的问题的。若是这些人对要作的工做缺少真正的兴趣和热情,你可能在早期阶段还能将工做完成的不错,可是从长远来看,你最终面对的将是一个个没法全身心投入工做的员工和一个表现不佳的团队。

  6、你面试工程师的流程步骤是怎样的?你为何认为这样的流程步骤很重要?

  咱们在 LendingHome 采用的工程师面试流程是很是直接的。第一步,面试官可能会对候选人人作一次电话面试。是否进行电话面试取决于:是咱们在积极挖一个比较被动的候选人,仍是候选人在积极地申请应聘咱们的岗位?若是是前面这种状况,咱们就不会进行电话面试了。若是是后面这种状况,咱们可能要作一轮电话面试。

  最开始要进行一轮电话面试筛选,主要有两个目的:

  1. 为候选人提供有关咱们公司和相应招聘岗位的相关信息。
  2. 评估候选人的解决问题能力和编码能力。

  经过电话面试的候选人将会被邀请参加最后的现场面试。现场面试有有几轮,要持续一成天时间,须要和 6 个面试官面试——3 个工程师、2 个技术经理(咱们会从总监、经理、VP、我本身和首席技术官中选取两我的)和 1 个产品经理。我但愿每个工程师招聘小组里都能有一个非工程师人员,这样咱们在招聘中就能得到一个彻底不一样的看待候选人的视角。

  在现场面试中,咱们要考察的内容包括专业能力、领导能力和行为技能。专业能力考察内容包括架构、系统设计、解决问题的能力和编码能力。我本身很是喜欢使用 STAR 法则来评估候选人的非技术方面的能力。

  每一位面试官在面试结束后都须要在面试追踪系统 Greenhouse 中填写对应聘者的详细评价和反馈。采用的是匿名评价的方式,这意味着你在评价以前是看不到其余面试官对应聘者的评价的。而后,咱们会在应聘者现场面试结束后的当天,对每一位候选人进行 30 分钟的总结评估,并决定是否给该候选人发 Offer。若是决定给 Offer,咱们就会尽快给候选人发出 Offer。

  7、何时招聘产品 VP 合适?招聘什么样的产品 VP 合适?

  这个问题主要看公司的发展阶段,以及你想经过招聘一个产品 VP 来解决什么样的问题。根据公司和技术团队规模的不一样,产品 VP 的职责也会有所不一样:

  1. 在一家大公司,产品 VP 可能只负责一个特定业务线的产品工做。
  2. 在一家小公司,产品 VP 可能会负责整个公司的产品工做。

  要问答上面这个问题,须要根据各个公司的不一样状况。对于那些想招聘一个产品 VP 来负责公司的全部产品工做的公司而言,下面是个人建议。在公司发展初期,CEO 本身一般是公司的首位产品经理。随着公司规模的发展壮大,其余一些人开始以兼职的形式分担部分产品工做。在创业公司,首先发展壮大的一般是工程师团队,CEO 会与工程师团队紧密协做。若是公司里没有一个技术联合创始人的话,这时公司首先招聘的一般是一个技术 VP。招到技术 VP 后,CEO 可能会招聘一个全职的产品经理来作一些产品战术方面的工做,好比制定产品说明书、与工程师协调等等,产品路线图和产品愿景仍是由 CEO 亲自把控。在这个过程当中可能会陆续加入几个产品经理,进而组成一个松散的产品团队,这个团队须要直接向 CEO 汇报。

  这时,CEO 应该认识到,除了产品工做外,本身身上还要肩负起不少其余职责,这时他们必须认识到必需要招聘一个产品 VP 了。一般状况下,不少 CEO 都是被迫作出这个决定的,由于他们一般认为本身是会一直负责产品方面的工做的。

  若是你是公司 CEO,面对须要招聘产品 VP 的状况时,你必须回答这样一个关键问题:新招聘的产品 VP 是只需负责执行 CEO 的指示、管理产品功能和产品经理团队?仍是须要让他来总体负责产品愿景的把控和产品路线图的制定工做?

  这是一个很难回答的问题,你对于这个问题的答案将决定须要招聘什么样的产品 VP。做为 CEO,你不该该本身独自作这个决策,你须要向你的董事会、投资者、团队中你信任的成员征求意见。让你们群策群力,看看到底是什么样的产品 VP 才是真正知足公司的总体发展须要的。

  8、你用来管理技术债的框架是什么?

  在很长一段时间里,公司增加得很是快,也开始受到不少资源方面限制,所以,咱们积累了大量的技术债务。因此咱们已经重构了系统的几个部分。是否要对系统进行重构,从而偿还技术债,主要要看如下几个方面:

  1. 在系统不断规模化扩展的过程当中出现的问题数量。
  2. 维护这个系统的复杂性。
  3. 须要将这个系统分解成独立的、更易于管理的服务或系统。
  4. 因为系统中存在太多的相互依赖的地方,所以没法快速开发系统中的某个部分。
  5. 现有系统没法知足日益增长的业务复杂性。

  然而你还须要问本身下面这几个问题:

  1. 如何平衡好“为了使业务向前发展而须要开发新的功能” 与 ”对可能不会马上带来明显效益的系统进行重构“这二者的关系?
  2. 你在这两个方面投入的资源占比分别是多少?
  3. 你是会在不影响系统正常工做的状况下对其进行按部就班地改进,仍是会重写系统并完全替换原有系统?

  随着时间的推移,咱们愈来愈擅长评估这些问题,但并非老是有一种可行的方法。举个例子,咱们如今正在重写一个项目,我想让团队并行地构建一个新系统去完全替换旧的系统。由于若是对原有的系统进行按部就班地改进,会花费太长时间,并且整个过程会让人感到很是痛苦。于此同时,咱们还有一些正在进行的技术改进项目,按部就班地改进一些现有的系统。

  9、你是否曾在面试过程当中使用过编码测试?若是有,具体是怎么测试的,为何使用这种方法?

  咱们确实在面试过程当中使用了编码测试。咱们对编程语言没有限制,候选人能够选择任何语言编写代码。咱们想要评估的是:

  1. 他们是否能写良好可行的代码?
  2. 他们是否能正确地解决手里的问题?
  3. 他们是否能进行良好的测试?
  4. 若是代码中有问题,他们是否会接受反馈?

  进行编码测试的时候,须要设置一个场景问题,这样咱们就能够评估应聘者是否能有效地解决问题。

  10、在一个技术经理招聘比他本身更有经验的人的时候,你有什么建议?

  理想状况下,你雇佣的每个人都应该在某些方面比你作得更好。这也适用于招聘比你经验更丰富的人。在招聘比你经验更丰富的人时,你须要考虑的主要问题是你如何为他们增长价值,以及你将如何从他们的经验中受益。

  了解这我的在哪方面可以为你带来价值,以及他能从你这里获得什么帮助。例如,他们多是在技术上比你更好的工程师,在设计和构建复杂系统时不须要你提供任何帮助。可是,他们可能没有你了解公司业务的相关背景、公司的客户等。你能够经过帮他们更快地熟悉全部这些东西来增长他们的价值,这样他们就能更好地完成工做。相似地,你也能够帮助他更好地了解公司的组织架构,从而更快地改善他们与其余团队的协做。

  全部这些点在面试过程当中就应该提到,而不是在他们接受了这份工做以后才告诉他们。当他们的这些需求和利益获得认可和知足时,说服他们加入就会更容易。

  雇佣比你更有经验的人的最重要的方面在于你能够从他们那里学到东西。必定要保持一个开放的心态,并对能从他们身上学到知识表示感谢。相信我,当你向他们学习的时候,你仍然会给他们增长价值,因此不要担忧这点。在我职业生涯中的不少时候,我老是不得不雇佣比我更有经验的人。我很是喜欢从他们那里学习,若是没有他们教给个人全部东西,就不会有今天的我。

相关文章
相关标签/搜索