项目管理

去年 11 月，我在一家 380 人的智能制造企业做项目复盘，研发总监把 ERP 集成项目的三版排期表摊在桌上：第一次承诺 6 月上线，第二次改到 9 月，第三次改到次年 1 月，…

去年我参与复盘一个预算 480 万、原计划 7 个月交付的企业级系统项目，最终用了 13 个月，实际支出接近 780 万。技术栈不复杂，团队也不算弱，真正把项目拖垮的是另一件事：立…

2023 年我参与过一家工业软件公司的项目复盘。他们交付了一个周期 14 个月的大单，最终实际投入超支 47%，合同金额一分没涨。我把 200 多份周报、邮件和会议纪要翻了一遍，试…

我见过太多项目不是死在执行上，而是死在开始前那一次”看起来没问题”的范围确认。去年我参与诊断过一家做工业设备数字化的公司，立项时范围说明书只有 4 页，交付…

2024 年我参与了一家工业软件公司的交付复盘。这家公司的范围管理看起来很”正规”：需求文档平均 60 页，变更要过三级审批，每周三下午固定开范围评审会。但…

我见过一家 180 人的制造企业，项目立项会上管理层签字确认的 WBS 只有 42 行，到第 7 个月，实际执行的任务条目超过 600 条，交付晚了 3 个月，最终超预算 38%。…

我接手过一个 140 人的研发组织，11 周里需求条目从 87 条涨到 142 条，涨幅 63%。没有人觉得哪里不对，每一次追加都有理由，每一个理由单看都成立。真正让项目崩掉的不是…

我见过最贵的范围定义失败，不是漏写了一份需求文档，而是让一个报价 60 万元的定制功能，在项目上线前 3 周才被判定为”不算在范围内”。项目经理翻出 4 个…

我见过一个 300 人规模的研发组织，项目范围失控的导火索不是需求变更太多，而是一次评审会上没人能回答一个简单问题：这个新增功能到底属于哪个工作包。会议室里坐了产品、研发、测试、交…

核心结论：范围制度的目标不是”卡需求”，而是让每一次边界变动都有可见的代价 我做过一个不算严谨但足够说明问题的复盘统计：2021年到2024年间，我以外部顾…