科技券 MVP 项目范围控制与变更申请模板
科技券（TVP）以「3:1 配对」资助企业采用科技方案，单次项目可获 港币最高 10 万元 项目资助（具体上限以官方最新公布为准）。对企业而言，资金到账只是开始——如何在 6 个月 内完成一个能跑的最小可行产品（MVP），并在审计与终期检讨中顺利通过，才是真正的考验。
科技券项目失败案例中，「范围蔓延」（Scope Creep）排第一：客户不断加需求、团队不断做加法、项目周期不断被拖长。结果往往是交付物臃肿、预算超支、最终报告对不上账目，被要求退回资助。
本文提供一套 MVP 阶段范围控制 + 变更管理 的实战模板，帮助企业在资助申报前就锁死边界，遇到合理变更则按规范流程走申请。
一、MVP 阶段为什么要先锁范围？
MVP（Minimum Viable Product，最小可行产品）的核心是「最小」二字：用最少的资源验证最关键的业务假设。科技券审计部门在终期检讨时，看的不是「你做了多少」，而是「你交付的与批准的是否一致」。
未锁范围会导致三种典型风险：
| 风险类型 | 表现 | 后果 |
|---|---|---|
| 范围蔓延 | 客户临时增加功能、扩大用户群、改技术栈 | 预算超支、时间超期、审计质疑 |
| 范围漂移 | 项目目标逐渐偏离原审批方案 | 审计要求解释，最终或被要求退还资助 |
| 范围镀金 | 团队主动加码「做更好看」 | 成本上升但价值不增，与 M&E 指标脱钩 |
在 MVP 阶段，锁定范围 + 建立变更机制 比追求功能完整更重要。
二、范围说明书（Scope Statement）模板
在项目启动会前，撰写一份 一页纸范围说明书，并由企业与供应商共同签署。这是后续所有变更的「基准线」。
建议结构
1. 项目基本信息
- 项目名称、申请编号（批准后填入）
- 企业名称、供应商名称
- 计划日期起止日
2. 项目目标（不超过 3 条）
- 用「动词 + 可验证成果」句式
- 例：「在 3 个月内上线一套 POS 系统，覆盖 2 家门店」
3. 范围内（In-Scope）清单
- 明确的功能模块
- 涉及的用户角色与数量
- 采用的技术栈与第三方服务
- 交付物清单（系统、文档、培训场次）
4. 范围外（Out-of-Scope）清单
- 明确不做的模块
- 明确不覆盖的门店、用户、设备
- 明确不包含的运维期与升级服务
5. 假设与约束（Assumptions & Constraints）
- 数据迁移范围
- 用户配合度（培训出勤、UAT 测试反馈时效）
- 第三方审批时间窗口
6. 验收标准（Acceptance Criteria）
- 与「M&E 成果指标」一一对应
- 例：上线首月活跃用户 ≥ 80% 注册用户
签署栏
| 角色 | 姓名 | 签字 | 日期 |
|---|---|---|---|
| 企业项目负责人 | |||
| 供应商项目经理 | |||
| 企业最终决策人 |
此说明书为项目的「范围基线」，任何变更都须按第三节流程办理。
三、范围变更管理流程
范围变更不是「不能改」，而是「先评估、再申请、最后批准」。以下为四步流程：
步骤 1：变更识别与登记
任一方提出新需求或修改时，须填写 《范围变更请求表》（Scope Change Request, SCR），并在 2 个工作日内 完成登记。
变更请求表核心字段：
| 字段 | 说明 |
|---|---|
| 变更编号 | SCR-001 起连续编号 |
| 提出方 | 企业 / 供应商 |
| 提出日期 | |
| 变更描述 | 要改什么？ |
| 变更原因 | 为什么必须改？ |
| 影响评估 | 对范围、时间、预算、风险的影响 |
| 备选方案 | 是否可以不改？折中方案？ |
| 建议级别 | 紧急 / 高 / 中 / 低 |
步骤 2：影响评估（由供应商完成）
供应商在收到 SCR 后 3 个工作日内 完成评估，输出：
- 范围影响：新增 / 删除 / 修改的功能点
- 时间影响：里程碑推迟天数
- 预算影响：人力、设备、第三方费用变化
- 风险影响：是否影响 M&E 指标达成
- 建议：批准 / 拒绝 / 折中
步骤 3：联合评审与决策
由企业决策方召集短会（不超过 30 分钟），按以下原则决策：
| 原则 | 含义 |
|---|---|
| 与项目目标对齐 | 改动是否服务于原始目标？ |
| 与 M&E 指标对齐 | 改动是否影响最终验收指标？ |
| 预算可控 | 改动后总成本是否仍在资助上限内？ |
| 时间可控 | 改动后是否能仍在批准周期内完成？ |
决策结果：批准 / 拒绝 / 暂缓 / 重新规划。
步骤 4：书面备案
- 批准的 SCR 一式两份，企业与供应商各执一份
- 涉及预算调整的，按科技券官方指引判断是否需要事先通知秘书处
- 所有 SCR 归档，作为 终期检讨 时的备查文件
四、变更申请的合规要点
科技券对「变更」有两类不同处理：
A. 项目细节微调（通常无需事先批准）
- 实施时间表个别阶段顺延
- 同一供应商内部项目经理变更
- 不影响预算与交付物的细节调整
B. 重大变更（建议事先与秘书处沟通）
- 增加 / 更换供应商
- 大幅修改项目目标或范围
- 预算调整（部分情况需事先通知）
- 项目延期超过原批准周期
实操建议：即使是 A 类微调，也保留完整的 SCR 档案。审计时，有据可查比口头解释强一百倍。
五、MVP 阶段的 5 条范围控制原则
| 原则 | 操作建议 |
|---|---|
| ① 先砍后加 | 立项时故意列出 3 项「不做」清单，比「要做」清单更关键 |
| ② 一页纸规则 | 任何需求超过 1 页 A4 描述，先拆解再决定是否纳入 MVP |
| ④ 二八法则 | 80% 用户价值来自 20% 功能，优先交付这 20% |
| ④ 固定里程碑 | 把时间盒（Time-box）写进合同，超时不加范围 |
| ⑤ 每周对齐 | 每周 15 分钟范围回顾会，主动暴露新需求 |
六、可直接套用的模板清单
| 模板名称 | 用途 | 触发点 |
|---|---|---|
| 《项目范围说明书》 | 锁定 MVP 范围基线 | 项目启动会前 |
| 《范围变更请求表 SCR》 | 登记每一项改动 | 任何一方提出变更 |
| 《变更影响评估报告》 | 评估时间 / 预算 / 风险 | 收到 SCR 后 3 个工作日 |
| 《范围蔓延登记表》 | 跟踪被拒绝的需求 | 每次评审会 |
| 《终期检讨范围对照表》 | 证明交付与审批一致 | 项目结题前 |
提示：上述模板均可在 1 个工作日 内用 Excel / Google Sheet 完成，不必引入复杂的项目管理软件。
结语
科技券的本质是「政府出钱，企业升级」，审计的核心是「账目清楚、范围一致、成果可验证」。在 MVP 阶段就建立范围基线 + 变更流程，不是官僚形式，而是保护企业自身——避免项目结束时面对一堆说不清的变更、退不掉的资助。
把范围说明书当作项目宪法，把 SCR 当作宪法修正案。两份文档归档齐全，审计与终期检讨时你会感谢现在的自己。
香港大全 整理了更多 香港中小企业资助计划 的申请策略、审计要点与合同模板，欢迎访问获取完整指南。
常见问答
科技券 MVP 项目的范围说明书必须包含哪些内容？
范围说明书建议包含六部分：项目基本信息（名称、企业、供应商、起止日期）、不超过三条的项目目标（用「动词+可验证成果」句式）、范围内（In-Scope）清单（功能模块、用户角色、技术栈、交付物）、范围外（Out-of-Scope）清单（明确不做的模块、不覆盖的门店或用户、不含的运维期）、假设与约束（数据迁移、用户配合度、第三方审批时间）、以及与 M&E 成果指标一一对应的验收标准。建议控制在「一页纸」范围内，由企业项目负责人、供应商项目经理与企业最终决策人共同签署，作为后续变更的「范围基线」。
项目过程中客户临时加需求，应该怎么处理？
任何一方提出变更，都应在 2 个工作日内填写《范围变更请求表》（SCR）登记，表中须写明变更编号、提出方、变更描述、变更原因、影响评估（对范围、时间、预算、风险的影响）、备选方案与建议级别。供应商收到 SCR 后应在 3 个工作日内完成影响评估，输出范围、时间、预算、风险四方面分析及「批准/拒绝/折中」建议；随后由企业决策方召集不超过 30 分钟的短会，按「与项目目标对齐、与 M&E 指标对齐、预算可控、时间可控」四项原则决策；批准后一式两份归档，作为终期检讨备查文件。
哪些变更属于「重大变更」，需要事先与秘书处沟通？
重大变更包括：增加或更换供应商、大幅修改项目目标或范围、预算调整（部分情况需事先通知，具体以官方最新公布为准）、以及项目延期超过原批准周期。此外，实施时间表个别阶段顺延、同一供应商内部项目经理变更、不影响预算与交付物的细节调整通常属于「项目细节微调」，无需事先批准。建议即使是 A 类微调，也保留完整的 SCR 档案，因为审计时「有据可查比口头解释强一百倍」。
科技券项目预算调整一定要事先通知秘书处吗？
原文明确将「预算调整」列入「重大变更」，并提示「部分情况需事先通知」秘书处，但并未给出具体阈值或金额标准。因此，是否需要事先通知，应以科技券官方最新公布的指引为准。在实操层面，建议企业在发生预算变动时同步填写 SCR，先评估对总成本是否仍在资助上限内的影响，再与秘书处沟通确认处理方式，避免事后被审计质疑。
团队总是忍不住给项目「加功能」，有哪些实用的范围控制原则？
原文列出五条 MVP 阶段的范围控制原则：①先砍后加——立项时故意列出 3 项「不做」清单，比「要做」清单更关键；②一页纸规则——任何需求超过 1 页 A4 描述，先拆解再决定是否纳入 MVP；④二八法则——80% 用户价值来自 20% 功能，优先交付这 20%（原文序号如此）；④固定里程碑——把时间盒写进合同，超时不加范围；⑤每周对齐——每周 15 分钟范围回顾会，主动暴露新需求。同时建议配套使用《范围蔓延登记表》跟踪被拒绝的需求，并在结题前用《终期检讨范围对照表》证明交付与审批一致。