软件测试|一站式效能平台演进之路原创

他那那个我英文名叫安迪，就叫安徽，对，然后。巩固人就是就安迪了，对。嗯，简单自我介绍一下吧，然后你在直乎这边负责整体的研发效能的产品的规划，然后整个技术建设和整体直乎的营效提升能个落地，同时那我过去呃，也是在大数据测试和技术测试的，有那些实践，那这两本书大学测试技术实践，还有继续测试论的实践书两部作品，大家感兴趣可以关注啊。然后过往其实在无论质量体系还是AI大数据稳定性，包括现在研发效能都有一些经验。对，这是我过往大。多年的一个旅游，呃，我今天主要带带来托皮是关于，嗯，整个以知乎这样一个背景来讲，整个研发效能提升时间怎么做的，对我真的展示前想问一下，呃，就是我们现场可以可以简单问卷一下，就是已经有团队，呃或者是公司已经开始在做研发效能或做这事情的可以举手。

有没有？呃，有有有公有，我们在座有同学，团队，公司已经开始在聊这个话题，或者开始在做后面的事情了吗？有没有啊？都都没有是吧，这么尴尬好应该现场有啊，然后。不好意思，没事没事没关系。然后然后那今天这个topic，呃，我我可能会从从产品的视角来来去讲，呃，整个这个事情是怎么做的，包括他的背景和整个研发项目，这个运营怎么做，还有对一站效率平台的平台能力是怎么build的，以及研发效能提升，看带来什么样的变化，然后最后呃，我会从产品视角来讲，产品应该怎么做，对不对，所以所以大家可以今天把我当为当成是一个技术产品，而不是一个一个代对不对。好，我其实这个背景，我我这里面是是主组织是是几乎把这个主语换成任何家公公司都是，其实这个背景是一致的，那呃，我们做这个研发效能。

起源，一个只是行业的环境，呃，在过去的，我觉得应该从二零疫情吧，也就是说开始，然后呃，整个的大经济环境，包括。呃，很多公司都，嗯，都都都对整个的这种所谓的数字化管理，还有这种酵母增效不同，不要童都开始在关注这个点啊，然后生成的原因其实就是增长的乏力，对吧，包括大家最近这几年频繁的看到说什么互联网红利鉴定，然后那个新生儿减少等等等，对吧，然后。你知道不知道？不少的公司去可以增售等等是一个意思啊，然后所以说呢，整个市场C端的，其实大家想到，大家看到，可能大家可以回想一下，从应该过往的五六年，你们有看到哪个线上级的，呃，这种独角兽的公司或产品吧，你像那个打车的滴滴是吧，或者说这种这种呃，短视频的抖音快手也好，可能就是早应该是六七年前就有了，对不对，所以说近三五年其实没有一个什么特别创新的一个产品。

对，所以所以整体来说的话，那对于企业来说，越来越注重那个成本时间和收益。呃，半年后。之前其实在很多创业公司比说他们考虑idea是说那个idea，然后呃，你各种去花钱买量，然后说增长就好了，现在呃，其实现在这个故事讲不通的，现在都是希望你你能够呃公司能够自己挣钱养活自己，他就他是一个好的创业模式，所以说办下来是有很多公司一旦这个业务不挣钱就咔咔裁员。就业务线整合，各种拆分对吧，我这里面是这几年主旋律特别主权，对，因为我之前最近也在也在招聘，然后发现，呃，真的就是可能一个岗位，然后能够收，可能一上午就能收到大几百份简历，就是我。

嗯，在在整个之后内部呢，似乎其实在嗯二一年上市，那上市之后呢，前后有很大的差别，之后的话，整个上市之后，它整个的。人员规模有了一个很高速增长，然后大老来就是我们整体的一些跨部门的沟通会比较难，而且有很多的一些呃。呃，各种一些这种比较冗余的流程啊，包括组织规模带来增长的压力，其实当一个组织规模增长的时候，公司一号位它是特别，呃经常会考虑问题是说我我之前是1000个人大概创造了呃一年比如说十个亿。这个亿的按理说是应该我翻了一倍，是比我的盈丰应该也翻倍，对吧，所以说他对整个组织规模增大的压力是很大，尤其是公司的高管和V聘的，所以这你们可以可以买一个伏笔，其实研发效能的出发点很多时候在在中国啊，其实更多说是说管理的诉求，管理诉求。

对，所以本质上就是一线员工和我们的M的我们的管理者的体感变差了，对。那那对这个事情策略，呃，在很多公司啊，包括一样的都是基于数于驱动的全面提效，大家可能听到或看到这两年有很多关于效能大会，包括。数据来刻画动产。本身就。会能效率于效能效果，呃，它能够使直接关系之间其实有差异，其实从管理学，从德鲁克它的定义，他在所有成效的管理应该大家看，如果看看过这本书，知道它有没有定义啊，在所有成效的管理者中，他追求。

效能的标，组织要个个人的效率对吧。然后那其实我们我们公司个体更更强调的是我们个体的效率，其实那这里面区别是在于说，嗯。我们前者强调是要把。他做正确的事，我们后总调调是把事情做正确对，然后那那对于所有成效的管理者，他他要求会高一点，是说要找到正确的事情，并把它做正确做好。然后可能会有抽象，后面我们我们会有例子来进一步解读啊，然后这些飘红的呃，大家看看就好了啊，然后。呃，我我重点就直接来来举这个例子来讲什么叫。那个效能我们就拿京沪高铁来举例，京沪高铁呃，首先呢，从效率的维度来是说我们正确的做事是吧，然后我们希望能够尽可能多的提升RI，也就是说我们的投入比较少，但是我们的收入比较可观，我们R占有利润，这是我们从效率上看，那呃，这个这个后面发号成整号啊，这有个bug，这说啊，然后效果是说我们强调是做正确的事是吧，我们希望这个事情的效果是可持续的，是是好的。

