与外部公司合作，什么才是产品经理的正确沟通方式？

不知道在你的职业生涯中有没有过这样的经历，公司的产品是需要两家公司的一起合作来完成的，其中涉及到产品、设计、技术、测试、运营等每个部门的协作，两家公司合作来做一个产品。

虽然作为产品经理不缺少跟技术、运营等部门打交道的经验，但那还都是局限在一个公司的范围内，解决问题的最终决定权也在自己公司的高管手里，很多问题都是可控的。但是与别的公司合作就不一样了，跟外包公司还不同，外包公司是一方出钱一方出力，甲方的话语权更大一些，乙方在满足甲方需求的前提下，可能也不会提出过多的主见，双方员工的心里都有一个默认的守则。

我要说的这种合作模式中，双方公司的地位是平等的，只是各自的分工、职责不同，这样的话在过程中更容易出现问题，各种小的摩擦更是不可避免。而对我来说，与外部公司的技术和设计沟通也还是头一次，合作的一年多来也有了一些收获，深深感受到沟通的重要性。

1.明确各自的职责

两个公司合作往往是因为各有各的优势，彼此取长补短，在项目开发前首先要明确好各自的职责。这事说起来这点挺简单的，做好各自的工作就好了，但是在实际过程中还是有很多模糊的地方，为了避免矛盾产生主要还是要明确各自的边界。

说个例子，我们跟对方公司合作的过程中，由于内容是放到对方家的平台上，为了避免内容风险，对方会给我们一定的要求，至于在符合要求的前提下上什么内容就是我们公司自己把控了。两家公司各自职责的明确这是合作的前提。

2.明确名词概念和文档中的内容

虽然同属互联网行业，对于行业内的一些常见的名词，例如产品，UI设计等，大家都很熟悉，但是不要自以为是，为了防止做无功用，彼此还是要明确一些，哪怕多问一嘴，也是有必要的。

我们就吃过这个亏，对方公司当时让我们提供一下产品详细设计文档，我们以为是产品需求文档，所以就把产品文档发过去了（为了体现专业性，发出之前我们还临时评审、修改了一遍）。结果后来却发现原来我们理解错了，人家说的“产品设计文档”其实是指技术开发文档。这就造成我们在错误的方向上花费了时间，而正确方向的事情，技术文档还一直没写，耽误了时间，最后没有得出想要的结果。

更重要的碰到这种事情，往往是说不清的，没法追责，所以为了避免出现这种问题最好还是提前沟通一下比较好。

除了明确术语概念外，还要提前沟通好合作中所需要书写的文档以及文档的内容。有了文档能够减少沟通成本，避免扯皮。关于文档，最重要是应该明确其中都要有哪些内容，只要文档中的内容，特别是关键点，有就可以了，形式不重要。

3.确定沟通方式和工作流程

沟通方式分两个方面：一个是确定一种沟通的工具，比如说邮件、QQ、微信等；一个是建立定期开会的制度，开会除了讨论已有需求如何实现外，还有一个好处是彼此可以就下一步的一些想法做一些沟通，有些事情做到双方的相关人士都知情。

不同公司之间的沟通方式和工作流程是不一样的，虽然在一个互联网公司中大致的流程都是相同的，包括产品设计、UI设计、技术开发、测试等环节，但是在具体的执行、产出物的标准上还是有一些不同的，所以在合作前还是要互相了解一下。

拿测试来说，即使都有测试环节，但具体的过程还是不一样的，一般的公司可能在内测后就会直接上线了，但是在有的公司就会有内测、众测和A/B测试这三个阶段，这样就会延长上线的时间。如果之前没有沟通好，认为测试只有内测一个环节，双方之间预估的上线时间不一致也会造成一些误会，影响其它工作如运营活动的准备时间。

对于产品经理来说，了解工作流程有一个很大的必要是不会耽误需求的开发时间。举个例子，如果有些功能是自己公司开发的话，那还好，对于技术的开发时间有准确的把握。但如果是需要对方公司开发的话，因为对方可能还有别的项目做，所以就需要提前把需求提给对方，把握好时间点，要不然因为需求提晚了，对方没时间做那麻烦就大了。

4.不要恶意揣测对方的意图

两个公司合作肯定会出现一些摩擦，虽然彼此的关系不像谈恋爱那么亲密，但也要建立起信任的基础。

让我感触非常深的一点是不要故意揣测对方，比如说对方是否有意使我们为难，对方是否有对我们的系统进行攻击等等。虽然这种情况可能确实存在，但是也要在经过实际验证后才能确定问题。

恶意揣测对方会造成什么不良的后果呢？极大影响团队的士气，特别是在两个公司的背景和团队实力相差悬殊的情况下，弱势的一方在某些方面确实会收到强势一方的要求，例如在代码的书写规范上。我们就遇到这种情况，虽然我们不是外包公司，但是由于产品性质和对方公司在行业内的地位，对系统的稳定性有特别高的要求。

如果对方的要求比较高，自己又无法理解，时间长了，次数多了，内心会积攒很大的情绪。这样一来就更容易揣测对方的意图，加上本身存在的公司地位的差距，会让员工的工作比较消极。

5.做好自己的事，严以律己

双方的合作中如果自己的下属受委屈了，领导会极力袒护，这可以理解，一个好的领导理应维护下属的利益。但还是要有公正的对待，对下属的工作态度和产出的结果有准确的评估，在维护下属利益的同时要判断下属有没有把事情做好。

有的领导一味的维护自己下属的利益，却忽略了下属能力欠缺的问题。甚者，有的下属也会利用领导的这种心理，工作上敷衍了事，遇到坎就让领导出面解决。

曾经有过一个页面的设计，我们的设计师出的设计稿，需要经过双方共同评审后才能通过，但是对方的设计师对我们设计的作品不满意，语言上有一些不妥。碰到这样的行为，可以强硬一些让对方道歉，但毕竟结果还是不理想，冷静下来还是要处理问题。

与技术上的问题不同的是设计稿的评审更多的是受主观因素影响。碰到这种问题，自己一方在尽其全力的前提下，如果效果还不太理想，双方彼此之间要给出具体的意见。之所以说是具体意见，也是为了模糊的说辞引起双方的猜疑，而且意见具体一些，解决问题的效率也更高一些。

#专栏作家#

云瑞，微信公众号：马虎眼，人人都是产品经理专栏作家。原片刻产品经理，6年产品人，走在内容社交产品路上，死磕产品设计，喜欢玩各种APP，玩桌球，打羽毛球，欢迎与大家交流。

本文原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Pexels，基于 CC0 协议