作者：JIN

全文共 4432 字，阅读需要 9 分钟

———— / BEGIN / ————

本人所在的公司是一家创业型公司，由于商业闭环没有打通，在公司发展过程中，就会需要对外接洽一些项目，承接作为公司业务之一进行对应开展。

也因为如此，所以才有幸担任了多个项目的产品经理一职，经历了多个产品从0-1的全过程。

由于在小厂（小公司）工作，所以人员方面都是能者多劳，并且项目开展比较粗暴，基本上精简下来就是一句话：怎么最快，就怎么来，期间能省掉的都省掉。

所以，我身为产品经理一职，为了产品的快速准确落地以及项目的顺利开展，沟通需求的时间和成本都需要极度控制。

当然，也正因为如此，让我经历了许多产品经理没有经历过的各种情况，也为我后来的产品之路成长打下了坚实的基础。

一、什么是沟通

我们可以先来了解一下沟通是什么？它的目的又是什么？

• 沟通是说明事物，把一件事情或一个东西，把它说得很清楚，这就是我们所要达到的目的。

• 沟通是表达情感，有时候不说任何关于其他的事情，单纯为了表达心中的真实情感。

其实还有更多关于沟通的解释，但是我单独说这两条就够了，这也就是我们在跟客户沟通需求的过程中，需要牢牢把握的两个沟通的核心点。

我们与客户沟通产品需求，目的就是为了将需求说清楚、明白，让客户知道你的理解是否跟他想表述的一致，理解到对方最真实的情感表达，即深层次的需求，从而达到沟通产品需求的目的。

二、沟通需求，我们需要注意什么？

由于公司规模不大，设立的产品经理一职，也就相对应的只有我一人，所以外接项目无论大小都会通过我这边来进行客户的沟通。

也因为如此，让我收获颇多，也自我总结了一些需要注意的地方以及技巧。

下面我将一一表述：

1. 项目背景

此处敲黑板！！！

每一个项目的开展，都会有对应的项目背景。

项目背景包括很多，比如：该项目是怎么产生的？项目的意义在哪？项目的目的是什么？项目的组成部分有哪些等等。

因为项目背景包含很多，每一家的项目背景倾向也不一样，获取到的信息也就不尽相同；也正因为如此，导致项目背景恰恰是大家最容易忽略，且不关注的地方……

我刚来公司下半年，公司就承接了一个上市企业的光伏监控项目，当这个前后端（app端、pc后台）都涉及，且还包含硬件方面的项目砸在我一个产品新人手上时，我一脸懵逼，手拿着一份对方给我们的“产品文档”，完全不知道如何下手。在得知第二天将要去和客户面谈需求的时候，我更加不知所措。

现在回想，当时自己的不知所措是为什么？估计是在于自己的害怕，因为不了解项目背景内容所带来的恐惧……

当时看着那份“产品文档”，其中的逆变器、采集器、辐照、装机量、pv1、pv2……让我一头雾水。

内心OS就是：What？这些都是啥？？什么鬼！！！

我相信这种情况不仅仅是我，应该是大部分产品经理或是新人接触到一个全新，或者说领域跨度比较大的项目内容时的第一反应。

这个时候，让自己最快了解项目的办法就是仔细研究项目背景了。

要记住：就算对方给的项目背景不是你想要的，或者提炼不出什么重要信息，你自己也要做一个项目背景调研。

这样对于产品经理来说，也就能够更快的融入客户所处环境，从客户的方面思考并解决这些问题。

如这套系统，知道了它是基于硬件设备（光伏板、逆变器及采集器等）的配合使用，进行发电量、发电功率等数据的收集处理，及对这些硬件设备的工作情况进行管理，达到一个监控管理的作用，方便于多角色管理的一整套系统。

当我们在了解到这些信息之后，就对整个项目有了一个大概的轮廓，对于面谈来说，我们就能够快速带入。

在有限的时间内，获取到更多对产品来说重要的信息，就不会因为在信息不对等的情况下，还要让客户在解释一遍客户认为“大家都懂的”内容，不利于我们的面谈效率。

假如：有产品经理工作内容包含类似这种，外接项目的前期需求对接沟通的话，最好是做一个小小的背景调研，让自己尽可能的和对方做到信息对等。

这样在后续沟通对接当中，就会省掉很多不必要的沟通障碍，也能置身于对方来思考问题。

2. 沟通内容

为了第二天的面谈，我归纳着“产品文档”中描述的重点，各种假设我们双方之间的沟通场景，想着面谈时能够得到比文档更加详细的信息。

然而，现实却是不一样的场景……

双方碰面先寒暄一会，做各种准备工作，等待相应参与会议人员的姗姗到来；再然后，商务进行一些沟通工作，相谈甚欢，又花去了一些时间；最后到我们项目产品沟通的时候，时间其实相对于计划时间，已经所剩无几了。

这个时候，对于一个产品经理来说，所需要面对的实际情况就是如何在有限的时间内，通过沟通获取到对产品来说，最重要的信息。

1）涉及对象

首先，我们一定要沟通清楚：项目业务会涉及到哪些人？这些角色的参与，会牵涉到业务进行的哪部分？哪些角色是参与了我们业务的开展，但是却在客户沟通中，告知我们并不会使用到我们的最终产品？

了解项目业务涉及到的人，意味着知道了将要做的这个项目，这个产品是在这些人的使用或参与下进行的，对后续的业务流程这块，理解起来就会更加形象。

了解这些角色的参与内容，牵涉到了业务开展的哪部份，就会对角色权限这块有清晰的了解，在后续产品文档输出及与开发沟通中，就不会出现权限不明确的情况。

