从工程文化到团队增长

从工程文化到团队增长

沈思维

作者介绍:曾就读于密歇根大学和卡耐基梅隆大学,毕业后加入Google,任研发工程师。后加入Twitter,任高级研发经理。现为Lyft Engineering Director(技术总监),专注于平台开发,并在支付反欺诈等领域有丰富经验。

案例背景

2017年4月,美国打车应用Lyft完成总额6亿美元的新一轮融资,目前估值达到75亿美元,成为Uber最大的竞争对手。Lyft对外平台包括Lyft的企业版、礼宾服务等,用于与包括酒店业在内的其他行业进行合作对接,之前Lyft与滴滴及全球各大打车平台的深度整合和资源共享就是通过Lyft的对外平台来实现的。

既然是公共平台,除了与苹果Siri、Google Map、Facebook等平台对接以外,Lyft对外平台也开放给广大移动App的开发者。然而,打造Lyft对外平台,涉及公司多个职能部门,除了技术团队外,还覆盖了产品、设计、技术服务、运营、商务、销售、市场等。

对于这样的多职能部门合作、业务覆盖面广的大型项目,除了需要优质的研发人员之外,良好的团队文化也至关重要。营造良好的团队文化有两个直接的目的:(1)提高团队效率;(2)促进人才培养。

本文以上面这个案例为背景对团队的技术工程文化做深入的分析。

全栈型组织架构

近几年非常流行的一个词叫全栈(full stack),而形成健康的技术工程文化需要全栈型组织架构的支撑。全栈式的技术团队(如图1-1所示)与传统按职能分组的团队相比,其主要优点是减少了团队对于外部其他组的依赖。

0102.tif

图1-1 全栈式技术团队

全栈团队的优势

以前的技术型团队,前端和后端研发通常是分开的。在移动开发工程师还处于人才稀缺的年代,会写移动开发代码的工程师们常常集中在一起,承接支持公司各移动端的开发需求。

而现在的做法是让每个项目都有属于自己的负责前端、后端、服务器端和移动端的人员,最好还包括测试、数据分析等角色。在国内外一些规模较大的公司里,还出现了把技术、产品、设计、运营从组织架构上进行深度配套,组成一个事业部来统一管理的模式,这种模式保证了各角色相互之间的高度同步。同时也把全栈式团队的意义进一步推广到技术范畴之外。

但即便如此,还有类似商务、销售、市场、法务等职能部门很难分散在每个事业部或每个项目中,而这些职能在许多项目中是不可或缺的。所以组建全栈式团队并不是解决所有问题的万能药,构建全栈式的研发团队还要考虑如何让跨职能部门的合作达到无缝高效。

全栈团队的劣势

全栈式团队也有它的缺点,例如资源重复、技术实现缺乏统一性,以及一些对于个人发展的不利因素。

先说技术实现的统一性问题。传统地把研发团队按照技术职能分组,虽然容易造成瓶颈,但是因为技术背景相似的被划分在同组,在统一技术架构设计模式和代码规范方面往往却可以做得更好。

再就个人发展而言,全栈式团队中的某些技术人员经常会落单。一个10人的全栈研发团队,可能有一半都是做后端的,两三个写移动端的,而做前端负责测试的很可能就独自一人。没有了按职能划归的组,这些人就会成为“卫星工程师”(satellite engineer),而且可能会出现他们没有全职工作量的情况。所以说全栈式的组织架构虽然对提高团队的总体效率有利,但对“卫星工程师”的职业发展而言并不是最佳选择。

针对以上问题有两个常见的对策。

(1)鼓励部分研发人员变成全栈工程师,就是一个人既可以写后端也懂得移动端开发,比如有数学统计背景的研发工程师有时可以兼任数据分析师。

(2)针对每个技术领域形成跨团队的“虚拟组”(virtual team)。所有的移动端研发人员应该定期地聚到一起交流讨论,以确保各个团队之间在移动开发架构技术上的一致性和兼容性。

全栈团队的管理误区

团队有了全栈的技术能力之后,随之而来的一个问题是如何分配做产品功能和做基础建设的研发资源。初创公司经常犯的错误是把所有的研发资源都投入到做产品中以追求增长速度。这样做带来的短期效果可能很好,但随着产品的复杂化程度加深,最终基础平台的不健全会彻底阻碍新的产品功能的实现,业界把这种现象称为“技术债务”。

技术债就要尽早偿还,否则雪球会越滚越大,最终使得改写成本非常大。全栈式研发团队把很多基建的研发资源分散到了各个产品组,如果不适当地利用,不仅每个产品团队内部的技术架构会变得混乱,各个团队之间还会出现重复、不匹配甚至互相冲突的设计。一旦需要对接,所有人都将痛苦不堪。

