跳至主要内容

Liwen Studio 專屬開發流程

這套流程跳脫了傳統教科書的僵化框架，是我在實務接案與專案開發中淬鍊出的 12 步核心流程。

這套流程最大的特色在於**「權責極度清晰」與「防禦性極強」**。它完美揉合了瀑布流的嚴謹（以保護團隊不被無底洞需求坑殺）與敏捷開發的彈性（以利快速交付與修正），確保最終產出的系統精準符合客戶需求，同時降低後期重構的巨大風險。

🛠️ 實務開發 12 步流程​

【階段一：需求訪談與合約確立】​

🎯 核心目標：收斂範圍、建立護城河，確保工程師不會寫出「白做工」的程式碼。

1. 深入客戶痛點 (PM 帶回需求)​

  • 具體行動：PM 帶著空白的畫布去見客戶，專注傾聽並挖掘「為什麼需要這個功能」。這時絕不給予任何技術承諾。
  • 📝 文件產出：01. 需求訪談單 (Interview Record)

2. 內部殘酷評估 (技術主管把關)​

  • 具體行動：PM 帶回訪談單後，與技術主管進行內部對焦。技術團隊針對「完整願望清單」進行全面評估，明確列出每一項的開發成本、技術可行性，並標示出那些「天馬行空或高風險」的地雷功能，為 PM 準備好談判的籌碼。
  • 📝 文件產出：02. 內部需求評估單 (Internal Assessment)

3. 產出 PRD 需求規格書與客戶對焦​

  • 具體行動：PM 揉合《01. 訪談單》的願望與《02. 評估單》的底線，過濾掉內部機密後，寫出一份白紙黑字的《03. PRD 需求規格書》草稿。PRD 上不僅列出「第一期要做的」，也會把做不到的列在「第二期未來擴充」中。PM 帶著這份 PRD 去跟客戶談判：「老闆，您許願的 AI 機器人我們有規劃進去，但考量預算與上線時間，我們把它放在第二期，第一期我們先把核心功能做穩可以嗎？」
  • 📝 文件產出：03. 需求規格書 (PRD)

4. 需求收斂迴圈 (Iteration)​

  • 具體行動：若客戶對 PRD 範圍不滿意或有意見，則回到步驟 1~3 重新跑一次循環，直到雙方對範圍與報價達成完全共識。

5. 簽約開工 (Contract Signed)​

  • 具體行動：PRD 定案後，雙方正式簽約。專案範圍就此鎖死，成為後續開發與驗收的唯一法律與執行依據。

【階段二：系統設計與技術落地】​

🎯 核心目標：將商業語言翻譯為技術語言與視覺畫面，為工程團隊鋪好鐵軌。

6. 雙軌分析與設計 (SA & UI/UX)​

  • 具體行動：這是簽約後平行進行的雙軌階段：
    • 邏輯軌 (SA)：分析師看著 PRD，梳理出系統面的「資料實體 (Entities)」、「服務邏輯」與「角色權限」。
    • 視覺軌 (UI/UX)：設計師看著 PRD 繪製 Figma 畫面動線，並必須交由客戶畫押定稿。
    • 兩者必須互相核對（確保畫面上的欄位與資料庫實體吻合），防堵規格斷層。
  • 📝 文件產出：系統分析規格書 (SA Document) 與 Figma 視覺定稿。

7. 系統開發規格與任務拆解 (SD)​

  • 具體行動：工程團隊左手拿著「SA 邏輯文件」、右手拿著「Figma 設計稿」，決定具體的技術棧、資料庫 Schema、API 路由，並拆解成實際可執行的 GitHub Issues 或工單。
  • 📝 文件產出：系統開發規格書 (Tech Spec / SD)

【階段三：敏捷開發與迭代驗證】​

🎯 核心目標：小步快跑，及早發現落差，把所有「功能修改」限縮在此階段。

8. 前後端平行開發與實作 (Development)​

  • 具體行動：工程團隊看著《05. SD》與 Issues 正式寫 Code。此階段嚴格執行「平行開發」：
    • 後端工程師：第一時間開出 API Mock (假資料伺服器) 供前端串接，隨後專注處理資料庫與底層商業邏輯。
    • 前端工程師：看著 Figma 畫面，直接串接後端假資料 API 進行 UI 實作與狀態管理。
    • 雙方無縫接軌不卡關。因前置作業扎實，工程師只需專注於純技術實作。

