昨天令狐看了《修车师傅=软件项目管理者》后私下里跟我讨论了一下。
令狐说得不错：管理是分几个层次的，每个层次都需要有管理。比如，高层领导对全公司进行管理，部门经理对部门的所有项目以及部门发展要有管理，项目经理对项目进行管理，至于最下面的小兵兵，也要对自己的任务有一个有效的管理。
我非常同意他的看法，但对于我们来说，高层的管理咱没接触过，不敢妄加评论，只能就接近具体开发工作的软件项目管理随便说说。
令狐说：这是一个典型的管理不足的例子，那个修车师傅应该做的是，告诉徒弟们如何修车（基础知识培训），另外，还必须告诉他们如何合理安排自己的工作（管理知识培训），师傅自己还要适当介入，为徒弟们做一些高层面的安排（项目管理），这样，这个团队才能有效运作徒弟要学，师傅也要学，师傅的专业技能应该是没问题了，那么他就应该学习如何合理使用手中的资源，包括静态资源和人力资源。
这也正是我要表达的：技术专家未必是管理专家，虽然说可以通过学习逐步掌握，但这样未必好。扬长避短才是更好的用人之道。如果一个公司里，只有向管理发展这条唯一的升迁之道，就必然迫使技术人员弃已之长，用已之短。就像让Anders去当BORLAND的CEO一样。
另一方面做技术管理的也必须了解技术，并参与其中，虽然他不必是高手，但不能脱离技术。其实在MS里也是这样的，很多项目经理甚至高级的产品主管都有在做编码工作，不过国内的很多软件项目经理好像一升做管理就觉得高人一等，不屑于再去做编码这样的工作，看来他们比MS的主品主管还牛啊。
令狐也说了：按敏捷的要求，管理者本身也是参与开发的，只是他的任务更加重而已，他起到的更多是一个协调团队的作用，而不是一个指手画脚的作用，作为一个团队的管理者，应该是开例会的时候调动大家发言，并且控制发言主题不会偏离既定主题太远的那个人，而不是一个在例会上长篇大论，让其它与会者只能接受的那个人。
这点我很赞同，有一种说法便是：如果会上始终只有一个人在发言，那不叫开会，那是上课。
当然上课也是必要的，那就是成员间的相互培训。令狐提到一个不影响工作的培训方法就是建立公司内部的知识库，这是一个好方法，不过我想面对面的培训同样不可或缺，但只能以自愿为原则在工作之余进行，这样的话就必须保证XP要求的每周四十小时工作，不能加班。这就比较难了。
本文大量引用了令狐的意见，特此鸣谢。^_^
鸣谢就够了吗？应该请客 :D其实说到底，技术和管理根本就是两条路。不过现在的开发方法越来越要求每个开发人员身兼二职了，因为软件领域目前还没有什么成熟的模板可以供管理者直接应用，管理者只能亲自上阵了解项目情况，根据情况来做下一步的安排。No silver bullet身处在这样一个不成熟的、快速演进的行业之中，真不知是幸运还是不幸 😛
请客就请客，不过只限携带一名家属:P
收藏进我的日记本。
记得猛禽兄曾经打过一个比方，好软件公司比作武林名派，而把一般的比作镖局。镖局不可能要段誉这类内功高手，所以镖局不可能成为武林名派。关键所在还是如何对员工所缺乏的知识层面，包括老鸟、令狐阐述的这些之外，觉得怎么对待研发人员，怎么根据研发人员的结果去打开市场。当好管理人员真的很难啊。还好我及时的不当了。我还不够资格。
呵呵，怕就怕那些还不知道自己不够资格的人。BTW：镖局的比喻出自偶的《效颦篇：编程本质论》^_^
同意令狐的观点：技术和管理本身就是两个东西。但后面的话表示不太同意。中国的软件开发要求管理和技术要不断的柔和，相互协调，外国也如此，只不过是国人自己认为两种技能需要在一种人身上加以体现而已，国外的情况就不大清楚了，我想也有中国的这种特色，但毕竟感觉还是要强于国人的。要不一个诺大的系统的开发管理都集中于一人身上岂不危险系数太高了！做项目管理尤其是软件项目管理没有对开发进度的把握是不可能实施的，但这种把握完全可以靠同技术人员的沟通协调来获取，而不是将技术成分生硬的加到管理实践中。社会分工是趋势，但就开发过程，管理和技术孰重孰轻各有各的看法，但太强调哪个都不是一种健康的观点。有点跑踢了，CUTTING……..
TO：FS我不知道你所说的“后面的话”是不是指的令狐所说的“敏捷”开发管理方面？如果是的话，我想你并没有理解Agile。所以也就不必再说了。分工是必须的，但合作才是最重要的。
不是了解不了解的问题，关于敏捷的东西我压根就不知道多少！偶所说的“后面的话”主要是不赞同这个话“按敏捷的要求，管理者本身也是参与开发的，只是他的任务更加重而已”，我不清楚这个是不是敏捷的要求，但项目管理远超过开发管理的范畴，好的项目管理者完全可以没有任何开发技能。
TO:FS你就是我说的那种坐小车的。对自己所管理的东西一无所知的人是不可能搞好管理的！就像你不了解AGILE就敢反对这段话，只能说你是无知者无畏。别的我也不想再说了，省得你又这个那个的。