效能工具如何在企业规模化落地？｜线上沙龙回顾

11 月 22 日，ONES 与 QECon 联合主办了以「效能平台的行业趋势与成功之路」为主题的线上直播，邀请的嘉宾分别为冯斌（Kid，ONES 联合创始人兼 CTO）、石雪峰（京东零售技术效能通道常委）、魏昭（腾讯研发效能技术专家），DevOps 与研发效能资深技术专家张乐担任主持人。

「效能平台」作为研发效能「黄金三角」中的重要一角，其重要程度不言而喻。不过企业普遍不缺工具，小规模的企业可能会选用开源工具或者采购商业化效能平台，规模相对较大的企业可能会采用自研的方式来设计和研发符合自己上下文的效率平台。

无论是哪种方式，在数字化转型浪潮席卷的今天，我们都会面临重重挑战。尤其很多企业已经走过了从 0 到 1 的工具小范围试点的阶段，那么在 1 到 N 的规模化发展阶段，如何通过平台产生更好的效能？为了达到我们所追求的价值目标，平台该往哪个方向发展？哪些方向值得进一步探索？

今天这场线上沙龙，我们就来看看四位老师的精彩讨论和碰撞。

工具最重要的目标是让业务成功

张乐：在降本增效的大背景下，研发效能平台应该往哪个方向演进？我们做工具还要是想一想，往哪个方向走才能获得更多好处。

冯斌（Kid）：数字化演进的实践其实已经跨过第一步了，就是把很多信息放在一个工具系统里，并且产生一些结构化的东西。但是有了工具之后，我们就更希望从中产生一些数据，并对数据进行度量。不过随之而来的问题是，我们到底应该要看哪些数据呢？

很多团队容易犯的一个错误是，定义的指标与最终的业务价值离得很远，最经典的笑话就是把研发效率和代码行数强关联起来，这就很容易产生内卷，而且方向也不对。

从我们的经验看，将与度量相关的最佳实践落到平台上是值得尝试的方向。比如在推进工具落地的过程中肯定会遇到一个挑战，就是在一个团队的推行效果不错，那怎么让第十个团队也能取得同样的效果？很重要的一点是把这些最佳实践落地到工具里，以便于通过平台帮我们去做规模化的扩展，把好的实践方法扩展到更多的团队。

当然还会有另外的挑战，比如如何度量效能，到底该用哪些指标。这方面我们也跟客户反复沟通过，首先指标一定不能是太过程的指标。衡量价值时要看最终的指标，改进时则需要更关注过程的指标。

石雪峰：我们做工具很长时间了，在我看来，从 0 到 1 再到 N 可以分为三个阶段。第一个阶段，工具特别重要，大家的注意力基本都聚焦在工具的建设上。

第二个阶段，工具没那么重要。我们建了很多工具，但无论是 DevOps 还是研效，都没有取得特别明显的效果，大家的感知也没有那么真切，所以就会产生另外一个极端：是不是用钱造出来一款最好的工具，就能提高人效呢？显然不是，很多有钱公司的人效并没有做到业界的 Top。继而大家就会推翻之前的结论，说工具可能不重要，我们要去做其他事情。

慢慢地就会来到第三个阶段，也就是今天这个大环境，工具的重要性又凸显出来了。这时就有一个特别有意思的话题：度量和工具哪个更重要？

度量固然很重要，但做工具的方式更重要。为什么？因为度量的目的最终还是会落到工具上，做度量不是目的，而是为了改进工具。工具的改进，能实实在在地帮助我们一线研发提升效率和体验满意度。那么在我看来，「以产品化的方式去做工具」就是未来比较明确的一个趋势。

以产品化的方式做工具，数据就显得尤为重要。从 0 到 1 时，大家去对齐功能，把工具做出来。从 1 到 N 时，如果再去堆砌功能，会让工具变得臃肿，没那么好用。所以从 1 到 N，导向应该是数据。

数据可以从两方面看，一是用户的反馈、主观感受、满意度，二是用户使用的数据，可以帮助我们真正去改善工具。

