GOV II 治理 實施 用實例學 CMMI V2.0

上一篇分享提到，管理層的支持很重要，V2.0專門增加了治理 (GOV) 與 實施基礎 (II) 這兩個PA，因若要過程改進成功，公司必須有管理層的支持與系統支撐。

這道理大家都懂，但我看國內真正做到的公司很少，爲什麼？

剛剛中秋節當天，與一香港公司幾位高管做CMMI項目啓動前交流。會議後，我更瞭解過程改進的成功要素。

大家可從以下分享可瞭解，推進過程改善預先必須考慮哪些問題：

 

目錄

 

• 1爲改進交流打好基礎

• 2從公司的改進目標開始

• 3投資與回報

• 4利用系統收集數據.挖掘改進機會

• 5對CMMI的誤解

• 6項目管理系統

• 7如何獲得CMMI預算

• 8總結

• 9後記

• 10一資深顧問對這文章的反饋

爲改進交流打好基礎

他們與會共有5人，包括IT主管（他曾在IBM工作過很久，是非常有經驗的人士）；下面還有管研發、管項目管理（PMO），不同領域的負責人，他們行業經驗都在20年以上。

簡單介紹後，我便打開一張幻燈片（如下圖）
我問：你們知道圖上的T和G分別是哪家公司？

研發主管很快回答：T公司是豐田，G是通用。

從這裏我很開心瞭解到，這幫高管確實很有經驗，都很熟悉“豐田故事”，持續改進思路。

我接下來跟他們說：豐田大野內一和改善（Kaizen）

 

改良 vs 改善

• 改良是指通過投入資金使情況變好， 改善是指通過動腦筋使情況變好。

                                                    ——豐田副總裁 大野耐一 先生

 

我說:你們都很清楚，從5、60年代到今天，豐田很成功地利用PDCA不斷完善的管理模式，提升到世界第一。在CMMI剛出現時，美國很多軟件開發項目，延誤、超支或失敗，所以CMMI的核心思路是在軟件開發中不斷改善。
我問:你們覺得這個思路可以用在貴公司的改進嗎？
他們都很認同。

有了認同這個管理思路的基礎，我們繼續討論如何實實在在做好CMMI改進。

從公司的改進目標開始

大家有了改進的概念，我就問IT主管：你們有什麼改進目標？今年或者明年有什麼公司的提升目標？
他說：希望可以更好控制項目的延遲與成本。
我說：好，我們現在是什麼水平？
他沒概念。

我說：首先你們需要有度量來收集一些客觀數據，針對現在團隊的生產率——軟件開發很多主管都希望知道，但卻不清楚。因爲軟件開發和其他生產工業不同，產出物是看不到的，比如你看到200人的開發團隊好像每天都埋頭努力工作，但(如公司沒有項目管理系統)是無法知道他們真實效率如何。
主管說：這也是我常常問下面主管的問題，但一直沒有獲得答案。
我說：這些都是應該依據一些客觀數據，不僅僅是依靠項目經理來彙報。 ‘度量系統’就是能幫助你瞭解不同團隊之間的效率如何？生產率如何？

投資與回報

IT總監說：好，請問有沒有什麼資料說做了CMMI後，回報多少？或者有什麼數據證明所獲得的好處？

我說：以前在SEI的時候是有的，就是以下這圖，比如從抽樣的項目，回報(ROI)平均大概是4:1

我在國內極少遇到以上問題。
很多做CMMI都只考慮給顧問公司的費用，但沒考慮內部人員的投入成本，爲整個項目做預算。

其中一位經理補充說：我以前老公司的CMMI經驗是：人員/資源投入不少,內部人員的投入遠遠大於給顧問的費用。
我說：你們要預算好內部和外部成本，如果沒有預留充分資源，很難做好。但在做預算時要注意，很多我們做改進的工作量，其實不應算在CMMI預算裏，因爲平常工作也要改進，應是工作的一部分。但若是爲了做CMMI需要參加的額外培訓，準備文檔證據的時間等便應算在預算裏。
他們都贊同。

利用系統收集數據.挖掘改進機會

接下來我跟他們分享一個故事。

