專案經理面試問題

框架: 目標 → 利害關係人 → 範疇 → 計畫 → 治理

我會先釐清商業目標和成功標準：我們要達成什麼成果、為什麼重要、要怎麼衡量成功，以及期限或限制條件是什麼？ 接著我會盤點利害關係人：決策者、專案發起人、交付團隊、使用者、相依單位，以及所有會受這次變動影響的人。我會及早釐清角色與職責，避免權責歸屬模糊。 再來是定義範疇：交付成果、需求、排除項目、假設、限制、里程碑、預算、資源與風險。我會把工作拆成不同階段或工作流，找出相依性，然後擬出初版專案計畫。 最後建立治理機制：狀態回報頻率、呈報管道、決策流程、風險紀錄、議題紀錄、變更控制和溝通計畫。專案起步打得好，就能在執行壓力來臨之前先建立共識。

框架: 工作分解 → 相依性 → 負責人 → 時程 → 風險

我會先定義預期成果和主要交付項目，再依專案性質把整個計畫拆成幾條工作流，例如產品、工程、營運、法務、財務、教育訓練、資料和上市推廣（go-to-market）。 每條工作流都要定義工作項目、負責人、相依性、估算、里程碑與驗收標準，接著找出關鍵路徑。有些工作可以平行進行，但有些得等前面的決策、簽核、技術工作、廠商交付或使用者測試完成後才能開始。 我會建立一份包含里程碑、相依關係圖、資源假設、決策點、風險和溝通頻率的專案計畫。這份計畫要細到足以管理執行，同時也要保留彈性，能隨著新資訊出現而調整。 在承諾日期之前，我會先和各團隊負責人確認計畫。專案經理不應該自己閉門造車訂時程；最好的計畫，是由實際做事的人共同擁有的。

框架: 範疇基準 → 評估變更 → 取捨 → 決策 → 溝通

首先，我會在專案一開始就建立明確的範疇基準和成功標準。如果原本的範疇就很模糊，範疇蔓延會更難控制。 有新需求出現時，我會先釐清需求內容、提出的原因、急迫性、商業價值，以及它是上線的必要條件還是可以延後。接著評估它對時程、預算、資源、風險、品質、測試和相依性的影響。 我不會直接說不，而是提出幾個選項：加入需求並延後日期、加入需求但拿掉其他項目、把需求延到下一階段，或者如果它對目標沒有幫助就予以否決。這個決定應該由對的負責人來做，並且留下紀錄。 關鍵在於透明。利害關係人可以提出變更，但必須看得到背後的取捨。真正傷害交付的，是那些沒被看見的範疇蔓延。

框架: 評估 → 根本原因 → 選項 → 決策 → 溝通

我會先掌握真實狀況：哪些里程碑延誤了、關鍵路徑上有哪些工作、哪些已經完成、還剩哪些，以及這次延誤會不會影響最終上線日。有時某項工作雖然延誤，但還有浮時；有時一個小延誤就會卡住所有事情。 接著找出根本原因：工作量低估、相依項目延誤、資源不足、需求不明確、技術問題、廠商延誤、簽核流程卡關，或是範疇變更。解法要看原因而定。 再來擬定救援選項，可能包括調整工作順序、增加資源、縮減範疇、延長時程、讓工作平行進行、把卡住的決策往上呈報，或接受較高的風險。每個選項都要說清楚取捨。 我會及早和利害關係人溝通。一份好的狀態更新要包含影響、原因、救援計畫、需要做的決策，以及信心程度。我不會把延誤藏到無法挽回才說。

框架: 產能 → 優先順序 → 取捨 → 共識

我會先量化產能和需求：哪些團隊或人員是瓶頸、他們的時間已經有多少比例被占滿、哪些技能特別稀缺，以及哪些專案里程碑仰賴他們？ 接著依商業價值、急迫性、風險、法規遵循、營收影響、客戶影響和策略重要性來排優先順序。如果產能真的不夠，答案就不能是假裝每件事都還是會如期完成。 我會把取捨攤在管理層面前：延後優先順序較低的工作、縮減範疇、調動資源、聘用約聘人員、延長時程，或接受風險。這個決定要公開透明地做，而不是私底下默默過度承諾。 執行期間，我會持續關注人力使用率、阻礙因素和團隊過勞的風險。資源規劃不只關乎日期，也關乎團隊能不能長期穩定地交付。

框架: 辨識 → 負責人 → 日期 → 風險 → 呈報

