駭客松沒方向時,怎麼把想法收斂成題目
駭客松最難的往往不是寫程式,是第一天大家圍著白板「那我們要做什麼?」的卡頓。 這篇記錄這個專案怎麼從一堆零散想法收斂成一個能做完、做得出來的題目 —— 一套任何小團隊都能照用的方法。
前提:我們的起點
四人團隊(1 PM、2 編輯、1 工程),一個共通背景:大家都在同一個內容產業工作。 沒有人一開始就知道要做什麼 —— 這很正常,也是重點:好題目不是想出來的,是篩出來的。
① 先發散,不要急著聚焦
第一步不是「找一個好點子」,是先攤開一批方向,不怕多、不怕重疊。 我們列了好幾個切角 —— 有的偏內容生產、有的偏情報蒐集、有的偏片單策展、 有的偏排程規劃。
這階段唯一的紀律:先求數量,不評好壞。 太早批評會殺掉還沒長大的點子。
② 用「真實痛點」當篩子,不是挑最酷的
收斂的關鍵不是「哪個最炫」,是哪個打中大家每天真的在痛的事。 我們把每個人的痛點攤出來,發現一個共同主題反覆出現:
內容多到一個程度,「內容本身有沒有被好好理解、好好找得到」就成了瓶頸 —— 分類、檢索、整理,從不同角色的角度看都卡同一件事。
→ 對齊到痛點後,「讓內容被理解 + 被找到」這條線立刻浮上來, 而幾個炫但沒人天天痛的方向(排程、跨通路改寫)自然沉下去。 三個人從不同角度都在痛同一件事,就是強訊號。
③ 投票後「合併」,而不是「二選一」
投票後票數接近的不是只有一個。我們沒有硬二選一,而是看哪些可以疊成同一條主線: 把「自動理解內容」和「依需求找內容」併成一個彼此餵養的系統,而不是兩個各做一半。
很多團隊卡在「到底選 A 還是 B」。其實常常答案是「A 為主、B 為輔」—— 把名次相近的選項看成可以疊加的層,而不是互斥的牆。
④ 用「可行性」與「範圍」把題目切定
收斂到後期,靠兩個現實問題定範圍:
- 這在駭客松時間內做得出來嗎? 技術門檻中等、prototype 跑得動的留; 要大量爬蟲 + 排程自動化那種工作量,直接標「之後有餘力再說」。
- 最小要證明什麼? 與其功能堆滿,不如先把「核心體驗」做到能 demo。
→ 限制不是敵人。「現在不做什麼」往往比「想做什麼」更快框出題目。
⑤ 切出最小可驗證範圍,並且敢砍
最後把題目切成「核心先做 / 其餘先放」:
- 核心(實際做出來的):自動標籤、語意搜尋、以及由此延伸的策展/獎項整理
- 延伸(列了但砍掉):即時情報蒐集那條 —— 工作量大、不是核心體驗, 最後刻意不做,把時間集中在能 demo 的主線上
列進提案、最後砍掉,不是失敗,是聚焦。駭客松最常見的死法是什麼都想做、 結果什麼都沒做完。能砍,題目才收得乾淨。
並且當場分工 —— 誰負責資料、誰負責 UX、誰負責測品質、誰負責定義分類標準。 一個切得出 MVP、分得出工的題目,才算收斂完成。
收斂的五步,濃縮成一句
發散列多個 → 用真實痛點篩 → 名次相近就合併 → 用可行性框範圍 → 切出 MVP 並敢砍。
駭客松時間有限,花在「選對題目」的半天,比埋頭做錯方向的三天值得太多。 最好的題目,通常是「團隊真的在痛、技術做得出來、又剛好沒人做過」三者的交集。