lyft沈思维：技术工程文化和团队效率

12月9日到12月12日，由麦思博(msup)举办的第五届TOP100summit全球软件案例研究峰会正在北京国家会议中心召开，在活动首日，记者有幸采访了大会开幕式嘉宾，来自硅谷Lyft的沈思维。

图为沈思维老师在大会开幕式进行演讲

Q：沈老师您好，我们知道您现在是美国第二大的打车应用软件Lyft公司的技术总监，请您再给我们进一步的做一下自我介绍吧？

沈思维：我现在是Lyft公司的技术总监，去了一年多一点的时间，之前是在推特工作，再之前是在谷歌。我自己也是技术出身，以前都是做一些后台的架构，也做过很多年的风控反作弊反欺诈，因为风控也需要很多架构的支撑。现在我在Lyft负责的是平台层，综合了产品和架构工作。 

Q：您这两天要演讲的题目是关于技术工程文化的，您觉得像Lyft公司当中，技术工程文化有什么特点呢？ 

沈思维：事实上在美国，在整个硅谷，技术工程文化是一个相对来说大家都会花很多精力去研究和思考的问题。我自己作为中国人，也很好奇国内在竞争更为激烈的情况下怎么看待同样的问题。因为人多、公司多，竞争的手段达到了极致。在美国有更好的竞争秩序，但是在美国碰到的更大的问题是人才的短缺。别看硅谷是大家公认的技术盛地，但是其实硅谷的最优秀的技术人才并没有中国多。在这样的情况下，作为一个相对来说比较小的公司，比如说像Lyft，我们直接的竞争对手Uber有我们十倍的人，我们必须思考怎么样去抵抗这个竞争，怎么样可以更加高效的迭代。技术工程文化对产值和效率在这里起到非常大的作用。 再说到那些大公司，包括我之前所在的推特和谷歌，他们碰到的问题是整个“机器”老化了，运作比较沉重，创新速度下降了。其实这些问题说到底也都是一些文化上可以解决的。所以大公司、小公司都在考虑技术工程文化。我觉得中国有中国独特的竞争方式，但是我也希望更多的中国公司，更多中国的技术人才，除了技术之外，在运营、管理、文化上再多下一点工夫。

Q：是的，我的感觉是国内公司这些年在运营管理，企业文化方面的意识在不断的提高，在向硅谷里面比较成熟的独角兽公司学习，得到了非常快的成长。

沈思维：对，我其实回来也是想和这里的业界人士交流。因为我觉得我们不能复制，不能抄袭，因为我们的竞争机制不同。我自己曾经觉得，技术工程文化在中国有多可行，是不是我们的竞争要逼迫我们放弃一些文化上的元素。但是可能要因地制宜，或者说自己找到自己的模式。技术工程文化本身这个主题是对的，但是要有一套适合中国特色的东西。

Q：您在Lyft是推崇一个全栈的文化，能给大家介绍一下么？

沈思维：全栈这几年非常流行。我觉得所有的科技公司都在试图做全栈，但是我更多看到的是全栈不能过头。今天、明天我都会讲到，过度全栈是有一定的代价的。全栈确实解决了很多问题，比如说团队的自主性，不受限制，没有对其他团队的依赖。也看到了技术内部的全栈和跨职能的全栈，就是把技术、产品、设计都放在一起。今年早些时候在滴滴访问的时候就看到滴滴的各个事业部，每一个都是非常全栈的团队。但是如果说盲目的追求这样的全栈，就会导致有很多重复性，就是每一个全栈都有做类似的事情，而且一样技术的实现不统一。在Lyft内部，我们在底层是有两个这样横向的团队的，他们并不是全栈组；在上方有很多全栈产品组。因此我认为一个横向和纵向的结合会更好一些。全栈在实践当中还是会碰到一些问题的。

Q：嗯，就是说在底层有一个团队负责例如工具链，服务框架，基础组件这样基础平台的维护？

沈思维：包括平台，最底层的包括数据库，或者Devops，这些如果你全部分散到全栈组，其实最终的结果是不如人意的。

Q：基础平台跟上面的业务全栈，怎么去平衡这两部分的关系？因为有的时候全栈的人也想做一些基础平台的工作。

沈思维：我们曾经会觉得，都以业务职能来划分，就是每一层都是横向的，不利于工程师发展。现在发现全是纵向之后也会有问题。这个结合你刚刚提到的，我们怎么去适应，包括人才的流动。我觉得我们鼓励每个人，就是那些研发的工程师本身，如果变成一个全栈工程师，就是他一个人可以做平台的，可以做架构的，也可以做一些前台，做一些产品。如果让更多人变成全栈工程师，比如把全公司所有的技术团队都变成全栈组，效果来得更好。一个人自己成为全栈工程师之后，他的流动性就更大了。这个问题非常好，我们也看到有的时候在一个全栈组里面，如果出现一个角色只有一名人员的时候，比如只有一个人负责测试工作，他其实是很落单的。这个团队里只有他一个人，跟他做相同事情的人都是在其他的团队当中。我们要尽量避免出现这种我们叫做“卫星工程师”的情况。一方面让更多人自己成为“全栈”，另一方面也要让自己可以去扮演不同的角色。 

