第3章 评审节奏制定原则：节奏类型、频次确定、周期对齐

适用场景

本章节适用于以下场景：

• 新建项目启动评审：项目初期需为PRD文档建立跨团队评审节奏，确保各阶段评审有序进行。
• 迭代/版本切换：产品进入新迭代或版本周期，需要重新调整评审节奏以适应变更频率。
• 跨团队评审冲突：多个团队参与评审时出现时间冲突或节奏混乱，需统一校准。
• 评审效率优化：现有评审节奏导致等待过长或反馈滞后，需要系统性调整节奏类型与频次。

前置条件

1. 已完成评审参与方识别（第2章输出），明确各团队角色与职责。
2. 已获得项目主计划或迭代日历，作为周期对齐的基准。
3. 已收集历史评审数据（如平均评审时长、反馈周期、阻塞次数），用于频次决策。
4. 已确认PRD变更触发机制（如需求变更流程、紧急通道），为事件驱动节奏提供输入。

操作步骤

步骤1：识别评审需求与约束条件

汇总项目阶段、团队资源、变更频率、风险等级等信息，形成评审需求清单。

• 项目阶段：探索期、交付期、维护期——不同阶段对评审密度要求不同。
• 变更频率：统计近1-2个迭代的PRD变更次数，识别高频变更区间。
• 风险等级：高风险模块需要更频繁的评审节点。
• 团队日历：标注各团队已有的固定会议（如迭代计划会、站会、发布评审），避免冲突。

步骤2：选择评审节奏类型

根据步骤1的输出，在以下三种节奏类型中选择主导模式（可组合使用）。

步骤3：确定评审频次

基于节奏类型和约束条件，计算具体评审频次。

• 固定节奏频次公式：频次 = 1 / (平均PRD变更间隔 × 团队并行数 × 风险系数)。
  例：变更间隔7天、团队并行数2、风险系数1.2 → 频次 ≈ 每3.5天一次 → 取整为每周2次。
• 里程碑驱动频次：按里程碑数量分配，每个里程碑至少安排1次初审+1次终审。
• 事件驱动频次：设定触发阈值（如PRD变更超过5个/天、涉及3个以上团队），达到阈值自动触发。

步骤4：对齐跨团队周期

将评审节点插入各团队已有周期，形成统一评审日历。

• 对齐对象：开发迭代周期、测试计划、发布窗口、跨团队同步会。
• 对齐原则：评审节点应位于迭代前期（需求澄清后）、中期（方案确认）、后期（发布前把关）。
• 冲突消解：当评审与团队固定会议冲突时，采用“微调偏移”策略（±1天）或“双通道”机制（线下预审+线上快审）。

步骤5：输出评审节奏方案

将前三步的决策汇总为文档化方案，包含节奏类型、频次表、周期对齐甘特图、应急触发条件。

输入输出物

责任边界

• PRD负责人（发起人）：提供评审需求与约束信息，确认节奏类型选择的合理性。
• 各团队负责人（开发/测试/设计等）：提供团队日历，确认频次可行性，对齐周期窗口。
• 产品经理 / 项目总监：决策最终节奏类型与频次，审批节奏方案。
• 评审协调人（或PMO）：负责步骤1-5的具体执行，输出方案文档与日历，处理冲突。
• 变更控制委员会（CCB）：审核事件驱动节奏的触发条件与应急流程。

记录材料

以下为评审节奏方案文档的YAML配置示例，用于记录节奏类型、频次与对齐信息：

review_cadence_scheme:
  project: "智能助手V3.0"
  version: "1.0"
  cadence_type: "fixed_milestone_mixed"
  fixed_cadence:
    frequency: "每两周"
    day_of_week: "周二 14:00-16:00"
    scope: "常规PRD变更与优化"
  milestone_cadence:
    milestones:
      - name: "M1-需求基线"
        date: "2025-05-10"
        review_type: "初审+终审"
      - name: "M2-方案锁定"
        date: "2025-06-05"
        review_type: "终审+签字"
      - name: "M3-发布前"
        date: "2025-06-25"
        review_type: "发布评审"
  event_driven_cadence:
    trigger_rules:
      - condition: "PRD变更数 > 5/天"
        action: "触发紧急评审"
      - condition: "涉及团队数 >= 3"
        action: "触发跨团队快审"
    review_window: "24小时内完成"
  cycle_alignment:
    aligned_with: "开发迭代两周制"
    review_insertion: "迭代第2天(初审) 第7天(终审)"
    conflict_resolution: "微调±1天 或 双通道预审"

异常处理

验收标准

1. 完整性：节奏方案文档包含节奏类型、频次表、周期对齐甘特图、应急触发条件4个核心模块，无缺项。
2. 可执行性：评审日历中各节点已明确日期、时间、参与方、时长，且与团队日历无直接冲突（冲突项已附消解方案）。
3. 共识性：所有相关团队负责人已在节奏方案上签字或通过邮件/IM确认，确认记录存档。
4. 可调整性：方案中预留了“频次观测窗口”（前3次评审后复盘调整），并定义了调整触发条件（如参与率<60%或反馈延迟>2天）。
5. 应急覆盖：事件驱动节奏已定义至少2条触发规则，且应急通道流程已同步至所有参与方。