我们如何用敏捷做数据产品

我们如何用敏捷做数据产品

2021年三季度，我接手了一个已经跑了11个月的数据产品，面向业务线的“客户健康度评分卡”。业务方说了一句话让我记到现在：“你们的模型每次上线，我们业务策略已经换了两轮。数据是对的，但节奏是错的。”当时团队算上我一共7个人，每周都在加班，但交付的报表和标签，业务实际用起来的不到40%。复盘时发现一个致命问题：我们从数据采集、清洗、打标到输出评分，整个周期最短也要5周，而业务促销活动的决策窗口只有3天。我们用的还是瀑布流程：业务提需求→数据探查→建模→测试→上线。敏捷开发的理念在软件工程里讲了那么多年，到了数据产品这里，大家又变回了“先想清楚再做”的老路子。

后来我们用18个月时间，把整个数据产品线切成了两周一迭代的节奏，交付周期压缩到7个工作日，业务采纳率爬到了82%。这条路不是照搬软件Scrum那么简单，中间踩过数据依赖的坑、踩过模型效果无法快速验证的坑，也重建了团队对“敏捷”两个字的理解。这篇文章，我想把这18个月的真实判断、取舍和工具落地的细节完整讲出来。如果你正在被“数据产品做不快”折磨，希望它能帮你少走一年弯路。

一、核心结论：数据产品的“敏捷”，首先是验证假设的速度，其次才是研发速度

在软件工程里谈敏捷，大家默认追求的是更快地交付可用功能。但数据产品有一个根本差异：它的“可用”不是由功能完整性决定的，而是由“数据结论是否可信、是否可解释、是否在业务时间窗内可行动”决定的。换句话说，你就算三天搭出一个BI看板，如果上面的指标口径业务不认、数据延迟超过决策窗口、或者无法追溯到业务动作，这个产品仍然是废的。

因此，我们内部后来把数据产品的敏捷重新定义为一句话：在可接受的置信度下，用最短的周期验证一个数据假设能否驱动业务动作。这句话拆开有四个关键约束：

• 可接受的置信度：不需要100%精准，但必须划定最低基线。比如客户流失预警模型，我们内部约定第一次迭代AUC不低于0.68即可进入业务测试，但必须交付配套的误判率说明。
• 最短的周期：不是指开发快，而是从业务提出问题到拿到可行动的中间结果，这个闭环要足够短。
• 验证数据假设：每一次迭代必须产出可证伪的结论。比如“会员沉睡的原因是复购品类集中度高于70%”，如果数据不支持，这个迭代也算成功，因为它阻止了错误的产品方向。
• 驱动业务动作：交付的不是报表，是一个业务可以立刻执行的规则、标签、阈值或预警。

有了这个共识，后续的流程设计、工具选型、迭代节奏才有了统一锚点，而不是在“是不是要写PRD”“要不要做每日站会”这些表面问题上内耗。

二、真实场景还原：我们是怎么被“数据”拖垮的

做数据产品的人，最怕听一句话：“你们的数据不对。”但在敏捷落地之前，我们团队几乎每个月都会被业务挑战一次。矛盾不是出在模型精度上，而是出在三个环节的断裂。

1. 需求传递的断裂：业务说“我想要用户画像”，实际要的是一个规则引擎

业务方第一次提“用户画像”需求时，我们按常规理解，交付了一套包含人口属性、消费偏好、活跃度的标签宽表，花了4周。业务拿到后反馈：“怎么没有‘是否即将流失’这个标签？”我们问为什么一开始不提，对方说：“我以为画像是包含所有东西的。”这类问题反复出现后，我拉了一份数据：2021年我们共收到41个中等以上规模的数据需求，其中19个在首次交付后需要大幅返工或重新定义口径，返工比例高达46%。

根本原因不在于业务方说不清，而在于我们用一种“交付静态数据集”的思维去对接一个“动态决策需求”。敏捷解决这个问题的办法不是让业务写更好的PRD，而是把交付物从“完整数据产品”拆成“最小可行数据切片”，让业务在第一个切片出来时就能介入纠正。

2. 数据准备的断裂：等一份测试数据要5天，迭代节奏无从谈起

另一个隐秘的拖累来自数据本身。开发一个用户分层模型，从提出假设到可以开始特征工程，中间要等数据仓库出样本集、做脱敏、做历史数据回放。我们踩过最极端的案例，是让一个算法工程师等了整整一周的“用户近90天交易流水”，原因仅仅是生产数据需要安全审批和手动导出。

