一邊是某咨詢公司在項目管理培訓中宣講：“CMM2級企業(yè)不適合實施6sigma，應該等到CMM4級之后，度量體系比較完善時再進行。”一邊是2004年世界軟件工程大會上，各國專家達成共識：“CMM/CMMI與6sigma能夠結合，互相促進”。我們怎么辦?我以前主張：爭執(zhí)暫放一邊，抓緊時間邊實踐邊改進，否則結果就很可能是：“我們在進步，但是我們與競爭對手相比更加落后。”有些同事接受了我的看法，于是又有一問：“你有沒有在軟件中實施6sigma的成功案例?”6個月前我還沒有，但是現(xiàn)在我有了幾個典型案例，它們各具特色，讓我們在此一一分享。

　　一、6sigma能幫助解決軟件技術問題嗎?

　　第一個項目是在去年年末，參加一個事業(yè)部的6sigma優(yōu)秀項目發(fā)布會看到的。項目名稱是《XX網(wǎng)管系統(tǒng)提高告警吞吐率》，問題是在大量告警上報時，UNIX服務器的告警處理吞吐率僅為8條/秒，同時占用CPU達90%，導致其它模塊的操作基本上不能進行。用戶對此非常不滿，要求我公司盡快解決此問題，提高吞吐率到至少48條/秒，而系統(tǒng)成本不能有較大幅度增加。如何解決這個問題?一個解決方案是提高硬件的配置，從而提高處理性能，但是這樣做會大大增加采購成本，而性能并不會有極大的提升，實際上降低了產(chǎn)品的可銷性，這樣的投入收益比極不合算，此方案被拒絕。項目組在花了大量時間和精力，仍然尋找不到合適的解決辦法之后，想到了6sigma。大家知道，6sigma項目的選擇就是那些“難度大、影響力大”的問題，于是這個項目組的成員將此問題立項，期待6sigma能在黑暗中帶來曙光。

　　除去定義與測量階段，此項目的分析思路是這樣的：首先是頭腦風暴魚骨圖，羅列所有大家能想到的可能原因;然后將這些原因按照告警的邏輯處理流程組織成FMEA，進行RPN分析，篩選出RPN值大于100的少數(shù)因素，作為潛在的關鍵因子;之后對這些潛在因子逐一試驗，進行確認。整個項目的突破就出現(xiàn)在第一個因子的試驗中，其試驗數(shù)據(jù)如圖1所示，橫坐標表示輸入的告警流量，縱坐標表示告警處理延時。圖中的曲線顯示有周期性的拐點，而在拐點之后，告警流量增加，服務器的處理延時反而有較大的降低。這個現(xiàn)象如果沒有針對此原因的試驗，沒有這些數(shù)據(jù)是無法看到的。分析這個現(xiàn)象的原因，難不到我們的軟件工程師，很快就得出了結論：TCP協(xié)議參數(shù)設置不當。修改此參數(shù)后，重新做同樣的試驗，得到數(shù)據(jù)如圖2所示，可見其告警吞吐率基本上與輸入流量呈線性關系增長，瓶頸已經(jīng)消除。這不僅僅是確認了此因子是關鍵因子，同時也驗證了改進措施的有效性。另外幾個因子也是類似的，通過針對每一種可疑因子的試驗，或確認此因子為關鍵因子，或篩選影響不大的因子;然后針對每個關鍵因子尋找技術上的解決辦法，就更不在話下了。此項目的成功為公司創(chuàng)造了每年166萬的收益。

　　回顧這個項目，又應驗了一句老話：“解決難題經(jīng)常是99%的努力在于尋找關鍵原因所在，而修改只需要1%的努力。”6sigma本身并不提供技術解決方案，但是它的思路引導我們向著正確的方向邁進，而數(shù)據(jù)是保障我們方向正確的重要依據(jù)。此項目雖然是軟件項目，但是問題本身Y是可以清晰度量的，這也是它能夠適應6sigma特色，得以成功的一個原因。

　　圖1 某項目針對關鍵因子一的告警處理流量試驗數(shù)據(jù)圖

