敏捷第8讲：迭代规划会议——拒绝派活式管理，如何让团队心甘情愿自己认领任务？

写在前面：

就在我们准备为第二个Sprint（迭代）进行规划，按部就班地推进V1.0原有功能时，新的变化如暴风雨般袭来。

早上刚到公司，运营负责人快步走过来，满脸通红：“老李！刚谈下一个搞笑网红，叫‘鸡你太美’（化名），已经火了两年半，他有25万粉丝！愿意给我们独家内容！但有个条件——下周就要看到他的内容在我们的App里上线，而且要有专属的‘网红频道’！ 如果做不到，他就签竞品了！”

紧接着，老板的消息在微信上闪烁：“老李，投资方下周二来访，希望看到‘抖腿’的演示。最好能有数据亮点，比如一个实时的 ‘热门排行榜’，能体现我们内容的热度算法，抓紧准备！”

团队看着刚刚稳定的看板，又看看这些新需求，眼神复杂。老张叹了口气：“计划又变了？”

优先级排序我们有了，工时估算我们有了。但当多个重要干系人同时提出 “生死攸关” 的紧急需求，且严重超出了团队当前的负荷时，我们该如何决策？如何执行？

这引出了敏捷项目管理中最考验人的一环：迭代规划会议（Sprint Planning Meeting） 。

在这一讲，我们将一起学会如何拒绝传统的“派活式管理”，通过一场教科书般的规划会，将外部的压力转化为团队的 “自我承诺”。

在传统的项目管理中，面对突发需求，PM通常是“接单 -> 拆解 -> 派活”。PM像一个工头，指着张三说“你干这个”，指着李四说“你干那个”。

但在敏捷中，尤其是面对高压的突发状况时， “派活”是下下策。因为被动接受任务的人，在遇到困难时会说“是你让我干的”；而主动认领任务的人，会说“这是我承诺要搞定的”。

这一讲，我们将还原“抖腿”项目组的迭代规划会，看PM如何三句话，却甘愿让团队自愿扛起突如其来的重担。

---

一、 传统“派活”的陷阱：PM 是如何累死的？

面对这种突发状况，如果是传统的项目经理，脑回路通常是这样的：

1. 照单全收： 既然老板和运营都说了必须做，那就做。
2. 压缩时间： 既然下周要用，那就压榨周末。
3. 暴力派活： 打开Project，指着老张说“你做排行榜”，指着小王说“你做网红频道”。
4. 结局： 团队带着怨气干活，遇到坑就甩锅给PM，上线延期，质量崩盘。

为什么“派活”在敏捷里走不通？ 因为“派活”剥夺了团队的控制感。 当你说“老张，你做这个”时，潜台词是 “我对这个任务的成败负责，你只是我的手”。 一旦出现技术难点（比如排行榜并发高），老张的第一反应不是“我该怎么解决”，而是“项目经理又瞎几把派活，这根本做不完”。

敏捷的核心，是把 “控制权” 还给团队，从而换取团队的 “承诺”。

二、 规划会前的准备：PM 的“牌局”整理

在召开全员规划会之前，作为PM，你必须先冷静下来，处理好手中的“牌”。你不能把混乱直接扔给团队。

1. 明确容量（Capacity）——我们能吃几碗饭？

根据上一讲的燃尽图和历史数据，你知道团队目前的 速度（Velocity） 大约是 20个故事点/迭代。 这意味着，无论老板需求多紧急，团队的胃口只有这么大。硬塞30个点的活，只会消化不良。

2. 需求卡片化与初步估算

你迅速拉着产品Linda，将“网红频道”和“排行榜”拆解成用户故事，并简单预估了大小：

• 故事A：网红专属频道页（含Banner、列表） —— 估算：5点。
• 故事B：热门排行榜（含伪算法、排序接口） —— 估算：5点。
• 原定计划： 个人中心优化、评论功能、点赞动效优化 —— 总计：15点。

数学题来了： 现有容量 = 20点。 总需求 = 5（网红） + 5（排行） + 15（原定） = 25点。 超标 25%。

这就是规划会要解决的核心冲突。

三、 规划会实战：从“要我做”到“我要做”

上午10点，迭代规划会议正式开始。 你没有像往常一样直接念任务，而是把所有任务卡片摊在桌子上。

第一步：同步目标（Sprint Goal）

你开场白非常直接： “兄弟们，情况有变。这个迭代（Sprint 2）的目标必须调整。 原定的目标是‘完善社区互动’。 现在，根据公司的生存需要，目标调整为： ‘拿下网红，搞定投资人’。 为了达成这个目标，我们必须交付两个核心故事：网红频道 和 排行榜。”

第二步：暴露矛盾（The Gap）

你把两张新卡片贴在白板的“待办”区，指着已经溢出的列表： “大家看，我们的胃口是20个点。现在桌上有25个点的活。如果不做取舍，我们绝对会死在下周二。 ”

