谈谈前端人员在项目中的正确沟通方式

　　做为一个有点想法的web前端从业人员，是从业人员，在项目中不免会跟不一样的角色打交道。有让本身舒服的，也有让本身难受的；有让别人舒服的，固然，也有让别人难受的。咱们固然但愿最好的结果是你们都很舒舒服服地把事情作完作好。这便就是本文要探讨的地方。 　　

项目中的角色

　　我根据本身经历的项目，大体分了以下几个角色。而后站在一个web前端的角度来吐槽一下与其余角色的种种“轶事”。同时也描绘一下我认为比较不错的处理方法。

产品经理

　　我所理解的产品经理是一个为其余全部角色服务的“奶妈”。全部问题，均可以找他。不过首先，他是项目之因此开展的起始。我认为产品经理的职责是：

1. 竞品分析。这个很重要。知己知彼，百战不殆。
2. 需求管理。从各类途径搜集需求，而后概括，整理，推敲，合并，删减。最终转化成功能。需求管理过程能够有其余人一块儿参与。最好是有一套需求管理系统对需求进行管理，方便你们同步信息。只要能实现需求录入，需求评论便可。
3. 用户行为统计分析。这是产品经理惟一能拿来讲服其余角色的客观数据。咱们的产品是最终给用户用的。用户的使用频率，使用反馈是最好的论据。好比：产品经理要求web前端把已作好的左侧的图标导航改为图标加文字导航，通常状况下，web前端确定会认为产品经理又在瞎搞。若是产品经理拿出用户反馈数据“70%的用户不清楚这个导航是什么含义”，那他的要求就更具备说服力了。
4. 巧妙设计。 有时候一些NB的功能不是非要靠技术的。若是能巧妙利用一些被常人忽视的现有特性，而后设计出眼前一亮的功能，会让产品更富有活力。好比，以前看到一个APP，利用手机通信录能够保存大量联系人及电话，对一些已经被标识的骚扰电话进行本地标识，从而巧妙的实现未越狱IPHONE手机的黑名单提示功能。
5. 产品设计。这个归纳有点大。其实包含了许多功能，诸如：
   1. 产品流程设计；
   2. 产品具体功能设计；
   3. 产品角色设计；
   4. 原型设计；

设计师

　　设计师这个没什么说的，就是在理解产品经理的原型的基础上，将它美化。固然，说的高大上一些，就是：

1. 用户体验设计；
2. 产品风格设计；
3. 视觉风格设计；
4. 导航设计；
5. 品牌包装设计；
   　
   　　这里面，和前端有关的，主要就是产品的界面（咱们讲的主要仍是web项目，虽然目前互联网项目还必需要有一个APP，此处略过，之后有机会再聊）。

前端

　　这里指web前端，若是有APP，也主要指的是H5。前端的产出最终将直接面向用户。你们可能会认为，设计师的设计稿也是最终面向用户啊？可是有谁见过页面出问题了后，无论是用户，仍是产品经理，后台，测试，老板，有谁去找过设计师？都是第一反应找前端，找前端。做为一个前端狗，本人深有体会。

后台

　　给前端提供数据，以及实现产品核心业务的开发人员。前端全部数据都是从后台而来。 　　

测试

　　测试也分好几种，

1. 功能测试。以产品经理的PRD和原型为依据，编写功能测试用例，逐项测试；
2. 接口测试。我这里已经假定项目的架构是先后端分离的模式，所以，通常测试也会单独对后台提测的接口进行接口测试。
3. 界面测试。不多有项目须要此测试，若是要进行此测试，那恭喜你，大家的产品成熟度已经很高了。作界面自动化测试，最费时，费力，且不必定有效果。目前各大厂有一些方案，无外乎使用phantomjs相似的无界面浏览器脚本框架，搭配测试脚本写的测试用例，进行测试。若是界面频繁变更，那测试就会累成狗。我以前所经历的一个项目（或产品？），为了解决界面频繁变更对测试脚本的影响。我提出一个方案：让编写自动化测试脚本的难度下降，即采用相似DSL（domain specific language 领域描述语言），实现简单的命令和逻辑，替换掉测试人员用相似excel或测试用例管理系统的人类文本语句。和测试人员一块儿配合，后来也只是用在了版本发版后的冒烟测试上。　

老板

　　这个不用说啦，老板最大，老板就是最大的用户。【捂嘴不笑】 　　

如何与产品经理沟通？

