有一次，隶属于一个大项目的一支开发团队的领导者被提升后，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了，表面上是更加专业的分工了，但项目团队对产品/需求变更的适应性就会变差，以致最终开发成本的上升。