所以笔者认为一个公司的技术团队内所有的组都搞全栈是不可取的,过度的全栈是一种“组织债务”(organizational debt)。为了杜绝产生技术债务,全栈式研发团队在任何阶段都应有组合型的工作规划即“投资组合法”(portfolio approach),以平衡产品研发的投入和对基础架构上的投资。从“投资组合法”这个名字不难看出这其实和资产投资的理念是相似的,都是短期和长线的组合。

不受限的研发团队

团队成员的发展:塑造T型人才

和硅谷内众多的互联网企业一样,Lyft用目标和关键结果(objective and key result,OKR)管理体系进行季度规划。这个体系在1954年被首次提出,随后英特尔把它付诸实践,Google在21世纪初真正地把它发扬光大并随后被许多的公司效仿。

OKR管理法可用于对公司、团队甚至个人每季度的工作进行规划、追踪和衡量。OKR框架中的目标通常是长期性的,但对同样的目标每季度会有新的需要达到的关键结果。每个团队在季度初做出规划,并在季度末的时候针对每个关键结果进行评分,所以这些关键结果都必须是可衡量的。

在我们做Lyft外部平台的时候,旗下所有团队也都各自制订OKR,并且连续多个季度近乎完美地达到了预期的结果。从工程到产品、到销售、再到商务,每个部门貌似都交出了无可挑剔的答卷,然而当我们回过头看最核心的数据,比如月活跃企业版打车单量的增长曲线并不令人满意,不像OKR打分那么光鲜。

于是我们做了总结,同时也向企业版客户征求反馈,归根结底发现增长不给力的原因十分简单。就是企业版的某些功能太复杂、流程太冗长,需要企业客户进行大量的数据及账户迁移工作,客户不是懒得弄就是弄错。另外一些潜在合作公司有些独特的功能需求,但是发现我们的产品不支持。遇到这些情况,很多公司往往认为还是使用传统的出租车或专车公司来得有保障。

这一现象暴露了两个问题:一是我们明明在开发之前就已经了解了所有的产品需求,但是为了保证在预计的时间内推出,团队不得不放弃部分功能;二是既然产品的用户体验不好,为什么我们OKR的打分都如此之高呢?

这里先讨论一下产品开发过程中因为时间压力而减去部分功能的问题。这样的现象在科技行业内司空见惯,比如每次人们为新一代iPhone的神奇功能惊叹时,背后不为人知的是苹果有更多更厉害的功能没有做完,也就是说因为他们程序员的拖沓导致了购买者可能在一年之后需要再花几千块钱去买新的机型。

遇到这些情况,工程师往往要让产品经理负责,因为很多时候为了更快地推出所谓的MVP产品(minimal viable product,也就是最简单化的可以推出市场的产品雏形),产品组会拿主意砍去他们认为不必要的东西。而排除的功能是不是客户接纳追捧一款产品的关键,是需要进行可用性研究和A/B测试的。

但这时候技术团队又会说:A/B测试没时间做,因为界面设计太慢了。设计组拖了很久,因为他们有很多优先级更高的项目要做。与其说这是技术团队在推卸责任,倒不妨更客观地把这些问题看成是部门之间合作的必然产物。如果想治标,那就让某个产品经理或是设计师改进,或者是给企业版和外部平台提供更多的资源。

但管理人员应该想的是如何从根本上杜绝类似情况的发生。一个高速发展的公司在面对巨大的市场竞争的时候,资源短缺、时间紧迫都是常态。在任意时刻,如果拥有完全充足的资源,可能就意味着资源浪费。所以当我们接受了资源有限这个事实后,开始思考怎样从技术团队着手,依靠优化工程师文化来提高团队效率,寻找让工程师可控的解决方案,即塑造T型人才。

让开发人员直接对产品负责

首先来看关于“产品决定”(product decision)的谬误。上面提到了技术人员在得知企业版没能达到用户期望时的第一反应是“这是因为产品经理做的决定”。这就意味着技术人员把产品经理视为负责人,而他自己的工作只不过是把产品经理决定的功能实现。

恰好相反,团队需要一种文化:工程师对产品有强烈的主人翁意识,与此同时他们也应被赋予自主权去履行主人翁的职责。我们倡导工程师应对其开发软件的质量和用户接受度全权负责。如果产品的用户体验不好,无论代码多干净多漂亮,开发者依然需要为此承担责任。

