蒐集漏斗：讓知識進來有地方落

蒐集漏斗：讓知識進來有地方落 那個 bug 上線前其實提到過。 PM 在站會結尾順口說了一句：「對了，這次限制只適用 VIP 等級，其他用戶直接放行。」沒人記，沒人問。需求文件裡沒有，Jira 票也沒更新。測試跑完、上線，兩天後客服開始收到回報。 你回去翻 Slack，找到那條訊息了，埋在 50 則討論後面。 需求散在 Slack 討論串、Figma 留言、Jira 評論、站會口頭、PM 私訊。每個頻道都有一部分，沒有一個地方有完整的版本。你問了三個人，得到三個略有不同的答案。你永遠在問「這版到底要幹嘛」。 知識消失在哪一關 大家都說需求不清。可是很多時候需求講過了，只是沒被記下來。 沒人是故意不記。當下要開工具、要分類、要整理成「正確的格式」，麻煩程度超過眼前那件急事，就跳過了。等到要用的時候，那句話早就記不清楚了。 蒐集 是整個知識系統裡摩擦最高、最容易斷掉的一關。這一關漏掉的東西，後面整理得再好也撈不回來。 三個原則 單一入口。 不管是需求討論、業務規則、測試想法、臨時補充，先進同一個地方。多個地方等於沒有地方。你不需要在當下決定這條資訊「屬於哪個專案」或「應該放哪個分類」，那是下一步的事。先有一個固定的收件位置，就夠了。 抓進來再說。 當下不要求把它整理成「最終版本」，不要求語句完整，不要求加標籤。先把原始片段存進來，截圖、轉貼、一句摘要都行。要求太高，就什麼都不會進來。 來源可追。 每條紀錄帶上三樣東西：原始來源在哪（頻道連結、票號、會議紀錄網址）、什麼時候（日期）、一句話說明為什麼這條值得留。不需要更多。有這三樣，事後能回去確認當時的 context，也能判斷它現在還算不算數。需求常常改，沒有日期的紀錄，你分不出它過期了沒。我後來多加了一條規則：每條都標「已確認」或「待確認」，不確定的就標出來，回頭去問。 什麼值得抓 全抓等於沒抓。收件位置會變垃圾桶，很快就沒人敢進去翻。 值得留的訊號，是 會影響測試決定的東西 ： 業務規則和例外條件（「VIP 才有這個行為」「只在特定時段生效」） 邊界條件（「金額上限是這個數字，原因是舊系統限制」） 特別交代的驗收要求（口頭提的比文件更容易被遺忘） 改動的歷史原因（「這個 case 是因為去年那次事故才補上的」） 客訴來源（某個 bug 背後有真實用戶受傷，值得留一條記錄） 判準只有一個：「如果這條漏掉，測試計畫會做錯或做少嗎？」是，就抓；不是，可以放掉。 可以怎麼做 設一個固定的收件位置。工具不重要，一份筆記、一個頻道、一張試算表、一個收件匣標籤都行，只要有一個地方是「什麼東西先丟這」。 蒐集的時機在資訊流過的當下：需求討論結束的那一刻，或者 PM 的私訊剛回覆完，就順手丟一條進去。不要等有空再整理。等到有空，context 早就流走了。 每週或每隔幾天，清一次收件位置。把值得留的搬進正式位置，按專案或業務領域整理。這個整理動作是下一步的事，S03 會專門處理「東西進來了，怎麼組織讓它不腐化」。 收件位置本身不需要漂亮。它的任務只有一個：讓東西進得來。 今天就開一個收件位置，任何工具都行。下次需求討論完，立刻丟一條進去，不用整理好，進得來就算數。 下一篇：東西進來了，收件位置越積越厚，怎麼整理讓它不變成知識墳場？