昨天令狐看了《修车师傅=软件项目管理者》后私下里跟我讨论了一下。
令狐说得不错:管理是分几个层次的,每个层次都需要有管理。比如,高层领导对全公司进行管理,部门经理对部门的所有项目以及部门发展要有管理,项目经理对项目进行管理,至于最下面的小兵兵,也要对自己的任务有一个有效的管理。
我非常同意他的看法,但对于我们来说,高层的管理咱没接触过,不敢妄加评论,只能就接近具体开发工作的软件项目管理随便说说。
令狐说:这是一个典型的管理不足的例子,那个修车师傅应该做的是,告诉徒弟们如何修车(基础知识培训),另外,还必须告诉他们如何合理安排自己的工作(管理知识培训),师傅自己还要适当介入,为徒弟们做一些高层面的安排(项目管理),这样,这个团队才能有效运作徒弟要学,师傅也要学,师傅的专业技能应该是没问题了,那么他就应该学习如何合理使用手中的资源,包括静态资源和人力资源。
这也正是我要表达的:技术专家未必是管理专家,虽然说可以通过学习逐步掌握,但这样未必好。扬长避短才是更好的用人之道。如果一个公司里,只有向管理发展这条唯一的升迁之道,就必然迫使技术人员弃已之长,用已之短。就像让Anders去当BORLAND的CEO一样。
另一方面做技术管理的也必须了解技术,并参与其中,虽然他不必是高手,但不能脱离技术。其实在MS里也是这样的,很多项目经理甚至高级的产品主管都有在做编码工作,不过国内的很多软件项目经理好像一升做管理就觉得高人一等,不屑于再去做编码这样的工作,看来他们比MS的主品主管还牛啊。
令狐也说了:按敏捷的要求,管理者本身也是参与开发的,只是他的任务更加重而已,他起到的更多是一个协调团队的作用,而不是一个指手画脚的作用,作为一个团队的管理者,应该是开例会的时候调动大家发言,并且控制发言主题不会偏离既定主题太远的那个人,而不是一个在例会上长篇大论,让其它与会者只能接受的那个人。
这点我很赞同,有一种说法便是:如果会上始终只有一个人在发言,那不叫开会,那是上课。
当然上课也是必要的,那就是成员间的相互培训。令狐提到一个不影响工作的培训方法就是建立公司内部的知识库,这是一个好方法,不过我想面对面的培训同样不可或缺,但只能以自愿为原则在工作之余进行,这样的话就必须保证XP要求的每周四十小时工作,不能加班。这就比较难了。
本文大量引用了令狐的意见,特此鸣谢。^_^