上周整理旧电脑的时候翻到个皱巴巴的Excel，是2021年那个跨部门权限重构项目的跟进表。当时我在表的第一行用红笔写了“绝不做催债式跟进”，结果后面的跟进记录全是“@产品部张哥 进度？”“@开发李姐 这周能出demo吗？”，整整27条，连我自己看着都烦。现在想起当时项目延期4个月的复盘会，老开发那句“你这么会做你来写？”，我还脸发烫。
把跟进做成“盯人”，是最蠢的机制设计
那时候刚升主管，满脑子都是“要盯紧进度，不能出问题”。我以为的跟进机制，就是定好几个时间节点，到点就挨个问进度。完全没考虑过，大家手上不止这一个项目——产品部的张哥同时要接3个需求，开发的李姐还要带新人。
更蠢的是，我当时的节点定得全是模糊的“时间点”，没有对应的输出标准。比如定了“第2周出需求文档”，我到第14天就准时去问，结果张哥挠挠头说“哦，上周业务部要加个新的权限校验，我忘了同步给你”。合着我这两周的等待，全是无效的。
说白了，我当时根本不是在做跟进机制，是在当人肉闹钟——到点就响，响完就忘，既没对齐标准，也没留风险同步的通道。整个项目的进度，全靠我一个人在群里@人，大家看到我的消息就烦，有卡点也不敢说，怕我骂。
后来复盘的时候，找了公司做了10年管理的老周聊，他扔给我一句：你跟进的是事，不是人。当时我愣了半天，才反应过来——我盯着的是“张哥这周有没有写需求”“李姐有没有敲代码”，根本没盯着“这个节点要产出什么东西”“出了问题谁来解决”。
能落地的跟进机制，从来不是给人套枷锁
后来做618用户增长活动的筹备，我推翻了之前的所有跟进逻辑。没有定每天要报什么进度，没有要求大家写没人看的日报，只是把每个核心节点的输出物列得明明白白：
需求节点的输出物，是“带业务、产品、开发三方签字的评审记录”，不是“需求写完了”；
开发节点的输出物，是“测试环境可操作的demo链接”，不是“代码写完了”；
上线前的输出物，是“第三方接口的联调测试报告”，不是“接口对接完了”。
更重要的是，我把“跟进”的主体从自己，换成了每个节点的对接人。规则只有一条：如果某个环节卡了，对接人要直接在群里@对应的解决人，附上自己的测试截图或者问题描述，不用等我去协调。
活动筹备到第3周，我本来在开另一个会，突然看到群里跳消息——开发的小宇@了技术部的接口对接人，附了一张支付接口的报错截图，说“这个权限申请卡了3天，麻烦帮忙看下”。我刚想打字问要不要我出面，就看到对接人回了“刚才已经提交申请，10分钟后给你权限”。
我盯着群聊记录，差点笑出声。原来跟进机制不是让我当传声筒，是让每个环节的人自己动起来。那天我全程没说话，活动最后比原定时间提前2天上线。
别追求完美的机制，能跑起来的才是好机制
刚把这套机制用在618项目上的时候，我飘了。熬了两个晚上，把从需求到复盘的所有环节拆成了27个节点，每个节点都列了输出物、对接人、跟进时间。结果发到群里，整整3天没人填，我差点把电脑砸了。
后来问了小宇才知道，大家手上的项目太多了，27个节点的表，光填就要花半小时，根本没人愿意做。我才反应过来——我追求的是“完美的机制文档”，根本不是“能帮大家推进项目的工具”。
后来我把27个节点砍到了5个：需求评审、demo测试、灰度上线、全量上线、复盘会。每个节点的跟进只问三个问题：输出物齐了吗？有卡点吗？需要协调什么？就这三个，多一个字都没有。
现在我带团队，跟进群的规则简单到离谱：每周三下午3点，我会发一次固定的节点提醒，平时大家有卡点自己在群里说，没有就不用冒泡。我从来不会在非固定时间@任何人问进度——毕竟谁都不想干活的时候，突然弹出领导的“进度？”消息，对吧？
上周有个新来的实习生问我，“跟进机制是不是要每天催大家报进度？”我翻出那个皱巴巴的旧Excel给他看，说“你要是想被全团队骂，就天天催”。
哦对了，之前那个怼我的老开发，现在在新的项目里当技术对接人。昨天他在群里发了个demo的链接，附了一句“支付接口的卡点已经解决，下周可以进测试”。
你看。
跟进机制的本质，从来不是盯着人干活。
是让干活的人，敢把难处说出来，敢把进度亮出来。
