根本沒事先討論！跨部門會議上被「突襲硬塞需求」如何不硬槓劃清邊界？
跨部門會議上，最怕遇到別部門報告到一半，直接把未經討論且無法執行的需求甩過來，甚至在沒打招呼的情況下擅自將你或整個部門列為執行端！本文剖析職場常見的「跨部門突襲」恐怖故事，並提供3個在會議桌上不硬槓也能優雅劃清邊界、甩開空頭支票的回應技巧。
文／《104職場力》
本文導覽
跨部門會議上，隔壁部門簡報到第15頁時，投影片上突然出現一行醒目的字：「主辦執行單位：OO部門／OOO（你的團隊或你的名字）」。
你坐在台下腦袋當機……這件事完全沒人來找你討論過！裡面的需求以現有人力和系統根本也做不到（或超出工作範圍），但對方卻在大老闆點頭沒發表反對意見的情況下順理成章繼續往下報告……
這種「沒打招呼就被列為執行端／協助單位」、甚至被硬塞「無法落地的需求」，絕對是職場上最讓人倒抽一口氣的跨部門恐怖突襲。
為什麼「先斬後奏」的跨部門合作通常是災難開端？
別部門之所以會在會議上發動「突襲」，要嘛無心的認知落差，誤以為這只是小功能，不曉得需動用特定人力與系統，也可能單純不懂人情世故，沒做好職場溝通，最怕的是刻意政治操作，想藉由會議現場的群眾及主管壓力，當場逼你吞下需求。
不管對方的出發點如何，這種未經事前評估就「先斬後奏」的合作方式，落到第一線團隊身上通常都會演變成以下3種連鎖災難：
1.癱瘓第一線人力與系統
動動嘴很容易，但執行端的血淚無人知！在舊系統架構不相容、原有的作業流程被打亂、還要處理新爆發的問題時……最後都得靠現場人員天天加班、人工手動貼資料除錯，用血汗去補對方當初在會議上高談的理想漏洞。
2.資源排擠，重要專案被迫延宕
團隊的產能與時間是有限的，突如其來被塞進一個未經排程的需求，勢必會擠壓到團隊原本正在執行的核心任務，結果不只突襲的新需求做得很勉強，原本承諾主管或客戶的既有專案也跟著全面延期，引發組織內的連鎖大卡關。
3.辛苦支援，出事可能還背鍋
未經完整評估的需求，落地時出包機率超級高！一旦後續時程延誤、系統崩潰或客訴暴增，若當初提案的人還把責任甩出來：「我們的企劃很完整，是配合團隊執行不力、進度落後」，那還真的是有苦難言。
想避免後續無窮無盡的麻煩與內耗，最好的防線就是在會議現場即時拉住煞車，這跟配合度高不高無關，看到坑在前方，本就該學習如何協商、為自己或組織爭取轉圜空間。
甩開突襲需求！3招優雅拆彈、劃清權責邊界
眼看那未經討論的需求就要砸到自己頭上，當場開嗆會被扣上「不上進、不配合」的帽子，默默吞下最後又是自己團隊背鍋，在會議桌上，你可以試試以下3個實戰技巧，把責任與風險搬回檯面上重新研議。
1.先說明「事前沒對過」，再把現場真實狀況拉上檯面
就算是事實也不要直接情緒化反駁「這根本做不到」，先溫和澄清「這件事我們之前還沒對過細節，現場的狀況比較複雜，剛好可以趁這個機會評估到底能不能配合 」，接著把現場實務、客觀限制、目前專案輕重緩急通通列出來，直接把問題攤開，讓雙方跟老闆一起面對、決策。
- 範例一（人力與作業極限）：「先跟大家澄清，這部分是我們團隊第一次看到此需求，以客服第一線現況來看，每人每天已滿載處理60件單，若新增此確認步驟，處理時間會翻倍，在未增加人力的前提下，預計有30%的客戶會面臨等候逾時，這部分我們該如何評估？」
- 範例二（技術與系統限制）：「這項功能牽涉到舊系統架構，我們團隊事先並未收到相關範疇進行排程評估，若以目前技術現場來看，API每天有處理上限，若要達到簡報中的即時連線，高峰期系統會有卡死風險，這部分提案團隊有建議的系統對接方案嗎？」
- 範例三（合規與審查時程）：「因為這項需求事前沒有送交我們做合規評估，依據資安與法務規範，使用者資料蒐集需OO天的審查期，若活動真要如期上線，目前的時程落差我們該如何調整？」
2.別急著回答「做或不做」，拋出方案與代價讓大家選
不要當場承諾要或不要接下，二選一就中了對方圈套，建議清楚提出執行所需的真實成本與風險，請主管與提案團隊做選擇，把決策的壓力還給對方。
- 範例一（排程vs.人力增援）：「若評估決定要執行這個新增的需求，現場有兩個執行路徑：方案A是維持現有人力，但先上線核心功能A，此新增項目延後；方案B是功能全上，但需要額外增加人力預算支援開發與除錯，請問主管與提案團隊傾向走哪一個方案？」
- 範例二（時程vs.預算選擇）：「如果要配合在下個月上線這個剛提出的需求，我們有兩種選擇：方案A是由提案團隊撥出預算找外部廠商趕工；方案B是時程順延1個月，由我們團隊進行正常開發評估。請問大家傾向怎麼拿捏？」
- 範例三（優先順序替換）：「這個新增需求若要啟動，會需要我們團隊投入 80% 的資源。目前我們手上正執行老闆交辦的 A 專案，若要插入這個新任務，我們是先把 A 專案暫停，還是將這個需求排在 A 專案完成之後？」
3.別一口氣衝！用「先評估、小範圍試做」爭取緩衝期
就算現場討論看似有了初步共識，也千萬不要在會議衝動承諾「沒問題，我們全面執行」！最安全的作法是採「正式評估」和「分階段測試」，既能展現積極配合的態度，也能幫團隊爭取到時間與空間，最後用客觀數據跟報告來劃清責任。
- 範例一（拉出評估緩衝期）：「因為這項需求我們今天也是第一次聽到，為了確保不會影響現有系統的穩定度，我們沒辦法在現場直接一口答應，建議提案團隊會後先補規格書給我們，我們會在5個工作天內做完可行性評估跟時程試算，再跟主管回報做不做得到。」
- 範例二（核心MVP分階段試做）：「未經測試直接全面上線風險太高，建議我們先切出最核心的功能做MVP，比如找10%的用戶試做兩週，等看過技術數據跟真實反應後，再來評估要不要正式排進團隊的開發時程。」
- 範例三（單一場域實測）：「為了避免新流程一上線就讓現場手忙腳亂，建議正式執行前，先選 1 家門市試跑兩天，測試第一線動線跟結帳時間。等實測數據過關了，我們再來討論全台推廣的時程。」
事先溝通與評估本來就是跨部門合作很重要的流程，但若真的不幸被突襲，不必急著當場翻臉，更不必當默默吞下的苦主，看完文章、掌握好這幾個心法，就算會議上被硬塞需求也能從容應對，當一個真正能保護自己跟團隊的聰明人！
延伸閱讀：