Q：更多的人更多的去参与不同的工作，去体验不同的角色。

沈思维：组织不见得要完全全栈，但是每个人可以进行全栈。

Q：刚才我们说全栈，如果说从管理者的角度看，怎么定义一个技术标准来评估不同的全栈工程师是否达到了全栈的要求？尤其是可能不同的全栈工程师所用的编程语言也不一样，能力也不一样的时候。

沈思维：这是一个不错的问题，就是我们不把它作为一个必需的事情。作为一个管理者你不能要求团队中的每个人都变成全栈，因为全栈要花很大的代价，懂的越多，可能每一部分就懂得越浅。我其实自己比较欣赏的人才类型，不管是做技术的，还是做管理的，都有共通点。从技术上来说，我希望这个人的技术结构是一个T字形的。你说的这个全栈，他会懂，他会去学一些东西。但是你不能要求他把每一部分都学的很精，因为我们的时间都是有限的。所谓T字形就是在他某一部分，如果说他自己的本行，他有一个很深入，很全面的知识。对其他东西他有兴趣去参与，可以学到足够的，可以帮助到团队其他的人。这就是我所谓的T字形的结构。在我们管理的话，其实也有T字形的结构。比如说有人更擅长去运营，有人商业敏感度非常强，这都是一样的。回到之前的问题，就是在评估的时候，这个只能作为锦上添花，如果完全要求把全栈做得非常好，我认为这是一个不合理的要求。在有限时间里，很难达到“川”字形的知识结构，也就是每个方向都研究很深。更现实的是鼓励T字形的结构。

Q：您认为什么样的工程师是您需要的？或者说在Lyft公司当中，大部分的工程师处于什么样的年龄段？

沈思维：年龄段的话，我觉得我们现在在慢慢增加一些刚刚大学毕业的，但是这种初创公司在刚刚起步的时候，他不少的研发是来自于之前的一些成功公司。像我们公司的话，推特和Facebook的就非常多。以暴露年龄的形式来回答这个问题的话，可能就是在28-35岁左右，这个成为了公司当时刚刚起步时的核心。现在基本上这个架构已经搭起来了，很多时候在产品功能上要更快的叠加。所以我们现在在比较大量的招一些刚刚从大学里出来的学生。 

Q：刚我们谈及了工程师、员工，那您觉得什么样的团队带头人是优秀的，这样的带头人在团队领导和研发团队当中可以起到什么样的作用？ 

沈思维：这个我可以给你我自己的看法，但是不是适用于中国的互联网企业我不敢说。我在硅谷这么多年下来，至少在美国的文化中，在硅谷的文化中，好的一个团队的管理者，他一定要有教练的气质，就是你去做教练而不是做最佳球员。 很多人放不下，因为作为一个技术团队的管理者，往往他曾经就是一个很强的程序员，曾经是一个高级的架构师，当转变这个角色去做管理，去带队的时候，他要放下很多对技术的掌控，把时间放在团队建设当中去。很多人不习惯这样的一种转化，觉得这样反而不能体现自己的价值了。其实这是对管理价值的一种不理解。我之前说了，我不知道这个是不是对中国有用，是因为我们国内的竞争环境不同，或者说我们的文化，包括亚洲其他国家的文化，管理或多或少地被认为是一种晋升。让技术做得最好的人去做管理，期望能够管理好团队之外，也可以在技术上作为一个带队的人，在硅谷会更强调团队建设，这个要根据国情，根据不同的体制来决定。我自己走过的这条路，我的追求是把自己从一个球员变成一个越来越好的教练，你自己去打理团队，对别人进行培养，最终是让别人有更大的产出，这是一种新的价值，所以有一个词叫multiplier，就是我可以让别人乘几倍，有一个“指数性”的发展，而不是我自己变成一个很优秀的研发人员。 

Q：除了刚刚提到的能够放权，做个好教练而不只是一个好球员之外，还有什么是一个优秀的带队人应有的素质呢？ 

沈思维：首先，在任何时候，都要找到一个可以替代自己的人。这个其实挺不容易做的，因为你会感觉我为什么要让别人来做自己的工作呢？感觉就是把自己架空了一样。但是很多很优秀的美国管理者会跟你说，要争取把自己manage out of job。假如你回想一下自己职业的发展，当你在“桌子的一边”，是个普通员工的时候，你肯定希望你的老板，你的经理是一个能够放权的人，可以让你做更多的东西，让你去做他曾经做过的东西。所以当我们自己到了“桌子的那一边”，也就是成为了管理者的时候，我们要知道年轻人对你的期望值是一样的，所以你也要找到这样的接班人，如果这个接班人非常优秀，他可以非常主动的把你做的部分工作做了，这个过程也是推动了你自己的进步。 

