第二，我的关注点不在交付8点还是10点，我希望这个例子能够引发大家对于均衡生产的思考。

　　软件的需求和实现可以被细化，但它毕竟不是大头针，需求和实现间往往呈现出关联与依赖，换言之，局部效率的增加无法直接转换为整体效率的增加。而整体效率的优化往往依赖于均衡生产（参考表三），即消除生产的波峰（过度生产）和波谷（生产不足），避免任务时松时紧，松时生产力浪费（周一时专职测试人员），紧时加班加点，粗制滥造。

　　我倾向于认为亚当·斯密对劳动分工论述的假设是：需求稳定，简单生产。对于IT领域来讲，这些假设还成立么？

　　拧螺丝的卓别林

　　不难发现，对分工以及个体效率的迷信已经深刻的影响着IT领域。分工的端倪在招聘时就已经显现，即便对于差异不大的毕业生们，雇主也会根据其极有限的技能，用不同的标准进行测试（Java， .Net， PHP等），并在入职后将其冠以前端工程师，后端工程师，测试工程师，支持工程师等不同的头衔，甚至可能在其可见的职业生涯中专门负责某个文件的维护。

　　整体效率的优化要求IT团队消除技能壁垒，培养多面手，根据计划的的变动，弹性地调整任务，达到各角色和流程之间的平衡。对于IT企业来说，变化从招聘时就必须开始。找到拥有学习热情、学习能力、学习习惯的人变成了当务之急，员工是否掌握了某种算法、语言或者工具应当从准入条件降格为对于其学习能力和热情的一种（不是唯一一种）证明。

　　整体效率的优化要求员工必须持续学习、成长，兴趣无疑是成长的催化剂，然而丧失意义的工作却在不断扼杀人的兴趣。丹？艾瑞里在怪诞行为学里著述到：

　　劳动者与他自己的生产活动、劳动目标以及生产过程相分离。这就使工作成为非自发性的活动，因此劳动者就无法对劳动产生认同或者领略到劳动的意义，而缺少了意义，专业人员可能觉得自己好像电影《摩登时代》中查理·卓别林扮演的角色，一切都由工厂的齿轮控制，他们根本不会有全心全意工作的愿望 。

　　如果员工成长是必须的，那么，帮助员工认识到工作的全貌也是必须的。角色轮换是一个很好的解决方案。在项目内部通过角色互换，不限角色的结对工作，加强不同角色，不同模块间的知识传递，打破技术壁垒，帮助员工从不同视角理解项目，锻炼技能，进而增加团队均衡生产的能力。

　　在我看来，进行角色轮换的最大阻碍在于编程能力的普遍缺乏，大多数的测试、需求分析工作（鉴于大多数团队所处的地位，需求分析师实在言过其实，更精确的名字是需求整理师），迭代管理，简单的客户交流，学习曲线都非常低，任何成员都可以在师傅的带领下迅速掌握工作要点，然而编写程序却是个例外，即便对于基础良好的新人，在经验丰富的导师带领下，也需要2个月左右才可能写出比较体面的单元测试、较为面向对象的程序。在分工的体制下，用别的角色轮换开发人员几乎是个死局。

　　非常奇怪，IT领域如此的看重抽象能力和逻辑分析能力，可为佐证的是层出不穷的建模语言，模式，领域模型，架构。然而最能训练抽象能力和分析能力的一项活动，却仅仅有选择性的开展，这是不是意味着我们认为IT项目可以在大多数人无法（也没有能力）达成共识的情况下顺利展开并成功交付呢？在我看来，编写程序不仅仅是一项技能，一种思考方式，还承担着构造IT团队成员间共同经验区，提高交流效率的目的。

　　一个值得从其它行业借鉴的经验是首先展开基础素质培养，再进入领域培养专业素养，换言之，避免过早的分工，所有新人从编程开始职业生涯，在公司的体制层面促成每个新人都能经历力所能及的所有角色。在具有了一定的基本素质后，在员工对工作内容和自身兴趣有了充分的了解后，根据个人意愿进入领域发展专业技能，兴趣将成为员工成长的内在动力，而良好的基本素质将使员工有能力在专业岗位上施展自己的想法。

　　同时公司应当鼓励员工跨界工作，《应用Selenium和Ruby进行面向领域的Web测试》的作者是拥有卓越能力的开发人员，他曾经进行了相当长时间的测试工作，在其它人抱怨自动化界面测试难于维护时，他优秀的抽象能力、分析能力已经帮他提炼出测试模式，识别出缺陷，找到了优雅高效的工作方式并诞生了这篇优秀的文章。

　　丹·艾瑞所言于我心有戚戚焉。

　　知行合一

　　在过去9个月间我们在团队中进行了建设全功能团队的初步实践，在分享具体实践前，我希望下面的总结性数据能帮助你获得一些背景知识。

　　项目处理的是期货交易领域，使用的技术栈是C#， ASP.NET MVC。团队主要由八名开发人员以及两名测试人员组成（其中一名测试人员在项目中期加入），其中4位是毕业生，3位具备工作经验，但刚刚加入Thoughtworks，只有一位开发人员具备.Net开发经验。