他最他最后带来带来的最后呢，我们指向的是效能，也就是说我们正确的去做正确的事。不高企，呃，这个业务而言。它的营收利润是为正的，它是一个健康的指标，对吧，这样的话，那京高铁才会这个服务，它整个的这个发车的品质，然后整个体验才会越来越好，对吧，所以它才会它会提升发车的单数，单侧运力润。等等，那所以说其实我们很多时候，很多公司里面呃，都特别强调效率，效率就比如说哈，就是说我们呃，我们十个研，我们我们十个研发的社开团队，然后呢，之前一个月能做，打比方能做100需求，然后基于某某实践，我们现在做一百一百五十个需求，150项目了。

那肯定会问。我们我们特别拼，特别短的一个月吞吐了150个项目，但这个业务一定好嘛，这个业务未必是一定好的，对吧，因为这个业务能不能成功，这个商业能不能成功，他有很多变异量啊，有可能没有，有有可能你做的好，原因是因为你在这个月里面，你又花，你又多花了几百万买的量。然后然后整个的效果比较好，有可能是说呃，你的体验，所以说效率不代表它的那个效果。就是错的，那你效率再怎么高，他这个路径的。跑不了对吧，所以说那效能本质上是应该是指效率加上效果，然后是这样的关系。对，但是我们很多时候。在做工程师的研发效能的时候，关注的是个体，其实对于这个整个的项目，这个产品是不是成功的，呃，这个定义或者关注点其实是呃，可能是比较显比比比较少的。

对对，我和小能拿来简单科普一下，他们是一个递进关系，对。呃，我们当我们谈到效能的时候，就不得不说到度量对吧，然后呃，那那上面这个图是那个比多鲁克说的，如果说你没法度量他，你就不能管理他，这是他的一个呃，一个比较鲜明的观点，呃这个观点其实呃基本上呃从管理视角来说，这个是OK的，但是呢，后面有一个叫一个比较有名的叫古哈德定律啊，这个是呃来自于一个印度的一个很古老的故事。大概意思是说，呃，你你当你把某一个度量。讲是一个KPI的时候，他可能就不是个好的度量指标了。就换说当我们在做效能或。质量度量，任何度量的时候，如果说你把它作为KPI，就比如说啊，就比如说呃，某某研发团队说他把开发工程司的代码量，每月提到代码量作为一个KPI指标，然后如果是这样的话，他会代码两个两大六，结果就是说大家都会转代码。

是吧，你知道他使用前端，发现前端引一个引引第三方的库代码蹭蹭蹭就上万好。所以这里面你如果你如果说你这么考评的话，他本来可能很简单，If else能处理的，他各种熏陶。循环，你要去转账样一个指标嘛，把它做为KPI嘛，对，所以说呃这里面有很多的一些空子可以钻或就但所以说我们引出这个叫古哈德定律，想表达就是说呃，我们真正在实践的时候，并不能把或者说也不步提倡把某个指标作为一个呃说是一个KPI指标一一定要提升到多少那个，其实这可能未必合理，他应该是一个呃渐进相对来看的一个事情，对。好，我们聊到我们聊度量的时候，我们不得不说呢，关于度量，其实呃，它有四个阶段，然后嗯，如果。

说当某做一个体系来做的时候，就要考虑怎么去搭档体系，那大会有哪哪四个四个部分，四个阶段呢？哦，第一个阶段是先要买点，买点我们要去能够很嗯高效的，然后相对严谨的准确的去收集数据，对吧？然后第二次那个数据收集完之后，我们怎么去展示它和可视化它，你不能说我每次看数据时候，我都要写条circle，写完之后导到Excel里计算，这个好像特别费劲，这好像也不是特别高效，对吧，如此类。然后第三点就是诠释第四个洞察，然后展示，这边我们在讲数据可视化的时候，我就说简单说一下就是。指标有差异，但是不论怎么做，其实业界最主流和比较通用的指标是四个，就是多的，就是dialos中最主流的是个指标。多的分别是指的是部署频率，它代表成功发布产品的这样一个频率，还有是我们的变更MR变更的前时间，是指一次变更mmr提交到发布的效时间，再就是我们变更失败率以及我们的服务恢复时间，它指向的就是我们的工程能力测度。

对，所以说呃，其实就是我们。这个大到大到质检，有时候有事情不用太复杂，那当有了指标之后。呃，我们考虑是肯定时候有的负责人或者是架构师啊，或者说我们的QQ同学客学，他需要去个人解读嘛，那当你在对指标做诠释和解读的时候，这个工作是一定需要小心的，因为你稍不足意就就就可能就点燃火药桶了，就就就背锅，或者就被被被喷的喷的那个体无完肤，为什么呢？你想想你你和RD的，你和研发的某个富人来去阐释说你们的研发，呃代码量特别少，然后然后那个那个那需求吞吐特别低，然后所以说你觉得他们是低效的，如果说你给这样的个解释和导读的话。

你你试想一下，跟你合作的ID是怎么去看待这个问题。对吧，指标做数据的解读的时候，要考虑我们是想要达到什么样的目的，我们是想基于这个来去推进敏捷流程，希望我们我们的交付变得更快，还是说。呃，希望说得到谁支持，还是说呃，因为我们之前的，我们的之前的代码CI和build的很慢，原因是因为我们的部署系统不好用，我们的CI系统比较机械不好，对吧，所以说还是要考虑你想想达到什么样的一个目的。对，然后那这个点的话，你解释你在做指标的这个数据分析的时候，一定是不是一开始就全部铺开的，而是应该先去选择一个可以试点的团队来做，现在试团队拿到结果之后。再不开是有错误，搞几次别人不信任你，那基本上这个事情你就做不下去了，对对对对，然后其实对数据的解读只是一方面，更重要是你你通过的解读能够去洞察出组织的问题，基建的问题，流程的问题，Anyway，找到问题，包括你们思考这个问题该怎么去解决，优化它，这个才是在整个效能实践中比较重要和复杂的一个部分，对对对。

