关键词：
Lyft 的技术总监沈思维分享了他对于管理技术团队和打造工程文化的经验，也欢迎添加他的微信公众号"人家的屋顶"了解更多（微信公众号ID: othersroof）。
沈思维毕业于密歇根大学和卡内基梅隆大学。他早年在 Google 任软件开发工程师 (2005 - 2011)，2011年加入 Twitter，后任产品安全部高级研发经理，负责反垃圾及帐号安全方面的工作。2015年底至今在 Lyft 担任研发总监，负责包括支付平台，风控平台、开放平台在内的多个团队。工作之外，沈思维关注并致力于提高科技行业里中国人的职业规划发展。 营造正确的团队文化
Lyft 开放平台（Public API Platform）是对 Lyft 主 app 的延伸，包括 Lyft 企业版、礼宾服务、与酒店航空等其它行业的合作对接，以及与其他平台的深度整合与资源共享。打造推广公共开放平台涉及公司各方面，除了技术团队外，还覆盖了产品、设计，售前售后技术支持、运营、商务、销售、市场、法务等等。
对于这样多个职能部门合作，业务覆盖面广的大型项目，除了需要高质素的研发人员之外，良好的团队文化至关重要。
营造正确的团队文化有两个直接的目的：提高团队效率；促进人才培养。
全栈型组织架构
健康的技术工程文化需要一个合适的组织架构来支撑。拿近几年流行的全栈 （full stack）概念来说，比起传统按技术领域分组，全栈式的技术团队的主要优点是消除了一些跨部门合作的壁垒，减少团队对于外部其它组的依赖。
以往前后台研发通常是分开的，现在的做法是让每个项目都有属于自己的前台、后台，服务器端和移动端，甚至专属的测试、数据分析部门。在一些较大规模的公司里，还出现了把技术、产品、运营从组织架构上深度配套，组成一个事业部并统一管理的结构，以保证相互间的高度同步。这就把全栈式团队的意义进一步推广到了技术范畴之外。即便如此，设计、商务、销售、市场、法务等这些不可或缺的职能部门，仍会因为资源有限，而难以分散在各项目中。所以全栈式的团队不是万能药，有了全栈式的研发团队，依旧要考虑如何让跨职能部门的合作达到无缝高效。
全栈式也有资源重复、技术实现缺乏统一性，以及限制个人发展等缺陷。把研发团队按照技术职能分组，虽然容易造成瓶颈，甚至导致各部门抢夺资源的情况。但是按技术背景的划分结构，统一技术架构设计模式代码规范往往可以做得更好。此外，全栈式团队中某些技术领域的工程师会落单，出现没有全职工作量的情况，即“卫星工程师”（satellite engineer）。全栈式的组织架构虽然对总体团队效率有利，但对卫星工程师的职业发展不是最佳的选择。
这里有两个常见的对策。
首先，鼓励尽量多的研发人员变成全栈工程师；其次，对于每个技术领域形成跨团队的“虚拟组”（virtual team）。每个虚拟组应该定期地交流讨论，以此确保各个团队之间在同一个技术领域的技术上的一致性兼容性。
团队有了全栈的技术能力，随之而来的问题，是如何分配做产品功能和做基础架构的研发资源。
初创公司经常犯的错误，是把所有的研发资源都投入到做产品追求最大化的增长速度。虽然这样短期效果喜人，但随着产品的复杂化，会出现“技术债务”，即基础平台的不健全会阻碍新产品功能的实现。
为了杜绝技术债务，全栈式研发团队在任何阶段，都应当有组合型的工作规划（portfolio aproach），平衡产品研发投入和对基础架构上的投资。这与资产投资的理念相似，即将短期与长线相组合。因而一个公司的技术团队所有的组都发展全栈式是不可取的，过度的全栈是一种“组织债务”（organizational debt）。
不受限的研发团队
在 Lyft，我们使用 OKR（Objectives and Key Results）进行季度规划，即目标和关键结果。因为谷歌全面采纳 OKR 的巨大成功，很多公司争相效仿。OKR 用于对公司、团队，甚至个人每季度的工作做规划、追踪和衡量。
Lyft 公共开放平台的所有团队都各自制定了OKR，并连续多个季度近乎完美地达到了预期的结果。然而，当回头看核心数据时，月活跃企业版订单的增长曲线并不像 OKR 打分那么令人满意。在总结调查中我们发现，增长不给力的原因是企业版功能复杂、流程冗长——传统行业的企业客户因大幅的数据及账户迁移门槛太高，望而却步；潜在合作公司发现产品不支持其独特功能需求。这直接导致了这些客户的离开。
这里有两个问题：第一，在开发之前，团队就已了解所有的产品要求，但是为了在预定期限内完成，不得不放弃部分功能；第二，产品的用户体验不好，而OKR 打分却很高，这说明 OKR 定得有问题。
产品开发中，因为时间压力而减去部分功能，这样的现象在科技行业司空见惯。为了赶进度放弃部分功能，研发往往想让产品经理背锅，但被排除的功能是否重要，需要实践测试。但这时候研发推脱道，界面设计太慢，Beta 测试来不及，项目优先级不够。
与其说是研发团队推卸责任，倒不妨客观地把问题想成是不同职能之间合作的必然产物。在资源有限的情况下，我们应当从研发团队入手，从技术工程文化上做改进，寻找技术可控的解决方案。
技术团队的主导地位
首先是“产品决定（product decision）”的谬误。我们需要一种文化，让工程师对产品有强烈的主人翁意识；让他们有自主权和权威去履行职责。我们倡导研发人员对其开发的软件质量和用户接受度全权负责。
如果产品用户体验不好，无论代码多好，开发者依旧需要为此承担负责。在 Lyft 刚开始推行此理念时，很多工程师觉得不合理。然而，用户最需要最喜欢的体验到底，是需要尝试需要更新迭代不断摸索的。在寻找到解决方案之前，所有人都不能认为自己已完成工作。作为技术人员，也要对产品的成功与否负责。
在很多公司，每当产品发布，产品经理常常会发一封热情洋溢的感谢信，把公司上上下下谢个遍。Lyft 的做法是让技术主管（Tech Lead）发信，除了对功能、产品的简单描述，必须包括初步统计数据——任何影响终端用户的产品改动，都需要经过分阶段发布的过程，初步统计数据即在此时获取。在宣布产品推出市场的时候，应清楚地说明成功标准及衡量方法。
换句话说，发布一款产品本身不值得庆祝，值得庆祝的是被用户接受从而给公司带来收益；而这样的电子邮件由技术主管来发，是为了明确技术团队的主导地位。
Lyft 企业版研发中的另一问题，是缺乏用户流程迭代和Beta测试。此时，研发团队将问题推给了UX设计：一直没有给出完美的设计（pixel perfect design），这种思路是不对的。工程师应懂得如何让自己不被受阻，在必要时做决策。对于Lyft，在我们面临的竞争环境里，必须要让每个人在存在未知的情况下有自主权去尝试。虽然难免有错误，但是赢得了速度，得到来自用户的实时反馈。
设计团队应传授设计原理给其它部门，尤其是研发和产品人员。在许多项目的初期，鼓励工程师和产品经理在设计团队的协助下，甚至是独立于设计团队地做自主设计选择，会大大提升效率。通过高频的迭代测试，从随机抽取的小部分用户实际使用情况，从而确定产品功能选择。技术和产品团队也可以给设计团队讲解不同设计的所对应的工程成本。在特殊的情况下，不是百分百完美的设计可以在不影响产品质量的情况下，大幅降低研发，带来意想不到的好结果。
众所周知，好的产品来自反复试验和快速迭代。在需要跨部门合作的项目中，增加人手并不直接解决问题，此时需要有一个技术工程文化，去鼓励研发人员突破框架，扮演不同的角色。
让研发人员跳出技术的束缚，扮演不同的角色，也是他们职业发展的关键。在职业起步初期，提高意味着对某一领域更深入的了解。随着成长，知识结构和综合能力应成为一个T字形——这也是目前硅谷各大公司竞相追逐的人材类型。具有T字形能力的人，精通一个或某几个领域，但对专业以外的其它职能有兴趣，并敢于涉足。
以被替换为目的的管理模式
技术工程文化的另一个重要元素，是技术研发经理的角色扮演。对于管理职位的定义，中美有所不同。在国内或其它亚洲国家，管理职位常被视作一种晋升；而在西方，管理是一种不一样的职能，强调管理和技术的独立性，淡化管理和研发之间的从属关系。一名研发人员的事业的发展，可以钻研技术，也可以选择管理，或者均有尝试。但无论如何，要创建一个健康的团队文化，管理者起到决定性的作用。
首先，管理者应该把自己看作教练，而不是试图成为最好的球员。很多技术研发经理曾经都是的工程师出身，当初次担任管理角色时，他们往往正是团队中最资深的工程师，此时要适应逐渐放手让团队中的其他人去做决定。当管理者寄希望长期扮演双重角色，既是团队的经理也是技术主管时，自身的效率会限制团队的效率。
关于管理有一个常见的误区：如果不负责技术细节，技术经理就只能专注于处理人事。这是很多优秀的工程师难以适应管理工作的一大原因——他们不愿意只管理人事，认为体现不了自我的价值。作为管理者，也必须要对团队业绩负责。不是为了处理人事而处理，一切都是为了团队利益。当管理者授权了团队的成员做所有技术决策后，需要把自己的时间花在其它正确的事情上，间接地为业务目标做出贡献。
在 Lyft 公共开放平台案例中，包括了与第三方的合同谈判，对用户流量的预估，竞争对手的分析比较，营销推广手段等等。技术管理者在这些工作中的跨界不仅加快了进度，也对自己管理能力有所提升，更是增加了作为技术管理者对商务的认知度和敏感度。
管理者的另一重要任务，是时刻寻找能够取代自己的人。听起来荒谬，但事实上，培养接班人是最有效的推动自己不停进步的方法。当发现下属已经可以完全担当自己的角色，管理者就会有危机感去发掘更大的舞台，拓宽自己的业务。
优秀管理者应必备的特质，是要勇于展示自己的弱点。正视自身的不足，会让周围的人感受管理者的真实，也会让团队的人意识到他们自己不可或缺的角色。最好的点子往往在别人的脑子里，作为管理者如果不能沟通不能赢得信任，就无法激发那些有最佳想法的人的潜能。
统一全面的绩效衡量
单个职能部门的业绩（OKR打分）和总体业务 KPI 之间如何脱钩？解决方法非常直接：让项目中各职能部门在制定 OKR 时都使用统一的绩效衡量指标。
什么是最好的统一绩效衡量指标？最直接的即为总体业务KPI本身。但实际操作起来，仅用总体业务 KPI 做指标未必能很好地衡量具体工作。所以每个部门内部仍需有细分的针对性指标，但必须坚持用总体业务成绩决定的各部门的最终打分评估，从而杜绝某些部门因追求表面业绩而避重就轻。
除此之外，对于每个有关增长的目标，应添加一个相关产品质量的杠杆指标。任何一项指标，都会将我们的注意力引向它监控的东西。对于库存，需要监控的杠杆指标就是供应短缺发生率。把杠杆绩效指标用在互联网产品研发上，在大力推动用户增长的同时，必须关心用户使用反馈， 否则就是刷数据，而非真正地解决用户的痛点。
从团队组织架构，到研发人员突破框架担起责任，再到研发经理管理者的角色，最后是团队之间使用统一全面的指标，这是 Lyft 的公共开放平台近半年从技术工程文化上做的一些改进，效果是极其明显的。
公司的规模发展阶段，以及宏观的经济情况和市场走向，都会影响我们的决策。在中国，竞争激烈程度可能导致我们必须调整或放弃对一些文化元素的追求；在美国，由于优秀技术人才资源更紧俏，对公司的运作效率提出了更大的挑战。
《大产品，小团队——携程敏捷技术与管理转型实战》读后感
...的成果。诚如书名《大产品，小团队——携程敏捷技术与管理转型实战》，此书着重于在敏捷开发与管理转型期碰到的问题与解决方案，所以建议小伙伴们在学过了ACP，或者敏捷项目管理理论知识之后的再看此书，会对自... 查看详情
tfs实战培训-博时基金公司（8月）
...一,是目前我国资产管理规模最大的基金公司。博时信息技术部的的软件研发团队是负责公司信息化的核心技术部门，为提升软件产品的研发效率和质量，计划引入TFS系统作为自己的软件研发管理平台，实现从需求管理到产品上... 查看详情
实战篇-teamcoach-“如何更好管理业务预期”
参考技术A这个团队是一个中台团队（金融业务里面的信贷资产部分）和业务团队的对接团队，团队已经通过引导的方式进行了团队融合，通过团队教练的方式，进行了团队定位、团队能力模型的探索。此次主题的由来：为了更... 查看详情
百度的管理团队
2019年5月17日的最新高管团队参考技术A百度创始人、董事长兼首席执行官李彦宏，百度公司创始人、董事长兼首席执行官，全面负责百度公司的战略规划和运营管理。李彦宏1991年毕业于北京大学信息管理专业，随后前往美国布法... 查看详情
简明技术团队管理写在管理之前
...结构不庞大，给与的管理职能时间不多的情况下如何进行技术团队的管理。往往在这种情况下，处于管理职责的负责人会身兼数职。但一定要清楚，管理技术团队和管理项目的区别。即，管理技术团队是要不断提升团队的技术成... 查看详情
技术团队管理体会
管理技术团队很多年了，一直在摸索怎么能带出好的团队，好的团队应该具备很多基本的特征，比如自律，自组织，自我驱动，团队成员间相互高度信任，多种不同性格的人相关配合，等等。可能很少有团队天生就是个优秀的团... 查看详情
技术管理规划-如何规划团队的架构
...标是否匹配梯队梯队代表了团队的成熟度和复原力（类似技术服务的健壮性）资源从资源的视角来看待团 查看详情
cto训练营2018公开课：技术团队的升级之路
从技术到管理，挑战技术管理者的不光是身份和工作内容上的变化，更多的是思维方式的转变。当你成为技术管理者的那一天，如何高效的管理团队，就会成为你的工作重心。如何更好的管理人和事，如何让技术团队更有战斗力... 查看详情
技术团队管理:技术分享
这里写自定义目录标题为什么要进行技术分享如何做技术分享找人找分享主题内容准备进行分享会后为什么要进行技术分享技术团队,员工为什么要离职?钱没给到位?没学到技术?技术成长对初,中级开发人员来说非常重要,曾经面试... 查看详情
大厂技术高管如何融入创业公司(代码片段)
来自互联网公司技术高管的亲身经历与感悟作者|日之崖 责编|朱珂欣出品|思辨致知（ID：gh_66c6f63fe6b7）我从19年9月从阿里巴巴离开，有幸加入了一家高速发展的创业公司，较好的完成了团队融入，伴... 查看详情
团队建设管理能力分析
...维护人心、扩展专业技能。特别是测试团队，个人认为是技术和业务的关系发展扩展性很重要，测试技术是什么？无论是自动化还是性能测试，技术在一个组织里有什么作用？我认为大部分测试涉及的技术无非是支持业务的可用... 查看详情
levitasbio补强公司高级管理层
两位行业资深人士加入，进一步补强公司高管团队生命科学领域市场领先的端到端样本处理和细胞分析技术提供商LevitasBio,Inc.宣布，聘请DominiqueRemy-Renou担任LevitasBioEuropeBV全球商业运营高级副总裁，同时任命GregHerrema为... 查看详情
持续交付实战
公司间竞争体现在产品、技术、效率、运营等多个维度，业务发展要求技术leader从团队、技术、流程、标准多管齐下保证自己负责的维度不成为公司瓶颈。万事万物同理，公司或团队的发展也可以理解成三个阶段：温饱、脱... 查看详情
scrum敏捷项目管理实战（深圳站）
...，敏捷更加直击要害，更加强调自组织和跨职能团队，更能帮助企业高效率交付和盈利！而敏捷强调的是交付价值和交付价值驱动下工作，敏捷项目管理没有这么“迂回曲折”，而是简单直接和刀刀见血&#x... 查看详情
技术走向管理一些思考-怎样建设团队
技术走向管理一点思考-文件夹1882年，法国人林格曼做了一个“拉绳子”试验，发现团队合作时。大家的表现比单独行动时差了近四分之中的一个。这个现象被称为“林格曼效应”。组织不佳的团队会使成员失去动力而且运行力... 查看详情
改名为meta的这一年，facebook已痛失18位高管
...0c;据报道，Facebook（已更名为Meta）今年经历了高管离职大潮，到目前为止至少已有18位高管离职，包括首席技术官（CTO）、首席营收官（CRO）、广告销售副总裁和数字货币和钱包负责人等。Faceboo... 查看详情
团队管理思考
...设要能长久保持一个方向的投入，才能积淀下足够的技术深度，才能更好面对将来的问题。如果总是更换团队的技术方向，则有以下坏处：团队技术方向和成员职业规划不一致，导致团队不稳定，失去成员... 查看详情
团队管理思考
...设要能长久保持一个方向的投入，才能积淀下足够的技术深度，才能更好面对将来的问题。如果总是更换团队的技术方向，则有以下坏处：团队技术方向和成员职业规划不一致，导致团队不稳定，失去成员... 查看详情