和前端沟通问题个人复盘

回顾整个过程

前天1031和前端沟通还是着急了，确实有点控制不住自几。主要是他老是说的有的没的，对解决当下问题没有任何帮助，感觉还把甩锅到我这边，大致意思他们还在解决问题，等解决了才能一起投入测试，不是他们不测试，说正常都是前端测一遍没问题，才让后端测试回归的。我笑了，这样算前后端联调？现在前端问题不断，那什么时候能解决，还没解决我后端就不投入测试了吗？在这干坐等你们解决？现在我发现问题大多集中前端样式？按照这样个人感觉无法达上线标准的。每个人都有各自的课题，我的课题是在排期内完成开发和自测，在前后端联调，测试全流程发现问题，解决问题，后端问题就修复，前端就抛给前端修复。你不需要对我个人评价，对事不对人，这件事你们做的不好，没有给我任何有益的输入点，整个联调测试压力都放在后端，这事情本身就是不合理的！

沟通推进中我自身可以改进的地方

• （找准漏洞，言简意赅强而有力回击） 沉住气深呼吸，先不着急发言，先听合作方说，如果是甩锅点，找漏洞反问句式有效回击
• （抛出问题后，让合作方给出明确解决时间，并群里同步会议结论，到时间再询问进度，什么时候没问题再进入下一阶段联调） 联调发现一方问题不断，存在上线延期风险，及时向上汇报，如果哪一方问题比较多，先让其自测解决大部分问题后在集中联调
• （项目把控风险上，谁来评估和拍板延期多久，如果延期发现还是有问题尼）合作流程中，谁来评估上线是否有风险（把控后端/前端整体进度） ，如果出现了风险应该找谁统一收口来判断是否延期，需要延期几天。（而不是后端抛出风险，前端说没问题这两天可以改完，结果还是没改完，这种情况怎么办）

这种case和小组长聊完，确定找对应小组长来评判，毕竟现在做的toD对内，而不是着急的业务需求，以及有对应的PM和业务方催促

• （梳理现状不合理性和寻找解决方法）

1. 正常流程中后端在技术方案评审时候，列出所有涉及接口，前端需要了解业务背景和接口设计，以及给予输入补充可能缺少的接口，避免漏需求

现状前端人力不足和个人能力差异，对业务需求理解不够无法在技术评审阶段时理清接口list，给予其他输入补充方案也好像也不太能够。目前解法：在技术评审还是列出涉及的接口，以及页面交互中如何使用该接口，给予接口时候分批给予，比如先做完xx模块的CRUD就先给，出入参和返回数据也一并给予，这就需要我们后端先开发完成并完成自测。虽然会变成串行开发，但这也是当下环境为数不多比较好的解法。

2. 在技术评审完前后端接口定义完毕，数据结构确定后，前后端都需要自行mock数据，各自按照约定独立开发

当下现状是在联调前自测页面的交互等，还是依赖于后端数据返回，同上需要后端先开发；以及接口文档介于公司没有统一的接口测试平台，还是放在wiki方式给予出入参定义，以及字段含义，在给予时需要后端将数据返回

3. 开发排期需要包括开发和自测，联调时间应该前后端在之前将项目部署泳道或者sit环境，双方可以直接在页面测试逻辑

4. （一定在技术详评完能双方直接进入开发，避免过多时间讨论）在技术方案评审时，把交互和对应接口都对齐，可以在详评前先找前端对一版有初步沟通

5. （联调前一天提前部署好项目在联调有环境，联调时双方直接测试）

6. （联调问题先群里发出来，问题多需要文档记录）