我以前分享過的一個關於瀑布開發的問題，如我所料，他們大部分的缺陷是在驗收和測試階段才發現，前面的單元測試和評審的發現很少，或者早期做相關測試但沒記錄。
研發經理說：我們有個大型的政府部門項目，在UAT期間，驗收測試發現的缺陷數超過2000個。 我就問他，是否可以把一些前期的評審和單元測試做好，以減少後面的缺陷呢？
研發經理迴應說：理論是可以，但是這個項目不一定有效，因爲這個項目時間很長，中間客戶方的經理換了4、5位，每個人的需求基本都推翻前一位項目負責人的需求。

我想了想，迴應說：我們工程說要有度量數據統計，如果以前統計過不同項目的延誤跟缺陷，那麼就可以建立公司的基線，知道哪些客戶他的項目成本、人員比其他公司高，下次接他的項目的時候，就可以預留一些空間，纔能有信心保證項目不虧損。

IT總監說：我們做乙方有個好處,跟做IT內部不同，內部是不可以選擇客戶來提供服務。但是做乙方的話，如果確實從歷史數據看到客戶的工作量很高，導致項目不賺錢，下次再有投標，就可以預留更好地預算空間，甚至不參加投標，避免虧損。

對CMMI的誤解

很多第一次接觸CMMI的經理都會誤解，以爲CMMI有一套標準過程，只需要照着去做，就可以達到CMMI的成熟度。 這位很有經驗的總監雖然曾是IBM的員工，但也有這個誤解。
我說：CMMI爲了滿足不同企業，會依據不同的客戶需要和團隊的特性，有不同的過程，爲了使CMMI可以在不同環境使用——從嚴謹的軍方項目到快速的敏捷項目，所以CMMI模型必須是一個比較高的框架，纔可以有這個靈活度，使得無論嚴謹還是快速，都可以用上。
開始的時候，這總監覺得很詫異：爲什麼沒有一套已經建議好的做法。
我接着說：其實每個開發團隊，無論他用什麼模式，自己肯定都有一套常用過程——雖然不一定是寫出來的。所以我們第一件事不是把一些外面的過程強加給他們用，而是要理解他們現在的過程，及如何匹配CMMI的最佳實踐，利用其中的差異，找出改進點。整個過程也需要團隊的參與。 例如下面的三角圖——一個成功的改進必須有模型、培訓、諮詢和工具的相互配合，才能成功。

單靠培訓和工具配合，可不可以？
評估的作用就類似於小孩學鋼琴——如果沒有每年的考級目標，就很難主動天天練琴。

這個企業比較注重項目管理的一些改進跟監控，所以後面我們就討論到，不同的項目管理工具也要配合到過程改進來用纔會有效。

 

項目管理系統

我說：根據你們希望完善項目延誤、控制項目成本的目標，最好可以借CMMI項目引進項目管理系統。

其中一位經理說：是的，我的老公司也是使用一套項目管理系統，要求每個團隊定期填工時表，這樣管理層就可以和財務可以及時知道實際的項目情況。

我說：對的，因爲我曾幫你們老公司做了10多年的CMMI過程改進，清楚他們那套系統可以體現很多CMMI項目管理和監控的最佳實踐。

 

如何獲得CMMI預算

IT總監問：應如何做好整個CMMI過程改進的預算，更好說服董事會，獲取批准。

我說：我沒有這方面的金科玉律，但可先回顧之前項目因爲缺陷而返工的損失是多少？比如剛纔你說的有些大型項目UAT 缺陷有超過2000個，你可以估算這些缺陷帶來的不必要的工作量、返工量是多少？成本是多少？然後就可以以這些成本的1/10、1/5作爲CMMI的預算。
同樣除了返工缺陷，也可以估計以往因爲項目的超時延誤導致的額外項目成本，雖然CMMI改進不可能完全消除，也可以作爲CMMI預算的參考。

總結

有些管理層不瞭解過程改進的原理，以爲是一套最佳實踐過程。 以爲只需套用一些顧問給的模板便會有效。

有些不相信過程改進改善能幫公司提升， 不希望改變以往的管理模式。

有些更可能是隻把CMMI過程改進視爲一個認證，希望以最小的投入，只要能通過評估便可。 沒有對內部人員投入的成本預算與相關自動化系統的預算。

以上都是很多公司未能真正從CMMI過程改進獲益的主因,也是爲什麼國內很少過程改進成功的原因。

公司要做好 治理(GOV)，不僅僅單靠高層口頭的支持，如沒有資源投入，改進便只是夢想。

 

