产品经理如何管理项目？

就像光无法从黑洞中逃逸出来一样，任何项目都无法摆脱“金三角”的制约，它就像一个铁律一样，任何“不遵守”三角规律的努力，都极容易陷入泥潭。

比如，原本一个几十号人的团队，能够应付一个新产品的研发。后面改成了3款新产品，还要加一点“创新性”的计划，然后又赶巧销售又接回来了两个大额的定制项目，整个研发团队，一下自从开发一个项目，变成了5个项目并行进行。

接单的时候都很开心，感觉马上有钱了，马上就能拿一笔奖金。其最终结果是，新产品迟迟不能如期上市，因为质量太差，引发一系列的用户投诉。

这种不顾现实条件，不尊重基本的客户规律，盲目把销售机会当作产品，盲目追求速度，要求工程师“并行开发”的行为，无异于饮鸩止渴的短视。

但这种现状，一直以来，比比皆是。未来，也依然会大行其道。

希望每一位产品经理也好，项目经理也好，都能够从内心深处，深刻理解一个产品的基本规律，尊重客观现实，尽可能的充分理解技术的基本原理，为了保证一个产品真正的成功，一定要保持这种敬畏之心。

从用户的角度，对生命、自然的敬畏之心，从项目的角度，对技术、质量的敬畏之心。

并且通过自身的努力，影响所处的环境，对产品、用户和技术，都抱有一定的敬畏之心。

回顾过去一系列成功和失败的项目，我认为产品经理们（虽然PM往往不一定真正具有决定性）最容易犯4个毛病：

1、关键需求遗漏：必须要做的需求，没有厘清楚，导致产品和技术的架构有缺陷，业务流程不够完整，用户体验很差；

2、镀金：这种现象特别普遍，有的功能确实有一定的吸引力，但不能构成用户的决策依据，一旦把过多的精力投入在这些不具备决策力的需求上，往往顾此失彼，产品也没有竞争力。

任何一个产品，能够保证3~5个核心卖点就足够打动用户，反过来，你需要罗列十余项“优势”，意味着这个产品基本没优势可言。

3、优先级失衡：判断优先级的依据是什么？个人的喜欢，领导的爱好，还是用户的痛点，或者技术的壁垒？

不要幻想着什么都能做，什么都可以做好。决定不做什么，比要作什么要困难很多。

4、富有想象力：基于有限的信息做出了过多的解读，把一些非关键性的需求当作了具有普适性的需求。单纯的靠想象，靠调研，靠领导的拍板都很难做出好产品，更关键的是，不要把单纯的销售机会，当作产品机会。

边界，对一个项目的成功具有决定性的影响。在一定的时间内，只可能完成一定的范围内的工作任务，有质、保量的输出相应的成果。

一个项目的完成通常需要对项目所依存的大环境有着敏感的认识和正确的理解。项目及其管理在通常情况下对环境有着极大的推动作用，但同时也被环境所制约，后者的制约通常都大于前者。

项目环境包括实施项目中的内在及外在环境。至少在3个方面对项目的实施有重大影响：

1、组织结构

组织结构对项目的影响最显而易见的就是对PM的授权。是否真正有授权给产品或者项目经理主导一个项目，是否是事无巨细都有请示汇报，项目经理是否有权限决定接受或者拒绝一个变更需求。

换句话就是，PM在项目过程中说话能不能算话。

2、文化制度

如果企业能够遵循一种好的、可以不断升级的项目管理方法，那么企业在项目管理方面不断取得成功的可能性就越大。

整个项目团队通常都了解如何制定和执行工作计划，并且能够利用标准化的方法来有效地对风险、变化范围和各项问题进行控制。反之，则依赖PM本身的影响力，逐渐去影响和推动项目，其难度是非常大的。

3、过往的经验

过去的经验对项目的影响特别严重，个人和组织都一样，都会形成惯性路径依赖。特别当过去的项目实施方案有过成功案例时，这种影响更为根深蒂固。

以前是怎么做的，现在还怎么做，至于做不做得成是一回事。按照习惯来就是了，既然过去能做成，那现在的项目就也应该能做成，做不成，一定的“人”出了问题。

温水煮青蛙，企业比个人更难以跳出舒适区。 这种固有的思维模式，对项目，对个人的成功都是很有伤害的。 

更为严重的是，这种局面很难改变。对PM来说，也不要太轻易的想去改变所在的环境——改革很不容易，除非你有足够的影响力和权威。另外一种方式就是从小处着手，潜移默化，不要追求一时突变。

所以找工作的时候就一定要多去了解一个公司是很有道理的，气场不合，强拉是不会幸福的。

对项目带来重大影响的除了“项目治理环境”之外，就是人的因素——干系人对项目的积极 / 消极作用。

这一点，可能2B产品、甲乙方项目的产品经理体会更深一些。

因为涉及到更多的业务部门和业务流程，很可能就会影响各个岗位原来的工作习惯和工作方式，从而带来各种“反弹”。A部门喜欢的，B部门不接受，A领导的提倡的，B领导有意见。部门和部门之间，人和人之间，多少都有一些利益因素在里面，都想要功劳，都想要甩锅，怎么办？