好，我们前面是讲了整个效能度量体系，那从整个工具侧来看的话，那整个效能度量工具的演进其实有几个可能有的团队呢？呃，整个基建不太完善，最开始。就比较这也是OK的，OK的当当这个事情，呃，你我们是希望做到更好的数据可视化和整个的这个成本降低的时候，下一步应该到BI平台了，那BI平台如果说我们是做总个全公司级的，那那BI平台是还是蛮必要的，对，那比如说你可以选择看来的卖来去做一些可视化看板和面板的一些开发和配置，然后接入我们公司所有工程的研发活动的项目流的有需求这样一个数据源是吧。

然后那如果说我们还是想在度量侧做的更加的体系和分层，那可能我们就需要去自建数仓，然后去找数仓分层。然后来再去呃去选择一些能够能够能支持一些跨数据源和更好能下转的这样一个呃这种BI平台我们用后来就切到水是百度的商业的BI平台，它在整个的数据下断还各种能力上更强大，对，然后呢，再往当当这个体组织足够大，当你的数据量就足够大的时候，你可以考虑进一步来去做一些自能的洞察，引进一些这种归因的，或者这些算法能力来做这种呃报表的呃自助的这种自动的呃自动的分析和解读输入出来的。好，那实际上这个是，呃，我们当时在在考。然后我们我们认为整体对研发向提升的模型，如果抽象来说可以分为几个部分，然后本质上它是围绕着人，制度和工程来做的，人就是说我们的组织架构，我们的整个的项目的文化这块怎么建设，怎么去去去去迭代，那我要记住就是说我们我们的项目流程是不是很好的支持我们去做研发项提升是吧，我们天然知道敏捷的这种项目模式下，他的整个交付客粒度比较小，如果铺布的话，肯定是可能项目一个版本发布会比较慢，如此类对吧，还有我们的一些管理实践，我们的一些精益看板等等等，以及那这个都是离不开一个。

的需求的管理，我们的CICD，我们的一些度量，我们的一些报表，对吧。那实际上我们整个的呃，我们这个事情定义，它就是需要我们最开始认定义是它是赋能业务成功，所以说我们认为效率效果和呃那个可持续，这跟指向的质量，效率指的是我们需求的周期，我们的人均称图，那效果我们会从呃，OKR一直关联到我们的用我们的需求，我们需求上线之后的这样一个效果总结，然后那再再往下的底座就是我们的整个的基建平台和我们相关的工程。

实践我们的CIID等等，对吧，以及我们的一些偏管理实践OKR管理我们的我们的看板，我们的经营。那实际上对于整体的效能度量的体系呢，会分为两趴，然后呃，一个是客观的，客观的其实大家应该都看到了很多，比如说我们的规模上的吞吐买我们速度的，我们的周期对吧，我们的持续发布的发布频率，我们的故障的时长，我们的回滚的时长等等，以及我们的质量这块，可能有的公司会基于故障结果来看质量分，事故分，以及我们的确确。分布，那除了客观，其实我们也关注主观，因为毕竟以人为本，对吧，我们要关注我们从效能上大家的体感，我们的我们的好评率怎么样的，对吧，然后体感上，体感按理说理论上，呃，客观和主观应该是相互印证，这才是一个好实践，对，所以说我们。

本质来说，我们会以需求为一个实体来去看全链路，从需求创建到合并上线的耗时，然这个是我们关注的一个点，其次的话，我们通过可视化能够很好的去呃下段分析我们的整个的呃，提升我们的分析能力，包括来去降低我们数据运营的。明白了。比较有意思case啊，其实大家知道就是业务研发和中台研发做做做英特尔架构研发，他们在度量上是不同的维度的，比如说有很多中台研发，他有处理一些on扣工单，对吧，可能他是在做一个，呃，一个一个一个服务，或者一个基建的一个一个中建的开发重构，可能重构他花两个月，但是这两个月可能是他能解决一个特别复杂就是问题，那他的需求可能就是两个或两个项目，那那如果说你完全拿项目数来去和业务研发比，这个就不对等，对吧，所以说这里你要允许业务差异性，再比如说呃，大家有对接过算法的研发，发现我们做算法。

研发可能model的去上线可能是至少是两周或一个月维度，他就是说他一个月可能就是在去一个模型去上线，但所以说呢，你你拿需求来比，好像他也比较糟糕，但是那你就是你你基于这个，你就说这个算法就没有意义，好像也不合理，对吧，所以说这里面是有差异的，这差异那怎么比呢？就比如说。首先我们认为应该是应该是八间训列的趋势来看这个组织，这个团队它的一个变化，而不是应该我们不太建议说人和人，团队和团队的比对对对。我们再看一下我们对于整个数据价值的挖掘啊。其实需要去选定指标，包括整个围绕效能，围绕指标，我们的北极星指标什么，从业务指标插到插到我们旧指标，然后再选举试点团队，然后然试团队的话，最好是选择那种有意愿，而且这种小闭环能很好闭环的团队，对吧。

然后那种跨端项目比较多的这种比较大的团队的话，不一优先是因为它涉及链路的组织角色太多了，然后再就是我们要去给一个完整的这样一个运营的方案，包括我们的数据收集和分析之后，我们再来去调优我们的管理策略，我们的工具的体验，之后我们来去做复盘和沉淀，这个是我们的一个呃。整体的一个在数据的化运营的一个思路，比如说我们的过程中会沉淀各种的一些月报，我们的报告，以及我们基于这个报告洞察出来问题可能是我们的基建的问题，可能是我们组织的问题，可能是我们文化问题，哎，对。那效能运营的技巧，呃，研发效能这个事情，它是一个特别富。做事情种他组建的时候，他需要招一个产品，需要招开发，此外呢，他可能很多时候，他可能还需要招一些所谓的教练，女教练，呃，因为让他来去推一些流程，推一些文化，推一些整体的一些模式的变革，他因因因为因为呃因为他涉及到人或者组织特别的繁杂，然后他不并不是说你开发个产品平台，说哎呦开发我跟你讲讲，你用就好了，立马上面就变好了，不是这样的。

