编辑导语：项目管理可以帮助项目团队对工作进行有效管理，进而提升业务处理效率，降低时间成本，推动项目目标的实现。那么，如何才能实现有效的项目管理？本篇文章里，作者就项目管理一事进行了总结和梳理，不妨来看一下。

项目是为向客户提供独特的产品或服务而进行的临时性任务，项目有两个重要的特点：

1. 一个是一次性的活动：项目有明确的开始和结束日期；
2. 另一个显著的特点是独特性的活动：交付的结果是独特的，所以其过程中需要创新性的活动来保证交付这个独特性的结果。

因此：

• 修建一栋楼房是项目；
• 开发一个新产品是项目；
• 植树也是一个项目。

通过有效的项目管理，你将获得更多的时间和更少的花费。

团队在微观层面做出的决策，在一天中的每个小时，都可能与预期产生差异：

• 与时间排期和预算之间产生差异；
• 在最佳的或仅仅足够的功能集之间产生差异；
• 在拥有让客户满意的产品或只是一个新产品样品之间产生差异。

在企业中，项目和操作是相对而言的，操作是周而复始、循环往复的活动，这种活动不需要创新。

举个例子，鞋厂工人按照 SOP 标准作业指导书制造产品：

工人需要把鞋帮和鞋底粘在一起，用多少胶、施加多少压力，操作指导书已经规定，日复一日、循环往复按照规定生产。

对于研发项目来讲，通常可分为 4 种类型：

1. 产品预研项目；
2. 产品开发项目；
3. 技术预研项目；
4. 技术开发项目。

一、什么是项目管理？

产品开发项目不能孤立地优化，这些项目在资源方面存在依赖关系，也可能共享可以降低成本的协同效应。

项目管理是指在企业有限的资源下，通过项目经理和项目团队的共同努力，运用系统的理论和方法，对项目所涉及的全部工作进行有效的管理。

项目管理是一项技能，用于管理项目以及项目之间的联系，以优化整个项目。

也即，在整个项目生命周期内进行计划、组织、指挥、协调、控制和评价等管理活动，以实现项目的目标。

1. 单项目管理

使用跨职能团队模型，通过定义项目经理和团队成员的角色，在项目中建立团队以取得成功。

成功的公司还会控制一个项目与另一个项目之间复杂的依赖关系，从而节省资源，同时帮助防止项目相互妨碍。

而单个项目管理的有效性一般通过三个方面来保证。

1）核心小组（Core Team）： 一般是指跨职能团队。

核心小组是指有权开发特定产品的一个小型跨部门项目小组：

• 一个典型的核心小组有 5-8 个成员；
• 有权也有责任管理所有与开发该产品相关的任务。

这些特定任务分配到核心小组的每个成员身上，每个成员都利用为该项目服务的人员完成这些任务。

2）阶段性审核过程。

3）结构化的管理方法：端到端的管理。

在项目管理上，如果一个项目的成功单纯依靠人的自觉性来保证，是很难取得持久性的成功。

因为人是复杂性的，必须建立一套管理机制，用管理的确定性来应对人性的不确定性，才能带来持续的成功。

下面是一个经典的项目管理案例。

有一个植树搞绿化的企业，在公司内部设置有五个部门，分别是：

1. 运输部门；
2. 挖坑部门；
3. 植树部门；
4. 封土部门；
5. 浇水部门。

在植树节前，公司总经理把各部门负责人召集在一起，召开了植树项目动员大会，要求各部门紧密配合把这个项目高质量完成。

各部门经理回到部门后，又分别把任务分配给了部门中的小赵、小钱、小孙、小李、小周，也就是说在植树项目中：

• 小赵的职责是负责运输；
• 小钱的职责是负责挖坑；
• 小孙的职责是负责植树；
• 小李的职责是负责封土；
• 小周职责是负责浇水。

在植树项目现场，虽然部门之间人员配合存在着这样或那样的问题，如：

• 小孙抱怨挖的树坑太浅影响了植树；
• 或者植树的小孙没有把树放直；
• 封土的小李对植树的质量不满意，爆发了诸如此类的各种问题。

但大家最终还是能够配合起来，项目能够缓慢向前推进直至结束。

