为何前端不常跟产品经理掐架

标签: 前端 产品经理 | 发表时间:2012-12-04 13:12 | 作者:hzlzh
出处:http://www.geekpark.net/

作者: hzlzh / 产品观察家
Code is Poetry, Life is Sweet.
[核心提示]既不是美工,也不写JAVA,我们是前端工程师,看看我们究竟想和谁打架?

前言:无论众人之前怎么称呼我们。前端工程师?重构工程师?JS 交互工程师?UED?切图仔(妹)?美工等等,都没关系,下文统称为:前端。至于“产品经理”,PM 这个缩写就简明多了。如果你是这里提到的前端,那么无论你是否戴表,你已经被代表了,还望见谅。

前端和 PM 的关系

早在上古时期,UI 和 UE 还未分化,UE 还未被重视到今朝这个程度的时候,前端这一职位多半被划分到设计部门,所以对于依然混淆前端为美工的朋友,我们只会淡然笑曰:呵呵。

切入正题,我们都知道,在产品开发流程日益清晰的今天,PM 这个角色承担着越来越重要的作用,外界评价一个产品的好坏优劣,第一干系人就直指 PM,然而在产品的流水线上,距离用户最近的一环却是前端了,因此 PM 如何跟前端进行良好的沟通就显得尤为重要。浅显的来讲,设计师出图,开发写程序,前端做交互,用户眼里的每一个页面元素,指尖上的每一次交互,都经过了前端代码的包装和沉淀。

所以,前端对用户负责,也对 PM 负责。

由于前端这个职位的定义和定性较为宽泛和模糊,尤以大中小企业的不同而各有差异(如:细成分 JS 交互和重构两个方向),但无论做重构也好,做交互也好,前端最重要的职责就是把 PM 想要的界面和期待的用户体验,制作并呈现给用户,并以自己专业的角度对当前解决方案进行优化和深入研究,反馈给 PM。

前端与 PM 的对话

如果你看过 产品经理专栏的《 技术之于产品经理》等文,大概会觉得多半的时候,一些公司的产品和技术是在彼此掐架状态,其对话或繁或简,比如我们就先看一段 PM 与前端的对话:

PM:这个滑动效果能实现吗?
前端:能
PM:这个 Ajax 交互呢?
前端:能
PM:那这个背景色渐变圆角有阴影而且半透明 Hover 之后有旋转效果的层呢?
前端:呃…
PM:我见到过国外某网站有这效果…
前端:能

前端与PM的对话 - 解

上述对话中前端只说了 3 个“能”字,PM 也得到了想要答复。

当然,前端是有思想的,和大多数程序员一样,我们思考的时候对外是一个黑盒,那是不是说:一个有思想的图灵机就能让所有前端丢掉饭碗呢?答案是否定的。即便不用“中文房间假设”( The Chinese Room)去验证,我也保证最终 PM 还是会选择有思想有创造力的前端而非机器。那么我们姑且打开这黑盒,看看上面那段对话里前端脑中那诡异的世界:

PM:这个滑动效果能实现吗?
PM:这个 Ajax 交互呢?

前端脑补:
* 涉及到样式和交互
* 页面布局能通过的浏览器:IE8 + Firefox3.5 + Chrome 9 + 等等
* IE6/7需要写个 hack
* 要新写响应式 CSS 来兼容移动设备(iOS和Android)版本
* 图片需要一份x2版本兼容 Retina 显示器
* ……
* 是否针对有色彩障碍用户进行优化?
* 是否需要兼容盲人浏览器?
* 如果用户禁用 JS 脚本该如何
* 如果是打印设备,样式如何
* (能)

在经过了若干个回合的斗争后,前端给出了最终解决方案“能”,那么继续:

PM:那这个背景色渐变圆角有阴影而且半透明 Hover 之后有旋转效果的层能实现码?
前端脑补:(呃...)如果是用 HTML5 实现,so easy,但是 F*ck IE6,其实不建议做这么华丽的装饰在层上的。

PM:我见到过国外某网站有这效果…
前端脑补:(能)好吧,既然我们的用户不是外国人,那么眼下,还是多写点 Hack 样式,能兼容都兼容吧

现在你知道前端最想和谁打架了吧?

PM 如何与前端沟通

上面罗列了这么多,我们大概可以看出,前端最大的“敌人”既不是强势的 PM,也不是频繁变更的需求,而是万恶的浏览器厂商。这也是前端通常为什么不跟 PM 掐架的一个原因,本来嘛,当内忧和外患共存的时候,前端更理所当然的把所有怨恨矛头指向 变化多端的浏览器,指向不愿升级用户群体,这就是主要矛盾。(此时,PM 是不是在偷笑?)

