一人公司專案管理範例

7個完成任務的核心步驟

---

前言：透過個人案例來學習專案管理

學習專案管理不是一件容易的事情，市面上有很多的書籍或課程，但一般而言如果理論居多，聽起來就會覺得有點難落地；而如果實務居多，學員又可能會覺得距離有點遠，有些會變成是聽經驗談。

所以在學習專案管理上，我覺得最好的方式，就是「將自己的實踐案例，套用進學習到的框架」，這樣除了可以熟悉專案的框架，也能夠藉由自己的案例去反思，讓自己能更深入理解。

這篇專案管理範例文章，我會利用林佳熹老師《一次搞懂專案管理，從入門到業界實務》課程中教導的內容，搭配我自己過去實際做過的網站改版專案來做學習，讓自己更知道過往在執行專案上「有做到什麼」與「還缺少什麼」，以及「未來執行專案要特別注意什麼細節」。

想追蹤更多「學習」新知，歡迎關注：
1. 線上課程/平台優惠折扣整理 (持續更新)
2. 跟著DEAN學一點 Facebook社團
3. 跟著DEAN學一點 LINE社群
4. 線上學習文章統整頁

專案管理是什麼？

專案是什麼？

在了解專案管理之前，要先了解什麼是「專案 (Project)」，主要有三點定義：

• 有目標產品、服務、結果。
• 有明確的開始和結束時間。
• 每個專案都不一樣。

專案要達成一個目標，無論這個目標是交出產品、服務還是成果，也必須有時限，並且是一次性的。如果是固定且持續的任務，就不會是專案，舉例來說，每個月月底都要交付的工作報表不是專案，但如果是要把以前的紙本報表輸入系統，那就是一個專案。

通常來說，專案經理 (或稱 PM) 在接受一個執行專案的任務時，必須確認的資訊會有下列三種：

• 專案目標：某個需要交付的產品、服務或成果，如開發一個產品查詢的 APP。
• 專案範圍：需要定義清楚，才能管控成本、時程與風險，如產品查詢 APP 只上線英文版本，並且要能在 IOS 和 Android 上使用(系統版本也要明確定義)。
• 專案期限：要先定義一個大概期限，再後續估算與溝通實際交付的日期，如產品查詢 APP 預定在明年第三季度上線。

專案基線(Project Baseline)是什麼？

雖然專案管理在前置作業時需要製作很多文件，可主要只是為了控管稱作「專案基線」的 3 個部分：

• 時程：同時影響專案的範圍與花費成本。
• 成本：同時影響專案的時程和範圍。
• 範圍：同時影響成本與時程的增減。

這三者會相互影響，例如專案完成的時間往後推，會拉高成本，並變更專案的範圍 (風險會提高)；想縮短時程，來變更專案範圍的方式 (如增員或外包) 可縮短時程，但會提高成本。

專案經理(Project Manager)所需能力？

在實務上，專案管理 (Project Manager, PM) 必須具備下列 2 種能力：

• 具備產業的相關知識：比如在軟體業，不一定要懂得寫軟體，但必須知道軟體的開發流程和相應的理論知識。
• 擁有管理的相關技能：分為軟技能和硬技能。
  • 軟技能：溝通協調、規劃成本、辨識風險等。
  • 硬技能：撰寫文件、軟體工具操作等。

延伸閱讀：
1. 新手PM課程推薦 |《產品經理職場學》完整心得與評價
2. 邱明琪專案管理課程心得：3大難題解法與2種溝通技巧
3. 溝通表達課程推薦，3大學習方向解決不同情境難題

專案管理範例：7個核心步驟

為了要讓自己更理解，我把「專案管理」的執行過程串接起來，分成 7 個主要步驟，並且會以我「網站改版專案」作為專案管理範例，將細節套用進課程的專案管理流程中：

STEP 1：明確專案核心目的

在定義專案之前，要先清楚「目的」和「目標」是不一樣的，明確這個專案要達成的「目的」，才會知道「目標」是什麼。

用同個概念來看我的實際案例，我會做網站改版是因為讀者表示「網站內容很多，但有時會找不到想看的文章」，希望可以「優化使用者體驗」，所以「優化使用者體驗」就是本次網站改版的目的，而「網站改版」則是我的目標。

