禮拜三下午三點，老闆走進會議室，廠商 PM 把筆電轉過來說：「系統可以驗收了。」桌上躺著一份 12 頁的測試報告、一個寫了「pass」的 Excel、以及一份要老闆當場簽名的驗收單。會議排了一小時。一小時後，老闆要決定要不要付出 30% 的尾款。
這是大多數軟體外包專案到驗收階段的場景。問題是——這場一小時的會議比較像「請你簽字」的儀式，而真正的驗收工作早該開始。真正的驗收，應該在這場會議之前的兩到三週就已經開始：誰測、測什麼、用什麼資料測、bug 怎麼分級、修不好怎麼辦——每一條都該寫進合約，並且在驗收會議當天打開 checklist 一條條走完。
這篇文章是給找外包做軟體的老闆寫的實戰 SOP：從合約怎麼寫驗收條款、UAT 測試該分幾類、30 點驗收 checklist、bug 嚴重度分級、驗收會議議程模板，到上線後怎麼處理「廠商說不在範圍內」的 bug。每個步驟都具體可執行，你可以直接把 checklist 複製到 Notion 或 Google Docs 給廠商，當作驗收依據。
如果你還沒簽合約、還在規劃付款節點，先看 MVP 4 階段付款與驗收節點完整指南把驗收條款訂進合約；如果你想看完整的軟體產品開發路線圖，從 0 到上線的全景建議直接讀 老闆指南：從 0 到上線打造會賺錢軟體產品的完整路線圖。這篇談的是條款訂好之後、怎麼真的把驗收會議走完。
為什麼驗收這關特別容易踩雷
先講個故事。一家做電商的老闆找廠商開發後台訂單管理系統，合約寫得很簡單：「依需求書交付，驗收完成後付尾款。」需求書 18 頁，廠商交付的時候給了一份 Excel 列了 47 個功能點，每個都打了勾。老闆點開後台試用半小時，覺得操作起來怪怪的，但功能好像都在，就簽了。
上線兩週後，財務小姐發現訂單匯出 Excel 的金額欄位，零頭都被四捨五入掉了。一個月內財報差了 28 萬。打電話問廠商，廠商說：「需求書沒寫小數點要保留幾位，這個是規格問題，要修要另外算錢。」
說廠商耍流氓也不公平，問題出在驗收 SOP 沒走完。需求書沒寫到的功能、UAT 沒測到的場景、驗收 checklist 沒列到的細節，事後都會變成「不在範圍內」的爭議。
⚠️驗收沒寫進合約 = 驗收沒做
如果你的合約只有「依需求書交付驗收後付尾款」這一句，驗收會議就會變成廠商請你簽字的儀式。驗收條款必須包含：測試範圍、測試環境、測試資料、bug 嚴重度分級、修復時限、未通過的處置方式（重測、退款、終止合約）。沒寫進合約，事後都是各說各話。
常見的驗收糾紛來源有四種，每一種都對應一個沒做好的 SOP 步驟：
糾紛類型 | 典型台詞 | 沒做好的 SOP 步驟 |
|---|---|---|
規格爭議 | 「需求書沒寫，這算客戶端追加」 | 驗收 checklist 沒對齊需求書條目 |
環境差異 | 「在我們環境是 OK 的，是你機器有問題」 | UAT 環境跟正式環境沒對齊 |
資料偏差 | 「測試資料這樣不會出錯，是你正式資料髒」 | 沒用真實資料量級做壓力測試 |
時程拖延 | 「上線了再修，先讓系統跑起來」 | 沒設定 bug 修復時限與卡關條件 |
UAT 是什麼，跟 SIT、QA 差在哪——老闆只要記住一件事
市面上講軟體測試的文章，喜歡把 UAT、SIT、QA、Smoke Test、Regression Test 一字排開介紹一輪。對老闆來說沒必要全部背起來。你只要記住一件事：SIT 是廠商自己測自己寫的東西、UAT 是你（業主）拿真實場景測廠商寫的東西。
根據 ISTQB 國際軟體測試標準 的定義，UAT（User Acceptance Testing，使用者驗收測試）的核心目的是「驗證系統是否符合使用者真實需求、是否準備好上線到正式環境」。換句話說，SIT 通過不代表 UAT 會通過——SIT 看的是技術正確性，UAT 看的是「業務跑得通不通」。
測試類型 | 誰來測 | 測什麼 | 典型場景 | 通過代表什麼 |
|---|---|---|---|---|
Unit Test | 廠商工程師 | 單一函式邏輯 | 計算金額函式回傳是否正確 | 程式碼層級沒寫錯 |
SIT（系統整合測試） | 廠商 QA | 模組之間銜接 | 下訂單後庫存是否扣減、發票是否開出 | 技術整合沒問題，可以送業主驗收 |
UAT（使用者驗收測試） | 業主指定的真實使用者 | 業務流程能否跑完 | 會計用真實的月底結帳流程跑一遍 | 業務上可以接受，可以付尾款上線 |
Smoke Test（冒煙測試） | 業主或廠商 | 核心功能還在 | 登入、下單、付款這三個能不能跑 | 最基本沒爆炸，可以開始細測 |
Regression Test（迴歸測試） | 廠商 QA | 改 A 有沒有壞 B | 修了 bug 之後重跑全部測試案例 | 修復沒造成新災難 |
老闆版心法：UAT 一定要你自己人下場
UAT 不能只看廠商給的測試報告就簽字。請排你公司真正每天用這套系統的人——會計、客服、業務、倉管——按照他們平常的工作流程實際操作一遍。廠商的 QA 知道功能怎麼用，但不知道你們公司「結帳前要先核對未開發票數量」這種土規則。
軟體驗收 SOP 完整流程：從接收交付到簽收的 7 個關卡
這是恆遠數位行銷在客戶軟體驗收時實際使用的 SOP 流程。整套走完通常需要 2 到 4 週，視專案規模決定。這 7 個關卡每一關都有明確的「準備工作」、「執行動作」、「卡關條件」，任何一關沒過，都不該放行到下一關。
關卡 1：接收交付物清單（驗收會議前 5 個工作天）
不要等廠商說「可以驗收了」才開始準備。驗收前一週，請廠商寄出書面的「交付物清單」，至少包含：完整功能列表（對齊需求書條目編號）、UAT 環境的網址與測試帳號、測試資料說明、操作手冊、API 文件、source code 交付方式、預計支援 UAT 的工程師窗口。
拿到清單後，你的第一份文件就是「對齊表」——把廠商的功能清單跟你的需求書條目逐條對比，缺一條都不准進入下一關。這一步可以擋掉 80% 的「需求書沒寫」糾紛。
關卡 2：UAT 環境部署驗證（驗收會議前 3 個工作天）
UAT 環境（Staging）必須跟正式環境（Production）盡可能一致：同樣的作業系統、同樣版本的資料庫、同樣的網域 SSL 設定、同樣的第三方 API key（用 sandbox 模式）。如果廠商說「我們開發機就是 UAT 機，你們直接連就好」，立刻拒絕——這代表他們沒有獨立的測試環境，正式上線後一改 code 就會影響到你。
關卡 3：測試案例覆蓋率審查（驗收會議前 1 個工作天）
廠商交付的測試案例（Test Cases）至少要對應到需求書的每一條功能。請廠商提供「需求 → 測試案例」追溯表，缺一條都要他補。如果廠商說「測試案例屬於我們內部文件不能給」，這在軟體外包業界是不合理的——測試案例是驗收的基礎，沒有測試案例你怎麼判斷他真的測過？
關卡 4：UAT 執行 + Bug 登記（核心關卡，2-10 個工作天）
這一關是驗收的真正戰場，後面會單獨拉一個段落講 30 點 checklist。重點是要有一個共用的 bug 登記平台（GitHub Issues、Jira、Notion 都可以，連 Google Sheet 都行），所有 bug 都要登記、分配嚴重度、追蹤狀態。禁止用 LINE 群組丟 bug——LINE 訊息會被洗掉、沒有狀態追蹤、誰修了什麼沒有紀錄，等到爭議時你會找不到證據。
關卡 5：全量回歸測試（修完所有 bug 後）
廠商修完 bug 之後，不能只測「修的那個地方」，必須跑一遍全量回歸測試（Regression Test），確認修 A 沒有壞 B。實務上常見的災難是：修了訂單金額計算 bug，結果發票模組壞掉了。回歸測試的證據是廠商給的「測試報告 v2」，列出所有測試案例的最新狀態。
關卡 6：文件交付與 source code 移交
驗收通過的同時，廠商必須完成 source code 與著作權的正式交付。這部分如果合約沒寫清楚誰是著作權人、source code 怎麼交、第三方授權怎麼處理，後面要拿回來會很痛。文件至少要有：操作手冊（給使用者）、系統架構圖（給維運）、API 文件（給未來接其他系統）、部署手冊（給未來換廠商）、第三方授權清單。
關卡 7：簽收 + 保固期啟動
簽收書面文件要明確寫上：驗收通過日、保固期起算日（通常驗收日當天）、保固範圍（哪些 bug 算保固、哪些算新需求）、保固期限（業界常見 3-12 個月）、保固期內回應時限（S0 多久、S1 多久）。簽完之後尾款才撥付。
UAT 該測哪些東西：5 大類測試對照表
很多老闆問：「UAT 我到底要測什麼？我又不懂技術。」答案是——你不用懂技術，你要測的是「業務跑不跑得通」。把 UAT 拆成 5 大類，每一類都有具體的測試方法。
UAT 類型 | 測什麼 | 怎麼測 | 失敗範例 |
|---|---|---|---|
Alpha Testing | 廠商環境內，模擬使用者測 | 廠商把 PM、QA、設計師當成假使用者操作 | 假使用者懂操作，測不出真實使用者會卡的點 |
Beta Testing | 業主環境內，真實使用者測 | 找 5-10 個會用這套系統的員工試用 1-2 週 | 會計小姐第一次用，發現報表匯出格式不能用 |
Operational Acceptance Testing | 維運可行性 | 測備份、還原、監控、告警是否運作 | 資料庫掛了沒人收到通知，三小時後才發現 |
Contract Acceptance Testing | 是否符合合約規格 | 逐條對齊合約附件的功能清單與 SLA 數字 | 合約寫「回應時間 < 3 秒」，實測首頁載入 8 秒 |
Regulation Acceptance Testing | 是否符合法規 | 個資法、電子發票、發票字軌、無障礙網頁 | 沒做密碼複雜度檢查，個資法稽核不過 |
ℹ️中小企業的實務建議
如果預算與時間有限，5 類不一定全做。但 Beta Testing（真實使用者測）跟 Contract Acceptance Testing（對齊合約）是底線，不能省。涉及金流、個資、稅務的系統，Regulation Acceptance Testing 必做。
軟體驗收 30 點 checklist：直接拿去驗收會議用
這份 checklist 是給驗收會議當天逐條走完用的。每一條都要勾「通過 / 部分通過 / 未通過」三種狀態，部分通過要寫明保留條件、未通過要寫明卡關原因與廠商修復時限。建議用 Google Sheet 或 Notion，廠商與業主雙方共用一份，會議當下即時更新狀態。
功能完整性（10 點）
# | 檢查項目 | 驗證方式 |
|---|---|---|
F1 | 需求書每一條功能都有對應的可操作介面 | 逐條對照需求書條目編號，缺一條都記未通過 |
F2 | 核心業務流程能完整跑通（從進案到結案） | 找真實使用者跑一個完整 case，不是一個動作測一次 |
F3 | 錯誤情境有友善提示，不是顯示英文錯誤碼 | 故意輸入錯誤資料，看畫面有沒有看得懂的訊息 |
F4 | 必填欄位、格式驗證、長度限制都正常運作 | 空白送出、超長字串、特殊符號都試一遍 |
F5 | 資料新增、查詢、修改、刪除（CRUD）四種動作都能作用 | 逐個資料表的 4 個動作都至少測 1 次 |
F6 | 匯入 / 匯出功能正常（Excel、CSV、PDF 等） | 用真實資料量匯入測試，匯出後用 Excel 開來看 |
F7 | 權限控制正確（誰能看誰、誰不能改誰） | 用不同角色的帳號分別登入測試 |
F8 | 通知、提醒（Email、SMS、LINE）能正確寄出 | 觸發每一種通知，檢查收件人、內容、時間是否正確 |
F9 | 第三方串接（金流、物流、ERP、發票）正常 | 實際串到 sandbox 跑一筆完整交易，不是只看設定畫面 |
F10 | 報表數字正確（特別是金額、稅、折扣計算） | 用會計師等級的細心，從交易記錄反推到報表數字 |
效能（5 點）
# | 檢查項目 | 驗證方式 |
|---|---|---|
P1 | 首頁與核心頁面載入時間 < 3 秒（4G 網路） | 用 Chrome DevTools 或 PageSpeed Insights 量 |
P2 | 查詢 1 萬筆以上資料能在 5 秒內回應 | 匯入大量測試資料後實測查詢 |
P3 | 同時 50 個使用者操作不會 timeout | 用 k6 或 JMeter 做基本壓力測試 |
P4 | 檔案上傳（10MB 以下）不會中斷 | 實際上傳一支 8MB 影片或一份 5MB Excel |
P5 | 資料庫查詢沒有 N+1 問題（後台幫你看） | 請廠商提供慢查詢日誌（slow query log） |
安全性（5 點）
# | 檢查項目 | 驗證方式 |
|---|---|---|
S1 | HTTPS 全站啟用，無 mixed content | 用 SSL Labs 掃描，A 級以上才算過 |
S2 | 密碼有複雜度檢查，不能存明碼 | 查資料庫直接看 password 欄位是否為 hash |
S3 | 防 SQL injection 與 XSS | 輸入 ' OR 1=1-- 跟 |
S4 | 登入失敗鎖定 / 驗證碼機制 | 故意輸錯密碼 5-10 次，看會不會鎖 |
S5 | 敏感資料傳輸與儲存有加密 | 看 API 回傳是否回 plaintext、DB 是否加密儲存 |
跨裝置 / 瀏覽器（5 點）
# | 檢查項目 | 驗證方式 |
|---|---|---|
D1 | Chrome、Safari、Edge 都正常顯示 | 3 個瀏覽器各跑核心流程一遍 |
D2 | iPhone 與 Android 手機 RWD 沒爆版 | 用真機測，不是只看 Chrome 模擬器 |
D3 | iPad 與一般平板能正常操作 | 注意手指點擊區是否夠大、橫直向都要測 |
D4 | 4K 與小筆電（1366×768）顯示正常 | 解析度極端值要測，不要只測 27 吋螢幕 |
D5 | 列印 / 列印預覽不會跑版 | 有列印需求的頁面（報表、訂單）逐個測 |
文件交付（5 點）
# | 檢查項目 | 驗證方式 |
|---|---|---|
DC1 | 使用者操作手冊（含截圖） | 交給沒看過系統的員工，能不能照著手冊跑流程 |
DC2 | 系統架構圖 / 資料庫 ER 圖 | 找另一個工程師審，能否看懂系統怎麼搭 |
DC3 | API 文件（Swagger / Postman collection） | 試著用文件呼叫一個 API，能否成功 |
DC4 | Source code 移交（Git repo + README） | clone 下來能否照著 README 跑起來 |
DC5 | 第三方套件與授權清單（含到期日） | 逐項確認授權狀態與費用負擔方 |
checklist 的正確用法
30 點不只是勾完就交差。重點是「未通過」與「部分通過」的條目要寫進驗收紀錄，列出修復時限與重測機制。每一條沒過的都對應到合約裡某條條款。把 checklist 當成跟廠商談判的工具，不是當成考試卷。
Bug 嚴重度分級：S0 到 S3，搞清楚誰該負責、什麼時候上線
驗收最常吵架的點，其實不在「有沒有 bug」（一定有），而在「這個 bug 嚴不嚴重、要不要修完才能上線」。沒有分級制度時，廠商會把所有 bug 都說成「小問題、上線後再修」，業主會把所有 bug 都說成「不修不能上線」。雙方都對也都不對。
業界通行的分級是 S0 到 S3 共 4 級。把這個分級寫進合約附件，搭配每一級的「修復時限」，吵架機率會降到原本的 1/3。
等級 | 名稱 | 定義 | 實例 | 處置（建議寫進合約） |
|---|---|---|---|---|
S0 | 致命 (Blocker) | 系統無法使用、資料遺失、安全漏洞 | 登入完全進不去、訂單金額亂跳、密碼明碼存 | 驗收暫停，廠商 24 小時內修復，不修退款 |
S1 | 嚴重 (Critical) | 核心功能無法執行、影響業務 | 發票開不出來、付款流程卡住、權限錯誤 | 驗收暫停，廠商 48-72 小時內修復後重測 |
S2 | 一般 (Major) | 功能可用但有缺陷、有 workaround | 匯出 Excel 欄寬亂跑、特定瀏覽器跑版 | 列入修復清單，1 週內修完，可選擇上線後再修 |
S3 | 輕微 (Minor / Cosmetic) | 不影響功能，視覺或文字小錯 | 錯字、icon 沒對齊、提示文字過長 | 列入保固期 ticket，不阻擋驗收 |
⚠️「上線後再修」的合理範圍
業界共識是：S0、S1 必須在驗收前修完，S2 可以協商是否「先上線後修」（但要寫進保留條款），S3 可以放到保固期。如果廠商把 S0 / S1 也說成「上線後再修」，這就是踩雷訊號——要嘛技術 debt 太重不敢動，要嘛準備拖你尾款。詳細案例可以看 找外包做 APP / 軟體前必踩的 9 個雷 第 7 點。
驗收會議議程模板：90 分鐘走完一場會
驗收會議的本質是「逐條走 checklist + 即時記錄爭議」的工作會議，不該被當成「請你簽字」的儀式。建議排 90 分鐘，超過 90 分鐘代表 checklist 沒在會議前準備好。
時間 | 議程 | 產出 | 主持人 |
|---|---|---|---|
0-10 分鐘 | 交付物清單對齊（廠商說明已交付什麼） | 確認文件、source code、UAT 環境都到位 | 廠商 PM |
10-50 分鐘 | 逐條走 30 點 checklist（即時勾選狀態） | 通過 / 部分通過 / 未通過 三欄都有結論 | 業主 PM 或專案負責人 |
50-70 分鐘 | Bug 嚴重度評估與排期 | S0/S1 修復時限、S2/S3 處置決定 | 業主 + 廠商雙方 |
70-80 分鐘 | 文件交付確認（手冊、API 文件、source code） | 文件清單簽收 | 廠商技術負責人 |
80-90 分鐘 | 驗收結論：通過 / 暫停 / 未通過 | 驗收紀錄表（含未通過項目修復計畫） | 業主 |
驗收會議要錄影
錄影的目的是保護雙方，跟信不信任廠商無關。事後爭議「當天到底有沒有討論這個」，看錄影 30 秒就有結論，比翻 LINE 訊息快 10 倍。會議開始前告知對方會錄影，沒人會拒絕。
驗收通過、上線後出 bug 怎麼辦——保固範圍與恆遠的做法
驗收通過、付了尾款之後，bug 還是會跑出來——這是軟體本質。這時候會發生兩種事：要嘛廠商說「保固範圍內，免費修」，要嘛廠商說「這是新需求，要另外計費」。差別在「保固條款怎麼寫」與「廠商願不願意陪你」。
保固期該寫進合約的 4 個重點
保固期長度：業界常見 3-12 個月，建議至少 6 個月。短於 3 個月很多場景測不到（年底結算、稅務申報）。
保固範圍：「合約規格內的功能異常」屬保固免費修；「使用者新需求 / 法規變更 / 第三方 API 改版」屬付費維護。寫得越具體越好。
回應時限：S0 / S1 / S2 各自的回應時間與修復時間要寫死。例如「S0 4 小時內回應、24 小時內修復」。
聯絡窗口：指定的 PM、技術負責人、緊急聯絡電話，寫成清單放在合約附件。
恆遠的做法：上線後仍持續陪客人測試
業界常態是「驗收簽完、保固期開始倒數、客人有問題自己丟工單」。恆遠數位行銷的做法不一樣——上線後我們仍會主動陪客人實際操作 1-2 週，幫他們發現自己沒想到的場景，遇到任何問題隨時可以聯絡我們的 PM 或工程師窗口。這不是業界標準做法，是我們覺得應該做但少數人做的事——軟體上線那天才是真正開始用，後面才是真章。
這個做法的成本是 PM 跟工程師的時間，但換來的是客人對系統真的「敢用」。一套系統如果客人裝了不敢用、員工碰到 bug 不敢回報，最後只會躺在伺服器上吃灰，這對業主跟廠商都是雙輸。
驗收常見問題 FAQ
Q驗收沒過要不要付款？尾款卡多久合理？
驗收沒過絕對不該付尾款。合約該寫的是「驗收通過後 X 個工作天內付款」，沒過就是沒過。實務上會發生的是「部分通過、保留款」——通過的部分先驗收，未通過的列為保留款（通常 10-20%），等修完重測通過再付。這比「全卡或全付」彈性，雙方都比較好處理。如果廠商堅持要先收全款再修，這是踩雷訊號。
Q上線後發現 bug，算不算保固？
判斷標準是「這個 bug 是否在合約規格內」。如果功能寫了「訂單金額計算正確」，上線後發現算錯了，這就是保固免費修。如果是「上線後想加一個新報表」，這是新需求要付費。最常吵的灰色地帶是「需求書沒寫但業務上理所當然」的功能，這部分要看合約怎麼寫——所以合約裡的需求書要越細越好，把「理所當然」寫成黑紙白字。
QUAT 沒人會做測試該怎麼辦？要不要自己學工具？
你不用學 JMeter 或 Selenium。UAT 的「U」是 User，重點是會用這套系統的人下場用真實場景測。會計就測月底結帳、客服就測退貨流程、倉管就測進銷存。如果公司真的沒人有時間做，可以委外給 QA 顧問公司（一個專案 5-15 萬不等），但記住——QA 顧問可以幫你測技術正確性，但業務正確性永遠要你自己人測。
Q驗收 checklist 30 點全要勾完才能上線嗎？
不是。30 點裡有「必須通過」（functional 與 security 大部分項目）跟「可以協商」（cosmetic、效能微調）。建議在驗收會議前先跟廠商過一遍 checklist，標出哪些是 must-pass、哪些可以 nice-to-have。Must-pass 沒過就暫停驗收，nice-to-have 沒過列為保留款。把標準訂在前面，會議當下不會吵。
Q廠商說「我們沒做過 UAT，照業界標準做就好」，能不能信？
「照業界標準」是話術，業界沒有單一標準。你要做的是把 ISTQB 測試流程、嚴重度分級、checklist 範本拿出來，跟廠商一條條對齊「這條我們有做、那條我們沒做、為什麼沒做」。如果廠商連 ISTQB 是什麼都不知道、也提不出自己的測試 SOP，這代表他們的測試文化薄弱，建議在合約裡多加保留款比例。
Q驗收完成後多久開始保固？保固期內 bug 修不完怎麼辦？
保固通常從驗收通過日（簽收書面那天）起算，建議至少 6 個月。保固期內 bug 修不完是另一種爭議——合約要寫「保固期內每筆 bug 的修復時限」（例如 S1 7 天、S2 14 天），超過時限沒修完視為違約，可以扣保留款或啟動懲罰條款。沒寫時限只寫「保固期內免費修」，廠商可以拖到保固期結束再說「來不及修」。
Q驗收後廠商把 source code 交給我，我自己沒能力維護怎麼辦？
這是很多老闆遇到的兩難——拿到 source code 但沒人會改。建議的做法：(1) 不管會不會維護，source code 一定要拿，這是你公司的智財，存放在你公司的 GitHub 或 GitLab 私有 repo；(2) 維運可以繼續委託原廠商或另找維運廠商；(3) 同時保留一份完整的部署文件，未來換廠商時新廠商照文件能 30 分鐘把系統搭起來。詳細的 source code 交付規範可以看「軟體著作權與 source code 歸屬」那篇文章。
給找外包老闆的最後一段話：驗收做好，省掉的不只是錢
有個老闆跟我說過一句話：「我以前覺得驗收就是把功能勾一勾，後來才發現驗收做得好不好，決定我接下來 3 年要不要每天罵廠商。」這句話我聽了印象很深。
驗收這關走不好，後遺症會發酵成接下來每一次小改動都要吵架、每一個 bug 都要先確認誰的責任、每一個新需求都從 0 開始談。把驗收 SOP 走完整，省掉的是你接下來 3 年的氣力。
這篇文章的 30 點 checklist、bug 分級表、會議議程模板，都可以直接複製到 Notion / Google Docs 拿去用。如果你正在規劃一個軟體外包專案、想要一套寫進合約裡的驗收條款，聯絡恆遠數位行銷的諮詢窗口，我們可以幫你把驗收條款、UAT 計畫、保固範圍三份文件搭起來——這三份做對了，後面 80% 的糾紛都不會發生。
下一步建議閱讀
驗收條款訂進合約之前，先看 MVP 4 階段付款與驗收節點完整指南 把付款節點對齊；驗收完成後 source code 要怎麼正式交付，看 軟體著作權與 source code 歸屬；要看完整的軟體產品開發路線圖，回頭看 老闆指南：從 0 到上線打造會賺錢軟體產品。
AUTHOR
自由揚AntonyLin
想了解更多？看看我們的相關服務
相關文章
企業內網 AI 助理自架完整指南：Open WebUI / LibreChat / AnythingLLM 三條路徑 + Claude API 接入 — 中小企業老闆「不被 SaaS 鎖死」的 5 個訊號與 4 條合約替代方案
客製化系統「程式碼審計」完整指南：上線前 6 個必查項、5 個 red flag、3 個第三方審計報價區間 — 中小企業老闆驗收外包工程廠商的最後一道保險
Google Gemini 3.5 Pro 完整解析：中小企業 AI 採購 5 個訊號 + 60 天評估清單（對標 Claude Opus 4.8、GPT-5.4）
Excel 自動化教學完整指南：VBA、Power Query、進階函式、Apps Script 四條路徑 + 五個業務場景 + 三個升級訊號
進銷存自己做完整指南:Excel / Google Sheet / Airtable / Notion 4 條 DIY 路徑與 5 個崩塌訊號
留言(0)
尚無留言，成為第一個留言的人吧！