　　圖2 某項目修改了協(xié)議參數(shù)后的告警處理吞吐率圖

　　二、主觀判斷的結果有說服力嗎?

　　這個案例是黑帶項目《降低異常代碼故障率》，它從CQ分析的主要故障類型之一：異常代碼故障率居高不下而來，這體現(xiàn)出負責人主動從失誤中學習和進步的精神，也給很多仍然為找不到合適項目的同事一個啟示：CQ庫是一個很方便的項目寶庫。

　　此項目對于故障分類的測量系統(tǒng)分析，是離散數(shù)據(jù)做測量系統(tǒng)分析的典型。在研發(fā)過程中，我們經(jīng)常遇到“只可意會不可言傳”的情形，大家都是主觀判斷“拍腦袋”，這樣的分析如何具有說服力?主觀判斷不等于拍腦袋，這個項目可以作為參考，感覺上的東西通過制定一定的準則，能夠?qū)⒋蠹业闹饔^判斷達到基本一致和準確的標準。以下摘自此項目負責人的總結文章：

　　在確定了故障的分類規(guī)則后，對于故障進行分類，對于同一個故障不同的研發(fā)人員分類可能出現(xiàn)不同的結果。出現(xiàn)這種問題可能是有兩個原因：(1)故障分類的標準還不夠明確，參加故障分類的研發(fā)人員對于故障理解不同。(2)參加故障分類的研發(fā)人員沒有能力按分類標準對故障進行分類。解決的辦法是在故障分類前進行測量系統(tǒng)分析，確認故障分類標準是否已經(jīng)明確，參加分類故障的研發(fā)人員是否具備了故障分類能力。

　　對于故障分類進行的測量系統(tǒng)分析可采用離散測量系統(tǒng)分析。進行離散測量系統(tǒng)分析的基本步驟為：

　　1、 在需要分析的故障中隨機抽取30個故障。

　　2、 多個開發(fā)經(jīng)理按故障分類標準共同確定每個故障的分類結果。(作為“真值”——本文作者)

　　3、 讓參加故障分類的研發(fā)人員按故障分類標準進行分類。(作為“測量值”——本文作者)

　　4、 一周后，讓參加故障分類的研發(fā)人員重新按故障分類。

　　5、 進行離散測量系統(tǒng)分析，確定故障分類的準確性、重復性和再現(xiàn)性。

　　如果通過測量系統(tǒng)分析，發(fā)現(xiàn)故障分類的重復性有問題，同一個研發(fā)人員對于同一個故障的判定結果不相同，則一般是研發(fā)人員自身素質(zhì)的問題，采取的措施是需要加強對分類標準的學習。如果不同研發(fā)人員之間的再現(xiàn)性有問題，則一般是由于分類標準不明確造成，需要進一步明確分類標準。若重復性、再現(xiàn)性都符合要求通過，基本可以保證故障分類的標準定義是明確的，參加故障分類的研發(fā)人員的技能已經(jīng)符合要求。

　　實際上這種測量系統(tǒng)分析的方法并非第一次使用，去年我們研究所的一個綠帶項目做法極其類似，其原理如圖3所示。

　　圖3 某綠帶項目的測量系統(tǒng)分析原理圖示

　　這是一種典型的離散數(shù)據(jù)MSA的案例，在展示時，不少研發(fā)人員很吃驚：“原來MSA是可以這樣做的”，或者“原來是可以這樣得到量化數(shù)據(jù)的”。有很多人總是說研發(fā)過程中的數(shù)據(jù)量化不足，所以不適合做6sigma項目。其實不是6sigma不能用于研發(fā)領域，而是很多時候是我們沒有找到正確的方法而已。所以多思考、多動手，這個從小老師就教我們的話，在工作中一樣適用。

　　三、如何提高執(zhí)行力?

