谈起团队合作，一个绕不开的话题就是我们的项目经理（Project Manager，PM）。要注意这里面的M就是Manager的意思。在第一讲中我们提到过，Manager处理的是“人”与“资源”的关系。

    下面我们就可以看到，其实在大部分公司，项目经理并没有做Manager应该做的事情。只有在第四阶段，项目经理才真正开始接触“人”与“资源”调配这个哲学问题。

项目经理的发展脉络

    在我们公司，对项目经理的期望以及项目经理实际达到的效果经历了（或即将经历）这四个阶段：

• 第一阶段：基于催项目进度的需求
  • 项目团队：总线模型
  • PM特点：简单粗暴，立竿见影
• 第二阶段：基于协调各方的需求
  • 项目团队：管道过滤器模型
  • PM特点：躬身入局，尽心尽力
• 第三阶段：基于内外对接的需求
  • 项目团队：MVC模型
  • PM特点：外部斡旋，内部推进
• 第四阶段：基于资源配置优化的需求
  • 项目团队：解释器模型
  • PM特点：回归初心，快就是好

1. 第一阶段：基于催项目进度的需求

    下图用两个不同的曲线描述了一个项目，在有项目经理跟没有项目经理情况下的实施进度。在图中，横坐标是时间，纵坐标表示项目完成进度情况。

    最理想的情况下，项目进度随着时间是线性的，就像上图上面的曲线一样——当时间过了20%的时候，项目完成了20%；当时间过了50%的时候，项目完成了50%；当时间到了100%的时候，项目完成了100%。

    但实际情况下跟理想中的进度仍然存在差距。项目可能因为一些其他突发事件的冲突而被搁置，也可能因为开发人员的拖延症而迟迟没有进展。就像图中下面的曲线一样——时间过了50%的时候，项目完成度可能只有20%；直到项目的最后开发人员才奋起直追，甚至在最后的20%的时间里完成了50%以上的开发任务。这还是比较好的情况，更常见的一种情况是到了deadline之后项目还没完成。

    所以这个时候就诞生了对项目经理的第一阶段的需求——基于催项目进度的需求。项目经理可以把任务拆解，并把任务的计划节点给制定出来，就像上图中直线上的四个点一样。项目经理要求开发团队在项目20%的时候一定要完成20%的任务，在80%的时候也一定要保证完成80%的任务。即便微观上看来每一个小阶段的开发任务完成曲线仍然像图中下面的曲线一样，但至少项目延期的风险也被控制在了很小的范围。

    在这个阶段，团队成员一般都是总线模型。每个人都依靠着自己的主观能动性与责任心，尽最大的可能性把自己负责的事情给做好。但因为流程规范以及每个人的职责边界都没有定义清楚，所以产出的产品质量存在很大的潜在风险，这也符合我们前文中提到的总线模型的基本特征。项目经理的特点就是“简单粗暴，立竿见影”，因为有项目经理，即便是用那种很简单粗暴的手段，项目的进度也能被大大的推动起来，可谓药到病除、立竿见影。在这个阶段跟开发人员太客气的项目经理，很可能不能胜任。

    在第一阶段，项目经理往往跟开发人员是一种相对敌对的关系。开发人员会有一种怕项目经理的感觉。但就项目经理本人来说，其实过得还算比较滋润。他们工作上面临的最大挑战是对进度的强烈要求，与开发人员的“追求完美”的目标之间的冲突。这种现象在一些责任心特别强、主观能动性特别高的开发人员（我们所谓的“优秀的工程师”）那里冲突更加激烈。

2. 基于协调各方的需求

    在上一个阶段中，项目经理在不断的跟开发人员催进度。开发人员或多或少都会说一些导致自己不能按时完成的外部原因（而不会把事情归因到自己身上）。这里面有一些可能会被项目经理怼回去，但有一些原因连项目经理都可能被说服。这个时候项目经理就开始去找问题的上游。久而久之，项目经理对项目的参与度越来越高，项目经理也会参与项目开发管理、流程的梳理、每个角色开发责任的确定等事情——项目经理也躬身入局了。

    躬身入局之后，整个团队每个角色的职责也都被定义清楚了，以前的总线模型的合作团队也很可能变成了管道过滤器模型。在这个模型中，每个人各司其职，做事的效率也比较高。团队的成员也慢慢发现，每次自己提出来的问题与困难，项目经理都愿意帮助自己去解决，就逐渐养成了“凡事就找项目经理”的观念与思维方式。

    项目经理跟开发人员在这个阶段是一种比较亲近的关系。但项目经理会比较累。一方面是因为从总线模型到管道过滤器模型的转变过程，是每个人职责的确定的过程，这个过程中其实也是每个开发人员划分地盘、讨论工作边界与接口的过程，此时难免会有大量的撕逼的事情存在。而且往往会因为职责定义的不够清晰完整，一些三不管地带暴露的问题的追责会让项目经理以及团队开发人员很是心累。另一方面是因为在这个阶段中，团队成员“凡事就找项目经理”的观念非常浓厚，某个开发人员想要跟另外一个开发人员就某个问题进行沟通可能也会让项目经理去转达、让项目经理深度参与其中。

