写在前面：
迭代规划会（Sprint Planning）结束后，你以为项目正如火如荼地进行，但当你走进办公区，却发现气氛不对劲。
那种键盘敲击的脆响变少了，取而代之的是低声的争执和无奈的叹气。
冲突现场一：业务逻辑的迷雾
后端负责人老张正对着产品经理Linda的工位发愁：“Linda，你给的‘视频流去重’的需求，卡片上只写了一句‘用户看过的视频不能再推荐’。但这简直是个哲学问题！什么叫‘看过’？ 滑过去1秒算看过吗？点赞了但没看完算看过吗？如果用户主动去个人中心找历史记录，那个算不算？这些验收标准（AC）和技术边界都没定，根本不敢写代码。我现在按‘滑过即看过’写了，上线后你如果说不对，我这几天的逻辑全得推倒重写。”
冲突现场二：前后端的“API战争”
在另一边的白板前，前端小王和后端吵得面红耳赤。 小王：“我要的API是返回一个包含‘is_liked’（是否点赞）字段的JSON对象，你给我返回的是两个数组，让我自己在前端做匹配？这逻辑太重了，会导致页面卡顿！” 后端说：“我只负责吐数据，拼装逻辑本来就该前端做。再说你之前没说清楚你要什么结构啊！” 结果：两人都按自己的理解写了代码，一联调，完全对不上，双方都要返工。
作为PM，你看着这一切，深刻地意识到：大家都很努力，但大家都在做无用功。
问题不在于技术能力，而在于 “输入质量”。垃圾进，垃圾出（Garbage In, Garbage Out）。
在开发开始前，我们缺乏一道 “安检门”。我们允许了模糊的、未定义的、没想清楚的需求流入了昂贵的开发环节。
这一讲，我们要解决的核心问题是：
如何建立严格的DoR（Definition of Ready，准备就绪定义），对需求进行“准入安检”，防止模糊需求祸害团队。
一、 概念厘清：DoD大家都有，DoR却没人管
在敏捷圈子里，大家都很重视 DoD（Definition of Done，完成定义） ，即“做完的标准”（如代码写完、测试通过）。这控制的是出口。
但在国内互联网实战中，DoR（Definition of Ready，就绪定义） 往往被忽视。这控制的是入口。
1. 为什么要设“安检门”？
想象一下，研发团队是一台精密的“绞肉机”（比喻可能不恰当）。
- DoR 是投料口的筛子：防止把石头、骨头（模糊需求）扔进去搞坏机器。
- Sprint 是绞肉过程。
- DoD 是出料口的质检：确保出来的是合格的肉馅。
在“抖腿”项目中，前端和后端的冲突，就是因为我们把“石头”扔进了绞肉机。 代价是巨大的：
- 1倍成本： 在需求阶段改文档，只要改几行字。
- 10倍成本： 在开发阶段改逻辑，要改代码、改单元测试。
- 100倍成本： 在测试/上线阶段改逻辑，要回滚、要发补丁、要赔偿用户。
所以，PM必须立下一条铁律：不符合DoR的需求，坚决不许进入开发，谁的面子也不给。
二、 业务侧安检：AC（验收标准）是产品的法律文书
针对老张和Linda关于“视频去重”的争执，你召集了紧急会议。
你对产品Linda说：“Linda，研发不是你肚子里的蛔虫。‘看过’这个词在人类语言里很通用，但在计算机语言里必须精确到毫秒和状态位。”
1. 什么是合格的AC？
验收标准（Acceptance Criteria, AC） 必须满足 “二元性”：即要么通过，要么失败，不存在“大概”、“也许”。
你引导产品将“视频去重”的AC细化如下：
-
AC 1（时间阈值）： 只有当视频在屏幕完全可见区域停留超过 5秒，或者视频总时长的 50% （取两者较小值）时，才标记为“已看过”。（防止用户快速划过被误判为看过）。
-
AC 2（交互权重）： 无论停留多久，只要用户进行了 点赞、评论、分享、收藏 任意操作，立即标记为“已看过”。
-
AC 3（作用域）： “去重”逻辑仅在 首页推荐流（Feed） 生效。在“个人主页”和“关注列表”中，即便是看过的视频也必须能再次展示。
-
AC 4（生命周期）： 去重记录在客户端本地缓存保留7天，服务端保留30天。
当这四条AC确定后，老张的眉头舒展开了：“这就清楚了！AC 1涉及客户端计时器，AC 4涉及Redis过期策略。有了这个，需求更明确了。”
PM总结： 没有AC的用户故事，就是一张废纸。DoR的第一条标准：AC必须清晰、可测试、无歧义。
三、 技术侧安检：API文档就是契约
针对前端和后端的“API战争”，这是技术协作中经典的 “甩锅现场”。
前端认为后端懒，啥东西都要前端处理。后端认为前端笨，咋啥都需要后端处理。 解决这个问题的办法不是劝架，而是 “契约前置”。
1. 设计先行（Design First）
敏捷不代表不设计。在“抖腿”项目组，你颁布了技术DoR标准： “在写任何一行业务代码之前，前后端必须先定义好API接口文档（Swagger/YApi），并评审通过。”
你把前端和后端关进会议室：“你俩先别写代码了，先把接口格式定下来。定不下来，谁也别想出去。”
2. API评审清单
经过半小时的激烈讨论（吵架），他们终于达成了一致，并产出了一份API定义。作为项目经理，你需要检查这份契约是否包含以下要素：
-
Request（输入）： 参数名、类型、是否必填？（例如：
video_id是 String 还是 Long？） -
Response（输出）： 数据结构是平铺的还是嵌套的？（后端之前给的是嵌套，前端要平铺）。
-
Mock数据： 是否生成了Mock接口？（有了Mock，前端就不用等后端写完代码，可以并行开发）。
-
异常处理： 如果没数据，是返回
null，还是空数组[]？（这决定了前端会不会白屏报错）。
PM的安检动作：
你检查了Swagger文档，问：“小王，这个结构你确认能用吗？”
小王：“确认，虽然后端还是有点懒，但这结构我能解析。”
你：“老张，这个结构会影响性能吗？”
老张：“多查了一次表，但在允许范围内。”
你：“好，契约锁定。谁再改这个接口，谁负责请全组喝奶茶。”
PM总结： DoR的第二条标准：API接口定义完成，并经前后端双方确认（Signed-off）。
四、 资源侧安检：UI与依赖检查
除了业务和技术，还有一种情况会导致“写了一半没法写”，那就是依赖缺失。
比如，前端代码框架搭好了，结果UI设计师小美说：“那个点赞的动画特效（Lottie文件）我还没做完，再等我两天。” 小王只能干等，进度直接阻塞。
PM的安检动作： 在迭代规划会（Planning Meeting）之前，或者在Story进入开发之前，PM必须检查：
- UI/UX图： 是否所有状态（正常、报错、空状态、加载中）都有设计图？
- 素材资源： 动效文件、图标、运营配置图是否到位？
- 第三方依赖： 如果要接美颜SDK，账号申请下来了吗？Key拿到了吗？
PM总结： DoR的第三条标准：所有外部依赖（UI、素材、账号）已就绪。
五、 实战落地：建立“抖腿”项目的DoR清单
为了让这些标准落地，不流于形式，你把它们整理成了一张检查清单（Checklist） ，贴在了看板的 “To Do” 列之前。
任何一张卡片，想从Backlog移动到To Do（进入开发），必须打勾通过以下安检：
“抖腿”项目需求准入检查单（DoR Checklist）
1. 业务清晰度（产品经理负责）：
- 价值明确： 清楚说明了User Story的“So that”（业务价值）。
- AC完整： 包含正常流程、异常流程、边界条件（如弱网、无数据）。
- 无歧义： 没有使用“大概”、“可能”、“极致体验”等模糊词汇。
2. 技术可行性（研发负责人负责）：
- 架构方案： 涉及的改动点（数据库、缓存、中间件）已评估。
- API契约： 接口文档已定义，前后端已确认。
- 估算完成： 故事点数（Man-day）已评估，且不超过3人天（过大需拆分）。
3. 依赖就绪（PM/Scrum Master负责）：
- UI就绪： 关键交互稿和视觉稿已上传蓝湖/Figma。
- 资源就绪： 所有的Key、账号、文案已提供。
执行规则： 在迭代规划会（Planning Meeting）上，PM会对着清单逐一检查。如果有任何一项没打勾，这张卡片就被踢回Backlog，拒绝进入Sprint。
六、 应对挑战：当老板说“别搞形式主义，赶紧干”
新规矩刚立起来，阻力就来了。
老板看到大家在会议室里讨论DoR，有点急：“老李，这都什么时候了？还在这填表？赶紧让大家写代码啊！边做边改不行吗？”
这时候，PM必须顶住压力，用数据说话。
PM的沟通话术： “老板，我理解您想快点看到东西。但上周我们复盘发现，前端和后端有30%的时间浪费在了‘改接口’和‘猜需求’上。 我们现在花1小时把DoR定清楚，是为了后面省下3天的返工时间。 这就好比盖房子，磨刀不误砍柴工，图纸没画好就砌墙，最后肯定是要塌的。 请给我这个权限，我保证这个迭代的一次性通过率会大幅提升。”
老板听到了“省下3天返工时间”，沉默了一下：“行，那你把控好度，别讨论太久。”
七、 总结：DoR是研发团队的尊严
DoR不仅仅是一个流程，它是研发团队的尊严防线。
它标志着研发不再是“收破烂的”——随便扔过来什么垃圾需求都得接。 它赋予了研发人员 “Say NO” 的权利，硬气一把：
“对不起，产品，你的需求没想清楚，AC缺失，我不接。”
“对不起，前端同学，你的参数定义没确认，我不写。”
当团队习惯了这道“安检门”，你会发现：
- 返工率 直线下降。
- 吵架声 变少了，讨论声变多了。
- 联调 变成了丝滑的“拼积木”，而不是痛苦的“修补丁”。
这就是“想清楚再动手”的力量。
【第9讲·思考】
场景回顾： DoR建立后，团队效率明显提升。 但在处理一个新需求—— “评论区IP属地显示” 时，由于是一个很小的功能（估时0.5天），产品Linda觉得没必要写详细AC，直接口头跟后端小李说了。 小李也没走DoR流程，直接写了代码。
结果测试后发现：“为什么我在上海，显示IP在河南？” 原因：小李直接用的请求Header里的IP，没考虑用户开了代理/VPN的情况，也没做运营商基站校准。而且，产品没定义“国外IP怎么显示”，导致测试国外用户显示乱码。
请思考并回答：
- 复盘题： 如果严格执行DoR，哪一条检查项能拦住这个Bug？
- 执行题： 针对“小需求绕过流程”的现象，作为PM，你该如何修正DoR的执行规则？是所有需求一视同仁，还是设立“简易通道”？如果设简易通道，底线是什么？
下集预告：
在上一次的迭代规划里，我们面对多个干系人的“突然加塞需求”，团队在压力下依然保持了节奏，并给出了合理的取舍方案。
但问题来了：
即使我们做出了决定，团队怎么真正落地？
每天的进度如何透明？
任务是不是越来越多、越来越乱？
怎么让老板、运营、测试都能一眼看到我们到底做到哪？
这些问题的根源，其实只有一个：
你缺少一个能让所有人都“看得见”的项目进度系统。
很多人一做敏捷就先问：“我们团队到底应该用 Jira、TAPD、禅道、飞书，还是 Notion？”
但问题的关键从来不是“选什么工具”，而是：
你能否让项目中最关键的信息，快速而清晰地流动起来？
在项目真正遇到压力时，工具的差异其实远没有你想象中那样重要：
- 信息是否透明？
- 哪些事做到什么程度？
- 风险在哪里？谁被卡住了？
- 所有人是否能迅速看到关键变化？
这些才是决定项目能否推进的本质。
而“看板”之所以被很多敏捷团队采用，并不是因为它比所有工具都强，而是因为：
它降低了“开始执行”的门槛。
不用选型，不用迁移数据，不用培训，一张白板、一叠便利贴就能跑起来。
看板本质上代表的是一种态度：
不沉迷工具，而是用最低成本，让项目立即动起来。
等项目成熟后，你自然会发现：
- 团队规模变大时，Jira 更适合
- ToB 项目流程复杂时，禅道或 TAPD 管控更细
- 小团队快速迭代，用 Notion 更轻巧
- 企业全面协作，用飞书更容易打通信息
工具当然有优劣，但工具不是灵丹妙药——
它只是承载信息的容器，而不是推动项目的发动机。
所以真正成熟的团队不会纠结“哪个软件更高级”；
他们关注的是：
当下这个阶段，我们用哪个方式记录信息、同步信息、追踪信息最快？最清晰？成本最低？
透过工具看信息流
透过表象看项目本质
这才是敏捷的核心。
下一讲，我们就来拆开这件事：
如何用最简单的方式，让团队看到同一份真实的项目状态。
