平台级 toB 产品的研发品控管理解析

前言

产品质量是吸引和积攒用户的重要因素，业内不乏由微小 bug 引起的灾难事故，对用户或公司造成巨大的损失。从业务角度，质量是产品口碑、市场、收益背后的助力；从技术角度，高可用性是衡量系统架构的核心指标之一。对质量的高要求并不区分产品类型，但是从研发团队的角度上，toB 产品的研发团队更加需要强化品控的意识，尤其是平台级 toB 产品。

腾讯云云开发是一个一云多端的应用开发平台，日调用量达 7 亿多次。作为一个平台级 toB 产品，云开发的研发团队又是如何做好研发品控管理，以确保交付的产品高可用呢？本文将从职能分工、研发规范、研发流程三个维度，与大家分享云开发研发团队的品控管理。

平台级 toB 产品的质量危机和信任危机

平台级 toB 产品提供的功能大多是细粒度、可组合的原子能力，B 端开发者通过组合不同的能力完成业务逻辑，属于 C 端应用背后的间接支撑。

toB 平台不直接接触 C 端一线用户，发生问题后需要经过二次传导才会影响 C 端逻辑。这种性质决定了 toB 平台在产生质量问题时与 toC 产品的两个差异点：

• 影响面大

• 反馈链长

影响面大

以云开发为例，B 端开发者针对不同的业务模块编写对应的云函数，某些云函数也可能被多个业务模块之间共用。一旦支撑云函数运行的底层系统出现问题，其影响范围可能会覆盖多个函数，进而扩散至业务逻辑层造成无法预估的破坏。

反馈链长

C 端用户在使用应用程序遇到问题时可以通过客服、社区等方式反馈，很多研发团队还会提供直接联系研发人员的渠道，目的是尽快收集问题并且第一时间解决。而使用 toB 平台开发的应用程序如果问题的症结在平台本身，B 端开发者则需要经过一轮排查之后进一步反馈至 toB 平台的研发团队，反馈链远比 toC 产品更长。这从侧面表明 toB 平台品控的敏感和重要程度。

toB 平台的质量危机极易引发信任危机。toB 平台作为生产工具为客户提供价值，一旦出现质量问题，客户对产品信任度将直线下降，产品需要恢复原有的信誉、口碑极其困难。需要时间、数据、市场等组合拳去挽留。事实上有一些 toB 公司就是“千里之堤溃于蚁穴”。

产品质量的把控并不仅仅是技术问题，高可用的系统架构背后同样有流程、分工等人的因素。研发过程严格的品控管理是保证产品质量的必要因素。云开发作为一款平台级 toB 产品，支撑小程序、Web、移动应用等多端平台，下面将简单介绍云开发背后的研发流程管理经验。

腾讯云云开发团队研发流程管理

首先介绍一下云开发研发团队的职能结构，一次完整的迭代流程中存在以下职能：

• 项目经理 PM：负责发起需求宣讲和评审，把控迭代节奏，保证在预排期时间内顺利完成迭代；

• 产品 FO（Feature Owner）：一次迭代需求很可能涉及多个子需求，每个子需求由指定的产品经理负责，产品 FO 把控主需求。产品 FO 往往由负责某个子需求的产品经理兼顾；

• 技术 FO：同产品 FO 的角色类似，技术 FO 把控主需求，每个子需求由指定的研发人员负责。技术 FO 也同样由负责某个子需求的研发人员兼顾；

• 产品经理：负责子需求的产品把控；

• 研发人员：负责子需求的技术把控 ；

• 测试人员：负责集成测试、多重回归并且在研发人员配合下完整测试 case 清单的制定和审核；

• 运维人员：负责与产品和技术人员评估可能存在的风险并提前预案并实施。

金字塔形的职能结构能够覆盖迭代需求中的所有细节，并且由于产品 FO 和技术 FO 的总筹调度，当子需求发生未提前预估到的风险时也能够从全局的角度及时协调各个子需求的优先级和人员分配以保证整体进度的正常推进。

研发规范：坚持“三隔离”法则

通用的研发规范分为技术和流程管理两部分。

技术方面，为保障研发环境的安全性，相关人员需严格遵守“三隔离”法则，即：环境隔离、权限隔离和网络隔离。

环境隔离

完整的迭代周期需要经过研发、联调、测试、发布流程，每个环节都分别对应不同的环境，各个环境之间的数据不能共用和混淆。

• 开发环境：即研发人员独立的环境空间；

• 联调环境：前后端联调所用的环境；

• 测试环境：开发完成后集成测试的环境；

