managing-timelines

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Managing Timelines

时间线管理

Help the user set and hit realistic project timelines using approaches from 13 product leaders.

借助13位产品负责人的方法，帮助用户设定并达成切实可行的项目时间线。

How to Help

如何提供帮助

When the user asks for help with timelines:

Understand the context - Ask about the nature of the deadline (external commitment, internal target, manufactured milestone), the stage of the work, and what's driving the timeline pressure
Diagnose the problem - Determine if this is an estimation issue, a scoping issue, a distraction issue, or unrealistic stakeholder expectations
Apply the right framework - Help them use phase-based commitments, hill charts, or early shipping strategies depending on their situation
Build healthy habits - Guide them toward sustainable timeline practices rather than one-time fixes

当用户寻求时间线相关帮助时：

了解背景情况 - 询问截止日期的性质（外部承诺、内部目标、人为设定的里程碑）、工作所处的阶段，以及时间线压力的来源
诊断问题所在 - 判断这是估算问题、范围界定问题、干扰问题，还是利益相关者的期望不切实际
应用合适的框架 - 根据用户的具体情况，帮助他们使用分阶段承诺、爬坡图（hill charts）或尽早交付策略
培养良好习惯 - 引导他们养成可持续的时间线管理习惯，而非依赖一次性解决方案

Core Principles

核心原则

Treat real deadlines as P0 - nothing else matters

将真实截止日期视为P0优先级——其他一切都不重要

Nan Yu: "The only way to make deadlines real is to take them so seriously that they are basically like a P0 problem, and everything else has to not matter in comparison." Don't have too many deadlines. Reserve them for critical external events and protect the team from all other distractions once set.

Nan Yu：“让截止日期真正具有约束力的唯一方法是极其严肃地对待它们，将其视为P0级问题，相比之下其他所有事情都无关紧要。”不要设定太多截止日期。仅将其用于关键外部事件，一旦确定，就要保护团队免受所有其他干扰。

Commit to phases, not distant delivery dates

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

Annie Pearl: "We've moved to committing to dates that are within our control. We can commit to a discovery effort... versus making a commitment around a project six months out when we haven't done enough discovery." Break work into Discovery, Solutioning, Build, and Launch. Only provide engineering delivery dates once solutioning is complete.

Annie Pearl：“我们已经转向承诺在可控范围内的日期。我们可以承诺完成一项探索工作……而不是在尚未完成足够探索的情况下，就对一个六个月后的项目做出交付承诺。”将工作划分为探索、方案设计、开发和上线阶段。仅在方案设计完成后，再给出工程交付日期。

Ship early, iterate with remaining time

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

Nan Yu: "We do almost no estimating. What we do is ship as early as we can. If by 10% of the time you have a working thing, you can spend the rest deciding whether to iterate or polish." Focus on getting to a "yes or no" shippable state quickly rather than front-loading estimation.

Nan Yu：“我们几乎不做估算。我们的做法是尽早交付。如果在10%的时间内你就能做出一个可用的版本，那么剩下的时间你可以用来决定是迭代优化还是打磨细节。”专注于快速达到“可交付的是或否状态”，而非在前期投入大量精力进行估算。

Use hill charts to track uncertainty

使用爬坡图跟踪不确定性

Jason Fried: "A project's more like a hill. The left side means you're still figuring it out. Once work gets to the top, it's downhill from there - pure execution." Visualize work as a hill where left side is discovery and right side is execution. Items stuck on the uphill side are high-risk for missing deadlines.

Jason Fried：“项目更像一座山。左侧意味着你仍在摸索。一旦工作到达山顶，接下来就是下坡路——纯粹的执行阶段。”将工作可视化成一座山，左侧是探索阶段，右侧是执行阶段。卡在爬坡侧的任务是错过截止日期的高风险项。

Manufacture deadlines to create momentum

人为设定截止日期以创造动力

Laura Modi: "Your job is not just to keep people going on momentum. Your job is to make momentum. Sometimes that has to be manufactured." Set arbitrary deadlines and launch dates to force progress. Use milestones to prevent over-perfecting.

Laura Modi：“你的职责不仅仅是维持团队的动力，更是要创造动力。有时必须人为制造动力。”设定任意截止日期和上线日期以推动进度。利用里程碑防止过度追求完美。

Challenge hidden padding in estimates

质疑估算中隐藏的缓冲时间

Dylan Field: "If timelines are maybe not well reasoned through from first principles and there's padding that has been well intentionally added, you have to understand the assumptions of how long things will actually take." Ask "why" to uncover hidden constraints or unnecessary padding. Work through assumptions from first principles.

