原因
有人的当地就会有江湖，有江湖的当地就会有情面。
程序员这个职业，尽管天天面对电脑需求满足理性，可是公司技术鸿沟问题在IT行业经常是含糊和理性的。对于大公司而言，规范和准则或许界说得比较清晰，这样的争辩会相对较少；对于小公司而言，部分和团队的职责界说得没有这么清晰，存在很多这种含糊的鸿沟；情面不好，此时跨部分协作就会经常出现这种扯皮的作业。
实践事例如下：
产品提出了一个需求：网约车行业，乘客预约用车时，需求对接到预约订单的司机进行履约监控，在司机忘记履约或许履约不及时的时分，系统要能够辨认，并告诉司机。
团队区分：派单团队和司机团队。
派单团队：从范畴区分的视点，派单侧担任给乘客找司机。找到司机后，这个司机能不能去服务这个乘客，应该归于司机团队来监控，并且这个归于对司机行为的履约监控，跟派单应该没有联系。
司机团队：从范畴区分的视点，司机侧只担任司机维度的办理，不担任司机和乘客双边联系的监控，司机接到订单后，归于司机和订单双边履约联系的监控，应该仍是派单团队担任。
争辩
对于司机的履约监控，这自身是一个非常大的方向。由哪边的团队担任开发，也意味着后续相关的保护和开发都会有较大的作业量。
从现在范畴区分的视点来看，这块其实归于含糊的鸿沟。
- 从司机的视角来看： 就是对司机的履约行为，进行监控。
- 从派单的视角来看： 就是对派单后，司机和乘客的联系是否合理，进行监控。
那两头各执一词，谁也无法压服谁，终究衍生到安排结构的问题。
- 司机侧：不能只从派单的视角来看，要从整体来看，可是这个整体是什么却是含糊的。又扯到这个需求对司机团队没有价值，对派单团队价值更大。。。
- 派单侧：产品文档已经界说的很清晰，这个归于司机侧的监控，并且这个彻底归于派单后的司机行为，跟派单的确毫无联系。
当两头都争执不下时，就只能请架构部分的人来进行和谐。其实架构部分的人，对两头的业务都不是了解，他的态度就代表那个所谓的“江湖”。
终究架构部分的人站在了司机侧的态度：
- 派单侧要对派单成果担任，订单派完后司机能不能履约，归于派单后续的闭环行为。
这个定论终究也没有彻底压服我，因为司机一切的后续成果都是派单这个底层才能支撑的，这么说司机侧后续的一切监控都要派单来担任。
反思
关于鸿沟含糊的问题，有没有更好的处理思路？
- 情面上处理，有人的当地就有江湖。多建立良好的协作联系，从日常的作业中去尽力，在力所能及的范围内多给他人协助。
- 准则上处理，向上推动这种含糊鸿沟的区分问题，协助公司建立更规范的准则，这种方式其实表现了个人才能的缺乏。
- 思想上处理，扩大考虑，含糊的鸿沟后续对哪个团队有更大的收益；或许说后续是否能够进一步成为团队的中心才能。
总结
根据不确定性的问题，此次自己得到经验和经验。
- 职场上永远要坚持理性，争持不会处理问题。
- 含糊的问题，更需求你提前去考虑，为自己的团队争取利益。
- 职场上要多去考虑，稳重表达，没有考虑清楚，就不要表达。
- 更多的去重视人，表达者最重要的是要重视对象的心理。
