前言
不知不觉已经入职快两个月了，虽然很多技术还在学习中，尚未达到能够输出足够有价值内容的水平，但是还是想尽可能保持定期记录的习惯，因此决定写下近期关于团队合作的一些感悟。
正文
此次团队合作的背景是公司给新入职MLE们设定的一个为期三个月的Hackathon项目，我们需要在这期间完成从问题挖掘到产品上线的整个流程，相当于不仅做了全栈开发，还得在这之前和这期间对预想的用户进行采访调研，了解他们的需求和痛点，并最终将成果汇报。我所在的团队说起来其实也就是我和另一位新入职的MLE两个人，对方是专攻推荐系统方向的博士毕业生，日语交流存在一定障碍，因此我们主要使用英语进行沟通。
阶段一：问题挖掘与调研
在Hackathon的第一阶段，我们需要向公司内部的员工进行问题挖掘，而我们需要进行对话的员工们并不是特别擅长用英语交流，因此负责这里面沟通的重担就很自然地落在了具有日英双语能力的我身上。至此，我遇到的第一个难题便是需要理解日语方的需求，并给我讲英语的队友进行说明，同时要将我队友的想法转述给日语方，并且在这之中我还需要平衡两者的意见以及让自己的想法不要迷失在其中。我得承认我最终在这点上做得有限，我最终尽力做到的事情是：
- 包揽了我们队伍中前期所有和公司内员工的会议沟通任务
- 承担了绝大多数中期发表的PPT制作任务
- 尽我所能将日语方的需求转述给队友
但我能感觉到我的队友在这些事情上参与度并不高，虽说有一部分来自整个体系的原因，但我或许应该想办法更好地鼓励并引导她参与进来。所以最终这个阶段的团队合作模式大致是我负责沟通和幻灯片制作，而她则直接开始了早期的概念验证和一部分模型训练。
阶段二：开发
其实目前这个阶段尚未结束，不过也已经过半，并且确实有一些值得反思的地方，所以决定提前写下。
来自不同组织的反馈冲突
在正式着手开发之前我们又与另一位公司内英语native的工程师进行了交流（因为我们需要做的产品有很大一部分基于他的工作），结果是我们又得到一套完全不一样的反馈和建议。在那一个时间点，我们其实已经收到了来自日语方咨询岗位的、来自日语方工程师的和目前这个英语方工程师的反馈，三者之间可以说各有冲突。这一点令我感到有些割裂和无奈，其实归根到底还是沟通的问题，因为基本都是我们和其中某一方进行单独会议，如果能将各方聚集在一起进行讨论可能会更好一些，但是体系和时间都并不允许。直到这时我才真正意识到一个具备多语言无障碍沟通能力的工程师是多么关键的存在，可惜我自己目前还达不到这个水平。
代码协作问题
接下来就是开发阶段了，经过简单的沟通，我们决定由她继续负责推荐系统的开发，而我这里则单开一个仓库负责基础的向量检索和前后端搭建，但后面我才意识到这会是一个多么错误的决定。总之我们就这么各自开发了一周，这期间我主要完成了以下几件事：
- 将已有的数据进行整理并存放至PostgreSQL数据库
- 用OpenAI的API对文本数据进一步提取关键词（利用大量提示词工程），并计算embedding，最终也入库
- 搭建了
PostgreSQL + pgvector的数据库 -> FastAPI后端 -> React前端的基本框架
问题出现在一周后，我将我的进度共享给了队友，但是队友告诉我她自己也在尝试做前端的可视化，我仔细看了她用的是Python的某一个可视化库，UI看起来是一股浓浓的科研画图风。这时我才意识到问题有些严重，一是因为某些未知的沟通缺失导致一部分的工作重叠，二是我意识到我们或许本该一开始就在同一个仓库中进行协作。随后我阅读了她的代码，发现情况比我想得还要严峻得多。
首先是她的代码量相当巨大，中间数据文件也非常多，其次是相当一部分方法中杂糅了太多的功能，导致可读性较差，并且为了跑通整个推荐系统，方法以及各种定义的类之间存在相当复杂的引用关系。此外整个仓库极其扁平化，几乎没有明确的模块划分。最后，整个仓库的代码所要用到的依赖包全部装在她的本地，找不到依赖关系文件，也没有容器化。总之我意识到我们必须尽快整合代码了，并且我需要主导这件事情。
我将我的想法告诉了队友，好在她比较配合，既然如此我便承担起了这一艰巨任务，其中的难点主要在于：
- 代码量巨大，理解和分离已有的功能需要花大量时间理解
- 容器化的过程中，推荐系统用到PyTorch系列库，尤其是图神经网络（GNN）相关的库，编写Dockerfile和容器的构建过程中Bug不断，极其痛苦
尽管如此，我依然在两天内完成了代码的整合和容器化，并将其推送至GitHub上。并且我教她如何拉取仓库，并成功引导她在自己的环境里构建了我打包好的容器，使整合起来的完整框架成功运行了起来。这便是我们目前的进度。
感悟总结
对我来说这也是第一次真正在工作上体会到团队协作是一件多么不容易的事情，由于缺乏经验，我们确实遇到不少困难。而在解决问题的过程中，除了注重效率，也需要考虑其他团队成员的感受，没有人希望自己的工作或努力被否定，我理解作为一个专心理论科研的博士生代码并不一定是她的强项，Git的使用可能也并不熟练，因此在她擅长的领域我选择不去干涉，而需要调整的地方我也尽量用温和的方式进行沟通，而不是冷冰冰地直接指出问题命令她修改。另一方面，尽管处理方式需要注重温和，但是在我能预见到的会影响最终产出的重大问题上，我还是会毫不犹豫地主导修正，毕竟最终的结果是我们两个人共同的责任。
