以产品经理的视角看待项目，以及如何管理项目（上）

对很多产品经理而言，特别是身处创业团队，往往都是一身挑几职，产品和项目，理不清理还乱。从本文开始，以产品经理的视角看待项目，以及如何管理项目。

不管你身处大公司大环境，还是小公司创业团队，相信你一定见过各种项目的问题，也见过很多失败的案例。所谓成功的项目，一定是在有限的条件下，达成预期的目的。

想要管理好一个项目，必须尊重基本的客观事实，对项目想要完成的功能范围、所需要消耗的资源和时间成本，必须有一个清醒的认识；一颗对产品、对技术、对用户的敬畏之心，是一个项目可能成功的基础。

一、敬畏之心

对任何项目项目而言：

• 时间紧迫，活儿就只能凑合了；
• 资源有限，人手不足，就往后拖吧；
• 东西做不完，就只能赶紧砍内容，别弄那么多。

范围、时间、成本、质量，环环相扣，任何一个环节都带来极大的挑战，都可能引发极大损失。

老板们都想项目完成的时间要快，完成的成本要低，完成后的质量要好。但能够完美做到以上三个要素的项目，少之又少，我基本没有见过。

反倒是，我见过最让人感到震惊的状况。

一种是多产品多项目的并行开发，最后发现没有一个产品可用。还有一种就是引发极大的质量问题，造成重大的损失。而事实上，这都是可以预计和预防的。

有的时候，真是 人心不足蛇吞象，想法足够大胆，但投入捉襟见肘。要知道，任何罔顾基本规律的做法，必然遭受现实的打击，造成不可估量的损失。

作为PM（项目/产品经理），一定要把这个金三角的关系牢记于心。

• 为了缩短项目时间，就需要增加项目成本（资源）或减少项目范围；
• 为了节约项目成本（资源），就需要减少项目范围或延长项目时间；
• 如果需求变化导致增加项目范围，就需要增加项目成本（资源）或延长项目时间。

甚至，对质量的追求，都是一个度量的平衡。

不管你用什么管理的方法方式，都不能绕过这一基本原则。

因此，在做预算的时候，必须面对现实，而且一定要掌握一个原则：预留一定的弹性空间。

PM应该用一种“悲观”的视角看待项目，用乐观的途径去解决问题。

但事实上， PM们最容易犯的错误，就是在完工日期的预测上，为了讨好客户或者上司而过于乐观，或者依据简单的经验数据来做出决定。

鱼与熊掌之间，是一道三角难题。项目计划是一个多次反复的过程，也是一个不断修正的过程，一定要时刻保持基本的敬畏之心，重复考虑各种因素的相互协调。

想要在三角之间找到一个平衡点，一定要弄清楚什么是“好”，什么是“快”，什么是“便宜”。最忌讳的就是盲目的追求“快”，最可怕的是过于乐观承诺“好”。

所以，对于产品（项目）经理而言：

第一条规则是：让你的老板认可和接受金三角法则；

第二条原则是：你始终在受限的环境下管理你的产品（项目）。

二、产品&项目的异同

“项目”这个概念，其实时刻都在我们身边发生，火箭上天是一个项目，家庭装修也是一个项目，他们共同的特性就是都有完全不同的开始、结束时间，也都产生完全不同的结果。

有的项目很长影响很大，甚至流芳百世，比如修建三峡。有的项目仅仅是你的私事，比如追求心中的女（男）神。

1. 产品 vs 项目，两个世界的追求

随着“互联网思维”的遍地开花，我们看到一种现象，项目经理这一角色似乎越来越被削弱，产品经理大有取而代之的趋势，甚至很多互联网公司都没有专职项目经理。

这是错觉还是必然，两者之间是否必然会被过渡？

但两者其实是完全不应该有混淆和争议。

• 产品，是指能够供给市场，被人们使用和消费，并能满足人们某种需求的任何东西 （百科定义）
• 项目，是为创造独特的产品、服务或成果，而进行的临时性工作 （PMP定义）

这个定义已经很清晰的界定了一个产品是由N个项目组成的，产品输出实际的东西，而项目对应产生产品的过程。也就是，产品经理对结果负责，项目经理对过程负责。

