追加功能、變更報價與版本管理
將修正、規格澄清同新增功能分清楚，每次改動記錄成本、時間、依賴及驗收影響。
作者：WeTech 技術團隊 · 內容更新： (香港時間（GMT+8）)
軟件變更應先對照已確認需求，說明改動原因、受影響功能、成本、時間及測試，再由授權人決定。口頭要求唔應直接變成默認承諾；批准後更新需求及交付版本，修正原有缺陷亦唔應混入增項收費。
適合哪些情況？
適合開發中經常加功能、報價範圍爭議，或要安排分期交付嘅企業。
變更申請最少欄位
| 項目 | 需要內容 | 決策用途 |
|---|---|---|
| 原因及基準 | 原需求、問題同目的 | 分清修正或增項 |
| 影響 | 角色、資料、畫面及接口 | 識別依賴同風險 |
| 報價與排期 | 工作量、費用及里程碑 | 批准、延期或換範圍 |
| 驗收及版本 | 測試、移交及回復 | 確認何時算完成 |
先分清係咩類型改動
原需求清楚但未做到，通常屬符合性問題；需求有歧義要共同澄清；加入新角色、規則或接駁則可能係範圍變更。判斷要引用原版本及驗收條件，唔係按邊個提出要求決定。
比較延後、替換同新增
每個新增要求列出不做、下期做、替換原功能或本期增加嘅影響。排期要考慮資料、測試及使用者培訓，不能只估改畫面時間。已批准範圍改動由同一授權人簽收。
交付版本要對得返
把已批准申請連到需求、工作項、測試及發布紀錄。上線前核對哪些變更已包含、哪些延期；如涉及資料結構，先列搬遷及回復安排，避免操作文件同正式版本唔一致。
假設情境
假設報價工具開發中新增第二層批准，先核對現有角色、通知、測試同文件影響，再決定替換其他功能或延後。唔單以「加一個按鈕」估工。呢個係假設例子。
常見問題
所有改動都要收費？
按合約及原需求判斷，原有缺陷同新增範圍要分清楚。
小改動可否口頭處理？
可用簡短紀錄，但仍要讓負責人確認內容同影響。
敏捷開發就毋須範圍？
仍要有優先次序、每期目標同可驗收工作，改動要透明。
品牌與公開案例範圍
WeTech Consulting（亦稱 WeTech／WeTech AI HK）提供香港 AI 與 IT 顧問服務。WeProperty HK 與 WeCredit HK 為自行開發產品，公開案例只支持所列可觀察功能。WeProperty 展示樓盤、屋苑與成交參考入口；WeCredit 展示提交、審核及公開資料遮蔽，唔構成 TU 信貸評級或最終事實裁定。
參考來源
官方文件用於核對技術、風險及量度概念；本文清單、估算方法與合成例子為 WeTech 規劃建議，並非官方定價或客戶成效。工具方案及條款以供應商當時版本為準。來源查閱： (GMT+8)
相關閱讀
一起梳理你的業務需求
提供現有流程、使用系統與目標，我們會先了解範圍，再討論交付、驗收與報價。
預約免費初步諮詢了解服務