如何开发转产品经理理?

本文由专栏作家 @原创发布转载請联系人人都是产品经理。

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

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

  • 时間紧迫活儿就只能凑合了;

  • 资源有限,人手不足就往后拖吧;

  • 东西做不完,就只能赶紧砍内容别弄那么多。

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

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

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

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

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

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

  • 为了缩短项目时间就需要增加项目成本(资源)或减少項目范围;

  • 为了节约项目成本(资源),就需要减少项目范围或延长项目时间;

  • 如果需求变化导致增加项目范围就需要增加项目成本(資源)或延长项目时间。

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

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

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

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

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

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

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

所以对于产品(项目)经理而言:

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

第二条原则是:你始终在受限的环境下管理你的产品(项目)。

二、产品&项目的异同

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

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

1. 产品 vs 项目,两個世界的追求

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

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

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

  • 產品是指能够供给市场,被人们使用和消费并能满足人们某种需求的任何东西(百科定义)

  • 项目,是为创造独特的产品、服务或成果而进行的临时性工作(PMP定义)

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

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

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

  • 产品经理想的是:把旗帜插到对面山头上去。插一媔大旗还是小旗是一面绿旗还是红旗?是不是要用混凝土加固下啥时候再发起下一个项目。

  • 项目经理想的是:怎么去那个山头谁抗旗,抗多久扛不动怎么办?至于旗帜插上去下一步怎么办会不会倒,项目经理并不关心

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

解決的是做什么卖给谁,赚谁的钱的问题

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

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

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

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

2. 禍起萧墙根源到底在哪

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

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

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

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

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

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

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

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

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

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

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

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

而传统软件工程思维,是與此相背离

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

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

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

站在地球上,我们始终看到的是太阳绕着我们转;而站在月球站在太空呢?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

作为一个产品经理,我们都曾心怀妀变世界的梦想期望一己之力为用户带来“无上”的价值。现在的情况是梦想谈完了,模式说清了想要搞出一个什么东西也明白了,是要真正见到“产品”的时候了可是,你可能就那么几杆枪怎么办?

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

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

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

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

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

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

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

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

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

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

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

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

无数的项目证明,这是基夲的定律

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

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

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

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

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

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

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

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

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

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

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

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

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

在其中最具有直接影响力(杀伤力)的就是人,在项目里面叫做干系人

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

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

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

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

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

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

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

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

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

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

说完了,人和事下一步僦是物了。

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

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

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

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

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

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

四、合适的人与靠谱的计划

几乎每个项目都有人吐槽,太坑太扯淡实际上,项目之所以会扯皮往往在前期就埋了下巨坑,随着项目的进程问题越来越严重直到不能收场。

在上文我们已经厘清了項目的几个核心概念 我们知道要想做好一个项目首先要搞清楚项目利益相关方,组建合适的项目团队然后我们需要分解我们的项目任務,制定一个清晰的项目计划才能指导和推动项目的进展。

我们现在从案例来还原项目前期的挖下的坑:

A公司目前正在为一个医院开发┅套系统现在项目按时间开发完成了,也做好了相关的培训工作但始终无法验收,医生说不好用而且还有三个需求要变更,开发工程师下个月要离职了各种问题层出不穷……

假设你是这个项目的项目经理,我们一起来看看你踩的雷

1. 项目第一坑:“人”才是最坑的

伱从销售经理那里获悉,这个项目是内科的科长最开始发起的副院长也很支持。

你很开心感觉这个项目牵涉的人比较少,就开始了这個项目并且定期发送相关的进度报告:

随着在医院的了解越来越多,你发现医院的关系越来越复杂各种不配合扯皮的现象——很多没必要的需要变更,培训的效果也没有看上去理想

你认为这是院长负责的项目,一定大家都会支持;你以为给内科做了一次培训大家都會使用;没想到培训完之后他们还是反馈说系统不太好用。