• 体验环境：测试完成之后供产品经理体验完整流程的环境；

• 预发环境：灰度发布之前有一个完全仿真现网的预发环境，此环境的数据与现网共用，用来做发布前的最后验证和缓冲；

• 现网环境：即线上环境，发布现网需渐进灰度。

权限隔离

对于涉及服务变更的需求，研发人员不能直接登录服务所在的服务器进行变更，必须经过跳板机授权。权限的严格隔离是为了维护服务器的稳定性以及权限的集中管理和收归操作。

网络隔离

办公网络、开发网络、公共网络之间的可访问权限分离，这对于 IT 研发来说是普遍的规范。

在流程管理方面实施以下原则：

• 提前预案：对迭代需求可能存在的风险进行提前预估和预案；

• 研发测试排期 1:1：一次完整的迭代周期一般是 4 周，研发和测试的排期分别占据 2 周。

研发流程：品控意识贯穿全流程

在整体流程上，云开发与其他大多数研发团队并没有太大区别，一次迭代流程依次经过评审、研发、测试和发布。品控意识体现在细节把控上。

需求宣讲

需求宣讲是发起迭代后的第一个步骤，PM 发起宣讲会议，有需求的产品经理们在会议中描述需求的背景、优先级、重要程度、成本以及预期等细节，所有参会者们共同对所宣讲的需求进行评估，确定是否加入到本次迭代中。最终宣讲结束后确定本次迭代的需求清单，进入技术评审环节。

技术评审

技术评审由项目经理发起，所有职能人员均需到场。产品经理提前建立需求单，在发起评审时进行逐行逐字描述，然后由研发人员和测试人员进行技术可行性评估，对需求描述中不清晰的地方进行讨论和纠正，以及预估可能存在的风险和对应的预案。需求明确后给出研发和测试方案以及各自的排期。研发和测试的排期比例为 1:1。

研发

在进入研发阶段之前，测试人员需要根据本次需求产出测试案例清单，并且由研发人员和产品经理共同审阅、补充和纠正。

前后端研发人员在各自的开发环境中编写代码，如果涉及服务变更则需严格遵守环境隔离规范借助跳板机登录服务器。

测试

在将需求提交测试之前有两项预备工作，缺一不可：

• 研发人员需要根据测试案例清单产出进行自测并产出自测报告；

• 产品经理需在联调环境下体验完整的功能和操作流程。

测试人员首先在测试环境下进行功能验证，在此过程中研发人员和产品经理共同协助。测试完成后由研发人员将代码部署至体验环境，然后测试人员进行完整的案例回归，通过后再部署至预发环境，再次完整回归之后才可达到发布标准。也就是说在测试环境需经过一次完整测试和两次回归。

发布

服务发布需严格遵循渐进灰度的策略进行，SDK 的发布需要依次按照“alpha->beta->正式版”的流程推进。除此之外，功能的变更不仅仅是代码本身，不同的产品类型往往还会涉及文档、多渠道等周边工作，比如服务的发布会影响多端 SDK，每个 SDK 的 API 及其对应的文档都需要同步进行更新。所以根据服务模块或 SDK 渠道进行专人专项划分也是很有必要的。保证发布出口的唯一性，并且在发布之前进行严格的涉及工作清单遍历。

回归

灰度发布过程中和全量发布之后，测试人员需要同步跟进对已发布的功能进行回归测试，完全通过后即本次迭代结束。

虽然从整体流程上与绝大多数技术研发团队并无二致，云开发团队对品控的管理意识体现在：借助完善和严格的规范制度将每个环节中可能出错的细节均通过技术和人的双重角度进行覆盖，很大程度上减少了质量问题的产生。

总结

计算机技术经过几十年发展到今天，人的很多工作可以由机器协助完成甚至被完全取代。技术力量的伟大无可置疑，但人的因素同样不可或缺。产品质量的把控容不得一丝大意，不论是技术缺失还是人为失误。云开发作为一款平台级 toB 产品，其高可用性背后是技术与人的双重加持。云开发研发团队在提高技术能力的同时，并未忽略人在其中的伟大性，未来我们也将继续秉承这项原则，将技术和人的双重因素渗透至研发品控管理的每个细节之中。

作者介绍

周俊鹏，腾讯高级前端工程师，就职于腾讯云云开发 CloudBase 团队，负责云开发 Cloudbase 相关技术研发工作。Qcon2017 讲师，GMTC 2018/2019 出品人，主要研究方向是前端图形编程、工程化和 web 应用层架构。著有《前端工程化：体系设计与实践》和《前端技术架构与工程》。