国内软件项目的典型历程 - 转自 http://space.itpub.net/17007506

  原文地址:http://space.itpub.net/17007506/viewspace-550369  

 

  国内现在有不少软件团队仍然在采用最原始的方式来做项目，我们来看一个典型的案例：

 

  老板将项目任务下达后，项目经理便开始拉拢公司中的几个能人，经过跟老板的一番讨价还价，总算将其中的两个受归麾下；而作为平衡，另外的人选老板则塞了几个菜鸟过来。

 

  于是，项目就这么开始了，项目经理先带队跑到客户那里呆了两星期，经历了若干次与客户的猜拳喝酒之后，终于拿到了一份客户签字认可的需求。此后，项目经理召集组员们开会，将需求中的功能划分出若干模块，然后据此开始分配任务；大家又是一番吵闹，在项目经理的威逼利诱之下，重要的模块总算压给了两个能人，剩下一些较容易的模块则理所当然地被菜鸟们瓜分一空。

 

  在组员们每天按时上下班，轻松了一个月后，项目经理在老板的压力下，终于露出了狰狞的面容，组员们只好开始加班。随着菜鸟们不断宣布有新的功能模块被完成，项目经理脸上也露出了久违的笑容，并催促那两个能人加快进度；慌乱之下，两个能人终于提交了几个关键的模块。

 

  项目经理决定将这些模块集成起来，给老板做次汇报演示。这时侯风云突变，一大堆bug突然冒了出来；更麻烦的是，有几个模块就是无法跟核心模块一起联调成功。项目经理发现这几个模块正是菜鸟们最先提交的那批成果。被逼无奈，项目经理请两个能人吃了顿饭，饭桌上，被灌醉了的能人们拍了胸脯——一定帮哥们将菜鸟们的模块搞定。经历一番痛苦的加班加点，项目经理跟两个能人一道修改了菜鸟们的模块，总算将软件集成成功，但是新的问题又出现了。

 

  在给老板演示汇报的现场，源于对项目经理的无比信任，老板将客户也请了过来。客户兴奋地尝试了一下操作，不料有个功能，客户出乎意料地输入了比较复杂的数据，结果等了半天系统也没有响应。客户不快地走了，第二天打电话给老板说，有几个主要的功能好像没有按他们原来要求的那样做。

 

  老板第一次将项目经理叫到办公室单独谈了一上午。项目经理于是耐心地与客户做了沟通，发现客户提到的那些功能，有的根本就没有写在需求上，当然也有几个是开发组与客户理解出现了不一致。客户不能接受项目经理的说法，认为要让他的业务能够运转，没有写在需求中的那几个功能恰恰是必不可少的，并指责项目经理不懂他的业务。项目组只好接受了这些需求变更，并组织组员们修改代码来实施变更，同时还决定要一并改进代码的运行速度。

 

  过了几天，其中一个能人跑来跟项目经理说想要调到其它项目组去。磨蹭了半天，能人才据实相告，因为事先没有设计好，客户要求的需求变更很难实现得了；另外改进代码运行速度的工作量比预想的要大很多，几乎所有的模块都要改。过了不久，这个项目最终被宣告失败。