通过软件项目外包的形式获得令人满意的产品并非易事，想想当初为何美国国防部要求卡内基梅隆大学的软件工程研究所（SEI）制定现在广为人知的CMM就明白了。在此，我想就我的工作体会谈一谈软件项目外包之路为何如此坎坷。

首先要明白的一点是，软件外包项目承包商（后面简称为“承包商”）与雇主之间的关系更多的是博奕，而非真正意义上的合作，因为两者之间存在利益冲突。雇主为了确保外包项目获得成功，必然会为承包商制定严格的成功评价标准，比如缺陷数不能大于多少，等等。承包商为了达到雇主所制定的成功评价标准，必然想法设法保证评价标准的稳定。要做到这一点，这就需要雇主做好需求管理 — 提供恰当、稳定的需求，然而即使雇主拥有经验丰富的架构师要做到这一点并非易事，最终结果就是很容易因为需求的不确定性而出现双方扯皮，从而影响了开发效率。

造成承包商与雇主之间成为博奕关系的另一个原因与项目开发时间的估算有关。@Thinker姜志辉在MPD的演讲中指出，“估计项目开发时间的的目的是为了适应变化，而非评估本身有多精确”，他还让与会者通过做硬币游戏的方式深刻理解这一观点。尽管我本人完全认同这一观点，但该观点却无法在软件外包项目上获得认可而实践。理由很简单，雇主是以软件的完成时间支付外包费用的 — 软件开发所花费的时间越长，雇主所支付的报酬就越多。正因为做到精确评估项目所需开发周期不可能，这就使得开发时间的估算成为了承包商与雇主争夺的“制高点”。

在“制高点”的争夺战中，会形成一种有趣的动态变化过程。如果承包商评估的时间存在富裕（这是她生存使然的行为），一旦被雇主感知（后面我们会谈雇主是如何感知的），雇主就会在项目的下一阶段通过某种方式的施压而压缩评估时间。承包商一旦接受，很有可能在开发的过程中发现时间不够，就会采用牺牲长远质量的做法，达到在承诺的时间内“完成”项目，承包商所采取的短视行为让项目欠下了技术债。由于技术债的存在，承包商在下一个阶段中会向雇主施压获取更多的估算时间，雇主由于产品面市方面的压力，即使觉得不合理也会答应承包商的要求（更换承包商会拉长项目周期）。这种“拉锯战”的最终结果往往不会是产品质量稳步上升（功能数量确实会稳步上升），反而是承包商在过程中不断地累积更多的技术债。最终雇主会发现，她花钱为自己制造了壁垒 — 项目只有该承包商可做，否则就得承担更大的损失。

前面还留下了一问题，即雇主是如何感知评估时间是否过于富裕的呢？有两种途径。最“菜”的方式是通过项目阶段性“生产”出的代码行。之所以说这种方法“菜”，是因为这会诱导承包商采用copy-paste的方法“生产”出大量的冗余代码。另一种方式是评估软件的设计质量（注意，不是评估缺陷数量）。很不幸，真正懂软件设计的人其实很少，这一点我在《软件开发：个人与团队是永远的核心》中通过“能力金字塔”已指出。就我在Motorola的经历来看，与承包商打交道的架构师正是因为不懂软件设计而使得不能及时地发现项目中存在的风险（很多架构师虽有其名，但由于长时间脱离代码，最终蜕变成对软件设计质量毫无鉴别能力）。我曾经就某外包项目的软件设计质量对与承包商接口的架构师进言，他当时很气愤地质疑我“show me evidence”。戏据性的是，该架构师最后因为项目质量问题而调离了岗位，最后项目从承包商手中收回，并由Motorola的美国与中国团队进行了大规模的重新设计。

软件项目外包的困境并非完全来自承包商与雇主之间，还来自承包商的内部。承包商通常不只为一个雇主服务，也很有可能承接多个项目。由于各项目存在不同的优先级，从而使得各项目间存在公司资源竞争。一旦某项目因为无法从公司内部获取好的人才，这势必影响项目的进展和质量。

另外，由于承包商并不拥有产品，对于他们来说只能是做一单是一单，谈不上对所做的产品进行长期规划，这在很大程度上会影响软件人才的培养进程。在这类企业工作的工程师通常不会有很强的归属感，也不容易激发他们的学习兴趣，职场晋升的机会也相对少。如果你怀疑这一点，去了解一下大连的外包产业就知道了，据说大连的一些外包商已经在做相应的转型了。

至此我们不难得出结论，要真正使外包项目成功，不光要承包商具备很强的专业性（不是指通过CMM5认证什么的，如果你还相信CMM能带来成功，多少有点幼稚。我所指的专业性在《软件开发：个人与团队是永远的核心》中有些阐述），还要求雇主对项目质量具备很强的控制能力（主要是架构师的能力。什么？靠项目经理？找死！），否则失败是早晚的事。由于人才的稀缺性，要满足这两个条件中的一个已不是易事，更别说两个。