第 12 章 · 会议、拆解与变更的闭环

让节拍真正转起来

上一章给了阶段和节拍的框架，但框架不会自己转。让它转起来，靠三样具体的战术动作:开对会、拆对任务、管住变更。 这一章把这三件事讲透——它们是 FDE 每周实操里花时间最多、也最容易做走样的部分。

很多团队一说「敏捷」就开一堆会,反而把节拍拖垮。FDE 小队要的不是多开会,而是每场会都有明确的目的和产出。围绕一个周节拍,真正必要的会就这么几场:

注意几点:周会尽量短、聚焦;失败样本复盘可以直接并进周 Demo,不必单开;真正重的只有 Kickoff、门禁评审和阶段复盘这几场「关口会」。判断一场会该不该开,就看它有没有一个明确产出——没有产出的会,砍掉。

一个场景需求(比如「差评聚类预警」)是没法直接开工的,它太大、太笼统。FDE 的一项核心手艺,是把它拆成一类类具体、可分派、可完成的任务。

一个好用的拆法,是按「任务类型」切:

按类型拆有两个好处:一是不漏——尤其权限任务和评估任务,是新手最容易忘、上线时最容易爆雷的;二是好分派——不同类型的活可以对应到小队里不同的帽子(第 4 章)。

拆完的每个任务,都应该小到「一两天能做完、且能验证做没做完」。太大的任务要继续拆,否则它会变成一个永远显示「进行中」的黑洞。

每个任务还要写清 Definition of Done。一个任务只有同时满足三条，才算完成：

例如「完成评论分类提示词」不是一个好完成定义；「分类提示词 v0.3 已提交，Golden Dataset 回归准确率 82%，高风险样本 0 漏报，AIBP 确认分类口径」才是。

项目一跑起来,业务方一定会不停提新想法:「能不能也加个 X」「这个能不能改成 Y」。这些想法本身是好事——说明他在用、在想。但如果随口一说就随手就做,一周的节拍分分钟被冲乱,你会永远在追着新需求跑,老需求却收不了尾。

解法是一个简单的机制:需求变更池。所有新提的东西,先进池子,不直接插队。然后给每一条分类:

分类的意义在于:它把「情绪化的临时插单」变成「有依据的排期决策」。业务方提的时候,你不说「不行」,也不说「马上做」,而是说「记下了,归到优化类,我们评估后排进合适的一周」。这既保护了节拍,又让业务方感到被认真对待。

变更入池后，还要标注它影响六要素里的哪一项：目标、数据、工具、权限、指标、路径。影响「权限」和「指标」的变更最敏感，通常要重新对齐场景卡；只是影响「工具」或「路径」的变更，可以由 FDE 在技术侧消化。

第 18 章那个「周报能不能按品类分开」的请求,走的就是这个流程——它被判为「优化」,评估后纳入当周。关键不是做不做,而是走没走流程。

会议、任务、变更,最终要拼成一个闭环,让信息能一圈圈转起来、项目能一轮轮变好:

用户反馈 / 失败样本
     ↓
归档、分类(变更池 + Golden Dataset)
     ↓
拆成本周任务
     ↓
做 → 周五 Demo
     ↓
收新反馈 / 新失败样本
     ↓
(回到起点,进入下一周)

这个闭环转得越顺、越快,项目质量爬升越快。FDE 在小队里最重要的作用之一,就是当好这个闭环的「传动轴」——保证反馈不丢、任务不漏、变更不乱,让每一周的产出都踩在上一周的反馈上。

往交付包里放两样东西:一张本周任务清单(按六类任务拆)和一个需求变更池(带五类标签)。

周清单与变更池模板见附录 E。