我们组有个同事，以前是那种闲不住的人。现在也闲不住 只不过是不敢动了。
去年部门空降了一位新总监，阿里P8，第一次全员会PPT上就八个大字：拥抱变化，永不言弃。
新领导上来搞流程改革，每个模块指定Owner，出事追责到人，A级事故罚款500起步，B级300 依次类推，发版上线改配置全走审批。说实话之前部门确实乱，发版靠嘴说，出事互相踢，推这套的时候大家都觉得我们终于靠近大场了 挺正规的。那哥们周会上还主动表态，说流程规范是好事。
后来第一刀来得挺快。
有天快下班，隔壁组一同事小王跑来找他，说自己有个紧急修复要发，审批人请假了，让他帮忙点一下确认。就改了一行配置，测试都过了，客户催得急，回头请喝奶茶。
他犹豫了一下。按新流程他不是人家组的审批人，不该碰。但想着就点一下的事，以前没流程的时候这种忙天天帮，同事一场，不至于。就帮人点了，下班了。
晚上九点电话响了，线上炸了。小王那行配置把数据库连接池参数写错了，服务挂了半小时。
周一复盘会才是真正让他开眼的环节。
对方负责人复盘原因就是：事故根因------跨组违规审批，发布流程未严格执行。 然后一二三条分析下来------审批人不对，违规；操作记录是他的账号，赖不掉；代码变更经过了测试，问题出在发布环节没走正规流程。
他急了，说配置是小王改的吧？参数写错了才是根因吧？对方不慌不忙地说，测试环境没复现，走正规流程的话发布前有生产校验，问题能拦住。正因为跨组审批跳过了这步才流到生产。
代码没问题，测试没问题，全是不走流程的锅。小王改错参数？不重要。
小王全程低着头，会后微信发了句"哥对不住"，然后就没然后了。
A级事故，责任人他，通报批评罚款。
第二刀砍得更狠，因为砍的是他自己主动做的东西。
这哥们以前有段时间看各组都在写重复的工具类、异常处理，手痒，业余时间封装了个公共SDK。接入简单，引个依赖就行，自己项目跑了几个月没问题，后来三四个组都在用。领导还在周会上夸过他。
一年多零故障，然后某天下午好几个项目突然同时报空指针。查下来是某个项目组调SDK方法传了个null进来，那个方法没做null校验，直接炸了。
他跟我说的时候摊了摊手：是他们传了null，不是我SDK自己崩的。
但复盘会上人家写上原因：公共组件健壮性不足，缺乏入参校验机制。 防御性编程嘛，行业共识，公共组件就得对所有入参做校验。你文档写了不能传null，文档约束不等于技术约束。
结论：使用方有责任，但Owner负主要责任。
新领导也发话了：你写的东西别人用出了问题，就是设计不够健壮，调用方是有问题，但组件要做最后兜底。这话搁哪个技术分享会都挑不出毛病，但写代码的人听了就是憋屈。
又是一个500块 主责，次责研发，复盘报告他写。
500块不多，但那之后他整个人肉眼可见地变了。
有人找他帮忙发版，他笑笑说按流程走。有人想用他的工具，他说你自己看着办，出问题别找我。有人提议做公共组件提效，他直接摆手，别搞了各写各的。
他还把SDK文档改了，最上面加了一行红字：本组件仅供参考，使用者自行承担风险。
有次吃饭我问他，你怎么现在什么都不愿意多干了？
他放下筷子认真跟我说：你算这笔账------做十件好事没人记得，出一件事全是你的。按流程走每一步留痕，不该碰的别碰，到点下班绩效也不差。多一事不如少一事。
我说那你以前写那SDK图啥呢？
他扒了口饭：以前觉得做技术总得有点追求吧。
不过他有些话说得确实有道理。
他说你看这套制度推下来，事故率确实降了，发版也规范了，管理变得可预测可追溯，从管理角度肯定是成功的。但你看现在谁还愿意写公共组件？谁还做技术分享？谁还跨组帮忙？每个人守着自己一亩三分地，不出错就是最高目标。
制度管得住人不犯错，但管不住人不做事。你可以罚一个写错代码的人，但你罚不了一个什么都不做的人。
大厂那套东西能在阿里跑通，是因为人家有配套的激励体系、资源冗余、人才梯队。咱们十几人的小团队照搬，管理成本说不定比它能避免的损失还高。
他说得也对，但新制度带来的有好也有坏，也不能一概而论。
前阵子有个新人跑来问他：哥，我想做个公共工具库，你觉得怎么样？
我正好在旁边。他看着那新人愣了几秒，说：你先想想，出了问题谁来背锅？新人没说话。
现在每天按时交活，不越界不帮忙不创新，到点下班，周末电话都不接。
你觉得这算成熟了还是被磨平了？