项目经理是否应该解决项目中的技术难题

ray_linn在大公司，对大公司来说资源不是个问题。技术人员中不可能没有architect或者technical lead，如果真得没有那肯定是要招一个的。对于大项目来说，没有一个好的技术人员带来的额外成本远远大于招一个员工的成本。

大公司的资源不是小软件作坊能比得上的，所以在用人，管理方面都不可同日而语。

大公司对应不同的项目给的资源也是不一样的。
大公司也不是什么项目都给你architect

有一门课叫“manage your manager", manager是你的resource，不会用还当什么pm

总结一下

1. PM是所有issue的owner，无论是技术问题还是其他什么问题，最后都会反映在PM的tracking list上

2. PM不应该为解决技术问题而亲自上阵：如果PM有技术背景，可以提供参考意见（仅仅是意见），如果没有，可以寻找相关的资源。

3. PM要解决的问题，远比技术问题多得多，如果一个公司的PM太多时间消耗在技术上，那么该公司就应该考虑他们需要的是DM还是PM了。

4. 行业背景和流程是PM的立足之本，很多技术问题是可以通过修改流程、规范等等来实现的。

把Dell的这些做法列出来想说明什么呢？给大家参考一下还是可以的，但我不觉得这些是必需的，最多是一种可行的组织架构吧。
跟踪问题列表也需要专门设一个高薪岗位么？如果每天有3位数的新问题，也许需要，否则 架构师顺便就可以做了。
行业背景和流程也更像是对BA的要求。

这跟兵器装备领域类似，小公司类似航母，上面飞机数量有限、空间有限，所以要求尽可能多功能；
而大公司像空军基地，陆基战斗机可以专业分工、各司其职。

总结的好啊！....以后一定要注意这方面！

所谓朽木不可雕也 您说得对，我何苦来着，只能充分说明一点：所谓的技术高手，常常是项目中最难搞的一环，呵呵对付这种人的经验可不能外传。

不同公司项目经理职责还不同，有些公司的所谓项目经理只不过是类似开发小组的小组长角色。


我偏向ray_linn。

项目经理不应该解决项目中的技术难题

否则就会影响到项目经理的应该做的工作

很多技术人员转过来的PJM连开一个跨部门会议的能力都没有，人家不愿意参加你的会，你能如何？