孕妇梦到蜘蛛:“双输”之路的困局（转）

“双输”之路的困局

  前两天，应邀请为一个项目案例做了点评，案例如下：

A公司是一家在家用电器零售领域深耕多年之后，拥有丰富的行业资源及经验的实体企业，A公司管理层想把这些经验及资源通过搭建一个IT系统来为客户提供相关行业信息并且实现交易。从年初项目正式开始到现在，7个月的时间过去了，这个系统还没有正式上线。为此，客户方负责该项目的IT信息主管刘一民，一直在为自己面对软件开发公司的一系列不规范化管理问题而愤愤不平。

刘一民通过熟人与某国内知名软件开发公司(以下称为B公司)开始接触，这家软件开发公司拥有近8 年时间的历史，其业务包括外包服务、软件开发等，并且有很深的政府行业开发背景。

双方谈定，由B承接A公司平台开发的项目，原定项目周期为三个月，第一期投资额为20万元。按照行规双方就付款商定，在项目开始之前预付50%，项目可以进行到验收的时候，再付30%，正式上线后全部结款，后续还将给予免费的半年服务。

年初，软件开发项目正式启动。先期A把各功能模块原型网站提供给B，比如，新闻发布系统、论坛，甲方都有自己中意的网站。让软件开发公司按照自己所中意的网站功能来做开发的参照??刘一民当时认为自己的需求应该是简单明了。

“最初我们在选择哪种开发语言犹豫了很久。最后选定了;主要是因为PHP开发简单，占用系统资源少。JAVA虽然具有跨平台及性高的特点，但是项目投资及占用系统资源较大。”刘一民说。由于刘一民作为甲方的主要负责人对于IT技术并不陌生，他认为，双方在沟通上应该更容易达成共识。 "

合同商定，项目实施期限为两个半月。客户方为此配备了本地、IDC托管、数据库系统和网络系统。与此同时，为了组建这个新的部门，刘一民开始招兵买马。也就是说，从人员到基础设备，客户方都作了充足的准备，各路人马各就各位准备在新业务中大展鸿图，可谓势气充足。剩下的就是等待这个信息平台的正式上线。　　

第一次出现分歧

在刘一民看来，这是一个并不复杂的项目。按说B公司的速度并不慢，四个软件技术工程师组成的项目组在半个月后就将开发出来的系统雏形交到刘一民手中。结果却出人意料。作为甲方项目负责人，刘一民大为惊异地发现项目原型跟自己当初的设想简直就是南辕北辙：“甚至于他们提供的原型图都有错误，小到图变形偏色，大到逻辑功能都弄错了，连版式都出现错误。第一个版本简直是完全失败的!”

在项目的进一步推进中，刘一民还发现，一旦涉及到修改版式，对方就会以各种借口要求项目延期。“一个小小修改，就要求给出十天时间，虽然对方没有提出要求增加项目的费用，但是对计划中等待上线的我们来说，付出的实际上有超出预算的时间成本。”

其实，刘一民也很清楚，没有一个软件开发公司能把第一个版式顺顺当当拿出来。可是，如果在此时，对方及时将必要的需求文档补上，重新对客户的需求进行分析，则可以将双方的损失减到最低。但是这家软件开发公司为了节约时间，根本无暇顾及规范文档的问题，他们采取客户提出一个错误就这个错误对着修改，结果却是旧错误派生出更多新错误。

“他们太轻视这个项目了，没有仔细分析客户需求。在正常情况下，需求规格说明书是在项目开发开始前就该做好双方签字的，而且做的过程中就该主动和我们沟通。”刘一民说。时间成本的损益为了加快项目进度，甲方公司其他同事开始参与进来，帮助做测试。但由于甲方大部分人员对专业技术的了解相对有限，他们只能从业务方面根据自己的使用习惯提出相关变更需求。

“此时，实际上需要开发商对他们的这些需求进行甄别，明确哪些功能是可以通过IT技术来实现的，哪些是超出了他们的业务开发的范围的。并且，在这个过程中应该由开发商来建立严谨的确认文档，以明晰双方的责权利，为后期追加项目资金投入作依据。”技术出身的刘一民对此相当熟悉，但他想不到即使在这种情况下，乙方也未采取相关措施。