至于参与了项目的角色，但是在客户口述中，这套系统却不是给他们用的这种情况，这个时候就需要产品经理多多留心记录。

因为这些角色及他们所涉及到的内容，说不定就是我们产品设计中的灰色地带。没有从一开始就把控好，后续就会演变成产品设计上的坑，继而影响到了整个开发。

从理论上来说，只要涉及到了项目开展进行的角色，都是系统的使用者。我们做的产品，根本上就是给他们解决问题的，那就不应该出现参与业务流程，却不使用的情况。

2）业务流程

业务流程，不用说也知道，这个肯定是我们在沟通过程中的重中之重，毕竟我们要是连业务流程都不清楚的话，产品设计是无法进行的，整个系统也就无法构建起来。

但是我们在沟通过程中，同样也要注意到一些情况。

情况1：流程的不确定性

这种情况，在许多外接项目中经常遇见，产生这种情况的原因不尽相同；有的是因为公司较大、部门繁多、牵扯太多，需要层层确认之后，才能定下来。

这就导致了：我们在一开始沟通的时候，就会碰到不确定的情况。

还有就是对方没有相对应的项目领头人，或是与我们对接需求的相关人员，并不能承担起确定的责任，这也就会产生后续流程不确定的情况。

这个时候，需要的就是产品经理的小本本，尽可能的把不确定的地方标记下来，一定要保证在有限的情况下，尽可能做到大家都无异议，并确定下来。

这不仅仅是产品经理的责任，也是对客户和开发团队的尊重。

情况2：流程的真实性，实际性

这种情况，一般出现在规模较小的公司，对自己的项目盲目乐观，对自身实力的高估，以及一些公司层面上的其他原因，让产品经理得到的业务流程并不真实，对产品设计和后续开发，产生不可估量的后果。

我在去年的时候，就做过这样一个项目，具体什么不方便说。但是可以说一下项目内容：

是一套在线拍卖系统，系统包含拍卖行端的后台管理、拍卖行端的app及用户端app等，内容大致为拍卖行在后台管理上传相应的拍品。

然后用户可以通过app来查看拍卖行的拍品，拍卖行线下正式拍卖后，通过拍卖行端app来进行线上线下的同步拍卖这样的一个业务流程。

直到现在，我仍然记得，这个项目的老总，亲自来到我们公司谈需求时说的话。

只怪当年太年轻，相信了对方说的。

果然项目后面，崎岖不平，搞得大家都在忙着各种填坑，项目周期也对应比原先拖长了许多。

在项目沟通过程中，我们就提出了这个问题“支付怎么解决”（项目是针对法国拍卖行的，支付这块涉及到国家政策的限制），这个项目的老总就让我们放心，说他在和法国的类似支付宝一样的支付公司，正在进行洽谈合作事宜，只需要开发人员对接接口就行。

听起来是不是感觉问题一下就变简单了？

但是，往往事实却很打脸。

当我们项目开发差不多的时候，问题就接二连三的出现了：

说好的对接呢？

说好的和法国支付公司谈合作呢？

最后什么都没有，没办法，项目还是要继续。

我就跟项目的老总商量了一下，重新设计和构思了一个支付流程，相比较原有的设计，多出了更多的操作流程，而且其中还严重影响到了客户的体验。

后期还会增加了对方工作人员的操作难度，自然而然，也就影响到了我们的开发进度及工作量。

所谓的理想情况又是什么呢？

就是认为的以自身来说，不会出现其他问题的情况，就是理想情况。

但是，往往有理想，就有现实。

说好的用户可以通过app端购买，就可以像类似电商平台一样，获取到物流公司的接口，让用户不用繁琐操作，就能有很好的体验呢？为什么要让用户申请物流？为什么要让服务人员，确认物流信息？为什么用户不能看见物流信息？说好的理想情况就是这样么？

这就是所谓的理想情况对应的现实情况！

这又是一个因为被隐瞒而踩到的坑，后来没办法，在开发都已经差不多的情况下，又重新设计了一个对应的流程，在增加了各方的负担，牺牲了体验的情况下，最后保证了业务的正常开展。

这些因为对方没有正确告知或故意隐瞒我们，导致业务流程不清晰或不正确的情况，是一直存在的。

假如不想被套路或者被开发同事鄙视的话，真的需要提高自己的“火眼金睛”，增强自己的鉴别能力，并做好相应的文档需求说明，让对方确认。这样即使是开发过程中，有需要变动的地方，也好有所依据。

现在回想，真的很感谢当时开发同事的不杀之恩。

3）想要达到的效果（目的）

沟通过程中，我们一定要明确对方的最终诉求是什么？希望达到的愿景是什么？或者说希望解决的问题是什么？

我们的客户，其实并不太会直接说自己想要的目的是什么？大都说的是想要解决的问题是什么？

想要达到怎样一个效果，这个时候的产品经理，一定要把握好，这不一定是他的最终诉求，但是肯定是对方能够表达的最直接的痛点，我们需要做的就是顺藤摸瓜，了解对方诉求。

往往对方在给你诉说需要解决的问题时，通常都会顺带给你一个建议。记住：这个建议可以当作参考，但是不一定要当作最终的解决方法，因为这样做，并不是不行，但是大家扪心自问，我们这样做的话，还是产品经理吗，还需要产品经理吗？

最终需求是什么？

这时候产品经理需要抓住的不是“马车”这个关键词，而是“更快”这个关键词，他应该理解用户的需求其实是在需要一个更快的交通工具上，所以汽车就被发明出来了。

这就是一个很好的例子，谨记。

这几点，基本上就是我产品路上经历过之后，总结的一些沟通方面的要点， 特别是作为项目型产品经理在沟通过程中，更加需要关注的地方，希望给大家一些启发。

———— / END / ————

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