俗话说，一千个职位眼中有一千个产品经理，其中，999个都是凶恶难搞的形象。唯一的那个例外就是前端，这是一个怎样的职位？我们来听听一个前端眼中的PM和整个世界。

无论众人之前怎么称呼我们：前端工程师？重构工程师？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 请示对于项目的参与，哪怕只是多一个项目邮件的抄送的对象，也会为后期前端代码的部署带来极大的便捷。否则遇到设计已定稿，前端做不出来的情形，责任在谁？多半会归给前端技术储备不足，同时让设计师也很尴尬。

前端的“职业病”

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

1.图层化的世界

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

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

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

2.总是考虑兼容性

知道前端最关心 IT 业界新闻是什么吗？

• 浏览器又升级了，版本号直逼 xx

• 公司宣布开始做浏览器

• 向 W3C 提交了一份新的 xx 标准

• 推出了 xx 最新 Retina 硬件，配备 xx 浏览器

• 又毫无节操的推出了非主流分辨率的屏幕

• 系统 500 天后将停止更新

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

结语

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

本文作者：@hzlzh 原文：极客公园