前两天在一个DDD的研讨群，讨论准入门槛和执行难度的时候，突然就歪到是否可以从研发效能改进进行切入。
在降本增效的主流导向下，研发效能好像被提很多，虽然很多内容都是新瓶旧酒，但很多时候，技术就是这样，本无罪，更多靠天时地利人和。
同时这几年，甚至我觉得接下来的好几年，更多被提及一个话题是数字化管理。
这两年直接的或者间接的参与了几次研发效能的改进，所以脑袋一热，以研发效能一事，记录一下一种大致可行的数字化管理建设的思路。
大致思路
从现实世界中发现，整理，记录数据
- 数据的开采
- 文字，图片
- 日志，记录
从数据中识别，聚焦核心价值数据
- 企业生存发展的主要核心
- 行业相关的价值数据
- 决策依赖信息
加工数据信息，分析总结，修正认知
- 指标体系演进
- 整合分析，关联分析
- 判断问题域️，确认问题路径
- 引入数量模型，算法性的预测分析
决策，提炼，标准化，以及解决应对方案
- 整合专家经验，个性化的预测判断
- 统一认知的情况下，提出解决应对方案
- 修正行动标准，提升生产力
关联研究范式
- 实证研究
- 数量分析
- 定性定量/指标体系分析
第一原理准则
- 观察变化，发现本质
- 不违背客观
- 噪音的分辨，比例弱化
团队分工建议
- 企业决策者（认知统一者，解决方案可行性，团队负责人）
- 市场专家/业务专家/PMO/QA（经验提供，指标体系核心，执行负责人）
- 数量分析团队（数量规则算法模型，客观性偏差修正，指标验证、体系搭建）
- 技术支撑团队（自动化，数据可靠性，数据规模，数据运算）
研发效能的数字化管理
目标
- 提升团队交付速度
基础数据来源（大范围数据采集，宽表采集）
- 内部知识库
- GIT API
- 项目管理工具接口，数据库
- 内部系统接口，数据库
- 人工整理Excel
过滤团队交付相关数据（数据整理计算，聚合）
- 需求文档（数量，前置消耗，紧急程度，人力规划，时间规划）
- 代码实现（commit数量，新增代码数量，修改代码数量，删除代码数量）
- 质量相关（sonar缺陷数量，测试bug数量，回归次数，最终完成时间，最终投入人力）
整理分析数据，寻找关联，发现问题（指标体系）
- 规划资源和实际资源的差异 -> 需求评估准确度不够，团队负载过大，外部依赖存在沟通障碍，环节存在阻塞
- 需求涉及到的代码整体规模 -> 需求是否可以进一步拆分，有效代码比例
- 历史代码修改频次 -> 历史代码存在设计问题，需求变更，出现大泥球，
- 代码修改删除原因 -> 是否存在技术债，是否需要重构
- 代码体积复杂度与缺陷关系 -> 常见复杂度问题和缺陷问题
- 团队人员健康度 -> 团队本身特性和个性偏好，有效工作时间，内部分工协作，工作环境
总结优化解决方案（成果，执行）
- 需求评估流程及标准优化 -> 明确需求内容，业务边界，关联业务依赖及影响，技术设计，多方参与评估
- 代码架构设计优化 -> 区分业务复杂度，技术复杂度，遵循整洁架构，业务技术结耦，技术反向依赖业务，提升复用
- 研发流程优化 -> 质量左置，CR规范，研发工具引入及升级，敏捷，结对
- 团队健康度提升 -> 人员调动，环境改善，职能明确，内部管理制度改进
关键点
度量指标的确认/指标体系建设
需要从自身业务方向出发，选取核心关联内容，建立长期的或者针对性的度量指标，并形成自有的指标体系，全局认可并支持演进。
类似北极星指标，产品的MVP原则，这一块是数字化管理建设的难点也是价值点，而且千人千面，合适的才是最好的，很需要投成本来做。
比如以服务客户为业务和生存核心的时候，需要关注需求来源可靠性，需求前置确认的难度和时间，需求变更及预估，整体交付时间，客户反馈；
以研发成本控制为核心的时候，要关注需求规模数量，历史技术债，技术团队负载，人员团队构成，外部资源依赖，自动化及工具使用情况等。
基础数据的采集及质量
需要对相关的技术工具进行引入，来实现自动化，包括采集，存储，规模计算等，属于技术性工具，需要先进性和可靠心，对技术团队存在要求。
对关键数据的产出进行规范，约定及补全（强制commit规范，编码风格统一，devops自动化，需求过程全记录，资源投入记录，需求追溯）。
基础设施：gitlab，jenkins，sonar，cicd
项目管理：tower/tb等kanban，jira/pingcode等具备API能力的项目管理平台
测试管理：https://metersphere.io/
知识库：企业微信/钉钉/飞书
数据呈现：各种大屏系统
其他的还有编码规范（ali，google），提交规范（git flow）等等
本质原因的挖掘与认知
数据分析时要非常明确很多数据只是表象，是具备迷惑性的，需要挖掘背后的本质。
比如交付延期了，经常能够看到的直接数据原因是技术团队负载过大，太多需求同时输入，bug多，测试周期长。
虽然最直接的解决方案可能是加人，但需要明确造成负载的本质原因是什么，是业务拓展导致的需求规模增大，是多方沟通传达出现问题造成需求或者理解多次发生变化， 是标准或流程混乱导致的有效工作时间地下，还是团队素质或者态度等健康度导致的产能下降，然后再有针对性的进行优化解决。
这一块是最热闹的，非常容易干架然后还解决不了问题，因为很多是看不到的，需要很多个角度来辨识，而且各个职级能给出的结论通常都是正确但是又局限的，这也是最需要决策者的时候，这个人要有足够的认知高度，兼具决策力和判断力，同时还要有沟通能力，让人信服，能够说服大家都认可问题的归因方式和本质，让相关人能够支持、至少有条件的支持改进方案并配合执行。
对经验的尊重
要尊重市场行为，尊重专家经验，在数据分析的基础上，需要结合经验和业务目标，做综合性判断，不能只拿数据说话。
数据是工具，度量是工作，实现目标才是所谓的可能成功。
很多事情需要综合判断，根据数据初始化，根据经验调优，然后结合实际不断迭代改进，建立度量和分析长期体系化，并过程化成长演进，要具备基础知识，但很多时候尽信书不如无书。
题外话
研发效能是一个属于决策层的事情，高管，部门经理，总架构，人力资源总监这些人是直接干系人，对不同的人意义也不太一样。
高管关注的是成本收益转换，经理关注的是目标完成度和客户满意度，总架构关注的是企业结构和技术结构的整体稳定可持续，人力资源关注的是激励绩效制度和团队人才建设。
不要和程序员谈研发效能，跟一个开发谈研发效能，大多数情况下他会认为公司是不是要拿这些数据扣绩效，少发钱，然后你就完全可以相信在造数据这种事情上，没有人比程序员逻辑更缜密，而这只会增加对实际问题判断的难度，对实际解决问题几乎没有帮助。
我个人认为，程序员的绩效应该只和生产事故挂钩，其他所有的扣绩效行为，都是为了掩盖非研发环节的过失，以及体现领导的无能，听懂掌声
无责任推荐：
Apache DevLake 开源研发数据平台
https://devlake.apache.org/
一个开源的研发数据平台，可以聚合devops常见工具的数据，同时内置了很多常见指标集，如果企业想做研发效能，又完全没有思路的时候，可以先看看这个工具能给出的东西。
国内的商业化团队叫思码逸，专门针对研发效能提供解决方案的，你看能省钱的地方，其实都能赚钱。
飞致云 MeterSphere 开源测试平台
https://metersphere.io/
一站式开源持续测试平台，包括用例管理，计划，自动化测试，缺陷记录报告等一大篮子的功能，集合型平台。如果研发迭代比较快， 测试团队工作量大，很需要问题追踪管理，同时又苦于各种测试工具比较独立分散的，可以试一试，有jmeter等并发测试，也有多环境支持，还有前端自动化测试。
国内的商业化团队叫飞致云，同时是jumpserver的东家，前同事在里面担任要职，对他家东西有兴趣的，可以找我要联系方式。
字节 DevMind 研发效能相关资料
https://www.infoq.cn/article/oiyyltdpp4yx1ifhs4a8
字节的研发数字化管理平台，是很完整的一套落地技术实现。字节给出了很多研发效能度量的概念和方法，有一套很全很完整的方法论。网上可以搜的几篇内容，都很具启发性。
不过字节这套东西，太过完备了，就导致他几乎不具备复制性，不是那种非常技术导向的公司，我个人感觉完全不要尝试这种东西，容易赔了夫人又折兵。还是从最适合自己情况的，最简单的开始，北极星 plus mvp，一点点搭建。
本文由 Ivan Dong 创作，采用 知识共享署名4.0 国际许可协议进行许可
本站文章除注明转载/出处外，均为本站原创或翻译，转载前请务必署名
最后编辑时间为: Jun 30, 2023 at 07:44 am