软件工厂、软件蓝领这样的术语在中国已经念叨了十余年了，除了北大青鸟、托普软件、重庆正大这样的软件学院还在沿着这个思路继续培养软件蓝领之外，真正做软件产品的公司，能做到将软件研发像制造业的流水线一样分工的有几个？没有！
几年前公司内也有人尝试软件分层研发模式：需求管理是一拨人，设计是一拨人，编码是另一拨人，测试当然还有一拨人。结果不了了之。
前些天看亚当斯密的《国富论》中关于劳动分工的阐述，茅塞顿开。亚当斯密说：“分工使得相同数量的劳动者能够完成比分工之前多得多的工作量，其原因有三：第一，劳动者的熟练程度因分工而提高；第二，工作之间因连接交换而损失的时间减少；第三，机械的发明为劳动提供了便利，简化了工作，劳动者的工作量随之极大提升。”而这，恰恰是软件工厂和软件蓝领热衷者的理论基础。
亚当斯密其实没有说错，因为亚当斯密关于劳动分工的所有论述都有一个明确的前提：制造业。而在亚当斯密生活的十八世纪，还没有出现软件这个产业。用在软件研发上，这三点理由有两点半都是不成立的！
第一，劳动者的熟练程度因分工而提高。如果是制造业，无疑这是正确的，因为你制造的对象是单一的，可重复的，基本无变化的，于是熟能生巧。软件研发却不是这样。世界上没有两个软件是一模一样的，一样的只有廉价的拷贝，研发过程却永远是唯一的。现代项目管理认为“项目”是一个组织为实现既定的目标，在一定的时间、人员和其它资源的约束条件下，所开展的一种有一定独特性的、一次性的工作。由于目标不单一、不可重复，就算将研发分层，各层所做工作也不可能单一和重复。就像软件项目的产出，都是独特的、唯一的软件产品。没有哪个组织哪个公司愿意花钱生产已经能从市场上找到并且满足需求的软件。至于模块化生产这样的理想，MDA这样的理论，在没有出现明确的大规模应用之前，都是浮云。
第二，工作之间因连接交换而损失的时间减少。这是“精益”管理（LEAN、JIT）中的要点之一，但还是只适用于制造业。软件研发是彻底的脑力劳动，“生产线”上的是代码，无形的代码，蕴含着无数逻辑、判断、需求关系、依赖关系的代码，你永远不知道上游会交给你个什么东西。通常情况下，软件工作之间的交换包括从需求到设计，从设计到编码，从编码到测试。试想一下完全分工研发，设计人员拿到需求说明书之后就能立即开始设计吗？不能，要首先消化、吸收和理解，要和需求人员反反复复沟通。这就是连接交换时间，无法减少。设计人员做出设计交给编码人员，编码人员能立即开始编码吗？不能，还是要先消化、吸收和理解，要和设计人员反反复复沟通。这也是连接交换时间，无法减少。同样的，测试人员如果拿到需求就开始测试，一定会出现很多漏测或误报。为什么无法减少这些消化、吸收和理解时间呢？根本原因还是跟上面一样：每个软件都是不一样的。Facebook够高效吧，因为他们人人都既做需求，又做设计，又做编码，还做测试（看这篇文章）。在软件研发行业，越细的分工，效率反而越低，因为连接交换时间反而因为分工的细化而加大。
第三，机械的发明为劳动提供了便利，简化了工作，劳动者的工作量随之极大提升。亚当斯密认为，正是因为分工让人们的注意力更专注于一个目标，才能产生更多的提高效率的方法。事实上对这点我最多同意一半。分工确实能让人更专注，但是否就因此能产生更多的提高效率的方法却因人而异。聪明人哪怕做一次也能找到更好的方法。安于现状的人一辈子就干一件事也不见得能有所创新。专注于一个目标可能造成思维更狭隘和局限，对各层次都了解也许能触类旁通、相得益彰。现在不都流行跨学科人才培养吗？从我们公司的十年创新历史看，创新多的总是那一小部分人，不论他们做什么。当然了，这也是个概率问题，不知道有没有专家做过更权威的统计，所以对这点我同意一半。
有人肯定会提到印度，软件外包、软件工厂的第一大国。不过你有没有听说过哪个著名软件是印度公司做的？哦对了，他们只做外包。那么有没有研究表明他们的效率就很高呢？我看绝大多数报道都只强调他们的规模大，效率嘛，不知道。
抛开效率问题，软件工厂、软件蓝领还是有用的，但也局限在严格执行CMMI之类软件工程规范的外包公司。但要发展软件产业，绝不能仅仅依靠软件外包，毕竟，软件外包是软件业的下游产业。
Sparkle in Spare 