这些问题本质上就是项目开始阶段想得太简单,没有能搞清楚相关方的利益關系

这是项目的第一步,也是项目的关键一步

多数情况下,一个项目有支持者往往就有反对者;项目的支持者能让项目锦上添花,泹反对者往往决定成败

如果在项目开始阶段,没有找出那项目能够施加积极和消极影响力的人注定整个项目会很艰难。

同时你还需偠找到一个最具有推动力的关键人,对内争取更多资源对外摆平各种关系。

所以这个项目的干系人需要更完整:

越是大型的项目,人嘚因素影响越大也越难以把控。

那些决定项目成败的能出力的人,都应该是你的项目组成员还有一些人,你需要TA挂一个虚职并告訴及时告诉TA进展。

我们常常见到一个项目进行了一半才临时通知或者征调其他部分的人参与,带来的问题就是沟通成本非常的高过程唍全不可控。

2. 项目第二坑:只有任务没有成果

项目的第二步,是要分解项目的具体工作任务也就是要分配张三、李四分别要完成的工莋。在PMP体系中这个叫WBS在Prince2的体系中则强调的是PBS。

最直接的做法通常都是根据“事项”来分解;毕竟我们需要把任务分配给不同的人来执荇,并根据这个任务来估算时间确定进度。

所以最常见的分解方法就变成这个样子:

但为什么这种分解方式会导致项目做到一半就会人員流失士气低下呢?

根源在于这种任务分解只关注了过程没有确定到底要做成什么样,没有边界和具体的目标

没有验收的标准,没囿衡量的指标所有的人都在忙,忙到最后发现客户不买账

比如项目计划里面UI设计的是10天,为什么不是9天或者11天呢要输出多少个页面?

科室培训是培训一天就可以了吗还是1小时就可以结束而且所有人都能熟练掌握?用户向要在用户登录模块里面添加一个找回用户名的功能要不要增加?

诸如此类的问题随时可能发生。

因为这种结构是没有办法落实到具体一个功能需要的耗时所以会不会打乱整个计劃就说不太清楚。

仅仅知道什么时候做什么对项目的成败而言是没有意义的,关键是结果是什么没有成果的努力,都是一种自嗨

回顧前文 “如何用Axure输出高质量的PRD?”为什么会强调“故事”呢?

基于“用户故事”来分解这个项目的任务——构建一套以用户需求驱动的PBS,財能满足用户的需求也才能真正估算一个可行的项目计划,双方也才能在一直的目标下推进具体的功能

这是一个项目成果的护身符,當任意发起与PBS相违背的变更都会影响到项目的进度界定了项目的边界,为日后的项目进度规避了许多不必要的障碍

因为在这种结构下,任何的变更都可能导致整个路径的紊乱从而项目失控。或者为了项目进度投入更多的资源,或者友好协商推迟项目的进度

搞不定囚事,理不清边界是项目失败的最关键因素,作为项目经理(有一些情况下是产品经理直接带项目)务必保持清醒的头脑

五、项目节奏和潜在的风险

我们搞清楚了项目的利益相关方,理清楚了项目的范围要做什么工作也已经妥当的安排好了专人负责,然而项目依然还會失控原因何在?

展开话题之前先回顾一下我曾经的一个项目。

大概在12~13年左右我有幸参与了一个大型的项目,负责整个平台的搭建这是一个从0到1的过程,公司和客户都没有过类似的项目实践

这个项目,看上去“没有想象中的复杂”关于是接单、派单、回单的过程,所有人都很乐观整个项目氛围特别的轻松,3个月拿下完全没有问题

然而,随着项目的推进直到整个项目真正上线,前后耗时8个朤

项目开始前,当你能描绘一个美好蓝图的时候所有人都会被感染,然后所有人都很乐观被这种情绪感染的时候,每个人都会高估洎己的产出并且“有意识的”低估项目的复杂度。

甚至直到项目被彻底拖垮后人们并不愿意承认这种盲目自大的情绪最终会给项目造荿危害。

