林佳熹 | 專案筆記 | AI 自動化

為什麼你做事這麼累？因為你一直在玩「必輸的賽局」 很多 PM 跟我抱怨：工程師推不動、業務亂答應、老闆天天改方向。他們問我： 「是不是溝通技巧出了問題？」 我說：不，這不是溝通問題，是你根本 看不懂現在是什麼局 。 1. 別想著感動人，要學會「誘因設計」 工程師不配合，通常不是因為他懶，而是因為在公司的制度下，配合你「沒有好處」，不配合你「沒有損失」。 這就是賽局裡的「激勵相容」： 傳統思維PM： 拜託工程師幫幫忙（消耗你的人情債）。 賽局思維PM： 把專案成功與他的考績、或是他想學的技術掛鉤。讓「為了他自己好」的行為，剛好等於「專案成功」。 2. 為什麼「恐嚇」有時比「獎勵」有用？ 行為經濟學有個詞叫 「損失規避」 。人們對於「失去 100 塊」的痛苦，遠大於「撿到 100 塊」的快樂。 實戰話術對比： ❌ 「如果大家提早做完，我請大家喝飲料。」（效果微弱） ✅ 「如果這週進度再掉，下個月的資源會被 A 單位收走，到時大家會更累。」（效果強大） 3. 別把「信用」在一次賽局中用光 PM 每天都在喊「這真的很急」。但在重複賽局中，如果你每次都喊急，最後卻沒準時上線，你的 「訊號」就會失真 。 專業 PM 應該像「發牌員」： 資源與寬限期不要一次全給。學會分階段釋放利益，讓對方知道你的支持是有條件、有價值的。這就是賽局中的 「一報還一報」策略 。 PM 指南：該做與不該做的事 不要做的事： 記著，賽局思維PM不會去跟開發者或業務吵架，那是降維打擊。 需要做的事： 你要做的是直接去「修補」那個壞掉的組織結構，或者證明這個結構會讓專案賠錢。 解決方法一定是有的，但解法往往不在溝通，而在 權力與資源的配置 。 賽局思維 PM 真正最強大的武器，是發牌權 如果你覺得自己每天都在「求」別人配合，那表示你已經把底牌一次出光了。 在賽局中，一個成功的 PM 必須學會 分階段釋放利益 ： 掌握寬限期： 對於誠信不良或適合X理論的人，不要把真正的期限告訴合作方。你的資源與時間就是你的籌碼，學會根據對方的誠信紀錄來決定釋放多少。[注1] 修補誘因 Bug： 與其抱怨工程師不配合，不如去跟老闆談談如何調整獎勵指標。當目標一致（...

【職場賽局】為什麼你的助理敢不聽話？ 拆解外商最荒謬的越級匯報陷阱 想像一個場景： 你是外商台灣分部的專案經理，手下帶了一個助理。某天專案急需趕工，你請助理配合加班完成報告。 沒想到，助理喝著咖啡，淡淡地回了一句： 「喔，那個不急啦，我昨天跟國外的老闆通過電話，他說這件事下禮拜再弄就好。」 你當場愣住。明明你才是他在地的老闆，但他竟然跳過你，直接拿「國外老闆的指示」來壓你。 更糟的是，國外老闆竟然還真的直接給他下指令，完全沒跟你商量。 如果你覺得這只是「助理不懂事」或「老闆愛越權」，那你就太天真了。 在 賽局理論 (Game Theory) 的眼裡，這是一個被精密設計過的 「權力殺豬盤」 。 這不是管理問題，是「三方博弈」 為什麼一個優秀的經理人，會被一個 Junior 助理卡死？我們得從這場賽局的三位玩家看起： 國外老闆：因為「不安全感」而玩分而治之 他遠在總部，看不見台灣辦公室的運作。為了不被在地經理「架空」，他故意讓助理直接報給他（Direct Report）。助理成了他的眼線，當經理與助理不合時，老闆反而覺得自己最有權威。 Junior 助理：拿著「雞毛」當「令箭」的套利者 他發現「考績權」在遠方，只要討好那個看不見他表現的人就好。在地經理對他來說，只是個「沒有生殺大權」的技術指導員。 在地經理：承擔責任卻沒有武裝的祭品 你要扛 KPI，卻連助理的請假和績效都管不到。這在賽局中叫 「權責不對等」 ，你的任何要求對助理來說，都是 「不可信的威脅」 。 賽局術語拆解：為什麼你會 GG？ 這場混亂的架構，其實可以用三個賽局核心概念解釋： 代理人問題 (Agency Problem)： 國外老闆為了自己的掌控感（個人私利），犧牲了專案效率（公司公利）。 資訊不對稱 (Information Asymmetry)： 助理利用能直接接觸國外老闆的機會，傳遞對自己有利的訊息，造成你與國外老闆之間的猜忌。 納許均衡 (Nash Equilibrium)： 既然助理不聽話沒代價、老闆越級管人有爽感，這兩個人就不會改變。最終只有「追求效率」的你會受不了。 最後誰會走？ 很多人問：最後誰會走？答案是 經理人 。 因為高階人才的「時間期望值...

