Back to Details

managing-timelines

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Managing Timelines

时间线管理

Scope

适用范围

Covers
  • Turning a deadline or target date into a clear commitment model (commit vs forecast vs target)
  • Building a phase-based plan (Discovery → Solutioning → Build → Launch) with decision gates
  • Creating a milestone tracker with simple RAG (red/amber/green) status and escalation triggers
  • Protecting the team when a deadline is real (treat it like P0, reduce distractions, control scope)
  • Setting a governance + comms cadence so stakeholders get early risk signals, not surprises
  • Handling “fast demo, slow production” cadence (especially for AI/ML features) via explicit outer-loop work
When to use
  • “We need to ship by <date>. Create a timeline/milestone plan and status cadence.”
  • “We have a launch date; convert this into phases, milestones, and a comms plan.”
  • “Stakeholders keep asking for dates; define what we can actually commit to and when.”
  • “The project feels off-track; set up RAG status + weekly exec review and escalation.”
  • “We can demo quickly, but production will take longer—help set expectations and plan the outer loop.”
When NOT to use
  • You haven’t defined the problem/outcome yet (use 
    problem-definition
    )
  • You need to pick which initiatives matter most (use 
    prioritizing-roadmap
    )
  • You primarily need to cut scope to fit an appetite/timebox (use 
    scoping-cutting
    )
  • You need a decision-ready PRD or build-ready spec/design doc (use 
    writing-prds
    / 
    writing-specs-designs
    )
涵盖内容
  • 将截止日期或目标日期转换为清晰的承诺模型（承诺 vs 预测 vs 目标）
  • 构建带有决策节点的阶段性计划（发现→方案设计→开发→发布）
  • 创建带有简单RAG（红/黄/绿）状态和升级触发机制的里程碑跟踪器
  • 当截止日期确定时为团队保驾护航（将其视为P0优先级，减少干扰，控制范围）
  • 制定治理和沟通节奏，让相关方获取早期风险信号，而非意外状况
  • 通过明确的外循环工作处理“快速演示、缓慢上线”的节奏差异（尤其针对AI/ML功能）
适用场景
  • “我们需要在<日期>前上线。请制定时间线/里程碑计划和状态更新节奏。”
  • “我们已有发布日期；请将其转换为阶段划分、里程碑和沟通计划。”
  • “相关方一直在询问日期；请明确我们实际能承诺的内容及时间。”
  • “项目似乎偏离轨道；请建立RAG状态+每周高管评审和升级机制。”
  • “我们可以快速完成演示，但上线需要更长时间——帮助设定预期并规划外循环工作。”
不适用场景
  • 尚未定义问题/成果（请使用
    problem-definition
    ）
  • 需要确定哪些举措最为重要（请使用
    prioritizing-roadmap
    ）
  • 主要需要缩减范围以适应资源/时间限制（请使用
    scoping-cutting
    ）
  • 需要可用于决策的PRD或可用于开发的规格/设计文档（请使用
    writing-prds
    / 
    writing-specs-designs
    ）

Inputs

输入信息

Minimum required
  • The deliverable and success bar (“done means…”) + key users/stakeholders
  • The date type: fixed deadline (external) vs target (internal) vs window (e.g., “late March”)
  • Constraints and non-negotiables (quality, compliance, privacy/security, platform, budget)
  • Team shape + capacity assumptions (who’s building; availability; parallel work)
  • Known dependencies and risks (other teams, vendors, data availability, approvals)
Missing-info strategy
  • Ask up to 5 questions from references/INTAKE.md.
  • If answers aren’t available, proceed with explicit assumptions and list Open questions that could change the date or scope.
最低要求
  • 交付成果和成功标准（“完成意味着……”）+ 关键用户/相关方
  • 日期类型：固定截止日期（外部）vs 目标日期（内部）vs 时间窗口（例如“3月下旬”）
  • 约束条件和不可协商项（质量、合规、隐私/安全、平台、预算）
  • 团队构成+产能假设（开发人员、可用时间、并行工作情况）
  • 已知依赖项和风险（其他团队、供应商、数据可用性、审批流程）
缺失信息处理策略
  • 从references/INTAKE.md中最多提出5个问题。
  • 如果无法获取答案，则基于明确的假设推进，并列出可能改变日期或范围的待解决问题。

Outputs (deliverables)

输出成果（交付物）

Produce a Timeline Management Pack in Markdown (in-chat; or as files if the user requests):
  1. Deadline & commitment model (what’s fixed, what’s variable; commit vs forecast vs target language)
  2. Phase plan (Discovery/Solutioning/Build/Launch) with outputs + decision gates + next commitment date
  3. Milestone tracker (owners, dependencies, dates, confidence, RAG) + RAG definitions
  4. Governance cadence (weekly review agenda, escalation triggers, decision log)
  5. Scope & change-control plan (cut list, non-goals, “trade don’t add” rule, freeze points)
  6. Stakeholder comms pack (weekly update template + escalation note)
  7. Risks / Open questions / Next steps (always included)
