如果你在大厂做过设计师，你肯定对自家产品的质量不甚满意。我待过几家大公司，在追求质量方面，每家公司都有值得吐槽的地方。作为设计师，我时常感到在团队里普及质量意识不容易，人们更喜欢盯着业务指标，不能提升业务指标的事情，大家就提不起干劲来。
最近读到一篇文章，完美写出了我在这方面的思考。文章作者 George Kendenburg III (GK3) 曾先后在 Facebook 和 Instagram 做过八年的设计师，他先是因为在 Facebook 工作感到郁闷转岗到了 Instagram，随着 Instagram 规模扩大，他再次感受到了同样的郁闷。他目前已经离职，加入了一家创业公司。
这篇文章的标题叫 The Cost of Craft。Craft 这个词意为工艺、手艺，在科技公司里，一般指在设计和开发软件产品时，对于代码、设计、用户体验、细节等方面的极致追求。
以下是我对文章主要内容的翻译，但是直接说工艺、手艺不好理解，所以我用“质量”这个词来代替 craft。
源起
2018年初，我产生了转岗到 Instagram 的想法。我约当时 Instagram 设计团队的负责人 Ian Spalter 一起吃午饭，他慷慨地答应了。席间他始终在问我一个关键问题：“你为什么想来 Instagram?”
答案是：我想亲身体验 Instagram 是怎么能持续在这么高的质量水平上做执行的。
那时我在 Facebook Video 团队已经工作了三年，心力交瘁。我对“快速试错”和不停“测试”一些不完整的产品感到厌倦。经过几轮可疑的数据验证之后，其他职能的人就开始推着设计团队妥协。最终，我们会上线一个缺少灵魂的、扭曲的产品，这个产品和最初的想法相比早已面目全非，但它在提升业务指标方面的效果倒是不错。
相比起来，Instagram 简直像一个乌托邦。那里的人都很重视细节！Bug 都第一时间得到修复。项目组讨论问题的时候，设计好坏也是一个影响决策的因素，直觉和常识比指标更重要！每次上线，他们都把质量水平提得更高。每个动效都恰到好处，不会莫名出故障或者有奇怪的转场效果，每个交互细节都经过了深思熟虑和完美执行。
我当时特别好奇，Instagram 团队有什么秘诀呢？
跟 Ian 吃完那顿午饭后又过了六个月，我终于有机会加入 Instagram 了。一开始，一切都跟我想象的一样好，我和一群牛人一起做很牛的项目。我学到了简洁、聚焦、克制的重要性，抛弃了一些坏习惯。跟我合作的工程师也很关心细节，他们实现出来的产品跟我设计的原型几乎分毫不差。
随着 Instagram 的成长壮大，产品功能越来越复杂，公司员工越来越多，竞争对手也越来越多。三年过去了，我觉得这里的工作环境开始变得像 Facebook 了 — 对于业务指标的追求超越了对打造人们喜爱的产品的渴望。
似乎所有的数字产品都难逃“追求规模高于追求质量”的宿命。
是什么因素腐蚀了原来的文化呢？思考了很久之后，我认为最终可以归结到一个原因：
追求质量的代价随着团队人数增长而升高。 这里的“人数”指个人贡献者 — 产品经理、设计师、工程师。
我苦苦追寻的秘诀其实就是恰到好处的团队规模和优秀人才的结合。当时 Facebook 有几百名设计师和几千名工程师，有很多条业务线。Instagram 团队的规模小得多，所有人都在做同一项业务。很显然，让十个人保持同步比让一万人保持同步简单得多，每增加一个人，沟通和聚焦的成本就升高一些。难怪 Instagram 的执行的水准那么高！
小团队的好处
团队小的时候，做什么都不费力。但如果你认为这是“公司的DNA”，你就错了。小团队有许多天然的好处是很容易被忽视的。
- 聚焦：小团队资源少，不得不聚焦，这让团队更懂得“简单”的重要性。为了节省大家的时间，设计和开发组件时也会更注重通用性。
- 高质量的招聘：小团队的HC少，因此会格外珍惜每一个招聘新人的机会。反之，如果像 Facebook 那样每年要招很多人，对候选人的要求有时候就降低了。
- 责任感：因为聚焦和高质量的招聘，每个团队成员都很在意产品的好坏，他们发自内心的关心产品，发现问题时也会及时指出来。
随着团队规模扩大，这些好处都会慢慢消失。如果不重视培养质量意识，复杂性和张力很快就会取代小团队的种种优点。
复杂性
让产品保持简单是件很困难的事，尤其是当你的产品有大量用户时，用户会提很多要求。为了满足他们，产品的功能不可避免地越来越多。市场上也会出现越来越多的竞争对手，每个竞争对手都把你向其他方向拉扯一下，如果你跟随它们的脚步，产品很快就会变得臃肿不堪。
与此同时，随着团队规模扩大，创始人不可能有精力参与每一个产品决策，业务团队终归要自己决定一些事情。这时候就需要一个抽象的代理 abstraction layer 来指导每个团队，确保它们的方向正确。
在 Facebook，这个抽象的代理是业务数据指标 data and metrics. 管理层根据公司的核心业务目标制定自己业务线的业务指标和目标，如果上线的某个产品功能提升了这个指标，我们就认为产品变得更好了！个人提升指标的能力被称为这个人的“影响力 impact”，影响力直接与个人绩效和奖金、晋升挂钩。这种激励机制让每个人都想在“提升指标”这件事上做得更好，但实际上我们都知道，指标提升不等于产品变得更好。
提升业务指标的手段一般是改造产品，改造大体上分三类：创新、迭代和补全。
创新
一般来说指一些大的变化。对产品的某个模块进行重新设计，或者开发一款新产品都属于创新类工作。这类工作意味着大量的探索、实验、不确定性和跨团队的协调。在大公司里，这种协调往往都比较难。即便最后能成功上线，你会发现用户还需要一段时间去适应新事物，短期内业务指标不那么好看，甚至有下降的可能。这种项目在公司早期比较常见，但是在成熟期就显得“风险太高”了。
迭代
相比创新类项目，这类项目的范围比较小，通常是对现有功能的渐进式改进。这类项目好执行，造成指标下降的风险也比较小，但也不会带来太大的增长。
补全
这类项目通常指的从竞争对手那里借鉴功能。竞争对手已经证明了用户需要这些功能，因此人们通常认为这些功能“风险低”甚至“是必要的”。它们对业务指标的短期影响通常也都不错，一部分原因是由于新鲜感，用户的使用确实变多了，另一部分原因是管理层为了项目成功在产品里进行的推广— 新增一个 tab 或者显眼的 banner。
当然只做哪一种项目都会让产品变得扭曲，健康的产品需要精心平衡这三类项目。小团队可以轻松地实现平衡，但在大公司里，当人们的绩效评估和业务指标紧紧挂钩时，平衡就没那么容易了。与其想着怎么让产品更好，不如想着怎么能更好地提升业务指标。从这个角度看，补全类项目脱颖而出，成了通往成功的捷径。
补全类功能通常意味着在产品里开辟一块新领地，因为要想优雅地把新功能融入现有产品中去太耗时耗力。那用户怎么知道这块新领地呢？理想情况下，你可以说服某个团队在主导航区域新增一个 tab，如果太难，你也能接受在一个流量大的页面上增加一个显眼的入口。有了入口，你就可以打造自己的功能了。打造自己功能的好处是，你可以制定自己的规则，使用自己的 pattern，不用获得其他团队的批准（可以节省大量时间！）。你还可以不遵守整体的设计规范，因为你的功能是“如此特殊”，别担心，你的总监或VP会尽其所能帮助你上线这个新功能。上线后，总监或VP会要求“破例进行一次推广”来确保“足够多的用户看到它”。所有这些因素叠加起来，新功能很难不提升指标。接着，就会有下一次。
当天平向补全类项目倾斜，人们很容易失去大局观，产品愿景慢慢被“追求用户数量”和“补全更多功能”的惯性取代。产品变得庞杂臃肿时，你不禁感叹，这些功能到底是谁要求做的？团队里的一群聪明人用看数字代替了思考和判断。
这样的变化不会一夜之间发生。最开始，可能只是放过了一两个不那么靠谱的需求和几个“临时的修复”。然后你发现，团队开始走捷径，确保在六个月的绩效评估期内能产生足够的“影响力”。技术债越积越多，人们永远都没时间去收拾之前的烂摊子。复杂性开始叠加，带来了不健康的张力 tension。
张力
当你的愿景变成“做更多的功能”，你会发现竞争对手也多了起来。它们做的事情可能和你现在的业务有联系，也可能不相关。每个竞争对手都意味着要成立新团队，制定新目标，还有从管理层下达的“不惜一切代价战胜对手”的新指令。
在 Instagram 早期，团队很重视简单这个价值，表现之一就是尽量避免创建新页面。因为每次创建一个新页面，用户的对产品的 mental model 就要跟着扩展，并且这些新页面需要新入口。产品功能少的时候，入口不难加，毕竟还有很多空间可以利用。但随着产品功能越来越多，团队对于界面空间的竞争就会越来越激烈。一级页面成了必争之地，占据一级页面上的位置就意味着你的新功能可以有更多曝光。
然而页面上的空间总是有限的，如果没有共同的愿景统领团队，很快它们之间就会打得头破血流。你可能经常听到人们这么说：
- “如果我们不依赖那个团队的项目，我们能开发得更快，这个组件我们可以开发自己的版本”
- “我觉得他们那个项目肯定没戏，我们不能把自己的项目跟它挂钩”
- “开发一个通用的组件是浪费时间，考虑其他可能用到的场景对我们的目标没有任何好处”
- “尽管这样开发可能对另一个团队更好，但是咱们还是应该首先为自己的目标服务”
- “咱们发布之后，其他团队可以学习怎么使用咱们开发的组件”
这种思维方式直接带来质量的降低和功能的无序叠加。因为没有考虑灵活性和复用性，组件更容易出问题。所有东西都成了 one-off，技术债没有机会还。设计一致性变差。团队什么都要自己做，压力变大，更没有时间关注质量。
要缓解这种张力，需要把大家的目标统一到共同的愿景上来，而不只是“获取更多用户”这样的目标。但不幸的是，如果你的组织长时间这样奔跑，它几乎不可能停下来。
想出一个共同愿景很难，因此管理层有时候会通过调整组织结构和项目分配来暂时缓解问题。但这不是长久之计，如果不改变激励机制，复杂性和张力迟早还会回来。
如何改变
团队规模变大时，追求质量的代价变高，但是投入更多资源到基础设施层面，保证产品各方面的一致性也是必要的。
给个人贡献者的建议
- 定义价值观：召集尽可能多的同事，讨论在产品决策时应遵循的原则，达成一致后把它写下来。书面文档在拒绝不靠谱的想法时会很有帮助。尽可能得到更高级领导的支持，比如你的总监或VP。
- 持续宣扬愿景：设计师的特殊能力是可以将愿景可视化。抽出一部分时间来做些大胆的尝试，用来提醒人们未来的各种可能性。
- 与合作者建立良好的关系：花时间了解其他角色的诉求。与他们建立良好的信任关系后，拒绝不靠谱的想法就没那么难了，因为你们毕竟还会在靠谱的想法上继续合作。
给管理者的建议
- 不断优化愿景：如果感到当下的工作只是在机械地做增长，那么是时候设想一个新的愿景了。
- 修复激励机制：引入和质量或大局观有关的评判标准来部分抵消只看数据带来的负面影响。在绩效评估时，除了关注那些可量化的业务指标，还可以问问“这个迭代你怎么帮助了其他团队”或者“你贡献或者改进了多少公用组件”。
- 关注基础设施：经常性地留出一些时间不开发新功能，只改善基础设施。成立基础设施团队，保证这个团队的规模随着业务增长而增长。
- 建立“本地”设计系统团队：在业务团队内部建立相应的设计系统团队。这个团队专门负责与其他业务线协作，并与公司大的设计系统团队配合，一方面帮助改进现有设计系统，另一方面支持公司设计规范在本业务线的落地。
GK3 对于这个问题的观察很到位，提出的建议也非常有操作性。我相信如果团队能共启愿景、统一质量意识和标准、主动承担责任，我们就有可能在大团队里打造出高质量的产品。