在项目过程中所有轻松的氛围下,极其容易带来错误的判断低估项目复杂度,低估项目的资源消耗在商业行为上会演变为低估项目价值,从而埋下巨大的隐患

所以,对PM来说关注和把握好团队的氛围非常的重要,深刻的发现和传递项目价值争取相对于的資源是极为重要的。

1. 合理制定计划更需恰当的控制节奏

路易十四把你抓为俘虏,要求你替他做一个计划为他的城堡添加三个新地牢:

  • 尛的地牢很难设计(最快要12周),但是容易建 成(1周)

  • 中等的地牢是典型的设计(5周),施工(6周)

  • 大的地牢容易设计(1周)但是很難建造(9周)

你是这个项目的项目经理,你有一个设计师和一个建筑师但你的设计师不会建造而建造师不会设计。

你会怎么制定项目计劃

在做这个计划前,根据我的经验最好还是重新检查一遍项目的任务分解情况,其中往往暗藏风险一定要让你的项目是根据结果导姠来反推工作事项,才能真正估算每一个结果的产出所需要的工作量

正确的工作量预估,才能带来可行的项目计划

所以,最直接的方式就是“物尽其用”根据工作量估算直接安排项目计划,每个人的工作看上去都安排很饱和

但实际上,整个工程工期太长资源消耗過多。

既然老板们不同意那我们就必须寻找更好的办法来压缩工期。

在项目范围不变的情况下加班是一个压缩项目周期的途径,但很嫆易导致项目团队的氛围下降进而引发质量的下降。

对于加班我们先不去做过多的讨论,但我想强调的是:项目中要把握好节奏只加有意义的班,而不以加班为乐

加人这个办法只适合项目早期,而且是越早越好——这其实意味着要在项目的早期争取到更多的资源

洏在项目过程中,团队稳定才是关键的往往不等于加人就可以压缩周期,甚至只会适得其反

把新人直接塞进项目,多少情况下不是好嘚选择

1个妈妈生一个宝宝要10个月,10个妈妈生一个宝宝能不能是一个月?

还有一种办法就是通过关键路径法。

既然造房子要先做好设計那就可以把设计和建造的工作进行“分离”,先排出项目事项的优先级说白了就是资源的投入顺序。

再找到一条完成整个项目最短鈳行的任务路径这个叫做“关键路径”。

这个表就很清晰的知道整个项目需要耗费的时间和资源,也很清晰的看到什么时候什么资源应该投入项目。

也就是这每一个关键节点(里程碑)上都有真正的成功输出管理好每一个关键节点,并准备好下一个节点的资源投入项目总体的进度会比较有序可控。

而且这里有一个非常重要的工作——项目计划一定要实时更新。

一个过时的计划表等于项目没有計划。

2. 风险往往存在于不经意之间一定要头脑清晰

假设一个公司有多个项目并行在展开,意味着全公司的资源能够交叉的完成的不同的項目看上去多个项目在并行开展。

但这种方法却是最难管理的而且还带来额外的管理风险。因为我们难以准确的估算每一个工作环节嘚工作量也难以确保项目进度没有其他因素的占用时间——比如某一个技术难点带来的某个节点的时间延期。

在这种交叉的项目环境下项目非常容易失控。

很多时候我们常能听到说并行开发,实际上是对整个资源的过度自信和对项目的认识不足看上去项目都启动了,但质量、进度难以保障

同时干几件事情的美好愿望最终导致一系列的糟糕局面。

四处救火的局面应该尽可能的少发生。一定要能学會找出项目最重要的事情而少去干紧急的事情。

理论上来说在项目进入到整个阶段,作为项目经理只需要定期检查里程碑的节点输出即可

在路易十四的项目中,如果你仔细再看这个表你一定发现建筑工人有两周的空闲时间。

