一个实施 + 一个软件负责人 = 项目经理？

Posted 2022-12-08 张传波

有朋友提到：

我们的项目经理都是实施 实施不懂技术 不懂估算工时、进度至做需求调研但是调研效果非常不好。

我们现在项目组成是这样一个实施+一个软件负责人作为项目经理。

我们分实施部和开发部，但都很委屈不管是实施项目经理，还是软件负责人。

俺的建议：

让实施的做项目经理，这样也很不错噢！
好过让只懂项目管理大道理的人来做。
估算、进度、需求做不好，最后做实施时就很受罪。
所以，你们的项目经理应该有条件和前提做好前面这些事情的。

实施部和开发部的同事可以坐下来好好谈，或者打一架也行。

主因就是你们因为分属于两个部门，利益没有能拧在一起的原因。从公司大领导的角度看，这样的部门设置和项目岗位设置，导致了这样的问题。大领导应该指导唯一的项目经理，统管全局。

开发部经理和实施部经理可以商量，每个项目只设立一个大头，由他统管全部。例如：项目1可以由开发部做头，项目2由实施部做头。不固定，大家都有机会做头。开发部经理和实施部经理，在项目启动会上要求所有人必须全力为项目服务，听从项目经理的安排。

至于互相不理解对方工作的问题，可这样解决：
开发部门需要派人常住实施部，实施部反之也要派人常驻开发部。

至于这个问题：缺乏能统筹管理的项目经理角色
这个问题首先是授权的问题，这个项目经理不能统管开发和实施。授权到位，人才能往这个方向发展，统筹项目全局的人很快就会诞生的了。
一般来说，开发的去熟悉实施，相对来说比较容易；实施要去懂写代码，就比较难，但实施因为经常战斗在第一线，接触客户，他的优势也是很明显的。

开发部老大应该和实施部老大好好谈谈，再拉上上面的老大，三人一起谈。梳理清楚关系，明确大家都要以公司利益为根本出发点。如果你们公司没有什么特殊的办公室政治环境，应该可以解决这个问题。如果有特殊的一些办公室政治关系，就不好说了，只能祝你好运

问题延伸：

战斗在第一线的，直接面对客户的实施，他们的反馈往往是最有价值的，但往往得不到重视。而直接开发产品的部门，确经常躲在后面，不能直接面对需求和客户。 

很多公司做大后，会按照软件生命周期模型划分若干个部门，例如：产品部（需求部）、研发部、质量部、实施部等，这些部门往往会将研发的过程切割为若干个上下游。成立这些部门的初衷是希望可以各环节做得更专业，但带来的副作用就是各部门只看自己部门职责，没有回到项目利益和公司利益为根本出发点，各部门协作成本大大提升等。 

强矩阵的部门架构才比较合适，项目小组成员来自不同部门，由项目经理统管，都需要为项目的成功负责。可惜很多公司采用的是弱矩阵架构，项目小组成员来自不同部门，各自对自己工作环节负责，没有一个“大头”来统管全局。

成为“全能项目经理”，做打工皇帝！
我在CSDN学院的这个课程，供你参考：
全能项目经理训练营
http://edu.csdn.net/course/detail/357