从零开始搞基建（2）——团队协作规范
前端会与公司的所有部门有协作，若在某一环出现问题，就会发生不必要的时间开销，降低开发效率。所以有必要制订一套完善的协作流程。
有个核心要素，那就是积极主动性。
一、与业务方的协作
1.1 BUG上报
业务方包括运营、客服、财务等部门，在使用软件时难免会遇到这样那样的问题。
若要上报这些BUG，则需要提供页面地址、问题描述、截图和机型，如果可以提供录像的话，那最好了。
还可以提供一些其他线索，诸如谁谁谁之前处理过该类问题，线索越多，定位问题的速度越快。
注意，页面地址是必填项，有了地址前端这边才能准确的定位到问题和相关责任人。
1.2 业务需求
在提出业务需求后，需要提供一些基础保障，帮助研发或测试，例如开通海外PayPal支付，需要提供测试用的海外账号。
实时更改需求池任务的状态，不必特地去通知业务方需求已上线。
1.3 维护
当有重要活动或业务上线时，需携带公司笔记本回去，及时修复线上问题。
一般情况下，若出现线上问题，先定位问题出现的位置，然后重启相关服务即可。
二、与设计的协作
2.1 定稿
2.2 交互
设计想要的交互动画，可以制作成一段 mp4 视频给到前端。
并且前端会提出可能存在的问题（技术实现问题、性能问题等），协商解决方案（如优雅退化）并达成共识。
2.3 核对
前端拿到设计稿后，与产品文档比对，当与产品原型不符时，要主动找产品和设计核对。
当前端收到新的设计稿与原先提供的有差异时，需主动与产品沟通。
2.4 验收
在完成页面的开发后，让设计确认验收，可在工作群中@相关人员，让他们确认回复。
三、与产品的协作
3.1 产品文档
产品应在文档中补全设计搞（上传设计稿图像或加个蓝湖地址），若有修改，则最好标明修改的位置，好让前端和测试做验收。
产品在设计产品文档时，得保证相关流程的完整性，例如新增一个支付渠道，那么就得把后台管理界面也写到文档中。防止在开发过程中临时加需求，打乱整体节奏。
前端必须仔细阅读产品文档，力求理解业务需求，杜绝由于需求模糊而发生的反复修改。
3.2 确定开发人员
在正式开发前，产品需要确认相关功能由哪一端完成，这部分主要涉及的是前端和客户端，以免在开发时临时修改技术方案。
3.3 核对
当文案发现有差异时，需主动与利益相关方核对，例如测试、产品、设计等。
3.4 权限
新功能提测与上线后，前端主动给相关人员开权限，不要再次提醒。
3.5 预估时间
根据项目时间要求及工作量，预估时间，精确到小时，在完成预估后主动提供给产品。
当需要预估提测时间时，最好将平时救火的时间也考虑进去，时间不要估的太紧。
四、与服务端的协作
4.1 接口文档
在开发伊始，就得先定好接口说明，既可以是规范的文档，也可以是JSON文件，只要能说明字段即可。
不要出现谁等谁的情况，这样既费时又耗感情。
4.2 技术细节
在需要互相协作时，需要先明确各个技术点，尽量做到在正式开发前就对好技术细节，避免返工。
五、与测试的协作
5.1 测试用例
在需求确认后的两天，测试整理出测试用例，开发在完成页面后，主动执行部分测试用例，减少不必要的纠缠时间。
若某个用例的执行成本较高，则略过，例如需要造很多复杂的数据。
通常测试用例会包含许多功能点，但至少要将核心流程的功能点跑一下。
5.2 结对编程
将代码的大致逻辑讲解给测试听一下，做次简单的结对编程，这么做可发现一些开发忽略的潜在问题。
若有收获，就点个赞吧
0 人点赞