理工人必修的「隱形技能」：為什麼技術夠硬，專案還是會 GG？ 在商學院的課程中，有一門課是所有準經理人的必修思維， 但在理工科系的訓練裡，卻鮮少被提及。這門課叫： 賽局理論 (Game Theory) 。 如果你曾有過以下這種「無力感」： 技術明明是正確的，但在會議上卻說服不了非技術背景的主管 專案出事時，發現自己成了那個唯一留在船上扛責任的人 明明投入了大量心血，專案卻在最後一刻被喊停，一切化為烏有 這往往不是因為你「不夠聰明」，而是因為你陷入了 職場賽局的盲點 。 這篇文章將拆解三個理工人最常忽略的博弈思維， 幫你把「硬實力」轉化為真正的「影響力」。 一：別掉進「沉沒成本」的技術執著 理工人對自己親手指揮AI寫出的程式碼、設計的架構，往往有著強烈的情感與堅持。 但現實是：當市場變了、客戶需求轉向了，過去投入的一千個小時就是 「沉沒成本」 。 博弈高手深知：決策時，唯一要看的是「未來的期望值」。 如果你因為「捨不得放棄過去的努力」而繼續加碼，這不是堅持，而是輸家的賭氣。 博弈心法： 學會「停損」比學會「技術」更難，但它決定了你是否能從失敗的賽局中脫身。 二：破解跨部門的「囚徒困境」 專案管理最難的不是技術整合，而是「人的利益」。 當研發想要品質、業務想要速度、財務想要省錢，每個人都追求自己的最優解， 最後的結果通常是專案進度卡死，形成 「囚徒困境」 。 「為什麼明明是為了公司好，大家卻不配合？」 成熟的 PM 知道：你不能只靠「邏輯」去要求別人，你要靠「誘因」。 你必須重新設計賽局，讓合作的 Payoff（收益）大於自私的收益，合作才會自然發生。 這不是玩弄手腕，這是「機制設計」。 三：重視「破窗效應」帶來的訊號 在工程領域，一個小 Bug 可能只是個案；但在博弈心理中，這是一個「訊號」。 如果專案初期的小缺失沒人理會，團隊成員就會接收到訊息： 「這個 PM 的標準是可以妥協的。」 這就是「破窗效應」，它會迅速侵蝕團隊的執行力與信任度。 PM 們 ~ 你對細節的縱容，其實是在釋放一種「博弈訊號」。第一時間修補破窗，是為了建立你「可信的威脅」。 ...

需求失控 × 專案成功率：三個關鍵誤判 專案會失控，通常不是因為技術不夠、團隊不努力， 而是因為 一開始就誤判了三件關鍵的事 。 如果你曾遇過以下狀況： 需求一開始說好，卻在專案中不斷膨脹 會議明明討論過，事後卻各說各話 專案看似還撐得住，最後卻突然全面失控 那你遇到的，可能不是執行問題，而是 結構性的誤判 。 這篇文章會用實際專案經驗，拆解三個最常被忽略、卻最致命的誤判點， 幫你看清為什麼「明明很努力，專案卻還是出事」。 誤判一：以為需求會「自然穩定下來」 很多專案一開始都很順。 林先生在專案初期沒有拒絕任何需求，他心想：「先做，再說。」 問題在於 : 當沒有清楚定義「哪些不在這一版要做」， 每一個新想法，都會自動被當成合理追加。 顧問觀察： 沒有被關起來的範疇，最後都會變成責任。 後來他調整做法，把需求明確分成三類： 本版一定要做 下版再談 本專案不處理 並要求每個決策都有明確共識紀錄，專案才開始回到可控狀態。 誤判二：以為「講過了」就等於對方記得 第二個問題，出在溝通。 會議很多、討論很熱， 但當進度開始落後時，每個人對「當初怎麼說的」記憶卻完全不同。 「我以為那只是討論，不是決定。」 林先生後來養成一個習慣： 每次會議結束，只做一件事，把結論寫下來，請對方確認。 他開始用簡單工具整理需求版本與決策紀錄， 不是為了流程漂亮，而是避免專案在「各說各話」中失控。 誤判三：以為風險要出事才算風險 第三個常見誤判，是把風險當成事後處理。 需求開始堆疊、人力逐漸吃緊， 但因為「目前還撐得住」，沒人願意踩煞車。 顧問提醒： 真正的風險，往往不是爆炸那一刻，而是你選擇忽略的那一週。 ...

利害關係人矩陣 × 專案穩定度：如何避免專案被「人」拖垮 在一次關鍵的專案會議中，Jason 坐在會議桌的一端，環顧四周。 來自不同部門的主管依序發言，每個人都帶著自己的立場、目標與顧慮。 表面上大家討論的是時程與功能，但 Jason 心裡很清楚， 真正的戰場從來不在簡報上，而在這些人的態度與影響力。 「進度要加速!」 這句話在他腦中反覆盤旋。 1. 顧問第一眼會先看「人」，不是進度 從顧問角度來看，Jason 面對的並不是單純的進度壓力， 而是一個典型的 專案管理 關鍵難題： 利害關係人的影響，往往比技術本身更致命。 在複雜的專案環境中，不同人的支持、冷淡或反對， 會直接決定資源是否到位、決策是否順利、風險是否被放大。 顧問視角洞察： 專案失敗，往往不是事情做錯，而是人沒有被正確對待。 2. 利害關係人矩陣，是 Jason 的第一道防線 Jason 習慣在專案初期就建立一張「利害關係人矩陣」。 他常對團隊這樣說： 不先搞清楚誰有影響力、誰站在哪邊， 專案只是在賭運氣。 這張矩陣很簡單： 橫軸：態度（支持 / 中立 / 反對） 縱軸：影響力（高 / 低） 一旦放上去，誰該優先處理、誰需要被經營， 立刻一清二楚。 3. 最危險的象限：高影響力 × 反對 Jason 印象最深的一次，是面對一位態度冷淡的財務長。 表面理由是「成本風險太高」，但 Jason 知道， 真正的關鍵在於：這個專案目前看不到對他個人的好處。 Jason 沒有硬拚，而是結合 AI 自動化 與歷史財務數據，整理出一份聚焦於「流程優化後節省成本」的風險評估。 重點不是技術，而是把專案重新翻譯成對方在意的語言。 關鍵策略： 反對者不是用來說服...