因为本质上，我认为工程师个体是没有意愿和动力去配合你转校人的。这个是付老板。效率做老板，效率是做个体。对，大实话这样的对。好，那我们说再来找这个项目负责人，呃是谁？呃，这个事情我前面反复强调他的复合，他是一个特别复合的这样一个事情啊，所以说我当我们做这样，越是很符合事情的，越是要把生产关系里边就什么叫生产关系，就是职责嘛，职责对吧，然后那研发团队的技术负责人默认就是言效提升的直接负责，他也是这个事情受益直接的受益方，所以说我们要提升技术管理者参与感。

对吧，假如说我们要提升呃，霍格欧学院这个研发团队的也会有人，那这个欧欧肯定是斯海对吧。不应该是这个事情才可能被提升，因为本质上是说他的，我举个例子对吧，对，那所以那个知乎的话，这个事情的负责人，第一负责人是我们的CPU，可能是CPU，当如果说当某某个公司团队说我们要招法一外向人了。这个事情如果说是，呃，某一个QQ负责人喊出来在那，我觉得他自嗨。然后如果说是某某目地出来，坦白说我们要组织团队，我觉得很有可能，那如果说是我们某公司说我想搞一发下来，招一个团队出来。我觉得纯粹瞎想。等你本质上你搞不成的，你知道吧，你做不成的对。那那我们再回到这个关系，那在那在在在之后来说的话，呃，我我们的整个组持人是需要试点团队对吧，某某业务团队他来负责人，他来负责提升他的团队的效能，然后我们的整个的我们的研发效能的产品团队，产品技术团队来推动整个研发，研发效提升，做整个产品化的一些开发和迭代，包括提供各种数据看板数据能力，那同时那他家说业务Q，业务测试开发他们要参与吗？他们需要参与，因为业务测试开发他可以承担BP的角色，来去推动做些运营的事情，当然这里面如果说有呃有女教练，有p Mo他们来推动，也是也是OK的，也是OK的，对。

待会这个图啊，找对研发效能提升的负责人，这个是属于很关键，那我们再说一下那个对知乎而言，我们的负责人就是一号位，研发效能这个项目来说，我们觉得挂出以后就是我们的CTO，对那我们的技术团队，我们就要在A团队做这个试点，A团队负责人他就就他就是这个直接负责人，受益方。那我们QA团队，业务QA他是来去纵向支持，我们负责遇到的问题和数据分析的，那研发项团队，比如说那我在这个团队，我做的事情就是提供上平台的工具，我们是工具的这样的产业团队，包括敏捷教练的支持，提供横向产品化的工作，包括敏捷方案。

制定和实施等等，巴拉巴拉，对对啊，这是我们对于整个研发教负责人是谁的关键，对。然后那其实很，所以说呃，大家可以再想一想，如果说张某大，如果说我们同学公司在搞什么项的时候，你先想想这个团队是怎么构成的，到底谁在负责，然后黑如果说这个这个负责。人找不，我觉得很多就就是拿不到结果，对对，因为我到就因为没有人为这个事情买单，或者说为这个为事情买单，对吧，那谁应该为了买单呢？你说你说我们的QQ团队能够就很牛逼，能够让我们研发团队效能从零到一。我说他们，他为什么会愿意陪你去做这个事情呢？他有什么意愿和动力呢？那如果说他的研发的负责人一号会说，哎，我觉得这是个问题，我们要做，然后每一次的数据和问题，他都来去参与进来，都来去给你一些输入，来去呃来去呃，给你些支持，那可能能做好，我大概是这个逻辑，对。

搭起来，负责人找对了生产关系女性的时候，我们需要做一个，呃，我们要做大张旗鼓的官宣，也就KO对吧，那KO这边的话。本质上我们是想去呃营造这样一个提升的氛围，去制造话题，包括为我们后面的效率提升来预热的，那我们首先要确定的是我们的北极星指标是什么，那其实我们当时确定北极指标就是核心就是冲突，冲突我们看我们的消费周期，我们的饱和对吧，和和度，然后那我们我们会和我们我们是那个指标呢？是需要和试验团队的负责人达成一致的，然后之后呃，我们要产生各种一些规范。包括布局，我们需求的规范，我们的呃呃系统的规范，然后我们来KO对吧。

然后这里面其实整个研校提升的事情，他的管理政策是需要落地的，然后因为关键他是他，因为很多时候发现有时候呢，可能这效能效能不太OK，可能是我们的负责人没找对，我们可能在我项目上没有技术owner能的个角色，是吧，所以说项目跨端的时候，各种合作的时候会有很多bad case。对，然后还有可能之前呃那个呃。诸此类，包括我们之前很少做我们的代码评审，我们客户有单测也没做是吧，诸如此类。所以说这里面是需要有技。人处理了。好，那实际上我们的运营，运营的时候呢，我们运营当时其实我们在乎，我们是尝试过引进专业的女教练来做这个事情，然后还是给到很大的助力了，至少就是在我们的方法论，我们的执行率方就只做了赋能，然后同时我们对整个需求的管理也统一了一些口径，包括布局限我们的，我们认为呃，反正我们的内务要求是三天以上的，是必须要那个提我们的，呃，需求就在我们的营销平台进需求，我们才能才能接活，才能干下一步走的。

然后呃，包括我们，我就我们认为是，只要是并非bug费之类的，所有的生产研发的活动都需要去。平台本地ID口Ding编代码，其他的活动一切全部在线上数字化来去做，在平台上做留痕，一旦你在平台上做有数字化了，这个数字准确的话，它能够相对是比较完善和和准确的去刻画一个组织，个人、个体和一个团队在某个时间段的所有研发生产活动怎么样的，那如果对于这个研发活动的生产分析进一步的去下断，他能找到，哦，原来他在测试环境，经常会比较判定，然后时间比较久，原因是因为我们的环境不好用，对吧，他可能发现原来他的整个的那个服务恢复很慢，说我们的整个故障这块做的不好，诸如此类。然后。八。

道不是道包括几个方面嘛。第一个是。呃，我们的内部的新员工培训，我们在我们的内部的全海报和一些企业服务号上都会就相。效能做各宣扬费，同时我们确实也在做，呃，这种效能的标杆的激励，包括最佳效能团队的这样一个评比，我们只会评比好的，那这种bad case的话，我们可能是下来自己私下去看怎么解决它，对，然后通过这种方式去塑造这样一个经励体系，要有更好的这种参与感和认同感。然后这个是我们一个呃，对外的应该是二一年的研发效能数据多少的海报，然后你们就挑选了一些呃，比较好的一些我们工程能力的这个数据，比如说我们的。

