项目黑帽

《项目黑帽》

凌晨三点，项目黑帽张野把最后一行代码提交到仓库，项目黑帽顺手删掉了本地分支。项目黑帽三年来他第一次没有写提交说明。项目黑帽第二天早上九点，项目黑帽甲方项目经理在群里发了一条消息：“系统上线后用户投诉激增，项目黑帽请各位排查。项目黑帽”张野没回。项目黑帽他正坐在去往云南的项目黑帽高铁上，手机调成了飞行模式。项目黑帽

这就是项目黑帽“项目黑帽”的典型收场——一个人扛下所有技术债务，然后在交付前夜消失。项目黑帽圈子里管这种人叫“黑帽”，项目黑帽不是项目黑帽黑客那个黑帽，是项目黑帽背锅的黑。他们通常是项目里技术最强、话语权最弱的那个人。需求评审时没人听他们的风险提示，上线出事了第一个被拉进应急群。

我见过最离谱的一个案例，发生在去年杭州某电商中台项目。老赵是后端负责人，架构评审时他提了七次“订单表分库键选择有问题”，产品经理每次都说“先这样，后面再优化”。结果大促当天，单表写入量突破两千万，数据库直接挂死。老板在全员会上拍桌子问谁负责，老赵站起来说“我负责”。当晚他提了离职，HR批得比外卖还快。

黑帽的养成路径几乎一模一样。项目启动时，技术方案被压缩到三天出稿，老赵们熬夜画完架构图，评审会上被一句“太复杂了，先跑通再说”打回。中期开发，业务需求一天三变，他们一边骂娘一边重构，测试环境永远缺数据，预发环境永远连生产库。上线前一周，所有人都在催进度，没人关心监控告警有没有配全。最后事故复盘，文档里写着“技术方案考虑不周”，签字栏只有黑帽一个人的名字。

有个数据挺有意思。某招聘平台去年统计，互联网技术岗离职原因里，“项目背锅”排进了前五，超过“薪资倒挂”。我认识的一个测试主管，连续三个项目上线后都被扣绩效，理由分别是“漏测了极端场景”“自动化覆盖率不够”“没提前预警性能瓶颈”。第四个项止开始前，他主动申请转岗去做运维。他说：“写代码至少知道自己怎么死的，做测试连死法都选不了。”

黑帽现象背后是权责错配。项目经理对进度负责，产品经理对功能负责，只有技术对稳定性负责。但稳定性这东西，不出事没人看得见，出了事全是你的锅。更荒诞的是，很多公司把“能扛事”当成技术人员的核心素质。扛一次是担当，扛三次就是软柿子。张野离职前跟我吃过一顿饭，他说：“我不是不能背锅，我是受不了锅永远往我头上扣，连个轮流坐庄的规矩都没有。”

有些团队开始试“技术一票否决权”。需求评审时，架构师对技术风险有一票叫停权，不用解释，不用说服谁。听着挺霸道，但跑了一年下来，线上事故率降了六成。代价是项目平均延期两周。老板们算完账发现，延期赔的钱比事故赔的钱少多了。你看，不是没办法，是以前不想有办法。

张野后来在云南开了家民宿，朋友圈偶尔发些修水管、换灯泡的照片。上个月他给我寄了饼普洱茶，附了张纸条：“现在修东西没人催进度，坏了就慢慢修，挺好。”我没告诉他，他走后那个项目又换了两个后端，第二个跑路时连离职流程都没走完。项目还在，黑帽的位子永远有人坐。

本文地址：http://www.79wt.cn/news/303b1899678.html