“ ……
你们将首先遇到塞壬女妖们
她们会唱出美妙无比的歌声
以此来诱惑往来穿梭的行人
若有人靠近聆听她们的声音
他将不可能获得生还的机会
再也见不到自己的妻子儿女
……”
—— 荷马史诗，奥德赛，第十二卷。
1964年，通用电气、贝尔实验室和麻省理工联合发起了一个极具野心的项目，Multics. 目标是创建一个用于大型机的分时共享操作系统。但项目的难度超过了大家的想象，到1969年，贝尔实验室断定 Multics 是一个代价高昂的错误，率先退出了该项目。最终，项目以失败告终。
2002年，原 Lotus 公司 CEO, 上世纪80年代 IBM PC上的杀手级应用 Lotus 1-2-3 的创始人 Mitchell D. Kapor，成立了 Open Source Applications Foundation (OSAF) ，启动了一个颇具野心，试图超越 Microsoft Outlook 的 PIM 项目，名叫 Chandler。到2008年，Kapor 辞去 OSAF 主席一职，并宣布撤资。Chandler 项目历时 6 年半时间，两打顶尖程序员，上百万美元的投入，却是南柯一梦。
Wikipedia上的 Chandler词条
我所在的公司也曾陷入过一次困境。几年前，公司与一家日本企业进行了深度合作，启动一项(方向错误的)产品战略。老板非常看好项目的前景，雄心勃勃地直接将公司做了技术转型。项目周期很长，持续数年，参与项目的同事们夜以继日的像日本人一样努力地干。最终等待大家的，是产品在日本市场根本推不出去的尴尬，拿回国内也由于设计思想不符合国情，毫无价值。最终，在 demo 之后，老板虽不甘心但无可奈何地壮士断腕。
软件开发这一行，失败是遍地开花的，所以成功才显得荣耀。每个项目的失败都有着这样那样的原因：需求分析没做好，产品设计有缺陷，市场调研过于乐观，项目周期太紧，人手不足，技术门槛太高，主程半路跳槽了，前端失恋了，设计师休产假了，产品经理是二货，项目经理是摆设，老板是外行，客户就是一坨翔…… (以下省略1万字)
其实，事情没这么缭乱。
OOP的世界有个“通病”，逮着什么都想封装，既然“万物皆对象”，那失败也应该可以抽象。
这几年的从业经验，我抽象了一个规律：
- 如果客户觉得事情简单，那么项目一定会延期。
- 如果客户和老板都觉得事情简单，那么项目会烂尾。
- 如果客户、老板和团队，同时觉得事情简单，那么…… 所有人最后死都不知道怎么死的。
项目中所有的 delay，都可以归结为一个原因：对困难估计不足！
而失败，就是无限期 delay.
把控 delay 风险，是一件很难的事情。在软件开发活动中，精确地预估项目周期是一个伪命题。想要搞清楚一个事情需要多少时间完成，习惯性的思维是从过去的同类项目经验中寻找依靠，可悲剧往往在于，软件项目不是简单的复制，总会有意外发生。更不用说那种50%以上的需求产生于交付之后的项目了。（朋友，勾起你的回忆没有？）
预估完成时间就像信用卡消费，刷起来容易，还起来要命。
所以，大多数人都很容易把问题想得太简单，这种思维陷阱就像塞壬(Siren)的歌声，充满了诱惑力，这就是为什么失败比成功更普遍。
人类很容易膨胀，尤其是男人，而我们又处于一个男权世界。（这里我并不想讨论女权问题，可能有人会说当今社会已经大力提倡男女平等了。对此，我只想说，男女平等这个口号的提出，本身就意味着男女不平等的事实，女权主义的存在，正是因为女权的缺失。）
1944年6月，因为事先知道任务的艰巨性，盟军做了足够的准备，所以，诺曼底登陆成功了。这个成功非常巨大，以至于对于训练有素的，每天都在拿命操作的军人们也瞬间被冲昏了头脑，喊出圣诞节前结束战争的口号，发动了著名的市场花园行动，结果盟军大败，损失惨重。这下才意识到从诺曼底到柏林，还有很长的路要走。
生死攸关的战争中，人类都可以盲目自大，何况一个软件项目。
经典美剧《兄弟连》第4集，讲述“市场花园行动”
我曾读过一本很棒的间谍小说，福赛斯(Frederick Forsyth) 的 《豺狼的日子》(The Day of the Jackal)，惊心动魄的情节中最令我印象深刻的，是代号“豺狼”的职业杀手在执行任务前的各种准备工作。其中有一段剧情：在接下任务之后，豺狼为了确定最重要的暗杀时间及地点的选择，他数日泡图书馆，通过《大英百科全书》检索有关戴高乐的参考书目，然后用假身份邮购了所有资料，花了三周的时间，阅读了所有能搜集到的戴高乐的资料，从中分析他的性格，习惯，总统日程等。最终发现戴高乐在每年6月18日——“自由法国运动”纪念日——必定会出席一个无论刮风下雨都要公开露面的仪式，地点就在“六月十八”广场。敲定了时间和地点之后，豺狼又用了三天，实地考察了准备行动的广场，并确定了暗杀时藏身的公寓。
对困难估计的越充足，准备工作就越周全，成功的机率就越高。
一个项目中的困难，是需要所有的项目干系人都意识到，才会有解决方案。之所以这么说，是因为我曾经合作过一个优质客户，甲方对困难的估计非常充分，光立项就花了半年的时间，并制定了400人天的研发周期，而当项目中意外频发，不可避免地还是面临 delay 时，甲方很理解地说对此有充分地心理准备，主动调整 deadline，这才保证了项目在和谐的氛围中“如期”上线。
做软件很难，需要每个人都不犯浑才能取得成功。
回到1969年，Multics 项目的失败后，其中一名叫做 Ken Thompson 的工程师总结了 Multics 中的种种经验教训，然后就有了Unix . 这听上去有些荒谬，大名鼎鼎的 Unix 起源于一个失败的项目。事实确实如此，Unix 最开始叫做 Unics ，起这个名字本身就是针对 Multics 而言的，Multics 希望做成大而全的系统，而 Unics 就只做好一件事。“小即是美”的哲学正是吸取了 Multics 失败的教训。这种影响也一脉相承到 Unix 的孪生兄弟 C语言文化中。
前面提到的 OSAF/Chandler 项目的失败，却由此诞生了一本不可多得的著作《梦断代码》(Dreaming in Code).
有句话怎么说来着：失败是成功的妈妈…… 嗯？
所以，项目为什么会失败。 :)
https://www.cnblogs.com/sherrywasp/p/9337270.html