对一个企业来说， 产品经理强调的是做一个什么东西，通过什么方式可以卖给谁，赚到多少钱 。

项目经理考虑的是：需要多少时间，投入多少资源把东西做出来。

比如对面有一个山头。

• 产品经理想的是：把旗帜插到对面山头上去。插一面大旗还是小旗，是一面绿旗还是红旗？是不是要用混凝土加固下，啥时候再发起下一个项目。
• 项目经理想的是：怎么去那个山头，谁抗旗，抗多久，扛不动怎么办？至于旗帜插上去下一步怎么办，会不会倒，项目经理并不关心。

2.1.1 关注点不同：

产品经理的侧重点向外，关注用户和市场

• 市场机会和竞争格局
• 用户需求和用户沟通

解决的是做什么，卖给谁，赚谁的钱的问题。

项目经理的侧重点朝内，关注资源和进度

• 资源调配
• 资源效率
• 项目进度

解决的是如何用有限的资源在限定的时间内，按照质量要求把东西做出来。

2.1.2 交付物不同

产品经理交付的是产品成果，最终交付给用户的产品，关注产品的成本、质量和体验，以及产品通过运营后转化的企业收益。

项目经理交付的是管理成果，最终交付管理层的工作报告， 关注团队的士气、效能、成本，以及企业整体的生产效率的提升。

2. 祸起萧墙，根源到底在哪

理论上来说，项目经理和产品经理是不应该存在争议的，但事与愿违。

为什么会出现“我到底是「产品经理」还是「项目经理」”的困惑呢？

首先，产品经理是抢着项目经理的饭碗而复兴的。

尽管产品经理很早就诞生了（来源于宝洁，故事可百度），但在IT领域并没有受到重视，在那个年代，对于看不见摸不着的软件，用户是没有概念的，只能是企业自己决定自己要做什么，以自己的技术推动用户往前走。

在2010年前后，技术的普及也带来了用户的觉醒，传统强调时间、进度的软件工程的思维越来越具有局限性，“宝洁的故事”事实上在重演，产品经理再次“横空出世”，一直到后面的“人人都是产品经理”，是一种彻底的 思维转向 。

也就是：产品经理试图分解和分担过去项目经理的职责和工作，把传统软件工程的项目概念，重新回归到产品本身来，从强调企业内的项目交付，转为面向用户的成果交付。

了解目前的“甲乙方项目”就能够感受得到，交付给甲方的成果，其中之一就是庞大的过程资产，甚至试图在尽可能的还原过程，“我就是按照你的思路和要求一步步做出来，你就老老实实的签字画押”吧。

所以，“甲乙方项目”、“外包项目”极容易脱离用户需求，因为面向管理过程。

第二，产品经理和项目经理存在难以逾越的鸿沟

事实上，对用户而言，一个产品是怎么做出来的，他完全不关心。加了多少班，熬了多少夜他也不感兴趣，他只关心这个产品是不是他想要的，有没有价值则直接决定他是否愿意付费。

你说你这个软件可以约妹子，他就试试能不能约到妹子？你说你这个app买东西便宜，他就试试比别人便宜多少？除此之外“多说无益”。

对用户来说，当物质丰富，用户有可选余地；他一定选择他喜欢的，满意的产品。只要他不开心，他除了卸载，还是卸载。

而传统软件工程思维，是与此相背离。

作为项目经理，如果一个东西，能够按质按量按时的生产出来，是难以评判它的失败。 完美的过程管理，更是能带来企业管理效率和人员能力的提升。遗憾的是，这些对用户而言都是无效的。

产品经理来说，“鸡飞狗跳”都是次要的，用户开心比什么都重要，所以他首要解决的是用户、市场和竞争性的问题。而把内在的过程放在其次，“需求很简单，怎么做我不管”在一定程度上并没有错。

子非鱼，用户思维，和我们自己的思维是存在天然的鸿沟的。

站在地球上，我们始终看到的是太阳绕着我们转；而站在月球，站在太空呢？

这也是以用户为中心往往很难落地的一个原因——用户思维是一种反向思维，反人性。

产品和项目在这个维度上存在对立关系。任何一个产品，越强悍越完美，越有可能让用户开心，但对企业来说就可能是灾难，项目过程必须采取折衷的办法。 打造完美的产品，意味着投入更多的额外资源，形成事实上不必要的光环。