不過，這邊也要補充，如果是大型專案，專案目的是「明年銷售額提升 10%」，那就會衍生多個中型專案來達成這個目的，比如「開發一項新產品」、「建立多元銷售管道」、「降低製造成本」等等。

而中型專案底下，又會有很多個小型專案，比如「市場調查」、「加入電商平台」或「更換製造商」等等，一切都還是需要考量專案的複雜程度來規劃。

STEP 2：設立專案目標、範圍、時程

在確定專案目的後，就可以開始設立目標、範圍、時程，例如：

• 專案目標：網站改版。
• 專案範圍：參考原有的網站頁面，設計新的網站頁面。
• 專案時程：2022 年第二季上線。

一開始建立專案的時候，先在目標、範圍和時程抓個大概就好，後續再藉由「專案章程」、「生命週期」、「分解工作結構」等文件的製作，並和成員、利害關係人溝通，來優化整個專案的執行細節。

STEP 3：組織專案成員和辨識利害關係人

在專案管理中，有兩個重要的角色：

• 專案成員：指的是執行專案的人。
• 利害關係人：對這個專案有極大影響力的人或團體組織；被這個專案影響極大的人或團體組織。

在專案管理上最常見的實務問題是「利害關係人」，所以要提早辨識哪些人或組織是需要特別關注與溝通的。當利害關係人之間有利益衝突，就很容易提高專案失敗的風險，而 PM 的任務就是平衡各「利害關係人」的利益。

以「網站改版」的例子來說，「利害關係人」會有兩種：

1. 從原網站獲得/減少利益的人。
2. 從新網站獲得/減少利益的人。

從以上兩個條件得出「利害關係人」會有我、設計師、讀者和廠商，但因為只是單純個人網站的改版，對廠商和讀者來說影響不大，所以就不另外分析個別的參與程度。

可要是你管理的專案是負責公司網站改版的話，就需要用「利害關係人參與評估矩陣」來分析，並提早做好因應對策，降低專案失敗的風險：

利害關係人	未察覺	抗拒	中立	支持	帶領
XXX			C	D
XXX			C		D

• C：Current Engagement level (利害關係人目前的狀態)
• D：Desired Engagement level (期望利害關係人達到的狀態)

STEP 4：撰寫專案章程

接下來，為了讓所有人能對專案有共識，會開始撰寫專案章程：

---

1. 專案目標：修改現有網站，在視覺設計和使用動線上優化使用者體驗。

2. 交付成果：設計 WordPress 個人品牌網站。

3. 專案範圍：

• 保留原本網站的 LOGO 與文字內容
• 優化網站架構與動線設計。
• 將重點內容擺在顯眼位置。
• 強化並統一視覺設計。
• 配合頁面設計增修文案。

4. 非專案範圍：

• 不需購物頁面和金流系統。

5. 專案方法：

• 確認個人品牌方向。
• 重新設計網站架構與動線。
• 強化並統一視覺設計。

6. 預估期間：2022 Q1 ~ 2022 Q3。

7. 專案成本/預算：$$$

8. 預期效益：

• 強化個人品牌形象。
• 提升網站瀏覽的留存率 20%。

9. 里程碑

里程碑(關鍵任務)	時限
依照品牌理念，溝通網站設計方向	2022 Jan
確認要留下或刪除的頁面	2022 Jan
確認新網站的架構/動線/視覺設計	2022 Feb
視最後的頁面增修文案	2022 Mar
上線測試/修改	2022 Mar
完成	2022 Mar

10. 專案資源

角色	姓名	參與率	責任
網站站長	Dean	100%	專案管理 品牌設計 架構/動線規劃 版面確認 文案撰寫 測試 審查
設計師	Winnie	100%	視覺設計 程式撰寫 測試

11. 限制條件/風險

• 在設計上須保留原 LOGO。
• 無法關站兩天，需要即時測試與修改。

---

原本的「專案章程」不只上面幾項，因為我是一人公司，為避免過度規劃，會刪去一般組織裡必須紀錄的項目，並把這份章程當作備忘錄。你可以視情況對下列項目做增減：

• 專案資訊：如專案代碼、專案名稱、贊助人、專案經理等。
• 專案審查委員：如政府案會邀請各方專家做審查。
• 專案變更審查委員。

另外，課程中講師在這邊特別提醒，「專案章程」主要是由 PM 的主管或專案辦公室 (PMO) 等管理階層或客戶來寫，不是由 PM 來寫，不過因為我是一人公司兼發案方，只能自己寫。

STEP 5：設計專案生命週期

「專案生命週期」指的是專案從開始到結束的整個過程會經歷的不同「階段」，根據不同產業、產品或專案特性，會有不同變化，沒有一定的標準，但基本上一定會有 4 個階段：

• 初始：不一定是開始專案，也可能是還在做可行性研究的前期階段。
• 規劃：在這個階段要組織成員，並做專案管理的計畫，最好完成計畫再進入執行階段。
• 執行：顧名思義就是執行專案的階段，但如果是開發軟體或產品等專案，這個階段也要包含測試。整個專案會在這個階段使用最多的成本及人力資源，所以要確保人力的投入是沒有問題的。
• 結束：包含稽核、結案檢討等，或結束之後再做也可以，那就需要新增階段。

之所以要設計專案的生命週期，是為了讓成員知道什麼階段該做什麼事情，節省溝通成本。

設計「專案生命週期」時，每個階段需要做什麼及製作什麼文件，因人、產業和交付成果而異，也可以一併考量組織標準和公司文化。

以「網站改版」為例，設計專案生命週期：

1. 初始：

• 動作/目的：
  • 確認有改版的必要。
  • 找尋合適的設計師。

• 必要文件：
  • 工作說明書 (SOW)
  • 合約。
  • 專案章程。

2. 規劃：

• 動作/目的：
  • 啟動會議 (Kick-off meeting)。
  • 需求討論。
  • 提出解決方案。

• 必要文件：
  • 專案生命週期表。
  • 網站藍圖。
  • wireframe 定稿。
  • prototype 設計稿。

3. 執行：

• 動作/目的：
  • 網站架構規劃。
  • 網站製作。
  • 視覺設計。
  • 增修文案。
  • 上線測試。

4. 結束：

• 動作/目的：
  • 確認達成需求。
  • 結案。
  • 網站改版經驗分享。

• 必要文件：
  • 勞報單。

補充：工作條款 (Statement Of Work, SOW) 這個文件通常由專案發起人、客戶或贊助者撰寫，把專案的目標、範圍和時程做大概的描述，讓成員知道要做些什麼。

做好「專案生命週期」後，就可以標準化了，若下次還要做類似的專案，能夠直接修改使用。

STEP 6：啟動會議 (Kick-off meeting)

「啟動會議」指的是專案正式成立後，與團隊成員、客戶所召開的第一次會議。一般會介紹組員給大家認識，也會介紹主要專案的重要資訊給所有人。

而在組織裡面，會召開這個會議就代表專案拿到經費和資源。

通常來說，在啟動會議上，最起碼要告知下列幾個部分：

• 專案目的。
• 專案目標、範圍、時程和達成標準。
• 團隊成員的角色與責任劃分。
• 公司內部和外部的利害關係人，例如審核主管、合作單位窗口、供應商負責人等。
• 文件的管理方式與規則。

即便是我和設計師的啟動會議只有兩人，除省去介紹利害關係人外，一樣要提出專案目的、目標、範圍、預算和期望完成的時程，讓對方明白我的需求才能進行後續討論。

STEP 7：分解工作結構並指派負責人與執行者

「分解工作結構」是一個很重要的步驟，原名稱叫做 “Work Breakdown Structure” (簡稱 WBS)，指的是把專案目標拆成一個個工作包以方便執行。

每個工作包都要有下列 2 個要素：

1. 有明確的開始時間和結束時間。
2. 有可量化的標準或可交付的成果。

你可以把「工作包」理解成「為達成專案子目標而要交付的小型成果」，所以每個工作包會有一個以上的「工作清單」。

以我的網站改版為例，其中一個工作包是「網站藍圖製作」，那麼這個工作包就會有下列的工作清單：

• 列出目前所有頁面。
• 刪去不要的頁面。
• 把頁面分等級：重要、中等、不重要。
• 重劃網站藍圖。
• 確認網站架構與頁面層級。

每個專案要分成幾層的 WBS 則不一定，但最上層一定是「專案名稱」，最後一層一定是「工作包」，中間如何拆解，可以參考下列 7 種方式：