後記

剛剛在中秋放假前，我爲另外一家公司專門做測繪業務的公司，準備CMMI評估。因爲軟件開發只佔公司業務的一小部分，很多軟件開發的實施都沒做好，例如配置管理、評審、單元測試等。

第一次到客戶現場，我都要求先與發起人(總經理)會面。 這位總經理行業經驗也很豐富，精通測繪業務，對我說他們行業從以前的手工爲主到現在越來越依賴軟件。

我對發起人說：很感謝你抽空過來，CMMI過程改進都是從公司的商業目標出發，所以想先了解你對現在公司的軟件開發有什麼要求？覺得有什麼不足？

他說：在我們項目中很多是需要軟件集成硬件，軟件只佔一部分，從我看來我們軟件沒有什麼問題。

我再問：有沒有一些你希望做的更好的地方，或者現在有什麼不足需要改進？

他想了想，迴應：確實沒有，都挺好。

從這個簡單的對話，我就瞭解，我後面要他們下面做什麼改進都不會有效果，因爲高層根本不瞭解過程改進，也沒有這個意願。

這讓我回想到幾個月前，有個總監說過，他下面有一些管軟件團隊的經理本身不是軟件開發出身，所以不知道軟件開發對測試質量的重要性，所以分配到測試的人員很少。

所以管理者的想法以及認同很重要。

 

一資深顧問對這文章的反饋

以下是我對當前國內大多數軟件公司實施相關內容的看法；

國內軟件公司大致可按成熟度分爲A B C三類：

A類--有大量項目實施積累，有基本的項目管理方法；

對體系的接受度比較高，容易對照模型的指導找差距，也可以根據已積累的實施數據、經驗快速進行改進，對於改善的目標較爲明確，改善方案的推進較爲順利。一般這類公司高層的配合度也較高，有了較多項目的實施積累，高層對於項目管理、質量、痛點的解決這些目標都比較清晰，目標分解、實施皆較爲易行，項目成本測算較爲精細。

B類--有一些項目實施積累，項目管理方法還在摸索中；

有較多項目實施上的痛點，但是在項目管理和實施方法上迫切需要有人指導，對於度量、改進的推廣略有難度，需要先培訓，梳理缺漏過程，建立基礎的體系標準（基礎項目實施要求），然後再逐步提升、優化。這類公司的高層迫切希望提升客戶的滿意度，提高項目實施過程的規範性，減少售後支持的壓力，項目成本測算較爲粗放。

C類--項目實施積累較少，暫無項目管理方法（以快速完成項目獲取利潤爲目標）。

公司處於上升期，亟需賺取利潤維持企業運轉，故公司高層大多關注於工期的縮短、成本的降低和客戶關係的維持，在體系的建設和過程管理的改善上沒有太多的目標要求，較多爲爲了獲取更多的合同而進行體系認證。體系過程改進的推廣較爲困難。

 

三類公司共同點：

公司需要如實反映當前項目的實施現狀，提出項目實施的痛點，便於諮詢人員協助進行過程實施分析，共同提煉出過程改進的目標，商討過程改進方案，然後進行PDCA實施。

在實施過程中，我們必須瞭解不同層次的干係人對過程改進的關注焦點及期待，例如：

1. 公司高層的關注重點：

   • 是否能夠實時瞭解各產品實施成本、實施平均週期及質量現狀

   • 是否可以降低成本（產品售前成本、項目實施成本、售後維護成本、管理成本、其他成本--如房租、福利等）

   • 是否可以提高產品質量，進而使客戶滿意

   • 是否有利於關鍵項目團隊及內部人員的穩定

   • 是否可以增強競爭優勢，從而促使商業目標的實現

2. 項目經理的關注重點：

   • 是否可以加快項目進度，進度可控

   • 是否有助於提升產品質量

   • 是否有助於降低人員的流動性

   • 是否有助於提升項目實施效率、降低實施風險

   • 是否有助於項目成本的降低

   • 是否有助於提升個人技能及在團隊中的威信力

3. 團隊成員的關注重點：

   • 是否有助於提升工作效率，減少加班

   • 是否有助於提升產品質量

   • 是否有助於提升個人的管理、工具使用、技術應用等能力

因必須獲得各層次干係人的支持，過程改進纔有機會成功。而基於客觀數據的溝通起關鍵作用。