运营自主改规则，工程师能彻底解放吗？

嚯... 在互联网较大厂或创业公司的日常协作中， 有一个心照不宣的“战场”：运营人员在文档里写满各种繁杂的逻辑需求，而工程项目师在代码堆里对着这一些需求揉碎了地头疼。最典型的场景莫过于此——运营想改一个活动页的领券门槛，或者调整一下推送消息的触发人群。如果当前这个规则是坚硬编码在程序里的，那么运营得提交需求单 $\rightarrow$ 产品经理评审 $\rightarrow$ 研发排期 $\rightarrow$ 开发修改 $\rightarrow$ 测试回归 $\rightarrow$ 发布上线。这一套流程走下来有可能一周过去了而运营此时有可能已经觉得当前这个规则“过时”了。

于是“配置化”成了全部技术手段团队追求的圣杯。较大家都在鼓吹：只要把规则交给运营自主修改， 盘它。 工程项目师就能从繁琐的碎片化需求中彻底解放。但事实真实的如此吗？

所谓的“解放”， 其实是一场权力的移交

很更多工程项目师在构建“规则引擎”或“可视化配置后台”之初，内心是极其兴奋的。想象一下：你写良好一套灵活的逻辑框架，定义良好几个参数接口，然后把后台账号交给运营。从此以后无论他们想怎么改权沉重、怎么调阈值，都只需要在界面上点点鼠标，点击“保存”，瞬间生效。你终于能够关掉那个地方的没完没了的需求群，宁静地去探究底层架构或者刷 LeetCode 了，我emo了。。

但这种兴奋往往保持不到一个月。很迅速你会发觉，当你给了运营“自主改规则”的权力时你实际情况是是将一种名为“不可控”的风险因素移交给了他们。 我emo了。 这是因为运营关注的是业务指标，而工程项目师关注的是系统平稳性。

当一个运营为了追求极端的转化率， 设置了一个极其繁杂的嵌套过滤条件时他有可能并不了解这会引起数据库产生一次全表扫描；当他随手将某个权沉重系数从 1 改成 100 时, 他有可能没意识到这会触发下游系统的级联崩溃。这时候，原本简洁的“改一行代码”，变成了紧急的一次全线回滚和彻夜未眠的复盘会。