不要将关口设为可选，而应使其灵活

# Wakamoleguy - wakamoleguy 之家 来源：https://wakamoleguy.com/p/flexible-gates ## 别把关卡设为可选，要让它们灵活 2026年6月26日当你需要一个审批检查点，却不想让它无处不在时，让关卡*要求但形式灵活*，而不是*可选但正式*。一个要求的关卡降低了误判风险所带来的后果。 ## 可选但正式关卡的问题 Pam 是一名产品经理，正在推动团队路线图。Hopper 是产品负责人，担心过度投入有风险或未经证实的项目。一项新政策出台：所有大型项目在纳入路线图之前，必须起草一份商业案例并提交给他审批。 Pam 看到后琢磨："什么算*大型*项目？"有些事明显界限分明：新产品推出算大型；更新设置 UI 算小型。但中间还有一大堆情况。Pam 很担忧。"要是我花时间给不需要商业案例的项目做正式商业案例怎么办？或者更糟，要是我推进了一个领导层认为本应做商业案例的项目怎么办？那风险太大了！" 这种关卡迫使 Pam 做出一个不可能的元决策。如果她单方面推进，风险在她身上。如果她求稳，整个团队就会因为等待正式审批流程而慢下来。 ## 灵活更优 在另一个平行宇宙，Hopper 实施了不同的政策：所有路线图都需经过他批准，但批准形式可以灵活。对于大型、高风险项目，可能仍需商业案例和讨论。对于较小或更安全的项目，一个快速的 DM 对话就够了。 表面上看这听起来很相似，但从 Pam 的角度考虑一下。风险发生了巨大变化。现在，即使是较小的决策，Hopper 也知情。Pam 可以放心地偏向速度。最坏的情况是 Hopper 回复："实际上，我认为这需要更深入的讨论；你能安排一次商业案例讨论吗？"而且无论批准性质如何，*确实有*一个批准环节。Pam 可以自信地推进她的路线图。 一份表格比较了 Pam 在两种关卡制度下的处境。在可选但正式关卡下：Pam 需要提前独自决定一个项目是否需要审查；猜错意味着浪费工作或未经批准的风险项目砸在自己手里；未能及时发现；所以她只能采取对冲策略，放慢速度。在要求但灵活关卡下：Hopper 根据完整信息做决定；猜错只会得到一个补充细节的提示；在决策落地前就被发现；所以 Pam 偏向速度，自信推进。这种灵活性并非偶然。正是灵活性使得要求成为可能，而不会让 Hopper 成为审批瓶颈，也不会让 Pam 花费大量时间打磨商业案例文档。大多数审批都是轻量级的，可以快速（且批量）完成。注意力留给最需要决策的地方。DM 上的一个赞耗时几秒；错过一个有风险的项目则会让团队损失数月。 ## 另一个例子：代码审查 软件工程团队在代码审查中经常看到这种做法。大多数公司都有政策：任何 PR 在合入前必须获得批准（不可选）。PR 的详细程度和审查深度则是灵活的。简单的 Bug 修复或依赖更新可能只需要简短的描述和快速盖章（"LGTM！"）。更复杂的 PR 则需要更多解释和更深入的检查。如果作者误判了复杂性，关卡会及时提醒：审查者说"嘿，你能再多说说这个改动吗？"或者留下详细评论，然后代码才能发布。 "这不就成了橡皮图章式审批吗？"如果你的团队即使需要深入审查时也没有认真做，我不确定流程改变能帮上忙。你得和你的团队成员好好谈谈！或者，如果复杂性*永远都不够高*，那么一个尖锐的问题是：这个审批检查点真的在提供价值吗？ ## 多个可调旋钮，善用它们 一个2x2的关卡矩阵。纵轴：要求 vs. 可选。横轴：正式 vs. 灵活。要求+正式：沉重且缓慢；要求+灵活：自信且快速；可选+正式：模糊陷阱；可选+灵活：建议性质，并非真正的批准。要记住的是，当一个要求的正式审批检查点显得过于沉重时，你有多个旋钮可以调节，而不仅仅是可选性。在很多情况下，一个要求但轻量的检查点比完全移除检查点更能帮助团队快速、自信地行动——移除检查点只会让团队陷入模糊、厌恶风险的状态。 干杯！