
前言
深夜,项目终于交付。看着报表上达标的利润数字,本该松一口气,心里却像堵了一块石头。
复盘会上,大家客套地互相祝贺,但我关上门,对着屏幕上的Bug列表和排期表,久久无法平静。我们赢了数字,却输了过程;拿到了合同,却透支了未来。
这是一篇写给35+技术同僚的复盘。内容有些赤裸,甚至带着血腥味。能看懂的,或许能救你一命;看不懂的,划走便是。
如果你是个程序员,已经35+,还混在软件行业,那么我建议你好好看看。
这次【某某某】项目,做得极其费劲。品质隐患频发,团队疲惫不堪。虽然最终利润达标,但过程中的惊险,只有我们自己知道。
本质原因只有一个:资源极度匮乏下的“既要又要”。
从部门视角看,我们的核心资源(A、B、C)屈指可数。真正能支撑起复杂移行工具分析、架构落地、疑难杂症攻关的,就这么几个人。
但这几个人,被撕扯成了碎片:
公司要生存,必须不断提案、拿新项目。没有项目就没有收入,没有收入就是死路一条。于是,为了“拿活”,核心资源被迫投入到无休止的提案作业中;为了“交付”,他们又必须在极短的工期内完成高难度的落地。
既要拿下高难度合同,又要确保零缺陷品质,还要极限压缩工期。这在逻辑上本身就是个死结。
回顾整个项目历程,价值创造残酷地遵循着二八原理。
80%的团队成员,只能做辅助性工作:跑脚本、执行测试、整理文档。这些工作固然必要,但真正的核心价值——移行策略的制定、深层Bug的根因分析、水平展开的预防机制——完全依赖那20%的核心资源。
最致命的问题来了: 移行中的Bug,往往是改Source代码“埋”进去的。做进去多少个隐患,就得挖出多少个Bug。在不懂业务全貌的情况下,普通测试人员只能发现表面现象,核心的故障分析和水平展开,非核心资源不可。
当工期被压缩到极致,核心人员分身乏术时,我们被迫做了什么?
加人,不仅没用,反而成了负担。这就是“既要又要”带来的必然恶果:工期过短,导致核心人员动作变形,品质防线全面失守。
在复盘中,有一个话题我们无法回避,甚至有些“残忍”:人员能力的结构性错位。
这里不谈年龄歧视,只谈**“性价比”与“抗熵增”**。
第一类困境:资深员工的“停滞”我们遗憾地发现,部分老员工陷入了“经验陷阱”。
第二类困境:整体能力的“依赖”普通员工缺乏举一反三的能力,遇到稍微复杂的问题,本能地依赖核心资源。
这不是针对某个人,这是对所有停止进化者的警告。在软件行业,停止学习的那一刻,你就已经开始被淘汰了。
面对“既要又要”的死局,解决方案只有三条路:
如何重构?
这很残忍吗? 是的。想到那些上有老下有小、身体每况愈下的老同事,我也于心不忍。但市场更残忍。如果公司因为效率低下、成本高昂而倒闭,所有人都将失去饭碗。为了让大家能长久地有饭吃,我们必须保证团队的战斗力和利润率。
权责一致,是职场最基本的契约。干着3级的活,就对得起3级的工资;想要5级的待遇,就必须扛起5级的责任,解决5级的问题。
写完这篇复盘,心情复杂。
我想对每一位35+的技术人说:不要抱怨环境残酷,不要指望公司养你一辈子。 在这个快速迭代的行业里,唯一的铁饭碗,是你不可替代的能力。
想要活得舒坦,想要轻松赚钱,想要不断发展,我们就必须砍掉自身的“拖油瓶”属性,努力成为“核心资源”。
如果团队中“拖油瓶”越来越多,大家只会走得越来越累,直到再也带不动,一起坠入深渊。
愿我们都能在风暴中,找到那个不可替代的自己。愿每一次复盘,都是为了更好地出发。