第三，产品经理和项目经理剪不断，理还乱

对一个将军来说，我只知道要拿不下这个山头，留多少血我不感兴趣。

但你并不能这么做。

软件开发过程中，就必须遵循基本的规则和规律，一个妈妈生一个宝宝要10个月，不能直接换算为10个妈妈生一个宝宝只要一个月。

当一个东西，决定要做的时候，就开始牵涉到复杂的资源、进度、质量和范围的问题，而这四个形成一个互相角力。比如范围扩大，就势必引发进度和资源问题：

很多时候常能听到并行，同步的字眼，多想想10个妈妈生宝宝的故事。

项目的过程有其复杂的机制和逻辑，同一个项目，在不同的模式下，极可能消耗的资源，进度，质量都会完全不一样， 项目的过程管理有科学的依据和成熟的体系 。比如工作任务的分解、关键路径的跟踪等等。

产品经理其实非常的依赖项目过程的管理，不管这个角色被定义为项目经理还是自身的兼顾，都会对产品的工作带来影响。

所以我们常常见到两种产品经理，一种是以市场、用户为天职的产品经理，看上去牛皮轰轰响，可东西没出来，还有一种是事无巨细过程很完美，但市场反馈差一点。

3. 相辅相成，方能互相成就

项目经理和产品经理的争议严格来说并没有意义。

个人的主张是，理应各司其事，特别是更加复杂的竞争环境下，想要真正的以用户为中心，势必进一步加强用户的沟通和研发，把更多的精力放在对市场的灵敏反馈上。

同时，产品的过程管理也极为重要，它反过来反作用于用户。清晰的业务方向，准确的市场反馈，以及完善的项目过程管理，才是真正无望而不利的。

对企业来说，小团队可以产品经理兼任项目精力，在一定程度上需要分设不同的角色，应对更为激烈的市场竞争。

对产品经理和项目经理而言， 彼此之间有清晰的定义，但从来都只有模糊的边界。

三、项目环境决定成败

作为一个产品经理，我们都曾心怀改变世界的梦想，期望一己之力为用户带来“无上”的价值。

现在的情况是，梦想谈完了，模式说清了，想要搞出一个什么东西也明白了，是要真正见到“产品”的时候了。

可是，你可能就那么几杆枪，怎么办？

磨刀不误砍柴工，在真正亲自下战场操刀之前，关于项目的几个核心概念一定要搞清楚。

你的身份现在应该切换到项目的角色。

不要再谈理想，也不要再说体验故事，先把东西做出来再说。

1. 项目生命周期

谈产品和项目的时候有一个清晰的定义——项目一定要有开始和结束的时间。

所以，任何一个项目一定都一个生命周期，或长或短。任何一个项目，规模、复杂度都不同，但无论大小，都一定具备一个通用的生命周期结构：

• 启动项目；
• 组织和准备；
• 推进具体的工作；
• 结束项目。

也就是任何一个项目，都有一个通用的项目阶段：

启动——计划&执行&控制——收尾

任何一个项目，最轻松的开始阶段，反正啥都好说；最难受的是推进的过程，不是甩锅就是撕逼，打架都正常；最尴尬的是收尾，对方不签字的时候想要跪下去叫爷爷，收了钱老子就是天下第一。

这是一句玩笑话，但在“甲乙方”的项目过程中，司空见惯。

所以，项目开始的时候，丑话要说在前头，开弓没有回头箭，开始没讲清楚的事情，到了后面就讲不清楚。先做恶人，才可能有机会做好人。

不能实现的功能一定要拒绝，当前不能满足的需求一定要明确，能达成什么样的指标一定清晰。

这个叫项目目标，所有后续的功能只能围绕这个目标来执行，任何要推翻目标的项目行为，都不能被直接接手，必须启动相应的机制和流程。

无数的项目证明，这是基本的定律。

项目目标和范围是两位一体的事情，只打30层楼的地基，就绝对不能去盖50层的楼。

想要修改目标和范围，一定要“重启全新”的项目。

项目的坑往往就是在这个时候挖下来而不自知。

而后期接手的人，根本没有任何办法理清楚过去的纠葛矛盾，它会演变成一出N角恋——二手项目很容易烂尾。