几个月后，公司发现所种的树大面积枯萎死去，把死去的树拔出来后发现，树根上包的塑料布没有被去掉，树根最终因为吸收不到足够的水分而死亡。

出了这么大的问题，公司要追究责任，为什么花了那么大的人力、物力、财力，种的树还没有成活？

企业开始实施项目复盘，复盘是指企业在项目中后期通过回溯的方式，总结成功经验或失败教训，为以后项目运作提供借鉴，防止以后项目再发生类似问题。

在项目复盘会议上，各负责人陈述了职责与实际工作情况：

• 负责运输的小赵说辛苦地把树从购买地运到了植树现场，摆放得很整齐；
• 小钱说我的职责是负责挖坑，我把坑挖得又圆又深，质量合格，出了这种事我没有责任；
• 小孙说我的职责是植树，我负责把树在坑中立得直直的；
• 小李说我按要求把土封上了，而且还用力踩上几脚，出了这种情况我没有责任；
• 轮到小周发言了，他说我的职责是浇水，我已经按照要求浇了水，出了这种事我也没有责任。

植树现场的每个人都没有问题，但结果是树没有成活。

在企业项目过程中，类似的现象也时有发生，项目结果是失败的，但各个部门都能够把自己成功“洗白”。

就上面植树的案例而言，往常情况下，运到现场的树没有包裹塑料膜，所以在以往的部门职责中，也没有明确要求哪个部门要把塑料膜解下来。

因此，各个部门按照原来定义的各自清晰的职责去种树，树是种上了，但由于塑料膜的原因，成活率大打折扣。

项目管理是“端到端”的管理，在起点就要明确终点的目标。

例如，种树的终点目标是把树种下去、并且要成活。

“端到端”管理的对立面是“段与段”，所谓“段与段”就是马路警察，各管一段，虽然每段都不错，但结果就是有问题。

项目管理端到端的思想就是要指定端到端的项目管理人员，而不仅仅是指定段与段的负责人。

就上面的种树，如果公司以项目管理模式管理此事，就会指定一个种树的项目经理，这个项目经理就是“端到端”管理者。

其重要目标是种上树、并保证树的成活率，而且会作为一项绩效管理目标，甚至作为对其绩效管理的依据。

在项目实施过程中，由于项目是创新性的活动，就会出现这样或那样不可预知的现象，因为项目经理的职责是保证项目最终目标实现。

作为端到端管理者，项目经理在项目现场，会根据项目现场出现的新情况进行管理和决策，直至最终目标实现。

2. 项目群及项目群管理

当多个团队管理相互关联的项目时，公司会扩展到项目级别，是指把项目链接在一起并作为一个整体进行管理，也即项目群管理。

相互关联的项目一般体现在两个方面：

1. 产品针对相同或类似的市场；
2. 产品基于相同或类似的平台和技术。

项目群管理是一种能力，它允许公司通过巧妙地管理各个项目和产品之间的协同作用和依赖关系，交付成功的新产品或服务。

• 项目群是一组相互关联的项目的集合；
• 项目群管理是指对项目群进行统一协调和管理，以保证项目群整体绩效最大化，而不是单个项目绩效最优。

注：项目群和项目组合概念来源于美国项目管理协会制定的 PMBOK。

以项目群（新产品开发项目）为例：

新产品开发项目可以看作由各个领域子项目组成的项目群。

• 一个项目群配备一个产品开发项目经理，负责项目群的管理；
• 各个领域子项目的项目经理作为产品开发项目的核心代表，由他们负责领域内单个项目的管理。

这种项目群管理方式能够方便地实现：

• 各单个项目之间的信息共享；
• 协调项目之间的依赖关系；
• 解决项目人力资源共享和冲突的问题；
• 共享对外沟通渠道；
• 避免独立管理单个项目存在的风险。

3. 项目组合及项目组合管理

项目组合是为实现组织战略目标而组合在一起的项目、项目群和其他工作，项目、项目群是项目组合的一个子集。

它是站在整个组织层面上，对现行组织中所有的项目进行计划、组织、执行与控制的项目管理方式。

项目组合中的项目/项目群不一定彼此依赖或有直接关系，这点与项目群中各项目之间的依赖关系是不同的。

项目组合管理继承了单项目管理中的理论和方法，不同的是，组合项目管理把关注焦点从单个项目内部转向多个项目之间，强调了项目之间、项目与组织之间协调一致的关系。

项目组合管理通过项目/项目群的组合，合理分配组织的有限资源，实现资源效益最大化。

以某厨房家电企业为例，所有项目都是为实现企业业务目标服务的，这些项目、项目群之间可能有依赖关系，也可能没有依赖关系。

但都要由企业来管理，通过协调、指导和决策，保证这些产品开发项目和项目群的方向和资源配置。

项目组合关注的是选择做哪些项目，项目群关注的是如何把已经决定要做的项目完成得更好。

二、什么是「管道管理」（Pipeline Management）？

管道管理是指结合企业的业务策略，对比分析核心业务和非核心业务，实现开发项目的优先级排序，以及所有资源的动态平衡，最终使投资效益最佳。

管道管理将产品战略与项目管理/职能管理联系起来，从而更合理地部署企业内与开发相关的资源，包括人员、重要设备、辅助设施等资源。

随着企业竞争压力的增大，企业就必须超越项目级的成功管理，而要对研发的投入作整体管理，这就需要在产品开发的投资结构平衡中进行更有效的管理。

为了达到这种平衡，企业必须设法使其开发管道处于最优性能水平上，必须作出更加完善的资源分配决策，以反映各项目之间的相互关系。

企业不但要考虑某一特定产品机会的优势，同时要考虑怎样才能让项目总体结构适应企业的产品战略前瞻。

此外，还应更有效地将产品开发决策整合到职能部门预算中去，因为职能部门预算是企业运作计划的一部分。

因此，对于在多个竞争资源的项目之间进行有效地平衡资源而言，管道管理是必要的。

管道管理主要针对下述这些问题：

• 产品战略与实际的企业能力和资源脱节；
• 职能部门的预算与项目计划不一致；
• 出现始终延误项目进展的组织瓶颈；
• 缺乏按计划补充项目所需的人力资源；长期的“救火”现象等。

管道管理主要通过以下三种活动来实现：

1. 战略平衡

战略平衡将产品战略与企业的能力和资源紧密地联系起来，它是一个反复迭代的过程，目的是选择出有利于企业发展目标及可行的开发项目。

• 对众多机会制定优先顺序；
• 对企业能力进行调整，以期拿出新产品。

在各个团队层面上，明确领导者在决策过程中所扮演的职责，可以改进项目管理。

在流程早期定义项目的关键参数，然后制定清晰的升级路径以帮助项目经理在团队开始偏离项目目标之前让他们重回正轨。

战略平衡限定了集成组合管理团队（高层决策团队）在阶段性审核过程中的决策授权，也限定了职能部门管理者有关资源分配的决策授权，从而避免官僚成分对产品战略的干扰。

主要使用了三种工具：

1）项目总体进度表

进度表是一个优化的开发主导计划，是产品战略的具体化：按时间排序的项目暂行进度表。

因而在阶段性审核中，它被用作各核心小组分配和特许资源的依据。

根据核心小组阶段性审核材料、管道载量分布情况及战略方向的调整等，进度表会不断地得到更新。

2）管道载量分布图

用于控制和维持管道的平衡，以便在最大限度上增加产品开发的输出。

在战略平衡过程中，该分布图用于制订项目总体进度表，使之与企业所拥有的与开发有关的资源和技术容量相吻合。

在开发的全过程中，该分布图一直作为控制和管理开发管道及职能部门管道的依据。

总体管道载量分布图作为总体管道载量的上限，用以保证项目和各职能部门的需求不会超出公司的资源容量。

为重要职能部门进行监控的各职能部门管道载量分布图会定期修正，以确保职能部门和技术技能之间保持平衡，避免产生“瓶颈现象”而降低整个管道的速度。

3）同步化的职能预算

与传统的职能预算的形成方式不同，它不是将各项目、各职能分散、单独地看待，而是通过战略平衡，把各项目和各职能部门的需求（如维修保养、追加投入、主要设备、过程改进等等）作为输入项目，在企业有限的资源和资金内进行调配。

项目之间、职能部门与项目之间不再为争取企业的有限资源而竞争，相反，鼓励它们互相合作，争取在整体战略上，以有限的资源创造出最大的效益。

但是这些同步预算必须具有一定的灵活性，使资源可以顺利地从一个职能部门转到另一个职能部门，以应付不可预计的项目差错。

2. 管道容量控制

通过增加阶段性评审过程中的决策透明度，来实现资源分配的微调。

虽然许多公司都设有阶段性评审，但都未用于优化开发管道，因为每个项目都是独立进行评审，而完全不考虑其它项目,因此就造成了管道的堵塞，

例如：

• 市场部只有招架的能力：一方面尽量满足一线的各种紧迫要求，另一方面，还要在其它产品的上市方面下功夫；
• 采购部也正超负荷运转，致力于解决卖方交货问题及尽量减小价格波动；
• 一些研究和开发部门的关键人员常常被召去解决一线出现的问题和产品生产线上的问题；
• 由于与其它项目重复，导致在瓶颈区域如进度、人员能力、交付周期等 方面的原因导致延误，尽管核心小组成员多方努力，局面还是难了挽回；
• 高级管理层不得不从其它项目抽调资源以解决项目的问题，因而引起其它管道混乱,很多项目处于”救火”状态。

影响管道容量的因素主要是三大因素：技术稳定性、变更控制力度、项目管理水平。

只有收集了必要的跨项目的数据和资料，阶段性评审工作才得以加强，IPMT 团队才能够优化整个管道的运作，优化的原则如下：

• 最佳实践表明任何组织应该把资源容量的 85% 分配给承诺的项目；
• 剩余 15% 用于职能提升、教育以及非计划项目；
• 有效的组织资源平衡（不是超负荷）导致更有效的资源利用。

3. 协调项目与职能部门的交接

确保无论是短期内还是长期内，职能经理都能使项目资源在企业里得到最大程度的流动。

职能经理对通过他们各自部门的项目工作量负责，实际上，他们管理着开发管道的一个部分。

协调职能交接的目的是不断优化管道以达到最大可能的流通量。在这种环境下，职能部门和项目是整合在一起进行考虑的，没有完全区分开来。

各职能经理共同努力，争取有更多的项目通过整个管道。他们不再仅仅关心各自的部门，而是积极地配合上游和下游职能部门迅速解决各种各样的问题。

协调职能交接要考虑到涉及所有开发相关部门资源需要的执行行为，包括：

• 产品开发；
• 技术开发；
• 产品辅助活动，例如：市场支持、生产故障排除和持续的监理等；
• 也应考虑一些重大的举措，如实施新的技术体制和改进开发过程等。

上述各种活动，只有产品开发活动由核心小组和阶段性审核小组负责完成，其它的活动将完全依赖于各职能经理根据具体情况通过战略平衡来完成。

为各项目安排人员常常是很困难的，因为每个核心小组通常都希望得到最好的人手，而且希望得到的数目也比实际上真正需要的多。

这样，在保证职能部门目标的前提下，与各项目的核心小组成员共同努力，合理地分配有限的资源就成为职能经理的职责。

与相关核心小组成员的密切合作，使部门经理能够确保每个项目计划都是高效的并且是可以实现的。

如果他们能运用过去的经验（如对以往项目周期的认识等）着手制订切合实际的计划，那么，他们的工作便简单多了。

同时，职能经理还必须为非产品开发行为配备人力资源。

高绩效团队对于项目群管理至关重要，然而，大多数公司低估或忽视了高绩效团队合作带来的好处和机会。

高绩效团队合作是世界一流技术公司 DNA 的一部分，对项目管理的有效性至关重要。

当然，也有许多低绩效团队英勇地将产品推过终点线的例子，但是往往会付出更高的机会成本：

硬成本：

• 延迟收入；
• 更高的产品成本；
• 低质量产品的更高支持成本 ；

软成本：

• 缺乏创造力；
• 团队疲劳；
• 士气低落；
• 糟糕的产品评论；

从敏捷的角度来看，团队应该是自我管理的。

要通过改进项目管理进行创新并将成功的产品推向市场，需要做以下四件事：

1）实施跨职能团队模型