私訊不是效率，是風險：顧問視角拆解「悄悄回」為何讓專案失控 在台北某間新創公司裡，專案經理 Eric 正面臨一個看似微小、實則危險的訊號。 客戶的問題來得又急又快，他需要即時回應，同時也必須確保團隊能完整追蹤所有決策與承諾。 但最近，他發現專案成員小安經常選擇「私下回覆客戶」，群組裡卻完全沒有任何紀錄。 表面上問題解決了，Eric 心裡卻越來越不安。 1. 顧問第一眼就會警覺：這不是貼心，是風險訊號 在專案現場，「私訊解決」乍看之下很有效率，但在 專案管理 的視角裡，它通常代表三件事： 決策無法被回溯 責任邊界開始模糊 風險在黑箱中累積 顧問視角洞察： 私訊不是壞，而是 當它變成主要溝通管道時，專案就開始失去控制 。 2. 為什麼主管會對「悄悄回」特別敏感？ Eric 在一次線上會議中說了一句話，讓團隊瞬間安靜： 如果所有對外回應都發生在私訊裡， 那我們其實是在霧中開專案。 問題不在於回覆得快不快，而在於： 之後發生爭議，誰說過什麼？ 客戶的期待是否被團隊一致理解？ 這個承諾是否已納入時程與風險評估？ 沒有紀錄的溝通，對專案來說就是一顆延遲引爆的地雷。 3. 真正的問題不是私訊，而是「私訊取代流程」 從顧問角度看，成熟的團隊不是禁止私訊，而是有清楚的界線： 私訊可以協調 但結論必須回到群組 對外承諾一定要可追溯 Eric 後來發現，小安並非刻意隱瞞，而是擔心在群組發言會被放大檢視。 這其實是文化問題，而不是個人問題。 4. 當透明度不足，AI 與工具才會變得有價值 在另一家台北的中小企業，CEO 刻意在內訓中示範： 如何透過 AI 自動化 讓溝通本身變成可管理的流程。 包含： ...

一句 @all 讓群組瞬間靜音：顧問視角拆解「集體不回」背後的政治訊號 上午十點二十分，林組長坐在位子上，盯著公司 LINE 群組。 專案進度卡了一天，他決定發一句看似再普通不過的提醒。 @all 請相關同仁協助確認文件是否已送交，謝謝。 沒有責備、沒有期限、沒有點名。理論上這只是一個中性的流程提醒。 但訊息送出後，整個群組像被按下靜音鍵。 沒有人回。 1. 顧問第一眼就會知道：這不是沒看到，是大家「看懂了」 在組織裡，真正需要警覺的從來不是「已讀不回」，而是 集體不回 。 林組長一開始以為只是時間點不巧，但一個小時後，他看到同事在別的群組聊天、主管也在其他頻道回訊。 只有這一句 @all，安靜得不正常。 顧問視角洞察： 這不是溝通失效，而是一個清楚的政治訊號： 群組正在做一個集體的政治選擇。 2. 第一個關鍵誤判：把 @all 當成通知，而不是立場宣告 很多主管、PM 都會犯同一個錯，以為 @all 只是「一次叫到所有人」。 但在實際運作的組織裡，@all 代表的是： 我不再私下處理 我把事情拉到公共場域 我讓每個人都成為見證者 這不是工具行為，而是政治動作。即使內容再中性，@all 本身就意味著：「這件事值得被所有人看到」。 顧問視角提醒： 你以為你在推進度，別人可能覺得你在「升溫」。 3. 一個 @all，會立刻喚醒三種角色 從顧問角度看，@all 送出後，群組內通常會立刻出現三種典型反應。 3-1. 執行派：最快回的那群人 「收到，我這邊已完成。」 「文件已送，謝謝提醒。」 他們不是最熱心，而是不怕被看見。 3-2. 冷淡派：真正的多數 回了會不會被拉進責任？ 不回會不會有人先出頭？ 這件事最後會不會燒到我？ 冷淡派的沉默，是風險管理...

專案卡住，往往不是反對者太多，而是你沒看懂冷淡派 下午一點半，吳經理坐在辦公室裡，視線停在桌上的專案文件上。 昨天那場會議，正式宣告了一個事實，那個被寄予厚望的 AI 自動化 專案，卡住了。 技術準備沒有問題，流程也規劃完整，但專案卻像一輛馬力充足的車， 因為抓地力不足，始終無法加速。 他心裡很清楚，真正的問題不是系統，而是人。 更精準地說，是專案裡同時存在的「冷淡派」與「反對派」。 1. 多數 PM 的第一個誤判：把冷淡派當成沒事的人 在專案會議裡，反對派很顯眼。 他們會質疑、會反駁、會公開唱反調。 相比之下，冷淡派看起來「沒意見」、「不吵不鬧」、「配合度尚可」， 於是常被 PM 視為低風險角色。 但從顧問角度來看，冷淡派往往才是專案推不動的關鍵摩擦力。 顧問視角洞察： 冷淡派不是沒立場，而是「看不到對自己有什麼好處」。 他們的沉默，本身就是一種政治訊號。 2. 反對派不是敵人，而是風險的早期預警系統 吳經理後來回想，那些明確反對導入 AI 自動化 的人，其實並不是單純排斥新技術。 他們擔心的是角色被取代、流程被改寫、影響力下降。 這些不是技術問題，而是身份與權力的問題。 反對派真正的價值，在於他們會把風險說出口。 顧問視角洞察： 反對派處理不好會變阻力，處理得好，反而是專案最早的風險雷達。 3. 顧問常用的關鍵切分：冷淡派要「看見價值」，反對派要「降低威脅」 吳經理後來找來資深顧問協助，才真正釐清策略方向。 顧問給他的第一個提醒很直接： 「你不能用同一種方式，處理所有不支持你的人。」 於是策略被清楚拆成兩條線： 冷淡派： 讓他們看見與自己相關的好處 反對派： 降低他們對失去控制權的恐懼 4. 資訊透明不是為了效率，而是為了政治穩定 在冷淡派身上，吳經理刻意強化「看得見的進展」。 不是說服，而是讓專案與他們的日常工作產生連結。 透過清楚的里程碑、可視化進度、固定節奏的溝通， 冷淡派開始理解：這個專案不是別人的事。 顧問視角洞察： 透明不...

