11月 29, 2012

产品经理是个辛苦的工作,除了要最热爱产品,练功坐禅研究用户体验外,还要和一大堆人打交道——写代码的,做设计的,搞运营的,做市场的。前两类人算是艺术家,自然会带点艺术家特有的奇葩气质,第一类人又是和产品经理打交道的人里面最聪明的,一个不小心,没准就被程序猿们划入“白痴”族群,作为茶余饭后鄙视的对象。

那么,产品经理要懂多少技术,才能游刃有余的和程序猿们打交道呢?

在 Gevin 看来,成功的产品经理必须是被程序猿尊敬的。虽然程序猿的水平和素质也良莠不齐,但要做一个成功的产品经理,必须假设面对的是一帮最优秀的程序猿,这样才不至于被当作白痴来骂。因此程序猿应该是这样一帮人,他们是聪明的,坚毅的,勇于克服困难的;中间也不乏文艺类的,或懂艺术,或注重体验,或关心人文。产品经理也不必为了能和各种程序猿沟通,使自己面面俱到,但至少对自己要有一个明确的定位,并把自己的定位展现在程序猿面前。

Gevin 会把产品经理分为两类:

A:改变世界的海贼

B:自给自足的农夫

A 类是那些真正热爱互联网的人,有自己的梦想,希望在互联网的海洋里冒险驰骋,不断创新,不断探索前行,看中的是这份冒险精神,享受的是冒险成功后的喜悦,他们也许会失败,但虽败犹荣,他们一旦成功,则会带来革命性的东西,甚至改变世界。B 类只是在互联网上求生存的人,他们并不热爱互联网,如果有更好的生存平台,他们可以放弃互联网;他们会踏实的基于数据做些分析,把一些实际可靠的元素融入产品,只要赚钱就行,创新和探索这些不靠谱的东西,尽量不碰。

产品经理在开始做事之前,需要明确自己是 A 类还是 B 类,与程序猿沟通时,通过语言或者行动表明自己的定位。如果你是 A 类,优秀的程序猿会成为你强大的助手,如果你是 B 类,好的程序猿也会帮你衣钵满载。但如果你有 A 类的心,却做 B 类的事,不被骂白痴才怪;如果你按 B 类的要求与程序猿沟通,却心怀 A 类的雄心,高傲的程序猿会认为你在玩弄他。

A 类的产品经理,对技术的要求高,能力覆盖范围广,程序猿对 B 类产品经理的要求,只是 A 类的一个子集。下面提到的产品经理,如无特别说明,是指 A 类。

程序猿也知道产品经理是要与多种职责的人打交道的,要有较强的综合能力,不会在技术领域拿自己的强项和产品经理过不去,但他们同时认为一个优秀的产品经理要具备一些能力,能力不足的产品经理不会被程序猿尊敬。这些能力包括:

  • 对技术的理解
  • 美学的修养
  • 强大的学习能力
  • 无限热情

对技术的理解

产品经理不懂技术当然不行,但产品经理也没必要掌握技术细节。产品的技术实现是由程序猿完成的,产品经理只要做到理解程序猿,尽量和程序猿做“无损沟通”即可。

非技术出身的产品经理是比较辛苦的,因为你要在技术上下不少功夫。技术不简单,种类多,各有特色,发展日新月异,是产品经理和程序猿要时刻关注的主题。即便是对技术做整体的宏观的把握,也不是一个不懂技术的人一时半会就能融会贯通的。非技术出身的产品经理首先要迈过技术上的一道坎,让不懂技术的人看来,你是一个技术领域的内行。技术出身的产品经理,对技术的理解自然不是问题,但在和程序猿沟通时,会不自觉疏忽的是,容易过分纠结于细节,尤其是曾经在技术领域有不菲造诣的产品经理。产品经理不是对产品做技术实现的人,技术更新那么快,技术细节本身甚至技术实现的理念,会迅速更新迭代,产品经理和程序猿死磕技术细节得不偿失。

上文提到的“无损沟通”,是指产品经理和程序猿在沟通中彼此完全理解,不存在疏漏和误解。这是不可能的,但这必须是二者沟通的目标。

产品经理和程序猿沟通时,两个方面尤其重要:

A:对需求的沟通

B:对技术实现的沟通

对需求的沟通主要应用于产品经理向程序猿阐述需求的场景中。程序猿实现产品功能,是基于对需求的理解;在功能实现过程中和实现完成后,需求的变化又可能带来产品实现上的灾难。如果程序猿不能准确理解产品经理对需求的描述,很可能实现的功能与产品经理的想法大相径庭,浪费大家的时间;如果产品经理想法不够明确,导致需求变来变去,无疑是对程序猿的恶意攻击。需求上任意一个小小的变化,在代码实现中的都有可能产生巨大麻烦,甚至会动摇代码的整体架构。从程序猿的角度来说,虽然程序猿在技术实现时以构建稳定的系统为目标,尽量灵活应对需求的变化,让系统易于扩展和维护,但这也是要基于程序猿们对需求的理解,以及对潜在的需求变化的预测。如果在沟通过程中做不到让程序猿准确把握需求,那就不用考虑产品实现的满意度了。

对技术实现的沟通主要应用于程序猿向产品经理沟通的场景中。如果产品经理对技术理解不够,程序猿很难向产品经理讲明白自己的工作现状,当产品经理想要改变需求或者希望为产品添加新的特性时,也无法准确理解程序猿对此产生的各种反应。

只有依靠足够技术基础,产品经理才能理解程序猿对工作和任务的描述,把握技术实现的难度,制定更加合适的计划。至于多少技术才算“足够”,需要产品经理和程序猿慢慢中磨合了。

最后,请相信程序猿,请在技术上放手!

美学修养

为什么程序猿可能会关注这一点?虽然程序猿不会像设计师那样与产品经理讨论产品的设计和交互等问题,但也会关注下用户体验的,而且优秀的程序猿也是艺术家,没准还是个真实的画家,要想赢得程序猿的尊敬,美学修养低于程序猿说不过去吧?

学习能力

产品经理和程序猿,是互联网上最需要频繁接受并掌握新知识的人。新知识新概念接受的慢,谁放心把产品交给这样的产品经理?何况产品经理要与聪明的程序猿们交流沟通,学习能力差的产品经理在沟通过程中会遇到各种困难,各种无法理解,在工作过程中也无法应该程序猿的尊敬。

无限热情

这是产品经理最重要的素质,也是程序猿最需要从产品经理身上获取的元素。产品经理是最热爱自己产品的人,如果产品经理不能把自己的热情传递出去,程序猿也不会实心实意做产品的实现,实现一个没有激情的产品经理的想法,实在不是一件很 cool 的事情!

小结

产品经理若要和程序猿默契配合,最重要的是要赢得程序猿们的尊敬。产品经理并不是懂的技术越细越好,而是要在宏观上对技术有总体上的把握,在微观上懂得放手,相信程序猿,并锻炼好自己其他几项能力。

做一个站在科技和人文交叉口上的产品经理吧!带着自己的梦想和激情去改变世界,会有一帮优秀的程序猿帮你的!

Tags: ,,.
11月 22, 2012

文/iDoNews认证作者 极客公园

PM(产品经理)VS RD(研发工程师)

常听业内人士说起,产品经理(PM) 和 研发工程师(RD) 之间是很喜欢互相掐架的(知乎上的讨论),对个人而言感同身受,因为自己内心的技术小人和产品小人也是常常互相掐架的,感觉更像是一种是思维模式上的互掐。当然这并不代表这两种思维模式是相互对立的,好的产品显然不是掐出来的。PM 和 RD 之间需要的是一种建立在尊重和理解上的有效沟通。不过铺砖垒石的朴实研发工程师们还是比较倾向于被动的,所以我的建议是,产品经理主动去了解技术

为何 PM 要懂技术?

不得不说,技术人员是很傲娇的。PM 虽然并不是凌驾于 RD 之上的角色,但遵照着 PM 的设计来进行实现多多少少会让 RD 生出低人一等的感觉(不乏 PM 本身也是这么认为的),这可能是让骄傲的技术流不爽的地方。所以 RD 不待见 PM 可以说是自然而然,如果 PM 还不懂技术,那么 RD 就更加可以在自己的长处上放心大胆地鄙视 PM 了。这倒也不是 RD 的小人得志,几年的技术经验会让他们觉得这更像是一种自我保护,保护自己引以为豪的知识领域不被非专业人员指手画脚。所以如果 PM 懂技术的话,是会在一定程度上赢得 RD 的尊重的。这么说似乎有点绕,说白了就是,如果我是 RD,我会更尊重懂技术的 PM。