所以，做任何项目的时候，一定要多去关注人的因素，持续性的分析所有的人对你的影响。有的人要知会，有的人要请示，有的人要安抚，有的人则要强硬。

有一条一定要记住的就是：不管怎么样，承蒙领导信任，委托我这么一个重任，我就是要排除万难搞定整个事情。该装孙子就装孙子，该扮黑脸也只好黑脸了，甚至，有的时候，你都不得不得罪人了（一定要少得罪人）。

因为我们作为产品经理，唯一能证明自己的就是把产品做成功。

每个项目都有计划，但多数情况下都不能真正按照计划来推进项目，几乎每一个项目在立项启动的时候，项目负责人所描绘的蓝图往往足够打动人心，但随着项目的不断推进，各种怨言，各种“坑”就越发凸显。

这种情况的出现，本质上来说是太把计划当“儿戏”了——项目计划脱离了实际情况，过于轻视项目的复杂性和低估项目的成本支出。

项目计划不是一本流水账，它必须是整个项目团队的行动指南，必须重复的考虑到项目的复杂性和多样性，预测项目各种可能的风险并提供相应的措施。

一个能够被执行的项目计划，必须包括准确的成果分解结构，清晰的界定输出的成果边界和验收标准，并确保项目的各个参与方都有一致性的理解和认可，否则所制定的项目计划一定无法被执行。

PBS是极具价值的工具。基于PBS的项目计划可以完整的回答上述问题。

PBS本身是以构成项目最终目标的项目单元进行分解的，关注的可交付成果本身，而不是单纯的针对项目任务。

基于此，我们在制定目标的时候，不应当只有任务而没有具体可交付的成果。

整个项目计划，必须依据“用户故事板”完整的回答整个项目如何解决谁的问题，以及可以完成的工作成果，并根据该工作成果来指导整个团队的工作安排和资源安排，以及进度安排。

一旦当项目被明确，所有受该项目影响的所有人，都很清晰的知道，通过通过的努力，在何时何地，何等条件下能够创造怎样的结果，是什么就是什么，谁也别赖账，该谁负责落地的事项就按时、按质、按量的有效交付。

制定项目计划，可参考如下工具：

• 排列任务顺序

• 估算任务消耗时间

• 计算关键路径

• 提前量 & 滞后量

• 预留缓冲时间

• 资源优化

• 进度压缩

一旦启动项目，计划被明确后，作为PM就必须实时更新、监控具体的项目事项的达成情况，检查每一个节点的项目成果输出状态和时间，包括可能出现的风险、变更，团队成员的状况和动态。

一定要实时更新和调整计划，并且和团队的所有人同步。

项目容易出现状况的一个显著特征就是，只有计划，没有更新的计划。往往都特别容易出现 需求变化后，计划没有变化，人员变化后，计划也没有变化， 带来的后果不延期，就是质量有问题。

因为这不符合金三角的基本规律。

也正是因为这样的情况，越是大型的项目就越是需要专人专职的负责进度、质量和项目范围，这一点千万不可轻视。

不要认为当把项目需求理清楚了，项目计划被明确后，项目就能如期按照计划执行，这其中的任何一点忽视都可能给项目带来重大的影响，首当其冲的就是变更带来的范围、进度和质量的影响。

变更通常来说有三种：业务性质的，人为导致的和技术性的。 

所谓需求不清，往往是没有厘清楚，可能是调研过程被遗漏了，也可能是流程设计的时候有问题。这种问题的影响非常大，弄不好整个项目都要重构。

第二个就是边界模糊，谁都可以说话，谁都有意见，谁都不满意，不断的增加，修改需求，导致不堪重负，然后项目无法收拾，甚至烂尾。

要知道，项目是一种收敛性的工作，越往后开口越小，直到业务闭环。而不是越做想法越多，需求越多。

第三个，就是技术性的。以工程为导向的产品和项目，就特别喜欢应用新技术，不是新技术有问题，而是不要把你最终面向用户的产品作为新技术的小白鼠。

所有的新技术在商业化之前一定是要经过严格的验证可行，而不是边做新产品，边做新技术研发。 

我还是强调那句话，在新产品新项目上，不要太乐观的应用各种新的东西。技术的研发要大胆，而产品的商业落地要谨慎。我在用华为手机的时候，它的更新节奏就有很明显的这种特征。

本质上来说，变更的管理，就是一种权力的管理。 

基本的原则就是：

• 唯一出口：任何人都可以提出需求和变更，但你必须作为唯一的接口人和过滤器。

• 严格评审：工程师不直接接受任何非PM的需求，所有未经过评审的需求，只可讨论，不可执行。

你在项目里面能说话算数，你就能管理变更，否则，就会被迫跟着需求变更走，就像打篮球一样，盯人而不是盯着球。不要管对方进不进球，看好你的人，抢好你的位置。

你就有机会赢。

项目管理也是一样，看好需求的入口，管好需求的节奏，每一个新的需求都要经历严格的设计和评审，接受能够接受的合理变更，杜绝随意的扩展项目分为。

在整个过程里面，坚守在项目初期拟定的变更流程，不要随意的打乱项目的节奏。