即便是站在敌对的观点,知己知彼,百战不殆,PM 若能洞悉前端的一些习性,了解前端的某些思维方式,那么将用户体验发挥到游刃有余便不再是多么难的事情。况且前端本来就是开发工程师和设计师之间的纽带,我们非常愿意配合好 PM,按照 PM 对产品的理解打造出有优秀的产品。

同样,在一个被理解和被认同环境中,前端也会得到满满的成就感,并同时激发出非凡的创造力。

前端是园丁(PM)手中的剪刀,噢不,应该是园丁的手指。(别忘了还有设计、开发等等别的手指哟~)

前端如何与 PM 沟通

换个位置,那么前端在和 PM 的沟通又需要做到什么呢?

有些团队这样默许:“前端没必要参与到产品的需求和设计,设计出来后自然会找你们。”

面对这样的困扰,我们前端自己要发挥主观能动性,极力避免“木已成舟,舟很破”的情况发生,做法很简单,主动的向 PM 请示对于项目的参与,哪怕只是多一个项目邮件的抄送的对象,也会为后期前端代码的部署带来极大的便捷。否则遇到设计已定稿,前端做不出来的情形,责任在谁?多半会归给前端技术储备不足,同时让设计师也很尴尬。

开个玩笑:(PM)是前端的朋友,再不济也是“敌人”(设计师)的“敌人”(PM)。(PM 又该笑了)

注:试试把()中的人换个位置,LOL

前端的“职业病”

继续知己知彼,了解前端这个话题,讲几个前端的“职业病”,可以当作福利,用于对症下药,今后和前端沟通起来会更顺畅。(每个职业都有自己的“职业病”,当然我不认为这是病态,只是这样形容会比较容易理解)简单列出两个:

图层化的世界

可以说在未来的 Google Glass 出现之前,我们所接触的 Web 页面几乎都是 2D 的,前端(设计师们会附议么?)眼中的世界通常会有一个 2D 的图层版本。

比如,在公交地铁站边看到的巨幅广告,前端眼中第一感觉是,如果把设计重构为 HTML 页面布局该如何,标签怎样嵌套会优化,CSS 兼容性又是如何,是的,我们常会把图片打会到图层的原型来看待,然后进行下一条“职业病”去迭代。

勤换位思考总不会是坏事的。

总是考虑兼容性

知道前端最关心 IT 业界新闻是什么吗? (看看下面几种)

  • xx 浏览器又升级了,版本号直逼 xx
  • xx 公司宣布开始做浏览器
  • xx 向 W3C 提交了一份新的 xx 标准
  • xx 推出了 xx 最新 Retina 硬件,配备 xx 浏览器
  • xx 又毫无节操的推出了非主流分辨率的屏幕
  • xx 系统 500 天后将停止更新

是的,我们关注那些硬件数码设备的发布,但相比设备本身,我们可能更关心屏幕分辨率,默认浏览器内核,JS 性能跑分等等。我们花费大量的时间和精力去解决不同浏览器,不同屏幕尺寸,不同设备内核之间的兼容性,为的是尽可能多的用户得到较好的用户体验保证。我们几乎会把所有的新鲜事物联系到兼容性的层面来讨论,这是可能是旁人无法理解的。

旧版本固然是稳定,但新版才是王道啊。

小结

做一个能沟通的 PM,做一个能沟通的前端,让产品在用户体验的丛林中一路披荆斩棘。

极客观察均为极客公园原创报道,转载请注明原文链接。

原文地址: http://www.geekpark.net/read/view/167656

关注极客公园,即时获得最新内容: Twitter | 微信:极客公园 | 新浪微博 | 花瓣网 | 人人小站 | Google+ | 点点

相关 [前端 产品经理] 推荐:

为何前端不常跟产品经理掐架

- - 极客公园-GeekPark
[核心提示]既不是美工,也不写JAVA,我们是前端工程师,看看我们究竟想和谁打架. 前言:无论众人之前怎么称呼我们. 美工等等,都没关系,下文统称为:前端. 至于“产品经理”,PM 这个缩写就简明多了. 如果你是这里提到的前端,那么无论你是否戴表,你已经被代表了,还望见谅. 早在上古时期,UI 和 UE 还未分化,UE 还未被重视到今朝这个程度的时候,前端这一职位多半被划分到设计部门,所以对于依然混淆前端为美工的朋友,我们只会淡然笑曰:呵呵.

产品经理

- - 人月神话的BLOG
再谈下怎样能够算得上一个合格的产品经理,一个人不是说你能够有产品构思,能够画点原型,能够做团队和项目管理就是产品经理. 苏杰原来有本书叫《人人都是产品经理》,看了后大家可能会觉得做一个产品经理是挺容易的一件事情,但是自互联网提供和设置了大量的产品经理岗位后,产品经理这个词基本就烂大街了. 我们如何来界定一个产品经理,如果简单点来讲可以理解为 根据自己长期的项目和运营实践,通过自己的敏捷洞悉能力和分析能力,能够将当前的市场需求或潜在的市场需求转化为具体的产品需求,并能够核心的定义产品功能模型和价值输出,同时能够通过项目和团队管理的能力,凝聚一个小组形成一个真正的团队,将自己的产品构思付诸于最终产品实现的人.

