本文是敏捷外包工程系列的第五篇。(专栏目录)
外包行业的问题及瓶颈分析
外包行业的所有研发问题,最终几乎都可以归结于报价管理问题,或者说其销售过程的问题造成了后续的研发问题。
整体上现在的外包企业大致有这样几种报价方法,几乎都存在相同的问题。下面就几种情况,从平衡计分卡的四个维度(收入,客户,内部流程,学习与成长)来分析其问题。之所以不用敏捷开发进行分析,是因为敏捷开发的视角高度不够,可以用来解决问题,但不能用来分析问题。
几种现在外包交易方式的分析
1. 包人头
就是把相关人员按人天报价,直接送给甲方阶段性使用。甲方节省了人员储备和人事管理问题,而乙方则可以“安全地”赚取差价。那存在什么问题呢?
财务
几乎没有“一夜暴富”的可能。我们无数次见到微型的团队日赚斗金(比如有一个只有几十人的手机游戏团队,现在的收入大约是每天100万美元),但包人头由于价格很透明,差价的附加值有限,连高利润都难以做到,更不用说一夜暴富了。
此外,外包公司由于单人的盈利很低,规模一般都比较大,最后造成人数庞大。这又导致了管理人员的增加,也就是“无法外包”的人员的增加,最终导致收入下降。
客户
客户可能会对派来的人更“忠诚”,而不是乙方。若能留下若干技术骨干,可以完全甩开乙方;若能找到更好的包人头的乙方,也可以甩掉之前的乙方。
比如,如果乙方想把之前提到的管理人员的费用加到报价里边,很可能导致甲方转而去寻找规模较小、价格更低的小型外包公司。
内部流程
“向管理要效益”是很多企业的方法,但在包人头的公司不行。实际上,甲方更像是“向管理要效益”,他们低价找来临时工,通过卓越的管理创造超额利润,而只需要支付有限的工资。
学习与成长
在包人头的公司,基本上没有这个过程。人员流动性导致最好不要自己投入培训成本,而是寻找现成的人员。
2. 工时报价
接到项目后,通过分析需求,推导出大致的工时,然后再用工时报价。
尽管和包人头看上去差别很大,但问题几乎一样。
财务
工时报价如果完全真实,那和包人头也没有什么区别。但如果做一些“手脚”,则能比包人头多出几种增加收入的方法,比如:使用比报价中更廉价的劳动力;使用比报价中少的工时;在1.0时报低价,在2.0时再高价捞回(俗称“钓鱼工程”)……由于实际销售的还是工作量,而非工作量的产物,所以技术先进、可复用的技术框架、更低的质量成本……都不能增加收入,节省的时间反而降低了项目价格。
实际上,很多外包企业也在提升技术先进性降低成本,但在报价后只能采用“使用比报价中少的工时”的方法从中受益。
客户
比包人头有很大改观,毕竟人员在自己手里,技术容易控制,客户不容易流失。
不过,尽管因此“留住客户”变得容易,但“获得用户”却依旧很难。
内部流程
比包人头而言,内部流程有很大改观。因为节省下来的时间可以通过“使用比报价中少的工时”来受益,虽然很难光明正大地进行,但至少是一种方法。
学习与成长
有改进但不大。
学习与成长能稳固地提升生产率(这里把质量作为生产率的一部分),但节省的时间无法直接转换为收入。
比如通过一年的努力,所有人的生产率提高了一倍;第二年,来了一个相同规模的项目,大家会如何?当然不会对外宣称只用一半时间即可完成,因为工作量少了价格也低了。
新风险
在工时报价中的风险是:若工时报低了,则客户很难在后期予以弥补;而在早期就准确估算出工时的可能性很小,在利润微薄的行业中,这是一个致命的问题。
下面的讨论主要集中在“工时报价”类型的外包开发,包人头类型更像人力资源管理而非软件研发管理。
交易方式对交付方式的影响
这里说明一下何为交易以及交付。
广义的交易包括甲方寻找合适的供应商,接触并获得信任,报价、谈判并签订合同,以及对交付物的验收和付款(可能是分阶段的)等环节。本文重点讨论报价过程和付款过程。
广义的交付方式很接近我们平时提到的“软件开发过程”,包括需求分析与管理、计划与跟踪、设计与开发、测试、验收(可以认为是CMMI2~3级的所有过程域);但应增加验收与付款的衔接过程,这个是传统开发所忽略的。
交易过程在很大程度上决定了交付过程,包括对需求、进度、质量的影响,也包括了开发模型的选择。
若工时是报价的基础,则甲方总是希望
压缩工时(而非成本本身,其差别日后会提到),工时压缩自然会
造成进度提前(即使甲方不要求,乙方也不能承受延期造成的额外工时),进而
导致质量下降(甲方和乙方都很难在早期意识到质量问题);在此过程中会不断
发生需求蔓延(这不仅仅是个技术问题,若成本由早期商定的工时确定而非实际交付的需求,那么为什么不多要一些需求呢?固定成本,可增加的需求,听着都像是自助餐的规则。)
上述问题,无论是瀑布开发,还是敏捷开发,如果不能对“工时报价”这种交易过程进行真正的改变,都很难对交付过程做彻底有效的改进。