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