我會在規劃階段就辨識出相依性，並在執行期間主動維護。每一項相依性都應該有負責人、交付項目、到期日、驗收標準，以及萬一沒達成會造成的影響。 我會用相依性追蹤表或 RAID 紀錄表，並在進度會議上檢視關鍵的相依項目。對於高風險的相依性，我會提早設定檢查點，而不是等到到期日才確認。 如果某項相依性延誤，我會評估它對關鍵路徑的影響，並和各團隊一起想辦法補救：調整工作順序、採用暫時的替代方案、縮減範疇、把決策往上呈報，或調整時程。 重點不只是追蹤相依性，而是讓權責和影響清楚到團隊能在專案卡住之前就採取行動。

框架: 辨識 → 評估 → 減緩 → 監控 → 呈報

我會從規劃階段就開始做風險管理，並一路持續到整個執行期間。風險可能來自範疇、時程、預算、技術、廠商、資源、簽核、法規遵循、使用者採用程度或外部因素。 每一項風險，我都會記錄描述、發生機率、影響、負責人、減緩計畫、應變計畫、觸發條件和目前狀態。機率和影響可以幫助判斷該把注意力放在哪裡。高機率、高影響的風險需要積極減緩，通常也要讓高階主管看得到。 減緩是降低風險發生的機率或影響；應變則是定義萬一真的發生時我們要怎麼做。舉例來說，如果廠商交付可能延誤，減緩措施可以是每週檢查點和提早做技術驗證；應變計畫則可以是暫時改用人工流程，或分階段上線。 我會定期檢視風險，在需要做決策或調度資源時往上呈報。風險管理要能實際派上用場，而不是一張沒人在看的靜態試算表。

框架: 釐清 → 影響 → 選項 → 決策 → 重設基準

我會先釐清需求為什麼改變。是法規要求、對客戶至關重要、高階主管的偏好、技術上的新發現，還是對原始範疇的誤解？強制性的變更和可有可無的改善，處理方式不一樣。 接著評估它對範疇、時程、預算、品質、測試、教育訓練、文件、相依性和上線準備度的影響，並和各交付負責人一起估算工作量與風險。 然後提出選項：納入變更並延後上線、只納入縮小版、延到上線後再做、拿掉其他項目以守住日期，或者如果它對專案目標沒有幫助就予以否決。這個決定要交給對的發起人或治理小組來做。 如果變更獲得核准，我會重設計畫基準，並更新範疇、時程、風險、測試、溝通和利害關係人的期待。重點是不要讓非正式的變更在不知不覺中把專案搞垮。

框架: 事實 → 影響 → 選項 → 建議 → 需要的決策

好的呈報要清楚、以事實為依據，而且以決策為導向。我會說明問題是什麼、造成什麼影響、已知的根本原因、有哪些選項、我的建議，以及需要什麼決策或支援。 舉例來說：「資安審查卡住了上線。如果週五前沒拿到核准，上線就要延後兩週。選項有三個：延後上線、縮減範疇把受影響的功能拿掉，或是加派一位審查人員。我建議加派審查人員，因為剩下的風險是可控的。」 呈報不是在究責，而是在專案受到傷害之前，讓對的人關注這件事。我會在主管還幫得上忙的時候就呈報，而不是等到所有選項都沒了。 呈報之後，我會記錄決策、更新專案計畫，並把變動告知受影響的利害關係人。

框架: 不確定性與變動 vs. 可預測性與控管

當需求還不確定、回饋很有價值，而且可以漸進式交付時，敏捷就很適合。它適用於軟體產品、面向使用者的工作流程，以及團隊需要邊做邊學、隨時調整的專案。 當需求穩定、法規文件要求繁重、相依性是依序發生的，或變更成本很高時，瀑布式或較偏重階段關卡的做法就比較合適。營建、硬體、法遵要求高的導入專案，以及部分企業系統遷移，可能都需要更多前期規劃。 很多實際專案採用的是混合式交付：敏捷團隊在較大的里程碑、治理機制、預算週期或法遵關卡之內反覆迭代開發。正確答案取決於風險、團隊成熟度、利害關係人的期待和專案類型。 優秀的 PM 不會主張某種方法論永遠比較好，而是選擇最適合這項工作的交付模式。

框架: 規劃、同步、檢視、改善

Sprint 規劃會議決定團隊要做什麼、為什麼做。每日站立會議幫助團隊同步進度、找出阻礙並調整執行方式。Sprint 檢視會議展示已完成的成果並蒐集回饋。Sprint 回顧會議找出下一個 Sprint 可以改善的流程。Backlog 精煉則讓接下來的工作保持清楚、隨時可以開工。 這些會議只有在能改善交付時才有意義。每日站立會議不是開給專案經理聽的進度報告會，而是團隊之間協調的工具。回顧會議提出的改善行動如果沒有真正追蹤落實，就沒什麼用。 在面試中，我會強調這些會議帶來的成果：透明度、優先順序、回饋、風險可見度和持續改善。