刘并非不愿说服公司停止该项目，只是他更清楚公司为此要付出的代价：“我们必然要付出更长时间，因为不仅所有的需求我们要重新讲一遍，并且即使这样，也无法肯定别家开发公司会比这家更好?”乙方的项目工程师也抱歉地表示，他们当初低估了这个项目的复杂程度。相关负责人直言不讳：“我们也希望这个项目能快点完工，公司在项目上投入的人员已经超过了项目成本，实在耗不起了。”

7个月下来，这个小型的项目开始有些眉目。其间，这家软件开发商临时抽调了更多人来参与项目开发，大大超过预期投入成本，核算下来，他们基本无利润可言。

客户方同样受损，他们计划在其年会发布该系统，结果因为系统延误而使负责人非常被动。因此，客户不仅不承认超出原定项目的投入额度，还表示应该由开发商来承担因项目延期给他们造成的损失。这次损失达到项目总额的两三倍，最终造成了所有人都不希望看到的双输局面……

点评：

这真是一个典型的失败案例。原定3个月的项目，做了7个月，才有点眉目，进度延迟了至少130％以上, 乙方投入的工作量大大超出预期，已无利润可言，甲方也同样损失了很多，“双输”的局面可谓“双方”共同造成的。双方在这个项目上均表现出缺乏项目实施经验。

从案例中看，这本来不应该是一个很难的项目，因为项目需求的大方向是很明确的， 正如文中所说，A公司的业务领域属于家用电器零售领域，想通过搭建一个IT系统来为客户提供相关行业信息并且实现交易。A公司甚至对系统做成个什么样子都很清楚，比如A都能把各功能模块原型网站提供给B...... 这比起许多客户都不清楚自己到底要什么的项目不是强太多了吗？那么，为什么却会有这个结果呢？

也许因为项目的合同额不高，似乎双方都没有很重视售前阶段的工作，从案例中看不出有《工作范围说明书》即SOW的编写和确认工作。SOW可是售前阶段的重要产出物，是项目实施的基础，一般都是做为技术附件随合同一起签订，没有SOW，工作范围是不清晰的，不明确的。《工作范围说明书》的形式可以多样化，但是这步工作必须要做。

因为案例没有详细介绍售前工作，双方谈定的三个月项目周期就不知是依据什么而来，对工作量的评估是否合理就都很难说了，这个合同一开始就充满了风险。

项目启动以后，双方应当就项目执行的规范和约束达成共识，包括双方的沟通和交流机制、必须交付哪些文档，哪些文档必须确认，确认以什么形式等等都应描述清楚，通常这份文档的名称是《项目章程》，A公司的IT信息主管刘一民出身技术，对选择哪种开发语言有自己的判断，却不清楚实施一个项目，做为甲方，最主要应当对乙方提出什么样的要求。

如果说，SOW和《项目章程》的缺失，反映出双方尤其是B公司的项目流程不正规，为项目带来了很大的风险，但接下来的需求调研和分析如果做好了，还是有可能不让这些风险“落实”成问题的。因为项目成功的因素是很多的。

不幸的是，从案例中我们看到，最关键的环节，项目的需求调研和分析工作似乎进行得非常简单，A将心目中理想的各功能模块原型网站提供给B，自认为需求很“明了”了，而B公司没有将客户提供的需求进行系统分析、综合归纳，理顺逻辑关系等工作，并形成《需求说明书》之类文档，至少从案例描述中没有看到这部分工作，即使做了，只怕也没经过认真的评审和签字确认，否则，就不会出现现在这样的结果。

等到B将第一个“失败的版本”拿出，虽说A方刘一民很意外，但其实太正常了。那么多应该做的事情都没好好做，凭什么做出来的东西就该符合他心目中的设想呢？

第一个版本错误太多，但是绝对不能客户提出一个错误就修改一个。因为做为一个系统，功能模块、功能点之间都是有关联的，修改一个错误可能会带出一堆新错误，这是最常见的现象，所以有经验的项目组都知道如何将错误控制在一定范围，如何将哪些错误放到下一个版本。B公司却恰恰这样做了，使得错误没完没了，而且他们修复错误的效率还很低，逼得着急的A公司也安排人加入了测试工作，这样又冒出了新的需求，项目越发结束不了了。这个过程中看不到B公司的“缺陷处理流程”，“需求变更控制流程”。

真是一步错，步步错，这个项目可吸取的教训太多了！