呃，我们的应用的数量，我们的传递生产发布次数，我们的质量的质量，我们。开源的一些一些贡献等等。然后这里说一下，其实当一个公司团队的这个效能做的比较好之后，这种对外的这种PR事情是可以多做的，这个意义还是蛮大的，因为你通过这个的话，可以进一步的去看看你个行业这种领先的大厂，他们的效能上的整体的这个，嗯，实践效果的差异在在哪里。好，我们呃前面是会偏这种数据和运营的这样一个，呃，这样一个输入多点，我们再聊到关于这个平台的建设，呃对于这样的校园平台的建设，首先这里面就要打个引号是什么叫一站式嘛。一站式。呃，五集成我配一个UR链接跳转，然后从A跳BP到C，不是这样的，严格上他不认为从一站式，一站式我们认为它是应该是说它是一个标准化的，然后是场景化的，能够包括能够很好的可视化，那怎么理解呢？就比如说呃，我们实际上我们在整个一站式少园平台中，我我们对于整个的呃分为几趴，一趴是我们在项目协同的需求这一块，一个是我们的研发管理，我们我们的MR，我们的开发水线，还有就是做线上运维这一盘，对，然后这个这个是我们的这样一个，这样一个我抽象的这样一个分成那。

同时他这个度量和可视化就包含我们的指标，我们的一些效能报告等等，对吧，就比如说那实际上我们再回到，呃，我们在知乎内部的平台对标准化定义定，就是说整个围绕着云校这个平台，我们只支持四种工作流。比如说极简的需求标准的标准是需要，呃，就是卡点比较多，需要严重依赖于测试来各种上线的，那极简可能说是KO上线就两个步骤对吧，还有一些这种偏纯项目管理的工作流等等，它本质上就是工作流抽象对大家理解，不论你用的用的什么，其他的一些阿里云像等等。

他的工作流就是工作流，只是说在不同的时候，他可能有一些不同的状态机不同流转之类，本质上是工作流。对，然后再就是我们的一些场景化，场景化我们认为我们横向是以需求为实体，为主要模型来做整个项目的协同，就需求这样一个状态流转等等，那纵向是基于应用，应用对，然后应用来维度来做相关的开发，对，然后打通，我们从横向这种打通，打通需求应用之间，我们就能从需求关联到它是哪个应用的开发，下面有多少MRMR的MR怎么的，MR的时间是什么样的，对吧。然后它的可视化怎么样的，然后它是。可不聊，等等。

好，这个是我们一个实在的一个一个一个一个整个研发项目平台的架构啊，然后呃，那这个平台架构我们可以看出来，然后呃，我们除了这个绿色的，这个是我们带其他经营能力大款的，或者说。公司的基建，我们的。对吧，我们我们用管理我们的组织架构，因为就是一旦整个的平台，这所有的相关的一些用户的，然后我们包括我们的，呃，我们的相关授权买点等等，巴拉巴拉对吧，还有我们的效能数仓。那我们整个整个平台能力分为呃几个部分，一个是项目协同这一趴，项目协同趴我们刚说的是围绕着需求为实体的这样一个模型，所以我们有需求的管理。然后需求的相关的下面论文理，文档管理，以及我们相关的一些呃，看板等以以及自理模式，还有各种一些呃资源日历等等，对吧，然后。

呃，这里面我们对整个项目系统关心的是他的用性和一致性，也就是说那呃作为一个用户来说，他在这平台里面创业需求，这个创需求的动作是不是用起来特别爽，是不是说我是不是能够在一秒内创个需求，而不是说咔咔的我创需求，各种填一堆表单，然后花个30秒弹创造需求，那可能就要就要骂凉了，对吧。然后那呃，我们研发管理这块是核心是我要应用管理，我们支持我们应用管理联调资源，然。然后因为对，然后我们的C我CD以及我们的相关的报警，我们的值班等等，我们的质量管理，就有我们相关的一些呃，围绕着故障，围绕着on，围绕着这种呃，这种这种呃呃用力平台等等，对吧，然后那同时我们也和OKR平台打通的，因为我们希望的是这个需求最终关联的OKKR效果怎么样，它的完度怎么样，是能关联出来的。

我觉得这个才是一个完整的闭环，对，然后那在最上层，在上层次，我们同时也支持我们的整个的研发效能度量平台，那整个度量平台我们我们提供包括不局限于我们的工时。各种科技数据的度量和下降，然后最最大的最层就是我们的微前端，我们会会有会有很多的组件化的能力，对，那当然还有我们的开放平台这些能力还是没有，这个能力还没有做，还没有做好，对对，包括我们的一些这种。对，项目整断能力都还没做好，对，这个是我们整体的这样一个从呃业务层面看这个能力建设，对，然后那呃本质上我们想指向的最左边的就是说首先我们的平台它是想面向业务价值的做交付，同时呃我们从一开始一直在强调和贯彻这是数据去做，所以。我们要把做数据化的，全部数据化，对，然后来去支持我们做全局的可视化，以及可能未来能能进一步让我们做做一些自动化的事情，对吧，然后那我们实际上围绕效能运营这样一个事情的动作有哪些呢？包括不局限我们效能年报，我们的效能案例，我们效能的呃这种满意度，我们的一些效能的一些评比等等了，对。

好，这个是我们，呃，整体来说这个产品架构的一个设计，是整个的产品的实体的。挖一些组逻辑，呃，我们从人人员的组织模型里面，其实呃，它包含的就一些业务线，团队和部门对吧，这样一些逻辑，那他最终他其实都是基于这个project架，就我们项目或需求吧来去做关联，然后那围绕以后完。里，他这里面有一些我们的report，以及我们的一些呃服务，我们的一些这种部署的一信息，那围绕着我们的项目需求需求集，然后不论需求需求集你都会猜task踏的个任务，因为本质上对于项目协同中最小的最原子单位就是一个任务，对吧？大家试想一下，你在接任何需求测试开发也好，你都会拆为几个任务对吧？这个任务可能是，诶，我今天一个任务是完成某某测试用力设计，明天任务是完成某某用例的执行，把bug后面是怎么及时回归，后面怎么自动化咔吧啦吧啦对吧。

