腾讯CDC：如何有效进行跨团队、多角色的沟通？

作为设计方接口人，我近期参与了某产品新版本的交互设计及开发跟进工作。该项目的产品规划、设计、开发、运营由京深两地四方多个团队合作进行。结合自身项目经历，现将我对跨团队多角色沟通的感悟与经验加以总结，希望对大家有所帮助。

一、背景

有效沟通是提升工作效率的基础，尤其是鹅厂这种业务涉及多地、对外多有合作的大型公司，进行跨团队的、多角色转换的沟通是工作常态。跨团队合作项目通常需要我们在团队内部、异地 leader、内外部合作伙伴、第三方外包等多种角色间灵活调整沟通方式，运用有效的沟通手段，以确保沟通效果。

二、索引

本文将从有效沟通的心理建设、角色分析、流程搭建+工具沉淀三个层次展开。

三、心理建设

1. 有效沟通的两点认识

为「传」而「达」

沟通是信息的有效传达。「传」是手段，要求沟通时需阐明观点；「达」是目的，指明沟通旨在使人通达理解。沟通中出现的自说自话、固执己见，通常是偏执于「传」，而忽视了「达」。需要明确的是，所有的沟通，都应该以接收方更好的理解接受为目的，而不是自顾自的滔滔不绝。

减少损耗

信息传达的过程伴随着信息的损耗。因此，在沟通的各个环节都需注意减少损耗，提升触达率。一方面，要理清自己的表达重点和思路，减少信息的输出损耗；另一方面，要从接受方关注点出发，提升对接受者的信息触达；此外，还要灵活切换沟通方式、正确处理意见分歧等，尽量减少信息在传递途中的折损。

2. 跨团队多角色沟通的基本态度

跨团队——秉持中立合作的态度

• 中立——团队不同，诉求不同，秉持中立的沟通态度，不要因个人偏向导致无意义消耗。
• 合作——以同理心赢得各方的信任，避免抵触情绪的产生，营造良好的沟通氛围。
• 产品目标导向——对有争议的问题点，应综合权衡用户体验、产品目标和开发成本，以产品目标为第一要义。

多角色——认清各方关注点的差异

• 理解各方差异化的核心诉求——对不同团队角色的沟通中应有不同的侧重点，灵活的转换角色，做有针对性的输出表达。
• 对内交流——以产品目标为导向，保证内部一致；对上汇报——重点明确，避免流水帐；对外沟通——目标明确，内部一致，有针对性的沟通，避免互相拆台或鸡同鸭讲。

四、角色分析

1. 项目组成员角色模型

项目伊始，在融入团队的过程中，应注意理清项目组内的不同角色，明确汇报对象，做好任务分工，理清利益关系，协调各方诉求。

2. 各角色核心诉求及沟通侧重点模型

不同角色的核心诉求不同，也因此在对不同角色沟通时也应该有所侧重，以本项目为例：京深两地四方的所有成员，可大致划分为如下七种角色。（详情请点击查看大图）

△ 项目组各角色核心诉求及沟通侧重点模型

3. 各角色核心诉求及沟通侧重点小结

五、流程与工具

1. 有效沟通流程模型

在有效沟通流程模型中，我按筹备、执行、跟进三个阶段，绘制出体验地图，将沟通中的关键节点按行为、心理、情绪、方法、工具五个纬度拆分，梳理各节点需注意的问题，以及相应的有效沟通方法和工具。（详情请点击查看大图）

△ 有效沟通流程模型

筹备阶段——明确目的，同步信息

• 明确沟通目的。无论是同步邮件、电话会议还是 IM 群聊，都需要在发起前明确目的，列好问题清单，带着目的沟通。如：多方电话会议前，应事先知会各方会议主旨，准备会议提纲并在会议开始时向各方阐明，为会议提供清晰的行进框架。
• 提前同步信息。信息同步是高效沟通的前提。依据沟通目的准备沟通所需的文档，根据需要提前同步，尽量减少因信息不对称带来的时间浪费。明确易读的设计输出、正式沟通前与各方单独的预沟通、提前邮件同步告知等，都是有效信息同步的手段。

