沟通管理作为项目管理核心知识领域之一，在项目管理和团队协作中的作用毋庸置疑。沟通管理涉及的范围很广，本文从沟通的重要性和模型出发，主要从信息传递和信息维护这两个方面对沟通管理进行阐述。

《圣经▪旧约▪创世纪》中提到了继诺亚方舟之后，人类历史上最大的工程就是建造巴比伦塔，但这个工程却以失败而告终。作为基督教徒，我还专门去翻了一下圣经。如果我们把建造巴比伦塔也看作是一个项目的话，这个项目的资源（两河流域丰富的石材和泥土）和时间（不计时间）都没有限制，项目启动后也非常顺利，但因为塔的高度直通云天引起了上帝的不满，所以上帝发明了多语言促使人们的沟通和协作出现问题最终导致了项目的失败。

回到现实，我们可以通过抽象把沟通过程描述成如下模型：

上述模型中无论是信息的编码和解码、发送和接收都会受到多种干扰导致信息的传递出现问题，如何保证信息传递的高效性是本文进行阐述的一个重点。

有了沟通模型，我们关注另一个项目管理中的重要概念：干系人。简单的干系人模型可以抽象为围绕”我“可以引出事情，只有满足是我的事情而且与这间事相关的人才是我的干系人，即下图中的1和2两个条件都需要成立：

影响沟通管理的另一个主要方面是组织过程资产，组织过程资产一般分成两个部分：

• 流程与工具：与沟通相关的包括沟通标准流程、媒介使用的模板、沟通模式和工具等
• 共享知识库：与沟通相关的包括项目档案、知识库、回顾数据等

人员组织结构等事业环境因素同样也会影响沟通管理的具体开展方式，各个组织可能差异较大，这里不展开。

二. 信息传递

信息传递的模型可以通过以下简图进行展开：

1. 信息传递的维度

信息传递的维度按照不同视角看可以有很多类别，一般包括如下几种，每一种参照字面意思即可：

• 内部（在项目内）和外部（客户媒体、公众）
• 正式（报告、备忘录）和非正式（电子邮件、即兴讨论）
• 垂直（上下级之间）和水平（同级之间）
• 官方（新闻通讯、年报）和非官方（私下的沟通）
• 书面和口头

2. 信息传递的模式

信息传递的模式只有三种，各种模式的特点和适用场景总结如下：

• 拉模式：受众明确、时效性强，但不适合版本信息管理
  
• 推模式：受众面广、平台化管理，适合版本信息管理
  
• 交互模式：实时性强、成本高，所以交互议程和节奏是关键

3. 信息传递的媒介

信息传递的媒介和传递模式紧密相连，这里结合上述传递模式的特点和适用场景分别列举一项最典型的传递媒介：

• 邮件，推模式的代表媒介。邮件是比较正式也最常用的推模式，即我把信息推送给你，至于后续你如何处理就看你的安排了。所以适合多方协作且时效性不强，需要明确细节、追踪状态、安排事情等场景使用。但因为推模式的效用只限于本次记录，所以类如对某一个文档不停更新版本并进行通知的场景，每一封邮件都会导致接收方生成多个工作副本，故需要版本信息管理的场景不适合使用推模式，而应该使用拉模式。

• 共享库：拉模式的代表媒介。共享库的运作方式如下图，信息发布者和信息接收者通过信息共享库进行交互并根据需要变换相互之间的角色。由于很多共享库带有版本控制功能，对提交者以及提交内容能够进行跟踪和管理，故适合团队协作和过程资产建设。

• 会议：交互模式的代表媒介。会议作为信息传递的媒介需要参与者做统筹安排，否则信息传递的效果会大打折扣。会议的发起者通常是管理者角色，而接收者可能来自跨职能的各个部门和小组。发起者和接收者之间的意识形态、工作方式等存在一定差异性，故会议前的准备、会议中的议题和节奏、会后的工作事项落地都会需要成本。相比邮件和共享库，交互模式中的会议是信息传递最需要管理理念渗入的一种媒介。

4. 再论干系人

5. 场景分析