框架: 日期固定，範疇就要有彈性

如果日期是固定的，範疇、品質門檻、資源或風險就必須小心管理。我會先釐清截止日前一定要達成什麼成果，以及哪些功能是真正必要的。 接著我會把 Backlog 依優先順序分成「必須有」、「應該有」、「可以有」和「之後再做」，定義截止日前的最小可行範疇，並把取捨講清楚。再透過 Sprint 規劃，搭配燃起圖或燃盡圖，追蹤距離發布目標的進度。 我也會及早辨識風險：相依性、測試、簽核、技術上的未知數和團隊產能。如果團隊進度有落後的趨勢，我會盡早提出選項往上呈報：縮減範疇、增加產能、延後日期，或接受風險。 敏捷不代表日期不重要，而是團隊根據實際證據調整範疇和計畫，同時保持透明。

框架: 對象 → 訊息 → 頻率 → 管道 → 負責人

我會先找出各個利害關係人群體：發起人、指導委員會、交付團隊、業務負責人、受影響的使用者、廠商、支援團隊和高階主管。每個群體需要的資訊不同，溝通頻率也不同。 針對每個對象，我會定義他們需要知道什麼、為什麼需要、多久一次、透過什麼管道，以及由誰負責溝通。高階主管通常需要知道狀態、風險、決策和影響；交付團隊需要知道相依性、阻礙、下一步和變動；終端使用者則需要知道上線時程、教育訓練和支援資源。 溝通計畫應該包含狀態報告、指導委員會會議、工作會議、呈報管道、決策紀錄和上線公告，也要定義緊急問題該如何處理。 好的溝通能避免意外。這不代表要發更多訊息，而是在對的時間，把對的資訊傳給對的人。

框架: 釐清目標 → 找出取捨 → 運用評估標準 → 做出決定

我會先了解每位利害關係人真正的目標。意見分歧可能反映的是不同的成功指標、客戶需求、風險承受度或組織誘因。 接著把取捨攤開來講清楚。每個優先事項各會影響什麼：營收、法規遵循、客戶體驗、成本、時程、技術風險，還是策略目標？可以的話，用大家事先同意的優先順序標準來判斷，而不是憑個人偏好。 我會尋找可行的選項：分階段交付、調整先後順序、只做部分範疇、先做試行，或交由治理小組決定。如果一定得做出決策，我會帶著清楚的建議和選項往上呈報，而不是只把衝突丟上去。 做出決定之後，我會記錄理由並清楚傳達，讓團隊能繼續往前推進。專案經理的角色，是讓大家圍繞著這個決定取得共識，即使不是每個人都拿到自己的首選。

框架: RAG 燈號 → 進度 → 風險／議題 → 決策 → 下一步

有效的狀態報告應該簡潔、以決策為導向。我通常會放上整體 RAG 燈號、上次更新以來的進展、接下來的里程碑、主要風險、進行中的議題、相依性、需要做的決策，以及範疇、時程或預算的變動。 狀態一定要誠實。把重大風險藏起來卻亮綠燈，比起如實亮黃燈並附上救援計畫還要糟。我不只會說明燈號顏色，也會說明原因和對應的行動。 不同對象需要不同的細節程度。高階主管需要摘要、影響和決策；交付團隊需要工作層級的阻礙和相依性；業務端使用者需要時程和準備度相關的資訊。 我也會持續觀察趨勢。一個專案如果連續三週都是黃燈而沒有改善，即使沒有哪個單一問題看起來是災難等級，也可能需要往上呈報。

框架: 影響 → 合約 → 救援選項 → 呈報 → 預防

我會先評估影響：錯過的是哪項交付、哪些專案里程碑仰賴它、會延誤多久，以及有沒有替代方案，並判斷它是否影響到關鍵路徑。 接著檢視廠商合約、SLA、權責劃分、呈報流程，以及合約中的補救條款。不過當下最優先的是救援，而不是究責。 我會和廠商開會了解根本原因，並要求對方提出修正後的交付計畫，包含日期、負責人和風險減緩措施。在內部，我會找出可行選項：調整工作順序、採用暫時的替代方案、縮減範疇、增加內部支援、向廠商的管理層呈報，或調整時程。 我會把影響和選項告知利害關係人。問題解決之後，我會更新廠商治理機制、檢查點、驗收標準和風險監控，避免專案再次措手不及。

框架: 穩定局面 → 溝通 → 分級排查 → 決策 → 學習

