跨部门会议上，最怕遇到别部门报告到一半，直接把未经讨论且无法执行的需求甩过来，甚至在没打招呼的情况下擅自将你或整个部门列为执行端！本文剖析职场常见的「跨部门突袭」恐怖故事，并提供3个在会议桌上不硬槓也能优雅划清边界、甩开空头支票的回应技巧。
文／《104职场力》
本文导览
- 为什么「先斩后奏」的跨部门合作通常是灾难开端？
- 1.瘫痪第一线人力与系统
- 2.资源排挤，重要专案被迫延宕
- 3.辛苦支援，出事可能还背锅
- 甩开突袭需求！3招优雅拆弹、划清权责边界
- 1.先说明「事前没对过」，再把现场真实状况拉上檯面
- 2.别急着回答「做或不做」，抛出方案与代价让大家选
- 3.别一口气冲！用「先评估、小範围试做」争取缓冲期
跨部门会议上，隔壁部门简报到第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 家门市试跑两天，测试第一线动线跟结帐时间。等实测数据过关了，我们再来讨论全台推广的时程。」
事先沟通与评估本来就是跨部门合作很重要的流程，但若真的不幸被突袭，不必急着当场翻脸，更不必当默默吞下的苦主，看完文章、掌握好这几个心法，就算会议上被硬塞需求也能从容应对，当一个真正能保护自己跟团队的聪明人！
- 「你觉得方案怎么样？」真正想说什么？4类关键词听懂弦外之音
- 「不配合我就CC你老板！」别把信件副本当武器！3个技巧让跨部门沟通更顺利