一、调研准备

（1）客户业务的了解

需要了解主题的业务知识，最好是该公司/部门目前的业务。若无法获知，则应了解行业或龙头的业务模式和解决方案，可在后续沟通中获得优势。

如果有条件/有需求，可以亲自体验一下对方的服务，在服务中通过自己的亲身体验感受目前的服务流程是怎样的？哪里可以优化？把服务流程中存疑的点能当时询问服务人员的最好都一一发问，并且将对方的回答也都一一记录。除了可以在事后仔细分析其背后的真实需求外，也可以圈定一部分和对方对接需求时需要当面重点交流的问题。

如果因为时间、地点等等原因没法亲自体验服务，那么事先在网上搜集相关资料也是极好的。特别是如果对方已经和一些平台合作的情况下，在那些平台上看看客户的评价反馈。对于差评和好评都应特别关注。在自己的产品研发过程中更好的扬长避短。

还需了解本次沟通的目的是为了解决什么问题，例如解决现有系统功能不好用的问题，则应尽量了解当前的系统操作。有条件的可以去测试环境等操作一下。

（2）对方的部门架构

Workshop费时费力，我们应了解对方部门的架构，确保沟通对象能决策沟通主题，或至少能负责大部分问题。对于中途加入的沟通对象，应了解或询问其岗位。比如：这位也是你们做运营的同事吗？和你一样负责系统对接吗？

以上问题也适用于沟通过程中出现的新主题、新加入访谈的成员。

前一阵某知名咨询公司来我司访谈，他们主访谈顾问都不问一下我司甲方参会的是谁，于是在一屋子业务中，选择问一个新人程序员业务流程，结果后面结论推翻重新谈。

（3）沟通对象的能力

我们需要找到一个熟悉业务/系统的人进行沟通。若已知该对象的能力不行，则可以在初期尝试换人或找到其他外援同事。换不了是大多数，但是如果外援都找不到那就会累死自己和项目。

外援可以是你同行其他公司的朋友（他们的意见只能作为参考），也可以是业务部门的其他负责相似模块的同事。

（4）我方领导的要求

我方领导掌握着资源，不搞清楚他们要什么、能接受什么，可能要命。大需求workshop之前，需要着重弄清楚领导对需求的定位（什么时候愿意投入多大资源），至少受到领导的授权。

二、实际的沟通

在沟通前，我们已经做了大量铺垫，这会大大提升我们的自信。访谈主要目的不是交朋友，而是对外理解需求，明确需求、挖掘需求、引导需求；对内传达需求，确保队友理解主框架，减少会后再次沟通工作量。

1. 抓议题

当会议较为顺利、人员沟通能力较好时，会议容易出现发散的情况。无关话题发散超过0~2分钟就必须打断。

另一种常见情况是，内容相关但是层次不对，例如在沟通框架的会议上过多地讨论细节，也需要打断。

对于会议主持者，要知道什么话题会易于带来发散和细节讨论，并在自身避免。

能判断什么话题需要打断，讨论的东西能否帮助解决问题，无关的及时打断。其次方式要合适，例如：你的点很有用，我记下来了，后面细节讨论的时候再说，我们现在先看XX问题。

2. 打破僵局

与上面一种情况相反的是，会议陷入僵局。你需要分析僵局的原因，例如：

参会人不知主题/其他人员，则需介绍背景。

被技术/业务性问题卡住，则可以抓大放小，能不纠结的就先过；对于较大问题可询问谁懂这一块，能否现在邀请参会。

被制度流程性、决策性问题卡住，大多数情况则需了解问题找哪位领导拍板，并给出可能结果的对应方案，重大问题不要擅作决定。例如：回去你和你们李总沟通一下，如果要做，我们就XXX；如果不做，我们也向领导反馈为什么不做。

对方故意不配合，若感受到这一点，则需说明来意，放低身段，可以说是双方领导安排，可以表明合作的好处，但不要自恃专业、表达高人一等情绪。

对方描述不清楚问题，这种情况需要你用清晰的逻辑帮忙梳理流程、问题。

对于暂时无解的阻断性问题，可以在安排后续action后，再中止会议，让出时间解决问题。

再举一个反例，前段时间有位tier2的10+年资深顾问来我司访谈，张口就说我们做了十多年的业务根本不对。我们解释了之后，她竟然反馈说这一套流程市面上80%公司都自动化了（这个数据不知道从哪里听来的，完全不负责的态度啊），导致我们业务狂翻白眼然后敷衍了事，最后她的访谈拿到的只是她脑海中的那一套已有的业务信息。

3. 及时反馈确认

沟通需求最忌讳的就是似是而非，最怕的就是以为自己懂了其实并没有。以下做法可以减少错误：

理解的情况下，要用自己的语言简短概括，这样能确保理解正确并同时完成需求明确。

对于似是而非的问题，要多问几个来源，确保自己理解了，确保访谈对象提供的信息可靠，而不是接受错误的结论。

