專案管理
一句話定義
在執行有開始與結束、為達成特定成果而存在的任務組合時，把目標、任務、角色、時程、預算、風險、利害關係人與採納過程組織成可交付系統的能力；實務姿態是把延遲、犯錯、變數扼殺在它們發生之前，核心目標是 get things done 讓專案成功。
核心要點
1. 大原則：預防勝於治療
「我認為專案管理的大原則就是六個字：預防勝於治療。」 —— 只要有人社群顧問 傑哥（2026-04-30-Indie-Creative-034-專案管理的奧義）
精確定義：「永遠別在對方延遲、犯錯、或出現變數後才提醒，好的專案管理者要讓延遲、犯錯、出現變數 … 這些事情根本沒有出現的機會。」
常見誤區的責任結構重定義：「客戶遲遲不回信」「客戶意見一堆」「窗口 OK 了但老闆翻案」這些抱怨都是事後現象——不是「客戶/主管永遠是對的」、而是「從結果來看，不管問題出在誰身上，專案搞砸都不是我們樂見的」——所以「我們的工作不是『搞懂誰造成專案失敗』，而是『讓專案成功』」。
2. Account 三流分級（能力成熟度標尺）
| 流別 | 行為 | 結果 |
|---|---|---|
| 三流 account | 讓專案出現危機 | 危機被製造出來 |
| 二流 account | 能應變各種危機 | 危機出現後解決 |
| 一流 account | 讓專案根本不出現危機 | 一切自然平順地推進 |
棒球比喻（傑哥）：account 像強力中繼或後援投手——能把專案完美終結 = “get things done”。
同客戶 A vs B account 對比：「同樣一個客戶，在 A 業務手上時就是難搞加龜毛、專案被搞得烏煙瘴氣；但由 B 業務控專案時，你就會覺得為什麼這個專案這麼順暢、客戶突然變天使 — 這其實就是 account 的功力。」
→ 三流分級的 vault 定位：與 創意風格「有資格談風格 = 必須熟悉多種風格」並列，是 vault 中明確的「能力成熟度標尺」論述——重點不是高階比低階「更會做什麼」，而是目標的維度差異（從處理問題 → 預防問題 → 讓問題不發生）。
3. 執行前的四個確認（預防的具體內容）
身為專案管理者，在專案執行前必須確認：
| # | 確認項 | 細節 |
|---|---|---|
| 1 | 多層 feedback 預留時間 | 如果不只一個人需要 feedback（客戶窗口 + 主管 + regional team），每一個階段是否預留足夠時間讓客戶內部討論？ |
| 2 | 修改背後的真正目標 | 客戶提出修改時，先理解背後的理由、或希望達成的目標——一定只有客戶建議的調整方式才能達成那個目標嗎？ |
| 3 | 調整對時程的影響 | 隨時讓客戶與所有參與者認知到：做出某些調整時會如何影響專案執行時程 |
| 4 | 下一步的關鍵時間點 | 每一次溝通都讓客戶清楚下一個關鍵時間點是什麼時候、要完成什麼 |
→ 「這些就是我所謂的『預防勝於治療』— 在任何可能出亂子的階段『之前』，先出手把危險因子扼殺掉。」
4. 執行期的四個小習慣（傑哥版）
- 一開始就抓出完整的專案時程大表：「真的不要對自己太有自信，沒有先抓時程表到時候一定會有任何一個小環節沒有考慮到。」
- 工具堆疊（只要有人社群顧問）：Google Sheet + 「projectsheet planning」 擴充功能。免費版也好用，付費版多了「時程連動調整」（一個任務時程移動，後續任務自動順延）。
- 時程連動的常見遺漏：「提供影片 a copy 需要幾天？→ 客戶提供 a copy 的 feedback 需要幾天？→ 拿到 feedback 後修改 a copy 需要幾天？很多人都會忘記先跟客戶確認『feedback 需要幾天』，最後發現客戶內部溝通流程超級長。」
- 每次溝通信件最後都放上 Next Step + 最新版專案時程表的連結：讓客戶隨時清楚接下來要做什麼。
- 雙邊都不只一人在 mail loop：避免單點故障——「如果只有你自己一個人在溝通群組中，只要你有任何原因無法回訊息，就會沒有人可以協助你，因為大家在整個溝通過程中都沒有參與到。」
5. 核心目標：get things done，不是「按指示做事」
「專案管理的核心目標是 — get things done 讓專案成功，而不是『完全按照客戶或主管的指示做事』。如果照著客戶說的做、但最後專案失敗了，我們也不會因為『啊反正是照客戶說的』而覺得專案失敗也沒關係。」
專業 account 的責任結構：
- 理解對方的需求與目標
- 給出自己建議的解決方案
- 想辦法讓專案成功
→ 這是 立場與利益 的精確專案管理場景應用：客戶的「修改建議」是立場，客戶的「想達成的目標」是利益；專業 account 必須穿透到利益層才能評估是否該照單全收。
6. Account 與 Creative 的關係重定義
「我不認為 account 是『支援』creative，account 就是『實現』creative 的關鍵。」
論述閉環：
- 開場：「沒有被精準執行出來的創意只是美好的想像」
- 結尾：「account 就是『實現』creative 的關鍵」
→ 好的業務是創意可見的條件，而業務的核心能力就是專案管理。這條把 只要有人社群顧問 的「社群討論與擴散思維」（007 / 008 / 018 / 026）擴張到整個交付鏈：好的擴散需要好的執行、好的執行需要好的專案管理。
7. 執行工法的「預防 / 應變」兩側結構
| 側別 | 工法 | 對應流別 |
|---|---|---|
| 預防側 | 執行前四個確認 + 一開始抓時程大表 | 一流 account 的核心 |
| 應變側 | 信件 Next Step + 時程表連結 / 雙邊都不只一人在 mail loop | 二流 account 的合格基本盤 |
→ 預防 vs 應變的優先順序：傑哥明確把預防擺在應變之上——「讓問題根本不發生」的一流 account vs 「問題發生後能解」的二流 account；二流是合格的基本盤，一流才是應該追求的目標。
預期與拒絕：不要讓小請求變成隱形 scope
2026-08-12-陳一枝-如何管理預期 把 預期管理 放進職場日常：答應同事或主管一個小請求，常常不只是多做一次小事，而是讓對方形成「這類事以後都可以找你」的預期。
在專案管理語境裡，這就是個人尺度的 scope creep：
- 小請求沒有被寫進時程、owner 或驗收條件，卻真實消耗時間。
- 多個人的小請求會疊成無名工作量，最後壓縮正式專案交付。
- 如果不早點拒絕或重新排優先序，對方會把你的額外付出視為常態。
所以「拒絕」不是不合作，而是把期待拉回可承諾範圍：這件事是否屬於我、是否要重排既有任務、是否需要明確 owner 和交付條件。這與本頁的「預防勝於治療」同精神：不要等超載、延遲或怨氣發生後才處理。
出錯後危機處理：先穩住，再溝通，再復盤
2026-08-11-陳一枝-工作中捅了大簍子怎麼辦 補上本頁原本「危機處理框架」缺口：即使再強調預防，實務中仍會出錯；出錯後的專案管理重點不是立刻找人背鍋，而是把局面從失控狀態拉回可處理狀態。
影片借飛行原則 aviate, navigate, communicate 整理出一條順序：
- 先穩住心態與環境：不要引起不必要恐慌、不要造成二次傷害、不要忽略更大風險、不要承擔不必要責任。
- 確認真的出錯：先排除虛驚，避免焦慮把普通偏差放大成危機。
- 評估穩定性 / 時效性 / 緊迫性：若問題會越拖越糟，先止血與穩定環境；不要在火還在燒時研究完整成因。
- 由內到外溝通：依序面對負責人、知情人與受害人，用簡潔、誠懇、有建設性的方式說明事實、影響與下一步。
- 止損 → 修復 → 補償：先阻止錯誤擴大，再修復工作結果，最後才談補償與信任恢復。
- 復盤系統因素：檢查資訊交接是否標準化、責任 owner 是否唯一、訓練是否包含自我檢查 / QA、環境是否降低低級錯誤機率。
這使「預防勝於治療」多了一個閉環：事前預防若失效，事後復盤要把事故經驗轉回流程、責任、訓練與環境設計，而不是只留下情緒性自責。
演講承辦：事件型專案的預防勝於治療
2026-05-06-辦好一場演講也是素養 把 演講承辦 當成一個細節密集的事件型專案：講者邀約、費用條件、公文、交通、設備、聽眾暖場、時間動線、現場秩序與事後照片回饋，都會影響專案成敗。
這是「預防勝於治療」在活動場景的具體版：
- 講者沒收到行前通知，就可能以為活動取消。
- 接送點不清楚，講者還沒開講就已經耗盡能量。
- 麥克風、轉接頭、影片與網路沒測，聽眾時間會被排錯消耗。
- 中途進出與錯開離場沒設計，會破壞演講的起承轉合。
- 事後照片與回饋沒有回傳，主辦方失去把單次活動轉成長期關係與口碑的機會。
好的承辦不是當天很會補救，而是讓講者和聽眾都感覺「一切自然順暢」。
8. Google PM 入門：生命週期骨架
2026-05-09-Google-Project-Management-Foundations筆記 補入 Google 課程的標準入門視角：專案是一系列為達成預期結果而完成的任務，具有暫時性；專案經理則是在開始到結束之間擔任團隊嚮導，靠組織與人際能力讓任務、資源與溝通接起來。
| 階段 | 核心任務 | 風險焦點 |
|---|---|---|
| 發起 | 定義目標、可交付成果、預算 / 資源、利害關係人與成本效益 | 目標不清、決策者未批准、資源假設錯誤 |
| 計畫 | 建立細部計畫、任務拆解、角色職責、時程、預算與變更應對方針 | 任務顆粒不清、責任不明、變更沒有預案 |
| 執行 | 監控進度、移除障礙、調整時程 / 預算 / 資源、維持團隊動力 | 障礙沒升級、預算失控、團隊不理解交付期待 |
| 關閉 | 確認任務與可交付成果、取得驗收、提交文件、歸還資源、記錄 lessons learned | 成果交付但沒被接受、文件散落、經驗沒有回收 |
這組生命週期讓本頁既有「預防勝於治療」有更清楚的位置：預防不是只在執行期提醒，而是從發起期就把目標、資源、利害關係人與驗收條件先對齊。
9. 方法論光譜：線性、迭代與流程改善
Google 課程把專案方法分成幾種典型節奏：
| 方法 | 適用情境 | 對本頁的意義 |
|---|---|---|
| 線性 / Waterfall | 階段順序明確、需求與資源不太會變、前一階段必須完成才能進下一階段 | 預防重點在前期 scope、時程與資源確認 |
| 迭代 / Agile | 需求、任務或環境會變，需要在過程中測試、回饋與調整 | 預防不是把變化消滅，而是用小批次交付提前暴露不確定性 |
| Scrum / Kanban | 需要用短 Sprint、跨職能團隊或看板視覺化工作狀態 | 與 敏捷增量 / 完成的定義 對位：短週期要以可用成果與明確完成條件驗收 |
| Lean Six Sigma / DMAIC | 流程品質、成本、浪費與變異是主問題 | 專案管理也可以是流程改善，不只是一次性產出交付 |
→ 方法論選擇不是信仰題，而是風險形狀題：穩定環境重前期規劃，高不確定環境重迭代回饋，流程問題重浪費與變異控制。
10. 組織結構、文化與變革採納
Google 課程也補上專案管理的組織環境：經典組織 vs 矩陣組織會影響專案經理的權力與資源可得性；組織文化則會影響衝突、支持度與變更邊界。
交付不等於採納：課程把變革管理定義為「交付完成的項目並讓組織中的其他人採用它」的過程。這提醒專案管理不能停在 deliverable 完成，還要處理：
- 團隊是否有正確技能組合與角色搭配。
- 成員是否感覺到專案所有權與急迫性。
- 溝通是否讓團隊成員有參與感，而不是只被通知結果。
- 新流程 / 新成果是否被組織文化接住，而不是交付後被舊習慣吞回去。
→ 這使 專案管理 與 管理 / 執行力 的邊界更清楚：專案管理是單一專案的交付系統，但交付是否被採納，取決於組織管理系統與文化。
與其他概念的關係
- 與 立場與利益 同源（不同場景）：客戶的「修改建議」是立場，「想達成的目標」是利益——好的專案管理者透過理解利益，才能評估是否需要照表面建議行事
- 與 原則性談判法 第三原則「找出對彼此有利的方案」同精神：先擴大選項、再收斂，而不是把客戶意見當聖旨；專案管理的「修改背後真正目標」確認 = 把談判從立場層拉到利益層
- 與 檢核提案的-10-個問題 對位：007 提案 10 問是專案前置（提案、立案）的對照清單；本頁是專案執行期的預防準則——同團隊（只要有人社群顧問）的「事前 check 文化」延伸（007 是甲方提案前的 check / 034 是專案啟動前的 check）
- 與 執行力 對照：執行力是組織層級把策略變成成果的能力（願景 → 流程 → 步驟）；專案管理是單一專案層級的具體 to-do（時程、溝通、變數預防）；前者是宏觀體質，後者是微觀手法
- 與 管理 區別：管理 討論組織層級的長期經營（流程、規章、透明度、可重複性）；本頁討論單一專案執行（時程、溝通、變數預防）——兩者都不是個人時間管理（個人任務管理另見 Delay-Box）
- 與 預期管理 連結：專案裡的 scope、時程、角色和驗收條件都是預期管理；沒有被明示的期待會在執行中變成變更、抱怨或隱形工作量。
- 與 情緒調節 連結：危機剛發生時，專案處理者若被焦慮、羞恥或自責帶著跑，容易製造二次傷害；先讓情緒降到可行動狀態，才有空間確認事實、穩定環境與溝通。
- 與 RACI框架 連結：事故復盤要檢查每個部分是否有單一明確 owner；「一群人都負責」常等於沒有真正當責者。
- 與 Slow-burn專案 對照：本頁討論有客戶 / 有時程 / 多方參與者的甲方專案管理；slow-burn 是個人 PKM 內部的孕育型專案管理——兩者都涉及「專案」但場景與工法都不同
- 與 時間箱 對照：時間箱 是個人版本的「先抓時程大表」（為自己的子任務設定時間預算）；本頁討論多人 / 客戶版本——兩者共享「先約束時間預算才能對抗 帕金森定律」的精神，但操作面（個人行事曆 vs Google Sheet + projectsheet planning）與利害關係人（一人 vs 多方 feedback loop）規模不同。個人時間箱練熟後，再升級到團隊時程大表會更自然。
- 與 KOL合作 互補：KOL 合作的「中介溝通」「合約管理」「滿足粉絲」三軸（016 視角）本質是專案管理在 KOL 場景的特化——預防勝於治療同樣適用（事前確認 KOL 經紀人決策層級 / 事前確認合約所有 deliverable / 事前確認滿足粉絲機制）
- 與 演講承辦 互補：演講承辦是專案管理在講座 / 校園活動場景的特化；交通、設備、聽眾動線與事後回饋都是可預防的風險點。
- 與 拆分需求 同源不同階段：兩者都是「預防勝於治療」在不同階段的具體實踐——拆分需求 = Discovery 階段預防（事前釐清需求顆粒，避免進開發後爆炸）/ 本頁 = Delivery 階段預防（事前確認時程 / feedback 預留 / 利害關係人，避免執行中失控）；同源精神：把延遲、犯錯、變數扼殺在發生之前。完整工作流：拆分需求（Discovery）→ PRD（規格化）→ 專案管理（Delivery）
- 與 創意風格「有資格談風格 = 必須熟悉多種風格」並列為 vault 中明確的「能力成熟度標尺」論述（三流分級的 vault 定位）
- 與 話語權 / 接案提案 連結：接案提案的「主動引導迷茫業主」與本頁「修改背後真正目標」確認都是專業 account / freelancer 拿回對話主導權的具體動作
- 與 完成的定義 互補：本頁是執行過程的危機預防（事前確認時程 / feedback / next step）；完成的定義 是執行結束的判定共識（用戶問題解了 / 解法交付了 / 回饋收齊了）。前者守過程、後者守出口；沒有完成定義，預防做得再好也會卡在「永遠 80%」
- 與 優先順序矩陣 對位：本頁是單一專案內的危機預防工法；優先順序矩陣 是多專案組合的選擇工法。當組織同時推太多「都很重要」的專案時，個別專案的預防做得再好也救不回——需要先用矩陣裁剪到第一象限的少數項目，再進專案管理層執行。對位「開火車」原則：先決定唯一聚焦項目，再用 prevention 工法推完它
- 與 敏捷行銷：本頁強調把延遲、犯錯、變數預防在發生前；敏捷行銷則在市場高度不確定時，用小型跨部門團隊、MVP 與快速實驗把不確定性提前暴露。兩者都是降低交付風險，只是前者偏交付控制，後者偏快速學習。
- 與 利害關係人管理：Google 課程把 stakeholder analysis 放在發起期；本頁處理專案目標、資源與交付節奏，利害關係人管理 則深入處理誰會影響 / 受影響、如何收編、如何維持信任與處理衝突。
- 與 敏捷增量 / 完成的定義：Scrum / Agile 如果沒有可運行、可測試、可釋出的增量與清楚 DoD，就只剩儀式；Google 課程給方法光譜，本 vault 既有頁補上交付成熟度檢查。
- 與 管理 / 執行力：組織結構與文化決定專案經理權力、資源可得性與採納難度；專案管理是單一專案層，管理 / 執行力是讓多個專案能被看見、排序、支援與持續採納的組織層。
相關來源
- 2026-08-12-陳一枝-如何管理預期 — 補入職場預期管理與拒絕小請求：一次順手幫忙可能形成未來渠道，累積成沒有 owner、時程與驗收條件的隱形 scope。
- 2026-08-11-陳一枝-工作中捅了大簍子怎麼辦 — 補入工作錯誤後的危機處理流程：先穩住環境、確認錯誤、評估緊迫性、分層溝通、止損 / 修復 / 補償，再回到流程、責任、訓練與環境復盤。
- 2026-05-09-Google-Project-Management-Foundations筆記 — Google 專案管理入門課筆記；補入專案定義、專案經理職責、四段生命週期、線性 / 迭代 / Waterfall / Agile / Scrum / Kanban / Lean Six Sigma 方法光譜，以及組織結構 / 文化 / 變革採納視角。
- 2026-05-06-辦好一場演講也是素養 — 補入 演講承辦 作為事件型專案管理：邀約、條件、行前通知、交通接待、設備、時間動線與照片回饋的預防清單
- 2026-04-30-Indie-Creative-034-專案管理的奧義 — 傑哥 / 只要有人社群顧問：vault 中第一個以「專案管理 / Account 工法元層」為主軸的期數；提出預防勝於治療大原則 + Account 三流分級 + 執行前四個確認 + 執行期四個小習慣 + get things done 核心目標 + Account 是『實現』creative 的關鍵 公司哲學
- 2026-05-06-行銷5.0數據推動行銷ML看書 — 補入 敏捷行銷：即時分析、跨部門小隊、MVP、快速實驗與敏捷行銷工作表。
備註
此頁建立於 vault 第 17 期 Indie Creative ingest（034）。本期以單篇從業者經驗分享形式提出方法論——傑哥從個人專案執行抽身後（轉到創意 + 公司治理），以「過來人」視角整理出 account 應該培養的核心能力。
未來累積方向：
- (a) 跨團隊協作的 PM 工法（PMP / Scrum / 敏捷專案管理 / 看板法）——2026-05-09 Google PM 課程已補入入門方法光譜，但 Scrum / Kanban / Lean Six Sigma 仍需一手或深度來源校準角色、artifact、限制與操作步驟
- (b) 危機處理框架深化（2026-08-11-陳一枝-工作中捅了大簍子怎麼辦 已補入工作出錯後的初步流程；後續仍需 incident postmortem / crisis communication / SRE 事故復盤等正式來源校準）
- (c) 客戶教育（如何讓客戶配合專案管理流程；本期傑哥默認客戶會配合，未討論教育流程）
- (d) 工具層深入（Asana / ClickUp / Monday / Notion / Linear 等專案管理 SaaS 比較）
- (e) Account vs PM 角色差異（廣告業 account 兼 PM；科技業有獨立 PM；本期未涉及）
- (f) 危險訊號識別（哪些客戶溝通模式是「即將出事」的早期警報）
- (g) 跨文化溝通（regional team / 跨時區 / 跨語言團隊的時程預留）
與 只要有人社群顧問 內部工具的關係：007 期的 檢核提案的-10-個問題（家瑜制定）+ 034 期的「Google Sheet + projectsheet planning」+ 內部「新客戶簽約流程、遠端開會指南」（007 提及）構成只要有人團隊事前 check 文化的工具集；如未來其他期數揭露更多內部工具或 SOP，可在 只要有人社群顧問 頁累積為「內部工具線」。
三流分級的 vault 定位：「三流出危機 / 二流應變 / 一流預防」是 vault 中第一個明確的 account 能力分級論述——對位 創意風格「有資格談風格 = 必須熟悉多種風格」這類「成熟度標尺」性論述。如未來其他 Indie Creative 期數提出類似的能力分級（例：creative 三流分級、社群操盤手三流分級），可在本頁累積為 vault 中的「能力分級論述集」。