managing-timelines

管理时间线

运用 13 位产品领导者的方法，帮助用户制定并实现切实可行的项目时间线。

如何提供帮助

当用户寻求时间线方面的帮助时：

1. 了解背景 - 询问截止日期的性质（外部承诺、内部目标、人为设定的里程碑）、工作的阶段，以及造成时间压力的原因
2. 诊断问题 - 判断问题是估算不准、范围界定不当、受到干扰，还是利益相关方的期望不切实际
3. 运用合适的框架 - 根据具体情况，帮助用户采用分阶段承诺、山形图或尽早交付策略
4. 养成健康习惯 - 引导用户建立可持续的时间线实践，而不是只求一时解决

核心原则

将真正的截止日期视为 P0——其他事情都不重要

Nan Yu：“让截止日期真正生效的唯一办法，就是把它们当成 P0 问题来严肃对待，相比之下，其他事情都不重要。”不要设置太多截止日期，只将它们留给关键的外部事件。确定截止日期后，要保护团队免受其他干扰。

承诺阶段，而非遥远的交付日期

Annie Pearl：“我们现在承诺的是自己能掌控的日期。我们可以承诺开展一项发现工作……而不是在尚未充分调研时，就承诺六个月后交付一个项目。”将工作拆分为调研、方案设计、构建和发布阶段。只有方案设计完成后，才提供工程交付日期。

尽早交付，用剩余时间迭代

Nan Yu：“我们几乎不做估算。我们会尽可能早地交付。如果在用了 10% 的时间时就有了可用的东西，剩下的时间就可以用来决定是继续迭代还是打磨完善。”重点是尽快达到可交付的“是或否”状态，而不是一开始就花大量时间估算。

用山形图跟踪不确定性

Jason Fried：“项目更像一座山。左侧代表你还在摸索。一旦工作到达山顶，后面就是下坡了——纯粹的执行。”将工作可视化为一座山：左侧是调研，右侧是执行。卡在上坡阶段的事项，错过截止日期的风险很高。

人为设定截止日期以创造势头

Laura Modi：“你的工作不只是让人们保持势头，而是要创造势头。有时候，这种势头必须人为制造。”设置任意的截止日期和发布日期来推动进展。利用里程碑防止过度追求完美。

质疑估算中隐含的缓冲

Dylan Field：“如果时间线不是从基本原理出发充分推敲出来的，而且其中刻意留了缓冲，你就必须弄清楚实际工作时长的假设是什么。”通过追问“为什么”来找出隐藏的限制或不必要的缓冲。从基本原理出发逐一验证假设。

考虑计划谬误

Nir Eyal：“人们完成任务所需的时间，是他们估算时间的三倍。当你做了五分钟的事情，接着收到一封邮件和一条通知，你根本不会记录自己实际花了多长时间。”衡量效率时，要看自己是否在不受干扰的情况下完成了原定任务。利用时间盒，为实际耗时建立反馈循环。

不要申请延期

Seth Godin：“专业人士不会申请延期，因为他们明白总会发生意料之外的事情。”将截止日期和预算视为硬性约束。在计划中预留缓冲，以应对意外情况，而无需延期。

每周使用 RAG 状态审查

Brian Chesky：“我有一位首席项目经理，会把所有项目标为绿色、黄色或红色。我每周都会审查工作；如果有事情没有进展，我就会叫停会议并问：‘为什么这件事没有进展？’”提升项目管理的作用。使用简单的 RAG 状态和每周审查，及早发现问题并排除障碍。

预期 AI 时间线会参差不齐

Aparna Chennapragada：“首次演示的时间大大缩短了，但全面部署需要更长时间。节奏并不均匀。”规划时，应缩短原型设计的内循环，但为规模化的外循环分配充足时间。管理好各方对演示与可交付产品之间差距的预期。

帮助用户的问题

• “这是对外承诺还是内部目标？如果未能按时完成，会有什么后果？”
• “这项工作处于哪个阶段——探索、方案设计还是构建？”
• “你们是否已经交付了一个‘可用版本’，还是团队仍在摸索？”
• “这个估算预留了多少余量？其中包含了哪些假设？”
• “你的时间有多少真正用于专注工作，有多少花在会议和干扰上？”
• “是否有太多相互争夺注意力的‘P0 截止日期’？”

需要指出的常见错误

• 在完成探索之前就承诺日期——还没明确范围，就无法估算。承诺阶段目标，而不是遥远的交付日期
• 高优先级截止日期太多——如果什么都是 P0，那就没有什么是真正重要的。只有对关键外部事件，才设定真正的截止日期
• 先花太多时间估算，而不是尽早交付——尽快做出可用版本，并利用剩余时间迭代
• 忽视计划谬误——由于各种干扰，任务耗时会比估算长 3 倍。设定时间上限，并衡量实际专注工作时间
• 申请延期——专业人士会考虑意外情况。留出缓冲，而不是延长时间线

深入了解

13 位嘉宾分享的全部 14 条见解，请参见 references/guest-insights.md

相关技能

• 确定范围并精简
• 规划优先级路线图
• 高效开展会议
• 在不确定性下规划