数据平台需求管理：从用户提需到评审、排期、交付与验收
“支持检索雨天场景”“帮我增加一个数据源”“把向量化速度提升一倍”，都可以进入需求池，但它们不能仅靠一个标题和一个截止日期完成交付。数据平台需要把问题背景、数据范围、负责人、承诺和验收证据串起来。
Data Flywheel 的“规划需求管理系统方案”讨论，最终明确了一个聚焦的目标：用户提需求 → 评审 → 排期 → 开发交付 → 用户验收。本文基于 2026-09-06 的代码阅读总结现有闭环，并讨论下一步如何连接数据与实验，不把它扩张成一套大而全的项目管理软件。
1. 需求不是开发任务，也不是数据处理任务
| 对象 | 表达什么 | 示例 |
|---|---|---|
| 用户需求 | 想解决的问题与业务结果 | 更快找到可用于训练的夜间雨天片段 |
| 开发任务 | 实现需求的工程工作 | 增加标签过滤接口、检索页面和权限检查 |
| 处理任务 | 一次可追踪的数据运行 | 对指定快照运行标签模型，产出结果版本 |
| 缺陷 | 已有承诺行为的偏差 | 过滤条件丢失，导出了未筛选数据 |
一条需求可以拆成多个开发任务，交付验证可以引用多次处理任务。代码完成、任务运行成功和用户验收通过，是三个不同事实。
Product Backlog 提供透明且有序的工作入口，Definition of Done 提供共同的质量约定；本文的表单和状态机是面向数据平台的工程设计，不是 Scrum 规定的固定模板。参见 Scrum Guide。
2. 提交时先描述问题，评审时确认可验收的结果
一份适合首版的需求记录可以包含：
| 字段 | 要解决的问题 |
|---|---|
| 标题、背景 | 什么问题反复发生，有何证据 |
| 期望结果 | 完成后谁的工作会发生什么变化 |
| 影响范围 | 哪些用户、项目、数据类型受影响 |
| 验收标准 | 用什么场景、指标与数据判定完成 |
| 用户期望日期 | 用户希望何时拿到结果 |
| 团队承诺日期 | 团队评估依赖和容量后承诺的时间 |
| 负责人、目标版本 | 谁推动交付，在哪次发布落地 |
| 交付说明、验收记录 | 如何使用、验证以及处理差异 |
现有 Requirement 模型已包含背景、期望结果、验收标准、优先级、期望日期、承诺日期、负责人、计划版本、交付说明等核心字段。
用户期望日期与团队承诺日期应分开保存。 把用户填写的期望直接当成开发截止日期，会让排期变成没有容量依据的承诺；修改承诺时覆盖旧值，又会让延期原因失去记录。
3. 当前实现中的状态机
以下流程与当前 requirements_api.py 的主要转换一致：创建后直接进入待评审；评审要求补充时退回 draft；暂缓需求可以重新安排进入执行。
这张图也暴露了值得完善的地方：当前允许暂缓需求直接排期；如果暂缓期间范围发生变化，建议要求先重新评审验收标准。现有转换表没有表达任意重开、取消与重新评审，这些不应被当成已经存在的功能。
后端通过动作接口执行转换，而不是允许前端随意把 status 改为 completed。当前实现检查源状态，非法跳转返回冲突；评审通过必须有验收标准，排期必须有负责人、承诺日期和版本，交付必须有说明，验收驳回必须有原因。
4. 责任与权限应跟随流程
| 阶段 | 主要责任 | 流转条件 |
|---|---|---|
| 提需 | 发起人描述问题与期望 | 信息足以进入评审 |
| 评审 | 管理者确认价值、范围与验收口径 | 通过、补充、暂缓或拒绝有结论 |
| 排期 | 承接团队确认容量与依赖 | 有负责人、承诺日期与版本 |
| 交付 | 负责人完成实现及内部验证 | 有可访问交付物和验证证据 |
| 验收 | 发起人或约定验收人确认结果 | 对照原验收条件通过或驳回 |
现有实现对普通用户的交付动作校验 owner_id，对验收动作校验 requester_id，拥有管理权限的用户存在更广的操作路径。若业务要求开发与验收职责严格分离，应进一步限制管理者代验收并记录代理理由；不能只依赖页面隐藏按钮。
“平台开发者只看到自己负责的需求”也需要在列表与详情查询实现，不能先把全量需求下发再用前端过滤。权限模型的进一步讨论见 数据平台权限管理。
5. 数据需求的验收必须固定口径
以“支持夜间雨天片段检索”为例，以下是假设的验收模板，数值用于说明写法，不代表项目实测结果：
| |
Precision@20 关注每个查询前 20 个结果中的相关比例，不能据此声称覆盖了所有雨天片段。需要评估召回时，还要建立合理的相关集合或抽样评估方法。
性能条件必须写明数据量、过滤条件、缓存状态和硬件；模型效果需要固定评测集与版本。否则评审时说的是 A，交付时测的是 B，双方仍可能都认为自己有道理。
对非功能需求也应提供证据：稳定性给故障恢复演练，权限给越权测试，成本给每千样本资源消耗。不要统一用“页面正常打开”验收所有工作。
6. 优先级、排期与范围变更
提交人的优先级表达影响感受，团队排期还要考虑影响人数、收益证据、时间窗口、实现成本、依赖和运行风险。一个简短的排序讨论通常比未经校准的复杂打分更有效。
可以先将需求分为阻断与事故修复、明确交付窗口、常规改进、探索验证四类。探索性算法需求优先设时间盒与退出条件，例如先验证样本上的可行性，再决定全量产品化。
执行中新增范围时，建议记录变更差异、原因、受影响验收项和新的承诺。不能一边持续加需求，一边仍用原日期衡量延期。
以下机制属于下一阶段建议：
- 为需求内容和验收标准建立修订历史。
- 使用乐观锁或条件更新，防止两人同时评审导致状态覆盖。
- 使用并发安全的业务编号分配，避免简单计数生成编号产生冲突。
- 将状态、活动记录与审计放在同一事务，外部通知使用可恢复投递机制。
- 补齐取消、重开、重新评审和附件访问规则。
当前已经有活动时间线，但活动日志的存在，不等于所有字段变化都有完整版本历史。
7. 把交付结果接回数据飞轮
建议让需求进一步关联下列证据链：
| |
这些关联是后续扩展方向，现有需求中心尚不能仅凭一个交付说明就自动提供全部血缘。
值得跟踪的运营指标包括：首次响应时间、评审等待时间、承诺按期率、从开始到验收的周期、一次验收通过率、驳回原因分布。定义指标时，应明确暂缓时间是否计入，已取消需求如何处理，以及承诺日期采用最初值还是修订值。
交付后还可以观察使用率、人工时间变化和模型效果，但上线前后指标不同不自动证明因果。数据分布、模型版本与评测环境变化都可能影响结果。
8. 第一版做好闭环，再扩展协作
现有需求池、详情、状态动作和时间线已经构成可讨论的基础。下一步优先完善真实用户权限、补充与修改体验、并发一致性和交付证据，再考虑子任务、依赖关系、容量计划与外部研发系统同步。
用 Commit 提交规范 关联工程变化，用 发布流程 关联线上版本，需求管理才能回答“结果是否交到用户手里”，而不只是“卡片是否被拖到了最后一列”。