結論先講
向上管理不是拍馬屁，是讓你的主管和利害關係人做出正確決策的能力。你需要學會：用對方聽得懂的語言說話、在壞消息惡化之前傳達、以及用「不是拒絕而是引導」的方式處理不合理的要求。這篇全部用實際場景來講。
進度報告：老闆到底想知道什麼
老闆不想知道的
- 你用了什麼技術架構
- 某個 API 的 response time 是 200ms
- Code review 還有三個 PR 在等
- 你這週加班了多少
老闆想知道的
- 現在進度到哪了？（vs 計畫）
- 有沒有什麼風險？（會不會炸）
- 需不需要我幫忙？（要不要介入）
- 什麼時候能交？（下游在等）
進度報告模板
專案：電商結帳功能
報告日期：2026-03-15
整體狀態：🟡 有風險
本週進度：
- ✅ 購物車摘要頁面完成
- ✅ 配送地址表單完成
- 🔄 信用卡付款串接中（預計下週三完成）
- ⏳ 超商取貨（尚未開始）
風險：
- 金流測試環境本週不穩定，可能影響信用卡功能測試
→ 已聯繫綠界客服，等回覆中
下週目標：
- 完成信用卡付款端到端測試
- 開始超商取貨功能
需要協助：
- 需要 PM 確認發票格式（電子發票 vs 紙本）
紅黃綠燈用法
| 狀態 | 定義 | 行動 |
|---|---|---|
| 🟢 綠燈 | 按計畫進行 | 不需要特別關注 |
| 🟡 黃燈 | 有風險但可控 | 需要關注，可能需要調整 |
| 🔴 紅燈 | 嚴重問題，需要幫助 | 需要立即介入 |
重要原則：寧可早亮黃燈，不要突然亮紅燈。老闆最討厭的不是問題本身，是「驚喜」。
壞消息怎麼說
Sandwich Method 不太行
「先說好消息，再說壞消息，最後說好消息」——這個方法的問題是：老闆會覺得你在粉飾太平，而且壞消息被稀釋了。
Context-Impact-Plan（CIP）方法
更有效的方式是直接面對，但提供解決方案：
- Context：發生了什麼事
- Impact：對專案的影響是什麼
- Plan：你打算怎麼處理
範例：延遲通知
不好的說法：
「那個功能可能要再多一點時間。」
好的說法：
Context：「信用卡串接的過程中，我們發現綠界的退款 API 有未記載的行為，需要額外處理。」
Impact：「這會讓信用卡功能延遲 3 天，原定 3/20 完成會推到 3/23。整體上線時間從 4/1 推到 4/4。」
Plan：「我們有兩個選項： (A) 接受延遲，完整處理退款流程。 (B) 先上線不含退款功能，退款改人工處理，節省 3 天。需要你決定。」
壞消息的時機
| 何時說 | 為什麼 |
|---|---|
| 發現問題的當天 | 越早說，調整空間越大 |
| 在你有初步解法之後 | 不要只帶問題，帶選項 |
| 在問題惡化之前 | 黃燈就說，不要等紅燈 |
「這要多久？」的正確回答
這是技術人最常遇到也最痛苦的問題。
錯誤回答
「大概兩週吧。」
為什麼錯？因為對方聽到的是「兩週一定做完」，你的意思是「我猜大概兩週但可能更久」。
正確回答模板
「根據目前的資訊，我的估算是 2-3 週。 這個範圍取決於：
- 設計稿是否在本週五前提供（如果延遲，會往後推）
- 金流測試環境是否穩定（如果不穩定，可能多 2-3 天）
我會在下週一給你更精確的估算。」
進階回答
當對方追問「到底是兩週還是三週」：
「如果一切順利，兩週。但根據我們團隊的歷史經驗，類似功能通常會有 30% 的額外工時用在我們現在看不到的問題上。所以我建議用三週來規劃，如果提前完成，我們可以提前開始下一個功能。」
不要承諾的時候
| 場景 | 回答 |
|---|---|
| 需求不清楚 | 「這取決於 X 和 Y 的定義，我需要先確認再估算」 |
| 技術未知 | 「我需要先花 2 天做技術調研（spike）再回覆」 |
| 資訊不足 | 「你能告訴我 [具體問題] 嗎？有了這個資訊我就能估了」 |
說不的藝術：引導而不是拒絕
場景 1：不合理的時程
老闆：「這個功能下週要上線。」
不要說：「不可能。」
要說：
「下週上線的話，我們可以交付核心流程（Happy Path），但不包含錯誤處理和 edge cases。完整版需要三週。你覺得先上核心流程、後續再補完整版可以嗎？」
場景 2：需求不在計畫內
PM：「客戶說要加一個報表功能。」
不要說：「我們沒排這個。」
要說：
「收到。這個報表功能大概是 5 SP 的工作量。如果要放進這個 Sprint，我們需要拿掉哪個功能來交換？或者我們放進下個 Sprint 的 backlog 前段？」
場景 3：技術上可行但不該做的
PM：「我們直接把使用者密碼存在 cookie 裡，這樣就不用做 session management 了。」
不要說：「你不懂技術不要亂提。」
要說：
「我理解你想簡化登入流程。但密碼存 cookie 有嚴重的安全風險——如果使用者的瀏覽器被入侵，密碼會直接外洩。我們可以用 JWT token 達到同樣的效果（不用重新登入），而且安全。你覺得這個替代方案可以嗎？」
引導框架
1. 肯定對方的需求（不是否定）
2. 解釋限制或風險（用對方聽得懂的語言）
3. 提供替代方案（至少兩個）
4. 讓對方做決定
技術債跟非技術人怎麼解釋
比喻法
「技術債就像信用卡債。你可以先刷卡（快速交付），但之後要還（重構）。如果一直不還，利息會越來越高（開發速度越來越慢）。現在我們的『利息』已經高到每個功能要多花 30% 的時間了。」
數字法
「去年 Q1，加一個新的付款方式需要 3 天。現在需要 8 天，因為程式碼的複雜度增加了。如果我們花 2 週清理，可以把時間降回 4 天。今年計畫加 5 種付款方式，這 2 週的投資可以省下 20 天。」
風險法
「目前有 12 個第三方套件有已知的安全漏洞。如果被攻擊，我們可能面臨使用者資料外洩和罰款。更新這些套件需要 1 週。」
不要用的解釋
- 「程式碼很髒」（什麼叫髒？）
- 「需要重構」（為什麼？多少錢？）
- 「架構不好」（所以呢？）
什麼時候升級，什麼時候自己處理
升級（Escalate）的時機
| 情境 | 為什麼要升級 |
|---|---|
| 問題需要跨團隊協調 | 你沒有權限指揮其他團隊 |
| 時程有風險，需要減 scope | 你沒有權限砍功能 |
| 技術決策會影響商業策略 | 決策層級不在你 |
| 團隊成員有衝突 | 需要主管介入 |
| 安全事件 | 必須立即通報 |
自己處理的情境
| 情境 | 為什麼不用升級 |
|---|---|
| 內部技術問題（bug、效能） | 團隊自己能解決 |
| 小範圍的 scope 調整 | PO 同意就好 |
| 團隊流程改善 | Retro 裡處理 |
| 個人工作分配 | 團隊內部協調 |
升級的正確方式
不要只帶問題，帶選項：
問題：金流串接延遲 3 天。
選項 A：接受延遲，上線推遲到 4/4。 選項 B：先上線不含退款，4/1 如期。 選項 C：加一個人支援，4/2 上線（需要從其他專案借人）。
我的建議：選項 B，因為退款量目前很少，人工處理幾天沒問題。
會議管理
三個原則
- 有 agenda 才開會：沒有 agenda 的會議 = 浪費時間
- Timebox：設定每個議題的時間限制
- 有 action items 才結束：每個決定要有負責人和期限
會議記錄模板
會議：Sprint 12 Review
日期：2026-03-15
參與者：[名單]
決定：
1. 結帳功能 MVP 範圍確認，不含退款（PO 同意）
2. 上線日期維持 4/1
Action Items：
- [ ] 小明：完成金流整合測試（3/18 前）
- [ ] PM：確認發票格式（3/17 前）
- [ ] 設計師：提供超商取貨的 UI（3/19 前）
下次會議：3/22 Sprint Planning
怎麼拒絕不必要的會議
「謝謝邀請。看了 agenda 之後，我覺得我在這個會議裡的貢獻有限。如果有需要我 input 的部分，可以會後傳 Slack 給我嗎？」
如果沒有 agenda：
「可以先分享 agenda 嗎？我想確認一下我能貢獻什麼，這樣會議效率會比較好。」
溝通頻率建議
| 對象 | 頻率 | 方式 | 內容 |
|---|---|---|---|
| 直屬主管 | 每週 | 1-on-1 或 email | 進度、風險、需要的幫助 |
| 利害關係人 | 每 Sprint | 書面報告 | 進度 vs 計畫、風險、下一步 |
| 跨團隊夥伴 | 需要時 | Slack / 短會議 | 依賴確認、技術討論 |
| CEO / 高層 | 每月 | 摘要（< 5 分鐘閱讀） | 大方向、重大風險、成果 |
給不同層級的溝通風格
| 層級 | 細節度 | 語言 | 時間 |
|---|---|---|---|
| 工程師同事 | 很高 | 技術術語 OK | 不限 |
| Tech Lead / EM | 中 | 技術 + 影響 | 15 分鐘 |
| PM / PO | 低 | 商業語言 | 5 分鐘 |
| VP / CEO | 很低 | 數字 + 風險 | 2 分鐘 |
FAQ
Q1：老闆不懂技術一直做錯誤決策怎麼辦？
先假設他不是傻——他可能有你不知道的商業背景。你的工作是提供技術觀點和風險分析，讓他做更好的決策。用「如果…那麼…」的格式：「如果我們跳過測試，上線後出問題的機率大約 30%，修復成本是現在做測試的 3 倍。」
Q2：如何跟固執的 PM 相處？
找到共同目標。你們都想要產品成功、使用者滿意。分歧通常在「怎麼做到」。試著用數據而不是意見來討論——「上個 Sprint 中途加了 5 張 ticket，結果 velocity 降了 30%」比「你不應該一直插單」有說服力得多。
Q3：英文不好，怎麼跟外國同事溝通？
用書面優先。email 和 Slack 可以慢慢想、慢慢寫，比即時口語壓力小很多。善用模板和框架（本篇的所有模板都可以翻成英文用）。技術溝通不需要華麗的英文，需要的是結構清楚。
Q4：遠端工作怎麼做向上管理？
比實體辦公更需要主動溝通。設定固定的 1-on-1 節奏（每週 30 分鐘），用書面進度報告取代「走過去問一下」。Over-communicate 比 under-communicate 好——寧可多寫一則 Slack 訊息，不要讓主管猜你在幹嘛。
Q5：怎麼跟同時管理多個團隊的老闆溝通？
讓他花最少的時間了解你的狀況。(1) 進度報告用紅黃綠燈——綠燈他可以跳過不看 (2) 只有黃燈和紅燈的時候才需要他的注意力 (3) 每次溝通都帶選項和你的建議，讓他只需要「approve」而不是「think」。