团队沟通成功案例.docVIP

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