Templates: references/TEMPLATES.md
Expanded guidance: references/WORKFLOW.md
生成Markdown格式的时间线管理包（在对话中展示；若用户要求可作为文件输出）：
  1. 截止日期与承诺模型（固定内容、可变内容；承诺/预测/目标的表述规则）
  2. 阶段计划（发现/方案设计/开发/发布），包含输出成果+决策节点+下一次承诺日期
  3. 里程碑跟踪器（负责人、依赖项、日期、置信度、RAG状态）+ RAG定义
  4. 治理节奏（每周评审议程、升级触发条件、决策日志）
  5. 范围与变更控制计划（裁剪清单、非目标、“替换而非新增”规则、冻结节点）
  6. 相关方沟通包（每周更新模板+升级通知模板）
  7. 风险/待解决问题/下一步行动（必须包含）
模板：references/TEMPLATES.md
扩展指南：references/WORKFLOW.md

Workflow (8 steps)

工作流程（8个步骤）

1) Intake + deadline classification

1) 信息收集 + 截止日期分类

  • Inputs: User request; references/INTAKE.md.
  • Actions: Identify the deadline type (fixed vs target vs window), the “why now”, and what variable can move (scope, resources, quality, or date).
  • Outputs: Deadline classification + constraints snapshot.
  • Checks: You can state: “The date is <fixed/target/window> because <reason>. The variable we will trade is <scope/resources/etc>.”
  • 输入：用户需求；references/INTAKE.md。
  • 行动：确定截止日期类型（固定/目标/时间窗口）、“为何是现在”的原因，以及可调整的变量（范围、资源、质量或日期）。
  • 输出：截止日期分类+约束条件快照。
  • 检查项：可明确表述：“该日期为<固定/目标/时间窗口>，原因是<具体理由>。我们将调整的变量是<范围/资源等>。”

2) Define the commitment model (“commit vs forecast vs target”)

2) 定义承诺模型（“承诺vs预测vs目标”）

  • Inputs: Deadline classification; current knowledge of scope/unknowns.
  • Actions: Define what you will commit to now (usually a phase output), what you will forecast, and what remains a target. Set confidence levels and language rules for stakeholders.
  • Outputs: Commitment model section + communication rules.
  • Checks: Stakeholders can tell which dates are promises vs estimates.
  • 输入：截止日期分类；当前对范围/未知项的了解。
  • 行动：定义目前可承诺的内容（通常为阶段输出成果）、可预测的内容，以及仍为目标的内容。设定置信度水平和面向相关方的表述规则。
  • 输出：承诺模型章节+沟通规则。
  • 检查项：相关方可清晰区分承诺日期与预估日期。

3) Build a phase plan with decision gates

3) 构建带决策节点的阶段计划

  • Inputs: Deliverable; known unknowns; constraints.
  • Actions: Break the work into Discovery → Solutioning → Build → Launch. Define the output of each phase and the decision gate (what must be true to move forward). Only commit to dates that are within control (near-term).
  • Outputs: Phase plan with dates, outputs, and gates; “next commitment date” (when you’ll re-forecast).
  • Checks: Every phase ends with a tangible artifact and a go/no-go decision.
  • 输入：交付成果；已知未知项；约束条件。
  • 行动：将工作拆分为发现→方案设计→开发→发布。定义每个阶段的输出成果和决策节点（推进至下一阶段必须满足的条件）。仅承诺可控范围内的日期（近期日期）。
  • 输出：包含日期、输出成果和决策节点的阶段计划；“下一次承诺日期”（重新进行预测的时间）。
  • 检查项：每个阶段均以有形成果和是否推进的决策结束。

4) Create the milestone tracker (+ “demo vs production” outer loop when relevant)

4) 创建里程碑跟踪器（+ 相关情况下的“演示vs上线”外循环）

  • Inputs: Phase plan; dependencies; team capacity.
  • Actions: Translate phases into milestones with owners, dependencies, dates, confidence, and RAG. If AI/ML is involved, separate “first demo” from “production-ready” and explicitly add evaluation, data, safety, and reliability work.
  • Outputs: Milestone tracker table + RAG definitions.
  • Checks: Milestones are outcome-based (deliverables), not just activities; critical dependencies are explicit.
  • 输入：阶段计划；依赖项；团队产能。
  • 行动：将阶段转换为包含负责人、依赖项、日期、置信度和RAG状态的里程碑。若涉及AI/ML，需将“首次演示”与“可上线”拆分，并明确添加评估、数据、安全和可靠性相关工作。
  • 输出：里程碑跟踪表+RAG定义。
  • 检查项：里程碑基于成果（交付物）而非仅活动；关键依赖项明确可见。

5) Set governance: RAG + weekly reviews + escalation

