深度解析文牍主义什么意思？为什么会影响工作效率

我最近在琢磨一个词，叫“文牍主义”，这玩意儿看着挺高大上，就是一堆没用的废话和流程，把简单的事情搞得贼复杂。

我先是自己琢磨了琢磨，最近工作上就碰到不少这玩意儿的影子。比如，一个简单的需求变更，本来三个人碰个头就能解决的事情，非得搞出一套复杂的审批流程，各种签字盖章，发现流程走完了，需求也变好几次了。

动手梳理流程

我决定动手梳理一下我们手头这个项目。我们这边有个很老的项目，维护起来特别头疼，文件一大堆，写文档的人都不知道是啥时候写的，没人敢动。我第一步就是把这个项目的文档系统摸了个底。

• 我找到了那个文档管理的系统，登录进去，发现里面堆满了各种“周报”、“月报”、“项目计划初稿”、“项目计划终稿”、“项目计划修订版A”、“项目计划修订版B”……看的我眼晕。
• 我开始筛选，把那些明显是历史遗留，没人看的文档给删掉或者归档了。这个过程特别费劲，删一个文件都得走好几步，生怕删错了，还得找对应的人签字确认。
• 我开始看那些关键的流程文档，比如需求提交流程、代码审批流程。我发现很多地方都写得特别绕，一个步骤卡住，下面的人就干瞪眼。

简化和实践

光看不改那没用，我得试试怎么简化。我挑了一个最折腾人的“线上 Bug 修复流程”下手。

原来的流程是：发现 Bug -> 提交工单 -> 团队负责人确认 -> 再提交给技术经理审批 -> 经理同意后才能开始修复 -> 修复完再走一遍审批流程验证 -> 才能上线。

我找了几个核心骨干开会，大家一致觉得这太慢了。我提议了一个简化方案：对于低风险的 Bug，如果团队负责人确认了，直接修复，上线前通知相关人员就行；高风险的直接走快速通道，负责人和技术经理双签，半小时内必须给答复。

我们把这个新流程试跑了一周。刚开始大家还有点不适应，总想着跑那个老流程，我得天天提醒。但跑了两天，大家发现效率明显提升了，以前一个紧急 Bug 搞完还得等半天审批，现在半小时搞定，大家干活的劲头都起来了。

遇到的阻力

改流程总会有人不乐意。有个老同事，干了十几年了，特别喜欢用“文牍”来证明自己的存在感。他天天跟我说：“小张，这流程是老领导定的，不能乱动，万一出问题，谁负责？”

我跟他解释，我们不是不要流程，是不要那种光走形式的流程。我把新旧流程的修复时间做了个对比图给他看，他才稍微缓和了一点。我甚至把他的名字特意加到了新流程的“重要参与者”里，让他感觉自己参与了制定，而不是被强行改革的。

我们把这个简化流程固化了下来，虽然还有一些小摩擦，但整体效率上去了不少。文牍主义这东西，说白了就是把“过程美化”看得比“结果有效”还重要，我们得学会把这些虚头巴脑的东西给砍掉，才能真正干成事儿。