写在前面：
需求范围（Scope）终于定下来了。MVP的功能列表已经躺在Product Backlog里。 接下来，该抛出那个灵魂拷问了： “所以，V1.0到底哪天能上线？”
你拿着列表去找研发老张：“老张，估个时吧。” 老张扫了一眼：“这个‘视频流预加载’没做过，不好说。顺利的话2天，不顺利的话……一周也可能。” 前端小王：“我也没做过，得看老张接口啥时候给我。”
你的排期表陷入了僵局。 如果你按“顺利”估，大概率延期；如果你按“不顺利”估，老板会骂你效率低。
这一讲，我们要解决敏捷PM的核心技能：如何在充满“未知”的情况下，拿到一个靠谱的排期？
在我们今天开始前，先回答我们上一讲最后提出的两个问题：
一、判断题：抖腿 App 的“高大上启动动画”，是伪需求吗？
首先，我们需要理解抖腿 App 的战略：
- 主打下沉市场
- 追求极致秒开
- 用户对品牌感知弱
- 用户对速度敏感度极高
在这种战略下：
任何延迟 0.5 秒的启动动画，都不是战略级价值。
所以结论：这是伪需求。
为什么？
因为你只要把数据拉出来看就知道：
- 新用户的 70% 留存是在 前 5 秒 决定的
- 下沉市场用户对“加载时间”的敏感性比一线城市高几倍
- 网络差→动画卡顿→反感→直接卸载
请注意：
不是“启动动画不好”，
而是“不符合本 App 的战略定位”。
如果你是做奢侈品、做高端品牌 App，那启动动画是必须的。
但抖腿不是。
所以这题的答案是：
是伪需求。
二、执行题：老板非要保留品牌展示，项目经历 如何做折中？
互联网 PM 不存在“干掉老板”的权限。
这你非常清楚。
所以我们不是“反对动画”，
而是给“更聪明的方案”。
你可以向老板提出三个选择，全都经过主流 App 验证。
方案 1：极简静态 LOGO（参考微信）
微信的启动页：
- 一张白底
- 一个绿色微信 LOGO
- 不闪、不动、不炫
只有 200ms 显示时间。
品牌完成，体验也不卡。
「这就是最强品牌：干净、稳定、克制。」
方案 2：动画提前异步加载（参考抖音）
抖音的做法是：
- 启动时先进入界面
- 动画只在“冷启动资源未准备好”的时间显示
- 只要资源提前预加载好，启动动画直接秒过
换言之：
动画变成“兜底方案”，不是“必展示方案”。
你可以告诉老板：
- 如果用户手机状况好 → 秒开
- 如果网络差 → 动画帮你遮挡
老板一般会接受这个方案，因为：
- 品牌展示有
- 秒开体验也不受影响
- 体验更智慧
方案 3：首帧即内容（主流做法）
把“首帧内容预加载”当作启动动画：
- 打开 → 直接看到视频封面
- 背后完成资源加载
- 加载完成 → 视频自动播放
这其实是：
内容即启动动画，启动动画即内容。
老板想展示品牌？
你可以：
- 把 LOGO 放在右上角
- 放在 Loading 点
- 放在自定义水印
- 甚至放在首帧蒙版里（3 秒淡出）
这个方案对于抖腿特别合适：
- 下沉市场用户：体验极致顺滑
- 老板：品牌露出得到了保证
- 研发：技术成本低
- 产品：体验无损
- PM：能上线
三、程序员说“这功能没做过，不知道要多久”怎么办？
这是每一个 PM 都一定会遇到的场景。
比如你让后端做一个“视频校验+AI 识别”的模块，他说：
“这个我没做过。
没概念，不知道需要多久。”
或者你让前端做一个“全局播放器组件”，他说：
“之前都是局部播放器…
这个我没做过，要评估下。”
或者你让算法同学做一个“冷启动推荐模型”，他说：
“我们没做过短视频，得调研下。”
作为 PM，你此刻的心理可能是：
- 不会吧不会吧，你都工作三五年了，怎么会不知道多久？
- 我排期怎么做？
- 进度怎么保证？
- 我怎么和老板解释？
你千万不要慌。
因为你需要理解一条在真实互联网团队里最重要的规律：
研发不是不能评估，而是“在不确定条件下给不出承诺”。
换言之：
他们不是不知道要多久，是不知道如何承担“万一做不完”的后果。
这句话很重要，建议你反复理解。
所以作为 PM，你的职责不是“逼他们给时间”，而是：
帮助研发把“不确定性”拆成“可确定性”，再估到小时级别。
换句话说：
不是“问多久”，
而是“拆到你肯定知道多久”。
四、 为什么传统的“拍脑袋”估时必死？
PM 的第一条工时原则：不是估工时，是拆工时
很多 PM 一股脑问：
“这个功能要多久？”
这是最不应该问的问题。
成熟 PM 的问法应该是：
“这个功能要分成几段？
哪些部分你能确定时间？
哪些部分你不确定？
不确定的部分我们怎么验证、怎么试探、怎么降低风险？”
你要把“不确定的整体”，拆成“确定的小块”。
比如一个“视频自动审核模块”，后端可能会觉得：
- 第一次接触第三方鉴黄平台
- 不知道 API 是否稳定
- 不确定数据量会不会压垮服务器
- 不清楚网络延迟
- 不知道要不要缓存
- 不知道需要前期多少样本测试
这些不确定性堆在一起，自然让他无法给你一个确定时间。
但你把它拆开，他就能给了。
示例拆分：
| 子任务 | 研发是否能给时间 | 说明 |
|---|---|---|
| 接入第三方 SDK（Demo） | ✔ 能 | 2 小时 |
| 调通一条 API 调用 | ✔ 能 | 1 小时 |
| 加入鉴黄回调机制 | ✔ 能 | 4 小时 |
| 大量样例测试 | ✔ 能 | 半天 |
| 性能压测 | ✔ 能 | 半天 |
| 业务接入（上传流程对接） | ✔ 能 | 1 天 |
| 缺少的部分：并发瓶颈预估 | ✘ 不能 | 需要小样本试探 |
| 缺少的部分：全链路延迟预估 | ✘ 不能 | 需要 mock 流量 |
你看，本来一个“未知功能”，拆完之后：
- 80% 的部分是确定的
- 20% 的部分需要实验或 mock 来降低风险
然后 PM 做的不是继续“问多久”，
而是帮研发建立一个 可验证的时间盒（Timebox） 。
比如：
“未知风险部分，我们先给 4 小时打样模型验证。”
打样完成后：
“结果能跑，我们继续做。”
“结果跑不动，我们改方案。”
这比“程序员瞎估一个时间→延期→甩锅”要成熟得多。
所以在“抖腿”项目组，我们首先要废除 “专家独裁估时法”（即项目经理问主要技术负责人，老张拍脑袋）。
因为“拍脑袋”有三个死穴：
- 幸存者偏差： 老张是资深架构师，他觉得简单的（比如搭个Redis），对新手后端来说可能要研究三天。老张估2小时，新手做3天，项目延期。
- 防御性估算： 大家怕背锅，都会在心里默默乘个3。3天的活报9天。老板一看排期：半年后上线？直接把项目砍了。
- 认知不一致： 同样是“登录”，产品以为是“手机号+验证码”，开发以为还要做“找回密码、第三方登录、风控校验”。大家聊的根本不是同一个东西。
敏捷的解药： 我们不追求绝对准确（那是算命），我们追求 “相对准确” 和 “团队共识”。
五、 当研发说“没做过”时，你可以用的实战工具
工具 1：拆到不能再拆（WBS 敏捷分解法）
永远记住一句话：
只要能拆，就能评估。
不能评估，只是因为还没拆。
你要让研发从：
- 需求维度
- 技术路径
- 外部依赖
- 自己没做过的点
- 可能踩坑的地方
逐个列出来。
一个 3 天做不完的功能，
拆完后可能是：
- 1 小时
- 2 小时
- 4 小时
- 半天
- 1 小时
- 2 天（这部分是真的坑）
这样 PM 就知道：
真正的不确定性只占整体的 20%。
然后可以进一步优化。
工具 2：时间盒 Timebox（限制投入时间）
对任何未知功能，不要问：
- 这个要多久？
而要说：
“我们给这个未知模块 3 小时做出最小验证。”
比如试探：
- API 通不通
- Demo 功能能不能跑
- 数据格式是否正确
- 并发是否爆掉
- 网络延迟是否能接受
3 小时后你会得到一个结果：
- 能做：继续推进
- 不能做：换方案
而不是：
- 研发卡 4 天
- PM 每天催
- 最后告诉你“方案可能不行”
这就是 Timebox 的意义。
工具 3：三点估算法（PERT）
这是项目管理专业人士的常用方法。
让研发分别估：
- 最乐观时间（O）
- 最可能时间（M）
- 最悲观时间（P）
真实估算 E = (O + 4M + P) / 6
这个方法能让研发从“拍脑袋”变成“结构化思考”。
工具 4：故事点 Story Point + 速率 Velocity
敏捷估工时不是问“几个小时”，
而是问“复杂度是多少？”
比如：
- 点赞功能：1 点
- 评论列表：2 点
- 视频上传：8 点
- 推荐流：13 点
然后用团队上一 Sprint 的平均速率（Velocity）来推算：
例如：
- 团队上个 Sprint 做了 30 点
- 本 Sprint 有 35 点
→ 你就知道一定会延期
→ 你就知道可以砍哪些点
而不是“等到最后一天才知道做不完”。
工具 5：研发借鉴对比（Reference）
你应该问研发：
“之前做过类似的吗？复杂度相似吗？依赖是同一套吗？”
例如：
- 新的播放器能对标旧播放器的复杂度
- 新的埋点模块能参考旧模块
- 新的上传链路能参考老系统的逻辑
- API 的签名方式与之前是否一致
研发很难估一个“完全未知”的时间，
但非常擅长估一个“与旧功能对比”的时间。
工具 6：计划扑克（Planning Poker）
场景还原：一场关于“视频上传”的估算博弈
会议室里，你给每个人发了一副扑克牌。牌面上不是JQK，而是斐波那契数列：0.5, 1, 2, 3, 5, 8, 13, 20, ∞（无穷大） 。 单位：人天（Man-Day） 。
你宣布规则： “全员参与，同时亮牌。”
第一轮出牌：
- 老张（资深后端）： 亮出 2。
- 新手后端（小李）： 亮出 8。
- 前端（小王）： 亮出 5。
巨大的分歧！ 如果按老张的排期，项目就挂了。
项目经理引导对话（这才是扑克的价值）：
- 你问老张： “你为什么觉得2天就能搞定？”
- 老张： “阿里云有现成的OSS SDK，接一下就行了，很快。”
- 你问小李： “你为什么觉得要8天？”
- 小李（怯生生地）： “我看文档里说要支持‘断点续传’和‘大文件分片’。我没做过分片逻辑，得去学，而且还要处理上传失败的重试，我觉得很复杂。”
真相大白！ 老张忽略了“断点续传”的复杂度（或者他以为不需要做），而小李考虑到了细节但高估了难度。
第二轮讨论与对齐： 老张：“哦，断点续传确实麻烦点。不过阿里云SDK里封装好了，不用自己写分片逻辑。小李我教你用SDK，大概半天能学会。” 小李：“啊？有现成的？那……那应该快很多。”
第二轮出牌：
- 老张： 3（加了点指导时间）。
- 小李： 3（有信心了）。
- 前端： 3（后端稳了我也稳了）。
最终估时：3人天。
深度思考： 计划扑克的本质不是为了“算命”，而是为了 “炸出” 团队内部的认知偏差。通过 “资深者” 和 “执行者” 的碰撞，消除“我以为很简单”和“我以为很难”的幻觉。
工具 7： 应对“黑盒”，探针任务（Spike）
对于“视频上传”这种通用功能，还能靠讨论对齐。但对于 “美颜滤镜” 这种团队从未接触过的黑科技，老张直接打出了 ∞（无穷大） 。
老张：“这玩意儿我真没底。市面上有几十家SDK，我不知道哪个好用，也不知道坑在哪。你让我估时，我只能瞎编。”
这时候，作为项目经理的你绝不能逼着老张给数字。 你要引入敏捷的大杀器：探针任务（Spike） 。
1. 什么是Spike？
它是一个 “有时限的调研任务”。我们不估算“做完这个功能要多久”，我们只估算 “搞清楚怎么做要多久”。
2. 实战操作
你在看板上新增了一张卡片：
- 任务名： 【探针】美颜SDK选型与技术验证
- 目标： 选出一家性价比最高的SDK，跑通Demo，列出接入风险。
- 时间盒（Timebox）： 1人天（老张负责）。
- 验收标准： 明天站会，老张告诉大家“做这个功能到底要3天还是13天”。
话术： “老张，我不逼你现在估时。我给你1天时间，你什么代码都别写，就去研究这个SDK。明天这个时候，你再给我一个靠谱的数字。如果1天不够，我们再商量。”
价值： Spike 把“无限的未知”变成了“有限的调研”。它保护了团队的承诺，避免了盲目承诺导致的延期。
六、 风险缓冲：PM要学会藏“私房钱”
通过常用工具，你拿到了一份相对靠谱的“工时表”。
总计：120人天。
团队：4人。
理论耗时：30个工作日。
这时候，你直接跟老板报“30天上线”吗？
绝对不行！ 那是找死。因为“墨菲定律”永远存在：老张会感冒，服务器会宕机，老板会临时加个Logo展示……
你需要加缓冲（Buffer） 。但在敏捷里，我们不简单的乘以系数，我们用 “聚焦系数（Focus Factor）”。
- 理想人天： 1天8小时全在写代码。
- 现实人天： 沟通、开会、上厕所、修老Bug……真正的有效产出时间通常只有 60% - 70% 。
最终排期计算：
向上的汇报艺术：
“老板，按最理想情况是30天。但考虑到技术风险和磨合成本，我们要预留安全空间。承诺45天上线（留2天富余）。 如果顺利，我们提前惊喜上线；如果不顺，我们也有退路。”
七、 总结：估时是团队的承诺，不是项目经理的命令
会议结束，白板上写满了数字。 大家看着自己打出的牌，心里是踏实的。因为：
- 数字是他们自己定的，不是你强压的（承诺感）。
- 不懂的地方给了调研时间，不心虚（安全感）。
- PM预留了缓冲，不焦虑（信任感）。
在这个“抖腿”项目里，我们终于从 “不知道什么时候上线” 的迷雾中看到了出口的影子。
【第7讲·思考】
场景回顾： 你用计划扑克搞定了大部分需求的估时。但在估算 “首页视频推荐流” 这个核心故事时，出现了僵局。 产品Linda说：“必须包含‘去重’逻辑，用户看过的视频不能再出现。” 新手后端小李打出了 13人天（非常大），理由是：“去重逻辑很复杂，随着用户看过的视频越来越多（几千条），每次查询都要过滤，数据库性能会崩，我得引入Redis BloomFilter，还要学怎么用……” 老张打出了 3人天，理由是：“V1.0数据量小，直接数据库 NOT IN 就行了，崩了以后再说。”
请思考并回答：
- 决策题： 面对“为了未来高性能而现在的复杂实现（小李）”和“为了现在快上线而欠技术债（老张）”，作为创业项目的PM，你会支持谁的方案？为什么？
- 话术题： 你决定支持其中一方。请设计一段话，说服另一方接受这个决定，并让他感到被尊重。
下集预告： 排期定了，开发开始了。你每天看着看板上的卡片在动，但心里还是没底： “我们真的能按时上线吗？大家是不是在报喜不报忧？” 你需要一张图，一张不撒谎的图。 敬请期待第8讲：《迭代规划会议——拒绝派活式管理，如何让团队心甘情愿自己认领任务？》
