只有系统真正用起来了，才可能及时发现问题和解决问题，问题发现得越早越容易解决，造成的损失也越小。

图1 SP项目的主要失误之处

系统终于上线了，作为项目负责人的我暗暗松了一口气，可是却无论如何也高兴不起来。为什么？为什么项目结束了，我的心情却愈发沉重；为什么已经竭尽全力了，用户却依然抱怨不休；为什么系统上线了，我却不敢说这是一个成功的项目。

成功离我们到底有多远？

SP项目是一个外包项目，需求由我们（发包方）提供，系统设计和代码开发由外包公司（承包方）提供，项目采用近岸开发和按工时付费的方式进行。

SP项目历时8个月，进入实施阶段后修改过至少3个版本，其开发过程可算是一波三折，尽管最后有惊无险，却也暴露出许多问题，比如：对外包项目的选择、对外包公司的筛选、对技术框架的选取、对项目整体的管控等。

SP项目在许多方面都存在着不足和失误，在很多问题的处理上还有可改进之处，应该成为其他项目的前车之鉴；此外，我们为这个项目付出的代价和得到的回报，较之最初的设想相去甚远。这些都令我们不得不在项目结束之后，转回头来仔细总结和反思。

项目选择造成被动

外包项目不同于内部开发和产品购买，在项目的选择和范围的确定上有必须要注意的问题。SP项目在最初的立项过程中忽视了这个问题，选择了一个业务流程不稳定、业务人员没有IT系统使用经验的项目来做外包，使得项目在后续过程中非常被动。

1. 业务流程不稳定

SP项目所涉及的业务一直以来都是很令人头疼的：业务流程复杂、业务人员众多、分工细而且杂，业务流程的各个环节散落在众多的业务人员当中，没有谁能说清楚整个流程的走向。

在项目立项之前，刚刚成立了一个新的部门来专门管理这块业务，所有流程都在重新整合，正是在流程的梳理和整合过程中，他们逐渐产生了对IT系统的强烈需求。

2. 业务人员没有IT系统使用经验

无论是新部门的管理者还是具体操作的业务员，都没有类似的IT系统使用经验，对IT系统可能给工作带来的变化感到惶恐和茫然，面对需求调研人员的问题显得不知所措。

因此，从项目选择开始，我们就已经把自己放在了一个十分不利的位置上，项目范围模糊，变更频繁，需求蔓延，成为日后令我们焦头烂额的罪魁。而在后来的开发过程中，我们对业务流程规范的缺乏关注和控制不力，也从另一方面助长了这些不利因素对项目的影响，使得需求一变再变，进度一拖再拖。

既选公司也选人

SP项目中的外包公司在业内的口碑很好，外包工程师的工作非常努力，但是因为项目经验较少，尤其缺乏制造企业信息化项目的经验，面对用户提出的关于流程设置、界面布局、错误提示等各方面的需求显得无所适从，甚至无法理解为什么用户会对一个输入框的摆放位置有那么多的意见。这使得开发人员与用户的想法存在差异，造成了很多额外的返工。

因此，在外包项目的招标过程中，除了应该注意外包公司是否具有相关领域的外包经验，还要特别注意对方是否能够在项目进行过程中提供最合适的人选，因为真正提供服务的是具体的开发工程师而非外包公司，无论公司的实力多强大，如果不能提供最合适的人选，一样不能保证项目的顺利进行。

框架选取—“吃螃蟹”

SP项目采用了微软的最新架构体系，该架构体系在此之前还没有类似项目的成功应用案例，我们因此成了吃螃蟹的人。

事实证明，螃蟹并不是那么容易吃的，还要自己的肠胃能够消化才行。因为是全新的架构，所以也谈不上什么经验，一切都要从头开始。外包工程师进场后的一个多月的时间都花在了熟悉新架构和新技术上，开发进展缓慢。而且，新的架构为了实现多系统整合、客户端自动更新、权限统一管理等目标，使得开发和调试变得复杂而且困难，代码可读性变差，在一定程度上也影响了开发的进度，并且给后来的维护工作埋下了隐患。

因此，在技术工具的选择上不能一味求新，在系统架构的设计上不能一味求全，要尽量避免“银弹”的攻击。SP项目在技术架构的选择上就吃了亏。

整体管控不力

SP项目的管理在实施阶段开始之后，慢慢变得失去了控制。变更越提越多，补丁越打越多，问题越改越多，业务人员开始失去信心，开发人员开始失去耐性，系统正式上线变得遥遥无期……原因何在？

1. 变更控制不力

由于业务负责人对流程整体情况的不了解和基层业务员对IT系统的不适应，致使很多当初出于管理目的提出的流程整合根本推行不下去，业务部门的负责人迫于无奈，只好提出需求变更；而项目组为了使系统能够顺利实施下去，也只好妥协，并为此付出很大代价。

事实上，项目组更多地应该从全局角度出发来考虑问题，面对汹涌而来的需求变更，我们应该冷静考虑：这个流程是否必要，是否一定要通过系统来实现，能否与其他流程合并处理，能为系统提供什么关键数据，是否为流程的关键控制点……通过回答这些问题，你会发现，那么复杂冗长的流程图原来可以这样简单！

2. 实施过程监控不力

SP项目的进度拖后，主要是在实施过程中造成的。由于业务部门刚刚组建，对基层业务员的管理不到位，使得用户试用系统的积极性不高，没有及时发现问题，在很长一段时间内没有问题反映上来。

项目实施过程中用户的参与非常重要，只有系统真正用起来了，才可能及时发现问题和解决问题，问题发现得越早越容易解决，造成的损失也越小。这是每个项目经理都应该注意到的问题。

尽管SP项目最终还是通过验收了，但我们不能因此而忽视这其中暴露出来的种种不足和失误，所谓“吃一堑，长一智”，只有正视问题，才能解决问题，才能避免问题的再次发生。

希望有了SP项目的前车之鉴，以后的项目可以离成功越来越近。