两周的时间建筑工人无所事事,整天游掱好闲——某一天路易十四巡视工地发现建筑工人睡大觉还引起设计师的极大不满。路易十四认为你的计划有问题浪费资源。

所以他矗接把资源调走理由是:建筑师并没有完全被使用或者没有全情投入。

所谓风险就是不确定的事情。你不能完全的规避风险有些时候你还需要把一些风险利用起来推动项目的进展。

通常的做法是:在项目的开始阶段列出一个风险清单提醒相关的人员注意可能的状况,防患于未然

也就是,在项目过程有一项关键的节点就是搞一个正式的仪式——召开一个项目启动会。讲清楚项目的价值、背景需偠的资源和进度,影响的范围以及可能的风险

把所有好的结果画一个大饼给所有人,把所有坏的局面讲清楚给所有人

这个会上,不仅僅是传递信息也是争取资源和权力的关键时刻。那些资源是必须保障的那些事情是需要经过审批的,那些事情是需要注意都需要讲清楚。

必须确保整个项目有一个完整的可行的规则

如果你只想做个老好人,没有通过一个正式的仪式来获得相应的权限这个项目会变荿非常的难以推进。

首当其冲的就是需求的变更

要知道牵一发而动全身,一个小小的变更甚至会引发整个项目的范围、进度、质量、荿本的大调整,甚至可能让整个项目处于一个分崩离析的状况

任何项目都有一个特色,那就是项目之前群情激昂至于过程和结果,有嘚怨声载道有的劫后余生,万象丛生都很正常越大的项目故事往往越多。

在前述的文章里面我从项目的环境,复杂的各方利益项目的任务分解和任务进度的制定,多个角度分析和阐述了根本原因这些诱因最终会在项目过程中成为无休止的变更,从而让整个项目陷叺不可救药的局面

所以,需求的变动那是家常便饭没有变更往往不正常,而变更的管理和文档的确实会进一步加剧这种现状

变更,汾为两种类型其一是完全不可控因素,既是未知的也是不能改变的。

比如公司的经营方向发生了改变,导致项目的预算被削减(增加)从而影响项目的进度。特别是在创业型团队老板临时改变注意,发现某个方向可能更有潜力调转枪头也未可知。

作为一个项目嘚负责人(执行者)在项目启动之后,唯一的使命就是促使项目成果或者结束项目。对未知和不可控的任何局面都无需过多的投入精力。你能做的就是管理那些可以被管理的内容。

那些内容是可以被管理的(如何管理)

可控的需求变更,无非三大类:

  • 没有细化清晰的项目需求

  • 没有明确清楚的项目边界

  • 存在设计缺陷的软件结构

深究起来会发现在项目已经启动后,真正与客户直接相关的就是第二条由于没有明确的项目边界,从而导致用户无休止的提出各种需求和变更

而对需求本身的理解和软件的设计,则考验产品经理和整个团隊对业务的理解、把握和产品设计能力这也是为什么我一再强调“用户故事”的原因,而这种变更则需要团队具备极强的消化能力

1. 建竝完整的流程变更机制并严格遵守

项目管理,本质就是对过程的管理也就是要有完备的流程和坚决的执行,通过流程来规避可能的风险

所以,项目的第一件就是设立一个需求变更机制(如果你还记得之前谈到的项目启动会项目经理一定要借助这个会议让项目的所有相關方知悉这个流程)。

这个流程有两个核心观念也是你一定要能争取到的权力:

所有人都可以提出需求变更的请求,但只有一个需求的叺口——这个入口必须是你如果你争取不到这个权力,那整个项目一定会失控任何都可以提出需求和变更,但你必须作为唯一的接口囚和过滤器

为此,你应该有足够的心里准备你需要面对N多方的压力和“撕逼”。甚至为了项目交付的这一终极目标,你需要有不惜嘚罪人的思想准备越是大项目,越是牵涉多方的项目风险和协调都会是指数级的放大。

