持續(xù)改進(jìn)（Continual improvement），也叫持續(xù)改善（Kaizen），最初是一個日本管理概念，指逐漸、連續(xù)地增加改善，是日本持續(xù)改進(jìn)之父今井正明在《改善-日本企業(yè)成功的關(guān)鍵》一書中提出的。Kaizen意味著改進(jìn)，涉及每一個人、每一環(huán)節(jié)的連續(xù)不斷的改進(jìn)，從高層管理人員、中層管理人員到工人。
持續(xù)改進(jìn)的關(guān)鍵因素是：質(zhì)量、所有雇員的努力、介入，自愿改變和溝通。提出持續(xù)改進(jìn)的原因是在做項目的過程中，如果發(fā)現(xiàn)一個問題，要在吸取經(jīng)驗教訓(xùn)之后進(jìn)行改正，主要用于推動事情發(fā)展的。項目不能反復(fù)地踩同一個坑，大家如果遇到了一次問題，下次再遇到這樣的問題你就不會再犯錯誤，這時候就已經(jīng)叫做改進(jìn)了。從這個角度來說，持續(xù)改進(jìn)是質(zhì)量管理重點關(guān)注的內(nèi)容。
項目管理有一個很重要的原則叫做吸取經(jīng)驗教訓(xùn)，吸取經(jīng)驗教訓(xùn)的背后其實就是要持續(xù)改進(jìn)。每次我們吸取了經(jīng)驗教訓(xùn)下次不犯了，這個就叫持續(xù)改進(jìn)。
本文基于軟件項目，探討如何持續(xù)改進(jìn)軟件質(zhì)量。
一、遇到的問題
在做項目過程中，經(jīng)常出現(xiàn)“反復(fù)踩同一個坑”的情況。一個團隊里小李犯了一個錯誤導(dǎo)致生產(chǎn)事故，沒多久后，小王又因同樣的錯誤導(dǎo)致生產(chǎn)事故，又沒多久，小張因類似錯誤導(dǎo)致生產(chǎn)事故………
作為項目管理人員，碰到團隊成員一而再、再而三的出現(xiàn)這個問題，絕對惱火。組織開會討論，強調(diào)安全生產(chǎn)、生產(chǎn)無小事等等，讓團隊成員緊繃一根弦。
短時間可能有效，但我們發(fā)現(xiàn)，沒過多久，還是會出現(xiàn)類似的錯誤。
二、持續(xù)改進(jìn)辦法
1、測試改進(jìn)
從測試階段來說，通常包括單元測試、系統(tǒng)測試（SIT）和驗收測試（UAT），每個測試階段的關(guān)注點不同，但相同的目標(biāo)都是檢查產(chǎn)品質(zhì)量、找出產(chǎn)品存在的缺陷。所以，我們歡迎測試人員在項目的各個階段發(fā)現(xiàn)缺陷、提出問題，但我們更歡迎在早期發(fā)現(xiàn)問題。發(fā)現(xiàn)越早，改造成本越小。
從測試手段來說，包括手工測試和自動化測試。手工測試由測試人員依據(jù)需求、設(shè)計編寫案例，采用腳本或客戶端操作的方式進(jìn)行驗證。自動化測試是把以人為驅(qū)動的測試行為轉(zhuǎn)化為機器執(zhí)行的一種過程。通常，在設(shè)計了測試用例并通過評審之后，由測試人員根據(jù)測試用例中描述的規(guī)程一步步執(zhí)行測試，得到實際結(jié)果后，與預(yù)期結(jié)果進(jìn)行比較。
手工測試更多的依賴測試人員的經(jīng)驗和責(zé)任心，而自動化測試可以集大眾經(jīng)驗，且節(jié)省人力、時間和硬件資源，提高了測試效率，目前比較受推崇。
遇到問題后，我們需要做測試改進(jìn)，更新測試案例或測試手段，比如，增加死循環(huán)檢查的案例、超時的案例、邊界值的案例等等。在這個問題上，自動化測試更占優(yōu)勢。
2、直面問題，不避諱、不隱瞞。
創(chuàng)造一種直面問題、不避諱、不隱瞞的工作氛圍。
這個事情說起來容易，做起來難。通常出問題后，我們總是希望知道的人越少越好，以免給部門帶來不好的影響。通常來說，隱瞞是為了考核、是為了績效。大部分公司都有健全的績效考核制度，出現(xiàn)生產(chǎn)問題時，會扣責(zé)任人的考評分?jǐn)?shù)或工資。倒不是說應(yīng)該取消這項制度，但HR部門最好能將兩個事情結(jié)合起來考慮，建立一種怎樣的考評機制，能讓大家敢于直面問題。
讓應(yīng)該知道的人知道。哪些人是應(yīng)該知道的人呢？項目團隊，跟你從事同一個崗位、負(fù)責(zé)同一個系統(tǒng)的小伙伴們。有了問題、出了事情，怎么解決的，原因是什么等等，一定要讓這些小伙伴們了解清楚。
3、建立問題比對機制（逐項比對，逐項打勾）
從某個角度講，犯過的錯誤也是一種資產(chǎn)、一種財富，當(dāng)然要建立在對這些錯誤充分分析、提出改進(jìn)措施的前提下。我們將團隊成員犯過的錯誤登記下來，團隊范圍內(nèi)共享，并且，投產(chǎn)評審時，要將這些問題比對一遍，確保歷史問題沒有出現(xiàn)。
在有的公司里，將歷史問題登記在《代碼走查單》中，做代碼評審時，逐項勾對。剛開始的時候還好，后期可能就變成一種形式，起不到預(yù)想的作用。
4、搭建問題墻。
我們已經(jīng)相當(dāng)習(xí)慣搭建榮譽墻，這樣看著舒服，團隊成員面子上也有光，但成績都是歷史，這些還是放在晉升報告里寫吧。在這里，我們要搭建問題墻。將團隊成員犯過的錯誤張貼在墻上，當(dāng)然，這個匿名比較好，只談問題、談原因、談解決辦法，也就是對事不對人。問題上墻的前提還是第一條，團隊要有直面問題、不避諱、不隱瞞的工作氛圍，這個時候團隊經(jīng)理要起表率作用，可以將自己以前犯過的錯、踩過的坑都貼出來，讓大家效仿；鼓勵團隊成員貢獻(xiàn)自己的“歷史問題”。
有新問題產(chǎn)生時，團隊經(jīng)理帶領(lǐng)大家分析、解決問題后，將問題貼上墻，一來讓大家學(xué)習(xí)，二來起到警鐘作用。
以上，是本人在項目管理中用到、想到的方法，應(yīng)用這些方法后，的確提升了軟件質(zhì)量。然而，提升軟件質(zhì)量無止境，方法也必然很多，需要項目經(jīng)理們不斷總結(jié)經(jīng)驗教訓(xùn)，不斷提升！
