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

& nbsp ;

前端和 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,做一个能沟通的前端,让产品在用户体验的丛林中一路披荆斩棘。