Tech Lead 成长之团队合作

合作

人类就是靠着合作一步一步走到现在的位置。

重要性

合作重要性毋庸置疑，人的精力是有限的，团队的服务能力也是有上限的，所以团队合作是不可避免的事情。但团队和团队之间的合作是一件很考验水平的事情。

合作程度

在团队管理篇聊过，每个团队都有自己的团队目标。当寻求团队合作，首先要确定外部团队的团队目标，这决定着外部团队的配合程度。

只有搞清楚了各个团队的目标，合作才能减少内耗，才能高效完成合作。

事例介绍

在做某个项目的时候，对接一个 OA 系统。OA 系统是比较老的系统，集团员工都使用这套系统来完成日常审批工作。因为系统比较老，我们对接的时候遇见了两个明显的 BUG：

1. 发送请求时，OA 系统有概率生成两个一模一样工单记录，只有 ID 不一样。导致回调时候，ID 匹配不上，导致状态更新失败。
2. OA 系统完成审批时，异步回调并且有概率失败，会导致状态更新失败。

乍一看，两个都是对方系统的 BUG，和自己团队没有关系。但最后方案是：

1. 我们修改代码，自己生成业务唯一 ID，抛弃 OA 系统的唯一 ID，OA 系统回调时把 ID 发回给我们。
2. OA 系统修改代码，增加失败补偿机制，确保回调成功，我们这边保证状态的单向流转。

这是一个很典型的案例，同样是 OA 系统的 BUG，结果却截然不同。

了解自己和对方

上述事例中，解决方案一开始不是这样的，经过多轮拉扯后形成的方案。

了解自己

在当时那个场景下面，我们作为业务团队，开发需求多，进度压力大，还有明确的上线计划。因为随着需求增加，中途已经临时添加过好几个人员，并且给新进开发人员拆分一些重复性报表工作去做。我们是期望对方能修复这个恶性 BUG，但 OA 团队也很坚持的不修，并且声称不是问题。

但从业务团队目标来说，这个恶性 BUG 不修，会遭到用户投诉。所以我们选择花费时间，设计了一套业务唯一 ID。因为在这个问题下面，被投诉的是自己团队。

了解对方。

我尝试带入 OA 团队的视角想了想这两个问题。

关于问题 1：OA 系统已经是一个运行很久的老系统，要去复现定位工单重复创建问题本身就是一个很麻烦的事情。即使定位到了，这个 API 给了很多个团队使用，修复过程中难免会遇见新的问题，也没谁能保证修复后一定不会遇见新的问题，索性就丢给调用方自己去想办法解决。

关于问题 2：新增一个定时调度任务，从数据库获取回调失败数据，重新回调。即时任务重复执行，下游也会保证状态正确更新。

这样一分析，对方决策似乎有迹可循。

小结

合作是为了共赢，在最后的功劳簿上面，我们会感谢对方团队的大力支持。