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 的公共开放平台近半年从技术工程文化上做的一些改进，效果是极其明显的。
公司的规模发展阶段，以及宏观的经济情况和市场走向，都会影响我们的决策。在中国，竞争激烈程度可能导致我们必须调整或放弃对一些文化元素的追求；在美国，由于优秀技术人才资源更紧俏，对公司的运作效率提出了更大的挑战。