从“验收”角度看交易平台如何保证项目高质量

1. 前言

大家好，本文是交易质量运营系列的第二篇，本文将从两个真实的案例说起，以“验收”的视角，来讲述我们是如何通过技术和流程规范，在整个研发流程中做好验收工作，从而达成交付高质量项目的目的。

2. 背景

一个线上问题

2020/05/11 重庆用户反馈，通过在线签约，在可视化“查看协议”时，展示协议为空白。

经过排查，是在 5 月初，交易系统这边通过上线 sql 进行开城时，同时开十几个城市，但漏开了重庆这个城市。上线后，各角色也没有对开城的城市进行线上验证。导致跳转“查看协议”时，获取的跳转链接为“线下签约“的链接，导致展示协议空白。

一个痛点

2019 年大连资金安全上线后，为了验证功能的可用性，由于业务特性，需要有一个真实用户通过完成整个交易的流程来验证这个功能：也就是需要通过买房签约来验证。

幸运的是，第一个版本上线时，正好大连某经纪人买房签约，于是通过此经纪人进行了第一个版本的线上验证。

但功能版本不断迭代，每次基本上都需要验证，但并不是每次都有正好买房的经纪人愿意配合进行验证。为了达成目标，我们通过在线上环境模拟交易的方式（如下图所示）进行验证：

但联系经纪人、联系交易专员、处理模拟导致的脏数据等，导致整个线上验证的过程非常耗时，且非常低效。

以上两个案例，第一个问题是由于代码缺陷，但功能上线后没有进行及时验证导致问题影响范围变大；第二个问题是功能上线后，线上环境无法高效进行线上验收。针对这两个问题，一个是从研发流程上保证功能上线后的及时验收，另一个是做到线上功能可验收、高效验收。

3. 交易全流程保障体系

如上图所示，交易的研发流程虽与通用研发流程大同小异，但交易平台更注重需求和技术评审、代码 CR 和项目验收，对各个环节都有详细的规范管控质量。这里仅通过“验收”角度进行详述。

3.1 为何如此重视验收？

一个是如前面所讲的案例，另一个主要还是与交易实际的业务场景也有比较大的关系。

交易的业务场景复杂：交易系统涉及买卖方、经纪人、交易专员等众多角色；功能链路更长，Bug 更隐蔽。另外，Bug 修复的成本随着项目生命周期呈指数级增长，这种情况在交易系统中更为突出。

3.2 验收三阶段

为了达成更好的质量效果，我们整体上把验收分为三个阶段：提测前、上线前、上线后。

提测前：我们把 showcase 看做是提测前的“验收”，会根据 case 评审时确定的等级，对编码实现情况的基础验收。这个环节是强制卡点的，PM\QA 验收通过了，需求才能流转到下一个环节。

上线前：上线前我们有 2 个验收环节：UI 验收和功能验收。

一般会在测试的最后阶段让 UI 对项目进行走查，完成 UI 角度的验收。

功能验收是代码发布前的最后一个测试步骤，是产品人员从产品维度对项目的第一次正式验收，一般在稳定的测试环境或者预上线环境（预发环境）进行。

但上线前的验收跟真实的线上环境有所不同，某些场景也无法覆盖，所以完成上线后，还是要做线上验收的。

上线后：线上验收是保证项目质量的最后一步。如果有质量问题，研发产品人员可以第一时间发现并进行相应的止损。线上验收也是最接近于真实用户的操作，能更有效及时的发现问题。

以上的验收阶段中，ShowCase 大家肯定最熟悉，一般的研发流程中必不可少的环节。上线前的验收因为是在测试环境，限制比较少，一般也不难做到，只要加入了这个流程，一般也能做好。我们接下来主要说一下线上验收。

3.3 技术角度：虚拟城市保证线上可验收

对于很多的 C 端业务，验收人员可以以用户的角度，对线上的数据进行操作，假设自己是用户就好，虽然也存在一定的偏差。但对于交易平台的一些业务场景，比如真实的交易流程，就比如最开始讲的第二个案例。

为了解决这类业务场景的线上验收问题，我们想到了通过技术手段提高验收效率：打通虚拟城市。

其他业务线也在用虚拟城市，但业务特性使得交易的虚拟城市建设也有所不同，比如我们面临的一个核心的系统特性问题：系统的配置化。几乎每个城市的交易流程都有差异，针对这些差异，我们有配置平台去支持管理每个城市。如果要实现虚拟城市可以在线上验证配置化的问题，我们需要做：

• 改造配置平台：虚拟城市可以对任意城市的配置进行复制、删除等操作。

• 对核心系统进行业务级别的改造：包括支持对交易单进行删除等操作。

但回归到最初的目标：打通虚拟城市，是为了能在功能上线后可以做到可验收、高效验收。暂时不对核心业务系统改造，是否可以达成目标呢？

我们分析历史问题数据发现，大部分的问题其实跟城市间的差异性配置无关，不做可配置化的虚拟城市，打通一个标准化城市，借鉴 MVP（最简化可实行产品）理论，满足核心的线上验证诉求即可。

