案例背景：
       云支付團隊項目模塊系統(tǒng)多且上線游鏈路比較長，各個域的分工人員都是固定的，對于大型百萬級訂單量的項目，專注于負責自己的域顯然是有悖于全鏈路測試的，也會使得考慮問題不全面使得系統(tǒng)在日常的迭代更新中出現(xiàn)很多因為不同域關聯(lián)考慮失誤的問題發(fā)生，這是其一；
       其二由于測試人員的固定性且人力成本的關系，使得每個域只有一名測試人員，沒有對應的backup人員，一旦臨時狀況發(fā)生，項目會出現(xiàn)延后且臨時介入人員對業(yè)務的不理解對迭代質(zhì)量保障會有很大的隱患。
目標：
       實現(xiàn)人員勻動機制，但是得在保證質(zhì)量的前提，使團隊成員慢慢兩兩替換磨合，逐步形成多域測試的復合型測試多面手，從而慢慢形成全鏈路測試思維。團隊人員可以相互作為其他域的backup
實施策略：
       勻動前各自域線梳理業(yè)務總結(jié)文檔分享，首先作為整個團隊的質(zhì)量護航熟悉整個域的業(yè)務，隨后評估每個域需求和技改的風險程度，風險低的讓勻動人員開始練手并把關測分，并跟蹤對于此域的理解程度。將測試關注的點整理成通用測試關注項作為參考。
       最終取得的結(jié)果：
       團隊中人員成功實現(xiàn)勻動轉(zhuǎn)換，一定程度提高了全鏈路思維，并且一旦有臨時情況項目也可以保質(zhì)保量。
管理問題：問題：
       結(jié)合C12中所描述的背景案例，要實現(xiàn)大型項目各個域復合型多域測試人員的成本是相當大的，主要是周期長、培養(yǎng)的成本也比較高。除了總結(jié)業(yè)務文檔的分享，但是這種形式大家都懂的，很多時候分享之后或者講過一遍之后，回頭開始介入上手的時候還是會很多講過的不記得了或者敏感度不夠根本沒想到等等的情況。當然這和每個人的經(jīng)驗和經(jīng)歷也有一定的關系，這種臨時介入大型穩(wěn)定項目幫忙的情況我想大家肯定遇到過很多，也有很多人會說找個人來幫忙不如自己做了，來個臨時的反而更慢了，還添堵。
       自我管理優(yōu)勢（經(jīng)驗總結(jié)）：
       業(yè)務是多變的，但是全鏈路分析思維是有一定的模式的，不同類型的項目關注的風險都有一些差異，多看多聽多總結(jié)，慢慢積累成自己的方法論。