当我们刚开始推行这样的理念时,组里的不少工程师都觉得不合理。他们的观点是:既然工程师不是做产品的,凭什么能在对产品的把控上做得比产品经理更好,为什么要扛起跟产品经理一样的责任呢?我们的解释是:其实没有人期待任何一个程序员或产品经理拍脑袋就能想出用户最需要、最喜欢的产品体验到底是什么,而是需要工程师们去尝试更新迭代,去不断摸索。

在寻找到符合用户需求的、能让用户喜欢用并一直用的产品之前,无论是产品还是研发,所有人都不能认为已经完成自己的工作了。作为技术人员,也需要为产品出谋划策,而不是在程序写完、编译完、测试完就撒手不管了,大家都在一条船上,每个人都应该把自己当作主人。

在很多公司,每当大大小小的产品发布的日子,哪怕是一个很小规模的新功能被推出的时候,产品经理也会发一封热情洋溢的感谢信,把公司上上下下谢个遍,真正参与开发的自然要感谢,还要感谢周边组的支持,更要感谢公司领导的指引。我们很讨厌这样的电子邮件。

Lyft的做法是让首席工程师发信,信的内容除了对功能或产品的简单描述,还必须包括初步统计数据。任何影响终端用户的产品改动都需要经过一个分阶段发布的过程,初步统计数据就是在这个过程中采集的。我们要求在宣布产品推向市场的时候,非常明确地说清楚成功标准和衡量的方法。换句话说,发布一个新产品本身不值得庆祝,值得庆祝的是产品使用率提高了,从而给公司带来更多的用户或更多的收入,这样的发布信由首席工程师来发也是为了明确技术团队的主导地位。

让开发者学习设计原理

前文提到在Lyft企业版研发过程中的另一个问题是缺乏用户流程的迭代和beta测试。至于原因,研发团队说没有足够的时间,因为UX设计组成了瓶颈,一直没有给出“像素级完美的设计”(pixel perfect design),而研发只能默默等待。

这种思路是不可取的。首先,根本不存在“完美像素”这样的设计,理论原理上的完美设计并不代表用户的体验就真的完美。其次,研发追求完美设计就等同于限制自身试验迭代的速度。工程师应该懂得怎样不受阻,在需要的时候自己来做设计上的决策。

当然这并不意味着研发者可以以解锁自己的名义发布不专业的设计,他们仍然要对最终产品的优劣负责,但是程序员们应该被允许和鼓励采取主动的态度。我们希望研发人员学习基本的设计原则,勇于尝试。

对于Lyft而言,在我们面临的竞争环境里,必须要让每个人在未知的情况下有自主权去试、去学。这其中一定会犯错、会反复,但最终赢得的是速度,和真正的来自用户的实时反馈。

我们甚至认为设计团队的核心任务除了帮助每个项目设计用户体验外,更应该传授设计原理给公司其他部门,尤其是研发和产品的人员。在许多项目的初期,我们鼓励工程师和产品经理在设计团队的协助下,甚至是独立于设计团队自主地做设计选择,并通过不断的beta测试来获取用户实际使用情况,从而确定产品的定位走向,这样可以大大提升效率。反之亦然,技术和产品的人员也可以给设计团队讲解不同设计的工程成本和影响,在一些特殊的情况下,不完美的设计反而可能会带来更好的结果。

几乎每个人都知道好的产品来自反复试验和快速迭代,但一般团队的做法是不停地加人手来保证速度。有时候在需要跨部门合作的项目中,人数的增加并不能直接解决问题,更重要的是有一个健康的团队文化去鼓励研发人员突破框架扮演不同的角色。

培养T字形能力结构

前面讲了研发人员如何“越俎代庖”参与产品决定以及做产品雏形设计,因为这两个职能部门平时跟研发人员打交道最频繁也最容易导致研发进度受阻。同样的道理也适用于其他职能部门与研发部门的合作。与其因为其他职能部门的资源有限而使研发进程变缓,不如主动出击,争取主动权。

值得一提的是,让研发人员跳出技术的束缚扮演不同的角色也是他们职业发展的关键。在职业生涯刚开始的阶段,提高意味着更深入了解一个领域。随着各项技能的成长,研发人员的综合能力应该逐渐成为一个T字形结构,这也是目前硅谷各大公司最想追逐的人材类型。

如图1-2所示,具有T字形能力的人精通一个或几个领域,并对专业以外的其他职能有热情和兴趣,且敢于涉足。这里提到的T形可以是任意范畴的,对于每个人都不尽相同。研发者可以完全在技术领域建立T字形的知识体系,很多互联网公司最资深的架构师就是这样,而对于其他的研发者,知识的广度可以覆盖技术之外的领域。

