第1章 死定了〔2003年7月〕
第一章将视角聚焦2003年7月的Chandler项目现场，此时项目进度严重滞后，原定交付日期遥遥无期，整个团队陷入巨大焦虑，所有人心里都清楚项目“死定了”。面对延期，管理层第一反应是扩招程序员，试图依靠增加人力追赶进度，可这个决策恰恰印证了软件工程经典理论——布鲁克斯法则：向已经延期的软件项目增加人力，只会让项目延期更久。
软件开发和工厂流水线完全不同，流水线增加工人能线性提升产能，软件开发新增人员却会带来成倍上涨的沟通成本。新人入职后，需要花费大量时间熟悉项目背景、代码架构、业务需求，老员工还要分出精力讲解文档、解答疑问、做代码交接，原本负责开发的核心人员被大量琐事拖累，实际产出不升反降。除此之外，本章完整揭露了大型项目崩盘的多重底层诱因：项目前期需求边界模糊，产品没有明确取舍，不断叠加新功能；底层架构尚未稳定，频繁进行大幅调整；长期积累大量未修复Bug，技术债务堆积；缺少可视化进度管理，管理者无法实时掌握真实开发情况。多重问题交织叠加，让项目彻底陷入恶性循环。
结合课堂所学与实训经历，我对布鲁克斯法则有了更深刻的理解。之前小组开发实训系统时，我们也曾因为进度落后临时增加两名组员，结果沟通冲突频发，代码规范不统一，整体进度反而放缓一周。这让我意识到，人力不是解决项目延期的万能解药。
本章带给我的核心思考：当项目出现进度预警，第一时间不该扩招人员，而是梳理核心需求、删减非必要功能、稳定底层架构、逐步清理技术债务。同时项目初期就要搭建风险预警机制，定期复盘进度，不要等到问题全面爆发才寻求补救。模糊的需求、不稳定的架构、无序的人员扩张，三重问题叠加足以摧毁任何一款软件，只有遵循软件工程客观规律，才能避免陷入“越赶工越延期”的死循环。