1. 前端人员与产品经理沟通的依据就是 原型设计。
2. 老是会遇到一些数据输入规则不清的状况，记住，这个时候，在和产品经理沟通清楚之后，必定要求产品经理更新原型设计。不然，过一段时间后，测试拿着原型设计给你的界面测出一堆bug，你就哭吧哭吧不是罪。
3. 在动手前，必定要与产品经理肯定好哪些是不会变的，哪些部分可能后续版本会扩展。固然，产品经理给你打的包票你也最好不要全信，仍是要结合本身对业务的理解，作好未雨绸缪，不然到时候，产品经理哪天跟你说要改动某个彻底没想到的功能的时候，你再说改动会影响全局，也是没用的，苦的仍是你本身。

如何与设计师沟通？

1. 前端和设计师沟通的最好方式是样式规范。这里的样式规范不必定是css，只要是设计师能理解的描述标识就行。好比：能够和设计师约定好，目前按钮有3种，分别是：btn1，btn2，btn3。设计师每次出设计稿的时候，给按钮标注：btn1，btn2，btn3。而后到前端这里，可能就是对应的某个class：btn-main,btn-sub,btn-third.为了方便设计师设计，在设计师完成了一些基础控件风格后，能够整理一套模板控件库，方便设计师后续套用页面。
2. 有了前面说的约定。作皮肤，那就是水到渠成的事。
3. 对于一些设计师天马行空的设计，切记要从技术上进行权衡。若是某个效果的实现难度大于最终体验效果，最好沟通后，降级处理。若是有明确证据（这里就是来自前面提到的用户统计）要求必须实现，那web前端就只能迎难而上。
4. 设计师在设计界面的时候，每每喜欢找最好的界面状态，而后画出效果。好比：数据恰好满一屏，某个侧边栏的宽度恰好够放一个弹出层。这个时候，当设计稿交到你手上的时候，必定要问一下设计师：没有数据怎么办？宽度不够怎么办？数据太多怎么办？这些都是由于设计稿只能展现某一个界面状态。而实际的产品界面，状态实在太多，各类条件的组合，最终仍是得由前端来负责梳理清楚。

如何与后台沟通？

1. 前端与后台的沟通依据必须是接口设计文档。之前是用文档，如今最好的方式，是后台在设计接口的时候，直接录入接口管理系统，明确代表某个接口的入参，入参类型，出参，返回错误码。只要发现问题，以接口设计文档为准，根本不用和后台扯皮。
2. 另外，有了接口管理系统，后台也很方便的对接口进行修改。测试还能够根据后台的接口设计定义，对接上接口自动化测试程序。好比：后台修改了某个入参类型，接口管理系统发出更改事件，测试人员根据类型，决定是否修改测试用例，或补充测试用例，实现高效的自动测试。
3. 有时候前端与后台常常在为某个数据处理该有谁来实现而扯皮。好比：前端想要A格式数据，后台为了统一，恰恰输出的是另外一种B格式，这样每次前端都得再转一遍。个人见解是：
   1. 若是是数据的格式化，则有后台给一个数据，由前端负责格式化处理并显示。好比：时间，后台统一给一个毫秒值，前端自行决定如何显示；
   2. 若是是要多种数据，最好后台统一处理好后，封装一个新的接口提供。这主要是考虑到前端请求太多，会有性能影响。我以前有一个关于这个问题的解决方案，不必定最好，也算是一种探讨吧。github.com/houyhea/blo…
   3. 若是有一些数据处理，逻辑处理是除了web前端，APP也会须要的时候，那么最好由后台来统一处理。前端永远只是一个可视化终端。因此，最好不要把不少核心的逻辑和业务放到前端来作。检验是否核心业务的方法其实也很简单，就是，设想一下，若是把前端拿掉（好比我换一个控制台做为终端），整个产品或系统还可否稳定运转？

如何与测试沟通？

1. 为了不测试提出一些无效的bug，最好提早参与测试的用例评审（若是有的话）；
2. 在某个功能的实际深刻开发中，全部的修改最后都要要求产品经理更新到PRD以及原型设计里，不然，测试若是不知道的话，会认为是bug；
3. 最好不要怕测试的刁难，多想一想，若是测试放水，等上线的时候，用户半夜再来刁难的时候，你就只有老实拍起来改bug；
4. 有些测试提出的不太靠谱的bug，最好一笑置之。我曾经碰到过一个测试mm提了一个bug，因为她输入大量重复字符，且有交替重复，总体产生某一个行倾斜的错觉。她居然认为是bug。我只能无语。

如何与老板沟通？

1. 等一切都作好了，正准备上线的时候，老板事必躬亲的看了一眼：这个版面不对，必须改！此时的你的正确作法是：是的老板，我也总感受哪里不对，您一说我就明白了，立马就改！
2. 老板才是你的衣食父母，老板的话就是圣旨。别笑，由于等你哪天坐上老板的位置，也会站在前端后面指点江山的。

写在最后

　　以上都是本身的一些思考和想法，若是你们以为有不对或更好的想法，均可以一块儿探讨一下。毕竟你们好，才是真的好嘛。