企业官网建设流程全解析

项目烂尾两年，代码没人敢动、需求没人说得清，直接报废又交代不了。先判断值不值得救，再做资产盘点和需求收敛，最后用小交付节奏把信心拉回来，这套步骤适合多数烂尾场景。

一、先判断：不是每个烂尾项目都值得救

盘活的第一个动作不是写代码，是判断。烂尾的原因不一样，处置思路完全不同，有的项目救回来是资产，有的项目救回来是负债。

1. 三类常见的烂尾原因

• 需求失控型：立项时范围就模糊，做的过程中业务部门不断加需求，厂商照单全收，做到后期范围已经是立项时的两三倍，预算和工期双双爆掉。这类项目的问题在需求治理，不在代码。
• 验证缺失型：POC阶段没验证关键假设（数据能不能拿到、接口能不能通、性能扛不扛得住），直接立项开工，做到一半发现核心链路走不通。这类项目死在选型阶段，烂尾只是结果延迟到达。
• 组织变动型：牵头的领导调岗、业务部门重组、厂商合同到期没续，项目没人推、没人验收、没人付款，自然停摆。这类项目的技术资产往往是好的，最值得救。

2. 值得救的判断标准

两条硬标准：一看数据资产，存量数据是否完整、业务是否还在往系统里录；二看业务痛感，访谈时业务部门是还在抱怨这事，还是已经绕开系统另起炉灶了。两条都满足的，盘活大概率有产出；两条都不满足的，建议走下线归档流程，别为了沉没成本再投新成本。判断这一步做完，救不救的结论就有了，后面三个步骤才有意义。

二、第一步：资产盘点，摸清家底

判断要救，先盘家底。烂尾项目最大的坑是"你以为有什么"和"实际有什么"之间的差距，盘点就是把这两个对齐。盘点结果同时是后面预算测算的依据：哪些资产能复用、哪些要修复、哪些必须重买，每一项都直接对应重启方案里的一笔钱，盘点做粗了，预算必然漏项。

1. 代码和文档盘点

拿到所有能拿的东西：代码仓库的地址和权限（很多时候密码在某个人脑子里，人已经转岗）、需求文档的最终版本（警惕只有PDF没有源文件的情况）、设计文档、测试用例、厂商交接报告。逐项登记造册，给每项资产标状态：可用、需修复、只能参考。一个实际经验：厂商交接报告里写的完成度，和代码里真正能跑起来的部分，往往是两个数字。以能跑为准，不以文档为准。

2. 数据和环境盘点

数据库里的表结构、存量数据量、每张表的最近写入时间（哪些表三年没有新数据，说明对应业务早就停用了）、第三方接口的连通状态、测试环境还能不能启动。环境盘点里最容易漏的是账号和证书：云资源在谁名下、域名和证书什么时候过期、消息队列有没有堆积。这些盘清楚，重启的底数才算摸到。

3. 关系盘点

最容易被忽略的一项：这个项目牵扯哪些人。原厂商的对接人还联系得上吗，业务部门的对接人换了几任，集团层面谁还愿意为这个项目说话。技术资产盘得再清楚，没人认领的项目也救不活。关系盘点决定后面需求收敛找谁谈、交付验收谁签字。

三、第二步：需求收敛，砍到能交付为止

烂尾项目的需求清单通常很长，因为停摆前积累了大量做了一半和提了没做的需求。收敛的思路不是把旧清单接着做完，是回到业务现场重新问一遍：哪个环节的痛最真实。

1. 需求重排：先解决一件事

把旧需求清单全部作废，拉着现任业务对接人重新走一遍流程，从日常动作里找最痛的一个点。判断标准很朴素：如果不做这个功能，业务方每个月要多花多少人力、多担多少风险。按这个标准排序，只取第一名。盘活项目最忌讳一上来就想把原来的蓝图全实现，那是二次烂尾的标准配方。

2. 定边界：写清楚不做什么