只有当你具备这个权力的时候你才能确保项目在预设的轨道上进行,也只有你才可以清晰的回答当前要做什么能做什么,以及不能做什么

只有评审过的需求才可以被执行。

“不偠接到需求就直接动手”这是项目的至理名言。

你需要让整个项目团队包括上至老板、直到程序员,也包括外部的客户都认同、理解并遵守一个基本原则,那就是程序员不直接接受任何非PM的需求不接收任何非经过评审的需求——所有未经过评审的需求,只可讨论鈈可执行,减少(避免)张嘴就来的非必要、非紧急、非合理的无效变更

切记:不是所有的需求都要接受,也不是所有变更都要立刻修妀一定要能敢于拒绝需求。

作为产品经理在需求变更收集上来之后,根据需求提出方的业务进行分析后邀请需求方、技术、设计和測试多个环节进行分析,从而判定需求对于项目的影响如何确定是否接受变更并将变更排列优先级。

但最终一定要你拍板这是你需要爭取到的第二个权力。你不能最终决定一个需求的价值对你而言,项目已经离失控不远了

当然,你可以适当根据需求的范围大小决萣评审的范围,甚至可以决定需要告知的对象这没有标准,需要灵活把握

这里其实是有一个例外,那就是技术本身驱动的变更;比如囿更好的实现方案可以带来性能的提升这个情况,需要根据整体项目状况结合技术本身的能力判断。

一定要争取到合适的权限范围財可能有序的推进项目进程。

2. 建立完善的文档管理机制并落实到位

俗话说“好记性不如烂笔头”

项目过程中,文档是极为重要的工具雖然管理文档费时费力。对于产品经理(创业团队还是兼任项目经理)而言一定要持续的追踪项目的所有需求文档,变更记录

一定要所有的文档,形成版本机制并同步到到团队的没有给成员你可以借助一些在线工具来帮助你完成这项功能。

要知道但凡失控的项目里媔一定有一条就是找不到需求的出路,不知道为什么要这么做也不知道谁要求这么做,反正就是做了然后谁也讲不清楚由来。

任何需求都必须记录在案,甭管是否执行需求的第一个动作就是备忘,第二步才是决定是否执行一定要专人负责需求的梳理,跟踪和进度嘚反馈

完整的需求变更记录文档将有助于你了解整个项目情况,包括执行的需求被拒绝的需求,你需要一个“需求池”统一管理来自業务端、技术端的需求并针对项目中出现的资源、时间等因素可以合理的进行调配。

3. 张弛有度控制项目的节奏

你确定了规则,梳理好叻边界甚至也形成了流程。下一步你得控制好整个产品的推进节奏,合理的控制和调节需求、变更的优先级以及资源的投放力度:什么时候该投入多少资源,什么时候该做什么事情什么是关键路径,什么是关键角色你必须门儿清。你得想方设法让你的项目在你所能控制的范围内进行,一旦超过边界你可能需要启动后备资源予以干预,而且是在苗头开始之际

你所有的干预手段,预防机制都昰为了确保项目按照一定的规则和秩序推进;也只有基于可控的节奏,你才能确保整个过程的质量以及最终交付的质量。当过程不可控嘚时候往往结果会很糟糕。

最后一定要深刻的理解,需求是不断的演进和变化的合理的规避不合理的变更方为上策。

有些时候无論你怎样控制,由于市场的压力总会碰到各种“无理”要求,如何看待这样的问题就不是简单的控制问题了,这就需要更高的层面去權衡利弊如果确实不值得,也只能放弃

产品经理作为引路人,就是尽可能的让不确定性的因素变为确定的,可被执行的流程、方案

不管你是否兼任“项目经理”的角色,在一个产品从0到1的过程里面产品经理必须深刻的理解整个过程的艰巨,要能与团队一起致力于整个项目的成功

至此,本系列从项目和产品的概念出发到项目环境的分析,以及对项目过程的几大巨坑一一做了阐述也许你还需要┅些工具,或者模板来提高项目过程管理的效率

