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配置的方式，整體+明細（驗收達標名單+驗收不達標名單），自動實時展示線上驗收率數據，如下圖所示：
迭代4：持續運營–將線上驗收率數據加入交易質量分的計算指標
經過上面的改進，線上驗收率有了極大的提升，整體驗收率可以達到95%以上（一些因爲業務特性需要延遲驗收），基本達到了最開始預期的效果。
但驗收率是需要持續達標的，展位也不可能一直用於線上驗收率數據的展示。此時平臺正在做“交易質量分“的模型。線上驗收率本來也是過程質量的一個重要指標，所以也就推進了線上驗收率作爲交易質量的一個指標體現。
在“交易質量分“中，如果現在驗收率有不達標的情況，會直接在交易質量分體現。（目前的策略是根據未驗收需求個數和驗收率進行扣分）。
通過以上幾次對線上驗收率運營的不斷迭代，目前平臺整體驗收率達標，且沒有再出現因爲驗收不及時導致的線上問題。
當然，也還有很多不足需要持續迭代的。目前只是驗收（是）或者未驗收（否）的數據量化，我們後續還期望推出一些更細化的指標，比如 驗收時效的分佈（30分鐘、1小時驗收、一小時以上驗收）、線上驗收完備度等數據，更好的運營“線上驗收率”指標，爲交易質量服務。
4. 總結
以上，我們主要通過“驗收”角度來介紹我們交易團隊是如何保證全流程質量的。主要是虛擬城市建設提高線上驗收效率、運營線上驗收率兩個方面。當然高質量的保證肯定也不只是只做好驗收就能達成的，需要我們做好研發流程的每個環節。
交易平臺2020年上半年線上質量數據：
-
公司級故障：
1例（D級）
-
整體系統穩定性：
99.999%
-
業務可用性：
100%
研發質量貫穿於項目的整個生命週期，每個環節都會影響到最後項目的交付質量。如果我們能像做好 “驗收”這樣，多從技術角度和流程角度思考，來做好研發流程的關鍵環節甚至每個環節，最後交付的項目一定是高質量的！
本文轉載自公衆號貝殼產品技術（ID：beikeTC）。
原文鏈接：