“ ……
你们将首先遇到塞壬女妖们
她们会唱出美妙无比的歌声
以此来诱惑往来穿梭的行人
若有人靠近聆听她们的声音
他将不可能获得生还的机会
再也见不到自己的妻子儿女
……”
—— 荷马史诗，奥德赛，第十二卷。
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 年半时间，两打顶尖程序员，上百万美元的投入，却是南柯一梦。
我所在的公司也曾陷入过一次困境。几年前，公司与一家日本企业进行了深度合作，启动一项(方向错误的)产品战略。老板非常看好项目的前景，雄心勃勃地直接将公司做了技术转型。项目周期很长，持续数年，参与项目的同事们夜以继日的像日本人一样努力地干。最终等待大家的，是产品在日本市场根本推不出去的尴尬，拿回国内也由于设计思想不符合国情，毫无价值。最终，在 demo 之后，老板虽不甘心但无可奈何地壮士断腕。
软件开发这一行，失败是遍地开花的，所以成功才显得荣耀。每个项目的失败都有着这样那样的原因：需求分析没做好，产品设计有缺陷，市场调研过于乐观，项目周期太紧，人手不足，技术门槛太高，主程半路跳槽了，前端失恋了，设计师休产假了，产品经理是二货，项目经理是摆设，老板是外行，客户就是一坨翔…… (以下省略1万字)
其实，事情没这么缭乱。
OOP的世界有个“通病”，逮着什么都想封装，既然“万物皆对象”，那失败也应该可以抽象。
这几年的从业经验，我总结了一个规律：
如果客户觉得事情简单，那么项目一定会延期。
如果客户和老板都觉得事情简单，那么项目会烂尾。
如果客户、老板和团队，同时觉得事情简单，那么…… 所有人最后死都不知道怎么死的。
项目中所有的 delay，都可以归结为一个原因：对困难估计不足！
而失败，就是无限期 delay.
把控 delay 风险，是很难的一件事情。在软件开发活动中，精确地预估项目周期是一个伪命题。想要搞清楚一个事情需要多少时间完成，习惯性的思维是从过去的同类项目经验中寻找依靠，可悲剧往往在于，软件项目不是简单的复制，总会有意外发生。更不用说那种50%以上的需求产生于交付之后的项目了。（朋友，勾起你的回忆没有？）
预估完成时间就像信用卡消费，刷起来容易，还起来要命。
所以，大多数人都很容易把问题想得太简单，这种思维陷阱就像塞壬(Siren)的歌声，充满了诱惑力，这就是为什么失败比成功更普遍。
人类很容易膨胀，尤其是男人，而我们又处于一个男权世界。（这里我并不想讨论女权问题，可能有人会说当今社会已经大力提倡男女平等了。对此，我只想说，男女平等这个口号的提出，本身就意味着男女不平等的事实，女权主义的存在，正是因为女权的缺失。）
1944年6月，因为事先知道任务的艰巨性，盟军做了足够的准备，所以，诺曼底登陆成功了。这个成功非常巨大，以至于对于训练有素的，每天都在拿命操作的军人们也瞬间被冲昏了头脑，喊出圣诞节前结束战争的口号，发动了著名的市场花园行动，结果盟军大败，损失惨重。这下才意识到从诺曼底到柏林，还有很长的路要走。
生死攸关的战争中，人类都可以盲目自大，何况一个软件项目。