1. 先聊聊放任这个词背后的真实含义1.1 目睹项目烂掉是一种常见的职场困境几年前我被拉进一个救火项目代码库已经乱到每加一个功能要修三个bug需求文档有四个版本互相矛盾测试环境三天两头崩。按说这种局面团队里最该着急的应该是那几个工作了七八年的资深工程师可他们反而最安静。开会时简单汇报两句分配到自己头上的任务照做项目往悬崖边滑的整个过程他们几乎没有过激烈的反对。我当时觉得不可思议后来在这个行业里待久了才明白这类情况太常见了。你以为资深工程师的职责是拦住糟糕的事情发生但现实中很多人选择了放任。这里的放任不是撂挑子不是消极怠工而是一种刻意为之的姿态我看见了问题我评估过风险我也提出了观点但我不再为此投入额外的情绪和行动。外人看到的是无动于衷当事人想的是我已经做了我能做的。这篇文章想聊的就是这种反差背后的逻辑。为什么一个技术能力强、经验丰富、最应该捍卫工程质量的人会在关键时刻选择袖手旁观这对团队、对项目、对个人分别意味着什么以及如果你正处在一个糟糕项目里你又能做点什么。1.2 糟糕和失败的标准并不统一在深入之前得先把两个词说清楚。糟糕和失败不是一回事不同角色对它俩的判断标准甚至完全相反。一个项目技术糟糕代码满天飞的if else上线全靠玄学但这东西月流水几千万产品占有率杠杠的。从商业角度它没失败从工程质量角度它糟糕透顶。反过来的例子也有架构设计得赏心悦目测试覆盖率百分之九十代码评审一丝不苟结果做了一年发现方向就走错了用户根本不需要这项目从商业上是彻底的失败。这里就会产生一个很微妙的局面资深工程师嘴上说的糟糕项目往往指的是技术层面的问题——设计不合理、债务过高、交付不可持续。而管理层眼里的糟糕项目指的是商业目标没达成。你在这两个坐标系里喊应该停对方听到的完全不是同一个意思。我见过太多资深工程师在第一种坐标系里拼尽全力试图把技术债还清、把工程质量拉回正轨结果管理层在第二种坐标系里根本感受不到压力两边驴唇不对马嘴地开会没人觉得自己做错了。这种我明明说了对方却觉得我没事找事的经历积累得足够多资深工程师自然就学会了闭嘴。2. 资深工程师选择不救场的六个真实理由2.1 救过的次数太多知道救不了先说实话不是所有放任都源于心机有些纯粹是累出来的。资深工程师大概率经历过不止一次英雄时刻人均凌晨两点的酒店走廊、逐步失控的问题清单、永远不够用的排期你像消防员一样冲进去灭火最后项目活了你垮了。火灭了之后没人记得你烧掉了多少健康和时间下次出问题第一个被想起来的人还是你。问题在于救火这事的边际收益会递减。你救了第一次大家说你好厉害救了第三次大家觉得这是你应该做的救到第五次你已经成了这个人怎么总是出问题的一部分。而真正让资深工程师对救火彻底祛魅的是当你冲到最前面、把方案做出来、把风险汇报上去之后决定权根本不在你手里。你提出的方案可能是砍掉一半需求、延期一个季度、换掉核心模块每一件都需要高层拍板。高层不拍板你的方案就只是PPT里的一页。一次是这样两次是这样到了第三次你自然就明白自己的边界在哪里了。不是不想救是知道光靠技术救不了。2.2 说话的分量取决于早期而不取决于技术资深工程师的话在项目里究竟有没有分量答案很残酷越到项目后期越没有。决策链上工程师对方向的建议权集中在需求定义阶段和架构设计阶段。一旦这两道关过了合同签了团队开了里程碑定了后面的一切都是在执行既定的路线。这就造成了早期反对有效晚期反对无效的格局。前期你提意见大家有充裕的余地去调整后期你提意见听起来就是给全项目组添堵你的技术能力再强也改变不了明天要交付演示版这个铁一样的事实。我认识一位做过十多年架构的同事他的习惯是在项目立项会上花最多精力去争论把需求问题、技术假设、验收标准在早期翻来覆去地抠。哪怕会上吵得面红耳赤他也在所不惜因为他知道项目一旦启动他再想有这种发言权就难了。反过来那些在早期沉默、等出了问题再跳出来喊停工的人哪怕技术判断再正确也很难被人严肃对待。资深工程师深谙此道所以当项目已经烂到中后期、自己说什么都不会改变走向时他们会收起嗓门选择保存体力。2.3 组织目标和个人目标并不总是一致工程师也是打工人也要考虑自己的职业生涯。一个糟糕的项目可能对你的组织是一场灾难但对你个人来说它未必是坏事甚至可能是一个机会。有个很扎心的现实项目越烂越需要熟练工来稳住局面这类人的不可替代性反而越高。一个项目平稳运转、毫无波澜的时候公司很容易觉得换谁上都行一旦项目出现混乱能在混乱中收拾摊子的人就成了稀缺资源。资深工程师对这种事心知肚明所以他们未必有动力去终结混乱——终结混乱意味着自己不再被需要。这里还没有算上晋升周期。很多公司的晋升窗口是半年或一年一次一个即将迎来评审的资深工程师他的最优策略是在评审之前不惹事、不站队、不触碰敏感决策。他也许内心清楚项目在走向失败但那个失败发生的时间点大概率在他晋升之后那他凭什么牺牲自己、去和一个必败的项目同归于尽听起来有点残酷但这才是真实的职场心态。别把人想得太高尚也别把人想得太卑劣大家都只是在复杂环境里做对自己最有利的决策。2.4 反对的声音需要一个背锅侠还有一个大家都心照不宣的原因在项目失败这件事上谁警告过谁就有责任。这话听起来反直觉可放到具体场景里就明白了。假设你当着全员的面说这个架构撑不过用户量翻三倍领导当时没采纳。半年后用户量真翻了系统崩了公司损失几百万领导复盘时不会说当时我没听劝他会说你们技术团队为什么不坚持你们的判断更常见的做法是他说你们当时的方案本身就有问题不然怎么会说出撑不住这种话解决方案呢光提出问题谁不会这种事只要经历过一次你就会知道提出正确意见是会招致记恨的。尤其是在层级森严、问责文化很重的组织里你提前预言了失败你反而成了那个让所有人都难堪的人。久而久之资深工程师学会了不预言至少不在公开场合预言不做第一个举旗的人非要等有人牵头自己再跟。2.5 代码的坏味道是团队关系的镜像有一句我很认同的话任何糟糕的代码本质都是糟糕的人际关系。一个项目如果架构混乱、模块耦合、文档缺失背后必然对应着团队配合差、职责边界模糊、信息反复断层。这种问题资深工程师一眼就能看出来。但他也知道代码层面他能改团队关系改不了。你没法通过一次代码评审解决两个组长之间的矛盾没法用一次重构解决产品经理和技术人员的信任危机更没法靠架构文档让一个部门跟另一个部门停止互相甩锅。所以当资深工程师判断问题的根源不是技术而是人和组织时他会很自然地退到我只做好我自己那部分的位置上。他的经验告诉他在这种项目里投入更多只是在替别人的管理失误买单。让项目失败有时候不是因为项目不行而是为了让某些协作问题暴露出来逼管理层去面对。2.6 失败本身就是一种前进最后一条往深处说是方法论层面的。不是所有项目都配得上成功。一个市场时机没到的产品、一个需求已被证伪的方向、一个商业模式有根本缺陷的方案你把它救活了反而是害了整个公司——资源被错误地固化团队被别人无法拒绝的任务锁死那些本来可以投到正确方向的钱和人就这样被一个注定要失败的东西耗完了。有经验的工程师经历过几次项目黄了是好事之后会建立一种新的时间观项目失败不等于公司失败更不等于团队失败。它只是验证了一个此路不通的假设省下了后续更大的资源浪费。抱着这种观点一些资深工程师在项目已经明显走向错误的时候反而不急着翻身他们会顺应这个趋势让失败早点发生好让大家早点解放。这不是躺平这是一种更大的战略判断。当然这种做法是否合适、该不该由工程师个人来替组织做这个判断这就值得商榷了。这也是后面要展开讲的部分。3. 糟糕项目是如何被一步步喂大的3.1 早期误判需求有问题时没人敢质疑糟糕项目从来不是一夜之间变糟的它的崩溃在立项那一刻就埋下了种子。正常项目启动时需求方会画一张大饼销售说市场急需产品说竞品都有老板说我们要抓住窗口期。这时候会议室里所有人都处于一种集体亢奋中唯一的煞风景者角色通常落在工程师头上。你要问一句用户真的需要这个功能吗、这个需求验证过吗气氛会瞬间尴尬。体制里不鼓励质疑。不管是团队文化、考核指标还是领导的个人风格都把执行力放在比判断力更高的位置。资深工程师吃过亏知道在立项阶段提反对意见往往会被贴上没有经营的全局观思路跟不上公司节奏的标签。于是大家不说话需求照单全收项目在一片假性共识中扬帆起航。等做到一半数据反馈越来越差用户根本不买账这时才有人想起来复盘——原来当时的质疑是准确的。但船已经开到深水区了这时候掉头要比当初回答那几个问题昂贵得多。3.2 中期失控指标扭曲了动作到了项目中期最要命的事情是指标主义。管理者需要数字来证明项目在推进于是有了各种漂亮的过程指标需求完成率、缺陷修复率、周迭代速度、里程碑达成数。问题在于当这些数字成了考核KPI团队的动作就开始变形。需求完成率怎么提升非常简单把大需求拆成小需求把复杂需求拆成表面简单但内部严重耦合的需求每周汇报已完成XX项需求。缺陷修复率怎么提升更简单开一堆低优先级bug然后快速标记为已处理或者干脆在验收标准上做到无法触发bug。迭代速度怎么提升砍掉文档、砍掉回归测试、砍掉操作手册只保留写代码和说能跑。资深工程师看得见这些动作是在饮鸩止渴但他没法跳出来说这个指标没有意义因为指标是管理层定的。指标本身不背锅背锅的是执行的人。他如果拒绝配合马上会有其他人来顶上这个角色而他在领导眼中就变成缺乏团队精神。所以他选择做旁观者看着项目在指标的美化下离真实目标越来越远。这又是一个典型的明知不对但无法干预的困局。3.3 晚期固化架构已经不兼容正确到了项目后期哪怕所有外部的条件都大转弯——市场变了、政策变了、竞争格局变了、连最初的需求方自己都承认方向错了——项目仍然很难停下来。为什么停不下来因为投入已经太大了。人投入进去了外包合同签了办公场地租了上下游的合作关系定了甚至有一部分人后半年的绩效就指着这个项目。停下来意味着大家都要收拾一个烂摊子很多人要面对重新找工作、重新找方向、重新解释自己之前做了什么。即使所有人都知道项目在错误方向上也没有人愿意承担宣布终结的成本。这在管理上叫作沉没成本谬误但参加过实际项目的人会告诉你它还有一个更通俗的表达项目早就不属于创始团队中的任何一个人了它是一个有了自己生命的组织。组织的惯性就是把一切资源维持在自己身上直到外部力量强行把它打碎。资深工程师在这时候的技术判断已经完全不重要了架构该怎么改、代码该怎么重构、技术债该怎么还——所有这些问题的答案都必须建立在这个项目还值不值得做的基础上。而那个问题早已超出技术范畴进入了政治和利益博弈的领域。他站在原地看着一个已经病入膏肓的躯体不断输血选择不再贡献自己的力气。3.4 项目经理视角里程碑像假新闻再补一个非常真实的观察角度项目经理的周报很多时候就是一份虚构文学。项目出问题之后没有人敢在周报里写我们可能要延后负责项目的PM会把风险提在最不起眼的角落用各种委婉的说法包裹起来受外部因素影响可能存在一定偏差部分里程碑处于风险状态需进一步确认。然后到了管理层晨会上最真实的项目状态被简化成一个任务列表上面全是进行中。资深工程师为什么会越来越沉默因为他每次在会上看到的项目状态和自己感受到的现实完全是两个东西。他提过真实的风险被PM用这个我们已经评估过了挡回来他写过真实的评估被领导用我们要从全局视角看问题压回去。几次之后他意识到在会议这个舞台上说话的唯一目的是管理其他人的情绪跟事实已经没什么关系了。于是他们就变成了那种开会时安静坐着的资深工程师。不是没话讲是讲了会被当成噪音干脆换一种方式来保护自己的带宽。项目该失败就失败反正周报上不会写我的名字。4. 资深工程师真正该做的是什么4.1 把放任变成可控失败三步止损法如果你现在正处在一个糟糕项目里正在纠结该不该放任我建议你把问题换一种问法不是我要不要阻止这个项目而是我要怎样让这个项目的失败成本降到最低。这里有一个可控失败的思路核心是三个步骤。第一步识别失败模式。糟糕项目通常分三种死法需求不成立做出来没人用、技术不成立根本做不出来或者做出来也是坑、组织不成立团队内耗到无法交付。先判断你这个项目是哪一种因为不同模式的处理策略完全不一样。需求不成立该做的事是停止开发、做市场验证技术不成立该做的是降低野心、换一个技术路线组织不成立该做的是推动人员调整否则做什么都白搭。第二步书面化风险并上报。你不能只是在头脑里认为项目会失败你需要把它变成文字发邮件、写文档、提交到项目管理系统里都要留痕。这不是为了说服别人而是为了在未来的问责场景里保护你自己同时也是在向组织释放一个正式的风险信号。你做了这一步就已经不是在放任了你是在履行你的职业义务。第三步划清止损线。给自己定一个明确的下限什么数据出现下滑我就必须走什么里程碑延期超过几周我就判断这个项目已经没有回天之力。止损线要提前划好最好写下来因为人是很容易被环境的惯性裹挟的明明说好了三个月后止损三个月到了又会说服自己再等等然后一等又是三个月。4.2 文档化一切让决策可以被追溯资深工程师做项目最重要的习惯不是把代码写好而是把所有关键决策记录下来。这听起来很平常但真正做到的人很少。我给你几个具体的文档化场景。你参加了一次需求评审产品经理口头承诺了某个功能不做但会后需求文档里没有体现这就是一个坑你要发一封邮件回述讨论结论留底。你评估了一个技术方案认为短期可行但长期会有债务这个判断只写在你的脑子里不算你要写进技术评估文档哪怕最后没人看。你在会上向领导反馈了项目风险领导说知道了但没有任何行动你也要发一条纪要说明你提出了风险并询问下一步计划。这些动作的意义不只是留证据更深层的作用是帮你保持头脑清醒。当你持续地写文档、记录决策你会越来越接近项目的真实面貌而不是被会议和口头传达制造出的幻象迷惑。等到项目失败的那一天你也可以坦然地翻开文档说我在哪个时间点、基于什么判断、提出了什么风险当时的决策链和信息依据在这里。这不是推卸责任这是一种职业素养。工程师对代码负责同样也应该对决策过程负责。4.3 用一个核心数据来说话在项目治理里有一条经验值得每一个技术人记住与其说一百句我觉得项目有问题不如让一个数据替你说。怎么选这个数据有讲究。你不能选代码行数这种无意义的虚荣指标也不能选bug数量这种会被修复操作注水的指标。更好的选择是和业务强相关的转化类指标比如用户留存、交易成功率、获客成本或者和技术强相关的交付质量指标比如生产环境故障次数、需求返工率、平均修复周期。我的经验是当你想向管理层证明一个项目应该被砍掉时最有力的证据往往是一张图表。拿一个周活跃用户数从上线到现在八周没有任何增长的数据图放在汇报PPT的第一页。比你说一万句用户不买账都管用。工程师长期被训练成用代码和逻辑说话但在管理层眼里逻辑如果没有数据支撑就只是你的个人观点。所以你不是要说服他们你是要提供他们愿意相信的证据形式。4.4 在有退路的时候喊停而不是在悬崖边喊停时机选择是资深工程师在放任与干预之间做决策的核心变量。好的干预时机是项目还有选择的时候需求定义阶段、架构选型阶段、上线前的最后一次大评审。这些阶段喊停调整成本低方案空间大即便你的提议最终被否决双方的讨论质量也会显著高于一个注定要走向终结的项目。坏的时刻是项目已经被宣布没有退路的时候。这时候跳出来喊停要么被当成抢戏要么被当成推卸责任最理想的结局是你把大家从坑里拉出来但没人感激你最差的结果是你被当作导致项目延期的罪人。我自己的经验是如果你判断一个项目需要喊停不要拖到第一波数据出来再喊第一波数据往往要几个月之后而到那时候组织已经付出了大量资源。你要在项目开始的第一个月内、在大家还有余量修正的时候把风险讲清楚然后给出你的替代方案。如果领导不接受那至少你已经尽到了提示的义务后面走多远都是组织自己的选择。5. 从组织层面看工程师不敢救的根子在系统设计5.1 建立红队会议和熔断机制前面聊的都是工程师个人的选择但如果一个组织里资深工程师普遍性地选择放任糟糕项目失败那问题就不在个人而在系统。一个健康的项目治理体系需要两个机制。第一个叫红队会议通俗地讲就是指定一个角色专门唱反调。每到一个里程碑节点由这个角色可以是外部顾问、技术委员会成员或者别的项目的工程师来审视当前项目假设这个项目注定失败最可能是因为什么这面镜子一照很多被团队集体无意识掩盖的问题就现形了。第二个叫熔断机制类似股市的断路器。项目在立项时就事先约定清楚哪些指标一旦跌破项目无条件进入暂停状态必须重新论证。比如用户周留存低于百分之五、关键功能截止日连续延期超过三周、单月实际支出超过预算一倍谁触发了谁就有义务喊停。熔断的意义在于把终止项目这个沉重的决策从某个人肩膀上拿下来变成一条组织预先同意过的自动化规则。这比指望某个资深工程师在关键时刻挺身而出要可靠得多。5.2 奖励止损者而非救火英雄大多数公司的激励体系都在造救火英雄而不奖励止损者。救火英雄的行为逻辑是项目出了问题我冲上去力挽狂澜最后项目勉强成功了我成为明星员工。这种激励的问题在于它鼓励项目到危机边缘因为没有危机就没有英雄登场的机会。讽刺的是真正阻止危机发生的人反而不被看见——项目没出问题大家觉得那是本来就该有的样子你提前预测了风险但项目没崩有人说你小题大做你推动砍掉一个注定失败的项目没人给你发奖章你只是让一个没发生的事故没有发生。要让资深工程师不再放任糟糕项目失败组织必须改变评价导向谁能用最低成本识别危险、谁能在错误方向早期止损、谁能把一个注定失败的项目拦腰截断谁就应该获得比救火英雄更高的评价。这个改变说起来容易做起来难因为它要求管理层有足够的心理安全感接受一个被止损的项目和一个成功的项目同样值得庆祝。大部分管理层做不到这一点他们眼里只有完成了的目标和没完成的目标那些被避免的失败因为看不见所以得不到奖励。5.3 管理者要回答的问题清单如果你是一位管理者已经意识到团队里资深工程师有着放任者的姿态请先不要指责他们缺乏担当先用下面这份清单检视自己的管理系统项目运行过程中我们是否允许技术负责人在不承担背叛团队骂名的情况下提出反对意见上一个被叫停的项目相关人得到了什么反馈被夸赞了、被冷落了还是被贴上了读不懂战略的标签里程碑达成这个庆祝信号出现时我们是否同步考察过达成的方式——是靠真实可用的功能还是靠砍掉测试、降低标准、虚报进度当一个资深工程师提交正式的风险报告后续有没有一个明确的处理流程还是说它的下场就是被收进共享文件夹吃灰我们奖励过那些阻止了灾难的人吗哪怕灾难没有发生有没有人为此得到过认可这些问题如果在你的组织里得到的答案都是负面的那么资深工程师的放任就完全是可以预期的理性行为。改变个人很难改变系统才有机会。6. 常见误区与边界什么时候真的不该放任6.1 误区一资深工程师放任项目失败就是不负责这个说法是片面的。资深工程师的放任往往是在系统地评估了干预成本与干预收益之后做出的选择。正如前面说的他可能已经提交过正式风险报告、在会议上提出过替代方案、在周报里标记过负面趋势。在这些努力全部无效之后他的放任已经在道德上站得住脚了——他已经做了所有他能做的接下来只是不再消耗自己。把放任等同于不负责会忽视一个更本质的现象组织本身就已经让负责这件事变得毫无意义。一个无法接受负面信息的组织就像一个无法接收疼痛信号的病人他不是不想治病是病已经让他感觉不到病的存在了。6.2 误区二项目失败就是技术失败这是很多技术出身的管理者最容易犯的误判。他们把项目失败等同于技术失败于是把责任追加到工程师头上。但多数项目失败的原因根本不在技术层而在需求、市场、协作和管理层。一个项目技术上很成功但商业上失败的状况太多了。做了个性能极佳的App用户不使用搭了个扩展性极好的平台方向根本错了。这时候资深工程师从一开始就看得出问题但他没法用技术手段解决一个商业问题。他没站出来说话不是因为他不负责而是因为让技术团队去给商业方向背书这个事本身就挺荒谬的。6.3 误区三放任永远不该发生最后说一下边界。不是所有项目都值得拯救也不是所有项目都应该被放任走向失败。什么情况下真的不该放任我梳理了几个特征项目所在的赛道正在高速增长、用户需求已经有了初步验证、团队手里有很强的技术壁垒、当前问题只是执行层面的混乱。这种项目虽然糟糕但底子是好的值得投入心力去抢救。判断标准很朴素糟糕和失败是暂时的还是结构性的。暂时性的糟糕比如人员错配、进度失控、某个技术方案选型失误可以救也应该救结构性的失败比如需求本身不成立、跟市场竞争格局根本不匹配、项目目标从一开始就基于幻觉救它就是在浪费资源。我看过太多工程师把二者混为一谈遇到一个烂项目就条件反射式地想要拯救把自己燃烧殆尽最后项目还是失败了自己成了那只殉葬的鸡。反过来也见过很多工程师矫枉过正把一个完全可以通过调整方向活过来的项目早早地宣判死刑。资深和资浅的差别不在于会不会踩坑而在于能不能看清这个坑是绕得过去的还是本来就在整片塌方区的中央。写到这里我想起自己带过的一个项目。当时所有人都在赶一个看起来很有前景的上线日期唯独架构师在第一次评审时坚持说技术债太多至少要再花三周重构。我一开始也觉得他过于保守后来真相是我们低估了数据量上线第三周系统就撑不住了那次重构如果没做整个季度都会被搭进去。从那时起我对资深工程师的反对有了新的态度他们不喊停的时候你未必看得出哪里有问题他们喊停的时候你要先认真听再判断是不是该信。至于他们选择沉默的那些时刻与其急着责怪不如先检查一下自己的组织是不是早就把他们的声音掐灭了。一个需要资深工程师用放任来自保的组织才是真正值得警惕的糟糕项目。