QC遇到了什么無法逾越的障礙
我們公司的主要業務是項目外包，一般的項目都在2-3個月的周期，采用瀑布模式。這種模式本身是相對簡單，且十分成熟的模式。但是在實際的工作中，我們還是遇到了前所未有的挑戰。
提測質量差
例如200-300人天的項目，提測bug數量基本在400-600左右，最高紀錄應該是一個400人天的項目，我們總共提交了1200個bug。數據的沖擊力可能沒有那么大，那換個描述方法：幾乎所有的功能都有bug。在項目提測時，仍然會伴有大量的嚴重和阻塞問題，從一個功能模塊不可用，都一條業務流程跑不通。各種問題層出不窮。
無法設置准入准出標准
在面對較差的提測質量時，首先想到的是做准入准出標准，如提測后的冒煙測試不能有核心問題，嚴重問題小於2個等等。准入准出在業內屬於比較普及的方法了，我見過很多公司在這方面執行的非常順暢。但是在我們團隊卻無法落地——周期不允許。對於項目外包團隊，周期就是成本，時間就是生命。如果我們嚴格的執行准入標准，那實際情況就是一輪一輪提測，一輪一輪被打回，周期會被拖的非常長。所以這個方案沒有落地就被扼殺了。
測試周期不可控
當bug數量到達這個程度時，提bug-改bug-回歸bug的工作量就顯得非常可觀了。龐大的bug基數，意味着改完這一遍相當於把整個項目的代碼重新寫了一遍，隨之而來的就是新的麻煩——bug激活/新增。我們的bug新增/激活率基本維持在13%~21%這個區間，例如回歸400個bug的項目，在回歸之后可能要激活或者新增80個bug。整體的測試周期也被迫拉長，個別項目還會變的失控，比如1200個bug要測試四輪到五輪。
QA又翻過了哪些高山
年初的時候公司引入了企業管理內訓，帶着我們重新理解了PDCA的循環。在這個過程中我們分析了以往工作和項目中的問題，發現過程管控是我們很薄弱的環節。方案的最初的方向是測試前置，在考慮了歷史項目的經驗和查閱了大量資料之后，決定將方向定位設立QA職能。
QA方案從最初的設想到最終在項目中落地，前后歷時近兩個月，過程中經歷諸多的問題。
選模型
首先在網上查閱了很多的資料，其中生產型企業的QA模型比較多，不知道怎么往IT行嫁接。后來又與業內的小伙伴們交流了很多，有像幽靈一樣處處盯着的，也有技術大牛review代碼的，基本不符合我們的現狀和訴求。其實這個時候我們犯了一個比較常見的錯誤——拿來主義。一心想着能有一套特別適合公司現狀的模型，可以直接拿過來用。每一套流程都只適用它當時所處的環境，不是說不可復制，而是需要針對性的進行裁剪。在意識到這個問題之后，我們把這些裁剪成了我們心里想像的樣子：
1 QA參與項目全流程工作，對過程和結果進行數據收集和監督；
2 收集全路程文檔，記錄，數據信息，並匯總整理，做數據儲備；
3 組織各個環節負責人，對項目過程的每個環節制定工作標准，如代碼規范，bug規范，需求規范等；
4 綜合數據分析，對各類型項目設置安全閾值，對觸發閾值的過程點及時干預；
5 對項目過程中的各個環節，提供改進意見，並反饋至總監和項目負責人；
6 跟進項目組成員實時填寫的風險列表，推進關鍵風險及時解決；
7 以事實數據為依托，對項目過程和結果進行質量評估。
當然，這個不是最終執行的內容，因為下面還有好多坑。
定標准
既然是檢查監督，肯定是需要有參考標准，就是這個標准可把我們給愁壞了。歷史工作保留下來的數據少之又少，想從數據分析上得出結論已經不可能了，就只剩下拍腦門了。最后一拍腦門，將標准一分為二：
一部分是流程標准，即規范流程內容。包括制定了任務創建規范，詳細描述了任務創建的格式和標准，引入了“結果定義五明確”，規定了任務的檢查及流轉規則；規范了計划模板的格式及修訂更新規則等。
另一部分是質量標准，引入CI/CD機制，規范了掃描問題的數量標准以及處理規則。
專業能力
針對QA人員的轉能技能，有兩個比較突出的問題：1 是否有能力深入檢查需求和開發的工作內容，比如review代碼等；2 對項目風險的識別是否准確。
這兩個問題的答案很簡單，當前團隊人員在綜合素質達不到這個要求，而且也不是短期可實現的。於是我們決定將重點放在方案的流程上，努力做到不依賴於個人能力就可以完成這項工作。
利益平衡
推動項目流程的變革，勢必會對損害既得利益者，這個似乎是所有的調整都會遇到的問題。對於如何識別和處理相關方，就是見仁見智的事了，無非就是做好向上，向下和橫向溝通。我們針對這個問題的處理原則就是，盡量把影響降到最低。就像醫院看病，能吃葯就不打針，能打針就不輸液，能微創就不開刀，都是一個道理。最鍾也是因為領導的加持，這個問題沒有特別凸顯。
如何授權
QA到底在項目中處於什么樣的角色，應該授予什么樣的權利？這個問題在最初是有過爭議的，有兩點分歧：1 職權過大是否會干擾到項目經理的工作，產生不必要的爭端或其他負面問題；2 職權過小是否起不到監督的效果，項目經理完全不理怎么辦。
我的最初設想是，讓QA像產線的質檢QA一樣，在問題超過控制線后有拉閘叫停生產線的權利。比如在過程中發現項目部分流程嚴重不合規，可以隨時發起專題會議，警示和糾正相關方的工作。但是考慮到項目運行過程中可能會因此產生矛盾，於是放棄了這個想法。在解決如何避免項目經理不理會的問題時，我們引入了第一版的三方監督機制，即把總監、項目經理和QA三方綁定監督，QA監督項目經理，總監監督QA，總監監督項目經理，避免利益共同體的形成。后來證明這個三方監督的機制有一個致命的bug，后面會提到。
終於，關於授權的問題也有了初步的方案。
評分
最初版本中，有針對項目團隊成員的評分制度，后來被砍掉了。原因是QA監督的這些維度，不能客觀的反應團隊成員的整體貢獻度。例如，針對任務延期的考評，無法判斷是否成員個人的原因造成還是項目經理臨時安排了其他工作；任務提前完成有可能是項目經理調整了任務優先級，但是沒有更新計划等等。如果要做到非常可觀，又需要增加很多的流程規范，並不利於項目的執行。於是在權衡之后決定砍掉了評分制度，等到體系更成熟的時候再加回來。
穩定運行
任何流程制度，能持續的運行才算是好的制度。工作中遇到了太多的走着走着就散了的事，數不勝數。和小伙伴們交流的時候，也發現了類似的情況，要么就形成了利益共同體，要么就是不了了之。所以，我們在做方案時優先考慮了可持續性的問題。為此引入了上文提到的三方監督機制。前面也提到了，這個方案有個bug，就是當總監沒時間檢查的時候，項目經理就不管了。運行的時候就變成了總監有空，項目經理就會處理，總監沒空，項目經理就不管。后來我們修復了這個bug，將QA接入到了我們現有的一套三方檢查機制（質詢會）中。簡單的說就是每周一次管理層例會，大家相互提出各種待辦事項並承諾完成時間，這些事項會計入質詢單中，由助理每日推薦和檢查，未完成的水果基金伺候。
還是這個觀點，能持續運行的制度才是好的制度。
持續改進
在運行的過程中，我們會不斷的發現問題。將這些問題整理總結，並與相關方討論處理方案，再將方案優化到流程中。如此往復，就是一個PDCA的循環。比如我們規定流程中每增加一個規則，就加入到QA的監督檢查項中。這樣一個循環一個循環的持續成長，才會讓我們的這套機制一直處於進步當中。