很抱歉这么久才有第4篇，希望还有朋友记得本文。欢迎大家提出意见。
原本预计写7个主题，但是在完成的过程中合并了几个主题，因此下一篇将是最后一篇，多谢关注。谢谢。
4. 管理与人-微观
在上一篇中我们探讨了管理和人其中一个方面，即从宏观的角度来说，对于目前公司和高层管理者在日常管理中的一些误区进行了讨论。我想我们可以同意，在日常的管理中，存在着相当多的地方是需要改进的。
但是，我想没有人会认为当前中国软件企业中的种种问题就纯粹是由于上层的管理不善造成的，作为问题的另一面，我们每一个开发人员，每一个项目经理和每一个部门经理，对于我们在日常工作中的工作方式，工作方法以及工作态度和工作意识，也都存在着相当的问题。下面，我就想和大家探讨一下管理和人的另一个方面：每个人的微观行为。
当然，在我短短的职业生涯中，所见过的，听过的肯定极为有限，曾经一起工作过的同事们也并不具备广泛的代表性。同时，既然是反思，自然会很少谈到优点，而并非我忽视了中国的软件开发人员身上所蕴含的优秀品质。因此，如果有什么说错的地方或是以偏概全了，还请大家不吝批评指正。
让我们首先从几乎我们每个人都经历过的，也是我们最有感情的角色，一个普通开发人员说起吧。
开门见山。第一，在程序员群体当中，有相当部分的程序员，其技术水平相当之低。我并非信口开河，而是根据我在实际工作中所见到情景才这么说的。
这样的程序员，其首要的表现就是不爱学习，得过且过。所谓的不爱学习，并不是说他真的不学习，不看书，而是说他缺乏一种真正学习计算机技术的激情，缺乏上进心。
由于我们国家大学计算机教育的问题，基本上我们在开始参与实际的开发工作时，很多具体应用层面的东西，都需要自己重新进行学习。在学习的时候，很多人就只是浅尝辄止，不求甚解，却从来不试图有意识的提高自己的水平。就以C++语言为例，就我的观点而言，一个没有通读过《C++ Primer》或《The C++ Programming Language》，没有精读过《Effective C++》的程序员，不会是一个合格的C++程序员（别误会，我不是说这就够了，这只是必要条件，不是充分条件）。而在实践中，我见过不只一个程序员，本来当年就由于历史的原因，只掌握了C++语法而不是C++语言，却根本连《C++ Primer》和《The C++ Programming Language》是什么都不知道。
对于这样的程序员，我们怎么能够期待他们开发出优秀的软件？又怎么能够宣称中国的软件开发人员水平都很高？
同时，由于这样程序员的存在，降低了中国程序员的雇主们对于中国程序员的整体评价。在大多数时候，对于新招聘的程序员，管理者暂时是不能够给予充分信任，一开始只会交给比较简单的工作以考察其水平。对于程序员来说，这妨碍了雇主对于自己工作能力的认识，也因此妨碍了可能的升迁；对于管理者来说，则浪费了资源，降低了效率。然而，因为这样做比选择一开始就信任新程序员却失败付出的代价要小，所以我们当中很多优秀而勤奋的程序员，在进入一家新的公司的时候，都不得不在相当长时间内重复地做对自己而言太过简单的工作。
因此，我想说的是，每个人都想自己的生活过得越来越好，作为一个普通的程序员来说，所能走的道路就只有一条：不断提高自己的技术水平。这样，一方面，虽然生活水平不一定能够与技术水平一起同步提高，但是终究比混日子更有可能过上自己喜欢的生活；另一方面，所有软件开发人员整体水平的提高有赖于我们每个人技术水平的提高，而整体技术水平的提高，虽然我不是学经济的，但是我认为，是有助于整体工资待遇水平的提高的。因此，请努力学习，不断提高自己的技术水平，为了你自己，也为了所有的程序员。
第二，有相当部分的程序员，主要以从事外包工作的开发人员为主，除了工作需要的之外，不掌握任何额外的知识，也没有学习额外知识的愿望。不过坦白地说，这到不能全怪程序员。一般能够稳定的从事外包工作的程序员，待遇还是相当不错的，而很多时候，外方的要求（我只做过日本软件外包，欢迎做欧美外包的同志补充）也并非是技术上的。同样因为外方要求的原因，就算你掌握了很新很好的技术，有了很好的想法，在实际工作中也很难得到应用。只有外方要求的时候，才会学习和实践新的技术。因此长此以往，渐渐地就只是简单的满足外方的要求，虽然有些人能够因此得以在一项技术上达到很深的境界，但是就总体来说，这样的程序员们，因为并不需要，所以实际的对于开发语言，开发工具和新技术的掌握水平，往往不高。这么说也许有点过分，但是很多我以前的同事和朋友，的确正是处在这样的状态之中。
以上所说的程序员们其实一定不包括CSDN上我这篇文档的读者。常上CSDN的朋友，是不会像他们一样没有上进心的。但是，很遗憾，我认为，在绝大多数这样的朋友身上，都存在着一个很大的误区。这也是我第三点想说的。
第三，我们一般总是喜欢钻研具体而实际的东西，比如掌握一种编程语言各种特性，得心应手的应用一种开发工具，学习一项具体的技术，等等。我们中国人勤劳而刻苦，所以在具体的钻研过程中，是不会输给任何民族的。因此我们经常可以见到在某一个语言，某一个工具或是某一项技术上，已经达到相当高度的高手。
然而，这是远远不够的。有相当多的朋友，在钻研技术的过程中，陷入了只见树木，不见森林的窘境：在对于具体语言和工具的应用当中，游刃有余，却缺乏对于软件开发科学整体的了解。
举几个例子。
不记得那一期《程序员》杂志上了，提到一次测试当中，被一个大学生发现的bug，邮件发送软件，如果不写发件人地址就点击发送，会导致死机。我个人在实际工作当中，也见过类似的例子。导致这样的bug，绝对不会是因为开发者对于语言或者开发工具不够熟练导致的，而是不掌握软件开发的科学。任何一个软件，都应该能够保证其内部的自我完整性，必须是自成体系的。即必须保证整个软件运行过程中的信息和数据的流动，都是完备的，得到处理和相应的。像本例中的bug，很明显，软件在开发过程中忽略了某个数据的处理，不能够满足内部自我完整的要求。而这种对于内部自我完整性的意识，不是通过钻研语言、工具或是技术能够得来的，并通过有意识的学习和时间才能够得到。
再比如，一个我实际工作中的例子，一个软件，负责从数据库中取出数据输出给用户，用户要求输出时对原始数据进行一定的格式转换，如数字转换成文本。此时正确的做法应当是，从数据库中原封不动的取出原始数据，自行根据要求进行格式转换，然后输出。然而，负责的程序员却选择了将数据转换交给数据库来做，不管原始数据是什么格式，要求数据库将数据按指定格式输出，然后直接输出给用户。先不说两种做法在维护上的好坏（得到原始数据之后可以适应各种需要，否则的话如果需要的不是格式转换了，程序要重写了），从根本上讲，作为一个从数据库中取出数据的程序，保证数据的纯洁性是自然而然的要求，有了原始数据之后在怎么做都是在掌握之中的，而你根本无法确定数据库究竟会如何对数据进行转换。同样，如果没有有意识的学习和实践，就算C++语言掌握的再好，数据库学的再精，也不能算是一个好的程序员。
就是类似这样一个一个的问题，在实际工作当中，很难得见到真正除了语言，开发工具之外，还能从整体上考虑和把握软件的整体架构和完整性的程序员。
因此，我认为，在实际工作和学习中，不但要注重深度，还要注重广度和对于整体架构的把握和感觉。对于这方面，我自己也没有什么好的经验，欢迎大家补充。
第四，三条腿的蛤蟆好找，虚心的程序员可比没bug的程序难找。这一点相信大家都和我一样深有体会。每次开会都吵的天昏地暗，程序员特别难以在技术分歧上达成一致。并且，我相信我们每个人都会有过这样的经验：明明对方程序中存在着一个很不合理的地方，对方却怎么都不肯听取自己的意见；或者自己的程序明明写得好好的，却偏偏有人无中生有，非说什么地方有问题。
就我所见到的程序员们，绝大多数都相当自负，很难听从别人的意见，并且从刚毕业不足一年的小菜鸟到若干年资格的前辈，莫不如是。因此，在实际工作中，发生种种的矛盾冲突也就是自然而然的了。我认为，我们很多人，都缺乏对于他人的尊重以及妥协的意识。
先说尊重。很难让一个程序员真心实意的承认自己比某个别的程序员水平低，在此基础上，自然也就很难听从一个水平不如自己的人的意见。而实际上，计算机技术发展一日千里，我们每个人都可能至少在某些方面落后。不论对方是资历和经验都比你丰富的老手（你往往觉得他们观念落后），还是刚入行没多久的小鸟（他们的技术水平比较低），都是和你一样的专业人士。他们基于自身的技术和经验所做出的判断，和你自己的一样，都可能包含着错误和正确的东西，并无高下之分。因此，认真、虚心的听取他人的意见，仔细的思考其是否正确，不但有益于你的工作，而且对你自身水平的提高更是有着极大的好处。孔子曰，三人行，必有我师。
再说妥协。当你听到别人的观点的时候，你先考虑的是什么？是对方观点中正确的地方在哪里，是否可以接受？还是先找其中错误的，不能实现的地方？我想说的事，就算你自己的意见比较正确，别人的意见中也未必没有合理的，能够对你进行补充的地方。因此，听到别人的观点，首先应当先考虑对方合理和正确的地方在哪里，而不是先抱着排斥的心理挑毛病。就算别人的观点最终不能够接受，其理由也应当是对方观点中的优点不够你的多，不够你的好，而不是由于对方的错误。
第五，严重缺乏团队协作精神。关于这一点，我认为最突出的表现就是只有极少数的程序员，会关心别人，自己的同事，团队伙伴，是否真正理解了自己的观点/文档/代码/其他。我在上一篇文章中已经提到过这个问题。我们绝大多数的程序员，都缺乏将一件事讲清楚的意识，甚至很多时候，也缺乏真正将别人的意思搞清楚的欲望。信息在沟通和交流当中，损耗和失真极其严重。就我自身的经验而言，我在开发组内部的技术会议上，往往会充当一个翻译的角色，即不但要将我自身的，特别是组内其他人的意见，以大家都能听懂的语言和方式描述出来，不然，我不止一次的见到过双方进行极其激烈的讨论，到最后却发现大家说的完全是不同的东西。
当然，正如我上一篇文章中所说的，不经过有意识的训练和实践，人是很难有把事情说清楚地意识的。因此，我们在实际工作中，就更要注意在表达自己的意见，撰写文档和代码等的时候，能够从别人的角度出发，思考一个对自己的工作不太了解的人，是否能够听懂，看懂自己的所说和所写，哪怕罗嗦和拖沓一点，也一定要把事情说清楚。而不能只从自己的角度出发，觉得写清楚了，说清楚了就算了。
第六，缺少一种白领工作的技巧和意识。先别觉得我故弄玄虚，我知道一般都认为，我自己也同意，程序员不过是坐办公室的蓝领而已。我这里所说的白领工作的技巧和意识，指的是从事类似的脑力劳动，主要与各种各样的文档和文件打交道的时候，所需要的工作的技巧、方法和意识。
我们在实际工作中一定要涉及到文档、代码等信息的交流，各个公司可能通过文件服务器、电子邮件等不同的方式来进行。我看到过很多这样的情景，采用文件服务器的，连文件服务器的地址都不知道，采用电子邮件的，所有的mail乱糟糟的堆在一起，什么都找不到。当在工作当中需要一份文档或别的什么的时候，明明早就已经收到过，却怎么都找不到，也不想找，直接要求该文档的负责人再次发送，甚至有时候他自己负责的东西都会找不到，要别人来为他提供。或者有的时候能找到，却往往是错误的版本。
这不仅浪费了自己的时间，更重要的事，还会浪费别人的时间，有的时候，会极大的降低整个项目组的效率。
其实要避免这些非常简单，只要能够每天花上一点时间，对自己收到的mail和文档进行分类，将自己的工作成果上传到文件服务器就行了。可是我却很少见到有人能够有这样的意识。当然，处理和分类文档也需要一定的技巧，但是这些并无一定之规，可以在实际工作中自行总结，一切以提升工作效率为目的，并没有什么困难的地方。
以上总结了六点，是我对于程序员这个角色所做出的反思。我认为，其中大多数问题其实都是意识问题，没有意识到这样做是不好的或是不对的，只要意识到了，要纠正非常容易。
然后让我们来讨论开发当中，最重要的角色：Project Manager和Group Leader。
如今我自己是一名具有Group Leader资历和经验的程序员，在过去几年的职业生涯当中，也有过曾经在数名Leader的领导下工作。就我所见，目前，我们的Project Manager和Group Leader们，最大的问题，就是不会也不知道该如何领导别人。
我这里所说的领导别人，指的不是开发过程中，种种具体问题的解决，比如如何组织和架构一个小组，如何制订工作流程，如何分配工作等等。关于这些问题，要么已经有先贤们的项目管理书籍可作参考，要么已经有成熟的制度和方式可供参考。
我所说的不知道该如何领导别人，指的是：第一，不知道在基层Leader这个角色上该如何与别人进行交流；第二，没有清楚的意识到自己真正的职责和应当做的事情。
基于目前中国软件行业的现实，我们当中绝大多数的基层Leader在被提拔为Leader的时候，鲜有人是经过了专门的培训了的。很多时候，就只是上级一个简单的任命，一个普通的程序员就变成了一个Leader。
作为一名Leader，权力，薪酬，责任，都是如同这个职位一样，可以简单的随着上级的任命得到。然而，作为一名Leader所需要的能力，意识，威信和技巧都是不可能这样简单得到的。因此，我们可以看到，有相当多的基层Leader们，在刚刚成为Leader的时候，并不知道该如何对待上级和下级，不知道该如何想上级正确的反映实际情况，也不知道该如何领导自己的下属。并且，因为在实践当中如果没有人能提供优秀的指导和范例，所能获得的经验和技巧相当有限，所以甚至很多人在已经做了很长时间基层Leader之后，仍然不能够正确的完成自己的职责。
关于如何与上级进行交流，我本人的经验并不足以教导别人（欢迎各位朋友补充），因此，让我们只谈如何与下属进行交流。
先问一个问题，请问你认为，当你作为一名Leader的时候，你认为你和你的下属的关系是什么？是领导和被领导的关系？还是合作的关系？
我认为，是合作的关系。当你成为一名Leader的时候，绝不意味着你就此高人一等，下属都应当无条件服从你。在这里，我认为应当认为Leader作为团队的一员，与普通开发人员的区别，应当只是分工不同而已。不错，Leader是有权力的，但是这种权力应当只能用于工作，而不能用于其他的地方。
我并不是说合作的关系正确，领导和被领导的关系错误，这取决于每个人的观念和意识，没有对错之分。我只是认为，以合作的意识来处理日常工作中的种种矛盾，会比以领导的身份来处理，对于工作更有好处。
当一个人成为Leader，自然而然也就得到了相当的权力。但是权力可以简单的由上级给予，威信却不可能这么简单的得到。我们都知道，如果要真正成功的领导一个团队，威信和权力是必不可少的，甚至很多时候，威信的作用还要远远的超过权力。特别在软件开发这种对于团队成员的主观能动性有着极大要求的领域里，威信就更为重要。别忘了，软件公司并不是军队，Leader是有权力，但是并没有大到可以完全凌驾于他人的意志之上。
我就亲身体会过一个自视过高的Group Leader，凡事都要拿着架子，总是趾高气扬，居高凌下的指挥下属做这个做那个，自己却从来不做任何实际的工作。在开始的时候，还能唬住大家，一年过去，如今，在他的项目组里，已经没有任何人服他，很多时候，即使他提出的意见是正确的，都会遭到大家的抵制和反对。项目组里人人都想离开，工作中一旦出了问题就只会互相推卸责任，整个项目组分崩离析。
因此，从合作的角度来看待自己与下属的关系，是非常必要的。
以此为前提，究竟该如何具体的与下属进行交流呢？
在这方面，我自己确实也有些小小的体会，然而，在人际关系、成功学领域里，早就已经有若干先贤的著述可供学习，在这里，我真心诚意的推荐美国著名心灵导师——戴尔卡耐基（Dale Carnegie）的作品。特别是他的《人性的弱点》全集，相信我，如果你没有看过的话，那么在如何处理你的人际关系上，它会给你一个全新的世界。我自己在初中时，十年前，就读过此书，一直受惠至今。这本书并不是专门讨论上级和下级的，而是涵盖了整个人际交往的方方面面，因此，读过之后，不仅会有助于你做Leader，还会有助于你的整个人际关系。
我是程序员，不是书贩子，因此，请相信我，我是真心的推荐——戴尔卡耐基。需要说明的是，目前市面上的戴尔卡耐基书籍良莠不齐，很多是中国的编者自行删剪过的，我在这里推荐两个版本的，一是中国发展出版社的《人性的弱点全集》，黄色封皮，25元，一是中国档案出版社的《卡耐基成功励志全书》，绿色封皮，上下两册包含卡耐基全部著作，48元。卡耐基的书其实很多小书店里就有，相信不难找到。
说完交流问题，我们再来看职责问题。
Project Manager的职责是什么？Group Leader的职责又是什么？我相信每个人都会有自己的理解，同时，也有很多项目管理的书籍，对此有着详细而明确的定义。在这里，我只想谈谈我在实际工作中观察到的，相当多的Leader身上都存在的误区。
我认为，首先要明确的一点是，身为一名Leader，在开发过程中，也许不会负责任何文档、代码等实际的工作，但是，你必须建立起这样的意识，所有的工作仍然都是你完成的，你必须为你的小组所产生的所有工作成果负责。
我知道很多人都不会赞同我的观点。的确，这看起来不太可能，我们怎么可能知道每个下属心里想什么，以什么样的态度和心情在工作，我们不可能控制的了一件工作到底是如何完成的。别人的怠工，别人的不认真，别人的水平低，不可能轻易的随着我们的意志而改变，那么，凭什么要我们为每一件具体的工作负责？
没错，我们不可能随时的监控每一个下属，他们也不会完全按照我们的意志和希望去工作，但是，这不是你可以对于具体工作的质量和成果不必承担责任的理由。其实作为一名Leader，我们每个人当然都希望自己的项目组所产生的每一件工作成果都能够高效率、高质量的完成，但是，你究竟为此做出了什么样的努力呢？
我见过不只一个Leader，在他们成为Leader之后，每天所做的工作就只是将工作分成一块一块，分发出去，再将成果汇总，向上级报告。如果有了错误，就指责该任务的具体负责者；遇到了困难，就强制大家加班，问题解决了才能下班。
不错，这些都是一个Leader应该做的，但是，如果一个Leader的职责就只有这些的话，那么，你凭什么拿你高于普通开发人员的薪水？这些工作，一个职业高中或者中专文秘专业毕业的学生足可胜任有余，而且肯定比你做的还好，为什么要付那么多的薪水来让你做这些事？
我认为，管理管理，核心在于管人，而不是管事。事情要管，所有刚才我列举的工作都是必不可少的，但作为一名Leader，真正重要的是管理你的下属。
我认为，身为一名Leader，必须对于整个项目的状况，都有全面的掌控。当你分配一项工作给别人的时候，你应当清楚，他大概会如何完成工作，或者说，你必须知道，如果是你自己来负责这项工作，应当如何来做，再或者，也许你自己不知道该如何做，但是你必须确定下属是知道该如何做的，并且，当下属在工作中遇到问题和困难的时候，你必须确定他是能够得到及时的帮助的，不论提供帮助的是你，其他人还是互联网。总之，你必须对这项工作心中有数。绝对不可以简简单单的说，某某，你来做这个，之后就再也不管，直到工作完成或是出现问题的时候你再去关心。
同时，你必须确认，每一个下属在工作中遇到了任何他自己难以解决或解决不好的问题，你都能够得到及时的反馈，并且马上想办法解决问题。
也就是说，作为一个Leader，你必须对整个项目进行过程中每一项工作的完成状况心中有数，你可以不了解具体的细节，具体怎样完成，但是对于这项工作的种种指标，比如工作承担者是否胜任，工作成果的大概质量，按时完成是否可能，如何提供帮助等等，都要有清楚的了解和预见。
并且，你必须对于整个项目进行中的重点和难点以及进度保持极度的敏感。每一个下属所反映的困难和问题，进度的延后，你都必须当作是自己的困难和问题，进度拖延一样，立即做出反应，马上和下属想办法，把问题解决掉。因为从下属的角度出发，问题反映给你就代表他自己解决不了或者解决不好，而你作为Leader，指导和帮助下属解决困难是你的责任。因此，当下属想你反映问题之后，就会认为他的责任已经尽到了，剩下的要看你怎么安排，怎么说了。接下来，对于工作积极性高的程序员来说，可能会继续自己努力去解决问题，但是前面说过，会向上反映的都是自己很难解决的问题，因此自行获得突破的可能性很小；而对于那些工作积极性不高的程序员来说，很可能就会将问题搁置，一直等待你的安排。
因此，如果此时你掉以轻心，没有对下属反映的问题及时做出反应，那么问题和困难就会一直搁置，直到有一天你突然发现，马上就是Deadline，竟然还有一个模块没完成！于是，我们就又有机会看日出了。所有人员疲惫不堪，整个项目组士气低落，怨声载道，而这所有的一切，都是因为你，一个没有尽到自己责任的Leader的错误。
这也是为什么我们经常可以在实际中看到，一个项目开发的前期，往往不那么紧张，大家都能保持正常的工作作息时间，可是到了后期，却恨不得一天真的有25个小时。实际上，如果早一点发现问题，解决问题，就能够把解决问题的时间分摊到整个项目周期中。那么我们可能只需要每天多工作很短时间，甚至根本不必额外加班，就能够成功的，甚至更高质量的完成目标。
这里举一个反面的例子。我曾经参与一个项目，本来一直都觉得进行得很好，代码写完之后没什么事，每天悠哉游哉。可是直到Deadline之前两天，我才知道，我们需要将若干个使用我们代码的UNIX守护进程调试运行起来，而那些守护进程基本上还都无法运行呢！于是一下子变得紧张起来，连续两个通宵，也没能让所有的进程正确的运行，不得不延期出品。并且，因为延期带来的压力极大，要求在最短时间内弥补过来，所以所有人继续超负荷工作，苦不堪言。这毫无疑问是Leader的失职。其中，必须调试运行若干个进程，Group Leader是知道的，然而他只是简单的自己调试了一下，通不过，就把这件事向上反映给了Project Manager，因为Project Manager没有反应，因此他就将此时搁置，既没有把这件事告诉下属，也没有持续努力去解决问题。而Project Manager作为项目的负责人，却没有我前面所说的负责的意识，听到Group Leader的报告没有及时做出反应，直到最后发现无法按期交付才开始着急，和开发人员一起去解决具体的技术问题，却已经晚了。因此，由于这两级Leader的失误，导致了项目无法按期完成，受到了客户严厉的批评。同时，大量的超时工作导致开发人员士气极度低落，有两名开发人员因此离开了团队。
让我们想象一下，在这个例子中，如果Group Leader在意识到问题的同时，能够意识到问题的重要性，不但反映给上级，同时也马上提醒所有的下属，组织大家一起来想办法，解决问题；如果Project Manager在接到报告的时候立刻做出反应，要求必须解决这个问题，并提供各种技术支持手段...这两层Leader中有任何一个尽到了自己的责任，就能够把解决问题的时间分摊到一个很长的时段，既可以保证按期交付，又能够避免大量的超时工作。
我想再强调一遍，我认为，那些只是简单的分发任务，收回工作成果，完成一些事务性的工作比如填表格，开会，出了问题就只会追究实际承担工作者的责任，自身对于具体的工作，重点和难点，既不了解也不想了解的Leader，一个中等专业学校文秘专业毕业的学生会比他干的出色的多。一个这样的Leader，根本就对不起他的那超出普通开发人员的工资，甚至，他应该拿的，还应该远远少于普通开发人员才对。
最后要说的就是，在实际工作中，我还发现很多Leader都有一种等级意识，认为自己高普通开发人员一等。这种等级意识往往表现为毫无必要的对很多应该公开或分享的信息保密。在实际工作中，老是搞的神神秘秘的，觉得知道一些普通开发人员不知道的情况就很有优越感。
我并不是说每件事情都应该公开，但是，我认为，至少，对于具体负责某项工作的下属，如果没有特别要求的话，你应当确保对于这项工作，负责的下属知道的至少和你一样多。你必须确保，负责实际工作的开发人员，对于他所负责的工作，完全清楚其重要性，并且确实知道他应该做哪些事情。在这方面保持神秘没有任何好处。不然，最终工作完成的速度，质量以及内容，就很可能跟你期望的，理解的有着极大偏差。
以上，就是我对于基层Leader这个位置所进行的观察和做出的反思。
最后，让我们再来看看比较高的位置，部门经理，以及更高层的管理者。
当然，我自己没有做过这些位置，因此，我所提供的，只是作为一个普通开发人员所看到的，想到的意见。未在其位，未谋过其政，很多地方看起来可能比较像笑话，还请多多批评指正。
第一，企业应当有意识的培养和招募人才。
这句话听起来是废话，但是在这里，我的意思与一般所认为的稍有不同。
我所说的人才，指的不仅仅是处于管理和技术金字塔顶峰的少数大牛。有意识的培养和招募人才，指的也不是我们经常可以在报章上看到的某某公司招募了某某大牛做总裁，或者某某少帅执掌某某公司。
我所说的人才，指的是构成整个软件产业大厦的一块块普通砖头，一条条普通钢筋。或者说，我指的是软件产业这张网上的络。离开了络，网就只是一堆绳子，同样，离开了一个个的项目经理，技术高手，也就没有了软件产业。
前面说了那么多项目经理的坏话，实际上，很大程度上，那并不是项目经理们自己的责任。我们都知道，如果没有外来的，先进的，理论上的指导，没有一个好的环境，只靠一个人在实践中摸索，其成长和进步是极其有限的。因此作为高层管理者，必须有意识的培养有经验有能力的中层管理人员。
当然，我完全明白我的这种愿望在现实中实行起来有多么的困难，软件公司的人员流动率足以打消任何老板在员工身上投资的愿望。但是，我认为，困难并不是我们不做某件好事的理由，只要我们有足够的诚意和努力，我们所收获的一定远远超出我们所付出的。
第二，在实际工作中，要注意，不要让歪嘴和尚念坏了好经。
软件开发公司可以说是目前中国学习热情最高，实际行动也最高的群体，因此，在实际的工作中，我们其实已经有了很多好的管理，技术等方面的好的原则，方法和技巧。但是，我在实践中经常发现，明明有很多好经，却被歪嘴和尚们出于种种的目的念坏了。
这里仅举一例。我们都知道当工作中出现问题和失误的时候，应当进行总结和检讨。这个时候，每个人都应当提出自己的意见和见解，进行批评和自我批评，并且，应当以自我批评开始，先找自身的失误，再批评别人。这个原则是正确的，没有问题的，我们确实应当如此。
但是，在现实中，我们经常可以看到，即使主要是管理者们的失误导致工作中的问题，但是在检讨中，往往大大小小的管理者都会让最基层的开发人员开始检讨，还要求他们主要先找自己的问题。OK，这样好了，每个基层开发人员明明责任很小，却不得不违心的把自己的种种小错误放大，自己攻击自己，不得不承担失误的主要责任。而任何对于真正的失误和责任的讨论，都会遭到管理者的斥责，被认为是不虚心，没有诚意。然后，基层开发人员检讨完了，管理者再敷衍两句，因为基层开发人员都已经不得已的揽下了大部份责任，管理者不但不必再检讨自身，反而可以大肆批评基层开发人员。于是，我们不但无法发现工作中真正的失误在哪里，还会极其严重的打击开发人员的士气。
批评和自我批评这个我党自我建设的法宝，就这样生生的被扭转到了反面。在实际工作中，还有很多类似这样的好经，不仅包括管理经验和方法，还包括很多品质管理办法，过程改进方法，都被生生的唱歪。因此，我认为，身为高层管理者，必须要注意，本部门，本公司所实行的种种规则，是否是真的在起到它应有的作用，还是已经走向了它的反面。
最后，我想说的一点就是，不劳无获。很多管理者，在推行好的措施，方法和规则的时候，往往容易就只是开个会，提出目标，要求大家努力，然后就等待收获了。可是，既然你都没有为达成这个目标付出过任何专门的努力，那么你又怎么希望最终这个目标成功达成呢？
再举一例，公司的最高领导者提出要求，要求BUG率达到若干个/千行，然而却没有具体的针对这个目标提出什么措施，只是简单的要求中层管理者，中层管理者再去要求基层管理者，基层管理者只好和开发人员一起自己瞎鼓捣。这样如何能保证最终达到目标？如果高层施加的压力很大，基层就会伪造数据来达到要求。
我认为，管理者必须务实，提出目标，还必须根据目标来具体的制定计划，拿出办法，一步步的引导着人们达成目标。还是那句话，没有努力就不要指望有收获。
对高层管理者的意见就到此结束。
本篇对于开发过程中的各个位置都提出了意见和看法。在下一篇当中，将会讨论目前中国软件产业的前景以及程序员的职业生涯，来作为本文的终章，多谢关注。
