企业沟通案例--X公司多轮需求沟通未明确需求的现象分析

Posted 2020-12-13 joeni

摘要：大型人工智能公司X公司的三个部门：资源部、研究院、数据平台组在涉及导出数据格式的确认上，出现了多轮沟通仍未能确认真实需求的情况。该问题出现的原因是需求传输路径过长，缺少直接沟通；需求的转述者缺乏对需求背后所隐含的原因的理解；其需求的接收者缺乏对业务操作细节的观察与理解。面对这种情况，需求的接收方如何深刻理解需求提出者的真实诉求并制定合理的方案。如何改进工作，减少这种现象出现的频率。各方分析问题解决问题的过程，诊断分析沟通存在的问题，以及工作方法的改进是本篇案例重点讨论的内容。

 

关键词：跨部门沟通，需求提出，需求传达，需求分析，换位思考，场景复现

 

1. 背景描述

1.1 沟通人员：资源部X女士、Ya女士；研究院Yu先生；数据平台方B女士、Ni先生、N先生。

 

1.2 公司背景：

X公司是一家人工智能公司，资源部、数据平台和研究院隶属3个不同的部门。资源部使用数据平台研发的数据标注工具生产数据资源，研究院用生产的数据资源对人工智能引擎进行训练，提高引擎的识别精度。

长期以来资源部X女士负责语音方向的数据生产管理，Ya女士负责资源部各个方向的成品数据管理；数据平台B女士、Ni先生从事数据平台的需求分析与功能设计，N先生从事数据平台的功能开发；研究院Yu先生从事人工智能引擎的训练工作。

 

2. 沟通过程：

一天，研究院Yu先生反馈了一些关于数据导出的需求给资源部的X女士，X女士将需求转述给了资源部负责数据管理工作的Ya女士。Ya女士汇总了资源部各个方向与导出相关的需求，并将需求提供给了数据管理平台的Ni先生。其中关于文本路径的问题，X女士，最初转述的是，文本的文件路径中文件名称部分和音频文件夹名称保持一致。但是并没有表述清楚，需要这样改动的原因是什么。在Ni先生的追问下，X女士再次和Yu先生沟通了解该需求背后的原因。然后X女士再次找到Ni先生，表明这样改动的原因是为了方便研究员根据文本路径寻找对应的音频文件。于是，Ni先生根据这个需求背后的目的，给出了自己的一套解决方案。鸡在导出的音频数据中保持上传云盘时的文件夹层级，因此标注完成后导出数据时，音频文件的相对路径就不会发生改变，这样便于研究组根据文本路径上记录的相对路径找到对应的音频。根据开发N先生的评估，这种改造方案的开发工作量中等偏上。Ni先生由于没有跟最初的需求方研究院的Yu先生直接沟通过，心里有些没底，所以打算约Yu先生一起沟通一下，此方案是否能够解决Yu先生的痛点。

于是Ni先生约了所有的相关人员，当面进行沟通。Yu先生当面阐述的需求起因，和X女士转达的基本相同。但是当Ni先生把自己的方案给Yu先生看时，Yu先生表示导出的文本路径会发生改变，方案并不能够让自己根据文本路径很快的找到对应的音频。但是Ni先生记得导出的文本路径并没有发生改变，为什么会找不到对应的音频呢？正当沟通陷入僵局时，B女士提议各方负责人直接按照真实场景的操作方式演示一遍，在演示的过程当中发现问题。于是X女士导出了一份结果数据，打开结果数据中的文本文件，发现文本文件中的路径和上传时的文件路径并不相同，而且与导出时的音频路径也不相同，所以即使音频导出时的路径和导入时的路径保持一致，根据现有的文本中记录的路径也不能够找到对应的音频。所以B女士，依据会议上演示的场景给出了自己的解决方案，即导出的文本文件中记录的路径和导出的音频文件所在的路径保持一致。至此，该方案终于得到了原始需求方Yu先生的认可。

 

1. 问题诊断：

3.1 传输路径过长，关键人员缺少直接沟通