專案進度為何常被政治力打亂？顧問視角解析 Jacky 的會議現場與五大關鍵判斷 你是一名在科技業打滾多年的專案經理 Jacky，技術能力扎實、流程規劃清晰，專案大小事早已成為日常。 但上週臨時加入的那場會議，卻像一場無預警的風暴。 當你簡報到一半，一位資深高階主管忽然問出一句： 「這次專案到底是誰主導？資源分配是不是要調整？」 這句話像在會議桌上投下一顆震撼彈。Jacky 立刻意識到，這不是技術問題，而是政治問題。 而政治，正是多數 PM 一開始沒被教、卻遲早會被迫學的課題。 Jacky 一直以為「技術能力強、流程穩」就能讓專案順利前進。 然而，真正讓專案脫軌的，往往不是技術，而是誰支持你、誰反對你、誰根本不在乎你。 1. 技術不是專案的全部：忽略政治意識是最大風險 在會議裡，高階主管的那句質問並不是「好奇」，而是「宣示」。 他在意的不是專案流程，而是：誰握權？誰擁資源？誰能決定方向？ Jacky 過去只專注於技術與流程優化，以為專案會因為「做得好」而被支持。 但在公司實際運作中，專案是否推得動，更取決於政治位置與權力結構。 顧問視角洞察： PM 必須培養的不只是技能，而是「權力敏感度」。 在每個決策前問自己：這件事誰會痛？誰會爽？誰會阻擋我？ 2. 理解部門故事：政治力是需求背後的隱形推手 Jacky 開始觀察，每個部門主管的行為背後都藏著一套邏輯。 行銷部關心的是 KPI，而不是專案完成度。 技術部關心資源負荷，而不是市場時程。 管理層關心風險、聲量與成果的可見度。 過去 Jacky 把這些解讀為「合作不順利」； 但現在他理解，這些都是部門自然追求生存與績效的結果。 顧問視角洞察： 理解立場比理解需求更重要。 利害關係人的話語是表象，他們的績效壓力、政治位置、部門目標才是真實動機。 3. 用 AI 與自動化拉高政治透明度：資訊清楚，支持自然增加 Jacky 發現，當資訊混亂時，政治力會上升； 當資訊清晰時，政治阻力會下降。 於是他開始導入自動化： 用 Google Sheet Script...

從顧問視角解析：為什麼 PM 常抓不到真需求？李經理的供應鏈專案現場紀錄 在繁忙的台北週一早上，李經理踏進會議室時，桌上堆滿的需求清單彷彿正等待他的判決。 客戶是一家醫療器材公司，期望透過 AI 自動化 改善供應鏈。但李經理心裡很清楚：利害關係人所說的需求，往往不等於真正需要解決的問題。 身為擁有十五年以上經驗的專案顧問，他比誰都明白：專案之所以失敗， 常常不是因為技術不夠好，而是從第一天開始，就追錯方向。 1. 表面需求 ≠ 真需求：錯在一開始就問錯題目 多數 PM 都曾有過這種經驗：花數月打造出客戶要求的功能，最後卻換來一句 「這不是我要的」。 李經理過去也掉進過同樣的陷阱。當年，他的團隊完全依據需求書打造系統， 但正式呈現時，客戶卻反應與期待落差巨大。 「我們按照你的需求做的啊！」 這句話通常代表：真需求被漏掉了。 真需求往往被業務包裝、被語言模糊、被政治力扭曲。 而 PM 若沒有辨識能力，就會一路錯下去。 顧問視角建議： 不要急著問「你想要什麼？」，而應先問：「你現在最想解決的，是哪個現象？」 把語言從「功能」轉向「痛點」，真需求才會浮現。 2. 傾聽不是聽字面，而是聽意圖 會議中，利害關係人常會避開不想面對的問題，也可能不願意直接講出真正的痛點。 李經理會觀察語氣、停頓、閃爍其詞的細節，因為那裡往往藏著真正的阻力。 在這次的供應鏈專案中，有位部門主管堅持加入某項自動化功能， 聽起來合理，但李經理敏銳察覺問題不在功能，而是該主管正承受某 KPI 壓力。 真需求與其說是「技術需求」，不如說是「心理需求＋政治現實」。 顧問視角建議： 有效傾聽不是等待對方講完，而是追問： 「你之所以想這麼做，是因為什麼困難？」 這句話可以打開所有原本不願透露的訊息。 3. 小步快跑：避免一次做滿卻一次做錯 李經理始終堅持「小步快跑」的原則，尤其是在 AI 自動化 專案中更是如此。 AI 專案不確定性高，如果一次交付過大範圍...

