那个项目其实不大，是客户归属争议的清理。每年销售部门都在为一些老客户的归属吵架，吵完继续搁置。当时我年轻，觉得“数据就是事实”，主动接了这个没人想碰的活。然后就跟隔壁组的一个同事撞上了。
她比我早来公司两年，不算老油条，但属于话不多、心气高的人。一开始的摩擦特别小——客户名称标准化的问题，我建议用统一编码，她说她们组一直用拼音缩写代替。我当场没说什么，但会后跟她发了条消息，说“我们一起看看能不能合并一套”。她已读不回。第二天会上，她在领导面前说“我们这边逻辑比较成熟，如果改编码会产生很大工作量”。
你如果只写一句话总结，那就是“同事之间因为方法分歧产生摩擦”，但真实事情的质感完全不是这样的。真实质感是：你被“已读不回”的那几小时，会反复回看自己发的消息有没有不妥；你在会上听到她强调“工作量”的时候，心里先是想争辩，然后开始怀疑自己是不是真的没考虑周全，最后居然有一点点被冒犯却说不出口的感觉。后来我养成了一个习惯，开会之前先把她的岗位KPI翻出来看一遍。
这事僵持了大概两周。中间我们领导各让了一步，说先并行一个月再决定。然后我发现她其实把那套拼音编码维护得很好，虽然没法跟财务系统联通，但她们组的日常运转确实依赖它。我拿着我自己做的对比结果，发现自己和她的矛盾不仅仅是“技术上谁更好”，还有一个她说不出口的原因——如果采用我的方案，她之前维护了两年的表格，就废了。
那一刻其实有点失落。因为如果矛盾是“谁对谁错”，我还有办法解决；但矛盾是“有人会因你的正确而受损”，这个真不知道该怎么处理。
后来我做了个决定，在合并方案里加了一个“历史数据兼容层”，专门把她维护过的编码保留在系统里，并且把她写进项目成员名单。她看到邮件后，没过十分钟就回复“技术方案没问题”。我们的对话恢复到正常的同事交流，没有再提之前的事。
这段经历没有什么“握手言和”的高光时刻，她也没变成我的好朋友。但后来我离开了那家公司，在办离职手续的时候，她路过我工位，没停步但说了句“那个编码层还在用”。我点了点头，她说“挺好”。
我写这篇文章不是想说“多替别人考虑”之类的正确废话。我是想说，工作矛盾绝大多数不是善恶问题，也不是沟通问题，而是利益结构的问题。你如果站在自己的逻辑里永远是对的，但职场里的“对”往往必须包含“别人会不会因为这个对而变得更脆弱”。这不是让你放弃原则，而是让你看清——你要么比对方更有实力来改变结构，要么就得让自己的方案里留出对方的位置。
这个方法也不是万能的。有些矛盾就是纯粹的烂，领导不靠谱、制度有病，你再怎么修修补补也没用。所以在看清利益结构之后，你还要分清哪些值得解决，哪些就让它烂着，然后自己跑掉。