这样的PM是我的目标么？

pm的核心职责在于协调资源，从道理上说似乎不需要他去做编码。但是我想没有具体的实际编码基础，很难掌握资源的分配原则。而很多文档的写作其实也是很有技巧，大家不要轻视。比如写标书，写方案，写计划，这些东西没有几年的牢固基础，写出来的东西只能吓唬吓唬外行。
而对于review的问题，我想PM不去做，也不是没有道理，而且我有的时候还认为，根本在国内就不应该提倡任何人来直接的review代码，而应该让人去review测试。这样会少很多人事关系的是非。
我也在所谓的大公司做过，很多所谓的pm只是一个摆设，他们顶这样一个头衔，负责的就是把单搞定。他们的工作很重要，而且往往是最重要的（虽然这样有些让人觉得悲哀）。这些人对于公司的生存是重要的，我们不能因为他们的工作不符合我们的胃口，就有看法。

o6z说的有道理经验之谈，这就是国内it界的现实

o6z 说的有道理，PM 不熟悉技术的一个最大的危险是无法地准确估计工作量，无法做好进度控制。当然这个和能否接到单相比还是次要的。而且这个问题将随着他做过的项目数量的增加，积累经验的增多而得到改善。因为他可以根据以前的经验估计得到一个平均结果。但是他不熟悉技术还有一个问题是无法预测到系统中实现的难点和瓶颈，有效地规避这些风险。所以让不熟悉技术的人做 PM 还是有很大风险的。基层的 PM 一定要从好的技术人员中选拔也是这个道理。

不过也有些公司的 PM 是不需要打单的，打单有 Sales 和 Presales，这样 PM 可以更加精确的做好进度控制。

PM 要做好工作还有一个技巧是决定不去做某些事情。为了做好某件事情而不去做某些事情，这个技巧是相当重要的。一些技术高手出身的 PM 往往对于解决复杂的技术问题有一种天生的冲动，而很可能这些问题对于实现项目的目标并不是非常重要的。PM 要善于利用他所掌握的资源，在自己对如何做某件事情胸有成竹的情况下多交给手下的人去做，这样可以利于他们的成长。甚至有些时候在自己并不清楚如何去做的情况下也应该交给手下的人去做。我曾经犯过的错误就是总是觉得自己应该想清楚所有问题后才交给手下的人做，但是发现这样做的问题很多。现在即使在我不清楚该如何做，但是只要我确信我手下有人会做这件事情，我就果断地交给他去做。我在这里起到的是 banq 今天所讲的那个Facade 或者 Proxy 设计模式的作用。

一个企业的中层对于企业非常重要，他可以说是牵一发而动全身。所以他要明确自己对于企业的责任。掌握好自己做事情和利用手下的资源做事情之间的平衡。PM 做一些技术工作是很有益的，有利于团队胶合的产生，但是要掌握好一个尺度。

o6z兄为什么说国内的人际关系是非不好作Code Review呢？
能否解释解释？

在我实际工作中,帮同事抓bug,和review code,我都称之为踢屁股.
你想想,你喜欢给人踢屁股吗???

hehe,这个比喻有趣，不过到也是事实。。

项目经理应该是个从技术人员转过来的管理人员。

PM的职责确实很难划分的，一般超过6个人的团队PM就不应该直接编码了，超过10个人的团队大概就会以开会写文档为主了……

对,同意楼上的看法.在一个比较大型的项目中,PM所起的作用主要是控制项目的进度,风险,质量等等一些关键因素,同时协调团对内部以及与客户之间的沟通.这样一些工作也许在某些人看来可能是比较鸡毛蒜皮,可是这样一些工作却保证着整个团队的努力最终可不可以得到一个满意的回报.没有道理要求PM参与到编码中去PM也没有义务哪样做,毕竟他/她是一个manager,做好自己的本分工作胜于面面俱到.

我也同意PM需要有一定的技术基础,但是不用对于当前项目的技术非常熟悉甚至于精通.没错,PM需要对于项目的关键因素进行估算,但是这个工作不能只交给PM完成,应该由各方面的key man来共同完成.至于code review,更没有道理要求PM参加了, 项目中的architecturer和senior developer到哪里去了?

恩,总而言之,中型到大型项目的PM并没有必须要求熟悉技术以及参加代码评审的义务.毕竟,项目的健康进行才是他们的工作职责所在. 而项目管理从某种程度上来说是比代码编写更有挑战性的工作.

能不能把这个问题再说得深入点呢? 我的设计现在被review得让人很头痛. 人人都可以对它提意见,要知道每个人都可以做一套OO的设计,在缺少一个在设计方面绝对power的人的团队里,人人都会认为自己的设计是最好的.  我的设计就经常被teamleader ,被pm(兼技术leader)枪毙. 我都快成了不是在满足需求而设计了, 而是在满足其它人的审美观. 我自己感觉最后弄出来的东西不伦不类,而且工作的效率也非常糟糕.

我不是说不提倡review,我觉得review的前提是,review的人的能力应该显著的比被review的人高一档次.