产品经理好与坏

- lnsoso - 随心所记 - 生活中的dodo
例如李明远,设计了百度贴吧和百科这两个重量级产品,只可惜我并没有亲见这些产品设计的过程,客观的说,我还不知道什么才是厉害的产品经理. 既然我有限的经历无法胜任点评产品经理这个重任,那就来感性的说一下我所欣赏和厌恶的产品经理类型吧,权当我所谓的好与坏. 我很欣赏曾经的百度有啊中充满想象力的产品经理,明远和东宝都能算作具有这样特质的人.

产品经理是炮灰

- 张金龙 - 所有文章 - UCD大社区
前些日子有篇网文,鼓吹产品经理的重要性,几乎夸上了天. 有人评论道:“是为了争取加薪吗. 一个人能取得多大的成功,取决于两点:1、他有多少才华与热情,2、这些才华和热情是否能战胜环境中的困难. 很遗憾,摆在产品经理面前的障碍大部分是不可战胜的. 在这篇文章里,我们只讲靠谱的产品经理,不讲不靠谱的. 不论PM靠不靠谱,都分为两种,或者在大中型公司工作,或者在小型公司(创业团队)工作.

产品经理好与坏

- abcd - 所有文章 - UCD大社区
例如李明远,设计了百度贴吧和百科这两个重量级产品,只可惜我并没有亲见这些产品设计的过程,客观的说,我还不知道什么才是厉害的产品经理. 既然我有限的经历无法胜任点评产品经理这个重任,那就来感性的说一下我所欣赏和厌恶的产品经理类型吧,权当我所谓的好与坏. 我很欣赏曾经的百度有啊中充满想象力的产品经理,明远和东宝都能算作具有这样特质的人.

产品经理是炮灰

- Neglect - 坏脾气的小肥
前些日子有篇网文,鼓吹产品经理的重要性,几乎夸上了天. 有人评论道:“是为了争取加薪吗. 一个人能取得多大的成功,取决于两点:1、他有多少才华与热情,2、这些才华和热情是否能战胜环境中的困难. 很遗憾,摆在产品经理面前的障碍大部分是不可战胜的. 在这篇文章里,我们只讲靠谱的产品经理,不讲不靠谱的. 不论PM靠不靠谱,都分为两种,或者在大中型公司工作,或者在小型公司(创业团队)工作.

产品经理“玩”数据

- - 一个产品经理的博客...
  产品经理生来就是要解决问题的. 那如何才能更好、更高效地解决问题?首先要求我们能发现问题,数据分析就是一种常用的发现问题的手段. 通过数据定位问题,然后用设计方案来尝试解决问题,之后再用量化的数据指标来评估问题是否解决了,解决了多少. 通过迭代优化,问题就能够得到较好解决.   本文结合自己在在登录产品的体验优化中积累的一些实战经验,重现过程中的设计点滴,有效果明显的方案,也有效果不明显的优化尝试,最后将总结一些通用的设计思路.

好的产品经理,差的产品经理

- - Xiaoxiao's Weblog
本文转载至 译言网 作者: Ben Horowitz. Ben Horowitz这篇不朽的杰作诞生于1996年,但时间的久远丝毫不影响其对当前的警示作用. 彼时,作为Netscape产品管理部门经理的Ben,没有假大空地介绍产品经理的角色和责任,而是很直观地对比了一个好的产品经理和差的产品经理.

一个谷歌产品经理眼中的产品经理

- - 互联网分析
我在创业公司已经呆了好一阵子了,我发现招聘这个事儿在大公司和创业公司还真是截然不同. 在雅虎搜索的时候,我们一直是持续的进行招聘的. 我一周会进行大概5-8次的面试. 简历、面试、offer,总是一个接一个,不间断. 现在我已经不做招聘经理的事儿了,我在创业公司只负责招很少一部分的产品经理. 但是总有人在招产品经理,而我也总是面试团队的一员.

优秀的产品经理/糟糕的产品经理

- - 标点符
每个产品经理都希望自己时优秀的,而不是糟糕的. 但如何定义是否优秀却没有一个统一的标准. 最近看到了一片文章,中间的一些观点给了我非常大的启发,让自己意识到原来自己做的很多事情,其实是属于糟糕产品经理做的. 优秀的产品经理:关注团队的快乐指数. 当一个团队对产品开发过程感到不满的时候,就无法为客户创造出好的产品,他们也不会喜欢自己的工作,一个好的产品经理除了会收集正式的反馈,同时也会收集一些关于项目、迭代余流程的非正式反馈.