作为一个有点想法的web前端从业人员，是从业人员，在项目中难免会跟不同的角色打交道。有让自己舒服的，也有让自己难受的；有让别人舒服的，当然，也有让别人难受的。我们当然希望最好的结果是大家都很舒舒服服地把事情做完做好。这便就是本文要探讨的地方。
项目中的角色
我根据自己经历的项目，大致分了如下几个角色。然后站在一个web前端的角度来吐槽一下与其他角色的种种“轶事”。同时也描绘一下我认为比较不错的处理方法。
产品经理
我所理解的产品经理是一个为其他所有角色服务的“奶妈”。所有问题，都可以找他。不过首先，他是项目之所以开展的起始。我认为产品经理的职责是：
- 竞品分析。这个很重要。知己知彼，百战不殆。
- 需求管理。从各种途径搜集需求，然后归纳，整理，推敲，合并，删减。最终转化成功能。需求管理过程可以有其他人一起参与。最好是有一套需求管理系统对需求进行管理，方便大家同步信息。只要能实现需求录入，需求评论即可。
- 用户行为统计分析。这是产品经理唯一能拿来说服其他角色的客观数据。我们的产品是最终给用户用的。用户的使用频率，使用反馈是最好的论据。比如：产品经理要求web前端把已做好的左侧的图标导航改成图标加文字导航，一般情况下，web前端肯定会认为产品经理又在瞎搞。如果产品经理拿出用户反馈数据“70%的用户不清楚这个导航是什么含义”，那他的要求就更具有说服力了。
- 巧妙设计。 有时候一些NB的功能不是非要靠技术的。如果能巧妙利用一些被常人忽视的现有特性，然后设计出眼前一亮的功能，会让产品更富有活力。比如，之前看到一个APP，利用手机通讯录可以保存大量联系人及电话，对一些已经被标识的骚扰电话进行本地标识，从而巧妙的实现未越狱IPHONE手机的黑名单提示功能。
- 产品设计。这个概括有点大。其实包含了许多功能，诸如：
- 产品流程设计；
- 产品具体功能设计；
- 产品角色设计；
- 原型设计；
设计师
设计师这个没什么说的，就是在理解产品经理的原型的基础上，将它美化。当然，说的高大上一些，就是：
- 用户体验设计；
- 产品风格设计；
- 视觉风格设计；
- 导航设计；
- 品牌包装设计；
这里面，和前端有关的，主要就是产品的界面（我们讲的主要还是web项目，虽然目前互联网项目还必须要有一个APP，此处略过，以后有机会再聊）。
前端
这里指web前端，如果有APP，也主要指的是H5。前端的产出最终将直接面向用户。大家可能会认为，设计师的设计稿也是最终面向用户啊？但是有谁见过页面出问题了后，不管是用户，还是产品经理，后台，测试，老板，有谁去找过设计师？都是第一反应找前端，找前端。作为一个前端狗，本人深有体会。
后台
给前端提供数据，以及实现产品核心业务的开发人员。前端所有数据都是从后台而来。
测试
测试也分好几种，
- 功能测试。以产品经理的PRD和原型为依据，编写功能测试用例，逐项测试；
- 接口测试。我这里已经假定项目的架构是前后端分离的模式，因此，一般测试也会单独对后台提测的接口进行接口测试。
- 界面测试。很少有项目需要此测试，如果要进行此测试，那恭喜你，你们的产品成熟度已经很高了。做界面自动化测试，最费时，费力，且不一定有效果。目前各大厂有一些方案，无外乎使用phantomjs类似的无界面浏览器脚本框架，搭配测试脚本写的测试用例，进行测试。如果界面频繁变动，那测试就会累成狗。我之前所经历的一个项目（或产品？），为了解决界面频繁变动对测试脚本的影响。我提出一个方案：让编写自动化测试脚本的难度降低，即采用类似DSL（domain specific language 领域描述语言），实现简单的命令和逻辑，替换掉测试人员用类似excel或测试用例管理系统的人类文本语句。和测试人员一起配合，后来也只是用在了版本发版后的冒烟测试上。
老板
这个不用说啦，老板最大，老板就是最大的用户。【捂嘴不笑】
如何与产品经理沟通？
- 前端人员与产品经理沟通的依据就是 原型设计。
- 总是会遇到一些数据输入规则不清的情况，记住，这个时候，在和产品经理沟通清楚以后，一定要求产品经理更新原型设计。否则，过一段时间后，测试拿着原型设计给你的界面测出一堆bug，你就哭吧哭吧不是罪。
- 在动手前，一定要与产品经理确定好哪些是不会变的，哪些部分可能后续版本会扩展。当然，产品经理给你打的包票你也最好不要全信，还是要结合自己对业务的理解，做好未雨绸缪，否则到时候，产品经理哪天跟你说要改动某个完全没想到的功能的时候，你再说改动会影响全局，也是没用的，苦的还是你自己。
如何与设计师沟通？
- 前端和设计师沟通的最好方式是样式规范。这里的样式规范不一定是css，只要是设计师能理解的描述标识就行。比如：可以和设计师约定好，目前按钮有3种，分别是：btn1，btn2，btn3。设计师每次出设计稿的时候，给按钮标注：btn1，btn2，btn3。然后到前端这里，可能就是对应的某个class：btn-main,btn-sub,btn-third.为了方便设计师设计，在设计师完成了一些基础控件风格后，可以整理一套模板控件库，方便设计师后续套用页面。
- 有了前面说的约定。做皮肤，那就是水到渠成的事。
- 对于一些设计师天马行空的设计，切记要从技术上进行权衡。如果某个效果的实现难度大于最终体验效果，最好沟通后，降级处理。如果有明确证据（这里就是来自前面提到的用户统计）要求必须实现，那web前端就只能迎难而上。
- 设计师在设计界面的时候，往往喜欢找最好的界面状态，然后画出效果。比如：数据刚好满一屏，某个侧边栏的宽度刚好够放一个弹出层。这个时候，当设计稿交到你手上的时候，一定要问一下设计师：没有数据怎么办？宽度不够怎么办？数据太多怎么办？这些都是因为设计稿只能展示某一个界面状态。而实际的产品界面，状态实在太多，各种条件的组合，最终还是得由前端来负责梳理清楚。
如何与后台沟通？
- 前端与后台的沟通依据必须是接口设计文档。以前是用文档，现在最好的方式，是后台在设计接口的时候，直接录入接口管理系统，明确表明某个接口的入参，入参类型，出参，返回错误码。只要发现问题，以接口设计文档为准，根本不用和后台扯皮。
- 另外，有了接口管理系统，后台也很方便的对接口进行修改。测试还可以根据后台的接口设计定义，对接上接口自动化测试程序。比如：后台修改了某个入参类型，接口管理系统发出更改事件，测试人员根据类型，决定是否修改测试用例，或补充测试用例，实现高效的自动测试。
- 有时候前端与后台经常在为某个数据处理该有谁来实现而扯皮。比如：前端想要A格式数据，后台为了统一，偏偏输出的是另一种B格式，这样每次前端都得再转一遍。我的看法是：
- 如果是数据的格式化，则有后台给一个数据，由前端负责格式化处理并显示。比如：时间，后台统一给一个毫秒值，前端自行决定如何显示；
- 如果是要多种数据，最好后台统一处理好后，封装一个新的接口提供。这主要是考虑到前端请求太多，会有性能影响。我之前有一个关于这个问题的解决方案，不一定最好，也算是一种探讨吧。github.com/houyhea/blo…
- 如果有一些数据处理，逻辑处理是除了web前端，APP也会需要的时候，那么最好由后台来统一处理。前端永远只是一个可视化终端。所以，最好不要把很多核心的逻辑和业务放到前端来做。检验是否核心业务的方法其实也很简单，就是，设想一下，如果把前端拿掉（比如我换一个控制台作为终端），整个产品或系统还能否稳定运转？
如何与测试沟通？
- 为了避免测试提出一些无效的bug，最好提前参与测试的用例评审（如果有的话）；
- 在某个功能的实际深入开发中，所有的修改最后都要要求产品经理更新到PRD以及原型设计里，否则，测试如果不知道的话，会认为是bug；
- 最好不要怕测试的刁难，多想想，如果测试放水，等上线的时候，用户半夜再来刁难的时候，你就只有老实拍起来改bug；
- 有些测试提出的不太靠谱的bug，最好付之一笑。我曾经碰到过一个测试mm提了一个bug，由于她输入大量重复字符，且有交替重复，整体产生某一个行倾斜的错觉。她竟然认为是bug。我只能无语。
如何与老板沟通？
- 等一切都做好了，正准备上线的时候，老板事必躬亲的看了一眼：这个版面不对，必须改！此时的你的正确做法是：是的老板，我也总感觉哪里不对，您一说我就明白了，立马就改！
- 老板才是你的衣食父母，老板的话就是圣旨。别笑，因为等你哪天坐上老板的位置，也会站在前端后面指点江山的。
写在最后
以上都是自己的一些思考和想法，如果大家觉得有不对或更好的想法，都可以一起探讨一下。毕竟大家好，才是真的好嘛。
