敏捷外包工程之五：报价管理（一）

本文是敏捷外包工程系列的第五篇。（专栏目录）

外包行业的问题及瓶颈分析

外包行业的所有研发问题，最终几乎都可以归结于报价管理问题，或者说其销售过程的问题造成了后续的研发问题。

整体上现在的外包企业大致有这样几种报价方法，几乎都存在相同的问题。下面就几种情况，从平衡计分卡的四个维度（收入，客户，内部流程，学习与成长）来分析其问题。之所以不用敏捷开发进行分析，是因为敏捷开发的视角高度不够，可以用来解决问题，但不能用来分析问题。

几种现在外包交易方式的分析

1. 包人头

就是把相关人员按人天报价，直接送给甲方阶段性使用。甲方节省了人员储备和人事管理问题，而乙方则可以“安全地”赚取差价。那存在什么问题呢？

财务

几乎没有“一夜暴富”的可能。我们无数次见到微型的团队日赚斗金（比如有一个只有几十人的手机游戏团队，现在的收入大约是每天100万美元），但包人头由于价格很透明，差价的附加值有限，连高利润都难以做到，更不用说一夜暴富了。

此外，外包公司由于单人的盈利很低，规模一般都比较大，最后造成人数庞大。这又导致了管理人员的增加，也就是“无法外包”的人员的增加，最终导致收入下降。

客户

客户可能会对派来的人更“忠诚”，而不是乙方。若能留下若干技术骨干，可以完全甩开乙方；若能找到更好的包人头的乙方，也可以甩掉之前的乙方。

比如，如果乙方想把之前提到的管理人员的费用加到报价里边，很可能导致甲方转而去寻找规模较小、价格更低的小型外包公司。

内部流程

“向管理要效益”是很多企业的方法，但在包人头的公司不行。实际上，甲方更像是“向管理要效益”，他们低价找来临时工，通过卓越的管理创造超额利润，而只需要支付有限的工资。

学习与成长

在包人头的公司，基本上没有这个过程。人员流动性导致最好不要自己投入培训成本，而是寻找现成的人员。

2. 工时报价

接到项目后，通过分析需求，推导出大致的工时，然后再用工时报价。

尽管和包人头看上去差别很大，但问题几乎一样。

财务

工时报价如果完全真实，那和包人头也没有什么区别。但如果做一些“手脚”，则能比包人头多出几种增加收入的方法，比如：使用比报价中更廉价的劳动力；使用比报价中少的工时；在1.0时报低价，在2.0时再高价捞回（俗称“钓鱼工程”）……由于实际销售的还是工作量，而非工作量的产物，所以技术先进、可复用的技术框架、更低的质量成本……都不能增加收入，节省的时间反而降低了项目价格。

实际上，很多外包企业也在提升技术先进性降低成本，但在报价后只能采用“使用比报价中少的工时”的方法从中受益。

客户

比包人头有很大改观，毕竟人员在自己手里，技术容易控制，客户不容易流失。

不过，尽管因此“留住客户”变得容易，但“获得用户”却依旧很难。

内部流程

比包人头而言，内部流程有很大改观。因为节省下来的时间可以通过“使用比报价中少的工时”来受益，虽然很难光明正大地进行，但至少是一种方法。

学习与成长

有改进但不大。

学习与成长能稳固地提升生产率（这里把质量作为生产率的一部分），但节省的时间无法直接转换为收入。

比如通过一年的努力，所有人的生产率提高了一倍；第二年，来了一个相同规模的项目，大家会如何？当然不会对外宣称只用一半时间即可完成，因为工作量少了价格也低了。

新风险

在工时报价中的风险是：若工时报低了，则客户很难在后期予以弥补；而在早期就准确估算出工时的可能性很小，在利润微薄的行业中，这是一个致命的问题。

下面的讨论主要集中在“工时报价”类型的外包开发，包人头类型更像人力资源管理而非软件研发管理。

交易方式对交付方式的影响

这里说明一下何为交易以及交付。

广义的交易包括甲方寻找合适的供应商，接触并获得信任，报价、谈判并签订合同，以及对交付物的验收和付款（可能是分阶段的）等环节。本文重点讨论报价过程和付款过程。

广义的交付方式很接近我们平时提到的“软件开发过程”，包括需求分析与管理、计划与跟踪、设计与开发、测试、验收（可以认为是CMMI2～3级的所有过程域）；但应增加验收与付款的衔接过程，这个是传统开发所忽略的。

交易过程在很大程度上决定了交付过程，包括对需求、进度、质量的影响，也包括了开发模型的选择。

若工时是报价的基础，则甲方总是希望压缩工时（而非成本本身，其差别日后会提到），工时压缩自然会造成进度提前（即使甲方不要求，乙方也不能承受延期造成的额外工时），进而导致质量下降（甲方和乙方都很难在早期意识到质量问题）；在此过程中会不断发生需求蔓延（这不仅仅是个技术问题，若成本由早期商定的工时确定而非实际交付的需求，那么为什么不多要一些需求呢？固定成本，可增加的需求，听着都像是自助餐的规则。）

上述问题，无论是瀑布开发，还是敏捷开发，如果不能对“工时报价”这种交易过程进行真正的改变，都很难对交付过程做彻底有效的改进。