项目为什么会失败

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

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


  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)公众号发布

posted @ 2018-07-19 17:59  sherrywasp  阅读(4907)  评论(23编辑  收藏  举报