前端会与公司的所有部门有协作,若在某一环出现问题,就会发生不必要的时间开销,降低开发效率。所以有必要制订一套完善的协作流程。

      有个核心要素,那就是积极主动性。如果需要涉及多端的,务必画出流程图,以免产生歧义。

  在推进业务开发时,遇到任何卡住流程的问题,都需要反馈给我,我会在第一时间进行协调。

一、与业务方的协作

1)BUG上报

      业务方包括运营、客服、财务等部门,在使用软件时难免会遇到这样那样的问题。

      若要上报这些BUG,则需要提供页面地址、问题描述、截图和机型,如果可以提供录像的话,那最好了。

      还可以提供一些其他线索,诸如谁谁谁之前处理过该类问题,线索越多,定位问题的速度越快。

      注意,页面地址是必填项,有了地址前端这边才能准确的定位到问题和相关责任人。

2)业务需求

      在提出业务需求后,需要提供一些基础保障,帮助研发或测试,例如开通海外PayPal支付,需要提供测试用的海外账号。

      实时更改需求池任务的状态,不必特地去通知业务方需求已上线。

  当业务人员修改需求,组内具体的开发人员获悉后,及时与研发负责人同步,以免因信息不同步而发生不必要的沟通问题,严重点的话可能会影响整个项目的上线时间。

3)维护

  当有重要活动或业务上线时,需携带公司笔记本回去,及时修复线上问题。

  一般情况下,若出现线上问题,先定位问题出现的位置,然后重启相关服务即可。

二、与设计的协作

1)定稿

      设计至少应在开发开始时敲定终稿,后面修改最多只做微调。

2)交互

      设计想要的交互动画,可以制作成一段 mp4 视频给到前端。

      并且前端会提出可能存在的问题(技术实现问题、性能问题等),协商解决方案(如优雅退化)并达成共识。

3)核对

      前端拿到设计稿后,与产品文档比对,当与产品原型不符时,要主动找产品和设计核对。

      当前端收到新的设计稿与原先提供的有差异时,需主动与产品沟通。

4)验收

      在完成页面的开发后,让设计确认验收,可在工作群中@相关人员,让他们确认回复。

三、与产品的协作

1)产品文档

      产品应在文档中补全设计搞(上传设计稿图像或加个蓝湖地址),若有修改,则最好标明修改的位置,好让前端和测试做验收。

      产品在设计产品文档时,得保证相关流程的完整性,例如新增一个支付渠道,那么就得把后台管理界面也写到文档中。防止在开发过程中临时加需求,打乱整体节奏。

      前端必须仔细阅读产品文档,力求理解业务需求,杜绝由于需求模糊而发生的反复修改。

  若接到的某个需求不必写产品文档,得提前和产品说明,避免他在不知情的时候补充了产品文档。

  需要至少有两个人确认最终的产品文档,罗列功能,以免需求有遗漏。

2)确定开发人员

      在正式开发前,产品需要确认相关功能由哪一端完成,这部分主要涉及的是前端和客户端,以免在开发时临时修改技术方案。

3)核对

      当文案发现有差异时,需主动与利益相关方核对,例如测试、产品、设计等。

  当版本开发中会对一个已有的功能做迭代时,需要和客户端、产品沟通兼容性问题,明确兼容到什么程度,以免出现返工。

4)权限

      新功能提测与上线后,前端主动给相关人员开权限,不要再次提醒。

5)预估时间

      根据项目时间要求及工作量,预估时间,精确到小时,在完成预估后主动提供给产品。

      当需要预估提测时间时,最好将平时救火的时间也考虑进去,时间不要估的太紧。

四、与服务端的协作

1)接口文档

      在开发伊始,就得先定好接口说明,既可以是规范的文档,也可以是JSON文件,只要能说明字段即可。

      不要出现谁等谁的情况,这样既费时又耗感情。

2)技术细节

      在需要互相协作时,需要先明确各个技术点,尽量做到在正式开发前就对好技术细节,避免返工。

  在与其他组沟通细节之前,需要自己了解清楚当前的产品需求,以及当前的系统情况。

  他们推荐的方案可以作为资料参考,但切记不要被他们影响自己的思路,我们要按自己的实际情况给出最适合的方案。

  务必要将技术细节确认好,即使是一个数据库表的字段也要核对好,不要有歧义。

3)建表

  在建表之前,需要先和服务端沟通清楚,重新建表合适,还是在原表上新增字段合适。

  在初步沟通完成后,最好再看看当前数据库中是否有相似功能的表,因为服务端的人很有可能刚接手,并不了解当前的数据库。

五、与测试的协作

1)测试用例

      在需求确认后的两天,测试整理出测试用例,开发在完成页面后,主动执行部分测试用例,减少不必要的纠缠时间。

      若某个用例的执行成本较高,则略过,例如需要造很多复杂的数据。

      通常测试用例会包含许多功能点,但至少要将核心流程的功能点跑一下。

2)结对编程

      将代码的大致逻辑讲解给测试听一下,做次简单的结对编程,这么做可发现一些开发忽略的潜在问题。

  虽然不需要干涉测试的流程,但是可以在他们测之前说明测试的重点,以免将时间花在无关痛痒的细枝末节上。

3)线上验收

  需求发到线上后,让测试组验收,需要得到明确回复。

  测试在验收完成后,需要与我们确认数据,例如缓存是否清除,定时任务配置是否正确。

六、与客户端的协作

1)JSBridge

  iOS和Android在实现细节和参数声明上需要统一,例如支付成功后的状态码,一个是0,一个是1,各有各的状态。

2)页面地址

  在客户端中的静态页面地址,尽量用短链包一层,以免修改地址要发代码或版本。

 posted on 2021-04-12 10:01  咖啡机(K.F.J)  阅读(1971)  评论(0编辑  收藏  举报