概述
質(zhì)量成本分為兩類：
- 一類是事前防止失敗的一致性成本；
- 一類是事后處理失敗的非一致性成本。
事后檢查處理的代價其實是最高的。
實際上，質(zhì)量是規(guī)劃、設計、建造出來的，不是檢查出來的。
預防高于檢查，預防錯誤的成本通常比在檢查中發(fā)現(xiàn)并糾正錯誤的成本低得多。
作為項目管理人員，你該如何更好地規(guī)劃質(zhì)量管理活動呢？
質(zhì)量規(guī)劃，明確標準
規(guī)劃質(zhì)量，是識別項目及產(chǎn)品的質(zhì)量要求和標準，并確定用哪些保障方法、改進措施來達到這些標準的過程。
需要注意的是， 在業(yè)務生命周期的不同階段，質(zhì)量標準應該是動態(tài)變化的。
定義好了質(zhì)量標準，你要思考的是，在整個項目的進程中，需要規(guī)劃好哪些質(zhì)量保障活動，以很好地達到這個標準。
其中，需要特別關注研發(fā)過程中的質(zhì)量保障手段，制定適當?shù)木幋a規(guī)范、提交規(guī)范和分支規(guī)范，同時設計代碼準入標準，確保代碼 Review、單元測試、接口驗證和 UI 驗證等手段與你的項目質(zhì)量要求相匹配。
項目經(jīng)理的視角始終聚焦在項目的整體目標上。在項目經(jīng)理看來，質(zhì)量作為目標的一部分，達到要求是最重要的，不需要追求質(zhì)量的無止境提升。因為，質(zhì)量終究也是有代價的，是否夠用則取決于項目目標和要求。
質(zhì)量分析，追根溯源
質(zhì)量分析，是指識別項目運行期間，整體質(zhì)量上遇到的問題和制約因素，分析根本原因，并制定相應的預防措施和解決方案。
定位完問題，我們就可以采取相應的措施進行改進或預防了。
質(zhì)量出現(xiàn)問題，經(jīng)過深入分析，我們對頻發(fā)的質(zhì)量問題有了以下認識：
- 1.團隊擴張得很快，在相當長的時間內(nèi)，測試人員的配比都非常低，8 個開發(fā)對應 0.5 個
測試。測試基本上只是給開發(fā)打工，只能保證最最基本的功能，其他更深度的測試類型
根本無所涉獵； - 2.團隊沒有從用戶的視角來檢驗產(chǎn)品，上層模塊的應用場景、運維的應用場景與測試的視
角相差較大，測試效果很難保障； - 3.約有五分之一的線上 Bug，是來自社區(qū)，用戶側(cè)出現(xiàn)問題以后才去社區(qū)找，再把這個補
丁合進來，沒有主動應對。
同時，我也做了用戶調(diào)研，最終的結(jié)果顯示，用戶對底層核心模塊的期望更多的是穩(wěn)定，至于新功能，用戶普遍表示暫時沒有需要。因此，盲目增加復雜功能其實并不明智，保持產(chǎn)品簡單可靠才是王道。
定位完問題，我們就可以采取相應的措施進行改進或預防了。
1.新功能適當放慢：在基本功能已經(jīng)成型的情況下，進一步控制新功能開發(fā)在迭代中的占比與優(yōu)先級。當時我們定義的是不超過 70%，在一定時期內(nèi)，核心功能不再做大的變動。
團隊沒有從用戶的視角來檢驗產(chǎn)品，上層模塊的應用場景、運維的應用場景與測試的視角相差較大，測試效果很難保障；
2.回顧總結(jié)：將線上 Bug 分析作為周會的一項固定內(nèi)容，集體討論出整體層面上的改進措施，并跟進實施到位。
3.查漏補缺：對已有的測試用例進行全面梳理，與相關的開發(fā)、測試、運維一起集體review，花大力氣補充測試代碼（增加異常、并發(fā)、穩(wěn)定性測試等）?？紤]到這是一項長期工作，要確保將其分解到各個迭代中，分批實施。
4.走到前面：緊密跟進社區(qū) Bug，分析重現(xiàn)并評估影響，定期總結(jié)梳理，并組織討論應對措施，主動引入必要的補丁。
5.以終為始：新功能需求確定后，測試用例同步設計并進行 review，然后開放冒煙測試標準，讓開發(fā)人員在明確“什么是完成”的前提下，進行開發(fā)。
在堅持了兩個月之后，整體的質(zhì)量狀況好了很多?？傮w來說，質(zhì)量分析最重要的是要追根溯源，找到問題癥結(jié)。我們給你推薦幾種簡單實用的方法：
- 1.每月堅持開線上 Bug 分析會。你可以召集產(chǎn)品、研發(fā)、測試，一起對過去一個月的線上問題，進行深入的根因分析，制定策略并推進落實。
- 2.持續(xù)進行內(nèi)部 Bug 分類。從不同維度分析 Bug 原因，你可以按照具體引入階段給 Bug分類，比如需求不清、設計缺陷、邏輯錯誤、測試遺漏、變更引發(fā)的覆蓋升級、歷史遺留等，也可以按照 Bug 類別分為功能問題、性能問題、界面問題、兼容性問題等。從數(shù)據(jù)統(tǒng)計上，你就可以準確地知道，自己項目的質(zhì)量問題主要出在哪個環(huán)節(jié)，下一步是要先規(guī)范代碼準入標準，還是加強需求評審，以及哪些保障措施會更有效。
- 3.建立質(zhì)量大盤，拉通不同業(yè)務線或模塊的每月 Bug 趨勢，對齊千行代碼 Bug 率、Bug數(shù) / 需求數(shù)的比率、Reopen Bug 率等，對低于平均線下的業(yè)務線或模塊進行有針對性的原因分析。
質(zhì)量控制，層層卡點
如果說質(zhì)量分析的要點重在追根溯源，那么質(zhì)量控制，就是將一些明確下來的質(zhì)量規(guī)范和做法，真正落地到各個環(huán)節(jié)。我給你分享一張樣例圖，它展示的是從需求到發(fā)布的整個過程中的質(zhì)量活動概覽。
想要推動質(zhì)量改進措施的落地，與之相匹配的工具是必不可少的。
使用 PMO自主設計開發(fā)的企業(yè)效能平臺 Overmind，來完成持續(xù)集成和持續(xù)交付，并在需求到發(fā)布
的整個鏈條中，層層設置相應的質(zhì)量卡點。你可以根據(jù)實際需要，逐步為自己的應用定制合適的持續(xù)集成方案，指定代碼準入的閾值，比如靜態(tài)掃描、單元測試、覆蓋率測試、沖突檢測、Jar 包版本檢測的通過條件等。
需要注意的是， 質(zhì)量控制及卡點行為，是要結(jié)合項目的質(zhì)量要求和團隊的質(zhì)量成熟度，一層一層地加強質(zhì)量把關和收口。即便是在同個項目的不同應用中，也會因為線上要求的不同，而對質(zhì)量卡點有不同的側(cè)重。通過質(zhì)量卡點的在線工具化，才能做到真正有效的質(zhì)量保障。
比如，某些團隊在特定階段，會按照靜態(tài)代碼掃描問題的級別來分級計算缺陷值，提交測試申請時，如果系統(tǒng)檢測到缺陷值有升高，就不能夠成功提交。
總結(jié)
今天，我們分享了項目經(jīng)理在質(zhì)量管理過程中的工作，可以從三個方面入手，分別是：
- 質(zhì)量規(guī)劃，明確項目的質(zhì)量標準；
- 質(zhì)量分析，追根溯源，找到質(zhì)量差距的根本癥結(jié)；
- 質(zhì)量控制，在需求到發(fā)布的過程中，設置層層卡點來控制質(zhì)量。
要想一次把事情做對，你首先得明確什么是對，然后要分析差距，找到相應的質(zhì)量保障方法，并不斷迭代。這三個方面是個螺旋式循環(huán)上升的過程，你需要不斷地根據(jù)質(zhì)量分析的結(jié)果，設置合適的質(zhì)量卡點，直到達到規(guī)劃中的質(zhì)量標準。
