去年深秋的那个凌晨三点，我在公司茶水间看着刚上线的系统后台一片飘红的报错，手里的咖啡凉得像冰。
没人想熬夜。
真的。
我们当时给整个团队定的目标是“11月30号之前完成客户管理系统的全量迭代”，从产品到开发到测试，所有人都盯着这个最终的deadline，没人问过中间每一步到底走得稳不稳。直到上线前72小时，我们才发现前端所有的用户行为埋点都写错了字段，后台根本收不到用户的点击数据——这意味着我们熬了俩月做的用户画像功能，从根上就是空的。
那时候我才反应过来，我之前信了好几年的“结果导向”，就是个坑。所谓的过程管理，根本不是我之前想的那种，拿着秒表盯人、催周报的破事。
我曾经把过程管理当成“抓考勤式的盯梢”
说出来不怕笑，前几年我带团队，搞过程管理的方式就是：每天下午六点在群里@所有人，发自己当天的进度；每周五下午开俩小时的进度会，每个人轮流说自己下周要干啥。
结果呢？
周报写得一个比一个漂亮，“完成了80%的需求开发”“推进了跨部门的协作流程”，真到要演示的时候，代码跑不起来，接口连不通，问就是“还差一点收尾”。
有个开发更绝，连续三周在周报里写“正在优化登录页的加载速度”，最后我才知道，他那三周一半时间在帮别的部门改bug，剩下的时间在调自己的私人项目，根本没碰我们的登录页。我当时气得不行，后来冷静下来想，我凭什么怪他？我从来没要求他拿出过任何可验证的中间输出，我只看他写的那几行周报字，换我我也能把周报吹得天花乱坠。
说白了，我之前那套所谓的“过程管理”，本质上就是把团队当成了需要盯梢的贼，既浪费大家的时间，又根本防不住真的风险。
真正有用的过程管理，是给每个节点装“刹车”
那次上线事故之后，我把之前所有的进度规则全删了，重新定了一套逻辑：不看你说自己做了多少，只看你能拿出来的东西，能不能跑。
我们把原来那个“11月30号交付”的大目标，拆成了每3天一个小节点，每个节点的要求只有一个：拿出能现场演示的东西，不准说“我在做”，只能说“你看，这个东西现在是这样的”。
比如做登录页埋点的那个节点，要求不是“完成埋点开发”，而是“你拿个手机扫一下测试码，后台能看到你点击登录按钮的记录”。就这么简单。
一开始大家都不适应，有个刚毕业的小开发私下跟我吐槽，说以前都是闷头写俩礼拜代码再拿出来，现在每三天就要被拉出来“过堂”，太麻烦了。结果第一次节点演示，他写的埋点在苹果手机上完全失效——那时候离大版本上线还有整整两周，要是等到最后才发现，我们又得熬三个通宵。他后来自己说，原来这个“破流程”不是来抓他错的，是帮他提前把坑填上，不用最后背锅。
我后来慢慢明白，过程管理从来不是为了把人管死，是为了把大的风险，拆成一个个小的、能解决的问题，别等到最后炸锅了才想起补救。就像开车的时候你不能等到要撞墙了才踩刹车，得提前在每个弯道、每个路口就把速度控住。
别让过程管理变成新的负担
不过话说回来，我见过太多公司，把过程管理搞成了新的形式主义。
填不完的表单，写不完的周报，开不完的同步会，一个节点验收要拉七八个人签字，光走流程就要花俩小时，最后干活的时间全被浪费在填表格上。
我们后来定了个死规则：所有用来跟踪过程的文档、表格，必须能在5分钟内填完，要是超过5分钟，直接砍。
原来的周报我们改成了三句话：这周我做完了啥，我现在卡在哪，下周我要做啥。没了。不用写套话，不用凑字数，哪怕你只写“这周修了三个bug，现在被支付接口的问题卡住了，下周要搞定支付的问题”，都算合格。
还有，我们从来不开超过30分钟的同步会，有问题直接拉相关的两三个人，15分钟说完就散。要是有人在会上扯闲篇，我直接打断，说“这个事我们会后单独聊，别耽误大家干活的时间”。
说真的，谁上班没摸过鱼？有个设计师同事，有时候下午灵感来了，会提前俩小时下班去江边坐俩小时，找灵感。我们从来不管，只要他能在节点前拿出符合要求的稿子就行。毕竟我们要的是能出活的人，不是每天坐在工位上熬够8小时的机器人。
后来我们再做项目，再也没出现过上线前才发现大问题的情况。有时候甚至能提前两天把东西做完，大家准点下班，不用再熬通宵。
前几天我跟那个之前吐槽流程麻烦的小开发吃饭，他现在已经是我们组的技术骨干了，自己带小项目的时候，第一件事就是把每3天的节点给拆好。
他说原来以前觉得过程管理是束缚，现在才知道，那是给干活的人搭的安全网。
对吧？
