晋升驱动型开发是什么
当晋升标准与“重大项目”强绑定时，工程师会倾向于追新框架、新建系统，避开维护性工作，形成俗称“简历驱动开发”的行为模式。个人理性选择叠加起来，结果是重复建设、系统越建越多，而真正决定稳定性的维护投入无人愿意承担。
怎么缓解
从标准入手：把晋升证据扩展到稳定性提升、知识传承、协作贡献与长期影响，并在评审中把“减少复杂度、下线系统”与“新建系统”同等看待。同时让维护工作可见——值班质量、故障率下降、接棒人培养都应写进评价材料，否则标准改了也无人相信。
基本信息
| 症状 | 热衷新框架新项目、不愿维护遗留系统、抢功劳轻复盘 |
|---|---|
| 根源 | 晋升标准单一偏向可见的新建设 |
| 对策 | 证据维度多元：稳定性、传承、协作、长期影响 |
| 观测 | 项目数量与系统下线数量是否长期失衡 |
典型使用场景
- 技术选型会议：区分真实需求与“可写在简历上”的动机
- 项目立项评审：要求说明为何不复用既有系统
- 晋升材料评审：核对是否有维护与稳定性类贡献
- 架构评审：把减少依赖与下线服务列为正向成果
- 离职交接：检查关键系统是否有接棒人
- 年度复盘：统计新建系统数与退役系统数
标准改进示例
标准改进示例
加分项补充：
- 把关键系统稳定性提升到可度量的新水平
- 沉淀被其他团队复用的规范与工具
- 培养出可独立值班与交付的接棒人
- 主导下线冗余系统，显著降低维护面
减分信号：长期只提新建方案，不参与既有系统治理行为信号与代价
| 信号 | 短期收益 | 长期代价 |
|---|---|---|
| 硬造新系统 | 个人材料亮眼 | 重复建设，运维面扩大 |
| 回避遗留系统 | 精力集中在舒适区 | 老系统风险累积到停摆 |
| 只抢新功能 | 曝光度高 | 稳定性与文档无人负责 |
| 轻视复盘 | 省时间 | 同类故障反复发生 |
缓解措施要能被验证：如果连续两年晋升材料里几乎看不到维护类贡献，说明标准只是写在纸上，评审环节并未真正采信。