“配合”这个词我一直不太喜欢。它听起来像两拨人各自完成任务、再在接缝处对一下——而产研之间真正的差距，往往就出在接缝上。
我做过工程，也和产品团队长期合作。体会是：产研合作的好坏，通常不是流程有多少，而是双方是否相信对方在和自己解决同一个问题。信息能互通、困难能早说、不同意见不会立刻被理解为对抗，合作才有基础；流程只是把这层信任固定下来。
坏合作则相反：把协作者当对手，靠信息差争资源，用标签、构陷或”戴帽子”替代对事实的讨论。它短期可能让某一方赢一次，长期只会让所有人开始隐藏风险、保护自己。合作一旦变成这样，再完美的流程表也救不回来。
冲突时不要私自承诺
目标、时间和资源冲突时，最危险的动作，是某一方为了过关先答应，再把代价转给执行者。工程侧这样的例子不少：产品对业务说”没问题”，转头把压缩的时间压到团队头上；团队为了表面上的配合，硬接一个明知做不到的排期。
更好的做法是上升对齐：带着事实、选项、风险和需要的资源，找拥有更高决策权限的人共同判断。
上升不是甩锅，前提是自己的信息线路一致：让直接上下级都知道真实情况，避免不同层级拿到不同版本的承诺。必要时引入更多资源、更多上下文和更高权限，才能让决策与责任匹配。
把”必须今天上”变成选择
有一次活动临近开始，业务希望当天增加入口，工程发现它会碰到共享依赖、无法完整验证。最省事的处理是某一方私自让步——工程咬牙上线，或者业务表面答应、暗中不满。
那次双方都没有私自承诺，而是一起带着收益、风险、当天可完成的最小版本和完整版本的时间，上升给决策者。最终先上线不触及共享依赖的简化入口，并约定后续版本。谁都没有拿到最初全部想要的方案，但也没有人用信息差把代价转给对方——这比”配合”出来的表面一致可靠得多。
信任不是永远没有分歧
信任不是永远没有分歧，而是分歧出现时仍愿意共享信息、共同承担结果。判断一段产研关系是否健康，我有一个简单的标准：分歧发生时，双方讨论的是方案、事实和代价，还是在互相猜对方的动机。 前者说明站在一起，后者说明已经站到了对面。
先把对方当作同一阵营的人，才有可能真正讨论方案。这句话听起来像态度问题，做起来其实是信息机制问题：共享事实、透明成本、把决策权交给该负责的人。信任是从这套机制里长出来的，不是开会开出来的。