共计 4582 个字符，预计需要花费 12 分钟才能阅读完成。
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、新增了多少性能，会很有成就感。但从用户的视角看，他们对性能没有太多概念。那么不如通过场景化的形式去介绍工具，让用户晓得工具能够帮忙他解决什么问题。
其次，工具是给用户用的，不是当陈设的。所以交付工具就不仅仅是在交付工具，配套的文档、培训、答疑，这些非技术性质的周边内容也承当着十分重的责任。它们相当于工具的门户，能够为用户提供好的指引和向导能力。
最初是疾速反馈。大家做过工具都晓得，大部分性能可能应用的频率并不高，所以要跟用户建设一种简略间接的反馈机制，让用户能直观地感触到工具的变动，而不是咱们依照本人的节奏迭代了很多性能。
魏昭：想要落地，我感觉前提是对于工具平台要有一个十分清晰的定位，就是说这个工具平台是一个生命线的业务，还是一个辅助性的业务？生命线工具，就是说没有这个工具就干不了活，比方代码治理平台。辅助性工具，就是说人力能够代替，只是效率可能没那么高。比方代码补全工具，能够帮忙提效，然而没它也行。
有了定位，就容易帮忙咱们找到痛点中的痛点问题，而后解决，最初带来的收益增值也会更大。