失败在所难免。

也就是：项目在开始和执行以及收尾的过程中，一定会要投入不同的资源，并催生各种需要控制管理的风险。越是早前不确定性最高，甚至随时都可以关闭，但损失可能小，越后后期越难控制，损失往往无法估量。

在项目的早期，一定要尽可能的预知风险，比如做硬件的，一定要明白，可能结构不行，材料不能准时到位，做软件的也一定要知道技术的瓶颈在哪里，而且，软硬件要及时同步。

遗憾的是，我们常能见到硬件设备已经出来，软件工程师还没有入场，然后就发现各种“货不对板”，彼此埋怨。

而硬件项目是不能像软件一样快速迭代甚至推倒重来。

3. 项目治理环境

项目早期的坑，最多是一个开胃菜，进入到项目之后，每个雷一旦引爆都可以逼停一个项目，这个环节最大的不可控因素就是人的因素——项目的环节因素。

没有人可以逃过环境的影响，也没有一种项目管理的方式可以超脱于外。

一个项目能否管好，不一定取决于你的努力，更多的是裁剪一个恰当的方式，符合这个环节的一种节制，和你所把控的那个节奏。

这是非常难的一件事，越是大的项目越难， 在这种大项目里面，对事不对人是绝对错的，搞不定人一定搞不定这个项目 。

环境因为包括组织的文化、结构、区域位置、行业标准、人事制度、授权机制，甚至法律法规等，任何一个项目都受其中的一些因素所影响。

在其中最具有直接影响力（杀伤力）的就是人，在项目里面叫做干系人。

有的人对项目有积极影响，有的是消极影响。

比如拆迁经常会钉子户，也有的时候，只要张三同意，李四就一定反对，诸如此类的情况比比皆是，所以搞清楚一个项目会涉及倒那些人以及什么利益关系，比啥都重要，否则谁都可以是项目经理了，都可以发号施令了。

老实说，这个图一定用都没有，所谓分析项目干系人，其实就是找出那些对项目施加影响的人，特别是那些负面影响的人，背后捅刀子的人，得了便宜还卖乖的人，那些不按常理出牌的人，作为项目经理你可以给一个大家都可见的关系图，但自己私下还要再准备一个。

所有的人和事，往往都是利益的事情。

搞清楚了关系，就要真正开始组织团队了，这个叫项目团队。

组成一个项目的人，都是各有所长（各怀鬼胎）的，作为项目经理就一定要分清楚职责职权，这里面又会涉及团队内部人的沟通，分享问题，以及各种奖励惩罚机制。

这个图是不是看着很官僚的样子。

官僚就对了，这种结构的设计，就是为了保证项目组内的有序可控，对外有统一的出口，对内有稳定的次序。

不要随便夸海口，更不要随便瞎承诺，只有项目经理才可以享有足够的权力，才能保证团队内部的健康，和项目的健康，否则就变成一锅粥。

每个人都有自己清晰的职责和权限，“按部就班才可保平安”。

3. 项目过程资产

说完了，人和事。下一步就是物了。

如果说项目的环境因素可以让一个项目万劫不复。一旦管不好过程资产，那就一定黄土加身了。

这个资产，指的是 一个项目在它整个生命周期里面所有产生的，使用到的全文文件文档，包括来自任何人，任何组织所涉及到的知识，文件，记录的。

为什么常说项目里面那么坑，有一部分原因就是没有管理好这些“资产”，比如产品经理输出的原型，业务流程不清晰，还没有存档。所以，写好一份文档的极为关键的，管理好这些文档是第二重要的是，详见 ” 如何用Axure输出高质量的PRD？ ”

在过程资产里面还有一些特殊的内容需要特别投入精力：项目本身的文档。

项目计划书、里程碑节点、变更控制流程、财务控制程序、缺陷管理程序等等，任何一个环节都足够展开一个宏大的篇幅细说它的故事。

从这里开始，热身运动做完，可以开始埋雷挖坑了。

具体内容，请听下回分解。

#专栏作家#

杜松，公众号：产品微言，人人都是产品经理专栏作家。专注于人工智能方向，擅长产品规划和架构设计。

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

题图由作者提供