摘要：文章内容主要来源于光环国际2022年第三届中国科创者大会姚冬老师的分享，原分享名称为"数字化时代的研发效能建设"。讲述了华为在研发上整套流程规范，通过云的方式去实现人机协同，保持人去做创新型工作。对人才梯队建设做了要求，特别是核心人才一定是需要懂管理也会编码，鼓励工程师多去和客户沟通，站在项目战场线上，形成全能小团队，自己去思考定位和养活自己。也侧重的表达了质量和安全重要性，因该贯穿全流程。
1、需求收集、客户沟通、业务设计、架构设计、开发代码、完成代码这些阶段活动都是增值，都会往发布包里面增加特性、功能。测试、部署、运维这些阶段活动理论上都是非增值，因为没有增加任何一个代码、核心。在软件开发中，非增值活动在整个过程中占比较重（要求做的好一点预计占到50%）
2、人和机器之间进行有效的协同，真正的让重复工作由机器完成，让人可以去持续做高增值、高价值的活动，这个是研发效能根本目的。
3、“核心人才”做到承上启下，带领团队，跟随推动组织向前走。主要重视这一部分人的培养和留存，建立梯队，有序的流动，不能流动的太快。
4、代码不是机器去读而是人
一、研发效能如何搭建
1.1 研发效能定义
研发效能是近几年出来的一个比较火的词，什么是研发效能，和敏捷和DevOps有什么关系。个人对研发效能的定义为：持续 并且 快速 的交付 高质量 的 有价值 的软件给客户。加粗的形容词是关键字，纲要。
研发效能有两点“效”和“能”，“效”也有两个含义，其中一个就是“效率”，快速就是指的效率。另一个就是“效果”，高质量、有价值就是指的效果。所有的效果都是由客户、用户去定义。“能”就是指能力，是否具备既有效率又有效果这样的一个能力，能力不能是一次性或者突然的，为了满足某一次上线的冲刺，而是可持续。
下图是一个研发效能端到端大的流程，一个典型的研发流程，有产品创新，大段的开发工作，发布上线，产品运维。从需求收集、客户沟通、业务设计、架构设计、开发代码、完成代码这些阶段活动都是增值，都会往发布包里面增加特性、功能。从测试、部署、运维这些阶段活动理论上都是非增值，因为没有增加任何一个代码、核心。在软件开发中，非增值活动在整个过程中占比较重（要求做的好一点预计占到50%）。
所以，软件研发效能做的是如何让这些非增值活动去争取一个极致的效能，比如通过工具自动化去完成，自动化后就可以保证效率和效果一致性。无论做10次、100次都是按照定义的流程、规范、要求完成，保证一致性。工具就是指机器，那么人有擅长什么了？
人擅长创造性这一部分活动，去整体保障效果。比如要做一个什么样的产品，它的方向是什么？客户想要的是他话术背后的隐藏的含义，人是擅长去抓取这些信息。这就是为什么要由人去在元宇宙中做职工，因为机器传递不出人的情感，抓不住客户的真实灵感。人和机器之间如何进行有效的协同，真正的让重复工作由机器完成，让人可以去持续做高增值、高价值的活动，这个是研发效能根本目的。
贯穿始终的有几条线：①测试：质量的保证，②安全，③可信：是否值得信任。
1.2 华为如何搭建研发配套
华为传统是做电信业务，随着最近几年做终端设备（手机、电脑、路由器等）才逐步让更多的人知晓华为这家公司。电信业务主要就是交换机，比如2G、3G、4G、5G网络相关业务。华为内部产品非常丰富，除了终端、交换机、还有换华为云，既有纯硬件，也有纯软件，同时也有两者结合的软硬件一体化。
华为历经30多年的发展，走过了成立之初的个人英雄主义，比如能看见的郑宝用、小徐总(徐直军)。在90年代中后期时，发展可持续，避免前面可能说一个产品是偶然成功，在下一个版本可能就会黯淡情况。这里推荐一本书《从偶然到必然》，这一本书讲述华为完整研发体系，集成产品开发 （Integrated Product Development, 简称IPD）。99年从IBM中引进，从先僵化、再固化、到优化用了将近5年时间。然后接纳很多业界的实践进行自己优化，比如持续集成、持续测试、敏捷到现的DevOps，在18年的时候产生华为自己的一套体系“可行工程”，在内部通过指标去做牵引。
①指标一：“六问一”，也是DevOps中的 MTTR (Mean Time To Repair，平均修复时间)，就是当一个服务宕掉的时候，多快的时间能恢复过来。给到一分钟时间，这么短的时间，就不是由人工的去检测发现问题，然后再切换回来，一定是工具自动化帮助完成，自动故障检测，自动恢复，推荐通过生态云、容器等等这样的基础去搭建。
②指标二：需求到闭环，就是客户的需求提出到完成、到上线，这个是一个平均的指标。就是敏捷 Scrum Time 或者 Lead Team 前置时间（采购方开始下单订购到 供应商 交货所间隔的时间），是客户可见的。华为在前置时间下，需要每周迭代。
①基础设施云化，以往可能有大量服务器、终端，各个部门在需要使用的时候去采买。过了这个时间阶段后，经常就会被闲置，资源利用率并不高。当把这些资源集中在一起，就可以有效去提高利用率。而且需要这个环境的时候，不用去跑到机房去搭建环境，只需要在页面点击按钮。
所以这里就用到云计算，虚拟化、容器化，包含DevOps中重要词汇基础设施即代码。把基础测试描述（如需要几G，什么系统，数据库中间件是什么，他们相关的配置、应用的版本是怎样）通过脚本化描述出来。
那么，能通过脚本化描述出来，就可通过工具自动化，以此保证高度的一致性。同时把环境和代码绑定到一起，一个标签打出，它所依赖的代码、底层环境一定是一致的，就不存在这个环境能跑，另一个环境就不能跑甩锅情况。
二、产品研发运维全过程
2.1 年度目标制定
下图为华为一个研发全景图，最上面绿色部分是一个大的战略或者战术计划，在每年年底时候就会做下一个年度规划，称之OBP。这里就会定义出来，明年的目标是什么，要挑战的目标是什么，跟OKR相结合，定下计划后，第二年会在季度上进行发布。按年做规划，按季度做大版本发布，这样所有服务都会向版本对齐，保证步调一致。
下方是一个过程，分为Dev 和 Ops，在Dev一侧会有以下几个贯穿始末：
①需求：需求是一个来源，也是一个目标，所有设计、架构、开发、测试等等都是因需求而来。在研发的整个过程中，都应该与需求做对齐。需求不是在前端设计完、分析完、采集完就完事，代码任务需要和需求相关联，测试标准、测试用例、测试结果数据也来源于需求。然后发布的版本，版本二进制包中包含哪些功能、缺陷、修复、生产环境也和需求有关联。
②流水线：流水线也是把这整过流程去惯穿。
③测试：测试不是开发完成后开始进行，在需求阶段就引入进来，站在测试角度看这些功能有哪些边界、异常等等。去验证测试的扩充性、稳定性等跟功能无关的非功能性需求（Non-functional requirements），这些都是架构师需要考虑的问题。
④安全：经常看见安全是上线后进行的安全巡检，做一些攻防演练等等，其实不是这样。安全一定是在早期设计阶段引入安全，否则不能保证开发的应用是安全内置的，不能依靠最后的验证去保证安全，这样效率也低下，效果极差，所以安全是贯穿始末。
⑤第三方：指开源，这一个无法回避也无需回避，同时应该极大的去利用它。在使用的过程要小心，保持警惕，包含对开源协议的了解、开源中可能存在的一些漏洞、版本依赖关系，一旦出现漏洞怎么快速检测到，怎么快速修复，同时让整个组织应用到你的包。
在Ops一侧主要是运维工作，主要是如何自动化和运营。
2.2 组织文化
对于华为而言需要的是，如何高效的、快速的去做一个创新。以往是跟随战略，主要跟随电信设备商，在十多年前华为已经做到很多领域第一，以前的跟随战略就不生效。在无人区，自己如何去做引领，做领航者。
2.3 人才梯队
所有都离不开人，如何取培养、留住一圈精英的人？华为有一个人才金字塔模型，经常会听见华为招聘某天才博士，比如前年有博士造出会自己行走的自行车。这些领军人物，在关键技术领域的突破确实起到至关重要的作用，华为对于这些技术领袖是非常非常看重。他们的职业发展可以跟各级部长、董事长都是匹配的。在内部一个 Title 叫 fellow，就是一个院士，其级别非常高。但是这些人非常少，中流砥柱主要就是红圈标注的“核心人才”，做到承上启下，带领团队，跟随推动组织向前走。主要重视这一部分人的培养和留存，建立梯队，有序的流动，不能流动的太快。
如何去体现工程师价值，让其即动手又动脑，这就是华为目前想做的一件事情。在此之下就是团队如何建设，构建高绩效团队，如何可被客户信任的交付。可信任就是质量保证、需求满足、周期内交付并和客户保持优秀的沟通，最后就是整体的去构建业务的竞争力。业务竞争力中需要强调的是所有的主管都需懂业务，关心业务，不是闭门造车。研发费用拆解完成一定是从业务侧而来，研发的产品它的市场是什么，用户群体是什么，市场竞争力是什么，收入从哪里来，这些收入需持续构建。现在非常重视开发者生态，比如说整个运营手段，也是源自于此。
①业务交付能力 ：项目管理能力、工程能力
②专业技术：技术领先性、架构要求，
不能只懂管理还需懂技术，在内部有要求写代码的需求，1年往代码仓库中（核心需求）commit的代码有多少。
2.4 代码检测
代码质量方面有一个Clean Code要求，如何让代码是好的代码，有哪些标准或特征。代码不是机器去读而是人，后来肯定有人会帮你去更新维护，90%以上代码一定会涉及到修改，在修改的时候不是同一个人，所以代码的可读性、可维性是代码整洁的核心。在华为有一个Committer机制，所有的代码都需要经过开发者自测，提交上去后，有一个门禁会进行检查，通过门禁后会有一个Committer帮助做评估，保证提交到主干代码一定是经过筛选。
2.5 测试能力
为了提升开发工程师的测试能力，进行了如下的一个培养方式。前期由测试人员培训，后面逐渐转成以开发人员自己为主，到独立自主偶尔遇到问题测试人员进行协助，最后整个团队都具备了测试能力。
2.6 质量守护
在质量里面会有很多质量的看护流程。
应用在开发转测试的时候，有需要达成什么条件规范，到达测试后，测试阶段又有分级分层的测试。比如集成测试、BPI功能测试、性能测试、压力测试、安全测试等等。做完这一些后，再去做端到端的测试。由测试转上线应有需要达成什么条件规范，这个叫测试左移或者测试前移。在上线后还会做大量的测试，比如线上的巡检、倒流测试、混沌工程等等。
每一个节点都会有不同的人员去参与，SDE会很忙，从架构设计、开发、测试、运维都会以SDE为主。
2.7 安全
安全应该是贯穿始末的，所以在需求阶段、架构阶段等各个阶段，都应该植入安全相关措施。
2.8 度量
最后讲一下度量，度量在讲效能的时候都会比较关心，具体的度量指标有过程性和结果性两个维度指标。所有的指标都应该是工具在过程中去抓取下来，最后去汇总形成一个展现，对不同的人员看到不同的内容，因为他需要看到内容不一样。
2.9 创新阻碍调研
我们需要的是软件创新，是什么妨碍了软件创新，下图为一个调研报告，其实技术层面占的不是很多，还应该从文化、团队等一些因素做建设。
三、在线答疑
1、DevOps投入占研发投入的总占比是多少？
答：不仅仅是自动化工具，在华为整个研发会占收入的百分之十几（预估14%），华为每年的收益在 7000 ~ 8000亿。研发效能研究占研发的占比具体不清楚，但是会是上亿的投入。老师部门主要承载公司内部工具建设，以前叫做<2012实验室>，主要研发新技术、前沿工具引入，然后给各个产品线去提供这些能力。就是搭底层给各个业务去使用，逐步这部分提取到华为云，因为内部本身也在云上，在华为云对外提供之后，顺带研发能力也对外提供，当然对外和对内还有有一定差异。
2、感觉devOps 对各个要求都是全栈？
答：对，希望是全栈，但是事实上不可能所有的都是精专。努力做到从T型（一专多能），到现场的多专多能。
3、小公司也需要投入这么多占比去构建DevOps体系吗？
答：个人觉得小公司要考虑的是存活问题，而不是更快的效率，更高的产出比。适度的客户满意度，不可能要求极致的质量。需要去背负一些风险，质量一旦出现问题，这个风险一定要去抗，但是不一定去修复它，要去平衡。明确小公司不能投入这么大比例，可去使用开源工具、云上服务去快速构建。增加的时候再逐渐去还这个风险债务，发展到一定的阶段后，不能承担失败风险，再花更多精力在这上面。
