瀑布模型

去年，我带着团队去给一家传统制造企业做项目启动汇报。对方的采购总监坐在对面，听完我讲了十五分钟的“瀑布模型阶段交付流程”后，放下茶杯说了一句话：“你们互联网公司那些新名词我不懂，我就问一句，你能不能先给我做出一个能用的东西看看？别等半年给我一堆代码，到时候改都来不及。” 那一刻我意识到，问题从来不出…

去年秋天，我给一家做医疗SaaS的团队做敏捷转型咨询。他们的CTO在会议室白板上画了一条线，左边写着“产品说的”，右边写着“开发做的”，中间画了个巨大的箭头穿透了三层省略号。他说：“同一个需求，经过客户成功经理、产品经理、技术Leader三个人的嘴，到开发手上已经面目全非。三个月返工两次，我们快被‘…

一、核心结论：瀑布不是开发方法，是风险控制框架 我跟很多技术负责人聊过高风险创新项目的管理问题，发现一个反复出现的认知偏差：大多数人把瀑布模型当成一种“落后的开发方法”来批判，而不是把它当成一种“成熟的风险控制框架”来使用。 这句话我在至少十几个项目的复盘会上讲过：当你管理的项目满足以下三个条件中的…

一、先说结论：多供应商协同，敏捷不是解药，是毒药 如果你正负责一个需要五家供应商协同交付的大型项目，比如银行核心系统升级、智慧园区集成平台、制造业MOM系统实施，我只有一个建议：立即放弃对敏捷开发的一切幻想，用瀑布模型把每一个阶段、每一个接口、每一份交付物锁死。 这不是我拍脑袋提出的观点。过去七年，…

不是敏捷不行,是你把场景搞错了 去年冬天,我接手了一个医疗器械软件项目的咨询诊断。技术团队用Scrum跑了三个迭代,每次Sprint Review都被产品负责人叫停，不是因为代码质量差,而是因为每个迭代产出的功能增量,放到医疗器械注册的框架里,都不构成一个“可提交审评的交付物”。当开发团队开始第八次…

一、先谈核心结论：需求变更的成本不是一条曲线，而是一场复合型灾难 在软件工程领域，有一个被反复引用以致于几乎失去警示意义的数据：需求变更发生得越晚，修复成本越高，后期变更成本可达初期的 100 倍。 这个结论最初来自 Barry Boehm 1981 年出版的《软件工程经济学》。它像一句咒语，被项目…

一、开篇：那个夏天，我们和一份设计文档死磕了两个月 2019年夏天，我接手了一个金融后台系统的产品设计。项目立项前，CTO在启动会上说了一句话：“这次我们严格走瀑布，需求必须一次搞清楚，不要边做边改。”当时我觉得这话没毛病，毕竟涉及资金清算，逻辑复杂，确实不适合“先跑起来再迭代”。可我万万没想到，接…

一、先给结论：瀑布开发不是“有没有用”，而是“你敢不敢用错” 如果你正在纠结团队到底该用瀑布还是敏捷，我的第一个建议是：先别翻那本 Scrum Guide，也别急着听敏捷教练画饼，先把你的项目性质看清楚。 我在过去十年里，见过不止一个团队在“敏捷转型”的口号下，把需求极度稳定、变更代价巨大的项目硬塞…

我见过太多“标准瀑布”项目死在最后一个月。需求文档签了三百页，设计稿画到像素级完美，开发按部就班写了十个月代码。测试阶段一跑，核心业务逻辑对不上；UAT 一演示，甲方当场拍桌子说“这不是我签的需求”。所有人都很委屈，产品翻着一年前发的需求邮件，开发指着代码库说按设计文档写的，设计拿出盖过章的交互稿。…