反面案例5：上级单位要检查工作，某领导B请缨负责该事，将其下属（本来都有各自工作）全部集中到单位加班，但大部分人都在等待安排工作，在汇报材料编排的问题上，该领导做出很多指示，负责编排的人员不断修改，其余人继续等待，深夜，开会讨论，负责编排的人继续加班修改。翌日，单位领导N看过之后，提出一套新的要求，基本上全盘否定那位领导B的想法，更要命的是，所谓的新的要求，也就是他昨晚否定的。

    最后要能够给予成员指导和帮助

    作为一个领导，不仅要知道应该做什么，还要知道应该怎么做，不要求你会具体的操作，但是至少能够指出方向和路线。

    案例6：单位希望落实ISO20000，前面提到的那位领导总是认为大家不认真，不落实，我说你请的咨询公司老师来了就按照ISO20000的中文译本给念一遍，你认为大家能明白么？能理解么？这些平时都是一线的工程师，对ITSM根本没概念的，不是自己回家看看标准就能明白的。我自己开始读ISO2000的标准，学习，在网上找资料，跟人交流讨论沟通，具体到流程的给大家培训，讲概念，讨论，这个概念在我们的工作中对应的是什么，我们可以怎么实现，应该如何实现，

    案例7：某个项目，作为监理，做OracleRAC，按照实施要求，服务器的4块网卡要做两两绑定，实施单位H说试了半天，只能做一组，是否能够改变实施方案，我看了一下时间，说再花一小时研究一下，你们做一台，我来在另一台上试一试，上网查资料，半小时后我告诉他们试验成功了，把整理好的文档也给他们了。

我没有因为这个事埋怨或轻蔑对方，只是跟他们说其实很多时候踏下心来仔细认真的看看文档就能够解决问题。顺便说一句，做实施的时候，我比较倾向于参考官方文档去做，而不是上来就凭经验凭感觉地实践摸索。后续的监理工作开展极为顺利，源于对方无论从项目管理还是实施技术上都对我已经给予信任，有问题都会主动来商量解决。

    案例8：某次部门开会，准备布置一项工作任务给W。W是驻客户现场的项目经理，并且那个项目的客户比较厉害，很反感派驻现场的工程师回我们单位。提前通知了W，开会当天中午，W电话给领导B说下午不能来开会了，领导B怒斥。我给W电话问其为何不能来开会，W说上午想跟客户请假来着，结果客户有个事，挺着急，一忙活完事都快中午了还没来得及请假。我跟B说，W未能提前准备好与会事宜是他的错，该批评，但是你不能只批评不帮他解决问题啊，你应该给客户打电话说明一下，要求他能够下午回来开会，这个还是做得到的。B不愿意，怕客户说他。我说你这样当领导，只会批评下属，却不能帮他解决，这怎么行？B领导很不高兴。结果下午的会照常开，在W缺席的情况下，给W布置了任务，这是如何完成的，我不知道，因为我也拒绝参会，一方面我已调离该部门，另一方面也没兴趣听B在会上训斥那些人。

    最后说一下“专家级员工”的管理。

    我是很希望下属有专家级的员工，因为尤其是以服务为产品的公司，服务团队人员素质的优劣往往决定了产品质量的层次。最好团队内的成员都是某一方面的专家，这样的话省很多心，工作分配下去都不用担心完成进度啊效果啊什么的了。

    很多人担心专家之间的关系不好处，“文人相轻”嘛，这个其实就看你团队建立的文化氛围了，一群志同道合的人在一起，水平越接近，大家互相都有学习，有进步，有发展。

    作为领导，你得给每个人以希望，前途，专家级员工，他之后还能怎么发展，有什么路？这个问题往往是企业领导层面应考虑的问题。中国的企业往往是“华山一条路”，给大家的发展路线就是“当官”，也就是只有“管理”一条线，而看看国外的企业，很多都至少是两条线：管理和技术，管理的路你一直可以做到CEO，技术的话你可以到首席科学家。并且待遇上来讲同级别的不同发展路线也不会差很多。所以国外经常能看到50几岁的程序员，系统管理员，那些著名的开源架构，往往都是这些极其资深的程序员写的，纯粹是爱好。在国内，30几岁还在做技术，就被人认为是没出息没发展没前途了。

    总之，中国要发展，就要改变，从你我做起吧。
 

扩展阅读

版权声明：