执行阶段——抓大放小、促成共识

• 对待争议，抓大放小，避免僵局。评估争议点时，先不要基于反驳避免情绪化表达，适当发问：为什么做？为什么不做？不做之后有什么后果？理智全面的做出评判。给问题点评定优先级，抓大放小，集中精力推进主功能，高成本、低优先级的细节问题放到最后统一处理，避免陷入「就是要改」vs「就是不改」的无谓消耗。根据需要及时协调第三方资源进场，寻求技术支持或资深 leader 的建议，避免沟通僵局的出现。
• 促成共识。无结果的沟通是无效的沟通，有效沟通应促使各方达成共识。无论是待协调、暂搁置还是需改进，都需要有一个结论明确、责任人明确、截止时间明确的沟通结论，并依此执行跟进。

跟进阶段——同步落实，自我反思

• 进度同步，问题落实。沟通过后及时同步沟通结论，设计交付、前端交付等阶段性时间节点，需以正式的项目邮件，及时周知项目相关人员。对于已解决的问题，及时跟进验收；暂时搁置的问题，做好记录，明确时间节点和责任人；需更多资源介入的问题，及时对上反馈，申请资源解决。
• 自我反思与补齐。每次沟通都是一次查漏补缺的过程，每次沟通后花时间反思一下本次沟通中自己在设计说明中有哪些疏忽、表述上有何不足、相关知识上有那些欠缺，以此为鉴及时调整、补齐疏漏。

2. 工具沉淀

开发故事卡

说明：明确易读的设计说明文档。

功能：产品设计说明、开发指导手册、阶段性交付走查依据。

使用场景：跨团队沟通中，便于开发人员准确高效的理解设计意图；适合外部合作时模块化开发与阶段性交付，便于交付及走查。

使用要点：

• 根据信息构架拆分产品模块，分别设立索引，提供产品概览，串联各功能详情页。
• 在索引和详情页之间由超链接跳转，方便快速定位。
• 按照功能点拆分详情页，提出功能需求，明确验收标准，说明页面细节。
• 各页面统一编号与视觉源文件一一对应，方便快速查找。

需求管理文档

说明：需求及反馈问题的规范化管理模板。

功能：需求变动及问题反馈的管理模板、开发跟进的沟通文档。

使用场景：开发跟进阶段，实时记录变动的需求及反馈的问题点；设计侧定期反馈给开发人员的规范化输出文档。

使用要点：

• 明确问题及目标效果，排定优先级依此解决。
• 明确负责人和时间节点，保证落实。
• 做好文档更新维护及信息同步。
• 按阶段统一反馈调整，节约开发时间。

关注点推进模型

说明：不同项目阶段明确核心关注点的虚拟模型。

功能：辅助聚焦当下关注点，避免陷入不合时宜的细节或宏观问题。

使用场景：从宏观到微观的产品设计过程中，帮助梳理各个阶段需沟通的核心问题，沟通时陷入细节或反复争论时的自查工具。

使用要点：

• 做好关注点的逐步推进：探讨信息构架时就不要在交互样式上反复拉锯；讨论交互方式时就不要过度关注视觉细节。
• 不过早陷入细节。优秀产品的细节固然需打磨，但从0到1实现一款产品的过程中，将有限的资源和排期消耗在不合时宜的细节权衡上，得不偿失。
• 同样，若因执行时的设计挑战需调整产品上层，也需主题限定问题范围，不要因宏观问题上的反复而影响执行效率。

优先级评估模型

说明：不同项目阶段评估需求优先级的 KANO 衍生模型。

功能：借助 KANO 模型分析思路，对需求优先级提供排定依据。

使用场景：设计阶段样式取舍、开发跟进阶段需求调整的先后顺序、应对分歧如何抓大放小，都可以借助优先级评估模型辅助评估。

使用要点：

• 不同项目阶段，不同沟通对象对同一需求优先级的评定标准不同，因此应注意根据项目阶段和沟通对象灵活调整。
• 不同产品在用户体验与产品目标取舍上有所区别。一般而言，2C 产品更注重用户体验，而2B 产品则可能更注重实现产品目标，因此应注意具体产品具体分析。