针对B端产品，如何顺利开展workshop？

　　workshop，也就是我们常说的需求访问会。在workshop中，业务双方会对产品需求进行初步沟通与评估，笔者结合自己的经验，和我们一起聊聊B端产品的需求访问是怎么样的。
　　一、什么是workshop
　　各位B端产品需求分析的同学一定对workshop这个名词不陌生，它的中文名是需求访谈会。个人对C端产品不熟，本文也仅就B端产品的访谈聊一聊个人经验。本文适合03岁的产品同学。
　　一般而言，workshop指的是就某一议题的面对面需求沟通会议，用于沟通业务现状、痛点，并初步评估需求的可行性及方案，及传达初步方案。
　　一般成员包括：
　　业务
　　产品经理
　　架构师资深开发
　　一场好的workshop应该至少做到以下几点：
　　业务关键流程及关键需求点达成决策；
　　评估需求可行性，对于简单需求可形成各方满意的初步方案；
　　识别并剔除不合理需求（例如：需求无逻辑或实际可能发生的业务支撑、投产比太低、造成项目风险的需求）；
　　形成清晰的会议纪要需求文档。
　　痛点
　　Workshop的特点是信息密集，背景了解较少，因此造成沟通较难。以下列举我在过去几年中常见的痛点：
　　业务需求沟通不到位：如遗漏、错误；未挖掘真实需求导致需求易变更；
　　方案可实施性差导致需求重谈；
　　需求管控失败：如跑题导致需求无法充分表达、无限发散、接受不合理需求等。
　　以下将根据经验方法，按照workshop的各个环节展开阐述如何避免痛点、达成目标。
　　二、事前准备
　　1。了解背景
　　会前需尽可能了解以下信息：
　　（1）沟通的主题
　　若沟通主题是他人发起的，则需要了解主题的业务知识，最好是该公司部门目前的业务。若无法获知，则应了解行业或龙头的业务模式和解决方案，可在后续沟通中获得优势。
　　还需了解本次沟通的目的是为了解决什么问题，例如解决现有系统功能不好用的问题，则应尽量了解当前的系统操作。有条件的可以去测试环境等操作一下。
　　（2）对方的部门架构
　　Workshop费时费力，我们应了解对方部门的架构，确保沟通对象能决策沟通主题，或至少能负责大部分问题。对于中途加入的沟通对象，应了解或询问其岗位。比如：这位也是你们做运营的同事吗？和你一样负责系统对接吗？
　　以上问题也适用于沟通过程中出现的新主题、新加入访谈的成员。
　　前一阵某知名咨询公司来我司访谈，他们主访谈顾问都不问一下我司甲方参会的是谁，于是在一屋子业务中，选择问一个新人程序员业务流程，结果后面结论推翻重新谈。
　　（3）沟通对象的能力
　　我们需要找到一个熟悉业务系统的人进行沟通。若已知该对象的能力不行，则可以在初期尝试换人或找到其他外援同事。换不了是大多数，但是如果外援都找不到那就会累死自己和项目。
　　外援可以是你同行其他公司的朋友（他们的意见只能作为参考），也可以是业务部门的其他负责相似模块的同事。
　　（4）我方领导的要求
　　我方领导掌握着资源，不搞清楚他们要什么、能接受什么，可能要命。大需求workshop之前，需要着重弄清楚领导对需求的定位（什么时候愿意投入多大资源），至少受到领导的授权。
　　2。安排人员
　　一个流程完善的公司，一场需求评审会要产品、业务、运营、UI、开发、测试、架构师等角色参与。同样，在workshop阶段，也有其人员安排：
　　12名产品（依据沟通会内容复杂度、长度而定，可用录音笔挽救）
　　资深开发架构师一枚
　　可决策的业务
　　确定人员后，对于内部team（其他产品和开发）还需做以下事情，用于培养默契：
　　互相传递了解的业务背景
　　预估会议沟通难度、难点
　　明确主旨和互相配合点
　　特别强调一下要带开发，因为哪怕真的很简单的功能，你的开发可能会告诉你不能做，所以需要一个技术伙伴实时帮你评估，帮你怼其他开发，还能从技术角度帮你怼需求。
　　3。安排场次
　　在workshop之前，需逐步了解信息以合理安排后续访谈计划：
　　根据业务知识和项目需求背景，找准对接人。
　　通过最初沟通了解需求框架和主要关联方，然后安排后续的workshop：
　　首先需组织一场项目需求背景介绍会议，务必请对接人协助邀请各个关联方参与。会后需收集关联方的态度和意见，明确后续对接人，并及时反馈各方领导。
　　后续根据需求细节安排主题相关的会议即可，但是每场会议都要事前明确沟通主题，时间和会议室尽早预定。
　　最后，需求内容定稿阶段，组织一次各方参与的会议评审，此次会议不强求各方参与、但需知会各方。
　　关于会议时间的选择，时长最好在2小时内，并且安排在上班半小时后、下班半小时前。如需其他人加班支持，最好事先面对面沟通请求帮助。
　　三、事中沟通
　　在沟通前，我们已经做了大量铺垫，这会大大提升我们的自信。访谈主要目的不是交朋友，而是对外理解需求，明确需求、挖掘需求、引导需求；对内传达需求，确保队友理解主框架，减少会后再次沟通工作量。
　　1。抓议题
　　当会议较为顺利、人员沟通能力较好时，会议容易出现发散的情况。无关话题发散超过02分钟就必须打断。
　　另一种常见情况是，内容相关但是层次不对，例如在沟通框架的会议上过多地讨论细节，也需要打断。
　　对于会议主持者，要知道什么话题会易于带来发散和细节讨论，并在自身避免。
　　能判断什么话题需要打断，讨论的东西能否帮助解决问题，无关的及时打断。其次方式要合适，例如：你的点很有用，我记下来了，后面细节讨论的时候再说，我们现在先看XX问题。
　　2。打破僵局
　　与上面一种情况相反的是，会议陷入僵局。你需要分析僵局的原因，例如：
　　参会人不知主题其他人员，则需介绍背景。
　　被技术业务性问题卡住，则可以抓大放小，能不纠结的就先过；对于较大问题可询问谁懂这一块，能否现在邀请参会。
　　被制度流程性、决策性问题卡住，大多数情况则需了解问题找哪位领导拍板，并给出可能结果的对应方案，重大问题不要擅作决定。例如：回去你和你们李总沟通一下，如果要做，我们就XXX；如果不做，我们也向领导反馈为什么不做。
　　对方故意不配合，若感受到这一点，则需说明来意，放低身段，可以说是双方领导安排，可以表明合作的好处，但不要自恃专业、表达高人一等情绪。
　　对方描述不清楚问题，这种情况需要你用清晰的逻辑帮忙梳理流程、问题。
　　对于暂时无解的阻断性问题，可以在安排后续action后，再中止会议，让出时间解决问题。
　　再举一个反例，前段时间有位tier2的10年资深顾问来我司访谈，张口就说我们做了十多年的业务根本不对。我们解释了之后，她竟然反馈说这一套流程市面上80公司都自动化了（这个数据不知道从哪里听来的，完全不负责的态度啊），导致我们业务狂翻白眼然后敷衍了事，最后她的访谈拿到的只是她脑海中的那一套已有的业务信息。
　　3。及时反馈确认
　　沟通需求最忌讳的就是似是而非，最怕的就是以为自己懂了其实并没有。以下做法可以减少错误：
　　理解的情况下，要用自己的语言简短概括，这样能确保理解正确并同时完成需求明确。
　　对于似是而非的问题，要多问几个来源，确保自己理解了，确保访谈对象提供的信息可靠，而不是接受错误的结论。
　　对于自己不懂的且在主线上的问题，不要羞于提问，不要窃窃私语，反而要及时直接提问。若花了一段时间仍不理解而且队友理解了，那可以考虑先过掉。
　　对于关键性节点，还需多问队友是否也理解了，否则后半程队友可能就是一尊菩萨。
　　往往是模糊的地方，藏着潜在需求。一般明确的、好解决的问题早就解决了。几个经典的问题是：
　　你们现在系统是怎么做的？
　　你们现在遇到的问题是什么？（要点是拆分问题、连续追问）例如自动化率不高，那么你们全流程是哪些步骤？哪些步骤已经自动化、哪些没有？已有的步骤是否已全部自动化？如何实现的？没有自动化的步骤问题是什么？是太复杂还是投产比太低？
　　你们曾经为了解决问题做过什么？（这个问题可以帮你踩坑）
　　关于具体挖掘需求的方法，站上有很多，就不多说啦。
　　4。配合引导
　　用开发的话说，需求都是能做的，只是人力的问题。而我们要引导用户去省时省力的方向，还要引导客户放弃次要矛盾。
　　对于需引导的点，在了解需求的基础上，还需要有以下能力，这样才能谈引导：
　　知道该需求的实际业务重要性
　　对于所谈需求的主要方案已心中有数
　　知道各个主要方案的人力耗费
　　知道你引导的方案不能解决什么问题，这些问题是否致命
　　对于不重要或不合理的业务需求方案，提出问题以引导。正向引导在于阐述方案的优点，反向引导则在于指出业务的不成熟想法。以反向提问为例：
　　讲机会成本：要做这个方案，你们需要投入多少IT人力，导致你们其他的XXX需求无法支持。
　　讲质量：若按你的方案做，重要性不高、解决不了你目前的问题，反而带来IT工作量，在固定时间内工作量变大，质量会下降，包括其余你重视的功能ABC。
　　讲后续业务自身影响：你们业务后续也需要花费多少人力支持。
　　讲复杂度：让开发小伙伴现讲后台实现方案的问题，喝口水让他们回答开发的问题吧。
　　设置统筹题：涉及其他业务风险，请统筹财务、法务、信息安全等等。
　　讲流程管控：能做，但是项目会带来上线风险，需告知项目组及双方领导核实后做；超出SOW范围无法做主，请上升PMO。
　　讲行业经验：龙头都是怎么做的
　　抛漏洞：迅速找到对方方案的漏洞（而我的方案没有的漏洞），让对方给出解决方案。
　　正向引导可以从以上角度讲自己方案的优点。不过遇上大包大揽的老板，那就只能多做啦。
　　5。传递情绪与价值
　　你要能及时感知他人的情绪，并制定对应的沟通策略。具体的内容后续有时间再写。只有情绪稳定、互相有一定信任感，才可能互相有效沟通。
　　作为被访谈方，业务输出了业务知识，你在接收之余应该回馈一些价值，以保持你来我往的平衡感（哪怕实际价值不对等）。在会议空余或闲聊时间中，可以与业务专家讨论一些别的事情。这需要在沟通中观察他人对什么感兴趣。总要能找到自己的一些输出点。
　　例如，教业务基本的IT项目管理知识是我最喜欢做的一件事，他们懂了项目管理基础之后，才能知道怎么配合你才能把项目打上线。
　　八一八各个部门公司间的行情都是可以的，这样可以了解对方部门的近况、趋势。
　　交流交流职业，比如之前我在乙方的实习生就给客户讲现在大学生都怎么找实习，实习行情怎么样，客户听了之后觉得自己的实习招聘贴应该改一改。
　　四、事后跟进
　　事后产出比较好理解，要及时发出会议纪要：
　　一般会议纪要都有模板，记录会议时间、地点、人物、主题；
　　内容方面记录业务需求沟通结论，对于重要非结论性沟通也要记录。会议纪要不是简单的内容阐述，要拿出写初稿需求的架势来对待。
　　会议纪要最核心的是待办事项，初步方案，及责任人，解决时间。
　　对于待追踪事项，需要持续跟进，在截止日前就要开始追进度，而不是以会议纪要发出为终点。
　　对于一些其他对结论有影响的较重大事项，应及时知会各方。
　　最后
　　记得刚毕业入行时，小朋友连访谈会都是不太能参加的，只能拿着前线senior的会议纪要画图，对直面业务客户有一定的恐惧感。实际上访谈是一系列综合因素混合的结果，表面上是主持需求访谈会议，实际上要求你对人对事对业务都要有一定的了解，才能顺利开展。
　　除了上文的一些内容，过硬的业务系统知识、过关的沟通表达、与客户关系维护能力、筛选靠谱的搭档队友等等都是成功访谈的其他条件，这都不是一朝一夕的事情，要早早准备哟。
　　第一次写文，写的比较浅显，主要是一些主持会议的思路框架，没有太多抽象的东西。欢迎大家交流