软件项目是这样失败的。

谁也不知道城西银泰豪华的大楼是什么时候出现的。即使像我这样天天上下班都经过那里。

记忆里似乎巨大的塔吊和漫天的扬尘在那里飞舞了大半年，也许是一年有余。几个月前突然某一天经过时，看到了颇具规模的大厦似乎正在慢慢形成。直到最后几天，当最后一个丑陋的脚手架被拆掉，才发现这里竟凭空出现了如此巨大的庞然大物。

不禁感慨人类的才华和创造力。

相比之下软件行业似乎显得很渺小，通常很难向一个行外人介绍一款“伟大的软件”，因为他们很难理解一堆.dll和.exe的伟大之处。在他们眼里，只有一堆看不明白干什么用的奇奇怪怪文件和一个不见得多漂亮的图标，双击进入之后有功能A,B,C,D,E,F,G。

不幸的是，在多数人坚信“项目经理不需要懂技术”的巨大背景下，连项目经理本人也理解不了程序员们那些自称屌炸天的设计架构。

于是有了各种银弹，各种管理方法。其中之一有一个大家都耳熟能详甚至耳朵磨出茧的名字——敏捷。

快速迭代，快速发布可用版本。在看得见的功能一个接一个被“制造”出来，管理者比任何时候都心中有谱。于是他们在此之上又发明了以功能点来计算工作量等等诸如此类的时间管理方法。并对所有人说自己的项目用这管理方法进行的十分顺利。

某天一个管理者理所当然地听说并坚信了敏捷管理的出类拔萃所向披靡。他的团队正要建造一个像银泰城一样伟大的项目。

他理所当然地不想看到一堆开发者貌似很努力的敲打键盘然后产生一个个莫名其妙的带着各自后缀名却无一可以双击点开的文件。这种感觉加上一些基因带给他的莫名的不安全感让他觉得可怕，这些埋头敲键盘的家伙到底在干些甚么？他们拿走了不菲的薪水却很可能在搞一些跟工作压根没关系的东西。项目进度怎么样了？是不是该让他们加加班？是不是他们中有人技术不达标导致整体进度有问题却瞒着我好多领几个月薪水然后走人？这种无力感让他坐立不安。看着这群自称程序员的家伙天天上班下班就像看着工地里漫天的扬尘和出入其中的满载的黄沙车，工地上看上去一直是一片混乱，工队负责人告诉他在打地桩，可是，天知道发生着什么？

这次他决定采用更先进的管理方法，而这一方法已经被无数人证明科学且百分之百成功。敏捷，或是叫别的什么名字，管它呢。快速发布可用版本，快速迭代，基于功能点的计划，棒极了。

于是他把大楼图纸大致看了一遍，决定在第一个月完成第一层的最北边商铺，接下来两个月继续完成剩下的三个方向的。一开始总是会比较慢，因为那群程序员告诉他有许多设计什么的额外工作。计划是再接下来每两个月完成一层楼，这样完成整栋6层大楼需要13个月。加上测试和发布，15个月足矣。何况，第五层和第六层面积要小很多，应该会快不少。

他把所有人召集到一起开了一次长达一天的会，解释敏捷开发的成功案例和他的计划。所有开发人员都同意敏捷是时下最先进的管理模式，其中有两个似乎还看了不少相关的书籍教程觉得计划非常科学，在会议上盛赞了半天经理的英明神武，经理决定下次有机会提拔他们。项目红红火火的开始了。

 

 ----------------->>> 分割线  <<<----------------------

 

在经理强大的个人魅力感召下，敏捷进行的比想象得还要顺利。一开始几个员工自愿加班加点，后来更多的人加入了他们。几乎每天都能看到他们在会议上为新完成的功能欢呼雀跃。不出所料，一开始的工程在20天内就完成了。经理给了项目中每一个人一笔不菲的奖金并在部门会议上表扬了每一个人。开发人员充满干劲，能够拥有如此优秀的团队，简直是上天的恩赐，经理睡得比任何时候都踏实。白天有人向他提到项目架构的风险，也许该给他加点薪水了，明天也有必要向全员强调下保证质量。

项目进度一路高歌猛进，团队里的每一个人都坚信自己所在的团队是首屈一指的，没有别的团队能在如此短的时间里发布如此多的功能。在前6个月他们已经完成了相当于3层大楼的所有商铺，唯一的问题是有比较多的零散BUG，大概是士气高昂之下大家都没有把项目质量的要求太放在眼里，以往的经验来看这些不会成为风险，经理自己也觉得这没什么可担心的。