最后是工具要向业务靠近。做工具也好，我们作为研发人员也好，如果一直以一种成本中心的方式去做，其实很难自证效果，因为我们本身就是成本中心。无论再怎么证明，也只能说明是大成本中心或者小成本中心，始终跳不出这个圈。

如果让工具成为业务的伙伴，业务方等角色对于工具价值的认可度就会越来越高，也更容易落地推广，A/B Test 就是一个很好的例子。工具最终的目标还是让业务成功，所以跟业务走得更近也是在扩展工具的边界。

魏昭：降本增效可以说是互联网寒冬的大势态下很多企业的共识。我个人认为降本不是目的，而是一个手段，降本的终极目标还是增效。比如通过裁员降低人力成本，短期看成本的确降低了，但从长期收益来看很可能是不值当的。所以降本，肯定不是单纯地去降人力成本。

我们更应该聚焦用户的痛点，在研发的各个流程中，解决人工化的一些痛点问题，从而实现工具化、智能化，通过创新来破局，达到增值的效果。

像需求管理平台、代码管理平台、CI/CD，都属于基础平台。除了这些平台外，研发环节中还有哪些痛点问题需要解决？比如代码开发环节，大厂积累了很多代码，为了避免重复开发、造轮子，就需要有代码搜索的工具，帮助检索内部的代码，复用高质量的代码。

降本增效和创新这两者并非互相冲突，如果用很传统的降本增效的方式，我们可能永远是在一个老的结构里不断循环，并不能带来本质上的改变。但创新就不一样了，创新很有可能带来十倍甚至更高的效能提升，起到破局的作用。

相比工具的功能，流程数字化更重要

张乐：之前有篇文章很火，叫「DevOps 已死，平台工程永生」，其中就把平台工程作为 2023 年一个极为重要的技术趋势。我们要怎么理解平台工程？平台工程跟研发效能有什么关系？是否有值得我们学习的地方？

冯斌（Kid）：还是要强调平台的重要性。工具的功能很重要，不过更重要的是「流程数字化」。对于一个中大型的团队来说，比如说几百人的团队，作为技术管理者，面临的很重要的挑战就是怎么保障大家在日常工作当中不犯大错，否则会严重影响效率。

以前我们会强调培训，激励大家从底层上有不犯错的驱动力，这没问题，不过可能没那么牢靠，因为人是肯定会犯错的。这个时候有一个很重要的手段，就是通过工具帮助我们把最佳实践固化到工具里。不过怎么保证第一位同学跟第三百位同学都做到不犯大错呢？

举个例子，我们在为客户服务的过程中，都会用工具平台去做卡点，比如分支要满足什么样的条件才允许被合并进去，而没有任何别的途径。

流程数字化有一个很重要的好处，就是可以保证大家执行完之后至少做到 70 分。想要做到 90 分，这对于团队来说是一个成本极高的事情，但是有了这 70 分的基础，之后再通过工具、激励团队等手段，就很有可能让团队往 90 分的状态逼近。所以通过工具固定流程，可以帮助我们把底线定义出来，把大家的水平拉到一个水平线上。

石雪峰：平台工程现在这么火，或许更需要追问的是，这背后所反映的诉求是什么？行业为什么会对它感兴趣？难道说是因为 DevOps 搞不下去了，渴望一个新的概念吗？

对于我们做平台或做工具的同学来说，平台工程并不是什么新鲜的概念，或者说它并不能给我们非常多的启发，也不能颠覆我们以往的固有认知。从这个角度来看，平台工程与我们的认知本质上是一脉相承的，不是多么新的领域或概念。

不过其中的确有值得我们借鉴的地方。第一是自服务，一直以来我们做工具都追求无人化，比如在超市可以做到自助结账。对于工具来说，无人化是好不好用的一个重要衡量标准。所以平台工程给我的第一个启发，就是我们做工具时应该思考「怎样才能做得越少，而不是做得越多」。

这需要我们站在用户的视角去做工具。比如做工具的时候切忌把自己变成上帝，用户一提需求，我们就觉得不靠谱，甚至觉得用户没有理解我们高深莫测的设计思路。

第二是基础设施即代码。就跟全世界的工程师都在 Github 写作一样，大家用的都是代码语言，能减少大家的沟通成本，更快地建立共识。

