写在前面：
项目进入了第二迭代的深水区。
前几周，大家还在为“用户故事”的拆解感到新鲜，看板上的卡片流动得也算顺畅。但作为项目经理，你心里很清楚，这种岁月静好只是暂时的。
敏捷真正的死敌，从来不是复杂的代码，而是“权力的任性”和“市场的焦虑”。
在国内的创业环境中，项目经理往往处于权力链条的末端。教科书上说“Scrum Master有权保护团队不受干扰”，但在真实的办公室里，当投资人要看Demo，当老板拍着桌子说“这个功能必须有”的时候，你如果敢拿教科书去挡，明天你就可以离职了。
很多敏捷教材会告诉你：“中途不允许插队”。
那是书本上的敏捷。
但现实世界中：
- 老板看到热搜
- 竞品突然上了新功能
- 运营抓到瞬时窗口
- 投资人临时要看 demo
- BD 突然有合作机会
- 法务/安全部/监管机构要求整改
- 市场突然要一场大促
- 公司战略朝令夕改
你不可能直接拒绝。
真正的敏捷实战，不是死守规则，而是管理博弈。
你是水。水利万物而不争，但水能载舟亦能覆舟。面对插队，你不能做墙（硬挡），要做海绵（吸纳压力，然后挤出水分）。
一、 突发：来自顶层的“降维打击”
周三下午，代码写得正热火朝天。 老板突然推开会议室的门，后面跟着一脸无奈的产品经理Linda。
老板没有坐下，直接把你和技术老张叫了起来：“老李，老张，先停一下。刚得到消息，竞争对手‘XX视频’下周要发版，主打‘一键卡点’功能。投资人那边催着下周一要看我们的Demo，只有刷视频不行，必须加上‘拍摄’和‘基础滤镜’。 没有拍摄，投资人觉得我们只是个空壳子，没价值。”
Linda在旁边小声补充：“可是我们V1.0规划的是纯内容消费端（只看），拍摄功能本来排在下个月的……”
老板打断了她：“市场不等人！下周一我看不到拍摄功能，这个项目咱们都别干了！”
说完，老板走了。留下一屋子面面相觑的人。 老张把鼠标一摔：“开什么玩笑？现在离下周一就3天，让我搞拍摄加滤镜？还得跟安卓适配？神仙也做不完啊。”
深度解析： 这才是真实的插队。它不是因为“运营想做活动”这种小事，而是关乎 “融资” 和 “生存” 的大事。 这种需求，必须做。 任何关于“敏捷流程不可变更”的理论，在“项目生死”面前都是废纸。
现在的局面是：
- 当前任务： 正在开发的“Feed流性能优化”（原定本周交付）。
- 突发任务： “拍摄+基础滤镜”（老板死命令，下周一见）。
- 资源： 没变。
- 时间： 3天。
二、 应对：不要说“不”，要说“代价”
作为项目经理，你现在的肾上腺素飙升。你的直觉想让你冲去老板办公室吵架，但你的职业素养让你冷静了下来。
你不能拒绝老板，但你也不能逼死团队。 你必须进行一次 “可视化的代价谈判”。
1. 快速评估
你立刻拉着老张和Linda开了个5分钟的短会。 “老张，别发火。老板的压力就是钱的压力，没钱大家都失业。现在咱就盘算一下，如果非要做个‘能骗过投资人’的拍摄功能，最低最低的成本是多少？”
老张冷静了一下：“如果不管代码质量，全是硬编码，不做美颜，只调系统相机拍一段视频传上去，后端不做转码直接存……最快也要2人天。前端小王得全扑上去。”
“好。”你转向Linda，“如果不做美颜，只调系统相机，能不能接受？” Linda咬牙：“投资人看Demo，没美颜可能会被吐槽土，但总比没有强。”
2. 向上管理的艺术：把“选择题”抛回给老板
你拿着笔记本，敲开了老板的办公室。
错误的话术： “老板，这不符合敏捷流程，团队做不完，我们要加班……”（老板会觉得你无能）。
正确的话术： “老板，刚和技术盘过了，为了保下周一的演示Demo，我们全力以赴。但时间只有3天，是个物理瓶颈。为了确保那天演示不翻车，我们需要做个极其艰难的置换。”
老板，您看：
方案A（保质量）： 咱们保Feed流的流畅度，拍摄功能只做一个‘假的’入口，点进去提示‘即将上线’。风险： 投资人可能不爽。
方案B（保功能）： 我们把现在正在做的‘性能优化’全部停掉，烂尾楼先扔在那。所有人扑上去做一个‘只能调系统相机’的拍摄功能。代价是： 演示的时候，刷视频可能会卡顿，拍摄没有美颜。
方案C（赌命）： 我们通宵加班，两个都做。巨大风险： 到了周一，可能拍摄也没调通，视频也卡，演示直接崩盘。
深度思考： 你没有拒绝老板。你只是告诉他： “我可以为您做这个，但代价是那个。您是CEO，您来决定我们要承担哪种风险。”
通常，理性的老板在看到“演示崩盘”的风险后，会冷静下来。 老板想了想：“演示不能崩，刷视频必须流畅。拍摄功能……你们能不能搞个‘本地模拟’？就是不用真上传，拍完在本地能播就行？”
“可以！”你立刻抓住了这个降级方案，“如果是这样，3天时间应该够。”
危机解除。 需求从“完整的拍摄上传”降级为“本地演示用的假拍摄”。
三、 流程：RICE模型的实战修正
虽然处理了老板的“原子弹”，但日常工作中，Linda（产品）和运营还是会有各种小需求想插队。 比如，Linda觉得“点赞红心不够红”，运营觉得“启动图要换个喜庆的”。
你不能每次都去找老板博弈。你需要一套 “软规则”。
对于创业团队，复杂的评分卡（Scorecard）没用。我们用改良版的 RICE 模型，但不是用来算分的，是用来 “吵架” 的。
当产品拿着“美颜滤镜”要插队时，你把她拉到看板前：
RICE 实战话术：
-
Reach (覆盖面)： “Linda，V1.0版我们主要推‘看’。你觉得有多少用户进来第一件事是‘拍’？1%有吗？” -> 把这种低频功能挡回去。
-
Impact (冲击力)： “如果不做这个，用户会卸载吗？还是说做了这个，留存能翻倍？” -> 逼产品想清楚核心价值。
-
Confidence (置信度)： “你说这个功能重要，有数据吗？还是竞品有我们就要有？”
-
Effort (投入)： “老张说这个要搞3天。你愿意用‘首页加载速度慢10秒’来换这个滤镜吗？”
所以优先级不是一句“重要”就能决定的，而是三个维度：
1. 收益（Business Value）
—— 做出来能带来什么（增长、留存、转化、品牌、合规、投资人信心）
2. 成本（Cost）
—— 做它要分散多少开发、测试、设计资源
3. 风险（Risk）
—— 不做它会发生什么后果（被监管、被竞品抢市场、上线延误、业务上不了线）
任何需求的排序，都必须同时考虑这三块。
这才是敏捷优先级的本质： 不是冷冰冰的公式，而是 “等价交换”的谈判工具。每一个新需求的加入，都意味着旧需求的牺牲，不然优先级就会变成某些领导的“拍脑袋排序”。
四、 执行：待办列表（Backlog）的动态平衡
在“抖腿”项目组，你不再维护一个静态的Excel表。你的看板上，Backlog那一栏是流动的。
1. 设立“插队缓冲区”
你在看板上专门划出了一条泳道，叫 “快速通道（Fast Track）”。
- 规则： 每个迭代，只允许一个紧急需求走这个通道。
- 代价： 一旦使用了这个通道，本次迭代中优先级最低的那个卡片，自动被踢回Backlog池子，不做任何解释。
这招非常狠。 当运营要插队“换启动图”时，你告诉他：“名额只有一个。你确定要用在这个换图上吗？万一明天老板又要改什么大事，你这就浪费了。” 运营可能想了想：“那算了，等下个版本吧。”
2. MoSCoW 法则的中国式落地
在V1.0上线前的冲刺阶段，你把所有需求按 MoSCoW 重新贴了标签，但换了个叫法：
- Must have (救命的)： 没这个功能，App上不了架，或者点了会崩。（例如：合规协议、登录验证）。
- Should have (保命的)： 没这个功能，用户会骂娘，留存率暴跌。（例如：无限滑动、点赞）。
- Could have (长脸的)： 有了锦上添花，没有也行。（例如：炫酷的转场动画、美颜滤镜）。
- Won't have (做梦的)： 想都别想。（例如：私信、直播）。
PM的铁律： 在V1.0上线前，只做“救命的”和“保命的” 。任何“长脸的”需求，只要进度有风险，立刻无情砍掉。
五、 总结：像水一样管理项目
回到最初的问题：面对老板的插队，做还是不做？
答案是：做，但按我的方式做。
敏捷不是僵化的教条。如果投资人明天要看Demo，你还抱着Scrum指南说“迭代期内不可变更”，那你就是迂腐。
深度思考： 国内敏捷PM的核心竞争力，在于 “预期管理” 和 “资源置换”。
- 当老板施压时，你是缓冲垫，通过降级方案（如做个假的Demo）化解技术压力。
- 当业务方插队时，你是交易员，通过展示成本（Effort）强制他们做取舍。
- 当团队动荡时，你是定海神针，通过“快速通道”规则，维持基本的秩序。
你不需要总是那个说“不”的人。 你要做那个说 “可以，但是……” 的人。
【第5讲·思考】
场景回顾： 你成功通过“降级方案”（本地模拟拍摄），帮老板搞定了投资人的演示。大家松了一口气。 但是，欠的债总是要还的。V1.0上线日逼近，产品经理Linda看着简陋的“系统相机拍摄”，焦虑得睡不着。她联合运营负责人，正式向你发起挑战： “竞品昨天上了‘一键大片’功能，数据爆了。我们V1.0如果还是只能调系统相机，上线就是死。我们愿意砍掉‘评论功能’和‘个人主页的美化’，以此置换‘基础美颜’功能进V1.0。”
研发老张的反馈： “砍掉评论和主页确实能省出人手，但美颜需要接第三方SDK，有技术坑，风险不可控。”
请思考：
- 决策题： 此时距离上线还有10天。作为PM，你会接受这个“置换”吗？为什么？（提示：考虑风险与收益的不对称性）。
- 执行题： 如果一定要接美颜SDK，为了防止技术坑导致项目延期（上线开天窗），你会制定什么样的 “熔断机制”？
下集预告： 优先级排好了，插队的需求也挡住了，权力斗争暂时平息。但当你冷静下来，对着剩余的工时和紧迫的上线日期进行计算时，发现了一个更残酷的事实：按目前的速度，V1.0的现有功能列表，依然做不完。
产品经理还在坚持“注册登录”是数据资产，研发还在担心“搜索功能”不可或缺。项目经理必须做出最后、最艰难的决定——做减法。
为了保上线，我们必须启动一场瘦身。那些在大家眼里“绝对不能少”的功能，为什么必须被我判定为“伪需求”？
敬请期待第6讲：《MVP最小可行性产品——为了赶上线，我们狠狠砍掉了这三个“伪需求”》
