前言

工作中真正讓人累的，並不只是主管嚴厲。

就算嚴厲，只要判斷明確、有優先順序、有目標、責任範圍清楚，人還是能往前做的。

最累的，是主管這樣做事：

• 不做決定
• 不分享資訊
• 不把要求整理成明確的需求
• 口頭含糊帶過
• 事後翻臉變卦
• 把局部的小毛病放大成整體的責任
• 最後把問題歸咎到部屬的個性或特質上

在這樣的主管底下，愈擅長需求釐清（把要做什麼、為什麼做、誰來決定、在什麼條件下做講清楚）的人，愈痛苦。

因為我們為了把事情推進下去，會去看目的、現況、原因、相關人員、執行條件、風險，以及拍板的人。
而主管只看表面印象和一點點瑕疵，然後開始挑毛病。

結果就是，雙方講話不在同一個層次上。

我們在談業務怎麼設計。
主管在談看起來怎麼樣、給人什麼印象。
我們解決的是主要問題。
主管只撿一些次要的改善點來說。

這種落差愈積愈多，主管就不再是支持者，而成了單純的雜訊。

---

1. 對主管的期待，只要「判斷、優先順序、扛責任」就夠了

有些人自己就能把工作往前推進相當一段。

例如能做到下面這些：

• 能釐清目的
• 能掌握現況
• 能找出瓶頸
• 能把方案分成 A 案、B 案、C 案
• 能提前預判風險
• 能和其他部門溝通
• 能把相關人員拉進來
• 能留下紀錄
• 眼看要出事就能喊停
• 需要時能在短時間內做出企劃書

對這樣的人來說，對主管的期待其實很有限。

原本，希望主管做的只有這些：

• 做判斷
• 定優先順序
• 正式出面和其他部門打通
• 扛起責任
• 負責向上說明，替底下擋一擋
• 不要多餘地事後加碼

反過來說，不做這些的主管，就相當礙事。

只會說「你去推」，卻不做判斷。
只會說「你自己想想」，卻不定優先順序。
只會說「你去跟其他部門談」，卻不給正式的支持。
只會問「現在怎麼樣了？」，卻不扛責任。
最後還追問「你為什麼要做？」「你為什麼沒做？」。

這不是在替團隊增加價值。
反而是在替工作添加雜訊。

---

2. 「能和上面的人說上話」和「能把需求定義清楚」是兩種不同的能力

主管之中，有人確實擅長和上面的人打交道。

和高階主管聊。
去開會。
聽取意見。
帶回一些像是方針的東西。
還能像模像樣地說一句「我們會推動的」。

光看這些，外人會覺得很有主管的樣子。

但問題出在後面。

把從上面聽來的模糊說法，轉換成底下的人能動手的需求，他做得到嗎？

照理說，會後應該整理成這樣：

• 決定了什麼
• 還有什麼沒決定
• 誰來拍板
• 誰來負責實際執行
• 要向誰分享什麼
• 什麼時候之前做什麼
• 推進的條件是什麼
• 喊停的條件是什麼
• 風險是什麼
• 是否已經到了可以交給底下的狀態

整理到這一步，執行的人才動得了。

可是做不到這種轉換的主管，會把上面的一團模糊原封不動地丟給底下。

「好像從 7 月開始要動了。」
「你跟 S 談談，把事情推進一下。」
「這個月內想辦法安排個會議。」
「總之先做起來。」
「現在怎麼樣了？」
「怎麼還沒進展？」

這只是有出席會議，並沒有做需求釐清。

能和上面的人說上話，與把工作設計成底下的人能動起來，是兩種不同的能力。

---

3. 擅長需求釐清的人，不妨把主管當成「核准關卡」

擅長需求釐清的人，如果把主管當作商量對象，往往會很耗神。

因為一商量，不是模糊的話愈來愈多，就是被淺淺的幾句指點帶偏、離開主要問題，要不然就是事後完成標準又變了。

