项目经理被裁那天，没人替他说话

简单写个自我介绍。

我在团队里算不上的管理层，没有人事权，也不决定谁走谁留，但我参与的项目一旦出问题，最后都会落到我这里。进度卡住、需求反复、线上事故，会议上可以绕一圈再绕一圈，最终还是要有人把代码改完、把锅兜住。我清楚自己的位置，用武之地比较多的一个“多功能开发者”而已。还依稀记得，当初总部另外一个项目的入侵测，找的还是我，而不是再招一个人。

所以我很少参与评价人，只谈事，谈事实，谈项目是怎么一步步偏离轨道的。

先直接告诉大家结果吧，他被辞退了。

当初公司决定要不要这个人的时候，无意中跟我提到过。我只讲述了几个项目事故，以及其他同事和他合作时的态度。至于留不留他，我不想决定，也决定不了。

那个项目经理，其实并不“坏”。他不吼人，也不甩脸色，会议纪要写得很勤，群里回复永远是“收到”“我跟一下”。问题出在另一层面：需求变更没有留痕，风险评估永远是“可控”，节点延期总能找到外部理由。

上面看到的是一条被不断抚平的曲线，下面看到的是每天被推翻重来的开发计划。我们不是没提醒过，只是提醒被整理成了更好看的版本，再往上递的时候，已经失去了原本的锋利。当然，这些最后都会被归结为一句话——开发同学多努努力，多扩展下思维，补补这个缺点就好了。

但我认为，有些问题其实在内部一直被反复提起，只是从来没有被真正放到台面上说过。

团队里的其他项目经理，大多都有过开发背景。哪怕代码早就不写了，对功能复杂度、实现成本、技术边界心里都是有尺度的。评估的时候会留余量，也知道什么时候该踩刹车。

只有他完全没有开发经验，对一个需求的理解停留在“看起来不难”的层面。既怕自己显得不专业，又怕在会上被认为拖进度，于是每次评估都偏向最激进的版本，功能报得满，时间压到极限。

开发这边明知道不现实，那又怎么办呢？你能说得过他吗？况且领导也是只看结果，活干得快，公司赚得多，干得慢赚得少。所以开发也只能硬着头皮往前推。

一次延期还能解释成意外，两次三次之后，延期就成了默认选项。项目表面上在跑，实际上每一步都在透支客户的耐心。

他甚至能把一个月的功能，压成 7 个工作日。

结果显而易见。项目连夜上线，第二天直接崩溃：APP、小程序白屏，数据无法保存，ToC 的用户一个都打不开。我们凌晨 4 点发完版本，早上 6 点半问题出现，7 点钟起床开始处理。

我起床的时候就已经料到了。项目有他管控着，您就放一万个心吧，麻烦肯定少不了。

当时写功能的时候，有个同事请了丧假。他来了句逆天发言：“到时候你能把电脑带上吗？有事可以找你。”

我当时真想告诉他，兄弟，全公司不是只有他一个前端，这个项目也不是只有他一个前端。人家就请假 3 天，已经很紧张了，还让人把电脑带着，真特么丧良心。

真正的转折点，是那次 A 项目上线。

我没有提任何人的名字，也没有用情绪化的词，只是把时间线拉直：哪一天确认需求，哪一天推翻，哪一天出 PRD，哪一天出 UI，最终导致了什么结果。那份文档写得很长，不好读，也不“体面”，但它有一个特点——每一个问题，都自然地指向了同一个岗位职责。

我提交的时候，甚至没多想，只觉得这次总算把事情说清楚了。

事后我想过，如果我当初不写那份复盘，不跟领导说这些事，会不会结果不同。答案大概是否定的。项目不会因为沉默变好，问题也不会因为不点名而消失。

那天没人替他说话，并不是因为他人缘差，而是因为在那个位置上，他已经很久没有为任何人、任何结果，真正说过一句“这是我的责任”。

系统从来不需要情绪，它只是在某个时刻，停止了包容。

我后来也明白了一件事：在很多公司里，项目经理这个角色，本质上是一个缓冲层。缓冲需求、缓冲压力、缓冲管理层的焦虑。

但一旦缓冲只剩下过滤，没有承担，系统就会重新校准。

那天被裁的不是一个人，而是一种失效的角色设计。而这件事，迟早会发生在任何一个不再为结果站出来的位置上。