（原载于Argo逸仙时空Java版）

二、
“你们很不幸，进入了这个几年来做得最糟糕的项目，大家都很辛苦，但是你们很幸运，
因为你们通过这个项目你学到很多别人学不到的东西。”

英国这个项目，开发团队有十来个人，他们面对的任务，是要找出现在英国现行系统的所
有组件的源代码，把它们全部重新编译一次，从WAS5升级到WAS6平台，除了java运行环境
不一样以外，还要将原来形式各异的代码结构重整成标准的形式，使其能够在Build Serv
er上build得出package。这个团队里仅有三四位是有经验的老同事，而且也仅仅做过其中
的一部分component，其他的新人不光是不了解整个银行系统，甚至连使用的技术框架都不
了解；Team Leader才刚入职没几个月，甚至对公司整个流程都还不熟悉，基本上是PM叫他
做什么他就做什么，即使遇到问题也不知道根源在哪里，往往向PM承诺的schedule做不到
，PM由于不熟知下面的情况，也只能不断地向这个Leader施压。

眼巴巴地看着整个项目跟着schedule就从DEV阶段去到SIT（系统集成测试）阶段，又从SI
T要进入FT（功能测试）阶段了，但其实产出的东西质量根本不行，很多东西都要返工重做
，安装文档根本是乱写的，写的人自己都不知道能不能这样安装成功的，但荒谬的是，领
队没有想出任何有效的解决方法来，却想死死地跟着schedule，眼看着还有一个月就要发
正式的版本了，而所有东西都还很混乱。这个项目经理是个强势而且聪明的人，他本能地
感觉到项目的状况很糟糕，于是就到处去找管理层施压，反映到下层的结果就是每天狂加
班赶进度。那一个多月的时间，放弃了周末天天都在工作，天天在加班，有好几天加班到
凌晨两三点，连打车的的士司机都认得我。

就在这个危急的时刻，终于见识到了英雄人物是怎样挺身而出，力挽狂澜。就像大浪淘沙
一样，在危机中，那些平庸的人逐渐散去，而有能力的人这时才显露出价值来。先是加入
了两个有经验的领队，原来的领队被调离。然后这两个leader一边制定出有效的措施，一
边与PM谈判并重新调整schedule，包括使用两班倒的轮班策略，让大家不做无谓的加班；
然后将所有文档规范化，集中处理普遍性问题，妥善分工。在紧张的一个月过去之后，我
们终于赶在deadline的时候成功把所有package发布出去。我和另外一个BE合力在几天之内
把几十份installation guide全部检查修改完毕，连PM都竖起了大拇指。然后就是给英国
那边做UAT的技术支持，还要按英国时间上班上了一周，之后每周出一次release修复出现
的bug，如此这般直到项目成功go-live。

其实我们这边没做好，客户那边压力也很大的。我们加班，他们也要跟着加班，因为大家
对这个东西都没有信心。所有东西本来就应该跟着流程走，流程本身是没有错的。在DEV阶
段应该解决而没解决完的问题，就不应该留到SIT才解决；所有SIT应该解决而没解决的问
题，就不应该留到FT去解决。死跟着schedule走是没意义的，等到FT的deadline到了，急
急忙忙把没有质量保证的东西交出去，到客户那边的压力就更大了。正如开发行业一个普
遍观点——尽早解决问题，因为越迟解决，问题就会越变越大，乃至无法收拾。
在项目总结会议上，PM才终于松了一口气，说：“你们很不幸，进入了这个几年来做得最
糟糕的项目，大家都很辛苦，但是你们很幸运，因为你们通过这个项目你学到很多别人学
不到的东西。”在这个项目里，我见识过公司里技术最可靠的人，也见过拯救项目于危难
的英雄式人物，明白了我们是怎么把这个项目做烂的，更珍贵的是，我还能见到我们是怎
么把它再从烂做到好的。获益良多。