昨天,我們協助客戶做出了決策,所以接下來,就可以進入開發了… …嗎?且慢,一個成功的專案,如果這樣就急著派下去進入開發,可以預見,後續等待整個團隊的,會是各種未爆彈及反覆修改之類可怕的問題。因此,我們需要一份將這些決策轉化為具體行動的作戰地圖。
在專案管理的世界,這份地圖最經典的呈現方式就是「甘特圖」(Gantt Chart)。它能讓我們一眼看清「要做什麼」 (What)、「誰來做」(Who) 以及「何時做」(When)。
今天,我們就直接拉出一張導入電子簽章系統的專案,最常見的甘特圖 (簡化版),並且來拆解其中的重點。
專案的生命週期,可以大致分為四個部份,而這些也是我們在拉甘特圖時的主要階段:
在繪製甘特圖前,首先需要將所有工作由上至下,仔細拆分列出,這樣的一份列表,就是工作分解結構 (Work Breakdown Structure, WBS)。
下面這份是精簡版的 WBS 參考範例,實際上會拆分的更細:
編號 | 標題 |
---|---|
1. | 啟動與需求訪談、設計 |
1.1 | 召開專案啟動會議 (Kick-off Meeting) |
1.2 | 進行需求訪談會議 (Requirements Gathering Meeting) |
1.3 | 產出客製項目設計稿 |
1.3.1 | 設計稿交付及簽回確認單 |
2. | 系統建置與開發 |
2.1 | 硬體與網路環境準備 (客戶端) |
2.2 | 系統安裝與設定 |
2.3 | API 整合 |
2.4 | 客製功能開發 |
2.5 | 團隊內部單元測試 |
3. | 測試與調整 |
3.1 | 規劃與撰寫 UAT 測試案例 (Test Cases) |
3.2 | 使用者進行實測 |
3.3 | 問題回報與調整 |
4. | 教育訓練與交付 |
4.1 | 前台操作教育訓練 |
4.2 | 後臺操作教育訓練 |
4.3 | 系統移交教育訓練 |
4.4 | 系統交付驗收 |
這邊就是利用上面的 WBS 拉一張簡易的甘特圖範例
那麼,這一條一條的圖,有什麼用呢?要看時間我看文字不就好了嗎?
對於 PM 來說,拉出任務列表只是基礎,透過甘特圖我們可以看到更多的要點:
甘特圖不只是一張給老闆看的必備文件,它也是 PM 管理專案的基礎、是與團隊和客戶溝通的共同語言,也是管理期望、控制風險的儀表板。
有了清楚的作戰武器,接著 PM 們就準備開始進行大量的溝通工作啦。我們要如何把客戶的需求精準翻譯給工程師?又要怎麼把生硬的技術,翻成客戶能懂的人話?
明天,就讓我們來聊聊 PM 最重要,但也常常被人小看的核心技能之一 — 溝通 (Communication)。