如何检测 IT 项目中资深开发者被初级开发者替换

供应商如何用初级开发者替换资深开发者，以及如何识别

在外包给外部IT承包商的项目中，开发速度下降了好几倍——原本两天就能完成的任务现在拖了几个星期。原因不是技术债或架构复杂，而是三分之一的资深开发者被悄悄替换成了初级开发者。这不是个案：在独联体市场，这种替换正成为一种系统性做法，尤其是客户上线后不监控团队组成时。

为什么替换会悄无声息

专家级别的替换很少一次性发生。供应商逐步行动：先把一个资深开发者“调到另一个项目”，换上一个“准资深”的、简历很好的新人，一个月后再换另一个。客户在报告中看到的是相同的团队结构，在Jira中看到的是相同的名字，但实际执行者的技能水平在下降。形式上——一切按合同，实际上——欺骗。

促成这种套路的關鍵因素：

• 客户对替换无强制审批权。
• 关注形式化指标（工时、冲刺任务），而非代码质量和解决方案深度。
• 客户技术主管或架构师参与不足。

客户将所有技术责任完全委托给供应商、没有定期代码审查和审计的项目尤其脆弱。如果没人检查谁在写代码、怎么写，替换就会在速度急剧下降前无人察觉。

如何在危机前发现替换

你可以在问题击中截止日期很久前就检测到。这里是关键指标：

• 无客观原因的速度放缓——如果任务复杂度没增加、技术债没积累，但任务关闭变慢，那就是第一个信号。
• 返工和bug增加——初级开发者出错更多，需要修复。如果QA或生产中的bug比例上升——检查谁写的。
• 代码质量下降——出现反模式、无视标准、以往有测试的地方现在缺少。
• 剩余资深者的负担加重——如果关键开发者突然开始“帮助”所有人，他们可能在弥补新手的低水平。
• 沟通语气变化——初级开发者问架构问题变少，更常要具体指令，避免复杂任务。

定期代码审查、与客户代表参与的结对编程，以及指标分析（例如圈复杂度、覆盖率、变更率）有助于及早发现问题。

该怎么办：预防措施和应对

如果遇到替换——别慌，系统性地重新掌控。这里是分步行动计划：

• 进行技术审计——不是看简历，而是看实际代码和提交历史。谁碰过哪些模块？频率如何？质量怎样？
• 恢复替换透明度——在合同中添加条款，要求供应商任何专家替换须经客户技术代表批准。
• 让资深者回归关键角色——预算允许的话，用中级/资深替换初级。不行的话——重新分配任务：让初级处理明确范围、文档齐全的代码段。
• 任命技术监督——客户哪怕派一个架构师或技术主管每周审查，也能将替换风险降低80%。
• 修订团队KPI——别只看纯工时和关闭票据，引入质量指标：每提交bug数、返工时间、变更覆盖率。

市场危险信号

一些供应商有意识地将这种套路作为商业模式，加剧了局面：用市场价吸引客户的高级团队，然后逐步换成更便宜的专家，保持利润。尤其在高竞争、价格压力大的地区常见。

两条铁律保护自己：

• 资深每小时低于25美元——危险信号。在独联体市场，真正资深不会低于这个价。如果报价太好——通过测试任务或现场编码检查水平。
• 供应商无技术主管或PM——风险。没有技术领导的团队更容易技能退化。技术主管是挡住不合格替换的天然过滤器。

关键要点

• 用初级替换资深不是失误，而是某些供应商为提升利润的故意策略。
• 首批迹象：速度放缓、bug增加、代码质量下降——危机前很久出现。
• 防护：强制替换审批、定期代码审查、客户方技术主管。
• 独联体资深低于25美元/小时的市场价——几乎总是骗局。
• 预防胜于治疗：上线时嵌入控制机制，比半年后修项目更好。

别信形式报告。检查谁在真正写你的代码——今天，而不是六个月前。你的项目依赖的不是花哨简历，而是键盘后的真手。

— Editorial Team