《圣经》上所提的原罪，指的是夏娃不听神的警告，被蛇诱惑偷吃了智慧树上的苹果。自此，人性中有了恶，世代忍受风吹雨淋，生老病死，以及各种丑恶事物的折磨。
19世纪70年代，随着PC的普及，一个生机勃勃的行业——软件业诞生了（尽管之前的20多年也有人在编写软件，但软件只是大型机的附属品或极少数人的爱好，无法称之为行业）。在最初的欣欣向荣后不久，80年代出现了广为人知的软件危机。我没有用“爆发”这个词是因为它并非是一个突然出现的事件，只是人们认识到随着软件规模及应用领域的不断扩大，很多的大型项目彻底失败了，超出预算及计划时间的更是比比皆是。与其他行业，比如制造业和建筑业相比，反差是极其巨大的。于是大家开始思考，如何解决软件项目的管理问题，“软件工程”这个学科即由此而来。
在软件业出现之前和初期，世界上到处是以生产制造为主的工厂，大规模批量生产和全面质量管理的理念深入人心。在一些大型企业中，计划与质量的控制手段堪称完美。
软件业的管理人员不可避免地爱上了这个 “工厂”模型。他们从工厂模型淘出的宝贝之一是：“一次就做对总是最省的”。瀑布模型应运而生，以生产线的方式将软件开发分为需求、设计、编码及测试等阶段，严格计划和控制每个阶段的产出质量，以求得最终产品的高质量。
第二个从工厂模型淘出的宝贝是：“基于统计的流程控制”，以解决计划准确性方面的问题。在软件开发过程中设置一系列的检查点，根据以往项目数据设计每个检查点的状态数据和误差范围。一旦超限，一个因果分析的程序将启动，以制定及时的行动方案将项目拉回正常轨道。针对操作中发现的典型问题和业务特性，具体的流程、检查点及衡量标准将会被不断更改和优化，此之谓“连续改进”。目前流行的6σ理论是一个系统化的流程改进方法。
工厂模型看起来和牛顿定律一样完美，然而，和牛顿定律一样，并不适用于所有的情况。牛顿定律只在速度远远小于光速时准确，工厂模型只在所需智力水平较低的工作中有效。即使在传统工厂内部，工厂模型也不适合用于管理营销策划、研发等方面的工作，因为那是一个智慧与创新的世界。
如果硬是要用工厂模型去管理智力活动会怎么样？智力水平将会降低。人们将会选择保守的方法，尽量沿用旧的东西，给出头痛医头、脚痛医脚的产品。长此以往，竞争力的丧失是不可避免的。
是什么从根本上导致了工厂模型在高智力产品生产中的效力丧失？需求规格的变化。
在传统的生产制造性活动中，最终产品的样式是非常明确的，中途改变产品的设计是极少发生的，可能对上下游发生严重的影响，甚至停产。因此人们可以从容布置生产的各个环节，使其傻瓜化，以换取可管理性。此之谓工艺设计。
而在研究开发性的活动中，只有目标是基本清晰的，最终产品的样式是待解决问题的一部分。随着对问题领域的探索和理解，最终方案不可能保持稳定（除非人们在做的是一个比较简单的东西，那就不该称之为研究开发）。因此，基于工厂模型的上下游工序安排是无效的，在下游活动中发现上游工作的问题然后返回重做是非常正常的，仅仅是一次失败的探索而已。这些探索对于最后的成功是非常有益的，而工厂模型将其视为质量事故。没有人愿意对质量事故负责，因此大家倾向于快速找到一个60分的方案作为产品样式，在其后的流程中以其为依据，对存在的潜在问题视而不见。在管理层看来，项目是成功的！有关质量、成本、工期的数据越来越好！工厂模型是有效的！可是用户不是傻的，他们会比较产品的可用性、维护及运营成本。60分的产品及其企业，必将远离人们的视线。
让我们回到软件业。就项目的数量而言，需求明确且容易把握的居多，因此基于工厂模型的管理大致是不错的。我们可以看到，在印度等以外包为主的企业里，可以说取得了巨大的成功。
然而，少数的研究型项目，却是软件企业的生命所在。这些项目的产品通常定位于提供某一领域的解决方案，是本企业行业经验与技术的积累，其他面向具体客户的项目很多都是在此之上的再开发。没有这类核心资产型产品的开发，一个企业在每个订单的成本、交付周期和质量方面将是缺乏竞争力的。即使在外包业，从零开始的订单项目也是越来越少了。
问题是，工厂模型也被运用到了研究型项目的管理上。其结果就是前面讨论过的：智力水平的降低。最终的产品只是及格而已，针对每个客户的个性化再开发成了从头再来。
那么，如何管理研究型的项目？
90年代以来，人们作了很多探索。基于增量迭代的敏捷方法论是有价值的一种进展，具体的开发流程有好多种，但思路是相似的：根据业务的重要程度及技术的实现风险，由高到底将项目周期划分为多个从1周到一个半月的迭代。每个迭代只实现一部分特定的需求，产品完成后由项目各方相关人员加以评估，反馈意见在后续迭代加以考虑。只有当前迭代具有比较详尽的计划，其他迭代只有宏观的规划，将会在进入时调整。项目的需求将被至少划分成必须及可选两个部分，一部分可选需求在项目即将到期时将被规划到下个版本或干脆砍掉。敏捷方法的原理在于：尽早解决有风险的问题，通过迭代快速地交付有价值的功能，不断接受反馈，将需求的调整消化到整个项目周期里，并坚决摒弃“花边”需求。
另一方面，对于软件项目的衡量应该着重于其业务价值、对业务变更的适应性、维护能力和运营成本等方面，预测这些方面的数据作为项目是否成功的考量之一，而不是仅仅关注时间和预算。
这样说说固然简单，在一个组织中具体实行却面临着很大的困难。软件业是一个年轻的行业，很多的管理人员来自传统行业，或者深受传统管理思想的影响，工厂模型的观念是根深蒂固的。而且，工厂模型并非一无是处，对多数的项目，是合适的。加之，有专家也认为，软件业与其他行业没有不同，只是太不成熟。
从客户的方面来看，很多是传统行业的企业，只有看见了传统企业常见的无微不至的计划并执行完美，才感觉到安全。客户的压力不可避免地转移到开发企业，让其按照工厂模型匍匐前行，尽管结果对于双方并不真的好。
在以工厂模型管理的软件企业内部，若非十分强势的改革者将卷入巨大的政治漩涡。部门的划分、企业的文化通常与项目生命周期紧紧相连，个人的能力与利益更是早已与旧有的衡量标准协调一致。如何能说改就改的？可能改革的效力还没见到，改革者已经去见“梁启超”了。软件人员并不傻，业界的方向他们是知道的，之所以装傻，是不想找死。
综上所述，笔者的拙见应该已经很清晰了。根据一个软件项目的具体特性来决定采取工厂模型或敏捷模型进行管理，通过研究型项目积累软件核心资产，注重客户业务价值及可用性的衡量是软件企业应当采取的手段。
我们可以从成功的软件公司看到，他们是多么聪明地看到了这一点。
微软的项目管理采用MSF框架，虽然与敏捷方法有所区别，但精髓是相同的。很多人嘲笑他们的产品动不动就延期，管理得不好。但实际上他们的产品非常强调竞争力，即使抛开垄断的因素单存从功能方面考察，大多数产品是无愧业界领先这一称谓的。在核心资产的积累方面，整个Office软件的基础代码很大部分是相同的，这意味着象Word, Excel这样的单个产品节省了很大的工作量。而从很早的时候，Excel的Apple版和Windows版就开始使用统一的源代码文件，只是编译选项有差别。
Google走的更远，它让高级研发人员随便去做自己喜欢的工作，有了雏形后由大家讨论是否继续推广。这种宽松的管理方式无疑是对研究型项目生产力的一种解放，拧开了创新的水龙头。
知道Java和Linux是如何开发出来的吗？研究一下吧，希望我们的结论一致。
如果不是工厂模型如此强势，以至核心资产的开发难以奏效，市场上将不至于这么多垃圾产品。模型错了，以后做什么都解决不了根本问题。因此，作者将工厂模型归为软件工程之原罪。