我會先穩住局面：確認失敗狀況、嚴重程度、使用者受到的影響、受影響的系統，以及能不能回滾。召集合適的應變團隊，並指定唯一一位事故負責人。 接著迅速溝通。利害關係人需要知道發生了什麼事、影響範圍、目前的處置，以及下次更新的時間。不要臆測。如果客戶或使用者受到影響，視需要協調客服與對外溝通。 在保護使用者的同時，分級排查根本原因。可選的做法包括回滾、hotfix、關閉 feature flag、部分上線、人工替代方案或延後上線。要選哪一個，取決於嚴重程度、風險和復原的把握度。 復原之後，我會召開事後檢討（postmortem），找出技術、流程、測試、溝通和決策上的缺口。改善措施可能包括更完善的 go/no-go 標準、回滾計畫、冒煙測試、上線檢查清單、監控，或分階段發布。

框架: 時程、範疇、預算、品質、風險、價值

要追蹤哪些指標取決於專案類型，常見的有里程碑狀態、時程偏差、預算偏差、範疇變更、未結的風險與議題、相依性狀態、缺陷數、測試完成度、資源使用率、燃起圖或燃盡圖、速度（velocity），以及上線準備度指標。 敏捷專案的話，我可能會追蹤 Sprint 目標達成率、速度趨勢、週期時間、Backlog 健康度、阻礙因素和發布燃起圖。瀑布式或系統導入專案，我可能會追蹤里程碑完成度、關鍵路徑、階段關卡、預算和變更請求。 指標應該要能支援決策。不會帶來行動的指標，通常只是雜訊。我會把量化指標和質性判斷結合起來，因為交付風險不一定都會反映在儀表板上。 可以的話，我也會追蹤商業價值：採用率、成本降低、客戶影響、法遵準備度或營運改善。光靠交付指標，無法證明專案成功。

框架: 能見度、權責、相依性、決策

工具應該要建立共同的能見度和當責機制。以 Jira 來說，就是要有清楚的 Backlog 項目、負責人、優先順序、狀態、驗收標準、Sprint 或版本發布追蹤，以及相依性。在 MS Project 或 Smartsheet 裡，則可能是工作分解結構、日期、相依性、關鍵路徑、里程碑和資源分配。 工具要配合交付模式。軟體團隊可能偏好 Jira；企業系統導入可能需要甘特圖檢視和相依性追蹤；給高階主管的報告則可能需要另外做一個摘要儀表板。 常見的錯誤是把工具當成專案本身。計畫更新得再完美，也取代不了溝通、決策、風險管理和利害關係人之間的共識。工具是用來支援執行的，它不會自己管理專案。

框架: 目標 → 複雜度 → 你的角色 → 行動 → 成果

挑一個有一定複雜度的專案：牽涉多個團隊、時程緊迫、商業影響大、有技術相依性、有廠商參與、有法規風險，或需要大幅度的變革管理。 先說明目標，以及它為什麼重要；接著說明限制條件和你的角色。重點放在你本人做了什麼：擬定計畫、凝聚利害關係人共識、管理風險、排除阻礙、控管範疇、回報狀態，或在問題發生後把專案救回來。 最後用可量化的成果收尾：準時上線、降低成本、縮短流程時間、趕上法遵期限、提高採用率，或為客戶帶來實際影響。也要說明專案成功的關鍵，以及你從中學到什麼。 避免講一個一切順利、毫無波折的籠統故事。面試官想看到的是你如何處理真實的複雜狀況。

框架: 利害關係人 → 阻力 → 共識 → 行動 → 成果

專案經理常常需要影響那些不直屬於自己的人。挑一個你需要爭取工程、營運、法務、財務、廠商或資深利害關係人投入承諾的故事。 說明你遇到的阻力：大家是工作量過載、抱持懷疑、目標不一致，還是各自在守護不同的優先事項？接著說明你如何建立共識：釐清商業目標、說明影響、傾聽疑慮、協商取捨、爭取發起人支持，或讓權責歸屬一目了然。 最有力的回答，展現的是靠清晰與信任發揮影響力，而不是靠施壓。最後說明結果，以及你如何維繫住彼此的關係。 好的專案經理不需要倚賴職權，也能讓大家對承諾負責。

框架: 失敗 → 承擔責任 → 補救 → 教訓

挑一個真實的例子，並避免把責任推給別人。說明專案目標、哪裡出了問題，以及你在當中扮演的角色。可能是時程延誤、需求不清楚、利害關係人目標不一致、廠商延誤、低估了複雜度，或使用者採用率不佳。 接著說明問題浮現之後你做了什麼：往上呈報、重新設定範疇、重設時程基準、加強控管、改善溝通、調整流程，或協助把交付救回來。 最重要的是學到的教訓。你現在會提早做哪些事？例如更扎實的風險規劃、更明確的決策權責、更好的相依性追蹤、更早取得利害關係人共識，或更務實的估算。 面試官重視自我覺察和成熟度。好的回答能展現你的當責態度，以及判斷力的成長。