三層需求分類法：Jack 如何在需求爆炸中守住專案底線 在台北市中心的一間會議室裡，週一早上的氣氛一點也不輕鬆。 Jack，一位有多年實戰經驗的專案經理，正盯著桌上堆得像小山一樣的需求清單。 主管前幾天留下一句話還在他耳邊打轉，「這禮拜要交。」 與此同時，來自行銷、產品、業務、客戶的各種需求像訊息通知一樣不斷跳出， 每個人都說自己的需求「很急」、「很重要」。 對很多專案經理來說，利害關係人需求「太多」是再熟悉不過的老問題。 真正的挑戰不只是量多，而是 怎麼在有限的時間與資源下，決定哪些需求非做不可，哪些可以往後排 。 Jack 後來採用了一個簡單但非常實用的思維框架，也就是本文要談的 「三層需求分類法」 。 它不是完美解藥，卻是一個能在混亂中穩住局面的起點。 1. 需求為什麼會失控：問題不在量，而在沒有分級 在多數公司的現實裡，需求大概有幾種來源： 行銷部門希望多幾個功能，好在活動頁面上有東西可以講 開發或技術部門希望設計得更「完整」、「未來可擴充」 業務希望多一些客製選項，好讓談案子時好講話 客戶則會根據自己現場習慣，不斷追加「如果可以順便也幫我…」 每一個需求看起來都合理，背後也都有善意，但加總起來就成了專案的夢魘。 Jack 很清楚，若只是把所有需求堆在同一個優先層級，最後一定只剩下兩種結果： 不是全部做不完，就是全部做得很勉強。 他需要的，不是再多一份更漂亮的需求清單，而是一套可以讓團隊與利害關係人 一起看見「輕重緩急」的共同語言 。 2. 三層需求分類法：必須、應可、可緩，先切出「底線」與「彈性」 Jack 在那次專案裡，開始嘗試用三層架構來處理所有需求， 他把所有需求分成三類： 必須達成的需求： 不做就會造成重大風險，或專案失去意義的項目 應可達成的需求： 有明顯正面效果，但不影響生死，可以視資源...

利害關係人訪談的 11 個關鍵提問：如何從「問錯問題」到掌握專案脈絡 在台灣的一家中型科技公司裡，身為專案經理的 Cindy 最近接到一個重任。 公司即將推出新的 AI 自動化 工具，她必須在有限時間內和各部門的利害關係人進行一輪深度訪談， 釐清需求、風險與期待。 這一次，她特別緊張，因為上次的經驗並不好。 那時她自以為準備充分，訪談大綱寫得滿滿，結果正式開會時， 問題問得太抽象，核心資訊沒問出來，利害關係人的真實顧慮也完全被埋在話裡不話外。 訪談利害關係人，看起來只是「聊天」，實際上是專案成敗的重要分水嶺。 問得好，可以挖出真正的需求、風險與政治現實；問得不好，整場會議就會變成客套與空話。 下面整理出 11 個訪談時可以使用的提問方向，同時提醒應該避免的問法， 幫助專案經理在 專案管理 與流程優化上少踩一些雷。 1. 釐清專案存在的理由：為什麼現在要做這件事？ 很多訪談一開始就跳進功能細節，結果雙方一直繞圈圈。 Cindy 這次學會先問大方向： 「這個專案對你來說，最重要的意義是什麼？ 如果它成功，對你或你單位會有什麼實際改變？」 避免的問法： 「你對這個專案有什麼看法？」 太寬、太空，很容易換來三句話就結束的寒暄。 2. 挖出真正需求：哪些細節其實不是細節？ 在 專案管理 裡，很多災難來自於「以為只是小地方」。 Cindy 會改問： 「在你每天的實際工作情境中，你最希望這個解決方案幫你處理哪幾件事？」 接著再追問： 「如果這一塊沒有處理好，對你會造成什麼影響？」 避免的問法： 「有沒有什麼要改的？」 多數人會客氣說「差不多」，真正的問題便被默默保留到上線後才爆出來。 3. 提早看見阻力：目前你最擔心什麼？ 對於導入 AI 自動化 這...

利害關係人分析 × 分類框架：如何用四張地圖掌握專案政治現場 走進楊經理的辦公室，他正盯著一份專案報告，眉頭微皺。 那份文件看起來像是一般的數據匯總，其實是他掌握整個專案利害關係人動態的索引。 在他的觀念裡，利害關係人管理從來不是「下命令」而已，而是一場有系統的分析與判讀。 他常對團隊說的一句話是： 「專案如果一直卡住，先不要怪流程，也不要怪工具。 很可能是你還沒搞清楚，這件事誰會得利，誰會受傷。」 在這樣的環境中， 專案管理 的精髓早已不只是管時程、管成本，而是要懂得分析各類相關人， 再藉由這些判讀來優化專案決策與溝通策略。 AI 自動化 只是輔助整理資訊的工具，真正決定專案走向的，仍然是你怎麼看懂這些人。 1. 為什麼利害關係人分析比你想的更關鍵？ 很多 PM 一開始接觸 專案管理 ，習慣從範疇、時間、成本、品質這些經典要素下手。 但楊經理的經驗是： 「專案會不會成功，常常不是看你計畫寫得多漂亮，而是看你有沒有忽略任何一個關鍵人。」 他遇過這樣的情況： 專案排程都算過了，卻被某個高階主管一句話打回重來 技術方案看似完美，上線前卻被一個前線單位否決 需求談得差不多了，真正簽字的人卻從頭沒有被拉進來 這些看起來像是流程問題，本質上都是利害關係人分析出了差錯。 也因此，他為團隊設計了一套簡單但實戰的四分類思維， 要大家在想「怎麼做」之前，先問自己： 「這個專案，到底動到了誰的盤子？」 2. 第一張地圖：權力 × 利益，先找出真正的關鍵角色 楊經理在每個專案啟動時，幾乎都會先畫出一張最基本的矩陣， 也就是常聽到的「權力 × 利益」分類。 利益低 利益高 權力高 保持關係、定期更新 ...