后来我们才意识到：做软件敏捷，通常假设“环境”是现成的；但做数据产品的敏捷，必须把“数据环境的敏捷供给”作为前置工程来建设。我们花了将近三个月搭建内部数据沙箱和脱敏流水线，才把测试数据准备时间从平均5天压到4小时。没有这个底层重建，上面的Scrum跑得再标准也是空转。

3. 效果验证的断裂：模型上线了，但业务动作无法归因

2022年初，我们上线了一版流失预警模型，运营团队基于模型圈选了30万人发优惠券。复盘时发现，这组用户的留存率与随机对照组相比只提升不到1个百分点，且统计不显著。问题出在模型给出的“高风险”用户中，有相当一部分已经在近7天内没有活跃行为，即便不发券也会沉默。我们缺乏一个快速验证的回路，模型上线后要等运营跑完全量活动才知道效果，一个周期又过去了两个月。

这个教训让我们后来强制要求：每个数据产品迭代必须包含一个可执行的验证方案，包括对比组设计、观察周期和最低样本量，并且在迭代计划中就把验证方案的开发视为“用户故事”的一部分。

三、拆解四大常见误区

在帮助兄弟团队落地敏捷数据产品的过程中，我发现以下四个误区反复出现，几乎每个团队都会踩中其中两个以上。

1. 把“敏捷”理解成“不用写文档，直接开干”

很多数据团队一说要敏捷，第一反应是把需求文档砍掉，直接开Jupyter Notebook探索数据。结果每个人都变成了“散兵游勇”，算法工程师跑了一周，发现取数逻辑错了；数据开发按自己的理解清洗，最后指标口径和业务报表对不齐。

数据产品不能砍掉需求文档，而是要换一种轻量级的需求载体：用户故事+验收标准+数据口径字典。我们在PingCode里规定，每一个数据需求必须用统一的用户故事模板录入，其中“验收标准”必须明确到字段级别，例如“用户近30天交易笔数（剔除退款），取值窗口为T-30至T-1”。这一点后面会详细展开。

2. 把“迭代”等同于“把一个长周期任务切成几段”

一个反例：团队计划做一个商品推荐引擎，把步骤拆成“数据ETL→特征工程→模型训练→在线服务→AB测试”，然后分配在四个迭代里，每个迭代两周。看起来是敏捷，实际上还是瀑布，因为业务方要等到第四个迭代结束才能看到推荐结果。真正的敏捷迭代，是每个迭代结束时都产出一个业务可感知的增量。比如第一个迭代交付离线Top100热榜推荐，第二个迭代加入协同过滤，第三个迭代接入实时行为流。业务能从迭代1就开始用起来，并且用反馈影响后续迭代的优先级。

3. 认为只要站会了、看板了就是敏捷

团队引入了PingCode的迭代看板，每天也站着开会，但三个月下来交付速度没有改善。我旁听他们的站会，发现发言基本是“昨天在做特征选择，今天继续做”。这种站会没有暴露阻塞项，也没有形成对迭代目标的聚焦。数据产品的站会需要额外增加一个环节：同步数据质量异常。比如“今天发现昨天导入的一批埋点数据有30%空值，需要数据开发协助排查，会阻塞模型训练”。只有把数据特有的不确定性纳入站会议程，“站会”才算真正服务于数据产品的迭代推进。

4. 把数据质量问题留到最后再修

软件功能开发可以允许先做出来再优化性能，但数据产品不行。一条错误数据进入训练集，模型上线后造成业务误判的代价远大于一个前端按钮的样式问题。我们曾有一版货品销量预测，因为特征里包含了上架时间（月份），模型在春节期间置信度断崖式下跌。如果我们在每次迭代中引入了数据质量监控指标（如特征分布漂移检测），这个风险在模型开发时就能被发现。所以现在我们的“完成定义（DoD）”里，数据质量校验是一项硬性通过条件。

四、专业判断逻辑：数据产品的敏捷需要重构“三流”

复盘我和多个数据团队的敏捷实践，影响数据产品能否真正提速的，不是站会、看板、或某种流程仪式，而是三个底层的“流”是否被打通。

1. 数据流：在“快”与“准”之间建立分级响应机制

