[專案管理happy書] 該蒐集哪些資料?(下)

| | | | | | 留下回應

    

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

人類好像一直沒有進化，三國時期，我們是這樣搞的：

曹操：誰敢幫我去恐嚇周瑜，讓他聽到我的神威就嚇到尿褲子投降？可以做到的人封他當萬戶侯。

蔣幹：屬下從小就跟周瑜一起掀小女生裙子一起長大。只要我出馬，周瑜一定會馬上把大喬小喬進貢給丞相。

曹操聞言大喜：當真沒問題？我下半身(or生？)的幸福就靠你了。

蔣幹：絕對沒問題。

結果，周瑜來個群英會戲蔣幹，讓曹操把擅長打水仗的蔡瑁，張允給砍了頭，赤壁之戰就輸到脫褲子。

現在我們是這麼搞的：

喬安娜：你們也拖了這麼久了，有沒有信心可以通過UAT(驗收測試)？如果可以快點進入UAT，然後讓這個系統驗收，我會去爭取加發百分之十的專案獎金。

吉娜眼睛為之一亮：我想經過這幾個round的測試，我想一定沒有問題。

布魯斯大驚，那有幾個round呀，根本就連一個round都測不完，所有的code不過是勉強整合在一起，這樣就要會死人啦：我覺得我們需要再進行更謹慎的評估，目前所有defect還在發散當中…

吉娜眼睛射出熊熊火燄打斷：你對你的團隊有沒有信心？

布魯斯無法直視吉娜眼中射出的信心火燄，只能畏縮地說：這跟信心沒關係。我當然信任我們team member的能力。

吉娜眼神再次射出$光：那就要拿出guts來。只要我們堅持我們的信心，一定可以克服所有的困難。

布魯斯想，又來這一套只要我們團隊合作之後，七個小矮人也可以打敗惡魔黨的荒謬故事了。好恐怖呀，妳的眼睛被$光給射瞎了嗎？來人啊，快把吉娜專用的可魯帶出來。

由於布魯斯無法承受這麼強烈的光線攻擊，整個人陷入流口水發呆狀態，不發一語。此時吉娜便說：報告老闆，我想應該沒問題。

結果…還需要再講下去嗎？沒有根據的信心，並不會改變事情的狀態。整個專案，就在客戶狂電之下退回到整合測試。

這個故事告訴我們，有些時候，總會有人會被義和團冤魂附身，擁有莫名其妙的信心。

如果我們是透過收集資料來進行決策，那當然就可以有一個判斷的準則。這也就是說，當你在收集資料時，你除了要知道要收集那些資料以外，你還要問自己，你為什麼想要收集這些資料？這些資料到底背後有什麼意義？

大體而言，我們在進行專案管理時，最關心的，不外乎成本，品質，參與專案的人數，與時間之間的關聯。所以收集資訊基本上就是以這幾個方向為主。一般來說，我會收集的資料包含了跟下列幾個主題有關：

1.跟專案規模有關的資訊：例如line of code, function point, use case point…

2.跟專案品質有關的資訊：例如defect 與defect 發現的時間，目前defect的狀態…

3.跟成本、人月、工作時間有關的資訊：例如總共投入多少人，多少時間，每個禮拜的工時表(time card)又是什麼，每個mile stone到達的時間點…

收集這些資訊，主要的用意，就是要讓你知道

1.現在專案的狀況是什麼？

2.以後如果遇到類似的狀況，應該就有一個預測的基準了。

基本上，技術分析的基礎就在於相信歷史會不斷重演。如果歷史不重演的話，收集這些指標就沒什麼意義了。

當我們收集 跟專案規模有關的資訊時，其實是為了要知道，下次如果遇到類似的專案，需要進行預估時，我是不是有一個指標，可以告訴我專案到底有多大？以方便我估計整個專案需要投入多少人，多少時間，會花多少錢？既然知道收集專案大小的資訊是為了這些事情，在收集專案的規模資訊時，其實就得要同時收集跟成本、人月、工作時間有關的資訊。

要不然，我光收集這個專案總共寫了20萬行的程式碼，其它相關的資訊卻付之闕如，那光是20萬行的程式碼，它就僅僅是一項資料，就沒有什麼太特別的意思了。

這就跟股票市場收集資訊的基礎差不多，一般而言，你要知道日期，收盤價，以及成交量。光是XX電這檔股票的今日收盤價是50元，沒有任何其它相關的資訊，那是一點用都沒有。

可是如果我做了統計，這20萬行的程式碼，總共花了20個專案成員開發了10個月，那你就會有一個20萬行的程式碼，需要200個人月，這樣一個數字的對應關係出來。這個數字有沒有意義，有沒有用，這很難說。不過它最少是一個可以做進一步判斷的開始。

作者為資深工程師及軟體開發專案經理，經常撰寫軟體專案的文章，作品散見於資訊論壇網站及其個人部落格中，著有《在公牛身上擠奶》一書。