乐于分享
好东西不私藏

TOB 软件开发项目为什么总在 UAT 后暴雷

TOB 软件开发项目为什么总在 UAT 后暴雷

我们专注于AI交付,拥有全流程工作流,让想法变成可验证、可上线的结果。

一句话先说清楚

国内多数 TOB 软件项目,做不了真正的敏捷,也套不上标准瀑布。

最后落进一种很熟悉的坑:阶段瀑布 + 客户延迟参与 + UAT/上线后集中暴雷

问题不在客户「事多」,在于项目默认 UAT = 验证通过

实际上 UAT = 需求第二次暴露期


先看典型路径

阶段
实际发生了什么
合同范围
签字时说得清楚,执行时慢慢模糊
多阶段内部开发
团队闷头干,客户基本不参与
集成测试
内部自嗨,问题还没暴露
客户 UAT
第一次认真看
问题清单
缺陷、优化、变更、新增——很多客户不认账
上线
赶工期,先上
真实使用
第二次认真用
,又一波问题
团队
继续扛成本,双方开始博弈

客户的心理其实合理:没上线前不上心,用了才知道要什么。

但交付方如果还按「UAT 过了就该上线」来预期,这个项目到客户侧几乎必然变成博弈战。


给这种困境起个名

阶段瀑布

项目大、周期长、客户又急。

PM 就会拆阶段上线——先上最核心的线下痛点,其余排后面。

看起来像迭代,本质是 按阶段切片的瀑布

延迟参与

没上线,客户不上心。

UAT 或上线后,才真正开始提需求、提问题、提变更。

从管理视角看,客户属于延迟参与——不是恶意,是 TOB 的常态。

集中暴雷

如果不做管控,团队把时间耗在「表面问题处理」和「内部推责」上。

UAT 后期、上线后,反馈像开闸一样涌进来。

没有池子、没有认定、没有成本账——暴雷只是时间问题。


AI 时代,为什么更需要这套流程

很多人有个直觉:AI 写代码快了,是不是可以更敏捷地响应客户?

是,也可以更危险。

AI 让「做」变便宜了,但没有让「该不该做」变便宜。

以前客户提 50 条反馈,开发排期就卡住了——客观上有一层缓冲。

现在 AI 辅助开发,改一个页面、补一个接口,可能半天就搞定。

如果没有 反馈池 → 内部认定 → 客户确认 → 再排任务 这条闸:

  • 客户说的,当天就进代码
  • 无偿工时悄悄涨,合同内实际悄悄超
  • 团队越「响应快」,项目越「看起来在失控边缘跑」

所以 AI 时代不是不需要流程,是需要更轻、但更硬的流程。

这套飞书五表链路,解决的就是三件事:

问题
怎么解
敢不敢收客户问题
敢。先进反馈池,不等于立刻做
成本会不会失控
会,除非所有投入只认工时登记表一张账
AI 快不快得起来
快。认定后的任务才交给 AI/开发,返工有归属

不是少收反馈,是把反馈从「口头任务」变成「可统计的数据」。

AI 可以帮你:整理客户原话、生成认定摘要、从反馈池批量归类、汇总三本账报表。

但 认定权、做不做、算不算无偿——必须留在人手里。


管理目标要对齐什么

不是「零变更」,是 变更可控、成本可见、下期有数

  1. 每个阶段留下可追溯、可统计的记录
  2. 变更先进池子,先认定,再决定做不做
  3. UAT 产出问题清单 + 认定结果,哪怕客户不认
  4. 当期能控多少控多少,更要为下期报价攒数据

四条线:反馈怎么流,任务怎么生

很多团队把客户说的,直接变成开发任务。

成本就从这里失控。

应该拆成四条线——客户/测试/现场反馈 → 反馈池 → 内部认定 → 分流

铁律:反馈 ≠ 任务。

客户说的必须先进反馈池,PM 认定后才生成任务。


范围基线:立项时就要钉死

立项时在 项目主表 写清两样东西:

  • 合同范围摘要
    :做什么、不做什么
  • 合同工时(人天)
    :报价/立项锁定,不轻易改

后面所有「要不要做」「算不算合同内」,都回来看这两行。


总体架构:五张表

序号
表名
职责
1
项目主表
项目信息、合同工时、成本汇总
2
阶段产物表
每阶段交付什么、产物状态
3
任务表
执行进度、计划工时
4
反馈池
UAT/上线问题与变更的 唯一入口
5
工时登记表
实际工时与无偿成本的 唯一来源