这时候，研发老张说话了：“那肯定是砍原定计划啊。评论功能能不能先不做？” 产品Linda急了：“评论是留存的关键啊！没有评论，网红来了跟谁互动？”

关键时刻，PM 不要做裁判，要做引导者。 你问团队：“如果我们必须保网红和排行榜，为了凑出这10个点的容量，你们建议把哪些原定任务踢出去？”

注意，是你问 “你们建议”。

前端小王举手：“其实‘个人中心优化’（3点）和‘点赞动效优化’（2点）可以缓一缓。现在的个人中心虽然丑，但能用。点赞动效哪怕没有，也不影响网红发视频。” 老张补充：“对，评论功能（5点）太大了，要不我们只做‘展示评论’，不做‘发评论’？或者先做个简版？”

经过15分钟的激烈讨论，团队自己达成了共识：

• 移出： 个人中心优化（3点）、点赞动效（2点）。
• 降级： 评论功能只做“一级评论”，不做“回复”（从5点降级为3点）。
• 加入： 网红频道（5点）、排行榜（5点）。

最终总分： 5+5+3+（其他小任务） ≈ 20点。 容量平衡达成。

第三步：认领任务（Self-Selection）

这是最关键的一步。 白板上写着最终确定的任务卡片。 “规划好了。现在，请大家上来认领自己想做的故事。谁领走了，谁就对它的最终交付负责。”

现场可能会出现的“僵局”与化解：

• 场景1：没人动。 大家面面相觑。

  • PM话术： “老张，排行榜涉及到后端排序算法，这个硬骨头你觉得谁能啃？”
  • 老张： “那我来吧，这个逻辑我比较熟。”（老张领走了任务）。
  • 破冰成功。 只要有人带头，气氛就活了。

• 场景2：挑肥拣瘦。 大家都抢简单的UI任务，没人拿复杂的业务逻辑。

  • PM话术： “剩下的‘网红频道’逻辑比较复杂，需要前后端紧密配合。小王，你之前做Feed流做得不错，这个频道页想不想挑战一下？如果做成了，这可是咱们App第一个运营位。”
  • 小王： “行，那我试试，但后端得配个熟手。”
  • PM： “小李（新手后端），你跟着小王做这个模块的接口，正好练练手？”
  • 结果： 在PM的 “激将” 和 “撮合” 下，任务被认领完毕。

第四步：做出承诺（Commitment）

任务分完了，每个人手里都有几个任务。 你最后问了一个问题：也就是敏捷中著名的 “信心投票（Fist of Five）”。

“兄弟们，看着你手里的任务，考虑到下周二的死线。各自判断下，1到5分，你对自己能按时交付的信心有几分？ ”

• 老张伸出4个指头。
• 小王伸出3个指头。
• 小李伸出5个指头。

你敏锐地抓住了小王的“3分”： “小王，为什么只有3分？你在担心什么？” 小王：“网红频道的UI设计还没定稿，我怕UI给得晚，我没时间写页面。” 你转向UI设计师：“小美，网红频道的图，明天下班前能给吗？” 小美：“可以，我今晚就加班出。” 小王：“那我就有4分了。”

总结： 直到所有人的信心都达到4分以上，这个会议才算结束。 这不仅仅是分任务，这是一场集体宣誓。

四、 为什么“认领”比“派活”好？

在“抖腿”这个案例中，我们发现“认领制”激发了两个关键心理机制：

1. 承诺一致性原理： 人一旦做出了承诺（自己拿走了卡片），就会产生维持承诺的心理压力。如果任务是你派给他的，出了问题他会怪你；如果任务是他自己领的，出了问题他会拼命想办法解决，因为他不想打自己的脸。
2. 掌控感与内驱力： 程序员是知识工作者。他们需要感觉到自己是工作的主人，而不是流水线上的螺丝钉。当老张主动认领“排行榜”时，他脑子里想的是“我要设计一个牛逼的算法”；如果是你派给他的，他想的是“又要写一堆CRUD”。

会后的私下交流中说道：“以前你派活给我，我做得好是应该的，做不好是我的问题。现在我自己选的，做不好丢的是自己的人。感觉不一样。”

五、 应对紧急需求的系统化方案

这次危机处理，让我们沉淀出了一套应对紧急需求的系统方法，你将其命名为  “三级响应机制” ：

第一级：需求缓冲池（接收所有需求）

• 任何紧急需求，首先进入“紧急需求缓冲池”
• 产品经理（Linda）立即进行需求分析，拆解为故事卡，给出初步RICE评分
• 绝对不直接打断正在进行中的迭代

第二级：快速评估会（决策是否介入）

• 迭代间隙召开，核心团队成员参加
• 评估问题：该需求是否真的紧急？能否等到下个迭代规划会？能否简化为最小可行方案？
• 决策产出：拒绝、纳入下个迭代、启动“绿色通道”

第三级：绿色通道（极高优先级需求的特殊处理）

