该帖子同步发自：(yanglinux的博客  访问该博客)

       往昔，职业中总会有一些意想不到的困难和苦恼，后来理清楚了——其实主要是定位不清晰引起的，希望以后不会再因为这些问题而导致烦恼，或者至少在有困难时能够理直气壮。

       什么情况下是PM（不是PM）？如果一个项目只有连同PM一起只有两个或三个人，那么项目经理肯定是需要做编码、设计甚至测试等工作的，并且其工作一定会在关键路径上，这样的PM只是一个名义上的人，其实质是一个开发leader。因为人的精力总是有限的，他不太可能有时间去做估算、去关注有哪些风险，去平衡各方的想法，他需要做的，就是赶紧干活，追进度。

       为什么国内多数做软件的PM无权也无钱？三个原因，一是国内的小项目太多，PM就是个干活的人，只是挂个名而已；二是PM经常跳来跳去，或者能力欠缺，没有树立自己的威信（地盘？）；三是公司的原因，权和钱都在职能经理以上的人手上。

       PM是否要懂技术？只是现今很多人都会提的问题。废话，当然要懂，否则需求调研、做估算、安排进度尤其是评估风险很难做（注意，难，没有说不能）。有人总喜欢拿毛主席说事，你看他老人家不会拿枪，你看他还不是指挥的非常好。哭笑不得，不会拿枪不等于不懂军事，他可是实实在在的军事家啊。就像我们做软件的PM，最好要懂开发流程、业务流程、软件工程等等的。同时，是不是技术越精通越好？不是，肯定不是。一定要避免另外一个极限——架构师，一心沉迷于编码，那谁去协调，去追踪进度，谁盯风险？

       是否要考PMP？不需要。这是我经常被问到的一个问题。PMP的通过最大的贡献就是将我从小小的困惑带入了大大的困惑，如果靠自己解决了这些困惑，那么PMP也算是大大的功德一件。一切得靠自己。

       如何界定公司层面和项目组层面的问题？我们职业生涯中很多困惑其实源于这点，公司怪我们的能力差，我们怨公司的环境恶劣。其实这个问题很泛、很大，需要专门的时间来理清楚，所谓的“事业环境因素”和“组织过程资产”不是三下两下能够说清楚的。至少，PM应该做到解决好项目组的问题，坚持科学合理的项目管理，做好本职应该做好的所有事情。