10.1.2 沟通信道与编解码模型

10.1.2　沟通信道与编解码模型

在Shannon-Weaver模型的基础上，对于日常沟通而言，沟通信道与编解码模型是值得我们关注的两个方面。

1.沟通信道

在Shannon-Weaver模型中我们提到了沟通信道，即当面沟通、视频电话会议、即时通信、Email这些沟通方式。不同的沟通方式各有优劣，主要体现在信道容量与可追溯性两个方面。

信道容量是指信息传输速率能够达到的上限，上限大小与带宽和信噪比相关。带宽可以理解为在日常沟通当中，一种沟通方式或沟通工具能够支持表达者传达多少信息出来；信噪比可以理解为沟通过程中干扰因素会在多大程度上影响沟通。

从信道容量角度看，上面这几种沟通方式的信道容量由大到小依次是：当面沟通＞视频电话会议＞即时通信消息≈Email。其中，当面沟通的信道容量最高，支持语言、图文展示、肢体语言，以及产品经理与工程师沟通过程中常用的一项非常重要的沟通工具——即兴板书，同时基本不会有环境噪声；其次是视频电话会议，也可以支持这些沟通形式，但容易被环境噪声影响；最后是即时通信消息和Email，基本只支持图文展示这一种沟通形式。

可追溯性衡量的是当沟通完成后一段时间内，还原当时沟通场景与沟通内容的难易程度。这一点前面提到的沟通模型中未提及，却是产品经理工作当中最需要关注的内容之一。可追溯性高一方面可帮助参与沟通者对相关内容进行备忘，另一方面可在发生冲突时帮助提供解决依据。

从可追溯性的角度来看，则恰好与信道容量相反，可追溯性由高到低依次是：Email＞即时通信消息＞视频电话会议≈当面沟通，其中Email的可追溯性最高，支持检索到具体项目且沟通内容完整；其次是即时通信消息，支持检索，但沟通内容较为碎片化；最后是视频电话会议和当面沟通，可以说基本上无法追溯。

从信道容量与可追溯性两个角度我们也可以看到，各种沟通方式各有优劣，没有哪一种是完美的，因此在工作过程中建议：

·沟通时尽量选择信道容量更大的沟通方式，在条件允许的情况下尽可能使用信道容量最大的沟通方式——当面沟通。

·使用多种沟通方式以便互为补充，增加可追溯性，例如当面沟通后再通过Email确认沟通内容，视频电话会议后总结会议纪要并以Email的形式发送给所有的参与沟通方等。

2.编解码模型

仔细观察我们会发现，图10-2所示的沟通模型与第8章提到的AutoEncoder从某种程度来说有异曲同工之妙，信息经输入环节后进行编码，经传输后进行解码并输出，整个过程通过反馈不断调整，最终达到输入和输出尽可能一致。

图10-2　AutoEncoder与沟通模型

当明确沟通方式后，是否可以随便沟通，也就是想到什么就说什么？这就好比在上面的AutoEncoder神经网络中，如果我们尝试任意的网络结构，例如采用不同的节点数量或网络层数，这样试验的成本就非常高了。

最好的办法是，根据对业务或数据的经验提前设置大致的网络结构，控制网络层数以及编码和解码部分的节点数量。假如我们能根据先验知识和经验，对沟通的结构进行约束，明确要沟通的要点有哪些，那么就能有效提升沟通效率，降低沟通成本，避免天马行空式的沟通——这就是我们要谈的沟通过程中的编解码模型。

在生活和工作过程中都有哪些沟通的编解码模型呢？以去医院看病为例，与医生沟通的编解码模型可以包含如下几个方面。

·当前病症：什么时间发现身体的哪个部位有什么不适？什么情况下会加重或减轻？持续多长时间？

·检查报告：近期做过的体检或检查报告（如果有的话）。

·病症史：与病症有关的过往病症史、家族遗传病史等。

与一上来就讲孩子上学、老人出行的故事，结果5分钟后还没进入病症描述相比，这种沟通结构要高效得多，这实际上也是医生在临床问诊时使用的沟通结构。

前面提到的函数方法论中的业务函数与各要素不仅是思考框架，也是策略产品经理与算法工程师沟通的编解码模型。例如，假设双方要设计一个内容风控方案，那么双方的沟通结构与沟通内容可以包含如下部分。

·业务函数：f（用户，内容）=是否有业务风险，业务风险包括垃圾广告、色情、反动、政治讨论等当中的一种或多种。

·样本：历史上被运营人员判断为有业务风险的内容和线上无业务风险的内容。

·特征：对内容的解析与统计，包括图片与文字等；用户相关的一些信息，如用户注册时间、历史发布过的违规内容比例等。

·评估：离线指标包括模型的精确率、召回率与AUC等指标，线上指标包括漏判率、误判率、举报率等。

·基准策略：基于敏感词表的正则判断策略等。

双方在这些沟通要点上达成一致后，有助于后续工作的开展，包括协调样本数据的准备、评估指标埋点或落库方案设计、线上A/B实验方案设计、离线模型设计与优化等。

以上这些是点对点沟通的例子，点对多或多对多同样可以基于类似的编解码模型进行沟通。例如在项目管理过程中，PRD文档就是这样一个点对多的沟通编解码模型。一个PRD文档应当至少包括以下部分。

·背景与目标：面向项目中所有相关人员，尤其是决策人员的沟通模块，包括基于需求分析和数据分析的项目背景以及项目目标。

·产品功能与逻辑：面向UI/UX、研发、测试等工程师的沟通模块，是PRD文档的核心部分，包括页面交互、业务状态机、数据流和业务流逻辑等。

·非功能需求：面向其他项目支持方或利益相关方的沟通模块，包括财务、法务、运维、DBA等相关人员。

·运营计划：面向运营人员的沟通模块，包括项目上线后的运营方案与一些应急备案。

可以看到PRD文档中的每个部分都是产品经理面向一个或多个沟通对象的编解码模型。成熟的产品团队一般都有PRD文档规范，PRD文档可以用于记录项目各方从项目立项开始依次达成的共识，能够减少反复沟通带来的信息失真与成本损耗。

对于多对多沟通的情况，例如会议沟通，也可以约定类似的沟通编解码模型，例如以下就是通过会议解决冲突的一个基本沟通框架，与会人员可以按以下顺序依次达成共识。

·目标：与会人员要解决的冲突和达成的目标，例如解决线上产品问题与运营资源不足的冲突，或就营销投放的预算方案达成共识等。

·决策逻辑：一些解决冲突的原则，例如用户利益优先原则、投入产出比（ROI）最大化原则等。

·信息：与会各方共享用于决策的信息，例如市场投放人员从一线获得的当前市场投放成本分布数据、产品运营人员或增长负责人获取的产品留存数据等。

以上就是一些沟通当中涉及的具体的编解码模型以及相关案例，工作当中出现的“鸡同鸭讲”“对牛弹琴”等沟通问题很大程度上描述的就是缺乏这类有效编解码模型的状况。对于团队管理者而言，在团队内部或团队间沟通前约定好沟通模型，能够有效避免出现上述状况，减少管理成本。