01 背景
談到質(zhì)量管理，這其實(shí)是一個(gè)比較大的話題，因?yàn)榈礁餍懈鳂I(yè)都有其質(zhì)量的定義和要求，也包括質(zhì)量管理的方式方法。
鑒于本人長(zhǎng)時(shí)間在互聯(lián)網(wǎng)行業(yè)，因此本文聚焦談的是互聯(lián)網(wǎng)項(xiàng)目如何做好質(zhì)量管理。
互聯(lián)網(wǎng)產(chǎn)品以快著稱，敏捷開發(fā)，快速迭代。不過(guò)這是精品1.0時(shí)代下的產(chǎn)物。在那個(gè)時(shí)代，因?yàn)樾枰焖偕暇€，搶占市場(chǎng)份額，這就使得發(fā)布的產(chǎn)品是某種程度上犧牲了產(chǎn)品的質(zhì)量的。所以，那個(gè)時(shí)候有一個(gè)名詞，叫做有損發(fā)布。
隨著行業(yè)的不斷發(fā)展，互聯(lián)網(wǎng)行業(yè)的產(chǎn)品已經(jīng)不再是以快著稱。進(jìn)入精品4.0時(shí)代后，提倡的是匠心思維。每一款產(chǎn)品正式發(fā)布時(shí)，對(duì)質(zhì)量都是高標(biāo)準(zhǔn)，高要求。因?yàn)樵谝黄t海時(shí)代，任何以犧牲質(zhì)量為代價(jià)而發(fā)布的產(chǎn)品，都可能帶來(lái)毀滅性的損失。
02 質(zhì)量管理的原則
或許正是因?yàn)樾袠I(yè)的演變，也讓質(zhì)量管理成為了項(xiàng)目整個(gè)生命周期的重中之重。我們知道項(xiàng)目管理四要素：時(shí)間、成本、范圍和質(zhì)量。在這個(gè)鐵三角中，質(zhì)量處于中心位置，項(xiàng)目經(jīng)理在安排各項(xiàng)工作時(shí)，需要全局考慮，質(zhì)量是默認(rèn)必須要保證的，可以調(diào)整的是時(shí)間、成本（人力）和范圍。這是質(zhì)量管理的一個(gè)原則之一。
在實(shí)際項(xiàng)目推進(jìn)過(guò)程中，質(zhì)量管理的第二個(gè)原則：產(chǎn)品的質(zhì)量是設(shè)計(jì)出來(lái)的，不是測(cè)試出來(lái)的。千萬(wàn)不要忽略過(guò)程，而把最壓力放到最后的測(cè)試環(huán)節(jié)。項(xiàng)目經(jīng)理不能最后只抓測(cè)試部門對(duì)質(zhì)量的測(cè)試，更需要抓產(chǎn)品源頭、開發(fā)設(shè)計(jì)、過(guò)程驗(yàn)收等全鏈條參與人員對(duì)測(cè)試的重視程度。
由此，也引出質(zhì)量管理的第三個(gè)原則：質(zhì)量管理是貫穿整個(gè)項(xiàng)目生命周期的，是一個(gè)體系化的事情。質(zhì)量管理從項(xiàng)目啟動(dòng)之初就需要開始，而不是某個(gè)階段，或某幾個(gè)階段才開始。要確保產(chǎn)品質(zhì)量的穩(wěn)定，在整個(gè)項(xiàng)目周期都需要做好質(zhì)量的管理。
質(zhì)量管理的第四個(gè)原則：一切的質(zhì)量管理過(guò)程，都要提前做好規(guī)劃，眼見為實(shí)。尤其是針對(duì)手游性能體驗(yàn)方面，優(yōu)化前后的版本，是可以非常直觀地感受到的。此外，眼見為實(shí)，也要求測(cè)試的整個(gè)過(guò)程可視化，做好質(zhì)量風(fēng)險(xiǎn)評(píng)估，抓關(guān)鍵點(diǎn)。比如說(shuō)最直接的，開發(fā)人員說(shuō)改了什么什么bug，結(jié)果版本里面發(fā)現(xiàn)壓根就沒(méi)有改。所以，要實(shí)際地看交付的版本，眼見為實(shí)。
04 質(zhì)量管理的方式方法
那怎么來(lái)做好質(zhì)量管理呢？從我自己的理解，我梳理了十大要點(diǎn)：
一、明確目標(biāo)
項(xiàng)目有項(xiàng)目的目標(biāo)，質(zhì)量管理，同樣有質(zhì)量管理的目標(biāo)。
對(duì)于質(zhì)量管理來(lái)說(shuō)，目標(biāo)包括目的和標(biāo)準(zhǔn)。質(zhì)量管理需要有明確的目的；質(zhì)量管理需要有明確的標(biāo)準(zhǔn)。
1、質(zhì)量管理的目的
學(xué)過(guò)PRINCE2的朋友可能都知道，P2的7大主題之一就有質(zhì)量主題。質(zhì)量主題的目的是定義并實(shí)施項(xiàng)目用來(lái)創(chuàng)建產(chǎn)品并驗(yàn)證其符合目的的方法。
質(zhì)量是產(chǎn)品、人員、流程、服務(wù)和/或體系的特質(zhì)和其內(nèi)在固有或外在賦予特點(diǎn)的綜合，顯示其達(dá)到期望或滿足陳述的需求、要求或規(guī)格的能力。
質(zhì)量的焦點(diǎn)在于產(chǎn)品達(dá)到要求的能力。
所以說(shuō)，進(jìn)行質(zhì)量管理的目的要清楚，而且也不言而喻，就是為了使得產(chǎn)品達(dá)到所設(shè)定的要求的能力。
2、質(zhì)量管理的標(biāo)準(zhǔn)
談到標(biāo)準(zhǔn)，僅從公司的角度來(lái)說(shuō)，我想每個(gè)公司都會(huì)有其自身的質(zhì)量管理體系。所謂質(zhì)量管理體系就是項(xiàng)目/產(chǎn)品或組織的一整套質(zhì)量標(biāo)準(zhǔn)、步驟和職責(zé)。這里我想分研發(fā)期的標(biāo)準(zhǔn)和正式上線發(fā)布的標(biāo)準(zhǔn)。
（1）研發(fā)期的標(biāo)準(zhǔn)
研發(fā)期的標(biāo)準(zhǔn)，是在符合整個(gè)公司的質(zhì)量管理體系下，由項(xiàng)目組根據(jù)實(shí)際情況來(lái)定義的一個(gè)標(biāo)準(zhǔn)。
之所以要定這個(gè)標(biāo)準(zhǔn)，是因?yàn)轫?xiàng)目在研發(fā)期的時(shí)候，因?yàn)轫?xiàng)目有大量的系統(tǒng)功能要進(jìn)行開發(fā)。從項(xiàng)目管理全局更優(yōu)的角度出發(fā)，不太可能做完一個(gè)版本就絕對(duì)穩(wěn)定一個(gè)版本。這是由互聯(lián)網(wǎng)產(chǎn)品或游戲項(xiàng)目本身所決定的。尤其是游戲項(xiàng)目，系統(tǒng)與系統(tǒng)之間才存在強(qiáng)耦合，強(qiáng)關(guān)聯(lián)或依賴關(guān)系，就更沒(méi)有辦法在項(xiàng)目初期、中期做到絕對(duì)的質(zhì)量穩(wěn)定。
以我們項(xiàng)目為例，我們?cè)陧?xiàng)目鋪量階段制定的一個(gè)迭代標(biāo)準(zhǔn)，參考如下：
項(xiàng)目經(jīng)理需要有一個(gè)清晰的認(rèn)知，迭代目標(biāo)的制定，就是為了交付質(zhì)量更加可靠的版本。所以，我們?cè)u(píng)判一個(gè)版本的質(zhì)量達(dá)標(biāo)與否，不是僅僅只看這個(gè)版本的bug修復(fù)情況，是看的整個(gè)全局，包括但不限于需求的實(shí)現(xiàn)完整度、資源的合入情況、開發(fā)的深度參與、體驗(yàn)問(wèn)題的修改、bug的修改。
（2）上線的標(biāo)準(zhǔn)
上線的標(biāo)準(zhǔn)，通常是指要滿足正式發(fā)布時(shí)，需要滿足的標(biāo)準(zhǔn)。但這些標(biāo)準(zhǔn)并不是等到產(chǎn)品正式上線的時(shí)候才會(huì)進(jìn)行，而是從項(xiàng)目立項(xiàng)之初就從多個(gè)階段來(lái)進(jìn)行保障。
鵝廠的質(zhì)量管理體系（以游戲項(xiàng)目為例）稱之為TDR評(píng)審指引及標(biāo)準(zhǔn)。TDR的全稱是Technical Design Review，稱作技術(shù)設(shè)計(jì)評(píng)審，分別有TDR1、TDR2、TDR3。針對(duì)項(xiàng)目的不同階段，側(cè)重點(diǎn)不一樣。
TDR1，策劃（產(chǎn)品）重點(diǎn)是游戲的設(shè)計(jì)方向、核心玩法、題材包裝等；美術(shù)重點(diǎn)評(píng)審的是游戲的整體定位風(fēng)格及各細(xì)部風(fēng)格是否已經(jīng)確認(rèn)完成，是否符合產(chǎn)品定位，是否有高品質(zhì)同類產(chǎn)品的競(jìng)品供對(duì)比參考；程序重點(diǎn)評(píng)審的是系統(tǒng)架構(gòu)設(shè)計(jì)是否合理。通常是在項(xiàng)目正式立項(xiàng)并確定時(shí)。
TDR2是根據(jù)不同的游戲品類所需要，主要是針對(duì)程序的技術(shù)設(shè)計(jì)評(píng)審。大多是在demo版本開啟的時(shí)候進(jìn)行。
TDR3重點(diǎn)針對(duì)的就是程序、測(cè)試、安全和政策。程序重點(diǎn)評(píng)審的是客戶端和服務(wù)端的性能、適配、CPU和內(nèi)存、crash率、弱網(wǎng)這些主要指標(biāo)；測(cè)試則重點(diǎn)評(píng)審的是客戶端性能基線、內(nèi)存消耗、CPU占用率、幀率、適配、弱網(wǎng)、crash率、服務(wù)器性能、容錯(cuò)容災(zāi)；安全方面，重點(diǎn)評(píng)審的是客戶端安全（是否加密）、游戲邏輯安全、敏感詞接入等；政策主要是版號(hào)、備案、實(shí)名制。
到TDR3的時(shí)候，基本上是需要對(duì)外測(cè)試（上線）的時(shí)候，要達(dá)到這個(gè)標(biāo)準(zhǔn)，才能申請(qǐng)資源進(jìn)行測(cè)試。
二、確定范圍
這里的范圍是指質(zhì)量管理的范圍。
具體到某一個(gè)版本來(lái)說(shuō)，在版本正式進(jìn)入開發(fā)階段，是需要確定范圍的。也就是說(shuō)要明確清楚具體做的需求是哪些，范圍確定了，才更好從源頭狠抓需求的質(zhì)量。對(duì)于質(zhì)量管理來(lái)說(shuō)，需求管理做的好與不好，也是直接影響質(zhì)量管理的好與不好。
項(xiàng)目經(jīng)理需要抓源頭，讓需求輸出的質(zhì)量更高，進(jìn)而最后交付的版本質(zhì)量也會(huì)更高。比如我們?cè)?jīng)就出現(xiàn)過(guò)典型的案例，某個(gè)需求輸出本身的缺陷：需求邏輯不清晰，前后后有矛盾。這樣一來(lái)，需求評(píng)審的時(shí)候就直接暴露出來(lái)這個(gè)設(shè)計(jì)缺陷。假設(shè)需求直接進(jìn)入開發(fā)，則對(duì)質(zhì)量的影響就更大了。所以，從需求源頭開始，就需要對(duì)需求的質(zhì)量進(jìn)行管理了。
當(dāng)需求的源頭明確了，對(duì)開發(fā)和測(cè)試來(lái)說(shuō)，目標(biāo)則會(huì)更加的明確。關(guān)于需求的源頭，抓需求質(zhì)量的輸出，在需求管理的篇幅里面有詳細(xì)介紹。
三、對(duì)需求進(jìn)行測(cè)試和評(píng)審
對(duì)需求的測(cè)試，是軟件測(cè)試領(lǐng)域里面提到的一個(gè)重要策略。但這對(duì)測(cè)試資源的依賴或要求是非常之高的。事實(shí)上，很多互聯(lián)網(wǎng)項(xiàng)目或游戲項(xiàng)目，沒(méi)辦法做到對(duì)需求進(jìn)行測(cè)試。
但為確保需求理解的一致性，需求評(píng)審在整個(gè)研發(fā)流程里面是必不可少的。不管需求的體量如何，在需求正式進(jìn)入開發(fā)階段，需求評(píng)審是必選項(xiàng)，而且相關(guān)負(fù)責(zé)人都需要參與。
作為項(xiàng)目經(jīng)理，不要認(rèn)為需求評(píng)審（或宣講）會(huì)耗費(fèi)很多時(shí)間，不如直接發(fā)給開發(fā)人員進(jìn)行方案的設(shè)計(jì)和工作量的評(píng)估。如果這么想了，質(zhì)量管理做起來(lái)會(huì)非常的痛苦。因?yàn)檫@樣做之后，很有可能會(huì)導(dǎo)致信息的不對(duì)稱，使得執(zhí)行時(shí)出現(xiàn)理解的偏差，結(jié)果做出來(lái)的產(chǎn)品不符合預(yù)期，引發(fā)各種問(wèn)題。
所以，需求評(píng)審，則可以有效地保障需求功能點(diǎn)的遺漏，減少開發(fā)過(guò)程中的補(bǔ)丁，讓整個(gè)設(shè)計(jì)在源頭更加完整。
四、狠抓設(shè)計(jì)方案和WBS
質(zhì)量是設(shè)計(jì)出來(lái)的，不是測(cè)試出來(lái)的。每個(gè)需求或版本對(duì)應(yīng)的需求評(píng)審?fù)瓿芍螅枰蛨F(tuán)隊(duì)達(dá)成共識(shí)。一些大的需求或者復(fù)雜的系統(tǒng)，在正式啟動(dòng)編碼時(shí)，需要輸出詳細(xì)的設(shè)計(jì)方案。這是和團(tuán)隊(duì)達(dá)成的共識(shí)。
或許寫設(shè)計(jì)方案會(huì)耗費(fèi)一定的時(shí)間，但這對(duì)整個(gè)質(zhì)量管理來(lái)說(shuō)至關(guān)重要。設(shè)計(jì)方案的輸出，不僅僅只是輸出，更需要進(jìn)行論證和設(shè)計(jì)方案的評(píng)審。這是非常重要的環(huán)節(jié)。
對(duì)于設(shè)計(jì)方案，在項(xiàng)目啟動(dòng)之初的時(shí)候，我們還會(huì)請(qǐng)部門的一些專家一起進(jìn)行論證和評(píng)審，目的就是確保設(shè)計(jì)框架沒(méi)有大的缺陷。
設(shè)計(jì)方案評(píng)審確認(rèn)后，是需要輸出詳細(xì)的工作量評(píng)估，也就是WBS。在做WBS的時(shí)候，我們有一個(gè)要求，即輸出的詳細(xì)工作量評(píng)估需要細(xì)化至0.5-2d的顆粒度。通常都是0.5d、1d，如果分解的任務(wù)里面，確實(shí)是有2d的工作量，還需要做特別的說(shuō)明，否則就需要重新評(píng)估。
之所以要細(xì)化，是因?yàn)轭w粒度細(xì)化的越細(xì)，說(shuō)明具體執(zhí)行人員對(duì)需求的理解和思考就更到位。結(jié)合設(shè)計(jì)方案，對(duì)需求的細(xì)節(jié)開發(fā)就更加有利。
正所謂磨刀不誤砍柴工，多花些時(shí)間在設(shè)計(jì)方案和詳細(xì)的工作量評(píng)估上，遠(yuǎn)比需求評(píng)審?fù)曛苯娱_干而有利于質(zhì)量管理。
五、接入一切可能的輔助工具
很多公司除了質(zhì)量管理體系標(biāo)準(zhǔn)，還會(huì)有各種輔助工具，用來(lái)更好的輔助和發(fā)現(xiàn)代碼的質(zhì)量。
代碼健壯性、可擴(kuò)展性越高，代碼的質(zhì)量就越穩(wěn)定，產(chǎn)品的質(zhì)量也就越穩(wěn)定。
對(duì)于我們來(lái)說(shuō)，在項(xiàng)目啟動(dòng)之初，就會(huì)考慮接入公司的各種工具，比如代碼掃描工具、crash上報(bào)平臺(tái)、日志上報(bào)系統(tǒng)。
在有利于質(zhì)量管理的前提下，我個(gè)人是傾向于盡可能的接入。當(dāng)然并不是為了接入而接入，需要思考是不是真的對(duì)質(zhì)量管理有利。
代碼掃描工具，可以在編譯階段就發(fā)現(xiàn)各種告警、報(bào)錯(cuò)，便于開發(fā)人員及時(shí)處理，防止出現(xiàn)大規(guī)模單元測(cè)試時(shí)出現(xiàn)異常。
日志上報(bào)系統(tǒng)，接入上報(bào)平臺(tái)之后，還需要項(xiàng)目側(cè)進(jìn)一步完善日志打印，這樣有利于問(wèn)題的排查。當(dāng)出現(xiàn)一些問(wèn)題，尤其是一些偶現(xiàn)問(wèn)題的時(shí)候，有比較健全的日志系統(tǒng)，就方便快速定位和排查，并深入地解決。
輔助工具，不一定是每個(gè)公司都會(huì)有的，那如果是一些沒(méi)有這個(gè)條件的，可以考慮搭建一個(gè)或者找一找開源的工具。
輔助工具，除了公司已有的以外，如果是有條件的項(xiàng)目，還建議提前搭建自動(dòng)化測(cè)試工具。
自動(dòng)化測(cè)試工具的構(gòu)建，是有利于節(jié)省測(cè)試資源，并提前發(fā)現(xiàn)問(wèn)題的。對(duì)于互聯(lián)網(wǎng)產(chǎn)品或游戲項(xiàng)目來(lái)說(shuō)，大多是增量開發(fā)。
此前已經(jīng)開發(fā)完的需求或功能，在搭建自動(dòng)化測(cè)試工具之后，我們可以在版本自動(dòng)構(gòu)建階段就使用自動(dòng)化工具跑起來(lái)，提前發(fā)現(xiàn)問(wèn)題，保證版本質(zhì)量的穩(wěn)定。
六、推行測(cè)試先行
在整個(gè)質(zhì)量管理的體系中，為從源頭更好的保障產(chǎn)品的質(zhì)量，我們還推行測(cè)試先行，測(cè)試驅(qū)動(dòng)開發(fā)的策略。
開發(fā)的思維邏輯通常正向思維，而測(cè)試人員通常是逆向思維。借助測(cè)試人員的逆向思維，把一些問(wèn)題前置。
比如我們現(xiàn)在通常的做法，就是大多數(shù)的時(shí)候，在需求評(píng)審?fù)曛螅瑫?huì)確定測(cè)試用例什么時(shí)候輸出，在測(cè)試用例輸出時(shí)，測(cè)試人員會(huì)輸出思維導(dǎo)圖，幫助開發(fā)提前做好一些異常、邊界功能的補(bǔ)充，在編碼的過(guò)程中就先行考慮，而不是等到版本交付后，測(cè)試過(guò)程中才來(lái)針對(duì)性的解決bug，這樣會(huì)對(duì)整體代碼健壯性有影響。當(dāng)自測(cè)用例輸出后，開發(fā)、產(chǎn)品和測(cè)試一起評(píng)審自測(cè)用例，有理解不一致或功能缺失，都會(huì)在開發(fā)階段補(bǔ)全。
推行測(cè)試先行的目的，也還是從需求源頭出發(fā)，利用測(cè)試的專業(yè)性，從邏輯架構(gòu)上，提前規(guī)避或提前解決一些邊界或異常的問(wèn)題。
七、加強(qiáng)驗(yàn)收環(huán)節(jié)
質(zhì)量管理一定不只是開發(fā)和測(cè)試的事情，因此，項(xiàng)目經(jīng)理要特別重視驗(yàn)收環(huán)節(jié)。
驗(yàn)收環(huán)節(jié)也是整個(gè)項(xiàng)目研發(fā)流程中的重要步驟之一，以游戲項(xiàng)目為例，一個(gè)版本（或系統(tǒng)功能）交付之后，對(duì)應(yīng)的產(chǎn)品人員結(jié)合美術(shù)人員需要參與版本的驗(yàn)收，并且輸出驗(yàn)收的意見，或體驗(yàn)問(wèn)題或bug。
因?yàn)槲覀兪翘匦孕〗M的模式，在具體負(fù)責(zé)需求的人員驗(yàn)收之后，整個(gè)特性小組還會(huì)參與一起驗(yàn)收。最后測(cè)試完成，項(xiàng)目的核心管理人員也會(huì)參與最后的體驗(yàn)。
這些驗(yàn)收環(huán)節(jié)，其目的之一就是傳遞給團(tuán)隊(duì)成員，對(duì)質(zhì)量的保證，不只是開發(fā)和測(cè)試的事情，是整個(gè)項(xiàng)目組的事情。目的之二是確保需求開發(fā)到交付的一致性。
除了讓項(xiàng)目其他人員參與到驗(yàn)收環(huán)節(jié)，實(shí)際上，對(duì)代碼本身的驗(yàn)收也是一個(gè)重要環(huán)節(jié)。代碼驗(yàn)收就是我們常說(shuō)的codereview（簡(jiǎn)稱CR）。
項(xiàng)目其他人員在對(duì)功能進(jìn)行驗(yàn)收時(shí)，開發(fā)的核心團(tuán)隊(duì)也會(huì)對(duì)代碼的質(zhì)量進(jìn)行評(píng)審和驗(yàn)收，提出的代碼問(wèn)題也會(huì)一并在正式轉(zhuǎn)測(cè)試的時(shí)候進(jìn)行修復(fù)，從而更進(jìn)一步的保證轉(zhuǎn)測(cè)試的版本質(zhì)量穩(wěn)定。
八、高標(biāo)準(zhǔn)要求
高標(biāo)準(zhǔn)要求，其實(shí)目的很明確。項(xiàng)目在研發(fā)期的測(cè)試，用戶體量是比較小的，一旦正式上線（公測(cè)），用戶體量就上來(lái)了，對(duì)于一些偶現(xiàn)的問(wèn)題或者crash的情況，都會(huì)隨著體量的增加而增加。
所以，要滿足項(xiàng)目側(cè)的標(biāo)準(zhǔn)，以及公司的質(zhì)量管理體系標(biāo)準(zhǔn)。在項(xiàng)目研發(fā)階段，都需要高標(biāo)準(zhǔn)要求：
1、在測(cè)試期間，重點(diǎn)抓偶現(xiàn)問(wèn)題的解決、弱網(wǎng)問(wèn)題的解決、crash問(wèn)題的解決及性能問(wèn)題。尤其是偶現(xiàn)問(wèn)題，不僅要高標(biāo)準(zhǔn)要求，還需要杜絕僥幸心理。曾經(jīng)就因?yàn)閮e幸心理，為了趕時(shí)間，而擱置了一些偶現(xiàn)問(wèn)題，使得項(xiàng)目上線后，不得不緊急修復(fù)各種問(wèn)題，緊急更新版本，也使得當(dāng)時(shí)項(xiàng)目的數(shù)據(jù)很糟糕。
2、拒絕僥幸心理，是為了更好地杜絕沒(méi)有解決的偶現(xiàn)的bug。同時(shí)，對(duì)于crash率，更需要高標(biāo)準(zhǔn)要求?；ヂ?lián)網(wǎng)產(chǎn)品（APP），運(yùn)行穩(wěn)定與否，crash率是一項(xiàng)重要的衡量指標(biāo)。
針對(duì)crash率，如果上線標(biāo)準(zhǔn)crash率不高于6%，那么在測(cè)試階段crash率至少要控制在1%以內(nèi)；如果上線標(biāo)準(zhǔn)crash率不高于1%，在測(cè)試階段則要求crash率不高于0.5%。
所以，高標(biāo)準(zhǔn)要求，需要重點(diǎn)監(jiān)控crash率的情況，在研發(fā)期間的crash率要控制其遠(yuǎn)遠(yuǎn)低于上線標(biāo)準(zhǔn)。
九、重視測(cè)試和風(fēng)險(xiǎn)評(píng)估
質(zhì)量管理過(guò)程有了保證之后，并不代表產(chǎn)品的質(zhì)量最終是有保障的。過(guò)程做的好，從項(xiàng)目的整個(gè)周期來(lái)說(shuō)，會(huì)有一定程度的縮短，也給測(cè)試提供了極大的便利，但這并不意味著就可以忽略最后的測(cè)試環(huán)節(jié)。
從互聯(lián)網(wǎng)產(chǎn)品或游戲項(xiàng)目來(lái)說(shuō)，測(cè)試的效用還是非常大的，這是由項(xiàng)目本身的特點(diǎn)所決定的。因此，測(cè)試是質(zhì)量最后的“守門員”，從項(xiàng)目經(jīng)理的角度來(lái)說(shuō)，一定要重視最后的測(cè)試環(huán)節(jié)。
怎么重視？清晰定義每個(gè)需求，每個(gè)版本的轉(zhuǎn)測(cè)試范圍，做好目標(biāo)和標(biāo)準(zhǔn)的同步。同時(shí)，關(guān)切測(cè)試提出的訴求并及時(shí)地給予認(rèn)可。
在很多公司，測(cè)試部門的屬于第三方支持團(tuán)隊(duì)，項(xiàng)目經(jīng)理對(duì)于一些重要的事項(xiàng)，需要將測(cè)試團(tuán)隊(duì)考慮在內(nèi)，增強(qiáng)測(cè)試團(tuán)隊(duì)的參與感和凝聚力，使其融入到項(xiàng)目組，成為項(xiàng)目的重要成員。
另外，專業(yè)的測(cè)試團(tuán)隊(duì)，在每個(gè)版本測(cè)試完成后，都會(huì)從測(cè)試的角度提出質(zhì)量的風(fēng)險(xiǎn)，這方面，項(xiàng)目經(jīng)理也尤其需要重視。往往測(cè)試團(tuán)隊(duì)提出的質(zhì)量風(fēng)險(xiǎn)，都會(huì)直接或間接影響接下來(lái)項(xiàng)目的安排。
比如某個(gè)版本測(cè)試完成后，測(cè)試人員給出的bug分布情況和各模塊的風(fēng)險(xiǎn)評(píng)估，特別指出一些系統(tǒng)功能模塊的質(zhì)量風(fēng)險(xiǎn)。一些數(shù)據(jù)或指標(biāo)的提出，就會(huì)直接影響下一個(gè)版本的安排。
十、最關(guān)鍵的還是在于人
前面我們講了很多，其實(shí)都是流程和具體的事情。
但真正的關(guān)鍵還是在于人。這是從軟件行業(yè)的角度來(lái)說(shuō)的，質(zhì)量是設(shè)計(jì)出來(lái)的。如果團(tuán)隊(duì)有靠譜的人，有更專業(yè)，更厲害的人，那么就可以從源頭避免很多質(zhì)量的問(wèn)題，這點(diǎn)其實(shí)是非?，F(xiàn)實(shí)的。
帶項(xiàng)目這么些年，這方面的感觸非常之深，就是技術(shù)牛人寫的代碼和一般的人寫的代碼完全不是一個(gè)級(jí)別，其所交付的產(chǎn)品的質(zhì)量更不是一個(gè)級(jí)別的。
所以，如果你發(fā)現(xiàn)做了上面的很多事情，產(chǎn)品的質(zhì)量還是不達(dá)標(biāo)，那就不僅僅是優(yōu)化流程，對(duì)齊目標(biāo)和范圍的事情，要重點(diǎn)考慮人是否合適。
流程和體系是解決不了底層的質(zhì)量問(wèn)題的，所以最關(guān)鍵還是找到更合適的，更牛的人，從根本上解決質(zhì)量的問(wèn)題。
05 歸納總結(jié)
上面介紹了十大要點(diǎn)，助力做好質(zhì)量管理?？偨Y(jié)歸納一下，要做好質(zhì)量管理，三個(gè)維度共同發(fā)力：
一、體系和流程
每個(gè)公司都會(huì)有自身的質(zhì)量管理體系，借助公司的質(zhì)量管理體系，可以有效地指導(dǎo)質(zhì)量管理。若一些公司沒(méi)有質(zhì)量管理體系，項(xiàng)目經(jīng)理可以根據(jù)實(shí)際情況，帶領(lǐng)項(xiàng)目團(tuán)隊(duì)搭建一個(gè)質(zhì)量管理體系，或者最簡(jiǎn)單的，制定一個(gè)最基本的質(zhì)量保障標(biāo)準(zhǔn)。
目標(biāo)，范圍這些都可以歸納到整個(gè)項(xiàng)目的研發(fā)流程中，參照如下圖：
項(xiàng)目經(jīng)理需要嚴(yán)格執(zhí)行研發(fā)流程中的每個(gè)環(huán)節(jié)，并跟進(jìn)落實(shí)到位，同時(shí)以質(zhì)量管理體系為參照標(biāo)準(zhǔn)，做好質(zhì)量管理。
二、工具建設(shè)
工具的重要性不言而喻，在上面十大要點(diǎn)中，也有特別地提及。
項(xiàng)目經(jīng)理需要有意識(shí)的推進(jìn)或落實(shí)對(duì)質(zhì)量管理有幫助的工具建設(shè)。
三、核心是人
人的能力高低、代碼能力的深淺、技術(shù)經(jīng)驗(yàn)豐富等，都是質(zhì)量管理的有力保證。項(xiàng)目的質(zhì)量管理中，最不可忽視的就是團(tuán)隊(duì)成員的能力。
作為項(xiàng)目經(jīng)理，不能指望著從目標(biāo)、流程、體系、工具等這些方面提升對(duì)質(zhì)量的管理，如果一旦這些都努力做到了，產(chǎn)品的質(zhì)量仍然沒(méi)有明顯的變化或提升，項(xiàng)目經(jīng)理需要果斷的從人員的維度進(jìn)行考量，向核心管理層提出招聘經(jīng)驗(yàn)豐富，能力更高的人，從根本上提升產(chǎn)品的質(zhì)量。
06 結(jié)語(yǔ)
最后，我想說(shuō)，質(zhì)量管理的終極目標(biāo)是挑戰(zhàn)零缺陷。
“零缺陷”思想，是早在20世紀(jì)60年代，被譽(yù)為“全球質(zhì)量管理大師”的菲利浦·克勞士比提出的，并在美國(guó)推行零缺陷運(yùn)動(dòng)。
克勞士比的“零缺陷”并不是說(shuō)絕對(duì)沒(méi)有缺陷或缺陷絕對(duì)要為零，而是指要以“缺陷等于零為最終目標(biāo)，團(tuán)隊(duì)成員的每個(gè)人都要在自己工作職責(zé)范圍內(nèi)努力做到無(wú)缺陷”。
這其實(shí)是要求我們要變被動(dòng)為主動(dòng)，在設(shè)計(jì)之前，就做好設(shè)計(jì)的防患措施，為設(shè)計(jì)高質(zhì)量的軟件打下堅(jiān)實(shí)的基礎(chǔ)，是要求項(xiàng)目團(tuán)隊(duì)人員具備更高的視野，從技術(shù)的角度出發(fā)，提出更多、更實(shí)際的設(shè)計(jì)質(zhì)量防控的措施。
一個(gè)項(xiàng)目的質(zhì)量，是需要依靠整個(gè)團(tuán)隊(duì)的共同努力，從需求開始，產(chǎn)品人員就要對(duì)需求的設(shè)計(jì)、各系統(tǒng)的關(guān)聯(lián)考慮得更周全。
開發(fā)人員要對(duì)底層框架設(shè)計(jì)，編碼規(guī)范，異常情況的考慮更細(xì)致。產(chǎn)品人員驗(yàn)收環(huán)節(jié)深入的驗(yàn)收，確保需求的實(shí)現(xiàn)符合預(yù)期。
測(cè)試人員要對(duì)測(cè)試分析，風(fēng)險(xiǎn)預(yù)判更深入、更全面，在測(cè)試總結(jié)分析時(shí)，要追本溯源，找到問(wèn)題的根源，分析后提出防范措施，并加以執(zhí)行。
因此，“零缺陷”是一個(gè)體系，不是依賴于某個(gè)人、某個(gè)團(tuán)隊(duì)就能做好，需要圍繞產(chǎn)品的整個(gè)開發(fā)鏈的所有團(tuán)隊(duì)、所有人都參加進(jìn)來(lái)，同時(shí)需要有高層領(lǐng)導(dǎo)的支持和參與。
聯(lián)系客服
