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

[核心提示] 既不是美工，也不写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，做一个能沟通的前端，让产品在用户体验的丛林中一路披荆斩棘。