不是所有数据场景都要求100%精准。我们将数据产品的用户故事按数据精度要求分成三级：

这个分级让迭代规划有了“灵活性开关”。L1级需求可以在迭代中优先交付，用低精度数据快速给业务一个方向判断；L3级需求则必须排到数据质量链路彻底验证之后。我们曾经让一个L1级的会员人群探索需求，在两天内就用现有宽表+手动抽样给出了结论，帮助业务在一周内调整了活动策略，而如果等L3级的数据准备，需要三周。

2. 价值流：每张数据表必须回答“然后呢”

数据团队容易陷入一种产出幻觉：这个月做了30张表、15个标签、4个模型。但业务实际用的很少。我们后来在需求评审时加入一个必答问题：“这个数据交付后，业务接下来会干什么？”答不出来的需求，优先级直接降级。这个简单的规则，让我们砍掉了近三分之一的低价值数据需求，把释放出来的产能投入到几个明确驱动业务动作的模型上。

3. 决策流：让业务在迭代待办列表里有投票权

传统模式里，数据团队按自己的技术路线图排优先级，业务只能被动等待。我们改用PingCode的史诗-特性-用户故事结构来透明化整个需求池，并且每两周一次的需求梳理会，业务负责人都必须参加，现场对用户故事进行优先级拖拽排序。这种可视化的决策流让业务第一次感受到“排期不是黑盒”，他们开始理解数据产品的每个功能背后是一个投入产出决策，也因此更愿意配合提供业务经验来提升模型效果。

五、案例实践：用PingCode落地数据产品Scrum，我们从失控到可控

工具不是万能的，但没有一个适配的工具，敏捷数据产品的实践会以Excel和微信群管理告终。我们团队从2022年二季度开始全面采用PingCode来承载整个敏捷流程，下面从六个场景展开具体操作。

1. 需求管理：用史诗-特性-用户故事实现三级透明

我们把整个数据产品线的愿景抽象成史诗（Epic），例如“客户全生命周期价值经营”；下面分解为多个特性（Feature），如“高价值客户识别”“流失预警”“交叉销售推荐”；每个特性再拆分为本轮迭代的用户故事（User Story）。产品负责人（通常是数据产品经理）在PingCode中为每个故事设定业务价值和优先级，所有的数据工程师、算法工程师都能在一个界面里看到“当前最高价值的需求是什么”，而不是凭自己的技术兴趣做探索。

更重要的是，我们在用户故事里强制嵌入了数据产品的特定字段：数据源、更新频次、SLA时间窗、验证方法、口径字典链接。一开始团队抵触，觉得太死板。但坚持执行两个月后，大家发现跨迭代的沟通成本急剧下降，不再需要每次迭代开始时重新对齐“上次那个表的逻辑是什么”。

2. 迭代规划：故事点估算代替工时，用数据度量复杂度

数据产品的工作量很难用传统工时估算，因为数据清洗、特征工程、模型调优的不确定性极高。我们采用了故事点估算，但做了适配：不是一个故事点等于半天，而是用“数据不确定性”作为参照标尺。团队共同定义了一个基准故事，例如“从已有清洗好的宽表中直接取数做一张单维度分布报表”，为1个故事点。然后其他用户故事通过与这个基准的比较来估算。比如一个需要新建特征工程逻辑但数据质量已确认的用户故事，通常是3个点；而一个需要从头探查新数据源并清洗的，可能达到8个点甚至被建议拆分成更小的故事。

在PingCode的迭代计划会议上，团队打开待办列表，由产品负责人讲解高优先级需求，大家现场估算故事点，并决定纳入本次迭代的故事量。一般控制在30点左右（团队7人两周迭代），这个容量是经过四个迭代的数据观测后才稳定下来的。

3. 迭代开发：用任务板透明化“数据阻塞”状态

日常开发中，我们不是让开发人员自己随便认领，而是将PingCode中的用户故事进一步拆分为具体任务（如“抽取交易流水表”“构建RFM特征”“训练基准模型”“编写验证SQL”），每个任务明确负责人，并关联到相应的代码仓库和CI/CD流程。当一个任务因为上游数据未到位而阻塞时，任务直接挪到“阻塞”列，并在站会上自动成为焦点。