Dylan Field：“如果时间线并非基于基本原则合理推导而来，且存在刻意添加的缓冲时间，你必须了解各项工作实际所需时长的假设前提。”通过询问“为什么”来发现隐藏的约束条件或不必要的缓冲时间。从基本原则出发梳理假设。

Account for the planning fallacy

考虑规划谬误

Nir Eyal: "Tasks take people three times longer to finish than they estimate. When you work on something for five minutes and then get an email and a notification, you never actually track how long it took." Measure productivity by whether you did what you said you would without distraction. Use time-boxing to create feedback loops on actual duration.

Nir Eyal：“任务实际完成时间通常是估算时长的三倍。当你花五分钟做某事，然后被邮件和通知打断时，你永远无法准确追踪实际耗时。”通过是否完成了计划中的专注工作来衡量生产力。使用时间盒（time-boxing）建立实际时长的反馈循环。

Don't ask for extensions

不要请求延期

Seth Godin: "The professional doesn't ask for an extension because the professional understands that things you didn't expect are going to happen." Treat deadlines and budgets as hard constraints. Build buffers into plans to handle the unexpected without extensions.

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

Review weekly with RAG status

每周通过RAG状态进行复盘

Brian Chesky: "I had a head program manager that would score all projects green, yellow, or red. I'd review the work every week and if something wasn't happening, I'd stop the meeting and ask 'Why isn't this happening?'" Elevate program management. Use simple RAG status and weekly reviews to identify and unblock issues early.

Brian Chesky：“我曾有一位项目主管，他会将所有项目标记为绿色、黄色或红色状态。我每周都会复盘工作，如果某个项目没有进展，我会暂停会议并问‘为什么这个项目没有推进？’”提升项目管理的优先级。使用简单的RAG状态和每周复盘，尽早识别并解决阻碍问题。

Expect AI timelines to be uneven

预期AI项目的时间线会不均衡

Aparna Chennapragada: "Time to first demo is much shorter, but time to full deployment is going to take longer. There's an uneven cadence." Plan for a shortened inner loop for prototyping but allocate significant time for the outer loop of scaling. Manage expectations about the gap between demo and shippable product.

Aparna Chennapragada：“首次演示的时间会短得多，但全面部署的时间会更长。节奏是不均衡的。”为原型设计的短周期内循环做规划，但要为规模化的外循环分配大量时间。管理好演示版本与可交付产品之间差距的预期。

Questions to Help Users

用于帮助用户的问题

"Is this an external commitment or an internal target? What happens if you miss it?"
"What phase is the work in - discovery, solutioning, or build?"
"Have you shipped a 'working version' yet, or is the team still figuring things out?"
"Where is the padding in this estimate? What assumptions are baked in?"
"How much of your time is actually going to focused work vs. meetings and distractions?"
"Are there too many 'P0 deadlines' competing for attention?"

“这是外部承诺还是内部目标？如果错过会有什么后果？”
“工作处于哪个阶段——探索、方案设计还是开发？”
“你们已经交付了一个‘可用版本’，还是团队仍在摸索中？”
“这个估算中的缓冲空间在哪里？包含了哪些假设前提？”
“你有多少时间真正用于专注工作，而非会议和干扰？”
“是否有太多‘P0截止日期’在争夺注意力？”

Common Mistakes to Flag

需要指出的常见错误

Committing to dates before discovery is done - You can't estimate what you haven't scoped. Commit to phases, not distant delivery dates
Too many high-priority deadlines - If everything is P0, nothing is. Reserve real deadlines for critical external events
Front-loading estimation instead of shipping early - Get to a working version fast and use remaining time to iterate
Ignoring the planning fallacy - Tasks take 3x longer than estimated due to distractions. Time-box and measure actual focused work
Asking for extensions - Professionals account for the unexpected. Build buffers rather than extending timelines

在探索完成前就承诺交付日期 - 你无法估算尚未界定范围的工作。要承诺阶段，而非遥远的交付日期
过多高优先级截止日期 - 如果一切都是P0，那就没有真正的P0了。仅将真实截止日期用于关键外部事件
前期投入大量估算而非尽早交付 - 快速做出可用版本，利用剩余时间迭代优化
忽视规划谬误 - 由于干扰，任务实际耗时是估算的3倍。使用时间盒并衡量实际专注工作时长
请求延期 - 专业人士会为意外情况做准备。要预留缓冲空间，而非延长时间线

Deep Dive

深入了解

For all 14 insights from 13 guests, see

references/guest-insights.md

如需获取来自13位嘉宾的全部14条见解，请查看

references/guest-insights.md