0104.tif

图1-2 T字形能力结构

前段时间笔者有机会认识了一些前Uber中国运营团队的朋友。他们其中许多人都是软件工程师背景, 后来华丽地转身成为了Uber在中国地区业绩最优秀的GM。在他们看来,做运营的人能力必须很广很杂,之前做过研发、做过产品就能更具备竞争优势。运营要同时与很多不同的职能部门打交道,需要不停地转换角色,比如跟研发人员沟通和跟设计组讨论是需要不同技巧的。

随着共享经济的崛起,运营方面的人才近年来变得更加抢手,在公司里不再是配角,薪资待遇也大幅提高。这不是要鼓励大家放弃编程都去做运营,而是坚持做技术的同时,也可以学习运营人员的模式,把自身的技能和职责多功能化。

以被替换为目的的管理模式

带头人的职业和能力拓展:以团队效率为先

除了对研发者的能力培养和职责进行重新定义之外,技术工程文化的另一个重要元素是技术研发经理的角色扮演。

这里要稍微提一下,中国和美国对于管理职位的定义还是有所不同的。在国内或其他亚洲国家,管理多多少少被视作一种晋升。而在西方,管理不过是一种不一样的职能,和研发之间没有地位的高低之分,只是各尽其职。所以,要创建一个健康的团队文化,管理者的自身素质和日常行为举足轻重。

管理者要逐渐放下技术主管的角色

首先,笔者认为管理者应该把自己看成是教练,而不是试图让自己成为最好的球员。

说起来容易但做起来不简单,主要原因是很多技术研发经理曾经都是工程师出身,而且他们往往是团队中最资深的工程师。初次担任管理角色时,他们要适应逐渐放手让团队中的其他人去做决定,很快他们会发觉团队中的其他人掌握了更多的技术细节,或者说已经是一个更好的球员,这种感觉不是每个人都能接受的。

我们看到许多管理者寄希望于长期扮演双重角色,既是团队经理也是技术主管。结果是,他们自身的效率直接决定了团队的效率。在这样的团队中,其他人也不会感到被需要或有机会跳出来带队。如果一个管理者想在管理这条路上走下去,团队经理和技术主管双重角色的扮演是不能长久的。

举个不太恰当的例子:梅西是很多人公认的当代球王,五次获得国际足联金球奖,而职业球员生涯相当平庸的勒夫作为主教练却把德国足球带到了世界之巅,并且在2014年世界杯决赛中,“德意志战车”碾压的恰好是梅西领军的阿根廷队。

毋庸置疑,不管是梅西还是勒夫,都是世界足球殿堂的巨星,功成名就。但是勒夫的故事告诉人们一个道理,要成为一位优秀的教练,不一定必须是最棒的球员;即使是最好的球员也需要一位懂得管理的教练。对于一支球队而言,教练的作用和球星的作用不冲突,都不可或缺。

管理者要对团队业绩负责

关于管理有一个常见的误区,就是如果不负责技术细节了,技术经理就只能专注于处理人事。

这是许多优秀的工程师难以适应管理工作的一大原因,他们觉得只是处理人事不好玩,也体现不了自我的价值。我在面试来应聘管理职位的人时,常问的问题之一是如何去评估一名技术研发经理的工作。几乎每个来面试的人都会马上意识到,我所期待的答案不仅仅是他们在技术方面的贡献,而是他们如何培养组员、创建团队。但是十有八九的人会继而提出团队的士气和团队的稳定性就是研发经理的成功指标。

这点我不能完全同意。他们说的也没有错,符合上文的教练与最佳球员的理论,但是作为管理者也必须要对团队业绩负责。纵然他们可以使团队中每个人都感到开心,做事有动力,但如果业务目标没有实现,仍然是管理不善。

这里的关键是,当管理者授权团队的成员做所有技术决策后,他需要把自己的时间花在其他正确的事情上,从而间接地为业务目标做出贡献。这些正确的事情当然也包括如果有人事问题,必须快速果断地解决掉。不仅是因为这是管理者的职责,更因为解决了这些人事问题可以修复或帮助提高团队的生产力。

管理者不是单纯为了处理人事而处理,一切都是为了团队利益。其实除了人事管理之外,一名技术研发经理还可以帮着去做许多技术之外但又是推广一款产品所必需的事。

