需求先寫成使用情境，看懂才開工。

我們用的方法叫行為驅動開發。每個功能動工前，先寫成你看得懂的使用情境：什麼狀況下、誰做了什麼、系統該怎麼回應。這些情境就是驗收標準，做完沒有，逐條對。

開工前: 每個功能都寫成情境，你看過、確認過才動工。
交付時: 照情境一條一條驗收，不靠感覺判斷做完了沒。

情境範例

刀具壽命到達警戒值

假設什麼狀況下: 3 號機上的 T12 銑刀，累計使用已達壽命上限的 80%
當誰做了什麼: 機台回報下一筆加工完成
那麼系統該怎麼回應: 監控看板把這把刀標為「注意」，並列入待更換清單

示意情境，非實際專案。

從第一次訪談到上線，五個階段。

軟體專案的成本，不只來自程式開發。需求反覆、範圍擴張、資料定義不一致、權限模糊與決策延遲，都會形成更高的隱性成本。分成五個階段，是為了在投入大量開發成本之前，先降低方向錯誤與重複工作的風險。

了解現況
需要回答的問題
誰遇到什麼問題，問題如何形成
可能產出
訪談紀錄、現況流程、角色盤點
定義問題
需要回答的問題
真正需要改變的是什麼
可能產出
問題陳述、成功條件、需求範圍
設計方案
需要回答的問題
系統如何支援目標
可能產出
資訊架構、流程圖、資料模型、原型
實作驗證
需要回答的問題
解法是否能在真實情境運作
可能產出
可操作版本、測試紀錄、階段驗收
上線迭代
需要回答的問題
如何維護並持續改善
可能產出
部署、文件、監測、後續路線

做系統時，我們這樣取捨。

你提的功能，先問它解決什麼: 功能通常源自真實的問題，但不一定是最適合的解法，所以我們會先回頭問：這一條是為了解決什麼？
不是所有流程都值得被自動化: 錯誤或多餘的流程，不應因為導入系統而被永久保留。
先處理資料與權限，再處理畫面: 穩定的系統來自清楚的資料關係、角色責任與狀態轉換，不只是介面設計。
先建立可用範圍，再增加完整度: 第一階段只做最關鍵的那幾條情境，其餘排進後面的階段。

先說說你現在怎麼做。

不須自備規格書。用一段文字描述目前的狀況，我們會儘快回覆你；諮詢不收費。