第三是黄金流程。比如在零售、购物的场景中有一条黄金链路，就是从商品详情搜索到下单结算的路径，这其实就是我们的核心系统。在平台工程里，可能一开始是条土路，还一堆坑。那我们可以通过工具把坑填上，把土路变成一个路径，然后再变成高速公路，让大家跑得更快。

不过不可能整个国家所有的路全是高速公路，高速公路只适用于那种点对点、有明确起始目标的场景，这样一来，需要铺装路径才能构成一个完整的道路体系。对于工具来说也是如此，假设未来整个研发工作都是按照标准化齐步走的方式，那么我们可以提供一条铺装路径，降低门槛，满足更大范围的人群需求。

所以对于我们做工具的人来说，最引以为豪的不是做的平台怎么样，而是通过平台去集成出来的这条路径，可以帮助更多人快速交付。

效能工具如何在企业规模化落地？

张乐：效能平台在企业落地并不是一件容易的事，尤其对于一些规模较大的企业，该怎么让大家接受工具？换句话说，效能工具该怎么在企业里规模化落地呢？

冯斌（Kid）：这是落地效能工具过程中很经典的一个问题，也是我们经常碰到的问题。首先，工具一定是解决了某些关键和痛点问题。那么在推广的过程中，我们就需要把使用过程中的关键问题找出来，然后去打一个「小胜仗」，这在推广过程中是一个很关键的节点。

第二，战役规模不要太大。在团队里我们总能找到一些人，会更有意愿来主动体验和尝试我们的工具。如果我们能从中看到他们真实存在的问题，那么这里就是我们继续改进的机会。而有了这些人的试验，之后的大规模推广落地相对来说就容易一些。因为大部分公司都有追求卓越的企业文化基因，当工具的的确确在某个团队起到作用后，我想大家会开始主动了解和体验的。

第三，工具的推广说到底是一把手工程。从我们服务客户的经验来看，有些团队推进速度特别快，虽然团队的满意度不能说非常高，但整体效果却是相当不错的。我们发现推进一个体系工具的落地，最终都是一个一把手的工程，需要团队的 Leader 想得很清楚。「求之于势，不责于人」，靠每个人自己去拼，可能很难规模化，所以要造一个势能，自顶向下地推广。

石雪峰：我们一做工具，就希望能在非常短的时间内得到规模化推广，我觉得这么说有点理想化，可能需要我们「降预期」。因为推广工具本来就比较强人所难，当用户习惯用某个工具解决问题，新的工具如果不能带来颠覆性的提改变，就很难说服他去用新的工具。此外，即便这款工具是一个颠覆性产品，但肯定还有细节需要优化。

既然如此，那是不是可以借助用户已有的习惯去做一些改变？比如跟用户已有的工具建立关联。

首先可以将用户的痛点通过场景化的方式呈现出来。从功能的视角出发来看，我们对于修复了多少 Bug、新增了多少功能，会很有成就感。但从用户的视角看，他们对功能没有太多概念。那么不如通过场景化的方式去介绍工具，让用户知道工具可以帮助他解决什么问题。

其次，工具是给用户用的，不是当摆设的。所以交付工具就不仅仅是在交付工具，配套的文档、培训、答疑，这些非技术性质的周边内容也承担着非常重的责任。它们相当于工具的门户，可以为用户提供好的指引和向导能力。

最后是快速反馈。大家做过工具都知道，大部分功能可能使用的频率并不高，所以要跟用户建立一种简单直接的反馈机制，让用户能直观地感受到工具的变化，而不是我们按照自己的节奏迭代了很多功能。

魏昭：想要落地，我觉得前提是对于工具平台要有一个非常清晰的定位，就是说这个工具平台是一个生命线的业务，还是一个辅助性的业务？生命线工具，就是说没有这个工具就干不了活，比如代码管理平台。辅助性工具，就是说人力可以代替，只是效率可能没那么高。比如代码补全工具，可以帮助提效，但是没它也行。

有了定位，就容易帮助我们找到痛点中的痛点问题，然后解决，最后带来的收益增值也会更大。