ChatGPT在正式交付之前，每输出一次结果，就会接受成百上千次的问询和打标：做得够好吗？​

对于企业研发效能建设，或许可以用同样的方式，鞭策组织和团队持续进化，用数据度量、经验分析和文化渗透促进组织自我升级。​

世界五百强企业如何进行研发效能建设？海亮教育科技致力于打造有竞争力、可复制、可推广的教育科技产品，助力学校快速提升管理和经营水平。近日，在飞书“项目管理社区”，海亮教育数字校园研究院效能负责人陈华亮，分享了海亮教育持续进化的研发效能建设实践。立足数据和经验，倚赖组织文化和关怀，借力飞书项目智能工具能力，陈华亮为海亮梳理出了一幅清晰可观的效能图景。​

下面是陈华亮的分享：​

​持续进化的团队才能成为卓越团队

大家好，我是陈华亮。

我相信大家最近都被一项新技术所打动，就是 ChatGPT。 ChatGPT 是如何获得强大的能力的？有些朋友可能会知道，ChatGPT 正式交付给用户之前，每输出一项结果，就会收到大量反馈，然后对结果进行打标。正是因为有这种做得好不好的反馈，它最终具备了这样强大的能力。

我们认为持续进化的团队才能够成为卓越团队。我们的团队如果也能够像 ChatGPT 一样，能够在做完一件事情的时候不断地得到关于它的复盘反馈，那它就能够自我升级、持续进化。

所以我们一般会怎么做复盘？

不外乎就是这样的一个经典思路：必须有数据化客观结果的支撑，也因此需要有数据总结；光有数据呈现的结果还不够，我们还得去做经验分析和复盘，即在客观数据的基础上，结合实际的工作经验进行进一步分析的过程。

数据总结的大前提其实就是过程在线。那过程在线怎么去做？

首先，这些数据不是凭空产生的，一定是来源于常态化的研发过程。

其次，如果我们的数据采集会带来额外的负担，并且难以确保我们的数据产生足够的效益，那我们宁可先不采集。

再次，如果能自动化采集数据，就不要去手动填写。

所以也非常感谢飞书项目强大的自动化配置能力，帮我们做了大量自动化采集数据的工作。

​

​​

数据总结之后，就要去结合经验去做复盘。经验复盘的关键思路就是洞察问题、下钻原因。其实问题原因的下钻维度，不外乎是哪个团队的问题、哪个人的问题、什么时间段的问题、什么类型的问题。归根结底，仅仅看到问题是不够的，还要一步一步往下钻，直到这个单元能够有人负责、能够独立解决。

​

​​

效能度量的终点不是考核，而是指导改进

那接下来就围绕着数据总结，展开讲一讲绕不开的最经典的效能度量话题。我们的效能度量的终点，绝不仅是为了考核，而是指导改进。因此，我们借助飞书项目强大的度量能力，搭建起了海亮教育研发效能建设的数据舱。

我们是一支已经相对初具规模的研发团队，也处于一个快速发展的阶段，可能这段时间集中精力在这两条业务线，过了一段时间就会转移到另外两条业务线上，那这就要求研发团队具备快速响应的能力。

首先，我们团队非常关注响应业务需求的机动能力，即响应需求时调配资源快速响应的能力。基于这样的能力拆解，我们定义了一个关键指标，叫做业务需求响应时长，即启动开发日期到需求完成日之间的时间间隔。直接选取启动开发的日期能够排除掉不必要的数据干扰，因为我们最终希望提升的改进方向是需求响应策略。​

​​

在这个实践过程中，我们也收获了一些心得：

第一点，我们需要对这个指标定义达成共识，即怎样算需求完成标准。

第二点，我们需要建立这个指标的趋势线，这是能很好反映过程改进情况的一个抓手。

第三点，想要去探测问题具体原因并总结改进，还需要可以下钻明细数据的辅助图表。

第二个就是核心任务的人力产量矩阵，类似于业界中提到的一个概念——研发浓度，这个浓度越高，就说明大家的这工作专注度越高。核心任务的人力产量矩阵可以从几个方面来提示问题：

首先，面向组织负责人，第一可以反映人力投入是否符合预期规划；第二可以看出人力投入是否产生了匹配预期的业务价值。

另外，面向一线管理者，可以看到团队人力资源是否被合理均衡分配，也可以看到团队成员的非核心工作过程是否具备提效的空间。