收敛需求时，不做什么比做什么更重要，白纸黑字写进重启方案：本期只做这条业务链路，涉及多部门协同的、涉及主数据治理的，明确写下一期评估。边界文档让业务方、信息化部门、分管领导三方签字，这份文件是后期需求反弹时的挡箭牌。没有边界文档的盘活项目，三个月后需求又会滚回失控状态。

四、第三步：小交付重建节奏

需求收敛完，进入交付。烂尾项目重启后最怕两件事：一是周期拉太长，做到一半士气没了又停；二是验收标准模糊，做完之后业务方说这不是我要的。解法是同一个小步快跑：短周期、可验证。

1. 第一个交付选最小业务链路

选一条两端清晰、参与角色少的业务链路先跑通，比如一条完整的申请、审批、归档流程。周期控制在一个季度以内，最好六到八周。技术上能复用旧资产的就复用（数据库表、接口封装），复用成本高于重写的就果断重写。我们盘活过一个流程类项目，原有自研的流程引擎只跑了三个月就停了，接手评估后，表单和流程部分直接用搭贝重建，按用户数报价，重启方案的测算好做；数据层和集成层的资产保留复用。第一个完整交付七周上线，业务方头一回在这个系统里走完一条完整的单子，信任就是这么一点点攒回来的。

2. 节奏比功能重要

第一个交付上线后，固定迭代节奏：每两到四周一个可见增量，每个增量有明确的验收标准。验收标准建议具体到操作层面：这条链路的单子从提交到归档全程线上走完，任何一步不落回线下纸面，就算过。节奏本身就是交付物——业务方开始相信提了需求真的会做，配合度完全不一样。盘活项目里，重建信任的优先级高于堆功能，宁可每个迭代少做点，也别断更。断一次，前面攒的信任就清零。

五、盘活过程中的几个坑

• 原班人马情结：迷信原来的厂商最熟悉情况，把重启项目又包回去。熟不等于行，先看它当初为什么烂尾，需求失控是不是它自己惯出来的。
• 复盘变追责：重启前的复盘会开成追责会，所有人开始自保，拿到的信息全歪了。复盘的规矩：只对事，对事也只写到流程哪一步缺了控制，不点名。信息不准，盘活的判断就是歪的。
• 预算按续建报：盘活项目按续建口径报预算，金额小、周期短、审批快，但埋着雷：续建的口径里没有需求收敛和资产修复的工作量，做着做着发现钱不够，二次停摆。建议按新立项口径报，把盘点、收敛、重建的工作量算足。

这三个坑的共同点：都指向人，不指向技术。烂尾项目的盘活，七分是组织和需求的事，三分才是代码的事。

常见问题

Q：怎么避免下一个项目又烂尾？

把这次盘活练出的方法前移到立项阶段：立项前把关键假设验证掉（数据、接口、性能），需求边界文档在立项时就要签，第一个交付周期的时长写进合同。烂尾的种子基本都是立项时种下的，盘活练出来的这套功夫，最值钱的用法是让下一个项目不需要盘活。
Q：需求收敛时业务方不配合怎么办？

先解决动机问题：业务方不配合，通常是上一个烂尾项目耗光了他们的信任。别急着开会收集需求，先用第一个小交付做出一个能用的东西，让业务方看到这次不一样。信任重建在前，需求收敛在后，顺序反了就是自嗨。

Q：盘活项目怎么向领导汇报进展？

用业务语言不用技术语言：这条流程上线后，多少单子在线上走、平均多少天走完、线下纸质单少了多少。领导不关心你修复了多少历史代码，关心的是这个项目这次真的动起来了。每次汇报带一个可演示的东西，比十页PPT有用。

Q：烂尾项目的旧代码，重写还是复用？

看两个指标：代码的可运行状态和团队的可维护性。能跑、有文档、团队看得懂技术栈的，评估复用；跑不起来、技术栈没人会、文档缺失的，重写比修复便宜。一个参考判断：如果评估复用需要的人天超过重写的六成，直接重写，别为舍不得三个字付长期维护成本。