1. 糟糕项目从来不是代码问题而是目标一开始就歪了这些年我被问得最多的一个问题是一个项目都烂成那样了怎么还有资深工程师在旁边看着不救说句实话在我刚工作前几年我也有同样的困惑。当时的我笃信一条铁律代码写得不漂亮就重构流程不顺就梳理流程需求不清就拉着产品经理一遍一遍过。只要人够拼任何项目都能救回来。后来经历得多了才慢慢明白一个道理大部分糟糕项目的毛病根本不在代码层而是项目想达到的目标从立项那天起就是歪的。1.1 糟糕项目的三个典型形态想判断一个项目该不该救先得搞清楚它属于哪一类烂。我见过最多的是下面这三种。第一种是伪需求项目。这类项目的核心特征非常明显产品的使用方是一个想象中的用户要么是领导拍脑袋觉得这个能力应该有要么是某次行业大会听完分享后拿回来的一句话需求。产品经理在里面找不到真实用户运营同学拉不出真实使用数据甚至连验收标准都说不清楚。我参与过一个内部数据报表平台前后做了大半年上线的第一个月一共只有三个访问者——其中两个还是我们自己的开发人员。这类项目的问题不在于技术选型对不对而在于它本身就不该存在。第二种是野心过大的平台化项目。公司看着自己手里的业务线多了就想做一个大一统平台把所有东西都收编进来。可现实往往是这个平台在需求层面根本没有收敛各个业务方提的需求互相打架权限模型改了四轮还是覆盖不全连最基本的用户是谁都定义出了好几套。你说技术上有救吗技术上什么都写得出来但业务逻辑本身就是一团互相矛盾的麻绳你把它理顺了它马上又绞在一起。这样的项目像是想要造一台能同时料理中餐、西餐、日料、火锅和一架洗碗机的厨房设备谁都知道它做出来一定难用但没人敢在立项会上说不。第三种是需求方内斗的项目。表面上看是技术债重、进度永远滞后实际上是背后几个业务方在争夺话语权。今天这个总监说流程必须这样走明天那个负责人说这个数据我们坚决不共享每一轮需求变更背后都是办公室政治。代码写得再干净也架不住每天变动的业务规则。这类项目有一个共同点你用尽全力上线一个新功能三天之后产品经理自己跑来跟你说内部口径又变了整个功能推倒重来。这种环境下的救是没有意义的因为项目根本不是在测试技术而是在测试谁能熬。1.2 临时变坏和本质变坏是两码事这里必须澄清一个容易混淆的概念项目暂时很丑和本质上坏掉了完全不同。代码写得乱、测试覆盖率低、线上偶尔出个bug这些属于丑。丑意味着它有修复的价值和可能性只要你有时间、有人、有足够坚定的决心它是可以被慢慢收拾干净的。我接过不少这种后妈项目接手的时候连启动文档都没有跑起来第一步就是装三年前的环境依赖。但这类项目有一个共同特性——它有一个真实的用户、一个真正在用的业务场景。只要底层逻辑是通的丑一点根本无妨反正烂账可以一笔一笔还。本质坏掉的项目则不同。它的目标本身无法成立或者成立的条件在可预见的未来都不可能满足。举几个信号第一项目的主要干系人之间对什么是成功没有共识第二项目依赖的外部前提政策、市场、关键合作方已经明确失效第三项目的使用者根本不愿意用底层逻辑是做了给老板看而非做了给人用。当你发现这些信号时再投入资源去打扫卫生是没有意义的——你只是想证明自己很努力而不是想解决问题。提示判断一个项目属于丑还是坏最有效的办法是问一句话如果明天这个项目原地消失会有人觉得不方便吗如果答案是不会那它大概率是个本质坏掉的项目。1.3 业务方眼里的成功和工程眼里的成功不是一回事有时候一个项目在业务方看来是成功的但在工程师看来却是彻底的失败。这句话听起来像抬杠但实际职场里每天都在上演。比如某项目当初立项是为了战略卡位目的就是把技术栈铺出去哪怕没有真实业务量也能在对外汇报时多个故事可讲。你辛辛苦苦把系统做出来业务方说很好很好KPI达成了明年继续立项。可工程师看到的是一个没有任何真实流量、却要持续投入维护资源、且随时可能被审计或是合规问题点名的系统。你说这项目算成功还是失败它是典型的组织层面的成功和工程层面的失败并存。资深工程师的嗅觉就体现在这里。他们不是看不懂业务方的KPI而是他们知道一个没有真实用户价值的系统最终是要还账的。今天它占用的人力和维护成本明天就要从一个有真实价值的项目身上扣除。所以遇到这类项目资深工程师往往不会热情高涨地冲进去加班加点因为他们的表情已经能读出四个字早点结束。2. 救火队长式的努力往往是最昂贵的成本你可能也发现了团队里总有一种人特别受欢迎谁的项目烂了他就冲进去救救完一个又一个到处被人感谢。大家觉得他是技术大神、救火队长、团队之光。但在资深工程师眼里这种模式恰恰是最需要警惕的。2.1 机会成本救一个烂项目等于杀死几个好项目先算一笔最直白的账。一个资深工程师一个月的成本放到外部市场谈大概是多少一个全栈工程师的人力成本加上管理沉淀、协作损耗保守来算一个月压在团队头上的综合成本可能是月薪的2到3倍。一个需要救的项目通常意味着需求推倒重来、核心模块重写、技术栈切换、历史数据迁移、各种接口兼容。你问任何一个做过大型重构的工程师都会告诉你这种项目少说三个月起步多则半年到一年。如果你把这三个月乘以团队人数比如一个6人小组你得到的是18到72个人月的投入。这笔钱放到一个健康增长的产品迭代上够你做出三个完整功能版本够你把用户体验提升一个台阶够你提前完成两个季度前就规划好的技术债偿还计划。说得扎心一点一个烂项目拖得越久从其他项目身上抽走的时间和士气就越多。很多管理者喜欢能救火的人是因为救火有即时反馈——看到进度推进、看到系统重新站起来那种我搞定了的快感确实很爽。但如果你拉长到一年周期再回看你会发现救火队长做的事情往往只是让一个本该淘汰的系统多活了一阵子而那些本可以顺势成长的新项目反而因此错过了窗口期。2.2 技术债可以还业务债和信任债还不清技术债是个好概念它给工程师提供了一个欠债可以还的想象空间——还了就清爽了。但现实中的烂项目欠的往往不光是技术债。我给你拆一下。技术债是什么是你当初图快选了一个不适合的组件是测试用例写得不够导致回归频繁是文档缺失导致新人上手两个星期才能改第一个bug。这些债的还法很明确重构、补测试、写文档。但一个烂项目的真实债务结构往往是三层的债务类型表现还债难度技术债代码混乱、组件老化、测试缺失中——只要有时间就能还业务债需求方没想清楚、功能根本不解决问题高——还债需要业务方自己转变想法信任债用户来过一次就被劝退了、名声坏了极高——基本等于重新教育市场技术债还起来投入产出比是相对明确的但业务债和信任债不是工程师加班就能解决的。你重构了一个没人用的功能重构得再漂亮它还是没人用。你把一个用户口碑已经崩掉的产品体验重新打磨一遍很可能发现用户早就走了连给你道歉的机会都没有。这里的关键判断是如果这个项目欠的主要是技术债救是值得的如果欠的主要是业务债和信任债那救的动作本质上是在给错误目标续命。资深工程师恰恰能分清这两者。他们不是看不到代码可以改好而是看到了就算代码改好了业务方向还是错的用户还是不来。2.3 救活了又能怎样活下去和有价值是两回事还有一个很多人忽略的点救活一个烂项目和让一个项目活得有价值中间隔着一整个太平洋。我见过太多救活的案例系统终于稳定了bug终于修完了终于可以半年不用通宵了。然后呢业务方发现这个产品本身留不住用户每个月的新增访客一只手数得过来。系统稳定运行稳定地没人用。你问业务方怎么办他们说再看看、再推推你问产品经理怎么说他们说明年换个方向你问管理层怎么想他们说放着吧反正也不亏太多钱。这个状态比直接失败更难受。一个直接失败的项目好歹有个结案报告团队可以撤走资源可以释放。而一个被救活的僵尸项目会像一个慢性病人一样一直在医院躺着每个月吃掉固定的床位费和护士的注意力。你要说它死了它系统还能跑你要说它活着它创造不了任何价值。这解释了为什么资深工程师往往对冲刺救火兴趣寥寥。他们不是没有能力救而是清楚知道救得太顺手反而容易让这个错误目标在组织里多存活好几年。放任它快速失败本质上是为了避免一个漫长的、消耗式的死亡。3. 刻意失败和弃坑跑路差在哪儿有人到这里可能会问那是不是所有烂项目都该放手你们这些资深工程师是不是就是想偷懒怕担责任不是。这里必须划清一条界线有意的、可控的失败和撒手不干是完全两种行为。前者是为了组织和团队的健康而做的一种策略选择后者是纯粹的失职。很多初级工程师误解了这一步以为老员工嘴里说让项目死吧就是从此不管不问其实完全错了。3.1 不救不等于不管所谓刻意失败指的是在明确评估项目前景之后有意识地把投入的资源降到最低保留关键的信息和证据让项目按照自身的规律走向终点。在这个过程中工程师依然要做好自己的本职工作代码该维护的维护、数据该保护的保护、事故该响应的响应。区别在于你不再把额外的人力、精力和资源往这个坑里填。这个过程里有很多细活儿要做。比如你决定不再投入新功能开发但必须保证已有功能在生命周期内安全运行不能突然停服导致线上事故你决定不再参加需求评审会但仍要把当前的架构现状、已知风险和后续交接建议写清楚挂在wiki里供业务方参考你甚至可以主动跟管理层说明我们评估这个项目不再具备继续投入的价值建议冻结新需求只保留维护模式给业务方一段时间验证是否还有真实需求。注意这些都叫管。你把边界划得清清楚楚让每个人都知道这个项目处在不再扩张、仅做维护、等待结论的状态而不是让项目在没有任何预警的情况下突然倒掉。这两者的区别团队成员心里跟明镜似的。3.2 刻意失败的三个操作要领第一把预期对齐到组织层面。当你判断一个项目不值得救你不会小声跟团队说然后自己溜走而是会在合适的机会用合适的措辞把结论同步给业务方和项目干系人。标准句式是按照当前的数据和反馈这个项目暂时不满足继续追加投入的条件建议我们先冻结新需求用一个迭代周期来做验证。如果验证结果不符合预期就需要考虑项目收尾。这不是推卸责任这是把判断透明化。第二留好证据和文档。这一点极其重要。所有关于风险预警、业务数据不达预期、需求变更导致目标漂移的记录都要有据可查。不是说你要准备甩锅而是因为一个项目失败的归因只有在数据清晰、过程可追溯时才算真正完整。如果每个人都心里知道项目不行但没有任何人留下记录那复盘的时候就只能靠记忆力和讲故事能力这注定会变成一场互相攻击的灾难。第三设定明确的观察点和止损线。你不需要一次性宣布项目死刑。更好的做法是先定一个验证周期——比如六周——明确在这个周期内需要看到哪些指标真实用户数、留存率、业务方确认的验收标准如果到期不达标则启动收尾流程。这种做法的好处是连最抵触的业务方也无法反驳因为在决策之前你已经给了公平的机会。3.3 什么时候必须救什么时候应该放再补充一个判断框架这个框架是我在实践中慢慢总结出来的比单纯的看心情靠谱得多。需要硬救的情形包括项目已经承载了真实用户的线上交易和数据。哪怕代码烂成一坨你也必须先保证它能继续安全运行不能因为架构不爽就直接停。这类项目的核心是稳定优先你可以后续再安排重构。项目虽然方向有问题但它是公司当前唯一的收入来源。这时候你当然可以提建议重新规划方向但短期内必须把眼前的业务保下来这是职业责任。团队里有很多新人正在通过这个项目成长且项目并非没有希望。这种情景下救更多的是一种人才培养手段你要救的是团队的信心和经验积累。适合刻意放置的则是另一种情形项目没有真实用户连验证商业模式的机会都看不到核心干系人之间目标冲突且没有任何一方愿意让步项目的历史已经明确证明了方向不可行继续投入只是为了面子工程项目的失败不会带来合规风险、数据安全事故或不可逆的用户伤害。注意刻意失败也分安全等级。你可以让一个内部工具自然死亡但不能让一个涉及用户隐私数据的系统在没有任何保护的情况下崩塌。放的前提是安全地放。4. 失败之后组织到底能留下点什么好假设你做出了判断项目也按计划慢慢收尾了。这时候真正考验功底的部分才开始——失败之后的复盘和重建。一个项目失败了如果组织什么都不留下那它真的就是白白交了学费如果留下了可复用的判断方法和经验教训那这笔学费就没白花。4.1 复盘的正确打开方式说到复盘很多团队的流程是这样的拉一群人开会放PPT回顾时间线问当时是谁做的这个决定然后陷入漫长的沉默最后出一个大家以后要多沟通的结论就散了。这种复盘除了浪费时间还有一个副作用它会让下次遇到类似情况的人更不敢做判断因为做得越多错得越多。真正有效的复盘前提是大家都承认失败不是某个人的耻辱而是项目级的信息资产。你要回答的只有三个问题我们原本想解决什么问题我们实际上做了哪些事这些事和问题之间的因果关系是什么整个过程不追究谁说得不对而是把精力放在为什么会做出这个判断、各个判断在当时的信息条件下是否合理上。比如你可以复盘立项时的市场调研是否充分需求方在项目中的决策流程是否顺畅技术方案是否在早期就发现了关键风险。如果你这样复盘收获的将是可复用的组织经验如果你把复盘变成追责会收获的只会是人心惶惶。4.2 团队心理失败不该是一场公开羞辱一个项目失败之后团队的情绪状态往往比任何时间线复盘都重要。尤其是那些跟着这个项目加班了大半年的工程师他们的投入是真的他们对产品的期待也是真的你要他们立刻轻描淡写地说没关系我们换个项目太反人性了。资深工程师在这里承担着一个不明显但很重要的角色给团队一个可接受、可理解的叙事。不是替失败辩护而是帮团队把我们失败转换成我们曾经做了一个判断这个判断在当时有合理依据但后来的事实表明目标需要调整。这个过程是必要的心理拆弹它能防止优秀工程师因为一次失败的项目而自我怀疑防止他们从此变得畏首畏尾。比较有意思的是团队对失败的反应往往是资深工程师行为的镜像。如果你冷静、理性、公开地讨论问题团队就会把失败当作一次普通的工作事件来处理如果你慌乱、互相甩锅、偷偷摸摸团队就会把失败当成一件丢人的事下次有风险就藏着不说直到变成更大的事故。4.3 组织能从一次失败里捡到什么一个项目失败之后组织实际上收获了三样东西。第一样是决策依据。以后谁再提类似方向的立项你可以直接拉出上次的复盘记录说这个方向我们验证过当时的结论是这样的如果我们没有新的变量出现不建议再重复投入。有了清晰的历史记录类似的项目就可以在提案阶段被更早地拦下来。第二样是代价估算法。失败项目给出的预算数字、周期估算、人力配置虽然不准确但它给组织提供了一个这类项目需要多少成本的参照系。下次做类似项目时预算审批就能更贴近实际而不是拍脑袋定一个过于乐观的数字。第三样也是最重要的是信任关系的重构。当一个团队被允许在观察期内犯错被允许对管理层说这个目标有问题而不被惩罚组织才真正形成一种基于事实的协作文化。这种文化带来的收益远远超过任何一个具体项目本身。5. 我的救与放清单从实践中来最后说点个人化的东西。这些年我自己经历过救成功的项目也经历过判断失误的项目还有过几次我早该放它走的后悔。总结下来我给自己整理了一份清单每次遇到类似处境我都会拿出来过一遍。5.1 三个真实感很强的判断经验第一个经验是看有没有真实用户。不管项目代码有多烂只要有一个真实的、每天在用的用户哪怕只有5个人我都会倾向去救。因为真实用户意味着需求是成立的剩下的只是技术层面怎么把体验做好而如果一个项目做了半年还处于发布后每天访问量是个位数的状态我绝不会再往里面加人。一个连真实用户都没有的系统你优化性能给谁看呢第二个经验是看业务方愿不愿意付出代价。经常有这样的情况业务方对项目有一堆愿望但当你问如果要实现这个功能你们愿意把优先级调到最低吗愿意配合每周做一次数据验证吗愿意把决策人机制固定下来吗的时候对方开始支支吾吾。这就说明业务方对这个项目的支持停留在口头上。如果业务方连基本的配合都不愿意给工程师越是拼命越是替别人的不作为买单。第三个经验是看失败的成本有多大。项目失败如果只是损失研发时间那风险是可控的但如果失败会导致用户数据被不当处理、会破坏核心业务的稳定性、会引发法律或合规上的连锁问题那无论项目看起来多没希望都必须先把安全底线守住。我甚至见过一个项目技术上已经全线崩溃但因为涉及几个大客户的SLA工程师团队还是硬着头皮稳住了半年等合同到期才停掉。这是放的必要代价也是职业操守。5.2 给工程师的放弃清单如果你正在纠结一个项目到底该救还是该放不妨把下面这个清单打印出来对着回答一遍这个项目有三到五个真实用户在持续使用吗业务方能明确说出这个项目的成功标准吗项目所有干系人对成功标准的理解一致吗过去两个季度里这个项目的核心数据是在增长、持平、还是下跌如果继续投入需要调用多少资源这些资源有其他创造更大价值的去处吗这个项目的失败会伤害到任何真实用户或者引发不可控风险吗你有没有把风险判断和预期对齐记录在案如果你在回答前四个问题时有三个以上是没有不一致下跌我建议你认真考虑放置观察而不是无条件抢救。而如果你在前几个问题的答案上犹豫不决那就先把第七个问题解决掉——把风险和判断写下来发出去让大家在同一个信息平面上讨论。这一步无论最后是救还是放你都赢了。写到这里我特别想分享一个个人的体会在工程管理的世界里让项目失败不是一个贬义词它是判断力的一部分。我们习惯于歌颂挽救者却很少谈论停止者。但真正让一个团队从普通走向成熟的恰恰是那些敢于说我们方向错了停下来的人。能救的项目你要对得起它注定失败的项目你要对它保持诚实。这两件事都需要勇气也都需要经验。我希望每一个还在纠结要不要放手的工程师都能在看完这篇文章后获得一点点底气。