那個禮拜，各部門輪流找我
進新環境的第一週，我走過每個部門。
業務說他們需要一個語音訓練系統。
行政說有個行事曆提醒的邏輯想自動化。
廣告組說每天追蹤數據太花時間。
客服說 AI 客服有時候卡住，重送又發了兩次。
還有合約自動填入、腳本生成、影片數據整合……
一週結束，我整理了 10 個左右的需求。
我以前會犯的錯
以前的我，看到這些需求會有一個直覺反應：
「好，我來一個一個做。」
然後陷入無止境的執行地獄。
每個需求都有技術細節要確認，每個部門都有 follow up，你變成所有問題的承接點，什麼都要自己動手。
結果是：你很忙，但對方感覺不到你的價值。
技術顧問的工作不是執行所有事
這個角色給我的最大改變，是重新理解「我的工作是什麼」。
技術顧問或技術總監的工作，不是把所有需求都扛下來跑。
是三件事：
1. 整理 — 把模糊的需求變成清晰的問題
2. 排序 — 決定什麼先做、什麼後做、什麼不做
3. 路由 — 決定哪些自己做、哪些帶人做、哪些外包
執行，是最後才發生的事。
整理的價值
10 個需求，表面上看起來都是「我們需要 XX」。
但問題本身不一樣。
有些是「現在就痛」的問題，不解決就有實際損失。
有些是「有更好」的問題，不解決也能活，但有了效率更高。
有些是「想法還沒成熟」的問題，現在做了之後還是要重做。
把這三種分開來，優先級就出來了。
排序的策略
我用的原則很簡單：
先做「技術明確 + 業務痛點直接」的。
技術複雜但業務不急，放後面。
業務很急但技術方向還不清楚，先去把技術搞清楚，再做。
需求模糊的，先訪談，不要先做。
做出來但沒人在乎的系統，是最貴的浪費。
路由的決定
不是每件事都要自己做。
有些需求，驗證一下技術可行性，找對的人帶著做就好。
有些需求，市場上已經有成熟工具，整合進來比自己從零建便宜十倍。
有些需求，等業務方準備好（SOP、模板、素材），才有意義開始。
技術顧問的判斷力，在於知道哪些值得做、哪些值得等、哪些值得外包。
不在於什麼都自己扛。
我做了什麼
那 10 個需求，我整理之後分成三類：
第一類：立刻可以動（技術明確 + 業務痛點清楚）— 先做
第二類：需要對方提供素材或 SOP 才能開始 — 記錄下來，等
第三類：方向還在討論中 — 先記著，下次討論
結果是：我這週真正動手的需求，只有兩三個。
但每個部門都覺得他們的問題有人在管，沒有被忽略。
這才是技術顧問的角色：
讓所有問題都有位置，讓對的事情先發生，讓執行的人知道自己在做什麼。
不需要什麼都自己做。
需要的是，看得清楚，說得清楚，讓事情動起來。