Review Latency 是可见性问题，而非人员问题

Source: Dev.to

开发周期中的真正瓶颈

大多数工程团队认为他们面临审查速度问题。他们设定 SLA 目标，安排专门的审查时段，并在 Slack 上催促人员。但在本周观察了许多团队的模式后，有一点非常明确：瓶颈很少是某人审查 PR 的速度，而是 在有人注意到 PR 存在之前 所花的时间。

通知墓地

GitHub 和 GitLab 都会发送通知——邮件提醒、应用内徽章、Slack 集成。然而 PR 仍然会停留数小时——甚至数天——才收到第一次审查。

为什么？因为信噪比太差。一个跨多个仓库工作的开发者可能每天会收到 dozens（数十）条通知。邮件通知会被过滤，Slack 消息会被快速划过，GitHub 的通知标签页则成为未读项目的墓地，没人会再去翻看。

PR 已经存在，通知已经发送，但没有人真正 看到 它并拥有足够的上下文去行动。

过程救不了你

自然的反应是增加更多流程：强制分配审查人、在每日站会中检查未审查的 PR、自动提醒。这些措施在边缘上可能有帮助，但它们只是在治疗症状，而不是根本原因。

根本原因是碎片化。当你的团队工作分布在 15 个仓库、两个 Git 平台和三种沟通工具中时，根本没有一个统一的地方可以让人一眼看到当前需要关注的事项。

可见性是乘数

交付最快的团队不一定是审查习惯最严谨的团队。他们是那些 打开的 PR 不可能被错过 的团队。

这在不同的设置下表现形式不同。有的团队使用仪表盘，有的团队使用 PR 看板。在 Code Board 我们构建了跨仓库、跨提供商的统一视图，并加入风险评分，正是因为我们不断看到这种模式——最大的收益来自于在正确的时间把正确的 PR 推送给正确的人。

但无论使用何种工具，原则都是一样的：如果你想缩短周期时间，别先让人们审查得更快，而是先确保他们能看到需要审查的内容。

本周该做的事

• 衡量团队的 首次审查时间（time‑to‑first‑review），而不仅仅是合并时间（time‑to‑merge）。
• 检查有多少 PR 在超过 24 小时内没有任何审查人交互。
• 诚实地询问团队：你们是否总是知道有 PR 在等你？

答案会告诉你是纪律问题还是可见性问题。大多数情况下，答案是后者。