這種情況下，把主管當成核准關卡，而不是商量對象，會比較好。

例如這樣說：

這件事我打算照 A 案推進。擔心的點是 B 和 C，都已經處理好了。如果沒有問題，就照 A 來。

或者這樣說：

有 A 案、B 案、C 案。考量影響範圍和工時，我認為 A 案比較合適。請您決定採用哪一個。

或者這樣說：

這件事要在全公司範圍推行，需要向其他部門發出正式的協助請求。如果要推進，請您決定配合的部門、窗口和優先順序。

這樣一來，就能縮小主管需要思考的範圍。

不是讓主管從零開始想。
而是讓主管做選擇。
讓主管只負責拍板。
讓主管把責任範圍說清楚。

擅長需求釐清的人，自己先把事情整理好，再向主管要「核准」「選擇」「正式委託」和「責任」，這樣比較好。

---

4. 就算解決了主要問題，也會因為次要的改善點被全盤否定

淺層主管最讓人頭痛的是：主要問題明明已經解決了，他卻只盯著次要的瑕疵，把整件事都否定掉。

舉例來說，寄給本人的文件被退回了 3 次。

為了解決「送不到」的問題，我們建立了這樣一套做法：

• 明確標示這是給本人的
• 印出「培訓學員本人收」
• 同時印上學員的部門名稱和姓名
• 用箭頭標出該看哪裡
• 註明如果因收不到而困擾，請寫明原因退回人資部門
• 註明如果一切順利，這張紙可以直接丟掉
• 附在正式文件上一起寄出

結果，正式文件送到了本人手上。

也就是說，主要問題「送不到」已經解決了。

可是淺層的審閱會變成這樣：

「附頁上收件人的手寫字太難看了。」
「這是客訴吧？」
「會不會太單方面了？」
「去跟本人談談，搞清楚真正的原因。」
「那真正的原因到底是什麼？不知道。」

這樣的審閱相當薄弱。

因為他根本沒有看該看的主要問題。

該看的是下面這些：

• 被退回 3 次的原因是什麼
• 有沒有建立起能送到本人手上的路徑
• 本人遇到困難時有沒有回覆的辦法
• 正式文件有沒有送達
• 以後能不能避免同樣的送不到

附頁手寫字不好認，頂多是下次的改善點。

它不能成為否定「主要問題已經解決」的理由。

---

5. 當「太單方面」的指責說偏了

對於以書面發出的說明，有時會被說「太單方面」。

可是，如果那張紙上寫著下面這些，就不能算單方面：

• 這是給本人的
• 文件一直沒送到，讓大家很困擾
• 如果有瓶頸或特殊情況，請告知
• 如果沒有問題，可以丟掉
• 提供了回覆的管道

這不是單方面的命令。
而是請對方協助確認沒送到的原因。

甚至比去找人當面談，給對方的負擔更小。

一說「你們去談一談」，乍聽之下好像很周到。

但落到實際流程裡是這樣：

1. 找出是誰發的文件
2. 找出那個人在哪個部門
3. 去那個部門談
4. 向本人或相關人確認狀況
5. 人資這邊把聽到的內容整理出來
6. 最後還是要留紀錄

工時很高。
而且是口頭的，之後還可能變成「你說過」「我沒說過」的扯皮。

相反地，如果做成本人看了這張紙、需要的話就回覆的機制，那麼只要本人確認就能了結。
紀錄也留下了。
也不用到處找相關人員。

周到不一定等於當面交談。
讓對方不迷惘、花最少的功夫、而且留有紀錄，同樣是一種周到。

---

6. 要說「查清真正的原因」，就得看這套設計是不是更接近真因

「要查清真正的原因」這句話本身沒錯。

但光是話說得對，沒有意義。

要查真因，有該看的東西：