專案新手為何總是吃虧？從小凱案例看懂 PM 必備的政治敏感度 在台灣的職場裡，新手 PM 的第一堂真正課程，往往不是排程、不是需求拆解、不是風險矩陣，而是： 如何在政治力與權力關係中，保住專案，也保住自己。 小凱，一位技術能力超強的新手專案經理，最近就遇到了一場典型的「被政治壓著跑」的場景。 主管對著小凱說：現在人力都在年底衝業績了，資源我們先不排，你們團隊就先上吧。 小凱愣住了。 他熟悉 Python、Google Sheet Script、PowerBI，甚至能做簡單的 AI 自動化，但這些技術沒有一樣能幫他處理這句話背後真正的問題，那就是 政治現實。 站在一旁的前輩蘇姐心裡想著： 「這孩子啊，不先學政治，永遠都會被壓著跑」 1. 技術強 ≠ 專案推得動：PM 最容易忽略的「政治盲區」 多數技術型 PM 都有一個共通的起手式： 我把事情做好就好了。 小凱也是如此。他相信只要把報表做得精準、流程設計得漂亮、PowerBI 看板跑得流暢， 專案自然可以推動。 然而，這套邏輯在專案政治世界裡完全站不住腳。 專案為何會失敗？ 在台灣，很多職場 80% 是人、政治、影響力、資源、立場。 只有 20% 是技術。 這也是為什麼許多新手 PM 感到挫折： 明明我做的東西最好，為什麼推不動？ 因為「最好」不是關鍵，「誰支持」才是關鍵。 2. 不懂政治敏感度的代價比你想像的大 在一場跨部門週會中，一位大部門主管突然丟出一句： 「我們現在手上案子滿到炸，真的抽不出人來啦！」 新手 PM 的典型解讀方式是： 「他們人力吃緊沒人可以投入專案」 但資深 PM 看到的是： 「這位主管的 KPI、風向與政治位置並不支持這個專案。問題不是人力不足，而是他看不出投入資源能為他帶來什麼好處。問題從來不是人力，而是這個專案...

跨部門專案難以推動？Eric 的真實故事教你看懂內部政治的本質 Eric，一位在公司被認為「穩定、可靠、扛得住壓力」的專案經理，最近就遇到一個經典的跨部門地雷。 新專案一啟動，來自產品、行銷、IT 的代表都齊聚會議室。表面上大家笑臉迎人，但 Eric 一走進來，就看見熟悉的暗流正在醞釀。 每個人心中都有自己的盤算： 行銷（最會玩 KPI 的部門） 產品（只在乎方向正不正確） 技術（避免背鍋、避免失控） 一場典型的「跨部門專案大爆炸」正在慢慢形成。 1. 跨部門衝突不是衝突，而是立場錯位 會議剛開始，行銷代表率先開火： 「為什麼這個功能還沒排優先？我們下個月活動要用。」 產品經理立刻反擊： 「市場還沒成熟，你現在推出去只會砸品牌」 Eric 聽著對話，心裡非常清楚： 這不是資訊不一致，而是 每個部門的 KPI 根本不同軌道 。 行銷不是在乎專案完成，行銷在乎的是「能不能交得出活動數字、能否拿到更多預算」 專案準時交是 PM 的 KPI，不是行銷的。 所以你常會看到一種弔詭現象： ➤ 行銷說的每個要求，都能讓他們的 KPI 好看 ➤ 但不一定能讓專案成功 Eric 曾形容這種狀況： 「跨部門專案像多軌列車並行，每個部門都在用自己的時刻表跑， 唯獨 PM 必須把所有軌道合在一起。」 每個部門說的都是真話，但都只是真實的一小部分： 行銷的真實：需要活動可以運轉、需要數字好看 產品的真實：方向錯了比延期更可怕 技術的真實：做不完的工最容易變成自己背鍋 PM 的真實：專案不能炸、不能延、不能亂 當每個人都為自己的 KPI 最優化時，專案自然就會變成政治戰場。 PM 的職責不是消滅衝突，而是把「每個部門的自利」轉換成「整體目標的一致」 ...

快速判讀利害關係人的真實意圖：David 的專案政治學第一課 在 專案管理 的世界裡， 專案初期往往是最混亂、也最容易埋下地雷的階段。 所有 PM 都遇過同樣的問題，那就是 : 「利害關係人口頭說的，和他們心裡真正想要的，到底是不是同一件事？」 要快速掌握利害關係人的真實意圖，不但影響專案啟動是否順利，更決定流程優化、風險管理、方向調整是否能奠定正確基礎。 David，一位在跨國企業磨練多年的專案經理，最近正面臨這樣的挑戰。 新專案牽涉營運、技術、業務多方利益，各自有自己的盤算與壓力。 專案才剛起步，會議室裡的空氣就已經充滿了看不見的角力。 1. 利害關係人的話，不能只聽表面 第一次啟動會議中，大家表面上都說「支持專案」， 但 David 很清楚，那只是禮貌說法。 他在會議中觀察到： 營運主管眼神飄移，明顯不確定是否願意配合。 技術代表態度保守，心裡還沒準備好要承擔風險。 新上任的業務部長，急著想做出績效。 「表面支持不代表真心支持；表面反對不代表不能合作。」 David 的第一步不是確認需求，而是確認「每個人背後的盤算」。 關鍵心法： 任何專案的第一堂課，不是做 WBS，而是判斷「誰想什麼、誰怕什麼、誰在保護什麼」。 2. 人心的訊號，往往藏在「欲言又止」裡 在一次會議尾聲，David注意到技術代表突然沉默。 他沒有插話，也沒有提出反對意見，但臉上明顯有顧慮。 多數 PM 會以為「沒講＝沒問題」。 但 David 知道，這是專案地雷。 「會議中不說、會議後爆炸。」 於是他會後立刻找對方喝咖啡。 技術代表終於說出真正問題：某個需求看似簡單，但其實會牽動底層架構，風險極高。 PM 的敏感度不是看誰講最多話，而是看誰...

