老板和经理关注结果、基层管理关注质量。一个生产力高的Team，除了技术行之外，好的气氛和好的沟通方式是Team战斗力提高、凝聚力提高的不二法门。

本节主要讨论关于要主要内容是谈谈如何提高团队的士气，如何提高团队意识，如何解决在沟通中出现的问题等。这几个问题往往在项目开发中期，十分的明显，而我们又是在封闭式开发中，大家想快点出成绩，心情有些急迫。同时各个小组开发都走过了摸索和技术储备的过程，架构也都基本确定，各小组的成员都专心于自己的模块，各个模块的接口部份也都逐渐清晰起来，沟通问题也随之而来。

归根到底，沟通问题主要以下两个原因：其一、对结果不能统一。是对于需求的不理解和标准定义不同导致了这些问题的发生，主要存在于产品经理和开发人员之间。其二，对于结果可以统一，对细节不能统一。主要存在于开发人员之间。其三、当没有预料的问题出现后谁该负责，或者谁该出来解决的问题。如果以上三个问题出现次数较多，则会出现第四个问题：士气低落。

这几个问题如果要钻牛角尖，则否十分浪费战斗力和时间，特别是第二个问题，开发人员往往会由于面子问题或者工作量的问题会浪费争吵的时间。下面把几个问题分开开来讨论。

问题 一：对结果不能统一。

描述：在做即时通信中 。在有一次讨论中，老大提出来要把所有的可其它业务功能都像QQ一样集成到我们的即时通信子系统中，像QQ一样在左边栏中都加入一排竖着的快捷按钮。

我们现阶段的时间压力下，是无法实现这个功能的。当然，这个需求是在汇报的时候老板才提出来的，因为在我们的团队中，都是对结果的问题都比较统一，我们都想快速的结束掉封闭式开发，完成任务。

解决办法：会把这种需求写入到故事列表中，设置较低的优先级。因为对于即时通信系统来说，有其它的任务优先级较高，如发送群消息，好友查找等等。

问题 二：对结果能统一，但对实现细节不能统一。

描述：还拿即时通信做举例子吧，有一个需求是查找好友列表，这时候有两种实现方式。

在选择群内的好友时，可能有两种展现方式，一种是以列表分页方式。如下图所示。

另一种是在左边以树型的方式显示,有点类似下面的左半部份。只是实际的需求更复杂一些。因为QQ中的好友和分组都是相对固定的。如果我们要去所有好友中查询的话，那么他所属的组织机构可是我们没有的。如果查出来的10个人分别各自属于10个不同的机构，则左边的树型就要生成10棵子树。如果查出来有1000个不同的部门的人。性能可想而知。

后台开发人员认为性能底，后台实现复杂，用户体验也不好。

前面开发人员由于有类型模块，如果使用树型，则开发代码较少。

于是，两边“讨论”了一些时间，没有把这个问题给定下来。

解决办法：

找出已有的几种用户列表的展现方式，如China人网、 人人网。包括QQ本身，大多采用列表方式，也就是前一种。这样用户体验十分友好，性能也能达到要求。遇到这种问题，一定要用事实和实例说话，不能一股劲的坚持自己的观点。如果你站在圈内的时候，都会认为自己是对的，只有走出自己的圈子，才能看到整个问题的全貌。接着，要从对方的观点入手，把问题再分析一遍。

如下图所示：当我们都坚持自己的观点时，我们常常看到只有冲突。

   但是，我们如果把自己的观点先放着，试着想想我们的目标：完成客户要求查询好友，然后组建群组的故事。那么我们就能看到共同的目标，而不是冲突。如下图所示。

站在点方的角度，我的理解是先放下自己的观点，然后找到共同目标，再理解对方难处。先把心情给摆平了，再谈问题往往比较顺。一味的深入讨论实现方式往往会迷失目标，有人说，我们一直匆匆忙忙的走，却忘记了为什么要走下去。

问题 三：出现无法预料的问题。

描述：项目快提交客户演示了，由于网速过慢，要换一个地址来部署我们的系统。在重新部署的过程中，出现了一个配置问题。这个问题原来都没有遇到，可是说是测试的灰色地代。马上就要演示了，全部的开发人员都很紧张。有的人开始否定当初定的演示方案。。。有的人。。。

解决方法：第一，冷静。没有什么问题解决不了，只是环境变了而以，不会有什么大问题。第二、少说话。不要说和解决问题无关的话，不要讨论是谁的问题。按配置手册一个一个的排查。看调用的配置接口是否是过时版本，或者配置有冲突。如果这时候互相推卸责任，那那么演示时间必然拖延，而且也会大大影响士气。

第三、不要抱怨。好的习惯会传染，坏的习惯也会传染。特别是抱怨，有时候一两句无心的抱怨真的很伤人。

问题四：士气底落。

描述：前三个问题没有处理好，加上高层压力不减，每个人的神经都很紧。这时候就会出现士气低落的问题。

解决办法

1.           创建和谐气氛，弱等级化。在封闭式开发中，我们不要过分强调权力和等级，我们都是平级的关系，而是一个球队。开开玩玩笑也不要太认真。

2.           培养互助精神。开发快的小组帮开发较慢的小组。这也适合在结队编程中。

3.           任务主动获取。把故事都列出来，看一个迭代能完成多少任务，由开发人员自己按优先级获取，化被动为主动。

4.           让开发人员参与到设计中来。在进行设计时，可以召集开发人员讨论接口设计和一些基本模式设计，让开发人员能感觉到在成长。

5.           做好代码审查。这又是一个让开发人员学习和成长的机会，会让开发人员的重构技术和单元测试技术都有所提高。

6.           多组织一些好娱乐节目。这点在封闭式开发中不太可能，只能自娱自乐咯，呵呵。

小结：有人曾说过“只要沟通，世上就没有解决不了的问题。”这点在一个新的团队，大家都不是十分了解的时候，而压力又十分的大时，

我们往往会等不及听对方的观点，也不想去管那么多，只想让对方快点接受自己的想法。与此同时，还会想自己的解决方案这么全面，

性能也很高，为什么你就不接受呢，然后就是一阵阵的扭结，甚至争吵。真是得不偿失呀。

        目录： 
    封闭式开发小记(1)：封闭式开发的基本装备
   封闭式开发小记(2)：封闭式开发的时间安排
   封闭式开发小记(3)：封闭式开发的人员配备
   封闭式开发小记(4)：封闭式开发的架构设计
   封闭式开发小记(5)：封闭式开发的敏捷开发
   封闭式开发小记(6)：封闭式开发的文档管理
   封闭式开发小记(7)：如何和谐沟通、提高士气（结合开发实际冲突来深入讨论合作与沟通）
   封闭式开发小记(8)：封闭式开发的项目讨论(10.9)
   封闭式开发小记(9)：封闭式开发的最后一天(10.10)
   封闭式开发小记(10)：封闭式开发的项目汇报(10.11)
   封闭式开发小记(11)：封闭式开发的测试发布(10.12)