数据关系一句话:

  • 反馈池 认定后 才生成任务
  • 任务 关联 阶段产物
  • 工时登记 挂任务或挂反馈(UAT 返工常挂反馈)
  • 项目主表 汇总 上面所有表

核算模型:工时三本账

合同工时(立项填一次,不轻易改)          ↓ 对比计划工时(任务表计划工时之和)          ↓ 对比实际工时(工时登记表之和)          ↓ 拆分├─ 合同内实际 = 实际 - 无偿└─ 无偿工时(登记时或认定后标记「是否无偿=是」)

项目主表自动算出:工时偏差、无偿占比

PM 每周看一眼,比开十次复盘会管用。

无偿不是不能给,是不能「给了还不知道给了多少」。


各表干什么(手册段)

项目主表

管项目全貌和成本汇总。

核心字段:当前阶段、合同范围摘要、合同工时、实际工时、无偿工时、合同内实际、工时偏差、无偿占比。

阶段选项:需求 · 设计 · 开发 · 集成测试 · UAT · 上线 · 质保 · 已结项

阶段产物表

每个阶段必须留下什么,提前预置。

阶段
建议产物
需求
《需求规格说明书》《需求确认签字》
设计
《设计文档/原型》
开发
《可部署包/分支说明》
集成测试
《集成测试报告》
UAT
《UAT 问题清单》(链到反馈池视图)
上线
《上线确认单》《上线问题清单》
质保
《质保问题汇总》

UAT 的问题清单不是 Word 附件——是反馈池的一个筛选视图。

任务表

只放 认定要做 的事。

推荐视图:看板(按进度)、甘特(按日期)、分组(按项目→阶段)。

从反馈池转入的任务,来源反馈 字段必填——可追溯。

反馈池

全项目最关键的一张表。

核心字段:来源、类型、是否要处理、是否无偿、客户是否认、关联任务、认定备注。

类型认定速查:

类型
典型情况
默认是否无偿
缺陷
不符合已确认需求
否(合同内)
优化
能用但不够好
多数「是」或谈认
变更
原需求范围内调整
看合同
新增
合同外新功能
默认「是」,需客户认
咨询
不会用、操作问题
一般不计开发工时

推荐视图:UAT 视图、看板(按是否要处理)、无偿视图。

工时登记表

所有成本只认这一张表。

场景
关联
是否无偿
正常开发/测试
关联任务
UAT 返工
关联反馈
按反馈池认定
尚未认定
关联反馈
待定,认定后改

建议给全员开 表单视图,每周五扫码填报。


全生命周期怎么跑

立项(主表 + 合同范围 + 合同工时)  ↓预置阶段产物清单  ↓开发阶段(任务表 + 计划工时 + 产物更新)  ↓集成测试通过  ↓UAT → 批量进反馈池  ↓内部认定会  ↓对客沟通 → 记录「客户是否认」  ↓「要做」的进任务表 + 登记工时  ↓上线  ↓上线后反馈 → 仍走反馈池 → 内部认定会(同一套流程)  ↓质保期 → 同一套流程  ↓结项复盘 → 对照工时三本账

上线不是终点。上线后、质保期的反馈,和 UAT 走同一条路。


为什么敢一直收客户问题,成本还能控

靠的不是「少做」,是 三道闸

第一道:反馈池。 所有声音先进池,不直接进开发。

第二道:认定。 合同内 / 超范围 / 不做 / 排下期 / 无偿——每条有结论。

第三道:工时账。 做了就登记,无偿单独标记,主表自动汇总。

客户可以一直提。

团队也可以一直收。

但「收」和「做」之间,永远隔着认定。

AI 时代开发更快,这道闸反而要更硬——不然你会用 AI 的速度,把无偿工时刷到爆表。


飞书模板

五张表的完整字段清单、单选选项、公式配置,我都做成了 飞书多维表格模板,复制就能用。

文章里不逐字段展开了——太长,也没必要。

想要模板的,后台回复「飞书模板」或私信我,发你链接。


收个尾

TOB 项目暴雷,很少是因为团队不努力。

多半是因为 把 UAT 当终点,把客户反馈当任务,把成本当感觉

改认知就一句:

UAT 不是验收通过,是需求第二次暴露期。

改做法也就一句:

反馈 ≠ 任务。所有成本,只认工时登记表。

AI 让交付更快了。

流程不是拖慢你,是防止你用 AI 的速度,把项目跑飞。

3104字 //End

yalo

AI交付 · 全流程工作流实践
AI交付|工作流|需求到上线|可验证结果