软件工程类似双项目经理的可行性探讨

“双项目经理”，看起来是一个管理非常混乱的做法，也可以说是一个很有争议的专业术语。

没错，所以标题加了“类似”两个字。

一个项目怎么能有并列的两个负责人呢？

我们可以有点灰色空间吗，完全并列或许不可能，但其实可以尝试不同分工，起码有正副之分。

当项目的庞大超出项目经理的能力范围，可以采用双项目经理分工合作，这种类似双项目经理的方式也许叫做“项目经理+迭代经理”更加合适（迭代经理一词源自ThoughtWorks，但本文并不参考他们的观点）。

然后这里罗列一下什么是软件工程项目经理？

1、有些地方认为项目经理属于搞搞关系陪客户喝喝酒来着，其实是一些销售为主的公司搞出来的，本质是销售，赋予销售更高的权力。

2、有些地方认为项目经理属于带领一队软件工程师牵头开发，其实本质上是有一位主程序员被赋予更高的权力，另一方面也忽悠着解决程序员转型问题。

3、接下来是比较正统的项目经理，项目合同签订以后，冲着项目验收为终点工作。

4、而《余世维企业管理》记载的项目经理，是一个年纪较长，资历较深，对公司各部门都有一定的威望，德高望重，可以诞生于任何一个部门或岗位，相当于是一种兼职，针对一个特定的项目，被公司选出来任命为某个项目的经理，解决公司内部跨部门沟通的问题（也许是余博士在汽车行业的关系吧）。

成功的经验

项目经理主外，迭代经理主内。对外造成一种错觉，只有一个项目经理说了算，其实分工明确。

项目经理相当于是上面的第三种，而迭代经理相当于第四种。

工作时间迭代经理会被误以为是助理，工作时间之外得是一个很好的“僚机”，还能对项目经费互相监督，项目经理请假也变成了可能，无疑降低了项目经理的能力要求。

只有项目足够庞大的情况才会采用这种工作模式。

迭代经理需要在公司内部有一定声望，且本身具备项目管理的基础，如果没有足够声望的候选人员，那么高层必须主动创造机会，不然只会让你的项目延期，增加沟通成本。

迭代经理可能要求有更高的综合素质，在软件公司内部各部门建立一定声望就需要有软件工程各阶段专业知识，尤其是面对开发部，并且结合公共关系学做好内部公关，对外还需要有良好的顾客公关意识。

需要的声望与公司大小成正比。

结束的话

我们一切都是事后诸葛亮，事前不会有这么专业的解决方案，但事后往往证明，当初的决定是正确的，对过程的重视，对细节的把握，是制胜法宝。

我们依然保持着传统的思想，只是有时候大胆尝试也会有奇效。

项目的成功，最大功劳并不属于项目经理，

架构师用他的智慧划分子系统，把复杂的系统简单化；

程序员与测试辛勤耕耘，保证进度与质量；

没有提及的每一个人都也功不可没。