“真感謝你這幾個月幫助我們試點專案應用這專案管理工具，現在我才理解這個工具確實很適用於我們軟體開發專案的管理。下個月我會開始要求所有研發專案都使用這方式與新的專案管理模板。”——進入CMMI評估前的最後準備的第一天，技術總監對我們的顧問這樣說。

 

讓我們一起回顧他們公司如何結合CMMI、敏捷、專案管理工具提升管理：

 

1「背景」

 

這是杭州一家專門做政府專案的公司，人數接近300。

技術總監一直深信要想可持續的過程改進，必須有自動化工具的配合。

以前公司一直使用開源工具來管理專案，也嘗試做了些訂製軟體，但因為都是基於缺陷管理開發的工具，只可以做到基本的任務管理，很難做到整個專案的計劃與監控。

 

2「希望解決的問題」

 

希望解決的問題——主要是希望管理好專案進度與成本

開源工具只可以記錄基本的任務，更希望有以下功能：

1. 工作任務分解 WBS 管理

WBS可以分層組織任務，而且建立活動間的依賴關係:

 

一般專案WBS都會包含很多活動，但專案經理不可能把每一項活動都計劃好，她只可以把專案分成多個子專案，然後由小組組長計劃下面的具體活動，例如測試、需求等子計劃。

所以需要各組長協同做計劃，而不是由專案經理一個人包辦。

但傳統的專案管理工具，很多都不支援，所有活動主要由專案經理一人統一管理。

 

2.  專案成本管理

公司的大部分收入是來自軟體專案，但單軟體專案最大的成本是人力成本，經常需要到專案結束才可以知道總共花了多少人力成本。

其實管理層對專案管理的要求很簡單，正如下面的圖，想實時清楚計劃和實際相比是否延後？是否超支？

正如這公司的技術總監說大家學專案管理的時候都學過這張圖，但因為缺乏監控工具而無法看到實際與計劃的對比。

希望專案管理工具可以每月甚至每週，即時按實際的人員工時表結算到現在的實際成本，並與預算對比差多少？不要等到最終才知道超過預算。

 

3.  變更管理

 

專案變更很常見，中間沒有實時記錄變更的話，會導致專案看不到進度偏差，但實際上與最初的基線比較延期不少。

 

4.  收集真正的實際工時

現在員工填工時表時，都基本按計劃填寫，沒有真正的實際工時，新的工具可以設定每一個活動的產出物，必須通過評審才算任務100% 完成。

 

5.  統計專案真實工作量，成為公司基線/標杆

也因缺乏專案進度、工作量的真正歷史資料，導致有新專案投標時無法估算成本，使得報價過低，贏了專案卻不能盈利。

 

6.  專案人員分配

現在只是靠部門主管手工分配，但經常出現重點被關注的專案，臨時抽調一些正在做專案的人員，

導致一些專案延誤。

 

3年前，在評估結束後，公司高層便決定購買專案管理工具，滿足以上需求。比較了3家，最終挑選併購買了一套叫EM的專案管理工具。

 

一年前，當這家公司要準備做新一輪的CMMI評估時，顧問得知公司已採購並使用了這EM系統，但很奇怪，為什麼公司買了EM專案管理工具，只用來做採購管理，報銷，但沒有用來管理研發專案。

 

在做差距分析和不同崗位層次交流訪談，發現因為開發人員多年都習慣了使用本來的開源工具

你自己說開發工作不一樣，堅持用本來的方法，管理層也沒有堅持。

 

雖然公司內有人熟悉這新工具的功能，但要改變大部分人多年的習慣不容易，高層也猶豫，不希望逼管開發的主管硬推（也理解研發主管自己也花了不少精力，做了一些對本來開源工具的定製）

 

3「利用CMMI評估催化變更」

 

利用CMMI評估催化變更——獲取管理者的支援

改變習慣是很難的事情，所以需要從上而下來推行。

顧問便安排了熟悉新工具的專案經理，給高層與技術總監演示如何實現上述的各種功能。交流後，大家都同意有用，接下來找試點推行。

 

4「試點」

 

因專案的交付期越來越短，需求也常常變，聽我們去年在杭州成功幫助另一家公司推行敏捷開發試點（不再用傳統的瀑布式），敏捷開發很多公司都已經開始用，我們的特點是不僅僅是敏捷的做法，也配合簡化功能點估算於每個衝刺的生產率與質量的資料統計，使用XLS表記錄與分析。

 

 

