引:沟通，是一种对所学知识的综合应用，这是我最近又体悟出的一个道理。
沟通，是一种对所学知识的综合应用，这是我最近又体悟出的一个道理。
沟通管理，是项目管理知识体系中非常重要的一部分，所以在学习项目管理的时候，也把相关的知识作为重点内容来研读。但是，总感觉这部分内容可操作性比较差、比较难应用。
前段时间，个人在项目管理俱乐部活动上，作为嘉宾分享了个人对沟通管理的一些理解，现在想来很是惭愧，因为那次活动直到结束，我也没有很明显的感觉到自己讲的主题，尽管在之前做了好长时间的准备，尽管有几个朋友做了良好的评价，但我还是不能保证能有一种我的观点深入在场人的心。现在想来，我倒更愿意把那个时候对沟通管理的理解划作为第一阶段，也就是了解了一些沟通的基本形式、初步认识到沟通的重要性的一个阶段。
沟通的重要性是大家都能说出来的，也是许多人都已经认识到的。但是，要实际去做才会有效果。如果要实际做，不仅仅是如何做的问题，还有一个做什么的问题。很多关于项目管理的书籍上都写了，项目管理者要花费70%以上的时间沟通，但是，并没有任何一种项目管理的书籍用70%的篇幅来告诉我们如何进行沟通。
项目管理是一个知识体系，越来越被更多的人重视。也只有对项目管理的知识有比较深入的理解，才可能去应用这些知识去进行实际的沟通。比如，当因某个团队成员落后于大家的进度而使里程碑的实现延误，作为项目管理者，要去与他沟通，那么我们是应该批评责怪还是找到问题的所在？理智的讲，我们要选择后者，可实际中，往往是前种结果发生得多一些，或者先责备再找问题。可我们知道，计划的延误与很多方面有关。
首先是里程碑的制定是不是合理。有一个“零缺点里程碑”的概念，所谓零缺点，并不代表软件中没有错误，也不表示没有遗漏的功能，而是指团队的成品经过测试验证达到了事先规划的品质水准，这就要求对一些要求要有明确的叙述。同时，每一个里程碑应有专属的宗旨，比如手机研发过程中，软件会对应GCF或者某次CDG测试，那么满足这些测试的要求的相关模块是有较高优先级的，不关键模块的要求在里程碑中可以订得低一些。
其次是团队的建设方面，任务分配和相互协调是否到位。研发的过程本来就是动态的，充满合宜与冲突、愤怒与喜悦，团队的行为是变幻莫测，基本上不能以组员的心情愉快与否、日程落后与否、或是表面上的行为与事件来判断整个团队行为是否正常。目标的确定要达到团队共识，并且要让整个团队共同承担达到里程碑的责任，除非每个人都达到，否则就算没有人达到里程碑。
再次是平时对项目进展的关心程度是否到位。落后不是一天造成的，落后不是到了到了里程碑的时候才出现的，也不是到检查点前一天才发生的，它每天都在发生，每小时都会发生。当然，关注的方法有很多，团队成员彼此之间的工作时程有上下游和回馈的关系，彼此互相依赖彼此的进度，于是形成了实施检查点的动机，而不一定要是靠管理者的铁腕来强制。
还有就是是否关注到团队成员的技术水平，安排的任务是不是很明显超出了他的能力范围。如果在手机的研发过程中让一个刚毕业的学生负责打电话模块，就是一种不合适的安排。
所有的这一切，任何一点出了问题，都应当是项目管理者的责任，而与开发人员无关。如果我们希望能通过开发人员的优异表现而掩盖自己的管理漏洞，这实在是一种不情之请，也太冒险。
作为“拖后腿”的当事人，他已经承受了懊恼、自责。相信我们团队中的每一个人都会很自觉地反省自己的过失，不管是由于自己的懒惰、低效率还是知识欠缺而造成不好的后果，他都会很自觉地承担。看到过这么一段话：一般来说，只要是健康的团队，不论成员的素质高低或是延误的情形严重与否，发生延误的组员都会觉得不好意思，而主动试着解决它，他会尝试修正对自己的期望，改善自己的工作效率或工作方法。管理者应该帮助他，责难他是愚蠢的行为，就好像责怪某一片叶子怎么可以从树上掉下来一样没有意义。
所以这个时候，我们应该与团队人员一起去找出问题的真正原因。
这样看来，如果一个人没有里程碑、计划、团队建设方面的管理知识，相信会本能地去责怪团队成员，或者即便不责备，也只是让团队成员反省，从开发人员的角度找原因，那么，事情发生的真正原因也许就不会被发现。整个沟通就不算很有效。
从这个意义上说，沟通管理，也是一种知识体系。这些知识，构成了沟通的基础，没有这些基础，讲沟通管理就是海市蜃楼。而如果我们仅掌握了其中的一点或一面，沟通都不会做得很好。换句话说，如果想真正做好沟通管理，各方面的知识都要懂才行。 |
