把訪談內容變成可執行的需求文件

口頭講好的事，三個月後不會是同一個版本 比喻：裝潢。屋主說「廚房希望大一點」，師傅點頭。三個月後驗收，屋主想的是多一個中島，師傅做的是把一面牆推 30 公分。兩個人都沒有說謊，只是從來沒有把「大一點」寫下來。 需求文件的功能只有一個：讓雙方對「做完長什麼樣」有同一個畫面。 它確實也能在爭議時保護你，但把它當成免責文件來寫，你會寫出一份沒有人想讀的東西。當成對齊工具來寫，它才會被讀。 七個區塊 區塊　·　寫什麼　·　漏掉會怎樣 1 問題描述　·　現在痛在哪，一段話　·　做到一半，沒有人記得為什麼要做 2 現況流程　·　現在這件事是怎麼做的　·　做出來的東西套不進他們實際的工作方式 3 目標與成功指標　·　做完之後怎麼判斷成功　·　驗收時變成無限修改（第 12 集） 4 範圍　·　做什麼 / 不做什麼　·　範圍無限擴大（第 05 集） 5 使用者與角色　·　誰會用、各自看得到什麼　·　權限與介面最後才發現要重做 6 資料來源與權限　·　資料在哪、誰能給、什麼格式　·　卡在拿不到資料，整個專案停擺 7 假設與風險　·　我們假設了什麼、什麼可能出錯　·　假設破掉時，變成你的責任 第 6 項是最容易被輕忽、卻最常拖垮時程的一項。「資料應該都有」這句話在第 01 集就出現過——在需求文件裡，它要變成「資料在哪個系統、格式是什麼、由誰在幾號之前提供」。 Must / Should / Won't 需求排優先序常用的是 MoSCoW 框架（Must / Should / Could / Won't）。實務上建議砍掉 Could，只留三格： 格　·　意思　·　判斷方式 Must　·　沒有它，這個專案就沒有意義　·　拿掉之後，客戶還會想做嗎？不會，就是 Must Should　·　有很好，但可以第二期　·　拿掉之後專案仍然有價值 Won't　·　這次明確不做　·　—— 為什麼砍掉 Could：Could 最後都會變成爭議。客戶記得的是「你說可以做」，你記得的是「我說看情況」。三格逼你現在就決定，不留模糊地帶。 Won't 是整份文件最有價值的欄位 大部分人只寫「要做...