针对周围碰到的信息传递过程中的问题，列举若干典型场景：

• 不必要的干系人：一般组织内部的邮件通常为以组的形式进行管理，如果你这封邮件只是发给某些人，那就不要用邮件组。邮件组是“不必要干系人”的典型应用场景，有些职位的人会加入到很多邮件组中，如果他每天都收到几十封和自己完成没有关系的邮件，那真正需要他采取行动的邮件很可能会被遗漏，导致沟通出现问题。
• 不正确的干系人：在项目启动会上我们会进行该项目的风险分析，如果你把“项目实施人员经验不足”这条风险写到启动会报告中，那很不幸你没有找对信息传递的干系人。“项目实施人员经验不足”确实是一项需要进行内部管理的很重要的风险，但项目启动会可能面对的是项目的甲方、乙方以及其他供应商，如果你说做这个项目我们的实施人员不行，你让其他方的人怎么想呢？
• 不合适的维度：典型例子有通过QQ传递重要信息；口头通知项目决定；项目数据非可视化沟通；缺少内部/外部信息过滤等。
  
• 不合适的模式：如果你想和团队成员分享一个很好用的小工具，那建议你不要用邮件去传递信息，因为邮件可能会被删除和遗忘，这种场景下运用拉模式通过SVN或FTP等共享库进行信息传递往往是更好的选择。
• 不完备的模式：主要是对会议而言，上面也提到会议需要进行统筹安排方能发挥其效用。会议前需要明确输入、议程和输出；会议中关注演示和节奏。如果一个会议连基本的输入输出都不明确的话，个人建议还是等这些都明确了之后再召开会更好。
• 不合适的媒介：如果你写一个文档，这个文档是静态的，即后续不会有任何变动和更新，那你把它放到Redmine这种工具平台上是合适的。反之，如果这份文档需要进行版本的演进和更新，那Redmine就不是合适的媒介，强烈建议使用带版本控制功能的共享库进行这些文档的统一维护。下文我们就从信息维护的角度出发再对沟通管理进行进一步分析。

三. 信息维护

信息维护是一项涉及知识库、过程资产、环境和交流等元素的整合过程，该过程包括信息保存的成本、信息转移的成本以及信息转化的成本，由于这种成本比较隐性，很多时候我们都或多或少不想投入这种成本，导致信息维护的完整性和时效性上出现问题。

同时，信息维护通常也和知识管理有很大交集。知识管理就是解决“隐性知识显性化”这个问题，而信息维护是确保解决这个问题的表现和手段。当同样的步骤需要重复发生？当信息传递因为人而中断？我们是否会想我们缺少什么，我觉得首先我们缺少的是一种统一平台。

1. 工具平台

简单列举若干个周围环境常用的工具平台，市面上也有很多类似的工具，可做类比，如下图：

• 版本控制工具：如果信息需要分版本、需要定期/不定期维护、需要团队多人协作，那版本控制工具是必需的，主流的包括SVN、GIT等。
• 问题跟踪工具：如果信息的特点是随项目/产品开发进程不断需要范围变更、问题抛出/解决、多方干系人参与，那采用一套完备的问题跟踪工具会事半功倍，主流的包括Redmine、Jira、Quality Center。一个组织最好只使用一台这样的工具，我们使用的是Redmine。
• 静态资源工具：如果信息只是一些静态资源，不涉及变动，但就用FTP吧。
• 知识共享工具：如果信息属于知识管理范畴，那采用一个知识共享工具能帮助团队解决很多耗费尽力但成效低下的信息共享和维护需求，主流的包括各种Note后缀的工具，很多是面向公网平台且不大适合内部团队使用，如果你想在组织内部建设一个知识共享平台，Office自带的OneNote可能是一个不错的选择。

2. 实践

有了工具平台，梳理所谓的“Best Practice”也是组织级别信息维护的重要方面，这些实践可能见仁见智，简单列举几个个人认为比较有效的做法，供参考：

• 信息按领域归类：把信息按领域进行分类是常见的也是很有效的做法，这一实践关键要按照工作特点进行领域的明晰梳理，我们团队的SVN团队共享文档根目录是这样的：