德州计算机培训 产品经理与专案经理经验谈 (上)

  • A+
所属分类:图像处理培训

1. PM做什么?

一间具有产品开发/研发能力的公司,势必少不了「PM」这个职位。

PM,可以指代产品经理(Product Manager),也可以是专案经理(Project Manager),顾名思义就是专注产品/专案的人员。

主要工作内容以产品规画、市场竞合调查、核心版本进度控管、细节验收与跨部门沟通为主。由于需要催生产品或专案,因此工作时接触人的机会极高,很常卡在会议中,也因此被视为公司的跨部门专业协调员。

Really?我再讲一下更清楚的工作流程,也许会更清楚。

每间公司开始一个专案/产品的原因跟考量不同,通常有几个可能:

上门客户提需求

异业谈合作

内部提案(包含上级的突发异想XD)

无论需求来源,PM 与需求端谈完初次需求后,多半要据此提案(此时通常会产个初步 user story、wireframe 等,跟工程师与相关人员确认技术、所需时程),其后再次确认规格,无误再跟工程师谈版本时程分割等。接著,就看每间公司的开发流程,可能会有些许差异,但以现在流行的敏捷开发为例,多半会以一到二周切时程,快速做出第一个最小可行版本。后续是否再开发,或者修正提案、改开发方向,又是后话。

听起来似乎不难,但现实比较有可能是这样:

(1) PM 谈完 A 案的初次需求,旋即在技术面被打枪。回头跟客户调整需求,却不被理解,遇上重重阻碍。

(2)或者 A 案的初次需求没遇上问题,但进入开发前期时,客户觉得花太多时间评估了,决定撤掉 A 案。

(3) A 案开发到一半,由于其他即上线的 B 专案需要资源,因此主力人员被调走,A 案无限期停摆。
以上所有状况都很基本,更多离奇、PM 难以独力处理的情况都会出现,因此「跨部门沟通力」跟面对案子各种状况也不混乱的「大颗心脏」都很重要。

汇集众人的点子,有时能打造出惊喜礼物,有时却产出了一场灾难。(Photo by Lucas Allmann on Pexels)

2. 两个都叫PM,有什么不同?

产品经理与专案经理的英文简称,很巧地都是「PM」;简单来说一个以产品为主,一个则以专案为导向。你也许仍听不出两者的差异,但没关系,在中小企业占多数的泰安,也许是企业规模不够大的关系,或者是基于大家都知道的原因, PM 头衔差异真的不大。(至少受访的 7 位 PM,每一位都得兼著做。)

通常,Project Manager 比较偏技术与规格层面,由于其主要工作是确保专案能如期完工,因此需要解译需求、思考做法,并在做法被工程师打枪后,提出其他解法(当然,也可以请工程师给你建议)。总之,与研发的沟通极为密切,也有非常多的技术活需要思考与判断。

至于 Product Manager,则比较像是从使用者体验与需求的角度,规画一个产品应该有什么功能、起什么效果,从无到有生出一个产品。

用工作对象来分,Project Manager 的主要思维对内部(老板、主管、团队),Product Manager 的思维则偏向对外部(也就是 B2B 跟 B2C 中,后面的那个B跟C。总之就是对用户!)

不过,为什么需要两种 PM呢?

以流程来说,无论是谁发起了产品/专案的需求,都需要 Product Manager 深入思考功能对使用者的效用,以及需要调整的体验;而 Project Manager 则在需求开出后,检验可行性、与工程师确认如何实作。两人都需要针对开发现况,不断调规格、找资源、沟通需求,是相辅相成的存在。
而到最后,其实两种 PM 的思维会渐渐混同,想著客户需求的同时,也明白技术的限制或可挑战的部分;或者想著技术与需求的同时,会再思考用户是否需要什么、会不会需求开不到点等问题。这境界,就需要时间累积、与你自己的努力了。

如需更具体的说明,可以参考这篇文章:〈PM 有两种,「专案经理」跟「产品经理」到底有什么不同?〉

3. 当 PM 困难吗?

知名的猎人头「江湖人称S姊」,在文章〈PM在做什么?PM厉害在哪?我想当PM可以吗?〉中,其实点出了 PM 的一个重要问题。