实施跨职能团队模型是优化项目绩效、确定减少周期时间的机会以及确保更广泛的团队（也称为扩展团队）有效运作的最有效方法。
当团队规模庞大且地理位置分散时，这一点尤其重要。

团队的多地分散管理已成常态，实施跨职能团队模型可以优化项目绩效、减少周期时间，以及确保团队有效运作。

跨职能团队模型由四到六个职能领导组成，通常来自项目管理、产品管理（产品负责人）、工程、设计和质量保证，他们分担在既定目标内交付项目的责任。

这个由项目经理领导的跨职能团队经常开会，负责与地理上孤立或处于次要职能的扩展团队进行沟通，项目经理在这一领导角色中至关重要。

为每个项目创建一个项目团队车轮有助于澄清跨职能团队和支持组织之间的关系。

2）为跨职能项目管理团队创建明确定义的角色和职责

随着公司规模的扩大和地理范围的扩大，对角色和职责的详细定义成为项目管理中越来越重要的组成部分。

清楚谁在做什么？什么时候做什么？将使团队能够专注于创新和将产品推向市场所需的工作。

3）赋予项目管理跨职能团队高级别权力

赋予团队很大的责任是吸引最优秀人才的战略投资，高绩效团队由高绩效者组成，无论是个人还是团队。

高绩效者因责任感而茁壮成长，因此，如果你让团队承担责任，你将提高留住最优秀人才的能力。

4）营造信任与协作的文化
只有在信任和协作的环境中工作，团队才能在项目管理中取得高绩效。

当团队知道他们可以在不涉及政治的情况下发布坏消息（以及缓解和解决建议）并且不玩弄数据或指责时，他们就会实现高性能。

他们专注于解决问题，而不是找出罪魁祸首并责怪他们。

三、总结：项目管理能力提升了，产品开发就一定能成功？

项目管理的成功不等于产品的成功，项目管理的成功表现在进度满足要求，开发费用降低，企业获得了必要的知识、经验。

但对于产品开发项目来说，最终的目标是实现产品的市场成功、财务成功。

企业的需求管理、产品规划、产品立项和产品开发以及上市管理，都会影响到产品的市场成功。

因此，卓越的项目管理能力需要依托卓越的平台来支撑，包括：

• 正确的战略指引；
• 成熟的产品管理体系；
• 成熟的技术管理体系；
• 成熟的能力保障体系；
• 成熟的绩效管理体系。

这些保障体系能够：

• 帮助企业减少紧急需求的数量，避免产品开发中需求的临时变更；
• 还能提供高质量的产品路标规划和资源规划，保证产品开发方向正确，减少资源冲突和版本过载。

通过平台化的产品管理战略，让产品开发更能够做到“多、快、好、省”（产品多、速度快、质量好、资源省）。

实现多个项目共享一个技术平台，快速推出面向细分市场的产品，同时产品质量得到保障、开发成本得到有效控制。

产品开发项目的持续成功，离不开人的能力，特别是项目管理能力和各领域的资源能力。

职能部门经理是构建卓越的资源能力的主体，包括输出合格的工程人员和核心代表、打造高效的领域流程。

比如，硬件开发部经理、软件开发部经理、供应链部门经理分别要打造卓越的硬件开发子系统、软件开发子系统、供应链子系统，并提供支撑流程运作的相关工具、方法、设备等。

职能部门经理要与人力资源部门一起制订员工培养计划，使能力建设的规划匹配业务发展的需要。

业务是由一个个项目构成的，职能部门的能力建设要为项目服务，因为项目经营的好坏会直接影响到业务目标能否实现。

项目经营的好坏，除了与人的能力有关，还与人的意愿有关。

因此，绩效管理在项目管理中的作用也不容忽视。

很多项目经理经常会抱怨自己有责无权，项目团队难以管理。

造成这种问题的原因有很多，其中常见的就是缺乏规范而有效的项目绩效管理和激励机制，不能调动团队的积极性，团队缺乏一致的目标和积极的团队文化。

#专栏作家#

卫Sir，公众号：简一商业，人人都是产品经理专栏作家。关注智能硬件领域，擅长市场分析、产品设计开发、生产管理等，喜欢阅读和爬山。

本文原创发布于人人都是产品经理，未经作者许可，禁止转载

题图来自Pexels，基于 CC0 协议