一场关于”职责边界不明确“引起的争论

起因

有人的地方就会有江湖，有江湖的地方就会有人情。

程序员这个职业，虽然天天面对电脑需要足够理性，但是公司技术边界问题在IT行业经常是模糊和感性的。对于大公司而言，规范和制度可能定义得比较明确，这样的争论会相对较少；对于小公司而言，部门和团队的职责定义得没有这么清晰，存在很多这种模糊的边界；人情不好，此时跨部门合作就会经常出现这种扯皮的事情。

实际案例如下：

产品提出了一个需求：网约车行业，乘客预约用车时，需要对接到预约订单的司机进行履约监控，在司机忘记履约或者履约不及时的时候，系统要能够识别，并通知司机。
团队划分：派单团队和司机团队。
派单团队：从领域划分的角度，派单侧负责给乘客找司机。找到司机后，这个司机能不能去服务这个乘客，应该属于司机团队来监控，而且这个属于对司机行为的履约监控，跟派单应该没有关系。
司机团队：从领域划分的角度，司机侧只负责司机维度的管理，不负责司机和乘客双边关系的监控，司机接到订单后，属于司机和订单双边履约关系的监控，应该还是派单团队负责。

争论

对于司机的履约监控，这本身是一个非常大的方向。由哪边的团队负责开发，也意味着后续相关的维护和开发都会有较大的工作量。

从目前领域划分的角度来看，这块其实属于模糊的边界。

• 从司机的视角来看： 就是对司机的履约行为，进行监控。
• 从派单的视角来看： 就是对派单后，司机和乘客的关系是否合理，进行监控。

那双方各执一词，谁也无法说服谁，最后衍生到组织结构的问题。

• 司机侧：不能只从派单的视角来看，要从整体来看，但是这个整体是什么却是模糊的。又扯到这个需求对司机团队没有价值，对派单团队价值更大。。。
• 派单侧：产品文档已经定义的很明确，这个属于司机侧的监控，而且这个完全属于派单后的司机行为，跟派单确实毫无关系。

当两边都争执不下时，就只能请架构部门的人来进行协调。其实架构部门的人，对两边的业务都不是熟悉，他的立场就代表那个所谓的“江湖”。

最后架构部门的人站在了司机侧的立场：

• 派单侧要对派单结果负责，订单派完后司机能不能履约，属于派单后续的闭环行为。

这个结论最终也没有完全说服我，因为司机所有的后续结果都是派单这个底层能力支持的，这么说司机侧后续的所有监控都要派单来负责。

反思

关于边界模糊的问题，有没有更好的解决思路？

• 人情上解决，有人的地方就有江湖。多建立良好的合作关系，从日常的工作中去努力，在力所能及的范围内多给别人帮助。
• 制度上解决，向上推动这种模糊边界的划分问题，帮助公司建立更规范的制度，这种方式其实体现了个人能力的不足。
• 思想上解决，放大思考，模糊的边界后续对哪个团队有更大的收益；或者说后续是否可以进一步成为团队的核心能力。

总结

基于不确定性的问题，此次自己得到经验和教训。

• 职场上永远要保持理性，争吵不会解决问题。
• 模糊的问题，更需要你提前去思考，为自己的团队争取利益。
• 职场上要多去思考，慎重表达，没有思考清楚，就不要表达。
• 更多的去关注人，表达者最重要的是要关注对象的心理。