一邊是某諮詢公司在專案管理培訓中宣講：「cmm2級企業不適合實施6sigma，應該等到cmm4級之後，度量體系比較完善時再進行。」一邊是2023年世界軟體工程大會上，各國專家達成共識：「cmm/cmmi與6sigma能夠結合，互相促進」。我們怎麼辦？我以前主張：爭執暫放一邊，抓緊時間邊實踐邊改進，否則結果就很可能是：「我們在進步，但是我們與競爭對手相比更加落後。」有些同事接受了我的看法，於是又有一問：「你有沒有在軟體中實施6sigma的成功案例？」6個月前我還沒有，但是現在我有了幾個典型案例，它們各具特色，讓我們在此一一分享。
一、6sigma能幫助解決軟體技術問題嗎？
第乙個專案是在去年年末，參加乙個事業部的6sigma優秀專案發布會看到的。專案名稱是《xx網管系統提高告警吞吐率》，問題是在大量告警上報時，unix伺服器的告警處理吞吐率僅為8條/秒，同時占用cpu達90％，導致其它模組的操作基本上不能進行。使用者對此非常不滿，要求我公司盡快解決此問題，提高吞吐率到至少48條/秒，而系統成本不能有較大幅度增加。如何解決這個問題？乙個解決方案是提高硬體的配置，從而提高處理效能，但是這樣做會大大增加採購成本，而效能並不會有極大的提公升，實際上降低了產品的可銷性，這樣的投入收益比極不合算，此方案被拒絕。專案組在花了大量時間和精力，仍然尋找不到合適的解決辦法之後，想到了6sigma。大家知道，6sigma專案的選擇就是那些「難度大、影響力大」的問題，於是這個專案組的成員將此問題立項，期待6sigma能在黑暗中帶來曙光。
除去定義與測量階段，此專案的分析思路是這樣的：首先是頭腦風暴魚骨圖，羅列所有大家能想到的可能原因；然後將這些原因按照告警的邏輯處理流程組織成fmea，進行rpn分析，篩選出rpn值大於100的少數因素，作為潛在的關鍵因子；之後對這些潛在因子逐一試驗，進行確認。整個專案的突破就出現在第乙個因子的試驗中，其試驗資料如圖1所示，橫座標表示輸入的告警流量，縱座標表示告警處理延時。圖中的曲線顯示有週期性的拐點，而在拐點之後，告警流量增加，伺服器的處理延時反而有較大的降低。這個現象如果沒有針對此原因的試驗，沒有這些資料是無法看到的。分析這個現象的原因，難不到我們的軟體工程師，很快就得出了結論：tcp協議引數設定不當。修改此引數後，重新做同樣的試驗，得到資料如圖2所示，可見其告警吞吐率基本上與輸入流量呈線性關係增長，瓶頸已經消除。這不僅僅是確認了此因子是關鍵因子，同時也驗證了改進措施的有效性。另外幾個因子也是類似的，通過針對每一種可疑因子的試驗，或確認此因子為關鍵因子，或篩選影響不大的因子；然後針對每個關鍵因子尋找技術上的解決辦法，就更不在話下了。此專案的成功為公司創造了每年166萬的收益。
回顧這個專案，又應驗了一句老話：「解決難題經常是99％的努力在於尋找關鍵原因所在，而修改只需要1％的努力。」6sigma本身並不提供技術解決方案，但是它的思路引導我們向著正確的方向邁進，而資料是保障我們方向正確的重要依據。此專案雖然是軟體專案，但是問題本身y是可以清晰度量的，這也是它能夠適應6sigma特色，得以成功的乙個原因。
圖1 某專案針對關鍵因子一的告警處理流量試驗資料圖
圖2 某專案修改了協議引數後的告警處理吞吐率圖
二、主觀判斷的結果有說服力嗎？
這個案例是黑帶專案《降低異常**故障率》，它從cq分析的主要故障型別之一：異常**故障率居高不下而來，這體現出負責人主動從失誤中學習和進步的精神，也給很多仍然為找不到合適專案的同事乙個啟示：cq庫是乙個很方便的專案寶庫。
此專案對於故障分類的測量系統分析，是離散資料做測量系統分析的典型。在研發過程中，我們經常遇到「只可意會不可言傳」的情形，大家都是主觀判斷「拍腦袋」，這樣的分析如何具有說服力？主觀判斷不等於拍腦袋，這個專案可以作為參考，感覺上的東西通過制定一定的準則，能夠將大家的主觀判斷達到基本一致和準確的標準。以下摘自此專案負責人的總結文章：
在確定了故障的分類規則後，對於故障進行分類，對於同乙個故障不同的研發人員分類可能出現不同的結果。出現這種問題可能是有兩個原因：(1)故障分類的標準還不夠明確，參加故障分類的研發人員對於故障理解不同。(2)參加故障分類的研發人員沒有能力按分類標準對故障進行分類。解決的辦法是在故障分類前進行測量系統分析，確認故障分類標準是否已經明確，參加分類故障的研發人員是否具備了故障分類能力。
對於故障分類進行的測量系統分析可採用離散測量系統分析。進行離散測量系統分析的基本步驟為：
1、 在需要分析的故障中隨機抽取30個故障。
2、 多個開發經理按故障分類標準共同確定每個故障的分類結果。（作為「真值」——本文作者）
3、 讓參加故障分類的研發人員按故障分類標準進行分類。（作為「測量值」——本文作者）
4、 一周後，讓參加故障分類的研發人員重新按故障分類。
5、 進行離散測量系統分析，確定故障分類的準確性、重複性和再現性。
如果通過測量系統分析，發現故障分類的重複性有問題，同乙個研發人員對於同乙個故障的判定結果不相同，則一般是研發人員自身素質的問題，採取的措施是需要加強對分類標準的學習。如果不同研發人員之間的再現性有問題，則一般是由於分類標準不明確造成，需要進一步明確分類標準。若重複性、再現性都符合要求通過，基本可以保證故障分類的標準定義是明確的，參加故障分類的研發人員的技能已經符合要求。
實際上這種測量系統分析的方法並非第一次使用，去年我們研究所的乙個綠帶專案做法極其類似，其原理如圖3所示。
圖3 某綠帶專案的測量系統分析原理圖示
這是一種典型的離散資料msa的案例，在展示時，不少研發人員很吃驚：「原來msa是可以這樣做的」，或者「原來是可以這樣得到量化資料的」。有很多人總是說研發過程中的資料量化不足，所以不適合做6sigma專案。其實不是6sigma不能用於研發領域，而是很多時候是我們沒有找到正確的方法而已。所以多思考、多動手，這個從小老師就教我們的話，在工作中一樣適用。
三、如何提高執行力？
記得前不久一位領導說：「我們公司從來不缺好的策劃，我們缺的是好的執行。」軟體中的問題有些就是執行的問題，如規範的執行不嚴格，流程不合理等等。有人會問：「如果解決方案就是執行的問題，可以依據其影響力選擇合理化建議，或者團隊專案來解決，並不適合做6sigma專案。」實際上，一來6sigma專案在開始時並不知道關鍵因子是什麼，二來執行也不簡單，知道和做到是兩碼事，正如乙個黑帶所言：「聽到你會忘記，看到你會記住，做到你才會明白。」
言歸正傳，這個案例是另乙個黑帶專案《提高功能測試儀的軟體研發效率》，研發效率的定義為單位軟體的軟體開發和維護人力成本。這個專案的特點首先是非常細緻，每乙個步驟都按照6sigma的思路、方法完整、清晰地描述，可以作為初學者的樣板指導。然而對我而言，它更加重要的特點是它強大的執行力。在分析階段，已經確認了三個關鍵因子：
1． 模組化程度不高；
2． 介面文件不規範；
3． 系統部、軟體部、硬體部溝通機制不健全；
為了解決第乙個問題，此專案提出建立10個模組的目標，而目前它只有3個模組；為了解決第二個問題，需要建立介面文件的模板，但是更重要的是得到使用者的認可和操作；而第三個問題更是需要三個部門的最高長官——部長來親自溝通協調解決。以上這些，這個專案都做到了！怎麼做到的？看看他的團隊成員，有研究所的所長，乙個產品總經理，三個相關部門的部長，還有相關的所有科長、開發經理，以及部分開發人員，這樣的團隊架構，還擔心解決方案得不到執行嗎？
案就是這麼簡單，每個專案負責人都需要慎重選擇您的團隊成員，力爭讓每個人各盡所長。團隊中需要各種人員：首先是各方客戶代表，然後是善於分析者，善於操作者，善於協調者，以及流程主管或組織負責人等等。記得以前有個專案，成員基本上都是專案經理，這樣的團隊溝通倒是通暢了，可是說到做具體的事情，大家都沒有時間做，專案怎麼進展呢？最後只有取消。想想有多少專案在到達終點之前倒下去，少有找不到解決辦法的，但是做出來的方案無法兜售給使用方，從而不能達到專案目標，這倒是常見。為什麼？多數是因為團隊中沒有使用方的代表，強加的東西誰都不喜歡。
也許有人會講，其實說到執行，就是要把領導拉進來，搞定了領導，讓領導出面推進執行和追蹤，就一切ok了。這話不對，因為我們不可能把領導搞定的，只會是領導把我們搞定：選擇專案一定要把握領導最關心的問題；即使不是最關心的，也要是在他的問題列表中位於前列的問題。如果你要做的就是領導非常想解決的問題，那麼邀請他加入專案團隊，請他做一些追蹤工作自然順理成章；然而如果選擇的課題，在領導問題列表中遠沒有排在前列，讓他分散精力，同時消耗他的資源來做事，他自然不肯。這就是目前我們強調自上而下產生專案的原因。目前，我們公司在一定程度上還是人治的社會，承認這個現實，並且主動調整我們的做法適應現狀，才是做事的明智之舉。
以上是我近期收集到比較典型和成功的軟體6sigma專案。然而我不得不承認，在公司已經完成的上千個專案中，軟體專案仍然是佔非常少的比例。如果是因為沒有成功的案例，影響到大家的信心，或者不知道怎麼入手來做，希望本文能夠為大家提供一些參考。cmm/cmmi與6sigma的結合和互相促進，在雙方領域內都是新課題，還有很大的拓展空間。目前我們公司也有不少黑帶身處epg，選擇的專案正是這個新課題。一年之後，我們再來回顧，希望能有更大的突破，讓我們也在6sigma的歷史上留下光彩的一筆。
6sigma管理的「七步驟法」
目前，業界對6sigma管理的實施方法還沒有乙個統一的標準。大致上可以摩托羅拉公司提出並取得成功的 七步驟法 seven stepmethod 作為參考。七步驟法 的內容如下 1 找問題 selectaproblemanddescribeitclearly 把要改善的問題找出來，當目標鎖定後便召集有...
6sigma精益改善 常用術語和方法工具
最近在學習6sigma精益改善，裡面常用的技術術語，記錄在此，供參考 在開始之前給大家分享下 學習三動 聽起來很激動，想起來很感動，做起來一動不動 度量單位 dpu 單位缺陷數，defects per unit dpo 每單位機會缺陷數，defects per opportunity dpmo de...
軟體研發的特點
追本溯源是人類的天性。當面對問題時，人們都會問，為什麼這樣做不行？為什麼那樣做就行？談及軟體研發過程中的問題和改善措施，需要首先分析其問題的本質，究竟是什麼原因造成了軟體研發過程的眾多問題。這樣我們才能說服自己，也說服別人，從根本上做些改變。在分析軟體研發特點之前，讓我們首先討論一下人類另外兩大類主...