阅读 3517

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

  作为一个有点想法的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. 老板才是你的衣食父母,老板的话就是圣旨。别笑,因为等你哪天坐上老板的位置,也会站在前端后面指点江山的。

写在最后

  以上都是自己的一些思考和想法,如果大家觉得有不对或更好的想法,都可以一起探讨一下。毕竟大家好,才是真的好嘛。

关注下面的标签,发现更多相似文章
评论