编辑导语：产品经理在岗位上需要明确自己的职责，项目经理也不例外。但是，由于工作内容的原因，许多人对项目经理的职责范围可能有所混淆，具体而言，项目经理可以分为哪些类型？不同类型的项目经理各自的角色特点是什么？项目经理究竟应该负责哪些事项呢？
前几天又有点激动地发火了，俗话说“火大伤身”，不应该发火！后来想想也不至于，毕竟身上脂肪较多，完全可以吸收，说不定发火还有减肥之功效呢。
废话不多说，事情大概是这样的：
某项目组找我来评估项目任务和资源，作为研发团队的领导做这个是无可厚非的，但是过程中，不论是该项目负责人还是他转述业务团队负责人的意思里，明显具有甩锅的嫌疑。说我是研发的负责人，项目的资源，外包的流程、整体的统筹和风险管理都需要我来负责。
作为专业线的领导，我可以为项目的开发质量、技术规范、方案合理性负责，所以我评估了项目组的资源评估是合理的，也阐述了研发团队目前无额外资源可用，建议启用外协团队支持，我做了我该做的职责。如果让我完成该项目负责人认为我应该完成的工作，承担相应的责任，我问他项目经理做什么？项目经理该承担什么责任？
他说，项目经理负责和客户的沟通，开各种会议，需求的收集巴拉巴拉。技术开发就是研发团队的活，当然这些需要你们研发团队承担。乍一听好像没毛病，但细想好像又不对，各位读者你们认为呢？
今天，我们就来扒一扒什么是项目经理？他的职责范围到底是什么？
项目经理( Project Manager ) ，从职业角度，是指企业建立以项目经理责任制为核心，对项目实行质量、安全、进度、成本管理的责任保证体系和全面提高项目管理水平设立的重要管理岗位。
它要负责处理所有事务性质的工作。也可称为“执行制作人”（Executive Producer）。
项目经理是为项目的成功策划和执行负总责的人。项目经理是项目团队的领导者，项目经理首要职责是在预算范围内按时优质地领导项目小组完成全部项目工作内容，并使客户满意。
为此项目经理必须在一系列的项目计划、组织和控制活动中做好领导工作，从而实现项目目标。
——百度百科
百度百科对于项目经理的定义中所说，项目经理是为项目的成功策划和执行负总责的人，而项目中不论是开发人员还是测试人员还是其他岗位，都是项目经理推进项目的各种资源，请问你要把锅甩给谁呢？不论甩给谁，这些责任你能撇清楚吗？
当然，如果我们仅通过百科定义来下结论，基本写到这里就结束了，但是熟悉老谭写作风格的朋友知道，这里仅仅是1/3，那就继续扒吧。
其实冷静下来后再去想一想，对方其实也不一定是故意甩锅，可能是每个人对于项目经理的职责范围的定义不同而导致的认知差异。在一个项目中，项目经理有多大权利，可以动用哪些资源，取决于项目管理模式，项目管理模式由公司的CTO（或者组织体系）来决定。简而言之，项目管理有三种模式：项目型、职能型、矩阵型。
1）项目型
将所有的能兵强将集结在一起，形成一个正式的部门，并由项目经理领导。
这样的优势是项目经理的权利很强、资源充足，所有的项目经理都希望有这样的团队。但是就公司而言，单独团队对公司整体资源的浪费，是显而易见的；对被抽调的个人而言，脱离了原有的部门进入新的团队，一旦项目结束，这些精兵强将又面临着新的岗位的安排。
一般的项目很少通过组建一个实体团队的方式进行，除非是周期很长的大项目，比如拿下一家大型医院的信息化建设项目，建设周期普遍需要两三年的时间，项目中的这些人基本上全部投入到这个项目中，就适合采用项目型的管理模式。
2）职能型
对于项目经理来说，这种情况可是最惨淡的了，无权无资源彻底杯具了。
所有项目人员还在属部门里面供职，仅仅花费小部分的时间来处理项目的事情。特别他们还有相应的职能经理，这样的双重管理，对于项目来说是最可怕的了。当然好处也是有的，就公司来说。为这个项目消耗的资源不是很多。个人来说，还在自己的萝卜坑里面。
这样的项目是我们工作中最常见的，一些短周期的小项目，或者需要多个部门一起协同处理的非常规性的项目。
比如我们科技型的企业经常会有科研课题申报的项目，每个项目什么申报的过程其实也是一个项目管理的过程，在这个项目中就需要市场部、产品部、研发部、财务部、人力资源部等，甚至有的公司有专门做课题申报的部门一起协同完成，这时候项目经理更多的是组织协调角色。
3）矩阵型
这可能是最微妙的组织关系了，分为弱矩阵，平衡矩阵，强矩阵。那么这个强、弱、平衡关系是如何界定的呢。就是项目经理与职能经理的权利的强弱关系决定；
- 项目经理>职能经理=强矩阵；
- 项目经理=职能经理=平衡矩阵；
- 项目经理<职能经理=弱矩阵。
其优点与职能型一样，对于公司来说资源均衡；对于个人来说稳定的岗位还在；对于你，项目经理来说横向沟通顺畅。缺点是：双重管理，纵向沟通困难。
矩阵型的项目管理模式可能是大部分公司采用的一种方式，我们公司就是采用了事业线和专业线双重管理的体系，而且在这个体系中，根据业务的性质不同，三种矩阵都同时存在。
比如事业部的研发和研发中心是一种强矩阵模式，研发中心多承担专业技能的职责；而在研发中心内部的各产品线其实优势弱矩阵模式，因为存在产品线既是职能线的情况。
权利和公司资源是对项目顺利进行的一个保障，没有权利，就不能给团队进行激励，给成员做出承诺。这样项目在进行的时候，成员的工作积极性会下降。
没有足够的资源，项目设计再好，没有人来执行，没有人来实现，那也不过是空中楼阁。
上图稍微总结一下，这几种模式的区别。很多时候我们如果不清楚自己的项目管理模式，就很难把握项目经理的责权范围，就会容易产生“甩锅”和“冲突”。
项目管理模式是一个公司都要重视的项目管理体系建设，不同的业务类型，不同的发展阶段我们采取的项目管理模式也不相同，他们没有对错没有好坏，只有适合和不适合，需要公司管理人员能够清晰的识别并合理的采用。
上面的项目项目管理模式更多是由组织管理模式决定的，其实对于IT类的项目，对外交付的项目和内部产品研发迭代的项目对于项目管理和项目经理的定义又有很明显的不同。
对外交付的项目：
对外交付的项目，其实从项目立项之前这个项目就已经运转了，只不过前期主要是商务或者销售在冲锋陷阵，研发团队提供技术方案支持。
而真正的项目管理是从项目立项开始，项目立项会上会指定对应的项目经理，因为客户交付的项目对于进度、质量、成本的控制较高，协调的人员和资源也更多样化，所以项目经理投入到管理上的精力会比较大，这类项目的项目经理主要以管理型的项目经理为主。
管理型项目经理的角色具备如下特点：
- 项目目标的实现者和责任承担者；
- 资源的协调者和运作者；
- 工作监督者；
- 客户管理者。
管理型项目经理的相对不足：
- 技术方案评估能力不足；
- 团队成员遇到技术难题时，自信不足；
- 技术风险评估不足。
管理型项目经理需要一名能充分相信的技术牛人的帮助，帮助他更好地实现项目交付。
所以回到刚开始的话题，你如果想当然地把锅甩给你这个战友，是不是就太不地道了，没有他的帮助你如何实现项目交付，因为只有项目经理是最终要向最终交付这个结果付全责的。
产品迭代的项目：
产品每次迭代的过程其实也是一次项目管理的过程，这个项目的起点往往是从产品经理确定本次迭代的需求开始，所以项目管理的环节相对于对外交付的项目要精简很多。
虽然产品经理需要具备一定的项目能力，但是实际执行的过程中，一般在开发团队中设置一个类似项目经理的角色来负责把控项目进度和质量，一般情况下技术经理就是项目经理，我们可以成为技术型项目经理。这类型的项目经理大部分仍在扮演自己技术领导人的角色。
技术型项目经理有如下特点：
- 充当救火队员，哪里需要人就去哪里补充，哪里出现问题，就在哪里出现；
- 技术核心，充当架构师或核心架构师，充当核心模块的代码编写者；
- 技术导师，团队中有任何技术问题都可以向他咨询，他也承担着带领整个团队技术进步的领头人角色。
技术型项目经理的相对不足：
- 项目规模稍大或者周期比较长的时候，因为太多精力投入到技术开发，而忽视了项目整体的控制；
- 希望用技术来解决所有问题，他对于干系人隐性需求的了解和管理明显不足，往往存在沟通问题；
- 协调资源略显不足，因为经常会将自己当做很重要的资源过度使用，而忽视了需求外力。
在产品迭代中，为什么产品经理不适合做项目经理呢？
- 产品经理的工作更多是靠想，更确切的说靠想法，一旦陷入到事无巨细的项目事务中，对于创造一个好产品不利；
- 产品经理往往不懂技术，不容易评估开发的难度和工作量，就很难进行过程的控制；
- 产品经理是需求的提出者，而项目其中一项重要的控制就是对于需求范围的控制，以降低风险，保证执行，自己控制自己，不是和谐就是精神分裂。
事事皆项目，产品经理对于研发团队来说是需求方，但对于老板来说又是项目管理者，需要给老板拿结果，也需要控制老板的需求天马行空的蔓延。
而商务人员，对于客户来说他们也是项目经理，为了保证回款，项目管理的工作也是不能少，只是管理内容更多是和客户的对接，关系的维系此类的工作。
所以每个人都是项目经理，只是我们每个人所管理的范围不同而已，所以在项目中我们一定要明确自己的职责范围，在这个职责范围内我们就是第一责任人，这其中的人和物都是我完成项目目标的资源，所以作为项目经理甩锅给项目组，门都没有！
对内甩锅不合适，因为这正是项目经理职责所在，那就只能对外甩锅，比如老板、客户等，结果发现这些人更没法甩锅，所以只能把苦往自己肚子里咽。因为我们是项目经理就要选择承受，多努力去修炼自己的技能，成为一名合格的项目经理。
#专栏作家#
菜根老谭，微信公众号：CGLT_TAN，人人都是产品经理专栏作家。经历程序员、技术Leader、产品经理、研发Leader等多种岗位。现负责某科技公司整体产品研发，擅长企业IT架构及互联网产品架构。
本文原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议