探知数字化研发 - 底座篇

就像汽车工业为了提升生产效率设计出基于模块化的生产方式“汽车平台”，可以同时承载不同车型的开发及生产制造，产生出外形、功能都不尽相同的产品，从而降低成本、缩短开发时间。

而软件研发领域的‘研发底座’也承载着类似的功能，基于分层+服务化+模块化 的形式给业务提供快速的系统搭建能力，小时级响应业务变化的需求。我们可以把它理解为业务生长环境，就像一个蔬菜大棚，提供土壤、阳光和供水系统，你可以在里面种各种蔬菜，而不用给每一种蔬菜都从开垦土地开始准备。具体到研发的车间或者大棚，我们应该如何来梳理它的框架、层次、模块呢？

1、[技术层] 能力汇聚、平台赋能

1.1 业务中台能力

业务/企业中台根据业务特点抽象共性能力，相当于一个积木块。中台能力可以在新业务开发中快速集成进来，如零售业务离不开交易、供应链等服务。在企业架构中，通过应用架构来承载，为业务架构服务。

1.2 技术中台能力

为应用架构提供信息系统的组件，如 API 网管、配置管理，任务调度、缓存等，抽象所有系统的通用依赖。

1.3 云管平台能力

以‘服务自助’的形式提供基础资源、基础组件、系统模板，屏蔽技术细节。起到“消除技术依赖”的作用。就像一个饭店可以给你承包婚宴服务（系统模板）、提供预制菜服务（基础组件）、提供蔬菜配送（基础资源），你可以根据用餐需求就行申请。

具体实现来讲包括：

1）为系统提供基础资源的调度，资源申请，垂直的扩缩容能力，水平的扩缩容能力

2）云 Paas 能力，建站能力（拉起一套新系统）、服务编排（预制菜自己组合）

3）DevOps 的支撑能力，如系统的容器发布，集群管理

2、[业务层] 生态链接、角色协同

1.1 流程规划能力

回顾一下企业架构篇的图一的"项目关注点"，即 IT 的基于企业架构的运营环节，梳理出几个关键的管理领域，研发底座的业务层能力需要满足这几个领域的管理运营要求

• 产品生命周期管理，直接面向企业服务所规划的系统承载能力，即对应用架构的系统节点实现

• 需求生命周期管理，业务需求转化为产品功能，从产品功能转为运营价值。需求管理的几个关注点

1）需求层次定义（业务需求->产品需求->系统需求）及拆分原则

2）生命周期及流转规则定义。数据后期应用到交付和各环节效率评估，流转状态汇聚项目整体进度

3）需求到项目、版本、迭代的引入，关联（任务、物料）成本评估

• 项目生命周期管理，项目承载着研发工作的阶段性目标，也是研发工作运行的核心载体，管理系统需要满足的能力参阅下图。

各研发角色所处项目的不同职能，对项目工作空间（工作台）要求也是不同的，如管理视图，呈现的是项目进度、风险、人力资源分布情况

1.2 工具链路能力

研发过程的每个职能领域都离不开平台/工具能力的支持，完善的 DevOps 能力是构建“产品型敏捷团队，赋能型技术中台”的基础，由于工具链能力的支持，才有了自动化、流程控制、研发效能数据分析的基础。

1.3 角色协同能力

以产品型敏捷团队视角来看，人员/角色配置/产品线是相对固定的，即大家在一个'研发空间'里协同，短期的工作目标通过项目运作，通常有多个项目在同时开展。一个项目的需求也可能同时在多个“研发空间”，跨团队协同，而项目维度视图通过需求的“项目标签”整合起来形成完整的进度信息。

在这个协作模型中贯穿两条线索

1）时间线索，项目维度的版本（分支）迭代

2）空间线索，产品维度的系统（需求）迭代

时间线索像树的年轮，空间线索像树的枝干。通过这两条线索的数据，除了可以回溯研发过程，也能形成立体的研发过程数据。

研发空间实例

1）、全角色，不同角色工作台

2）、一站式，需求->项目->研发->发布->运维->价值评估

3）、基于 Scrum 开发模型，将敏捷研发的每阶段的策略、实践和规范融入

4）、工具链集成，分支管理、流水线、自动化测试、自动化发布、监控、运维

平台逻辑视图：

系统通过调用链接入、SDK 集成等方式接入监控大盘，把监控运维工作一同纳入‘敏捷团队’，实现运维能力服务化。

[线上化+流程化+可视化+服务化+自动化]的平台能力体现数字化思维“消除协作依赖”

3、[数据层] 决策模型、数据驾仓

3.1 指标框架能力

试想面向一个数千人研发人员，数十个研发部门的公司，管理部门如何了解到 IT 部门的交付效率，交付质量，改进方向？所以需要相对完善的数据驾仓来辅助决策。但是研发的数据指标和模型并不是一蹴而就的，需要考虑

1）工具链的集成化能力，就是思维篇提到的“打通经络”

2）管理意识导向，需要根据工作重点迭代数据能力，比如优先规划交付质量指标（如生产问题的缺陷密度），然后到过程的关键支撑指标（测试的代码覆盖，开发的单测覆盖），形成可回溯的分析链路。

3.2 场景应用能力

• 质量门禁的作用在于控制制品流转的质量要求，如单元测试覆盖率未达标，不能进去测试环节发布

关于门禁的定义和配置考虑点

1）管理分级，不同组织级别可以定义不同的要求，不同系统级别可以定义不同的要求

2）发布的代码分支在不同环境间的流转控制，DEV（开发环境）->SIT（集成测试环境）->PRE（预生产环境）->PRD(生产环境)

• 考核、评价、改进在下一[研发管理实践篇]探讨应用场景

3.3 辅助决策能力

1）可参考/对比（业界对比、集团对比）的全局和结果指标呈现，了解能力差距

2）细化质量和效率评价，评估改进方向

3）支持组织级自定义的看板展示

附：大厂对于指标能力关注情况

图片来源：ONES 研发管理大师课 《研发效能度量的国内外行业动态》-张乐