[dg0020]專案管理（Project Management）入門相關知識整理

專案管理（Project Management）入門相關知識整理

越來越多人想做專案管理這一行！但專案管理真的是個行業嗎？
學習專案管理

專案管理雖然不像會計學有一套嚴謹的準則，但畢竟也發展了七十年以上，還是有相對較佳的做法（Best Practices）存在！所以像是

• WBS（工作分解結構）Work Breakdown Structure，中文翻譯成「工作分解結構」
• 資源分派（Resource Allocation）、
• 任務排程（Scheduling）、
• 要徑（Critical Path）、
• 進度追蹤（Progress Controls）
  
  這些議題，身為專業PM是一定要熟悉的，否則美其名為專案經理，實質上只是聯繫窗口罷了！

＊我建議真正當了幾年PM，累積三五年實務經驗再去考PMP證照比較好：錦上添花，回報更佳！

• 我們所稱的「專案」，指的是『為了要產生一個獨特的產品或是為達成一目標，在特定時段中將各有專精的人，聚在一起所做的活動。』專案這東西之所以特別，在於他通常有很高的獨特性以及強烈的限制條件。


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

因為這些複雜性，我們執行專案的人往往需要花費很多心力在專案的「規劃與問題監控」上。
• 明明自己技術能力很強，團隊對這產業的特性也很懂，可是每次怎麼好像都被各式非技術的雜事拖慢。 

• 需求變來變去、人員爭執不休、老闆或客戶總好像有要不完的報告、這麼多事情大家認定的優先性好像都不太一樣、到底該聽誰的? 
• 到底現在超前還是落後?人力到底夠不夠?有沒有超支?會不會超支? 甚至大家權責都常扯不清楚。
• 
  
資源的調度需要預先規劃；因此如何「了解現狀」以便妥善規劃、並管理日益複雜的專案資源變成大家戒慎恐懼想克服的困難。

所以主管可能老是得問自己：「目前我們是否有足夠的資深的設計人員?」、「 足夠的程式設計師? 足夠的…..?」
「這些人員到底在做甚麼事情?」、「 這些人已經完成了哪些事?」
「我們這一年需要多少人、下年度如果新起動三個案子，會不會人員不夠?」
「是要預先招募? 預先做內部教育訓練? 還是乾脆延後展開這些新案子?」
「哪樣的抉擇對專案最好?」
「哪樣的抉擇對團隊最好?」
「尤其怎麼才能讓公司的利益達到最佳化?」嚴格來說，這些資訊其實也不是多難以取得，只是過程往往充滿了痛苦。 必須要有人收集資料、有人整理資料、要有人統計數據並做成報表。 這往往意味著是在一堆Word、或EXCEL檔案中整理半天。 可是負責整理的人未必知道專案全貌，以致於常有疏漏或是謬誤；加上整理曠日廢時，最終產出可能總是延遲半個一個月。找個很清楚專案全貌的人來整理又如何呢? 這也未必可行，因為知道專案全貌的人恐怕沒這麼多時間整理數據。 以致於這變成一個可怕又讓人痛苦的日常行政工作。 而整個專案進行中，需要用來輔助決策的資訊，通常還不單僅是資源(人力)狀態，也包含專案全貌的了解、包含：時程狀態、進度、風險、變更影響、承包商狀態、實際產出監控等等的所有控制。

我們先不談資料怎麼收集，但若這些資料能妥當的存在在每個管理者眼前。 大家就可以更容易預先規劃資源調度、調整、招募、及培訓。

產品經理（Product Manager）究竟是一個什麼樣的職位?

• Business（商業分析）——產品經理其實就是一個商務的職位，他專注於產品價值利益最大化。為了達到商業的目標同時又要使投資回報最大化，產品經理需要常常熱衷於如何挖掘他們的產品價值。

• Technology（科技趨勢）——如果產品經理不知道做一個產品的技術，那就意味著產品經理很難將產品做好。

• User Experience（使用者體驗）——產品經理在商業領域就是該產品的代言人，他必須對使用者體驗保持熱衷。不見得你要成為該產品的使用高手，但是你必須要時時去測試產品，和使用者交流並且得到回饋（尤其在產品開發初期）。

產品經理首先要為產品設定一個目標，這就需要你對市場、客戶及他們存在的你正試圖解決的問題，進行反覆的研究。

你必須能夠消化掉巨大容量的資訊——來自客戶的回饋、網站分析所產生的量化資料、研究報告、市場趨勢以及統計資料

——你必須瞭解產品市場和客戶的所有資訊，用創新的思維去整合所有資訊，以説明定義所要研發的產品。

產品經理 與 專案經理 最大的不同

一個專案經理會致力於資源分配，管控問題和風險，需要集中所有必須的力量來完成該項專案。

如果該專案被看成是產品，則會被理解為開發一個產品，如：添加產品新功能、新版本或是新產品延伸。

當一個專案完成時，專案經理將常會換一個新的專案，很有可能是一個新的與原來絲毫不相關的“產品”。

一個新產品開發專案可以由專案經理來負責, 一旦專案結束, 該專案經理必須歸建或是繼續從事下一個專案;

而產品經理在整個新產品流程中, 除了是全程參與之外, 只要是該產品沒有phase-out, 產品經理就得負責到底, 

直白一點說: 產品經理是掌管產品的生與死以及P/L(Profit and Loss)。

專案範疇管理與WBS再探

透過WBS這工具，我們將把專案所有的「交付標的」(Deliverable)以有系統的方式詳列出來。

在案子的初期正確辨識出Deliverable是很重要的一件事

Deliverable讓所有專案相關人員了解，當專案宣稱完成時，你是否有辦法能客觀的定義專案的結果是「完整」的？ 你將提供甚麼給你的客戶、你的業主、你的老闆、或你的委託人？ 最終如何能來驗證專案產出了正確的結果？ 必須要有一份對內對外所有人都認同且接受的「交付標的」清單才能讓我們回答這些問題。

也因此Deliverable能否正確定義將影響專案成敗；而WBS則是「Deliverable」具體拆解的一種展示工具。