时间: 2021-07-30 09:51:56 人气: 7 评论: 0
文章将围绕公司外接项目的产品从0-1的第一阶段（沟通需求），并结合自身实际经历，浅谈一下所总结的方法技巧，希望对大家，尤其是踏入产品的新人及做承接项目的产品经理有一定的帮助。
本人所在的公司是一家创业型公司，由于商业闭环没有打通，在公司发展过程中，就**需要对外接洽一些项目，承接作为公司业务之一进行对应开展。也因为如此，所以才有幸担任了多个项目的产品经理一职，经历了多个产品从0-1的全过程。
由于在小厂（小公司）工作，所以人员方面都是能者多劳，并且项目开展比较粗暴，基本上精简下来就是一句话：怎么最快，就怎么来，期间能省掉的都省掉。所以，我身为产品经理一职，为了产品的快速准确落地以及项目的顺利开展，沟通需求的时间和成本都需要极度控制。
当然，也正因为如此，让我经历了许多产品经理没有经历过的各种情况，也为我后来的产品之路成长打下了坚实的基础。
我们可以先来了解一下沟通是什么？它的目的又是什么？
其实还有更多关于沟通的解释，但是我单独说这两条就够了，这也就是我们在跟客户沟通需求的过程中，需要牢牢把握的两个沟通的核心点。
我们与客户沟通产品需求，目的就是为了将需求说清楚、明白，让客户知道你的理解是否跟他想表述的一致，理解到对方最真实的情感表达，即深层次的需求，从而达到沟通产品需求的目的。
由于公司规模不大，设立的产品经理一职，也就相对应的只有我一人，所以外接项目无论大小都**通过我这边来进行客户的沟通。也因为如此，让我收获颇多，也自我总结了一些需要注意的地方以及技巧。
下面我将一一表述：
此处敲黑板！！！
每一个项目的开展，都**有对应的项目背景，项目背景包括很多，比如：该项目是怎么产生的？项目的意义在哪？项目的目的是什么？项目的组成部分有哪些等等。
因为项目背景包含很多，每一家的项目背景倾向也不一样，获取到的信息也就不尽相同，也正因为如此，导致项目背景恰恰是大家最容易忽略，且不关注的地方……
我刚来公司下半年，公司就承接了一个上市企业的光伏监控项目，当这个前后端（app端、pc后台）都涉及，且还包含硬件方面的项目砸在我一个产品新人手上时，我一脸懵逼，手拿着一份对方给我们的“产品文档”，完全不知道如何下手。在得知第二天将要去和客户面谈需求的时候，我更加不知所措。现在回想，当时自己的不知所措是为什么？估计是在于自己的害怕，因为不了解项目背景内容所带来的恐惧……
当时看着那份“产品文档”，其中的逆变器、采集器、辐照、装机量、pv1、pv2……让我一头雾水。
内心OS就是：what？这些都是啥？？什么鬼！！！
我相信这种情况不仅仅是我，应该是大部分产品经理或是新人接触到一个全新，或者说领域跨度比较大的项目内容时的第一反应。
这个时候，让自己最快了解项目的办法就是仔细研究项目背景了。要记住：就算对方给的项目背景不是你想要的，或者提炼不出什么重要信息，你自己也要做一个项目背景调研。
例如：这个光伏项目，给到的信息不是太明白，那我们就去看同类的类似项目的介绍，了解项目的组成部分，开展情况，以及达到的效果目的。这样对于产品经理来说，也就能够更快的融入客户所处环境，从客户的方面思考并解决这些问题。
如这套系统，知道了它是基于硬件设备（光伏板、逆变器及采集器等）的配合使用，进行发电量、发电功率等数据的收集处理，及对这些硬件设备的工作情况进行管理，达到一个监控管理的作用，方便于多角色管理的一整套系统。
当我们在了解到这些信息之后，就对整个项目有了一个大概的轮廓，对于面谈来说，我们就能够快速带入。在有限的时间内，获取到更多对产品来说重要的信息，就不**因为在信息不对等的情况下，还要让客户在解释一遍客户认为“大家都懂的”内容，不利于我们的面谈效率。
假如：有产品经理工作内容包含类似这种，外接项目的前期需求对接沟通的话，最好是做一个小小的背景调研，让自己尽可能的和对方做到信息对等。这样在后续沟通对接当中，就**省掉很多不必要的沟通障碍，也能置身于对方来思考问题。
为了第二天的面谈，我归纳着“产品文档”中描述的重点，各种假设我们双方之间的沟通场景，想着面谈时能够得到比文档更加详细的信息。
然而，现实却是不一样的场景……
双方碰面先寒暄一**，做各种准备工作，等待相应参与**议人员的姗姗到来。再然后，商务进行一些沟通工作，相谈甚欢，又花去了一些时间。最后到我们项目产品沟通的时候，时间其实相对于计划时间，已经所剩无几了。
这个时候，对于一个产品经理来说，所需要面对的实际情况就是如何在有限的时间内，通过沟通获取到对产品来说，最重要的信息。
1）涉及对象
首先，我们一定要沟通清楚，项目业务**涉及到哪些人？这些角色的参与，**牵涉到业务进行的哪部分？哪些角色是参与了我们业务的开展，但是却在客户沟通中，告知我们并不**使用到我们的最终产品？
了解项目业务涉及到的人，意味着知道了将要做的这个项目，这个产品是在这些人的使用或参与下进行的，对后续的业务流程这块，理解起来就**更加形象。
了解这些角色的参与内容，牵涉到了业务开展的哪部份，就**对角色权限这块有清晰的了解，在后续产品文档输出及与开发沟通中，就不**出现权限不明确的情况。
至于参与了项目的角色，但是在客户口述中，这套系统却不是给他们用的这种情况，这个时候就需要产品经理多多留心记录。因为这些角色及他们所涉及到的内容，说不定就是我们产品设计中的灰色地带。没有从一开始就把控好，后续就**演变成产品设计上的坑，继而影响到了整个开发。
从**上来说，只要涉及到了项目开展进行的角色，都是系统的使用者。我们做的产品，根本上就是给他们解决问题的，那就不应该出现参与业务流程，却不使用的情况。
2）业务流程
业务流程，不用说也知道，这个肯定是我们在沟通过程中的重中之重，毕竟我们要是连业务流程都不清楚的话，产品设计是无法进行的，整个系统也就无法构建起来。
但是我们在沟通过程中，同样也要注意到一些情况。
情况1：流程的不确定性
这种情况，在许多外接项目中经常遇见，产生这种情况的原因不尽相同。有的是因为公司较大、部门繁多、牵扯太多，需要层层确认之后，才能定下来。这就导致了：我们在一开始沟通的时候，就**碰到不确定的情况。
还有就是对方没有相对应的项目领头人，或是与我们对接需求的相关人员，并不能承担起确定的责任，这也就**产生后续流程不确定的情况。
这个时候，需要的就是产品经理的小本本，尽可能的把不确定的地方标记下来，一定要保证在有限的情况下，尽可能做到大家都无异议，并确定下来。这不仅仅是产品经理的责任，也是对客户和开发团队的尊重。
情况2：流程的真实性，实际性
这种情况，一般出现在规模较小的公司，对自己的项目盲目乐观，对自身实力的高估，以及一些公司层面上的其他原因，让产品经理得到的业务流程并不真实，对产品设计和后续开发，产生不可估量的后果。
我在去年的时候，就做过这样一个项目，具体什么不方便说。但是可以说一下项目内容，是一套在线拍卖系统，系统包含拍卖行端的后台管理、拍卖行端的app及用户端app等，内容大致为拍卖行在后台管理上传相应的拍品。然后用户可以通过app来查看拍卖行的拍品，拍卖行线下正式拍卖后，通过拍卖行端app来进行线上线下的同步拍卖这样的一个业务流程。
直到现在，我仍然记得，这个项目的老总，亲自来到我们公司谈需求时说的话。
“放心，你们提的这些问题，我们都能解决。“
“我们的理想情况是……“
“功能不要太复杂，但是体验一定要好……“
只怪当年太年轻，相信了对方说的，果然项目后面，崎岖不平，搞得大家都在忙着各种填坑，项目周期也对应比原先拖长了许多。
在项目沟通过程中，我们就提出了这个问题“支付怎么解决”（项目是针对法国拍卖行的，支付这块涉及到国家政策的限制），这个项目的老总就让我们放心，说他在和法国的类似支付宝一样的支付公司，正在进行洽谈合作事宜，只需要开发人员对接接口就行。
听起来是不是感觉问题一下就变简单了，但是，往往事实却很打脸。当我们项目开发差不多的时候，问题就接二连三的出现了，说好的对接呢？说好的和法国支付公司谈合作呢？
最后什么都没有，没办法，项目还是要继续，我就跟项目的老总商量了一下，重新设计和构思了一个支付流程，相比较原有的设计，多出了更多的操作流程，而且其中还严重影响到了客户的体验。后期还**增加了对方工作人员的操作难度，自然而然，也就影响到了我们的开发进度及工作量。
所谓的理想情况又是什么呢？
就是认为的以自身来说，不**出现其他问题的情况，就是理想情况。但是，往往有理想，就有现实。
说好的用户可以通过app端购买，就可以像类似电商平台一样，获取到物流公司的接口，让用户不用繁琐操作，就能有很好的体验呢？为什么要让用户申请物流？为什么要让服务人员，确认物流信息？为什么用户不能看见物流信息？说好的理想情况就是这样么？
这就是所谓的理想情况对应的现实情况！
这又是一个因为被隐瞒而踩到的坑，后来没办法，在开发都已经差不多的情况下，又重新设计了一个对应的流程，在增加了各方的负担，牺牲了体验的情况下，最后保证了业务的正常开展。
这些因为对方没有正确告知或故意隐瞒我们，导致业务流程不清晰或不正确的情况，是一直存在的。假如不想被套路或者被开发同事鄙视的话，真的需要提高自己的“火眼金睛”，增强自己的鉴别能力，并做好相应的文档需求说明，让对方确认。这样即使是开发过程中，有需要变动的地方，也好有所依据。
现在回想，真的很感谢当时开发同事的不杀之恩。
3）想要达到的效果（目的）
沟通过程中，我们一定要明确对方的最终诉求是什么？希望达到的愿景是什么？或者说希望解决的问题是什么？
我们的客户，其实并不太**直接说自己想要的目的是什么？大都说的是想要解决的问题是什么？
想要达到怎样一个效果，这个时候的产品经理，一定要把握好，这不一定是他的最终诉求，但是肯定是对方能够表达的最直接的痛点，我们需要做的就是顺藤摸瓜，了解对方诉求。
往往对方在给你诉说需要解决的问题时，通常都**顺带给你一个建议。记住：这个建议可以当作参考，但是不一定要当作最终的解决方法，因为这样做，并不是不行，但是大家扪心自问，我们这样做的话，还是产品经理吗，还需要产品经理吗？
“我需要一辆更快的马车……“
最终需求是什么？这时候产品经理需要抓住的不是“马车”这个关键词，而是“更快”这个关键词，他应该理解用户的需求其实是在需要一个更快的交通工具上，所以汽车就被发明出来了。
这就是一个很好的例子，谨记。
这几点，基本上就是我产品路上经历过之后，总结的一些沟通方面的要点， 特别是作为项目型产品经理在沟通过程中，更加需要关注的地方，希望给大家一些启发。
本文由 @JIN 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
