初创公司经常犯的错误，是把所有的研发资源都投入到做产品追求最大化的增长速度。虽然这样短期效果喜人，但随着产品的复杂化，会出现“技术债务”，即基础平台的不健全会阻碍新产品功能的实现。

为了杜绝技术债务，全栈式研发团队在任何阶段，都应当有组合型的工作规划（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，在我们面临的竞争环境里，必须要让每个人在存在未知的情况下有自主权去尝试。虽然难免有错误，但是赢得了速度，得到来自用户的实时反馈。

设计团队应传授设计原理给其它部门，尤其是研发和产品人员。在许多项目的初期，鼓励工程师和产品经理在设计团队的协助下，甚至是独立于设计团队地做自主设计选择，会大大提升效率。通过高频的迭代测试，从随机抽取的小部分用户实际使用情况，从而确定产品功能选择。技术和产品团队也可以给设计团队讲解不同设计的所对应的工程成本。在特殊的情况下，不是百分百完美的设计可以在不影响产品质量的情况下，大幅降低研发，带来意想不到的好结果。