「講一次你在需求很模糊的情況下完成任務的經驗」是越資深越會被問的行為題。因為真實工作裡，需求幾乎都是模糊的——老闆丟一句「幫我做個能看數據的東西」，剩下全靠你補。這題考的不是你會不會做，而是：當沒有人給你明確規格時，你怎麼自己把混沌變成一個可執行的計畫？
最容易講壞的方式：① 被動等指令（「我問了主管，他叫我做什麼我就做」——顯得沒主見）；② 悶頭猜（不對齊就埋頭做，最後做錯方向重來——顯得魯莽）。好的版本要展現一套化模糊為明確的方法：定義問題 → 做假設 → 對齊關係人 → 小步交付驗證。
這篇用一個「需求一句話、細節全空」的專案當素材，示範怎麼用 STAR 把它講成展現結構化思考的故事。
先記住：處理模糊需求的四個動作
| 動作 | 在做什麼 | 面試加分點 |
|---|---|---|
| 定義問題 | 把模糊的「想要」翻成具體的「問題與目標」 | 展現你會主動 framing，不是等指令 |
| 做假設 | 在資訊不全時，明確列出你的假設 | 展現你能在不確定下前進，且把假設攤開 |
| 對齊關係人 | 用問題/原型跟人確認方向 | 展現溝通，不是悶頭猜 |
| 小步驗證 | 先做最小版本拿回饋，再迭代 | 展現用迭代降低不確定性 |
💡 核心心法：模糊需求的解法不是「問到完全清楚才動」，也不是「不問就埋頭做」，而是**「用假設與小原型，把模糊一步步收斂成明確」**。展現這套收斂方法，就是這題的高分點。
逐字稿示範（中文，~380 字）
數字、情境為示範用，練習時換成你自己的真實經歷。
「【S】 主管丟給我一句話:『幫團隊做個能看專案數據的儀表板』——沒有規格、沒說要哪些指標、沒說給誰看、也沒說技術選型。整個需求就這一句。
【T】 我的任務是把這個模糊的想法,變成一個真的有人用、有價值的東西——但首先,我得自己定義『這到底要解什麼問題』。
【A】 我沒有立刻開始寫 code,也沒有把主管問到煩。我分三步收斂:第一,定義問題 + 做假設——我先假設『使用者是團隊成員,最在意的是專案進度與卡關項』,並把這個假設寫下來。第二,對齊關係人——我沒有問一堆開放式問題(那只會得到『都可以』),而是直接做了一個very rough 的原型草圖,列出我猜的 3-4 個核心指標,拿去問主管和兩位未來使用者:『是這個方向嗎?哪個指標沒用、缺了什麼?』。用具體的東西問,他們馬上能給出明確回饋,我也很快發現有一個我以為重要的指標其實沒人看、反而漏了一個大家都要的。第三,小步交付——我先做一個只含核心指標的最小可用版本上線,讓大家真的用起來,再根據實際使用迭代,而不是憋一個大而全的版本。
【R】 最後這個儀表板團隊真的天天在用,還被其他組借去套用。更重要的是:從一句模糊的話到有人愛用的產品,中間沒有一次『做錯方向重來』,因為我每一步都先用假設和原型對齊。我學到的是——面對模糊需求,最快的路不是埋頭做,而是先用一個具體原型把『大家腦中不一樣的想像』對齊成同一個。」
English Script (~250 words)
"[S] My manager handed me one line: 'Build the team a dashboard to see project data' — no spec, no metrics named, no audience, no tech stack. The entire requirement was that sentence.
[T] My task was to turn this vague idea into something people would actually use and value — but first, I had to define for myself 'what problem this really solves.'
[A] I didn't start coding immediately, nor did I pepper my manager with questions. I converged in three steps. First, define the problem + make assumptions: I assumed 'the users are team members who care most about project progress and blockers,' and wrote that assumption down. Second, align stakeholders: instead of asking lots of open questions (which only yields 'anything's fine'), I made a very rough prototype sketch listing the 3-4 core metrics I guessed, and asked my manager and two future users: 'Is this the right direction? Which metric is useless, what's missing?' Asking with something concrete, they gave sharp feedback immediately — and I quickly found one metric I'd thought important that nobody looked at, while a metric everyone wanted was missing. Third, ship in small steps: I launched a minimal usable version with just the core metrics, got people actually using it, then iterated on real usage rather than hoarding a big all-in-one version.
[R] The dashboard ended up in daily use, even borrowed by other teams. More importantly: from one vague line to a product people loved, there was never a 'wrong direction, start over' — because every step aligned via assumptions and a prototype. My lesson: facing ambiguity, the fastest path isn't heads-down building — it's using a concrete prototype to align everyone's different mental pictures into one."
面試官最愛追問的點（先準備好）
-
🎤 「你怎麼決定哪些假設可以自己定、哪些一定要問人？」 → 展現判斷力：低風險、可逆的假設我自己定並標註出來（如配色、版面）；高風險、難回頭的（如核心指標、使用者是誰）一定先對齊。把『該問的』和『能自己決定的』分清楚，是這題的關鍵。
-
🎤 「如果關鍵關係人意見不一致呢？」 → 展現處理衝突：我會把分歧攤到原型上具體討論（而非抽象爭論），找出共同的底層目標,必要時請出能拍板的人,並用『先做最小版本驗證』降低押注風險。
-
🎤 「你為什麼先做原型而不是先寫一份完整需求文件？」 → 點出方法的效率：面對模糊,文字規格大家各自想像不同;一個具體原型能讓抽象分歧瞬間變具體,回饋更快更準——這是『用具體物件對齊』的威力。
-
🎤 「最後成果跟你一開始的假設差多少？」 → 誠實談迭代：差不少,而這正是價值所在——我的假設只是起點,靠對齊和迭代修正方向,證明這套方法能在不確定中收斂到對的東西。
💡 應對追問的原則:追問常想測『你是有方法,還是運氣好猜對』。每次都回到『定義問題 → 攤開假設 → 用原型對齊 → 小步驗證』這條收斂線。
打磨清單（套用到你自己的故事）
- S 段要凸顯真的很模糊（一句話、沒規格、沒對象），否則沒有張力
- Action 要展現主動 framing：你自己把『想要』翻成『問題與目標』
- 一定要有「做了假設並攤開」+「用具體原型對齊」兩個動作
- 展現小步交付（最小版本 → 迭代），而非憋一個大版本
- Result 收在「沒有做錯方向重來」或「真的被採用」這類具體價值
- 全程用「我」，凸顯是你主導收斂
- 中英雙語同一結構，念出來控制在 2-2.5 分鐘
結語
「處理模糊需求」這題真正在問的是:沒人給你明確指令時,你會不會自己把混沌定義成問題、用假設和原型對齊方向、再用小步驟降低不確定性? 這是資深工程師和執行者最大的差別——執行者等規格,資深的人自己造規格。
把故事寫成 STAR,核心放在那套「定義問題 → 做假設 → 對齊關係人 → 小步驗證」的收斂方法,再用「沒有走錯方向 / 真的被採用」收尾。這樣這題就從「我做完了一個沒人講清楚的任務」變成「我能把模糊變成明確」——後者才是能獨當一面的人。這是 STAR 系列第六篇,前五篇談了自我介紹、克服技術難題、快速學習、Ownership 與失敗教訓。