• 過去 3 次的收件地址
• 收件人姓名的寫法
• 寄送方式
• 退回理由
• 本人那邊的簽收狀況
• 地址、部門、公司內部郵務路線
• 是誰在哪裡卡住的
• 在哪個環節被退回的

這些都不看，只說「可能是字太難看」「去跟本人談談」，那不叫原因分析。

而且這次正式文件已經送到了。
那麼至少這次的對策是改善了送達率的。

這裡該看的，是把主要問題的解決和遺留問題區分開來。

• 主要問題：給本人的文件送不到
• 對策：明確標示是給本人的，並附上回覆管道後寄出
• 結果：正式文件送達
• 遺留問題：附頁的手寫部分，下次起改成列印比較好

這樣整理就行了。

不這麼做，只說「字難看」「像客訴」「太單方面」，只停留在表面，層次太淺。

---

7. 「手寫字難看」是下次的改善點，不是主要問題

說手寫字不好認，並非完全沒有意義。

下次起改成列印就行了。
做成固定格式就行了。
收件人也全部用電腦打字就行了。

但那只是次要的改善點。

這次的主要目的，是解決送不到的問題。

這個主要目的已經達成。

所以，應該這樣說：

這次因為寄給本人的文件多次被退回，所以我們用紙本告知了這是給本人的，並請對方如有送不到的原因或瓶頸，回覆給人資部門。結果正式文件已送到本人手上，最初的送不到問題已解決。附頁上的手寫部分，下次起改為列印。

這樣整理，主要問題和改善點就分開了。

淺層主管做不到這種區分。
所以他們會拿次要的改善點，去否定連主要成果。

---

8. 交了企劃書，不會做決定的主管也會從頭開會

企劃書也會發生同樣的事。

看部門的課題，思考瓶頸在哪裡。
例如先發現需要確保人力或招募。
排出優先順序。
用 30 分鐘左右搭出骨架。
用一天左右寫成企劃書。
提交給主管。

照理，接下來該做的是下面幾種之一：

• 採用
• 修改
• 暫緩
• 只試行一部分
• 決定由誰來推進
• 決定拉哪些部門進來
• 決定什麼時候之前做什麼

可是不會做決定的主管，用不好企劃書。

企劃書傳過去，只是已讀不回。
不做決定。
不定團隊。
後來別人也開始說類似的話。
於是變成「大家一起從頭想想吧」。

這相當浪費。

草案已經有了。
現在不是從頭想的階段。
而是決定已有的方案要採用還是修改、由誰來做的階段。

這時需要的不是從零開始的會議，而是決策會議。

例如可以這樣說：

企劃案已經提交，所以這次不是從零開始提點子的會，而是想用來決定是否實施、優先順序和各自負責的範圍。

這才是本來的推進方式。

---

9. 想得快的人，他的方案容易被看輕

能在短時間內做出企劃書的人，有時會吃虧。

30 分鐘搭出骨架。
一天做成資料。
把課題、原因、優先順序、措施方案都整理好。

這本來價值很高。

可是如果主管沒有辨識這種價值的眼光，就只會把它當成「不知道誰寄來的一個方案」。

看起來沒花多少時間。
所以被看輕。

但其實，是因為平常就在盯著課題、做了結構化，腦子裡早就整理過了，所以才快。

不是因為交得快才淺。
而是因為早就想過了，才快。

理解不了這一點的主管，事後會讓大家把同樣的話從頭再說一遍。
然後花很長的時間，重新發現一個和已經提交的方案差不多的結論。

對一個組織來說，這非常浪費。

---

10. 「事後補課會議」會占用已經想過的人的時間

事後補課會議，指的是別人已經整理好並提交的內容，事後再由一群人從頭重新想一遍的會議。

當然，多人討論本身並沒有錯。

但既然已經有了草案，會議的目的就應該改變。

糟糕的會議是這樣的：

「先大家從頭想想吧。」
「課題是什麼呢？」
「問題在哪裡呢？」
「有什麼方案嗎？」