5) 设定治理机制：RAG状态+每周评审+升级流程

  • Inputs: Milestone tracker; stakeholder map.
  • Actions: Define update cadence (weekly by default), who reviews, and escalation triggers (what turns yellow/red). Use a simple RAG system and a short weekly review agenda to unblock work.
  • Outputs: Governance cadence + weekly review agenda + escalation triggers.
  • Checks: A “red” status produces a concrete ask/decision, not just a warning.
  • 输入：里程碑跟踪器；相关方图谱。
  • 行动：定义更新节奏（默认每周）、评审人员和升级触发条件（何种情况转为黄/红状态）。使用简单的RAG系统和简短的每周评审议程来推进工作。
  • 输出：治理节奏+每周评审议程+升级触发条件。
  • 检查项：“红”状态需提出具体请求/决策，而非仅发出警告。

6) Protect the deadline: scope control + distraction shield

6) 保障截止日期：范围控制+干扰屏蔽

  • Inputs: Deadline type; milestone risks; incoming requests.
  • Actions: If the deadline is real, treat it like P0: define what gets deprioritized, reduce WIP, and implement change control (“trade, don’t add”). Create a cut list and freeze points (e.g., scope freeze, QA freeze).
  • Outputs: Scope/change-control plan + cut list + freeze points.
  • Checks: New scope cannot enter without an explicit trade-off and decision owner approval.
  • 输入：截止日期类型；里程碑风险； incoming请求。
  • 行动：若截止日期确定，将其视为P0优先级：定义需降级优先级的工作，减少在办工作项，并实施变更控制（“替换而非新增”）。制定裁剪清单和冻结节点（例如范围冻结、QA冻结）。
  • 输出：范围/变更控制计划+裁剪清单+冻结节点。
  • 检查项：新范围需经过明确的权衡和决策负责人批准后方可加入。

7) Stakeholder comms + expectation management

7) 相关方沟通+预期管理

  • Inputs: Commitment model; tracker; risks.
  • Actions: Write a weekly update template and an escalation note. Pre-wire stakeholders about uncertainty (especially the demo→production gap). Ensure comms use correct language (commit/forecast/target) and highlight asks/decisions.
  • Outputs: Comms pack (templates + initial draft update).
  • Checks: Updates include “what changed since last week” and “what decision is needed by when”.
  • 输入：承诺模型；跟踪器；风险。
  • 行动：撰写每周更新模板和升级通知。提前向相关方说明不确定性（尤其演示→上线的时间差）。确保沟通使用正确的表述（承诺/预测/目标）并突出请求/决策需求。
  • 输出：沟通包（模板+初始更新草稿）。
  • 检查项：更新内容需包含“自上周以来的变化”和“需在何时前做出何种决策”。

8) Quality gate + finalize

8) 质量检查+最终定稿

  • Inputs: Full draft pack.
  • Actions: Run references/CHECKLISTS.md and score with references/RUBRIC.md. Ensure Risks / Open questions / Next steps exist with owners and dates.
  • Outputs: Final Timeline Management Pack.
  • Checks: A stakeholder can approve the plan async and the team can execute without re-litigating dates every week.
  • 输入：完整的管理包草稿。
  • 行动：执行references/CHECKLISTS.md并通过references/RUBRIC.md进行评分。确保包含风险/待解决问题/下一步行动，并明确负责人和日期。
  • 输出：最终版时间线管理包。
  • 检查项：相关方可异步批准计划，团队无需每周重新讨论日期即可执行。

Quality gate (required)

质量检查（必填）

  • Use references/CHECKLISTS.md and references/RUBRIC.md.
  • Always include: Risks, Open questions, Next steps.
  • 使用references/CHECKLISTS.md和references/RUBRIC.md。
  • 必须包含：风险、待解决问题、下一步行动。

Examples

示例

Example 1 (fixed external date): “We’re launching at an industry event on May 15. Create a milestone plan, RAG cadence, and a comms template for Sales/Marketing/Execs.”
Expected: a fixed-deadline plan that treats the date as P0, with change control and clear escalation triggers.
Example 2 (AI uneven cadence): “We can demo an AI support agent in 2 weeks, but production will be risky. Build a plan that separates first demo vs production-ready and sets expectations.”
Expected: milestones that include evaluation, safety/reliability, and rollout steps; explicit commit vs forecast language.
Boundary example: “Decide what we should build this quarter and set dates for everything.”
Response: use 
prioritizing-roadmap
first; then apply this skill to the chosen initiative(s).
示例1（固定外部日期）：“我们将在5月15日的行业活动上发布。请为销售/市场/高管制定里程碑计划、RAG状态节奏和沟通模板。”
预期输出：将日期视为P0优先级的固定截止日期计划，包含变更控制和明确的升级触发条件。
示例2（AI节奏差异）：“我们可在2周内完成AI支持Agent的演示，但上线存在风险。请制定拆分首次演示与可上线状态的计划，并设定预期。”
预期输出：包含评估、安全/可靠性和部署步骤的里程碑；明确的承诺vs预测表述。
边界示例：“确定本季度应构建的内容，并为所有事项设定日期。”
回应：先使用
prioritizing-roadmap
；再将本技能应用于选定的举措。