3. 基于内外对接的需求

    在上一个阶段中，团队开发成员养成了“凡事都找项目经理”的习惯。一方面项目经理本身精力也是有限的，这方面的需求很多都不能及时满足开发人员。另一方面，团队开发成员也慢慢意识到了很多事情其实自己直接去找相关业务的对接方进行沟通就行了，不需要叫上项目经理。慢慢的，项目经理在团队具体的项目开发中的作用就被减弱，与此同时，项目经理在对外沟通中作用被增强。这里的对接不光是跟上游客户需求、供应商之间的沟通，还包括跟工厂、客户交付方面的沟通。

    在这样的情况下，项目团队变成了MVC模型——团队开发人员相当于Model，负责核心技术的开发，而项目经理相当于Visualization和Controller，对外负责信息对接，对内负责内部资源的协调。因为流程、职责已经在第二阶段被定义并运作了一段时间，项目开发团队内部就会逐渐摸透各个项目之间的套路，建立了一套能够更加灵活的应对各种不同项目的机制，项目开发的效率也会大大提高。在这个阶段中，项目开发的规范性也得到了大大的加强，对客户的形形色色的需求也能够非常及时快速的去响应。开发团队本身的气氛也会变得比较好，团队慢慢的开始更加关注人员的培养，人才成长进步也会比较明显。

    项目经理跟项目开发团队之间的矛盾会比第二阶段高。主要是因为项目经理对接外部客户，客户的欲望其实是无限的。他们希望你的产品性能足够好，希望你的产品能给他做深度定制化，希望你的产品能价格足够低，还希望你的产品在推广的时候就能有样品送到他们手上他们可以直接开展测试。项目经理此时需要内外斡旋，努力协调好外部需求跟内部团队实力之间的差距。在这个阶段，项目经理已经不会像第二阶段那么累，但对项目经理技术上的要求会空前提高。项目经理必须不断的学习产品所需要的基本技术基础知识才能跟客户取得比较好的沟通。而且项目经理在这个阶段会非常心累——在外面被客户怼，回到公司之后被自己的Leader怼，自己遇到的困难说出去被其他项目经理鄙视，内部推动项目的时候又被开发人员怼。项目经理这个时候里外不是人，必须要有足够强大的内心，要不然很可能会不能胜任。

4. 基于资源配置优化的需求

    在上个阶段中，项目经理也帮助捋清了团队的流程，定好了各个岗位的职责，也经历了团队内部外部的斡旋与项目推进，见识了团队合作中的各种大风大浪之后，项目经理们也总结出来了一套管理好项目的哲学。他们知道哪里是项目管理的重点，哪里可以稍微放一放。他们知道哪些事情自己必须亲自去抓，哪些事情不去抓团队成员也能很顺利的做好。他们知道团队风险点有哪些，可以只去关注重要的事情与有风险的事情。在这个阶段，项目经理甚至已经搭建了一个很好用的项目管理平台，通过一些客观的数据，来发现项目宏观上的一些问题与潜在风险点。有了这些工具、平台以及经验的支撑，这个时候团队已经变成了解释器模型，一个项目经理同时负责十多个项目也变成了可能。

    当经历过第二、三阶段之后，团队开发人员的输出质量也有了较大的提升。项目经理手中的资源也比前几个阶段丰富的多。资源的丰富，同时也意味着公司运作成本的提高——每天公司为了这些资源都要花费数万、数十万、数百万元。为了尽可能帮助公司节省成本，这个时候项目经理的使命也开始回归初心：快就是好。他们这个时候可以从更高的视角去看自己所能掌控的“人”与“资源”，从公司整体利益出发去帮助公司效率更高。

    这个阶段要达到“快”的目标，所要做的以及所能做的已经跟第一阶段完全不同。只有在这个阶段，项目经理才真正是项目的Manager。

项目团队的发展脉络

    说完了项目经理的发展脉络，我们来简单看一下项目团队的发展脉络。

    我们时不时会听说有的人，“资料丢群里，要干什么也不说，谁来干大家也都不知道”。一听这样的话，我们就知道这个团队十有八九就是总线模型的合作模式。在这面这个图里我们也可以看得很清楚，团队运行的模型其实也是一个团队做事情负责程度以及专业程度的一个大概体现。一个Serior的团队，或者一个Senior的Leader，更可能采用的是右半边的模型。而一个做事更专业的团队，更可能采用的是上半边的模型。

    当然了，总线模型稍微改良一下就变成了管道过滤器模型；MVC模型也很容易转化为解释器模型。这些转化做起来水到渠成，转化之后原来的工作模型的弊端就会大大降低。