Q：您认为研发团队中员工的的绩效衡量该怎么做，有什么经验可以分享？

沈思维：绩效衡量我之前和滴滴也有过交流，发现中美的差距比较大。现在大家比较同意的是绩效衡量要数据化，要能够量化而不是一个主观的认知。我们现在规划项目的OKR，到季度末的打分要客观，用数据的形式来做这个打分，这也是大家共通的。但是在这个形式上，在这个流程上，我自己觉得硅谷做得比较好一点的是更注重团队的人员之间，也包括其他团队和你有过交流的人给你的一些反馈。在绩效衡量的时候，更注重的是平级的人，甚至是比你更初级的人给出的反馈。比如说你作为一个比较资深的研发，你带了一个新来的人，带了一个菜鸟，或者你招了一个实习生，他们给你的这个反馈，再综合管理者或经理对他的看法。总体来说是把经理和管理者的作用淡化。有一些东西可能是更有经验的人看得更明白，但是日常生活中的那些贡献，他的这些绩效，更多的要从他周围的人得到反馈来实现的，要有这样扁平化管理的理念。尊重团队之间的反馈，而不是经理一言堂，我觉得这一点是美国或者说西方做的相对先进的。

Q：您刚刚回答第一个问题的时候也提到了中西方的文化是有差异的，公司的竞争也不太一样。能不能大概讲讲东西方的文化差异对团队的影响？ 

沈思维：我们把中国作为东方的一个代表，我们的特点就是人多。比如说我们在说效率的问题，如果效率提不高，我人可以涨一倍，也许速度就不再是个问题了。如果说你可以找到这么多真的能够听话干活的，确实是解决问题的一个办法。我们的团队创建更偏向于军队化的管理。我在国内做了很多次交流和采访，之后我很感叹，也很希望我美国的团队是这样子的。在国内团队的感觉像是一个家，他们以一个很和谐的，很愉快的形式去相处，比如说每天都加班，每天都做到很晚，然后每个人都非常开心，觉得这就是我的生活。在美国的话，更注重每个人的生活，公司会更尊重你，理解你要花时间陪你的家庭。在时间上就没有强制的要求，团队就是团队，是一个很专业化的一个关系。国内这边可能是工作会走进生活，这样团队人员间的关系也更紧密了，把这个团队的凝聚力增加的非常多。因为有这样的团队，在有些时候从数量上和时间上就可以弥补一些效率上的不足。这个方式也有缺点，缺点就是团队之间形成这样一个关系之后，比较难互相给予最真实的反馈，特别是一些建设性的意见，因为大家都是朋友，都是兄弟姐妹，这样有的时候就不够专业了，包括你和你老板之间也会有这样的关系。这一点上的差异其实是非常明显的。我一直在考虑西方的这些技术工程文化，到底有多少对中国是有用的。我看到很多大公司，经常想把这样的文化移到国内来，做得比较好的是百度。我有很多朋友，包括我自己以前也在谷歌呆过，也有很多谷歌的朋友回到中国加入百度，因为他们都是做搜索，所以觉得技术上也比较吻合。回百度的人就觉得，百度的技术工程文化氛围和美国非常相似，觉得非常自然。但是我们看到百度这两年在国内的竞争压力，他们还是一个有非常大实力的企业，但是竞争当中碰到了一些问题，和腾讯，和那些更土生土长的公司相比还是有所不同的。我们知道百度内部很多流程、很多文化和美国硅谷是非常非常接近的，也非常坚持这样的文化，可以看到西方文化的影子。 

Q：那再向您提问一个偏向技术方向的问题。做程序开发的人经常会讨论，什么样的编程语言好，什么样的语言不好，在Lyft公司里对于全栈工程师的编程语言有没有什么要求，有没有什么推崇的，标准的语言方面的东西？ 

沈思维：因为最近几年好像Python用的比较多，因为快，简洁一些。之前对C++和Java这些语言，主要的感受就是太重了。就是写一个东西太复杂，上手不容易，搭这个框架要搭半天。Python就比较轻便，也参照了一些成熟语言的优点。不过Python毕竟也有Python的局限性，主要是Python不是类型安全的(type safety)而且缺少一些复杂的但很重要的程式库，所以在我们的基础架构层，我们最近在试着用Go语言。对于Go的选择（而不是Java），我们是抱着一种尝试的心态，Go和Java的更适合底层的架构组建，测试性高，性能调控也好很多。上层产品开发要求的更多时候是速度，所以更倾向于用Python。所以这个是一个结合商业需求的选择。 

原文出处：http://m.csdn.net/article/a/2016-12-19/15842671