核心任务和迭代核心任务占比，就可以反映团队协作成熟度。我们更加希望通过这个协作过程的改进去压缩闲置或者低效的工时，比如通过并行的作业去缩短依赖等待时间，又比如提升沟通效率、完善质量管理体系。

​

​​

第三个是迭代质量。如果只有一个指标衡量我们的迭代质量，那就是来自需求方的评价。但是仅仅只有这个评价是不够的，因此我们的迭代质量，除了包括来自产品经理对产品质量验收的人工评分，还包括来自技术团队对产品经理的需求文档质量的人工评分和通过数据计算的开发交付质量。而在飞书项目上，几乎不需要增加任何其他工作，我们就能把每一期迭代的开发交付质量分给算出来。

​

​​

第四个就是缺陷原因。我们有一个管理熵增，要求开发人员解决完每一个缺陷的时候，就去标记一下这个缺陷产生的原因。为什么我们要做这样的管理？因为处理缺陷往往占据1/3左右的时间，这其中蕴含着很大的优化空间。因此，我们想要重点去抓因为主观意识导致问题的原因，然后下钻分析这些问题的关键原因。

​

​​

最后一个就是异常洞察。这些异常问题其实是符合二八定律的：20% 的极端情形，往往占据了 80% 的改进空间。所以我们建立了一个专项的异常洞察图表，去做各种各样的排行榜，把我们认为最有问题的数据排在最前面，通过关注最异常、最极端的任务，去发现任务拆解不合理的问题。

​

​​

组织文化是生生不息的效能源动力

其实上面所说的度量，其实是植入了我们的组织文化的，所以我们认为组织文化是生生不息的效能源动力，认为软件研发是一种社交活动，它无时不刻不充满协同。在我们的社交活动当中，文化共识发挥着至关重要的作用。

我们内部有一个自创词，叫做 Sipu ，它实际上是一个基于组织文化的敏捷实践。它的主要思想跟方法论其实来自经典的敏捷开发框架 Scrum ，我们在它的基础上面做了一些简化跟补充。Sipu 围绕简单（Simple）、高效（Speedy）、阳光（Sunny）的核心文化，以及我们海亮教育其他相关的组织文化去设立的。

这三个文化是跟我们的研发效能息息相关的。

“简单（Simple）”：衡量流程机制的投产比，对工作鲜有帮助的包袱越少越好

“高效（Speedy）”：一次把事做对，效率是最高的；更小的颗粒度，更早地暴露问题，能更好更快地修正错误

“阳光（Sunny）”：追求信息公开共享与过程可视，推崇聚焦事实、直奔主题、没有层级、果敢评价、虚心纳谏的沟通氛围。比如我们在飞书项目的信息管理几乎都是公开共享的，所有的过程都是可以被看到的。

在经典敏捷框架里面，有一个叫做 Sprint Backlog 的概念，即一个迭代冲刺的待办事项。但是我们最终选择去除了它，简化工作层级，给团队更大灵活性，有能力的团队仍然可以按照这个方式去做，没有能力的团队就精简他的负担，可以给出更适应他管理方式。

同时，我们在过程中强化流程节点和流程中所需的交付物，这也得益于飞书项目强大的流程管理能力。可能敏捷概念本身并不强调流程与工具，但实际情况是组织内部并不是所有人都对我们的目标和协作分方式有深刻的潜在共识，所以我们不得不做一些必要的流程跟交付的固化，引导团队采用正确的工作方法。

至于我们为什么引入缺陷、产品验收、质量评分这样的环节，其实就是想要更阳光地去呈现我们迭代质量的验收意见，通过我们的反馈指导改进。当我们没有这个质量评分的时候，产品经理也会在私底下评价，还不如直接暴露问题，为团队带来更大的价值。

谈及这些文化，其实还蕴含着我们对研发过程的沟通文化的重视，简单、高效、阳光其实也都是在做一部分关于沟通文化的诠释。我们认为研发软件具备跨职能协同的复杂性以及需求描述的信息复杂性。低效的沟通协同是非常影响工作效率的，错误的理解也会带来严重的后果，所以我们甚至还约定了一份关于沟通的共识公约，目的就是让大家能够对事不对人地去思考怎么达成双方的共识，怎么达成产品经理与技术团队的共识，怎么达成技术团队之间不同职能之间的共识。

​

​​

因此，让效能持续进化的关键就在于从反馈中汲取有用的经验，从数据中找到改进的方向。我们也希望每一个组织、团队和个人，都能够在工作过程当中接收源源不断的反馈，在数据和经验分析中持续进化，变得更加卓越和优秀。​

​