与被“指点”的设计师不同的是研发很难被“指点”

懂技术解决的不仅仅是心理层面的问题,事实上,这会让 PM 和 RD 之间更容易交流。我们常常觉得 RD 出于对技术的自负而难以沟通,如果 RD 开始甩术语、甩原理,那么多耗费一些时间和耐心也还是能够理解的,有时候,更可怕的就是 PM 会觉得自己和 RD 的对话完全发生在两个次元里。其实 RD 们在这样交流的时候,并不是在企图彰显技术的 NB,这似乎更多的是一种习惯,是技术流长期和技术流交流所养成的习惯。所以,PM 懂技术,可以更好地去理解和适应这种习惯,至少也可以让自己不被 RD 们忽悠了,PM 如果被 RD 绕得云里雾里,无法反驳、无力判断,那也是一件很可怕的事情,如下面这个来自 xkcd 的漫画。

另外懂些技术可以把 PM 从高屋建瓴拉到脚踏实地。很多时候 RD 会消极配合 PM,很有可能是 PM 的设计在技术可行性上出现了问题或制造了麻烦。于是在 RD 看来,PM 就是天马行空不负责任的 YY,却把落实的各种不靠谱问题都抛给了他们。就好像建筑师不可能对土木工程毫无了解,PM 有时候也需要在技术层面上了解一砖一瓦是如何落实的,才能让设计变得踏实。

PM 也许可以不懂技术?

行文至此,也该中庸一下,其实 PM 懂技术,也未必是必须的,比如我个人内心的技术小人就会把这三种情况排除在外。

1. 这位 PM 有着非常成功的产品经验

技术流虽然骄傲,但也有着崇尚权威的谦卑。如果你有着非常辉煌的历史,即使你对技术一窍不通,但凭借着“PM 将再一次带领大家走向产品成功”的信念也足以令 RD 们信服。不过能够做到这种程度的 PM,不懂技术的应该是凤毛麟角吧。

2. 这位 PM 有着非常敏锐的产品直觉

如位 PM 有着非常敏锐的产品直觉,尤其对新技术可能带来的产品革新有着灵敏的感知的话也是被排除在外的。好的 sense 是能令其他人都跟着拍手叫好的,RD 再顽固,也是能够嗅到方向的,所以也会愿意跟着你的直觉走。不过,sense 这种东西,有时候跟天赋一样可遇而不可求。

3. 这位 PM 有着很强大的逻辑思维能力。

技术流都是逻辑控,如果你的设计出现了逻辑上漏洞或者问题,将会让 RD 们无比鄙夷,如果已经令 RD 们做了很多无用功,那更可能招致怨念。正是因为 RD 们对逻辑的执着与看重,PM 的逻辑思维能力就更加成为了一个巨大的考验。另外学习技术其实可以锻炼人的逻辑能力。当然,懂技术到逻辑强大,这不是充要条件。

小结

说了这么多,倒也不是要标榜懂技术的种种好处,其实技术有时候反而会给设计思维带来限制。例如,PM 看产品可能首先考虑的是产品定位,而 RD 看产品首先想到的是功能。个人以前就很喜欢拿功能攒产品,做出来的东西基本不能称之为产品。这也许就是前面所说的思维模式上的差别。PM 的思维模式其实是很宝贵的,所以学习技术,还需慎重。

总而言之,PM 应该是懂些技术的,或许不需要懂到技术的细枝末节,但至少要有常识,再次也要对技术表现出尊重和热情。只有这样才有可能成为一个优秀的产品经理。

一天一分钟,业界在听你回声。如果你有更加丰满、个性化的互联网点评视角,欢迎奔跑加入iDoNews业内点评团,私信@沸话小欧 即可。

转载请注明 iDoNews认证作者/极客公园

Tags: ,,.