这里有一个被证明特别有效的细节：我们让数据工程师和算法工程师的任务在同一块看板上可视化，而不是分开管理。过去两个岗位的工作脱节严重，数据工程师认为清洗完并推送到数仓就结束了，算法工程师却发现字段含义不明确还得回去找。两个角色的任务在一个看板上流动时，依赖关系一目了然，交接时间从之前的“一两天问一次”变为了小时级的即时沟通。

4. 站立会议：围绕迭代目标展开的15分钟

我们用PingCode打开迭代任务板，由Scrum Master主持，轮询三个问题：昨天完成了什么，今天计划做什么，有什么阻塞。但在数据产品的站会里引入了第四个问题：“有没有昨天还正常、今天发现异常的数据现象？”，比如某个埋点突然缺失、某个第三方API返回超时、特征分布出现可疑漂移。这些小异常往往是迭代失败的前兆，提前暴露给我们争取到了反应时间。例如有次发现APP端新版本升级后某事件埋点上报率下降了12%，我们在一天内就定位并修复，如果等到迭代评审时才发现，会直接导致两周的工作结果不可信。

5. 进度跟踪：燃尽图和关键风险预警的配合

PingCode的迭代概览提供了两种可视化：待办事项燃尽（基于故事点）和用户故事点燃尽。我们更关注后者，因为一个用户故事如果只是浅尝辄止而没有真正完成所有验收条件，故事点不能算完成。燃尽图如果连续三天理想线偏离超过15%，Scrum Master会启动一次快速回顾，判断是估算不准、还是出现了未预见的阻塞。

另一个我们自定义的风控措施是“迭代中数据质量红灯”：每次迭代中期，我们会自动运行一组数据质量校验脚本，如果任一核心数据表的数据完整率或延迟SLA突破阈值，直接在该迭代任务板上亮红标，所有受影响的故事评估是否降级或延期。

6. 评审与回顾：让业务参与进度的“双重闭环”

每个迭代结束后，我们邀请业务方参加评审会议，由团队成员演示当前迭代完成的数据产品切片，比如一个新的人群标签、一张自动化报表、或一个预测模型。业务可以当场提供反馈，这些反馈不是散落在聊天记录里，而是直接录入PingCode的待办列表，作为下一个迭代的输入。评审之后紧接着是回顾会议，只限团队内部，聚焦“做得好、做得不好、改进计划”，记录在迭代回顾板上形成行动项。我们有一条铁律：每次回顾至少产出一个可执行改进，并指定负责人和检查时间。比如“下次迭代所有L2级以上需求必须在规划时提供样本数据预览”，或“引入自动化数据质量扫描工具”。

六、行动建议：分三步把敏捷装进数据产品团队

根据多个团队的实施经验，我总结了一套最低启动成本的渐进路径：先定义可验证的最小单元，再搭起需求的骨架，然后工具固化流程。

1. 先定义最小可行数据产品（MVDP）

不要一上来就想做完整的“客户360画像”或“智能营销平台”。找到一个业务当前最痛的一个决策点，定义“这个数据产品的最小可用形态是什么”。我们第一次尝试选的切入点是“高价值客户识别标签V0.1”，仅定义一个复合指标（近90天消费金额>P90且活跃天数>15天），不要模型，不要UI，产出一个离线表。这个MVDP从提出到交付给业务只用了4天，业务立刻能用来做短信推送。收到正向反馈后，才在下一个迭代中加入LTV预测模型、流失风险修正等高级逻辑。

MVDP必须满足三个条件：一是有明确的业务动作可触发；二是数据既有链路能支持，无需新建大数据管道；三是效果可在两周内通过业务指标观测到。

2. 建立数据需求的“用户故事地图”

MVDP验证成功后，整个团队对产品全景有了初步共识。接下来用一场两小时的Workshop，和业务一起绘制用户故事地图。从左往右是用户（业务方）完成一个完整决策流程的步骤，从上往下是每个步骤所需的数据能力和优先级。我们第一次画故事地图时，发现业务“决策流程”居然有7步是我们之前完全不了解的，于是当场把两个低优先级的技术模型需求从待办列表底部提到了顶部。

这张地图直接导入了PingCode，成为史诗和特性的拆分依据，让后续的迭代规划不再由技术驱动，而是由业务决策链条驱动。

3. 用PingCode透明化迭代过程并持续度量

