上周三晚上十点半，我在公司楼下的全家啃着茶叶蛋，对着电脑里的项目甘特图发愣——原定上周要交付的用户调研模块，拖了整整六天。
风卷着梧桐叶打在玻璃门上，哗啦响。
我盯着甘特图上标红的延期节点，突然觉得有点可笑。三个月前项目启动的时候，我们拍着胸脯说这个模块是整个客户成功体系的核心，肯定能提前交付，结果现在卡在最基础的环节，谁都不肯先往前迈一步。
最开始踩的坑：把“目标共识”当开会念PPT
最开始做这个SaaS客户成功模块项目的时候，启动会拉了12个人，产品、开发、运营、销售全到了。我站在投影前面，花了40分钟把项目背景、最终目标、时间节点讲得明明白白，最后问大家”有没有问题”，所有人都摇头。
散会的时候我还挺满意，觉得大家都理解了。
结果第一周站会就乱了套。
产品经理说，他理解的核心目标是做自动触发的客户提醒功能，帮运营省回访的时间。运营主管说，他以为目标是搭一套全流程的客户回访SOP，要能直接给一线销售用。开发组长更直接，说他以为这次的需求是改后台的客户标签体系，已经在排数据库的优化计划了。
说真的，那时候我攥着笔的手都在使劲。合着我开了俩小时会，大家各记各的小九九？
之前有次更离谱，为了赶进度，我们跳过了和销售团队的对齐环节，闷头做了个客户分层的功能，等上线了才发现，销售那边根本不知道这个功能怎么用，甚至觉得这个功能反而给他们的客户跟进增加了步骤，整整两周的活，打了水漂。
所谓的目标对齐，从来不是你把话说完就算数，是要确认每个参与的人，能说出自己手上的活，和最终结果的直接关联。
后来我们改了启动会的规矩，不再花半小时念PPT，最后留20分钟，让每个人站起来说两句话：我这周要做的第一件事是什么，这件事做完之后，会给哪个同事的工作省麻烦，或者给最终目标加多少分。说不出来的，就留下来和我一起捋清楚再走。
中途的内耗：别让“等回复”变成拖进度的借口
项目推进到第二周，我翻聊天记录，看着三个部门的人在群里@来@去，突然就泄了气。
开发找产品要交互稿，产品说他在等运营给最新的用户画像数据。运营说他在等销售给上个月的流失客户访谈记录。销售说他在等市场部给的上季度活动转化数据，才能筛出来符合要求的访谈名单。
一圈转下来，三天过去了，群里没有一个人把手上已有的东西发出来。全在等完美的前提，全在等别人先动。
我那时候盯着屏幕，就想起之前看的那个笑话：三个人等电梯，一个人做俯卧撑，说他刚才是靠自己的力量上来的。这场景简直一模一样——所有人都觉得，要等所有的输入都100%完备了，才能开始动手，不然做出来的东西就是错的。
可实际上呢？
项目推进里最要命的拖延，从来不是谁故意摸鱼，是大家默认“没有100%完备的输入，就不能开始动手”。
之前运营要做客户回访的SOP，按之前的流程，得等销售把所有流失客户的访谈记录整理完发过来，才能开始搭框架。我们后来改了规矩，让运营先把去年存的老访谈记录翻出来，先把SOP的通用框架搭好，等销售的新记录到了，再把新的客户痛点填进去迭代。本来要等三天的活，当天就出了第一版框架，后面也没耽误任何进度。
后来摸出来的笨办法，比任何方法论都好用
说实话，我现在根本不信那些花里胡哨的项目管理理论。什么敏捷开发，什么OKR对齐，什么跨部门协同模型，听着都对，真落到具体的事上，全是虚的。
我们现在就两个笨规矩，用了快半年，项目延期的情况少了一大半。
头一条规矩，所有待办事项，除了写清楚负责人、交付时间，必须加一个“兜底人”。不是说负责人没做完就追责，是到了交付时间点，如果负责人没把东西交出来，兜底的人要先把手上能做的部分顶上去，绝对不允许整个环节停在那干等。比如之前那个等运营给用户画像的事，我们给这个事设了，运营周三下午六点前必须交第一版，哪怕只整理了20个客户的标签，兜底人是产品，周三晚上就可以先基于这20个客户的标签做第一版交互稿，后面运营补新数据的时候，再一起迭代。
另一条规矩，每周的项目站会，不许说“我等谁的什么东西”。要换成三句话：我手上现在有什么，缺什么，需要谁在什么时间点给我什么，我拿到之后多久能出东西。之前有个开发，每次站会都皱着眉说“我等产品的需求文档”，我们后来就盯着他说，你现在能先写哪部分的代码？哪怕是通用的工具模块，先写，不能干等着。后来他发现，其实很多通用的功能，根本不需要等需求文档出来，先写了，后面需求调整的时候，也只需要改很少的部分。
这些办法一点都不高级，甚至有点笨，但真的比你在会上讲半小时“高效协同”的大道理有用多了。
上次那个拖了六天的调研模块，我们用这两个规矩，花了三天就交付了。交付那天团队在楼下便利店买了冰可乐，冰得罐身的水珠粘在手上，大家站在路边喝，没人说什么豪言壮语，就有人嘟囔了一句“早这么干不就完了”。
那天风还是很大。
项目推进从来不是要找一个完美的流程，是要在所有不完美的条件下，找到能往前挪一步的最小动作。
