上一篇写的是季度复盘材料预组装：把 rule revision trace、owner capacity delta、carryover risk 和 unresolved decision 提前整理成证据包。
材料准备好以后，复盘会还有一个更难的问题：这些判断怎样进入下一季度 roadmap。
如果没有明确转换机制，roadmap 很容易回到熟悉路径。最常见的是，谁讲得更具体，谁的主题就先排；哪个团队更会表达风险，哪个议题就更像优先级；上季度最痛的事故，也可能压过更长期的治理缺口。
这一篇写一个轻量做法：把季度复盘结论转成 roadmap 争议项清单和决策顺序，让下季度计划先处理真正需要裁决的问题，而不是只处理最容易被讨论的问题。
1. 复盘结论不要直接变成 roadmap item
季度复盘会结束后，很多团队会直接把结论写进 roadmap：
1
2
3
4
| roadmap_items:
- strengthen_admission_rule
- improve_owner_capacity_management
- close_audit_replay_gap
|
这种写法看起来很快，但问题是它跳过了争议识别。
复盘结论进入 roadmap 前，至少要先问三件事：
1
2
3
4
5
6
7
8
9
10
11
| retrospective_to_roadmap_gate:
finding: owner_capacity_was_over_committed
should_be_roadmap_item: maybe
dispute_questions:
- is_this_a_capacity_rule_problem
- or_is_this_a_scope_admission_problem
- or_is_this_an_incident_buffer_budget_problem
decision_needed_before_roadmap:
- choose_primary_problem_type
- choose_owner_constraint_change
- decide_whether_to_reduce_new_items
|
也就是说，复盘结论不是 roadmap item，而是 roadmap 争议项的输入。
只有当争议被裁决，团队才知道下季度应该改规则、砍范围、补容量，还是把某个风险继续作为 baseline gap 管控。
2. 先把结论拆成 dispute list
争议清单不是会议纪要。
它只承接那些会影响下季度资源、准入规则、交付包边界或风险状态的判断。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
| roadmap_dispute_list:
quarter: 2027_q1
source_retrospective: 2026_q4
disputes:
- id: dispute_api_contract_as_workflow_entry
source_packet: rule_revision_packet
question: can_stable_downstream_api_contract_replace_human_workflow_entry
affected_rules:
- benefit_capability_requires_workflow_entry
affected_packages:
- internal_capability_onboarding
- external_team_adoption_path
decision_type: admission_rule_boundary
- id: dispute_release_platform_owner_capacity
source_packet: owner_capacity_packet
question: should_release_platform_team_accept_new_governance_items
affected_packages:
- replay_gate_completion
- exception_preview_workflow
decision_type: owner_capacity_constraint
- id: dispute_audit_replay_manual_step
source_packet: carryover_risk_packet
question: should_remaining_manual_step_block_next_quarter_admission
affected_rules:
- release_gate_replay_required
decision_type: baseline_gap_or_blocker
|
这一步的关键是把“要做什么”推迟一点。
先把需要裁决的分歧写清楚。否则 roadmap 会过早进入排期，后面再发现规则边界没定、owner 容量不够、风险状态没关，就只能在执行中返工。
3. 每个争议项要有 decision type
争议项如果只写成问题，很难排序。
需要给每个争议项标注 decision type：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| decision_type_catalog:
admission_rule_boundary:
changes:
- who_can_enter_next_quarter_roadmap
- which_evidence_is_accepted
owner_capacity_constraint:
changes:
- who_can_accept_new_items
- how_much_incident_buffer_is_reserved
baseline_gap_or_blocker:
changes:
- whether_risk_blocks_new_scope
- whether_remaining_gap_must_be_carried_as_named_work
portfolio_tradeoff:
changes:
- reliability_baseline_vs_benefit_capability_ratio
- exploratory_investment_budget
|
decision type 的作用不是分类好看，而是帮助团队理解这个决策会改变什么。
如果一个争议项会改变准入边界，它应该早于普通交付包排序。因为准入边界不定，后续所有主题都可能排错。
如果一个争议项只影响局部实现路径，它就不应该占用 roadmap 最前面的裁决窗口。
4. 决策顺序先排 blocker，再排容量，再排收益
roadmap 决策顺序可以很简单。
先处理会阻塞后续判断的事项，再处理容量约束，最后处理收益排序。
1
2
3
4
5
6
7
8
9
10
11
12
| roadmap_decision_order:
stage_1_blocking_rules:
- dispute_audit_replay_manual_step
- dispute_api_contract_as_workflow_entry
stage_2_capacity_constraints:
- dispute_release_platform_owner_capacity
stage_3_portfolio_tradeoff:
- dispute_preview_policy_cleanup_reentry
- dispute_new_team_self_service_diagnosis
stage_4_execution_sequence:
- q1_delivery_package_order
- first_month_checkpoint
|
这个顺序能避免一种常见误判：大家先讨论最有业务收益的主题，最后才发现关键 owner 没容量，或者 baseline gap 没关，导致前面的收益排序全部重来。
治理类 roadmap 尤其需要先排 blocker。因为很多治理包不是单点功能，而是建立执行边界。边界没定，后续越细的排期越容易失真。
5. owner 决策包要在排序前出现
owner 容量争议不能等排完 roadmap 再处理。
如果一个 owner 在上季度已经连续低于准入容量，下季度 roadmap 就不能默认它仍然能接新增治理项。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| owner_decision_packet:
owner: release_platform_team
q4_retrospective_signal:
- capacity_below_threshold_for_2_months
- replay_gate_completion_kept_minimum_closure_only
- exception_preview_workflow_rejected_new_scope
q1_decision_options:
- option: freeze_new_governance_items
consequence:
- only_baseline_gap_closure_allowed
- option: allow_one_new_item_with_incident_buffer
consequence:
- incident_buffer_required
- scope_must_be_smaller_than_2_points
- option: keep_original_capacity_assumption
consequence:
- high_risk_of_repeat_overcommitment
recommended_decision_window: before_portfolio_tradeoff
|
这里不需要把 owner 的所有工作重新拆一遍。
只要把上季度复盘信号、下季度可选决策和每个选项的代价写清楚，就能避免 roadmap 会议中出现“先排进去，后面再协调”的默认动作。
6. 争议项要绑定可接受的证据
争议项进入 roadmap 之前，还要说明什么证据能关闭争议。
否则争议会在多个会议之间漂移。
1
2
3
4
5
6
7
8
9
10
11
12
13
| dispute_evidence_contract:
dispute: dispute_api_contract_as_workflow_entry
accepted_evidence:
- named_downstream_consumer
- stable_api_contract_for_2_release_cycles
- repeated_use_metric_above_threshold
rejected_evidence:
- one_time_integration_request
- verbal_commitment_without_usage_metric
- internal_demo_without_consumer
decision_can_close_when:
- accepted_evidence_count_at_least_2
- no_rejected_evidence_used_as_primary_reason
|
这份 evidence contract 能让争议项不被“看起来也合理”的材料带偏。
它还可以反向约束下季度执行：如果某个交付包要靠这条争议结论进入 roadmap，就必须先补齐证据，而不是在执行中继续解释为什么它应该被允许。
7. dispute list 要能输出 roadmap action
争议项不是为了制造更多流程。
它最后必须输出一个明确 action：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| dispute_resolution_output:
dispute: dispute_audit_replay_manual_step
decision: treat_remaining_manual_step_as_blocking_baseline_gap
roadmap_action:
type: blocking_work
package: replay_gate_completion
required_before:
- new_exception_preview_workflow
- external_team_policy_cleanup
owner: release_platform_team
q1_acceptance:
- manual_step_removed_for_policy_exception_case
- replay_api_covers_top_3_audit_paths
trace:
source_retrospective_packet: carryover_risk_quarterly_packet
decision_meeting: q1_roadmap_dispute_review
|
输出 action 时要避免两种极端。
一种是只输出“继续跟进”，这等于没有决策。另一种是直接输出完整项目计划，过早把执行细节写死。更稳的做法是输出 action type、依赖关系、owner、下季度 acceptance 和 trace。
8. 一个最小转换模板
把这些内容合起来，可以形成一个最小模板：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
| retrospective_to_next_quarter_roadmap:
source_quarter: 2026_q4
target_quarter: 2027_q1
inputs:
- rule_revision_packet
- owner_capacity_packet
- carryover_risk_packet
- unresolved_decision_packet
dispute_list:
required_fields:
- dispute_id
- source_packet
- decision_type
- affected_rules_or_packages
- accepted_evidence
- rejected_evidence
decision_order:
stages:
- blocking_rules
- owner_capacity_constraints
- portfolio_tradeoff
- execution_sequence
outputs:
required_fields:
- decision
- roadmap_action_type
- owner
- q_next_acceptance
- trace
|
这份模板可以在季度复盘后一周内冻结第一版。
冻结的不是最终 roadmap，而是争议边界。后续如果新增证据，可以追加到 dispute evidence contract；但不能在没有说明来源的情况下，把一个新偏好直接塞进 roadmap。
小结
季度复盘材料解决的是“证据从哪里来”。roadmap 争议清单解决的是“这些证据要改变什么决策”。
复盘结论不要直接变成 roadmap item。先拆成 dispute list，再标注 decision type，按 blocker、容量、收益和执行顺序排序。owner 决策包要在 portfolio tradeoff 前出现，争议项也要绑定可接受和不可接受的证据。
这样下季度 roadmap 就不会只跟着熟悉主题或声音最大的需求走。它会先处理真正改变准入边界、owner 容量和 baseline gap 的问题，再进入交付包排序。
下一篇可以继续写 roadmap 争议项被裁决后，如何把决策顺序落到下季度第一个月的执行检查点和 owner acceptance window，避免计划刚开始就偏离复盘结论。
本文永久链接: https://www.mulianju.com/learning-notes/ai-learning-notes-llm-governance-quarterly-retrospective-roadmap-dispute-list-decision-order/