好，我们在工作流，工作流。块吧，一个是我们的标准的工流，一个是极简的，还有我们相关说管理的工作流，那比如说标准极简差异大的标准这块，我们从需求创建，一直到需求的完成上线，它这里面呃，整个的整个的这个这个过程的一些阶段。还大家极简嘛，可能是尽可能的简洁和尽可能的短平快，就说我们基本创建需求之后，基本上完成KO，下一步就是可以直接上线了，对，因为后面你说MR合并到后面上线，它全部自动化的我们的CS过程对吧，所以说相比这个环节中那很很大的差别是说。

我们我们把测试环境全部都尽可能的砍掉了，因为极简的我们认为是可以开发是。那个自己开发，自己上测试，自己上线的，这样这样这样一个项目这样需求。我们的项目协同中，呃，项目协同包含有需求，需求及任务和。对吧，就这包含关系，那其实我们我们对这个事情的定义是这样的，我们认为需求或者项目呢，它才是一个项目交付的或项目型交付的核心的产物，所以说我们的度量都是以需求为开始的。我知道我和外部交流，有的团队、公司，他们度量吞吐是以task为为为单位的，其实会有问题啊，因为task力度太小了。

我可能修个bug是一个task，我可能看他的改改革是也是个task，对吧，我们我们我们认为是说我们认为是需求的话，为什么需我们需求它是个相对可度量的有意义的这样一个这样一个产物。因为需求可以关。可能OKR会关联到他的文档，然后各种关联对吧，所以说我们我们内部定义自己需求或者项目，它是一个核心场，对。那那基于这样的话，我们本次的项目协同是要去快速创建需求，然后那怎么去降低需求创建成本，对于呃用户对用户体验来说是很重要的一个一个一个点，一个优化点，就所以说我做一个做一个产品经理，做一个PM来说的话，我们我们一直在考虑是怎么去优化和迭代，去提升呃创建需求的体验，对吧。对，那所以说我们用他一个矿，同时呢，那那对项目学生这块，那做管理者视角，他应该他应该包含什么能力呢，他应该还。提供比，因为当当一个项目，当一个团队组较复杂的时候，他的需求你不能他一个个评估，一个大块表去看，对吧，你很好能够去通过看板的模式或通过日历模式来去各种去聚合，去看我们的整个呃，这个组织团队的过去半个月，过去一个月的所有需求什么状态是什么样，是什么样的现状，对吧。

那这实际我们的一个一个真实产品的DEMO，然后呃。我们所拥有我们的工台对吧，然后我们的项目协同研发管理和质量管理，自己拍。那项目块项目审核里面就包含默认我们的收。收集我们对吧，然后呢，这个就是我们的列表模式，我们下面的这个，呃，这个需求相关的一些任务吧，代办的任务，然后类似于这样的一个页面设计，应该尽可能越简洁越好，越简越好，对对对，不应该不应该复杂，对对对。它这个呃，第二趴是我们的研发管理的一个DEMO，研发管理中它包含就是应该围绕着研发的相关的，呃拉代码联条，然后呃那个代码仓库以及打包以及变更，还有一些资源申请等等都应该或代码搜索都应该在平台能够完成，所以说它包含有这么这么多一些能力，但这里面很容力它不都是。

外部其他内部系统可能是一个跳转，然后大部分，但是我们尽可能希望这个体验是一致的，所以说我们能把它包进来就包进来，对。然后质量管理包含我们的故障管理，我们的质量分，我们的用平台等等的对。呃，那实际上那我们度量大家都看到，就之前说，呃，面向业务价交付，如何去实现一个端到端的需求全流程价值的这样的度量的，这个是一个就是我们真实刻画的，我们认为营销需求上线的画像，一个需求上线要经过哪些步骤？他到了。可以什么时候开始，什么结束，是怎么定义的，我们认为呃，从创业需求为为为为一个起点到最终呢，呃，它那个完成上线，他就是一个需求交付周期，对吧？那需求开发周期呢，是从完成需求的KO审批KO啦，然后呢，到需求完成上线，这个是一需求开发周期，也就是说当我们发现。

创的需求到需求KO的时间占比较久的，可能的卡点是在产品而不在开发，对好，那MR前置时间是什么？MR前点是代码，前置时间是第一次，首次啊。希望对吧，那大家家关注一下，比如说呃，从Q到disccom me这个时间多久是吧，这个时间过长是我们。呃，如果说时间过短，是因为我们没有做技术的设计评审，就直接咔咔就干了，举例子啊。那。测试前时间是从从需求首次提测就整体提测到上线，我们认为这是一个测试前的时间，那还有集成发布时间等等等等。

这里面还有很多细节啊，比如说呢，呃大会那呃怎么定义或怎么定义，或什么叫故障和线上问题的恢复时长啊。呃，这个时间指的是什么呢？是。后面问题时间。在做最最顶头的一部分，对。好，这是我们实际上来支撑我们的整个的端端端调上的数据度量可视化，呃在整个的呃数仓架构设计怎么做的。呃，最底层的数据采集，我们需要采集我们的组织数据，比如说我们从不从研发序列的这个OA的数据，他的呃，汇报关系是吧，然后他等等，然后人员数据嘛，到多少人我们要知道，对吧，还有我们需求的管理数据，我们的需求排期，这样数据里程碑流转，我们的代码，我们的任务数据，我们代码就是我们的K相关的数据，对吧，代码库。

