大道至简后续章节
团队缺乏的不只是管理
开头写到：团队是至少以三个人为规模的。这有其合理性。为什么呢？首先一个人算不得团队，那是个体。两个人则互相支撑，古文中“从”字是二人互立，就是这个意思。然而二人互立并不算团队，因为没有监督。三个人便可以构成团队，这样便有了团队的一些基本特性：主从、监督和责任。
“言人三为众，虽难尽继，取其功尤高者一人继之，於名为众矣。”在一个团队中功劳最大的就是团队中的领导者吗？并不是，领导不一定功劳最大，但他一定管理能力最强，可以联合其他队友共同完成，他一定是承担责任的那个人。就像刘邦，文不如张良，武不如韩信，但他还是成为了领导者。而做一个好的管理者，需要的是顾全大局，合理的分配成员的工作，使他们合理地完成某项任务。
流于形式的沟通
流于形式的沟通，可能是使得你的项目被不断推翻和不断延迟的最直接原因。“我们总是要先接触客户的，是的，如果不这样，我们将无法确知要做什么”。但与客户沟通时，怎样才是最有效的沟通方式，将自己正在做的工作用客户能够听的懂的语言来描述；不能要求用户会c语言，当然也不能要求他们会uml图，高效的沟通方式在于两边都能听得懂，而不是只流于形式。专业术语的堆砌。
失败的过程也是过程
很多人把问题的本质给忘掉了。从最开始，从我们编程开始，我们的目的就是实现一个东西。无论这个东西是小到一个称手的工具，还是一个大到千万的工程，我们的目标，都是要“实现”它。工程只是一种实现的途径。最初做开发的前辈们，不用什么工程或者过程，也一样编出了程序，也一样解决了问题，也一样实现了目的。而现如今，我们讲工程了，讲过程了，讲方法了，却什么都再也做不出来了。不奇怪么？
工程被当成了借口，掩盖了我们做事的真正目的：“实现”。因此，我们在一个项目中常常听到说“工程要这样做”，或者“工程要那样做”，而绝少听到“项目要求这样做”或者“客户的本意是那样的”。这样的结果是：我们做完了工程(的每一个过程)，却没有完成项目(的每一个“实现目标”)。为工程而工程的人，都迷失在项目中了。就象开发人员迷失在一个技术的细节上一样。专注于 RUP 或者 RAD之间的区别的人，可以把每一个过程的流程图都画出来，却也被这每一个流程给捆绑得死死的，再也没有挣扎一下的力气。
不要只拘泥于形式，不忘本意（解决问题）才是最重要的。