合作
人类就是靠着合作一步一步走到现在的位置。
重要性
合作重要性毋庸置疑,人的精力是有限的,团队的服务能力也是有上限的,所以团队合作是不可避免的事情。但团队和团队之间的合作是一件很考验水平的事情。
合作程度
在团队管理篇聊过,每个团队都有自己的团队目标。当寻求团队合作,首先要确定外部团队的团队目标,这决定着外部团队的配合程度。
只有搞清楚了各个团队的目标,合作才能减少内耗,才能高效完成合作。
事例介绍
在做某个项目的时候,对接一个 OA 系统。OA 系统是比较老的系统,集团员工都使用这套系统来完成日常审批工作。因为系统比较老,我们对接的时候遇见了两个明显的 BUG:
- 发送请求时,OA 系统有概率生成两个一模一样工单记录,只有 ID 不一样。导致回调时候,ID 匹配不上,导致状态更新失败。
- OA 系统完成审批时,异步回调并且有概率失败,会导致状态更新失败。
乍一看,两个都是对方系统的 BUG,和自己团队没有关系。但最后方案是:
- 我们修改代码,自己生成业务唯一 ID,抛弃 OA 系统的唯一 ID,OA 系统回调时把 ID 发回给我们。
- OA 系统修改代码,增加失败补偿机制,确保回调成功,我们这边保证状态的单向流转。
这是一个很典型的案例,同样是 OA 系统的 BUG,结果却截然不同。
了解自己和对方
上述事例中,解决方案一开始不是这样的,经过多轮拉扯后形成的方案。
了解自己
在当时那个场景下面,我们作为业务团队,开发需求多,进度压力大,还有明确的上线计划。因为随着需求增加,中途已经临时添加过好几个人员,并且给新进开发人员拆分一些重复性报表工作去做。我们是期望对方能修复这个恶性 BUG,但 OA 团队也很坚持的不修,并且声称不是问题。
但从业务团队目标来说,这个恶性 BUG 不修,会遭到用户投诉。所以我们选择花费时间,设计了一套业务唯一 ID。因为在这个问题下面,被投诉的是自己团队。
了解对方。
我尝试带入 OA 团队的视角想了想这两个问题。
关于问题 1:OA 系统已经是一个运行很久的老系统,要去复现定位工单重复创建问题本身就是一个很麻烦的事情。即使定位到了,这个 API 给了很多个团队使用,修复过程中难免会遇见新的问题,也没谁能保证修复后一定不会遇见新的问题,索性就丢给调用方自己去想办法解决。
关于问题 2:新增一个定时调度任务,从数据库获取回调失败数据,重新回调。即时任务重复执行,下游也会保证状态正确更新。
这样一分析,对方决策似乎有迹可循。
小结
合作是为了共赢,在最后的功劳簿上面,我们会感谢对方团队的大力支持。