Owner等等，还有我们的故障的数据和部署和用数据，当我们把这些数据都拿到的时候，我们就能和我们在基于我们的数据的计算从成e tr的过程，我们最后能刻画的就是最开始在在应用层提供需求的看板吞吐，包括。我们的那些我们实际发布看板发布的频率，变更失败率等等，巴拉巴拉对吧，然后以及那这样的话，同时我们基于该趋势的分析，下段分析，关联分析，模型分析，能很好的刻画呃组织过程，然后效能上的瓶颈和问题等等。好，这是我们真实的一个需求价值流的交付的一个数据的度量，然后大家看到MR的首次靠me是到哪一天的哪一点，对吧，然后它首次的呃，Approve approve这一那个时间。那这个MR时间线，那这个MR关联，关联几个任务，它有几次，它性能代码行多少三多少它的。

六等啊等等，以及他的整个干动图，然后这个其实对你去掰下段的去更好，去看一些细节的数据来去看我们生产，我们的研发生产活动的问题是有意义的，是有意义的。啊，这是我们的一个M的传统计，从com的到我们的那个，呃，整个部署的统计，以及我们的一些mmr发布周期的干特图，还有我们相关的各种的一些，我要跟MR的一些代码行文件数量，流水线，自动化相关的一些数据全部画出来。那效能这个事情，它能带来什么样的收益呢？呃，那我我以这个实际上以从支付视角来看啊，然后首先有几个点，第一点是说确实是很好的支撑的，规范的落地，包括不局限于个需求的，还有技术种质能规范，我们的一些相关的研发管理的，然后实际上从数据上刻画呢，我们通吐提升了5.64倍。

大家会这吞提升点夸张，我们提升物流设备的，但是因为我们之前推很低，因为当时的时候我们很多的需求都是用五体来管理的，然后都不太爱去上系统的，还有那有有那种接入，所以当时数据基术本来就很低，然后。然后我觉得这个倒还不是最最核心的，最核心的是说基于这样一件事情呢。去搭建和建立起来整么知乎的研发项目的度量体系，包括呃夯时了整个机建能力，就也就是说我大概呃在知乎大用了一年半两年时间做了一件事情，全面的去jar，我们把jar换了，换成自研的平台，就是刚刚的营销平台。我们之前是相当于采购的，相当于是呃，商业付费买家一些license来去做，去管理，后面我们全部用自研的平台。对，所以说这么说是说当一个组织公司，他想慢慢的想要在这个效率这块做的更加的自主和。

都不会。大部分都会走走走向自研，但是我不鼓励自研，因为自研成本也挺高的，大部分会走向自研，反正就几乎就是大概调研之后，后来做的事情，大概用了一年半两年不到吧，就就走向自研，目前我们内部的那个Java的所有相关的呃服务都已下了，没有Java。好，那那呃，后面再聊聊从产品视角来看产品应该怎么做，然后呃，对于产品来说的话，其实整个内部协作工具大多会有这样一些痛点吧，比如说我们的个性化流程比较多，算法部门。流程特别呃辛苦特别拼命的，然后呃，觉得自己开发了一个特别牛逼的这样的工具平台，但业务买单不用这个事情可以，呃可以可以换位到任何在质量部门或测试团队做工具平台开发的这样的社开同学。我开发了一个贼牛逼的自动化测试框架，他又怎么推就推不下去，别人就是不想用，他宁愿去手动点点点他就不用了，还各种说不好用。

然后呢，我我我刚才看反正就是说呃是吧，为什么呢，大大呃反正是结果就是又不用了啊这问题又不用怎么办，对吧。然后这是一个点，一会儿。我们的假用钱啊，还有就是说，当我在内部做平台做工具的时候，呃，我是开发或产品，我也比较关心增长用户。我觉得有关系，我我发现我们之前很多很多同学很多的内部的开发或做内部公平台，特别害怕做做者容易陷入自嗨，你知道吧，我的平台贼好用，就会问有几个人用啊，哎哟，好像就咱团队几个人用，然后整个质量部有100个人不到1/10的用啊，要举例子。然后最后你的故事不好讲，最后数值说我平台特别好用，然后老板又问几个人，呃，不到十个人。对吧，然后呢，你怎么还，你怎么衡量这个产品价值，或者说我开发了自动化框架，我看。

发了一个平台，那这个平台好和不好，从用户视角，你觉得它的价值怎么衡量呢？你通过什么指标策划他那这些都是我觉得这些我呃坦白说啊，我我我我之前也没有这个视角，但是后来做一年做几件事情，发现，发现我们之前做事情的标准太低了，其实你应该有，如果说你这样一个产品视角的时候，是比较容易拿结果和做成功的，好我们我们再来聊啊，呃个性化需求怎么怎么太多怎么办呢。个性化需求，它都是大部分的弊端或内部的产品通用问题，所以说当你随着你你你推动一个效果或任何一个事情变革，推动产品时候，他。不种有90%的需求都是单点的，单个用户的，可能他突然间他就是一下子一时兴起。帮我整个看吧，一生姐给我整个日历模式对吧，但发现哎，除了你除了这个leader的用之后，其他的不利的，其他的都不太用。

然后但是你为了看板咔咔的投了两个人开发了一个月，最后呢，就服务了一个leader，还有八个leader说我用日历就好了，按理说这个事情RY不高，对吧，你应该把这个八个B的搞定就好了，对其财不买单。还有就是我们的产品成。面它NPS降低，就是对于呃，内部平台都会关心个指标，就NPS用户满意度啊，对，然后这个指标其实是比较通用指标，然后这个指标如果它高不代表这个产品一定好用，但它低大部分是说明问题，说你这产品做的比较烂，或者说大ug太多了，然后系统体验太差等等等等，好，那我们我们对这个更换需求，我们我们是怎么做的呢？我们会严格来去按模板提需求，就是说。假如说就是某某人说我需要一个日历看板日历的模式来去看需求，那这个是张三提的需求，那张三。做张三，他可能要用。