好的會議是這樣的：

「先確認已經提出的方案。」
「哪些論點採用？」
「哪些論點需要修改？」
「哪些論點還需要進一步確認？」
「誰在什麼時候之前推進？」

後者的推進效率高得多。

既然已經有人想過了，直接用他的草案就好。
沒必要從頭再想。

主管做不到這一點，愈會思考的人就愈疲憊。

「這點我早就想過了。」
「資料也交了。」
「都整理到只剩下做決定的狀態了。」
「結果還要從零開會？」

就會變成這樣。

---

11. 擅長需求釐清的人需要的，不是善解人意的主管，而是不添亂的主管

對擅長需求釐清的人來說，理想的主管不必特別優秀。

最起碼，別添亂就行。

例如，這樣的主管就很好配合：

「照 A 案推進吧。」
「其他部門我來協調。」
「這裡有風險，加一句話。」
「需要判斷時再拿來。」
「這件事這次先擱置。」
「這是全公司推行的事，先把正式的組織編制定下來再推進。」

光是這樣，就已經幫了很大的忙。

相反地，下面這樣的主管就是在添亂：

「為什麼？」
「打算怎麼辦？」
「計畫呢？」
「不過明天就要。」
「這個也明天要。」
「這是客訴吧？」
「字很難看吧？」
「真正原因我可不知道。」
「這就是你的特質問題吧。」

這樣並沒有推進工作。
只是把工作攪渾了。

擅長需求釐清的人想要的，不是過度的指導。
而是判斷、責任，以及不添亂的態度。

---

12. 適不適合當主管，看的不是頭銜，而是「轉換能力」

主管需要的，不只是能和上面的人說話。

還需要把上面模糊的方針，轉換成底下的人能動手的需求。

具體來說，是下面這些能力：

• 把目的講清楚
• 把未決事項找出來
• 定好誰來拍板
• 定好誰來負責
• 定好優先順序
• 定好期限
• 定好捨棄什麼
• 向其他部門發出正式的委託
• 讓執行的人處於可以動手的狀態
• 留下紀錄，以免日後被推翻

做不到這種轉換的主管，與其說是主管，不如說是製造「未定義」的機器。

另一方面，沒有頭銜卻能做這種轉換的人，在實際工作中非常強。

「A、B、C 裡，您看照哪一個推進？」
「這個擔心已經考慮進去了。」
「照這個條件的話，就走 A 案。」
「需要通知的範圍是這些。」
「只需要您做決定。」
「實際作業我們這邊推進。」

能說出這些話的人，相當具備主管、專案經理的素質。

不是不適合當主管。
只是不適合那種靠含糊的權威來驅動人的老派管理。

對於靠需求釐清、達成共識、風險管理、協調相關人員來推進的專案經理型管理，反而很可能很適合。

---

13. 可以拿到檯面上用的說法

從情緒上說，難免會覺得「礙事」「膚淺」「真蠢」。

但在實際工作中，最好別原樣說出來。

在檯面上，可以這樣換個說法。

把主要問題和次要改善點分開

本次的主要目的是把文件送到本人手上，這一點已經完成，送不到的問題已解決。附頁的填寫方式，作為下次起的改善點，會改為列印。

已經提交過企劃書的情況

這件事我已經提交了企劃書。下次希望不要從零開始提點子，而是請您對是否實施、優先順序和負責範圍做出判斷。

需要主管做決定的情況

有 A 案、B 案、C 案。考量影響範圍和工時，我認為 A 案比較合適。您決定之後，我就照這個方向推進。

事後冒出追加要求的情況

依最初指示的範圍，我已經做到了○○。如果還需要做到△△，請明確列入工作範圍，我就繼續推進。

被說「太單方面」的情況

這並不是單方面的要求，而是作為一份確認請求發出的，請對方在有送不到的原因或瓶頸時回覆我們。

