需求边界不是用来拒绝客户的，而是让「改」这件事有价格、有次数、有记录。
一、「再改一下」是怎么变成无限循环的
以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。
一位独立开发者接了一个 1.8 万元的企业官网项目，约定 6 周交付。开工后，客户每周提一次「小调整」：
- 第 2 周：首页配色换一版。
- 第 3 周：产品介绍从 3 段改成 5 段，再加一个视频位。
- 第 5 周：老板觉得「不够大气」，整体重做。
- 第 7 周：又加了中英文切换。
第 9 周项目交付，他实际投入 210 小时，折算时薪 85.7 元。没有一次修改是「大改」，但没有一次修改被计价。
问题不在客户贪心，而在于开工前没有定义三件事：什么算「范围内」、什么算「完成」、超出之后按什么规则处理。
二、SOW 的五要素
SOW（Statement of Work，工作说明书）不需要写得像法律文件，但五个要素必须齐全：
| 要素 | 必须写清的内容 | 缺失后的典型争议 |
|---|---|---|
| 范围 | 做哪些页面、模块、流程，明确不做什么 | 「这个本来就应该有」 |
| 交付物 | 文件、源码、文档、部署，逐项列名 | 「你说的交付到底是什么」 |
| 验收标准 | 可观察、可复现、可判定 | 「我觉得还不行」 |
| 时间 | 起止日期、里程碑、客户配合的时限 | 因客户拖延却算你逾期 |
| 价格与付款 | 总价、是否含税、各节点比例 | 「做完一起结」 |
五要素应共同起作用：验收标准提供可核对的依据，范围、授权和争议处理说明谁能确认、出现异议怎么办；写了标准也不能保证没有争议。价格怎么定，另见从卖时间到卖结果 。
三、验收标准怎么写：可观察、可复现、可判定
三条判据：
- 可观察：不依赖主观感受，能看到具体现象。
- 可复现：换一个人、换一台设备，按同样步骤能得到同样结论。
- 可判定：结果是「通过」或「不通过」，没有「差不多」。
反例与改写：
| 反例 | 问题 | 改写 |
|---|---|---|
| 界面好看 | 主观，无法判定 | 记录 Chrome 版本、1440px 视口与 100% 缩放，首页三栏布局无横向滚动条 |
| 性能要好 | 没有阈值与条件 | 测试机型与浏览器版本固定，带宽 10 Mbps、延迟 100 ms、1000 条固定样本、冷缓存，约定工具连续测 5 次的 LCP 中位数 ≤ 2.5 秒 |
| 兼容手机 | 没说什么手机、什么版本 | 在附件列明的 iOS/Safari、Android/Chrome 版本和设备组合上，按测试步骤完成下单 |
| 代码质量高 | 无法验收 | 通过项目内 ESLint 配置，0 error；核心模块单元测试覆盖率 ≥ 70% |
| 文档齐全 | 没定义「齐全」 | 交付 README、部署说明、接口文档三份，每份含可执行示例 |
写法上有个简单模板：在（环境/条件）下，执行（操作），得到（可观测结果），误差或时限为（阈值）。 一句话里四个位置都填上，验收标准就基本可用了。交付接口或组件时，还可以用语义化版本 标注破坏性变更，把「改一下」落到具体版本差异上。
四、修改轮次：区分设计反馈与质量纠错
双方可把“包含 2 轮设计反馈”作为本项目的商业选择，轮次和时间应按范围协商，不能把它当作质量免责条件。
- 一轮设计反馈，是客户在约定窗口集中提交的偏好调整清单；收到后先确认属于原范围还是新范围。
- 对已确认规格的实现错误、漏做和未达到验收标准的修复，属于质量纠错，不因轮次用尽自动变成收费变更。
- 新页面、新业务流程或推翻已确认的设计，先评估价格和工期，再经有权人员确认变更。
- 反馈分批到达时按双方约定合并；不能用供应商自身引入的新缺陷消耗客户反馈次数。
| 请求 | 示例 | 处理 |
|---|---|---|
| 原规格未达标 | 第三次反馈同一个下单错误 | 记录复现与修复验证，按原质量义务处理 |
| 原范围设计偏好 | 已实现指定配色后又希望换色 | 按约定设计轮次判断，有争议先确认 |
| 原范围外新增 | 增加原来没有的英文站 | 评估后走变更单 |
| 验收后发现问题 | 隐藏缺陷、安全漏洞、数据异常 | 先分级止损、保留证据，再按合同与法律判断责任；不直接套“支持已到期” |
若剩余反馈混合多种类型，拆成纠错单和变更单，不能整包按新需求收费。
五、变更单的六个字段
| 字段 | 写什么 | 示例 |
|---|---|---|
| 变更内容 | 具体要加、改、删什么 | 增加中英文切换，覆盖首页与产品页 |
| 影响范围 | 涉及哪些模块、是否影响已验收部分 | 影响导航、路由与 12 个文案文件 |
| 工期变化 | 增加几天，是否影响原里程碑 | +8 个工作日，上线顺延至 11 月 14 日 |
| 价格变化 | 增加多少，是否含税 | +6800 元（含税），预付 50% |
| 生效条件 | 何时生效、以什么为凭 | 双方书面确认并支付预付款后生效 |
| 双方确认 | 签字、盖章或邮件确认 | 邮件回复「确认」并附日期 |
变更单应把新增范围、价格、时间、授权人与生效条件写到能核对的程度。它既用于项目控制，也可能成为合同变更证据；效力需结合授权、订立方式和原合同判断，不能仅靠模板名称。
六、需求确认清单
开工前逐条勾掉，缺一条就不要进入开发：
- 范围清单里每个页面或模块都有名称和一句话说明。
- 将实际不包含事项列明，不用凑数量替代关键边界。
- 每个交付物都有格式、位置和接收人。
- 每条验收标准都能回答「谁、在哪、怎么验」。
- 修改轮次与每轮时限已写明。
- 变更单模板已随合同一起发给客户。
- 客户方的决策人、日常对接人、付款人已确认。
- 客户需提供的账号、素材、数据的到位时间已写进计划。
清单过了，再进入排期。排期与周报的写法，见交付节奏、里程碑与验收 。
七、常见争议与处理
| 争议 | 典型说法 | 处理方式 |
|---|---|---|
| 口头需求 | 「上次开会你不是答应了吗」 | 及时发纪要，标注待确认事项并请求有权人员明确回复；单方写未回复视为同意不够 |
| 会议决定 | 「这是会上定的」 | 纪要里区分「已确认」与「待评估」，后者不进范围 |
| 微信语音 | 「我语音里说过了」 | 统一要求文字确认，语音转成文字后回读一遍 |
| 客户方换人 | 「新来的负责人不认之前的方案」 | 以签字版 SOW 与变更单为准，交接不作为变更理由 |
| 验收久拖 | 「再用一段时间看看」 | 先按约定送达并催告；只有具备适用法律、有效约定或交易习惯依据，才能判断沉默的效果 |
处理争议的原则只有一条：所有改变范围的决定，都要留下文字痕迹。 不是不信任客户，而是双方的记忆本来就会分叉。合同层面的条款设计，可参考合同与条款 。
八、行动清单
- 把当前项目的 SOW 补齐五要素，缺哪条补哪条。
- 挑 3 条最模糊的验收标准，按「环境-操作-结果-阈值」改写。
- 在报价里写明包含几轮修改，并定义「一轮」。
- 做一份一页纸的变更单模板，存成可复制的文件。
- 协商合理检验期、送达与异议方式；采用沉默验收约定时履行必要的提示说明，不把它当回款保证。
- 每次会议后 24 小时内发书面纪要。
- 项目结束后统计：变更单数量、额外工时、实际时薪。
使用边界与实操验收
上文的 1.8 万元、6 周、210 小时与 85.7 元时薪都是演示数字，不代表任何真实项目。真实项目要按自己的报价、工时记录和合同条款复算。
复算示例：项目总价 1.8 万元，原计划 120 小时，实际投入 210 小时，则实际时薪为 18000 ÷ 210 = 85.7 元/小时。若其中 60 小时来自 3 张变更单，每张计价 3000 元，则变更收入 9000 元，原合同对应的 150 小时折算时薪为 18000 ÷ 150 = 120 元/小时；即便加上变更收入，整体也只有（18000 + 9000）÷ 210 = 128.6 元/小时。在本组假设中，补收变更费后时薪仍低于原计划；应同时复盘初始估算和变更定价，不能认为只要有变更单就必然回本。
同样修改内容的净工作量为 W，每次重新进入上下文需要 s 小时：一次提交约为 W+s，五次提交约为 W+5s。若 W=5、s=1，则是 6 与 10 小时，差 4 小时，并不是固定 5 倍。存在相互推翻的反馈时另记返工，不能把相同工作量重复计算五次。
关键参考与核验范围
下列官方资料只支持所标明的规则。案例、价格、评分与工时为教学假设，核验日期：2026-10-22。
系列导航
- 上一篇：报价：从卖时间到卖结果
- 下一篇：交付节奏：里程碑、周报与验收
- 回到目录：一个人的服务生意：从接单、报价到产品化
- 相关阅读：合同与条款 、外包与协作的合规
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。