项目经理一定要懂技术已成旧观点？

我想程序员对芮林这个名字很熟悉。当时我正在看他的《高质量C/C++编程》，写我的第一个正式项目。但是，大家有没有注意到，在芮林的两本书里，他的一个观念发生了很大的变化，那就是对项目经理的技术要求:
在2003年芮林写的《软件工程思想》里，提到了“项目经理必须懂技术”；在2005年出版的《IT企业中的项目管理:问题、方法和工具》一书的序言中，芮林反思了一些陈旧的观点，他对项目经理是否应该懂技术有不同的看法:“项目经理其实并不一定要懂技术”。
那么，项目经理需要技术技能吗？以及从技术人员到项目经理需要怎样的思维转变？在这篇文章中，我将谈谈我自己的经历，如有错误，请不吝指正。
有一个自以为很有学问的人，向一位大禅师求教佛法。禅师不说话，一直给他倒茶，茶溢出来也没停过。那人非常惊讶:“师傅，茶杯满了，装不下了！”禅师笑了，停下手，意味深长地对他说:“是的，你的大脑就像这个茶杯。已经满了。我怎么能抓住我对你说的话？”
佛教徒说的“知识障碍”，是指自己学了很多东西，实际上阻碍了自己的修行。项目经理也是如此。如果他们太执着于技术，就会阻碍他们的管理技能。
那么项目经理这个职业有什么特点呢？从思想和执行两个方面来说吧。
先说思想方面:
技术人员有两个特点。第一，他们做事注重细节，追求完美；二是动手能力强，经常喜欢自己动手做事。对于项目经理来说，这两个特征是不可接受的。
任何人，任何公司，只要做事，都会犯错。作为管理者，如果他们一心想把每一个细节都做到尽善尽美，最终可能会一事无成。对于细节的改进，我更倾向于把重点放在最重要的事情上(一般来说就是和QCD直接相关的节点)。这些关键点一定要符合要求，剩下的东西不需要挖太多。另外，如果你发现你的团队成员在细节上做得很好，一定要及时表扬。真诚的赞美，比赞美更宽泛，是对待细节的态度。
作为管理者，团队的表现就是你的表现，但团队的能力不等于你个人的能力。也许你的技术很强，但你不可能一个人做所有的事情。就像踢足球一样，一个人的球队是无法取得好成绩的。所以，要敢于把事情交给别人。可能他做的不太好，那就告诉他怎么改进。如果同样的事情总是失败，那么也许这个团队成员需要换一份更合适的工作。
总之，作为项目经理，你不再是在做自己的工作，更多的是在做别人的工作。注重与领导、业务、技术等层面的沟通，关注QCD的地位，以大局为重，对事不对人。这是项目经理的思维方式。
再来说说执行力:
有个朋友在一次聊天中提到，他们公司的一个部门经理教见习经理“你想成为一个好的部门经理吗？那你得先学会怎么发奖金！”题外话，在所有的事情中，我最喜欢的是拿到奖金的感觉...【/br/】作为项目经理，如何汇报，如何明确自己的责权利，非常关键。发奖金只是一个方面，真正落实的还有更多。
汇报工作，首先要学会发邮件。汇报工作时，将邮件发给你的领导，并抄送相关人员；安排工作时，邮件发给目标收件人，抄送相关领导。不要小看电子邮件，它是工作内容的重要载体，也是每个人责任明确的证明。电话、面试、会议等沟通方式。最后必须书面确认，电子邮件是书面确认方式。善用电子邮件可以使你的工作更加有序。
权力与责任密切相关。从你接受项目经理任命的那一刻起，你就要负责这个项目的QCD，但是这个责任是广义的，大部分公司不会直接给项目经理人事、费用等资源的支配权，这些资源可能都在老板手里。项目经理需要及时汇报项目的进展，提出下一步的计划，以及所需资源的预算，然后上级领导审批人员和费用。一个好的项目经理能够与企业高层保持良好的沟通和信任，从而获得推进项目的必要资源。
作为项目经理，一方面要把握项目的关键节点，另一方面要准确、及时、合理地进行汇报，这样才能充分取得领导的信任，从而获得推进项目的必要资源，并赋予自己相应的权力。这是项目经理的工作方式。
从细节到大局，从自身到团队，从思维方式到管理人员和技术人员的工作方法，都有本质的区别，这也是为什么管理人员并不真的需要成为技术娴熟的人。
回到本文开头的问题，我觉得项目经理懂不懂技术并不重要。关键是不要让技术“拖垮他”。只有超越技术，站在项目的全局层面思考问题，项目管理工作才能真正落到实处；从另一个角度来说，项目经理在把握整体工作的前提下，适当做一些技术工作，也能很好的带动团队士气！
注:QCD，即质量、成本和进度，是项目管理的三个关键点。掌握QCD的能力标志着一个组织项目管理的成熟。