到底「專案」是啥？

這詞可能每個人都有不同的解讀。 有些公司把行銷活動稱為專案、有些電信公司把購機方案稱為專案、也有保險業的「鍾愛一生平安久久專案」。 是的，這個字已經用得太過浮濫了。 為避免你是想了解電信專案結果來這裡翻了半天，最後罵聲連連的離開，我覺得應該要先好好定義一下到底甚麼是專案。

我們所稱的「專案」，指的是為了【要產生一個獨特的產品或是為達成一目標，在特定時段中將各有專精的人聚在一起所做的活動】。 尺度小的可能只有三兩人，在幾天內達成 (如籌畫一場郊遊烤肉的活動)。 尺度大的可能參與者多達數千數萬人，花費數月甚至數年才達成。(如建築萬里長城)

而專案這東西之所以特別，在於他通常有很高的獨特性以及強烈的限制條件。 比方以開發遊戲為例，不管你開發幾次，每次的條件與情況多少都會不同；可能是遊戲內容不同、平台不同、使用的表現方式不同、故事不同、合作團隊不同、用的方法或工具不同，但都會有時間、成本、範疇、人力資源等的限制。

專案麻煩之處，在於不像做漢堡，或是炸雞排等等的工作。 後者這些事情，你若能建立一套標準流程，訓練新人照著做 - 麵包皮加上兩片牛肉放上三片蔬菜加一片洋蔥蓋好包裝...大概就不會差到哪裡去。 但是專案的世界變化多端，就算我們能把其中大部分的事情流程化，也不表示下次專案能絲毫不變的照著之前SOP套用。 因為除了既有的工作流程以外，串接的工作很可能每次不同，而為了整合所需要關注的如合約、溝通、人力管理、外包管理、變更管理、信息傳遞、甚至專案進行中該進行的監控修正都不一樣。

舉個誇張的例子。 假設我是個到處幫人在路邊辦桌的廚師，我是可以把所有菜的製作流程都寫成SOP。 但是因為每次辦桌時客戶選的菜單會不同、環境不同、對象不同，對我來說每次接單就等於是一個專案。 因為變數太多，所以我每次都必須在「事前」針對不同的狀態做全盤考慮與推演：當地如果沒自來水是不是表示我要先規劃如何取得水源來洗米洗菜? 緯度不同時我可能不能用SOP的標準煮菜時間。 高山的客戶如果要吃魚我怎麼調度? 周邊沒商店買食材的客戶我是不是需要自己把食物從遠端運來(還是可以發包? 只是發包就又得多了管理承包商的工作要規劃)；就算自己有辦法先買食物運過去，是不是還要規劃冷凍方式以確保食材的新鮮度? 那我手邊有幾個助手可用，助手的能力經驗與數量則還會影響我菜的做法與順序。 而這一切一切都可能影響調理方法與過程甚至結果。

也因此，專案的環境下，比單純做營運工作要複雜多，但相對也有趣的多。

因為這些複雜性，我們執行專案的人往往需要花費很多心力在專案的「規劃與問題監控」上。

但這卻往往是很多人深感挫折之處。 明明自己技術能力很強，團隊對這產業的特性也很懂，可是每次怎麼好像都被各式非技術的雜事拖慢。 需求變來變去、人員爭執不休、老闆或客戶總好像有要不完的報告、這麼多事情大家認定的優先性好像都不太一樣、到底該聽誰的? 到底現在超前還是落後?人力到底夠不夠?有沒有超支?會不會超支? 甚至大家權責都常扯不清楚。 有時候，夜闌人靜時，我們在累的要死之餘總會以為是自己命不好，選了個複雜難搞的產業。 但其實別這麼悲觀，試想蓋高鐵、太空飛行、開發Windows Vista、研發一台新戰機，他們的專案也一樣會遭遇各位可能正在遭遇的問題，但人家卻也一步一步走了過來。

事實上，美國從1960's冷戰的武器競爭時期開始體會到專案複雜度日增以及時間成本等限制卻越來越緊的衝突狀況，而開始專注於研究專案規劃及執行反饋上的方法(Methodology)與工具技術，也產生了所謂「專案管理」這項專門的管理課題。 在這五十年間，數千計的專案人員血淚流下的歷史與教訓雖然還不至於能讓我們這些後人完全無憂，但最少也不至於完全無助。 學習「專案管理」雖然不敢保證能讓大家完全無憂，但最少將讓做專案的大家不再完全無助。

而在後續部落格中，我將以最生活化最平易近人的面貌來跟大家一起談談專案管理這東西。

下一篇 : 專案要管的好，你需要成為資料收集達人