以产品经理的视角看待项目,以及如何管理项目(上)

13 评论 25267 浏览 208 收藏 24 分钟

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

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

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

一、敬畏之心

对任何项目项目而言:

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

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

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

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

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

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

作为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?

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

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

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

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

#专栏作家#

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

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

题图由作者提供

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
海报
评论
评论请登录
  1. 也准备写篇类似的文章,优秀的产品经理必须要掌握一下项目管理的常识……为了从容应对项目管理工作和项目经理撕逼,做好必备知识的储备。

    来自山东 回复
    1. 期待

      来自广东 回复
  2. 你把产品经理说的太笨了,不懂点技术流的产品经理叫什么产品经理

    回复
    1. 产品经理确实不需要懂技术,只要搞清楚逻辑别给开发挖坑就好了

      回复
    2. 现在不懂点UI设计和交互也不行了

      来自北京 回复
  3. 感觉全篇废话

    回复
  4. 写的可以,错别字太多,需要注意下

    回复
  5. 一次性全部看完,感谢分享。文章发现2点语句不通:
    ①对一个将军来说,我只知道要拿不下这个山头…
    ②项目干系人图下接的第一句。老实说,这个图一定用都没有…
    当然都是小问题,不影响文章理解😊,再次感谢分享。

    回复
  6. 非常非常干

    回复
  7. 真心不错

    回复
  8. 完美的过程管理,更是能带来企业管理效率和人员能力的提升。遗憾的是,这些对用户而言都是无效的。

    来自江西 回复
  9. 很不错,厉害,我的哥

    来自江苏 回复
  10. 好文章

    来自广东 回复