好规则，坏规则

每个团队都有自己的纪律，或叫规则，有的被明文规定出来，有的隐藏于行为习惯中，有的继承自公司的要求，有的来源于团队。问题来了，怎么评判规则的好坏呢？

以修复缺陷这个事为例，“缺陷要在被发现的当天修复”可以认为是个规则。但从另一个角度看，缺陷修复时效这个事应该是一个被观察出来的百分比，比如80%的缺陷能在发现的当天修复，用来了解团队对这类工作项的服务水平。

这个服务水平本身不适合做为规则（你规定不了），而保证这一结果的一系列策略更适合做为规则：

1）可测试的工作项才能支持测试人员尽早介入，有利于降低后期风险，避免修复缺陷的压力突增，于是一个策略就是确保分解出的每个工作项都是可测的。

2）缺陷发现的越及时就越容易定位和修复它，于是一个策略就是设置开发完成的工作数量约束，打破时开发做测试，经常打破就补充测试人力。

3）提高开发的初始质量有利于减少缺陷从而团队能更从容地修复有限的缺陷，于是一个策略就是开发按某标准自测和验收。

4）提高修复缺陷的优先级有利于快速修复，于是一个策略就是高优先级修复缺陷，其他“干扰”升级到管理者。

5）多一个有经验的人帮助有利于快速定位问题，于是一个策略就是评估有难度的缺陷需结对修复，等等。

上面提到了5个团队规则，它们在第一时间指导团队成员鼓足勇气做合适的现场决策，而不是把问题推到最后，这确保我们能观察到更好的缺陷修复服务水平。

可见，好的规则鼓励团队做及时的自我决策，坏的规则更关注在最后出问题时提供足够的压力。好规则往往伴随管理方式的改进，坏规则利用倒逼，是“有效”的传统手段。

我认为，“坏规则”最大的问题是逃避了管理责任，让结果变得不可预期，即使达到要求也可能深藏隐患。就像上面最初的那个缺陷修复规则，如果没有“好规则”的支撑，即使加班加点达到要求也会埋下内部质量的隐患并带来内耗和浪费。

更进一步总结一下，好规则的表现：

反映了一项策略，鼓励现时现地的自我决策

体现团队正面共识和文化，往往无需明文记录

带来结果而不是用结果倒逼

尊重现场的个人判断，鼓励打破和调整

坏规则的表现：

用结果当规则，简单粗暴，利用压力

涉嫌逃避管理责任

往往伴随内耗和隐患

需专人检视，或是常常被集体无视