被說「去談一談」的情況

這件事本人看一下就能了結，而且紙本上也設了回覆管道，所以先以紙本確認的方式處理了。如果還需要口頭確認，我會先明確對象和確認事項，再去處理。

---

14. 結論：不要讓膚淺的指摘毀掉你的主要成果

工作中重要的是，把主要問題和次要改善點分開。

主要問題解決了，那就是成果。
有次要的瑕疵，那就是下次的改善點。

這兩件事不能混為一談。

如果問題是給本人的文件送不到，主要問題就是「能不能送到」。
正式文件送到了，主要問題就解決了。
附頁手寫字難認，下次改成列印就好。

如果是針對部門課題的企劃，主要問題就是「瓶頸是什麼、先從哪裡下手」。
企劃書既然已經提交，接下來就不是從頭想，而是到了做決定的階段。

對擅長需求釐清的人來說，淺層主管的指摘相當礙事。

但沒有必要被這種膚淺的指摘牽著走，連自己的成果都一併否定。

該看的是目的、原因、優先順序、執行條件和結果。

表面的瑕疵，改善就行了。
解決了主要問題這個事實，不必抹去。

---

實用範本集

1. 文件送不到的處理紀錄

這次因為寄給本人的文件多次被退回，所以我們用紙本告知了這是給本人的，並請對方如有送不到的原因或瓶頸，回覆給人資部門。
結果正式文件已送到本人手上，最初的送不到問題已解決。
附頁上的手寫部分，下次起改為列印。

2. 區分主要問題和改善點

本次的主要目的○○已經完成。
另一方面，△△作為下次起的改善點來處理。

3. 希望對方用上已有企劃書時

企劃案已經提交，所以這次希望不是從零開始提點子，而是請您對是否實施、優先順序和負責範圍做出判斷。

4. 請主管在 A/B/C 中做決定時

目前可以考慮 A 案、B 案、C 案。
考量影響範圍和工時，我認為 A 案比較合適。
如果沒有問題，就照 A 案推進。

5. 防止主管事後加碼時

依最初指示的範圍，我已經做到了○○。
如果還需要做到△△，請明確列入工作範圍，我就繼續推進。

6. 被要求直接去談時

這件事本人看一下就能了結，而且紙本上也設了回覆管道，所以先以紙本確認的方式處理了。
如果還需要口頭確認，請告訴我對象和確認事項。

---

相關文章候選

• 無權限責任陷阱：沒有權限卻只揹成果責任的職場
• 別把未定義的工作攬在身上：釐清決策者和負責範圍的方法
• 自我申報制度崩壞的時候：自己訂目標的陷阱
• 防止事後評價的電子郵件範本
• 企劃書被已讀不回時的自保紀錄
• 主管成為阻礙的瞬間：審閱變成了挑毛病的狀態
• 人資工作中未定義業務的可怕之處
• 為什麼不能把全公司措施變成個人目標

---

發布時的注意事項

這篇文章包含接近真實經歷的內容，發布時一定要做匿名化處理。

• 不寫公司名稱
• 不寫個人姓名
• 模糊部門名稱
• 把「猴子」之類的內部說法替換成「主管」「管理者」
• 把文件種類和業務內容一般化
• 刪掉具體日期
• 求職期間作為不公開的草稿處理
• 如果發布，要從「業務設計」「需求釐清」「主管的角色」這個角度來寫，而不是發洩憤怒

---

最後

擅長需求釐清的人，最好不要因為膚淺的指摘而看不清自己的成果。

解決了主要問題，那就是成果。
有次要的改善點，下次改掉就好。

主管的職責，不是撿表面的瑕疵去逼問部屬。
而是定目的、定優先順序、扛責任，並營造出執行的人能動起來的狀態。

做不到這些的主管，不是支持者，而是雜訊。

而且，不能讓雜訊抹掉你的主要成果。