「這不是我要的！」利害關係人為何反悔？小林的專案政治現場 當利害關係人盯著成果，吐出一句：「這不是我要的」，專案經理心裡往往只剩下一句話，那就是完蛋了。 這個場景在 PM 的職涯裡幾乎無可避免。 在台北一間科技公司中，資深專案經理小林正面臨這場風暴。專案是關於 AI 自動化 的新應用。 明明所有人早已「達成共識」，但在審核那天，利害關係人卻突然全盤否定。 小林並不陌生這種情況。 專案開始時，大家對目標滿懷期待；越到後期，跨部門合作與需求變動卻讓專案風險不斷升高。 專案管理走到這一步，靠的已不是框架，而是 PM 的政治敏感度與人性洞察。 1. 需求變動不是問題，真正的問題是：你沒看懂原因 面對利害關係人的否定，小林沒有急著辯解，而是選擇先「安靜」。 他深知一句老話： 「利害關係人口中的需求，從來不是需求本體，而是背後的動機」 他開始反問自己： 需求變動是因為市場變了？ 還是高層戰略調整？ 抑或只是利害關係人焦慮、想掌控？ 很多 PM 在需求變動時會陷入技術思維，以為是規格問題，但小林知道： 需求變動其實是 人性訊號 ，是組織政治的表現，是權力關係的影響。 小林的洞察： 真正的風險不是需求變，而是你沒看懂「誰在改、為什麼改、他改的目的是什麼」。 2. 與利害關係人的溝通，不是說服，是重新找平衡 小林安排多場深度會議，不是要辯護，也不是逼對方接受，而是想先讓對方「把真話說出來」。 他發現利害關係人真正的擔心不是技術，而是： 新功能是否符合他部門的 KPI 如果方向錯了，他要不要負責 上層是否已改變策略，但他沒被通知 一句「這不是我要的」，背後常常不是不滿，而是「害怕」。 「我們可以在這週補一版模擬，你再看看是不是符合新的策略方向？」 ...

專案一開始就藏著失敗徵兆？李先生的五個現場觀察 在台灣的職場裡，身為專案經理的李先生最怕聽到的一句話，就是主管淡淡地說：「這禮拜要交。」 經過多年 專案管理 經驗，他越來越確信一件事： 多數專案並不是在後期突然失敗，而是在最一開始，徵兆就悄悄出現。 李先生常說，專案的結局往往不是在交付那天決定的，而是從第一次會議、第一次共識、第一次需求確認時，命運就開始成形。 那些看似微不足道的細節、沉默、猶豫與錯誤假設，往往會在後期變成巨大的地雷。 1. 目標不清楚，是最早也最致命的警訊 每當專案啟動會議一開始，李先生最先觀察的不是簡報內容，而是參與者的眼神。 如果團隊對「到底要達成什麼」說不出同樣的答案，他心裡會立刻亮起紅燈。 某次公司推動 AI自動化 專案時，大家對新科技充滿期待， 但沒人先問清楚「我們想改善什麼問題」。 等到進度卡住、方向改了又改，整個團隊才意識到從一開始就走錯方向。 目標不清楚的專案，通常不是慢慢做不出來，而是越做越迷失。 2. 不切實際的預算與時程，是專案悲劇的起點 李先生最常遇到的，就是高層拍胸脯說：「這個應該不難吧？兩個月交得出來。」 但只要是有經驗的 PM，一看估算就知道是災難的開始。 過度樂觀的時程與預算，幾乎永遠忽略： 不可預期的風險 跨部門協作成本 需求變動 現有資源的極限 專案後期的失控，不是運氣不好，而是「從一開始就註定不可能」。 3. 新人加入但未提供支援，是早期最容易忽略的地雷 有次公司突然安排一位缺乏背景的新成員加入專案。 對方有熱忱，但毫無經驗，很快變成團隊的瓶頸。 文件品質下降、溝通延遲，工程師甚至需要花時間重新解釋需求。 問題不是新人能力不好，而是團隊沒有給他足夠的支援與 onboarding。 李先生常說，專案不是「人越多越快」，而是「...

技術專案經理最容易忽略的七個政治風險：阿智的工作現場筆記 在技術導向的公司裡，專案經理的日常常常不是大家以為的那樣。不是每天跟工程師討論技術細節，也不是寫完需求就能等進度。 大部分時候，真正讓人頭痛的，是那些看不見的期待落差、決策延誤、單位之間的小角力。 阿智，一位擁有十年以上經驗的技術型 PM，最近正負責一項新產品開發專案。專案進度看起來還算穩，但利害關係人的需求一直變來變去， 使他覺得自己像是在跑一場沒有終點線的馬拉松。技術面的挑戰他不怕，真正讓他疲憊的，是處理各種人性的細節。 他曾因錯估高階主管的想法而被臨時換方向，也曾因忽略外部風險，讓專案陷入被動。 這些經驗讓他慢慢意識到，技術可以靠學習解決，人性與政治才是專案經理真正需要花時間理解的部分。 1. 忽略組織文化造成反效果 公司最近導入一套 AI 工具，希望加速流程。阿智本來覺得這是好事，沒想到推動起來卻完全不是那麼回事。 技術部門願意試，營運部懷疑會拖慢流程，業務部更是覺得這些工具只會讓事情變複雜。 他這才發現，每個部門對變革的反應完全不同。如果沒有先理解文化與氣氛，技術再好也推不動。 建議： 在任何技術導入前，先找到各部門真正說話有分量的人，讓他們成為內部的帶頭者，比工具本身還重要。 2. 低估利害關係人的影響力 有次專案已經到最後階段，財務經理突然提出要加強 AI 模組，又強調不能延遲。 阿智擔心衝突，選擇直接答應。結果工程團隊接不住，時程最終還是拖延。 他才理解，不是不是每個需求都能無條件答應，有些需要先判斷對專案的影響，有些則必須先讓對方看到代價。 做法： 對每位利害關係人做影響力與立場分析，再決定談判策略，會比硬吞下需求要安全得多。 3. 溝通透明度不足 為了加快會議，阿智曾將進度報告簡化。沒想到資訊縮水後，利害關係人反而更不放心，甚至懷疑專案狀況是否真的控制得住。 他才發現，PM 的溝通並不是越短...

