核心用法
Project Planning 是一套面向复杂项目的六阶段深度规划工作流，专为多团队协同、硬截止日期或外部依赖场景设计。使用时需确认规划风格（里程碑制、敏捷发布火车或混合模式），随后依次推进：
1. Frame Outcome（框定成果）：明确问题陈述、成功标准、非目标与约束条件（时间、预算、合规），产出单页章程供利益相关方对齐。
2. Decompose Work（工作分解）：将项目拆分为 Epic 或 WBS，优先采用垂直切片（端到端薄功能），避免"先做完全部后端"的横向堆积。
3. Map Dependencies（映射依赖）：识别外部团队、供应商、法务、安全、基础设施等关键路径依赖，预留评审与采购提前期，输出含负责人、需完成日期、状态的依赖表。
4. Schedule & Buffers（排期与缓冲）：识别关键路径，对高风险未知项而非所有任务统一加缓冲；设定里程碑并附可演示的验收标准。
5. Risks & Mitigations（风险与应对）：列出高概率/高影响风险，指定负责人、缓解措施及 Plan B 触发条件。
6. Operating Rhythm（运营节奏）：建立稳定沟通机制——周战术同步、里程碑评审、RAID 日志更新、决策日志记录以防反复讨论。
显著优点
- 依赖显性化：核心设计哲学是将隐藏依赖尽早暴露，这是项目失败的首要根源。
- 约束透明化：强制明确"固定范围+固定日期+固定质量"三选二的权衡。
- 灵活适配：既支持传统里程碑制，也兼容敏捷发布火车，甚至为小型团队提供最小可行方案（MVP RAID+周优先级）。
- 反模式识别：针对研究型任务建议先时间盒 Spike，避免过早承诺交付日期。
潜在局限
- 学习曲线：六阶段流程对简单项目可能过度设计，需判断触发条件（多团队、硬截止、外部依赖）是否成立。
- 工具依赖：工作流本身不提供工具集成，依赖人工维护依赖表、RAID 日志等。
- 敏捷张力：虽宣称兼容敏捷，但"里程碑意图"可能对纯敏捷团队造成节奏冲突。
- 无实时协作：缺乏同步协作机制，跨时区团队需额外设计异步对齐方式。
适合人群
- 技术项目经理、Scrum Master 需升级至跨团队复杂交付
- 产品经理面临 scope creep 需与高层进行优先级对话
- 工程负责人经历时间滑落后需诚实重新基线
- 中大型企业需协调外部依赖（法务、安全、供应商）的标准化规划
常规风险
- 规划仪式化：团队机械走完六阶段却未真正对齐约束，沦为" checkbox 工程"。
- 缓冲误用：均匀给所有任务加缓冲会掩盖真实关键路径，应聚焦高风险未知。
- RAID 日志僵尸化：风险登记册创建后无人更新，建议在 Operating Rhythm 中嵌入强制更新节点。
- 非目标漂移：未明确排除的功能在过程中悄然进入范围，需反复引用 Charter 中的 non-goals 进行辩护。