今天在北京為一家軟體開發公司做培訓、診斷。
當談到度量與分析，他們部門經理就要求專案經理開啟他們使用的免費專案管理工具，希望讓我看看他們如何度量與監控專案。專案經理開啟專案展示了一些任務的記錄和圖表：如，敏捷的燃燒圖和任務實際完成多少%。
我問：從度量與分析的角度，你們度量的主要目的是什麼？
他想了一下，然後說：當然是把專案管好。
我說：管好專案是否代表盡量控制專案進度與工作量偏差？
他說：是的。
我問：從剛才這些圖與表，怎麼可以知道實際與計畫的對比？
部門經理就讓專案經理找，找了好一會，他們自己發現工具記錄的都只有實際，沒有與計畫的偏差。雖然也有活動計畫工作量，但由於專案經理會不斷按實際調整，我們看到已完成的活動都沒有超出計畫工時。
開始時，部門經理滿臉笑容，覺得用工具獲得這麼多各樣的圖表已經很不錯，現在發現原來有基本的不足，已經不再說話，只是一直望著他的專案經理。
我立馬打圓場說：請不要太介意，很多像你們的公司也有類似的問題，這種工具是無法有效地度量實際與計畫的對比，因為你的計畫天天按實際來變動，也不知道第一版本，第二版本是多少，所以永遠是度量不出真正的偏差。
這工具也沒有里程碑的概念：里程碑是當你一開始做專案計畫時，預計哪些必須達標或按時完成的日期，定期監控，就可以避免專案不會到最後才知道超時。
如果沒有明確截止時限，每個人很自然都會盡量拖到最晚，（帕金森定理,詳見我11月份的 「為什麼要wbs管理v1.0"）最終導致工作不斷延遲，但管理層不知道。如果沒有乙個固定里程牌的計畫，按照這個計畫去監控的話，大家都延誤，整個研發的的生產力便難以提公升。
除了實際監控的問題以外，我也發現他們的任務有些還是非常大，比如超過200工時。
我問他們為什麼不再細分？
他們專案經理也知道wbs最底下的工作包應該不超過4-5人天才可以有效管理。只是由於專案經理分派工作後，有些活動沒管到那麼細，只是把大的包分出來，然後下面的人員再依據這些填實際。大家可以想象這種的話，肯定很難控制好時間，很容易延誤。所以工具也需要能讓下面的小組主管把大的任務再細分。
我再問他們如何填寫每週的工時表，他說這工具沒有工時表功能，只是在工具上面直接填所花的工時。我再問比如隨便乙個開發人員，他在某一段時間之內總共要負責多少個任務，我們隨便抽某員工的某一周出來，我們發現某小李在短短一周之內，有二三十個活動要處理。
專案經理解釋說：有些可能是維護專案，實際上應沒有這麼多，但確實經常乙個開發同時要兼顧幾個開發專案。
我解讀:如果開發人員每天都有這麼一大堆做不完的任務要處理，你覺得他會有動力自己把最重要的開發任務用心地做好？
想想都知道很難，並且最後會導致——雖然任務很多，最終每個活動、專案都服務不好。
我再問他們：如何分派人員到專案中？當專案要占用某個開發的時候，怎麼知道這人是否已經被其他專案占用？
他們說：這個工具沒有這個功能，所以很可能導致一人身兼很多任務的情況。
依據下圖的《度量與分析》，假如剛才的目標是控制好進度與偏差的話，現在工具是無法做到有效監控。理論上你可以人手定期去記錄收集、計算，但又太費勁，也很難確保不會有人為因素的干擾，導致最後資料失去意義。
再依據度量與分析來收集一些度量項時，需要自問：我們要控制好進度與偏差？會有哪些影響？
其中一位專案經理很快就回應：影響的因素可能有不同客戶型別、需求變化多少、人的能力等。
我說：好啊，那有沒有收集過不同專案這些引數？然後定期從專案的實際資料來驗證不同型別的客戶確實有差異？需求變更的多少是否影響進度偏差？如果沒有資料驗證你的想法，一切都只是猜想。所以我們度量與分析，使用了乙個gqm (goal, question, metric）的方法——依據目標，比如進度偏差，加上自問的問題，來收集你所需要的度量項。所以你收集的度量項不應該僅僅是一些結果，也應該是一些可以控制或有影響的因素，比如需求變更、人的能力等。就好比你要**，不能只度量體重一樣。有了這些，其實你在開始做度量之前，你應該已經有概念，當我收集到那些度量以後，我會怎麼分析？從分析得到什麼結論？就好比做乙個問卷調查，在郵寄第一封信或打第乙個**之前，其實你心裡已經預計到會如何對收集到的資訊做分析，得出結論一樣。
也常被問到選擇工具有什麼要注意，下面是我常用的檢查單：
實際與計畫對比：如何收集任務的實際完成情況？是否可以與專案成員填寫的工時表關聯？
系統中，任務之間如何做分層？專案wbs不可能一開始就全部建好，是否可以先有乙個總括(上層)，然後逐步細分？
專案經理把每個活動分配給負責人。由負責人進行一步細分。
因每個wbs都應該有乙個明確的產出物 (如** ， 文件 )。產出物如何與wbs 對應活動關聯？如何確保產出物確實已完成?
專案很多時候都會有需求變更，系統如何支援不同版本的wbs或專案計畫？避免出現偏差只是和最後版本比較?
( 但實際 可能已經變了多次) 如何與不同版本對比？
系統可否打基線？可監控實際與不同基線的對比
安排人員到專案時，可否檢視人員被其他專案的占用？例如: 如何避免同乙個人需服務好幾個專案（人員過度分配)，或者成員臨時被其他專案調走？
關鍵路徑是專案中最長（也是最短）路徑，如關鍵路徑上的活動延誤，整個專案必然延誤。
當專案有非常多活動，專案經理應主要關注關鍵路徑上的活動。
如需要管專案的實際成本，專案管理系統可否把人力成本管理起來，而不是要靠手工計算出來?
用來監控進度與成本偏差（計畫與實際對比）
(以上每一項都能對上 cmmi-dev 實踐，表示這些也是卓越軟體公司的做法。)
注：工具會有重疊，比如基線管理，就包括了時間管理，wbs分解，也需要資源分配計畫的支撐等；變更可以包括時間，資源等。
後來我跟一位總監也討論過這個問題，結論是：他們大多數還沒有真正管理研發的成本和效率。
這一兩年，市場的競爭越來越激烈，客戶都嚴格控制預算，使得成本的控制越來越重要，很多他認識的同行都開始考慮要從以前研發做出乙個成本分享中心，幫助部門、專案管好成本和進度，成為考核指標。
所以當管理層迫切地覺得有這種需要時，才會意識到現在工具的不足。因任何改變都不容易，人的習慣（包括管理層本身）是最難改變。
除了高層需要有改變的決心，要成功除了有合適的工具，也需要給專案經理和團隊充分培訓。
這些事令我想起一位專案管理的老前輩說過：
「如果公司沒有這個決心要把wbs管好，配合相關的培訓，單是購買具有wbs功能的工具也沒用，不如就讓他們繼續用現有的工具就算了。若要真正做好wbs管理必須工具配合足夠的專案管理培訓才會有效果。很多開發人員都不希望被管得這麼嚴，因覺得開發工作已經很累了。」
我非常贊同，歸根到底，必須高層有專案管理的意識與決心，工具才會真正被使用起來。
官網：www.processis.org
IT專案管理工具
一 完善的專案管理工具，需要具有如下的管理模組 1.需求管理 專案的需求變更，跟蹤，控制 2.資源管理 專案的可利用的資源 人力，物力，財力 3.計畫管理 包括成員管理和許可權分配，日程排定，工作時間管理，里程碑設定 4.進度管理 日曆，工作流，專案路線圖和gantt圖 5.測試管理 專案軟體缺陷b...
常見Sqlite管理工具
sqlite是一款輕巧的開源且跨平台的採用標準sql語法格式的資料庫，其得到了廣泛的應用，比如在google android手機作業系統中就得到了很好的應用。visual sqlite 開發商 www.visualsqlite.com 介紹 visual sqlite是乙個簡單的和完整的sqlite...
redmine 專案管理工具
本文出處 曾經有這樣一位專案成員。在專案主管的眼中，她既不是乙個得力的開發人員，或測試人員，也不是有任何其他特長的人。但在她就職的這家公司的12年間，凡是她從事過的專案都取得了巨大的成功。她為專案做了什麼是不明顯的，但是有她在專案總是成功的。多年後，在一次專案組成員聚會上，通過與其他成員交談，專案主...