关于修车师傅的补充

关于修车师傅的补充

昨天令狐看了《修车师傅=软件项目管理者》后私下里跟我讨论了一下。

令狐说得不错：管理是分几个层次的，每个层次都需要有管理。比如，高层领导对全公司进行管理，部门经理对部门的所有项目以及部门发展要有管理，项目经理对项目进行管理，至于最下面的小兵兵，也要对自己的任务有一个有效的管理。

我非常同意他的看法，但对于我们来说，高层的管理咱没接触过，不敢妄加评论，只能就接近具体开发工作的软件项目管理随便说说。

令狐说：这是一个典型的管理不足的例子，那个修车师傅应该做的是，告诉徒弟们如何修车（基础知识培训），另外，还必须告诉他们如何合理安排自己的工作（管理知识培训），师傅自己还要适当介入，为徒弟们做一些高层面的安排（项目管理），这样，这个团队才能有效运作徒弟要学，师傅也要学，师傅的专业技能应该是没问题了，那么他就应该学习如何合理使用手中的资源，包括静态资源和人力资源。

这也正是我要表达的：技术专家未必是管理专家，虽然说可以通过学习逐步掌握，但这样未必好。扬长避短才是更好的用人之道。如果一个公司里，只有向管理发展这条唯一的升迁之道，就必然迫使技术人员弃已之长，用已之短。就像让Anders去当BORLAND的CEO一样。

另一方面做技术管理的也必须了解技术，并参与其中，虽然他不必是高手，但不能脱离技术。其实在MS里也是这样的，很多项目经理甚至高级的产品主管都有在做编码工作，不过国内的很多软件项目经理好像一升做管理就觉得高人一等，不屑于再去做编码这样的工作，看来他们比MS的主品主管还牛啊。

令狐也说了：按敏捷的要求，管理者本身也是参与开发的，只是他的任务更加重而已，他起到的更多是一个协调团队的作用，而不是一个指手画脚的作用，作为一个团队的管理者，应该是开例会的时候调动大家发言，并且控制发言主题不会偏离既定主题太远的那个人，而不是一个在例会上长篇大论，让其它与会者只能接受的那个人。

这点我很赞同，有一种说法便是：如果会上始终只有一个人在发言，那不叫开会，那是上课。

当然上课也是必要的，那就是成员间的相互培训。令狐提到一个不影响工作的培训方法就是建立公司内部的知识库，这是一个好方法，不过我想面对面的培训同样不可或缺，但只能以自愿为原则在工作之余进行，这样的话就必须保证XP要求的每周四十小时工作，不能加班。这就比较难了。

本文大量引用了令狐的意见，特此鸣谢。^_^