104學習

WBS

AI 專區學習課程

證照測驗共學

WBS

關注

邀請朋友

Line

Facebook

複製連結

取消

「WBS：負責專案的工作分解結構(WBS)設計與管理，確保專案按時、按預算及符合品質要求交付。主要職責包括定義專案範疇、分解工作任務、分配資源及建立進度計劃。需具備優秀的跨部門協作能力及溝通技巧，以有效整合各部門需求及進展。此外，需掌握專案管理工具及方法論，如Gantt Chart、Agile等，以應對快速變化的商業環境及文化需求，特別是在台灣重視團隊溝通與合作的職場文化下，具備問題解決與風險管理能力尤為重要。」

關於教室

關注人數 5 人

104人力銀行從職缺中挑選出常見技能所成立的官方教室，提供大家進行共學互動。

學習主持人

持續分享知識，
有機會成為官方教室主持人

教室標籤

WBS

Hi~ 歡迎分享學習資源，有學習問題可匿名向Giver發問！

我要分享

我要提問

WBS 學習推薦

全部

影片

文章

下班後的產品工程師

關注

Larry

Software Engineer

2023/05/19

《大人學：101 專案管理一日特訓班》——學習心得（下）

上一篇我們講到 WBS （Work Breakdown Structure，工作分解結構）是什麼，這篇要繼續說明，執行上實際要做哪些事情，更細節的「任務」（Task / Activity）怎麼做。

任務則是完成專案產出所必須執行的各項「活動」，也就是說是「行為」或「動詞」，跟 WBS 和工作包不一樣。且是一個工作包對應多個任務。在排程的時候，也是以任務作為基本元素。專案管理會畫的甘特圖，那一條條的橫桿就是任務。在描述任務時，通常以主詞＋動詞＋受詞的方式描述。就跟 User Story 的概念很像，要寫出誰做了什麼事情，只是 User Story 會多描述為了達到什麼目的（或商業價值）。

一頁式的 BIG TABLE 幫助掌握專案的資源、成本、時程

課堂上讓我們練習從一開始的整理工作包與任務、資源與任務分派、任務總成本的計算、工期與繪製時程網圖、資源的時間分佈、成本的時間分佈等等。

到中間穿插著各種實作以及個案練習。包含怎麼計算變動成本；工時不見得會因為人多就能減少，相反可能還會增加；查核點的設立；甘特圖上任務之間的相依性／邏輯關係（Relationship）；時間跟成本在專案運行中的分佈；有沒有人單日工時超過 8 小時……等等。

這些是身為 PM 應該要具備的技巧，就像是一位籃球選手一定要會投籃一樣。如果沒有前面提到的基礎、沒有了解什麼是專案、沒有了解專案的目標和範疇是什麼、沒有了解工作包跟任務的關係，那麼在這種大表式的表單中，是很難掌握隱藏在其中的資訊的。

課堂中花了相當長的篇幅在教導我們要怎麼完成這張 Big Table。上完課之後我才真切了解到甘特圖裡面各種標記，是用來表示任務之間的相依性，不單單只是表示各項任務所花的工時跟起迄日期而已。

要徑／關鍵路徑（Critical Path Method，CPM）的概念則是幫助我們在專案有異動時，能夠迅速評估哪些任務可以迅速調整而不影響交付時間。

更高階的專案檢核

最令我意外的是這堂課還有教我們專案檢核／專案審計（Project Audit）如何看懂專案報告。（期望在不久的將來）擔任 PM 的主管時，如果底下的 PM 呈交了一份專案進度報告，要怎麼從字裡行間看出不合理的任務工時；以及怎麼計算專案的計畫值（Planned Value）、實際成本（Actual Cost）、實獲值（Earned Value）。

同時也教我們在面對底下的 PM 如果「亂來」時，要怎麼樣透過這些進度報告跟數值，展現自己的專業度要求對方改善。

上完課的心得

以前的我覺得甘特圖就是「一張圖」，曾經有主管天天都要我更新甘特圖，我心裡知道要讓團隊成員知道專案現在的進度沒錯，但是就是覺得做起來很冗餘，心想「不過就是一張圖，交了差就完事了」。現在則是透過循序體驗 PM 的工作，才能夠改觀了解：

甘特圖是「工具」，是讓 PM 掌握潛在風險及現在進度狀況的工具。

而專案在初始時，透過 Why to do、What to do，到 Who and when、How much and when 等等七個步驟，逐步將專案的全貌規劃成型。但也承接甘特圖的概念：專案是會變動的，要隨時因應發生的事情調整專案的方向。這也是專案有趣的地方。

Plans are nothing. Planning is everything.

計畫不重要，制定計劃很重要。

很重要所以要講三次。

可以實行的後續行動

上完課之後最能夠付諸行動的，應該就是看待「更改計畫」這件事情了。以往認為專案就像是一套公式，所有人都套進這個式子裡照著式子運作。即便知道專案會有變化在，也讓專案成員調整執行的任務或是需要的時間等，當初制定好的「公式」卻是動也不動（或者改的很隨便），以至於專案進度到後來都只能用問的，而不是從相關的文件或是進度報告中可以知道，導致專案的溝通成本增加、PM 的負擔增加……種種的惡性循環。

現在開始會提醒（或是督促逼迫）自己，每當專案有任何風吹草動時，務必要將改動後的專案狀況呈現在報告中。同時也會開始試著將 Big Table 的觀念應用在開發上。雖然現在不是全職 PM，但也循序開始養成專案管理的習慣。要記得「Plans are nothing. Planning is everything.」

看更多