第一次问题出现在第7个月中旬，有两个开发在例会上告诉大家ORM模块线程不安全。经理对此一头雾水，但似乎所有的开发人员都认为形势很严峻。有人提出在保证进度不拖慢太多的情况下进行一定程度的返工。有时候这在所难免，技术负责人说这就像是给大楼的第一层较小的柱子加一个支撑结构，应该很快就会完成。很快项目回到了正轨，只是更多的人偶尔提出设计架构的缺陷，但我们拥有如此优秀的团队，大家总会有办法做好它。项目进行到中旬，这往往是最考验项目经理能力的时候。经理表现出他在软件项目上的强大经验适时的激励组员，强调这个项目完成后公司能获得的巨大收益，所有人倍受鼓舞。

顺境只持续了两周，在第8个月初，计划中要进行的5个功能点开发有2个停摆，问题还是在ORM上。组里最年轻的程序员提出项目架构有巨大缺陷，需要大规模重构。其他所有人都认为这样做风险巨大，而我们目前面临的问题并没有想象中那么严重。只是需要在更大的层面上返工一下，然后在某些不能工作的地方做点特殊处理。经理这时候隐约感觉到似乎有点不对劲，好在项目进度已经足足提前了两个月，就算有问题也还有的是时间慢慢解决。他在例会上允诺了正在想公司为每一个组员争取利益，大家站在同一阵线上努力前进。例会非常成功，员工们又开始自愿加班。 

此后又有若干次功能开发上的问题，在大家集思广益下都一一得到解决，虽然进度的领先已经几乎不复存在，但大部分功能也已经可以工作了。

真正的问题出现在第11个月中旬，在所有人测试服务器负载时发现并行处理能力不足以支撑整个系统业务需求。开发人员分析后告诉经理这主要还是因为ORM多线程处理有问题，而目前模块间耦合十分严重又导致不可能单独替换掉ORM模块。这就像是大楼的承重结构有问题，不把整个楼拆除根本不可能换掉哪怕其中的一根柱子。而底层的数据结构设计也有很大的缺陷。产品经理开始妥协砍掉上层一些不太重要的功能以期待系统能满足大多数需求，可技术负责人说还是不行。时间仅剩4个月，这时候已经没有人说要从头搭建架构了，因为所有人都知道时间不够。经理也清楚，在没有把握的情况下自己跳进这坑里极有可能被坑死在里面，未来也没可能再在这个公司混下去了。大家开始质疑需求的合理性，推脱责任，和有问题的模块划清界限。越来越多的BUG被证明与架构缺陷有关，不大规模重构就无法修复。项目陷入了一片混乱，所有技术人员每天开会思考风险较小的办法处理，但似乎每个方案都被推翻。知道12月初，一些人开始提出除了大规模重写别无他法。经理为此每天无法入眠，他每天陪员工加班到深夜，恨不得自己也上去写两行代码，如果能帮上忙的话。他开始询问每一个技术细节，希望自己能为大家或多或少提供点意见。但这除了增加了更多的会议之外似乎没有什么效果，甚至有人抱怨他占用太多时间。

噩梦一般的日子又持续了两周，眼看离交付只剩3个月，经理感到前所未有的无力和沮丧。自家小区边又开始建造房子，灰蒙蒙看上去一片混乱，看不出来工地里在干什么。这种工程居然能够成功，果然造房子比造软件容易多了。

 

 ----------------->>> 分割线  <<<----------------------

 

部门领导每周都会询问这一重要项目的情况，以往经理总是会给出超出预期的答案。可最近连续几周项目没有任何进展，经理在周会上根本不敢面对大家。领导还在安慰他说努力努力，大家都在同一战线上。激励下属，作为这个民族管理学的最核心精髓，经理对此再熟悉不过。只是，假如一开始大家没有被热情冲昏头脑，是不是就会发现问题？会不会有人其实一开始就已经发现问题而没有说出来，只因为说出来会大家耻笑太悲观？

看着窗外远处建筑工地一片混乱的情景。也许房子只有这一种造法，前八个月注定尘土漫天，不会有一家商铺靓丽地出现在世界上，只有打桩机的轰鸣和巨大的钢筋混凝土柱子，商铺只在最后6个月以惊人的速度完成。

第二天，经理找来了所有的开发，询问了每一个人的意见后宣布，所有底层设计架构重做。

我们一起回到那一片漫天的尘土中去。