技术出身的项目经理容易犯的一个错误

从技术出身的项目经理，很容易犯这样一个错误：对自以为简单的问题，分配任务给成员时，会夹带技术细节并表露出问题的简单性。

譬如X项目经理接到客户的新需求，要求更改页面上的某个字符串。于是立刻把成员A叫过来，“这个需求只要把对应页面的字符串改一下就OK了，5分钟搞定，你赶快去改一下吧”。姑且不论这个问题是否真的简单，首先的问题是，X混淆了项目经理和开发人员的界线。具体实现细节是开发人员的事，项目经理不需要关心，即使开发人员不懂如何实现，那也是技术经理的事。此外，“5分钟搞定”这种话，对开发人员来说往往是一种伤害。最常见的一种结果是，成员A下去后发现问题没这么简单，不光要修改页面文件中的字符串，还涉及到数据库中某个字段的修改，更麻烦的是，修改后单元测试一片红。5分钟的问题，最后花了一天才搞定。

项目经理一般不参与具体编码工作，凭借以往的开发经验得到当前项目中“某个问题很简单”的结论往往经不住推敲。我的建议是，项目经理最好绝口不提技术细节，分配任务就OK，譬如“目前接到一个新需求，客户要求更改某个页面上的某个字符串，你下去分析解决一下。问题比较急，相信你能尽快完成。”首先把需求描叙清楚，然后说明一下紧急性，剩下的放心大胆的交给开发成员就是了。

好的项目经理一定要时刻清楚自己的职责所在。如果因为种种原因，项目经理同时兼任技术经理，不得不参与具体编码实现，那也得时刻清楚自己的角色转变。分配完任务后，可以建议性的提及技术细节：“这个问题比较急，根据我以往的经验，需要修改对应的某个页面。你下去修改下，看能否尽快搞定。”这个例子过于简单，后面这些话基本是废话。兼任技术经理的项目经理，提及技术细节时，除非是别人不懂而自己很清楚，否则还是绝口不提的好。

有的项目经理可能会辩解说，把问题描叙得简单些，可以避免员工磨洋工。如果真有员工磨洋工，5分钟能做的活拖上一天来完成，那我觉得是整个团队建设出了问题，需要改进的是代码评审和奖惩等制度。团队建设涉及的话题太多，此处不展开了。

总之，对项目经理来说，凡事尽量二思而后行之（一是清楚的表达需求，二是换位思考，三思无必要）。