利害關係人管理 × 專案成功率：從顧問視角解析小瑄錯失的十個關鍵判斷 在專案管理的世界裡，真正讓專案陷入泥淖的，往往不是技術，而是「人」，更精準地說，是利害關係人的動機、期待、政治現實與決策模式。 作為外部顧問，我常看到專案失敗的原因並非技術不足，而是：專案經理沒有正確讀懂利害關係人的盤算，或誤以為流程完備就能推動專案。 小瑄，一位中型企業的 IT 專案經理，最近在推動一項技術導入。她擅長工具，也熟悉流程，但卻一直覺得專案進度「卡卡的」。 直到後來她才發現：真正阻礙進度的，是利害關係人的誤判，且這些誤判在許多企業裡反覆出現。 目錄 專案顧問眼中：真正的專案壓力從不是技術 企業最常犯的十大利害關係人誤判 專案經理可以立即採用的三大策略 結語：從技術 PM 進化成決策型 PM 常見問題 FAQ 1. 專案顧問眼中：真正的專案壓力從不是技術 某次跨部門會議中，財務長老李語氣平淡卻帶著壓力：「下週要看到結果。」 小瑄愣住了。因為她知道事情沒那麼簡單， IT 認為功能太多；業務想搶最快時程；供應商還在延遲交付；而老李只是希望能對董事會交代。 專案不是技術問題，而是人、利益、政治、風險、時程與意圖交織的生態系。 作為顧問，我看過許多像小瑄一樣的 PM，努力加班、做流程、做 WBS、寫文件，但依然被利害關係人牽動得疲憊不堪。 其中的根本原因不是不努力，而是「對利害關係人的判斷不夠準確」。 以下十個誤判，是企業專案中最常反覆出現的模式，也是專案成功率提高不了的主因。 2. 企業最常犯的十大利害關係人誤判 以下十項誤判，我在各產業都屢見不鮮，尤其在跨部門與技術專案中。 誤判 1：以為利害關係人「知道自己要什麼」 很多 PM 認為需求只是問一問。 但利害關係人往往不知道「自己真正想要的是什麼」，只知道「他不想承擔什麼風險」。 顧問建議： 使用「Why × 5 ...

2025 數據分析 × AI 自動化：Mark 如何帶領團隊從卡關到加速 在某個光線明亮的早晨，台灣一家知名企業的專案經理 Mark 盯著電腦螢幕微皺眉頭。月底的績效報告顯示，團隊把大量時間花在數據清理與準備工作上，導致真正的數據分析進度一再延後。他心想：「如果有更好的方式能提高效率就好了。」 目錄 數據分析效率低落的真正壓力來源 AI 自動化為何價值無法完全釋放 AI 如何降低專案風險並提升分析精準度 機器學習帶來的 2025 分析新能力 Mark 的轉折：導入 AI 流程後的改變 2025 的數據分析趨勢：每位員工都必須具備的能力 管理者的建議：如何打造高效數據分析團隊 常見問題 FAQ 1. 數據分析效率低落的真正壓力來源 數據分析愈來愈重要，但 Mark 發現團隊的時間都卡在前期的「資料清理」。 這不只是他們公司的問題，而是許多台灣企業共同的痛點。 如果明明擁有大量資料，卻無法轉化成洞察，那麼資料只會成為負擔，而不是資產。 Mark 的團隊成員技術能力不差，但手動清洗資料仍然需要反覆檢查、調整格式、去除異常值，甚至要處理跨部門資料標準不一的問題。 在每次截止日逼近時，他們總覺得像是在追趕一列永遠追不到的火車。 2. AI 自動化為何價值無法完全釋放 在 2025 年，許多企業都宣稱自己正在導入 AI 自動化，但效果卻無法完全展現。 原因是： 數據來源與格式不一致 標準流程未定義清楚 團隊對自動化工具的使用不熟悉 管理者期待與團隊執行能力不一致 提醒： AI 自動化不是魔法。如果基礎資料品質不佳，AI 只會更快放大問題。 Mark 深刻感受到...

數據治理 × AI 自動化：Emily 如何把失控專案拉回正軌 數據治理 × AI 自動化：Emily 如何把失控專案拉回正軌 在某個繁忙的星期一早晨，台北一間中小企業的專案經理 Emily 再次被叫進會議室。延宕兩週的專案又被提醒「這禮拜要交」，螢幕上滿滿的報表與數字讓她頭更痛，卻仍無法得到一個可以真正幫助她判斷的答案。 表面看起來是進度問題，實際上則是典型的數據治理缺口。 目錄 被延誤專案背後的真正原因 什麼是數據治理？專案經理為何要在意 AI 自動化幫不了忙的時候：當資料是錯的 數據治理實務框架：從混亂到有標準 專案經理在數據治理中的角色 立即可用的行動清單 FAQ 一、延誤專案背後：不是工具不夠，而是數據太亂 Emily 的麻煩一開始看起來只是「估算錯誤」。預期三週完成的進度一路滑到第五週，每天加班補洞仍跟不上變動。 她看著報表心想： 「這個估算一看就知道做不到，可是當初大家都點頭說可以。」 進一步檢視後，她發現不同部門用的是不同版本的數據： 財務看的是上個月結帳數字 營運抓的是自己維護的 Excel 行銷依賴第三方平台的匯出報表 同一個指標有三套數字，任何一套都看起來「有道理」。這種情況下，即使用再多 專案管理 工具也只是把混亂包裝得更漂亮。 關鍵提醒 很多延誤並不是因為執行力差，而是決策與規劃基於「沒有被治理過的數據」。 二、什麼是數據治理？不是 IT 的事，而是專案成功的基礎 數據治理可以簡單理解為：用策略性的方式管理組織內的數據，讓它「可信、可找、可用、可追溯」。 對 Emily 這樣的專案經理來說，數據治理與...