对于自己不懂的且在主线上的问题，不要羞于提问，不要窃窃私语，反而要及时直接提问。若花了一段时间仍不理解而且队友理解了，那可以考虑先过掉。

对于关键性节点，还需多问队友是否也理解了，否则后半程队友可能就是一尊菩萨。

往往是模糊的地方，藏着潜在需求。一般明确的、好解决的问题早就解决了。几个经典的问题是：

你们现在系统是怎么做的？

你们现在遇到的问题是什么？（要点是拆分问题、连续追问）例如自动化率不高，那么你们全流程是哪些步骤？哪些步骤已经自动化、哪些没有？已有的步骤是否已全部自动化？如何实现的？没有自动化的步骤问题是什么？是太复杂还是投产比太低？

你们曾经为了解决问题做过什么？（这个问题可以帮你踩坑）

关于具体挖掘需求的方法，站上有很多，就不多说啦。

4. 配合引导

用开发的话说，需求都是能做的，只是人力的问题。而我们要引导用户去省时省力的方向，还要引导客户放弃次要矛盾。

对于需引导的点，在了解需求的基础上，还需要有以下能力，这样才能谈引导：

知道该需求的实际业务重要性

对于所谈需求的主要方案已心中有数

知道各个主要方案的人力耗费

知道你引导的方案不能解决什么问题，这些问题是否致命

对于不重要或不合理的业务需求方案，提出问题以引导。正向引导在于阐述方案的优点，反向引导则在于指出业务的不成熟想法。以反向提问为例：

讲机会成本：要做这个方案，你们需要投入多少IT人力，导致你们其他的XXX需求无法支持。

讲质量：若按你的方案做，重要性不高、解决不了你目前的问题，反而带来IT工作量，在固定时间内工作量变大，质量会下降，包括其余你重视的功能ABC。

讲后续业务自身影响：你们业务后续也需要花费多少人力支持。

讲复杂度：让开发小伙伴现讲后台实现方案的问题，喝口水让他们回答开发的问题吧。

设置统筹题：涉及其他业务风险，请统筹财务、法务、信息安全等等。

讲流程管控：能做，但是项目会带来上线风险，需告知项目组及双方领导核实后做；超出SOW范围无法做主，请上升PMO。

讲行业经验：龙头都是怎么做的

抛漏洞：迅速找到对方方案的漏洞（而我的方案没有的漏洞），让对方给出解决方案。

正向引导可以从以上角度讲自己方案的优点。不过遇上大包大揽的老板，那就只能多做啦。

5. 传递情绪与价值

你要能及时感知他人的情绪，并制定对应的沟通策略。具体的内容后续有时间再写。只有情绪稳定、互相有一定信任感，才可能互相有效沟通。

作为被访谈方，业务输出了业务知识，你在接收之余应该回馈一些价值，以保持你来我往的平衡感（哪怕实际价值不对等）。在会议空余或闲聊时间中，可以与业务专家讨论一些别的事情。这需要在沟通中观察他人对什么感兴趣。总要能找到自己的一些输出点。

例如，教业务基本的IT项目管理知识是我最喜欢做的一件事，他们懂了项目管理基础之后，才能知道怎么配合你才能把项目打上线。

八一八各个部门公司间的行情都是可以的，这样可以了解对方部门的近况、趋势。

交流交流职业，比如之前我在乙方的实习生就给客户讲现在大学生都怎么找实习，实习行情怎么样，客户听了之后觉得自己的实习招聘贴应该改一改。

三、会议纪要

应该含有以下几个要点：

明确对方的业务目标和自己公司的商业目标

数次会议后达成的共识（本次产品设计中涉及/不涉及的功能点）

对方参与的用户角色（需要考虑相应的角色划分）

业务主流程（若比较复杂，还需要附上关键部分子流程）

本次产品预计设计的功能点及其包含的功能

需要对方协助的一部分工作（需要提供的辅助材料、相关的人力/物力/宣传）

其中需要重点关注的有：达成的共识中不涉及的功能点，若是客户意见强烈希望在产品上得以实现，则需要在和老板商量和给客户一个大概（模糊、糊弄过去）的时间；客户的用户角色则是参与产品使用的角色，一般要涉及到用户角色划分以及相关权限配置；本次产品设计的功能点：若有 DEMO、草图是最好，若没有则可以输出一份需求清单 List 类似的描述文件，让对方大概知道里面有什么功能，大概的层级是什么；需要对方协助的工作：这里需要和市场部的同事提前确认一下宣传和运营 Follow，其他的多是一些基础资料初始化的东西。

四、需求验证

验证的方式是多样的，可以是产品、竞品、demo、高保真、低保真、草图原型甚至是一张手绘的草图都可作为测试方法，根据演示环境和用户的角色的不同观察用户使用产品，其本质目的就是验证需求、收集需求。