| | | | | | | [文章信息] | | | 作者: | freezingfire | | 时间: | 2003-10-25 | | 出处: | 论坛 | | 责任编辑: | 方舟 | |
| [文章导读] | | | 本文就软件企业的微观管理和程序员的职业发展进行了探讨 | |
| |
|
| | | |
|
|
|
|
|
天极IT资讯短信服务 电脑小技巧
|
介绍：细处着手，巧处用功。高手和菜鸟之间的差别就是：高手什么都知道，菜鸟知道一些。电脑小技巧收集最新奇招高招，让你轻松踏上高手之路。(首月免费) | |
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，我们每个人当然都希望自己的项目组所产生的每一件工作成果都能够高效率、高质量的完成，但是，你究竟为此做出了什么样的努力呢？
|
|
|
|
|
|
|
|
情人玫瑰坊
音乐风云
新片速递
神秘测试
都市约会