我們給了試點專案經理一個敏捷專案度量模板，開始時，專案經理不太瞭解功能點規模估算，也覺得較複雜，我們顧問便給他介紹簡化功能點法，因敏捷每個迭代只有2-4周，雖然簡化版有15-25%的偏差，但還可以接受。

 

客戶專案經理學懂了這量化敏捷開發方法後，決定試點，同時也嘗試利用EM工具來計劃與監控，如果效果理想，會整個公司推行。

 

因為這個專案會使用EM專案管理工具，所以顧問便召集專案經理和技術總監。制定敏捷專案WBS模版。

 

專案計劃與監控都很順利，過了三個月開始要準備CMMI評估了。

 

專案經理以以往準備CMMI評估的經驗，以為對每一個迭代都要為所有過程準備相關的文件，例如需求文件、設計文件、測試計劃文件等等。算起來要準備文件的數量比以前用瀑布式的專案的文件還多幾倍。

 

總監覺得不對，便叫專案經理聯絡顧問。

顧問聽完他問題，說：“您被 ’CMMI ‘ 的毒害太深了，以為CMMI是等同於大批文件。你這個專案使用敏捷，再配系統管理工具，很多瀑布式專案所需要的文件都應該可以省掉。例如： 不需要像以前那種按公司模板編寫需求說明書，里程碑時，再使用XLS表格模版填寫實際工時與進度，形成報告。 “

 

顧問便教他如何在計劃與監控等過程域配一個敏捷XLS模板，加上用工具，滿足CMMI 中專案計劃 PP、專案監控 PMC、整合專案管理IPM、風險管理 RSKM 等要求。

 

CMMI評估促進了專案經理去了解並在實際專案中使用新的專案管理工具，如果沒有評估，管理層未必會考慮專案管理的問題，這種變更/試驗也不一定能發生。

 

5「效果」

 

有了完整的專案模板、測試、研發與實施階段在工具中串聯起來，使每一個問題等都能找到前因後果，對資源的掌控更清晰，不會出現大規模的衝突，也有效的監控了專案預算及成本。

 

因為敏捷迭代開發，每2-4 周都會有客戶產品的展示，都需要有測試，質量明顯比以前瀑布性開發好。 

 

專案管理方面，專案WBS可以按不同活動負責人進行分解，並對活動分配人力資源，同時也會顯示活動狀態，是否為里程碑等。

 

每一次專案審批都會形成一次基線，不同的基線可以進行對比，不同的內容用黃色標註出來：

 

依賴關係設定好後，可以檢視關鍵路徑等。

 

 

當預算與成本有相關數值計算或錄入進去，一旦活動開始有進度進行，可自動計算出EV (Earned Value) 、 PV (Planned Value)等來顯示進度偏差 、成本偏差。 

 

當活動申請人力資源時，可以根據技能進行查詢，找到技能滿足的可用人力資源。

 

在工作統計量報表中，可以看到每個資源的工作量及完成工作量等，也可以根據專案來看。

申請資源時，可以看到此資源已被審批通過的資源人時，同時也會計算出與目前所要申請的資源時相加是否超出總資源時。

 

這用工具的試點專案也滿足了 CMMI 中 專案計劃 PP、專案監控 PMC，、整合專案管理IPM、 風險管理 RSKM 等的實踐，不需要再填寫手工模板。

 

總經理一直都是做市場，以往都是依賴於技術總監彙報專案的實際情況。包括進度、工作量、成本，現在他可以直接在專案管理系統中即時看到實際的專案狀況，他很高興地發現可以識別出每個專案佔用公司的資源的多少。

 

“原來 XX客戶的專案都常常超出本來專案報價的預算，我們下次再報專案時，報價一定不能低。“ 他說——有了可靠資料作為指標，管理層便可以判斷合適的報價。

 

他要求接下來 所有專案都要用這新方法，技術總監和主管們也贊同。

 

6「後記」

 

常常被問 ，怎樣才可以使CMMI可以幫助公司實際提升，並且可以持續？

這案例便是如何集合模型 + 系統 + 人員 （有度量） 的好例子：

- 用度量讓員工瞭解現在的不足，制定具體的目標；

- 用模型+評估促進員工改變習慣，開始改進；

- 用系統把改進後的過程持續下去。

必備條件：領導對現狀不滿，覺得必須要改進試點專案人員有能力，有動力。

 

聯絡我們

電話：18921395967

QQ：1228021190

微信：processis2009

地址：香港/北京/江蘇

官網：www.processis.org

郵箱：[email protected]