解决了配置化的问题，其他打通虚拟城市面临的问题跟其他业务线类似，交易平台是需要对接更多的上下游系统，我们结合实际的系统架构，给出了核心系统整体的实现虚拟城市的基本方案：

实际效果：

4 个项目，共发现问题 77 个，其中 35 个问题在测试环境无法复现。

3.4 流程规范：以运营的方式提高线上验收率

对于研发质量，我们关注的一些核心指标是需要运营的，慢慢建立大家对于质量的认知和意识。我们以线上验收率为例，虽然我们在流程中加入了验收的卡点，目的是为了让大家完成线上验收的时候做好确认，保证线上验收执行的有效性。

在不运营这个指标的情况下，存在一些问题：

• 线上验收通知只通知到个人，其他人无法看到个人的验收结果

• 无法看到交易平台整体的验收数据

• 存在项目上线后某些角色某些场景下不验收的情况

• 存在线上验收之后，不在系统点击“验收“，QA 需要跟各角色单独确认是否完成验收。

上述存在的问题，直接对线上系统稳定性产生影响。比如交易平台上半年唯一的一次公司级 D 级故障，如果上线后及时进行线上验收，就能最快的发现问题，将影响范围降低到最小。

为此，我们展开了对于线上验收率指标的运营并不断迭代：

迭代 1：明确流程规范+整体验收率展示

明确流程规范：对于参与线上验收的各个角色（PM\RD\FE\QA），进行流程规范宣讲，拉齐大家对线上验收率的认知并明确各个角色在执行线上验收时的职责：

PM：上线主要关注产品需求；上线前明确线上验收 checklist，上线后立即执行验收 checklist；

RD/FE：主要关注线上日志、报警，排查异常信息

QA：关注整体上线情况（监控信息）；关注当前上线功能是否无异常；关注项目整体功能及系统间的交互是否正常。

整体验收率展示：推进 keones 平台在原有“PM 线上验收率“的基础上，增加”研发线上验收率“，完成整体数据展示（keones—>BI—>过程数据—>过程质量—>上线阶段）

迭代 2：数据运营–用数据说话

在完成流程规范宣讲+整体验收率展示的前提下，运营两周，整体验收率提升并不明显。

针对于这种情况，总结发现：一个是数据没有展位可以让大家看到，大家都数据没什么概念；二是没有明细的个人验收数据，可能关注不到个人的验收情况。

为此，我们通过“导出明细”+Excel 数据透视分析的方式，拿到个人验收数据并进行分析及整体验收质量评级；整理成宣传物料，并通过平台展位（办公区电视展位）轮播宣传、展示，并进行规范性的操作引导。

图：展位轮播展示线上验收率数据

迭代 3：自动化展示数据

上面的数据运营中，线上验收率有了较为显著的提升。但导出数据+分析的方式是人工手动来执行的，每周更新一次宣传物料，人工重复劳动+数据延迟长。为提高运营效率，通过拉取 keones 验收率数据+Grafana 配置的方式，整体+明细（验收达标名单+验收不达标名单），自动实时展示线上验收率数据，如下图所示：

Grafana 线上验收率数据

迭代 4：持续运营–将线上验收率数据加入交易质量分的计算指标

经过上面的改进，线上验收率有了极大的提升，整体验收率可以达到 95%以上（一些因为业务特性需要延迟验收），基本达到了最开始预期的效果。

但验收率是需要持续达标的，展位也不可能一直用于线上验收率数据的展示。此时平台正在做“交易质量分“的模型。线上验收率本来也是过程质量的一个重要指标，所以也就推进了线上验收率作为交易质量的一个指标体现。

在“交易质量分“中，如果现在验收率有不达标的情况，会直接在交易质量分体现。（目前的策略是根据未验收需求个数和验收率进行扣分）。

通过以上几次对线上验收率运营的不断迭代，目前平台整体验收率达标，且没有再出现因为验收不及时导致的线上问题。

当然，也还有很多不足需要持续迭代的。目前只是验收（是）或者未验收（否）的数据量化，我们后续还期望推出一些更细化的指标，比如 验收时效的分布（30 分钟、1 小时验收、一小时以上验收）、线上验收完备度等数据，更好的运营“线上验收率”指标，为交易质量服务。

4. 总结

以上，我们主要通过“验收”角度来介绍我们交易团队是如何保证全流程质量的。主要是虚拟城市建设提高线上验收效率、运营线上验收率两个方面。当然高质量的保证肯定也不只是只做好验收就能达成的，需要我们做好研发流程的每个环节。

交易平台 2020 年上半年线上质量数据：

• 公司级故障：

• 1 例（D 级）

• 整体系统稳定性：

• 99.999%

• 业务可用性：

• 100%

研发质量贯穿于项目的整个生命周期，每个环节都会影响到最后项目的交付质量。如果我们能像做好 “验收”这样，多从技术角度和流程角度思考，来做好研发流程的关键环节甚至每个环节，最后交付的项目一定是高质量的！

本文转载自公众号贝壳产品技术（ID：beikeTC）。

原文链接：

从“验收”角度看交易平台如何保证项目高质量