大型科技公司的项目是如何失败的？
原始链接: www.seangoedecke.com/how-project...
大型科技公司的项目为什么会失败？正如我多次提到的，失败意味着高管对结果不满意。在运转良好的公司里，这也意味着理智的工程师同样不满意，因为项目要么没成功，要么用户很讨厌。那么到底是什么导致了项目失败？过去十年，我近距离或远距离旁观了许多出错的项目。以下是几个主要原因。
注定失败
许多项目从一开始就不可能成功。就像在法律案件中，有些诉讼即使原告证明了所有细节，也无法胜诉。在科技公司，有些项目也是如此：即使计划执行得再完美，最终也难逃失败的命运。
有些项目死于好高骛远。 比如，高管（通常是副总裁或高管团队）觉得自己的团队能和某家成功的公司竞争，于是启动项目去复制人家的产品，结果半年后整个项目就被悄悄搁置了。大公司常常看着初创公司想："我们工程师多得多，为什么做不到？" 这种想法催生了无数失败的项目。
有些项目死于对技术的纯粹误解。 最近常见的一个例子是，高管决定"我们要用 AI 给用户自动完成某项任务"，但 AI 的实际能力根本达不到他们的期望。如果公司领导和优秀的高级工程师关系融洽，通常可以避免这类注定失败的项目。如果公司执意要做一系列不可能的事，往往说明核心工程师群体要么能力不足，要么没能与产品领导层建立起信任。
缺乏内部支持
还有些项目本来不是死局，但因为缺乏内部政治支持 而失败。也许公司本来可以完成副总裁的计划，但根本没有足够的资源去验证。项目执行到一半，核心工程师就被强行抽调去干别的（无视副总裁的强烈反对），导致项目延期且充满 Bug。发布前，项目没能在公司的主要营销渠道上宣传，导致难以积累首批用户。而一旦出现失败的苗头，领导层直接决定放弃，而不是想办法抢救。
无论主意好坏，任何项目想要成功，都需要在整个生命周期内获得持续的支持。领导层里必须有人出面，阻止别人挖走你的工程师，或者防止团队被塞入其他"看起来更炫酷"的新任务。项目上线交付给用户后，也必须有领导确保仍有专门的团队负责处理用户反馈。
这种失败模式的一个经典例子是不合时宜的领导层更迭。这对耗时多年的项目（如大型基础设施重构或语言迁移）尤为致命。假设新来的 CTO 非常喜欢 Scala，并说服团队用 Scala 重写大部分系统。这项工作量很大，但因为有 CTO 在背后推动，进度一直不错。两年后，CTO 离职另谋高就了。这对正在用 Scala 重写代码的人来说绝对是个坏消息！失去了领导层的持续施压，团队就会开始优先处理更面向用户的需求。其他副总裁也趁机推销自己的想法，因为 Scala 迁移现在显得没那么重要了。最终，整个重写计划半途而废，系统里既有 Scala，也有其他语言。
纯粹运气太差
有些项目失败是因为遭了雷劈 ：遇到了难以预料的灾难性厄运。比如，项目偶然引发了一次大事故，导致全公司宕机两天。那么这个项目很可能会被套上各种拖慢部署进度的繁文缛节，再也无法高效推进。哪怕事故纯属倒霉，极度厌恶风险的大公司通常也会把锅甩给这个项目------除非项目有极其强大的靠山。
还有些项目则是一次合理的尝试，但没收到成效。用户的心思很奇怪且难以预测。你可能做了一个看起来会大火的产品（甚至用户自己都强烈要求过），结果上线后根本没人用。这就是纯粹运气差！科技公司通常会耐心等一阵子，因为很多成功的产品起步都很慢，但最终领导层还是会失去耐心并停止支持。
执行能力太差
有时候失败无关运气，就是执行得太烂。项目目标合理、支持到位，万事俱备，结果被工程师自己搞砸了。如果首席工程师完全无视我在这里给出的建议，项目就会变成一团糟：缺乏协调、沟通不畅、关键环节掉链子等等。
这有几种可能的结局。最乐观的情况是勉强混过去：上线不顺利，大家也搞不清状况，但 Bug 最终被修复了，首批用户也有足够的耐心陪着工程师慢慢解决问题。最糟糕的情况是，糟糕的执行引发了我们在上一节提到的灾难性事故。
最常见的结局是，领导层发现这是一个运转不良的项目，并采取措施限制损失。这看起来有点像项目失去了支持（比如减少营销投入），但这其实是执行不力的后果。无论如何，项目最终雷声大雨点小地草草收场，很快被遗忘。
凌迟处死（被各方意见拖垮）
如果一个好点子一开始没有强大的"靠山"（通常是副总裁或高管），就容易陷入这种死法。假设一个工程师提出了一个好主意并试图说服公司。产品经理说太棒了，但要求微调一下；经理也要求改一点；更高层的领导非常喜欢这个主意，但要求必须和即将上线的"新产品 Y"整合，并且必须在公司的新版移动 App 上首发。就这样，最初的好点子被各种强制要求不断稀释，最终变成了一个烂主意。
发生这种情况是因为：在大公司，想把事情做成需要很多人的认可。你需要很多不同的人同意这件事值得做。然而，所有人支持你都是有私心的（通常是希望你的项目能帮他们自己的项目成功）。所以，你获得的每一份支持都带有附加条件，久而久之，这些条件就会在好点子真正起飞前把它扼杀。
解决办法之一是想办法先让 CEO 对这个点子感兴趣，然后由 CEO 直接下令让大家配合，从而省去讨价还价的麻烦。另一种办法是不经过批准直接干（比如做成地下"臭鼬项目"），指望不靠大公司的资源也能搞成。但这两种做法风险都极高：越级直接找 CEO 会得罪你的整个汇报链，而大部分地下项目都会失败。但既然人们宁冒风险也要这么做，恰恰说明被各方意见"凌迟处死"是多么可怕。
总结
科技公司的项目会因为各种原因失败，我亲眼见过以上提到的所有情况：
- 有些项目注定失败，要么好高骛远，要么技术上不可行。
- 有些项目本来能成，但缺乏贯穿始终的内部政治支持。
- 如果推动项目的关键领导离职，项目通常就死定了。
- 有些项目死于纯粹的运气差：要么用户不买账，要么倒霉遇到事故，导致项目被后续的补救工作压垮。
- 有些项目死于工程师糟糕的执行力。
- 如果项目没有强大的靠山（比如由普通工程师驱动），为了获得认可而答应的每一个附加条件，最终都会把整个项目拖垮。
如果你喜欢这篇文章，欢迎订阅我的邮件更新，或者在 [Hacker News 上分享](news.ycombinator.com/submitlink?... projects fail at large tech companies)。以下是一篇相关文章的预览：
在大型科技公司把事情"做完"
把事情做完意味着什么？在理论上，你可以解出一道数学题，但在现实世界中，界限往往模糊得多。假设我在后院种了一棵树。把树苗埋进土里，就算做完了吗？并不是。总有更多活要干：清理周围的杂草、浇水、防虫、修剪等等。编写大型 Web 应用比解数学题更像种树。一旦你写好了一个服务，只要你愿意，你可以永远维护下去。
继续阅读...