标签：
大道至简第三章读后感
本章节主要讲的是团队的合作与分工三个或者三个以上就能算得上是一个团队了。但还必须具备一些基本特征:主从，监督和责任。
这也就让我们联想到了我们得一个程序的深度剖析，我们是不是可以把一个程序也对他进行分工？当然可以，对于任何一个稍微复杂一点的程序，我们都是可以对它进行拆分的，这样不仅有利于编译，更有利于后期的查漏与改进。在编译程序之前，我们应该像一个管理者一样，首先要对这个程序进行分析，确定对它的分块，第一部分负责什么，第二部分负责什么等等。另外，我们从本章节中也不难发现，书中提到了IOS质量体系认证。某公司就是利用该认证体系来规范自己的员工和生产。这就好比我们在编译程序时对程序的某些代码进行注释。注释越多越利于我们对程序的理解和对错误地查找。
在搞管理的时候，我们切记，制度不可动摇这就好比我们所使用的编译软件，软件自有他的语法规则，我们只能去遵守。在所有的准备工作都准备充分后，我们就可以着手进行程序的编译了。与此同时，作为一位管理者（程序员）应当看一下你的团队里有没有“盲点”这就类似我们程序中的无用代码，应当予以删除。同时应当反思，why？
此篇文章，不仅仅对我们在日后编译程序有很大的帮助，同时也给我们很多其他方面的启迪，团队真的需要管理吗？开发团队其实根本不需要管理者。温伯格讲到，对于一个并非由你亲自雇佣的团队成员你的选择有三个：1.与成员面谈 2.解聘他们 3.你放弃这个职位这就告诉我们在对一个新程序或者一个你不熟悉的程序进行调试的时候应当弄清楚他代码的含义和作用，而不是有错误时就无脑的删除要不你就放弃调试，交给其他有耐心或有能力的人。嗯有时候就像蚂蚁一样，秉性难移，要想改变一个人的习惯都很难何况是要改变一个团队？！因此，我们要去适应程序语言的运行和编译规则，而不是按照我们的想法，异想天开。
最后作者提到了“增值税发票”，为此我还特地百度一下。我对它的理解是，这东西就和当今的豆腐渣工程一样，一层一层的“转让”，但也不完全一样它还含有着一种类似“嫁祸”的感觉，都是向对方索要增值税，一层一层索要。有种推卸责任的感觉。因此，管理者不能像这个“增值税发票”一样推卸责任。管理者应该做好明确分工而不是弹性分工。而对于末尾那句“如果所有人都在思考’增值税发票‘，那么你的组织机构将立即溃散”仍不是比较理解。
末尾对管理者有了更为通俗易懂的理解，管理者不是所谓的伯乐。你身上更多的是责任与担当。
标签：
原文地址：http://www.cnblogs.com/ykxstn/p/4887092.html
