前两天在甲方的会议室里，老板突然拍桌子，说他们手里的合同写的是“迭代式交付”，可是他们自己人手不够，工期又超了，还要在那儿扯皮。

我心想，这哪是管理啊，这分明是项目管理遇到瓶颈了，正常人都得坐牢。

那会儿总认定敏捷就是敏捷，只要加了几个看板就完事了，目前才发现，这才是真·痛苦。 实际上，敏捷那套理论早就烂大街了，泛泛而谈的无数文章、PPT 里早就堆满了“双周迭代”、“每日站会”、“Scrum Master"这些词。真正落地的时候，挖个坑，填个坑，半天就没了。你当作你是在做敏捷，实际上是在模仿。 真正的敏捷，不是坐在办公室喊口号，而是把项目当成一个有血有肉、会呼吸、能打仗的活生生的人。你别说，大量时候，用户比程序员更会“敏捷”。 上周有个项目，我们跟客户讲“敏捷开发”，结局客户在群里发了一堆截图。他们说自己改了需求，程序员说没工夫改，说赶工期。最终搞出来的东西，连个核心功能都没有，全是堆砌的功能点，像菜市场大妈的杂货摊，啥都有，但啥也没用。

这时候我才知道，他们搞错了一件事。敏捷不是让需求变多，而是让交付的速度和知足价值的节奏匹配。

要是需求本身是错的，哪怕代码写得再“优雅”，也是垃圾。

这就好比厨师想做一道拿手菜，但客户非要改成做火锅，厨师只能翻车。

这时候，不是厨师不敏捷，是灶台间的锅没洗干净利落。 记得有个团队，为了赶上市大促的上线，连续两周只开了 4 天站会。结局第一天站会，大家就忘了上次改过啥功能，重复聊聊昨天的 Bug，结局新 Bug 又冒出来了。

第二天，项目经理直接吼着气氛组：“再开一次！”然后大家又回到了最初的状态。

这种“制造焦虑”的行为，是不是比敏捷本身更让人头疼？ 有人会说，那为啥我们总说敏捷就是“快速迭代”？实际上不然。敏捷的核心是应对变化。变化无处不在，有时候是需求变了，有时候是技术栈不中，有时候可能是老板发来的新消息。面对这些变化，我们不是要僵化地执行盘算，而是要拆解盘算。

要是盘算定了 3 个月，中间突然有个新技术风口要么客户要加个新功能，这时候我们能不能说“明天启动做”，而不是“明天启动做”？ 那会儿我认定，敏捷就是把大任务切成小任务，然后一个个做。目前我认定，敏捷是准你回头看。每天下午 4 点，项目组的每个人都要停下来，问自己一个难题：“今天做的那件事，离目标还远吗？”要是远，就砍掉；要是近，就停下来改个 Bug。

这看起来像是在偷懒，实际上是极度的负责。一个项目，要是三天打鱼两天晒网，哪怕最终能做完，质量也绝对不中。真正的敏捷，是保证每一个小步都能走得稳，而不是为了快，把路走歪了。 这就得提到数据了。数据是敏捷的基石，但数据不是用来填表看数字的，是用来找难题的。上次我带团队做电商项目，为了评估“敏捷有效性”，我让每个人都发了一份周报，列出了“本周搞定啥”、“啥没搞定”、“下周盘算啥”。结局，我看了半小时，都像是在变相催命。真正的数据，应当是像复盘会议一样，大家坐在一起，指着白板，指着刚刚做出来的东西，对当天的表现打分。一个准点率打了 90 分，一个准点率打了 60 分，那天晚上我们开了个长胡扯，最终发现那个打 90 分的人，实际上是在 Using 模板，而不是在做敏捷。 还有个数据，我认定最关键：难题暴露的频率。

要是一个项目，一直等到上线发布会前一个月，才发现核心链路有 Bug，那说明之前的流程根本没建立好。敏捷时常是“救火队员”模式，忙得头都大了，才发现连个水龙头都拧不开。而真正的敏捷文化，是“预防”文化。在开发之前，就和客户说清楚，这个功能大约啥时候能成，大约如何成。

要是有风险，提前告诉，而不是等到代码写了一半，发现不中再改。改代码最痛苦，改需求改两次、改三次，有时候比改需求本身还累。 这就涉及到“自张罗”的概念了。

那会儿项目经理是监工，目前项目经理是教练，就连是那个在混乱中保持冷静、帮大家理清思路的人。你要知道，项目里的每个人都是专家，但没有人是全知的。遇到不懂的，大家就一起查、一起合计。项目经理的角色，不是做命令者，而是做连接器，把分散的个体变成整体上的一个整体。就像搭积木，你不能光指挥哪位先放哪，你得让大家知道，这块积木放在哪能搭出啥效果。 有时候你会发现，团队里根本没人讲话，表面上一片热火朝天。

这时候，如何让沉默的人开口？

如何让一个人做出来的东西，能被另一个人理解？那就要靠沟通。沟通不是扔个文档，是面对面地聊。

哪怕只是说“我认定这个描述有点歧义，改一下”，这也是沟通。敏捷需求高频的沟通，但不是无意义的闲聊。是带着目标性的交流，是为了让信息流快一点，为了让理解快一点。 说白了，敏捷开发项目管理，就是要在“控风险”和“求速度”之间走钢丝。一手抓合规，一手抓变通。你不能为了合规，把项目做得死气沉沉；也不能为了速度，把项目做得乱七八糟。最好的状态，是像玩泥巴一样，玩对了就玩下去，玩错了就立马换个泥巴玩。 最终，我想说，不要总想着把敏捷做成一套完美的 SOP（标准作业程序）。流程是死的，人是活的。

要是流程规定了你务必周一开会，那周一务必开；要是规定你不能加班，那加班也得搞定。但人呢？人总有情绪，总有突发状况。

这时候，灵活一点，略微破个格，有时候比死守流程更有用。 项目管理的艺术，不在于你制定了多少规则，而在于你有多大的包容心，有多高的智慧，能让团队在你感到累得慌或迷茫的时候，依然能自驱力地往前冲。大家都说敏捷，哪位敢告诉我，你是确实敏捷，还是假装敏捷？希望我们都能看到那个真正在干活、在思索、在想办法的人。

毕竟，发加班费的时候，别指望别人说我是为了敏捷加班的，只想说我是为了项目加班的。