软件项目烂尾有很强的共性。它不是技术难度造成的，多数时候是管理与协作方式造成的。下面六种情况，占了实际项目中绝大多数。
六种典型死法与早期信号
| 死法 | 早期信号 | 怎么处置 |
|---|---|---|
| 需求无边界扩张 | 每周都有"顺手加一下"，但没人签变更单 | 建立变更单机制，把新增排进下一期 |
| 只有一个人懂 | 关键问题只能等某个人回来处理 | 要求关键模块必须有文档与第二负责人 |
| 数据库设计不合理 | 加一个字段要改三个页面，报表算不出来 | 在设计评审阶段就把字段表与表结构过一遍 |
| 关键路径没有验证 | 演示一直用准备好的数据，没跑过真实流程 | 每两周用真实数据完整走一次主流程 |
| 甲方决策链太长 | 一个确认要等一周，开发只能先做着看 | 指定唯一需求确认人，约定答复时限 |
| 上线才想起运维 | 临近上线才发现没买服务器、没做备份 | 启动时就确定部署方案与运维责任人 |
三个能救命的机制
每两周一次真实演示
不用 PPT，直接在生产级数据上走流程。看到的问题最真
一份持续维护的风险清单
把"卡住的事"列出来，每条写明影响、责任人、解决时间
一个不变的验收基准
需求文档 + 变更单的合集。任何时候只认这一份
什么时候该考虑叫停
如果项目同时出现"进度落后 50% 以上""关键人员离职""需求还在增加"三种情况，大概率不是延期问题，而是方案问题。这时候继续投入的边际收益很低，停下来重做一次范围评估，比硬推到上线更省钱。
一句话：烂尾是结果，不是原因。盯住上面六个信号，比事后追责有用。
常见问题
项目已经延期了，还能救吗？
能。办法是把剩余功能砍到最小可用集合，先上一个能跑通的版本，之后再迭代。怕的不是延期，是"全部做完再上线"这个执念。
怎么判断是开发方能力问题还是需求问题？
看演示。如果每次演示都在"准备数据"，是能力问题；如果每次演示都能跑起来但总说"这个你没说过"，是需求问题。