• 启动条件：公司战略级需求、重大客户承诺、严重线上问题

• 处理流程：

  1. 从当前迭代置换出等价工作量的任务（由提出方决定置换什么）
  2. 或协调额外资源（如加班费、临时外包）
  3. 更新所有相关方计划

• 关键原则：紧急需求必须“付费” ，不能免费插队

对于网红需求和投资方需求，我们走的是“快速评估会”路径，将其转化为最小可行方案后，纳入下一个迭代的正常规划。

六、沟通的艺术：管理干系人预期

处理完内部规划，接下来是对外沟通。你需要同步三方：老板、运营负责人、网红团队。

对老板的沟通策略：
“老板，投资方演示的需求我们评估了。完整的实时排行榜需要2周，但下周一我们可以交付一个‘演示版本’：使用真实后台数据，前端静态展示，能清晰体现内容热度趋势和用户互动数据。这既能展示产品潜力，又不影响正式版上线。这是我们的方案，您看是否可以？”

（结果：老板同意。他真正要的是“有东西可看，有故事可讲”，而不是一个完整功能。）

对运营负责人的沟通策略：
“刘总，和网红合作的机会我们非常重视。技术团队评估后，建议采用‘精品专栏’方案：在App首页增加‘爆笑专区’入口，点进去是他所有视频的聚合页，页面有专属头图和标识。这能在一周内上线，且后续可以复用于其他网红合作。这是效果图，您看是否满足网红老师的诉求？”

（结果：运营和网红方认可。他们发现这个方案比预想的“频道”更轻、更快，且更有辨识度。）

关键沟通心法：

1. 先呈现解决方案，再说明约束：不要先说“这个很难”，而是先说“我们可以这样满足您”。
2. 提供选择，而非判断题：给出2-3个可行方案，让干系人参与决策。
3. 管理期望，而非拒绝需求：明确说明“最小可行方案”和“完整方案”的区别，以及各自的时间线。

七、反思：紧急需求的常态化管理

最后，两个紧急需求都成功交付。网红内容如期上线，投资方演示顺利进行。重要的是V1.0核心进度，没有出现大面积不可控的延误。

在后续迭代复盘会上，我们总结了这次经历的最大收获：

“紧急需求永远不会消失。但成熟的团队，不是没有紧急需求，而是拥有消化紧急需求而不崩盘的能力。”

这种能力由三部分组成：

1. 需求转换能力：将模糊的“我要”转换为具体的“可做”
2. 容量透明管理：团队清楚自己能做什么、不能做什么，并能让干系人理解
3. 团队自主文化：信任团队，让他们在约束下自主决策

你在整个过程中只做四件事：

1. 把变化放进机制，而不是落在头上
2. 帮团队把需求拆成可控范围
3. 把优先级和限制条件透明化
4. 让团队自己做决定，而不是你替团队决定

当你做到这一点时，你会看到一个最明显的变化：

需求再紧急，团队也不再疲于应对，
因为一切都有机制兜底。

这才是敏捷项目经理的高级境界：你并没有指挥千军万马，但千军万马正朝着你想要的方向狂奔。

【第8讲·思考】

场景回顾： 规划会很成功，大家领走了任务。 但在执行过程中，新手后端小李领走了“网红频道接口”的任务（估算3点）。 到了第二天站会，你发现小李进度迟缓。一问才知道，他高估了自己的能力，那个接口涉及到复杂的数据库连表查询，他卡住了，不敢问老张，怕被骂。

请思考并回答：

1. 干预时机： 在“认领制”下，当成员能力不足以完成他认领的任务时，PM该什么时候干预？是立马换人，还是再等等？
2. 话术设计： 你决定找小李谈谈。请设计一段话，既不打击他的积极性（毕竟是他主动领的），又能让他接受老张的介入或者任务的移交。

下集预告：

迭代规划会很成功，大家拿走了任务，也做出了承诺。但很快，新的问题就来了。

后端老张找到你：“Linda给的‘视频流去重’的需求，只说了一句‘看过的不能再看’。但用户什么时候算‘看过’？点赞算不算？滑过3秒算不算？这些验收标准（AC）和技术边界都没定，我根本不敢敲代码，敲了也是返工。”

在后续开发过程中，小王和老张发生了几次轻微的摩擦：

• 小王认为API应该返回A数据结构，老张设计的是B结构
• 老张认为某个逻辑应该前端处理，小王认为应该后端处理
• 双方都按自己的理解开发，联调时发现对不上

你意识到，尽管有了用户故事，但 “没想清楚就写代码” 才是研发最大的陷命。

问题不在于谁对谁错，而在于：在开发开始前，我们对“完成”的标准理解不一致。如何确保需求在进入开发前，是真正“就绪”的？如何建立一道“安检门”，防止模糊需求流入开发环节，造成浪费和返工？

敬请期待第9讲：《需求准入标准——没想清楚坚决不许敲代码，建立研发的“安检门”（DoD vs. DoR）》