写在前面：
“抖腿”App 的“春节红包”功能终于开发完了。 为了赶进度，后端和前端连续熬了好几个通宵。代码写得飞起，测试也通过了（哪怕是冒烟测试）。大家看着手机里那个能点击、能弹窗、能入账的红包功能，心里充满了自豪感：“这把稳了！”
你提前一天反复确认了功能：
- 主流程能走通
- 核心页面没报错
- 数据能正常展示
你心里甚至还有点小骄傲：
“这次迭代节奏不错，领导应该会满意。”
周五下午，你把领导、运营总监、客服主管等主要干系人都叫到了会议室，准备进行 迭代评审会 。
你把手机投屏到大电视上，带着兴奋地说：“各位领导请看，这是我们目前做出来的红包功能。”
你展示了红包功能，功能逻辑完美：
- 用户 A 成功向好友 B 发送了 1 元红包。
- 好友 B 成功领取了红包。
- 系统账户金额准确扣除。
领导问了一个关键问题： “这个红包，能发给那些不是我好友的人吗？比如我发给微信好友，他们点开链接，下载 App 就能领红包吗？”
你心里咯噔一下。你边回忆着 PRD： “支持发给站内用户”。 边回答到：“老板，我们理解的 ‘站内用户’ 是已添加的好友，所以现在只能发给好友。”
领导的怒火瞬间爆发： “我们做红包是为了什么？是为了拉新！ 如果用户只能给已经在我 App 里的好友发红包，那这个功能怎么裂变？我们花了几百万投入，是为了让老用户多给老用户发钱吗？这在商业上是零价值！ ”.
你的团队没有犯错，需求文档上确实写的是‘站内用户’，实现的逻辑也是完全符合验收标准的，但却没有达到领导的预期价值。
空气变得凝固，你只能硬着头皮继续演示：
- 新增的频道页
- 新加的标签
- 推荐算法参数配置页
结果演示没多久，老板就又皱起了眉头：
- “你先别点了，你告诉我一句话：这版改完，用户会多刷 5 分钟吗？”
- “这个按钮点了半天，价值在哪？”
- “我以为你们这版能解决那个老问题？”
- “这就是你们两周做出来的东西？”
你愣住了。
因为你突然意识到：
你准备的是“怎么做”，而他要的是“值不值”。
终于熬到演示会议结束，你一身冷汗，
领导留下一句：
“你们这个迭代，方向有点问题。”
你很委屈。
代码是好的，功能是做完的，进度是按计划走的。
但你还是输了。
失败的原因是：项目经理在流程中的“价值验证”失职。
一、 先说结论：Demo 翻车，90%不是技术问题
很多项目经理在被骂后，第一反应是：
- “功能还不够多”
- “UI 还没优化”
- “测试没测全”
但真正的问题，往往在更前面：
你把“迭代评审”，当成了“成果汇报”，而不是“价值对齐”。
这是一个致命误解。
二、迭代评审真正的目的是什么？
我们先把概念掰正。
迭代评审（Sprint Review）不是验收会，也不是述职会。
它的核心目标只有一个：
不是展示“我们做了什么”，而是确认“我们该不该继续这么做”。
注意关键词：
- 不是“做了多少”
- 不是“多辛苦”
- 而是——方向对不对
而老板骂你，往往不是因为“你没做事”，
而是因为：
他看到的 Demo，和他脑子里的“正确答案”，不是同一个东西。
三、 那为什么会“货不对板”？
你可能是这样准备的：
- 先演示登录注册
- 再演示列表页
- 再点进详情页
- 最后补一句：“这个下版再优化”
你讲得很完整，但老板听得很痛苦。
因为在他眼里：
你在“带他逛系统”，而不是“帮他验证判断”。
在敏捷开发中，最悲剧的不是“做不完”，而是“做完了，但没人要”。
导致这种“被骂”惨剧的核心原因可能是：
- 团队只盯着任务描述进行开发，却忘了思考“用户怎么用”。
- 你把 Demo 当成“功能展示清单”。
- 缺乏中间反馈，这是最致命的。整整两周，除了项目经理和开发，没人看过这个功能。你把所有风险都积攒到了最后一刻才引爆。
四、 如何开一场“不挨骂”的演示会？
项目经理必须搞清楚：
当领导在看 Demo 时，脑子里真正想的是什么。
当领导坐在那里看你演示时，他关注的从来不是：
- 用了什么技术
- 页面切换多顺
- 代码写得多规范
他脑子里只有这几件事：
- 这个东西能不能解决当前最痛的问题？
- 这个方向是不是值得继续投资源？
- 有没有明显的坑我没提前看到？
如果你的 Demo 不能帮他回答这三个问题，
那你演得再熟，也是在浪费时间。
想要演示会成功，功夫全在技术之外：
1. 会前：拒绝“惊喜”，只有“剧透”
铁律： 永远不要让领导在演示会上第一次看到产品。
在迭代中期（比如开发到 50% 时），项目经理就应该拿着半成品（甚至只是交互原型）去找领导或运营： “领导，红包的交互流程大概是这样的，最后的样式还没调，您先看看这个路径对不对？”
- 如果领导说不对： 马上改。这时候改代码成本极低。
- 如果领导说对： 演示会上的“正式展示”只是走个过场，确认成果而已。
2. 开场先对齐“这版解决什么问题”
不要急着点页面。
你应该先说一句话：
“这次迭代，我们聚焦解决一个问题：新用户进来后，不知道看什么，3 分钟就走。”
领导一听，就知道接下来该怎么看。
3. 会中：像讲故事一样演示
不要上来就点功能点：
“这是推荐页，这是榜单页。这是按钮 A，这是输入框 B。”
领导不关心按钮，领导关心场景，领导关心场景，领导关心场景。
而是用故事，而不是菜单：
“我们假设一个第一次打开 App 的用户，看他 30 秒内会看到什么。”
所以项目经理必须担任“导演”和“解说员”的角色：
- 场景化开场： “各位，假设我现在是一个刚吃完年夜饭的用户，我在群里看到了一个链接……”
- 操作演示： 拿起手机投屏操作，“我点击链接，直接唤起 App……大家看，这里我们特意做了一个‘爆炸’的动效，为了增加爽感……”
- 引导反馈： “在这个环节，我们有两个设计方案，现在选的是 A。大家觉得在这个场景下，用户会更想点击哪里？”
这样做的效果： 你把领导带入到了 “用户视角”，而不是 “审判视角”。他提出的意见会是“我觉得用户可能找不到”，而不是“你做的这是个啥”。
4. 主动暴露“没解决的地方”
这是很多项目经理不敢做，但其实极其加分的一步。
你可以直接说：
“这个方案目前有两个风险点：
1️⃣ 冷启动推荐还不稳定
2️⃣ 数据样本还不够多
我们下个迭代准备重点验证这两个点。”
这不是示弱，是成熟。
5. 面对老板的指责
一个被骂的 Demo，不一定是失败；
一个被夸但方向错的 Demo，才是真的灾难。
作为项目经理，你真正要怕的不是被骂，
而是：
- 老板点头
- 团队继续干
- 两个迭代后发现：全错了
6. 把选择权留给老板，而不是被动挨骂
不要等老板问。
你可以主动抛选择题：
“基于现在的效果，有两个方向：
A：继续深挖推荐，压榨时长
B：先补内容池，保证基本体验
我更建议 B，但也想听听大家的判断。”
你不是来交作业的，你是来辅助决策的。
7. 演示的“禁忌事项”
为了防止翻车，要牢记以下几点：
- 禁忌 PPT： 敏捷宣言说“可工作的软件胜过详尽的文档”。演示会只看真机/真系统，禁止念 PPT。
- 禁忌“本地环境”： 演示用的包必须是 测试环境 甚至 预发布环境 的。不要说“我本地是好的”，别人不关心你本地好不好。
- 禁忌“技术黑话”： 别说“API 延迟了 200ms”，说“用户等待时间变长了”。别说“数据库分表了”，说“现在支持 1 亿人同时抢红包了”。
五、 总结
你永远不可能保证：
- 老板每次都满意
- Demo 每次都被夸
但你可以保证一件事：
每一次评审，都是一次清晰的“方向校准”，而不是一次情绪宣泄。
当老板即使不满意，但能说清楚：
- 不满意哪
- 想调整什么
- 下步怎么走
那这次评审，就是成功的。
每一次成功的演示，都是在向领导和业务方存入信任。 每一次失败的演示（被骂、Bug 频出），都是在透支信任。
如果你的团队连续三次演示失败，领导就会介入“微管理”，开始盯着你们的日报、查你们的工时。那是敏捷的末日。
记住： 挨骂不可怕，可怕的是 “因为同样的理由挨两次骂”。
【第17讲·思考】
场景回顾： 你按照“场景化演示”的方法，成功安抚了领导。 但是，在演示“高并发抢红包”环节时，因为会议室 Wi-Fi 信号不好，App 突然转圈圈，卡死了。
领导眉头一皱：“这性能行不行啊？演示都卡，上线不得崩？”
研发赶紧解释到：“领导，这是网的问题，不是服务器的问题”
请思考并回答：
- 反思题： 这属于演示准备中的什么失误？（提示：关于环境和预案）。
- 救场题： 面对“演示翻车”的突发尴尬，作为项目经理，除了怪 Wi-Fi，你该用什么话术或行动来挽回老板的信心？（提示：你可以展示监控数据，或者……）。