由于原始需求方和最终制定方案的人，中间隔了两位转述者。转述者并不能够将需求的所有细节以及背后的原因，及时的同步给制定方案的人。导致沟通流程较长，具体的细节还需要跟原始需求方进行沟通，耗费了许多人员的时间。

 

3.2 需求的转述者缺乏对需求的深刻理解

需求的转述者缺乏对需求背后原因的理解，所以当需求的接受者需要了解原因，制定合理方案的时候，还需要转述者在双方间做二次沟通，浪费了较多的时间。

 

3.3 需求的接收者缺乏对业务实际操作和体验

需求的接收者仅凭需求的提出者和转述者的描述以及自己的记忆来制定响应方案，缺乏实际操作和体验，导致制定的方案能够解决实际问题。

 

1. 解决策略：

4.1 缩短关键人员的沟通路径

原始需求方和制定方案的人直接沟通，并将最终制定的方案同步给相关的负责人。这种沟通方法既保证了沟通的效率和准确性，又节省了部门多位负责人的沟通时间。

本案例中沟通路径过长的原因是因为有中间转述者，而存在中间转述者的原因是工作需要分工，X女士只负责数据生产的管理，对数据标注的工作比较擅长，和Yu先生的对接频率也比较高。Ya女士只负责产品数据的汇总和管理，对数据的生产过程了解较少。Yu先生需要什么样的产品数据，需要先和X女士沟通，由X女士进行生产。生产的产品数据需要满足什么样的形态既需要告知X女士，由X女士转述给经常沟通的Ni先生。也需要和Ya女士沟通看是否满足统一管理的需要。而作为需求的接收者，首先应该满足的是原始需求方的需求，同时也应该将解决方案同步给利益相关方，各方达成统一意见。

当多个需求方的需求出现矛盾时，利用优先级的排序解决争端，主要的方法是象限法。其核心思想是将参考两个维度进行比较，由此决出先后。但是有些例子本身不够全面，比如其中一个分析优先级的例子，将需求实现难度和价值产生的快慢作为横纵坐标，那么越靠近原点的坐标优先级越高。2个维度的比较固然简单实用，但是在实际中，我们面临的许多问题往往是更多维度的抉择。比方说，决定一堆需求的优先级的维度除了实现难度、价值产生快慢，还有价值的大小、价值是否具有复利（具有复利价值的功能应该尽早上线）。如果这些维度的重要程度是一样的，我们可以尝试引入X, Y, Z三个轴的空间直角坐标系，同一个空间象限的需求向量，比较它们模长的大小，并作出决策。对于更多维度，且不同维度的重要程度不一样，则可以引入层次分析法，辅助判断。

 

4.2 了解需求背后的原因

沟通中的所有相关方都需要了解需求背后的原因，知其然并且知其所以然。这样就可以跳脱出需求本身，以更宽阔的视野，探寻更多的解决方案。

不同类型的需求收集手段是不一样的。简单的需求、可用性调查适合用问卷调查。因为做问卷的人通常没有耐心思考较为深入的复杂问题。对产品细节、交互体验的使用适合直接观察使用者的真实使用过程，将使用过程中发现的问题同使用者进行交流，弄清楚使用者本人的内心真实想法，以此来指导产品改进。这种方法往往能够发现产品人员习以为常，但是对用户来说却存在不便的问题。

需求整理过程中，从不同的用户角色去分析，他们的需求点以及每个需求点背后的动机，用户在哪些场景下会产生这些需求。然后通过结构化思考再表达给信息接收者，结构化的方法有多种多样，结构化思考的好处是能够帮助自己全面深入地思考问题，条层缕析。也有助于我们去表达想法，说服他人。

 

4.3 耳听为虚，眼见为实

需求的接收者在制定方案的时候并没有将资源部同事使用导出功能时的全流程真实地再现一遍。所以在导出文本时，文本路径是否改变的问题上，记忆中的结论是错误的。导致在制定方案的时候，无法解决需求方的痛点。所以这就要求我们在与别人沟通前，需要设身处地的站在对方的角度，尽可能详细的体验对方在真实的场景中遭遇的困难。听别人转述的内容，永远不能替代自己亲自验证得到的结论。只有自己亲自验证了才能够准确的给出契合需求方需求的解决方案。