流程稳定后，引入可量化的敏捷度量指标，而不是凭感觉判断团队效能。我们目前在PingCode中固定监控四个指标：

• 需求交付周期：从用户故事进入迭代到满足验收标准的时长。目标是中位数控制在7天以内。
• 迭代目标完成率：计划的故事点中实际完成的比例。低于70%说明估算或外部依赖有问题，高于95%可能意味着故事点被低估。
• 业务采纳率：迭代交付的数据产品功能中，被业务实际应用到决策中的比例。这是验证数据产品价值的终极指标，低于60%就要回溯需求评审环节。
• 返工比例：因口径或逻辑变更重新打开已关闭故事的比例。这是衡量“第一次就做对”能力的反向指标。

这些数据每个迭代都在PingCode的报告面板中自动聚合，团队回顾时直接看数据，而不是靠回忆。

七、不同场景下的取舍：没有一个方案适用所有团队

敏捷数据产品的实践不是教条，我在不同规模的团队和产品形态中观察到必须做的取舍。

1. 小团队（10人以内）vs 大组织（多个数据团队并行）

小团队的敏捷可以更激进。我们初始7人团队实践的是全功能小队模式，每个迭代里数据开发、算法、产品经理都在同一个迭代周期内完全对齐，站会和评审都很轻量。但在大规模组织中（比如我后来协助的一个集团数据中台，涉及三个数据开发组、一个算法组、两个业务分析组），必须引入Scrum of Scrums机制，并且用PingCode的多团队视图来管理跨组依赖。大规模场景下，用户故事的颗粒度需要重新约定，避免出现“一个故事跨三个迭代依赖三个团队才能交付”的情况。我们的做法是强制要求一个故事必须能在一个迭代内由单一团队独立完成，如果不能，就拆解到更小颗粒度。

2. 自研数据产品 vs 对外商业化的数据产品

自研场景下，业务方就是内部运营，反馈回路短，可以容忍比较频繁的口径调整和模型迭代。但如果是做对外商业化的数据SaaS产品，比如给客户提供行业洞察报告或者数据API，敏捷的迭代节奏要更加谨慎。外部客户不会接受“本周API返回值含义改了”这种变化。这时候我们的实践是双轨制迭代：内部保持两周一个数据模型研发迭代，但对外的接口和数据结构变更收敛为四周一次，并提前两周发布变更通知。PingCode中通过自定义标签区分“内部”和“外部”两类用户故事，两者在不同的发布火车上。

3. 有强合规要求的行业 vs 互联网轻监管场景

金融、医疗等强合规行业，数据产品敏捷面临的最大约束是“数据不出域”和“脱敏规则”。我们在一个银行合作项目里的变通做法是：把脱敏和合规审查从“上线卡点”变成“迭代内建流程”。每个用户故事的“完成定义”里增加了数据安全评审单，由安全团队在迭代中期进行预审，而不是等上线前一次性评审。虽然增加了单迭代内的流程成本，但避免了最终上线被一票否决的巨大风险。

八、总结：敏捷不是目标，而是更快找到“不做错”的方法

用敏捷的方法做数据产品，最大的改变不是团队写代码变快了，而是我们终于建立了一套机制，可以让团队在投入大量资源之前，就用尽可能低的成本去验证一个数据假设是否值得做。我不再要求团队“一次性跑通全量数据”，而是允许先用1000条样本得到一个方向性结论；不再要求模型上线必须A/B测试显著打正，而是要求每个迭代必须产出一个可验证的业务命题。这个转变，让数据产品从“半年憋一个大招，结果可能歪了”变成“每两周校准一次方向，小步快跑”。

如果你也在推动数据产品的敏捷转型，下面三步是下周就可以开始的：

1. 选定一个当前业务最痛、数据就绪度最高的场景，定义它的MVDP，并承诺在7个工作日之内交付。不要选大而全的，选最小的可行动单位。
2. 用一个工具（PingCode或类似的）把所有需求透明化，从职责模糊的Excel转移到可视化的史诗-特性-故事结构中。第一周只做录入和优先级排序，不要急着开站会。
3. 在第三个迭代时引入效用量化指标，特别是“业务采纳率”和“返工比例”，用数据证明敏捷的价值，才能争取到更多团队的信任和资源。

数据产品最怕的不是做得慢，而是一直做得很快，却一直在做错的事。敏捷帮我们解决的，恰恰是最后这个问题。