当前位置:首页 > 科研成果库

别再把持续改进机制当年终总结凑数工具了

2026-10-21 09:03:57小研科研成果库6

上周四在南京河西产业园楼下,碰到之前同组的老周。

他蹲在路边抽电子烟,脚边还放着半袋没吃完的盐水鸭,脸皱得像刚蒸过了头的鸭血粉丝。

问了半天才知道,他们部门刚搞完半年度的持续改进复盘,收上来的几十份改进提案,翻来覆去全是“希望下午茶多加点芒果班戟”“希望团建的大巴离公司近点”这类话,领导拍着桌子说要把机制落地,结果落得一地鸡毛,连个能推的实际项目都没有。

你以为的改进,其实是在给流程打补丁

好多人对持续改进机制的理解,从根上就错了。

以为就是出了问题打个补丁,改完就拉倒。

我刚做前端那两年,踩过一模一样的坑。当时负责的电商系统,每到大促就出接口超时的问题,每次我们都是临时把超时阈值从2秒调到5秒,热修复完就开庆功会,觉得自己反应快、效率高。结果三个月下来,同一个问题犯了八次,每次大促的值班群里,全是@我的消息,熬得我眼睛里全是红血丝。

后来我们换了个思路,不再盯着“怎么快速把问题修完”,而是每次复盘的时候,必须挖到底,把根因找出来,再把对应的检查项加到发版的流程里。比如那次反复超时的根因,不是阈值设得不对,是我们从来没有在压测的时候,把峰值流量下的接口响应时间算进检查指标里。从那之后,每次发版前,我们必须核对压测报告里的峰值响应时间,不达标就不准上线。

真正的持续改进机制,从来不是解决某一个具体问题,而是建立一套“问题不重复犯”的自动循环。

你今天补了这个洞,明天那个洞又冒出来,那不叫改进,叫消防员救火。

互联网团队站会复盘问题白板实拍互联网团队站会复盘问题白板实拍

南京小厂的笨办法,比大厂的OKR好用

说起来好笑,我们团队之前在南京做ToB SaaS的时候,一开始学大厂搞什么改进OKR,定了一堆“季度效率提升20%”“流程优化覆盖率100%”的目标,搞了两个月发现根本没人理。

大家上班已经够累了,谁有空盯着这些飘在天上的数字干活?

后来我们索性把那套花里胡哨的东西全删了,定了个特别土的规则:每次迭代结束的复盘会,每个人必须提一个“自己上周做的时候觉得别扭的小事”,不许提别人的问题,不许扯公司层面的宏大叙事,就说自己手上的活。

比如有个刚入职的运营小姑娘说,每次给客户发试用账号,要在CRM、账号系统、邮箱三个后台之间复制粘贴信息,每次都要错两个字符,核对半天。我们当场就记下来,当天下午两个后端工程师花了两个小时,写了个简单的同步脚本,把三个系统的账号信息打通。就这么个小改动,小姑娘每次发账号的时间从15分钟降到了2分钟,每个月省出来的时间,够她多跟进3个意向客户。

我们从来没把这个当什么高大上的机制。就是觉得大家上班已经够辛苦了,能少点没必要的重复劳动,就算赢。

小团队迭代复盘手写改进清单便签墙小团队迭代复盘手写改进清单便签墙

别把改进机制搞成全员的负担

我见过太多公司,把持续改进机制搞成了全员的KPI负担。

要求每个部门每个月必须交够多少份提案,必须落地多少个改进项目,攒够积分才能换绩效加分。结果呢?大家为了凑数,什么水提案都敢往上交。

有人把会议室的桌子从左边挪到右边,下个月再挪回来,美其名曰“空间布局优化”;有人把团队群的公告换个排版,就敢说是“沟通机制升级”。折腾来折腾去,大家的精力全花在凑数上,根本没人关心这些改动是不是真的能帮大家省力气。

持续改进机制的核心边界,是不增加额外的无效工作量。

我们团队后来定了个死规矩:凡是需要大家花超过10个小时额外精力去搞的改进项目,除非是已经影响到线上稳定性的大问题,否则一律不碰。之前有人提说要把整个团队的文档全部迁移到新的知识库系统,算下来每个人要花差不多15个小时整理旧文档,我们直接就否了。现有系统虽然不好用,但大家已经用熟了,迁移的成本比用旧系统的成本高多了,这就不是改进,是纯粹的折腾。

没人是傻子。

你搞的东西是真的能帮大家少干活,还是为了凑领导的考核指标,大家心里门儿清,对吧?

我之前在苏州见过一个做精密零件加工的车间,人家没有什么高大上的数字化系统,就是在每个机床旁边贴了个线圈本,操作的工人每次换模具的时候,觉得哪个步骤不顺手,就写在本子上。每周五下午班组长花20分钟,把本子上的内容过一遍,能当场改的就马上改——比如哪个扳手放的位置不对,就挪到顺手的地方;哪个参数设置得不合理,就当场调整。改不了的就往上汇报,申请资源支持。就这么个简单的机制,他们车间的生产效率,比隔壁同规模的车间高了差不多30%。人家也没天天把“世界级持续改进体系”挂在嘴边,就是觉得干活的时候能少点别扭,就多赚点钱。

上周老周给我发消息,说他回去把之前收上来的那些水提案全撕了,下次复盘就按我说的来,每个人只说自己上班时觉得“这事能不能别这么折腾”的小事,不许提别人,不许扯公司战略。

第一次复盘会下来,他们收上来的最实在的一条提案,是运维岗的小伙子提的:每次改个线上配置,要走三层审批,找三个领导签字,每次要等两个小时,赶上出告警的时候,等审批下来,故障都扩大了。他们当场就定了,核心配置的修改,只要是值班的运维确认没问题,就可以改,事后补记录就行。

就这一个小改动,他们上周处理线上告警的平均时间,从40分钟降到了12分钟。

你看。

哪有那么复杂。