如果你在大厂做过设计师,你肯定对自家产品的质量不甚满意。我待过几家大公司,在追求质量方面,每家公司都有值得吐槽的地方。作为设计师,我时常感到在团队里普及质量意识不容易,人们更喜欢盯着业务指标,不能提升业务指标的事情,大家就提不起干劲来。

最近读到一篇文章,完美写出了我在这方面的思考。文章作者 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”,你就错了。小团队有许多天然的好处是很容易被忽视的。

随着团队规模扩大,这些好处都会慢慢消失。如果不重视培养质量意识,复杂性张力很快就会取代小团队的种种优点。

复杂性

让产品保持简单是件很困难的事,尤其是当你的产品有大量用户时,用户会提很多要求。为了满足他们,产品的功能不可避免地越来越多。市场上也会出现越来越多的竞争对手,每个竞争对手都把你向其他方向拉扯一下,如果你跟随它们的脚步,产品很快就会变得臃肿不堪。

与此同时,随着团队规模扩大,创始人不可能有精力参与每一个产品决策,业务团队终归要自己决定一些事情。这时候就需要一个抽象的代理 abstraction layer 来指导每个团队,确保它们的方向正确。

在 Facebook,这个抽象的代理是业务数据指标 data and metrics. 管理层根据公司的核心业务目标制定自己业务线的业务指标和目标,如果上线的某个产品功能提升了这个指标,我们就认为产品变得更好了!个人提升指标的能力被称为这个人的“影响力 impact”,影响力直接与个人绩效和奖金、晋升挂钩。这种激励机制让每个人都想在“提升指标”这件事上做得更好,但实际上我们都知道,指标提升不等于产品变得更好。

提升业务指标的手段一般是改造产品,改造大体上分三类:创新、迭代和补全。

创新

一般来说指一些大的变化。对产品的某个模块进行重新设计,或者开发一款新产品都属于创新类工作。这类工作意味着大量的探索、实验、不确定性和跨团队的协调。在大公司里,这种协调往往都比较难。即便最后能成功上线,你会发现用户还需要一段时间去适应新事物,短期内业务指标不那么好看,甚至有下降的可能。这种项目在公司早期比较常见,但是在成熟期就显得“风险太高”了。

迭代

相比创新类项目,这类项目的范围比较小,通常是对现有功能的渐进式改进。这类项目好执行,造成指标下降的风险也比较小,但也不会带来太大的增长。

补全

这类项目通常指的从竞争对手那里借鉴功能。竞争对手已经证明了用户需要这些功能,因此人们通常认为这些功能“风险低”甚至“是必要的”。它们对业务指标的短期影响通常也都不错,一部分原因是由于新鲜感,用户的使用确实变多了,另一部分原因是管理层为了项目成功在产品里进行的推广— 新增一个 tab 或者显眼的 banner。

当然只做哪一种项目都会让产品变得扭曲,健康的产品需要精心平衡这三类项目。小团队可以轻松地实现平衡,但在大公司里,当人们的绩效评估和业务指标紧紧挂钩时,平衡就没那么容易了。与其想着怎么让产品更好,不如想着怎么能更好地提升业务指标。从这个角度看,补全类项目脱颖而出,成了通往成功的捷径。

补全类功能通常意味着在产品里开辟一块新领地,因为要想优雅地把新功能融入现有产品中去太耗时耗力。那用户怎么知道这块新领地呢?理想情况下,你可以说服某个团队在主导航区域新增一个 tab,如果太难,你也能接受在一个流量大的页面上增加一个显眼的入口。有了入口,你就可以打造自己的功能了。打造自己功能的好处是,你可以制定自己的规则,使用自己的 pattern,不用获得其他团队的批准(可以节省大量时间!)。你还可以不遵守整体的设计规范,因为你的功能是“如此特殊”,别担心,你的总监或VP会尽其所能帮助你上线这个新功能。上线后,总监或VP会要求“破例进行一次推广”来确保“足够多的用户看到它”。所有这些因素叠加起来,新功能很难不提升指标。接着,就会有下一次。

当天平向补全类项目倾斜,人们很容易失去大局观,产品愿景慢慢被“追求用户数量”和“补全更多功能”的惯性取代。产品变得庞杂臃肿时,你不禁感叹,这些功能到底是谁要求做的?团队里的一群聪明人用看数字代替了思考和判断。

这样的变化不会一夜之间发生。最开始,可能只是放过了一两个不那么靠谱的需求和几个“临时的修复”。然后你发现,团队开始走捷径,确保在六个月的绩效评估期内能产生足够的“影响力”。技术债越积越多,人们永远都没时间去收拾之前的烂摊子。复杂性开始叠加,带来了不健康的张力 tension。

张力

当你的愿景变成“做更多的功能”,你会发现竞争对手也多了起来。它们做的事情可能和你现在的业务有联系,也可能不相关。每个竞争对手都意味着要成立新团队,制定新目标,还有从管理层下达的“不惜一切代价战胜对手”的新指令。

在 Instagram 早期,团队很重视简单这个价值,表现之一就是尽量避免创建新页面。因为每次创建一个新页面,用户的对产品的 mental model 就要跟着扩展,并且这些新页面需要新入口。产品功能少的时候,入口不难加,毕竟还有很多空间可以利用。但随着产品功能越来越多,团队对于界面空间的竞争就会越来越激烈。一级页面成了必争之地,占据一级页面上的位置就意味着你的新功能可以有更多曝光。

然而页面上的空间总是有限的,如果没有共同的愿景统领团队,很快它们之间就会打得头破血流。你可能经常听到人们这么说:

这种思维方式直接带来质量的降低和功能的无序叠加。因为没有考虑灵活性和复用性,组件更容易出问题。所有东西都成了 one-off,技术债没有机会还。设计一致性变差。团队什么都要自己做,压力变大,更没有时间关注质量。

要缓解这种张力,需要把大家的目标统一到共同的愿景上来,而不只是“获取更多用户”这样的目标。但不幸的是,如果你的组织长时间这样奔跑,它几乎不可能停下来。

想出一个共同愿景很难,因此管理层有时候会通过调整组织结构和项目分配来暂时缓解问题。但这不是长久之计,如果不改变激励机制,复杂性和张力迟早还会回来。

如何改变

团队规模变大时,追求质量的代价变高,但是投入更多资源到基础设施层面,保证产品各方面的一致性也是必要的。

给个人贡献者的建议

给管理者的建议


GK3 对于这个问题的观察很到位,提出的建议也非常有操作性。我相信如果团队能共启愿景、统一质量意识和标准、主动承担责任,我们就有可能在大团队里打造出高质量的产品。