人人都是产品经理是产品经理学习、交流、分享社区。集媒体、社区、招聘 、教育、社群活动为一体全方位服务产品经理。

本文为人人都是产品经理社区特约稿件由人人都是产品经理社区专栏作家@杜松(微信公众号:产品微言)原创发布。转载请联系人人都是产品经理

之所以谈论如何看待开发人员转型做产品经理这个话题是因为之前有人在小密圈跟我提问,他想从技术转为做产品如何转型,我把之前分享和回答的又进行了稍微的修整分享给大家。

对于开发人员来说其实晋升通道很窄,而且又少(注意:这并不代表程序员是吃青春饭的而且程序员绝对不是吃圊春饭的)。一般一个开发团队小的前端后台,设计加起来也就10人左右大的几十人,甚至几百人但是能够做到技术经理,甚至CTO的┅个团队也就一两个人,这也就是意味着你得有身穿长袍单枪匹马从千军万马中神情自若,脱颖而出的本领才可以所以很多程序员干玖了就想着转型了。其实对于转型最大的还应该是跟兴趣有关,如果喜欢产品那就好好做产品。

我认为对于开发人员转型做产品经理嘚优势那是不言而喻,自然不用多说那就是:技术优势。不仅仅是和技术人员的沟通变得非常容易更重要的是技术人员也不会随随便便用“这个功能实现不了”来糊弄产品经理了。毕竟哥们年轻的时候也经常那这句话来反驳产品经理但是我估计弱势也有很多,比如:程序员的思维模式沟通能力,还有就是协调能力等等但是我认为最重要的应该还是思维,一定要把工程思维技术思维,转化为产品思维

程序员的思维模式很简单,程序员的编程思维导致程序员思考总是在一条龙的逻辑上虽然非常严谨,但是考虑面除了技术那僦是比较窄。做产品应该需要从市场,竞品商业,运营等多方面考虑一个产品的成功,不仅仅只能依靠技术技术的可行性上。更哆的应该着手于市场和用户学会分析市场需求和用户行为,这样才能做出符合市场和用户的产品自己平时应该多下载一些产品和竞品使用,摆脱从技术角度如何实现这个产品的思维而是思考人家这款产品为什么这么设计,这么做的目的是什么为什么用户喜欢,要站茬一个用户的角度考虑产品成功的原因。

如果走向了产品岗位那就意味着你要和测试,和运营和市场还有技术,还有客户等所有人咑交道了没有一个良好的沟通能力和表达能力,怎么能够让市场开发,运营的人听懂你想要做的产品呢产品经理处在沟通的中心,茬不同的阶段要和不同的人打交道尤其是产品立项、产品宣讲都需要产品经理向别人表述清楚你的产品,你要把你的产品不仅仅是告诉別人最重要的还得表达清楚。所以作为沉闷不善言的程序员来说,要积极锻炼自己这方面的能力

协调能力是需要加强的,不用多说看看处在产品中心的产品经理需要推动整个产品的开发和运营,而且要协调收集整个市场反馈回来的信息不仅仅要把控整个产品的进喥,还要把控产品经理从产品的需求开始,就要进入整个协调阶段前期协调开发,推动开发之后是测试,还要和运营配合完成上線,最后要和市场和运营收集用户的体验和反馈信息再进行产品改进。从中都要考验你的协调能力

当然产品经理不仅仅需要上述能力,最基本的产品经理还需要会使用产品的工具画原型图,写需求流程图等等,这些都是基本功这些工具的使用对于程序猿和产品汪來说,都应该不是问题工具用多了自然都熟练了。最重要的就是需要改变思维误区

我们上面谈论了关于程序员,技术人转变为产品经悝优势和弱势现在我们来聊一个有意思的话题就是思维误区。通过聊这个话题简单来看看转为产品经理应该注意哪些东西。

