项目为何会失败

“ ……
大家将首先遇到塞壬女妖们  
她们会唱出美妙无比的歌声  
以此来诱惑往来穿梭的行人  
如有人靠近聆听她们的声音  
他将不可能得到生还的机会  
再也见不到本身的妻子儿女  
……”

—— 荷马史诗，奥德赛，第十二卷。

　　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的世界有个“通病”，逮着什么都想封装，既然“万物皆对象”，那失败也应该能够抽象。

 

　　这几年的从业经验，我抽象了一个规律：

1.  若是客户以为事情简单，那么项目必定会延期。
2.  若是客户和老板都以为事情简单，那么项目会烂尾。
3.  若是客户、老板和团队，同时以为事情简单，那么…… 全部人最后死都不知道怎么死的。

　　项目中全部的 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).

　　

　　

　　有句话怎么说来着：失败是成功的妈妈…… 嗯？

 

　　因此，项目为何会失败。 :)

 

 

 

 

 本文已独家受权给脚本之家(ID:jb51net)公众号发布