就一半的人都不用这个功能，或他自己过往的三个月里面都没有点两次PV都基本上是个位数，我觉得可能，那你就问他是怎么样，是是功能不好还是怎么的，还是他自己就是不愿意用，要是不愿意的话，你下次可以对他的需求能处理，我默认不接你的活了，还不行吗？因为我跟你开，我跟你费脑劲头，两个人开发两个月，你最后能点都不愿意点，那那那完全可以把这个资源投到更有意义的事情方，对吧。租出来，而且就这还有就是我们的大的一些需求的话，最好发邮件去去提需求，对吧，那这样的话到时候加一也知道，这样的话，其实我们。作为慎重，他会想的更明白，他为这个需求我想明白到底该不该去做个能力，还是说我我我线下运营一下就好了，或这个需求是一个个性化，很通用的，对，同时我们一定是要看数据的，看我们的PVUV，看我们渗透，看我们的讲话之类的。

这是我们的需求管理一个流程，然后呃，其实也没有太大的一点，只是说会会会在有些节点会卡点一下，会会会审会评评审一下好业务不用怎么办，然后业务不用的话，如果是真的是不好用，那其实解法就是你要优化需求，优化平台，优化能力。如果。我们有时候就是可能真的忙自嗨了，你忘记去，呃，跟小白用户去做培训，做赋能去跟他去。你没有写用户手册，他真的不知道你开发了一个很牛逼的一个平台或能力，对吧，所以说我们当时会每双周去做产品发布会或内部的，我们会公告，在群里面给我们公告，呃，营销平台V2.3版本上线了，有十个功能，一二三四五六八九十，对吧，然后解决什么问题。然后每周去做一些牵引到的同步，然后和用户建立好很好的互动，告诉他们对吧。然后我们产品迭代，做了什么事情，解决什么问题，那还有就是。

呃，你首先要搞定KOL，就是关用户，就比如说我们张三同学，他是呃质量部门团队的一个测试开发，专门综控平台的，他开发这种框架。然后呢，有ABC3个业务组的QA测试，他都不太用，但他先应该搞定ABC3个团队的一些leader等，就是在做这个需求之之前，就告诉他我为什么做，他这要解决什么问题，对吧，然后能给你带来什么，给你赋能什么，然后让他们如果说他们有这个，呃，有有一些天涯能给你站台，那这个平台推广是很顺的，还有就是说，呃，还有就是说很多时候的话，当你。做都是共建的，反正还有还是有些技巧性的，对。那我们怎么去度量工具产品的用户体验，也就是我们内部的这种工具平台体验度量呢？首先B端和C端的形态是很差异的，B端的我们对于整个工具平台的体验度量大概会有几个维度，NPS我们用满意度，我们整个平台的一致性，对吧？你的导航一般都是左侧的，然后呢R系统是顶部的，差异很大，然后呢，颜色本来都是那种那种这种比较简洁风。

特别繁琐，还有就是说我们首页的这个，呃，性能，首屏的时长渲染要分中级，那好像不太OK对吧，以及我们的应用性，应用性可以通过WUPV和整个渗透和我们的功能使用率来看，来知道你这个功能是不是用的对吧，以及我们的我们的一些效率。嗯，等等。呃，我们我们在在在在支互内部在做整个项目平台的时候，其实绝对是不是呃闭门闭门造句的，然后那个到时候我们那个呃，我们其实在内部呢，嗯，也做做大量的一些这种竞品调研，比如说国内的万，还有我们的几乎对吧，我们国外都是在国外特别特别特别牛逼的一个一个用用管理平台叫三纳，以及我们也对标了，以及阿里云，像百度项目云coding和对，然后呃其实他们本上都是偏项目协同diops或校人这样平台，然后我们做了充分的一些参考来看看。

有利，很多商业的商业产品和内部产品它的定位不一样，商业的话必须考虑是说嗯，开源即用，它需要有很呃，它需要有各种开发平台能力，对吧，但是对于内部的话说，可能开发平台这个事情，就他不是高优的，他并不高优的。好，本质上其实上的平台和代平台，它它它也是属于一个in的，就是基础架构的工具的吧，那对于in刷我们其实属于我们就在哪，我们在哪有部分呢，我们其实可能说在交付这块的这样一个合同，那呃。其实其实那个这里面有个比较有意思就是。

说这个领域的的工分牌很多，但是中国和美国这个，或者中国和国外吧，他们在这国外专体讲就是单体的效率，就是他是觉得那个，呃，我单个工具做到极致就好了，国内是讲究所谓的一站式，呃一大统大统一的，他希望。就是百花齐放的，每个领域都很好，但是国内这边就是大一统，这是一个文化差异。好，我们最后来讲一讲关于整个的研发效能提升重要什么？重要的有两趴，一个是我们自己的技术图壤，就是呃，管理运动作跟在一起，还有是工具也好用，没有工具，没有基建，那我觉得纯人肉的运营这方式是不可取，也是不可持续的，对。然后对于整个校园平台的体会有几点，一个是线上化。呃，我们把整个的研发的生产活动统一哈，统一哈了，其实这个事情当我们掌握了。

啊，已经基础了，或者度量基础了，还有就是说我们从开始在做这样一个平台的时候，就要考虑标准化和数字化。对，然后呃，我们对于整个数据指标的解读，这个事情是要尤其慎重的，前面讲到了。然后再就是我们在这事情上，本质上最开始就要挣，挣的足够高，就是我们他是要能够帮到业务的，如果说你这个平台帮不到业务，帮不到研发工程司，然后只会给他们带来更多的一些一些麻烦的话，那我那想必他们司不会太配合你去去运。所以说。本身还是回到问题，你能帮助这个平台，这个工具。能够是吧。能不知道他们用，他们用起来爽不爽是这个道理。而对于整个研发工程师啊，就是研发效能工程师，其实呃，这个工作是比较难做的，因为因为呃它不直接产生业务价值，它并不直接产生业务价值，它是一个中台，是个成本部门。

因为是吧，那这种情况下，他更多的是for内部的，所以说但是呢，你想想你开发的工具给开发用，给一些公司用，他其实相比比一些又c r c rud公司来说，它其实对于产品的一些功能体验的打磨是需要更精细的，所以说呃。而且各个平台的推广还是研发公司来推的话，他又特别考验这个公司的这个对组织啊，对文化，对对来自于对人性的理解，所以说这个其实对对这个研销公司要求挑战会比较高一点。好，上述就是我今天呃，关于那个整个研发效能的提升的一个分享，然后。