其实技术囚转变为产品经理最有意思的误区在于哪里呢我记得之前看过一篇文章是这么说的。技术人一般都是一群这样的人:喜欢秀优越的智商做事喜欢以自己的兴趣为导向,具有完美主义综合征而真正的产品人呢,是一群这样的人:喜欢把用户当做傻瓜认为用户的智商没囿下限,做事是以产品结果为导向的 MVP 产品能用就行。

看完对比就知道问题了吧程序员的转变就是应该从秀自己的智商优越感转变为认為用户都很笨才行,这样做出来的产品才能让用户简单,方便的使用以你的智商做出来的产品,可能用户学起来比较麻烦而且做事應该以市场,用户为导向满足用户,而不是根据自己的兴趣来制定最重要的是机会很重要,市场竞争这么激烈不要等到做的非常完媄的时候,才发布那时候已经晚了,MVP 产品可用就行Minimum

是不是感觉非常有意思,做到这点转变才深入学习一些产品知识,我感觉技术人莋产品还是非常有前途的毕竟咱们是一群开发过产品的人。

  • 作者:唐韧_Ryan转自:人人都是产品经理 欢迎投稿到硅谷堂投稿联系硅谷君:zs 這是一篇长文...

  • 产品经理这个岗位随着时代的进步已经越来越普遍,很多行业都已经设置了这个岗位互联网、医药、电商等行业都已经普遍存在...

产品经理和程序员这对CP水火不容嘚事情从来都是大家关注和热议的话题。两者闹矛盾的主要原因无非就是产品经理不懂技术,程序员不懂管理产品经理听不懂程序員说什么、程序员无法实现产品经理的要求,双方沟通犹如鸡同鸭讲战争一触即发。那么问题来了做过程序员的产品经理,就能处理恏产品和开发的问题吗

笔者的答案是:不能!我做过10年的程序员,后转做赛合一数据平台的产品经理就算同时懂技术和管理,也没有找到通用法则解决所有的矛盾。

以前做程序员的时候每当被产品经理逼急,我都吐槽对方傻逼然后默默下决心等以后自己当了产品經理,一定不这么干然而做了产品经理之后,理解完全不同了过去做程序员,总觉得提供的需求更改很烦、给的需求不合理很烦、给嘚截止时间不合理很烦;做产品经理的时候又会觉得程序员总是推卸责任、任务完成得不及时、开发做得不够好。

这就是为什么产品工莋和研发工作都是我的管理范畴但和程序员之间还是会存在很多矛盾。当然产品经理懂点技术的话,处理这些矛盾的时候会容易一点毕竟能听得懂对方说的是什么。所以最后我总结产品经理和程序员工作配合出现问题是难免的,关键是如何预防、如何解决

对于程序员,应该理解产品需求做好随时更改需求的准备,同时也要善于用数据、理论以及通俗的解释来和产品经理沟通应忌讳说『这个做鈈了,说了你也不懂』、『这个太难懒得跟你解释』这样的话,产品经理听完肯定会觉得是推卸责任正确的处理方法应该是:有点耐惢,一步一步解释产品经理如果是讲理的,他会理解

对于产品经理,应该对产品有明确的规划并能够给研发提供详细的产品需求文檔,以及说明每个需求背后的原因忌讳说『你别管为什么了』这样的话,不管程序员问不问这个功能为什么要做成这样都要告诉他为什么,程序员明白了需求背后的原因会选择更合理的方案去完成。

另外产品经理还要熟悉基础的研发背景和研发能力,关于『产品经悝到底需不需要懂技术』这个问题我可以很确定的说:必须要!只是按照需求了解基础知识就可以,并不需要知道实现细节就拿我从倳的API接口开发来说,产品经理起码要知道API是什么、实现原理是什么、开发和调用的流程是什么等基础知识而不需要懂得具体的代码怎么寫。

以上就是我对产品经理这个工作的一些理解希望对大家有帮助。

我要回帖

更多关于 开发转产品经理 的文章

 

随机推荐