[推荐]浅谈研发项目经理的技能要求

小鞋带

有一次，隶属于一个大项目的一支开发团队的领导者被提升后，Arnold C.被指定去接替他。Arnold的资历主要来自于其在数据处理方面的销售经历，然而他假装自己在程序开发方面富有经验。在项目遇到一个关键的问题时，他却做的太过头了，居然“提供”了一个解决问题的“算法”。但是对于他手下极具经验的两名程序员来说，他显然根本没有弄明白自己在说什么。当他私下里向这两个人解释他的“方案”时，他们并没有立即指出其中的错误，相反的，他们却怂恿Arnold把项目中主要的程序员们召集起来，听他讲解他的算法。在会议中，他们在短短5分钟内，就让Arnold彻底的陷入了自相矛盾的境地。接下来，他们对他的“算法”进行了详细的解剖——详细到犹如在一个大项目中一样。最后，Arnold在被召集来的人们的阵阵嘲笑中离开了黑板；两个月后，应他的请求，他被调往另一个岗位。
 
　　　　　　　　——《程序开发心理学》，Gerald M. Weinberg
 
上述的项目经理看起来即可悲又可怜，令一大批新的项目经理或者准项目经理倒吸口冷气：原来下属还敢于如此放肆的联手捉弄领导，一不留神就会掉进“陷阱”，看来即使管理几个人的团队并不比调试枯燥的代码容易。

这位倒霉的项目经理很清楚管理研发性质的项目团队除了需要具备管理技能，还需要一定的技术知识，也就是要从“管理”走向“技术”，否则充其量也只是隔靴搔痒，不能管到点子上；但遗憾的是在技术上的不懂装懂害了他，事实上根据我以往的工作经验，这类自我感觉良好的“技术型”主管并不少见（尤其在大型公司内），只是矛盾没有达到激发的程度，或者就像下面的小幽默。 
赫鲁晓夫开会，台下有人小声提出异议：“斯大林时代为甚麽不提出改革？”赫鲁晓夫怒不可遏：“刚才是谁说的？”满场寂然。赫鲁晓夫平静的说：“我当时所处的正是你现在的位置。”
 
与上面相反，有些经理是从“技术”走向“管理”，他们面临的问题是如何管理一群高智商、有独立见解、且思维活跃的开发人员，对于一个技术难题或许可以采取集中攻关的方法解决（IT公司常常加班就是例证），但是管理的问题却不是急风暴雨可以解决的。 

那么具备哪些技能才可以成为合格的研发团队项目经理呢？一般来讲，需要具备技术技能、管理技能、领导/沟通能力、业务知识等几种技能。
 
技术技能：技术技能是对研发项目经理最为基础的要求，否则很可能像上述案例一样被下属嘲笑或者不被尊重：无论如何解释，技术人员的技术情结仿佛是与生俱来且难以割舍的。当然不是要求各个项目经理都是系统工程师，但是起码SRS、HLD是应该看明白的，否则项目经理就会丧失对项目的应有的嗅觉。有人会说微软或者IBM的XX项目经理不是技术型的，但也照样能把项目做好。我认为大项目和我们常常遇到的10人以下的小项目是不同的，想管理上百人的团队，首先需要证明管理小规模的项目团队是称职的。

项目管理技能：项目管理技能主要包括项目计划和控制。对于一名从研发骨干提拔的项目经理而言，这些技能的掌握并不困难，但是要做项目管理实践中熟练运用却需要长期的经验积累。通过学习尽管可以了解知识，但无论多么成熟的体系/模型都有具体定制的必要，你会发现管理工具滥用的情况比比皆是，搞得项目运作像蒙住眼睛的毛驴一样，情绪激昂的在原地打转转。 