PM 是一个相对职缺较多、入门门槛不如想像高,要做得好却极其困难的职位。S姊点出的原因大致有三:

(1) 标准化流程不再重要

进入互联网时代,专案/产品不再追求标准化或大量生产,因此不具管理权,也无专案决定权的 PM,缺乏「控管」的必要,企业似乎也想不出找个专职控管者的必要;

(2) 职衔廉价、信任感低

由于许多人以为 PM 只要会控时程、凹人凹钱凹资源就好,企业征才也没有列出具体条件,因此入门门槛很低;很多企业不知道该给员工什么职衔时,往往也是套个 PM 就让上了。

在这种职位泛滥、能力参差不齐的情况下,开发部门对 PM 的信任自然也很低。

更可怜的是,以前 PM 还可以靠那张贵爆的 PMP 证书证明自己,现在拿出来却只是「努力」的证据,还有可能被以为「只会照本宣科」。

(3) 高级行政助理

不管你懂不懂专有名词、是否了解公司的产品与政策,PM 很容易就因为工作关系,成为部门之间的高级打杂员工。

美其名是跨部门协调者,事实是什么东西没有职权归属、就会落到你身上。

此外,超长的回馈期与累积的挫折感,也非常折磨人。更别提因为自身技术不足或跨部门关系因素,所需面对的人事纷扰。除了上下层与跨部门的两极意见冲突以外,有更多问题会一波一波涌上来。如果是委外开发产品,还得控管外包、对内安抚同工者的不满。

而由于整个专案、产品都由你掌握,久了自然也知道各个部门的境况与需求,因此只有你知道真正可能验收上线的时间(也因此极度绝望)。毕竟其他人都像瞎子摸象,只看到局部,有很多误会与坚持的空间;说穿了只有从头到尾跟著跑的你,看得见那头大象生得什么模样,知道根本没什么美好的想像。也因此,你可能会长时间处于焦虑中。

在正式上线交付营运团队之前,即便有快乐与回馈,也都是短暂的。

总之,技术混杂著人事碰撞就是一团大灾难。而解决这团灾难,就是你的工作。

你能经得起开发部门信誓旦旦告诉你:「这个功能不能做」「这个功能做不到」「不是原生规格很麻烦」,但其实功能早就在系统内、只是他懒得找或想敷衍你吗?

你能承担 3 周后核心版本要完工,但 KPI 的运算方法出不来、系统无法验收,团队无法加人加时,但客户也不愿放宽时程的庞大压力吗?

你敢不敢在上头开出奇妙需求、或是自己对完规格,发现功能不可能做到时,回头跟上司否决提案,而非压著 RD 强跑专案?

或者该问,你是否有足够坚强的心理素质,面对四面八方(包括你自己)的质疑与挑战呢?

有时我觉得,PM 就像负责著色的人,专案最终可能会是一团彩色乱线,有时则是有模有样,端看你听取意见后,怎么引导画笔(伙伴)。

4. PM的快乐与成就感

看完以上一大串经验分享,也许你有点恐慌,搞不懂做 PM 有什么必要。但先别急著下定论,让我们来看看 PM 的快乐与成就感吧!

多数 PM 都认为,「产品如期推出、品质达到一定水准、获取充分的用户反馈」是漫长奋战后最佳的回馈。要知道,即便是「小步快跑」、「敏捷开发」盛行的当代,产品开发依然是一条漫漫长路。

要在海量竞品、复杂资讯、庞大数据中,梳理出用户的需求,并规划、执行整个产品与专案的开发,从来都不是一件容易的事。而由于 PM 既无管理权,又多半无自主开发的能力(比如 coding、美术),因此被质疑的机会很多,要抓紧所有工作伙伴一起向前冲,更是困难。

也因此,最终收获的果实才会加倍甜美。

就这样吗?

对,PM的快乐就是这样,但也很足够了。

想想这世界上有多少产品与专案胎死腹中,你就能明白,看到产品与专案面市,获得一位客人的评价,是多么令人激动的事情。

也许再加一个:在一片混乱中梳理出一条可行的道路,其实某方面来说也是很有成就感的。这样的成长非常明显,尤其当你回头看第一个专案的兵荒马乱,再看看自己几年后的不同,相信差别一定很大。如果还能被团队伙伴肯定能力,就更锦上添花了。



发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: