上周三跟合作了三年的产品总监喝冰美式，他皱着眉说上周上线的客户定制项目，离交付期只剩21天，核心功能的联调还卡着，团队每天开俩小时站会，人人都说“在推进”，但实际进度条动都不动。
真的。
我太懂这种无力感了。
你以为的“进度正常”，可能只是大家都在“假装推进”
去年我带团队做企业服务系统迭代，一开始每周拉同步会，每个人报的进度都是“完成80%”“在对接”“待确认”，我看着满屏的乐观数字，还特意在周会上夸了大家效率高。结果离交付只剩半个月拉进度复盘，才发现根本不是那么回事——前端等着后端的接口文档，后端等着产品经理的需求签字，产品经理还在跟客户来回改细节，所有人都在等，所有人都觉得自己没拖后腿。
当时我真的火大。
把一摞打印的进度表摔在会议室桌上的时候，手都抖。
后来复盘才想明白，我们之前的进度统计，全是靠人嘴报，没有对“完成”的定义做统一标尺：什么叫完成？是写完代码就算，还是跑通测试用例才算，还是跟上下游对接完签了确认单才算？没人说。
所有模糊的进度汇报，本质上都是给团队留了“假装努力”的空间。你不把完成的标准钉死，就总会有人用“我已经开始做了”来应付你，至于什么时候能做完，做到什么程度，全凭心情。
后来我们改了进度统计的规则，所有汇报进度的内容，必须绑定可验证的交付物。比如你说“完成了用户模块开发”，就得把跑通的测试链接附在进度表后面，没有链接的进度，一律算0%。改完规则第一周，之前报“完成80%”的三个开发，直接把进度改成了15%——不是他们故意撒谎，是之前大家对“完成”的尺度太松了。
别把“拆目标”拆成没人接的散纸片
之前我也跟着网上的管理教程学，说要把大目标拆成小目标，拆到天，拆到人，越细越好。我照着做了大半年，结果踩了好大一个坑。
上次做用户运营活动的项目，我们把“活动上线”的大目标，拆成了“设计活动页面”“写活动规则”“配置后台奖品”“对接投放渠道”四个小任务，每个任务都分到了人，看着整整齐齐的任务表，我当时还挺得意。结果临上线前三天，才发现设计做完的图，尺寸跟前端的开发框架完全不匹配，活动规则写了三版，运营和产品对奖品发放的口径都没对齐，后台配置的奖品库存，比实际能发的多了两倍。
说穿了，就是拆目标的时候，光顾着列“要做什么”，根本没说清楚每个任务做完了要交给谁，要达到什么标准，出了问题谁担着。那些散在共享文件夹里的任务，就像没人接的传单，风一吹就没影了。
后来我们拆任务的时候，强制要求每个条目必须写清楚三个要素：具体交付物是什么，直接对接的接收人是谁，截止时间是哪天。比如不是“做活动banner”，是“9月12号之前，交付3张宽度750px、符合前端开发框架要求的活动banner，直接发给前端开发小张，做完在任务系统里@小张确认收悉”。
拆目标最忌讳的，是把“要做什么”列出来，却忘了写清楚“做完之后要给谁、要达到什么标准”。飘在天上的细任务，不如一个落了地、有人接、有明确交付标准的小节点。
改了这个规则之后，我们的任务返工率直接降了一半。之前总觉得拆目标越细越好，现在才明白，拆到最后没人接的任务，拆得再细也没用。
那些卡着不动的节点，别等“有空了再解决”
之前有个跨部门的合作项目，需要市场部出一份近半年的客户调研数据，一开始对接的同事说“最近忙，等下周给你”，我们就很懂事地把这个事记在待办清单里，等着。
结果等了两周，市场部那边换了新总监，之前对接的同事调去了别的业务线，那份调研数据存在哪个共享盘文件夹里，没人说得清，我们又从头开始对接，硬生生耽误了一周的进度。
我后来真的学乖了。
但凡涉及跨部门的卡点，绝对不搞“等一等”的默契。上次有个项目，需要法务部审合作协议，对接的人说这周案子多，可能要排到下周，我没等着，直接拉了个三个人的小群，把项目的交付时间、协议涉及的核心条款、如果晚一天审完会导致的客户流失损失，全写在群公告里。当天下午，法务就把审完的版本发过来了。
很多人觉得项目推进卡壳，是因为团队不够努力，是因为大家配合不好。其实根本不是。大部分的卡点，都是因为大家都默认“这个事总会有人管”，都在等一个合适的时机，等一个“不忙的时间”，结果等着等着，约定的截止时间就到了。
上周跟之前皱着眉头的产品总监再见面，他已经把项目的进度表全换了，每个节点都标了交付标准、对接人，每天的站会不超过15分钟，谁的节点卡了，当场就协调资源解决。现在离交付期还有一周，核心功能的联调已经跑通了80%。
他笑着说，之前总觉得项目推进就是天天催进度，现在才明白，你追着人跑，不如把路给人铺顺了。把每个坑都标出来，别让大家走着走着就掉进坑里，进度自然就跑起来了。
对吧。