领导/沟通能力：管理的对象就是人，一群思维活跃、高智商的人。对于管理者的一个比较恰当的定义是“A Manager is…… a person who gets things done through PEOPLE in order to
 achieve highest STACKHOLDERs’ SATISFACTION”。即包括指导项目团队朝既定目标前进，监督工作绩效,指出和帮助成员解决问题并取得工作进展,向上级汇报有关情况。上述的那位经理显然沟通的功夫没有到家，并没有意识到项目团队并不认可“空降兵”，也许厌恶了他平时高高在上、发号施令的派头，以致后来矛盾的彻底爆发。如果他能够认真倾听下属的意见，及时沟通，扬长避短，也许会做的时间长一些。 

业务知识：业务知识并不是指技术，而是包括了公司愿景及核心业务、产品规划、市场管理、需求管理等一系列内容。深刻的理解公司业务，能够帮助项目经理从更高层面定位产品，充分满足用户需要，最终造就产品的市场成功。有些公司推崇将业务和产品开发彻底分开，即开发项目经理不需关注产品定位（有其他团队搞定了），甚至不需知道开发的是什么产品，仅仅“just do it”就ok了，表面上是更加专业的分工了，但项目团队对产品/需求变更的适应性就会变差，以致最终开发成本的上升。 

健康的疲劳

就四方面中的能力，是否可以详细谈一谈？大家列一下讨论条目？
其中领导力和沟通是通用的。讨论常用沟通，是否可以根据常用沟通方式，讨论应用场景，共同内容，注意事项进行讨论？

南华学童

话题不错，能深入沟通自已的体会就更好了。

例如，搞技术出身的会习惯性服从一种观念，只认同技术事实上的权威。用什么有效方法能与他们很好沟通才是关键。

[此贴子已经被作者于2007-12-2 17:00:57编辑过]

健康的疲劳

技术人员沟通常见会有关于目标的沟通，任务沟通，个人发展沟通。 任务沟通的时候，可能会出现仅仅对技术事实上的权威认可。
技术人员不是多只对技术权威认可，而是对事实，真相认可。 需要在任务沟通时细化为几方面，找到几方面的责任人、用户，有把握的人。
我的经验是，任务沟通细化为：任务目标的沟通，任务执行进度、思路的沟通（如分歧大，可找相关技术点资深人员辅助），任务验收标准的沟通。 验收标准的沟通以外部使用人员为准绳， 目标的沟通以上级目标为依据，上级主管负责，执行沟通，以执行人员为主。
注意任务沟通是，需要三者一起考虑，进行。 技术人员，和各相关责任人一起协商，在基于事实的基础上，合理目标的基础上是比较好沟通。（比较难沟通多出现在：不理解技术执行难度，强行要求实施；模糊或不合理的验收标准；双方对任务目标理解有歧义）。
需要注意的是，技术工作是一个有明确科学依据的工作，一定要摆事实，讲规律。如不顾规律要求，这容易顶牛。

南华学童

技术人员较易认同技术权威的事实，而对分派任务目标上的采取过于究缠于仅仅是自已所理解细节事实。技术人员对技术细节认知有限的领导来说，有不服从或配合不到位的现象，以致影响总体目标的实现。

健康的疲劳

指派任务目标是必须考虑合理资源和执行进度要求。如果任务目标不包含对资源和执行进度的要求，技术人员不会纠缠于细节。之所纠缠多时因为其认知的资源需求和已有的目标需求矛盾，影响执行。
这就涉及一个问题，对于执行的资源评估如何进行，是以执行人员为主（或相关资深人员为主），考虑经验，环境登因素，还是脱离以往执行经验，拍脑袋决定。
布置任务时需要综合考虑资源、人员素质、进度安排、目标。
如果经理是仅仅是抽象谈目标，不考虑执行，不光是技术人员，任何负责的执行人员（评估执行进度）时，这个经理都会觉得纠缠于细节的。

percyshine

研发项目经理还是要以自己的技术能力为背景加上良好的沟通管理能力为好。在整个过程中能够掌握项目的进度和过程，定期总结，定期跟进，让每个人知道目前所处的位置，和项目的内容。