团队沟通



团队形成合力，则有强大的战斗力。五根手指，蜷在一起，就是拳头，手指脆弱，但是拳头强有力；手指并不是简单的合在一起，而是通过手掌联系在一起，使之成为一个有机整体。同样一个团队，如果抱团在一起，也会形成强而有利的“拳头”，同样团队的个体，也不是简单的聚集在一起，而是聚合在一起，要想聚合，就必须有纽带，这个纽带就是沟通，而且是有效沟通。

一个人再强也不是万能的，有句话说“两人智慧胜一人”，“三个臭皮匠，抵个诸葛亮”，人多就要发挥人多的优势；一加一大于二的前提是有着良好的沟通，一个人的想法在得到另一个人的理解的同时，两个人才能才能就这个想法讨论，同样一个人的想法要想在团队内获得良好的讨论，必须团队的人首先理解他的想法，才可能进行有效沟通。

各自为战，都是按照自己的想法想当然，自认为聪明，认为别人的想法都不如自己，别人的设计只是如此而已，如此，这个团队就危险了，定时炸弹可能随时埋下，在某个时间内被引爆。

一个团队首先要沟通。在修改某人的设计或者相关代码之前，和原始设计者或者代码开发人员沟通是第一重要的，也是必须要做的，否则，潜在危险可能就此产生。本人所在团队，在移动互联网刚要兴起的时候，由本人设计android版的一个OA系统，由于当时网络资费昂贵，网速慢，所以采用了专门对http协议定制的方法，尽量缩减流量，提高响应速度和运行的流畅性，期间，本人由于有事，回老家办事，工作由团队另外一个技术经理暂时接替，为了方便沟通，本人24小时开机，以备咨询。可惜的是，等我回来的时候，一个电话也没有，我认为工作进展顺利，但是当我回来的时候，我惊呆了，架构有所改变，他采用了apache的http协议封装来支撑这个OA系统，我觉得很奇怪，因为apache的这个包，在做架构的时候研究过，针对pc端的，臃肿且庞大，而且无法实现低流量，高性能响应。我问他为啥采用这种技术，有何优点，我的设计你看过吗，他回答说这是标准的，我说修改之前为啥没和我沟通，他说联系不到.......。后来，用户要求实现可以查看此系统对流量的消耗情况，以减少最终客户顾虑，这时候，问题来了，当需要实现流量统计功能的时候，由于底层封装，发现很难简单做到。要么放弃此功能，要么修改apache底层代码实现，这两点哪个都不是项目所能接受的。为了达到用户要求，不得不改回当初的设计，而且要花费时间重构代码，结果成本投入翻了几倍........

一个团队，要有效沟通。某个公司，为了实现所谓的正规化，在一个坐在一起的10人团队中使用了bug管理系统，但是遗憾的是，大家从来不主动登录这个系统，没有在问题解决后，输入解决方案，更没查过已经解决过的问题。每个人发现了问题后，都登录这个系统，填写问题。然后喊一声：某某某，我给你提了一个bug，你登录看看吧。结果某人登录，然后回头说：你的这个问题是啥意思？你再给我说一遍，然后就是一通讨论解释。我很奇怪这个系统存在的价值何在，为了所谓的正规？一个系统的引入，如果不能有效的使用，那么就没有存在的必要。如果一个系统的引入，让大家的工作效率下降了，那么这个系统就是个累赘，耗费成本的垃圾。如果大家时刻关注这个系统，或者此系统有通知机制，又或者可以参考以前发生相同问题，那么它就有存在的必要。但是，遗憾的是，这些都没有，使用这个系统起到的作用就是浪费时间。可以一句话解决的问题，为啥非得绕那么大的圈子？绕圈子不是浪费时间和资源吗？有效沟通，要直接要有效率。