已经学习了《大道至简》两章，我们了解了编程的本质和“懒人”造就了方法。书中没有提供给我们编程的技巧，捷径，而是从别的方面为我们讲解了编程的精义。第三章就为我们引入了“团队”这个概念。
我们一个人的时候是个体，两个人的时候大家互相依赖，互相支撑即二人互立，这也不是团队，当三个人的时候就是团队了，而且有了团队的一些基本特性：主从、监督和责任。一个人的时候可以通过自身努力取得成功，两个人的时候也可以互相帮助、依赖获得成功。但是三个人的时候就要选一个领导者来管理这个团队了，选择一个有领导能力的，功劳大的来担任这个角色。而担任管理者角色的这个人最起码要做到的就是能够承担责任，这是一个管理者最基本的素质。书中借李离伏剑的故事为我们讲述了这个道理“自己该承担的责任不可以推卸给别人”。所以想要做一个领导者除了有领导能力、有功劳最重要的还要有承担责任的勇气。
但是接到一个软件工程的时候，预期的工期不总是可以完成的，这可能无关乎项目经理的能力，或者团队的工作能力，可能在一开始就估计错了，所以项目经理往往在开始就承担了犯错的风险，这跟他们的经验有关；那这个时候项目经理虽然有责任，但他们却是可原谅的，因为他们需要时间来变得成熟，变得有经验。
书中通过ISO质量体系的教训教给我们又一个道理，先确定团队模式，才能寻求相应的统治制度，并且才能把这样的制度实施在团队之上。有人把这次的失误归于体制的问题，但这并不是十分正确的。“体制”有体有制，只是把制度分发给每个员工，是绝对不能成事的。所以在转型期，第一要务是解决“体”的问题，也就是“组织机构建设”的问题。没有确定的组织机构，当然也不能指望统治制度合乎人情了。
总之，在组织模式确定的同时，相应的制度也应该随之建立。先做制度才是明智的。这样就有办法来维持你的组织模式，监督员工，惩戒员工。而对于一个已经规范管理、体制健全的公司，不容许员工反错是没什么错的，只要有制度有法则在先，有公平性的制度在先。制度是不可以讲情面的，如果有一次网开一面，那就有可能规矩变成了虚设，被公司员工作为笑柄，没有任何威慑力可谈，那这个制度也就离崩溃不远了。这个时候重要的就是制度的修订和补制了。所以毁掉制度的往往是统治者而不是员工，所以在制度面前既要做到“人性化”，又做得到“公平性”，统治者才会待得更长久吧。
在有了制度又有了可以编程的员工的时候，很多人就会说“那我们就开始吧”，这就是操之过急的结果了。因为还有直观重要的一点需要上级人员来做，那就是角色的分工和定位，这样就不会出现那些不知道做什么的人。作为一个管理者，不是要去管束开发团队，而是团队协作，首先跟随他们，找到他们的规律最后做一些有意义的改变，这才是王道。
作为一个项目负责人，只需观察他们，而不是加入他们，观察之后弹性分工，将效率提高到最大。