　　記得前不久一位領導說：“我們公司從來不缺好的策劃，我們?nèi)钡氖呛玫膱?zhí)行。”軟件中的問題有些就是執(zhí)行的問題，如規(guī)范的執(zhí)行不嚴格，流程不合理等等。有人會問：“如果解決方案就是執(zhí)行的問題，可以依據(jù)其影響力選擇合理化建議，或者團隊項目來解決，并不適合做6sigma項目。”實際上，一來6sigma項目在開始時并不知道關鍵因子是什么，二來執(zhí)行也不簡單，知道和做到是兩碼事，正如一個黑帶所言：“聽到你會忘記，看到你會記住，做到你才會明白。”

　　言歸正傳，這個案例是另一個黑帶項目《提高功能測試儀的軟件研發(fā)效率》，研發(fā)效率的定義為單位軟件的軟件開發(fā)和維護人力成本。這個項目的特點首先是非常細致，每一個步驟都按照6sigma的思路、方法完整、清晰地描述，可以作為初學者的樣板指導。然而對我而言，它更加重要的特點是它強大的執(zhí)行力。在分析階段，已經(jīng)確認了三個關鍵因子：

　　1. 模塊化程度不高;

　　2. 接口文檔不規(guī)范;

　　3. 系統(tǒng)部、軟件部、硬件部溝通機制不健全;

　　為了解決第一個問題，此項目提出建立10個模塊的目標，而目前它只有3個模塊;為了解決第二個問題，需要建立接口文檔的模板，但是更重要的是得到使用者的認可和操作;而第三個問題更是需要三個部門的最高長官——部長來親自溝通協(xié)調(diào)解決。以上這些，這個項目都做到了!怎么做到的?看看他的團隊成員，有研究所的所長，一個產(chǎn)品總經(jīng)理，三個相關部門的部長，還有相關的所有科長、開發(fā)經(jīng)理，以及部分開發(fā)人員，這樣的團隊架構，還擔心解決方案得不到執(zhí)行嗎?

　　案就是這么簡單，每個項目負責人都需要慎重選擇您的團隊成員，力爭讓每個人各盡所長。團隊中需要各種人員：首先是各方客戶代表，然后是善于分析者，善于操作者，善于協(xié)調(diào)者，以及流程主管或組織負責人等等。記得以前有個項目，成員基本上都是項目經(jīng)理，這樣的團隊溝通倒是通暢了，可是說到做具體的事情，大家都沒有時間做，項目怎么進展呢?最后只有取消。想想有多少項目在到達終點之前倒下去，少有找不到解決辦法的，但是做出來的方案無法兜售給使用方，從而不能達到項目目標，這倒是常見。為什么?多數(shù)是因為團隊中沒有使用方的代表，強加的東西誰都不喜歡。

　　也許有人會講，其實說到執(zhí)行，就是要把領導拉進來，搞定了領導，讓領導出面推進執(zhí)行和追蹤，就一切OK了。這話不對，因為我們不可能把領導搞定的，只會是領導把我們搞定：選擇項目一定要把握領導最關心的問題;即使不是最關心的，也要是在他的問題列表中位于前列的問題。如果你要做的就是領導非常想解決的問題，那么邀請他加入項目團隊，請他做一些追蹤工作自然順理成章;然而如果選擇的課題，在領導問題列表中遠沒有排在前列，讓他分散精力，同時消耗他的資源來做事，他自然不肯。這就是目前我們強調(diào)自上而下產(chǎn)生項目的原因。目前，我們公司在一定程度上還是人治的社會，承認這個現(xiàn)實，并且主動調(diào)整我們的做法適應現(xiàn)狀，才是做事的明智之舉。

　　以上是我近期收集到比較典型和成功的軟件6sigma項目。然而我不得不承認，在公司已經(jīng)完成的上千個項目中，軟件項目仍然是占非常少的比例。如果是因為沒有成功的案例，影響到大家的信心，或者不知道怎么入手來做，希望本文能夠為大家提供一些參考。CMM/CMMI與6sigma的結合和互相促進，在雙方領域內(nèi)都是新課題，還有很大的拓展空間。目前我們公司也有不少黑帶身處EPG，選擇的項目正是這個新課題。一年之后，我們再來回顧，希望能有更大的突破，讓我們也在6sigma的歷史上留下光彩的一筆。

　　參考資料：

　　《讓失敗成為成功的母親》，徐金爐，2004-3。