PMBOK2008中的三种沟通方式（草稿版）

草稿哈，先凑合看，这几天还得重构呢。欢迎拍砖！

在PMBOK2008中介绍了三中沟通方式，分别是交互式沟通（Interactive Communication）、推式沟通（Push Communication）和拉式沟通（Pull Communication）。最近工作中遇到了一些与沟通相关的困难，正好结合理论知识总结一下。

交互式沟通：

在双方或多方之间同时进行多向信息交换，多数情况下是口头沟通。常见的方式有面对面的会议、电话会议、视频会议、网络聊天室（群）等。

• 优点：某些情况下，最高效的沟通方式。有问题可以当面澄清或者解决，非常适用于头脑风暴等。面对面的会议或者视频会议可以清楚得看到各位干系人的表情和肢体语言，有利于沟通的顺畅进行。
• 缺点：某些情况下，形成决策的效率非常低。有时会陷入扯皮中；如果有N名干系人参与沟通，沟通的路径就会有N(N-1)/2条，控制不好会陷入混乱。另一个缺点是有可能无法找到一个合适的时间段以确保所有必需出席的干系人都能出席。

建议：

• 明确的话题和会议目的。
• 会议进行中要有强有力的话题，进度控制。保证准时开始，按时结束。
• 尽早发出会议邀请，“占住”所有干系人的时间，保证重要的干系人能按时出席会议，并发表意见。
• 对于无法出席的干系人，尽量使用视频会议或者电话等实时性强的工具将其loop到会议中。
• 明确干系人的身份。哪些是必须出席的，哪些是可以出席也可以缺席的；哪些是必须要进行决策的，哪些是发表意见的，哪些是纯粹的听众等等。控制好各个角色，该主动一定不能沉默是金；该聆听的一定不能喧宾夺主。
• 解决复杂、困难问题时使用，典型应用就是War Room。
• 头脑风暴尽量使用交互式沟通。
• 防止“开小会”，这也就是经常有会议组织者喊“One Meeting”的情况。

推式沟通：

把信息发送给需要了解信息的特定接收方。常见的方式有邮件、电子邮件、传真等。

• 优点：当无法与受众取得实时联系时，受众处于不便于实时响应（休息、外出、专心于某项事情不便打扰等）或者受众故意躲避等情况，该方法是非常有效的。
• 缺点：这种方法有点像UDP协议，发布信息后，不能确保信息到达目标受众，也不能保证信息已被目标受众争取地理解。

建议：

• 推式沟通多为书面形式，适用于重要非紧急的事情。
• 当参与方较少时，比如只有两方时，适宜推式沟通。
• 当参与方较多时，如果可能产生多次信息交互，应尽量减少沟通方数量，将大问题分解成小问题单独沟通。千万别忘了N(N-1)/2！
• 推式沟通发布信息时，特别要注意受众的背景，减少误解、歧义的发生。
• 必要时，需要对方提供回执，甚至让对方用对方的语言复述沟通内容，以确保信息被接收并正确理解。
• 使用推式沟通时，应充分考虑受众的感受，尊重对方的私人空间和私人时间。

拉式沟通：

在一个或有限几个信息源集中发布信息，要求接收方自主自行地获取信息内容。典型的形势有公共网站，网络论坛，网络Wiki，企业内部网站，各种C/S B/S模式的项目管理软件等。其实大字报、报刊栏也是。

• 优点：特别适宜大团队的沟通，尤其是异地团队。沟通成本相对降低。有利于信息的积累，有利于信息变化的跟踪。可以发挥团队中每个人的积极性对信息源进行贡献（contribution）
• 缺点：搭建维护信息源需的时间、人力和技术成本较高。信息安全级别管理复杂，存在一定的信息安全隐患。信息沟通实时性相比于交互式较差。

建议：

• 大型团队合作，一定要使用拉式沟通！
• 团队成员间具有相近的文化，使用相互可以看懂的语言。
• 团队成员有更高的素质，具有开放、共享和奉献的精神。
• 限制信息源的数量
• 严格的权限管理，确保不同的受众得到其应得的信息，没有权限获得其不应得到的信息。
• 信息源上的信息要及时更新，避免“忘记”信息源的情况。
• 结合推式沟通，将信息源上的变化推到受众处。

拉式沟通与推式沟通的结合

随着信息源的不断增多，对于个人来说，想要及时的监视N多个信息源是个非常困难的事情。所以出现了拉式沟通与推式沟通向结合的方式。典型的有RSS阅读器，在微软工作过的同事对Bugger一定也不陌生，通过Twitter的Follow功能获得自己赶兴趣的人的微薄。这都主动把信息源上的信息通过“推”的方式“推”到自己这一端。

今天先写到这里，太晚了，明天继续。