为什么回顾会让人觉得是浪费时间？

Source: Dev.to

“我们刚刚花了 300‑400 美元在讨论鸡巴**。”
— 回顾顾问，在主持了两个小时的会议后

模式

冲刺 1： “我们的 CI 流水线太慢了。”
冲刺 2： “CI 流水线仍然很慢。什么也没改变。”
冲刺 3： “我们能升级吗？”
冲刺 4： 没有人再提 CI 流水线。

我在不同公司、行业和团队规模中看到过这种模式数十次。具体问题会变，但轨迹完全相同。

组织免疫

当团队识别出一个问题时，通常会落入以下两类之一：

• 类别 1 – 团队可解决： 沟通模式、代码审查实践、内部流程。
• 类别 2 – 组织依赖： 预算、人员编制、基础设施、跨团队流程。

令人不舒服的数学事实：70‑80 % 的有意义问题属于类别 2。这会触发组织免疫——中和对现有权力结构的威胁的机制。

促进幻觉

敏捷行业常把功能失调的回顾归咎于糟糕的促进：尝试帆船模型、玫瑰与荆棘，甚至海盗主题的会议。促进技巧可以略微提升参与度，但它们无法赋予团队解决他们无法控制的问题的权力。

把责任归咎于促进，就像把建议箱的责任推给管理层不阅读建议一样。

真正有效的做法

• 按控制范围分类

  • 绿色 – 团队可以解决
  • 黄色 – 团队可以影响
  • 红色 – 没有控制权

• 把时间集中在绿色问题上 – 这些是唯一有实际行动可能的事项。

• 记录红色问题，不要反复争论 – 维护一份组织阻碍日志。确认、指向它，然后继续前进。

• 有策略地升级 – 量化影响，提出带成本的解决方案，并设定截止日期。

• 接受有些问题永远无法解决 – 某些组织问题在领导层眼中被视为特性，而非缺陷。

不舒服的真相

回顾最初是为团队层面的改进而设计的，适用于团队能够控制的情境，而不是组织变革的机制。我们告诉开发者敏捷会赋能他们，给他们仪式来暴露问题，随后却把这些“被赋能”的团队嵌入到传统层级中，预算、人员配置和战略都由上三级决定。

回顾成了一个泄压阀：表面上有发声，却没有实质性的权力。高级开发者保持沉默——不是因为冷漠，而是对有限影响力现实的适应。

最初发表于 agilelie.com