• 按產品的物理結構來分解：如電腦主是個別製作的商品，最後才組裝。
• 按產品的項目功能來分解：如軟體開發可能會按照不同的功能來分配工作。
• 按實施過程分解：如專案生命週期。
• 以目的地或區域來分解：可用於旅遊專案、各地銷售專案。
• 用主目標下的子目標分解：可用於運動員訓練專案。
• 按組織的不同部門分解：如公司內部的教育訓練專案。
• 按職能分解：適用於跨部門合作。

在網站改版的例子中，由於涉及到網站設計的專業，是在雙方確定目標和需求後，由對方告知的。而若是在組織中管理專案，則最好是讓每個成員自行分解任務後再溝通確認。

上面是我為網站改版做的簡易 WBS，如果是涉及單位比較多的專案，建議用專業軟體來畫，專業軟體在新增的時候會自動上代碼，變更方便，不像心智圖和 Excel 要一個個手動去改。

這邊推薦 2 個線上 WBS 工具「Visual Paradigm」和「Creately」，不過需要付費。而我使用的是 GitMind 這款線上心智圖軟體，也可以用來製作 WBS。(延伸閱讀：心智圖軟體推薦)

講師最後提供一個小技巧，讓成員都確認被指派的任務之後，若為公司內部專案，負責人要寫上人名而不是單位名稱，以釐清責任，避免自己變成夾心餅乾。

補充：11個常見專案管理文件

課程中有介紹到講師實務上常用的 11 個專案管理文件，以下我也整理出一份表格方便理解：

文件名稱	用途	備註
專案生命週期圖	設計專案週期	-做完一次，後續維護 -專案辦公室來寫
專案活動矩陣	依照專案風險程度，釐清需要繳交哪些文件	-做完一次，後續維護 -專案辦公室來寫
專案章程	釐清專案資訊，尤其是交付成果	-起始階段就要備好 -由贊助人、發起人或專案辦公室來寫
需求分析文件	釐清專案範圍、需求、測試與限制，以便後續使用「需求跟蹤矩陣」文件	較少用到
專案時程計畫	-工時估算，讓成員確認 -確認是否有縮短時程的可能性	-小專案用Excel -大專案用專用軟體
工作分解結構 (WBS)	把目標分解成工作包，確認時程	-要有可交付的小型成果和明確的時程 -不要切成工作清單
需求跟蹤矩陣	-對應「需求分析文件」的需求代碼 -紀錄需求從開始到結束的不同階段	較少用到
三時估計法	-以工作包為單位，估算成本與工時 -由成員自行估工作包的工時再加總	風險小的專案可不用
成本評估表	估算專案每階段的固定成本與變動成本(不同的會計年度可分開計算)	風險小的專案可不用
溝通計畫表	-搭配「利害關係人參與評估矩陣」 -訂下對團隊中不同角色的溝通方法及頻率，若有特殊狀況再做備註	觀察實際狀況，隨時調整
風險管理計畫書	-計算發生機率與衝擊程度帶來的風險值，評估相應的作法 -風險若高，就要增加溝通頻率或往上匯報	風險小的專案可不用

結論：專案管理需要大量的實務練習

以上，是我這次針對《一次搞懂專案管理，從入門到業界實務》這堂課中提到的專案流程所做的練習，而透過實際的專案管理範例練習，我對於專案管理確實有了比較深刻的概念。

也很明確知道，專案管理很多時候還是會根據團隊體制做變化，像是我在一人公司的狀態下，其實很多因為內部溝通要做的細節，都是可以省略的，至少在前面的練習中就省略了許多。

我覺得如果你想要讓自己專案管理能力變好，除了上課外，還是會需要實際去執行許多不同種類的專案，各種規模、風險、複雜度都盡可能去嘗試，就會更深刻知道之間的差異，未來在執行各種專案時，才會變得有更多經驗、更好上手。

專案管理相關文章延伸閱讀：
1. 專案管理課程評價，入門到實務應用1堂課全搞懂 (這篇文章提到的課程)
2. Gipi 專案管理課程心得：打造高效團隊的 4 個重點
3. 雲端工作術課程評價，教你打造高效的工作與生活
4. Notion實戰課程評價，課後心得與專案實作分享

[end]