MVP 工程手冊：在 6 週內交付有用的 0→1

任何小團隊都可以複製的實用範圍、衝刺和 CI/CD 藍圖。

為什麼需要另一份 MVP 指南？

大多數 MVP 失敗是因為範圍蔓延、脆弱的基礎設施或緩慢的反饋循環—而不是缺乏想法。本指南專注於一條最小但可靠的路徑，讓真實用戶快速接觸真實產品，並有足夠的質量關卡來避免重寫。

第 0 週：定義「完成」並消除不確定性

• 用一句話陳述問題
• 三個主要使用案例
• 一個成功指標（例如，首次任務完成或首次付款）
• 不可協商項目：認證、審計日誌、基本可觀察性、備份
• 明確擱置的錦上添花功能

成果：一頁 PRD 和簡單的系統草圖（客戶端 → API → 資料庫 → 第三方）。

第 1-2 週：交付運行骨架

• 程式庫：單一程式庫或兩個（網頁/行動 + API）
• 選擇無聊、經過驗證的技術棧（例如，Next.js/React + Node/Laravel + Postgres）
• 實現：認證、角色、種子數據、功能標誌、錯誤追蹤、健康檢查
• 在第 3 天前部署到測試環境

質量關卡：程式碼檢查、核心領域的單元測試、提交前鉤子、CI 在 10 分鐘內完成。

# .github/workflows/ci.yml (範例) name: CI on: [push, pull_request] jobs: build_test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: { node-version: '20' } - run: npm ci - run: npm run lint && npm test -- --ci

第 3-4 週：交付薄垂直切片

以用戶可見的切片形式交付功能，而非層。

切片模板

1. 小規格（給定/當/則）
2. API 契約 + 正常路徑測試
3. UI 狀態：空、加載中、錯誤、成功
4. 遙測：事件 feature_used
5. 文檔：CHANGELOG 中的 5 行 + 一個簡短的 GIF 用於 QA

第 5-6 週：穩定並證明價值

• 為頂級流程添加驗收測試
• 對最慢端點進行負載測試（目標 p95 < 500 毫秒）
• 備份 + 恢復演練
• 可觀察性儀表板：錯誤、延遲、註冊、首次成功率
• 發布說明 → 試點用戶

MVP 基線檢查清單

• 具有速率限制和安全密碼存儲的認證
• 授權（最小權限）
• 輸入驗證和請求大小限制
• 集中式日誌記錄 + 錯誤警報
• 每日備份 + 恢復測試
• 風險變更的功能標誌
• 基本隱私頁面 + 條款；收集最少的 PII

不會說謊的估算

只估算接下來的兩週。使用T恤尺寸進行積壓工作估算，並在拆分故事後將 S/M/L 轉換為小時。只追蹤已完成的故事點來設定下一個衝刺的容量。

關於架構的說明

偏好簡單：單一 Postgres、單一 API 服務、單一網頁應用。只在真正的瓶頸處添加隊列或微服務。複雜性每天都會讓你付出代價。

積壓工作範例（前 6 週）

• 註冊/登入、電子郵件驗證、密碼重置
• 組織 + 角色（擁有者、用戶）
• 核心對象 CRUD + 搜索
• 導入 CSV（正常路徑）
• 事件追蹤 + 簡單儀表板
• Stripe 測試支付（如相關）
• 通過功能標誌進行管理員切換
• 文檔：入門 + FAQ

要測量什麼（以及為什麼）

• 激活：完成首個核心任務的註冊百分比
• 延遲 p95：用戶感知速度
• 錯誤率：每 1k 請求的警報數
• 留存率（週環比）：用戶是否回來？

無懼發布

1. 每個 PR 通過 CI
2. 測試環境在合併時自動部署；生產環境需要手動批准和功能標誌
3. 回滾計劃 = 先前的容器標籤 + 資料庫遷移回退步驟
4. 發布後審計：頂級錯誤、修復時間、下一步緩解措施

常見陷阱（及出路）

• 無止境的打磨：固定時間盒；交付給 5 個真實用戶
• 框架購物：選擇你已經熟悉的
• 過早擴展：更多實例無法治癒糟糕的查詢—先進行分析
• 分析雜湊：只追蹤與成功指標相關的 3 個事件；不要更多

可複製的資源

• OWASP ASVS（基線安全）
• Twelve-Factor App（運維理智）
• GitHub Actions 市場測試/檢查操作

\