[專案管理happy書] 要收集什麼資料(上)

獨孤木撰
20/2/2006
原文網址 : http://taiwan.cnet.com/enterprise/technology/0,2000062852,20104219,00.htm

對於不知道要收集那些專案管理資訊的公司來說,他們的狀況是沒有任何指標。一般人希望可以找到技術的指標,透過數字來告訴他,到底該怎麼做決策,不過這些公司就是基於大膽,無知,或是我也不知道是什麼的原因,他們沒有收集任何專案管理資訊的習慣。

那他們怎麼進行專案管理呢?答案是憑著經驗,印象,與記憶。

這樣不是很不精確嗎?是的,所以他會給出很多沒什麼道理的承諾。例如下面這個例子。

喬安娜:吉娜,現在客戶問我到底什麼時候才可以上線,你告訴我,現在到底實際的狀況是怎麼樣?

吉娜:報告老闆,根據我的了解,現在完全測不下去呀。一開始要測就會當,而詳細的原因我們還在仔細檢查當中。

喬安娜:你這樣講也不成,你要告訴我什麼時候才有辦法繼續測下去。還有我們什麼時候才交得出一個可以開始讓user進行測試的版本。

吉娜:在現在這個時點,我也沒有辦法做很精確的答覆。我需要時間進行完整的評估與分析,我想我需要再跟team member好好討論。不過你放心,我們一定會在這個禮拜內給他們一個版本。

喬安娜:好吧。那你們現在到底發現多少bug?

吉娜:目前為止就是一個問題,這個問題卡住測不下去如此而已。不知道為什麼本來都會動的東西突然不會動了。

喬安娜:好吧。那你們要加油喔。回頭mail給我一份status report。

過了一個禮拜。

喬安娜:吉娜,你上次說一個禮拜,現在他們又在催了。到底實際的狀況是怎麼樣?還有多少bug?

吉娜:就是還一個bug,動會動了,不過報表出來數字不對。

喬安娜:那這樣到底狀況是怎麼樣,可以開始測了嗎?

吉娜:再給我一個禮拜吧。報表數字不對,一定會被打死的啦。

喬安娜:那這樣我要算幾個bug?

吉娜:就一個呀。

喬安娜:上次那個不會動的不算喔?

吉娜:那個不是解了嗎?那算總共有兩個好了。

X X X X X X X X X X X X 

專案管理學

對於不太懂專案管理的人來說,這樣的場合並不會有什麼不可思議的地方。有很多負責專案管理工作的主管,並不了解所謂的專案管理,還包含需要收集統計資訊這一塊。Bug的資訊只要憑印象與記憶就好了,老闆問時可以隨口說說搪塞過去就好了。好像每個老闆腦中的記憶體都小到記不得上個禮拜的status report的內容一樣。還好這年頭隨著專案管理學逐漸變成顯學,這種狀況慢慢在改善當中。

拿這個例子來說好了。我們應該要怎麼樣判斷系統品質的好壞呢?這牽涉到了我們的測試工作應該要怎麼樣來進行。

首先,你要有一個獨立的測試團隊。這些人,需要先想一想,要怎麼樣來測試一個已經完成的系統。為了避免他們忘記,他們必需把這些測試的情境給寫下來,我們稱這樣的文件為測試個案(test case)。

接著,等到系統進入測試階段時,測試團隊就要依據原先規劃好的測試個案,在時間與人力所允許的範圍之下,挑選適合的測試個案,開始進行測試。

如果測試發現問題(defect),就應該要把它記錄下來。記錄的時候,如果這個問題很嚴重,會影響很多測試個案的執行時,你就要標明這個問題,是屬於非常嚴重(high severity)的問題。

所以你想要確定你的系統的品質到底可不可以進入下一個階段(phase),讓使用者可以開始進行測試(user acceptance test)時,你就得要先知道,現在的這個系統,原先在規劃test case時,到底規劃了多少個?而到目前到底執行過多少個test case?到目前為止,發現了多少個defect(問題,缺陷)?而這些defect,又有多少是屬於high severity(嚴重程度很高)的defect?

※作者註:severity我們通常用1 ~ 5來表示。Severity 1表示非常嚴重的問題,只要一出現,那整個系統都測不下去。Severity 2則表示有一個子系統被檔住了,沒有解開的話,會有很多測試個案走不下去。Severity 3則表示系統出錯了,與你預期的反應不一樣。Severity 4是指那些跟美醜,操作習慣比較有關的問題。Severity 5則通常表示這是一個沒有在原先的需求中被提到的一項建議修改的項目(enhancement)。Severity 1與2,我們稱為high severity defect。

※作者註:一般來說,如果你要安心的進入UAT,你必需走完具有代表性的test case。除非時間與人力極度不許可,否則最好是走完原先規劃所有應該要測試的test case。當你要進入UAT時,通常是應該要把severity 3以上的問題通通都解掉。

當你要判斷一個系統的品質時,你不知道什麼叫做defect,也不曉得defect的severity(嚴重程度)是什麼意思,更不要提你到底會不會收集defect了,你就很難用很簡單的數字,來表示這個系統的品質到底好不好。到底可不可以進入下一個phase。

這些只是簡單的專案管理ABC,不過蠻多不懂軟體開發的高階主管在進行決策時,並不知道進行客觀的分析。反過來,他們是直接詢問專案經理的勇氣與信心。而通常,只要有獎金與bonus的誘惑,經理人員的信心指數都會以驚人的速度飆高。

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License