当谈到项目管理，管理者更多的会讨论和研究的话题是围绕范围，时间，成本，质量这四个主要的领域展开，相对的，也挺少会看到一些文章，深入讨论沟通管理这个领域。沟通在团队规模较小的时候， 问题总是不会太过重要，换句话说沟通成本还是相对能够控制，但是当团队规模的不断变大，甚至是团队的组成比较复杂的时候， 团队之间沟通的成本就会逐渐增加，也会成为我们项目管理人员不得不面对和改进的重要问题。
想象一下这样的情景，团队成员经常会抱怨忙不过来，而当问起原因大多会有这样的回答， “人员不足”。 管理人员也没有经过论证，单纯的把这个问题抛到到了上层， 作为团队交付没有达到预期的最好借口。人员紧急补充，交付逐渐增加， 但仍旧没有达到预期，因为人员补充了1/3，但交付也许只增加了1/4。人员随之进一步增加，但情况持续下滑， 随着人员的增加，交付并没有增加相匹配的量，直到有一天，即使增加了人员，交付也没有什么明显的变化， 甚至于还减少了。导致这个问题的原因是系统性的， 但是有一个很直接的原因就是因为沟通的成本增加比生产力的增加要快。
加入网易后，我就一直担任网易云计算的项目管理工作，云计算大大小小有不同的模块组十余个，总人数逾130人，而且这些模块组还来自于多个不同的部门，虽是一个项目组却不得不进行部门间的合作，论人数这可能未必是网易最大的项目，论技术复杂度和各模块之间的协作，绝对是网易屈指可数的项目之一。
技术的复杂度加上组织架构上的特殊性，天然的决定了云计算这个项目所面临的沟通成本不会低，大部分的隐性风险可能都会源于沟通的问题。
进入云计算项目起初，我经常会碰到林林总总的沟通问题，先让大家看几个案例。
案例1
PaaS层某服务leader有一天，急冲冲的跑了过来（虽然都坐在一块区域，但人数多，往往最远的团队可能要相距50米，中间隔了2-3个会议室）。
PaaS某服务leader：“昨天我们线上服务某功能失效了，听说你们底层昨晚升级，原本工作的接口现在不工作了，我们整整查了一宿，怎么改了接口也不通知一下，你们得要负责！”。
底层leader听了不乐意了，立马翻出一封系统发的上线通知邮件，“看，邮件上写的清清楚楚，参数和以前不一样了，请上层做好适配，这责任还得你们自己背！”。
“每天这种邮件那么多，怎么可能一一看过来”，PaaS某模块leader，又不服气的说。
“那通知已经发了，况且我哪知道你们谁用了，会不会出问题？”，底层leader也不示弱。
争吵持续5分钟，10分钟，30分钟…1个小时，始终没有结论，但又怎么会有结论？
案例2
A为了完成任务依赖某一模块的工作，于是向B提出需求任务，他们一合计没什么问题，B也就接受了，同意1周后完成。为了不至于等待，A继续其他任务的工作。
1周后，A向B询问任务的进展，B回答，“为了要完成这个任务还需C的工作，需求任务也提给C了，他也正在开发中”。
“那啥时候能给？”A有点急。
“C一完成我马上就能给你”，B说。
时间又过了一周，A又去问B进展。B回答，“C好像碰到点技术难题，一直没完成，具体什么原因你去问问C吧？我这儿正忙着其他工作”。
A无奈找到了C，C告诉他，“的确碰到点技术问题，需要重新修改原本的设计”。
两人一商量敲定了方案，约定就这么做，一周后完成。A心想这回总好了，心满意足的回去了，但一周过去了还是没动静，A去问C进展，C说，“约定的方案当时没叫上B，现在对接到B那边又出了问题”。
A：“…”。
最终什么时间解决的也不得而知，A由于心力交瘁，再也不想管这档子事儿了。
案例3
这是一个大块的功能设计，涉及到多个模块的工作，设计由核心模块出，其他团队配合。在设计评审会上，各方都参与了会议，虽然有不少争论和讨论，但最后也确定了设计方案，大家也表示没有问题，会按设计完成。待到按时完成的时间，突然发现工作不起来。一查，原来当时出方案的时候，核心团队并未了解其他团队目前的设计和工作模式，其他团队也并未完全搞懂整个设计的真实需求，大家也都只是在各自理解的基础之上达成了表面的共识。当真的联调的时候发现，以现在的实现无法达到最终的需求目标，而如果要达到最终的需求目标，其他模块的实现目前也无法做到。
互相推责抱怨的声音，又开始此起彼伏，不绝于耳。
以上的例子，读者想必也会深有感触，可能也会因为这些问题痛得深切，惺惺相惜而感动落泪，仔细总结一下就会发现，沟通的问题有如以下几种类型：
信息不交换
信息传递不正确
信息传递损耗
信息传递中断
信息传递链路太长
立场对立
沟通人员太多，沟通成本高，耗时长
对在云计算里摸爬滚打的经历，我加以总结，并以三个维度（沟通模式，流程制度以及价值原则）来具体分享我的经验， 也希望能给那些同样面对大团队沟通问题并困扰其中的管理者们一些借鉴和参考。
(本文于2016-02-18首次发布)