回到Lyft外部平台这个例子,推广所必须做的事情就包括了与第三方的合同谈判、对用户流量的预估、市场竞争的比较分析、营销推广等。这些工作平时不太会被想到,不是因为它们不存在,也不是因为我们真的帮不上忙,而是因为它们并不是搞技术的人的专长所在。如果你不理会不参与这些事情,其他职能部门的人可能最终也会搞定。但是跨界参与这些工作不仅能加快整个产品推向市场的进度,也有助于自己作为管理者的能力的提升(好比鼓励研发人员学做产品学做设计一样),再者通过这些经历也能让管理者从崭新的角度来看待一个项目。

管理者要学会培养接班人

作为管理者,有一个重要的任务是寻找能够取代自己的人。

这听起来可能有些荒谬,搬起石头砸自己脚的感觉,但事实上培养接班人的确是最有效推动自己不停进步的方法。当管理者发现下属已经可以完全担当管理的角色,他就会有危机感去发掘更大的舞台,拓宽自身的业务。

回想我在Twitter工作的四年半。我第一次担任研发经理时,团队中的另一位工程师无缝地接过了技术主管的角色,有了他带队,我可以腾出时间来研究怎样把分散在公司各块的相关项目整合到一起。

当新团队规模不断壮大,所涉及的项目开始多元化后,我又及时地找到了几位可以独当一面地把一个或几个小组打理好的研发经理人。不停地拓展,不停地交付给别人,然后再拓展。

一年前决定离开Twitter时内心非常纠结,毕竟放弃的是自己一手从零组建起来的产品安全风控团队。但让我欣慰的是,团队当时处在一个稳定的状态,三个直接下属—两个研发经理和一个架构师,合力妥妥地接过我的所有工作,所以我的离开对组织的高效运行没有什么太大的影响。我把这个称为“以被替换为目的的管理模式”。这样的管理理念也有利于培养有责任意识、有T字形技能的技术人才和管理人才。

优秀管理者要勇于展示自己的弱点

优秀管理者必备的特质是要敢于展示自己的弱点。每个人都渴望成功,希望受到尊重,于是扬长避短成为自然的选择。但反过来,正视自身的不足会让周围的人感受到你的真实,也会让团队的人意识到他们自己是不可或缺的角色。

一位业界前辈说过,领导和管理是门艺术,需要管理者建立连接,善于倾听,不耻下问,最好的主意往往在别人的脑子里。作为领导者如果不能沟通,不能赢得信任,就无法激发那些有最佳想法的人的潜能。

适当的时候我们的确需要展现信心和个人魅力,但是信心和魅力都是成功的必要但非充分条件。我们平时工作上做的很多决定具有很大的不确定性,即使有海量的数据,也很难明确地指向一个唯一的方向。在这种情况下,团队需要他们的领队来做抉择,如果没有平时的沟通与信任,他们很难坚定地跟随。

统一全面的绩效衡量

最后讨论一下单个职能部门的业绩(OKR打分)和总体业务KPI之间脱钩的问题。

解决方案非常直接:让项目中各个职能团队在制订OKR时都使用统一的绩效衡量指标,最直截了当的就是总体业务KPI了。但实际操作起来,单单用总体业务KPI做指标未必能很好地衡量各组各人的具体工作。

比如说做基础架构的研发、构思用户体验的设计师很难把他们的产出和最终的KPI直接挂上钩,所以每个部门内部还是需要采用更细致的、有针对性的目标和指标。但必须坚持的是:任何部门的业绩打分必须取决于总体业务的成绩。

这样做的必要性有两点:其一,杜绝某些部门追求表面业绩,比如销售部门优化合同意向书中的预计流量而不是实际订单;其二,如果项目规划设计中有明显遗漏的地方,各部门都达标但总体业务指标不一定随之而动就能及时发现问题。

除此之外,对于每个有关增长的目标都建议添加一个相关产品质量的杠杆指标(如图1-3所示)。这个概念是由传奇的英特尔前首席执行官安迪·格罗夫提出的。安迪在他的书中提到,任何一项指标都会将人们的注意力引向它监控的东西。就像骑自行车,人们会不自觉地朝正在看的方向打把。再如传统制造业企业,如果员工开始关注库存水平,他可能会想尽办法来降低库存,但是当库存变得过小,以至于员工不能快速应对需求的变化,就会造成供应短缺。所以,我们要防止因为指标引起的过度反应。解决方法就是引入配对的杠杆指标,对于库存,需要监控的是库存水平和短缺的发生率。机器学习里的二元分类问题中,精确率和召回率之间的权衡也是一个很好的例子,我们可以把这套理论用在互联网产品研发上,在大力推动用户增长的同时,必须关心用户使用反馈,否则就是刷数据而不是真正地解决用户的痛点。

0105.tif

图1-3 杠杆指标

目录

相关技术