9. 階段性 MVP 測試與修正迴圈 (Iterative Testing)​

  • 具體行動：每一個小階段（Milestone）完成後，立刻讓客戶進行該模組的 MVP 測試。
  • 核心心法與防禦機制：這是開發中最關鍵的「除錯與微調」期。
    • ✅ 允許修改（UX/邏輯/手感）：客戶覺得操作不順、功能有 Bug，工程師當下立刻微調修改。
    • ❌ 嚴禁大改（UI/大排版/視覺）：若客戶突然要求推翻版面架構或更改主色系，PM 必須拿出【步驟 6】已簽署的 Figma 視覺稿進行防禦，拒絕無償修改或啟動追加報價流程。此防禦機制可徹底消除工程師「做完才被大改」的恐懼。

【階段四：測試、部署與正式交付】​

🎯 核心目標：產品交付前的終極防線。此階段理論上不應再有功能修改。

10. 程式碼封版與完整系統測試 (Code Freeze & QA)​

  • 具體行動：當所有 MVP 都經歷過步驟 9 的修正並確認後，進行「全面封版」。接著由 QA 團隊進行最全面的系統測試（回歸測試）。
  • 核心心法：既然功能在步驟 9 都測過了，這裡的重點是嚴格把關極端邊界條件、資訊安全（Security）與系統效能（Performance），確保系統底層絕對穩定。

11. 部署測試區與最終 UAT 驗收 (Final UAT)​

  • 具體行動：QA 確認無誤後，將最終完整版系統部署到測試機 (Staging)。交由客戶進行最後一次的「完整走查驗收 (Final UAT)」。
  • 核心心法：因為在步驟 9 已經做過多次 MVP 測試與修改，理論上這裡**「不應該再有任何邏輯或功能的修改」**。這一步純粹是為了上線前的安心確認與最終畫押。

12. 正式部署與結案 (Production)​

  • 具體行動：客戶最終畫押且結清尾款後，將系統部署至正式環境 (Production)。專案完美結案。

📋 附件：職責與產出對照總表​

這是一份給團隊內部成員的快速檢核表，確保每個階段的「執行動作」與「產出文件」都有確實交棒。

階段步驟負責角色核心執行動作必須產出物
一、需求與合約1. 需求訪談PM、客戶聆聽並記錄客戶所有功能願望與痛點，不給技術承諾。📄 《01. 需求訪談單》
2. 內部評估PM、技術主管針對願望評估技術可行性、開發成本與潛在風險。📄 《02. 內部評估單》(機密)
3. 產出 PRDPM、客戶區分「第一期核心」與「第二期擴充」，並談判預算。📄 《03. 需求規格書 (PRD)》
4. 需求迴圈PM、客戶依據客戶反饋，反覆調整 PRD 範圍直至雙方達成共識。（更新 PRD 草稿）
5. 簽約開工PM、客戶簽名鎖定範圍，並取得專案所需之真實資料與圖文素材。📄 已簽署《PRD》、真實資料
二、設計與技術6. 雙軌設計SA、設計師、客戶設計師繪製 UI 並定稿；SA 梳理商業流程與資料庫實體。📄 《04. 系統分析 (SA)》、Figma
7. 開發規格技術團隊依據 SA、Figma 與真實資料，決定技術棧、API 與 Schema。📄 《05. 系統開發 (SD)》
三、敏捷與驗證8. 平行開發前端、後端工程師後端建置 Mock API 供前端切版，並同步實作底層邏輯。💻 MVP 階段性程式碼
9. MVP 測試PM、工程師、客戶每完成一個 MVP 即交由客戶實測，工程師針對反饋即時修改。💻 已修正的 MVP 系統
四、測試與交付10. 封版與 QA工程師、QA 團隊嚴格執行程式碼封版。QA 進行回歸測試、資安與效能檢查。📋 QA 測試報告、穩定版系統
11. UAT 驗收PM、客戶部署至 Staging，交由客戶進行最後完整走查（不修改功能）。📋 客戶簽收之 UAT 驗單
12. 正式結案PM、工程、客戶結清尾款，系統部署至 Production 正式環境上線營運。💻 Production 上線系統